RAG 这个词去年到现在不知道被翻来覆去讲了多少遍。简单说Retrieval-Augmented Generation检索增强生成就是为了解决大模型只会背书、不懂查资料的问题你先把知识库切碎、向量化、建索引用户提问时先检索出相关片段再把相关片段连同问题一起喂给 LLM 生成答案。思路听起来一点都不复杂但真正把问答准确度做上去的团队十个里面可能不到两个。我自己调过的 RAG 项目少说也有七八个从几百条的小知识库到千万级的文档库都碰过今天这篇就把优化 RAG 应用提升问答准确度这条路上该踩的坑、该用的招系统性捋一遍。这篇内容适合谁正在搭 RAG 知识库问答的开发者、准备把 RAG 落地到业务里的技术负责人以及被模型回答得挺好但一到真实数据就胡说困扰的调参选手。你不需要有很深的理论背景但最好动手写过一点检索或调用过 LLM API。我尽量说人话把每个方案背后的原因讲清楚而不是扔一堆配置让你照抄完事。老实说RAG 的瓶颈从来不在模型有多强而在工程细节。很多项目死在召回都召不回来生成怎么可能好甚至有些人压根不知道怎么量化答得不好。所以这篇文章我按实际优化路径来组织先定位问题再逐层处理入库、检索、重排、生成、评估最后附一份排查清单希望能帮你少走几个月的弯路。1. 先诊断你的 RAG 应用到底卡在哪个环节很多同学一上来就急着换 embedding 模型、调 chunk 大小折腾一圈发现准确率纹丝不动。原因很简单你没搞清楚问题出在哪一环。RAG 本质上是一条流水线——文档解析 → 切分 → 向量化 → 索引 → 检索 → 重排 → 构造 Prompt → 生成。每一环都在掉精度你的最终答案质量是整条链路中最弱一环决定的。拿我接手过的一个合同答疑项目举例用户问供应商逾期交货的违约金比例是多少系统老是答不上来。一开始我以为是向量检索不行后来一查才发现原始 PDF 表格里写的不是违约金比例而是表头写违约金正文里只有日万分之五这种表述。PDF 解析丢了表格结构词向量召回自然找不到。换什么 embedding 都救不回来问题出在最前面的解析环节。所以在动手优化前先做一次环节隔离测试拿 20~30 条你手头最典型的业务问题分别查一下——文档能不能正确解析检索能不能把包含答案的片段召回来召回来的片段丢给 LLM 后能不能得出正确答案这个方法我内部叫三分法90% 的项目都能用它快速定位瓶颈。召回失败问题出在解析、切分、向量化、索引或查询改写。召回成功但答案错乱问题出在重排策略、Prompt 构造或上下文序。召回和答案都正常但用户觉得答非所问问题往往出在意图理解不足单轮 RAG 结构本身就不合适。一个容易被忽略的点是RAG 的准确度天花板在入库那一刻就已经定死了。检索做得再好也只是逼近这个天花板。所以真正的优化顺序应当是从数据端往生成端走先把地基打好再谈上层优化。2. 知识入库是准确度的地基解析与切分2.1 文档解析别指望一把梭的通用解析器文档解析是 RAG 项目里最脏最累、却最影响上限的活。很多教程让你直接拿 pypdf 或者 unstructured 跑一遍但真实业务里的 PDF 花样太多了扫描件、三栏排版、表头跨页、页眉页脚污染、表格被切断……通用解析器处理不了的场景至少占你知识库的 30%。我的建议是分层处理先做一个文件类型画像统计知识库里 PDF、Word、Markdown、HTML、Excel 各占多少再针对占比较高、且问题集中的格式做专项解析方案。PDF 文本型优先尝试 pymupdf它对文本块的还原质量通常优于 pdfplumber遇到页眉页脚干扰可以配合坐标过滤比如剔除页面顶部 10% 和底部 5% 区域。PDF 扫描型需要 OCR我实测 PaddleOCR 对中文表格和公式的效果比 Tesseract 好一个档次缺点是部署略重。如果敏感数据不能出内网就老老实实本地跑。Word 文档python-docx 可以按段落、表格分别抽取注意 docx 里的文本框内容默认读不到需要额外遍历。表格类内容文本化不可避免会丢结构建议转成 Markdown 表格或键值对形式再入库这对查一个具体数字的问题特别有用。我还习惯给每个段落记录来源元数据文件 ID、页码、章节标题、文档类型、更新时间。这不仅是给后续重排和引用溯源用更是排查问题时的救命稻草——没有元数据你连这段内容是哪来的都说不清。2.2 Chunk 大小与重叠度没有银弹但有公式可循切分是 RAG 里讨论最多、也最容易玄学化的环节。我见过有人把 chunk_size 从 100 调到 800 一路试却说不清为什么 500 比 300 好。这里其实存在一个基本矛盾chunk 太小语义不完整检索容易丢上下文chunk 太大噪声多embedding 向量被稀释并且超出模型上下文窗口的合理利用范围。我的经验公式是这样的chunk size 取决于你的最小语义完整单元是什么。对于产品说明书、规章制度这类按条写的内容chunk 就是一条对于长文章chunk 倾向于 400~800 token重叠 80~150 token。关键不是死记数字而是先看一下你文档里的自然段落有多长——段落本身就是很好的天然边界硬切只会把句子的语义切成两半。做切分实验时我强烈建议用 RecursiveCharacterTextSplitter 自定义分隔符优先级而不是简单的按字符数硬切。实际使用中我通常把分隔符优先级设成段落标题 换行符 句号和分号 逗号这样既能让系统感知段落结构又不会为了追求结构完整把 chunk 弄得过分大。2.3 结构感知切分是知识库问答的最优解之一如果知识库本身有清晰的层级结构比如帮助中心 FAQ 的标题-正文、操作手册的章节-步骤请一定利用起来。结构感知切分在处理这类文档时效果是碾压性的——它把摘要信息放在 chunk 开头让语义向量更容易命中同时方便后续做父子块检索。我常用的一个处理思路是父子切分给每个大章节甚至整个章节一个父亲块用于检索同时把章节下的子段落切碎成子块用于真正喂给 LLM 生成。检索的时候先命中父亲块再根据命中信息把子块拼出来。这样既保住了章节的全局语义又避免了一个 chunk 塞太多无关内容导致向量被稀释的问题。做了这个改动之后我那套操作手册问答项目的命中率从 61% 涨到了 78%几乎没付出额外成本。3. 向量化与索引召回率的第一道闸门3.1 Embedding 模型选型中文场景别无脑用开箱模型向量化是把文本变成数字坐标的过程embedding 选得不好后面所有环节都在将错就错。中文场景里我踩过最大的坑是直接用英文语境训练的 embedding 模型来处理中文效果惨不忍睹——逾期和延期这两个词在语义上明明近到不行向量距离却远得像两个星球。现在的实际情况是好用的中文 embedding 模型已经是开箱即用的级别了比如 bge-large-zh、bge-m3、通义千问的 text-embedding-v3 系列、智源的 bge 系列等。选择的标准不是看榜单分有多高而是看你自己的语料评测。我每次选 embedding 都会跑一个几十条的数据集测两个指标命中率和平均相似度排名花一个小时就能刷掉一多半候选模型。另外需要留意的是国内大厂的 embedding API 限流和费用在规模化场景下非常感人。如果你要建的是百万级知识库私有化部署一个 bge-m3 或同类模型反而是性价比最优解。量化版比如 INT8在牺牲 1%~2% 精度的情况下能把显存占用砍到三分之一实战中非常划算。3.2 混合检索词法 向量的组合拳向量检索擅长找语义相近但表述不同的内容但对精确关键词却很迟钝。而很多问答场景偏偏就吃关键词——用户问退货政策你文档里写着退换货规则向量其实也能命中但如果文档里写着退/换货细则2024 版含斜杠的词向量就经常抓瞎。这时候稀疏检索BM25的优势就出来了。所以我现在做检索默认不搞纯向量直接上混合检索Hybrid Search。实现方式很简单BM25 结果和向量检索结果各取 top_k再合并去重最后用重排器统一打分排序。字符串检索和语义检索是两条互补的路一个抓字面一个抓含义合在一起才能盯住不同风格的提问。3.3 索引存储与 top_k 参数别用默认值骗自己向量数据库选择上如果知识量不大几百万条以内Milvus 或开源的 Qdrant、Weaviate 都能用。但请注意向量检索的 top_k 不要默认取 3~5也不要不要命地取 50。top_k 太小容易漏调相关片段top_k 太大塞给 LLM 的上下文会掺入大量噪声反而拉低准确度。我在生产中一般设 top_k10~20 进重排经过重排后取 top_5 进 Prompt。有一个被忽视的点是分数阈值。向量检索返回的分数不同模型分布差异很大直接拿一个固定阈值卡所有场景是自找麻烦。更稳妥的做法是在验证集上画出分数分布找一个能区分相关/不相关的临界值或者干脆不设全局阈值只依赖重排器的排序结果。4. 精排与重排别让向量模型替你拍板4.1 为什么必须加一个 Re-ranking 阶段向量检索本质上是粗排它做的是在几十万条向量里快速筛出几百个候选这个阶段必须快所以它用的模型能力上限也被压着。真正决定答案质量的关键决策应当交给一个更聪明的模型来做——这就是重排Re-ranking。我拿一个真实例子说明知识库里同时存在2023 年版本的售后政策和2024 年新版本的售后政策用户问现在退货还能全额退吗。向量检索可能把两个版本都召回来甚至因为新版本文档表述更详细被排到了后面。此时重排模型可以直接将当前生效版本这个语义相关且带时效的信号排到最前避免 LLM 拿到一堆过期信息胡编。加了重排之后这类时效性问题的准确率提升非常显著。4.2 主流的重排方案怎么选目前主流重排方案有三类纯特征排序、开源交叉编码器、LLM 坐下游打分。纯特征排序比如混用 BM25 分数、embedding 相似度、PageRank 类特征写个加权公式。优点是零额外成本适合快速验证。开源交叉编码器比如 bge-reranker、Cohere Rerank 这种把查询和候选项拼在一起编码交互充分效果比向量相似度高一个档次也是我现在的主力方案。LLM 打分拿 GPT-4 或自家的 LLM 对候选做逐条评估排序效果上限最高但成本感人我只在评测集或高价值场景用。我实际常用的是 bge-reranker-base 这一档的模型既能在 GPU 上批量跑也可以 CPU 推理扛住中小流量。重排时我将候选固定在 50 条以内超过 50 条先做一轮粗筛否则重排的延迟会肉眼可见地上升。重排输出的分数分布漂移少可以直接用来做阈值判断。4.3 查询改写把用户的病句变成检索友好的好句用户提问很少是规整的表达。有人问那如果我提前退租押金能退吗也有人问房租押金退还条件甚至有人问押金 退 不 退——带空格、带口语、带指代不明。这种 query 直接拿去检索效果自然大打折扣。查询改写Query Rewriting的核心思路是在检索之前用一个轻量 LLM 把用户问题转成更适合检索的句式。比如把指代补全它支持吗 → 这个产品支持 Mac 吗把疑问句转成陈述句怎么申请发票 → 申请发票的流程也可以做多查询扩展一个用户问题生成 3~5 个不同角度的检索子问题分别检索后再合并去重。这个操作对 RAG 问答准确度的提升非常明显尤其多轮对话场景查询改写几乎是必选项。生产上要注意的是别让改写模型放飞自我——它可能在改写过程中丢掉关键限定词。我通常的做法是白名单黑名单双重约束改写结果和原 query 同时参与检索再通过重排自然决胜负。5. Prompt 构造与生成优化最后一公里的工程5.1 上下文窗口怎么塞才不浪费很多精力都白花在把检索结果全部堆给 LLM上了。LLM 的上下文窗口虽然越开越大但真正让模型集中注意力的区间是有限的而且塞太多无关片段会直接拉低准确度。我现在做法是经过重排取 top_3~5 片段同时按相关度从高到低排列再用指令明确告诉模型只依据下面提供的资料回答问题资料中没有的信息就说不知道。这里有个细节片段在 Prompt 里的排列顺序会影响 LLM 对信息的关注度。有研究直观地告诉我们模型对开头和结尾的内容记忆更牢中间容易视而不见。所以最高相关度的片段我会放在开头直给中期放一些次相关的为补充结尾再放一条强相关的兜底。配合具体业务逻辑这个三明治布局比单纯从高到低排下来在实测中更稳。5.2 引用溯源与答案约束让大模型学会说不RAG 应用落地时最怕的是模型扯谎。约束的方式不是只在 Prompt 里喊口口号而是要在机制上做限制。我在 Prompt 里会加上几条硬性约束如果提供的资料不足以回答问题请直接回复根据现有资料无法回答并给出缺少的信息方向。回答必须以资料中的原文为依据涉及数字、日期、金额等关键信息时不自行推断。回答末尾列出引用的资料编号及来源格式为引用 [1][2]。同时我在代码端强制校验如果 LLM 回答中引用了片段编号但该片段根本不在本轮 Prompt 上下文中直接打回重写。这一条小规则把幻觉率从我项目里的 11% 压到 3% 以内。5.3 多轮对话场景的特殊处理多轮对话中的 RAG 是另一个深坑。用户前一句问你们支持哪些支付方式第二句问那退款呢如果只拿第二句去检索那退款呢谁能召回什么系统的做法是把上下文做一次压缩和改写把前几轮的信息提炼成一句独立的检索 query然后再去检索。比如那退款呢会被改写成支持哪些支付方式的退款流程。另外一个多轮的坑是知识库内容本身可能随时间变化而用户历史里带了过期信息。多轮对话场景我建议每次检索时把用户的当前意图跟历史中的事实信息做区分避免 LLM 把历史里的旧答案当成当前事实来用。6. 评估体系没有指标就没有优化6.1 检索侧指标Hit Rate、MRR、Recall很多人把答案看起来还行当成评估标准其实这完全无法迭代。RAG 优化必须有量化指标。检索侧我常用三个Hit Rate对于预设的测试问题检索结果中是否包含正确答案片段。这是最直觉的指标。MRRMean Reciprocal Rank正确答案在检索结果列表中的排名倒数取平均越靠前分越高。衡量的是排在最前面的结果是否对路。RecallK前 K 条结果中覆盖了多少应该召回的片段。评估工程库信息覆盖率用这个更准。实际项目中我会准备 100~200 条带标准答案片段的测试集golden set每次改动切分方式、embedding、重排模型后都跑一遍这组测试对比 Hit Rate 和 MRR 的升降。这一套流程能让优化不靠感觉走而是改一个变量、看一次分数。6.2 生成侧评估人工 LLM-as-Judge 双轨制生成侧的评估比检索侧更主观也更难自动化。我的做法是双轨制人工抽检 50~100 条真实用户对话按正确、部分正确、错误、无法判断四档打分其余存量数据交给 LLM-as-Judge用一个评分 Prompt 让大模型对答案完整度、忠实度、相关度打分。然后对比人工分和 LLM 分的偏差定期校准 Judge 的 Prompt。LLM-as-Judge 不是完美的它会有偏好比如倾向更详细更长的答案、倾向复读 Prompt 里的观点。我自己的校准经验是在 Judge Prompt 里加答案忠实于给定资料的程度单独打分维度让它把依据资料回答与全凭编造地详细区分开这样幻觉问题更容易暴露。6.3 建立回归测试集把优化固化成流程我见过太多项目优化一时爽两周后又退回到原来的水平。原因是改了检索参数但并没有守住之前的成果。建议把所有历史问题和评测结果存成一个回归测试集每次更新代码或模型后强制跑一遍。我甚至建了一个简单的评测脚本输出一张本周对比上周的表格哪个指标掉了立刻定位到对应版本。这套测试集也是团队协作时的安全网别人加了新文档、改了切分逻辑不会让之前的优化白费。7. 常见问题与排查技巧实录7.1 召回不到相关内容十有八九是这五个原因一个很反直觉的排查经验当召回完全为空或召回结果明显无关先别怀疑向量模型先查数据端。文档解析时表格内容被丢弃或乱码——打印解析后的文本来检查。chunk 边界把关键信息拆散了——看一眼切分结果尤其长句和跨列表项。用户 query 与文档措辞差异太大——上一版查询改写能缓解。向量索引没更新新文档入库后检索的依然是旧版本——检查索引更新机制。元数据过滤条件太严——比如你按来源手册过滤而目标内容其实在来源FAQ里。排查技巧对于召回不到的问题直接把 query 放到调试台上打印 BM25 和向量检索各自的候选结果再对比 gold 答案出现在哪一侧。这能快速区分是向量语义差还是关键词完全没覆盖。7.2 答案质量忽好忽坏优先怀疑重排与上下文相关片段明明召回来了但 LLM 给出了错误答案大概率是 top_k 取太狠或重排把相关片段挤到后面去了。打印 Prompt 里实际拼进去的片段和顺序一眼就能确认。答案发挥过度编出知识库之外的内容先查 Prompt 约束是否生效再查是否漏了第 5 章说的无依据就拒绝回答那条。同一问题两次回答不一致这可能因为 LLM 采样温度过高生产环境把 temperature 调到 0 或 0.2配合固定种子。系统联调好但线上经常答错关注的往往是用户的 query 脏——大量口语、错别字、指代不明。这个时候查询改写比换更贵的模型划算。7.3 性能与成本的平衡先上缓存同一问题按语义哈希 关键词 hash 做缓存能挡住 30% 以上重复查询。再说降本top_k 不要一味给大重排器的 batch 要利用好 GPU 的并行度embedding 模型可以用量化版。存储和索引如果向量库在增长关注 recall 的退化及时做 HNSW 参数调优M 值、ef_construction、ef_search别等线上召回率掉到 50% 才发现。其实 RAG 工程的性能和准确度往往不是对立的。很多降本操作比如先去粗筛再重排、重排模型用小的在准确率上反而是正向的因为它们让系统把资源集中在真正有价值的候选上。8. 从 RAG 到 Agentic RAG下一步怎么演进当你的基础 RAG 准确度稳定之后如果想要继续提升可以考虑 Agentic RAG 的路线。所谓 Agentic RAG不是加一个Agent的名字就完事而是让系统具备自适应检索的能力先根据问题决定要不要检索、检索多少轮、检索结果不够是否要二次检索以及多路检索结果要不要交给工具或外部 API 去验证。我目前的实践是分级演进第一级是单轮 RAG解决 70% 的简单问题第二级加查询改写和重排覆盖大部分场景第三级引入多轮检索-反思-再检索的 Agent 结构——用户问今年 Q3 华东区销售额对比去年 Q3 有什么变化单轮 RAG 很可能只捞到一张表但 Agent 会先后查销售额表、增长率表、去年数据再交给 LLM 做对比分析。这种边查边想的模式准确率天花板明显更高。但这不意味着无脑上 Agent。Agent 结构的延迟和成本是单轮 RAG 的 3~5 倍如果知识库本身干净、问题模式固定老老实实做好单轮 RAG 的解析、切分、重排和评估往往已经能拿到 90 分的答卷。Agentic RAG 更适合问题复杂多变、知识库庞大、可分散在不同数据源的场景。这也是我想最后强调的一点优化 RAG 永远是从数据、检索、重排、生成、评估这条线一路打怪而不是靠哪个银弹一步到位。我自己踩过最深的坑就是一开始迷信换最新的模型就能解决问题结果发现花了大价钱准确率反而因为上下文塞入太多噪声而下降。后来老老实实回到数据端逐个环节量化比对才真正把准确度稳定在让业务方点头的水平。希望这篇经验笔记能让你在优化 RAG 时少走几步路——如果你正准备搭知识库问答系统不妨先按第 6 章搭一套评测集把基准线立起来再谈优化那时候每一次改动都会变得心里有底。