1. 先定位一次错误回答到底是检索的锅还是生成的锅我接手过不少RAG项目团队上来第一句话往往是换个更强的LLM是不是就好了。钱花了延迟上去了准确度没见涨。后来我把错误回答全摊开复盘发现绝大多数压根不是生成的问题而是检索环节根本没把真正有用的资料捞出来。这个认知偏差如果不纠正后面所有优化动作都会白做。1.1 复盘一个典型的RAG翻车案例我之前处理过一个客服知识库类的RAG应用知识库里放了产品手册、退换货政策、常见问题总共一千多份文档。用户问保修期是从发票日期开始算还是从收货日期开始算系统给出的回答引用了某款配件的安装说明答案自然是错的。把这次回答的完整链路拆开来看用户问题被向量化为768维的向量在向量库里按余弦相似度召回了top 10个文档块召回的10个块里有8个来自安装手册真正写保修政策的文档块排在第17位根本没进候选LLM只看到了8个不相关的安装说明块也只能硬着头皮编了一个听起来合理的答案。问题出在哪召回环节漏了。这跟模型智商没关系换GPT-5来喂它一份安装说明它照样答不对保修期。这类案例我见过太多所以我现在做RAG优化的第一件事永远是先把检索中间结果打出来看而不是急着调提示词。1.2 判断链路瓶颈的快速方法把中间结果摊开看很多人不知道RAG应用其实是可以半可视化排查的。我在本地跑了一套简易诊断脚本对任意一条用户问题输出三样东西检索到的前10个chunk各自的文本片段和相似度分数每个chunk来自哪份文档、哪个章节LLM基于这些chunk给出的最终回答。然后把这条问题的标准答案拿来对比基本就能判断瓶颈在哪。规则很简单如果chunk里面明明有正确答案的文本但LLM答错了那是提示词或生成环节的问题如果chunk里面压根没有答案相关的内容那是索引或检索环节的问题如果chunk有关键信息但被大量无关信息淹没LLM答得模棱两可那是上下文排列和截断策略的问题。我统计过三个不同项目的bad case第一种情况大概占15%第二种占65%第三种占20%。也就是说大部分准确度问题其实出在检索端。你如果连这个都没排查过直接去调prompt等于头痛医脚。1.3 我见过的优化资源错配准确度上不去最常见的资源错配有几个一是盲目换大模型。从7B模型换到70B推理成本涨了十几倍但如果检索回来的chunk本身就不对准确度几乎不会有变化。我实测过在检索质量差的场景下换模型提升幅度通常不到3个百分点。二是盲目堆文档。知识库越做越大向量检索的噪声就越来越多相似度分数整体被拉平真正相关的文档反而被淹没。这个现象叫向量空间拥挤我见过一个团队把知识库从500份文档加到5000份准确度反而掉了5个点。三是盲目调相似度阈值。很多人一看到答错就调低threshold想让系统更敢回答结果召回了一大堆似是而非的内容幻觉反而更多。正确的做法是先按上述方法定位再针对瓶颈做优化。下面几章按这个逻辑展开。2. 检索侧三板斧切分、召回、重排的实操细节2.1 文本切分chunk_size和overlap怎么定文本切分是RAG索引构建的第一步也是大多数人最不重视的一步。很多开箱即用的框架默认按固定长度切分比如把文档切成512个字符一块overlap设成128。这个配置在小规模demo里看不出问题一旦文档结构复杂漏召回的情况会集中爆发。我做过一组对比实验用的是某产品FAQ文档集分别测试了256/512/1024三种chunk_size配合0、64、128三种overlap在同一个评测集上测hit ratechunk_sizeoverlaphit rate说明256072.3%切得太碎语义被打断问题里的关键词分散在不同块2566474.1%稍有改善但整体仍偏低51212881.5%均衡多数场景够用102425679.8%块太大混合语义导致检索噪声上升语义切分按段落/标题—86.2%最优但需要文档自带结构信息结论并不复杂固定长度切分只是兜底方案优先按文档的自然结构切。Markdown的标题、PDF的章节、数据库里已有的段落边界这些都是免费的语义边界。很多文档本身就是按问题-答案组织的这类结构直接拆成一条一条的QA对检索效果立竿见影。overlap的作用是防止信息被切分线拦腰截断。比如保修期自发票日期起12个月这句话如果刚好被切成两块上半块没有12个月下半块没有保修期那无论用户用什么问法都很难同时召回这两块。overlap设太小等于没有设太大又会造成大量重复内容挤占向量空间。我在处理混合型文档既有长段落技术说明又有短条目政策条款时最终用的是按结构切分 兜底长度限制的组合方案有标题的按标题层级切没有标题的段落超过800字再按句号边界二次切分。这个策略在多个项目里都稳定优于纯固定窗口。2.2 向量与关键词混合召回单一向量肯定会漏向量检索的本质是把文本映射到高维空间按语义相似度做召回。它的优势是能处理同义不同形的查询比如用户说退货怎么弄文档里写的是退换货流程两者字面上不重叠但语义相近向量能兜住。但它有个明显的短板对专有名词、型号、编号这类精确信息非常不敏感。举个例子用户问SF-3000型号的滤芯多久换一次Embedding模型很容易把SF-3000当成普通token模糊处理导致召回的chunk里混入大量其他型号的内容。这种场景下BM25这种基于关键词匹配的算法反而更精准。所以我在生产环境里几乎从来不用纯向量检索而是做混合召回BM25负责精确匹配型号、编号、人名、地名、法规条款号这类硬信息向量检索负责语义匹配同义改写、口语化表达、跨段落语义关联两路结果合并做分数归一化后统一进入重排环节。具体操作上如果用Elasticsearch或OpenSearch可以直接用它们的hybrid查询把BM25分和向量分做weighted sum。如果用的是FAISS或Milvus这类纯向量库就需要自己维护一个倒排索引或者引入单独的BM25服务。对于中小型项目我的建议是直接上Elasticsearch它本身带稠密向量插件混合查询的工程成本最低。合并分数的权重也需要调。我在冷启动阶段通常给BM25和向量各50%的权重然后用评测集跑一轮看看bad case更偏向哪种召回方式再往对应方向加权重一般调整区间在30%到70%之间。2.3 重排环节top20到top5的准确率跃升重排Rerank是我在所有RAG优化手段里性价比最高的一步没有之一。它解决的是候选集有点靠谱但不够精准的问题。初筛阶段为了不漏我们通常召回top 20甚至top 50个chunk。但这批chunk里有相当一部分是沾边但不完全相关的。如果直接把20个chunk全塞给LLM模型会被无关信息干扰同时浪费上下文窗口。重排的作用就是把候选中真正有用的那几条排到最前面。我常用的做法是向量BM25混合召回top 20然后用一个Cross-Encoder重排模型比如bge-reranker-base或Cohere的rerank接口逐条计算用户问题-文档块的相关性分数取top 5作为最终上下文。用Cross-Encoder的原因很简单它能同时看到问题和文档块的完整文本像裁判一样两边对照而初筛阶段的Bi-Encoder只能把两边各自编码成向量再比距离精度天然受限。还是用上面说的那个客服场景做测试只做向量召回top 5时hit rate是74.3%混合召回top 20后重排取top 5hit rate是88.6%。14个百分点的提升只是加了一个重排模型其他什么都不用动。重排模型的缺点也有就是慢。Cross-Encoder要对20个候选逐条推理一次20条还好如果是100条单次查询延迟可能增加200到400毫秒。所以我的策略是宽召回、窄重排、小上下文召回可以宽重排候选控制在20到30条重排后只保留5到8条进上下文。3. 生成侧陷阱提示词、上下文与引用约束3.1 提示词模板越长越好恰恰相反我第一次写RAG提示词时也犯过模板越长越严谨的毛病写了两百多字设定角色、分步骤要求、强调不要编造、要求语气专业……结果模型回答得啰嗦且频繁拒答。后来做消融实验才发现真正的关键指令就那三板斧。LLM处理指令时存在注意力稀释尤其当指令里塞满了抽象要求模型反而不知道哪些是硬约束、哪些是可以灵活发挥的。我的经验是提示词按功能区隔开结构如下你是一个问答助手。只能使用“参考资料”中的内容回答问题。 如果参考资料中没有足够信息直接回答“资料不足”不要编造。 回答时在每句话末尾用[序号]标注信息来源。 参考资料 {context} 用户问题 {question}注意几个细节只能使用参考资料回答和资料不足时明确说不知道是必须有的硬约束这两句能显著压住幻觉要求标注信息来源这是可验证性的关键后面我会细说不要把语气热情像专家一样这种要求写进去它们除了拉高Token消耗和让回答变啰嗦之外没任何用。如果想让回答更贴合场景比如客服场景要求简洁直接加一句用不超过100字回答先给结论再给依据效果比描述性指令好得多。3.2 上下文塞满top_k个block模型反而看不清我在前面提到重排后保留5到8个chunk这不是拍脑袋定的。有段时间为了不遗漏信息把top_k调到10以上结果准确率明显下降。后来查论文和做实验才理解背后的机制Transformer模型的长文本注意力是稀疏的塞进去的内容越多模型越难把注意力集中在真正关键的那几行。尤其在chunk里大量内容跟问题无关的情况下模型会被无关信息带偏。我做了一个简单的对比实验同一批测试问题只改动送入LLM的chunk数量其他不变送入chunk数上下文Token量回答正确率3约150085.1%5约250088.4%8约400087.2%12约600081.3%20约1000073.8%注意这里的正确率并不是单调上升的。超过8个chunk后更多的信息变成了噪声回答正确率反而一路下滑。Token太多还有另一个隐形代价LLM的响应时间随输入长度增长用户侧的体感延迟会明显增加。所以我的经验是重排后取top 5作为基准如果某个问题的答案确实分散在多个文档里可以放宽到8个但绝不要无脑把整个候选集灌进上下文。3.3 强制引用与拒答机制把幻觉逼回去标注来源这一步看着简单实操中特别容易被忽视。我早期做RAG时模型答得挺流畅但用户反馈答案看着对就是不敢直接用因为没人知道这个结论是模型编的还是从文档里来的。后来我在提示词里要求模型必须用[序号]标注每句话对应的来源chunk并且增加了一条硬约束如果某个结论在参考资料中找不到对应出处不许写进回答。这两条加进去之后幻觉率下降非常明显。再进一步我还会做答案回溯校验模型回答里的关键断言去对应的chunk里做关键词/深度文本匹配匹配不上就标注无法验证。这个校验逻辑可以在代码里实现不用靠LLM自查。伪代码大概是def verify_answer(answer, chunks): for sentence in split_sentences(answer): # 找到该句标注的来源序号 source_idx extract_citation(sentence) source_chunk chunks[source_idx] # 用关键词重叠或向量相似度判断是否真能支撑 if not is_supported(sentence, source_chunk): flag_unverifiable(sentence)有了这套机制模型的回答就从一个漂亮但无法追溯的段落变成了每条都有据可查的结论集合。用户拿到回答后可以点开引用直接看原文这个信任价值比单纯地提升一个百分点的准确率更有意义。4. 从传统RAG到结构化和Agentic RAG的升级路线4.1 知识割裂多文档场景下向量检索的结构性天花板前面聊的都是单轮检索优化的内容但实际业务里有一类问题是纯靠优化检索解决不了的答案需要跨多条文档、多个片段拼装出来。我把这类问题叫知识割裂问题。举个例子你问我们公司对质量问题导致的退货有什么政策知识库里可能有三个文档一个投诉处理流程一个质量检验标准一个退换货政策。三个文档从不同角度描述了这件事但没有任何一个chunk能单独回答完整问题。传统向量检索的召回逻辑是把问题映射到向量空间找最相似的chunk它擅长找包含答案的一段话但不擅长找拼接出答案的几段话。这类问题的占比取决于你的知识库形态。纯FAQ型的知识库里很少见但如果是产品手册、规章制度、研究报告这类长文为主的知识库这类问题可能占到三成以上。我在评测集里加了这类复杂问题之后传统RAG的准确率图景才真正暴露出来。4.2 GraphRAG和本体RAG给知识加上关系和约束解决知识割裂比较成熟的思路是给文档构建一层结构化的知识表示。GraphRAG是这条路线上目前讨论度最高的方案它的核心动作是先从文档里抽取实体如产品、条款、部门、流程节点和关系如产品A适用条款B、流程C由部门D负责把文本知识转成语义网络。回答问题时先在图里找到相关实体顺着关系扩展出上下文子图再把子图对应的原始文本喂给LLM。我在这类场景里实测过GraphRAG对跨文档推理类问题的准确度提升幅度通常在15到25个百分点代价是索引构建成本明显上升需要跑一次全量文档的实体抽取文档量大的话光抽实体就要消耗不少算力和时间。本体RAGOntology RAG是另一个思路它比GraphRAG更强调约束在构建图谱之前先定义一套本体Schema规定有哪些实体类型、哪些关系类型、实体属性有哪些。相当于在抽实体之前先给知识建模。这个方案对领域内逻辑一致性的提升帮助很大但要求领域专家深度参与本体设计门槛比较高。对大多数团队来说我建议先跑通GraphRAG等遇到逻辑冲突或关系混乱的问题时再考虑引入本体层约束。4.3 Agentic RAG拆解提问、按需调用的多步推理GraphRAG解决的是知识有结构但检索是单轮的问题。另一条路线则是让检索本身变成多步推理这就是Agentic RAG。传统RAG是问题进、上下文出一次搞定Agentic RAG是把找资料这件事交给Agent来规划先判断这个问题需要哪些信息拆成子问题再为每个子问题选择不同的检索方式向量库、图谱查询、SQL、Web搜索拿到结果后综合推理。说人话就是传统RAG像一个只会查一本书的图书管理员Agentic RAG是看到一个复杂提问会先列清单、再去好几个书架翻书、最后汇总做笔记的研究助理。我做一个实操层面的判断如果你的问题大多是直接问某件事是什么优先把传统RAG优化到极致如果评测集里明显有一批需要多步推理才能回答的问题比如对比A和B两个产品的售后政策差异并结合我们的投诉记录给建议才值得引入Agentic RAG。引入的时候也不用一步到位可以先做一个轻量版本问题分类器判断是否是复杂问题是则走多步检索流程否则走原来的快速通道。这套方案我在实际项目里落地过复杂问题的回答质量明显提升同时简单问题的延迟没有变大。顺带提一句如果团队用的是LangChain4j或Spring AI这类Java生态框架现在都有现成的RAG模块。它们内置了文档解析、切分、向量入库这些基础流程用来快速搭一个RAG demo非常省事。但它们默认给的参数往往是最保守的配置要拿到好的准确度还是得按我前面说的切分、重排、评测这套流程自己调一遍。5. 用评测集驱动优化命中率、忠实度与迭代节奏5.1 评测集怎么建才不自欺欺人所有优化动作最后都要落到可量化的提升上。如果你们团队的RAG应用连一个固定的评测集都没有那后面的优化基本就是在赌运气。我见过不少团队优化半天问效果变好了吗答感觉好多了这种感觉往往靠不住。评测集的建设原则很简单但要做到位并不容易从真实用户日志里收集问题而不是自己编问题。自己编的问题往往和自己的知识库风格一致测不出真实短板覆盖三种难度单文档单块能回答的简单问题、需要从多个chunk里拼信息的中间问题、需要多步推理或跨文档关联的复杂问题比例大概在5:3:2每个问题配一个标准答案并标注答案出自哪份文档或哪些文档的哪些片段。这个标注过程比较耗时但它是后面计算指标的基础。数量上50到100条问题是一个能启动迭代的下限200条以上可以支撑比较可靠的回归测试。不用追求一开始就建几百条先建一个50条的小集合后续每周从用户反馈里补充新的bad case进去慢慢扩大。5.2 准确度指标怎么解读hit rate与忠实度评测集建好之后需要几个指标来衡量优化效果。我日常最看重的有四个指标计算方式关注点Hit Rate标准答案对应的chunk是否出现在最终送入LLM的上下文里检索环节是否捞到了关键信息MRR标准答案chunk在候选列表中的位置倒数取均值关键chunk排名是否靠前FaithfulnessLLM回答中的断言能否在给定chunk中找到支撑生成环节是否忠于资料Answer Correctness回答与标准答案的语义一致性打分用户侧最终体验Hit Rate和价值最大的一个指标因为它衡量的是系统到底有没有把正确答案送进去。如果Hit Rate已经95%了回答还错那问题在生成侧如果Hit Rate只有70%那你优化生成侧是白费功夫。MRR则进一步告诉你正确答案排在第3和第排在倒数第2虽然都在上下文里但模型关注到的概率差别很大。所以MRR低的时候优先考虑引入重排模型。Faithfulness是衡量幻觉的关键指标。我见过一种情况Hit Rate不错但LLM在组织答案时绕过了chunk里的原话自己重新措辞结果把意思讲偏了。Faithfulness能把这类问题暴露出来。5.3 迭代节奏一次只动一个变量这个原则我吃了不少亏才总结出来的。早期优化RAG我经常一次性改好几个东西把切分规则换了、embedding模型换了、又加了重排模型。结果准确度确实提升了但根本说不清是哪一步贡献的出了新bad case也追不到根因。后来我改成严格的单变量实验流程冻结当前版本在评测集上记录基线指标每次只改一个变量比如从固定512切分改成语义切分其他所有配置不变重跑评测集对比指标变化决定保留还是回滚一个变量稳定后再进入下一个变量的实验。我按这个流程跑过一轮典型的优化从基线到最终上线效果是这样的版本改动内容Hit Rate回答正确率v1固定512切分纯向量top574.3%70.2%v2改为按标题结构切分长度兜底79.1%75.4%v3加BM25混合召回top20后重排取top588.6%83.7%v4提示词加引用约束与拒答机制88.6%87.3%v5上下文压缩按相关性过滤掉后置低分chunk89.2%88.9%每一轮改动都不大但每轮都能明确归因。最终上线版本比最初的基线回答正确率提高了将近19个百分点而每一步的成本都不高。这比憋一个大招整体重构要靠谱得多。最后说一句我做了这么多RAG项目的体会优化RAG的准确度本质上是优化一套资料分发系统——先确保最相关的资料被准确捞出来、排在最前、没有被噪音干扰然后再让LLM当那个照着资料念答案的翻译官。把所有力气花在让检索侧更精准永远比逼LLM凭空变出答案更值得。
1. 先定位一次错误回答到底是检索的锅还是生成的锅我接手过不少RAG项目团队上来第一句话往往是换个更强的LLM是不是就好了。钱花了延迟上去了准确度没见涨。后来我把错误回答全摊开复盘发现绝大多数压根不是生成的问题而是检索环节根本没把真正有用的资料捞出来。这个认知偏差如果不纠正后面所有优化动作都会白做。1.1 复盘一个典型的RAG翻车案例我之前处理过一个客服知识库类的RAG应用知识库里放了产品手册、退换货政策、常见问题总共一千多份文档。用户问保修期是从发票日期开始算还是从收货日期开始算系统给出的回答引用了某款配件的安装说明答案自然是错的。把这次回答的完整链路拆开来看用户问题被向量化为768维的向量在向量库里按余弦相似度召回了top 10个文档块召回的10个块里有8个来自安装手册真正写保修政策的文档块排在第17位根本没进候选LLM只看到了8个不相关的安装说明块也只能硬着头皮编了一个听起来合理的答案。问题出在哪召回环节漏了。这跟模型智商没关系换GPT-5来喂它一份安装说明它照样答不对保修期。这类案例我见过太多所以我现在做RAG优化的第一件事永远是先把检索中间结果打出来看而不是急着调提示词。1.2 判断链路瓶颈的快速方法把中间结果摊开看很多人不知道RAG应用其实是可以半可视化排查的。我在本地跑了一套简易诊断脚本对任意一条用户问题输出三样东西检索到的前10个chunk各自的文本片段和相似度分数每个chunk来自哪份文档、哪个章节LLM基于这些chunk给出的最终回答。然后把这条问题的标准答案拿来对比基本就能判断瓶颈在哪。规则很简单如果chunk里面明明有正确答案的文本但LLM答错了那是提示词或生成环节的问题如果chunk里面压根没有答案相关的内容那是索引或检索环节的问题如果chunk有关键信息但被大量无关信息淹没LLM答得模棱两可那是上下文排列和截断策略的问题。我统计过三个不同项目的bad case第一种情况大概占15%第二种占65%第三种占20%。也就是说大部分准确度问题其实出在检索端。你如果连这个都没排查过直接去调prompt等于头痛医脚。1.3 我见过的优化资源错配准确度上不去最常见的资源错配有几个一是盲目换大模型。从7B模型换到70B推理成本涨了十几倍但如果检索回来的chunk本身就不对准确度几乎不会有变化。我实测过在检索质量差的场景下换模型提升幅度通常不到3个百分点。二是盲目堆文档。知识库越做越大向量检索的噪声就越来越多相似度分数整体被拉平真正相关的文档反而被淹没。这个现象叫向量空间拥挤我见过一个团队把知识库从500份文档加到5000份准确度反而掉了5个点。三是盲目调相似度阈值。很多人一看到答错就调低threshold想让系统更敢回答结果召回了一大堆似是而非的内容幻觉反而更多。正确的做法是先按上述方法定位再针对瓶颈做优化。下面几章按这个逻辑展开。2. 检索侧三板斧切分、召回、重排的实操细节2.1 文本切分chunk_size和overlap怎么定文本切分是RAG索引构建的第一步也是大多数人最不重视的一步。很多开箱即用的框架默认按固定长度切分比如把文档切成512个字符一块overlap设成128。这个配置在小规模demo里看不出问题一旦文档结构复杂漏召回的情况会集中爆发。我做过一组对比实验用的是某产品FAQ文档集分别测试了256/512/1024三种chunk_size配合0、64、128三种overlap在同一个评测集上测hit ratechunk_sizeoverlaphit rate说明256072.3%切得太碎语义被打断问题里的关键词分散在不同块2566474.1%稍有改善但整体仍偏低51212881.5%均衡多数场景够用102425679.8%块太大混合语义导致检索噪声上升语义切分按段落/标题—86.2%最优但需要文档自带结构信息结论并不复杂固定长度切分只是兜底方案优先按文档的自然结构切。Markdown的标题、PDF的章节、数据库里已有的段落边界这些都是免费的语义边界。很多文档本身就是按问题-答案组织的这类结构直接拆成一条一条的QA对检索效果立竿见影。overlap的作用是防止信息被切分线拦腰截断。比如保修期自发票日期起12个月这句话如果刚好被切成两块上半块没有12个月下半块没有保修期那无论用户用什么问法都很难同时召回这两块。overlap设太小等于没有设太大又会造成大量重复内容挤占向量空间。我在处理混合型文档既有长段落技术说明又有短条目政策条款时最终用的是按结构切分 兜底长度限制的组合方案有标题的按标题层级切没有标题的段落超过800字再按句号边界二次切分。这个策略在多个项目里都稳定优于纯固定窗口。2.2 向量与关键词混合召回单一向量肯定会漏向量检索的本质是把文本映射到高维空间按语义相似度做召回。它的优势是能处理同义不同形的查询比如用户说退货怎么弄文档里写的是退换货流程两者字面上不重叠但语义相近向量能兜住。但它有个明显的短板对专有名词、型号、编号这类精确信息非常不敏感。举个例子用户问SF-3000型号的滤芯多久换一次Embedding模型很容易把SF-3000当成普通token模糊处理导致召回的chunk里混入大量其他型号的内容。这种场景下BM25这种基于关键词匹配的算法反而更精准。所以我在生产环境里几乎从来不用纯向量检索而是做混合召回BM25负责精确匹配型号、编号、人名、地名、法规条款号这类硬信息向量检索负责语义匹配同义改写、口语化表达、跨段落语义关联两路结果合并做分数归一化后统一进入重排环节。具体操作上如果用Elasticsearch或OpenSearch可以直接用它们的hybrid查询把BM25分和向量分做weighted sum。如果用的是FAISS或Milvus这类纯向量库就需要自己维护一个倒排索引或者引入单独的BM25服务。对于中小型项目我的建议是直接上Elasticsearch它本身带稠密向量插件混合查询的工程成本最低。合并分数的权重也需要调。我在冷启动阶段通常给BM25和向量各50%的权重然后用评测集跑一轮看看bad case更偏向哪种召回方式再往对应方向加权重一般调整区间在30%到70%之间。2.3 重排环节top20到top5的准确率跃升重排Rerank是我在所有RAG优化手段里性价比最高的一步没有之一。它解决的是候选集有点靠谱但不够精准的问题。初筛阶段为了不漏我们通常召回top 20甚至top 50个chunk。但这批chunk里有相当一部分是沾边但不完全相关的。如果直接把20个chunk全塞给LLM模型会被无关信息干扰同时浪费上下文窗口。重排的作用就是把候选中真正有用的那几条排到最前面。我常用的做法是向量BM25混合召回top 20然后用一个Cross-Encoder重排模型比如bge-reranker-base或Cohere的rerank接口逐条计算用户问题-文档块的相关性分数取top 5作为最终上下文。用Cross-Encoder的原因很简单它能同时看到问题和文档块的完整文本像裁判一样两边对照而初筛阶段的Bi-Encoder只能把两边各自编码成向量再比距离精度天然受限。还是用上面说的那个客服场景做测试只做向量召回top 5时hit rate是74.3%混合召回top 20后重排取top 5hit rate是88.6%。14个百分点的提升只是加了一个重排模型其他什么都不用动。重排模型的缺点也有就是慢。Cross-Encoder要对20个候选逐条推理一次20条还好如果是100条单次查询延迟可能增加200到400毫秒。所以我的策略是宽召回、窄重排、小上下文召回可以宽重排候选控制在20到30条重排后只保留5到8条进上下文。3. 生成侧陷阱提示词、上下文与引用约束3.1 提示词模板越长越好恰恰相反我第一次写RAG提示词时也犯过模板越长越严谨的毛病写了两百多字设定角色、分步骤要求、强调不要编造、要求语气专业……结果模型回答得啰嗦且频繁拒答。后来做消融实验才发现真正的关键指令就那三板斧。LLM处理指令时存在注意力稀释尤其当指令里塞满了抽象要求模型反而不知道哪些是硬约束、哪些是可以灵活发挥的。我的经验是提示词按功能区隔开结构如下你是一个问答助手。只能使用“参考资料”中的内容回答问题。 如果参考资料中没有足够信息直接回答“资料不足”不要编造。 回答时在每句话末尾用[序号]标注信息来源。 参考资料 {context} 用户问题 {question}注意几个细节只能使用参考资料回答和资料不足时明确说不知道是必须有的硬约束这两句能显著压住幻觉要求标注信息来源这是可验证性的关键后面我会细说不要把语气热情像专家一样这种要求写进去它们除了拉高Token消耗和让回答变啰嗦之外没任何用。如果想让回答更贴合场景比如客服场景要求简洁直接加一句用不超过100字回答先给结论再给依据效果比描述性指令好得多。3.2 上下文塞满top_k个block模型反而看不清我在前面提到重排后保留5到8个chunk这不是拍脑袋定的。有段时间为了不遗漏信息把top_k调到10以上结果准确率明显下降。后来查论文和做实验才理解背后的机制Transformer模型的长文本注意力是稀疏的塞进去的内容越多模型越难把注意力集中在真正关键的那几行。尤其在chunk里大量内容跟问题无关的情况下模型会被无关信息带偏。我做了一个简单的对比实验同一批测试问题只改动送入LLM的chunk数量其他不变送入chunk数上下文Token量回答正确率3约150085.1%5约250088.4%8约400087.2%12约600081.3%20约1000073.8%注意这里的正确率并不是单调上升的。超过8个chunk后更多的信息变成了噪声回答正确率反而一路下滑。Token太多还有另一个隐形代价LLM的响应时间随输入长度增长用户侧的体感延迟会明显增加。所以我的经验是重排后取top 5作为基准如果某个问题的答案确实分散在多个文档里可以放宽到8个但绝不要无脑把整个候选集灌进上下文。3.3 强制引用与拒答机制把幻觉逼回去标注来源这一步看着简单实操中特别容易被忽视。我早期做RAG时模型答得挺流畅但用户反馈答案看着对就是不敢直接用因为没人知道这个结论是模型编的还是从文档里来的。后来我在提示词里要求模型必须用[序号]标注每句话对应的来源chunk并且增加了一条硬约束如果某个结论在参考资料中找不到对应出处不许写进回答。这两条加进去之后幻觉率下降非常明显。再进一步我还会做答案回溯校验模型回答里的关键断言去对应的chunk里做关键词/深度文本匹配匹配不上就标注无法验证。这个校验逻辑可以在代码里实现不用靠LLM自查。伪代码大概是def verify_answer(answer, chunks): for sentence in split_sentences(answer): # 找到该句标注的来源序号 source_idx extract_citation(sentence) source_chunk chunks[source_idx] # 用关键词重叠或向量相似度判断是否真能支撑 if not is_supported(sentence, source_chunk): flag_unverifiable(sentence)有了这套机制模型的回答就从一个漂亮但无法追溯的段落变成了每条都有据可查的结论集合。用户拿到回答后可以点开引用直接看原文这个信任价值比单纯地提升一个百分点的准确率更有意义。4. 从传统RAG到结构化和Agentic RAG的升级路线4.1 知识割裂多文档场景下向量检索的结构性天花板前面聊的都是单轮检索优化的内容但实际业务里有一类问题是纯靠优化检索解决不了的答案需要跨多条文档、多个片段拼装出来。我把这类问题叫知识割裂问题。举个例子你问我们公司对质量问题导致的退货有什么政策知识库里可能有三个文档一个投诉处理流程一个质量检验标准一个退换货政策。三个文档从不同角度描述了这件事但没有任何一个chunk能单独回答完整问题。传统向量检索的召回逻辑是把问题映射到向量空间找最相似的chunk它擅长找包含答案的一段话但不擅长找拼接出答案的几段话。这类问题的占比取决于你的知识库形态。纯FAQ型的知识库里很少见但如果是产品手册、规章制度、研究报告这类长文为主的知识库这类问题可能占到三成以上。我在评测集里加了这类复杂问题之后传统RAG的准确率图景才真正暴露出来。4.2 GraphRAG和本体RAG给知识加上关系和约束解决知识割裂比较成熟的思路是给文档构建一层结构化的知识表示。GraphRAG是这条路线上目前讨论度最高的方案它的核心动作是先从文档里抽取实体如产品、条款、部门、流程节点和关系如产品A适用条款B、流程C由部门D负责把文本知识转成语义网络。回答问题时先在图里找到相关实体顺着关系扩展出上下文子图再把子图对应的原始文本喂给LLM。我在这类场景里实测过GraphRAG对跨文档推理类问题的准确度提升幅度通常在15到25个百分点代价是索引构建成本明显上升需要跑一次全量文档的实体抽取文档量大的话光抽实体就要消耗不少算力和时间。本体RAGOntology RAG是另一个思路它比GraphRAG更强调约束在构建图谱之前先定义一套本体Schema规定有哪些实体类型、哪些关系类型、实体属性有哪些。相当于在抽实体之前先给知识建模。这个方案对领域内逻辑一致性的提升帮助很大但要求领域专家深度参与本体设计门槛比较高。对大多数团队来说我建议先跑通GraphRAG等遇到逻辑冲突或关系混乱的问题时再考虑引入本体层约束。4.3 Agentic RAG拆解提问、按需调用的多步推理GraphRAG解决的是知识有结构但检索是单轮的问题。另一条路线则是让检索本身变成多步推理这就是Agentic RAG。传统RAG是问题进、上下文出一次搞定Agentic RAG是把找资料这件事交给Agent来规划先判断这个问题需要哪些信息拆成子问题再为每个子问题选择不同的检索方式向量库、图谱查询、SQL、Web搜索拿到结果后综合推理。说人话就是传统RAG像一个只会查一本书的图书管理员Agentic RAG是看到一个复杂提问会先列清单、再去好几个书架翻书、最后汇总做笔记的研究助理。我做一个实操层面的判断如果你的问题大多是直接问某件事是什么优先把传统RAG优化到极致如果评测集里明显有一批需要多步推理才能回答的问题比如对比A和B两个产品的售后政策差异并结合我们的投诉记录给建议才值得引入Agentic RAG。引入的时候也不用一步到位可以先做一个轻量版本问题分类器判断是否是复杂问题是则走多步检索流程否则走原来的快速通道。这套方案我在实际项目里落地过复杂问题的回答质量明显提升同时简单问题的延迟没有变大。顺带提一句如果团队用的是LangChain4j或Spring AI这类Java生态框架现在都有现成的RAG模块。它们内置了文档解析、切分、向量入库这些基础流程用来快速搭一个RAG demo非常省事。但它们默认给的参数往往是最保守的配置要拿到好的准确度还是得按我前面说的切分、重排、评测这套流程自己调一遍。5. 用评测集驱动优化命中率、忠实度与迭代节奏5.1 评测集怎么建才不自欺欺人所有优化动作最后都要落到可量化的提升上。如果你们团队的RAG应用连一个固定的评测集都没有那后面的优化基本就是在赌运气。我见过不少团队优化半天问效果变好了吗答感觉好多了这种感觉往往靠不住。评测集的建设原则很简单但要做到位并不容易从真实用户日志里收集问题而不是自己编问题。自己编的问题往往和自己的知识库风格一致测不出真实短板覆盖三种难度单文档单块能回答的简单问题、需要从多个chunk里拼信息的中间问题、需要多步推理或跨文档关联的复杂问题比例大概在5:3:2每个问题配一个标准答案并标注答案出自哪份文档或哪些文档的哪些片段。这个标注过程比较耗时但它是后面计算指标的基础。数量上50到100条问题是一个能启动迭代的下限200条以上可以支撑比较可靠的回归测试。不用追求一开始就建几百条先建一个50条的小集合后续每周从用户反馈里补充新的bad case进去慢慢扩大。5.2 准确度指标怎么解读hit rate与忠实度评测集建好之后需要几个指标来衡量优化效果。我日常最看重的有四个指标计算方式关注点Hit Rate标准答案对应的chunk是否出现在最终送入LLM的上下文里检索环节是否捞到了关键信息MRR标准答案chunk在候选列表中的位置倒数取均值关键chunk排名是否靠前FaithfulnessLLM回答中的断言能否在给定chunk中找到支撑生成环节是否忠于资料Answer Correctness回答与标准答案的语义一致性打分用户侧最终体验Hit Rate和价值最大的一个指标因为它衡量的是系统到底有没有把正确答案送进去。如果Hit Rate已经95%了回答还错那问题在生成侧如果Hit Rate只有70%那你优化生成侧是白费功夫。MRR则进一步告诉你正确答案排在第3和第排在倒数第2虽然都在上下文里但模型关注到的概率差别很大。所以MRR低的时候优先考虑引入重排模型。Faithfulness是衡量幻觉的关键指标。我见过一种情况Hit Rate不错但LLM在组织答案时绕过了chunk里的原话自己重新措辞结果把意思讲偏了。Faithfulness能把这类问题暴露出来。5.3 迭代节奏一次只动一个变量这个原则我吃了不少亏才总结出来的。早期优化RAG我经常一次性改好几个东西把切分规则换了、embedding模型换了、又加了重排模型。结果准确度确实提升了但根本说不清是哪一步贡献的出了新bad case也追不到根因。后来我改成严格的单变量实验流程冻结当前版本在评测集上记录基线指标每次只改一个变量比如从固定512切分改成语义切分其他所有配置不变重跑评测集对比指标变化决定保留还是回滚一个变量稳定后再进入下一个变量的实验。我按这个流程跑过一轮典型的优化从基线到最终上线效果是这样的版本改动内容Hit Rate回答正确率v1固定512切分纯向量top574.3%70.2%v2改为按标题结构切分长度兜底79.1%75.4%v3加BM25混合召回top20后重排取top588.6%83.7%v4提示词加引用约束与拒答机制88.6%87.3%v5上下文压缩按相关性过滤掉后置低分chunk89.2%88.9%每一轮改动都不大但每轮都能明确归因。最终上线版本比最初的基线回答正确率提高了将近19个百分点而每一步的成本都不高。这比憋一个大招整体重构要靠谱得多。最后说一句我做了这么多RAG项目的体会优化RAG的准确度本质上是优化一套资料分发系统——先确保最相关的资料被准确捞出来、排在最前、没有被噪音干扰然后再让LLM当那个照着资料念答案的翻译官。把所有力气花在让检索侧更精准永远比逼LLM凭空变出答案更值得。
