回归报告里的“通过率 100%”可能来自严谨的测试也可能来自一行写死的返回值。如果测试没有固定数据、没有独立期望结果或者把模型自己生成的解释当作判分标准这个百分比就很难说明问题。10 月 20 日公布的 Agentic Analytics Benchmark 第二轮使用一组固定的合成分析问题并区分规划错误与执行错误。它提供的启发是评测条件需要显式化而不是把任何 SQL 成功执行都算作答对。本文只做一个很小的本地回归例子不复刻该基准也不借用它的成绩。先放进一个负对照下面有三条候选查询两条正确一条错误。第三条把退款订单也算进了已支付金额必须失败。如果一个评测器仍给出全通过就应先修评测器。import sqlite3 con sqlite3.connect(:memory:) con.execute(CREATE TABLE orders(region TEXT, amount INTEGER, state TEXT)) con.executemany(INSERT INTO orders VALUES(?,?,?), [ (east, 100, paid), (east, 50, refunded), (west, 80, paid)]) cases [ (east paid, SELECT SUM(amount) FROM orders WHERE regioneast AND statepaid, [(100,)]), (paid total, SELECT SUM(amount) FROM orders WHERE statepaid, [(180,)]), (negative control, SELECT SUM(amount) FROM orders, [(180,)])] results [] for name, sql, expected in cases: actual con.execute(sql).fetchall() results.append((name, actual expected, actual, expected)) assert [r[1] for r in results] [True, True, False] print(*results, sep\n) print(passed, sum(r[1] for r in results), total, len(results))输出是 2/3。这不是产品准确率只是三条手写查询在一份教学数据上的比对结果。负对照故意保留错误验证判分逻辑确实有能力拒绝它。比较规则不能等模型答完再选无序明细可以按约定排序后比有业务排名的结果必须保留顺序。金额可以用最小货币单位整数浮点指标则应提前规定容差。空值、重复行、列名和空结果也需要各自的规则不能把所有结果转成字符串后“看起来差不多”就放行。固定数据还不够。应记录数据库版本、时区、指标定义、允许的工具和预算。修改 Schema 剪枝策略时尽量在同一套题上成对比较并单列“没有执行”“执行报错”“执行成功但答案错”。这几类问题的修复方式不同。本例运行的是 Python 自带 SQLite没有运行模型、DuckDB 或 ClickHouse。三条 SQL 也不覆盖权限、超时、复杂 JOIN 和业务指标的全部变化。它的价值是把一个最基本的问题钉住错误出现时测试会不会明确地失败。延伸阅读Agentic Analytics Benchmark 第二轮Python sqlite3 文档DuckDB 2.0 迁移指南