一个看似正确却无法追溯的回答
假设某公司内部知识库问答系统上线了。员工问：“小规模纳税人转一般纳税人之后，公司的纳税人识别号会变吗？”系统回答：“会变，需要重新登记。”这个回答语气肯定、语法通顺，但公司财务制度文档里写的恰恰相反。检索环节确实返回了正确的税务登记说明，生成模型却给出了一个与上下文矛盾的结论。
这类问题很难靠人工逐条抽查发现。企业知识库每天可能有几百次问答，答案对错取决于具体制度条款，评审人员不可能每次都翻原文核对。更麻烦的是，答案“看起来对”和“确实能从文档推导出来”是两回事。传统做法要么依赖人工标注标准答案，要么只看回答是否流畅，两者都无法规模化地判断“这句话有没有依据”。
RAGAS（Retrieval-Augmented Generation Assessment）提供的思路是：不要求人工写标准答案，而是让一个评估用 LLM 去检查生成答案中的每条事实陈述，能否从检索返回的上下文里推导出来。本文以企业知识库问答为贯穿场景，拆解其中忠实度（Faithfulness）与答案相关性（Answer Relevance）两个指标的计算原理、工程实现和适用边界。
为什么不能只看答案像不像标准答案
RAG 系统由检索器和生成器两部分组成。检索器从向量库中找出与问题相关的文档片段，生成器再根据这些片段和问题组织回答。评估的困难在于，这两个环节都可能出错，而且错误会叠加。
如果只比较生成答案和人工标准答案的语义相似度，会遇到两个问题。第一，标准答案需要人工逐条编写，企业制度文档更新频繁，维护成本很高。第二，语义相似度高的答案未必忠实于检索上下文。模型可能凭借预训练知识给出一个与标准答案接近、但检索文档并未支持的回答。一旦文档更新而模型知识滞后，这种“碰巧相似”会掩盖真实问题。
RAGAS 论文（Es 等，arXiv:2309.15217）提出了一套不依赖人工标注的评估指标，把 RAG 的评估拆成检索质量和生成质量两个维度。检索维度关注上下文是否相关、是否覆盖了回答问题所需的信息；生成维度关注答案是否忠实于上下文、是否切题。忠实度和答案相关性正属于后者。
这两个指标回答的是不同问题。忠实度问的是“答案里的每句话，能不能在检索到的上下文里找到依据”；答案相关性问的是“这段回答有没有正面回应用户的问题”。一个答案可以很切题但缺乏依据，也可以有依据但答非所问。分开度量，才能定位问题出在检索还是生成。
忠实度：把答案拆成语句，再逐条回查上下文
忠实度的核心操作是把一段连续的回答拆解成若干条独立的事实陈述，然后判断每一条能否从检索上下文中推导出来。
具体流程分两步。第一步，评估 LLM 接收问题和生成答案，按句子或语义单元提取出一组陈述语句。例如答案“小规模转一般纳税人后，纳税人识别号不变，只是资格认定信息中会增加一般纳税人资格”会被拆成“纳税人识别号不变”和“资格认定信息中增加一般纳税人资格”两条。第二步，评估 LLM 拿到检索上下文和这组陈述，逐条判断该陈述是否被上下文支持，并给出简短理由和 Yes/No 结论。
最终得分是支持陈述数除以陈述总数。如果答案包含 5 条陈述，其中 4 条能从上下文推导，忠实度为 0.8。得分低意味着答案中有相当比例的内容在检索文档里找不到依据，这些内容要么来自模型自身知识，要么是凭空编造。
这里的关键设计是“逐条判断”而不是“整体打分”。整体打分容易受答案长度和语言流畅度干扰，评估 LLM 可能因为回答通顺就给高分。拆成语句后，每条判断的对象更具体，评估结果也更可解释——可以明确指出哪句话没有依据。
需要注意，忠实度只检查答案与上下文的一致性，不检查上下文本身是否正确。如果检索到的文档本身就是错的，模型忠实照搬，忠实度依然很高。因此忠实度高不等于答案正确，它只说明答案没有脱离给定材料。
答案相关性：反向生成问题，用向量相似度衡量切题程度
答案相关性要解决的是答非所问。它的计算方式比较特别：不是直接判断答案和问题是否相关，而是让评估 LLM 根据答案反向生成若干个可能的问题，再计算这些问题与原始问题的向量相似度。
流程是这样的。评估 LLM 拿到生成答案，被要求“针对这个答案生成 n 个问题”。如果答案内容集中、信息明确，生成的问题会围绕同一主题；如果答案含糊、包含大量无关内容，生成的问题就会发散。随后用文本 Embedding 模型把这些生成问题转成向量，分别计算它们与原始问题向量的余弦相似度，再取平均作为答案相关性得分。
这个设计的直觉是：一个好的答案应该能被还原成与原始问题等价的问题。如果答案答非所问，反向生成的问题就会偏离原始问题，相似度自然下降。相比直接让 LLM 打分，向量相似度提供了更稳定的数值信号，减少了评估 LLM 主观判断的波动。
答案相关性同样不判断答案是否正确。一个错误但切题的回答，仍然可能获得较高的相关性得分。它衡量的是回答与问题之间的语义对齐程度，包括是否完整覆盖了问题要点、是否包含大量冗余内容。
上下文精度与召回率：检索质量的另一面
忠实度和答案相关性评估的是生成环节，但生成出问题有时根源在检索。RAGAS 还提供了上下文精度（Context Precision）和上下文召回率（Context Recall）来评估检索质量，它们需要人工提供标准答案作为参照。
上下文召回率检查标准答案中的每条信息，能否在检索到的上下文中找到归属。如果标准答案提到三个要点，检索上下文只覆盖了两个，召回率就不完整。它衡量的是检索是否“找全了”。
上下文精度关注的是排序。它检查那些与标准答案相关的上下文片段，是否排在检索结果的前列。相关片段排得越靠前，精度越高。这个指标能感知排序效应，但也有一个明显缺陷：如果相关片段召回得很少，但恰好都排在最前面，精度得分依然会很高。因此上下文精度必须和召回率一起看，单独使用会误导判断。
把四个指标放在一起，可以形成一张定位表。
| 指标 | 需要的输入 | 衡量对象 | 得分低时的典型含义 | 是否需要标准答案 |
|---|---|---|---|---|
| 忠实度 Faithfulness | 答案、上下文 | 答案是否可从上下文推导 | 生成模型编造或使用了上下文之外的知识 | 否 |
| 答案相关性 Answer Relevance | 答案、问题 | 答案是否切题 | 回答偏离问题、答非所问或冗余 | 否 |
| 上下文精度 Context Precision | 上下文、标准答案 | 相关片段是否排在前面 | 检索排序差，噪声片段挤占了前排 | 是 |
| 上下文召回率 Context Recall | 上下文、标准答案 | 所需信息是否被找全 | 检索遗漏了回答所需的关键文档 | 是 |
在企业知识库场景中，如果忠实度低而上下文召回率高，说明检索找到了正确文档，但生成模型没有好好利用，问题出在生成提示词或模型选择上。如果忠实度高但答案相关性低，说明模型忠实复述了文档，却没有针对用户问题组织回答，可能是提示词没有引导模型聚焦问题。如果召回率低，无论生成质量如何，答案都不可能完整，需要先优化检索策略。
评估流水线如何运转
把上述指标串起来，一次完整的评估需要准备问题、生成答案、收集上下文，再分别计算各指标。下面的流程图展示企业知识库问答场景中，忠实度和答案相关性的计算路径。
flowchart TD
A[员工问题] --> B[向量检索]
B --> C[检索上下文]
C --> D[生成模型]
D --> E[生成答案]
E --> F[忠实度评估]
C --> F
A --> F
F --> G[拆解答案语句]
G --> H[逐条回查上下文]
H --> I[支持数除以总数]
E --> J[答案相关性评估]
A --> J
J --> K[反向生成问题]
K --> L[计算向量相似度]
L --> M[取平均得分]
I --> N[汇总评估报告]
M --> N
流程中有两个容易出问题的环节。第一个是语句拆解。如果评估 LLM 把一条复合陈述拆得过细，可能把上下文隐含支持的内容判为不支持；拆得过粗，又会掩盖部分编造内容。第二个是反向生成问题的数量。生成问题太少，相似度平均值的方差大；生成太多，评估成本上升，边际收益递减。
工程上通常把评估流水线和在线问答流水线分开。在线服务只负责生成答案并记录问题、答案、上下文三元组，评估任务异步消费这些日志。这样评估不会增加用户请求的延迟，也方便在模型或知识库更新后批量重跑。
什么时候这些指标会失效
忠实度和答案相关性依赖评估 LLM 的判断，因此继承了 LLM 的局限。
评估 LLM 的判断能力不足时，会把上下文实际支持的内容误判为不支持，或者把编造内容误判为有依据。模型规模较小、上下文较长、陈述涉及专业术语时，误判率会上升。工程上通常用能力较强的模型做评估，但这会推高成本。
上下文长度也是约束。如果检索返回的片段很多、很长，评估 LLM 在逐条回查时可能遗漏信息，导致忠实度被低估。另一种情况是上下文包含相互矛盾的内容，评估 LLM 难以判断哪条陈述被支持。
答案相关性对反向生成问题的质量很敏感。如果评估 LLM 生成的问题过于宽泛，相似度会普遍偏高，指标失去区分度。如果原始问题本身表述模糊，反向生成的问题也可能偏离用户真实意图。
还有一个边界是语言和领域。RAGAS 默认提示词是英文的，直接用于中文企业知识库时，评估 LLM 可能生成英文问题或做出不符合中文语境的判断。资料显示，RAGAS 支持通过 adapt 方法把内置提示词适配到目标语言，也可以保存适配后的提示词供后续加载。这一步在中文场景中通常不能省略。
最后，忠实度只度量答案与上下文的一致性。如果检索到的文档本身过时或错误，忠实度无法发现。企业知识库需要配套的文档审核机制，评估指标不能替代内容治理。
成本、替代方案与部署边界
RAGAS 的忠实度和答案相关性是 reference-free 指标，不需要人工编写标准答案，这是它相比语义相似度评估的主要优势。上下文精度和召回率仍然需要标准答案，适合在关键场景中抽样评估。
成本主要来自 LLM 调用。忠实度每条样本至少需要两次 LLM 调用：一次拆解语句，一次逐条判断。答案相关性需要一次 LLM 调用生成问题，外加若干次 Embedding 计算。如果评估集有几百条样本，成本会随样本量和上下文长度增长。工程上可以先用小样本校准提示词和评估模型，再扩大到全量。
与人工评估相比，自动指标的优势是速度和可重复性，适合在每次模型或知识库更新后快速回归。劣势是判断粒度受评估 LLM 能力限制，无法完全替代人工抽检。与基于标准答案的语义相似度相比，忠实度能发现“答案像但没依据”的情况，这是语义相似度做不到的。
部署时需要明确几个边界。评估集应该来自真实用户问题，而不是凭空构造，否则指标无法反映生产分布。评估 LLM 和生成 LLM 最好不同，避免同源模型对自身输出过度宽容。指标阈值需要结合业务容忍度设定，不能直接套用通用标准。
仍未解决的问题包括：如何评估多轮对话中答案的忠实度，如何处理上下文本身包含错误的情况，以及如何降低评估 LLM 在长上下文下的判断偏差。这些问题在现有资料中没有给出确定答案，需要在实际部署中通过持续抽检和指标监控来逐步校准。