引用支撑度评估怎么配置或排查

引用支撑度评估不应该只看一个总分。更稳妥的配置是把 RAG 答案拆成“可核验声明—来源片段—引用标记”，先统计引用是否存在、来源 ID 是否有效，再让评估器判断声明是否真的被来源支持。Hugging Face 的评估资料也把数据集、模型和指标分开；RAG 评估示例则采用独立评估数据集和 LLM-as-a-judge。

官方地址：https://huggingface.co/learn/cookbook/en/rag_evaluation

先固定声明和引用的数据契约

先约定一条评估样本长什么样。答案中的每个可核验事实都保存为独立声明，声明带唯一 claim_id；来源片段带 source_id 和原文；答案里的引用标记只引用这些 ID。这样“模型说错了”和“模型忘了标引用”才不会被混为一谈。

{
  "question": "Evaluate 是否支持自定义评估指标？",
  "claims": [
    {"claim_id": "c1", "text": "Evaluate 可以扩展自定义评估模块。", "citations": ["s1"]}
  ],
  "sources": [
    {"source_id": "s1", "evidence_text": "用户可以创建并分享新的 evaluation module。"}
  ]
}

这里的 JSON 是评估输入契约，不是某个模型固定要求的输出格式。字段名可以按项目调整，但 claim_id、source_id 和原文片段必须稳定保存。Hugging Face Evaluate 的核心是用指标对给定数据集上的模型表现进行测量；引用支撑度属于需要自定义输入与指标定义的 RAG 场景。

先跑确定性引用覆盖检查

语义判断成本更高，也可能受评估模型影响，所以先做不依赖模型的检查。至少统计三项：声明是否有引用、引用的来源 ID 是否存在、一个声明是否引用了过多无关片段。这个阶段只判断“引用结构完整”，不宣布事实一定正确。

def check_citation_coverage(sample):
    # 先建立来源索引，避免在每条声明中重复扫描列表。
    source_ids = {item["source_id"] for item in sample["sources"]}
    claims = sample["claims"]
    missing = [item["claim_id"] for item in claims if not item.get("citations")]
    invalid = [
        item["claim_id"] for item in claims
        if any(source_id not in source_ids for source_id in item.get("citations", []))
    ]
    covered = len(claims) - len(set(missing))
    # coverage 只描述标注覆盖率，不代替语义上的事实支持。
    coverage = covered / len(claims) if claims else 0.0
    return {"coverage": coverage, "missing_claims": missing, "invalid_claims": invalid}

如果 invalid_claims 不为空，优先回查检索结果序列化、引用 ID 映射和答案后处理；不要先改评估提示词。若 missing_claims 很多，可能是生成模板没有要求逐声明引用，也可能是拆分声明的规则过严。

再配置语义支撑度判定

确定性检查通过后，再判断来源是否支持声明。评估器的输入应只包含当前声明、它引用的证据片段和必要的判定规则，并要求返回结构化结果，例如 supported、score、reason。不要让评估器根据“看起来相关”给高分：来源提到了同一个实体，却没有支撑声明中的数字、范围或因果关系，仍应判为部分支持或不支持。

JUDGE_RULE = """
你是引用支撑度评估器。
只根据 CLAIM 和 EVIDENCE 判断，不补充外部知识。
若证据完整支持声明，supported=true；只支持一部分或相互矛盾时为 false。
只返回 JSON：{"supported": true, "score": 0.0, "reason": "简短依据"}
CLAIM: {claim}
EVIDENCE: {evidence}
"""

def build_judge_input(claim, source_map):
    # 只拼接声明实际引用的来源，防止评估器偷看未引用上下文。
    evidence = [source_map[key] for key in claim["citations"] if key in source_map]
    return JUDGE_RULE.format(claim=claim["text"], evidence="\n".join(evidence))

Hugging Face 的 RAG Cookbook 展示了用评估数据集和 LLM-as-a-judge 检查系统表现的思路，但示例中的判定标准仍需要按业务定义。生产环境应抽取少量人工复核样本，比较评估器对“完全支持、部分支持、无关来源、来源冲突”的判断，避免把评估模型本身的偏差当成系统质量。

用分层指标定位分数下降

把结果按故障来源拆开，排障速度会明显快于盯着一个平均分。coverage 低，先查引用格式和声明切分；valid_source 低，查检索结果与 ID 映射；两者正常但 entailment 低，查召回片段是否真的包含答案所需事实，或模型是否越过上下文补写内容。

Lighteval 官方文档强调逐样本结果有助于调试，也支持自定义任务和指标。因此不要只保存批次平均值：至少保留问题、声明 ID、引用 ID、四项指标和评估理由。这样一次失败可以回放，模型、切片策略或提示词变更也能做同一批样本的对比。

用边界样本反向验证

配置完成后准备四组小样本：没有引用的声明、引用无关文档的声明、只被来源部分支持的声明，以及需要两个来源共同支持的声明。检查结果时，确定性指标应该先暴露缺失和无效 ID，语义指标再区分支持程度。若一个平均分掩盖了某类错误，就把该类单独设为报表维度。

还要留意评估对象的边界：引用覆盖率高，不代表答案正确；来源相关，也不代表来源足以证明结论。只有把结构检查、检索命中和语义支撑分开记录，引用支撑度才适合用于回归比较。

引用支撑度评估常见问题

引用有了，为什么支撑度还是低？

先看来源是否真正包含声明中的关键限定词、数字和因果关系。实体相同只能说明相关，不等于完整支持；还要确认模型没有引用了未参与生成的片段。

可以只使用一个总分吗？

总分适合看趋势，不适合定位故障。至少并列保存 coverage、valid_source、retrieval 和 entailment，否则检索问题与生成越界会互相遮蔽。

Hugging Face Evaluate 是否直接提供引用支撑度指标？

Evaluate 提供通用指标、评估器和自定义评估模块能力，RAG 引用支撑度仍需要项目自己定义样本字段与判定规则。不要把通用准确率直接当成引用支撑度。