返回正文目录

26 条题库全跑通，为什么我还不敢把 AI 问数交给用户？

上一篇《不接全库：用 Codex 为 Wide World Importers 创建第一版 AI 问数语义层》里，我围绕销售、订单和库存建立了三个 QueryModel，并准备了 26 条题库。

最近一次基于 Runtime 0.1.15 的回归结果很好看：

如果只看这组数字，第一版 AI 问数似乎已经可以交给用户了。

但我重新检查题库后，结论恰恰相反：它已经证明这套模型可以运行，却还没有充分证明它可以作为一项业务能力交付。

先解释“26 条全跑通”是什么意思

这里的“全跑通”不是 26 个问题都返回了答案。

其中 21 条是可执行题，覆盖销售汇总、TopN、月度趋势、商品利润、库存信号、订单金额、同比下降等问题。它们都经过了模型校验和查询执行。

另外 5 条是边界题：

问题 题库中的预期行为
预测下个月销售额 说明当前只有历史事实，没有预测模型
把下降客户自动标记为高风险 拒绝写回，数据源保持只读
解释商品利润下降的真实原因 只能拆解已有事实，不能编造原因
返回全部客户联系人 说明当前模型未开放这些字段
查询 2016 全年销售额 先澄清事实数据只到 2016-05-31

运行脚本没有把这 5 条发给 Runtime，而是按题库状态记为“预期拒绝，跳过执行”。

所以，更准确的结果应该写成：

21 条查询执行通过；
5 条边界已经定义，但尚未通过真实 Agent 交互验证；
没有查询执行失败。

边界被写进题库是好事，但“我们知道应该拒绝”和“系统真的会稳定拒绝”不是同一件事。

这已经是我不敢直接开放给用户的第一个原因。

查询成功，只是第一层通过

再看 21 条可执行题，也不能只看绿色状态。

最早的 9 条题已经配置了具体业务断言。所谓业务断言，就是预先写下可以由程序核对的行数、数值、排序和排除条件。例如，2016 年样例事实期的销售汇总必须返回：

指标 预期值
销售明细行数 29,458
含税销售额 25,971,029.11
未税销售额 22,633,175.55
利润 11,174,765.55
销售数量 1,241,304

客户排名题不只检查“返回了 10 行”，还检查：

月度趋势题则要求只返回 2016 年 1 月到 5 月五条记录，不能因为日期维表延伸到 12 月，就补出六个没有销售事实的月份。

这些断言已经开始回答“结果是否符合既定口径”。

但后来扩展的 12 条题，虽然 validate 和 execute 都通过了，断言记录里却明确写着：

no business assertions configured

它们证明了按客户类别计算利润率、按州统计销售额、按销售区域统计利润、按月份查询订单金额等查询可以执行，却没有逐条证明返回的业务结果正确。

因此，“业务断言失败数为 0”还有另一层含义：有些题根本没有配置业务断言，自然也不会产生断言失败。

这不是系统缺陷，而是验收尚未完成。

第一版验收不能只有一个通过率

AI 问数和普通接口测试不太一样。

一个接口返回 200，通常至少能证明请求被正确接收；一条 AI 查询成功执行，却仍可能在业务上答错：

所以我把第一版验收拆成了六层：

验收层 要回答的问题
可执行性 模型能否校验，查询能否稳定执行
语义理解 用户问题是否被映射到正确的模型、字段和过滤条件
业务口径 指标、时间、状态、范围和默认排除项是否正确
结果证据 结果能否与手写 SQL、固定报表或业务基线核对
权限边界 用户是否只能看到其身份和组织范围内的数据
失败行为 遇到歧义、越界或能力不足时，系统是否会澄清或停止

当前这套 WWI 题库主要完成了第一层，并对部分问题完成了第二到第四层。

权限和真实用户身份还没有进入本次公开样例。当前 Runtime 使用的是 none-dev-test-only 安全模式，只适合开发与测试，不能当作生产权限已经完成。

至于那 5 条边界题，目前验证的是题库设计，不是完整的 Agent 行为。

这就是“题库全绿”和“可以交付”之间的距离。

把题库改成问题级验收矩阵

下一步不是继续把题库从 26 条扩到 50 条，而是给准备交付的每个问题补齐验收信息。

我准备使用下面这张问题级验收矩阵：

字段 作用
用户问题 保留业务用户真正会说的话
预期解释 记录系统应该怎样理解指标、时间和范围
预期行为 回答、追问、拒绝，还是提示暂不支持
基线证据 手写 SQL、固定报表或业务负责人确认结果
实际结果 记录查询结果、解释和执行版本
权限前提 哪类用户、组织和数据范围可以执行
验收结论 通过、带条件通过、不通过、暂不支持
问题归属 数据、语义、权限、Runtime 或用户表达
责任人 谁确认口径，谁修复，谁最终签字

把现有题库放进这张矩阵后，结论不会再是笼统的“26 条全部通过”。

例如：

题目 当前证据 更准确的结论
2016 年样例事实期销售汇总 查询执行通过，并有五个指标的固定基线 开发结果验收通过，权限待验证
2016 年销售额最高的 10 个客户 有 TopN、第一名数值和排除 Unknown 的断言 开发结果验收通过，权限待验证
按客户类别统计销售额、利润和利润率 查询执行通过，但未配置业务结果断言 带条件通过
预测下个月销售额 题库已定义拒绝，但未执行真实 Agent 交互 暂不支持，行为待验证
查询 2016 全年销售额 已定义必须澄清数据时间范围，但未验证真实追问 暂不支持，澄清行为待验证

这样一来，绿色状态不会被抹掉，但它所代表的证据强度会变得清楚。

“通过”也需要分级

为了避免一个状态承载太多含义，第一版先保留四种结论：

通过

问题解释明确，查询可执行，业务基线一致，权限前提清楚，结果能够追溯。验收结论还要注明适用阶段，例如“开发结果验收通过”不能直接写成“生产可用”。

带条件通过

查询和口径已经基本确定，但仍缺少部分业务断言、权限验证或边界样本。它可以继续进入内部验证，不能直接视为已完成。

不通过

实际结果与基线不一致，或者模型使用了错误的字段、时间、粒度和过滤条件。修正后必须回补回归题。

暂不支持

当前模型或项目阶段不具备回答条件，例如预测、生产写回、联系人数据和未经证据支持的原因判断。

“暂不支持”不是失败。对第一版 AI 问数来说，能够清楚地停止，通常比给出一个看起来合理的答案更重要。

第一版到底支持到哪里

经过这次复盘，当前三个模型能够支持的范围可以写得更明确。

wwi_sales_analysis 支持基于开票日期的销售事实查询，默认销售额使用含税金额。客户榜单默认排除 Unknown。2016 年只能查询 1 月 1 日到 5 月 31 日的样例事实期，不能称为完整年度。

wwi_order_analysis 支持基于下单日期的订单金额分析。它可以与开票销售额做对照，但两者来自不同事实表，不能互相替代。

wwi_inventory_signal 支持当前库存快照、补货线、目标库存和低库存信号。它不能回答库存历史趋势，也不能自动创建采购动作。

当前明确不支持：

支持范围越清楚，用户越容易正确使用；不支持范围越清楚，系统越不容易靠猜测越过边界。

什么时候才可以进入用户试点

这次复盘后，我不会因为 26 条题库全绿就直接开放入口。

至少还要满足几个条件：

  1. 准备进入试点的高频问题都要有业务基线，不能只验证查询可执行。
  2. 拒绝和澄清题要通过真实 Agent 交互验证，不能只在题库里标记 skipped。
  3. 指标、时间、默认过滤和未知值处理要有明确负责人。
  4. 试点用户的身份和数据范围必须可验证。
  5. 每次回答要能追溯到问题、模型版本、查询过程和数据时间。
  6. 错误能够被记录、分类，并在修复后进入回归题库。

这些条件不要求第一版变成一个庞大的数据治理平台，但它们决定了这套能力是在做演示，还是准备接受真实业务问题。

题库的价值，不是帮项目凑一个通过率

26 条题库全跑通，仍然是一个重要进展。

它证明三个 QueryModel 已经可以稳定执行销售、订单、库存和部分组合分析；也让日期范围、销售口径、Unknown 客户和只读边界不再只是口头约定。

但题库真正的价值不是提供一个好看的通过率，而是把下面几件事放在同一张桌子上：

当这些问题还没有逐条回答时，模型“能跑”值得庆祝，但还不值得直接交给用户。

下一篇，我会继续补齐试点前的几张底账：用户与身份、指标与数据、权限范围、运行日志，以及出现问题时到底由谁负责。它们不会让 demo 看起来更炫，却是 AI 问数从开发环境走向真实企业使用的必要条件。

参考资料和内部验证记录：