![氛围图](https://developer.qcloudimg.com/http-save/8729876/d2f5dac7617193a08e0d175300e27165.jpg)

> 💡 **一句话总结**：ConfBench 用受控退化造出一份「低精度区」基准，首次系统测出 VLM 在文档提取时自报的置信度能不能信，还给了 ECARB 这个能直接算「省多少人工审核」的指标——做文档智能 / IDP 的人值得读。

## 💬 导语：那个 0.95 的置信度，你真敢拿它分流吗？

先问一个可能戳到你的问题：你那个跑得好好的文档抽取 pipeline，每条结果都附一个置信度分数，你是不是就按这个分数把高自信的自动入库、低自信的丢给人工复核？

如果是，再追问一句：**你验过那个分数本身可不可信吗？**

很多做智能文档处理（IDP，Intelligent Document Processing）的人都默认「模型自报的置信度 = 真实把握」，可现实常常打脸——大模型在提取错的时候照样拍胸脯说「我 95% 确定」。校准（calibration，就是「模型说的自信程度跟它实际答对的概率对不对得上」）一旦失准，按置信度路由的整套人机协作就会出两种毛病：

- **过度自信的错**：本该送审的错被自动通过，漏到客户或合规那里
- **过度不自信的对**：把一堆其实没问题的结果也丢去人工，审查队列被淹

而你要去验证校准好不好，会发现一个尴尬的现状：现有的文档基准（DocVQA、FUNSD 这类）都是干净高质量样本，正确率高得离谱，**错误样本和低自信样本实在太少**。可校准恰恰要在「模型答得不太好」的那段区间里才有意义——干净基准把这段盲区留给你了。

这正是 Amazon AWS 团队的 ConfBench 想填的坑。

> **想自己动手试？**
> - 📄 论文：[arXiv 2608.01792](https://arxiv.org/abs/2608.01792)
> - 📊 基准数据集：[HuggingFace · amazon/ConfBench](https://huggingface.co/datasets/amazon/ConfBench)
> - 📊 源数据集：[HuggingFace · amazon-agi/RealKIE-FCC-Verified](https://huggingface.co/datasets/amazon-agi/RealKIE-FCC-Verified)
> - 🛠️ 评估库：[GitHub · awslabs/stickler (conf-plus-date 分支)](https://github.com/awslabs/stickler/tree/local/conf-plus-date)

## 🤔 这篇论文到底想解决什么问题？

研究问题一句话：**视觉语言模型（VLM，就是能同时看图、读文字的大模型）在文档关键信息提取（KIE）里自报的置信度，能不能信？能不能拿它可靠地把结果分流到「直接自动化」或「送人工审查」？**

这件事为什么重要？因为 IDP 生产系统几乎都靠「置信度阈值」做人机协作路由——分数过线就自动处理、不过线就丢人工。这套逻辑成立的前提，是模型的置信度真的反映了它答对的可能性。一旦模型过度自信（这是大模型的通病），阈值路由就会失灵，要么错误漏审带来风险，要么人工队列爆炸带来成本。

那为什么以前没人好好测这个？因为缺合适的基准。测校准需要一种叫 **ECE（期望校准误差）** 的指标——简单说，它要看「模型说 80% 自信的那些预测里，实际是不是大约 80% 答对了」，而且要在从低到高各个自信区间都有足够样本才能算准。可现有文档基准都是干净样本，正确率集中在高位，错误和低自信样本稀疏，**低精度区根本没几个点**，ECE 在这段就算不准。

打个不太严谨但好记的比方：这就像你去做体检，可体检样本库里全是健康人——你想知道「各项指标在人不舒服时还准不准」，可样本里压根没几个不舒服的。ConfBench 干的第一件事，就是把这段盲区手动填满。下面这张图就是它的「战绩」——用 Claude Sonnet 4.5 跑同一批文档，原始 75 份发票的精度都挤在 0.6 以上（左峰），经过论文的退化处理后，0.0–0.6 的低精度区被实实在在填满了（右峰）。



*图说：左峰是「原本就干净」的文档，右峰是论文用退化「制造」出的难题——低精度区从无到有被填满，校准评估终于有了足够样本*

## 🛠️ 它的思路是什么？

ConfBench 的思路分三步走：**先把样本造难、再让模型各显神通、最后用一个接地气的指标算经济账**。

**第一步，把样本造难。** 作者拿 75 份人工核验过的真实 FCC 发票（来自 RealKIE-FCC-Verified）当底子，套上一个叫 **Augraphy** 的开源文档退化引擎，模拟一份真实文档从打印、流转到扫描一路上会遭的罪。退化分三个阶段，对应文档的「一生」：

- 🖨️ **墨水阶段（Ink phase）**：模拟字迹洇开、淡墨、印痕
- 📄 **纸张阶段（Paper phase）**：模拟老化、折痕、污渍、水印、打孔
- 📠 **后期阶段（Post phase）**：模拟 JPEG 压缩、旋转、扫描摩尔纹、传真/复印噪声、点阵打印

关键是有个 **OCR-Safe 约束**——退化力度卡在「精度有意义地下降、但不至于全军覆没」的区间。这点很要紧：如果退化太狠、模型全部识别失败，那也没法测校准（全错就没梯度了）。最后 75 份干净发票变成 1,346 个退化变体，按精度下降幅度分 Mild（轻）、Moderate（中）、High（重）三档。直观感受一下「同一份发票在轻度和重度退化下长什么样」——难度梯度一目了然：



*图说：原始的干净扫描件——模型在这种图上正确率高，但恰恰因此测不出校准盲区*



*图说：重度点阵打印退化——人看着都费劲，正好把模型推到「低精度区」，校准评估要的正是这种样本*

**第二步，让模型各显神通。** 作者拉了 7 个 VLM 来跑——4 个专有（Claude Opus 4.6、Sonnet 4.5、Haiku 4.5、Kimi K2.5）加 3 个开源（Qwen 3 VL-235B、Qwen 3.6-27B、Gemma 3-12B）。每个样本用 3 种输入模态喂给模型：

- 📝 **OCR-only**：只给 OCR 抽出来的文字
- 📝🖼️ **OCR+Image**：文字和原图都给
- 🖼️ **Image-only**：只给原图，让模型自己看

那置信度怎么拿？这是这篇论文最有意思的部分，它比了两大流派。

一是 **verbalized（语言化置信度）**——直接让模型「自己说」。做法是让模型对每个字段列出 top-4 个候选值并各打一个 0–1 的概率，取最高概率那个当结果、概率当置信度。妙处是**单次调用同时完成提取和打分**，省 token，而且明确不用 chain-of-thought（作者引前人发现 CoT 不改善校准）。

二是 **logprob（token 对数概率）**——扒模型内部。让模型贪婪解码吐出答案，然后取答案那串 token 各自的对数概率（模型生成时给每个 token 的内部打分），再按三种方式聚合成一个置信度：

- 🔹 **first-token**：只看答案第一个 token 的概率（「模型对这个值的开头有多笃定」）
- 🔹 **mean-token**：所有 token 的几何平均概率
- 🔹 **margin**：top-2 候选的标准化差距（差距越大越确定）

两条路径、加上模态和模型，最终汇成一张完整的对比矩阵。下图是整个实验设计的鸟瞰：



*图说：两条置信度获取路径从同一批退化文档出发，最终都汇入同一组校准指标做对比*

**第三步，用一个接地气的指标算经济账。** 这是这篇论文我最喜欢的地方。学术指标 ECE、Brier、AUROC 对运营者来说太抽象——你跟老板说「我们模型 AUROC 0.84」，老板关心的是「那我雇的人工能少看几条」。于是作者提出 **ECARB（审查预算下的错误捕获倍率）**，把校准直接换算成钱。它的工作方式是这样的：

1. 把所有预测按置信度从低到高排（最低自信的排最前，也就是「模型最该送审的」）
2. 取前 30% 送人工审查（30% 是你能负担的审查预算）
3. 数这 30% 里实际抓到了多少条错误
4. 拿这个数除以「随机抽 30% 期望抓到的错误数」

比值大于 1 就说明模型的置信度有路由价值——越大，说明同等人工能抓越多错。**比起一个抽象的 AUROC，运营者更需要「我审 30% 能比瞎蒙多抓几倍错」这种话。**

## 📈 效果到底怎么样？

7 个模型 × 3 种模态 × 4 种策略，跑出 7 万多条实体级评估。结果里我挑几条最值得在意的说。

**先看模态：OCR 文本和原图一起喂，是双赢。** 在「提取精度（WOA）」对「置信度判别力（AUROC）」的散点图上，OCR+Image 模态稳定占据右上角——既准又可信。这有点反直觉：你可能以为多给一份 OCR 文本只是帮模型提准，但它连带把置信度质量也抬上去了。换句话说，喂得全，模型不仅答得更对、对「自己答得对不对」也判断得更准。



*图说：右上角是「又准又可信」的理想区，OCR+Image 点云稳定挤在那里——给模型同时看文字和原图，是最划算的输入方式*

**再看模型：同一家校准随规模变好，跨家参数量却不灵。** Claude 家族内，校准随模型规模干净地单调提升：

| 模型 | AUROC↑（越高越会分辨对错） | ECE↓（越低越校准） |
|------|------|------|
| Claude Opus 4.6 | **0.84** | **0.05** |
| Claude Sonnet 4.5 | 0.77 | 0.13 |
| Claude Haiku 4.5 | 0.74 | 0.17 |

（AUROC：模型「把错和对分开」的能力，0.5 是瞎蒙、1.0 是完美；ECE：置信度数值跟实际正确率的偏差，越接近 0 越校准。）

这条「能力→校准」的单调关系在 Claude 家族里很漂亮。**但跨家族就翻车了**：Qwen 3.6-27B（AUROC 0.72）反而压过自家更大的 Qwen 3 VL-235B（0.62）。所以「参数量越大校准越好」这个直觉不成立——作者据此把结论模糊成「模型能力主导校准」，但「能力」到底指参数、数据还是对齐方式，论文没拆开讲（这点后面 caveat 再说）。最有说服力的是 reliability diagram（可靠性图），它直接把「模型说的自信」和「实际正确率」叠在一起比：



*图说：对角线是「说多少自信就答对多少」的完美校准；Opus 几乎贴着线，Haiku 则系统性跑偏——校准好坏一目了然*

**最后看经济账：ECARB 告诉你选错模型会浪费多少人工。** 在 30% 审查预算下，最佳配置（Claude Opus 4.6 + verbalized）达到 **2.43×**——也就是同等人工能抓到 2.43 倍于随机抽查的错误。最弱的配置（Gemma verbalized）也有 1.39×。**关键不是「都比 1 大」，而是 2.43 和 1.39 之间差了快一倍**——选错模型，你的审查团队效率就白白折半。

主表里还有一个我特别想点的细节：**「提取最准」和「置信度最可信」不是一回事**。看 Verbalized 这组，Sonnet 4.5 的提取精度（Acc 0.77）和 F1（0.51）其实反高于 Opus 4.6，但 Opus 的校准（ECE 0.05）远好于 Sonnet（0.13）。换句话说，Opus 提取略不那么准，但它「对自己答得对不对」判断得更诚实——而做人机协作路由，你恰恰更需要后者。下面这张主表摘录（OCR+Image 模态）值得存下来当参考：

| 模型（策略） | AUROC↑ | ECE↓ | ECARB@30%↑ |
|------|------|------|------|
| Claude Opus 4.6（verbalized） | **0.84** | **0.05** | **2.43** |
| Claude Sonnet 4.5（verbalized） | 0.77 | 0.13 | 2.24 |
| Claude Haiku 4.5（verbalized） | 0.74 | 0.17 | 1.96 |
| Qwen 3.6-27B（verbalized） | 0.72 | 0.22 | 1.93 |
| Gemma 3-12B（logprob first-token） | 0.64 | 0.36 | 1.45 |

最后一条值得记的：**置信度策略没有银弹**。Qwen 3.6-27B 上 verbalized（0.72）赢 logprob（0.62），可 Gemma 3-12B 上反过来，logprob（0.64）赢 verbalized（0.58）。所以「verbalized 一定比 logprob 好」这种结论不能下——换个模型可能就翻转，得实测。

## 🚀 为什么你要关心？

你可能不做发票提取，但只要工作里有大模型「自报置信度 + 按阈值路由」这套模式，这篇都跟你有关。几条我看到的实际落点：

- 🎯 **重新验你的置信度阈值**：如果你现在按某个固定阈值分流提取结果，拿这篇的方法在自家真实文档上复测一次 ECARB。很可能你会发现，信了很久的置信度，路由效率其实只有 1.3×——大量该送审的没送、不该送的浪费了人工。
- 🎯 **选模型别只看 F1**：这篇最大的贡献之一，是把「校准质量」单独立成一条跟「提取精度」并列的评估维度。以后选文档抽取模型，F1 高不代表置信度可信，得另看 AUROC / ECE——ConfBench 给了首个可比的基线。
- 🎯 **ECARB 这个指标直接拿走**：任何「靠置信度路由」的场景——欺诈审核、内容审核、医疗初审、RAG 答案要不要信——都能套 ECARB 算「我审这么多人能多抓几倍错」。它把抽象的校准统计量翻译成了运营听得懂的话。
- 🎯 **verbalized 1S-TopK 是个省钱的通用招**：单次调用同时拿到提取结果和置信度、不用多次采样、对所有 VLM 通用——如果你的 pipeline 还在用多次采样估置信度（贵），这套单阶段方法值得借鉴。

再往远看一层：多模态大模型做文档解析是这两年明确在火的方向，各家都在卷「提取准不准」。但「能不能信它的自信」是这条赛道落地生产的下一道关卡——ConfBench 恰好把这道关卡的头一份体检报告交了出来。

## ⚖️ 理性看待

几个该打问号的地方，挑最要紧的说。

**最该记住的一条：ConfBench 的「低精度区」是用 Augraphy 合成退化造出来的，不是真实部署里文档的自然低质量。** 真实生产里的低质，更多来自布局罕见、手写、跨领域模板、语义歧义，而不是扫描退化。所以 ECARB 那个漂亮的 2.43× 是「在合成退化分布上」的路由收益——一个模型可能对「扫描糊了」判断得很准（ECARB 高），却对「这个表单没见过」判断失准。迁到你自己的真实流量上，这个倍率很可能缩水。论文 limitations 提了单领域，但没强调「合成 vs 自然」这个对外推更根本的限制。

其次几个样本规模上的硬约束：

- 只用了 **75 份 FCC 发票**，单领域、单布局、单语言，外推到其他文档类型要打折
- 暴露 token-level logprob 的**开源模型只有 2 个**（Qwen 3.6-27B、Gemma 3-12B），所以「logprob 三聚合谁更好」「策略最优性随模型翻转」这两条结论样本偏小，别太当定律
- 跨模型比较有个没消除的混杂变量：**专有模型 token 预算 40K、开源只有 8K**，长文档截断会系统性压低开源模型的精度和置信度质量——开源 vs 专有的横向对比，你得自己打个折扣

另外，「模型能力主导校准」这条核心结论，在我看来更像**经验相关、而非因果机制**——论文展示了 Claude 家族内的单调关系，但「能力」是参数量、训练数据、对齐方式还是架构，没拆。跨家族参数量无效恰恰说明这事没那么简单，当成「经验观察」用没问题，别当成可迁移的定律。

最后一句实话：这是该细分方向目前最扎实的基线工作，数据、退化代码、评估库全开源——值得作为对照点和数据来源。但照搬到自己生产场景前，**务必先在真实流量上复测一次 ECARB**。

> 作者：lusca
> 版本：lusca-paper-blog v1.5.0
> 出处：https://github.com/yjmm10/lusca-skill/tree/main/skills/lusca-paper-blog



💡 一句话总结：ConfBench 用受控退化造出一份「低精度区」基准，首次系统测出 VLM 在文档提取时自报的置信度能不能信，还给了 ECARB 这个能直接算「省多少人工审核」的指标——做文档智能 / IDP 的人值得读。

ConfBench：大模型的「我很有把握」，到底能不能信？

ConfBench 是首个专门测试「VLM 在文档信息提取时自报的置信度可不可信」的基准。作者用 Augraphy 对 75 份真实发票做 20 种受控退化，把样本刻意推到现有干净基准测不到的「低精度区」，再用 7 个 VLM、3 种输入模态、4 种置信度策略跑出 7 万多条实体级评估。结论：OCR 文本加原图一起喂最准最可信；同厂家模型校准随规模变好，跨厂家参数量却不靠谱。作者还提出 ECARB，把校准直接换算成「能省多少人工审核」——做智能文档处理、需要人机协作路由的开发者值得读。

人工智能

新闻资讯

算法

ConfBench通过受控退化生成低精度文档基准，首次系统评估VLM在文档提取中置信度的可靠性，并引入ECARB指标量化人工审核效率。实验显示OCR+Image模态最优，Claude Opus校准最佳（ECARB 2.43×），且提取精度与置信度可信度独立。为IDP系统置信度路由提供首个可复现评估基线。

人机协作

文档处理

路由

GitHub

2026上云采购 | AI焕新·智启新局

documentocr

tione

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

ConfBench：大模型的「我很有把握」，到底能不能信？-腾讯云开发者社区-腾讯云

ConfBench：大模型的「我很有把握」，到底能不能信？

ConfBench：大模型的「我很有把握」，到底能不能信？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐