标签: llm-as-judge

  • DeepEval Faithfulness Metric 的已知缺陷:idk 不扣分问题

    背景

    在使用 DeepEval 对 GraphRAG 系统进行无标准答案(no-reference)评测时,我们发现 FaithfulnessMetric 在特定场景下会给出误导性的满分结果。

    问题现象

    我们向 GraphRAG 提出了一个关于 5GC PDU Session 建立流程的复杂问题。系统返回了详细的技术回答(涉及 AMF、SMF、UPF、PCF 等网元的具体职责),但检索到的 context 仅包含 3GPP 文档的目录结构,例如:

    The document contains a section '5.6 Session Management' with several sub-subsections.
    The document contains a section '5.2 Network Access Control' with several sub-subsections.
    

    Context 中没有任何实质性的技术内容,但 Faithfulness 评分为 1.00(满分)

    根因分析

    Faithfulness metric 的评估分为 4 步:

    Step 作用
    1. Truths 提取 从 retrieval_context 提取事实列表
    2. Claims 提取 从 actual_output 提取声明列表
    3. Verdicts 判定 将每条 claim 与 context 比对,判定 yes/no/idk
    4. Score 计算 根据 verdicts 计算最终分数

    关键在于 Step 3 的判定规则:

    • yes — claim 与 context 一致
    • no — claim 与 context 直接矛盾
    • idk — context 中找不到相关信息,无法判断

    以及 Step 4 的默认计分公式

    score = (总数 - no的数量) / 总数
    

    idk 不计入扣分。 只有明确矛盾(no)才会降低分数。

    实际案例

    我们的评测中,LLM judge(换用更严格的模型后)对 20 条 claims 全部判定为 idk

    {
      "verdicts": [
        {"verdict": "idk"},
        {"verdict": "idk"},
        ...  // 共 20 条,全部 idk
      ]
    }
    

    计分结果:score = (20 - 0) / 20 = 1.00

    最终 reason 输出:

    “The score is 1.00 because there are no contradictions; the actual output fully aligns with the retrieval context.”

    这显然是误导性的 — 回答中的所有声明都没有被 context 支撑,但因为也没有被”矛盾”,所以得了满分。

    本质问题

    Faithfulness 衡量的是“有没有与 context 矛盾”,而不是“有没有被 context 支撑”

    这两个是完全不同的维度:

    场景 Faithfulness Groundedness
    回答完全基于 context
    回答正确但 context 无关 高(无矛盾) 低(无支撑)
    回答与 context 矛盾

    当 retrieval context 只包含目录级、摘要级信息时,几乎不可能与任何具体声明产生”直接矛盾”,Faithfulness 就会永远满分。

    解决方案

    方案 1:开启 penalize_ambiguous_claims

    DeepEval 提供了内置参数:

    FaithfulnessMetric(model=model, threshold=0.5, penalize_ambiguous_claims=True)
    

    开启后计分公式变为:

    score = (总数 - no的数量 - idk的数量) / 总数
    

    此时 20 条全 idk 的分数为:(20 - 0 - 20) / 20 = 0.00,更真实地反映了 context 对回答的支撑程度。

    方案 2:补充 Groundedness 指标

    使用 GEval 自定义一个 Groundedness metric,直接评估回答是否被 context 支撑:

    GEval(
        name="Groundedness",
        criteria="Determine whether the actual output is fully supported and grounded by the retrieval context. "
                 "Penalize claims in the output that cannot be traced back to specific information in the retrieval context.",
        evaluation_params=[SingleTurnParams.INPUT, SingleTurnParams.ACTUAL_OUTPUT, SingleTurnParams.RETRIEVAL_CONTEXT],
        model=model,
        threshold=0.5,
    )
    

    建议

    两个方案并用:
    – 保留 Faithfulness(开启 penalize_ambiguous_claims)检测矛盾和无支撑
    – 增加 Groundedness 从正面评估支撑程度
    – 在报告中注明 Faithfulness 的局限性,避免误读

    补充缺陷:总结性 claim 被误判为 idk

    即使 context 中包含了具体的细节信息,当 actual output 对这些细节做了归纳总结时,judge 仍然可能将其判为 idk

    实际案例

    Context 中包含了 PDU Session 建立的具体步骤细节(AMF 处理注册、SMF 选择 UPF、N4 会话建立等),而 actual output 中有一条总结性 claim:

    “从UE尝试访问特定DNN直到实现有效的用户面转发,整个过程涉及到了多个核心网元之间的紧密合作,每个组件都扮演着不可或缺的角色。”

    Judge 的判定:

    {
      "verdict": "idk",
      "reason": "The claim is a summary statement; the context provides specific procedural details but does not directly confirm this overall description."
    }
    

    原因

    Faithfulness 的 prompt 对 judge 有严格约束:

    “Only use ‘no’ if retrieval context DIRECTLY CONTRADICTS the claim — never use prior knowledge.”
    “Use ‘idk’ for claims not backed up by context — do not assume your knowledge.”

    Judge 被要求做字面级匹配,而不是语义级推理。即使 context 中的细节完全可以推导出这个总结,但因为 context 没有”直接确认”这句话,judge 就只能判 idk

    影响

    对于 RAG 系统来说,回答本来就应该基于 context 做归纳总结,这是正常且期望的行为。但 Faithfulness 的字面级判定会将这类合理总结视为”无支撑”,导致开启 penalize_ambiguous_claims 后分数偏低。

    可能的改进

    DeepEval 的 FaithfulnessMetric 支持 evaluation_template 参数,可以继承 FaithfulnessTemplate 并修改 verdict guidelines,将”可从 context 细节合理推导出的总结”纳入 yes 的判定范围。但这需要修改评测标准的语义,应谨慎使用。

    结论

    Faithfulness metric 的设计初衷是检测 hallucination(幻觉),即模型是否编造了与 context 矛盾的信息。但它存在两个层面的局限:

    1. idk 默认不扣分 — context 无关时永远满分(通过 penalize_ambiguous_claims=True 解决)
    2. 字面级匹配过于严格 — 合理的归纳总结也会被判为无支撑(需自定义 template 或依赖 Groundedness 指标补充)

    评测 RAG 系统时,需要同时关注 Faithfulness 和 Groundedness 两个维度,才能全面评估回答质量。

  • 为什么 Gold Answer 在 GraphRAG 系统中越来越不重要了

    传统 RAG 评估依赖人工标注的”标准答案”,但在 GraphRAG 时代,这套方法正在失去意义。

    什么是 Gold Answer?

    Gold Answer(黄金答案)是指人工标注的”标准正确答案”。在传统 NLP 和 RAG 系统评估中,我们通常这样做:

    1. 准备一批测试问题
    2. 人工写出每个问题的”正确答案”
    3. 让系统回答同样的问题
    4. 对比系统答案和 Gold Answer,计算 F1、BLEU、ROUGE 等分数

    这套方法在搜索引擎和简单问答系统中运行了很多年。但在 GraphRAG 这类复杂系统中,Gold Answer 的价值正在急剧下降。

    知识图谱持续演化,Gold Answer 跟不上

    问题本质

    GraphRAG 的核心是知识图谱。图谱不是静态的——每次文档更新、每次重新抽取实体关系,图谱都在变化。今天的”正确答案”,明天可能就过时了。

    举个例子

    假设你的公司有一份内部技术架构文档:

    • 1 月版本:文档写着”订单服务使用 MySQL 数据库”
    • 3 月版本:架构升级,改成了”订单服务使用 PostgreSQL + Redis 缓存”

    你在 1 月标注的 Gold Answer 是:

    Q: 订单服务用什么数据库?
    A: MySQL

    到了 3 月,GraphRAG 系统重新索引了新文档,正确回答了”PostgreSQL + Redis”。但如果你还拿 1 月的 Gold Answer 去评估,系统反而会被判”错误”。

    更现实的场景

    在企业内部,文档更新频率远比想象中高:

    • API 文档每周都在改
    • 组织架构每季度调整
    • 技术选型每半年可能翻新一次

    每次文档更新后,你都需要重新标注 Gold Answer。一个有 500 个测试问题的评估集,每次更新可能有 30% 的答案需要修改——这意味着每次要重新审核 150 个答案。

    人工标注 Gold Answer 成本极高且不可靠

    问题本质

    GraphRAG 处理的问题往往是多跳推理、跨文档关联的复杂问题。对于这类问题,连人类专家都很难给出一个”唯一正确”的答案。

    举个例子

    假设问题是:

    “张三负责的项目中,哪些使用了已经 EOL(End of Life)的技术栈?”

    要回答这个问题,标注人员需要:

    1. 找到张三负责哪些项目(可能分散在 5 份文档中)
    2. 找到每个项目的技术栈(又是另外几份文档)
    3. 判断哪些技术栈已经 EOL(需要查外部信息)
    4. 综合以上信息给出答案

    假设真实情况是张三负责 4 个项目,其中 3 个用了 EOL 技术栈。标注员经过 1 小时的文档翻阅,写出了 Gold Answer:

    项目 A(Spring Boot 2.5)、项目 B(Log4j 1.x)、项目 C(Python 2.7)

    但标注员漏掉了项目 D——因为张三对项目 D 的负责关系写在一份会议纪要里,而不是正式的项目分配表中。

    现在来看评估结果:

    系统 回答 对比 Gold Answer 的得分
    普通 RAG 找到了项目 A、B(漏了 C) 召回率 2/3 = 0.67
    GraphRAG 找到了项目 A、B、C、D(通过会议纪要中的关系推理找到了 D) 召回率 3/3 = 1.0,但精确率 3/4 = 0.75(D 被判为”多余”)

    讽刺的是:GraphRAG 因为比 Gold Answer 还要正确,反而被扣了分。它通过图谱中的关系链(张三 → 参会 → 会议决议 → 负责项目 D)找到了标注员都遗漏的信息,但在评估框架里,这个”多出来的正确答案”被当成了错误。

    最终 F1 分数:
    – 普通 RAG:F1 = 0.80
    – GraphRAG:F1 = 0.86

    GraphRAG 明明找得更全、更准,分数优势却微乎其微——甚至在某些评估设置下(比如严格精确匹配),分数可能比普通 RAG 还低。Gold Answer 的天花板限制了对更优系统的识别能力。

    成本账

    标注一个复杂的 GraphRAG 测试问题,一个领域专家可能需要 30-60 分钟(需要翻阅多份文档、交叉验证)。如果你需要 200 个测试问题,那就是 100-200 小时的专家时间。而且这些答案的保质期可能只有几个月(参见论点一)。

    GraphRAG 的答案形式天然多样

    问题本质

    传统 RAG 往往回答事实性问题(”X 是什么”),答案相对固定。但 GraphRAG 擅长的是关系推理和综合分析,这类问题的”正确答案”本身就有多种合理表达。

    举个例子

    问题:

    “我们的微服务架构中,哪些服务之间存在循环依赖?”

    GraphRAG 可能回答:

    答案 A:服务 A → 服务 B → 服务 C → 服务 A 形成循环;服务 D 和服务 E 互相调用。

    答案 B:存在两组循环依赖:(1) A-B-C 三角循环 (2) D-E 双向依赖。建议优先解耦 A-B-C 循环,因为涉及核心交易链路。

    答案 C:检测到循环依赖路径:A→B→C→A。另外 D↔E 存在双向调用,但由于是异步消息,实际影响较小。

    三个答案都是”正确”的,但侧重点不同。用任何一个作为 Gold Answer,都会不公平地惩罚其他同样正确的回答。

    传统指标的失效

    用 ROUGE 分数对比上面三个答案:

    • 答案 A vs 答案 B:ROUGE-L 可能只有 0.3(措辞完全不同)
    • 答案 A vs 答案 C:ROUGE-L 可能有 0.5(有部分重叠)

    但从信息正确性来看,三个答案都应该得满分。Gold Answer + 文本相似度指标的组合,在这里完全失效了。

    LLM-as-Judge 正在取代 Gold Answer

    问题本质

    既然 Gold Answer 有这么多问题,业界正在转向一种新的评估范式:用 LLM 作为评判者(LLM-as-Judge),直接评估答案的质量,而不是和”标准答案”做文本对比。

    举个例子

    传统方式:

    系统答案: "PostgreSQL + Redis"
    Gold Answer: "MySQL"
    ROUGE 分数: 0.0  → 判定为错误 ❌
    

    LLM-as-Judge 方式:

    问题: "订单服务用什么数据库?"
    系统答案: "PostgreSQL + Redis"
    参考文档: [最新架构文档,明确写了 PostgreSQL + Redis]
    
    LLM 评判: 答案与文档一致,信息准确,得分 5/5 ✅
    

    LLM-as-Judge 的优势:

    维度 Gold Answer LLM-as-Judge
    是否需要人工标注 需要大量人工 不需要
    能否适应文档更新 需要重新标注 自动适应(参考最新文档)
    能否处理多种正确表达 不能 能(理解语义等价)
    评估成本 高(人工) 低(API 调用)
    评估速度 慢(天/周) 快(分钟)

    GraphRAG 的评估维度远超”答案正确性”

    问题本质

    Gold Answer 只能评估一个维度:答案内容是否正确。但 GraphRAG 系统的质量取决于很多其他因素,这些因素 Gold Answer 完全无法衡量。

    举个例子

    同一个问题,两个 GraphRAG 系统都给出了正确答案,但质量天差地别:

    系统 A 的回答

    张三负责项目 X,使用了 Spring Boot 2.5(已 EOL)。

    系统 B 的回答

    张三负责项目 X,使用了 Spring Boot 2.5(已于 2023 年 11 月停止维护)。此外,该项目还依赖 Log4j 1.x(2015 年 EOL,存在已知安全漏洞 CVE-2019-17571)。建议参考内部迁移指南 [链接] 进行升级。

    两个答案对比 Gold Answer 可能得分相同,但系统 B 明显更有价值——它提供了更完整的信息、安全风险提示和行动建议。

    真正重要的评估维度

    对于 GraphRAG 系统,我们更应该关注:

    • 图谱覆盖率:实体和关系是否被完整抽取?
    • 推理路径可解释性:系统是通过哪些节点和边得出结论的?
    • 信息完整度:是否遗漏了重要的关联信息?
    • 时效性:引用的信息是否是最新的?
    • 可操作性:答案是否给出了可执行的建议?

    这些维度都不是 Gold Answer 能评估的。

    那我们该怎么评估 GraphRAG?

    既然 Gold Answer 不再是银弹,以下是更适合 GraphRAG 的评估策略:

    1. LLM-as-Judge + 评估维度拆分:让 LLM 从准确性、完整性、相关性等多个维度分别打分
    2. 基于源文档的事实核查:检查答案中的每个事实是否能在源文档中找到依据
    3. 图谱质量指标:直接评估知识图谱的实体覆盖率、关系准确率
    4. 端到端用户满意度:让真实用户评价答案是否解决了他们的问题
    5. 回归测试而非绝对评分:关注系统更新前后的质量变化,而非追求绝对分数

    最后

    Gold Answer 并非毫无价值——在简单事实问答、系统冷启动阶段,它仍然是有用的基线。但在 GraphRAG 这类复杂系统中,过度依赖 Gold Answer 会带来三个风险:

    1. 虚假的安全感:Gold Answer 评分高不代表系统真的好用
    2. 维护负担:持续更新 Gold Answer 的成本可能超过它带来的价值
    3. 评估盲区:Gold Answer 无法覆盖 GraphRAG 最重要的质量维度

    与其花大量时间维护一套注定会过时的”标准答案”,不如把精力投入到更现代、更全面的评估体系中。GraphRAG 的评估,应该像 GraphRAG 本身一样——动态、多维、基于理解而非死记硬背。