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
- Write down the input contract. Identify required fields, allowed values, types and relationships.
- Create deliberate failures before evaluating a model. A missing key and an incorrect value should exercise different checks.
- Keep the checks separate in the report. Explain what a pass establishes and what it leaves unresolved.
- 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.id、order.items[0].name 和 order.items[0].quantity 三条路径。
| 输出 | 可解析 | 官方路径分数 | 额外的精确值检查 |
|---|---|---|---|
| 正确 YAML | 是 | 1.0 | 通过 |
| 缺 quantity | 是 | 2/3 | 失败 |
| quantity 改成 200 | 是 | 1.0 | 失败 |
| 含尾随逗号的 JSON | 否 | 0 | 失败 |
值错误却取得完整路径分数,并不意味着“路径是否存在”这个指标有 bug;它说明我们需要按指标定义解释结果。最后一列是本例增加的业务检查,不是 StructEval 指标。精确相等也不适用于所有任务:如果允许多种正确表达,应先列出可接受的变化。
怎样用在自己的评测中
- 先写输入约定:必要字段、允许的值、类型以及字段之间的关系。
- 在跑模型之前构造故意失败的输出,确认缺字段和值错误能被不同检查捕获。
- 分项报告结果,说明每一项通过证明了什么、还没证明什么。
- 一起保存输入、输出、评测器版本和错误明细,不把解析成功当成整体可靠性。
视觉输出还需要检查呈现内容;交互页面还需要行为测试。这个小型文本练习不覆盖这两种能力。
下载并修改一个输出
打开 CPU mini-lab。包内包含输入、预期结果、依赖版本、未经修改的官方代码及哈希、许可证和本地运行输出,无需模型 API 或 GPU。公开 ZIP 已经通过未登录下载、解压和异目录运行检查,四个预期案例全部通过。
试着修改数量,再分别看路径与值检查的变化。这个练习用于理解指标边界,不是完整 benchmark 复现,也不是外部采用的证据。