怎么说呢，

💬 那个置信度，你真敢拿来分流吗？

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

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

很多做智能文档处理的人默认「模型自报的置信度 = 真实把握」，但现实往往打脸——大模型在提取错的时候照样说「我 % 确定」。如果校准失准，按置信度路由的整套人机协作就会出现两大毛病：

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

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

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

🤔 这篇论文到底想解决什么问题？不过，

研究问题一句话： 视觉语言模型在文档关键信息提取里自报的置信度。能不能信，能否拿它可靠地把结果分流到「直接自动化」或「送人工审查」？

This matters because IDP 程序几乎都靠“置信度阈值”做人机协作路由。阈值设定假设模型的置信度真的反映答对概率。一旦模型过度自信，阈值路由会失灵——要么错误漏审导致风险。要么人工队列爆炸导致成本。其实，

如果你现在按固定阈值路由。却没有验证校准，你可能正在让错误逃脱或浪费大量人工。

为什么以前没人好好测这个？不过，

缺合适基准。使 ECE 等指标无法在低精度区评估。常规基准只提供高质量样本，让你难以了解低置信度场景下模型表现。

至于第一步先，造难样本。

• Mild / Moderate / High 难度等级：Agraphy 退化引擎将真实 FCC 发票逐步转化为三阶段退化。生成 6000+ 退化变体.
• OCR‑Safe 约束： 退化力度保持在“精度下降但不至于全失败”的区间内，让我们能够真正测校准，而不是因为全部识别失败而无梯度。
• "低精度区" 填充完成： 原始发票集中在高精度峰；退化后形成新的低精度峰，为校准提供必要数据。

说到接下来，让模型各显神通。

• MVP 模型阵容： 专有 & 开源。
• • 📝 OCR‑only: 抽出的文本；
  • 📝+🖼️ OCR+Image: 文本 + 原图；
  • 🖼️ Image‑only: 原图；

获取置信度的方法：

 "LogProb":  利用内部 token 对数概率：

• first-token 
• mean-token 
• margin 

：用接地气指标算经济账。

1. # 排序所有预测从低到高置信；最低先排，# 按 % 的预算挑前部分送人工审查。不过，# 在这 % 内统计实际抓到多少错误。# 与随机抽取相同比例时预期抓到错误数量比较得到比值 —— 即 ECARB.

。

📈 效果到底怎么样？

：模态选择决定“准确&可信”双赢，而不是单纯提高准确率。”