依据一致性

它是什么

依据一致性衡量的是一段输出里的主张有多少能被给定资料支持。做法很直接：把回答拆成一条条可以单独判断真假的主张（claim），再逐条回到提供的资料里找支持。[S1]

它有两个容易说错的边界。第一，它衡量的是关系，不是绝对值——同一段话，给十份资料和给一份资料，「有依据」的结论完全不同。第二，它只在有资料的前提下成立：纯靠模型内部知识生成的回答，谈不上「一致于什么」，那属于幻觉范畴而不是依据一致性问题。

为什么需要它

因为在检索增强生成这类系统里，最危险的失败不是「不知道」，而是看起来知道。模型即使拿到了资料，也可能给出资料里没有的细节——参数、日期、条款编号——而语言层面完全看不出来。

这类错误之所以必须单独度量，是因为它同时躲开了两个常用的检查：

• 准确率检查躲开它：如果评测只统计「整条答对/答错」，一段大半正确、末尾夹一句编造的回答会被判为错，但团队拿不到「错在哪类」的信息；而如果那句编造恰好落在没人测的字段上，它就会被记为对。
• 人眼抽查躲开它：流畅、结构好、术语正确的回答最容易通过抽查，编造部分恰恰是「最像真的」那一段。

把回答拆成主张逐条核对，是唯一能稳定抓到它的方式。它也是评测集里那类「编造」题目的判定依据。

它如何工作

把一段回答拆成主张的过程，大概是三步：

1. 断句去连接词：把「因此」「综上所述」这类连接去掉，只留下可以单独判断真假的内容。
2. 逐条标注支持关系：对每条主张，在资料里找出支持它的片段。标注结果通常有三档——有直接支持（资料里明确写了）、可推断（需要一步推理，例如资料给了两个数字、结论是二者之和）、无支持（资料里找不到）。
3. 算比例并提出问题所在：支持比例是一个总分，但更有用的是那些「无支持」的条目长什么样——它们往往集中在同一类字段上（数字、日期、专有名词），指出来的是一处可修的漏洞，而不只是一个分数。

工程上有两种落地方式：人工抽样核对（准确、贵，适合建立基线）与模型辅助判断（便宜、需要校准，适合日常监控）。可行的组合是先用人工核出一批标准，再用它校准自动判断的可信度。

值得单独记住的一条：「可推断」这一档是最容易高估的。它给了标注者解释空间，「我觉得可以推出来」会让支持比例虚高。实践中要规定推理步数上限（例如只允许一步），否则这个维度就会慢慢失去指示能力。

必须澄清的误会

依据一致性 ≠ 幻觉。 幻觉是一个现象描述——模型生成了不实内容；依据一致性是一个可测维度——答案里的主张有多少被证据支持。差别在两个地方：其一，现象无法直接度量，维度可以；其二，在没有提供资料时，依据一致性根本不适用，而幻觉依然会发生。把两者当同义词，会导致在纯生成任务里也去「量依据」，然后发现无从下手。

依据一致性 ≠ 检索精确率。 检索精确率衡量的是「召回的片段里有多少是相关的」，是检索环节的指标；依据一致性衡量的是「回答里的主张有多少被这些片段支持」，是生成环节的指标。检索很准而回答仍在编，是完全可能的——资料就摆在那里，模型没用。反过来，检索召回了一堆噪声，模型也可能靠常识给出正确答案，但这时它「有依据」的说法是不成立的。

高依据一致性 ≠ 答案正确。 如果资料本身错了，回答可以既「有依据」又「完全错」。这个维度只回答「有没有用给的资料」，不回答「资料对不对」。评估结论必须两句话连着说：依据一致性告诉我们它有没有编，资料正确性要靠另外的手段保证。

还有一条实践中的反直觉结论：提升依据一致性的主要手段不是把提示词写得更严厉。 反复强调「必须基于资料」能改善一部分，但更有效的是让答案带上可核查的出处（引用生成）——当每条主张都要指出依据在哪一段时，编造的成本会明显上升，同时核查也变得可行。

真实例子

一条 RAG 回答：「根据第三条，甲方应在收到发票后 30 日内付款；若逾期，按每日千分之五计息；该条款适用所有分期付款订单。」

拆成三条主张后逐条核对：第一条在资料里有支持；第二条有支持；第三条在资料里找不到任何依据，而它恰好是整个回答里最有决策影响的一句——用户据此可能认为所有分期订单都适用。[S1][S2]

这就是依据一致性的典型用处：支持比例 2/3 这个数字本身没什么用，指出「第三句没有依据」才是这次核查的产出。它把一个「回答看起来不错」的印象，变成了一条可以立刻去修的具体问题。

什么时候适合与不适合

适合：知识问答、合同与政策查询、客服答复、任何「答案应该来自给定资料」的场景。尤其是那些错误答案会被拿去执行动作的场景，值得把依据一致性作为上线的硬指标。

不适合：创作类任务（文案、头脑风暴）——那里没有「依据」这个概念，衡量它会得出无意义的结论；以及资料本身就是回答的核心但资料很短、逐条核对成本高于收益的场景。

标注高估与「只报数字不说位置」，是两个不同层面的问题。 一种是标注高估：把「可推断」放得太宽，导致支持比例虚高、维度失去指示力。对策是限定推理步数并定期复核标注一致性。另一种是只说数字不说位置：报告里只出现「依据一致性 87%」，没人知道那 13% 在哪。对策是报告必须附带无支持条目的样例——这个维度的价值几乎全部在具体条目里，而不是在那个百分比里。

亲自试一下

用约 30 分钟对一条真实的 RAG 回答做一次人工核对：

1. 取一条回答：从你的系统里挑一条看起来不错的回答（不要挑它已知会错的）。
2. 拆主张：把它拆成可以单独判断真假的句子，去掉连接词。
3. 逐条标注：对每条写「有支持 / 可推断 / 无支持」，并在资料里指出依据的位置。
4. 算比例、找模式：算出支持比例，然后看无支持的那些条目是不是集中在同一类字段上。

观察点在第 4 步。如果无支持条目集中在数字或时间上，说明这类字段需要额外的结构化校验；如果它们散落在各处、且看不出规律，说明问题出在生成环节而不是资料。

接下来学什么

依据一致性是这一站（给判断）里针对「编造」这一类失败的专门维度。它需要三个邻居配合：评测集 提供题目、大模型裁判 提供低成本打分、可观测性 把线上的真实失败捕获回来变成新题。

它同时连着上一站（给知识）的两个环节：检索端的 检索精确率 与 检索召回率，生成端的 引用生成。如果你关心的是「模型为什么会编」这个更底层的问题，回到第一站的 幻觉。如果你担心的是「不可信内容会利用这一点」，那是 给安全 的 提示词注入。

来源与修订

把评估需覆盖系统的风险与影响、并强调可验证的测量方法，来自 NIST 的 AI Test, Evaluation, Validation and Verification (TEVV) 与 ARIA Pilot Evaluation Report。[S1][S2]

需要说明一处边界：「拆主张 → 三档标注 → 报告必须附带无支持条目的样例」，以及「限制推理步数以免高估」这两条操作规则，是本站在整理评估实践时总结的，不是上述来源的原文。NIST 的文档给出的是评估框架与风险维度，不规定主张级核对的执行细则。

2026-09-21 按决策页规范重写，本次修订补入三档标注口径与「报告必须附无支持条目样例」的要求，避免这个维度退化成一个孤立的百分比。