加载失败
这是一个 Show HN 项目，作者提出了一个新的 benchmark，用来测试 LLM 在“确定性/结构化输出”场景下的表现，而不是传统的开放式问答。讨论围绕一篇配套博客和论文展开，核心指标不是模型能否生成看起来像 JSON 的内容，而是能否在满足 JSON schema 的同时把字段值填对。评论中提到的模型包括 Anthropic 的 Opus/Sonnet 系列、Google 的 Gemini 系列，以及智谱的 GLM 系列；争议点之一是作者挑选测试模型时是否过于偏向开发者常用、成本较低的模型。另一条主线是方法论：作者没有使用 structured decoding，而是统一采用 greedy decoding，以保证不同模型之间的可比性。
不少评论质疑榜单只挑了部分模型，尤其缺少 Anthropic 的 Opus 系列、Google 的 Gemini 3.1 Pro，以及智谱的 GLM 5，让“Top 5”看起来不够完整。作者回应说，这个 benchmark 主要面向开发者实际会接入的结构化输出模型，因此优先选了常见、成本偏低到中等、且推理能力不重的模型。作者还解释，基准是开源的，别人可以自己跑模型并提交 PR，leaderboard 也会动态更新。另有评论指出同一时期发布的 Sonnet 4.6 被测了，但 Opus 4.6/4.7 和部分新模型缺席，进一步放大了“选择性测试”的观感。
有评论怀疑这类测试是否还有增量价值，因为现在很多模型在这些任务上已经能拿到很高分。反方回应强调，真正的差异不在于能不能输出合法 JSON，而在于字段值是否真的正确。作者提到博客里的“JSON-pass vs Value-Accuracy gap”图表显示，模型通过 JSON schema 的比例很高，但值准确率会掉约 20%–30%。这意味着只看格式合规会高估模型在真实结构化任务中的可用性。
有人直接问，既然目标是结构化输出，为什么不使用 structured decoding 来约束生成。作者解释，他们在论文里的 ablation 已经比较过 structured decoding，结果显示对输出质量没有明显改善。为了让 benchmark 在不同模型间保持一致，同时兼容那些不支持该功能的模型，最终选择了统一的 greedy decoding。这个决定更多是为了可比性，而不是默认某种解码方式更优。
一部分评论认为，如果要“deterministic output”，那就不该用 LLM，因此这个 benchmark 的前提本身就值得怀疑。回应则指出，很多实际开发流程并不是让模型直接回答知识问题，而是让 LLM 把非结构化输入转换成结构化工件，这正是很多工作流需要的能力。评论还对比了 GPQA、MMLU 这类偏知识问答的传统 benchmark，认为它们并不能覆盖端到端结构化输出这个场景。作者还提到他们在做一种 LLM 与传统 CNN/DNN 的混合方案，目标是在自定义 schema 和高质量结构化结果之间取得平衡。
structured output: 指模型输出必须符合预设结构，例如固定字段的 JSON、表格或 schema。
JSON schema: 用于定义 JSON 数据结构、字段类型和约束的规范。
value accuracy: 字段值是否填对的准确率；不同于只检查格式是否合规。
structured decoding: 在解码阶段施加结构约束，尽量让模型只生成合法格式的输出。
greedy decoding: 一种每步选择当前概率最高 token 的解码方式，常用于追求稳定和可比性。