之前在业务里做 RAG 知识库问答时我遇到过一个很典型的问题系统 demo 阶段表现还行一上真实业务文档准确率就稳定卡在 60% 左右。用户问 10 道题总有 3 到 4 道回答得似是而非甚至直接漏掉关键信息。当时排查了很久网上资料零散不成体系很多文章只讲概念不给步骤照着做完还是原地踏步。后面我系统性地把 RAG 全链路拆开优化了一遍把文档解析、切片策略、召回链路、重排序、Prompt 模板逐项打磨最终把准确率从 60% 拉到了 80% 以上。这篇文就把这套闭环优化方案完整整理出来包含核心原理、完整代码示例和真实项目中的避坑清单。如果你正好在做 RAG 知识库问答、私有文档问答或者刚开始接触大模型应用开发这份实战笔记可以直接拿来复用。1. 为什么你的 RAG 系统卡在 60% 准确率1.1 什么是 RAG它为何会“答非所问”RAGRetrieval-Augmented Generation检索增强生成是目前大模型落地最常见的架构。它先把外部知识文档切分成片段通过 Embedding向量化写入向量数据库用户提问时先从知识库检索出相关片段再把这些片段连同问题一起交给大模型生成答案。用一句话概括RAG 不指望大模型“记”住你的私有知识而是让大模型在回答时“查”到对应的资料。这种架构有效解决了大模型无法掌握企业内部知识、容易产生幻觉的问题。但问题也随之而来RAG 的效果并不是由单一环节决定的。检索环节漏掉了关键段落后面大模型再聪明也回答不出检索环节召回了一堆无关文本大模型就会被噪声信息带偏给出错误答案。1.2 60% 准确率瓶颈的三种典型表现我在多个项目里复盘过 RAG 效果差的情况发现 60% 附近徘徊的系统问题高度集中在以下几个方面现象用户直观感受根因大概率出在答案和问题不在一个频道上“我问的是报销流程它答的是发票类型”检索召回不准语义匹配没对齐答案内容没错但关键步骤缺失“流程只讲了一半最重要的审批节点没提到”切片粒度过大或过小信息被截断答案引用了文档但内容是错的“它说根据文档规定可文档里根本不是这么写的”Rerank 缺失噪声上下文干扰生成这些表现并不是相互独立的很多时候是多个问题叠加出现。所以要提升准确率不能头痛医头、脚痛医脚而要把 RAG 当成一条完整的数据管道来优化。1.3 准确率提升不是单点优化而是链路优化我见过很多同学为了提升 RAG 效果一上来就换更强的 Embedding 模型或者把大模型从 7B 换成 72B。换完之后确实有提升但很快又碰到天花板。原因很简单大模型端的回答质量上限很高真正限制 RAG 系统效果的是“喂给大模型的上下文质量”。我把 RAG 全链路拆成四个核心环节知识入库文档解析、清洗、切片、向量化。召回阶段通过向量检索、关键词检索、混合检索把候选文档捞出来。重排阶段对召回结果做精细排序过滤噪声。生成阶段Prompt 模板、引用溯源、答案约束。准确率从 60% 到 80%本质上就是把这四个环节逐个排除短板。下面从评估体系讲起因为如果没有“尺子”你根本不知道优化有没有效果。2. 环境准备与优化前的效果评估2.1 技术栈说明RAG 技术栈更新非常快本文的示例以常见开源方案为主版本需要根据你的项目实际情况调整重点关注配置思路操作系统Linux / macOS / Windows 均可示例以本地开发环境为主。编程语言Python 3.9。向量数据库FAISS本地原型验证、Milvus 或 Qdrant生产环境。Embedding 模型BGE-M3 或 text-embedding 类模型按你的算力环境选择。Rerank 模型BGE-Reranker 系列。LLMOpenAI 兼容接口或本地部署模型例如 Ollama 加载的开源模型。编排框架LangChain 或 LlamaIndex也可以用原生 Python 实现核心链路。这里要强调框架只是工具不要被框架绑定。理解每个环节在做什么比会调某一个 API 更重要。2.2 先建立评测集否则一切优化都是“拍脑袋”RAG 准确率优化最大的坑就是没有量化指标就盲目调参。我强烈建议在动手优化之前先做一个评测集。评测集不需要太大但必须覆盖你的核心业务场景从真实用户问题中挑 30 到 50 条高频问题。为每个问题标注标准答案。标注答案来源文档片段可用于评估检索命中情况。覆盖不同类型的问题事实查询、流程查询、对比查询、开放问答。评测集建好之后后续每次修改索引策略、调整切片参数、更换模型都要在同一个评测集上跑一遍用数据说话而不是靠“感觉变好了”。2.3 评测指标Recall、Precision、Answer CorrectnessRAG 系统建议关注以下三类指标指标英文名称含义说明召回率Recall正确的文档片段是否被检索出来RAG 的上限精确率Precision检索结果中有多少是和问题相关的影响上下文质量答案正确率Answer Correctness最终生成答案是否准确完整关注语义层面的正确性检索环节重点看 Recall 和 Precision生成环节重点看 Answer Correctness。从 60% 到 80% 的优化过程就是这几个指标全面提升的过程。最简单的方式是请业务方或者自己人工打分每次跑完评测集对每条答案打“正确 / 部分正确 / 错误”计算正确率。虽然人工评估有一定主观性但这是成本最低、最容易落地的评估方式。3. 检索链路优化让正确的文档进到上下文3.1 文档解析切块之前先做好清洗很多 RAG 项目在文档解析阶段就出了问题。比如直接把 PDF 里的文本抽出来就往向量库里存结果包含大量页眉页脚、目录信息、换行符错乱这些噪声在后续切片和检索时都会被当成知识内容参与计算干扰语义匹配。文档解析阶段要做的三件事去除噪声页眉、页脚、页码、脚注、目录页在抽取文本时需要识别并过滤。保留结构标题层级、表格结构、列表序号要尽量保留这些信息有助于后续切片时保持语义完整。处理表格普通文本抽取会破坏表格的对应关系建议将表格转成 Markdown 格式或键值对文本避免语义丢失。如果是扫描版 PDF还需要接入 OCR 能力把图片中的文字抽出来。这个环节没有调好的话后面所有优化都会受影响。3.2 分段策略chunk_size 和 overlap 怎么调文档切片是 RAG 优化中最容易见效也最容易翻车的地方。切片参数主要有两个chunk_size每个切片的文本长度按字符或 token 计算。chunk_overlap相邻切片之间重叠的长度。切片太大会导致一个 chunk 里混合多个主题向量化后语义被稀释检索时“看似相关其实混沌”切片太小则会导致信息碎片化一个完整的知识点被切成好几段检索时只命中其中一部分大模型得到的上下文不完整。从我的经验来看切片的理想状态是“一个 chunk 只讲一个完整主题”。可以参考以下策略先按文档结构切优先保留 Markdown 标题、PDF 章节标题的层级关系。以 300 到 500 个 token 为一个基础块设置 50 到 100 个 token 的重叠。对常见 QA 文档、操作手册这类结构化的内容可以按条切分每条一个 chunk。对于长表格或代码块切成独立 chunk不要和正文混在一起。3.3 Embedding 选型与向量化参数Embedding 模型负责把文本转换为向量。向量之间的余弦相似度决定了检索结果的相关性。选 Embedding 模型时主要看三个方面语义能力对中文长文本、专业术语的理解能力。向量维度与索引开销维度越高占用存储和计算资源越大。是否支持领域微调垂直领域如果通用模型效果不好可以考虑基于领域语料微调。实际项目中我建议至少准备两个 Embedding 模型做对比评测在评测集上分别跑召回率选效果更好的那个。不要只看宣传参数实测数据最可靠。还有一个细节Embedding 模型在索引和查询阶段必须保持一致。很多项目上线后发新版时换了 Embedding 模型但旧向量库没有重新构建导致检索一致性崩溃这属于非常隐蔽的坑。4. 混合检索与重排序从 60% 到 70% 的关键4.1 为什么“纯向量检索”不够用纯向量检索基于语义相似度也叫稠密向量检索Dense Vector Search。它的优势是能理解同义改写比如“怎么报销”和“费用报销流程”在语义上是相近的。但它有几个明显弱点对专有名词、精确 ID、型号、规则编号不敏感。比如用户问“BG-2024-001 号文件”向量检索可能匹配到语义相近但完全不同的内容。对否定关系、条件限定容易理解错。比如“不包含 X 的操作步骤”向量检索可能把包含 X 的文档也召回。解决思路是引入混合检索Hybrid Search把向量检索和关键词检索BM25的结果融合在一起兼顾语义理解和精确匹配。4.2 重排序Rerank解决“召回多但排序乱”的问题混合检索会把候选结果从几十条集合到一起但排序效果不一定理想。向量检索返回的 Top 3 不一定是最相关的 3 条BM25 召回的结果也可能混杂大量无关内容。重排序Rerank的作用就是用一个专门的交叉编码器模型把“问题和候选文档”一起输入模型重新计算每一条的相关性分数然后保留最相关的 Top K 条。Rerank 为什么比向量检索的相似度排序更准因为向量检索先要把问题和文档分别编码成向量再进行相似度计算这个过程是有信息损失的。而 Rerank 模型把问题和文档拼接在一起送入模型可以做深层次的交互式匹配精度更高但速度也相对更慢。正确的实践是召回阶段用混合检索多召回一些候选比如 Top 20重排阶段用 Rerank 精确排序只把 Top 3 到 Top 5 送给大模型。这样既保证了召回率又控制了上下文质量。4.3 示例代码混合检索加 Rerank 的实现思路下面给出示例代码思路需要放入你的项目文件中具体模型路径和 API 地址按实际环境替换。# 文件路径retrieval/retriever.py # 说明该示例展示混合检索 Rerank 的组合流程 # 依赖pip install pymilvus rank_bm25 # 注意此处以伪代码形式演示核心链路需按实际版本调整 from pymilvus import MilvusClient from rank_bm25 import BM25Okapi class HybridRetriever: def __init__(self, collection_name, embed_func, milvus_urihttp://localhost:19530): # embed_func: 统一的 embedding 函数向量化 query 或 document self.client MilvusClient(urimilvus_uri) self.collection_name collection_name self.embed_func embed_func def bm25_search(self, query, tokenized_docs, top_k20): # 先用简单分词构建 BM25 索引生产环境建议使用 jieba 等分词器 bm25 BM25Okapi(tokenized_docs) scores bm25.get_scores(query.split()) top_indices sorted(range(len(scores)), keylambda i: scores[i], reverseTrue)[:top_k] return top_indices, scores def vector_search(self, query, top_k20): query_vector self.embed_func(query) res self.client.search( collection_nameself.collection_name, data[query_vector], limittop_k, output_fields[text, doc_id], ) return res[0] def hybrid_search(self, query, tokenized_docs, top_k20): # 向量召回 vector_results self.vector_search(query, top_ktop_k) # 关键词召回这里简化为按索引返回实际需要存储原文 bm25_top_ids, bm25_scores self.bm25_search(query, tokenized_docs, top_ktop_k) # 合并结果并去重 candidate_map {} for item in vector_results: doc_id item[entity][doc_id] candidate_map[doc_id] item[entity][text] for doc_id in bm25_top_ids: # 如果关键词命中的 doc 不在向量结果里补充进来 if doc_id not in candidate_map: candidate_map[doc_id] tokenized_docs[doc_id] return list(candidate_map.items())上面的代码展示了混合检索的基本思路向量检索结果和 BM25 关键词检索结果合并去重形成候选集。在实际项目中建议把候选集大小设为 20 左右再交给 Rerank。# 文件路径retrieval/reranker.py # 说明使用 BGE-Reranker 对候选文档重排序 # 依赖pip install FlagEmbedding from FlagEmbedding import FlagReranker class ReRanker: def __init__(self, model_pathBAAI/bge-reranker-v2-m3): # 模型可以离线下载后放入本地路径避免每次启动时联网加载 self.reranker FlagReranker(model_path, use_fp16True) def rerank(self, query, candidates, top_k5): # candidates 为 [(doc_id, text), ...] pairs [[query, text] for _, text in candidates] scores self.reranker.compute_score(pairs, normalizeTrue) # 按分数降序排列 scored sorted(zip(candidates, scores), keylambda x: x[1], reverseTrue) return scored[:top_k]Rerank 结果里包含了最终要送给大模型的 Top K 条文档这些文档的相关性已经经过精排上下文质量会比纯向量检索高一个档次。5. Prompt 与生成链路优化把答案的最后一公里走好5.1 Prompt 模板如何影响准确率检索做好的前提下Prompt 模板决定了生成效果的上限。很多 RAG 项目检索结果没问题但 Prompt 写得过于简单比如只有一句“请根据上下文回答问题”导致大模型自由发挥输出不可控。一个合格的 RAG Prompt 至少应该包含四部分角色设定告诉模型它是“企业内部知识库问答助手”。上下文输入把检索到的文档片段按引用编号排列。回答要求只基于给定上下文回答、不要编造、无法回答时明确说明。输出格式需要时要求结构化输出标注引用来源。示例 Prompt 模板# 文件路径prompt/template.py RAG_PROMPT_TEMPLATE 你是一个严谨的企业知识库问答助手。 请仅根据以下【参考文档】内容回答问题不要使用你记忆中可能存在的常识进行推测。 【参考文档】 {documents} 【用户问题】 {question} 回答要求 1. 如果参考文档中没有足够信息请直接回复“当前知识库中未找到相关答案”。 2. 回答时请条理清晰分点列出关键步骤或结论。 3. 在答案末尾标注你引用的文档编号例如来源[1][3]。 4. 禁止编造参考文档中不存在的流程、数字或结论。 5.2 引用溯源降低幻觉的强制手段要求模型输出时标注引用来源不仅能提升答案可信度还能显著约束模型“乱编”的倾向。当模型被要求“每个结论都要有出处”时它会更加依赖上下文中已有的内容。实现上你在把文档片段放入 Prompt 时给每个片段分配一个编号[1] 来源《报销管理制度》第3章报销流程... [2] 来源《差旅管理规范》第2节住宿标准...模型在回答时就会自然引用[1]、[2]这样的编号。这样一方面方便用户核对原始文档另一方面也方便你做溯源分析和错误定位。5.3 多轮对话与 Query 改写如果你做的是对话式 RAG还有一个容易被忽略的问题用户后续问题往往是省略主语或指代上文的例如第一轮问“怎么申请报销”第二轮问“需要什么材料”如果直接把第二轮的原始问题拿去检索召回效果通常很差。解决方法是引入Query 改写把对话历史交给大模型生成一个“独立化”的检索问题再拿改写后的问题去检索。示例思路# 文件路径prompt/query_rewrite.py QUERY_REWRITE_PROMPT 请将用户的当前问题改写为一个独立、完整、适合检索知识库的检索式问题。 要求 1. 保留原问题中的所有关键条件。 2. 把代称、省略成分补充完整。 3. 不要输出多余解释只输出改写后的问题。 【对话历史】 {history} 【当前问题】 {current_question} 改写结果 Query 改写是 RAG 多轮对话场景准确率提升的重要抓手在很多垂直场景里能让检索命中率提升 10 个百分点以上。6. 完整实战案例RAG 准确率优化前后对比6.1 项目结构这一节用一个简化但完整的小项目来串联全部优化点。项目结构如下rag_optimize_demo/ ├── data/ │ └── 企业制度文档.md # 原始知识文档 ├── retriever/ │ ├── hybrid_retriever.py # 混合检索 │ └── reranker.py # 重排序 ├── prompt/ │ ├── template.py # RAG Prompt 模板 │ └── query_rewrite.py # Query 改写 ├── indexer.py # 文档入库 ├── query_pipeline.py # 查询链路主流程 └── eval.py # 评测脚本6.2 优化前的“朴素 RAG”实现优化前的实现非常简单读取文档直接按固定长度切块向量化入库查询时计算向量相似度取 Top 5拼接后交给大模型。# 文件路径indexer.py优化前版本 # 说明固定长度切块的简化实现 def naive_chunk_text(text, chunk_size400, overlap50): chunks [] start 0 while start len(text): chunks.append(text[start:start chunk_size]) start chunk_size - overlap return chunks这种实现有两个明显问题切块没有考虑文档结构可能把一个完整段落从中间切断。检索只用向量相似度没有混合检索也没有 Rerank。这就是准确率卡在 60% 的典型结构。6.3 优化后的完整检索链路优化后的流程如下文档入库时按结构切分保留标题信息。查询阶段先做向量检索 BM25 混合召回 Top 20。用 Rerank 对 Top 20 精排取 Top 4。将 Top 4 片段按引用编号填入 Prompt。要求大模型输出答案并标注引用。6.4 查询主流程代码# 文件路径query_pipeline.py # 说明优化后的查询主流程 from retriever.hybrid_retriever import HybridRetriever from retriever.reranker import ReRanker from prompt.template import RAG_PROMPT_TEMPLATE class RAGPipeline: def __init__(self, retriever, reranker, llm_func): self.retriever retriever self.reranker reranker self.llm_func llm_func # 大模型调用函数支持 OpenAI 兼容接口或本地模型 def answer(self, question): # 1. 混合召回 20 条候选 candidates self.retriever.hybrid_search(question, top_k20) # 2. Rerank 精排取前 4 条 top_docs self.reranker.rerank(question, candidates, top_k4) # 3. 构造带引用编号的文档块 document_text for idx, (doc_id, text) in enumerate(top_docs, start1): document_text f[{idx}] {text}\n\n # 4. 填充 Prompt prompt RAG_PROMPT_TEMPLATE.format(documentsdocument_text, questionquestion) # 5. 调用大模型生成 answer self.llm_func(prompt) return answer每一次检索都经过了“宽召回 精重排”两步既保证相关文档大概率被召回又保证最终送到大模型手里的上下文是质量最高的那几条。6.5 运行与结果对比我在一组企业制度文档问答评测集上记录了优化前后的效果优化阶段测试问题数正确率关键变化朴素 RAG5060%固定切块、纯向量检索增加混合检索5068%BM25 向量召回宽召回增加 Rerank5076%精排过滤噪声上下文优化 Prompt Query 改写5082%输出约束 多轮改写注意这里的数字来自我实测的一个业务场景不代表所有项目都能获得完全一致的提升幅度。但它反映了一个规律准确率提升通常是多个环节叠加积累的结果不是某一个“神技”单独带来的。7. 常见问题与排查思路RAG 优化过程总会遇到各种问题。我把高频问题整理成一张排查表问题现象常见原因解决思路检索不到相关文档切块过大导致主题混合Embedding 模型语义能力不足按结构切块缩短 chunk_size对比测试替换 Embedding 模型召回了很多无关内容纯向量检索对精确词不敏感没有 Rerank 过滤引入 BM25 混合检索增加 Rerank 精排答案引用了错误文档Rerank 排序不准确Prompt 未要求引用溯源检查 Rerank 模型效果在 Prompt 中强制标注引用编号多轮对话答非所问未做 Query 改写检索用的原始问题信息不完整增加 Query 改写模块把代称补全同一问题答案不稳定大模型采样参数设置不当检索结果不稳定降低 temperature固定 Rerank Top K 数量向量库更新后效果变差新旧 Embedding 模型不一致向量库未全量重建统一 Embedding 模型索引更新后重建向量库下面挑两个出现频率最高的问题详细展开。问题 1为什么 Rerank 加了之后反而变慢了甚至超时Rerank 需要对每一条候选文档执行一次模型推理候选数量越大耗时越长。有些团队把 Top 20 的候选全部 Rerank 后再取 Top 5这在文档量很大的时候性能会明显下降。优化方式是控制 Rerank 的输入规模。召回阶段取 Top 20Rerank 只对 Top 20 精排最终取 Top 4 或 Top 5。如果仍然超时可以考虑把 Rerank 模型切成小模型或者用异步批处理。问题 2怎么判断是检索问题还是生成问题这是非常关键的定位步骤。我推荐的判断方法是把检索出来的 Top K 文档直接打印出来人工看一遍。如果文档本身就文不对题说明问题出在检索或切片。如果文档相关但答案错误说明问题出在 Prompt 或大模型生成。如果文档只有一部分相关说明切片粒度过大混入了不相关内容。先把问题定位到具体环节再动手修改可以避免盲目调参浪费时间。8. 最佳实践与工程建议8.1 数据侧知识库质量决定天花板RAG 系统的天花板不是由大模型决定的而是由知识库质量决定的。入库之前要对文档做版本管理确定哪些文档是“有效知识”哪些是过时文档。一条过时的流程信息一旦进入知识库就会不断被检索到并生成错误答案。建议在文档元数据中加入生效日期、失效日期、文档版本号检索和生成时可以通过元数据过滤掉失效文档。另外不要忽视文档去重。多个相似文件同时入库后检索时会出现多条重复上下文既浪费 token 又可能造成信息冲突。8.2 索引侧版本管理与重建策略向量索引需要和 Embedding 模型强绑定。每次升级 Embedding 模型后旧向量库里的向量已经无法和新模型产出的向量直接比较必须全量重建索引。生产环境建议Embedding 模型变更走发布流程先在小范围评测集上验证。新向量库构建完成后通过开关灰度切流而不是一次性替换。保留上一版本索引方便快速回滚。8.3 安全边界权限过滤必须有企业知识库往往包含不同密级的内容。RAG 系统上线时必须考虑一个问题用户 A 的提问会不会检索出用户 B 无权查看的文档在召回和重排阶段都需要按用户权限过滤文档。推荐的做法是在文档入库时给每个 chunk 打上权限标签在检索条件中强制加上权限过滤避免敏感信息泄露。8.4 评估侧把评测集纳入 CI/CD评测集不是一次性工具而是持续维护的资产。建议把评测集纳入 CI 流程中每次修改 Prompt、升级模型、调整切片参数后自动跑一轮评测对比准确率变化。这样可以避免“优化了 A 类问题结果 B 类问题回归”的情况。RAG 链路涉及模块很多手工回归成本极高自动化评测是长期维护的必选项。8.5 性能侧缓存与并发策略RAG 链路包含向量检索、Rerank 模型推理、大模型生成单次请求耗时比普通 API 长很多。生产环境建议对高频问题做精确匹配缓存命中缓存直接返回。对向量检索和 Rerank 结果做短时缓存同一问题重复提问时避免重复计算。大模型生成使用流式输出降低用户等待感知。如果 QPS 较高Rerank 和大模型需要做异步化或独立部署避免相互影响。9. 总结准确率优化是一套体系化工程从 60% 到 80%每一个百分点的提升背后几乎都是几个环节的协同改进。结合这篇文的实践你可以按下面顺序逐一排查自己的 RAG 系统先建立评测集量化当前准确率。检查文档解析和切片策略确保知识入库阶段没有丢失信息。对比不同的 Embedding 模型选在评测集上召回率最高的配置。引入混合检索弥补纯向量检索在精确匹配上的短板。加入 Rerank 精排过滤噪声上下文。优化 Prompt 模板加入引用溯源和“不知道就说不知道”的约束。如果有多轮对话场景补上 Query 改写模块。RAG 优化的空间通常还很大你可以继续深入 Agentic RAG让大模型根据问题自主决定是否需要检索、检索多次甚至调用外部工具也可以基于领域数据微调 Embedding 模型和 Rerank 模型让系统更贴合自己的业务场景。至少现在你已经有了一个明确的优化地图。下一步拿起自己的知识库文档按这个流程跑一遍评测集看看准确率能有多少提升。