LLM 分析基准测试：如何为分析智能体挑选最佳模型
LLM analytics benchmark: the best model for your analytics agent
Cassis 用 30 道 Formula 1 题（基于 Spider 2.0 数据库）加 60 道业务题对比八款 LLM，衡量答案质量、推理开销与成本。业务题上 Sonnet 5.5 以 75% 正确率、每题 $0.12 居首，Fable 5.1 仅 53% 却要 $0.57，因此 Cassis 将默认模型切换为 Sonnet 5.5。
我们在分析问题上比较了八个 LLM，以选择我们代理的模型，衡量答案质量、推理投入、成本以及我们测试框架的效果。
Matthieu Geoffray 2026年10月6日
当分析代理给出错误答案时，可能有三个原因。它所需的信息在上下文中缺失或错误。信息存在，但代理没有找到。或者代理找到了，但模型误读了它或写错了查询。在 Cassis，我们的大部分工作集中在前两个：随着业务变化保持上下文真实，并对其进行结构化，以便代理能找到所需内容。我们还在该上下文上运行自己的代理，它通过 Cassis Web 应用和我们的 MCP 服务器回答问题。第三个原因取决于模型，并且每次发布都会变化。
这三者并非相互独立。上下文需要详细说明的程度取决于阅读它的模型，而推理更多的模型可能会读取超出问题所需的上下文。因此，每次新模型发布都会带来同样的问题：我们是否应该更新代理背后的模型？LLM 提供商提供的基准测试让人跃跃欲试，但它们不会在公司自己的定义上测试模型。我们需要在将新模型交到用户手中之前验证代理行为。手动测试所有这些需要时间，我们无法在每次发布时都花费这些时间。因此，我们构建了一个可重复的基准测试，以比较不同模型的答案质量、一致性和成本。在本文中，我们解释了基准测试背后的方法，以及我们迄今为止学到的东西。
我们测试什么
我们将 30 个关于 公开 Formula 1 数据库的案例与 60 个受我们内部实际使用启发的业务案例相结合。两组都包含我们的代理必须处理的案例：一个直接且简单的问题、一个修改初始请求的后续问题、一个模糊的问题，以及对我们来说非常重要的一个案例：可用数据无法覆盖的问题。
Formula 1 基准测试在来自 Spider 2.0（一个公开学术基准）的 Formula 1 数据库上运行：比赛、车手、车队、积分。模式很小且有文档记录，而 Formula 1 锦标赛的运作方式已经在模型的训练数据中。基准测试本身可能也是如此。我们运行每个生成的查询，并将其结果与预期输出进行比较。
业务基准测试更接近我们用户所做的事情。它的 60 个问题受我们在实际使用中看到的内容启发，基于一个带有上下文的大型业务模式：业务定义、指标和规则。该上下文太大，无法放入模型的上下文窗口，因此代理必须找到所需内容。我们有模式和上下文，但没有数据，所以我们不运行这些查询：由 LLM 评判员检查生成的 SQL 是否与参考等价。
我们的测试框架是我们的代理如何在该上下文中找到所需内容，即上述三个原因中的第二个。它将上下文作为业务领域的树进行导航，读取所需的表、指标和连接，规划查询，然后编写它。为了衡量测试框架增加了什么，我们还在没有它的情况下运行了每个模型：模型使用纯文本搜索（grep）搜索相同的上下文和模式，并阅读它找到的文档。
结果
在我们的业务问题上，Sonnet 5.5 排名第一：正确率 75%，每题成本 $0.12。我们测试过的最贵模型 Fable 5.1 得分为 53%，每题成本 $0.57。本节中的数字均基于我们的测试框架，采用中等努力程度：中等努力程度的结果覆盖了全部八个选定模型，并保留 GPT-6 Sol 和 Sonnet 5 作为其后续模型的参照点。图表保留了所有可用设置。
一级方程式基准测试很容易被大多数模型饱和，因此不太适合进行细粒度排名，但它仍然是一个有用的低成本回归检查。在自适应推理和中等努力程度下，Sonnet 5、Sonnet 5.5 和 Fable 5.1 在我们的 25 个可回答的一级方程式案例中，各自匹配了全部 75 个执行结果，重复三次。GPT-6 Luna、GPT-6 Sol 和 Opus 5.5 各自匹配 72/75（96%）；GPT-6 Astra 匹配 69/75（92%），GPT-6.1 Sol 匹配 66/75（88%）。在 25 个案例上相差几分并不显著。当不同的模型和设置组合取得相同分数时，成本就成为首要决定因素。
业务基准测试将各模型区分开来：得分从 38% 到 75% 不等。在这个规模下，小差距仍然是噪声：Sonnet 5.5 领先 Sonnet 5 7 分，即 150 次对话中的 10 次。但它对 Opus 5.5（13 分）、Fable 5.1（22 分）以及每个 GPT 模型（20 分或更多）的领先则并非噪声。因此我们将默认模型切换为 Sonnet 5.5：它得分最高，而且成本低于 Sonnet 5——唯一与其差距在噪声范围内的模型。GPT-6 Luna 的每题成本低 25 倍，但正确回答的问题少 20 分。
当上下文很大时，我们的测试框架会带来差异。在一级方程式上，大多数模型使用与不使用它的结果相似。在业务基准测试上，它为 Sonnet 5.5 增加 10 分（从 65% 到 75%），为 GPT-6.1 Sol 增加 11 分，为 GPT-6 Astra 增加 15 分。Fable 5.1 是例外：不使用我们的测试框架为 58%，使用后为 53%。我们目前还无法解释。一种假设是我们在其他模型上调整了我们的测试框架。
业务基准测试得分
27 个结果
| 模型 | 测试框架 | 努力程度 | 得分 | 成本 / 任务 |
|---|---|---|---|---|
| GPT-6 Astra | 使用 | 低 | 37.3% | $0.3845 |
| GPT-6 Astra | 使用 | 中 | 40.7% | $0.4266 |
| GPT-6 Astra | 使用 | 高 | 37.3% | $0.5431 |
| GPT-6 Astra | 不使用 | 中 | 25.3% | $0.1766 |
| GPT-6 Luna | 使用 | 无思考 | 43.3% | $0.0037 |
| GPT-6 Luna | 使用 | 低 | 46.0% | $0.0039 |
| GPT-6 Luna | 使用 | 中 | 55.3% | $0.0049 |
| GPT-6 Luna | 使用 | 高 | 52.9% | $0.0050 |
| GPT-6 Luna | 不使用 | 中 | 53.3% | $0.0027 |
| GPT-6 Sol | 使用 | 无思考 | 40.7% | $0.0931 |
| GPT-6 Sol | 使用 | 低 | 44.0% | $0.0875 |
| GPT-6 Sol | 使用 | 中 | 38.7% | $0.1112 |
| GPT-6 Sol | 使用 | 高 | 45.1% | $0.1165 |
| GPT-6 Sol | 不使用 | 中 | 37.3% | $0.0453 |
| GPT-6.1 Sol | 使用 | 低 | 39.2% | $0.0699 |
| GPT-6.1 Sol | 使用 | 中 | 38.0% | $0.0726 |
| GPT-6.1 Sol | 使用 | 高 | 35.3% | $0.0996 |
| GPT-6.1 Sol | 不使用 | 中 | 27.3% | $0.0313 |
| Fable 5.1 | 使用 | 低 | 52.9% | $0.5087 |
| Fable 5.1 | 使用 | 中 | 53.3% | $0.5695 |
| Fable 5.1 | 使用 | 高 | 63.1% | $0.6053 |
| Fable 5.1 | 不使用 | 中 | 58.7% | $0.8052 |
| Opus 5.5 | 使用 | 低 | 76.5% | $0.2322 |
| Opus 5.5 | 使用 | 中 | 62.0% | $0.3004 |
| Opus 5.5 | 使用 | 高 | 58.8% | $0.3115 |
| Opus 5.5 | 不使用 | 中 | 56.0% | $0.4801 |
| Sonnet 5 | 使用 | 无思考 | 58.7% | $0.1268 |
| Sonnet 5 | 使用 | 低 | 65.3% | $0.1250 |
| Sonnet 5 | 使用 | 中 | 68.7% | $0.1384 |
| Sonnet 5 | 使用 | 高 | 62.7% | $0.1400 |
| Sonnet 5 | 不使用 | 中 | 61.3% | $0.2032 |
| Sonnet 5.5 | 使用 | 低 | 82.4% | $0.1154 |
| Sonnet 5.5 | 使用 | 中 | 75.3% | $0.1237 |
| Sonnet 5.5 | 使用 | 高 | 76.5% | $0.1478 |
| Sonnet 5.5 | 不使用 | 中 | 65.3% | $0.1223 |
我们如何评估答案
开发参考答案是最耗时的部分。现有仪表板查询和经过验证的用户查询是很好的起点，但每个参考答案都需要仔细检查。我们在同一组问题上、使用相同的上下文和工具评估每个模型，并将每个测试重复 3 次以衡量一致性。
会出现两种情况：
-
问题期望得到结果。在 Formula 1 上，我们可以将查询结果与预期输出进行比较。我们不比较列名或 SQL 查询，从而允许列别名等无害差异。
-
问题期望得到澄清或期望得到“我不知道”的回答。这些情况和分歧由 LLM 评判员评估，需要人工关注。合理的进一步询问信息请求不应被视为错误答案。对于每个被测试的模型，LLM 评判员完全相同（相同的测试框架、相同的模型）。
业务失败告诉我们什么
我们检查的失败属于第三种：智能体拥有所需的一切，而模型没有遵循定义或问题。
-
一些模型不遵循预期的输出约定。GPT-6.1 Sol 经常将比率表示为百分比，而上下文将其定义为比值。业务计算可能是正确的，但其表示方式与我们的评估预期不同。
-
增加投入可能会触发更多验证请求。使用 Opus 5.5 时，中断的对话数量从“低”级别的 3 次上升到“高”级别的 9 次。智能体向用户提供更多选择，这会在我们的测试框架中触发暂停。这些问题已经由上下文解决了。
-
增加投入可能导致超出初始请求。在我们的测试中，“高”模式查阅更多上下文（约多 30%），有时会添加未请求的列。虽然这些添加可能有用，但它们可能导致潜在错误：我们观察到少数情况下，额外的列改变了分组并改变了结果。
为了保持成本合理，我们在缩减的问题集上运行了低和高投入级别。在该集合上，Opus 5.5 在低投入下正确回答了 51 个对话中的 39 个，在高投入下回答了 30 个，而额外的六次暂停占了这一差距的大部分。更谨慎的模型不应得分更低，所以部分责任在我们：只要计划提供选择，我们的测试框架就会暂停，即使上下文已经解决了该选择。
下一步是什么
保持分析智能体与时俱进，需要一种可重复的方式来检查新模型和智能体的变更。更新提示、添加工具或更改我们的上下文格式都可能影响质量、成本和行为。我们的基准测试有助于衡量这些影响并防止回归。检查失败是改进我们的智能体及其评估的好方法。
我们的下一步是评估智能体如何得出答案。它如何在上下文中导航？读取了哪些领域，遗漏了哪些相关定义？我们需要区分有用的探索和无用的绕路。这指向一个更广泛的想法：除了最终得分之外，我们如何确保智能体方法的可靠性和一致性？
博客
关于数据、含义和上下文的说明
来源：Hacker News · blog.getcassis.com