数据核验

一种没人及时发现的失误 让 AI 总结一条 CI pipeline，你会得到一段很整齐的话：lint 阶段 42 秒、build 3.5 分钟、整条 pipeline 16.4 分钟、比上周快 18%。读起来像一份报告。两个小时后才有人发现 build 从来没有花过 3.5 分钟，而失败率是从另一周抄来的。 这段话看起来没有任何可疑之处。问题就在这里：编造的数字和真实的数字，排版上完全一样。 为什么模型会这样 AI 在写总结时并不是在查你导出档里的行，而是在生成「最像下一个词」的内容——而「像」不等于「有出处」。两种失误最常见： 编造：那里需要一个数字，于是就生成了一个。「失败率 2.4%」会出现，是因为 pipeline 总结里通常有失败率，而不是因为 2.4% 真的存在。 漂移：数字本身是真的，但在流转中变了样——被四舍五入两次、秒和分钟换算错、从相邻的行/周/项目里串了行。 这两种都能通过人工审阅，因为审阅看的是文字逻辑，不是算术。 五分钟核验流程 1. 留原始导出，不要只留摘要。 把 CSV、日志、SQL 查询结果交给 AI。如果来源本身就是摘要，就没有东西可以核对了。 2. 把每个数字都当成需要出处的断言。 一条实用规则：没有来源行号，就不进报告。 这跟新闻业要求引用出处是一个道理，只是用在算术上。 3. 先对单位，再对数值。 1500 ms、1.5 s、0.025 min 是同一个时长。AI 总结里大量「看起来错」的数字其实是单位或四舍五入造成的，而真正编造的数字就藏在这片噪声里。 4. 留出容差。 摘要里保留三位有效数字的数值不可能和原始的 4183000 完全相等。设一个小的相对容差（1% 是个合理默认值），超出容差的判定为「待核实」，而不是直接判错。 5. 把「待核实」和「错误」分开。 待核实代表你贴的来源里找不到它——它可能是对的，只是来自你还没提供的数据；但在找到那个来源之前，它不能进报告。 AI 数字核验器 把第 3～5 步自动化了：把 AI 回答和来源一起贴进去，它会抽出每个数字、归一化单位与倍数量词、逐一比对，并把找不到出处的标红，同时给出对应的来源行号作为证据。 标红之后做什么 按影响从大到小处理，并给每个数字归类： 现象 常见原因 处理方式 完全找不到，但量级合理 编造 删掉，或者要求给出出处 差几个百分点 四舍五入、口径不同、周期不同 确认统计周期再用 只在单位换算后才匹配 摘要产生的偏差 可以用，但要写清单位 匹配到相邻但不同的行 串行 改正，并复查相邻数字 这套方法的边界 比宣传更重要的是说清限制：核验工具确认的是可追溯性，不是真实性。 ...