LLM能当数据侦探吗？诚实比贵更重要的基准测试

一个让所有数据工程师头疼的工单

每个数据工程师都收到过这样的工单：销售说某家公司明明在 CRM 里，却从仪表盘上消失了，麻烦今天之内查清楚它去哪儿了。问题恰恰在于——没人知道原因。

CRM 和仪表盘之间横亘着一条数据管道：它负责摄取记录、抽取公司名、合并重复项、过滤掉一部分数据。记录可能在任何一个环节丢失。于是你翻遍日志，发现一半已经在上周二被轮转清空了，最后在终表里看到一个「Umbrella Corporation Inc」。这是我们要找的 Umbrella 吗？也许吧，大概？名字一样，就多了个 Inc。

好的侦探会说「它被过滤掉了，这是日志行」，或者在线索断掉时诚实地说「我判断不了」。糟糕的侦探会说「大概就是它吧」，挑个长得像的记录结案走人——两周后别人才发现仪表盘上一直显示的是另一家完全不同公司的数据。

现在大家都想把这类工单丢给 LLM 处理。任何一个 LLM 都能在终表里认出那个长得像的记录，但问题是：当日志根本不足以判断记录去向时，模型会不会老实承认？开发者 olgazju 为此构建了一个名为「Where Did My Data Go?」的 Kaggle 基准测试，专门拷问这个问题。

基准测试是如何设计的

这个测试的巧妙之处在于，它考验的不是模型猜得准不准，而是模型知不知道自己什么时候「不该猜」。整个流程分四步：

1. 模拟 15 个小型管道场景，每个场景中作者预先决定某条公司记录真实发生了什么：从未被加载、名字无法读取、被规则过滤、被错误合并进其他公司，或是换了个 id 存活下来。
2. 管道像真实系统那样写日志，然后作者故意删掉一部分——有时一条不删，有时删几条，有时几乎全删。
3. 模型只拿到剩下的日志，必须判断记录发生了什么，或者在剩余日志无法证明任何单一答案时回答「can't tell」。
4. 用纯代码核对答案，没有 LLM 裁判。关键在于：它核对的是剩余日志实际能证明什么，而不是隐藏的真相。所以如果证据被删了，哪怕蒙对了，「can't tell」才是唯一正确答案。

每个答案落入六种裁决之一：从未加载、名字无法读取、被过滤、错误合并、以别名存活，以及「冷案」——日志说不清。测试还特意设计了一对「双胞胎案例」：两个场景日志完全相同，但一个的相似记录确实是目标公司，另一个却是碰巧撞名的别家公司。对两者唯一诚实的答案都是「can't tell」。

每个调查都用两种模式提问：一种是纯粹的问题，另一种附带一份简短「规则手册」，要求不许猜、必须指出证明答案的确切日志行。借此观察几行指令能带来多大改变。

这种设计思路在评估体系中被称为「认知谦逊测试」（epistemic calibration）——不仅考察模型是否给出正确答案，更考察模型是否能准确感知自身知识边界。传统的 LLM 基准（如 MMLU、HumanEval）通常以准确率为唯一指标，但在真实工程场景中，一个「以高置信度给出错误答案」的模型往往比一个诚实说「我不确定」的模型危害更大。用纯代码而非 LLM 裁判来核对答案，也是刻意规避了「LLM 评 LLM」时常见的偏袒同类或风格偏好问题，使评分结果可复现、可审计。

八个模型，诚实度大相径庭

作者按真实生产环境的逻辑挑选模型。这种检查会在每张工单、每个夜晚运行，没人会把最贵的模型放进这个循环。因此入选的是各家厂商的廉价档、两个可自托管的开源权重模型，以及作者构建基准所用的 Claude Sonnet 5 作为高价参照。

参测模型包括 GPT-6 Luna（最新一代 GPT 的小模型）、Claude Haiku 5.5（最便宜的 Claude）、Gemini 3.5 Flash-Lite、Qwen 3 Next 80B（开源权重）、Gemma 4 31B（谷歌开源）、GPT-6 Sol、Claude Sonnet 5，以及 Kaggle 默认模型 Gemini 3.7 Flash。每个模型在每条赛道跑 107 次调查，无一次调用失败。

衡量的三个指标

作者关注三件事：在冷案例上模型多频繁地瞎猜；完整答案（裁决和 id）的正确率；以及「正确且被证明」——即模型每次下结论时，它引用的日志行确实存在并能证明该结论。这是三个不同的东西：一个对所有问题都回答「can't tell」的模型永远不会猜错，却也只能拿到 44% 的分数。

价格买不来谨慎

结果最反直觉的一点是：价格与谨慎度毫无关联，两个方向都是如此。

最便宜的 GPT-6 Luna，每千次调查仅 0.18 美元，在无规则手册的情况下一次都没猜，凭直觉全部答对。而 Sonnet 在将近三分之一的冷案例上瞎猜，Kaggle 默认的 Gemini 3.7 Flash 价格几乎是 Luna 的 40 倍，照样会猜。两个最爱瞎猜的模型 Qwen（59%）和 Flash-Lite（45%）恰恰也很便宜。价格标签什么都说明不了，你必须亲自测量。

速度同样不跟随质量：Flash-Lite 不到一秒就能作答，却在近一半的冷案例上瞎猜；Luna 和 Sol 约两秒且几乎总是正确；Gemma 在 Kaggle 托管上每次调查需要约 40 秒。

规则手册的威力

提示词里加几段规则，让八个模型中的七个瞎猜率归零，并把 Qwen 从 59% 压到 7%。有了规则，Haiku 和 Sonnet 最终得分完全相同——但 Haiku 便宜 14 倍。

要求指出确切日志行同样重要：开发阶段作者只加规则而不要求引用日志行时，Sonnet 仍有 4.5% 的概率瞎猜。作者的结论很直接：如果明天必须把一个模型放上工单队列，他会选一个带规则的廉价模型，而不是一个不带规则的昂贵模型。

这一现象在提示词工程领域有专门的术语：「约束提示」（constrained prompting）或「行为锚定」（behavioral anchoring）。通过在系统提示或用户提示中明确列出禁止行为（如「禁止推测」）和操作规范（如「必须引用原文日志行」），可以显著收窄模型的输出分布，抑制其在训练阶段形成的「倾向于给出有用答案」的惯性。这种惯性在客服、问答等场景是优点，在需要严格溯源的诊断场景却会变成缺陷。值得注意的是，规则手册并未让模型「变聪明」，而是让它在知识边界处「踩刹车」——这解释了为什么 Haiku 加上规则手册后得分追平了 Sonnet：两者的智识能力在该任务上并无本质差距，差距主要来自默认行为的激进程度不同。

那些和人类如出一辙的失败

最耐人寻味的是模型犯的错和人类高度相似。

有个案例：两家注册号不同的公司被错误合并，随后一条审查规则把合并后的实体整个丢弃。Gemini 3.7 Flash 和 Flash-Lite 每一次都把锅甩给过滤规则，而非真正的错误合并，不管有没有规则手册。Gemma 在拿到规则手册后也犯了同样的错——这正是「从日志底部往上读、看到第一个错误就停下」的典型后果。

Qwen 则秉持「日志里没有就等于没发生过」的逻辑。某条记录没出现在一份明确标注为「部分日志」的摄取日志里，它就断定记录从未被加载——哪怕提示词里白纸黑字写着「在部分日志中，缺失的行什么都证明不了」。

而「不瞎猜」也不等于「有用」。Sol 从不瞎猜，但凭直觉时它有时连一个干净的注册号匹配都说「我判断不了」，每一个在简单工单上的「判断不了」最终又会落回你的办公桌。

作者坦言，他用 Sonnet 搭建整个基准，原以为它会是最谨慎的那个，结果 Sonnet 在开发阶段对 25% 的冷案例瞎猜，在 Kaggle 上更是 30%，而最便宜的模型滴水不漏。Gemma 不带规则手册反而比带的时候表现更好。下一步作者想让模型主动申请它需要的日志，而不是一次性全给——看它会不会在甩锅给过滤规则之前，先去找那条合并日志。

Qwen 表现出的「闭合世界假设」（Closed World Assumption，CWA）是数据库与知识表示领域的经典概念：若某条信息未出现在已知数据集中，则默认其为假或不存在。这与「开放世界假设」（Open World Assumption，OWA）相对——后者认为信息缺失只是「未知」而非「不存在」。大多数关系型数据库（如 SQL）默认采用 CWA，而知识图谱（如 RDF/OWL）则倾向 OWA。LLM 在处理部分日志时犯下的这个错误，本质上是把「日志中未记录」等同于「现实中未发生」，是 CWA 在自然语言推理中的一种有害延伸。提示词中明确写明「部分日志中缺失不等于未发生」，正是试图将模型从 CWA 切换到 OWA 模式。

对 AI 落地的启示

这个小而精的基准测试给出了一个清醒的结论：在数据管道排查这类对「诚实」要求极高的任务上，模型价格、速度都不是可靠信号，必须针对具体任务实测。

更实用的收获是，一份简短的规则手册——明确要求「不许猜、指出证据行」——其价值可能远超换一个贵十几倍的模型。作者的最终策略很务实：无论用哪个模型，规则手册都要写进提示词，模型不必昂贵，也能老实说出「我判断不了」，而不是用错的 Umbrella 草草结案。

基准和代码均已开源，感兴趣的工程师可以在 Kaggle 和 GitHub 上复现。