为什么你的RAG系统回答问题总是不准确

张坤zkun 2026年4月3日 09:00

01 缘起：一个让我学会"管理预期"的项目

去年六月份，我们团队接了一个制造业客户的项目——搭建企业内部知识库问答系统。

客户的IT负责人找到我们时，需求很明确：他们有三年积累下来的产品手册、技术规范、售后FAQ，两万多份文档，想做一个内部问答机器人，主要给客服和售后团队用，减少重复咨询的压力。

我们评估了一下，文档量够、需求清晰、场景典型，签了合同，进场。

前三周做得很顺。文档清洗、切分、向量化、入库、接大模型，一气呵成。Demo阶段在客户会议室里演示了三十多个问题，准确率测出来95%，效果相当好。客户的业务负责人当场拍板：“就这个方向，尽快上线。”

当时我坐在会议室里，心里其实有点不安。

Demo用的问题，是我们的实施顾问和客户的IT一起挑的。三十多个问题，天然就是"好回答"的问题——文档里有明确答案、表述和文档原文高度接近、不涉及多步推理。

但我没拦住。项目排期紧，客户催得急，CEO在周会上已经说了"这个月底要看到效果"。

先上再说。

上线第一周，我每天晚上都能收到客户IT负责人的微信。

第一天，语气还算客气：

“客服反馈有个问题答得不太对，我发你看看。”

第三天，开始带情绪了：

“今天又收到三个投诉，一个是答非所问，一个是关键信息没给全，还有一个最离谱——回答里出现了我们根本没生产过的产品型号。你们的系统是在’编’吗？”

我连夜拉了我们的算法工程师排查。结果让人头疼：

那个"答非所问"的问题，客户问的是"XX型号在海拔3000米以上怎么调试"。我们去查检索日志，发现Top5的chunk里确实有调试相关内容，但没有一条提到"高海拔"的具体参数调整。模型拿到了一堆通用调试步骤，自然就只能回答通用内容。

那个"编造产品型号"的问题更离谱。检索结果里根本没有相关信息，但模型"自信地"编了一段看起来很专业的回答，连产品型号都编得有模有样——格式对、命名规则对，但那款产品根本不存在。

上线第三周，客户的VP拉了一个紧急会议。

会议室里坐着七八个人，客户的VP、IT负责人、客服主管，我们这边是我和两个工程师。VP没发火，但说了一句让我到现在都记得的话：

“准确率从测试时的95%，掉到了上线后的不到60%。这个系统，我不敢开放给外部客户用了。”

作为乙方项目经理，那一刻我最怕的不是技术问题——技术问题总有解法。最怕的是信任崩塌。客户开始怀疑的不是某个功能点，而是"你们这个团队到底行不行"。

这个项目后来花了两个月才把准确率拉回到90%以上。过程很痛苦，但值了——不是因为项目交付了，而是因为这次翻车让我彻底想明白了一件事：

RAG不准确，从来不是某一个环节出了问题。

它是检索→理解→生成这条链路上的累积误差。检索偏一点，理解偏一点，生成再偏一点，三个"偏一点"叠在一起，最终答案可能离正确答案差了十万八千里。

后来我复盘了我们团队过去两年做过的十几个类似项目，发现一个规律： 几乎每一个从Demo走向生产的RAG项目，都会经历一次准确率的断崖式下跌。 Demo阶段所有条件都是"理想态"——问题是精心挑的，数据是干净的，场景是简化的。一旦进入真实环境，用户的问题千奇百怪，数据质量参差不齐，准确率自然大幅下滑。

2026年1月，InfoWorld的一项调查更是揭示了一个残酷的事实： 企业RAG系统失败的根本原因不是模型不够强，而是28%的文档已过时，22%的政策相互矛盾，19%的知识散落各处。 另一项来自斯坦福的研究发现，当知识库超过约1万篇文档时，语义搜索会开始明显失灵——这不是模型变笨了，而是向量空间本身出了问题，学界称之为"语义崩塌"（Semantic Collapse）。

这篇文章，我想把我这两年踩过的坑、趟过的路，以及2026年最新的技术进展，系统地讲一遍。不是写给学术圈看的，是写给正在做RAG、或者准备做RAG的项目负责人的——你的系统为什么不准，到底该从哪里修起。

02 拆解：RAG准确率的四个断裂层

在展开讲之前，我先给一个框架。后面所有的分析和解法，都围绕这个框架展开。

先学会"翻译"客户的反馈

客户说"系统不准确"的时候，他们描述的症状其实可以归为四类：

客户原话	翻译成技术语言	问题出在哪
“答非所问，根本不是在说我问的东西”	检索拿到了错误或无关的文档	检索层
“说的对但不全，关键信息没提到”	检索对了，但模型没充分理解	理解层
“看起来很对，但细查发现是编的”	模型理解了，但生成时自由发挥	生成层
“上个月还行，这个月突然不准了”	知识库退化、向量漂移、数据腐烂	运维层

作为乙方PM，学会听懂客户的"症状描述"并翻译成技术语言，是第一个要练的基本功。客户不会告诉你"检索层的召回率不够"，他只会说"这系统不行"。你得会追问、会定位。

四个断裂层

后面第三章，我会逐层拆解每一层到底出了什么问题。第四章讲那些只有做过项目才知道的坑。第五章给解法，按投入产出比排序，告诉你先改什么最划算。

先建立这张地图，后面才不会迷路。

03 深挖：逐层击破

检索层：你的知识库在"答非所问"

检索层的问题是最常见、也是最容易被忽视的。很多人觉得"我检索出来的文档和问题很相关啊"，但相关≠精确。检索层的问题，本质上可以拆成三个子问题：分块策略、嵌入模型、检索方式。

分块（Chunking）——最被低估、也最容易翻车的环节

我们团队早期做文档切分，用的是最朴素的策略：按512 token切分，overlap 50 token。简单粗暴，Demo阶段也看不出问题。

上线后，问题全暴露了。

回到开头那个制造业客户。他们的产品手册里有一段调试流程，原文是这样的：

“在海拔超过2000米的环境下使用本设备时，需将参数X调整为1.5，参数Y调整为0.8，并关闭辅助散热模块。”

按512 token切分后，“海拔超过2000米"和"参数X调整为1.5"被分到了两个不同的chunk。用户问"高海拔怎么调”，检索引擎匹配到了含"海拔"的chunk，但参数值在另一个chunk里——模型拿到的上下文只有半截话，它能怎么办？只能猜。

这就是分块策略中最典型的 语义断裂 问题：关键概念被切断到不同分块中，每个分块的向量表示都因上下文缺失而变得模糊。

但分块的问题远不止"切错了位置"这么简单。它背后有一个更本质的 结构性矛盾 ：

任务类型	最优Chunk大小	核心需求	冲突表现
语义匹配（召回）	100-256 tokens	语义焦点明确，减少无关信息干扰	小切片导致信息支离破碎
上下文理解（利用）	1024+ tokens	逻辑完整性，背景信息充足	大切片引入噪声，丢失细节区分度

也就是说， 小chunk有利于检索匹配，但不利于模型理解；大chunk有利于模型理解，但不利于检索精度。 用单一粒度的chunk同时承担这两项任务，本质上就是一种妥协。

我们后来踩过一个更极端的坑：某客户要求全部采用"语义分块"，结果向量数量增加了4.2倍，月度成本从6000元涨到25000元，平均chunk大小降到了38个token——检索准确率反而下降了12%。原因很简单：chunk太小，每个chunk携带的语义信号太弱，embedding根本表达不出有意义的信息。

我们现在的做法： 语义切分（按段落/标题/表格边界切）+ 滑动窗口重叠（20-50%重叠保留上下文边界）+ 父子文档检索（检索时返回子chunk做匹配，但同时附带父级完整文档作为上下文）。对于表格数据，单独建立处理管线，保留行列结构，将表格转化为结构化描述或Markdown格式，必要时为表格生成自然语言摘要，摘要和结构化数据同时索引。

光是调整chunk策略，那批高海拔相关问题的准确率就从30%提到了70%。

嵌入模型（Embedding）——通用模型在垂直领域经常翻车

我们试过好几个通用embedding模型，在通用场景表现还行，但在垂直领域经常出问题。

那个制造业客户内部文档里把某设备简称为"K3机"，但用户提问时写的是全称"KX-3000型智能控制器"。通用embedding把两者算成了低相似度，检索直接漏掉了。

但这还不是最严重的问题。嵌入模型有一个更底层的缺陷： 有损压缩 。

嵌入模型将一整段文本压缩为固定维度的向量（比如768维），这是一种有损压缩。当把一个长而细致的段落压缩为768个浮点数时，语法信息、否定关系、特定实体关系都会丢失。有研究发现，同义句（如"已取消订单"vs"订单未被确认"）在256维嵌入下的余弦相似度从0.82骤降到0.41，而逻辑对立的表达（“禁止吸烟"vs"不反对吸烟”）相似度却异常升到0.76。

这意味着： embedding模型在处理否定、对比、条件限定等逻辑关系时，天然就是弱的。 而企业文档中恰恰充满了这类表述——“在海拔超过2000米时”“除XX型号外”“当且仅当”。

还有一个容易被忽视的问题： 向量漂移（Vector Drift） 。当embedding模型升级后（比如从text-embedding-ada-002升级到text-embedding-3-large），新旧向量不在同一个语义空间，混在一起检索，结果近乎随机。我们在一个项目上踩过这个坑——客户升级了模型但没重建索引，排查了两天才发现问题。

检索方式——纯向量检索的盲区

向量检索擅长语义匹配，但不擅长精确匹配。当用户问的是产品型号、参数值、日期等精确信息时，向量检索经常失准。

举个例子：用户搜索"error code ERR-4012"，纯向量检索可能返回一篇"通用错误处理指南"，因为语义上"错误处理"和"error code"确实相关——但用户要的是ERR-4012这个特定错误码的解决方案。

还有一个更隐蔽的问题： 向量相似度只能找到数学上相似的文本，无法提供判断准确性所需的元数据。 比如法律团队问"Johnson Industries合同的责任限额是多少？“，向量搜索找到了"责任每年不超过500万美元”（相似度0.94），但系统无法知道这是2019年的合同还是2023年的修正案，是母公司的条款还是子公司的条款，是否有后续条款修改了这个限额。

我们现在的标准配置是混合检索（向量+BM25关键词）+ Reranker精排。 向量负责语义匹配，BM25负责关键词精确匹配，Reranker从Top20里精排选出Top3。这套组合在我们最近几个项目里，检索准确率稳定在90%以上。

这里展开讲一下Reranker为什么这么重要。向量检索用的是Bi-Encoder架构——查询和文档分别编码为向量，然后计算余弦相似度。这种方式快，但查询和文档之间没有真正的"交互"。Cross-Encoder Reranker则不同，它把查询和文档拼接在一起输入模型，让模型真正"阅读"这对文本，给出一个相关性分数。精度高得多，但速度慢得多——所以不能用来直接检索百万级文档，只能用来对Top20-50的候选结果做精排。

两阶段架构（快速召回+精排）是目前生产级RAG的标配。

理解层：模型"看到了但没看懂"

检索层解决了"给模型什么"的问题，理解层解决的是"模型能不能用好给它的东西"。

上下文窗口污染——"大海捞针"问题

我们做过一个对比实验，结果让我很意外：

方案	配置	模型回答准确率
A	返回Top10 chunks	67%
B	返回Top3 chunks（加reranker精排）	84%
C	返回Top1 chunks（最精确的那条）	78%

不是给模型越多信息越好，而是越精准越好。Top10里有大量噪声，模型的注意力被稀释了，真正关键的那1-2条反而被淹没。Top3加精排的效果反而最好——信息够用，噪声可控。

这就是业界常说的"大海捞针"（Needle in a Haystack）问题：当上下文窗口里塞满了不相关信息时，模型可能无法精准定位到其中真正有用的关键信息。更糟糕的是，检索到的信息总量如果超过模型的上下文窗口长度，关键信息会被直接截断，完全丢失。

Prompt设计的隐性差异

很多客户以为prompt很简单，"不就是写几句话吗？"但我们实测下来，同一组上下文，不同prompt的效果差异巨大：

Prompt写法	准确率
“请回答以下问题”	约40%
“请基于以下上下文回答”	约55%
“请仅基于以下上下文回答。如果上下文中没有相关信息，请回复’根据现有资料无法回答’”	约75%
上面那句 + “请在回答中标注引用来源（文档编号）”	约85%

从40%到85%，改的不是模型，是prompt。这也是为什么我们现在每个项目都会花专门的时间做prompt工程——它是ROI最高的优化手段，成本几乎为零。

但prompt工程能解决的问题是有限的。它本质上是在做"约束"——约束模型的行为边界。当约束不够时，模型会回归它的"固有倾向"。

模型的固有倾向——参数知识压制检索证据

这个坑我们踩过一次，印象深刻。某客户的保修政策在2024年从1年更新为2年，文档已经更新入库了，但模型回答时仍然说"保修期为1年"。

排查后发现：模型训练数据里的知识是旧的，它更"相信"自己的参数知识，而不是检索到的上下文。这种现象在学术上叫做 “知识脱节”（Knowledge Disconnect） ——模型基于预训练知识生成文本的倾向性极强，可能压制检索到的外部证据。

解法不复杂——在prompt里明确加一条指令："当上下文中的信息与你的已有知识不一致时，以上下文为准。"但你得先意识到这个问题存在，才能去解它。

还有一个更棘手的情况： 多跳推理失败。 当回答一个问题需要组合多条检索信息时（比如"2025年Q3由于政策变更导致的合规性变动有哪些"），模型需要跨文档、跨段落建立关联，但传统RAG架构将检索片段视为独立的"事实孤岛"，模型缺乏对跨文档逻辑链条的理解能力。这也是GraphRAG（图检索增强生成）技术兴起的核心原因——后面第五章会展开讲。

生成层：理解了，但"自由发挥"

这是最隐蔽的一层。检索没问题，理解也没问题，但模型输出的时候"加了点料"。

编造细节——最危险的情况

模型基于上下文给出了一个大致正确的回答，但在细节处"合理地"编造了一些上下文中不存在的信息——产品编号、参数值、引用条款。因为编得"很合理"，客户和测试者都不容易发现。

有一次我们的系统回答了一个售后流程问题，整体流程是对的，但里面引用了一个条款编号"第3.2.1条"——客户翻遍了文档，找不到这个条款。后来查日志发现，上下文里确实没有这个条款编号，是模型自己"补"上去的，而且补得格式完全正确。

学术研究显示， 即使在检索结果准确的情况下，模型的faithfulness分数（忠实度）可能从0.91跌到0.67，意味着每三个回答中就有一个在提出检索上下文不支持的主张。 这种情况比"答非所问"危险得多，因为用户可能直接拿这个错误答案去执行。

答案粒度失控

客户要精确数据，模型给了概括性描述。客户要步骤列表，模型给了段落叙述。这不算"错"，但客户感知就是"不准确"。

多轮对话的上下文漂移

客服场景特别明显。第一轮检索准确，但随着对话深入，用户的指代（“那款设备”“刚才说的那个参数”）让检索越来越偏。我们实测过，第三轮之后，准确率通常会下降20-30个百分点。

运维层：之前对的，现在不准了

这一层是最容易被忽视的，但对生产系统的长期可靠性影响最大。

数据腐烂（Data Rot）

斯坦福HAI研究院的实验揭示了一个残酷的事实： 当知识库中15%的文档过期时，RAG回答错误率会飙升至67%。 而在受监管行业（如医疗、金融），数据腐烂可能导致严重的合规风险。

我们有一个客户，知识库上线时准确率85%，半年后掉到了60%出头。排查发现：期间有30多份文档更新了，但知识库没有同步更新。更麻烦的是，新旧版本同时存在于知识库中，模型随机引用，答案自相矛盾。

向量漂移

前面提到过，embedding模型升级后，新旧向量不在同一个语义空间。如果只更新了部分文档的向量而没有全量重建索引，检索结果会变得混乱。

评估缺失

很多团队不知道如何科学地、自动化地评估一个RAG系统的好坏。当用户反馈"答案不对"时，很难定位问题究竟出在检索环节还是生成环节。没有评估体系，所有优化都是盲人摸象——你不知道自己改完之后到底变好了还是变差了。

04 坑点：只有做过项目才知道的坑

前面三章讲的是技术层面的问题。但做过项目的人都知道，真正让项目翻车的，往往不是技术问题。

数据层的坑——“80%的问题根源在数据”

坑	我们踩过的场景	正确做法
PDF解析丢表格	客户的技术规范里大量参数以表格形式存在，通用PDF解析工具直接把表格内容变成乱码，关键参数全丢了	用专门的解析工具（如Unstructured、Docling），表格单独处理
OCR引入错别字	客户有一批扫描件，OCR把"压力阀"识别成了"压力阀"（字形相近），检索时关键词匹配直接失败	OCR后做自动纠错+人工抽检，关键术语做白名单校验
过期文档没清理	知识库里同时存在2022版和2024版产品手册，模型随机引用，答案自相矛盾	文档入库时加版本标签和生效时间，检索时按时间排序
重复文档	同一份技术规范存了三个版本（Word、PDF、扫描版），检索结果被重复内容占据	入库前做去重（指纹哈希+语义去重）
文档权限没隔离	有些文档只对特定角色可见，但检索时没做权限过滤	检索层加权限过滤，按用户角色控制可见范围
视觉信息丢失	客户文档中60%以上包含图表、流程图、产品图片，纯文本RAG系统"看不见"这些内容	引入多模态RAG（如ColPali），直接以视觉方式处理文档页面

我现在跟客户谈项目，第一句话一定是："我们先看数据。"数据质量不过关，后面所有优化都是空中楼阁。

评估层的坑——“没有度量就没有改进”

最常见的坑是"肉眼测了几个case觉得还行"。我们早期也这样，挑了十几个问题测一下，效果不错就交付了。上线后翻车。

现在我们每个项目必须构建系统化评测集：至少200个问题，每个问题标注期望引用的文档和期望答案的关键要素。没有评测集，所有优化都是盲人摸象。

这里分享一个我们现在的评估框架—— RAG Triad（三元组评估） ，这是目前业界比较成熟的评估方法：

维度	评估内容	核心指标
Context Relevance（上下文相关性）	检索到的上下文与查询的相关程度	Precision@k, Recall@k, nDCG
Faithfulness（忠实度）	生成内容对检索证据的忠实程度	幻觉率、事实一致性
Answer Relevance（答案相关性）	答案对用户原始意图的回应程度	用户满意度、任务完成率

三个维度缺一不可。只看检索指标，你不知道模型有没有用好检索结果；只看生成指标，你不知道是检索的问题还是生成的问题。 三个维度一起看，才能精准定位问题在哪一层。

项目管理的坑——乙方视角特有的问题

这些坑和技术无关，但对项目成败的影响比技术大得多。

Demo≠生产。 客户看完Demo觉得"已经很好了"，不愿意再投入做优化。我现在Demo前就跟客户明确：Demo是验证方向，不是交付标准。准确率基线要在真实数据+真实问题上建立，不是在精心挑选的case上建立。

"准确"的定义不一致。 技术团队觉得"答案包含关键信息就算对"，业务方觉得"要跟标准答案一字不差才算对"。我们在一个项目上因为这个问题吵了两周。后来的解法是：项目启动时就定义清楚"准确"的评判标准，双方共同标注一批case作为校准基准。

客户期望管理。 很多客户觉得"上了RAG就万事大吉"，系统上线后知识库没人更新，准确率逐月下降。我们现在的交付物里一定包含"运营手册"和"监控看板"，明确客户侧的日常维护职责。不然后面出问题，客户还是会找你。

05 解法：从能用到好用

按投入产出比排序，不是按技术难度排序。你最想知道的一定是"先做什么最划算"。

速赢方案

方案	预期提升	实施难度	说明
Prompt工程	准确率提升10-20%	★	加拒绝机制、引用溯源、答案格式约束、上下文优先于参数知识的指令
TopK调优	准确率提升5-15%	★	从Top10降到Top3-5，减少噪声
相似度阈值过滤	减少幻觉15-25%	★	设置最低相似度阈值，低于阈值的结果直接丢弃，避免用无关内容强行生成

这三项加起来，基本能解决你当前30-40%的准确率问题。成本几乎为零，今天改今天生效。

中期方案

方案	预期提升	实施难度	说明
混合检索（Hybrid Search）	准确率提升15-25%	★★	向量检索+BM25关键词检索并行，用RRF（Reciprocal Rank Fusion）融合结果
Cross-Encoder Reranker	准确率提升10-20%	★★	对Top20-50候选结果精排取Top3-5，推荐Cohere Rerank 3.5或开源的ms-marco-MiniLM
构建评测集（RAG Triad）	不直接提升，但让所有优化有据可依	★★	200+问题，标注期望答案，建立Context Relevance+Faithfulness+Answer Relevance三维评估
数据清洗+元数据治理	准确率提升10-15%	★★	去重、纠错、过期文档标记、版本控制、为文档添加时间戳/来源/权限等元数据

这四项是我们现在每个项目的标配。做完之后，大部分场景的准确率能到80-85%。

这里重点讲一下混合检索为什么比纯向量检索好这么多。

纯向量检索的问题在于：它只看语义相似度，不看关键词精确匹配。当用户搜索"error code ERR-4012"时，向量检索可能返回一篇"通用错误处理指南"——语义上相关，但不是用户要的。BM25关键词检索则能精确匹配到"ERR-4012"这个字符串。

但BM25也有盲区：用户说"发烫"，文档里写的是"温度异常"，BM25匹配不到。

混合检索把两者的优势结合起来了：向量负责语义匹配，BM25负责精确匹配，然后用RRF或学习权重把两路结果融合。 2026年所有主流向量数据库（Milvus、Pinecone、Qdrant、Weaviate）都原生支持混合检索，接入成本很低。

深度方案（长期投入，适合核心业务场景）

方案	预期提升	实施难度	说明
领域Embedding微调	准确率提升15-30%	★★★	用业务数据微调embedding模型，解决行业术语理解问题
父子文档检索（Parent-Child）	准确率提升10-20%	★★★	检索子chunk做匹配，附带父级完整文档作为上下文
Query改写（HyDE）	准确率提升10-15%	★★★	用LLM先生成假设答案，再用假设答案做检索查询，在RAGTurk基准上达到85%准确率（基线78.7%）
GraphRAG（知识图谱增强）	复杂问题准确率提升20-40%	★★★★	将实体关系构建为知识图谱，支持多跳推理和跨文档关联
Agentic RAG（智能体RAG）	复杂问题准确率提升20-40%	★★★★	多步检索+自验证+迭代查询，Agent自主决定何时检索、检索什么、检索几次
多模态RAG（ColPali/VisRAG）	视觉类文档准确率提升30-50%	★★★★	跳过OCR，直接将文档页面作为图像进行嵌入和检索

这些方案投入大，但对垂直场景效果显著。建议先用速赢和中期方案把准确率拉到80%以上，再看剩余的薄弱环节在哪里，针对性引入深度方案。

这里重点展开讲两个2026年最有突破性的方向：

GraphRAG 的核心思想是：不再把文档视为孤立的文本块，而是从中抽取实体和关系，构建知识图谱。当用户提问时，系统不仅做向量检索，还在知识图谱上做图遍历，找到跨文档的关联信息。这对需要多跳推理的问题（比如"找出所有与该项目相关的合同及其修订版"）效果显著。研究显示，GraphRAG在医疗、法律和金融等对逻辑链条要求极高的行业，可将准确率平均提升54.2%。

Agentic RAG 的核心思想是：从被动检索转向主动决策。传统RAG是"查一次、生成一次"的固定管线，Agentic RAG则让AI Agent自主决定何时需要检索、检索什么、检索几次、是否需要补充搜索。如果首次检索结果不理想，Agent会自动重新表述查询、切换检索工具、甚至触发多轮检索。Self-RAG模型通过特殊的"反思Token"（如 IsREL 相关度、 IsSUP 支持度、 IsUSE 实用度）让模型自我评估，如果发现证据不足，会拒绝回答而非强行编造——这直接将幻觉率从14%降到了5.8%。

我们现在的项目标准流程

第一步：数据体检
  → 文档数量、格式分布、质量抽检、权限梳理、元数据梳理
  → 输出：数据质量报告

第二步：构建评测集（RAG Triad）
  → 与客户业务团队共同定义200+问题
  → 标注期望引用文档和期望答案关键要素
  → 建立Context Relevance + Faithfulness + Answer Relevance三维评估
  → 输出：评测基线（当前准确率）

第三步：速赢优化
  → Prompt工程 + TopK调优 + 相似度阈值过滤
  → 用评测集验证效果

第四步：检索优化
  → 混合检索 + Reranker + Chunk策略调整 + 元数据治理
  → 用评测集验证效果

第五步：按需引入深度方案
  → 根据评测结果定位剩余薄弱环节
  → 针对性选择（微调/GraphRAG/Agentic/多模态）

第六步：交付与运营移交
  → 运营手册 + 监控看板 + 知识库更新流程
  → 明确客户侧的日常维护职责
  → 建立持续评估机制，定期回归测试

前三步做完，大部分项目准确率能从60%左右拉到85%以上。这是我们十几个项目验证过的路径。

06 总结：你无法优化你无法衡量的东西

回头看一下，这篇文章其实就讲了四件事：

第一，RAG不准确是链条上的累积误差。 检索、理解、生成、运维，每一层偏一点，最终结果就差很远。不要只盯着一个环节优化。2026年的数据很残酷——28%的文档已过时，22%的政策相互矛盾，19%的知识散落各处。模型再强，喂给它的数据是烂的，结果就是烂的。

第二，先建评估体系，再做优化。 RAG Triad（上下文相关性、忠实度、答案相关性）三维评估是目前最成熟的框架。没有评测集，你不知道自己到底在优化什么，也不知道优化完之后到底变好了没有。这是我们交了最贵学费学到的一件事。

第三，80%的准确率问题不需要换模型。 混合检索+Reranker+Prompt工程+数据治理，这四件事做好，大部分场景就够用了。别被"换个更强的模型就能解决"这种话忽悠了。从GPT-4o换到Claude 4，对准确率的提升可能只有5%；但把Top10降到Top3加Reranker，提升可能是15-20%。

第四，RAG正在从"检索+生成"的简单管线，演进为"图谱+智能体+多模态"的复合架构。 GraphRAG解决跨文档推理问题，Agentic RAG解决自适应检索和自我纠错问题，ColPali/VisRAG解决视觉信息丢失问题。2026年，这三个方向正在从实验室走向生产。但对大部分企业来说，先把基础的混合检索和数据治理做好，比追新技术重要得多。

做了十几个RAG项目，我最大的体会是：

客户以为最难的是选模型，实际上最难的是洗数据。你以为最难的是洗数据，实际上最难的是跟客户对齐"什么算准确"。而你真正应该最先做、也最容易被忽视的事，是建评估体系——你无法优化你无法衡量的东西。

你们的RAG项目遇到过哪些"不准确"的坑？最后是怎么解决的？或者，你正在被准确率问题困扰，卡在哪一步了？评论区聊聊，说不定能互相帮到。