刚接手这个项目的时候，我其实有点低估了它。内部知识库一直在用一套“搜索式问答”，效果嘛，能用，但离好用差得远。原话是“搜出来的东西看着相关，但没解决我的问题”。做了几个月的RAG落地之后，我才真正想明白一件事：从“搜索式问答”到“理解式助教”，并不是把模型换大一点、把向量库加多几行就能解决的，而是一次从检索逻辑、交互方式到评估体系的整体重构。
这篇文章就把整个项目的拆解思路、技术选型、核心代码片段、踩坑记录都放出来。适合已经在做知识库问答、或者正准备从“能搜到”向“能答对”进化的团队参考，尤其适合那种文档存量不小、用户问题千奇百怪、但检索命中率一直提不上去的场景。
1. 为什么“搜索式问答”不够用
1.1 搜索式问答的本质：把用户当成了“搜索引擎操作员”
传统搜索式问答的思路非常直接：用户输入几个关键词，系统在知识库里做全文检索或者向量检索，把最像的几个文档片段拼在一起展示出来。这看起来没什么问题，但实际操作过的人都知道，这里头有两个很隐性的前提，而且这两个前提在真实业务里几乎都不成立。
第一个前提是“用户知道怎么搜”。他得能把心里的问题翻译成恰当的关键词，还能在结果里自己判断哪段是对的、哪段是错的、哪段和哪段拼在一起才能形成完整答案。举个例子，业务同学问“我们上个月华南区的退款率为什么突然上升”，他得知道自己在找“华南区”“退款率”“月度统计”这些词，还得自己去翻返修记录、客服工单、财务报表三个不同来源的内容，自己去拼凑因果关系。这个行为要求用户对知识库的内容结构相当熟悉，否则他会一直搜不到。
第二个前提是“答案等于文档片段”。但真实业务里，答案往往不是忠实复述某一个文档，而是“把多个来源的内容加工之后的结论”。比如“新人入职第一周该做什么”这种问题，可能散落在人事制度、部门手册、导师带教计划三个文档里，搜索式问答只会把三个片段分别抛给用户，不会做合并、去重、排序，更不会告诉你“第一天的重点是领设备，而不是看文档”。
所以这个阶段的本质，是把信息检索的责任压在了用户身上。系统只做匹配，不做理解。用户表面上在用“问答”，实际上在干搜索引擎操作员的活儿。
1.2 检索命中率提不上去的深层原因
我一开始以为检索命中率的问题是Embedding模型选得不够好，后来发现这只是表层原因。真正的问题可以拆成三个层次。
第一个层次是“词不达意”。用户的问题表述和文档的说法差异太大。比如文档里写的是“产假申领流程”，用户问的是“休产假找谁审批”，两边字面上几乎没有重叠。传统的BM25靠词形匹配，直接废掉；向量检索虽然能意图匹配，但如果Embedding模型没有经过领域数据微调，这种业务近义词关系也未必能捕捉到。
第二个层次是“答案藏在上下文中”。知识库里大量内容是相互引用的，比如“具体操作详见X文档”“按Y规则执行”，这类内容单拎出来毫无价值。搜索式问答只给了用户一个片段，用户还得再点一次链接、再读一遍原文才能完成理解链条。这意味着检索命中了文档，但没有命中答案。
第三个层次是“问题被拆碎了”。用户经常一句话问两三个事，比如“为什么退款率高，和上个月活动有关系吗，要不要调整策略”这个问题里其实包含了归因分析、相关性判断、行动建议三个诉求。搜索式问答只能把它当成一个整体去匹配，结果什么都抓不到。
这三个层次叠加起来，结果就是：表面上检索到了一些内容，但用户觉得“答非所问”。这不是模型的问题，而是系统设计假设的问题。
1.3 我们真正需要的“理解式助教”
理解式助教的判断标准，不是“能不能搜到”，而是“能不能答对”。这中间多了几件事：
- 理解用户的问题意图，识别出他是在问事实、问流程、问原因、还是问建议；
- 把碎片化的文档内容结构化，找到真正的答案节点，而不是文档片段；
- 能处理“问题里包含多个子问题”的情况；
- 能在回答里显式区分“这个结论来自哪里、哪个条件还未知、哪个建议是基于默认假设的”；
- 更重要的是，当用户追问“为什么”“然后呢”的时候，系统能接着上一轮的语义继续回答，而不是重新搜索一遍。
这个定位对系统框架的要求完全不同。搜索式问答是一条直线：输入、检索、拼接、输出。理解式助教至少是一个带状态的决策流程：先理解、再规划检索策略、多次检索、汇总评估、生成答案、保留上下文。
想明白这一层，后面所有技术选型就都顺了。
2. 整体架构设计：从直线流程到决策流程
2.1 模块划分与数据流向
我们最终落地的架构分成了四个核心模块：意图理解层、混合检索层、答案生成层、会话管理层。
意图理解层实际做得比名字更复杂。它不只是给问题打个标签（“这是流程类问题”），而是要提取出一条“检索计划”。比如用户问“上个月退款率为什么上升”，这个层要输出三个东西：检索目标是怎么样的（要找归因相关的数据和分析）、查询需要哪些实体（上个月、退款、华南区）、甚至要不要触发专门的统计分析接口。这个设计借鉴了Agent的规划思想，但被严格控制在一个小范围内，避免跑偏。
混合检索层是我们投入精力最多的地方。我们同时跑了BM25全文检索和向量检索，再用一个轻量级的重排模型把两边的结果合在一起。为什么要混合而不是只用向量？因为向量检索对语义相似度高的情况很舒服，但对精确术语、编号、格式这类硬条件匹配很差。比如“编号X-203的采购合同”这种查询，分词拆出来的“X-203”在向量空间里几乎没有意义，但BM25能精准命中。在真实业务里，编码、型号、人名、日期这类实体查询的比例其实非常高，所以纯向量方案一定会漏。
答案生成层不再直接采用“检索片段拼接”，而是先做一轮候选片段的重组与筛选。我们会把检索到的TopK片段按引用关系做一次合并，去掉冲突的内容，再交给大模型生成。在生成时，Prompt里会明确告诉模型“只基于提供的材料回答，材料不足以判断时直接说不确定，不要脑补”。这一步是为了控制幻觉。
会话管理层则维护了多层状态：当前对话的语义摘要、最近的几个问答对、用户已经确认过的事实标记。这个模块处理的是追问和上下文指代，比如“那和上个月的营销活动有关系吗”里的“那”，如果不结合上一轮的问题，新query就是一句无法理解的半截话。
整个流程跑完一遍大概是这样的：用户提问，意图理解层输出检索计划，混合检索层并行召回，重排合并，回答生成层综合判断并输出答案，会话管理层更新本轮状态。这个流程每轮都跑，但不同轮次走的路径可能不同，比如连续追问时，意图理解层会把“检索计划”简化为“在上轮结果里再筛选”，从而大幅降低延迟。
2.2 关键决策：为什么做成“可控的Agent”而不是直接让模型自由发挥
我们最开始也试过直接给大模型挂一堆工具函数，让它自己决定调哪个、怎么调，这是看起来最“智能”的方案。试用了一周，放弃了。
原因是表现极不稳定。模型有时会为了完成回答，调用一个过度宽泛的检索接口，结果返回几百个文档，然后它自己都处理不过来；有时会在不知道某工具返回值格式的情况下，强行猜一个结果；最麻烦的是不可复现，同一个问题上午答得好好的，下午同样的输入它会换一条完全不同的执行路径，而且这个路径可能是错的。
所以我们在落地时做了一个重要妥协：把模型自由调用的Agent改成了“策略约束下的半自动流程”。意图理解层只输出一个结构化的JSON，JSON里的字段是预定义好的有限集合；检索层的执行顺序和并发策略由代码控制，模型不参与调度，只负责产出“检索计划”和“最终答案”。这样既保留了Agent的灵活性（不同问题产出不同检索计划），又避免了模型乱调度导致的不确定性。
很多人纠结于“要不要上Agent”，我觉得用户真正在乎的不是Agent本身，而是“系统能不能自己判断该怎么查”。你要做的是把这个“判断”控制在预设轨道里，而不是交给模型自由发挥。稳妥的做法是：先做确定性流程，再逐步把一部分决策开放给模型，每一步都要有评估兜底。
3. 核心环节实现：从“搜得到”到“答得对”
3.1 知识库构建：把文档变成可检索的“知识点”，不是切成碎片就行
知识库构建这一步，网上教程很多，但大多数只讲了“加载、分割、向量化”三步，实际落地完全不是这么简单。文本分割方式直接决定了检索质量，而这一步的调优是最脏最累的。
我们一开始按固定的512字长度切分，效果很差。原因在于文档里的“知识点”根本不是按字数分布的。一个知识点可能是一段200字的完整操作说明，也可能是一句20字的政策开关，还可能是一个表格里的一行。死板地按字数切，把很多完整语义活生生地截断了。
后来我们换了一种方式：按结构化边界切分。优先按Markdown标题、段落、表格行、列表项切，最小单元限制在60字以上，最大单元700字。同时保留每个知识点的来源路径、标题链、模块归属，这些元数据在后续重排和溯源展示时非常有用。这种切分方式，中长文本的检索命中率比固定窗口切分高了约17%，而且这是在我们内部评测集上稳定跑出来的结论，不是拍脑袋。
除了切分，我们还为每个切片生成了一组“扩展标签”。比如一个关于“请假流程”的片段，我们会额外打上“休假”“考勤”“审批”“请假类型”等标签。这一步通过大模型自动生成，再人工抽样校验。有了扩展标签之后，像“我想请两天假怎么弄”这种口语化查询，即使向量匹配得分不高，也能靠标签召回补回来。
3.2 混合检索与重排：BM25+向量+规则触发
混合检索的公式很简单：分别跑BM25和向量检索，各取Top50，然后用重排模型算出最终的TopK。但真正有价值的是细节。
我们在两路召回之外，还加了一条“规则触发”通道，专门处理高度结构化的查询：纯数字编号、合同号、人员工号、日期范围。这类查询词的语义空间几乎没有信号，靠向量或者关键词都可能翻车，但用正则或者查表就能稳定命中。比如“帮我查下合同编号X-203的付款节点”，规则通道直接定位到该合同的支持文档，再拿上下文补充回答，效果非常稳。
重排模型我们选用了一个轻量的交叉编码器。它把查询和候选片段拼接后一次性输入模型打分，比向量检索的双塔结构精度高不少。但交叉编码器计算量大，不能直接用在第一轮召回，只能做TopK重排。我们用两阶段结构：粗召回的时候保持高召回率（宁可多召回不准确的，也不能漏掉正确的），精排阶段再靠交叉编码器把真正相关的排到前面。
这套两阶段结构跑下来，Top5命中率从原来的62%涨到81%，提升还是比较明显的。这里要特别注意的是，重排模型的训练数据要尽量贴近真实用户query，泛化测试集和真实分布差太多的话，你的评估结果会虚高，上线后立刻露馅。
3.3 意图理解与检索计划：把用户的一句话拆成可执行的查证方案
意图理解层是整个项目里最容易被低估的部分。很多人觉得意图分类嘛，不就是SPU、筛几个类别，但真正做起来，它承担的是“把用户的一句口语变成一套可以并行或串行执行的查证方案”。
举一个真实案例。用户的问题是：“我们部门上个月离职率很高，能看看是什么原因吗？是不是和绩效考核调整有关系？”
这句话可以被拆成三层诉求：查数据（上个月离职率、部门分布）、查归因（公司内部是否有过分析讨论）、查政策（绩效考核调整的发布时间和内容）。如果只把它当成一个整体query去检索，大概率只能匹配到“离职率是怎么计算的”这种基础文档，完全答非所问。
我们的实现方案是：第一步由大模型产出一个结构化的检索计划JSON，包含意图标签、实体、需要调用的检索通道、子查询列表；第二步由代码解析该JSON，执行对应的检索动作；第三步把多个子查询的结果汇总后交给生成层。
这个方案跑起来之后，最明显的变化是：用户问复杂问题时，系统会返回一个类似“我分别查了离职率数据、近期绩效政策、内部讨论记录，发现以下几点”的结构化回答。用户一眼就能看出系统确实理解了问题的层次，而不是单纯丢出来一段文档。
3.4 Prompt设计与答案生成：怎么让模型“答得准，又敢于说不知道”
答案生成这一步，技术含量在Prompt设计之外，更在“生成前”和“生成后”的处理。
生成前，我们要做一次候选片段冲突检测。比如用户问“请假最长能几天”，检索到的两个文档可能一个写“年假15天”，一个写“事假累计不超过10天”，这两个片段都相关但不是同一个问题的直接答案。如果直接丢给模型，它会把两边信息都塞进回答，用户看完反而更乱。我们的做法是把检索片段先按“问题类型”做一次信息提取，比如流程类问题提取步骤和条件、政策类问题提取适用人群和限制条件，提取后的结构化信息再喂给模型，生成的答案会更聚焦。
生成时，Prompt里的关键是限定：“只基于提供的【参考材料】回答，不要使用外部知识和推测；材料矛盾时，分别列出两种说法；材料不足时，明确回答‘根据现有材料无法确认’，并给出可能的查询方向。”这句话看起来简单，但对控制幻觉非常有效。我们做了消融测试，加上这个约束之后，幻觉类错误率从22%降到了8%。
生成后，还要过一个自检环节。让大模型重新读一遍自己的回答，检查是否有超出参考材料的结论。这一步会再消耗一次模型调用，但换来的是回答稳定性的显著提升。对企业场景来说，宁可答得保守一点，也绝对不能一本正经地胡说八道。
3.5 会话记忆与追问处理：助教要能接得住上一句
一个“理解式助教”和“搜索式问答”最直观的区别，就是追问能力。用户第一句问“华南区上个月退款率高不高”，系统答了“整体偏高”；他接着问“那主要是哪个品类拉的”，这个“那”和“主要”“拉的”都高度依赖上一轮的实体——华南区、上个月、退款率。
我们实现追问处理的方式是轻量级的：维护一个对话摘要，每轮结束后由模型把当前对话的关键实体和结论压缩成一段摘要文本，下一轮生成时把这个摘要和原始历史都放进Prompt。同时在意图理解层检测到“指代词”时，优先用摘要里的实体补全query，再做检索。
效果上最大的变化是，用户不再需要每轮都重复“华南区、上个月、退款率”这几个限定词，对话体验一下子就从“搜索引擎”变成了“聊天对象”。这个模块的代码量其实不大，但交互上是质变。
4. 数据评估与调优实践
4.1 建立贴近真实分布的评测集
做这个项目期间，最值回票价的一件事，就是在第一天就搭了一个相对完整的评测集，而不是等项目跑通了才开始测。
评测集的建立过程是这样的：我们从线上日志里捞了2000条真实用户query，按频率做了分层抽样（高频问题多收，长尾问题也保留），然后人工标注每个query应该命中的知识库文档和标准答案。这个过程中最耗时的是标准答案的标注，因为80%的问题其实是复合问题，需要一个由多篇文档得到的答案。
然后我们定义了三类指标：
- 召回命中率：看Top5片段里是否包含标注的标准来源；
- 端到端正确率：看最终答案是否覆盖了标准答案的所有要点，且没有明显错误；
- 幻觉率：看答案里是否有超出材料依据的陈述。
这三类指标缺一不可。只看召回命中率，可能检索对了但生成时模型瞎编；只看端到端正确率，出了问题分不清是检索的锅还是生成的锅。
4.2 分模块定位问题：检索优化和生成优化的“三七开”
项目过程中我最大的体感是：端到端回答质量差的根源，七成在检索，三成在生成。很多时候模型答得不对，不是因为它“不会答”，而是因为“该看到的内容根本没被检索出来”。
检索问题的排查方法是“透检”：把模型输入里的参考材料直接打印出来，人眼看一眼就知道到底有没有包含正确答案材料。如果材料里根本没有答案，那不管怎么调Prompt都没用，只能回头优化检索。如果材料里有但模型答错了，那才轮到生成层的问题。
生成问题的排查方法是“删减对比”：同一组材料、同一个问题，分别用完整Prompt、删掉一段推论引导的Prompt、加上自检环节的Prompt去跑，对比输出质量的差异。这个方法能很清楚地定位Prompt里的哪个片段起了坏作用。
我们在过程中专门花了两个迭代周期去修检索。一开始只靠向量检索，后来发现问题多出在精确匹配上；把BM25和规则通道加上去之后，很多case立刻跑通了。很多人上来就想要“一步到位的RAG”，说实话不存在，检索和生成必须分开打磨。
4.3 指标优化过程实录
记录几组真实数据供参考。
第一版粗原型（仅向量检索+直接大模型回答），Top5命中率约62%，端到端正确率只有39%，幻觉率高达22%。这个阶段几乎不能用，原因是用户的问题表述和文档的表述差异太大，向量检索的召回质量太差。
第二版加了BM25和规则通道，Top5命中率升到77%，端到端正确率升到53%。这一步说明混合召回确实管用，但生成层的混乱仍然拖累着端到端效果。
第三版优化了Prompt约束和答案生成前的信息提取环节，端到端正确率升到了71%，幻觉率降到8%。这个阶段已经能用于小规模内测了。
第四版加入重排模型和会话记忆之后，Top5命中率稳定在81%，端到端正确率到77%，长尾查询的表现提升尤其明显。到这一步，我们才敢放开到内部全员使用。
这几组数据意味着什么？如果用一句话总结，就是：纵向优化检索可以止血，但真正让指标上一个台阶的，是把“检索到啥就答啥”改成“理解了才答”。
5. 常见问题与排查技巧实录
5.1 为什么检索到的内容看起来相关，但答不出正确答案
这是最典型的误诊现场。表面看是“生成了错误回答”，实际是“检索到的片段属于同一主题”，但“正确的答案节点没被召回”。比如用户问“年假可以积累到下一年吗”，检索结果全是“如何申请年假”的流程文档，看起来高度相关，但里面没有一句讲到“年假是否可结转”。端到端自然答不出来。
排查方法：把检索结果打出来人肉看一遍，问自己一个问题——“如果我现在是这个用户，光看到这些片段，能回答这个问题吗？”如果不能，问题在检索；如果能，问题在生成。
修复方向一般有两个：一是增强实体的精确匹配能力，让“年假结转”这种词能命中到对应条款；二是在分割时保留文档的条款结构，不要用固定窗口切碎。
5.2 模型一本正经地编答案，怎么压都压不住
幻觉问题没有一次性能解决的办法，但有一个组合拳比较有效。
第一拳是Prompt约束，明确说“不确定就说不确定”，这一条能降低一部分幻觉。第二拳是自检环节，让模型重新读自己的回答，标记出“哪些结论在参考材料里有依据、哪些没有”，把没有依据的部分删除。第三拳是条件拦截：如果检索到的候选片段整体置信度太低，系统直接返回“抱歉，根据当前资料库无法确定”，而不是强行给一个答案。
再提一个容易被忽略的细节：很多幻觉其实不是模型“想编”，而是参考材料本身冲突。文档A说流程需要3个工作日，文档B说5个工作日，模型为了自洽，选了一个或者编了一个中间值。我们的解法是，生成前做片段冲突检测，发现冲突时在答案里明确“不同材料存在两种说法”，同时把两个来源都摆出来，让用户自己判断。这比让模型强行给结论要安全得多。
5.3 长尾问题总是踩不准，该怎么办
长尾问题的特点是：每个问题出现的频率都不高，但合起来占了用户提问总量的一半以上。这时候只优化高频问题是不够的，因为用户感觉到“不智能”，往往就是从某个小众问题答不上来开始的。
我们做了三件事，效果很大。
第一件事是给评测集加“长尾比例”约束，刻意在每次迭代里考察长尾问题的准确率，避免只盯着Top20高频问题调参导致过拟合。
第二件事是给知识库做“缺问答疑”闭环。用户提问后如果系统判定了低置信度，把这个query沉淀到一个“未覆盖问题”列表里，每两周人工review一轮，把高频缺失问题对应的文档补录到知识库中。这个闭环直接解决了“知识库里根本没有这个内容”的根因。
第三件事是扩展标签的持续迭代。新的长尾问题进来之后，我们会拿它去跑一遍检索，看命中的是哪些片段，如果命中的片段和query在语义上有关联但字面差太远，就给相关片段补打标签。这个过程是半自动的，但三个月跑下来，长尾问题的Top5命中率从61%提高到了76%。
5.4 成本、延迟与质量的三难选择，怎么取舍
最后聊一个不那么工程但也很实际的话题：这套系统贵不贵，快不快。
我们内部的服务规格是：问答接口平均响应时间在3到5秒之间（这里的瓶颈几乎全在生成层的模型调用上），单次调用成本在0.2元以内（用的都是国内可采购的商业模型服务，固定region的API）。
如果你的场景对延迟有硬要求，有几个降延迟的路子。第一是做大模型回答结果的缓存，高频问题直接命中缓存，秒回；第二是检索和生成的并行化，让意图理解模型和第一轮检索同时开始跑，因为意图理解的结果往往不影响第一轮召回；第三是把重排模型的候选范围缩小，从50压到20，重排耗时能降一半，但要注意召回率下降的风险。
成本控制上最有效的办法是“分级回答”：简单事实型问题（比如“XX公司的客服电话是多少”）直接走检索+规则模板，不经过大模型生成；只有复杂的归因分析、综合型问题才走完整的大模型链路。实测下来，这个策略能让整体成本下降40%，同时端到端正确率几乎不受影响。
6. 从助教到智能体：这套框架还能长成什么样
项目做到“理解式助教”这个阶段其实只是起点。我自己的判断是，这套框架最大的价值是沉淀了一套“可控的理解-决策-执行”基础设施，后续只要在流程里插入不同的执行器，就能扩展出更多场景。
短期内最容易做的一件事是“主动提问”。现在的助教还是“用户问、它答”，被动等待。如果你把意图理解层加一个“信息完整性检测”的输出，当用户的问题里缺少关键要素时（比如“帮我分析下退款率”但没指定区域和时间范围），系统可以先反问“您想分析哪个区域、哪个时间段”，拿到补充之后再继续。这一个改动对用户体验的提升非常大。
再远一点，可以把“建议”能力接上。“政策变更后预测影响范围”“新规则上线后主动提醒相关人”，这类能力本质上需要把静态的知识库检索变成动态的执行链路，会触达更多业务系统，变得更像一个数字员工。这个方向我们也在做POC，目前看下来框架不用大改，主要是执行器要按业务逐个定制。
还有一个容易忽略的扩展点是“数据沉淀”。每一轮问答、每一次低置信度检索、每一个用户反馈，都应该被收集起来形成闭环数据源。这些数据不只是用来优化模型，更是后续做“个性化助教”的基础。同一个问题，新员工和老员工需要的答案深度完全不同，只有积累了足够多的人、问题、反馈的三元组，才能做出这种个人化差异。
在实际运维的过程中，我最大的体会是：这个项目最难的部分不是把某个模型调好，而是把“理解”这件事拆解成可拆、可测、可迭代的流程模块。模型是脑袋，检索是手，评测集是眼睛，缺一不可。如果你的团队正打算从“搜索式问答”升级到“理解式助教”，我唯一的建议是——先把评测集建起来，再谈模型选型；先把流程打通，再优化单点指标；先把闭环跑起来，再追求大而全的智能。这条路看着绕，其实是走得最快的捷径。
