CONSTRUCT: Real-Time Trustworthiness Scoring for LLM Structured Outputs

Quick Start

先用 3 分钟抓住整篇论文。

最朴素的版本

LLM 现在可以按 schema 输出 JSON，但 JSON 格式对了，不代表里面的日期、金额、实体也对。CONSTRUCT 做的事很简单：再请一个 LLM 当检查员，从几个不同角度检查这份 JSON，最后给出“整份文档可信不可信”和“哪个字段最可疑”。

输入：原始任务、文档、schema、LLM 生成的 JSON。
检查：并行跑 5 个 verifier prompt，每个 prompt 看问题的角度不同。
打分：得到文档分和字段分，分数越低越需要人工复核。
用途：企业不用审全部文档，只优先审最可能错的那 1–5%。

一句话区分三个概念

Structured Output: 让 LLM 按固定 JSON/schema 输出，保证“形状”对。
token logprobs: 模型生成每个 token 时的自信程度，像“写这个词有多顺手”。
LLM-as-a-Judge: 请另一个 LLM 给答案打分，像找同事快速复核。
CONSTRUCT: 不是只找一个同事，而是让几个不同风格的检查清单并行工作，再把结论合并。

Background

为什么企业不是只要“结构合法”的 JSON？

Structured Outputs 解决的是格式约束：字段存在、类型符合 schema、输出能被下游程序消费。但企业真正怕的是语义错误：日期提错、金额算错、多个实体串线、该填的字段填成 null。论文的出发点是：结构化输出让自动化变得可能，trust scoring 才让自动化在规模化时可控。

95–99%

可自动化区间

作者从企业文档处理工作流观察到，如果只把低可信的 1–5% 交给人审，其余样本即可由 LLM 自动处理。

1 个

错误即可毁掉文档

文档级正确性定义很严格：只要任意字段错误，整个 structured output 就被视为 incorrect。

0–1

统一信任分

论文把 per-document 和 per-field trustworthiness 都映射到 \([0,1]\)，接近 1 表示更可信。

先别被术语绕住

这节其实只是在回答一个问题：LLM 已经输出 JSON 了，我们该用什么办法判断它有没有错？

把一份 JSON 想成一张报销单。格式都填好了，但发票日期可能不存在，金额可能差了 0.50，供应商也可能串了。token logprobs 只告诉你模型写这些字时顺不顺；LLM-as-a-Judge 像让一个同事看一眼；CONSTRUCT 像让几个不同检查清单同时扫一遍。

Problem Framing

它要解决的不是“生成”，而是“生成之后的风险排序”。

当前方法 1：训练一个 detector

优点是可专门优化；缺点是和企业实际需求相冲突：需要标注数据、训练/部署基础设施、还要随 generator model 更新而重训。论文认为这对已经忙着把 LLM 输出做好的团队来说过重。

需要标签需要部署模型更新成本高

当前方法 2：token logprobs

平均 token log probability 很常见，但它不等价于语义置信度。开放域生成中，同一语义可由大量 token 序列表达；logprobs 也难覆盖 epistemic uncertainty。更现实的是，不少黑盒或 reasoning LLM API 不暴露 token-level logprobs。

语义不稳定API 不一定提供跨模型不稳

当前方法 3：LLM-as-a-Judge 文档级

让 verifier 对整个 \((x,\hat{y})\) 给分，延迟低、实现简单，但容易漏看某些字段。结构化输出常有 20+ 字段，甚至 50+ 字段，单次全局判断会把注意力集中在显眼错误上。

便宜漏字段解释粒度不足

当前方法 4：LLM-as-a-Judge 字段级

每个字段单独 judge 最细，但成本随字段数线性增长；单次输出所有字段分数又容易分配注意力失败。论文把这两种方案作为 CONSTRUCT 的主要 baseline。

Multiple Calls 昂贵Single Call 容易分心字段数越多越痛

方法先看直觉

CONSTRUCT 的核心不是一个新模型，而是一个验证流程：同一个 verifier LLM 被问 5 个略有不同的问题。有的问题问“整份答案对吗”，有的问题问“每个字段对吗”，还有的问题先让模型列出可疑字段。最后把这些分数合并。

如果只问“这份表格整体对吗”，检查员可能漏掉小字段；如果每个字段都单独问，又太贵。CONSTRUCT 走中间路线：少量但多角度检查。

1. 原始任务文档、抽取指令、JSON schema

2. LLM 输出一个格式合法但可能有错的 JSON

3. 五路检查文档级、字段级、可疑字段列表

4. 聚合分数合并为文档分和字段分

5. 人审排序低分文档和字段优先检查

Method

CONSTRUCT 的关键：少量、多样、并行、可聚合的 verifier evidence。

作者没有押注一次完美 judge，而是设计 5 个互补 prompt，让 verifier LLM 从不同角度产出文档级分数 \(S_{\mathrm{doc}}(x,\hat{y})\) 和字段级分数 \(S_i(x,\hat{y}_i)\)。所有调用并行执行，无顺序依赖；超时调用可被忽略，以保持实时性。

算法流程

输入。拿到 generator LLM 的原始 prompt \(x\)、JSON/Pydantic schema、以及结构化输出 \(\hat{y}=[\hat{y}_1,\ldots,\hat{y}_n]\)。

并行验证。用同一个或任意 off-the-shelf verifier LLM 同时执行 5 个 prompt templates；论文实验中统一用 GPT-4.1-mini 做 scoring。

中间分数。模板输出 \(S_{\mathrm{doc}}\)、\(\{S_i\}_{i=1}^n\)，或先输出 suspicious fields 再间接映射成字段分。

聚合。用 harmonic average 把字段分变成额外文档级信号，再对所有文档级信号取 arithmetic mean；字段级信号也取 arithmetic mean。

解释。返回最低中间分对应的 explanation；字段解释只从产生字段级分数的 verifier calls 中选择。

五个 prompt 模板

E.1 文档级 confidence：先反驳答案可能错误，再给 0–100 分。

E.2 字段级 numeric：每个 top-level key 给 explanation + 0–100 score。

E.3 字段级 Likert：Certain / Mostly Certain / Somewhat Certain / Uncertain / Likely Incorrect。

E.4 文档级 + 间接字段级 accuracy：列出 incorrect fields，并给 0–100 overall confidence。

E.5 文档级 + 间接字段级 confidence：逐字段 evidence audit，列错字段，并给 0–10 rating。

附录消融显示，去掉任意一个模板都会降低整体 AUROC：E.1 为 4.4%，E.2 为 3.2%，E.3 为 3.6%，E.4 为 3.8%，E.5 为 5.7%。继续增加 verifier calls 的收益通常小于 1%。

What Is New

创新点不在复杂模型，而在把验证任务拆成了可实时部署的证据系统。

1. 面向 Structured Outputs 的 trust score

它同时给出文档级 \(S_{\mathrm{doc}}\) 和字段级 \(S_i\)，直接服务于 human-in-the-loop：先决定哪份文档要人看，再决定哪个字段要重点看。

2. 不依赖 logprobs 或标签

方法只需要 generator 的输入、schema 和输出，因此适用于黑盒 API、reasoning models、Anthropic/Gemini/OpenAI 等不统一暴露 token probability 的场景。

3. Prompt ensemble 的结构化聚合

5 个 verifier calls 在任务类型、评分格式、推理诱导上保持多样；聚合时用 harmonic average 捕捉“任一字段错则文档错”的结构。

4. 高质量 benchmark

论文没有直接沿用噪声标注，而是清洗/构造 4 个数据集，覆盖金融实体、PII、保险理赔、表格分析。这个贡献对 structured output 评测尤其关键，因为错误 ground truth 会把 detector 的排序能力评估反过来污染。

5. 延迟友好的工程形态

所有 verifier calls 并行，无 sequential dependency，并有 timeout 机制。相比每字段一次 judge，CONSTRUCT 的成本不随字段数线性爆炸，因此更适合 20+ 或 50+ 字段的企业抽取任务。

公式怎么读

这一节的公式只表达三件事：第一，JSON 有很多字段；第二，每个字段都有一个可信分；第三，只要一个关键字段很低，整份文档分就应该被拉低。

所以 harmonic average 在这里像“木桶效应”：一块木板很短，整桶水位就上不去。结构化输出也是一样，一个字段错，整份输出就不能放心自动通过。

Mathematical View

符号、映射与聚合：这篇论文的数学很朴素，但抓住了结构化输出的失效形态。

问题表示

给定输入 prompt \(x\)，generator LLM 产生满足 schema 的结构化输出 \(\hat{y}\)。schema 定义 \(n\) 个 top-level fields：

\[ \hat{y}=[\hat{y}_1,\hat{y}_2,\ldots,\hat{y}_n] \]

CONSTRUCT 产生文档级分数 \(S_{\mathrm{doc}}(x,\hat{y})\in[0,1]\)，以及每个字段的 \(S_i(x,\hat{y}_i)\in[0,1]\)。

间接字段分映射

对于 E.4/E.5 这类先列 suspicious fields 的模板，设 verifier 标记的字段集合为 \(I\subseteq\{1,\ldots,n\}\)，论文固定 \(\alpha=0.1\)、\(\beta=0.9\)：

\[ S_i(x,\hat{y}_i)= \begin{cases} \alpha, & i\in I,\\ \beta, & i\notin I, \end{cases} \quad 0\le \alpha < \beta \le 1 \]

这里的洞见是把“列错字段”当作 structured reasoning，让模型必须把关键证据写出来。

Likert 到数值

E.3 的五档 confidence 被映射为字段级数值：

\[ \text{Certain}\mapsto1,\quad \text{Mostly Certain}\mapsto0.75,\quad \text{Somewhat Certain}\mapsto0.5,\quad \text{Uncertain}\mapsto0.25,\quad \text{Likely Incorrect}\mapsto0 \]

字段分到文档分

因为文档级错误是字段错误的并集事件，论文用 harmonic average 作为 soft-minimum，把任一低分字段强烈传导到文档级：

\[ S_{\mathrm{doc}}^{(\mathrm{field})}(x,\hat{y}) = \frac{n}{\sum_{i=1}^{n}\frac{1}{S_i(x,\hat{y}_i)}} \]

最终文档级分数是所有文档级中间分的算术平均；最终字段级分数是所有字段级中间分的算术平均。

实验先看问题链

先准备更干净的 ground truth，因为旧数据集标注错误会误伤评测。
用 5 个主流模型生成 JSON，看它们到底会犯多少字段级错误。
再比较不同 trust score 方法，看谁最能把错误排到前面。
主指标 AUROC 可以理解为：错误样本能不能被排在更低可信度的位置。

Experiments

实验设计：先造一个更可信 benchmark，再评估谁更会发现错误。

论文强调现有 structured output benchmarks 的 ground truth 噪声很重，因此作者先构建/清洗 4 个数据集，再用 5 个 frontier LLM 生成输出，最后比较 4 类 trust scoring 技术在错误检测上的效果。

数据集

Financial Entities Extraction。清洗 FIRE 数据集，删除 Action、BusinessUnit、Designation、FinancialEntity、Sector 等歧义字段，合并 GeopoliticalEntity 和 Location，最终 7 个字段：Company、Date、Location、Money、Person、Product、Quantity。

PII Extraction。清洗 PII Entity Recognition 数据集，任务是在文本中抽取 56 类 PII，例如 age、credit card、city、street、IPV6 等。

Insurance Claims Extraction。作者自写保险理赔文档，输出 nested JSON，包含 claim identifiers、policy information、insured property、incident details 四大块及其子字段。

Data Table Analysis。作者创建 CSV-like tables，要求抽取行列数、列类型、min/max、统计量等，共 7 个字段，混合 string、numeric、dictionary 类型。

生成模型与评分模型

生成 structured outputs 的模型：

GPT-4.1-miniGPT-5Gemini-2.5-ProGemini-2.5-FlashGemini-3-Pro

所有 trust scoring 统一使用 GPT-4.1-mini 作为 verifier，包括 CONSTRUCT 与 LLM-as-a-Judge baselines。Gemini-2.5-Flash 使用 default thinking mode。

论文没有给出 temperature、max tokens 等完整 generation hyperparameters；可复现时应以公开 benchmark repo 和 API 默认 structured-output 设置为准，并记录各模型版本日期。作者明确说明 GPT-5 与 Gemini-3-Pro 在实验日期不暴露 token-level logprobs，因此 token-probability baseline 对这些模型省略。

Table 1：生成模型在四个 benchmark 上的准确率

Benchmark / Metric	GPT-4.1-mini	GPT-5	Gemini-2.5-Pro	Gemini-2.5-Flash	Gemini-3-Pro
Financial Entities · Field Accuracy	0.922	0.949	0.887	0.919	0.935
Financial Entities · Document Accuracy	0.580	0.700	0.422	0.557	0.624
PII Extraction · Field Accuracy	0.966	0.979	0.972	0.973	0.979
PII Extraction · Document Accuracy	0.260	0.460	0.300	0.330	0.440
Insurance Claims · Field Accuracy	0.750	0.767	0.775	0.758	0.775
Insurance Claims · Document Accuracy	0.333	0.300	0.400	0.300	0.300
Data Table Analysis · Field Accuracy	0.863	0.956	0.944	0.829	0.964
Data Table Analysis · Document Accuracy	0.450	0.760	0.720	0.280	0.770

结论：没有单一模型统治所有任务。字段准确率看起来高，但文档准确率显著下降，说明多字段任务中“每个字段都对”非常难。

Reproducibility Checklist

复现实验时，你需要固定这些东西。

数据与标注

每个样本包含：用户 prompt / 文档 \(x\)、JSON schema、ground-truth structured output。评估时把模型输出和 ground truth 做字段级比较；若任意字段错误，则文档级 label 为 incorrect。

作者特别检查了现有 benchmark 的错误：FIRE 中实体类别不一致，PII 数据中上下文编号被误标为信用卡或地址，法律/合同抽取数据中长 span 与表格格式带来混乱。复现时不能把原始 public datasets 直接当可靠答案。

Baseline

Token Probability。使用 generator 输出 token 的 average log probability 作为置信度；GPT-5 和 Gemini-3-Pro 因实验时不提供 logprobs 被省略。

Per-document LLM-as-a-Judge。GPT-4.1-mini 基于 Zheng et al. 风格 prompt，对整体答案给 1–10 rating。

Per-field Single Call LLM-as-a-Judge。一次结构化输出调用，同时为所有 top-level fields 返回 explanation + rating。

Per-field Multiple Calls LLM-as-a-Judge。每个字段单独调用一次 judge，只评价目标字段；更强但随字段数线性变贵。

指标

Field Accuracy。所有样本所有字段中，字段完全正确的比例。

Document Accuracy。所有字段均正确的样本比例。

AUROC。主指标，衡量 trust score 对 incorrect outputs / fields 的排序能力。分数越能把错误排到前面，AUROC 越高。

Precision @ Num-Errors。附录指标，令 \(K\) 等于真实错误数，看分数最低的 \(K\) 个里有多少真错。

Confidence Gap。附录指标，衡量正确与错误输出之间的平均分数间隔。

Prompt 模板核心

E.1 文档级 scoring

Think critically to provide a comprehensive veritable argument for why the proposed Answer might be incorrect.
Then consider the argument, consider the Answer again, and determine:
How certain are you that the proposed Answer is correct?
Provide a score between 0-100.

E.2 字段级 numeric scoring

For each top-level key:
- How certain are you that its value is entirely correct?
- Provide a score between 0-100.
- If unverifiable, score should never exceed 50.
Output JSON with explanation and score for each key.

E.4/E.5 间接字段级 scoring

Identify fields that are factually incorrect, incomplete, unverifiable, or misleading.
Return incorrect_fields plus an overall confidence/rating.
Map flagged fields to alpha=0.1 and unflagged fields to beta=0.9.

结果怎么读

不用死盯每根柱子。读图时抓住三个结论：CONSTRUCT 总体最高；字段级 multiple-call judge 虽然强但贵；token logprobs 不稳定且很多模型不给。

论文最想证明的是：如果你只能人工检查一小部分输出，CONSTRUCT 更可能把真正有错的文档/字段排到最前面。

Results

核心结果：CONSTRUCT 在文档级和字段级错误检测上都赢。

主文以 AUROC 展示结果。论文的定性结论非常强：在 5 个生成模型、4 个 benchmark 上，CONSTRUCT 的 per-document trust scores 在每个 benchmark 都取得最高 AUROC；per-field scoring 也稳定超过 single-call 和 multiple-call LLM-as-a-Judge，同时比 multiple-call 更省 token/compute。

文档级错误检测

论文 Figure 1: Per-document scoring AUROC — Figure 1（论文第 11 页）：不同 per-document scoring 技术检测 incorrect structured outputs 的 AUROC。图中每个子图对应一个 generator model。

字段级错误检测

论文 Figure 2: Per-field scoring AUROC — Figure 2（论文第 12 页）：不同 per-field scoring 技术检测错误字段的 AUROC。Multiple-call judge 比 single-call 强，但 CONSTRUCT 更强且更省。

结论 1：logprobs 不是答案

平均 token logprob 的表现跨模型波动大；某些新模型甚至不给 logprobs。对于企业 API 场景，依赖 logprobs 的 detector 可用性和可迁移性都很弱。

结论 2：单次 judge 会漏

文档级 judge 容易忽略字段错误；单次字段级 judge 又容易在大量字段之间分配注意力失败。论文把这归因于 transformer verifier 的 approximate information processing capacity。

结论 3：多样性胜过更重调用

CONSTRUCT 用 5 个不同 prompt 形成互补证据。它不是让模型“想更久”，而是让模型从不同任务表述和评分格式中暴露不同错误信号。

Appendix Figures

附录结果：换指标后，结论基本不变。

论文 Figure 3: Per-document Precision at Num-Errors — Figure 3（论文第 35 页）：per-document scoring 的 Precision @ Num-Errors。CONSTRUCT 平均能用更少人工检查发现更多错误文档。

论文 Figure 4: Per-field Precision at Num-Errors — Figure 4（论文第 36 页）：per-field scoring 的 Precision @ Num-Errors。字段级错误定位上 CONSTRUCT 仍保持领先。

论文 Figure 5: Per-document Confidence Gap — Figure 5（论文第 38 页）：per-document Confidence Gap。CONSTRUCT 通常给正确与错误输出更清晰的分数间隔。

论文 Figure 6: Per-field Confidence Gap — Figure 6（论文第 39 页）：per-field Confidence Gap。Multiple-call judge 有提升，但仍通常落后于 CONSTRUCT。

Reviewer Comments

我的评价：这是一篇工程直觉很强、理论包装克制，但证据还可以更硬的工作。

优点

真正切中企业痛点。论文没有纠缠“LLM 能否完美生成”，而是把问题改写成“如何把有限人审预算投到最危险样本”。这个 framing 非常务实。

方法简单但不浅。5 个 verifier prompt 的组合看似 prompt engineering，但它背后抓住了 structured output 的特殊性：文档级错误是字段级错误的 union，字段级验证又受 attention/capacity 分配影响。

benchmark 贡献有价值。作者指出现有 ground truth 很脏，这比又跑一个排行榜更重要。对于 extraction benchmark，标注噪声会直接扭曲 detector 评价。

不足

理论解释仍偏事后。“information-processing capacity”是合理叙事，但没有被直接测量。比如字段数、字段长度、相关证据跨度、schema 嵌套深度与错误检测性能的关系，论文可以做得更因果。

prompt 选择有经验主义色彩。消融说明每个模板有用，但缺少系统搜索空间定义。为什么正好 5 个？为什么这些 wording？为什么 \(\alpha=0.1,\beta=0.9\) 对所有任务固定？这些选择有效，但理论可解释性有限。

缺少校准讨论。论文强调 error detection 而非 calibration，这没问题；但企业上线时阈值很关键。AUROC 高不等于某个阈值下的风险可控，最好报告 calibration curves 或 selective risk coverage。

我会怎么改进

第一，增加 coverage-risk curves：当自动通过 90%、95%、99% 文档时，剩余错误率是多少。这个比 AUROC 更接近企业上线决策。

第二，做 field difficulty modeling：给字段引入类型、证据跨度、是否需要计算/推理、是否多实体歧义等特征，分析 CONSTRUCT 在哪些字段类别上最有效或最脆弱。

第三，把 prompt ensemble 变成可学习但轻量的 routing/aggregation layer：不同任务、字段数、schema 深度下，动态选择 verifier templates，而不是固定 5 调用。这样可以进一步降低实时成本。

第四，加入 adversarial / distribution shift 测试。企业文档最痛的不是平均样本，而是 OCR 噪声、格式崩坏、边界 case、schema 语义含混。CONSTRUCT 的定位天然适合做这些 stress tests。

One More Thing

这篇工作的隐含启发：LLM 产品需要“可审计的不确定性接口”。

对结构化输出而言，最有产品价值的不是一个漂亮的全局分数，而是把“哪里可能错、为什么错、要不要人看”变成下游系统可执行的信号。CONSTRUCT 的形式很像一个 review scheduler：它把 LLM 的自由文本能力重新约束成风险排序、字段定位和解释证据。这可能比单纯追求更强 generator 更接近企业 AI 的下一阶段。

一句话总结

CONSTRUCT 的贡献不是证明 LLM 会自知，而是证明 多个互补的、结构化的 LLM 自检信号 可以足够可靠地支撑 real-time human-in-the-loop。