RAG 答案置信度生产实战：Answerability、Risk–Coverage、校准与拒答

从硬约束、证据充分性、Claim 支持、模型不确定性、概率校准、Risk–Coverage 到回答、追问、补检索和拒答策略，搭建可解释、可评测、可持续校准的生产级 RAG 置信度系统。

很多 RAG 产品都会在答案旁边展示一个看起来很精确的数字：

置信度：87%

这个数字很容易让用户产生错误理解：

它是答案正确的概率吗？
是向量相似度换算的吗？
是第一名候选的 Rerank Score 吗？
是模型自己说“我有 87% 把握”吗？
不同问题、语言、模型和知识库中的 87% 可以比较吗？
87% 为什么允许回答，86% 为什么拒答？

在没有校准数据、Cohort、阈值策略和错误定义时，87% 往往只是一个具有误导性的 UI 数字。

生产级 RAG 不需要一个“万能置信度”，而需要一套选择性回答系统：

硬约束是否通过
+
证据是否足够
+
答案 Claim 是否被证据支持
+
当前模型和 Pipeline 在相似样本上的真实正确率
+
业务能接受多大错误风险
+
失败后应该回答、追问、补检索、转人工还是拒答

资料快照：本文核查截至 2026-08-06。模型自我评估部分参考 Language Models (Mostly) Know What They Know 的 P(True) 与 P(IK)；生成不确定性部分参考 2024 年 Nature 发表的 Semantic Entropy；概率校准参考 Guo 等人的 Temperature Scaling；选择性回答参考 Selective Classification 与 SelectiveNet。研究结论不能直接替代业务校准：生产阈值必须基于自己的数据集、Pipeline Version、Query Cohort 和风险成本确定。

RAG 答案置信度生产实战：从证据、校准、风险覆盖到回答、追问和拒答决策

图 1：置信度的最终产物不是一个百分比，而是一个带有证据、校准版本、风险边界和行为策略的决策。

一句话结论

RAG 置信度系统应该遵循下面的顺序：

Hard Veto
→ Evidence Sufficiency
→ Claim Support
→ Calibrated Probability
→ Risk-aware Policy
→ Answer / Caveat / Clarify / Retrieve More / Handoff / Abstain

其中：

权限、安全、无效引用和关键依赖失败不能被高分覆盖。
向量相似度、Rerank Score 和 LLM 自评都只能作为 Feature。
校准概率必须说明预测目标、数据分布和版本。
不同业务严重度应使用不同 Risk–Coverage 工作点。
拒答质量、错误回答率和错误拒答率必须同时评测。
用户看到的是行为理由，而不是一个伪精确的小数。

1. 先定义“置信度”到底预测什么

confidence 这个字段如果没有明确目标，就无法校准，也无法评测。

常见目标至少有六种：

目标	定义	是否等价
`p_answerable`	当前可访问语料是否足以回答问题	不等于答案正确
`p_evidence_sufficient`	当前 Context 是否覆盖所需证据	不等于模型会正确使用
`p_claim_supported`	某个 Claim 是否被 Context 支持	不等于世界事实正确
`p_answer_correct`	当前答案是否符合业务事实和 Rubric	不等于引用完整
`p_citation_valid`	引用是否存在、支持、可访问和可定位	不等于答案完整
`p_policy_safe`	按当前策略展示答案是否安全	不等于模型能力强

因此不要只存：

{
  "confidence": 0.87
}

至少要存：

{
  "confidence": {
    "target": "answer_correct",
    "probability": 0.87,
    "calibration_model": "answer-calibrator-v7",
    "cohort": "zh-CN|concept|kb-policy|high-risk",
    "pipeline_version": "rag-pipeline-v24",
    "decision": "answer_with_citations"
  }
}

1.1 Answerability 与 Correctness 必须分开

下面两种情况经常被混淆：

语料中有完整证据，但模型答错
→ answerable = true
→ answer_correct = false

语料中没有证据，但模型凭参数知识答对
→ answerable = false
→ answer_correct 可能碰巧为 true

RAG 的目标通常不是“碰巧答对”，而是提供可追溯的 Grounded Answer。因此 Answerability 应独立评测。

1.2 Answer-level 与 Claim-level 必须分开

一个答案可能包含四个 Claim：

C1 正确且有证据
C2 正确但无引用
C3 只被证据部分支持
C4 错误

把整个答案压成 0.75 会丢失重要信息。高风险场景应保留：

answer-level decision
+
claim-level support / correctness / citation status

2. 置信度信号栈：不是所有信号都属于同一层

RAG 置信度信号栈：硬约束、检索证据、上下文与 Claim、模型不确定性共同进入校准和决策

图 2：先处理不可妥协的 Hard Veto，再把其余信号交给校准模型；不要用一个高相似度覆盖权限或无效引用。

可以把信号分成四组。

2.1 Hard Veto

这些条件不应该参与加权平均，而应该直接阻断：

Unauthorized Retrieval / Context / Citation；
Citation Key 不存在；
Source Revision 不匹配；
Required Anchor 无法解析；
关键 Tool 调用失败；
输出 Schema 无效；
命中高严重度安全规则；
业务要求必须有证据，但 Context 为空；
关键数据源已知不可用；
Tenant / ACL Scope 无法确定。

错误做法：

向量相似度 0.95
+ 权限检查失败 -0.20
= 最终置信度 0.75
→ 仍然回答

正确做法：

permission_allowed = false
→ decision = block

2.2 Retrieval Evidence

BM25 是否命中精确实体、错误码或版本号；
Dense 是否找到语义相关证据；
两路候选是否一致；
Top-1 / Top-2 Margin；
RRF 后 Gold-like Evidence 是否靠前；
Rerank 前后排名变化；
Query Rewrite 是否保留 Anchor；
多 KB 是否使用同一 Embedding 空间；
正确来源是否被 Filter 排除；
Source Authority、Freshness 和 Revision。

2.3 Context 与 Claim

问题中的实体、时间、数值和比较约束是否被覆盖；
多跳问题的 Evidence Chain 是否完整；
Context 是否冲突；
Context 是否被截断；
是否包含过多重复内容；
Required Claims 是否都有 Evidence；
Claim–Evidence Support；
Citation Precision / Recall；
是否需要 Clarification。

2.4 Model 与 Runtime

P(True) 或其他自评；
多次采样的一致性；
Semantic Entropy；
Judge Score；
模型是否进入 Degraded Route；
Token 截断；
Timeout / Retry；
Tool 是否返回 Partial Result；
Cache 是否命中旧 Pipeline Version。

这些信号都可能有价值，但没有任何一个应被单独称为“最终置信度”。

3. 为什么向量相似度不能直接当答案置信度

向量相似度回答的是：

Query Embedding 与 Document Embedding 在当前空间中有多接近？

它不直接回答：

这段证据是否完整回答问题？
模型是否会正确理解？
答案是否有引用？
来源是否最新？
用户是否有权限？

3.1 不同模型的 Score 不可直接比较

Embedding A 的 cosine 0.82
Embedding B 的 cosine 0.82

两个分数不一定表达同样的相关程度。

3.2 不同 Query Cohort 的分布不同

错误码查询
→ 正确结果可能由 BM25 精确命中
→ Dense Score 不一定高

抽象概念查询
→ Dense Score 可能高
→ BM25 Score 不一定强

3.3 高相似不代表可回答

问题：

“这个政策什么时候生效？”

检索到的段落可能都在讨论该政策，但没有生效日期。语义相关性高，Answerability 仍然低。

3.4 Score Margin 也只是 Feature

第一名远高于第二名，有时说明结果清晰；也可能说明整个索引里只有一个“勉强相关”的文档。

因此至少需要结合：

absolute relevance
+
rank margin
+
evidence coverage
+
source quality

4. Evidence Sufficiency：真正回答问题需要什么证据

4.1 从 Query Constraint 开始

Query Planner 应提取：

{
  "entities": ["external version", "Tombstone"],
  "intent": "explain_why",
  "constraints": {
    "time": null,
    "scope": "elasticsearch consistency",
    "comparison": null
  },
  "required_facts": [
    "external version 的保护边界",
    "删除版本信息的保留窗口",
    "旧 UPSERT 复活路径",
    "Tombstone 与 Repair Job 的作用"
  ]
}

Evidence Sufficiency 可以定义为：

Required Facts 中有多少被 Context 中至少一个可用 Evidence 支持

4.2 一个简单的 Feature Schema

{
  "evidence": {
    "required_fact_count": 4,
    "covered_fact_count": 4,
    "coverage": 1.0,
    "direct_support_rate": 0.75,
    "source_count": 2,
    "authoritative_source_count": 1,
    "fresh_source_rate": 1.0,
    "conflict_count": 0,
    "unresolved_conflict_count": 0
  }
}

4.3 不是所有问题都能预先列出 Required Facts

开放问题可以采用：

Query Decomposition；
Schema / Domain Rubric；
Claim Proposal；
Answerability Judge；
人工定义的核心问题集；
线上 Bad Case 反向沉淀。

但要避免让同一个模型同时：

生成 Required Facts
→ 生成答案
→ 判断自己是否覆盖

这种闭环很容易产生自我确认偏差。高风险场景应使用独立模型、确定性规则或人工 Rubric。

5. 模型自评：P(True) 与 P(IK) 能做什么

Language Models (Mostly) Know What They Know 研究了两类自我评估：

P(True)
→ 在模型已经提出一个答案后，估计该答案正确的概率

P(IK)
→ 在没有固定答案时，估计模型是否“知道”如何回答问题

研究显示这些信号具有一定预测能力，并且在部分任务上可校准；但 P(IK) 对新任务的校准泛化存在困难。

工程结论是：

P(True) 可以成为答案后验证 Feature；
P(IK) 可以成为 Query Routing Feature；
都需要在本地任务上重新校准；
不能替代 Evidence、权限和 Citation Validation；
不能把模型输出的 0.9 直接展示给用户。

示例：

{
  "self_evaluation": {
    "p_true_raw": 0.92,
    "p_ik_raw": 0.88,
    "prompt_version": "self-eval-v4",
    "model": "model-x",
    "calibrated_p_correct": 0.71
  }
}

注意 0.92 → 0.71 并不矛盾：原始自评可能过度自信，校准模型会根据真实历史表现修正它。

6. 多次采样与 Semantic Entropy

普通 Token Entropy 对开放式文本不够稳健，因为不同字符串可能表达同一个意思：

“7 天内”
“七日内”
“订单完成后的一个星期内”

Semantic Entropy 的核心思路是：

对同一问题采样多个答案；
按语义等价关系聚类；
对语义簇而不是字符串计算不确定性。

2024 年 Nature 论文显示，在其研究的多组任务和模型上，Semantic Entropy 对不可回答或错误输出具有较强检测能力，并优于若干基线。

但生产使用有成本：

需要多次模型采样；
需要语义等价判断；
长答案聚类昂贵；
一致地生成同一个错误答案，Entropy 仍可能很低；
领域内专业细微差异可能被误聚类。

推荐只在下面场景启用：

高风险问题
+
第一阶段信号处于灰区
+
延迟预算允许

示例：

{
  "semantic_uncertainty": {
    "sample_count": 5,
    "semantic_cluster_count": 3,
    "semantic_entropy": 0.84,
    "dominant_cluster_share": 0.4,
    "method_version": "semantic-entropy-v2"
  }
}

7. Calibration：让 0.8 真正接近 80% 正确率

如果一个系统对 1000 个请求都预测 p_correct ≈ 0.8，其中大约 800 个真的正确，才可以称为接近校准。

7.1 Reliability Diagram

把预测概率分桶：

0.0–0.1
0.1–0.2
...
0.9–1.0

每个桶比较：

平均预测概率
vs
真实正确率

理想情况落在对角线上。

7.2 常用指标

指标	关注点	注意事项
ECE	分桶后的平均校准误差	依赖分桶方式
Brier Score	概率预测与二元标签的平方误差	同时受准确率与校准影响
NLL	对真实标签赋予的概率质量	对极端错误很敏感
AUROC	区分正确与错误的排序能力	不代表概率已校准
AUPRC	错误样本稀少时的区分能力	依赖正负类定义

一个模型可以 AUROC 很高，但概率严重失真；也可以校准较好，但区分能力弱。两者都要看。

7.3 后处理校准方法

Temperature Scaling

Guo 等人的研究表明，Temperature Scaling 在其分类实验中是简单而有效的后处理方法。

logit / T
→ sigmoid / softmax

它通常不改变排序，只修正概率尺度。

Platt Scaling

使用 Logistic Regression 将 Raw Score 映射为概率。

Isotonic Regression

不假设线性关系，适合数据量较大、映射单调但形状复杂的情况。

Histogram Binning

简单易解释，但容易受样本量和分桶影响。

7.4 不要使用一个全局 Calibrator

推荐按 Cohort 评估：

language
query_type
domain
tenant tier
retrieval mode
answer behavior
model family
pipeline version
risk severity

例如：

zh-CN 的错误码查询
和
英文多跳政策比较

分数分布和错误模式完全不同。

如果样本不足，可以采用：

global calibrator
+
cohort correction
+
minimum sample fallback

8. 置信度 Feature 不应直接做手工加权平均

常见实现：

confidence =
0.3 × vector_score
+ 0.2 × rerank_score
+ 0.2 × judge_score
+ 0.2 × citation_score
+ 0.1 × source_authority

问题包括：

Feature 不同尺度；
强相关 Feature 被重复计算；
权限等 Hard Gate 被平均；
权重对 Cohort 不稳定；
没有真实标签支撑；
Pipeline 改版后分布漂移。

更可靠的方案：

Hard Rules
→ 先剔除不可回答请求

Feature Vector
→ Logistic Regression / GBDT / Monotonic Model

Calibration
→ Temperature / Isotonic / Platt

Policy
→ 根据风险、成本和 Coverage 选择行为

8.1 推荐的 Feature Vector

{
  "query": {
    "type": "multi_hop_temporal",
    "language": "zh-CN",
    "ambiguity_score": 0.12,
    "anchor_preservation": 1.0
  },
  "retrieval": {
    "bm25_top1": 14.2,
    "dense_top1": 0.81,
    "channel_agreement": 0.67,
    "rrf_top1_margin": 0.018,
    "rerank_top1": 0.91,
    "rerank_margin": 0.16
  },
  "evidence": {
    "required_fact_coverage": 0.75,
    "direct_support_rate": 0.67,
    "freshness_rate": 1.0,
    "authority_score": 0.9,
    "unresolved_conflicts": 1
  },
  "answer": {
    "claim_coverage": 0.8,
    "citation_precision": 1.0,
    "citation_recall": 0.8,
    "p_true_raw": 0.88,
    "semantic_entropy": 0.42
  },
  "runtime": {
    "degraded": false,
    "timeout_count": 0,
    "tool_failures": 0
  }
}

8.2 单调约束很有价值

在可解释模型中可以要求：

unresolved_conflict 增加
→ p_correct 不应上升

required_fact_coverage 增加
→ p_answerable 不应下降

unauthorized_evidence = true
→ 直接 Hard Veto

9. Selective Prediction：用 Coverage 换取更低风险

Risk–Coverage 曲线：提高回答覆盖率通常会增加错误风险，不同业务严重度应选择不同工作点

图 3：拒答让系统放弃一部分不确定请求，从而降低已回答请求中的错误率；最优阈值取决于业务风险，而不是追求一个统一的 0.8。

Selective Classification 又称 Reject Option：模型可以选择不对所有输入给出预测。

在 RAG 中：

Coverage =
选择回答的请求数
÷
全部请求数

Selective Risk =
选择回答的请求中错误请求数
÷
选择回答的请求数

通常：

阈值提高
→ Coverage 下降
→ Selective Risk 下降

9.1 Risk–Coverage Curve

对不同阈值计算：

threshold
coverage
selective_risk
false_answer_rate
false_refusal_rate

不要只选一个点，要看整条曲线。

9.2 AURC

Area Under the Risk–Coverage Curve 可以概括模型在不同 Coverage 下的选择性表现，但上线决策仍要看目标工作点和高严重度 Case。

9.3 不同严重度使用不同阈值

场景	更关心	策略
权限与敏感数据	Unauthorized / False Answer	严格 Hard Gate，低 Coverage 可接受
财务、法律、医疗流程	Critical False Answer	高阈值、更多 Clarification / Handoff
企业内部知识问答	Wrong Action / Stale Policy	中高阈值、强 Citation
通用技术解释	Useful Coverage	平衡 Answer 与 Caveat
灵感与探索	User Utility	可提高 Coverage，但标明推断与不确定性

10. 阈值不应该只控制 Answer / Refuse 两个状态

RAG 置信度决策树：从 Hard Gate、Evidence、冲突和校准概率到回答、补检索、追问、人工升级与拒答

图 4：置信度需要编译成行为；同样的低分，在问题含糊时应追问，在证据不足时应补检索，在高风险时应转人工。

推荐至少支持六种行为：

answer_with_citations
answer_with_caveat
answer_conflict_explained
retrieve_more
clarify
handoff
abstain_with_reason

10.1 行为矩阵

状态	行为
Hard Gate 失败	Block / Abstain
Evidence 足够、无冲突、概率高	Answer with Citations
Evidence 足够但存在可解释冲突	Explain Conflict
Query 含糊、补充一个条件即可回答	Clarify
Evidence 不足但可通过额外检索补齐	Retrieve More
高风险且概率处于灰区	Handoff
Evidence 不足且不可补救	Abstain with Reason
低风险、部分证据可用	Answer with Caveat

10.2 拒答要说明原因

差的拒答：

抱歉，我无法回答。

好的拒答：

当前可访问资料只说明了退款条件，没有找到申请时限，因此无法可靠回答“最晚什么时候申请”。
你可以补充政策版本，或允许我查询最新官方政策。

拒答应该告诉用户：

缺少什么；
哪些内容已经确认；
怎样补充；
是否可以升级查询或转人工。

11. Query Ambiguity：有时应该追问，而不是降低分数

问题：

“这个什么时候生效？”

如果会话中有多个候选对象，系统无法确定 这个 指什么。

此时最合理的行为不是：

confidence = 0.42
→ 拒答

而是：

decision = clarify
clarification_question = "你指的是退款政策 v3，还是新的索引迁移方案？"

建议记录：

{
  "ambiguity": {
    "ambiguous": true,
    "missing_slots": ["target_policy"],
    "candidate_entities": ["refund_policy_v3", "index_migration_plan"],
    "clarification_expected_gain": 0.46
  }
}

11.1 Clarification Value

可以估计：

追问一个 Slot 后，Answerability 预计能提高多少

如果提升很小，继续追问只会增加用户负担；此时应拒答或提供相关资料。

12. Evidence Conflict：冲突不是简单减分

Context 中可能同时存在：

旧政策：退款窗口为 14 天
新政策：退款窗口为 7 天

如果问题问“当前政策”，应按有效时间和权威来源选择新版。

如果问题问“政策如何变化”，两个版本都必须保留。

推荐结构：

{
  "conflict": {
    "detected": true,
    "type": "temporal_revision_conflict",
    "evidence": [
      {
        "evidence_id": "old_policy",
        "valid_to": "2026-06-30",
        "stance": "14_days"
      },
      {
        "evidence_id": "new_policy",
        "valid_from": "2026-07-01",
        "stance": "7_days"
      }
    ],
    "resolution": "latest_valid_authoritative"
  }
}

系统不应把“存在冲突”机械视为不能回答，而应区分：

已由时间解决；
已由 Authority 解决；
需要向用户解释；
仍然无法解决。

13. Claim-level Confidence 与答案策略

假设答案包含四个 Claim：

{
  "claims": [
    {
      "claim_id": "c1",
      "text": "External version 可以阻止旧版本覆盖。",
      "p_supported": 0.98,
      "decision": "include"
    },
    {
      "claim_id": "c2",
      "text": "删除版本信息会永久保留。",
      "p_supported": 0.08,
      "decision": "remove"
    },
    {
      "claim_id": "c3",
      "text": "Tombstone 应覆盖消息重放窗口。",
      "p_supported": 0.91,
      "decision": "include"
    },
    {
      "claim_id": "c4",
      "text": "保留 24 小时就一定足够。",
      "p_supported": 0.44,
      "decision": "qualify"
    }
  ]
}

最终答案可以：

删除 C2；
保留 C1、C3；
将 C4 改成“保留窗口需要覆盖最大延迟与重放周期，不能统一写死为 24 小时”。

这比对整个答案做一次 confidence < 0.8 → 全部拒答 更有用。

13.1 Answer Confidence 的聚合方式

可以使用：

关键 Claim 的最小值
加权 Required Claim Coverage
风险敏感聚合

不要简单平均。一个 Critical Claim 低置信，不能被十个背景 Claim 拉高平均值。

14. 两阶段决策：生成前与生成后

14.1 生成前 Answerability Gate

输入：

Query Plan
Retrieval Candidates
Context Manifest
Source / Permission / Freshness

输出：

answerable
clarify
retrieve_more
abstain

它避免为明显无证据问题支付生成成本。

14.2 生成后 Grounding Gate

输入：

Answer Claims
Claim–Evidence Links
Citation Validation
Self Evaluation
Semantic Uncertainty

输出：

publish
repair
qualify
abstain

完整流程：

推荐最多一次受控 Retrieval Expansion 和一次 Answer Repair，避免无限 Agent Loop。

15. Calibration Dataset 应该标什么

一条样本至少包含：

{
  "case_id": "conf_0042",
  "question": "为什么删除后的旧事件会让 ES 文档复活？",
  "query_type": "concept_with_constraint",
  "severity": "high",
  "scope": {
    "tenant_id": "tenant_001",
    "knowledge_base_ids": ["kb_rag"]
  },
  "expected_behavior": "answer_with_citations",
  "labels": {
    "answerable": true,
    "evidence_sufficient": true,
    "answer_correct": true,
    "all_required_claims_supported": true,
    "citation_valid": true,
    "policy_safe": true
  },
  "required_claims": [
    "删除版本信息只保留有限时间",
    "旧 UPSERT 可能在窗口后复活文档",
    "Tombstone 与 Repair Job 是补偿机制"
  ]
}

15.1 数据集分层

数据集	用途
Calibration Set	拟合概率映射
Validation Set	选择阈值和方法
Hidden Test Set	评估泛化
Safety Set	验证 Hard Gate
Shadow Set	检测线上分布漂移
Regression Set	防止历史错误重现

不要用同一批样本同时训练、调阈值和报告最终效果。

15.2 错误标签要稳定

answer_correct 必须有明确 Rubric。否则模型校准的是标注员偏好，而不是业务正确性。

高风险样本建议至少两人标注，争议进入仲裁。

16. 离线评测指标

16.1 Accuracy / AUROC 不是全部

需要同时看：

Accuracy；
AUROC / AUPRC；
ECE；
Brier；
NLL；
Risk–Coverage；
AURC；
False Answer Rate；
False Refusal Rate；
Critical False Answer Rate；
Clarification Success Rate；
Retrieve-more Recovery Rate；
Handoff Precision。

16.2 False Answer 与 False Refusal

False Answer
→ 系统选择回答，但答案错误或无依据

False Refusal
→ 语料和模型本来可以可靠回答，但系统拒答

不同业务的成本不同：

高风险业务
→ False Answer 成本远高于 False Refusal

低风险助手
→ 过度拒答会严重损害可用性

16.3 Case-level Diff

Baseline 与 Candidate 必须在同一批 Case 上比较：

{
  "case_id": "conf_0042",
  "baseline": {
    "p_correct": 0.81,
    "decision": "answer",
    "correct": false
  },
  "candidate": {
    "p_correct": 0.63,
    "decision": "retrieve_more",
    "correct_after_retrieval": true
  },
  "classification": "improved"
}

虽然 Candidate 的初始概率更低，但它做出了更好的行为决策。

17. 阈值配置应该版本化

confidence_policy_version: confidence-policy-v8

cohorts:
  - match:
      severity: critical
    hard_gates:
      unauthorized_evidence: block
      invalid_citation: block
      unresolved_required_anchor: block
    thresholds:
      answer: 0.97
      answer_with_caveat: 0.90
      handoff: 0.70
    fallback: abstain

  - match:
      severity: high
      query_type: multi_hop
    thresholds:
      answer: 0.90
      retrieve_more: 0.62
      clarify: 0.55
    max_retrieval_expansions: 1
    fallback: handoff

  - match:
      severity: medium
    thresholds:
      answer: 0.80
      answer_with_caveat: 0.68
      retrieve_more: 0.50
    fallback: abstain

每次决策都要记录命中的 Policy Rule。

18. API 契约

18.1 内部决策响应

{
  "request_id": "req_001",
  "decision": "answer_with_citations",
  "confidence": {
    "target": "answer_correct",
    "raw_score": 2.34,
    "calibrated_probability": 0.91,
    "calibration_model": "answer-calibrator-v7",
    "cohort": "zh-CN|concept|high",
    "policy_version": "confidence-policy-v8"
  },
  "hard_gates": {
    "passed": true,
    "failures": []
  },
  "evidence": {
    "required_fact_coverage": 1.0,
    "unresolved_conflicts": 0,
    "citation_precision": 1.0
  },
  "explanation_codes": [
    "EVIDENCE_COMPLETE",
    "CITATIONS_VALID",
    "CALIBRATED_ABOVE_HIGH_RISK_THRESHOLD"
  ]
}

18.2 对用户的响应

不要把全部内部 Feature 暴露给用户：

{
  "answer": "...",
  "citations": ["cite_1", "cite_2"],
  "answer_status": "verified",
  "confidence_label": "高",
  "confidence_explanation": "答案由两份当前有效资料支持，关键结论均已通过引用校验。"
}

用户更需要：

为什么系统愿意回答；
哪些部分有证据；
是否存在冲突；
哪些内容是推断；
怎样验证。

18.3 不建议显示两位小数

置信度 87.43%

通常制造虚假精确感。可以展示：

已验证
证据有限
存在冲突
需要补充信息
无法可靠回答

如果业务必须展示概率，应同时展示定义和校准范围。

19. MySQL 数据模型

CREATE TABLE confidence_runs (
  confidence_run_id       VARCHAR(64) PRIMARY KEY,
  request_id              VARCHAR(64) NOT NULL,
  answer_id               VARCHAR(64),
  target                  VARCHAR(32) NOT NULL,
  raw_score               DECIMAL(10,6),
  calibrated_probability  DECIMAL(10,6),
  calibration_model       VARCHAR(64) NOT NULL,
  cohort_key              VARCHAR(256) NOT NULL,
  policy_version          VARCHAR(64) NOT NULL,
  decision                VARCHAR(32) NOT NULL,
  created_at              DATETIME(6) NOT NULL
);

CREATE TABLE confidence_features (
  confidence_run_id  VARCHAR(64) NOT NULL,
  feature_name       VARCHAR(128) NOT NULL,
  feature_value      DOUBLE,
  feature_json       JSON,
  feature_version    VARCHAR(64) NOT NULL,
  PRIMARY KEY (confidence_run_id, feature_name)
);

CREATE TABLE confidence_gate_results (
  confidence_run_id  VARCHAR(64) NOT NULL,
  gate_name          VARCHAR(128) NOT NULL,
  passed             BOOLEAN NOT NULL,
  reason_code        VARCHAR(128),
  detail_json        JSON,
  PRIMARY KEY (confidence_run_id, gate_name)
);

CREATE TABLE calibration_models (
  calibration_model  VARCHAR(64) PRIMARY KEY,
  target             VARCHAR(32) NOT NULL,
  cohort_definition  JSON NOT NULL,
  training_dataset   VARCHAR(128) NOT NULL,
  method             VARCHAR(32) NOT NULL,
  artifact_uri       TEXT NOT NULL,
  metrics_json       JSON NOT NULL,
  created_at         DATETIME(6) NOT NULL,
  retired_at         DATETIME(6)
);

决策事实应保持不可变；后续人工反馈和真实结果作为 Label 追加。

20. Trace 与可观测性

confidence.policy Span 至少记录：

confidence.target
confidence.raw_score
confidence.calibrated_probability
confidence.calibration_model
confidence.cohort
confidence.policy_version
confidence.decision
confidence.threshold
confidence.hard_gate_passed
confidence.degraded
confidence.reason_codes

不要把 Query、文档文本和用户身份作为 Metric Label。

20.1 指标面板

answer_coverage
selective_risk
false_answer_rate
false_refusal_rate
critical_false_answer_rate
clarification_rate
clarification_success_rate
retrieve_more_rate
retrieve_more_recovery_rate
handoff_rate
calibration_ece
confidence_drift

按低基数 Cohort 聚合：

language
query_type
severity
pipeline_version
decision

21. 在线漂移与再校准

下面变化都会让旧 Calibrator 失效：

Embedding 模型更换；
Chunk 策略变化；
Reranker 升级；
Answer Prompt 修改；
模型路由变化；
新数据源上线；
用户问题分布变化；
语言比例变化；
权限策略变化。

21.1 监控分布漂移

Feature PSI / JS Divergence；
Raw Score 分布；
Cohort 占比；
Prediction Histogram；
Calibration Error；
Error / Refusal 类型；
Shadow Set 表现。

21.2 再校准触发条件

recalibration:
  min_new_labels: 1000
  max_ece: 0.04
  max_brier_increase: 0.02
  max_feature_psi: 0.20
  trigger_on_pipeline_change: true

Calibrator 不是永久模型，必须和 Pipeline 一起发布、回滚和审计。

22. 缓存策略

置信度结果不能只按 Query 文本缓存。

Cache Key 至少包含：

normalized_query
scope_hash
corpus_revision
pipeline_version
calibration_model
policy_version
user_permission_hash
business_as_of

否则会出现：

新文档上线后仍使用旧 Answerability；
不同用户共享权限判断；
新 Calibrator 复用旧概率；
当前问题错误使用历史时间语境。

可以缓存：

Query Classification；
Embedding；
Claim–Evidence Support；
Semantic Equivalence；
Calibrator 输出。

但必须有正确版本边界。

23. 延迟与成本预算

置信度链路可能新增：

Answerability Judge
P(True)
Multi-sample Generation
Semantic Clustering
Claim Validation
Calibration Model
Policy Evaluation

建议分层启用。

层	成本	默认策略
Hard Gate	低	所有请求
确定性 Evidence Feature	低	所有请求
轻量 Calibrator	低	所有请求
Answerability Judge	中	灰区请求
P(True)	中	生成后灰区
Multi-sample Consistency	高	高风险灰区
Semantic Entropy	高	高风险且预算允许
人工 Handoff	很高	Critical / 无法自动决策

示例预算：

Hard Gate + Feature Extraction       15 ms
Calibration + Policy                  5 ms
Answerability Judge                  80 ms
P(True)                              60 ms
Semantic Entropy                   400–1500 ms

真正数值需要压测。

24. Release Gate

confidence_release_gate: confidence-gate-v5

hard_gates:
  unauthorized_answer_rate:
    max: 0
  invalid_citation_answer_rate:
    max: 0
  critical_false_answer_rate:
    max: 0
  confidence_trace_contract_rate:
    min: 1.0

calibration_gates:
  ece:
    max: 0.04
  brier_score:
    max_increase: 0.01
  hidden_test_auroc:
    min: 0.80

selective_gates:
  risk_at_80_percent_coverage:
    max: 0.05
  coverage_at_2_percent_risk:
    min: 0.55
  false_refusal_rate:
    max: 0.12

case_rules:
  high_severity_regressions:
    max: 0
  policy_behavior_regressions:
    max: 0

下面变化必须触发 Confidence Regression：

Feature Schema；
Calibration Dataset；
Calibration Model；
Query Planner；
Retrieval / Reranker；
Claim Validator；
Confidence Policy；
User-facing Label；
Risk Severity 定义。

25. 线上反馈怎样变成校准标签

用户点赞不等于答案正确，点踩也不一定是事实错误。

反馈需要分诊：

incorrect_fact
missing_information
wrong_citation
stale_source
over_refusal
under_refusal
unclear_answer
permission_problem

高质量 Label 来源：

领域专家审核；
工单最终结论；
用户纠错并经验证；
业务操作结果；
Citation Verification；
线上 Bad Case 复盘；
Shadow / Canary Paired Review。

每个 Label 应关联：

request_id
pipeline_version
confidence_run_id
decision
actual_outcome
reviewer
label_version

26. 常见反模式

反模式一：把向量相似度显示成 92%

它没有经过答案正确率校准。

反模式二：一个全局阈值控制所有问题

不同语言、Query Type 和风险场景分布不同。

反模式三：所有信号手工加权

尺度、相关性和分布变化都没有被验证。

反模式四：高分覆盖权限失败

Hard Gate 不能参与平均。

反模式五：只看 AUROC

区分能力不等于概率校准，也不等于正确工作点。

反模式六：只优化回答正确率

系统可能通过大量拒答获得很高准确率。

反模式七：只优化 Coverage

系统可能为了少拒答而大量强答。

反模式八：拒答没有原因

用户无法补充信息，Bad Case 也无法归因。

反模式九：让同一个模型生成并自我评分

容易形成自我确认偏差。

反模式十：P(True) 直接作为最终概率

新任务和新分布需要重新校准。

反模式十一：每次低分都调用五次采样

延迟和成本不可控。

反模式十二：Calibration Model 不跟 Pipeline 版本

Pipeline 改变后概率含义失效。

反模式十三：把置信度展示成两位小数

制造虚假精确感。

反模式十四：只做 Answer / Refuse

忽略 Clarify、Retrieve More、Caveat 和 Handoff。

反模式十五：错误拒答不进入 Bad Case

系统会越来越保守，却没人发现。

27. P0 / P1 / P2 落地路线

P0：先把行为和硬边界做正确

定义 Answerability、Correctness 和 Citation Validity；
Hard Gate；
Evidence Coverage；
Answer / Clarify / Retrieve More / Abstain；
基础 Calibration Set；
Logistic / GBDT + Platt / Isotonic；
False Answer / False Refusal；
Confidence Trace；
Policy Version；
User-facing Reason Code。

验收标准：

每次回答或拒答都能解释：
依据什么信号、命中哪条策略、使用哪个校准版本。

P1：校准与选择性评测

Cohort Calibration；
Reliability Diagram；
ECE / Brier / NLL；
Risk–Coverage / AURC；
Claim-level Support；
P(True)；
灰区 Answerability Judge；
Shadow Evaluation；
自动再校准触发；
High-risk Handoff。

P2：高级不确定性

Semantic Entropy；
多模型 Agreement；
Conformal / Distribution-free Risk Control；
Active Labeling；
Per-tenant Calibration；
Online Contextual Threshold；
Cost-aware Policy；
Long-horizon Agent Confidence；
Tool Outcome Probability；
人工与自动决策联合优化。

28. 上线检查清单

总结

RAG 置信度不是一个来自模型或检索器的现成字段，而是一套从证据到行为的决策基础设施：

Hard Gate
→ 保证不可妥协的安全和权限边界

Evidence Features
→ 描述语料是否足以回答

Claim Validation
→ 判断答案是否真正被证据支持

Uncertainty Signals
→ 提供模型自评、一致性和语义不确定性

Calibration
→ 把 Raw Score 映射为真实历史正确率

Risk–Coverage
→ 在回答覆盖率和错误风险之间选择工作点

Policy
→ 决定回答、限定、追问、补检索、升级或拒答

最重要的工程原则是：

不要问“这个答案的置信度是多少”，而要问“在当前证据、权限、风险和校准版本下，系统应该采取什么行为，以及该行为预计承担多大错误风险”。

当系统能够回答这个问题，confidence 才不再是 UI 装饰，而成为生产治理能力。

官方资料与原始论文

讨论

继续讨论这篇笔记

有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。

RAG 答案置信度生产实战：Answerability、Risk–Coverage、校准与拒答

继续讨论这篇笔记

On this page