企业官网建设流程全解析

RAG系统准确率卡在60%，最直接的感受就是：回答看起来像模像样，但一问到细节就翻车。用户问“我司报销标准里住宿上限是多少”，模型答对了酒店等级，却把城市分类搞错；问“这份合同第7条违约责任是什么”，它自己推断出三条，原文里其实只有两条。更让人头疼的是，这类问题不是换个模型就能解决的。查ReRanker、调temperature、重写Prompt、把知识库重新清洗一遍，准确率可能只涨两三个点，甚至原地不动。

我一直觉得，RAG准确率从60%拉到80%，这件事的价值不在于“多了20分”，而在于它逼你把RAG从“一个黑盒功能”变成“一条可诊断、可优化、可回归的工作流”。一旦你把这条链路理清楚了，后面从80%再往上走，思路会顺很多。

1. 先搞清楚“60%准确率”到底意味着什么

1.1 准确率不是一个单一数字

很多人习惯用“回答准不准”来评价RAG系统，但落到实际项目里，“准确率”至少包括三个维度：

• 检索命中准确率：系统检索到的Top 5/10片段里，是否真的包含可支撑答案的内容。
• 生成回答准确率：最终答案是否正确、完整，有没有把原文信息说歪。
• 引用与格式准确率：回答是否标注依据来源，输出格式是否稳定，哪些问题应该拒绝回答，它有没有硬编。

如果只盯生成回答准确率，很难定位问题。两个系统“准确率都是62%”，一个是检索完全没找到，模型在硬编；另一个是检索到了但关键信息在多个片段里，模型只读了一段导致漏答。这两种问题的优化路径完全不同。

1.2 60%这个区间的典型瓶颈

从实测经验来看，RAG准确率落在60%到65%附近，大概率不只是生成端的问题，而是“检索到但不够用”和“检索到了但没有被正确用起来”这两类问题叠加。

检索端最常出现的情况是：相关文档确实被找回来了，但排在前面的片段是不相关的；等真正需要的片段排在第三、第四位时，生成模型往往会忽略掉它。分块太碎导致一个完整知识点被切断，也能解释为什么模型经常回答得“像是对的，但细节对不上”。

生成端的问题则更多出在Prompt约束不够、上下文组织混乱，以及指令不明确。比如你只是说“根据文档回答”，没说“如果文档中没有明确信息，必须回答无法确认”；你只是把Top 5片段直接拼接，没有让模型注意片段先后顺序和重复内容。这些细微差别，最后全都会折算成准确率上的几个点。

1.3 核心判断：先分清是“没找到”还是“没用起来”

我自己的经验是，首先要做一轮可复现的“问题分层”：把错误样本翻开，逐条标注它为什么错。是检索结果里根本没有相关片段，还是检索结果里有，但生成时没参考够？这一步做完，提升路径才会清晰。

不要一上来就调这调那。先用20到50条真实问题，判断瓶颈在检索侧还是在生成侧，这一步的价值超过后面所有参数调整。

2. 把RAG拆成流水线来诊断，而不是当黑盒

2.1 RAG的四段链路

一个标准的RAG流程，可以简化成四个环节：

1. 文档解析与切分：PDF、Word、HTML、表格等来源，转成干净文本，再按策略切成片段。
2. 向量化与索引：把片段转成向量，建立索引。
3. 检索召回：根据用户Query召回Top N相关片段。
4. 生成回答：把召回片段和用户问题一起送给大模型，生成最终答案。

任何一个环节出问题，最终准确率都会受影响。但“影响”的表达方式不一样，完全可以反推。

2.2 从现象反推环节

我在项目里一般会用这样一张对照表，来快速判断问题出在哪一层：

这张表不是万能公式，但它提供了一条很好的排查链路：先看现象，再定位环节，最后再动手改。绝大多数“调参数治不好”的问题，都是因为跳过了定位这一步。

2.3 最小可验证用例

定位问题的时候，要准备20条左右“最小可验证问题”。它们的特点是有标准答案，而且答案只依赖文档里一两句话，不需要复杂推理。

然后逐条运行，打印出：

• 用户Query
• 实际召回Top 5片段的文本开头
• 每条片段的相似度得分
• 最终回答

这一步能看到很多东西。比如你会发现，某条问题的正确片段虽然被召回了，但排在第6位，根本没进入生成上下文。这时候问题就明确了：不是模型不聪明，而是检索排序没把真正需要的片段顶上去。

3. 检索侧调整：优先级比想象中高

3.1 分块策略决定了很多问题的上限

分块是RAG最容易被低估的环节。固定大小分块虽然实现简单，但在真实文档上经常把概念切碎。比如一个技术方案里的“性能对比表”，被切到两个块里，表格说明在上一块，数据在下一块，模型读到一半自然答不准。

常见的分块策略有三种：

实际选择时，建议先做一轮“问答对验证”：从真实咨询记录里抽问题，看不同分块策略下，答案所在片段是否完整落入某个块内。不要只看块的平均长度，要看信息连续性。

3.2 向量化模型和Embedding质量

同一个文档，用不同的Embedding模型，检索命中率差异可能很明显。尤其中文场景，通用Embedding模型的领域术语覆盖能力、长文本语义理解能力都不一样。

如果发现很多问题“语义相近但检索不到”，要先看两个地方：一是Embedding模型是否适合中文业务领域，二是Embedding输入的最大长度是否足够。文档文本过长被截断时，末尾关键信息很容易丢。

还需要检查相似度阈值。太高会导致“宁可漏、不要错”，太低则会召回一堆无关内容。这个参数要在小样本上验证一遍，不能拍脑袋设置。

3.3 混合检索：关键词与语义互补

向量检索擅长语义相似，但对精确关键词、编号、代码标识符、英文缩写这类内容很弱。很多RAG项目里，用户问题就是“修订记录里的签发日期是哪天”，这种Query用BM25大概率能更快定位。

所以我的建议是：在同时存在“语义检索”和“关键词检索”的场景里，优先做混合检索。用BM25召回关键词相关片段，用向量召回语义相关片段，再做合并去重。不要只依赖纯向量检索，尤其资料里术语密集时。

3.4 重排序：从“找得差不多”到“排得准”

Top N召回之后，顺序就是一切。因为生成模型看的是Top K片段，不相关的片段排在前面，会严重影响回答质量。

引入一个轻量级的Rerank模型，对召回的Top 20到50个候选重新排序，再取Top 5或Top 7给生成端，通常可以直接提升几个点的准确率。这一步的原理不算复杂：向量召回负责广撒网，Rerank负责精挑细选，让关键信息尽量压在前面。

在常见成熟框架里，大多数已经内置了Rerank接口，配置上几分钟就能接好。但要注意，每次查询都会多一次模型推理，延迟会涨，需要在响应时间和准确率之间做权衡。

3.5 元数据过滤：先缩小范围再检索

当知识库足够大时，直接在全部文档上检索，相当于大海捞针。如果文档本身有部门、品类、文档类型、生效时间等元数据，可以使用元数据预过滤。

比如“查南京分公司的报销标准”，可以在检索前先过滤掉别的分公司文档。这个优化不一定直接提升单条准确率，但能减少无关内容对排序的干扰，很多时候会决定模型有没有被带偏。

4. 生成侧优化：上下文组织比提示词模板更关键

4.1 Prompt的结构化约束

生成端优化不只是一句“请根据以下文档回答”。更有效的Prompt一般包含四个部分：

• 角色与任务：明确大模型的身份，说明只需要做事实抽取结合回答。
• 参考依据：把检索到的片段完整放进去，并说明“只能依据以下内容回答”。
• 回答约束：不能编造；没有依据时直接说明；引用依据编号。
• 输出格式：规定答案结构、是否加编号、是否需要引用来源。

这套结构看起来很基础，但很多项目其实只写了“根据文档回答”，其他全靠模型自觉。模型一旦“自觉”，就开始自由发挥。

4.2 把“未知”变成可接受的答案

60%准确率阶段，用户最反感的是模型“不懂装懂”。这其实不是模型能力问题，而是你允许它在不确定时继续生成。

建议在Prompt里显式加入边界条款：如果文档中找不到足够信息，直接返回“根据现有资料无法确认，建议联系XX部门核实”。这样反而能提高用户对系统的信任度，因为错误回答造成的信任损伤，比“不知道”大得多。

同时要规定回答必须引用来源编号。这样用户能自己核对，同时系统出错了也能倒查是哪一段检索内容导致的。

4.3 上下文组织：Top K不是越多越好

有的项目为了提高“召回率”，把Top K设成8、10甚至更多，结果生成质量反而下降。原因很简单：大模型面对大量片段时，注意力会被无关内容稀释，而且多个片段之间信息重复时，模型可能不知道以哪个为准。

我一般更倾向于：先通过检索和重排，把高质量的5到7个片段喂给生成端；如果这些片段本身已经包含了完整答案，就不要再多塞。这里可以做一个简单判断：如果Top 3片段已经能覆盖大部分真实问题，就直接用更小的K。

4.4 上下文内去重与排序

在把片段拼进Prompt之前，最好先做一步轻量处理：

• 去掉明显重复的片段。
• 把和Query相似度最高的片段放最前面。
• 删除无关片段，特别是那些相似度高但实际是干扰项的文本。
• 把长片段做截断或摘要，避免单个块占满上下文窗口。

这一步虽然不起眼，但对生成准确率的影响很大。原因在于，大模型对上下文的利用不是均匀的，离Query更近、信息更紧凑的内容更容易被作为主要依据。

5. 可复用框架：从60%到80%的推荐路径

5.1 先搭一个最小评估集

这件事看起来费时间，其实是后续所有优化工作的基础设施。评估集不需要很大，50到100条来自真实业务的问题就够了。每条问题需要标注：

• 标准答案（人工确认过）
• 关联片段（在文档中的具体位置）
• 可接受回答范围（允许什么表述，不允许什么表述）
• 检索评测点（正确片段是否在Top 5内）

指标建议分两块：检索命中率（Recall）和生成正确率（Answer Accuracy）。每次修改只改一个变量，然后跑同一个评估集，看两个指标变化。

评估集是RAG项目的“方向盘”。没有它，你只是在凭感觉踩油门。

5.2 按顺序做，而不是同时做

很多项目卡在60%，是因为多个变量同时修改，出了问题也不知道是哪一步引起的。我更推荐按下面这个顺序来：

1. 先把文档解析和分块跑通，用最小评估集确认“答案能在某个块里找到完整依据”。
2. 再引入混合检索，用BM25补全关键词召回。
3. 接着接Rerank，把正确片段尽量提到Top 3以内。
4. 再优化Prompt和上下文组织，让生成端把检索结果用好。
5. 最后调参数：相似度阈值、Top K、分块重叠量、Rerank候选数。

每一步修改后，都跑一次评估集。如果准确率提升不明显，不要直接进入下一步，先把当前环节的问题解决掉。

5.3 单点修改、关联回看

我自己的习惯是，每次修改只改一个地方。假设你在调整分块策略，就其他参数保持不变，分块策略这一项分别用固定大小、语义分块、父子分块跑一遍，然后对比结果。

这看起来慢，但实际会节约大量时间，因为你能明确知道“这个提升来自哪里”。从60%往80%走的路上，最高效的不是找到一个神奇的“最优参数”，而是建立一套“知道怎么调、调了有效、能回流到评估集”的循环。

6. 到了80%之后，真正要面对的是工程化

6.1 文档变更与数据版本

静态知识库的RAG能调到80%，但一旦文档每月更新，准确率就可能悄悄掉回70%。原因在于，分块、向量索引和文档版本不是自动同步的。

建议把知识库的“版本”纳入管理。每次文档更新后，重新生成索引，并把评估集跑一遍，看有没有因数据变更导致的准确率回退。这一步做不做，决定了RAG系统能不能长期维护。

6.2 日志、反馈、人工复核

日志是排查线上问题的关键。至少要记录：用户Query、召回片段ID、相似度分数、实际使用的Top K、生成结果、用户是否有负面反馈。没有日志，准确率的下降就变成了一个难以定位的黑盒事件。

有条件的话，加入“用户反馈”通道，让业务人员可以点踩。每周抽样审阅一批错误案例，定期把它们补充进评估集。这样评估集会越来越接近线上真实分布，而不是一份静态的“考试题”。

6.3 边界：不是所有问题都适合RAG

需要清醒一点：80%准确率的RAG系统，适合的是“信息查找和有限总结”类问题。如果用户问题需要跨多个文档做复杂推理，或者需要结合领域经验做判断，RAG的溢出效应会很明显。这时候与其硬调RAG，不如考虑路由方案：哪些问题走RAG，哪些问题走传统关键词搜索，哪些问题直接交给大模型推理。

也就是说，RAG只是系统中的一个环节。与其让RAG满足所有问题，不如把问题分类，让不同的工具做擅长的事。

6.4 长期迭代的心态

RAG的准确率优化不是一个“一劳永逸”的任务。它的本质是不断观察错误样本、修正流程、验证效果、再重复。真正支撑这个循环的，是评估集、日志、回归测试和文档版本管理这些工程基础设施。

如果你现在正卡在60%，我的建议是：先别急着换模型或加文档。把评估集搭起来，跑一轮错误分析，确认瓶颈是在检索、分块还是生成，然后按顺序一个个解决。等准确率到了80%以上，你再回头看，会发现自己对RAG的理解已经完全不一样了。