发布于 更新于 Published Updated

All the fields are there. The value is still wrong.

An order asks for two notebooks. A YAML response includes the order ID, item name and quantity, but changes the quantity to 200. It parses, and every required field exists. Which check should fail?

I coauthored StructEval. This note was prepared with AI assistance and describes four handwritten teaching outputs, not model predictions. The results below come from a small, locally executed exercise using pinned official evaluator code. They are not the paper’s benchmark results.

Name the property before interpreting the score

A parser checks whether the output is acceptable to that parser. A path check asks whether required locations exist. Neither alone establishes that values match the input. In this exercise the required paths are order.id, order.items[0].name and order.items[0].quantity.

Output Parses Official key-path score Separate exact-value check
Correct YAML Yes 1.0 Pass
Quantity omitted Yes 2/3 Fail
Quantity changed to 200 Yes 1.0 Fail
JSON with a trailing comma No 0 Fail

The wrong-value case is not a bug in a metric defined to check path existence. It shows why the metric’s scope matters. The exact-value column is an additional application check written for this order, not a StructEval metric. Exact agreement can itself be too strict when multiple outputs are valid, so define the accepted alternatives for your application.

Make this useful in an evaluation

  1. Write down the input contract. Identify required fields, allowed values, types and relationships.
  2. Create deliberate failures before evaluating a model. A missing key and an incorrect value should exercise different checks.
  3. Keep the checks separate in the report. Explain what a pass establishes and what it leaves unresolved.
  4. Save the input, output, evaluator version and failure details together. Avoid turning a successful parse into an overall reliability claim.

For visual output, a screenshot introduces different questions; for an interactive page, behavior requires further tests. This small text exercise does not cover either mode.

Run it and replace an output

Download the CPU mini-lab. It includes inputs, expected results, dependency versions, unmodified official files and their SHA-256 hashes, licenses, and the retained local output. No model API or GPU is needed. The published ZIP was downloaded without authentication, extracted, and checked from a different directory; all four expected cases passed.

Try changing the quantity in a supplied file, then inspect the two columns independently. This is a learning exercise, not an independent reproduction of the full benchmark or evidence of external adoption.

StructEval paper · Published version · Pinned evaluator · Research guide and citation files

字段齐全,数值却错了

订单要求购买 2 本笔记本。YAML 输出保留了订单号、商品名和数量字段,却把数量写成 200。解析成功,字段也齐全:究竟应该由哪项检查发现问题?

我是 StructEval 的合著者。本文使用 AI 辅助撰写,介绍四个手写教学输出,不是模型预测。下表来自固定版本官方评测代码的小规模实际运行,不是论文的完整评测结果。

先说明指标检查什么

解析器检查格式能否被读取;路径检查判断指定位置是否存在。它们本身不能证明数值与输入一致。本例要求 order.idorder.items[0].nameorder.items[0].quantity 三条路径。

输出 可解析 官方路径分数 额外的精确值检查
正确 YAML 1.0 通过
缺 quantity 2/3 失败
quantity 改成 200 1.0 失败
含尾随逗号的 JSON 0 失败

值错误却取得完整路径分数,并不意味着“路径是否存在”这个指标有 bug;它说明我们需要按指标定义解释结果。最后一列是本例增加的业务检查,不是 StructEval 指标。精确相等也不适用于所有任务:如果允许多种正确表达,应先列出可接受的变化。

怎样用在自己的评测中

  1. 先写输入约定:必要字段、允许的值、类型以及字段之间的关系。
  2. 在跑模型之前构造故意失败的输出,确认缺字段和值错误能被不同检查捕获。
  3. 分项报告结果,说明每一项通过证明了什么、还没证明什么。
  4. 一起保存输入、输出、评测器版本和错误明细,不把解析成功当成整体可靠性。

视觉输出还需要检查呈现内容;交互页面还需要行为测试。这个小型文本练习不覆盖这两种能力。

下载并修改一个输出

打开 CPU mini-lab。包内包含输入、预期结果、依赖版本、未经修改的官方代码及哈希、许可证和本地运行输出,无需模型 API 或 GPU。公开 ZIP 已经通过未登录下载、解压和异目录运行检查,四个预期案例全部通过。

试着修改数量,再分别看路径与值检查的变化。这个练习用于理解指标边界,不是完整 benchmark 复现,也不是外部采用的证据。

原论文 · 正式出版版本 · 固定版本评测代码 · 研究说明与引用文件