8个LLM，480个问题，1个Kaggle基准：谁能解释流量下降？

这是对 Kaggle 基准测试挑战赛 的投稿。

我基准测试的内容

简短版本

我构建了 InsightTrack，一个开源的网络分析
平台。它具有一个名为 Pulse 的 AI 分析师。您会问 "为什么上周 /pricing 页面的流量下降？"，然后 Pulse 会选择合适的工具，读取数据，并用通俗易懂的英语作答。

Pulse 需要一个语言模型作为后盾。我想用证据而不是直觉来选择该模型，所以我
把 Pulse 的实际工作变成了一个基准测试：480 个问题，自动评分，答案来自 InsightTrack 自身的代码。

问题：AI 分析师可能会自信地犯错

分析助手不仅仅是用来提供趣味事实的聊天机器人。人们会根据它的说法行动：他们可能会修改页面、暂停广告活动，或停止担心。当它出错时，错误通常表现为以下两种代价高昂的情况之一：

1. 它会编造原因。 流量变化可能源于枯燥的原因（比如假期、新闻通邮或纯粹的噪声），而助手会自信地将其归咎于谷歌排名。您可能会花一天时间去修复其实并未出问题的 SEO。
2. 它会忽略真实问题。 流量可能减半，而助手却说“没有显著变化”。您可能要等一个月后才发现。

这两种情况都比说“我不知道”更糟。一个有用的分析师需要具备三种习惯，而这些习惯在通用 AI
排行榜上看不到。

• 克制： 在事实确实如此时，会说“这只是噪声”或“数据未显示这一点”。
• 对数字的规则遵循： 精确应用阈值。对只有 6 位访客的 15% 变化不算趋势。
• 读取真实工具输出： 实际返回的精确字段、四舍五入方式和格式，而非教科书中的示例。

为什么通用基准无法回答这个问题

公共基准在告诉您哪个模型在数学方面更强、编码更好或
函数调用更正确方面表现出色。但为产品选择模型是一个 产品决策，它有
三个它们无法为您回答的问题：

• Accuracy on my job: 我的工具、我的数据格式、我的数据库方言（DuckDB，而非 PostgreSQL）。

回答这些问题的唯一方法是在实际工作中测试模型。这就是这个基准所做的。

它包含什么

InsightTrack 分析师基准 包含四个任务的 480 个自动评分用例。前三个是 Pulse 今天的工作；第四个是 SQL，这是 Pulse 尚未采取的一步：在没有内置工具适用时编写查询。

每个任务有 80 标准 + 40 困难 个用例。困难用例体现在粗心的推理中：

• 恰好落在阈值上的变化（例如 15.0% 的下降）
• 若干关键词指向不同方向
• 完全停止排名的页面
• 类似的域名：getsite.com 是另一个站点，但 www.site.com 是您的站点

一个案例，逐步分解

以下是一个简化后的诊断问题示例：

• 每周页面浏览量： … 495, 517, 347。上周下降了 170 次浏览，即 33%。
• Google，之前： 该页面在其关键词上的排名为 #3。
• Google，现在： 其排名为 #5。其他未变。
• 规则全部在提示中。只有当变化至少为 15% 且 至少有 20 次浏览时才算数。排名变动 1–2 位属于正常抖动，绝不是原因。

正确答案：下降是真实的，但搜索并未导致它。 在 InsightTrack 的术语中，
{"significant": true, "direction": "drop", "causes": ["unexplained_by_serp"]}。诱人的错误
答案是 "你的排名下降"。说出这种答案的模型会让用户去修复其实并未损坏的 SEO。

这就是基准的核心：模型能否区分真实原因和巧合？

为什么这些答案可以被信任

没有 LLM 会给另一个 LLM 打分：

• 诊断： 答案密钥是 InsightTrack 自身的相关引擎，已移植到 Python。测试会在每个案例以及另外 1,500 个随机案例上运行 original JavaScript，任何不一致都会导致失败。
• SQL： 答案通过 执行 模型的查询来评分，因此两个不同但正确的查询都会通过。
• 其他一切： 其他所有答案均基于模型所看到的相同数据计算得出。
• 数据： 全部为合成数据（5,940 事件，2,494 次会话），不含任何真实个人数据，且整个数据集可以逐字节重建。

每个评分者还会标注 how 模型出错：虚构原因，将真实变化称为噪声，
编造数字，拒绝回答可回答的问题，使用不存在的工具。这将把得分转化为你可以采取行动的东西。

谁会受益

• 在分析或 BI 数据上构建 AI 功能的开发者。 你面临着我曾经面临的同样的选择。这些结果以及上面的失败类型展示了对每类模型的预期。
• 预算有限时挑选模型的任何人。 这些结果为准确性定价：在哪些地方多花钱能带来很大提升，而在哪些地方多花钱却毫无用处。
• 构建和评估模型的人。 大多数测试奖励已知知识。此测试奖励 不 声称事物，这更难衡量，但在实际产品中很重要。
• InsightTrack 的用户。 Pulse 从证据而非猜测中获取其模型和安全检查。

已测试的模型

所有模型均通过 Kaggle 的模型代理在同一任务版本上运行。我按配对挑选它们，以便每个
比较都能回答一个实际问题：

• 前沿 vs. 低成本，同一公司： Claude Sonnet 5 vs. Claude Haiku 4.5，以及 Gemini 3.7 Flash vs. Gemini 3.5 Flash-Lite。 省钱会损失多少？
• 推理开启 vs. 关闭，同一模型： Grok 4.20 带有和不带有推理。 “思考”会改变答案吗？

发现

1. 工具选择问题已解决。诊断是模型分歧的地方。

每个模型至少有 93% 的时间选择了正确的工具。因此，“它能否调用工具？”对于分析助手来说不再是有趣的问题。真正的问题是它是否理解该
数字 意味着什么。在诊断方面，前三名模型得分 100%，GPT-5.5 得分 96.7%，而每个更便宜的
模型得分在 20% 到 49% 之间。

2. 同一模型，推理开启 vs. 关闭：100% 对比 35%

Grok 4.20 带有推理功能在所有诊断病例中答对。同一模型在没有推理功能的情况下答对率为
35%。它在所有 16 个多因素病例中失误，以及 12 个干扰项中的 9 个。结果中其他方面没有移动如此
程度。如果你的助手回答“X 为什么会变化？”，推理功能不是可有可无的。

3. 便宜模型以两种相反的方式失效

危言耸听者。 没有推理，Grok 凭空编造了 34 次搜索原因。 在一种情况下，流量
上升 从 437 次浏览增加到 538 次浏览，而该页面在 Google 上的排名从第 3 位下降到第 5 位。 提示明确说明，1–2 位的变动是正常抖动，绝不是原因。 Grok 回答：

{"significant": true, "direction": "spike", "causes": ["rank_drop"]}

他们把流量 rise 的增长归因于排名 drop 的下降。正确答案是 unexplained_by_serp：这一变化
并非来自搜索。

耸肩者。 GPT-5.4 nano 则走向了另一方向，将真实的变化称为噪声，共 73 次。一个页面的浏览量
从 209 降至 110 次（−47%），就在它从 Google 排名 #14 滑落到 #26 之后。Nano 回答：

{"significant": false, "direction": null, "causes": []}

对一款分析产品来说，这种失误最危险：报假警的模型让你白忙活一下午，满不在乎的那个
则在你流量被腰斩时，还一直告诉你一切正常。

4. 信号混杂时，所有更便宜的模型全部失灵：8题0分

在最难的那批案例里，一个关键词排名下滑，另一个关键词却在上升，而整体流量是下降的。正确答案应当
只指出那处下降，因为上升解释不了流量为何减少。Flash-Lite、Haiku、不开推理模式的 Grok，以及
nano，8道题全部得 0 分。比如 Haiku 把流量下滑归咎于 ai_citation_gained，可提示词里写明
这条规则只在流量上涨时才适用。真实页面往往同时排上多个关键词，所以这种情况是
家常便饭，而非罕见边角案例。

5. 读取数据：便宜的模型要么拒答，要么瞎编

在读取数据这项上，面对数据本身无法回答的 24 道标准题，7 个模型全都正确地回复了
not_available。但难题集里的陷阱让它们高下立判：

• 凭空编数：要求统计一列页面的独立访客总数（这本不可能，因为同一个人可能访问多个页面），nano 却笃定地报出 9,149。
• 拒答本可回答的问题：nano 出现了 13 次，其他几个便宜模型也各有 5–7 次。明明一次简单计算就能得出答案，它们却回复“不可用”。

一个分不清“我算不出来”和“这根本算不出来”的模型，两头都靠不住。

6. SQL 出错是习惯问题，不是逻辑问题

Gemini 3.7 Flash 在 JSON 类题目上得了 0/7，而其余题目几乎全对。每一次，
它都写出这样的代码：

WHERE properties->>'name' = 'signup'