2026/9/13 4:52:27
FEATURED · 精选文章 
先交代一下背景。我最近在做一个面向内部业务的知识问答系统核心要求就一条大模型回答任何问题必须给出来源依据不能凭空捏造。换句话说我不让大模型“闭卷考试”而是逼它“开卷考试”——每答一句都得标注出处能回溯到具体文档、章节甚至行号。这套系统上线跑了几个月效果超出预期中间也踩了不少坑。这篇文章我把整个设计思路、实现细节和排障过程完整梳理一遍希望能给正在做类似事情的朋友一些直接可用的参考。很多人觉得大模型有“幻觉”是模型能力不行换更强的模型就行了。实际上下场做过的都明白哪怕GPT-4级别的大模型在某些垂直领域、特定资料上照样敢一本正经地胡说八道。原因不复杂模型训练时压根没见过你的内部文档它只能靠“泛化能力”硬猜。所以我从一开始就想清楚了不能用“闭卷”的思路去解决“开卷”的问题正确做法是给大模型配一个知识库让它在回答前先查资料回答时逐句引证。这篇内容适合谁看如果你正在做企业知识库问答、智能客服、文档助手这类应用或者你被大模型胡说八道坑过想知道怎么把“可信度”补上这篇文章值得你花几分钟读完。我会从设计思路、知识库构建、检索策略、提示词设计、出处标注到效果评估再到常见问题排查完整讲一遍。1. 内容整体设计与思路拆解1.1 为什么“开卷考试”比“闭卷考试”靠谱我们先想清楚一个核心问题大模型产生幻觉的根源是什么本质上是模型在生成文本时并没有一个强制机制让它只使用给定的事实依据。它是在做“概率化的续写”而不是“基于事实的推理”。当它遇到不确定的知识点最合理的做法是老实说“不知道”但大部分模型在训练目标驱动下倾向于给出一个看起来合理的答案这就是幻觉的来源。我拿生活里的场景类比一下。你闭卷考历史题遇到不会的题只能瞎编编得还挺像那么回事。但如果给你参考资料让你开卷作答你还瞎编那就说不过去了。大模型也一样我们把它从“闭卷考试”变成“开卷考试”它自然就没有瞎编的借口了。“开卷考试”系统的核心就是把一个纯粹的生成任务改造成“先检索、再生成、后校验”的复合任务。具体来说系统分三层职责检索层从知识库中根据问题找出最相关的段落这段负责“找证据”。生成层大模型只负责根据这些证据来组织语言回答问题这段负责“写答案”。验证层对生成的答案逐句检查确认每个观点都能找到对应的出处这段负责“审稿”。这三层缺一不可。少了一个“验证层”你只能防止大模型“看不见”证据瞎编却防不住它“看见了却不好好用”。我的项目里验证层的核心逻辑是把答案拆成若干独立命题再拿每个命题去知识库里做相关性检索如果匹配不到足够的依据就把这个句子标记为“无出处”再打回重写。1.2 方案选型为什么首选RAG框架而不是模型微调确定了“开卷考试”的方向之后我面临的第一个抉择是技术路线是微调模型还是走RAG检索增强生成路线说实话这两个技术栈我都有接触各有适用场景。微调模型解决的是“表达风格”和“领域格式”问题但它解决不了“事实错误”问题——因为模型参数里的知识仍然是训练时“记住”的它不会因为微调就“学会”只在你的资料范围内说话。而且微调一次成本高后续资料更新又得重新训练周期长、维护麻烦。RAG路线的优势在于“知识外置”。知识库是独立的模型不“记”知识只负责“读”和“写”。资料更新只需要更新知识库不用重新训练模型。每一条回答都能回溯到知识库里的原始段落天然满足“答案必须带出处”的需求。我的选择是主链路RAG辅以少量指令微调来规范输出格式。主链路负责可信和可溯源微调负责让模型输出更贴合内部格式要求。两条腿走路效果才最好。选型时我还考虑过一个问题如果企业内部文档格式特别复杂是否需要用专门的文档解析工具我的答案是需要但不要一上来就上重型方案。前期用轻量解析跑通全链路后续再分批上重型解析器优先处理核心文档性价比更高。1.3 整体架构从“提问”到“带出处的回答”完整链路我搭的系统整体结构大概是这样用户提问 ↓ 问题预处理改写/拆解/意图识别 ↓ 向量检索 关键词检索双路召回 ↓ 召回段落合并 重排序 ↓ 构造Prompt携带证据文本 问答指令 ↓ 大模型生成答案分点回答标注引用标号 ↓ 出处校验逐句核对引用依据 ↓ 渲染输出带链接/页码/原文档出处这个链路不算特别稀奇市面上做RAG的差不多都是这个套路。但关键的差异体现在的细节上段落怎么切、向量怎么算、重排序怎么做、Prompt怎么写、引用标号怎么对应、校验怎么执行。这些细节我会在后面的章节逐一展开。有一个比较容易被忽略的点是“问题预处理”绝对不是可选项。用户的提问五花八门有的很长有的有歧义有的自带上下文比如追问“那它呢”如果直接拿原始问题去检索效果通常很差。我加了一个“问题改写”模块先把含糊的提问改写成一个独立、清晰、检索友好的查询语句再去向量库检索。这个小改动直接把检索命中率拉高了大约15个百分点非常值得做。1.4 为什么先做最小闭环再逐步优化搭建这套系统时我给自己定的原则是先做一个“能用”的最小闭环再逐步优化“好用”的部分。因为“带出处”本身是一个系统性问题牵一发动全身。如果一开始就想把检索精度、生成质量、验证准确率全部做到位项目可能几个月都上不了线。第一版我只做了三件事文档切块、向量检索、带引用标号的Prompt生成。先让系统能跑通“提问→给出带编号引用的回答”这条主链路。上线之后再根据用户反馈逐步增加重排序、问题改写、出处校验、引用标号与原文锚点映射、答案置信度评分。每加一个模块就做一次回归测试确保老问题的效果不倒退。我特别想强调这一点做AI应用一个最大的坑就是“想一口气全做完”。模型输出的不确定性决定了你没法一下子判断问题出在哪一个环节必须靠小步快跑用真实流量来暴露问题。你在开发环境里构造的测试集永远是“干净”的真正的问题都藏在实际用户的五花八门提问里。2. 工具选型与知识库构建解析2.1 模型选型本地部署还是API调用在这个项目里我同时用了开源模型和商用API分别承担不同职责检索重排序模型用的是开源的bge-reranker系列。这类模型参数量不大跑在普通GPU上完全没有压力但效果非常明显它能把向量召回的结果重新排序把最相关的段落挤到前面。生成模型主用商用API业务数据经过脱敏备选本地部署的Qwen系列对应千问大模型本地部署的场景。商用API效果更好本地部署更安全两者互相兜底。有人问我为什么生成模型不直接用开源的原因是生成质量差距确实存在尤其在长文本理解、复杂指令遵循、以及对“不知道就无法回答”这类场景的判断上商用大模型的经验更丰富。但我也不是无脑用商用API因为企业内部确实存在数据不能出域的场景所以保留了一条本地部署链路。两条链路共享同一个知识库、同一套检索逻辑、同一套Prompt模板只是生成模型不同。部署本地模型时我用的是vLLM框架吞吐量和显存效率都还不错。如果你只是个人实验Ollama就够用如果是生产环境且并发访问量不小vLLM是更合适的选择。至于模型量化我建议先用半精度跑通确认效果之后再考虑量化为int8或int4不要一开始就追求省显存否则排错的时候保护层太多会很痛苦。2.2 文档切分策略固定窗口、语义切分还是递归切分文档切块是整个知识库构建里最容易被低估的环节。切得太碎语义不完整检索出来的是“断章取义”的片段切得太大冗余信息太多不仅浪费向量存储空间还会稀释检索精度。我实测下来推荐使用“标题感知的递归切分”。具体做法是先用解析器提取文档的标题层级结构H1/H2/H3。在标题边界处优先切分确保一个块尽量属于同一个章节。如果块还是太长再按段落、句子逐级切分直到满足最大长度限制。我第一版用的固定长度切块每512个字切一块重叠50个字结果发现很多块内容是“半句话”检索出来之后大模型拿着残缺的证据根本没法好好回答。后来改了递归切分并把重叠调到了100字左右效果显著改善。关于重叠overlap的设定我建议放在最大长度的15%~20%之间。太短了上下文衔接不够太长了重复信息太多既浪费存储又影响检索。这个比例是我在具体业务上试出来的你可以参考但还是要结合自己的文档情况多试几组。还有一个细节表格数据不要硬切。如果文档里有完整表格建议把整个表格作为一个块存进去不要剥裂成碎片。我遇到过一个情况一份产品的参数字段被切成两半检索出来只有一半数据大模型直接按另一半“脑补”差点出事故。这种问题在切块阶段不处理后面再想补就是巨大的坑。2.3 向量化Embedding模型的选型与实战经验向量化的核心是把文本映射到高维向量空间里让语义相近的文本在向量空间中距离更近。我对比过几款Embedding模型的效果OpenAI的text-embedding-3系列通用性强英文效果好中文稍逊。智源的bge-large-zh-v1.5中文场景表现扎实是中文本地化的不错选择。阿里通义的text-embedding-v系列中文效果好和自家大模型配合得好。最终我选了bge-large-zh-v1.5作为主力向量模型原因有三中文效果好贴合我们的业务文档。开源可本地部署不依赖外部API数据不出域。支持“查询指令”在检索时给查询语句加一个指令前缀能显著提高检索效果。这里有个使用细节想单独说一下bge系列模型在对比学习训练阶段会区分query和passage两侧所以正式使用时检索侧和文档侧要加不同的指令前缀。如果两侧都裸着去向量化效果会打折扣。这个细节我从源码注释里翻到的特意验证过确实有效。Embedding模型换个角度来说是整套系统里“更新换代最慢”的组件。不需要频繁升级它决定的是“上限”而切分策略和重排序模型决定的是“下限”。所以我建议选一个好一点的Embedding模型固定下来把精力放到检索和重排序上去。2.4 向量数据库选型与明细字段设计向量数据库我用的是Milvus也考虑过Elasticsearch的向量检索插件和开源的Qdrant。选型的时候我在意这几点开源可控、支持向量与标量组合过滤、有成熟的分布式方案。Milvus在这几个方面都符合需求社区也活跃所以我选了它。但我特别想提醒的是向量数据库里不能只存文本块和向量一定要把文档元数据一起存进去。我在集合里设计了这些字段chunk_id切块的唯一ID。doc_id原始文档ID。title文档标题。chapter章节标题用于最终出处展示。source_url原文链接。page_num原文页码。content切块内容。content_vector向量字段。为什么必须存这些元数据因为“出处”能否精确到页码和章节全靠它们兜底。如果只存embedding和content最后你就只能给用户弹出一段文字连链接都点不了体验会大打折扣。关于分区partition我在初始阶段没有做因为文档量还没到必须分区的程度。但如果你的文档量很大且分类明确比如按部门或按产品线分建议一开始就建分区检索时可以按分区过滤性能和精确度都会提升。3. 检索与重排序决定“能不能找到”3.1 双路召回向量检索与关键词检索的结合很多RAG教程告诉你“用向量检索就行了”但实际生产环境里只靠向量检索是远远不够的。原因在于专业术语、缩写、型号代码在向量空间里不一定能跟用户的自然语言对齐。比如用户问“AD账密过期策略”如果知识库里写的是“账号密码有效期规则”向量相似度未必高但关键词“密码”“过期”能精确匹配。向量检索对精确匹配不敏感而关键词检索对精准实体匹配很有优势。所以我的方案是**“向量检索 关键词检索”双路召回**。向量检索负责找语义相似的段落关键词检索负责找包含关键实体的段落两路结果合在一起再交给重排序模型统一打分排序。具体实现上关键词检索我用的是Elasticsearch的BM25算法它和向量检索并行执行。召回数量上向量召回取Top 20BM25召回取Top 10合并去重后总共大约20~25段再进重排序阶段。有人觉得Top K设得越多越好其实不是太多会把不相关的段落带进来干扰重排序模型的判断。合理的做法是“召回宽进排序严出”。3.2 重排序为什么是RAG系统的“隐形功臣”RAG系统里最容易被忽视的组件我觉得就是重排序Rerank。很多人以为有向量检索就够了其实向量检索的召回结果只是“相关候选”排序的合理性并没有保证。重排序模型的作用是站在向量检索的肩膀上用更精细的交互方式评估候选段落与问题的相关度重新排序。我用的bge-reranker-v2-m3输入是(query, document)的文本对输出一个相关性分数。它比双塔结构的向量模型更精确因为它在模型内部让问题和文档做了token级别的交互。我实测了一组数据在没有重排序时Top 1命中的准确率大约是55%加了重排序之后Top 1的命中率提升到72%。这个提升幅度非常大而成本仅仅是多了一次模型推理耗时增加大约几十毫秒完全可以接受。重排序的输入长度限制是个坑bge-reranker-v2-m3最大输入长度是1024个token长文档会被截断。解决方法是先从向量检索召回结果里保留完整的段落文本但重排序时对超长段落做“分段打分取最大段得分”的处理避免信息丢失。3.3 混合检索的归一化与合并策略两路召回的结果怎么合并听起来是个细节实际很影响效果。向量距离得分和BM25得分不在同一个量级不能直接相加或取最大值。我用的方法对向量检索结果把相似度归一化到0~1区间。对BM25结果把得分除以最高分也归一化到0~1。两者加权融合向量权重0.6BM25权重0.4这是我从业务数据上试出来比较平衡的值。融合后的候选集合输入重排序模型做最终排序。这个融合策略的好处是简单、稳定、可调参。不同业务场景两个权重可以调如果你的文档里专业名词多可以适当增加BM25的权重。我后来还试过让BM25只负责“必须包含实体”的硬过滤效果也不错但不如融合方式普适。还有一个细节检索阶段不能只搜未加工的查询词。我在问题预处理阶段做了一个查询扩展把用户问题中的同义词和缩写展开比如“AD”展开为“Active Directory”“账密”展开为“账号密码”然后再去检索。这算是“开卷考试”里给考生“提前划重点”的操作效果明显。4. 生成与出处标注从“有依据”到“看得到依据”4.1 提示词设计强制模型“先引用再回答”如果检索质量不错但生成的答案没有“引用痕迹”那整个系统前功尽弃。这就要靠Prompt把规则讲清楚。我的Prompt模板核心指令如下你是一个知识问答助手。请严格按照“参考资料”中的内容回答问题。 规则 1. 只能使用参考资料中的信息不得使用外部知识或推测。 2. 每个回答要点后用[引用编号]标注出处编号对应参考资料中的编号。 3. 如果参考资料不足以回答问题请直接回答“根据现有资料无法回答”不要编造。 4. 引用格式[1][2]表示引用了第1条和第2条资料。这个Prompt看着简单其实有三层用意规则1掐死了模型“自由发挥”的欲望。规则2强制模型在回答时把答案和引用锚定在一起生成格式天然可校验。规则3给模型留了一条“安全出口”宁可说不知道也不能瞎编。我在实战中发现模型对“无法回答时怎么说”的理解直接影响幻觉率。如果Prompt里只有“不知道就说不知道”这句话还不够我会在Few-shot示例里专门给一个“资料不足、拒绝回答”的例子。Few-shot示例对模型的约束力比纯文字规则强很多这算是提示词工程里面比较实用的一招。4.2 引用编号与出处的对应关系实现检索阶段我找回来的每一条段落都带一个文档ID、章标题和页码。我在构造Prompt时给每一条段落都编了一个引用编号例如[1] 来源产品手册-第三版第二章第5页 内容当账号密码连续输错5次后系统锁定30分钟。 [2] 来源运维规范-V2.1附录B第12页 内容账户解锁需管理员在后台手动执行。大模型在回答时如果引用了“[1]”那全文里就能准确回溯到“产品手册-第三版第二章第5页”。这不仅是一个标号它是一条完整的、可点击的、可追溯的证据链。我特别想说的是引用编号最好不要让大模型自己编。有些做法是让模型回答后自己生成一个“参考来源”列表这是极其危险的——它有可能编造出来一个“看起来很像那么回事”的来源标题。正确做法是来源列表由系统在检索阶段恒定生成模型只能从给定的编号里引用不能自己新增。4.3 出处校验逐句核对引用是否真实存在这是整套系统里最硬的“防瞎编”环节。大模型生成了答案之后我们不能直接信要做一次“审计”。我的做法是把回答按句号拆成独立的句子。提取每个句子末尾的引用标号比如[1][3]。检查这些标号是否都在本次检索返回的引用编号范围之内。如果句子没有引用标号或者引用了不存在的编号就触发“重新生成”流程。对于有引用的句子我再做一个“引用相关性校验”把该句内容与对应的资料段落分别向量化计算相似度低于阈值的句子视为“引用与内容不匹配”同样打回重写。这套校验流程我称之为“三查”。一查引用格式在不在二查标号真假三查内容与引用的语义匹配。三查都通过了答案才算合格否则进入“重写队列”。重写不是简单的重新调用一次生成模型而是把校验时发现的错误反馈带回Prompt里。比如我会告诉模型“上一轮你在回答第2点时引用了[4]但这段资料与你的表述不符请重新组织语言只基于[1][2]回答”。这种“纠错式提示”比闷头重新生成有效得多也让我比较意外。大模型是能够在收到明确反馈后修正回答的。4.4 置信度评分让系统知道“自己有多大把握”用户问一个问题系统答得好不好不能只靠人去判断。我加了一个置信度评分模块输出0~1之间的分数由以下因素加权计算最终检索到的Top1段落与问题的相关度权重40%。引用段落与该句答案的平均语义相似度权重30%。答案长度是否落在合理区间权重10%。是否存在无引用句子权重20%存在直接扣掉这20%。置信度低于0.6的答案界面会显示“该答案置信度较低仅供参考”并优先展示参考来源降低误导风险。高于0.85的答案直接进入高可信通道。这个模块的价值在于给使用者一个“信任预期”。大模型回答天然有不确定性与其让用户盲目相信不如诚实地告诉用户“这题我们有把握”“这题我们也没底”。这在一部分场景下是系统能用起来的关键。5. 评估与调优用数据说话的系统5.1 评测集构建怎么衡量“答案带出处”做得好不好做AI应用不建立评测集就等于盲人摸象。我建的评测集一共分三类标准问答集从历史用户真实提问里抽样300条人工写好标准答案标注对应的知识库位置。这部分主要测“答得对不对”。来源可溯集随机抽100条检查答案里的每个引用是否真实存在且指向正确。这部分主要测“出处真不真”。拒答集专门准备50条知识库里没有答案的问题看看系统会不会“硬答”。这部分主要测“知不知道边界”。每次系统调整之后我都跑一遍这三类评测集记录三个指标答案正确率、引用真实率、误答率。我给自己定的目标是答案正确率不低于75%引用真实率不低于98%误答率不高于10%。定期跑评测集效果好坏一目了然不至于被个别例子带偏。5.2 常见调优方向与优先级按我自己的经验RAG系统调优的优先级排一个序的话文档切分第一优先切碎了怎么做都白搭切好了后面的问题少一半。重排序第二优先性价比最高效果提升最明显。Prompt规则第三优先直接决定输出格式合不合格。Embedding模型第四优先重要但更新代价大不需要频繁动。生成模型按需有条件再上更强的模型。按这个顺序排查调优遇到问题不至于手忙脚乱。我最常遇到的现象是某类问题答得不好九成情况不是模型不行而是“资料压根没切好”或者“压根没被检索回来”。所以先回头检查知识库再检查检索最后才去调生成参数。5.3 效果数据这套系统到底把幻觉降了多少上线一个多月后我从日志里统计了几组数据未加系统前纯大模型回答的幻觉率大约37%人工抽检300条。加了RAG主链路后幻觉率降到12%。加了出处校验和重写机制后幻觉率进一步降到4%左右。4%的幻觉率谈不上完美但已经能给业务一个“基本可信”的答案。剩下的4%是什么大多数是“检索到了相关段落但段落本身信息不完整”导致回答以偏概全。我们正在通过引入多轮追问和扩展资料来解决这是下一步的事情了。6. 常见问题与排查技巧实录6.1 检索老是不准先排查文档清洗和切分如果你发现系统的回答质量不稳定别急着调大模型参数先做几个排查项文档格式是否统一PDF、Word、PPT混合在一起的文档解析器兼容性问题会非常多。我的做法是统一转成文本或Markdown再做后续处理转不了的单独走人工清洗。文档是否有OCR扫描件有的PDF是图片格式直接读取是乱码必须先走OCR。这一步不做后面检索效果再好也没有用因为索引里都是乱码。切分长度是否合理太长或太短对检索影响都很大。你可以对同一个文档试几组不同的切分参数分别在评测集上跑一遍看Top1命中率变化。我记得有一次系统效果特别差排查了很久发现是一批新导入的PDF全是扫描件切块后存进去的全是乱码。后来加了OCR预处理问题直接消失。这种问题属于“数据进不来”再厉害的算法也救不回来。6.2 引用编号对不上检查模型的“标号洁癖”生成模型在引用编号这件事上偶尔会“自作聪明”。我遇到过几种情况回答中引用了[1][4]但给定资料只有[1][2][3]它编了个[4]出来。引用了[1]但内容表述更贴近[2]的含义。回答里压根没有引用编号变成了“自由创作”。这些问题的根源是Prompt约束不够强或者模型本身对指令遵循能力有限。我用的解决方案包括提高Few-shot示例中“正确引用”示例的数量。在生成参数里把温度调低到0.1左右减少随机性。最关键的绝对不要给模型“自由发挥”的空间Prompt里明确说“如果没有合适的引用不要回答该点”。如果多次重写仍然出问题我有时候干脆把答案切成多句话分别生成把“引用范围”收窄会更容易控制。6.3 文档更新后老答案还“阴魂不散”注意缓存与版本控制知识库不是一成不变的文档会更新。我踩过一个坑文档A在知识库里更新了内容但用户问问题检索出来的还是旧版本。原因是文档解析和向量化的缓存没打版本号旧向量覆盖了新向量导致检索结果混乱。解决方案是给文档加版本号更新文档时生成新的doc_id旧版本向量定期清理。查询时按版本过滤保证只用当前生效的资料。另外索引有缓存问题向量数据库的写入和删除不能想当然立即生效需要确认文档状态。6.4 成本与性能怎么在预算内维持体验整套系统的成本大头不在GPU而在向量化和重排序这两类模型推理。每个用户提问都要走一次向量化、一次重排序如果没有缓存机制高频问题会烧掉大量算力。我的优化手段问题级缓存相同或高度相似的问题直接返回缓存答案命中率接近30%。批量向量化文档导入时不逐条向量化而是批量提交给Embedding模型吞吐量翻倍。重排序模型量化把bge-reranker量化到int8精度损失很小但推理速度提升明显。如果你想控制成本优先考虑这三个方向。不要一上来就堆GPU很多时候是代码层面的浪费比算力不足更严重。7. 一套“开卷考试”系统的最终复盘与后续演进系统上线快三个月了说几个我感触最深的地方。“答案必须带出处”这个需求比我想象的更刚需。它不是某个领导拍脑门定出来的而是知识密集型业务的天然要求。回答错了可以改没有出处的“权威感”对用户决策影响太大了。技术上我认为最有价值的设计决策是两处第一是双路召回 重排序它保证了“找得准”第二是逐句校验 纠错式重写它保证了“敢负责”。这两点组合在一起才真正把幻觉压到了可接受的范围。至于Embedding用哪家、向量数据库用哪个反而不是最关键的变量只要选稳定开源、社区活跃的产品都不会出大岔子。另一个体会是RAG系统的调试周期比传统软件长不少因为它每一个环节都可能引入不确定性。你得习惯“改了一个变量要跑一轮评测集”的工作方式而不是“改完立刻就能看出效果”。这个节奏对团队管理也是一种挑战我一度被业务方追问“为什么调优这么慢”解释清楚评测逻辑之后才达成共识。后续我计划做两件事。一是给检索层引入知识图谱让系统能处理“A和B是什么关系”这类多跳关系型问题单靠向量检索在关系推理上还是太弱。二是增加答案分点的多轮追问机制用户可以对答案中的某一点继续追问系统可以精准定位到指定段落提供更深度的信息。这两个方向都是“开卷考试”的自然延伸等有新进展了再单独写一篇。最后分享一个小细节在出处展示上我后来给答案里的引用标号做了“悬浮卡片”效果鼠标一放上去就能看到引用来源的标题和页码。就这么一个小改动用户对系统答案的信任度明显上升。很多影响“可信感”的往往不是算法复杂度而是产品细节有没有做到位。做“带出处的系统”这件事最终目标不仅是技术上不瞎编还要让使用者真切感受到“这个答案是有据可查的”。
让大模型开卷考试：RAG知识库问答系统实现每句答复可溯源
先交代一下背景。我最近在做一个面向内部业务的知识问答系统核心要求就一条大模型回答任何问题必须给出来源依据不能凭空捏造。换句话说我不让大模型“闭卷考试”而是逼它“开卷考试”——每答一句都得标注出处能回溯到具体文档、章节甚至行号。这套系统上线跑了几个月效果超出预期中间也踩了不少坑。这篇文章我把整个设计思路、实现细节和排障过程完整梳理一遍希望能给正在做类似事情的朋友一些直接可用的参考。很多人觉得大模型有“幻觉”是模型能力不行换更强的模型就行了。实际上下场做过的都明白哪怕GPT-4级别的大模型在某些垂直领域、特定资料上照样敢一本正经地胡说八道。原因不复杂模型训练时压根没见过你的内部文档它只能靠“泛化能力”硬猜。所以我从一开始就想清楚了不能用“闭卷”的思路去解决“开卷”的问题正确做法是给大模型配一个知识库让它在回答前先查资料回答时逐句引证。这篇内容适合谁看如果你正在做企业知识库问答、智能客服、文档助手这类应用或者你被大模型胡说八道坑过想知道怎么把“可信度”补上这篇文章值得你花几分钟读完。我会从设计思路、知识库构建、检索策略、提示词设计、出处标注到效果评估再到常见问题排查完整讲一遍。1. 内容整体设计与思路拆解1.1 为什么“开卷考试”比“闭卷考试”靠谱我们先想清楚一个核心问题大模型产生幻觉的根源是什么本质上是模型在生成文本时并没有一个强制机制让它只使用给定的事实依据。它是在做“概率化的续写”而不是“基于事实的推理”。当它遇到不确定的知识点最合理的做法是老实说“不知道”但大部分模型在训练目标驱动下倾向于给出一个看起来合理的答案这就是幻觉的来源。我拿生活里的场景类比一下。你闭卷考历史题遇到不会的题只能瞎编编得还挺像那么回事。但如果给你参考资料让你开卷作答你还瞎编那就说不过去了。大模型也一样我们把它从“闭卷考试”变成“开卷考试”它自然就没有瞎编的借口了。“开卷考试”系统的核心就是把一个纯粹的生成任务改造成“先检索、再生成、后校验”的复合任务。具体来说系统分三层职责检索层从知识库中根据问题找出最相关的段落这段负责“找证据”。生成层大模型只负责根据这些证据来组织语言回答问题这段负责“写答案”。验证层对生成的答案逐句检查确认每个观点都能找到对应的出处这段负责“审稿”。这三层缺一不可。少了一个“验证层”你只能防止大模型“看不见”证据瞎编却防不住它“看见了却不好好用”。我的项目里验证层的核心逻辑是把答案拆成若干独立命题再拿每个命题去知识库里做相关性检索如果匹配不到足够的依据就把这个句子标记为“无出处”再打回重写。1.2 方案选型为什么首选RAG框架而不是模型微调确定了“开卷考试”的方向之后我面临的第一个抉择是技术路线是微调模型还是走RAG检索增强生成路线说实话这两个技术栈我都有接触各有适用场景。微调模型解决的是“表达风格”和“领域格式”问题但它解决不了“事实错误”问题——因为模型参数里的知识仍然是训练时“记住”的它不会因为微调就“学会”只在你的资料范围内说话。而且微调一次成本高后续资料更新又得重新训练周期长、维护麻烦。RAG路线的优势在于“知识外置”。知识库是独立的模型不“记”知识只负责“读”和“写”。资料更新只需要更新知识库不用重新训练模型。每一条回答都能回溯到知识库里的原始段落天然满足“答案必须带出处”的需求。我的选择是主链路RAG辅以少量指令微调来规范输出格式。主链路负责可信和可溯源微调负责让模型输出更贴合内部格式要求。两条腿走路效果才最好。选型时我还考虑过一个问题如果企业内部文档格式特别复杂是否需要用专门的文档解析工具我的答案是需要但不要一上来就上重型方案。前期用轻量解析跑通全链路后续再分批上重型解析器优先处理核心文档性价比更高。1.3 整体架构从“提问”到“带出处的回答”完整链路我搭的系统整体结构大概是这样用户提问 ↓ 问题预处理改写/拆解/意图识别 ↓ 向量检索 关键词检索双路召回 ↓ 召回段落合并 重排序 ↓ 构造Prompt携带证据文本 问答指令 ↓ 大模型生成答案分点回答标注引用标号 ↓ 出处校验逐句核对引用依据 ↓ 渲染输出带链接/页码/原文档出处这个链路不算特别稀奇市面上做RAG的差不多都是这个套路。但关键的差异体现在的细节上段落怎么切、向量怎么算、重排序怎么做、Prompt怎么写、引用标号怎么对应、校验怎么执行。这些细节我会在后面的章节逐一展开。有一个比较容易被忽略的点是“问题预处理”绝对不是可选项。用户的提问五花八门有的很长有的有歧义有的自带上下文比如追问“那它呢”如果直接拿原始问题去检索效果通常很差。我加了一个“问题改写”模块先把含糊的提问改写成一个独立、清晰、检索友好的查询语句再去向量库检索。这个小改动直接把检索命中率拉高了大约15个百分点非常值得做。1.4 为什么先做最小闭环再逐步优化搭建这套系统时我给自己定的原则是先做一个“能用”的最小闭环再逐步优化“好用”的部分。因为“带出处”本身是一个系统性问题牵一发动全身。如果一开始就想把检索精度、生成质量、验证准确率全部做到位项目可能几个月都上不了线。第一版我只做了三件事文档切块、向量检索、带引用标号的Prompt生成。先让系统能跑通“提问→给出带编号引用的回答”这条主链路。上线之后再根据用户反馈逐步增加重排序、问题改写、出处校验、引用标号与原文锚点映射、答案置信度评分。每加一个模块就做一次回归测试确保老问题的效果不倒退。我特别想强调这一点做AI应用一个最大的坑就是“想一口气全做完”。模型输出的不确定性决定了你没法一下子判断问题出在哪一个环节必须靠小步快跑用真实流量来暴露问题。你在开发环境里构造的测试集永远是“干净”的真正的问题都藏在实际用户的五花八门提问里。2. 工具选型与知识库构建解析2.1 模型选型本地部署还是API调用在这个项目里我同时用了开源模型和商用API分别承担不同职责检索重排序模型用的是开源的bge-reranker系列。这类模型参数量不大跑在普通GPU上完全没有压力但效果非常明显它能把向量召回的结果重新排序把最相关的段落挤到前面。生成模型主用商用API业务数据经过脱敏备选本地部署的Qwen系列对应千问大模型本地部署的场景。商用API效果更好本地部署更安全两者互相兜底。有人问我为什么生成模型不直接用开源的原因是生成质量差距确实存在尤其在长文本理解、复杂指令遵循、以及对“不知道就无法回答”这类场景的判断上商用大模型的经验更丰富。但我也不是无脑用商用API因为企业内部确实存在数据不能出域的场景所以保留了一条本地部署链路。两条链路共享同一个知识库、同一套检索逻辑、同一套Prompt模板只是生成模型不同。部署本地模型时我用的是vLLM框架吞吐量和显存效率都还不错。如果你只是个人实验Ollama就够用如果是生产环境且并发访问量不小vLLM是更合适的选择。至于模型量化我建议先用半精度跑通确认效果之后再考虑量化为int8或int4不要一开始就追求省显存否则排错的时候保护层太多会很痛苦。2.2 文档切分策略固定窗口、语义切分还是递归切分文档切块是整个知识库构建里最容易被低估的环节。切得太碎语义不完整检索出来的是“断章取义”的片段切得太大冗余信息太多不仅浪费向量存储空间还会稀释检索精度。我实测下来推荐使用“标题感知的递归切分”。具体做法是先用解析器提取文档的标题层级结构H1/H2/H3。在标题边界处优先切分确保一个块尽量属于同一个章节。如果块还是太长再按段落、句子逐级切分直到满足最大长度限制。我第一版用的固定长度切块每512个字切一块重叠50个字结果发现很多块内容是“半句话”检索出来之后大模型拿着残缺的证据根本没法好好回答。后来改了递归切分并把重叠调到了100字左右效果显著改善。关于重叠overlap的设定我建议放在最大长度的15%~20%之间。太短了上下文衔接不够太长了重复信息太多既浪费存储又影响检索。这个比例是我在具体业务上试出来的你可以参考但还是要结合自己的文档情况多试几组。还有一个细节表格数据不要硬切。如果文档里有完整表格建议把整个表格作为一个块存进去不要剥裂成碎片。我遇到过一个情况一份产品的参数字段被切成两半检索出来只有一半数据大模型直接按另一半“脑补”差点出事故。这种问题在切块阶段不处理后面再想补就是巨大的坑。2.3 向量化Embedding模型的选型与实战经验向量化的核心是把文本映射到高维向量空间里让语义相近的文本在向量空间中距离更近。我对比过几款Embedding模型的效果OpenAI的text-embedding-3系列通用性强英文效果好中文稍逊。智源的bge-large-zh-v1.5中文场景表现扎实是中文本地化的不错选择。阿里通义的text-embedding-v系列中文效果好和自家大模型配合得好。最终我选了bge-large-zh-v1.5作为主力向量模型原因有三中文效果好贴合我们的业务文档。开源可本地部署不依赖外部API数据不出域。支持“查询指令”在检索时给查询语句加一个指令前缀能显著提高检索效果。这里有个使用细节想单独说一下bge系列模型在对比学习训练阶段会区分query和passage两侧所以正式使用时检索侧和文档侧要加不同的指令前缀。如果两侧都裸着去向量化效果会打折扣。这个细节我从源码注释里翻到的特意验证过确实有效。Embedding模型换个角度来说是整套系统里“更新换代最慢”的组件。不需要频繁升级它决定的是“上限”而切分策略和重排序模型决定的是“下限”。所以我建议选一个好一点的Embedding模型固定下来把精力放到检索和重排序上去。2.4 向量数据库选型与明细字段设计向量数据库我用的是Milvus也考虑过Elasticsearch的向量检索插件和开源的Qdrant。选型的时候我在意这几点开源可控、支持向量与标量组合过滤、有成熟的分布式方案。Milvus在这几个方面都符合需求社区也活跃所以我选了它。但我特别想提醒的是向量数据库里不能只存文本块和向量一定要把文档元数据一起存进去。我在集合里设计了这些字段chunk_id切块的唯一ID。doc_id原始文档ID。title文档标题。chapter章节标题用于最终出处展示。source_url原文链接。page_num原文页码。content切块内容。content_vector向量字段。为什么必须存这些元数据因为“出处”能否精确到页码和章节全靠它们兜底。如果只存embedding和content最后你就只能给用户弹出一段文字连链接都点不了体验会大打折扣。关于分区partition我在初始阶段没有做因为文档量还没到必须分区的程度。但如果你的文档量很大且分类明确比如按部门或按产品线分建议一开始就建分区检索时可以按分区过滤性能和精确度都会提升。3. 检索与重排序决定“能不能找到”3.1 双路召回向量检索与关键词检索的结合很多RAG教程告诉你“用向量检索就行了”但实际生产环境里只靠向量检索是远远不够的。原因在于专业术语、缩写、型号代码在向量空间里不一定能跟用户的自然语言对齐。比如用户问“AD账密过期策略”如果知识库里写的是“账号密码有效期规则”向量相似度未必高但关键词“密码”“过期”能精确匹配。向量检索对精确匹配不敏感而关键词检索对精准实体匹配很有优势。所以我的方案是**“向量检索 关键词检索”双路召回**。向量检索负责找语义相似的段落关键词检索负责找包含关键实体的段落两路结果合在一起再交给重排序模型统一打分排序。具体实现上关键词检索我用的是Elasticsearch的BM25算法它和向量检索并行执行。召回数量上向量召回取Top 20BM25召回取Top 10合并去重后总共大约20~25段再进重排序阶段。有人觉得Top K设得越多越好其实不是太多会把不相关的段落带进来干扰重排序模型的判断。合理的做法是“召回宽进排序严出”。3.2 重排序为什么是RAG系统的“隐形功臣”RAG系统里最容易被忽视的组件我觉得就是重排序Rerank。很多人以为有向量检索就够了其实向量检索的召回结果只是“相关候选”排序的合理性并没有保证。重排序模型的作用是站在向量检索的肩膀上用更精细的交互方式评估候选段落与问题的相关度重新排序。我用的bge-reranker-v2-m3输入是(query, document)的文本对输出一个相关性分数。它比双塔结构的向量模型更精确因为它在模型内部让问题和文档做了token级别的交互。我实测了一组数据在没有重排序时Top 1命中的准确率大约是55%加了重排序之后Top 1的命中率提升到72%。这个提升幅度非常大而成本仅仅是多了一次模型推理耗时增加大约几十毫秒完全可以接受。重排序的输入长度限制是个坑bge-reranker-v2-m3最大输入长度是1024个token长文档会被截断。解决方法是先从向量检索召回结果里保留完整的段落文本但重排序时对超长段落做“分段打分取最大段得分”的处理避免信息丢失。3.3 混合检索的归一化与合并策略两路召回的结果怎么合并听起来是个细节实际很影响效果。向量距离得分和BM25得分不在同一个量级不能直接相加或取最大值。我用的方法对向量检索结果把相似度归一化到0~1区间。对BM25结果把得分除以最高分也归一化到0~1。两者加权融合向量权重0.6BM25权重0.4这是我从业务数据上试出来比较平衡的值。融合后的候选集合输入重排序模型做最终排序。这个融合策略的好处是简单、稳定、可调参。不同业务场景两个权重可以调如果你的文档里专业名词多可以适当增加BM25的权重。我后来还试过让BM25只负责“必须包含实体”的硬过滤效果也不错但不如融合方式普适。还有一个细节检索阶段不能只搜未加工的查询词。我在问题预处理阶段做了一个查询扩展把用户问题中的同义词和缩写展开比如“AD”展开为“Active Directory”“账密”展开为“账号密码”然后再去检索。这算是“开卷考试”里给考生“提前划重点”的操作效果明显。4. 生成与出处标注从“有依据”到“看得到依据”4.1 提示词设计强制模型“先引用再回答”如果检索质量不错但生成的答案没有“引用痕迹”那整个系统前功尽弃。这就要靠Prompt把规则讲清楚。我的Prompt模板核心指令如下你是一个知识问答助手。请严格按照“参考资料”中的内容回答问题。 规则 1. 只能使用参考资料中的信息不得使用外部知识或推测。 2. 每个回答要点后用[引用编号]标注出处编号对应参考资料中的编号。 3. 如果参考资料不足以回答问题请直接回答“根据现有资料无法回答”不要编造。 4. 引用格式[1][2]表示引用了第1条和第2条资料。这个Prompt看着简单其实有三层用意规则1掐死了模型“自由发挥”的欲望。规则2强制模型在回答时把答案和引用锚定在一起生成格式天然可校验。规则3给模型留了一条“安全出口”宁可说不知道也不能瞎编。我在实战中发现模型对“无法回答时怎么说”的理解直接影响幻觉率。如果Prompt里只有“不知道就说不知道”这句话还不够我会在Few-shot示例里专门给一个“资料不足、拒绝回答”的例子。Few-shot示例对模型的约束力比纯文字规则强很多这算是提示词工程里面比较实用的一招。4.2 引用编号与出处的对应关系实现检索阶段我找回来的每一条段落都带一个文档ID、章标题和页码。我在构造Prompt时给每一条段落都编了一个引用编号例如[1] 来源产品手册-第三版第二章第5页 内容当账号密码连续输错5次后系统锁定30分钟。 [2] 来源运维规范-V2.1附录B第12页 内容账户解锁需管理员在后台手动执行。大模型在回答时如果引用了“[1]”那全文里就能准确回溯到“产品手册-第三版第二章第5页”。这不仅是一个标号它是一条完整的、可点击的、可追溯的证据链。我特别想说的是引用编号最好不要让大模型自己编。有些做法是让模型回答后自己生成一个“参考来源”列表这是极其危险的——它有可能编造出来一个“看起来很像那么回事”的来源标题。正确做法是来源列表由系统在检索阶段恒定生成模型只能从给定的编号里引用不能自己新增。4.3 出处校验逐句核对引用是否真实存在这是整套系统里最硬的“防瞎编”环节。大模型生成了答案之后我们不能直接信要做一次“审计”。我的做法是把回答按句号拆成独立的句子。提取每个句子末尾的引用标号比如[1][3]。检查这些标号是否都在本次检索返回的引用编号范围之内。如果句子没有引用标号或者引用了不存在的编号就触发“重新生成”流程。对于有引用的句子我再做一个“引用相关性校验”把该句内容与对应的资料段落分别向量化计算相似度低于阈值的句子视为“引用与内容不匹配”同样打回重写。这套校验流程我称之为“三查”。一查引用格式在不在二查标号真假三查内容与引用的语义匹配。三查都通过了答案才算合格否则进入“重写队列”。重写不是简单的重新调用一次生成模型而是把校验时发现的错误反馈带回Prompt里。比如我会告诉模型“上一轮你在回答第2点时引用了[4]但这段资料与你的表述不符请重新组织语言只基于[1][2]回答”。这种“纠错式提示”比闷头重新生成有效得多也让我比较意外。大模型是能够在收到明确反馈后修正回答的。4.4 置信度评分让系统知道“自己有多大把握”用户问一个问题系统答得好不好不能只靠人去判断。我加了一个置信度评分模块输出0~1之间的分数由以下因素加权计算最终检索到的Top1段落与问题的相关度权重40%。引用段落与该句答案的平均语义相似度权重30%。答案长度是否落在合理区间权重10%。是否存在无引用句子权重20%存在直接扣掉这20%。置信度低于0.6的答案界面会显示“该答案置信度较低仅供参考”并优先展示参考来源降低误导风险。高于0.85的答案直接进入高可信通道。这个模块的价值在于给使用者一个“信任预期”。大模型回答天然有不确定性与其让用户盲目相信不如诚实地告诉用户“这题我们有把握”“这题我们也没底”。这在一部分场景下是系统能用起来的关键。5. 评估与调优用数据说话的系统5.1 评测集构建怎么衡量“答案带出处”做得好不好做AI应用不建立评测集就等于盲人摸象。我建的评测集一共分三类标准问答集从历史用户真实提问里抽样300条人工写好标准答案标注对应的知识库位置。这部分主要测“答得对不对”。来源可溯集随机抽100条检查答案里的每个引用是否真实存在且指向正确。这部分主要测“出处真不真”。拒答集专门准备50条知识库里没有答案的问题看看系统会不会“硬答”。这部分主要测“知不知道边界”。每次系统调整之后我都跑一遍这三类评测集记录三个指标答案正确率、引用真实率、误答率。我给自己定的目标是答案正确率不低于75%引用真实率不低于98%误答率不高于10%。定期跑评测集效果好坏一目了然不至于被个别例子带偏。5.2 常见调优方向与优先级按我自己的经验RAG系统调优的优先级排一个序的话文档切分第一优先切碎了怎么做都白搭切好了后面的问题少一半。重排序第二优先性价比最高效果提升最明显。Prompt规则第三优先直接决定输出格式合不合格。Embedding模型第四优先重要但更新代价大不需要频繁动。生成模型按需有条件再上更强的模型。按这个顺序排查调优遇到问题不至于手忙脚乱。我最常遇到的现象是某类问题答得不好九成情况不是模型不行而是“资料压根没切好”或者“压根没被检索回来”。所以先回头检查知识库再检查检索最后才去调生成参数。5.3 效果数据这套系统到底把幻觉降了多少上线一个多月后我从日志里统计了几组数据未加系统前纯大模型回答的幻觉率大约37%人工抽检300条。加了RAG主链路后幻觉率降到12%。加了出处校验和重写机制后幻觉率进一步降到4%左右。4%的幻觉率谈不上完美但已经能给业务一个“基本可信”的答案。剩下的4%是什么大多数是“检索到了相关段落但段落本身信息不完整”导致回答以偏概全。我们正在通过引入多轮追问和扩展资料来解决这是下一步的事情了。6. 常见问题与排查技巧实录6.1 检索老是不准先排查文档清洗和切分如果你发现系统的回答质量不稳定别急着调大模型参数先做几个排查项文档格式是否统一PDF、Word、PPT混合在一起的文档解析器兼容性问题会非常多。我的做法是统一转成文本或Markdown再做后续处理转不了的单独走人工清洗。文档是否有OCR扫描件有的PDF是图片格式直接读取是乱码必须先走OCR。这一步不做后面检索效果再好也没有用因为索引里都是乱码。切分长度是否合理太长或太短对检索影响都很大。你可以对同一个文档试几组不同的切分参数分别在评测集上跑一遍看Top1命中率变化。我记得有一次系统效果特别差排查了很久发现是一批新导入的PDF全是扫描件切块后存进去的全是乱码。后来加了OCR预处理问题直接消失。这种问题属于“数据进不来”再厉害的算法也救不回来。6.2 引用编号对不上检查模型的“标号洁癖”生成模型在引用编号这件事上偶尔会“自作聪明”。我遇到过几种情况回答中引用了[1][4]但给定资料只有[1][2][3]它编了个[4]出来。引用了[1]但内容表述更贴近[2]的含义。回答里压根没有引用编号变成了“自由创作”。这些问题的根源是Prompt约束不够强或者模型本身对指令遵循能力有限。我用的解决方案包括提高Few-shot示例中“正确引用”示例的数量。在生成参数里把温度调低到0.1左右减少随机性。最关键的绝对不要给模型“自由发挥”的空间Prompt里明确说“如果没有合适的引用不要回答该点”。如果多次重写仍然出问题我有时候干脆把答案切成多句话分别生成把“引用范围”收窄会更容易控制。6.3 文档更新后老答案还“阴魂不散”注意缓存与版本控制知识库不是一成不变的文档会更新。我踩过一个坑文档A在知识库里更新了内容但用户问问题检索出来的还是旧版本。原因是文档解析和向量化的缓存没打版本号旧向量覆盖了新向量导致检索结果混乱。解决方案是给文档加版本号更新文档时生成新的doc_id旧版本向量定期清理。查询时按版本过滤保证只用当前生效的资料。另外索引有缓存问题向量数据库的写入和删除不能想当然立即生效需要确认文档状态。6.4 成本与性能怎么在预算内维持体验整套系统的成本大头不在GPU而在向量化和重排序这两类模型推理。每个用户提问都要走一次向量化、一次重排序如果没有缓存机制高频问题会烧掉大量算力。我的优化手段问题级缓存相同或高度相似的问题直接返回缓存答案命中率接近30%。批量向量化文档导入时不逐条向量化而是批量提交给Embedding模型吞吐量翻倍。重排序模型量化把bge-reranker量化到int8精度损失很小但推理速度提升明显。如果你想控制成本优先考虑这三个方向。不要一上来就堆GPU很多时候是代码层面的浪费比算力不足更严重。7. 一套“开卷考试”系统的最终复盘与后续演进系统上线快三个月了说几个我感触最深的地方。“答案必须带出处”这个需求比我想象的更刚需。它不是某个领导拍脑门定出来的而是知识密集型业务的天然要求。回答错了可以改没有出处的“权威感”对用户决策影响太大了。技术上我认为最有价值的设计决策是两处第一是双路召回 重排序它保证了“找得准”第二是逐句校验 纠错式重写它保证了“敢负责”。这两点组合在一起才真正把幻觉压到了可接受的范围。至于Embedding用哪家、向量数据库用哪个反而不是最关键的变量只要选稳定开源、社区活跃的产品都不会出大岔子。另一个体会是RAG系统的调试周期比传统软件长不少因为它每一个环节都可能引入不确定性。你得习惯“改了一个变量要跑一轮评测集”的工作方式而不是“改完立刻就能看出效果”。这个节奏对团队管理也是一种挑战我一度被业务方追问“为什么调优这么慢”解释清楚评测逻辑之后才达成共识。后续我计划做两件事。一是给检索层引入知识图谱让系统能处理“A和B是什么关系”这类多跳关系型问题单靠向量检索在关系推理上还是太弱。二是增加答案分点的多轮追问机制用户可以对答案中的某一点继续追问系统可以精准定位到指定段落提供更深度的信息。这两个方向都是“开卷考试”的自然延伸等有新进展了再单独写一篇。最后分享一个小细节在出处展示上我后来给答案里的引用标号做了“悬浮卡片”效果鼠标一放上去就能看到引用来源的标题和页码。就这么一个小改动用户对系统答案的信任度明显上升。很多影响“可信感”的往往不是算法复杂度而是产品细节有没有做到位。做“带出处的系统”这件事最终目标不仅是技术上不瞎编还要让使用者真切感受到“这个答案是有据可查的”。 
