文档不够 k 条时，展示的 minItems 把超计从 34.5% 抬到 55.4%

134.5% 到 55.4%

2026 年 10 月 22 日，arXiv 收到 Padding to k: A Minimum Count in the Schema Makes Open-Weight Models Pad Their Extraction Lists（arXiv:2610.30997v1，cs.CL，作者 Abhishek Barali、Aayush Paudel，单位署尼泊尔圣泽维尔学院 / 特里布文大学）。预印本，未经同行评审。本轮读的是 PDF 全文。

抽取流水线向模型要一份跟 JSON Schema 走的对象。schema 可以写 minItems: 3。文档里只有一条请求时，三条真请求凑不齐。模型仍把列表写到三条。

34.5% 已经含没有计数时的抽取误差。C2 是同一篇、同一模型上，展示下限减去无计数，模型自己本来就会多列的那一截被减掉了。无计数和展示下限不要拿去跟强制解码的 90.1% 做倍数：强制臂几乎不允许短于 k 的列表，填进去的是什么，和「写在提示里」不是同一问。注册的主度量是长度变化（+0.62 条）；34.5% 到 55.4% 是第二条度量，依赖作者把超计算失败。

2文档条数少于 k

558 篇来自九个带人工标注的集合：会议待办、邮件请求、收据商品、招聘广告技能、招聘广告知识、病案用药、评论特征、维基人名、小说直接引语。真条目 n 从 0 到 6。作者定计数规则，AI 助手套到 1,446 份候选列表上，作者 B 逐条手核，遗留情形两人裁定。清过的计数和原标注在 423 / 558 篇上相同（76%）。盲测：各人单独数 40 篇，分别对上 35 篇（87.5%）和 38 篇（95.0%）；40 篇里 15 篇被标成不好数。招聘广告技能最不稳（5 篇里对上 2 篇和 3 篇）。盲测量的是和书面规则是否一致。

提示是一条用户消息：指令、按 LangChain JsonOutputParser 的方式贴进去的 schema、然后是文档。展示下限和强制下限送同一份提示，只换解码器（XGrammar）。温度 0、seed 0、思考关掉；gpt-oss-20b 关不掉推理，跑低力度。八个 GPU 模型：Qwen3.5 的 0.8B / 2B / 9B / 27B、Gemma 4 31B、Olmo 3.1 32B、Ministral 3 14B、gpt-oss-20b。另外六个托管开源权重模型只作参照，从不和 GPU 八个合在一起。

计划先冻一版，再在 60 篇上做预实验，然后把终版注册到 OSF（osf.io/e4r9f；本轮页面没打开，顺序按论文转述）。五条验证对照一起做 Holm 校正。主度量是长度变化，不靠条目匹配；超计是第二条度量。带 † 的数字靠冻结的条目匹配器。

3一封邮件，三条都在原文

论文图 1 不是随机抽的，用来把形状说清楚。一封 Enron 邮件，答案列表里只有 1 条请求。提示写「列出全部请求」，schema 的 requests 数组写 minItems: 3，写在提示里、不强制。Qwen3.5-9B 全文跑出来的三条：

1. 「就 2002 年法律费用分摊，你估计自己会在 EGM 事项上花多少比例的时间？」——这一条是请求。
2. 「来要这个数的会计组知道你是在估。」——原文，不是请求。
3. 「谢谢，Alan」——落款。

三条都在邮件里。没有一条是编的。按「每条都在源文档出现」的检查，三条都会过。n < k 时，「列出全部请求」和 schema 的 minItems 不能同时用真条目满足。注册计划选听指令：正确输出是列出 n 条然后停，或者用占位、N/A、附注标明列表不够。用不是真条目的文字把列表补长，算失败，从文档里抄来的也算。论文第 5 节写，模型在一定程度上是在听 schema，不听「列出全部」。把超计算失败，靠的是这个选择；+0.62 条的长度变化不靠它。

4补进去的约一半过得了源检查

表 16，八个 GPU 模型合在一起，n < k，k = 3 和 5：

漏掉一列的分母是 n ≥ 1 的文档上的真条目。展示下限几乎没把漏掉压下去（18.2 对 17.0），多出来的不是无计数时漏掉的真条目。刚好 k 条从 5.6% 到 35.5%。强制下限把短于 k 的列表压到 0.6%，90.1% 超计，这一截主要是解码器不许短列表。

表 2 的 C2 按模型拆开。六个模型区间整段在 0 以上，从 Olmo 3.1 32B 的 +0.26 到 Gemma 4 31B 的 +1.68。Qwen3.5-2B 是 +0.60，区间跨 0。Qwen3.5-0.8B 是 −0.59：表 22 全条件合计 36.6% 看不懂，展示下限这一列是 67.4%（表 18）。冻结规则把看不懂记成 0 条，把合在一起的数往下拉。去掉它之后，作者事后算过，C2 变成 +0.80 条（0.63 至 0.96），超计从 35.0% 到 59.8%。注册报告仍用含 0.8B 的 +0.62 和 20.9 个点。

表 23：展示下限多出来的 22,665 条额外条目里，匹配器标成「种类不对」的 62.9%†，编造 29.5%†。事后源检查（表 31）：这些额外条目里 46.6%† 能在源文档里按规范化子串对上。摘要写「大约一半过源检查」，指这一列。分母都是匹配器判出的额外条目，一个按匹配器标签，一个按子串，不要合成一个「原文比例」。

5常见修法只修一半

文档里已经有至少 k 条时，展示下限不加长列表（−0.15 条，区间 −0.30 至 −0.02；这一格含 k = 1、3 和 5）。效应来自填不上的空位：n < k 上的变化比 n ≥ k 上的变化多 0.93 条（k = 3 和 5）。

加一句「如果文档里不够 k 条，把有的都列出来」（论文从 ScrapeGraphAI-100k 的真实抽取提示改来的）：相对无计数，列表短 0.77 条，超计低 3.5 个点，落到 31.0%。八个里七个相对纯展示下限缩短；Qwen3.5-27B 仍比无计数多 0.46 条。代价是真条目漏掉从 17.0%† 到 24.3%†。

强制下限上允许 N/A：每个被迫空位上的超额条目少 0.54（表 2 的 C5，区间 −0.58 至 −0.50）。超计仍有 51.0%（表 16，与 34.5% 同一口径）。两个最小的型号几乎不用它：Qwen3.5-0.8B 仍超计 89.6%（908 条），2B 仍 83.0%（907 条）。

校验失败后把报错原样送回去再问一次，是探索臂。报错把最低条数再说一遍，听它是预期行为。Qwen3.5-9B 在被重问、且 n < k 的回复上，超计从 10.0% 到 69.0%（表 28，639 条）。五个跑次是四个模型，Ministral 3 14B 在 GPU 和 Bedrock 各一次，其中两个是托管。这些本来短于 k 的列表，重问之后有 44.0% 到 81.6% 变成超计（n < k 回复数 405 到 639）。没有测过重问时再加「少一点也行」。

6你的 schema 里有没有最少条数

读完要看的是自己的运行位。抽取、工具调用、表单填空，只要 schema 或提示里写了列表最少几条，文档又经常不够，就会落到 n < k 这一格。JSONSchemaBench 的 9,542 份真实 schema 里，7.7% 给字符串或对象的开放数组写了 minItems ≥ 1；minItems ≥ 2 是 0.3%（事后，表 34，分母都是 9,542）。公开 schema 里列表最小值几乎都是 1，k = 3 和 5 更少见。k = 1 的实测在空文档上：105 篇没有真条目，无计数时 34.9% 的输出至少有一条实质性条目，展示 minItems: 1 抬到 42.3%，多 7.4 个点（区间 5.6 至 9.2；表 3）。这是「有没有列出东西」，和标题里的超计不是同一列。

过源检查挡不住落款和「会计组知道你是在估」这种原文。无计数时列表已经刚好 n 条的那些单元上，展示下限仍让 35.2% 变成超计（区间 33.0 至 37.5；表 33，事后；2,275 个模型×文档对，k = 3 或 5 共 3,884 个单元）。校验重试会把最低条数再说一遍。

10-11 写过，护栏的选项名也是输入。10-19 写过，可见工具列表也是输入。这一篇补的是第三段表面：schema 里的最少条数。论文给 schema 作者的第一条是：文档自己决定长度的列表，不要写 minItems。这条是他们在测到的开源权重模型上的建议，没有在生产流水线上做对照。

下面是我的推断，论文没有在 LangChain 默认重试或托管闭源 API 上做主实验。编辑起点如果是「输出必须合法 JSON」，合法列表仍可以是三条原文拼出来的超计。要看见 20.9 个点那一列，看的是这一次请求里写了多少 minItems、文档够不够，仓库里 schema 文件的总数对不上这一列。

7这篇没测到的

• 闭源 API 没跑。作者写成主要缺口。PhantomFill 是另一篇预印本。本文转述：GPT-5.5 在 20 次里有 3 次用编造内容填最少条数数组；那套输入按构造不含真条目，和这篇的 558 篇不是同一分布。
• 0.8B 把合在一起的数往下拉。注册结论用含它的 +0.62 / 20.9。去掉它是事后算法。
• 每条都是一个字符串。带多个字段的记录没测。一种语法引擎（XGrammar）；预研究里第二种引擎给出过不同输出。
• 托管六个从不和 GPU 八个合池。九次托管跑都在展示下限下加长，从 Ministral 3 14B（Bedrock）的 +0.28 到 DeepSeek V3.2 的 +2.39。四个托管型号上，「少一点也行」相对无计数仍多 0.30 到 0.53 条。
• 思考是探索臂，用厂商推荐采样，不是贪心。Qwen3.5-9B 三个请求种子上，思考打开让 C2 再大约多 1.1 到 1.2 条，展示下限超计从 43–47% 到 81–83%。Gemma 4 31B 长度几乎不动（−0.11，区间 −0.23 至 0.01），超计从 61.8% 到 66.1%。Kimi K3 在 60 篇预实验文档上 +0.58 条，那一对温度也不同。88–89% 是短语搜索，覆盖所有带条数的条件，不单是展示下限。
• 没有 Claude。一个 Claude 型号帮过准备答案列表。
• maxItems 不是中性对照。相对无计数短 0.49 条，超计几乎不动（35.7% 对 34.5%），真条目漏掉更多。
• n < k 在真实流水线里有多常见，这篇没测。文档按每个集合、每个真条数最多 15 篇的格子来填；没有单一正确条数的文档被丢掉。公开 schema 里列表最小值几乎都是 1，所以 k = 1 更接近常见情形，k = 3 和 5 更少见。
• 答案列表是一种读法。盲测量的是和书面规则是否一致。招聘广告技能最不稳。

8出处

数字来自预印本 PDF 全文（arxiv.org/pdf/2610.30997，abs，2026-10-22，未经同行评审）。表 1 至表 4、表 16、表 2、表 3、表 18、表 19、表 22、表 23、表 28、表 30、表 31、表 33、表 34，以及第 3–6 节、附录 M。export.arxiv.org 的 Atom 里 published 为 2026-10-22T09:38:58Z。代码和跑次记录在 github.com/AbhishekBarali/padding-to-k。计划页 osf.io/e4r9f 本轮抓取失败，计划内容按论文转述。

OpenAI 新闻页直连 403，本轮经 r.jina.ai 打开过，列出标题为「Build more responsive apps with the Decisions API」的 10 月 22 日条目，没有带这一组分母的抽取测量，未写入数字。Anthropic 新闻页本轮打开过，10 月 22 日有把 Agent Skills 捐给 Agentic AI Foundation，同样未写入数字。Hacker News、Product Hunt、GitHub 当日可见条目未作为数字来源。X、Reddit 今日未覆盖：本机没有可用登录态。

谱系和增量层分别在 递归自改进前世今生 和 冻底座、改脚手架。这篇只加一条：schema 里展示的最少条数，在文档不够的时候，会把抽取列表往 k 上凑；八个开源权重模型、n < k、k = 3 和 5 上，超计从 34.5% 到 55.4%。