为什么你的 RAG 引用在撒谎：源归因中的事后合理化

向用户展示一个带有 AI 答案的界面，且每句话末尾都附有链接，还没等他们读完任何一个引用的段落，他们的信任度就已经飙升。这正是企业级 RAG 的全部营销卖点：“有据可查”、“有源可循”、“可验证”。这也是 AI 工程领域中交付最多、但测试最少的说法。最近的基准测试发现，50% 到 90% 的 LLM 回复并未得到其引用来源的完全支持，有时甚至与来源相矛盾。在对抗性评估集中，最先进模型生成的引用中有高达 57% 是不忠实的：模型根本没有真正使用它指向的文档。这些引用是事后补上去的，目的是为了让模型已经决定给出的答案显得合理。

这不是检索层面的 Bug。即便你拥有完美的检索系统，仍然会得到虚假的引用，因为这种失效是架构性的。生成器先写出文字，然后再缝补链接。这些链接看起来像证据，实则只是装饰。

业界一直过度关注引用的文档是否相关，却忽略了一个更令人不安的问题：引用的**片段（span）**是否真的蕴含了它所关联的论点？在生产规模下，答案通常是否定的。而且你的 UI 把引用做得越精致——角标注释、悬停预览、彩色高亮——用户就越会果断地停止检查。

正确性不等于忠实度

研究界终于在企业级 RAG 产品混为一谈的两个概念之间划清了界限：引用的正确性（correctness）和引用的忠实度（faithfulness）。

• 正确性考量的是：引用的文档是否支持该陈述？你可以通过自然语言推理 (NLI) 模型来衡量，询问“段落 P 是否蕴含论点 C？”
• 忠实度考量的是：模型是否真的从引用的文档中推导出了该论点，还是说模型先根据参数记忆生成了论点，然后去猎取一个看起来兼容的段落？

一个事后合理化的引用在输出层面与忠实的引用是无法区分的。它甚至在技术上可能是“正确”的——段落确实支持论点——但模型在生成答案时忽略了该段落。这使得整个信任链条变成了一个“隐瞒真相的谎言”。用户（或下游代理）假设检索到的证据驱动了答案。事实并非如此。驱动答案的是模型的预训练，而检索只是“演戏”。

这一点至关重要，因为这种失效模式是无声的。如果你的生成器自信地断言了一些看似合理的事情，附上了一个看起来很真实的引用，且引用的片段与主题大致相关，那么任何“检查来源”的 UI 设计都无济于事。人类会略读，代理会将通过的链接视为确认。幻觉在引用这一步被“洗白”了。

架构如何固化了谎言

看看大多数 RAG 流水线是如何构建的，事后合理化就变得可以预见，甚至几乎是不可避免的。

主流模式是先生成再检索后引用 (generate-then-retrieve-then-cite) 或 先检索再生成后引用 (retrieve-then-generate-then-cite)。在这两种模式中，先运行检索，再运行生成，然后是第三步——通常是一个单独的提示词，有时是一个单独的模型——为已经写好的文本分配引用。等到引用步骤运行时，生成器与任何特定段落之间已经没有了机械上的联系。它根据 (提示词指令) × (参数记忆) × (松散关注的检索上下文) 的混合分布选择了 Token。引用器随后做了它唯一能做的事：将输出的每个句子与最接近的检索上下文块进行相似度匹配。“最接近”并不代表“因果关系”。

那个架构上的接缝就是忠实度丧失的地方。最近对比“生成时引用 (G-Cite)”与“事后引用 (P-Cite)”的研究发现，这种权衡早已植根于设计之中：P-Cite 实现了更高的引用覆盖率（它几乎能为任何论点找到某个匹配的段落），但语义精准度较低；而 G-Cite 在解码过程中就选定了证据，对于引用的内容更加吝啬。在 FEVER 事实核查任务中，G-Cite 达到了 94% 的正确性，但覆盖率仅为 27%；P-Cite 则在 75% 的正确性和 75% 的覆盖率之间取得了平衡。覆盖率是营销所需要的——每个句子都有脚注；精准度才是用户所需要的。

另一个架构上的罪魁祸首是块级检索 (chunk-level retrieval) 与句级引用 (sentence-level citation) 的配对。你的检索器返回一个 512 token 的块，生成器写一个句子，引用器把该块的 ID 钉在句子上。这个块包含十二个论点，其中只有一个（可能）支持写下的句子。用户看到“[3]”并点击；他们跳转到一个包含关键词的段落；他们的大脑将该论点归类为“有据可查”。没有人验证过他们阅读的具体句子是否被所引用块的特定片段所蕴含。这就是为什么子句级和片段级引用的研究在近期呈爆发式增长的原因——粗粒度的指向在功能上无异于误导信息。

引用忠实度评估 (The Citation-Faithfulness Eval)

测量层面的修复方法是：停止将“是否有引用？”视为通过/失败的检查，并开始将引用级蕴含（citation-level entailment）视为一级评估（first-class eval）。

一个极简流水线：

• 将回答分解为原子主张（每个主张是一个可验证的断言）。
• 针对每个主张，提取被引用的文本段（span），而不仅仅是被引用的文档。
• 运行一个 NLI（自然语言推理）模型：被引用的文本段是否蕴含该主张？标记为 SUPPORTS（支持）、CONTRADICTS（矛盾）或 NEUTRAL（中立）。
• 汇总为引用精确率（实际产生蕴含关系的引用比例）和引用召回率（拥有至少一个蕴含引用的主张比例）。

这是 ALCE 等基准测试的骨架，它使用 NLI 模型自动检查引用的段落是否蕴含生成的文本。在金丝雀测试集（canary set）上运行它的成本很低，但揭示的事实却很残酷。第一次安装此评估方案的团队通常会发现，他们“生产就绪”的 RAG 系统在引用精确率方面仅在 40-60% 之间——这意味着大约有一半的脚注主张是由一个实际上并不支持它们的段落支撑的。

值得注意的两个陷阱：

1. NLI 模型有其自身的误差特征。 它们在处理部分支持、数字主张以及偏离主张的长文本段时表现挣扎。要将评估视为信号，而非真理（oracle）。在可能的情况下，在边界案例上叠加一个更强大的 LLM-as-judge（大模型作为评判者），并对小样本进行人工抽检，因为评判者会与生成器共享失效模式。
2. “引用的文档包含答案”是不够的。 如果你的评估只检查文档级的相关性，那么你衡量的是检索质量，而不是引用的忠实度（faithfulness）。文本段（span）很重要。主张与文本段的对齐（alignment）很重要。

还有一种针对严格意义上忠实度的独立评估——即模型是否真的使用了检索到的文档。最严谨的探测方法是换入修改过的或反事实的文档，观察答案是否改变。如果没有改变，说明模型是在依靠参数化记忆（parametric memory）运行，无论你的引用是否碰巧正确，它们都是表演性的。

真正有效的架构修复方案

衡量问题并不等同于解决问题。架构上的修复方案可以归纳为一个短列表，大致按对现有技术栈的干扰程度排序。

生成即引用，而非生成后引用。 强制模型在解码支持该主张的同一过程中输出引用——理想情况下采用交错模式，如 主张 → 引用 → 主张 → 引用。这将引用与产生该主张的隐藏状态（hidden state）联系起来，而不是要求下游步骤去猜测生成器当时在“想”哪个文档。像 ReClaim 及其后续方法通过结构化输出语法来实现这一点，并在模型输出没有配对引用的主张时给予惩罚。

基于检索段落的受限解码。 最强版本：在引用位置，解码器只能输出作为检索语料库中连续文本段存在的标记（tokens）。在段落标记上建立前缀树（prefix tree）使得这在推理时是可强制执行的。最终你会得到引用证据，其来源是机械性的而非虚构的。代价是生成器在引用处不再能自由地改写（paraphrase），但这种约束正是目的所在——改写正是忠实度泄露的地方。

段落级（Span-level）和子句级引用。 停止将脚注固定到整个数据块（chunks）上。以标记级（token-level）偏移量存储段落。输出指向特定段落内 3-30 个标记组成的文本段的引用。在 UI 中显示突出显示的文本段，而不是整个块。用户实际上会验证段落级引用，因为认知负荷很低；他们永远不会验证块级引用，因为扫描一个 512 标记的段落来寻找相关性是没人愿意干的活。

将引用模型与生成器分离。 一个经过专门训练、仅执行段落级 NLI 的较小专用模型，比生成器反射性地匹配主张与证据更加可靠。使引用分配成为一个专门的、可审计的步骤，而不是系统提示词中的事后想法。这看起来像 P-Cite，但与幼稚的 P-Cite 不同，它强制执行蕴含（entailment）而非相似性（similarity）。

当蕴含关系薄弱时拒绝引用。 这是一个文化层面的修复。大多数系统都被调校为总是提供引用，因为缺少引用在演示（demo）中看起来很糟糕。反转这一策略：缺少引用是诚实不确定性的信号。在 UI 中添加一个“未找到支持段落”的分支——将其渲染为可见而非隐藏——比伪造脚注更能维护信任。

为什么不合格的产品仍在不断交付

如果研究已经如此明确，修复方案也如此为人熟知，显而易见的问题是为什么企业级 RAG 仍然在带着不忠实的引用不断出货。三个原因不断浮现。

首先是评估的不对称性。团队衡量检索召回率、答案正确性和延迟。他们很少衡量引用段落的蕴含关系，因为它需要第二个评估套件和一个大多数团队从未部署过的 NLI 模型。被衡量的事物才会被修复。

其次是演示激励。带脚注的回答看起来很权威。在采购演示中，“这是我的答案 [1] [2] [3]”与“这是我的答案——我无法在提供的语料库中找到此主张的依据”之间的区别，就是签下合同与等待后续会议的区别。在买家开始要求提供引用忠实度数据之前，供应商没有动力公开这些信息。

第三是失败的非对称成本。一次缺失的引用会导致演示失败；而一个错误的引用会在几周后私下影响用户，且处于供应商永远看不到的情境中。引用忠实度的反馈循环很长且弥散，很少能到达工程端。因此，这个 Bug 依然存在。

周一该做什么

如果你在生产环境中运行 RAG 系统，且从未衡量过引文片段蕴含（citation-span entailment），请假设你的引文精准度在 40% 到 70% 之间。按顺序执行以下三件事：

• 构建一个小型的 Canary 评估——100 到 200 个查询，包含人工验证的答案和人工验证的支撑片段。使用 NLI 模型（或带有严格蕴含准则的 LLM-as-judge）来为引文精准度和召回率打分。在每次提示词变更和模型升级时运行它。
• 审计你流水线中生成与引文之间的架构缝隙。如果引文是在生成之外的独立步骤中分配的，那么你几乎肯定是在进行事后合理化。将引文移入解码循环中，即使你必须切换到交错输出格式。
• 将粒度细化到片段（Span）。存储带有偏移量的检索结果。将引文渲染为高亮片段，而非 Chunk ID。让用户能一眼验证；他们会这么做，你的评审会议也会如此。

“我们引用了来源”是企业级 AI 最常断言、却最少测试的说法。将这种比例反转——从信任的表演转向信任的证据——是将那些经得起审视的 RAG 产品，与那些用户在私下停止信任的产品（通常在他们向供应商坦白前几个月就已经不再信任了）区分开来的关键工作。