一个通顺但不可信的答案
假设公司内部知识库上线了问答入口。员工问：“出差住宿的报销上限是多少？”检索模块返回了三段制度文本，其中一段写着“一线城市住宿标准每人每晚不超过 600 元”，另一段写着“超标部分需部门负责人审批”。模型生成的回答是：“一线城市住宿上限为每人每晚 800 元，超标部分由部门负责人审批。”
这句话语法正确、结构完整，甚至把“审批”这一条也复述对了。但它把 600 改成了 800。检索到的上下文并不支持这个数字，答案因此不可信。问题在于，这类错误不会触发任何异常：接口返回 200，生成延迟正常，用户界面也没有报错。如果只靠人工抽查，评估速度远跟不上知识库和提示词的迭代频率。
RAGAS 提出的忠实度（Faithfulness）指标，正是针对这一维度：答案中的每个声明是否都能从检索到的上下文推导出来。它不判断答案是否回答了用户问题，也不判断检索是否召回了正确文档，只回答一件事——模型有没有在给定材料之外自行编造。
忠实度衡量的边界
RAGAS 是一个面向检索增强生成管道的无参考评估框架。所谓无参考，是指评估过程不依赖人工标注的标准答案，只需要用户问题、模型回答和检索到的上下文。论文把 RAG 系统的评估拆成几个维度：检索系统能否找到相关且聚焦的段落、LLM 能否忠实地利用这些段落、生成本身的质量如何。忠实度对应第二个维度。
官方文档给出的定义很直接：忠实度衡量回答与检索上下文在事实层面的一致程度，取值 0 到 1，越高表示一致性越好。当回答中的所有声明都能被检索上下文支持时，该回答被视为忠实的。
这个定义有两个容易忽略的边界。第一，它只检查“答案是否被上下文支持”，不检查“上下文是否正确”。如果检索到的制度文本本身就是过期版本，模型忠实复述了过期数字，忠实度仍会很高。第二，它不惩罚遗漏。如果答案只说了住宿上限，没提审批流程，只要说出的部分有依据，忠实度就不受影响。因此忠实度必须和上下文召回、答案相关性等指标一起看，单独一个分数无法判断整个问答系统是否可用。
声明分解：把一段话拆成可判定的原子
忠实度的计算分三步。第一步是声明分解：让评估用的 LLM 把生成答案拆成若干条独立声明。第二步是逐条判断：对每条声明，判断它能否从检索上下文中推导出来。第三步是求比值：
忠实度 = 被上下文支持的声明数 / 答案中的声明总数
官方文档给出的例子很能说明问题。问题是“爱因斯坦在哪里、何时出生”，上下文只写了“Albert Einstein（生于 1879 年 3 月 14 日）是一位出生于德国的理论物理学家”。一个高忠实度回答是“爱因斯坦 1879 年 3 月 14 日出生于德国”，一个低忠实度回答把日期改成 3 月 20 日。低忠实度回答被拆成两条声明：“爱因斯坦出生于德国”和“爱因斯坦出生于 1879 年 3 月 20 日”。第一条可从上下文推导，第二条不能。于是忠实度为 1/2，即 0.5。
声明分解之所以关键，是因为它把“整段话像不像真的”这种模糊判断，变成了若干次范围很小的判定。一段包含五个事实的回答，如果其中一个是编造的，整体语义相似度可能仍然很高，但声明级判断会把这个错误单独暴露出来。
分解粒度会直接影响分数。同一句话可以拆成一条粗声明，也可以拆成三条细声明。比如“一线城市住宿上限 600 元，需部门负责人审批”可以视为一条复合声明，也可以拆成“上限为 600 元”和“需要审批”两条。如果拆得粗，一条错误声明会让整条复合声明判为不支持，分数偏低；如果拆得细，错误被定位得更精确，但评估调用次数增加。工程上通常需要在提示词里明确要求“每条声明只包含一个可独立验证的事实”，以减少粒度漂移。
蕴含判断：LLM 如何决定“能不能推导出来”
第二步是蕴含判断。对每条声明，评估 LLM 要回答的是：仅凭检索上下文，这条声明是否成立。这里的“推导”不等于字面匹配。上下文写“生于 1879 年 3 月 14 日”，声明写“出生于 1879 年 3 月 14 日”，属于同义改写，应判为支持；上下文写“不超过 600 元”，声明写“上限为 800 元”，数值冲突，判为不支持。
判断过程中还有一类中间情况：上下文没有直接说，但可以合理推出。例如上下文写“超标部分需部门负责人审批”，声明写“住宿超标不是自动通过”，这属于可推导。是否把这类推断算作支持，取决于提示词对“inferred”的界定。如果界定过宽，评估器会放过一些实际没有依据的声明；界定过窄，又会把合理的同义改写判成幻觉。
从系统实现角度看，这一步通常是一次 LLM 调用，输入是单条声明加上检索上下文，输出是支持或不支持。也可以把多条声明合并成一次调用，让模型逐条给出判断，以减少请求数。合并调用的风险是声明之间相互干扰，尤其是当上下文很长、声明数量较多时，模型可能漏判或错配。
下面这张流程图展示了企业知识库问答场景中，一次忠实度评估的数据流动。
flowchart TD
A[员工提问：住宿报销上限] --> B[检索模块返回制度段落]
B --> C[生成模型输出答案]
C --> D[评估LLM分解声明]
D --> E1[声明1：上限600元]
D --> E2[声明2：需负责人审批]
E1 --> F[逐条蕴含判断]
E2 --> F
B --> F
F --> G1[声明1：支持]
F --> G2[声明2：支持]
G1 --> H[计算支持比例]
G2 --> H
H --> I[忠实度得分]
在这个例子里，如果模型输出的是 800 元，声明 1 会被判为不支持，忠实度为 0.5。分数下降的位置正好对应错误发生的位置，这比一个笼统的“答案质量分”更有定位价值。
与人工评估的关系和检测边界
论文的核心主张是，这套指标可以在不依赖人工标注标准答案的前提下评估 RAG 的不同维度，从而加快评估周期。这并不意味着它等价于人工评估。忠实度与人工判断的相关性，取决于评估 LLM 的分解能力和蕴含判断能力，也取决于任务领域。
在企业知识库场景中，有几类失败模式需要特别注意。
数值和日期是最容易出问题的地方。模型对“600”和“800”的语义差异未必敏感，尤其是在上下文很长、数字密集的财务或合规文档中。评估器如果把数值差异当作同义改写，就会漏报。
否定和条件也容易误判。“需要审批”和“不需要审批”只差一个字，但事实完全相反。上下文包含多个条件分支时，声明可能只对应其中一个分支，评估器需要判断声明是否在所有相关条件下都成立。
多跳推导会拉低分数。如果答案需要把两段上下文组合起来才能得出，而评估器只看到单段上下文，可能判为不支持。这不一定说明生成模型在幻觉，也可能是评估输入的组织方式有问题。
上下文噪声会干扰判断。检索返回的段落里如果混入了相似但不相关的条款，评估器可能把噪声当作依据，从而高估忠实度。
反过来，忠实度高也不等于答案有用。一个只复述上下文、不回答问题的答案，忠实度可以接近 1，但答案相关性很低。评估时需要把忠实度和相关性、上下文召回放在一起看。
实现成本与替代方案
忠实度评估的主要成本来自 LLM 调用。一次评估至少需要一次声明分解调用和若干次蕴含判断调用。如果逐条判断，调用次数与声明数量成正比；如果合并判断，调用次数减少，但单次输入变长，对上下文窗口和判断稳定性提出更高要求。
官方文档还提到一种替代实现：使用 HHEM-2.1-Open 这类模型来计算忠实度。这类方案不依赖通用 LLM 的提示词判断，而是用专门训练的模型做事实一致性打分。它的优势是调用成本更低、延迟更可控，适合高频在线评估；代价是灵活性较差，面对领域术语和复杂条件时，判断边界由模型训练分布决定，不容易通过提示词调整。
| 方案 | 判断方式 | 质量特点 | 延迟与成本 | 适用场景 |
|---|---|---|---|---|
| LLM 声明分解加蕴含判断 | 提示词驱动，逐条判定 | 可解释，能定位到具体声明；受提示词和模型能力影响 | 调用次数多，成本随声明数增长 | 离线评估、回归测试、需要定位错误 |
| 专用模型打分 | 模型直接输出一致性分数 | 稳定、成本低；领域适应性依赖训练数据 | 单次调用，延迟低 | 在线监控、高频抽样 |
| 人工评估 | 人工逐条核对 | 质量最高；可处理复杂条件和领域知识 | 成本高，速度慢 | 校准自动指标、处理争议样本 |
选择哪种方案，取决于评估目的。如果要在每次提示词或检索策略变更后快速回归，LLM 判断能给出可定位的错误列表；如果要持续监控线上流量，专用模型或抽样评估更现实。
工程落地需要观察什么
把忠实度接入评估流水线后，需要关注的信号不只是平均分。平均分稳定在 0.9 以上，可能掩盖少数严重幻觉。更有用的做法是同时记录：
- 不支持声明的数量分布，而不只是比例。一条回答包含十条声明、其中一条错误，和一条回答只有一条声明且错误，比例相同但风险不同。
- 被判定为不支持的声明原文。这些文本是排查检索和提示词问题的最直接线索。
- 评估器与人工标注在抽样集上的一致率。如果一致率低，说明提示词或评估模型需要校准。
- 忠实度与上下文召回、答案相关性的联合分布。忠实度高但相关性低，说明模型在安全地复述无关内容；忠实度低但相关性高，说明模型在编造用户想听的答案。
当忠实度突然下降时，排查顺序通常是：先看检索上下文是否变化，再看生成提示词是否改动，最后检查评估提示词本身是否被修改。评估器也是软件，它的提示词变更同样会改变分数。
适用边界与未解决的问题
忠实度指标适合回答“答案有没有超出给定材料”这个问题，但它不能替代端到端评估。它假设检索上下文是判断依据，因此对检索质量不敏感；它依赖 LLM 的判断能力，因此在数值、否定、条件分支上存在系统性误差；它按声明数量取平均，因此对长答案和短答案的惩罚力度不同。
一个尚未完全解决的问题是评估器自身的校准。不同评估模型、不同提示词版本给出的忠实度分数不可直接比较，这意味着跨时间、跨团队的分数对比需要谨慎。另一个问题是如何处理多跳推导和领域术语：当正确答案需要组合多条上下文，或依赖领域内约定俗成的表达时，自动判断的边界仍然模糊。
在工程实践中，更稳妥的做法是把忠实度当作一个快速筛查器，而不是最终裁判。它负责把可疑答案筛出来，人工只需要复核被标记的少数样本。这样既保留了自动评估的速度，也避免了把评估器的判断当作事实。