1. RAG 问答准确度为什么总卡在“最后一公里”做过 RAG 应用的人大概率都经历过这个阶段Demo 跑起来很惊艳文档一多、问题一刁钻回答就开始胡编乱造。用户问“这个专利的申请日是哪天”模型给你编一个日期用户问“对比 A 和 B 两种方案的优劣”模型只答了 AB 完全没提。表面看是“大模型不行”实际上十有八九问题出在检索环节而不是生成环节。RAG 的全称是 Retrieval-Augmented Generation检索增强生成。它的核心逻辑很朴素用户提问 → 从知识库里找出相关片段 → 把片段塞进提示词 → 让大模型基于片段作答。这个链条里检索决定了模型能看到什么生成只决定它怎么组织语言。如果检索回来的内容本身就是错的、缺的、碎的再强的模型也救不回来。这就是业内常说的“garbage in, garbage out”。我自己的经验是一个 RAG 应用从“能用”到“好用”准确度提升的收益分布大致是这样的检索策略优化贡献 60%文档预处理贡献 25%提示词与生成控制贡献 15%。很多人一上来就折腾提示词工程、换更大的模型结果收效甚微就是因为把力气用错了地方。这篇内容就是把我踩过的坑和验证过的优化路径完整梳理一遍从检索、切分、向量化、重排到生成控制每一步都给出可复现的操作和参数依据。适合已经跑通过基础 RAG 流程、但被准确度问题困扰的开发者也适合正准备选型向量数据库和检索框架的技术负责人。2. 先搞清楚准确度到底丢在哪一环2.1 把 RAG 拆成可度量的四段流水线优化之前必须先能定位问题。我习惯把 RAG 拆成四段文档解析与切分、向量化与索引、检索与重排、生成与引用。每一段都有对应的度量指标不能凭感觉说“效果不好”。文档解析与切分看切分后的 chunk 是否语义完整有没有把一句话从中间劈开有没有把表格拆得七零八落。向量化与索引看召回率也就是正确答案所在的 chunk 有没有被检索出来。检索与重排看命中率hit rate和 MRR平均倒数排名即正确 chunk 排在第几位。生成与引用看答案是否忠实于检索内容有没有编造引用是否准确。我一般会先构造一个 50 到 100 条的小型评测集每条包含问题、标准答案、答案所在的文档 ID。然后逐段跑指标哪一段掉得厉害就重点优化哪一段。没有评测集的优化都是盲人摸象今天调一个参数感觉好了明天换个问题又崩了根本不知道是进步还是退步。2.2 用 hit rate 和 MRR 定位检索瓶颈hit rate是最直观的指标在 Top-K 检索结果里包含正确答案的比例。比如 K5100 个问题里有 80 个的正确答案出现在前 5 条里hit rate 就是 80%。MRR则更精细它看正确答案排在第几位排第一得 1 分排第二得 0.5 分排第三得 0.33 分最后取平均。我实测下来很多 RAG 应用的 hit rate 在 Top-20 时能到 90%但 Top-5 只有 60% 左右。这意味着正确答案其实被检索到了只是排名太靠后被前面一堆不相关的 chunk 挤掉了。这种情况下问题不在向量化而在重排rerank。加一个重排模型把 Top-20 重新排序取 Top-5hit rate 往往能直接拉到 85% 以上。这个诊断过程非常关键它决定了你是该换 embedding 模型还是该加重排还是该改切分策略。2.3 一个真实的准确度归因案例举个我实际遇到的例子。一个做专利检索问答的系统用户问“某专利的独立权利要求有几项”模型经常答错。我先跑评测集发现 hit rate 在 Top-10 时只有 55%。进一步看检索结果发现专利文档里的“权利要求书”部分被切成了很多小块而“独立权利要求”这个关键信息分散在多个 chunk 里单个 chunk 都不完整。问题定位在切分策略。原来的切分是按固定 512 token 硬切没有考虑文档结构。改成按章节标题切分把“权利要求书”整段作为一个 chunkhit rate 直接升到 82%。这个案例说明切分策略对检索质量的影响往往比换 embedding 模型还大。很多人忽略了这一点一上来就换模型其实是在错误的层面上使劲。3. 文档切分决定检索质量的地基3.1 固定长度切分的三个致命缺陷固定长度切分是最省事的做法按 token 数或字符数一刀切。但它有三个致命缺陷。第一语义断裂一句话或一个论点被从中间切开前半段在 chunk A后半段在 chunk B检索时只召回一半模型自然答不全。第二上下文丢失chunk 脱离了原来的章节语境单独看可能产生歧义。第三表格和列表被破坏结构化信息被切碎后基本失去价值。我见过最离谱的情况是一个表格的标题行在 chunk 1数据行在 chunk 2模型检索到数据行却不知道每列代表什么回答时把“申请日”当成“公开日”。这种错误不是模型笨是切分把信息结构破坏了。3.2 按语义和结构切分的实操方法我的做法是结构优先、语义兜底。先按文档的自然结构切Markdown 按标题层级切PDF 按章节和段落切HTML 按 DOM 结构切。每个章节作为一个父块如果父块太大再按句子边界切成子块但保留父块的标题作为上下文前缀。具体操作上我会给每个 chunk 加上元数据头比如“文档标题 章节标题 小节标题”然后把这个头拼在 chunk 正文前面一起做向量化。这样即使子块脱离了原文检索时也能通过标题信息匹配到相关查询。实测这个简单的改动能让 hit rate 提升 10 到 15 个百分点。对于表格我单独处理把表格转成 Markdown 格式保留表头整表作为一个 chunk不切分。如果表格特别大按行分组但每组都重复表头。这个细节很琐碎但对专利、财报、技术文档这类表格密集的场景效果立竿见影。3.3 chunk 大小与重叠度的参数选择chunk 大小没有万能值但有几个经验区间。中文场景下300 到 500 字是比较稳的区间。太小语义不完整太大检索精度下降因为一个 chunk 里混了多个主题向量表示被稀释。重叠度overlap我一般设成 chunk 大小的 10% 到 20%。重叠的作用是防止句子被切断但重叠太大会导致检索结果冗余多个 chunk 内容重复浪费上下文窗口。我试过 50% 重叠结果 Top-5 里三条是重复内容反而挤掉了其他相关信息。注意chunk 大小要和 embedding 模型的最大输入长度匹配。有些模型支持 8192 token但不代表你就要用满长文本的向量表示会丢失细节检索精度反而下降。4. 向量化与向量数据库选型别被参数忽悠4.1 embedding 模型选择的三个维度选 embedding 模型我看三个维度中文语义能力、维度与性能、领域适配性。中文语义能力是基础有些模型英文很强但中文拉胯检索中文文档时明显力不从心。维度方面768 维和 1024 维是主流维度越高表达能力越强但存储和检索成本也越高。领域适配性则看模型有没有在相关领域语料上训练过比如法律、医疗、专利这些专业领域通用模型往往不够用。我的建议是先用一个通用中文 embedding 模型跑 baseline测出 hit rate然后再试领域微调过的模型或更大的模型看提升幅度是否值得成本。很多时候换模型带来的提升还不如优化切分策略来得大。不要一上来就迷信“更大更强”。4.2 向量数据库选型的对比与决策向量数据库选型是很多人纠结的点。我把常见选项列个表方便对照。数据库部署方式适合规模核心优势注意事项FAISS本地库百万级以下轻量、零依赖、速度快无持久化需自己管理索引Chroma本地/服务十万级上手快、API 简洁大规模性能一般Milvus分布式亿级扩展性强、功能全运维复杂资源占用高Qdrant本地/云千万级过滤检索强、Rust 性能好生态相对年轻pgvector依托 PostgreSQL百万级和业务数据同库、事务一致索引类型有限调优空间小选型的核心不是“哪个最强”而是“哪个匹配你的场景”。个人项目或中小规模知识库Chroma 或 FAISS 足够别为了“先进”去上 Milvus运维成本会让你怀疑人生。如果业务数据本来就在 PostgreSQL 里pgvector 是最省心的选择省去了数据同步的麻烦。过滤检索是个容易被忽略的点如果你的检索经常需要按时间、类别、权限过滤Qdrant 和 Milvus 的过滤能力明显更强。4.3 索引参数对检索速度与精度的影响以 HNSW 索引为例它有两个关键参数M和efConstruction。M 是每个节点的连接数越大图越密检索越准但内存占用越高一般设 16 到 64。efConstruction 是建索引时的搜索深度越大索引质量越好但建索引越慢一般设 100 到 200。检索时还有个 efSearch 参数越大召回越高但越慢。我的调参顺序是先固定 efSearch64 跑 baseline然后逐步提高 efSearch 看 hit rate 和延迟的权衡曲线找到拐点。很多时候 efSearch 从 64 提到 128hit rate 只涨 2%但延迟翻倍那就不值得。参数调优要看边际收益不要盲目拉满。5. 检索策略优化从单路召回走向混合检索5.1 纯向量检索的盲区纯向量检索擅长语义匹配用户问“怎么提升问答准确度”它能召回“优化检索策略”这类语义相近但字面不同的内容。但它有个盲区对精确匹配不敏感。用户问“专利号 CN123456789A 的权利要求”向量检索可能召回一堆讲权利要求的通用文档却漏掉那个特定专利号。因为专利号这种精确标识符在向量空间里没有特别的语义区分度。这个盲区在专业领域特别致命。法律条文编号、产品型号、人名、地名、代码函数名这些都是精确匹配需求纯向量检索经常翻车。5.2 混合检索的落地配置解决方案是混合检索向量检索 关键词检索BM25 或全文索引两路结果融合。向量检索负责语义召回关键词检索负责精确匹配互补短板。融合策略我常用两种。一种是加权求和把两路的归一化分数按权重相加比如向量 0.7、关键词 0.3具体权重用评测集调。另一种是RRFReciprocal Rank Fusion不看分数只看排名把两路结果按排名倒数相加公式是 score Σ 1/(k rank)k 一般取 60。RRF 的好处是不用归一化分数对分数尺度不敏感实测更稳。# RRF 融合示例 def rrf_fusion(vector_results, keyword_results, k60): scores {} for rank, doc in enumerate(vector_results): scores[doc.id] scores.get(doc.id, 0) 1 / (k rank 1) for rank, doc in enumerate(keyword_results): scores[doc.id] scores.get(doc.id, 0) 1 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)我实测下来混合检索相比纯向量检索hit rate 能提升 15 到 25 个百分点尤其在包含大量专有名词的知识库里提升更明显。5.3 查询改写与意图识别的增益用户的问题往往不是最优的检索查询。口语化、省略、指代都会让检索效果打折。查询改写就是在检索前用大模型把用户问题改写成更适合检索的形式。比如用户问“它和上一个比怎么样”改写后变成“方案 B 相比方案 A 的优缺点对比”。更进一步是意图识别先判断用户是想查事实、做对比、还是求操作步骤然后走不同的检索策略。事实查询走精确匹配优先对比查询走多路召回再合并操作步骤走结构化文档优先。这个思路就是业内说的 agentic RAG让检索过程有“思考”和“决策”。不过我要提醒一句查询改写会引入额外的大模型调用增加延迟和成本。我的做法是只在检索结果置信度低时触发改写比如 Top-1 分数低于阈值或者多路结果分歧大才启动改写重试。这样既保证了效果又控制了开销。6. 重排与生成控制把好最后两道关6.1 重排模型为什么能显著提升 hit rate重排rerank是检索后的第二道筛选。向量检索是“粗筛”从海量文档里快速找出候选集重排是“精筛”用更精细的模型对候选集重新打分排序。重排模型通常是 cross-encoder 结构把查询和文档拼在一起输入能捕捉更细粒度的交互信息精度比向量相似度高得多。代价是速度慢因为它要对每个候选逐一计算没法像向量检索那样用 ANN 加速。所以标准流程是向量检索取 Top-50重排后取 Top-5 送给大模型。我实测过加一个重排模型Top-5 的 hit rate 从 62% 提到 88%这个提升幅度是任何单点优化都比不了的。如果只能做一件事来提升准确度我会选加重排。6.2 上下文组装与引用标注检索回来的 chunk 怎么塞进提示词也有讲究。我见过有人把 Top-10 直接拼接结果上下文里全是重复和噪声模型反而被干扰。我的做法是重排后取 Top-3 到 Top-5按相关性排序每个 chunk 标注来源编号提示词里明确要求模型“只基于以下材料回答并标注引用编号”。引用标注不仅让答案可追溯还能抑制幻觉。当模型知道要标引用时它会倾向于从材料里找依据而不是自由发挥。实测加了引用要求后编造答案的比例明显下降。6.3 提示词中的防幻觉约束提示词里我会加几条硬约束材料中没有的信息明确说“材料未提及”不要推测如果材料之间矛盾指出矛盾并分别陈述不要用材料之外的知识补充。这几条看起来简单但能挡掉大量幻觉。还有一个技巧是让模型先复述再回答。比如要求它先列出“材料中与问题相关的关键句”再基于这些句子作答。这个“先检索后生成”的思维链能让模型的注意力更集中在材料上减少跑偏。注意提示词约束不是万能的如果检索材料本身就是错的模型再老实也会答错。所以提示词是最后一道防线不是第一道。7. 常见问题与排查技巧实录7.1 检索到了但答不对怎么办这是最常见的问题。检索结果里有正确答案但模型没用上。排查思路先看正确答案在 Top-K 里排第几如果排第 4、第 5可能是被前面的噪声干扰了加重排或减少送入的 chunk 数量。如果排第 1 但模型还是答错那可能是 chunk 本身表述不清或者提示词没引导好。我遇到过一个案例chunk 里写的是“该参数默认值为 0.7可通过配置修改”用户问“默认值是多少”模型答“可通过配置修改”。这就是提示词没强调“直接回答问题”模型抓错了重点。改提示词后解决。7.2 多跳问题的拆解策略多跳问题是指需要多步推理才能回答的问题比如“A 公司的 CEO 毕业于哪所大学”。这需要先查 A 公司 CEO 是谁再查这个人的教育背景。单次检索搞不定因为知识库里可能没有直接答案。解决方案是迭代检索先检索第一跳从结果里提取中间答案再用中间答案构造第二次查询。这个过程可以用 agent 框架编排也可以用简单的循环实现。关键是设置最大迭代次数防止无限循环。7.3 评测集建设与持续迭代最后强调评测集的重要性。没有评测集所有优化都是玄学。我的做法是从真实用户问题里采样人工标注标准答案和来源文档初期 50 条就够用随着系统迭代逐步扩充到几百条。每次改动都跑一遍评测集看指标变化避免“感觉好了”的错觉。评测集还要覆盖不同类型的问题事实查询、对比、多跳、否定、模糊查询。只测单一类型会高估系统能力。我一般按类型分层采样确保每类都有足够样本。问题类型占比建议考察重点事实查询40%精确匹配与召回对比分析20%多路召回与合并多跳推理15%迭代检索能力否定与边界15%防幻觉与拒答模糊口语10%查询改写效果这套评测体系跑下来每次优化的收益都能量化团队沟通也有共同语言。我个人在实际操作中的体会是RAG 优化没有银弹但有一套可复现的方法论先度量、再定位、后优化每一步都用数据说话。把切分、混合检索、重排这三件事做扎实准确度提升到可用水平并不难。后续如果还想往上走可以考虑引入知识图谱做结构化增强或者用微调让模型更适配你的领域语料但那是另一个阶段的事了。