上个月我们做了一轮内部演示一个很简单的查询就把整套系统打回了原形。用户问的是“周末带小孩去浦东哪里看书比较安静”知识库里明明有十几篇关于亲子阅读空间、少儿图书馆、社区书房的优质内容线上的AI搜索却一条都没用上。原因不复杂文档里写的是“亲子阅读”“儿童阅览区”查询里全是“带小孩”“看书”“安静”这些口语化表达典型的召回失败。这个场景逼着我把AI搜索优化重新想了一遍——只调某个单点环节根本不解决问题必须把查询改写、知识库治理、内容分发、跨模型引用监测、周期复测串成一条完整的闭环链路搜索质量才有机会真正迈过生产门槛。这篇文章就围绕我们在这套闭环里的技术选型与落地过程展开适合正在搭AI搜索团队、想把RAG项目从Demo推向生产的工程师和技术负责人阅读少走我踩过的那些弯路。1. 从一次失败的搜索演示说起单一优化手段撑不起AI搜索1.1 那台演示机器暴露的第一层问题那台演示机器当时跑的是很标准的RAG链路用户输入query向量检索top 20重排后取top 5丢给大模型生成答案。单看每个组件都是市面主流方案但端到端的效果就是不行。青少儿图书这个例子的问题不在检索而在“入口”——用户没有用文档里的词来表达需求向量检索在语义空间里也没能弥补这种表达差异。后来我们统计了一周的真实日志接近三成的失败查询都属于这种“原文不会这么说”的情况。这说明AI搜索和传统搜索最大的区别并不是多了个生成模型而是用户对它的期待变了他们会用更自然、更模糊、更口语化的方式提问默认系统能听懂。传统搜索靠关键词命中用户会自己换词重试AI搜索场景里用户更倾向于只输入一次长句等着系统理解。1.2 我为什么把查询改写放在第一优先级那次演示之后我们做过一轮复盘结论是召回漏斗的每一层都会过滤掉信息但最上游的查询理解一旦出错后面所有环节都没有补救机会。你可以在重排阶段用再强的交叉编码器也无法让一个从未被召回的正确文档重新出现在候选集里。所以整个改造项目的第一优先级不是换更大的模型不是调向量库参数而是先把“用户想找什么”这件事搞清楚。查询改写在这个阶段的定位是把口语化的、指代不清的、上下文依赖的原始输入改写成知识库更可能命中、检索系统更容易匹配的若干查询形态。它不像生成答案那样追求“妙笔生花”它追求的是“稳、准、多路覆盖”。1.3 闭环图景五个环节如何咬合沿着这条思路我们把整个优化目标定义成一条五段式链条任何一段单独拎出来优化都会在其他环节暴露出木桶短板。链条如下查询改写把用户原始表达改写为适合检索的查询集合包括同义词扩展、结构化查询、多路子查询。知识库治理保证内容本身是干净、结构化、可召回、可引用的包括切分、标注、去重、更新、下架。内容分发决定改写结果如何驱动检索策略包括多路召回、父子文档分发、重排、上下文截断和降级处理。跨模型引用监测在生成侧约束引用来源并自动核验答案陈述是否真的被引用片段支持。周期复测用评测集和真实反馈持续度量各环节质量让优化动作能够被量化、可回归、可回流。这个闭环不是一次瀑布式交付而是一个持续运转的飞轮。下面我按这个顺序把每个环节的技术选型、具体实现和踩坑记录拆开讲。2. 查询改写引擎的选型与调优别让召回在第一步就输掉2.1 双层改写架构规则层兜底、模型层理解查询改写这个模块我们最终采用了“双层架构”而不是一上来就全量依赖大模型。第一层是规则与词表层用词典、同义词表、正则、地名实体库做确定性改写第二层才是LLM改写处理规则层覆盖不了的模糊意图与复杂口语。这个排序是有意的规则层速度快、零成本、完全可控适合处理高频、确定性强的改写LLM层灵活、能理解上下文但存在延迟和改写漂移问题。我们见过不少团队把所有改写交给LLM结果单次改写耗时超过1秒线上毛延迟飙升同时出现“把用户的限定条件改没了”这类灾难问题。规则层先做一轮把能确定的先确定下来LLM只处理残差成本和质量都可控。规则层我们维护了一张针对上海本地场景的开放词表覆盖地铁站名、行政区划、商圈别称、机构俗称等。比如“徐家汇”“徐汇” “XJH”的归一化“浦东图书馆”和“浦图”的别名映射这些在传统搜索引擎里早就是成熟做法但很多AI搜索项目因为觉得“有大模型了不需要词典”就丢掉了非常可惜。词表的好处是行为可预期上线前可以逐条验收不会出现大模型那种“这次改了、下次没改”的随机性。2.2 LLM改写层的Prompt设计与输出约束LLM层我们只处理规则层无法处理的场景典型的有三类指代消解“它比那家更安静”中的“它”指什么、口语省略“附近哪有24小时能待的书店”——“附近”在对话上下文里指什么、复杂意图拆解“适合带三岁小孩去又能办活动的书店”隐含多个约束。LLM改写的Prompt约束我建议只做三件事一是忠实保留原查询的所有限定词禁止自行删减二是输出固定JSON结构便于下游解析三是要求改写结果必须有明确检索增益如果原查询已经足够清晰就原样返回不要画蛇添足。{ original_query: 周末带小孩去浦东哪里看书比较安静, rewritten_query: 浦东 亲子阅读空间 安静 推荐, sub_queries: [ 浦东 少儿图书馆, 浦东 亲子书房 安静, 浦东 儿童阅览区 周末开放 ], intent_tags: [location:浦东, scenario:亲子, constraint:安静], need_search: true }这里有一个很微妙的点改写不是越“文学”越好而是越“贴近文档语言”越好。所以我们在评测改写质量时不看它写出来的句子是否通顺漂亮而是看它召回的结果是否更准确。一个看起来笨拙的改写只要能让正确答案进入候选集就是好的改写。2.3 改写质量评估口径与几个典型的坑如果只用一个指标衡量改写质量我会选“改写后检索的Recall20”。具体做法是准备一批查询标注出每个查询对应的正确答案文档ID然后分别用原始query和改写后的query走同一套检索对比正确答案被召回的比率。这个指标比BLEU、ROUGE那些文本相似度指标有意义得多因为改写的最终目标不是文本像不像而是召回准不准。踩坑方面有三条经验值得单独写。第一LLM改写容易丢失数字和否定词比如“不要周末去”被改写成“周末去”这种错误在文本相似度指标里几乎看不出来但召回结果完全相反所以Prompt里必须强制要求“逐一核对限定词是否保留”。第二地名实体不能依赖LLM上海本地有大量历史地名、道路简称、商圈约定俗成的叫法LLM未必知道而规则词表一劳永逸这个就是为什么我说规则层不能丢。第三改写要控制在线耗时我们给LLM改写设定的性能预算是单次100ms以内超时直接降级到规则层结果宁可少一条扩展查询也不能让用户等待响应。实测在并发高峰期这个降级策略避免了大量超时故障。3. 知识库治理AI搜索项目真正的护城河3.1 语义单元切分固定窗口不是万能的很多团队把知识库治理想得太简单文档导入、切个chunk、存进向量库就以为万事大吉。实际做下来切分这件事就足够折腾人。早期我们也用固定窗口切分512字一个chunk、64字重叠跑起来很快但检索质量很不稳定。问题在于固定窗口会把一个完整段落拦腰切断比如一个介绍书店历史的段落被切成两半语义信息不完整向量表示也会被稀释。后来改成语义段落切分以标题层级、段落边界、列表结构为依据做切分单元效果提升明显。我们的做法是先解析文档结构按Markdown/HTML的标题层级确定块边界然后对每个大块判断长度过长再按段落边界或句子边界二次切分。切分单元的下限是完整表达一个语义点通常一百到三百字超过五百字就要考虑内部是否存在多个子主题。这套规则看起来朴素但配合后续的父子文档结构效果远超无脑固定窗口。3.2 元数据标注召回和引用的地基知识库里的每一段内容我们都会维护一套元数据字段。这些字段的价值至少体现在三个方面召回阶段的过滤路由、排序阶段的特征输入、引用阶段的来源回溯。没有元数据内容就只是一堆不可解释的文本碎片出了引用错误你连查都没法查。字段示例作用doc_idBK-2024-00321全局唯一内容IDsource浦东时报-20240415来源与最终引用出处region浦东新区地域过滤与本地化路由publish_time2024-04-15时效性排序entity_tags亲子阅读, 图书馆, 免费开放标签召回与知识图谱关联permission_levelpublic/internal权限过滤避免越权parent_id父级文档ID父子文档分发与上下文回溯这里特别提醒一点permission_level这个字段一定不能省。AI搜索最容易出安全问题的不是模型而是权限过滤没做好内部文档被检索出来拼接进答案。我们在检索阶段就会根据用户身份强制附加过滤条件而不是等生成结果出来再筛。3.3 双通道召回为什么不能只靠向量检索向量检索对语义相似非常有效但它有几个天然短板专有名词、英文缩写、精确ID、数字区间这些场景经常失败。比如用户搜索“ISBN 9787201154567”或者“读者证号怎么补办”向量检索大概率找不到精确匹配而关键词检索一行BM25就能解决。所以我们采用了向量检索和关键词检索双通道召回的结构向量通道负责语义相似倒排索引通道负责精确匹配和词法覆盖两路结果做融合取并集再进重排。融合策略并不复杂我们先用RRFReciprocal Rank Fusion对两路结果做初步合并把不同的排序体系拉到一个可比空间里然后进入重排模型精排。这个方案的好处是互补性强向量通道能拉回“语义相近但字面不同”的内容关键词通道能兜底“字面完全一致但向量飘了”的内容两路一起召回显著降低了漏召回的概率。3.4 知识库治理不是一次性工程知识库治理真正难的不是“建”而是“养”。文档有生命周期新内容要采集、入库、质检、发布旧内容要更新版本失效内容要标记下线。我们建了一条流水线每天凌晨跑任务增量采集、重复检测、失效链接检查、过期内容自动标记入库前还要过一轮质量闸门检测内容包括编码兼容、必填元数据完整性、敏感信息过滤。有一个数据让我印象很深上线治理流水线之后引用准确率提升了一半以上原因很简单知识库里那些过期的、重复的、残缺的内容被清理掉了大模型引用的地基干净了答案质量自然就上去了。很多团队花大价钱调模型、调prompt却不愿意在知识库治理上投入这是典型的舍本逐末。AI搜索的竞争力短期看模型能力长期看知识库的深度与新鲜度。4. 内容分发的协同逻辑改写结果如何决定检索策略4.1 改写器输出的三件套查询改写模块稳定运行后我们把它的输出定义为三件套主改写查询、同步扩展词、多路子查询。主改写查询用于主路径召回同步扩展词用于关键词通道的加权多路子查询用于多路召回每路设置不同的检索参数。这个结构让下游不再只是拿着一个字符串去检索而是拿到了一组“检索策略指令”。举个例子原始查询“周末带小孩去浦东哪里看书比较安静”主改写是“浦东 亲子阅读空间 安静 推荐”子查询分别覆盖“少儿图书馆”“亲子书房”“儿童阅览区”每路子查询独立走双通道召回最终汇合。这种多路并行策略对复杂查询尤其有效一个宽泛的长查询往往包含多个约束维度单路召回很难同时照顾到拆成子查询后每一路聚焦一个维度效率高得多。4.2 父子文档分发粗召回用小块、展示用父级内容分发的第二个关键设计是父子文档结构。我们发现如果直接把切片后的chunk作为引用单位交给大模型经常出现“信息残缺”的问题模型拿到的是被切断的半篇文章生成的答案要么不完整要么引用时无法给出有意义的标题。解决办法是建立父子两级结构子块负责参与检索号和段落号并和知识库里的元数据保持一致。在生成阶段我们要求模型以指定的引用标记格式输出比如“根据[doc_id]资料显示”而不是自由发挥写链接。这样系统就能在答案生成后把引用标记和知识库原文逐一对应完成自动核验。我们的引用指纹包含以下信息doc_id、parent_id、source、publish_time、段落号、段落哈希。段落哈希尤其重要它能在引用核验时快速判断模型引用的文本是否真的存在于原文而不只是文档ID对得上。5.3 自动核验答案句子与引用片段的一致性检查有了引用指纹还不够因为模型可能引用了正确的文档但答案里说的内容和引用片段根本不匹配。这是“引用漂移”最常见的形态。比如文档里写的是“书房提供周末预约服务”模型生成的答案是“书房全年无休随到随读”引用文档完全真实存在但内容经不起对照。要堵住这个问题必须有自动核验环节。我们实现的核验流程是把答案按句子切分每个句子对应它声称的引用片段然后用一个轻量级的文本蕴含模型判断“引用片段是否支持答案句子”。判断结果分三档支持、矛盾、无关。矛盾和无关联的句子会被标记出来进入人工复核队列同时触发告警。整个核验流程在答案生成后异步执行不阻塞用户返回只影响后续的展示和反馈。这个设计里有个经验值得分享不要试图用同一个模型既生成答案又判断引用一致性模型给自己打分存在严重的“自我偏好”自己写的答案怎么看都顺眼。用两个不同模型一个做生成、一个做核验效果会好很多这也是“跨模型”这个名称的由来。5.4 一个典型的引用漂移案例我从线上数据里找了一个典型案例。用户问“长宁区有哪些适合晚上自习的公共空间”系统检索到一篇关于社区书房的文章文中明确写了“晚间开放至21:00”。但生成模型输出的答案是“该空间支持24小时自习”引用标记指向了这篇真实存在的文章。从文档ID看引用没有错从内容看答案完全是编造的。这个案例在人工复核之前被自动核验模型成功拦下。这个案例说明了一个容易被忽略的事实AI搜索的引用错误很多时候不是“引用了一个不存在的文档”而是“引用了真实文档但内容对不上”。前者相对容易被规则发现后者必须靠语义一致性核验。所以我把跨模型引用监测的重点放在陈述与引用之间的逻辑关系上而不是仅仅检查链接是否有效。5.5 引用监测的粒度与性能平衡引用核验不能做得太细也不能太粗。太细意味着每个句子都要跑一次模型推理成本急剧上升太粗又会漏掉关键错误。我们目前的粒度是答案主干句子全量核验每个句子绑定一个主引用背景补充类句子做抽样核验抽检比例控制在两成左右。核验任务走异步队列错峰处理避免和在线检索抢占算力。上线这项监测后答案级错误率下降了约六成这个收益不是来自更好的生成模型而是来自“让错误可见”。6. 周期复测把优化动作固化成数据闭环6.1 评测集从哪里来黄金评测集与动态增量闭环能不能转起来前提是有可靠的度量工具也就是评测集。我们维护了两套评测集一套是黄金评测集约三百条人工标注的高质量查询覆盖各类典型场景和边界情况用于版本级回归测试另一套是动态增量集每周从线上日志中采样真实用户查询结合人工标注答案用于补充覆盖面。黄金评测集保证纵向可比动态增量集防止过拟合历史数据。建设评测集时有个容易犯的错直接用历史日志里的query作为评测输入却忽略了日志里的query往往是不完整的、充满噪声的。更合理的方式是人工清洗和重写把用户意图补充清楚再作为评测标准。这个过程确实耗时但评测集质量决定了优化方向的正确性这笔投入不能省。6.2 复测节奏周级快测与版本级全量我们把复测分成两个节奏。每周跑一次快测选取黄金评测集中的核心子集加上最近一周的线上采样查询验证查询改写、检索、重排这几个关键环节有没有出现质量回退。每次重大版本更新前跑全量测试包含全部黄金评测集和动态增量集同时检查端到端引用准确率、无引用率、拒答率等指标。全量通过后才能进入灰度发布流程。这套节奏看起来简单但执行起来需要很强的纪律性。我见过很多团队在项目初期热情高涨地建评测集到了后期就流于形式只在发布前临时跑一跑结果线上出了质量回退都无法定位是哪个环节引入的。周期复测的意义不在于“测了”而在于“长期可追踪”每一次优化动作都要以指标变化作为反馈。6.3 核心指标看哪几个复测不能只看一个端到端指标那样无法定位问题环节。我们日常监控的一组核心指标如下指标计算方式预警线Recall20正确答案在top 20候选中的覆盖率低于85%触发告警MRR第一个正确答案的排序倒数均值低于0.55触发告警引用准确率支持答案陈述的引用÷总引用数低于80%触发告警无引用率答案句子中未关联引用的比例高于10%触发告警用户反馈率点踩/纠正÷总回答数高于3%触发告警这些指标分别对应闭环里的不同环节Recall20对应查询改写和召回MRR对应重排质量引用准确率和无引用率对应生成与引用监测用户反馈率对应端到端体验。任何一个指标异常都能快速收敛到所属环节去排查。6.4 反馈回流让数据真正转起来周期复测最终要形成回流。用户点踩、无引用答案、核验模型标记的“矛盾”句子都会被自动收集到问题库。每周我们做一次问题归类如果大量问题集中在查询改写环节就补充规则词表和改写样例如果集中在知识库覆盖不足就推动内容团队补充资料如果集中在引用漂移就优化生成侧的引约条件和核验阈值。每一次优化动作上线前都要先跑对应环节的快测确认没有引入新的回退。回流机制是整个闭环的发动机它让优化不再依赖个人感觉而是建立在数据反馈之上。项目做到后期最大的体会就是AI搜索优化的上限其实取决于团队把“失败样例”转化成“改进动作”的速度。7. 落地后的几点务实总结跑完这一整套闭环我最大的感受是不要被“大模型”三个字迷惑。AI搜索的工程难度大头在数据处理和海量细节的把控模型选型反而是相对标准化的事情。我们踩过最大的坑就是把资源过多投入到调Prompt和换模型上忽视了知识库治理和引用可回溯性结果模型换了一圈端到端效果始终原地踏步。对资源有限的团队我的建议是分三步走第一先把知识库治理和引用监测搭起来让错误可见、可追踪这是性价比最高的第一步第二再优化查询改写和内容分发把召回漏斗的每个环节用数据度量起来第三最后才考虑换更强的基础模型那时你会发现换模型带来的提升是最直接的因为前两层的坑已经填平了。周期复测和反馈回流机制一定要从第一天就建起来哪怕评测集只有几十条数据也比没有强。它会逼迫你不断回答一个问题这个改动到底有没有用AI搜索优化的本质是一场持久战闭环越完善迭代的效率就越高。希望这套技术选型的思路能帮你的项目少走几步弯路把每一分算力都花在真正影响用户体验的地方。
AI搜索优化五段闭环：从查询改写到引用监测的完整实践
上个月我们做了一轮内部演示一个很简单的查询就把整套系统打回了原形。用户问的是“周末带小孩去浦东哪里看书比较安静”知识库里明明有十几篇关于亲子阅读空间、少儿图书馆、社区书房的优质内容线上的AI搜索却一条都没用上。原因不复杂文档里写的是“亲子阅读”“儿童阅览区”查询里全是“带小孩”“看书”“安静”这些口语化表达典型的召回失败。这个场景逼着我把AI搜索优化重新想了一遍——只调某个单点环节根本不解决问题必须把查询改写、知识库治理、内容分发、跨模型引用监测、周期复测串成一条完整的闭环链路搜索质量才有机会真正迈过生产门槛。这篇文章就围绕我们在这套闭环里的技术选型与落地过程展开适合正在搭AI搜索团队、想把RAG项目从Demo推向生产的工程师和技术负责人阅读少走我踩过的那些弯路。1. 从一次失败的搜索演示说起单一优化手段撑不起AI搜索1.1 那台演示机器暴露的第一层问题那台演示机器当时跑的是很标准的RAG链路用户输入query向量检索top 20重排后取top 5丢给大模型生成答案。单看每个组件都是市面主流方案但端到端的效果就是不行。青少儿图书这个例子的问题不在检索而在“入口”——用户没有用文档里的词来表达需求向量检索在语义空间里也没能弥补这种表达差异。后来我们统计了一周的真实日志接近三成的失败查询都属于这种“原文不会这么说”的情况。这说明AI搜索和传统搜索最大的区别并不是多了个生成模型而是用户对它的期待变了他们会用更自然、更模糊、更口语化的方式提问默认系统能听懂。传统搜索靠关键词命中用户会自己换词重试AI搜索场景里用户更倾向于只输入一次长句等着系统理解。1.2 我为什么把查询改写放在第一优先级那次演示之后我们做过一轮复盘结论是召回漏斗的每一层都会过滤掉信息但最上游的查询理解一旦出错后面所有环节都没有补救机会。你可以在重排阶段用再强的交叉编码器也无法让一个从未被召回的正确文档重新出现在候选集里。所以整个改造项目的第一优先级不是换更大的模型不是调向量库参数而是先把“用户想找什么”这件事搞清楚。查询改写在这个阶段的定位是把口语化的、指代不清的、上下文依赖的原始输入改写成知识库更可能命中、检索系统更容易匹配的若干查询形态。它不像生成答案那样追求“妙笔生花”它追求的是“稳、准、多路覆盖”。1.3 闭环图景五个环节如何咬合沿着这条思路我们把整个优化目标定义成一条五段式链条任何一段单独拎出来优化都会在其他环节暴露出木桶短板。链条如下查询改写把用户原始表达改写为适合检索的查询集合包括同义词扩展、结构化查询、多路子查询。知识库治理保证内容本身是干净、结构化、可召回、可引用的包括切分、标注、去重、更新、下架。内容分发决定改写结果如何驱动检索策略包括多路召回、父子文档分发、重排、上下文截断和降级处理。跨模型引用监测在生成侧约束引用来源并自动核验答案陈述是否真的被引用片段支持。周期复测用评测集和真实反馈持续度量各环节质量让优化动作能够被量化、可回归、可回流。这个闭环不是一次瀑布式交付而是一个持续运转的飞轮。下面我按这个顺序把每个环节的技术选型、具体实现和踩坑记录拆开讲。2. 查询改写引擎的选型与调优别让召回在第一步就输掉2.1 双层改写架构规则层兜底、模型层理解查询改写这个模块我们最终采用了“双层架构”而不是一上来就全量依赖大模型。第一层是规则与词表层用词典、同义词表、正则、地名实体库做确定性改写第二层才是LLM改写处理规则层覆盖不了的模糊意图与复杂口语。这个排序是有意的规则层速度快、零成本、完全可控适合处理高频、确定性强的改写LLM层灵活、能理解上下文但存在延迟和改写漂移问题。我们见过不少团队把所有改写交给LLM结果单次改写耗时超过1秒线上毛延迟飙升同时出现“把用户的限定条件改没了”这类灾难问题。规则层先做一轮把能确定的先确定下来LLM只处理残差成本和质量都可控。规则层我们维护了一张针对上海本地场景的开放词表覆盖地铁站名、行政区划、商圈别称、机构俗称等。比如“徐家汇”“徐汇” “XJH”的归一化“浦东图书馆”和“浦图”的别名映射这些在传统搜索引擎里早就是成熟做法但很多AI搜索项目因为觉得“有大模型了不需要词典”就丢掉了非常可惜。词表的好处是行为可预期上线前可以逐条验收不会出现大模型那种“这次改了、下次没改”的随机性。2.2 LLM改写层的Prompt设计与输出约束LLM层我们只处理规则层无法处理的场景典型的有三类指代消解“它比那家更安静”中的“它”指什么、口语省略“附近哪有24小时能待的书店”——“附近”在对话上下文里指什么、复杂意图拆解“适合带三岁小孩去又能办活动的书店”隐含多个约束。LLM改写的Prompt约束我建议只做三件事一是忠实保留原查询的所有限定词禁止自行删减二是输出固定JSON结构便于下游解析三是要求改写结果必须有明确检索增益如果原查询已经足够清晰就原样返回不要画蛇添足。{ original_query: 周末带小孩去浦东哪里看书比较安静, rewritten_query: 浦东 亲子阅读空间 安静 推荐, sub_queries: [ 浦东 少儿图书馆, 浦东 亲子书房 安静, 浦东 儿童阅览区 周末开放 ], intent_tags: [location:浦东, scenario:亲子, constraint:安静], need_search: true }这里有一个很微妙的点改写不是越“文学”越好而是越“贴近文档语言”越好。所以我们在评测改写质量时不看它写出来的句子是否通顺漂亮而是看它召回的结果是否更准确。一个看起来笨拙的改写只要能让正确答案进入候选集就是好的改写。2.3 改写质量评估口径与几个典型的坑如果只用一个指标衡量改写质量我会选“改写后检索的Recall20”。具体做法是准备一批查询标注出每个查询对应的正确答案文档ID然后分别用原始query和改写后的query走同一套检索对比正确答案被召回的比率。这个指标比BLEU、ROUGE那些文本相似度指标有意义得多因为改写的最终目标不是文本像不像而是召回准不准。踩坑方面有三条经验值得单独写。第一LLM改写容易丢失数字和否定词比如“不要周末去”被改写成“周末去”这种错误在文本相似度指标里几乎看不出来但召回结果完全相反所以Prompt里必须强制要求“逐一核对限定词是否保留”。第二地名实体不能依赖LLM上海本地有大量历史地名、道路简称、商圈约定俗成的叫法LLM未必知道而规则词表一劳永逸这个就是为什么我说规则层不能丢。第三改写要控制在线耗时我们给LLM改写设定的性能预算是单次100ms以内超时直接降级到规则层结果宁可少一条扩展查询也不能让用户等待响应。实测在并发高峰期这个降级策略避免了大量超时故障。3. 知识库治理AI搜索项目真正的护城河3.1 语义单元切分固定窗口不是万能的很多团队把知识库治理想得太简单文档导入、切个chunk、存进向量库就以为万事大吉。实际做下来切分这件事就足够折腾人。早期我们也用固定窗口切分512字一个chunk、64字重叠跑起来很快但检索质量很不稳定。问题在于固定窗口会把一个完整段落拦腰切断比如一个介绍书店历史的段落被切成两半语义信息不完整向量表示也会被稀释。后来改成语义段落切分以标题层级、段落边界、列表结构为依据做切分单元效果提升明显。我们的做法是先解析文档结构按Markdown/HTML的标题层级确定块边界然后对每个大块判断长度过长再按段落边界或句子边界二次切分。切分单元的下限是完整表达一个语义点通常一百到三百字超过五百字就要考虑内部是否存在多个子主题。这套规则看起来朴素但配合后续的父子文档结构效果远超无脑固定窗口。3.2 元数据标注召回和引用的地基知识库里的每一段内容我们都会维护一套元数据字段。这些字段的价值至少体现在三个方面召回阶段的过滤路由、排序阶段的特征输入、引用阶段的来源回溯。没有元数据内容就只是一堆不可解释的文本碎片出了引用错误你连查都没法查。字段示例作用doc_idBK-2024-00321全局唯一内容IDsource浦东时报-20240415来源与最终引用出处region浦东新区地域过滤与本地化路由publish_time2024-04-15时效性排序entity_tags亲子阅读, 图书馆, 免费开放标签召回与知识图谱关联permission_levelpublic/internal权限过滤避免越权parent_id父级文档ID父子文档分发与上下文回溯这里特别提醒一点permission_level这个字段一定不能省。AI搜索最容易出安全问题的不是模型而是权限过滤没做好内部文档被检索出来拼接进答案。我们在检索阶段就会根据用户身份强制附加过滤条件而不是等生成结果出来再筛。3.3 双通道召回为什么不能只靠向量检索向量检索对语义相似非常有效但它有几个天然短板专有名词、英文缩写、精确ID、数字区间这些场景经常失败。比如用户搜索“ISBN 9787201154567”或者“读者证号怎么补办”向量检索大概率找不到精确匹配而关键词检索一行BM25就能解决。所以我们采用了向量检索和关键词检索双通道召回的结构向量通道负责语义相似倒排索引通道负责精确匹配和词法覆盖两路结果做融合取并集再进重排。融合策略并不复杂我们先用RRFReciprocal Rank Fusion对两路结果做初步合并把不同的排序体系拉到一个可比空间里然后进入重排模型精排。这个方案的好处是互补性强向量通道能拉回“语义相近但字面不同”的内容关键词通道能兜底“字面完全一致但向量飘了”的内容两路一起召回显著降低了漏召回的概率。3.4 知识库治理不是一次性工程知识库治理真正难的不是“建”而是“养”。文档有生命周期新内容要采集、入库、质检、发布旧内容要更新版本失效内容要标记下线。我们建了一条流水线每天凌晨跑任务增量采集、重复检测、失效链接检查、过期内容自动标记入库前还要过一轮质量闸门检测内容包括编码兼容、必填元数据完整性、敏感信息过滤。有一个数据让我印象很深上线治理流水线之后引用准确率提升了一半以上原因很简单知识库里那些过期的、重复的、残缺的内容被清理掉了大模型引用的地基干净了答案质量自然就上去了。很多团队花大价钱调模型、调prompt却不愿意在知识库治理上投入这是典型的舍本逐末。AI搜索的竞争力短期看模型能力长期看知识库的深度与新鲜度。4. 内容分发的协同逻辑改写结果如何决定检索策略4.1 改写器输出的三件套查询改写模块稳定运行后我们把它的输出定义为三件套主改写查询、同步扩展词、多路子查询。主改写查询用于主路径召回同步扩展词用于关键词通道的加权多路子查询用于多路召回每路设置不同的检索参数。这个结构让下游不再只是拿着一个字符串去检索而是拿到了一组“检索策略指令”。举个例子原始查询“周末带小孩去浦东哪里看书比较安静”主改写是“浦东 亲子阅读空间 安静 推荐”子查询分别覆盖“少儿图书馆”“亲子书房”“儿童阅览区”每路子查询独立走双通道召回最终汇合。这种多路并行策略对复杂查询尤其有效一个宽泛的长查询往往包含多个约束维度单路召回很难同时照顾到拆成子查询后每一路聚焦一个维度效率高得多。4.2 父子文档分发粗召回用小块、展示用父级内容分发的第二个关键设计是父子文档结构。我们发现如果直接把切片后的chunk作为引用单位交给大模型经常出现“信息残缺”的问题模型拿到的是被切断的半篇文章生成的答案要么不完整要么引用时无法给出有意义的标题。解决办法是建立父子两级结构子块负责参与检索号和段落号并和知识库里的元数据保持一致。在生成阶段我们要求模型以指定的引用标记格式输出比如“根据[doc_id]资料显示”而不是自由发挥写链接。这样系统就能在答案生成后把引用标记和知识库原文逐一对应完成自动核验。我们的引用指纹包含以下信息doc_id、parent_id、source、publish_time、段落号、段落哈希。段落哈希尤其重要它能在引用核验时快速判断模型引用的文本是否真的存在于原文而不只是文档ID对得上。5.3 自动核验答案句子与引用片段的一致性检查有了引用指纹还不够因为模型可能引用了正确的文档但答案里说的内容和引用片段根本不匹配。这是“引用漂移”最常见的形态。比如文档里写的是“书房提供周末预约服务”模型生成的答案是“书房全年无休随到随读”引用文档完全真实存在但内容经不起对照。要堵住这个问题必须有自动核验环节。我们实现的核验流程是把答案按句子切分每个句子对应它声称的引用片段然后用一个轻量级的文本蕴含模型判断“引用片段是否支持答案句子”。判断结果分三档支持、矛盾、无关。矛盾和无关联的句子会被标记出来进入人工复核队列同时触发告警。整个核验流程在答案生成后异步执行不阻塞用户返回只影响后续的展示和反馈。这个设计里有个经验值得分享不要试图用同一个模型既生成答案又判断引用一致性模型给自己打分存在严重的“自我偏好”自己写的答案怎么看都顺眼。用两个不同模型一个做生成、一个做核验效果会好很多这也是“跨模型”这个名称的由来。5.4 一个典型的引用漂移案例我从线上数据里找了一个典型案例。用户问“长宁区有哪些适合晚上自习的公共空间”系统检索到一篇关于社区书房的文章文中明确写了“晚间开放至21:00”。但生成模型输出的答案是“该空间支持24小时自习”引用标记指向了这篇真实存在的文章。从文档ID看引用没有错从内容看答案完全是编造的。这个案例在人工复核之前被自动核验模型成功拦下。这个案例说明了一个容易被忽略的事实AI搜索的引用错误很多时候不是“引用了一个不存在的文档”而是“引用了真实文档但内容对不上”。前者相对容易被规则发现后者必须靠语义一致性核验。所以我把跨模型引用监测的重点放在陈述与引用之间的逻辑关系上而不是仅仅检查链接是否有效。5.5 引用监测的粒度与性能平衡引用核验不能做得太细也不能太粗。太细意味着每个句子都要跑一次模型推理成本急剧上升太粗又会漏掉关键错误。我们目前的粒度是答案主干句子全量核验每个句子绑定一个主引用背景补充类句子做抽样核验抽检比例控制在两成左右。核验任务走异步队列错峰处理避免和在线检索抢占算力。上线这项监测后答案级错误率下降了约六成这个收益不是来自更好的生成模型而是来自“让错误可见”。6. 周期复测把优化动作固化成数据闭环6.1 评测集从哪里来黄金评测集与动态增量闭环能不能转起来前提是有可靠的度量工具也就是评测集。我们维护了两套评测集一套是黄金评测集约三百条人工标注的高质量查询覆盖各类典型场景和边界情况用于版本级回归测试另一套是动态增量集每周从线上日志中采样真实用户查询结合人工标注答案用于补充覆盖面。黄金评测集保证纵向可比动态增量集防止过拟合历史数据。建设评测集时有个容易犯的错直接用历史日志里的query作为评测输入却忽略了日志里的query往往是不完整的、充满噪声的。更合理的方式是人工清洗和重写把用户意图补充清楚再作为评测标准。这个过程确实耗时但评测集质量决定了优化方向的正确性这笔投入不能省。6.2 复测节奏周级快测与版本级全量我们把复测分成两个节奏。每周跑一次快测选取黄金评测集中的核心子集加上最近一周的线上采样查询验证查询改写、检索、重排这几个关键环节有没有出现质量回退。每次重大版本更新前跑全量测试包含全部黄金评测集和动态增量集同时检查端到端引用准确率、无引用率、拒答率等指标。全量通过后才能进入灰度发布流程。这套节奏看起来简单但执行起来需要很强的纪律性。我见过很多团队在项目初期热情高涨地建评测集到了后期就流于形式只在发布前临时跑一跑结果线上出了质量回退都无法定位是哪个环节引入的。周期复测的意义不在于“测了”而在于“长期可追踪”每一次优化动作都要以指标变化作为反馈。6.3 核心指标看哪几个复测不能只看一个端到端指标那样无法定位问题环节。我们日常监控的一组核心指标如下指标计算方式预警线Recall20正确答案在top 20候选中的覆盖率低于85%触发告警MRR第一个正确答案的排序倒数均值低于0.55触发告警引用准确率支持答案陈述的引用÷总引用数低于80%触发告警无引用率答案句子中未关联引用的比例高于10%触发告警用户反馈率点踩/纠正÷总回答数高于3%触发告警这些指标分别对应闭环里的不同环节Recall20对应查询改写和召回MRR对应重排质量引用准确率和无引用率对应生成与引用监测用户反馈率对应端到端体验。任何一个指标异常都能快速收敛到所属环节去排查。6.4 反馈回流让数据真正转起来周期复测最终要形成回流。用户点踩、无引用答案、核验模型标记的“矛盾”句子都会被自动收集到问题库。每周我们做一次问题归类如果大量问题集中在查询改写环节就补充规则词表和改写样例如果集中在知识库覆盖不足就推动内容团队补充资料如果集中在引用漂移就优化生成侧的引约条件和核验阈值。每一次优化动作上线前都要先跑对应环节的快测确认没有引入新的回退。回流机制是整个闭环的发动机它让优化不再依赖个人感觉而是建立在数据反馈之上。项目做到后期最大的体会就是AI搜索优化的上限其实取决于团队把“失败样例”转化成“改进动作”的速度。7. 落地后的几点务实总结跑完这一整套闭环我最大的感受是不要被“大模型”三个字迷惑。AI搜索的工程难度大头在数据处理和海量细节的把控模型选型反而是相对标准化的事情。我们踩过最大的坑就是把资源过多投入到调Prompt和换模型上忽视了知识库治理和引用可回溯性结果模型换了一圈端到端效果始终原地踏步。对资源有限的团队我的建议是分三步走第一先把知识库治理和引用监测搭起来让错误可见、可追踪这是性价比最高的第一步第二再优化查询改写和内容分发把召回漏斗的每个环节用数据度量起来第三最后才考虑换更强的基础模型那时你会发现换模型带来的提升是最直接的因为前两层的坑已经填平了。周期复测和反馈回流机制一定要从第一天就建起来哪怕评测集只有几十条数据也比没有强。它会逼迫你不断回答一个问题这个改动到底有没有用AI搜索优化的本质是一场持久战闭环越完善迭代的效率就越高。希望这套技术选型的思路能帮你的项目少走几步弯路把每一分算力都花在真正影响用户体验的地方。
)
