先看一个典型场景。你基于本地知识库搭建了一个 RAG 问答系统文档已经解析好、向量也已经存进数据库用户随便问一句业务问题系统却经常答非所问要么检索出来的片段和问题完全无关要么答案里混着好几段互相矛盾的内容要么明明知识库里有答案模型却回答“我不知道”。这是很多 RAG 项目从“能跑”到“好用”之间最真实的落差。我今年在多个实际项目里踩过一遍之后把 RAG 系统的准确率从最初的 60% 左右逐步拉到了 80% 以上。这篇文章不聊复杂的理论只把优化链路完整拆开为什么准确率低、怎么建立评估体系、每一步优化怎么做、完整代码怎么落地。文章适合这几类读者正在做知识库问答应用的开发者、想系统学习 RAG 优化方法的算法工程师、以及准备把 RAG 接入业务系统的后端同学。1. 背景为什么 RAG 系统“能跑但不好用”RAGRetrieval-Augmented Generation检索增强生成是目前大模型落地最常用的技术方案之一。它的核心思路并不复杂当用户提问时先从外部知识库中检索出与问题相关的内容片段再把“问题 检索到的片段”一起交给大模型让模型基于这些内容生成回答。这样做的好处很明显模型不需要记住所有知识知识可以随时更新回答可以溯源。因此在企业知识库问答、智能客服、文档助手、政务问答等场景里RAG 成了主流选择。但很多团队在 Demo 阶段很顺利一旦进入真实业务准确率就明显下降。常见表现有三种检索结果不相关用户问“报销流程”系统检索出来的却是“差旅标准”回答自然偏离主题。上下文信息不足用户问“如何申请产品试用”知识库里虽然存在申请入口、审核时长、试用额度等分散信息但检索引擎只找到一个片段模型拿到不完整素材只能靠“脑补”回答。答案冲突知识库不同文档说法不一致比如新旧制度并存模型把多条冲突信息全部塞进上下文生成结果前后矛盾。RAG 系统的准确性并不只取决于大模型本身。它的完整链路包括文档解析、文本分块、向量化、检索召回、重排序、提示词构造、生成回答。任何一个环节质量不够都会把错误传递到最终答案里。换句话说准确率低不是某一个环节的问题而是一整条链路的综合结果。这也是为什么很多开发者单点优化后效果提升却很不明显。2. RAG 准确率低问题通常出在哪要系统提升准确率得先定位瓶颈。以我在项目中的经验90% 以上的 RAG 效果问题都集中在下面五个环节。2.1 文档解析质量差知识库里的原始文档可能是 PDF、Word、Markdown、HTML甚至扫描件。PDF 如果不做版面分析单纯按文本流提取很容易出现段落顺序错乱、表格内容丢失、标题和正文粘连等问题。这些脏数据进入分块环节后检索到的自然也是一堆破碎内容。2.2 分块策略与业务不匹配分块是 RAG 中最容易被低估的环节。块太大单个片段包含多个主题向量表示不聚焦检索精度下降块太小上下文语义不完整模型无法理解前因后果。固定字符数切分还会把段落从中间截断导致语义断裂。2.3 向量检索本身有天花板向量检索解决的是“语义相似”问题但它对关键词、专有名词、编号规则的匹配能力很弱。比如用户问“HT-208 设备故障代码 E03”如果知识库里写的是“型号 HT208 报错 3”纯向量检索很难精准命中。这其实就是 RAG 里常说的“召回不足”。2.4 检索结果没有重排序向量检索返回的 Top-K 结果是按向量相似度排序的。但“向量相似”不等于“对回答有用”。前几条结果可能高度相似但信息重复真正包含关键答案的片段反而排到了后面。如果不加重排序Rerank大模型拿到的上下文质量就差很多。2.5 提示词没有约束生成最后一步是生成。如果提示词写得太随意模型可能忽略检索内容、直接凭自身知识回答这就完全违背了 RAG 的初衷。提示词里必须明确“只能基于给定的资料回答资料不足时明确说明不清楚”。理清这些瓶颈之后我们还需要一套方法来判断优化是否有效。接下来先讲评估体系因为没有评估体系的优化本质上都是碰运气。3. 优化前先搭建评估体系没有评测就没有优化很多团队优化 RAG靠的是“人工看几十条问答感觉变好了”。这种方式的问题在于主观性强、不可复现而且无法定位哪个环节出了问题。合理做法是准备一份有标准答案的评测集用统一指标评估每次改动前后的效果。3.1 评测集怎么准备从真实业务问题中抽取 50~200 条问题覆盖不同难易程度。每条问题至少包含问题文本标准答案或关键答案片段问题所属的类别比如报销、售后、技术故障、政策查询复杂程度标记单片段可回答 / 多片段融合 / 需要推理。评测集不需要一开始就做得很全但一定要覆盖真实使用场景。后续可以随着线上反馈不断补充。3.2 两个核心评估维度维度说明简单评估方式检索命中率检索返回的 Top-K 片段中是否包含能回答问题的关键片段人工判断或 LLM 判断计算命中比例最终答案正确率模型基于检索内容生成的答案与标准答案相比是否正确人工打分或 LLM 打分分 0/1 或 0~5 分其中检索命中率更值得优先关注。如果检索命中率不高把大模型换成更强的版本也很难救回来如果检索已经命中但答案仍然不对问题则更多出在提示词或模型能力上。3.3 用脚本批量评测实际项目中我习惯把评测集写成 JSON 文件用自动化脚本跑完整链路输出每个问题的检索结果和生成答案再统一打分。[ { question: 员工报销差旅费需要哪些材料, reference: 报销差旅费需要提供发票、行程单和审批单, category: 报销, difficulty: single }, { question: 如果同时申请试用和购买价格怎么计算, reference: 试用期间免费购买按正式报价计算, category: 售前, difficulty: multi } ]有了这个评测文件后面每做一个改动都可以直接对比“改动前 vs 改动后”的准确率。推荐的优化顺序是先修解析和分块再换/调 Embedding然后加检索策略接着加重排序最后优化提示词。下面按这个顺序逐步拆解。4. 方法一文档解析与分块策略优化4.1 文档解析先结构化再向量化原始文档不能直接“一股脑”塞给分块器。对于 PDF建议先做版面分析识别标题、段落、表格、页眉页脚再按阅读顺序提取文本。对于 Word 文档尽量利用标题样式和段落结构。对于 HTML先去除导航、广告、脚本等无关内容再提取正文。这一步的意义是只有拿到结构清晰的正文文本分块才不会截断语义。4.2 分块策略不要只用固定长度固定字符分块虽然简单但对中文场景效果并不稳定。中文没有天然空格固定 500 字切分很容易把一句话、一个表格或者一条完整流程从中间切断。我比较推荐“结构化优先”的分块思路优先按文档的标题层级切分Markdown 标题、Word 标题样式每一级标题下的内容作为一个候选块如果候选块太长再按段落或者句子边界二次切分如果候选块太短则与相邻内容合并避免单块信息量不足。这里给一个基于标题和段落的分块示例from typing import List def split_by_headings_and_paragraphs(text: str, max_chunk_size: int 800) - List[str]: 按标题层级和段落边界进行分块。 简单实现以 ### 或 ## 为第一层切分点然后在块内按空行切分段落。 import re # 按标题切分这里以 ## 和 ### 为例 sections re.split(r(?m)^(#{2,3})\s, text) chunks: List[str] [] for i in range(1, len(sections), 2): heading sections[i] body sections[i 1] if i 1 len(sections) else current_chunk f{heading}{body}.strip() # 如果整个小节仍然过长再按段落切分 if len(current_chunk) max_chunk_size: chunks.append(current_chunk) continue paragraphs re.split(r\n\s*\n, body) buffer for para in paragraphs: para para.strip() if not para: continue if len(buffer) len(para) max_chunk_size: buffer f\n\n{para} else: if buffer: chunks.append(f{heading}{buffer}.strip()) buffer para if buffer: chunks.append(f{heading}{buffer}.strip()) return chunks4.3 分块参数怎么定分块大小没有统一最优值取决于知识库文档类型和模型上下文窗口。按照经验可以从以下参数试起通用文档400~600 字问答对类型的知识库200~300 字长文报告800~1200 字并且需要带标题。关键原则是一块只讲一个主题且首尾语义完整。另外建议在分块时把标题信息嵌入到块内容前部让向量能感知到上下文主题。比如原始块内容是“报销标准普通员工每天 150 元”加上标题后变为“差旅费报销制度 报销标准普通员工每天 150 元”检索效果往往会有明显提升。5. 方法二Embedding 模型选择与向量检索优化5.1 Embedding 模型决定语义理解上限Embedding文本向量化模型负责把文本转换成向量是向量检索效果的核心。不同模型的语义理解能力差异很大尤其对中文长文本、专业术语、同义改写等场景。选择 Embedding 模型时的几个判断维度中文效果优先测试中文语料上的表现支持的最大输入长度比如 512 还是 8000 token向量维度会影响存储与检索性能是否支持领域微调垂直场景下可微调会比通用模型更准。在实际项目中建议准备一组“检索命中率”评测集用同一个测试集跑两三个候选模型直接对比命中率而不是只看网上口碑。5.2 向量检索参数注意事项向量检索时Top-K 的选择也很关键。K 太小容易漏掉关键信息K 太大又可能让不相干内容占据上下文。常见设置是召回 Top-20~50经过重排序后再取 Top-3~5 给大模型。千万不能把 Top-K 直接当成最终给模型的片段数量。另外要关注相似度阈值。如果检索结果整体相似度都很低说明知识库里可能根本没有相关内容。此时与其强行生成不如让系统返回“当前知识库暂未覆盖该问题”。下面是一个使用 FAISS 做向量存储和检索的最小示例仅演示核心逻辑import numpy as np import faiss # 假设 vectors 是已经计算好的文本向量 vectors np.random.rand(1000, 384).astype(float32) # 建立索引 index faiss.IndexFlatIP(384) # 内积相似度使用归一化向量等价于余弦相似度 faiss.normalize_L2(vectors) index.add(vectors) # 检索query_vector 也需归一化 query_vector np.random.rand(1, 384).astype(float32) faiss.normalize_L2(query_vector) scores, ids index.search(query_vector, k20) print(Top-20 相似度分数, scores) print(Top-20 文档编号, ids)5.3 关键词召回与向量召回结合纯向量检索对专有名词、编号、缩写不敏感。实际系统中比较推荐“向量召回 关键词召回”的多路召回方式向量召回适合语义相近但表达不同的情况BM25/Elasticsearch 关键词召回适合精确匹配型号、人名、编号的情况两路结果合并后用重排序模型统一打分。多路召回会增加工程复杂度但能明显提高检索命中率。尤其是知识库中包含大量产品型号、工单编号、法规条款时关键词召回几乎是刚需。6. 方法三查询改写与多路召回用户的问题往往不是“最适合检索的 query”。比如用户问“我要报打车费走什么流程”直接拿整句话去做向量检索效果不一定好。把问题改写成更利于检索的形式是提升召回率性价比很高的一步。6.1 查询改写方式常见的改写策略包括去口语化将“我想问一下咱们公司报销打车费是咋弄的”改写成“公司打车费报销流程是什么”提取关键词把问题中的实体拆出来比如“HT-208 报错 E03”作为检索关键词生成子问题把复杂问题拆成多个简单子问题分别检索再合并结果补充上下文多轮对话场景下把指代信息补充完整。比如用户说“那这个能报多少钱”改写为“打车费报销能报多少钱”。下面是一个简单的查询改写示例思路是通过大模型生成检索用关键词同时保留原始问题def rewrite_query(original_query: str, llm_call) - str: 简单查询改写让大模型输出更适合检索的关键词。 llm_call 可以是 OpenAI/本地模型的调用封装这里只演示思路。 prompt f你是一个检索词改写助手。 请把用户的问题改写成适合搜索引擎和向量库检索的关键词形式尽量保留专有名词和编号。 只输出改写结果不要输出解释。 用户问题{original_query} 改写结果 return llm_call(prompt).strip()6.2 多轮对话中的改写如果你的 RAG 系统支持多轮对话建议先做指代消解。例如用户问“试用期是多久”用户追问“那收费呢”如果不做改写第二问单独检索会丢失“试用”这个主题。正确做法是把对话历史拼进改写 Prompt让模型把指代补全成“试用期收费吗”再去检索。6.3 混合检索实现思路在代码层面可以先把关键词召回和向量召回的文档 ID 合并去重再进入重排序阶段。这里需要注意权重问题向量分数和关键词分数量纲不同不能直接相加通常需要先各自归一化或者直接把合并结果交给重排序模型处理。7. 方法四重排序与 Prompt 构造优化7.1 为什么需要重排序向量检索阶段追求的是“不要漏”所以候选集可以放宽一些但大模型上下文有限不能把几十个片段都塞进去。重排序模型的作用是对候选片段进行精细打分把真正能回答问题的片段排到前面。目前比较常见的做法是使用专门训练的 Cross-Encoder 重排序模型。和向量检索的双塔架构不同Cross-Encoder 会把“问题 文档片段”拼在一起输入模型交互更深排序效果通常更好但速度相对较慢。因此重排序一般只作用于向量召回后的几十条候选集不会对全库执行。7.2 重排序后的片段选择重排序返回后建议先做一个简单的规则过滤去掉与问题完全无关的片段去掉互相重复的片段优先保留包含具体数据、编号、时间、金额等事实信息的片段如果发现多个片段互相矛盾可以在 Prompt 中提示模型注意版本差异。7.3 Prompt 构造最后一道护栏即使检索结果已经很准Prompt 写得不好也会前功尽弃。推荐的核心要点明确告诉模型“只能使用给定资料回答”要求模型在资料不足时直接说“根据当前知识库无法回答”要求模型回答时标注来源片段编号如果资料存在冲突让模型如实说明“不同资料说法不一致”。下面是一个比较通用的 RAG Prompt 模板你是一个企业知识库问答助手。请根据以下资料回答用户问题。 要求 1. 只能使用资料中的信息回答不要使用你自身记忆中的内容。 2. 如果资料中没有足够信息请回答“根据当前知识库无法回答该问题”。 3. 回答时在句末标注来源片段编号例如 [1][2]。 4. 如果不同资料存在冲突请分别列出不同说法并注明对应来源。 资料 [1] 差旅费报销制度普通员工每天住宿标准150元。 [2] 差旅费报销流程报销需提供发票、行程单及审批单。 用户问题员工出差住宿能报销多少钱模型输出示例根据差旅费报销制度普通员工每天住宿标准为150元 [1]。报销时需提供发票、行程单及审批单 [2]。这种 Prompt 的好处是既约束了模型不乱编也方便用户验证答案来源后续排查 RAG 问题也会容易很多。8. 实战完整项目示例下面把前面讲的优化思路落成一个可运行的完整示例。这里使用 Python FAISS 本地/远程 Embedding 的方式重点演示检索链路。注意示例依赖版本需要根据你的环境调整。本文以常见实现为参考重点演示方案思路不是固定教程模板。8.1 项目结构与依赖rag_demo/ ├── data/ │ └── knowledge.md ├── splitter.py ├── embedder.py ├── retriever.py ├── generator.py └── main.py依赖建议pip install numpy faiss-cpu openai如果使用本地 Embedding还可以安装 sentence-transformerspip install sentence-transformers8.2 文档加载与分块这里直接用 Markdown 文档来演示。# 差旅费报销制度 ## 住宿标准 普通员工每天住宿标准为 150 元部门经理每天 300 元。 ## 交通标准 市内交通凭票报销长途交通需提前审批。 # 报销流程 ## 提交材料 报销差旅费需要提供发票、行程单和审批单。 ## 审批时限 审批通常需要 3 个工作日。加载与分块代码如下# splitter.py from typing import List def load_markdown(path: str) - str: with open(path, r, encodingutf-8) as f: return f.read() def split_by_headings(text: str) - List[str]: lines text.splitlines() chunks [] current_heading current_lines [] for line in lines: if line.startswith(#): if current_lines: chunks.append(f{current_heading}\n \n.join(current_lines).strip()) current_heading line.lstrip(#).strip() current_lines [] else: if line.strip(): current_lines.append(line.strip()) if current_lines: chunks.append(f{current_heading}\n \n.join(current_lines).strip()) return [c for c in chunks if c.strip()]8.3 向量化与存储# embedder.py import numpy as np import faiss from sentence_transformers import SentenceTransformer model SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) def embed_texts(texts): return model.encode(texts, normalize_embeddingsTrue) def build_index(texts): vectors embed_texts(texts).astype(float32) index faiss.IndexFlatIP(vectors.shape[1]) index.add(vectors) return index8.4 完整检索与生成# main.py import numpy as np from embedder import model from retriever import retrieve_top_k from generator import generate_answer # 1. 加载知识库并分块 from splitter import load_markdown, split_by_headings text load_markdown(data/knowledge.md) chunks split_by_headings(text) # 2. 建立索引 vectors model.encode(chunks, normalize_embeddingsTrue).astype(float32) import faiss index faiss.IndexFlatIP(vectors.shape[1]) index.add(vectors)检索函数# retriever.py import numpy as np def retrieve_top_k(query, chunks, index, model, k3): query_vec model.encode([query], normalize_embeddingsTrue).astype(float32) scores, ids index.search(query_vec, kk) results [] for score, doc_id in zip(scores[0], ids[0]): results.append({ score: float(score), chunk: chunks[doc_id] }) return results生成函数示意需要替换为你实际的模型调用# generator.py def generate_answer(prompt: str, llm_call) - str: return llm_call(prompt)8.5 运行验证在 main.py 里传入一个问题query 员工出差住宿能报销多少钱 results retrieve_top_k(query, chunks, index, model, k3) print(检索结果) for r in results: print(r[score], r[chunk])预期检索结果中会包含“住宿标准”对应的分块。最终生成的答案应当基于这些分块内容给出而不是模型自行编造。如果检索结果不理想优先检查分块是否完整、Embedding 模型对领域语料是否适配、是否需要加入 BM25 关键词召回。9. 常见问题与排查思路问题现象常见原因解决思路检索到的内容明显不相关分块粒度过大或过小语义被截断按标题/段落分块调整块大小增加重叠专有名词、编号检索不到纯向量检索对精确匹配较弱增加 BM25 关键词召回做多路召回相似度分数整体偏低Embedding 模型能力不足或领域不适配更换大模型/领域模型或对 Embedding 做微调检索结果对但答案错误Prompt 没有约束、模型忽略资料强化 Prompt 指令要求标注来源并限制只能基于资料回答相同问题每次答案不稳定模型采样参数过高、Prompt 不够明确降低 temperature固定 Prompt并做评测对比知识库文档更新后效果变差没有重建索引或旧文档残留建立版本管理更新后重新向量化并清理旧索引多轮对话第二问检索不到未做指代消解和查询改写对第二问做上下文补全后再检索排查时建议按“数据 → 分块 → Embedding → 检索 → 重排序 → Prompt → 生成”的顺序逐层检查而不是一上来就换大模型。10. 工程落地的几点建议10.1 建立知识库版本管理知识库不是静态文件企业文档会不断更新。建议给每个文档加版本号向量库按版本重建。否则旧文档内容残留会导致新旧制度同时命中回答冲突。10.2 监控召回质量而非只看最终答案很多团队只盯着最终回答效果发现问题后很难定位。建议在检索链路里打印每个问题的 Top-K 结果把“检索是否命中关键片段”当作一个独立指标来监控。可以通过日志或离线评估任务来实现。10.3 注意生成模型幻觉风险RAG 本身不能彻底消除大模型幻觉只能降低幻觉概率。即使优化后准确率到了 80% 以上仍要保留“无法回答”的兜底路径。在金融、医疗、法律等高风险场景建议对关键答案增加人工审核或答案规则校验环节同时做好权限控制与操作审计遵守最小权限原则。10.4 不要忽略成本与延迟多路召回、重排序、长上下文都会增加延迟和成本。上线前要做压测明确每条链路的耗时预算。如果用户对实时性要求高可以只对高置信度问题启用全链路优化其他问题走简化链路。10.5 从 Agentic RAG 看下一步当单轮 RAG 的效果稳定后可以进一步尝试 Agentic RAG 方向让大模型根据问题自动选择检索工具、判断是否需要二次检索、多步推理后再回答。这种方案在复杂问题、跨文档融合问题上表现更好但工程复杂度也更高。建议先从稳定的单轮 RAG 开始再逐步引入 Agent 能力。11. 总结RAG 准确率从 60% 提升到 80% 以上并不是靠某一个“神技”实现的而是对整条链路的持续打磨先建立评测集再按照“文档清洗 → 结构分块 → Embedding 选择 → 多路召回 → 重排序 → Prompt 约束”的顺序逐项优化。如果你现在正在做一个效果不理想的 RAG 项目建议不要急着换大模型。先把 20~50 条典型问题整理成评测集跑一遍当前链路定位是“检索不到”还是“生不成”。大部分情况下问题都出在检索侧而不是生成侧。最后给你一个实操建议每周抽一点时间回看系统回答较差的案例把新问题补充进评测集。RAG 系统不是一次上线就结束的它需要依靠真实反馈持续迭代。只要评估集在增长系统的准确率就还有提升空间。如果这篇文章对你有帮助可以收藏备用。你在 RAG 优化过程中遇到过哪些“奇怪问题”欢迎在评论区分享一起交流排坑经验。