检索增强生成（RAG）一度被当成「解决幻觉」的标准答案：先找文档，再按文档回答。2026 年的新研究却把问题说得更尖锐——模型忠实于检索到的内容，并不等于答案正确；当知识库本身被污染、过时或自相矛盾时，「只信文档」反而可能把本来答对的问题改错。

评测里常被忽略的假设

多数 RAG 评测默认知识库是干净的：检索命中相关段落，再量 faithfulness（答案是否贴合检索上下文）、answer relevancy、context precision / recall。这套指标对「流水线有没有按设计工作」很有用，但对「业务事实对不对」不够。

原因很直接：

  • Faithfulness 对的是检索上下文，不是客观真相。上下文错了，忠实复述也会错，而且分数依然漂亮。
  • 干净检索会掩盖鲁棒性差异。模型在理想语料上表现接近，一旦知识库出现事实篡改、数字笔误、相关但误导的段落、或显式矛盾，差距才会拉开。
  • 「无检索准确率」推不出「脏检索下的稳健性」。闭卷答得好，不代表面对错误证据时懂得拒绝。

近期出现的 RAGStress / RAG-Stress 一类压力测试，正是为了把这些假设拆开：固定问题与参考答案，系统性地腐蚀知识库或证据句，再观察模型何时被带偏。

「只依据文档」为何会更糟

很多团队的默认提示是：优先或仅根据检索到的文档作答，禁止使用模型先验知识。动机合理——想压住胡编。但诊断实验给出了反直觉结果：

在模型本来闭卷就能答对的题目上，强制「文档优先」会显著提高 misleading rate（被错误证据改口的比例）。跨多套 QA 数据与十余种系统，严格「只信文档」相对允许结合先验知识的指令，平均误导率高出约 11–14 个百分点量级。

更细的一点：错误断言出现在证据文本的末尾时，往往比出现在开头或中间更容易被采纳。这对长文档截断、重排后拼接、以及「最后一段摘要」式拼装都有工程含义——你以为提高了 grounding，其实在放大最后一段的话语权。

换句话说：服从证据 ≠ 可靠。评测若只奖励「跟文档走」，会把「扔掉正确答案、改信坏证据」也算成成功。

落地时该拆开量什么

与其追逐单一 faithfulness，不如把评测拆成几层，且接受它们回答的是不同问题：

  1. 检索层：相关文档是否进了 top-k？有没有过时版本、重复副本、权限越界内容？
  2. 生成层：答案是否覆盖问题、是否引用了被检索到的关键断言？
  3. 知识库健康度：事实是否可追溯、是否有矛盾条目、更新延迟有多长？
  4. 抗污染能力：在故意注入错误/矛盾证据时，模型是坚持正确先验、请求澄清，还是顺从地改口？

开源评测栈（如 RAGAS、TruLens、DeepEval）擅长推理层的参考无关打分，但它们区分不了「忠实于错误上下文」与「忠实于正确上下文」。业务侧仍需要：抽样人工核对、关键字段的结构化校验、以及针对污染场景的回归集。

硬件与时延侧也在补课。MLPerf Inference 等基准开始把整条 RAG 流水线（索引、检索、重排、生成）端到端计时——提醒采购方：只加速生成，往往吃不满整条链路的收益。评测产品可靠性和评测吞吐，最好不要混成一张表。

可执行的工程建议

  • 提示词留一条退路：允许模型在证据不足、冲突或明显异常时拒绝作答，或标明「文档与已知常识冲突」。
  • 证据位置做消融：同一错误句放在开头/中间/结尾，看线上策略是否被尾部绑架。
  • 把「坏知识库」纳入 CI：不只测黄金文档，也测轻微篡改、过期版本、相关毒药段落。
  • 业务指标与 LLM-as-judge 并行：订单号、金额、政策生效日等，用确定性校验；叙述性部分再用裁判模型。
  • 区分「不能编」和「不能信错」：前者靠 grounding，后者靠冲突检测、多源交叉与人工闸门。

小结

RAG 没有过时，但它不再是「接上向量库就消除幻觉」的故事。2026 年更清楚的共识是：评测必须同时问「检索帮没帮忙」和「坏证据来了会不会更惨」。忠实于错误来源，比坦率说不知道更危险——尤其是在客服、合规与内部知识助手这类高信任场景。

下一篇可以继续拆：知识库新鲜度 SLA、冲突检测策略，以及何时该上 Agent 式多步检索而不是单次 top-k。