AI分析引擎难题评测：Spotter领跑BIRD

📌 核心要点

• 1. 该领域在挑战性和高难度问题上的表现出现分化：Spotter 答对了挑战性难度档位中 70.6% 的问题，而表现最差的引擎仅答对 46.8%。
• 2. 预测在你的数据上表现如何的，是准确率斜率，而不是标题上的准确率。
• 3. 换用更新型号的模型使整体得分提升了 3.4 个百分点，而其底层的智能体框架没有任何改动。
• 4. 完整协议、置信区间以及逐题结果可按需提供。

分析供应商声称其 AI 能准确回答问题，但几乎没有一家会向你展示他们是如何验证的。

标准做法是给出一个没有分母的百分比：“在内部基准测试上准确率 90%+”。没有可下载的数据集。没有可检查的评分方法。没有竞争对手在相同条件下运行。你被要求信任这个分数，却从未见过考卷1

我们改为以公开方式进行了这场考试。今年夏天，我们把 Spotter 和四个竞争性智能体分析引擎送入了 BIRD，这是针对真实数据库的自然语言问题最广被引用的公开基准：1,533 道题、11 个数据库、所有人采用同一套评分方法、每道题仅一次尝试机会。

结果如下：Spotter 答对了 82.8%，领先于前沿大语言模型的 78.4% 和编码智能体的 72.5%。

但必须在知识工作的语境中理解这些数字。BARC 的 BI 与分析调查显示，活跃的 BI 采用率约为员工总数的四分之一，而这一比例在七年里几乎没有变化。

例如：在一家拥有 10,000 名员工的企业中，这意味着 2,500 名分析用户；按每人每周提出五个数据问题计算，每年约 650,000 个问题。一个准确率百分点就意味着每年有 6,500 个答案由错误变为正确。与编码智能体之间 10.3 个百分点的差距无需任何附加说明：每年 67,000 个错误答案。

图 1。 整体执行准确率，五个引擎，BIRD 开发集拆分 dev_20251106。Pass@1，单次尝试。

当数据是你自己的时，“简单到挑战性”意味着什么？

BIRD 将问题分为三档：简单（859 题）、中等（443 题）、挑战性（231 题）。这些标签追踪的是所需 SQL 的结构，而非问题的长度。

五个引擎在同一源数据上参加了同一场考试。我们以类别而非产品名称来报告它们，复现包中列出了每一个：

• Spotter，基于受治理的语义模型工作
• 一个仓库原生助手，在其自身平台内读取原始架构
• 一个湖仓 AI/BI 智能体，基于其目录工作
• 一个直接编写 SQL 的前沿大语言模型
• 一个在提问时发现架构的编码智能体

以一家 B2B 软件公司的销售运营为例。RevOps 分析师底下的仓库从来都不是一张干净的表。它是一张与账户、负责人和区域相连接的商机表。一张阶段历史表，每笔交易每次阶段变更都会出现一次，因此计算行数毫无意义。

三个金额字段： amount、ARR、TCV，它们在好日子里彼此一致。一个由财务部门决定何时开始的财年日历。以及一个根本不算列的“细分”；它是一条关于员工人数和支出的规则，存放在某个文档里。

现在用一个团队的问题来攀登这个阶梯。

简单：“我们目前在 EMEA 有多少个未结商机？”一张表，两个筛选条件。唯一的工作是把“未结”映射到正确的阶段值上。BIRD 中这一档的版本是按边框颜色统计交易卡，我们测试的每个引擎在这里都超过了 80%。

中等：“哪些企业账户有本财年创建的未结交易，以及它们由谁负责？”现在答案跨越三张表，“企业”解析为一条规则而非一个列，而且“本财年”不是从一月开始。BIRD 的版本是将一张学校财务表与一个目录连接，通过一个 Y/N 标志和一个以文本存储的日期来查找特许学校。这是这样的难度级别：没有你的架构地图的引擎开始猜测连接路径。

挑战性：“在我们顶级 SDR 获取的交易中，有多大比例以超过 10 万美元成交？”顶级 SDR 是一个最高级表述，必须变成一个子查询，这还没算到比率——而比率有一个正确的分母和几个错误的分母。这与 BIRD 挑战性档位的问题在结构上相同，正是在这里各引擎出现了明显分化：Spotter 答对了该档位 70.6% 的问题，编码智能体为 46.8%。

难题之所以难，不是因为 SQL 语法。它们难是因为你的业务：采用哪种赢单率定义、按谁的财年日历、三个金额字段中哪个是真的。

对于 RevOps 分析师来说，看得见的好处是省去了写 SQL。对于 CRO 来说，真正重要的好处是最终进入董事会演示文稿的那个覆盖率数字是否正确。

为什么五个引擎的看法不同？

每个引擎都在相同的源数据上回答了相同的问题。但没有两个引擎看到相同的数据模型。编码智能体和前沿大语言模型在提问时才发现架构：列出表、读取列名、推断连接，然后指望这些名称说的是真话。

仓库原生助手在其自身平台内读取原始架构，并在其上叠加检索。湖仓智能体基于其目录工作。Spotter 基于一个受治理的语义模型工作，其中连接拓扑、指标定义和业务词汇在任何问题提出之前就已一次性编码完成。

这种差异在简单档位上不可见，而它决定了挑战性档位的成败。

一个诚实的细节：BIRD 为每道题附带一条证据提示，比如“black border card 指的是 borderColor = 'black'”这样的一行说明。每个引擎都得到了提示；协议完全相同。

但请注意这条提示是什么。它是有人把引擎无法从架构中推断出的业务定义直接交给它。

在生产环境中，没人在早上 8 点、在预测电话会议之前把证据提示输入聊天框。这些定义永久存放的地方是语义模型。

基准测试给每个引擎发了一张便利贴；Spotter 是唯一一个保留了档案柜的。

领先优势体现在哪里？

图 2。 按 BIRD 难度分档的准确率，pass@1。从简单到挑战的斜率把各引擎区分开来。

如实看待差距。在简单和中等难度问题上，Spotter 对仓库原生助手的领先为 0.1 和 0.4 个百分点，即一题和两题。这可以称为平局。

持久的差距出现在挑战难度级别：70.6%，领先最接近的竞争对手整整 3.9 个百分点、九道题，而正是在这一档，“最高销售额代表”必须变成子查询。

作为校准参考：231 道题的分档对应约 ±6 个百分点的抽样区间，因此我们公布该差距时附上其区间，并且在将其称为定论之前，我们正在做逐题配对分析。

它们是多重连接、多条件、业务逻辑类问题，也是这场考试中最接近你企业数据的东西。以下是各选手在这些问题上的表现。

从表格底部看起，因为崩塌才是关键。编码代理总体取得尚可的 72.5%，然后在难题上正确回答的不到一半。

这使它与 Spotter 之间相差 55 道题，而这是唯一一个所有人都该关心的分档。湖仓代理差了 28 道题，前沿 LLM 差了 32 道。

这三个差距都很大；它们远在抽样区间之外，并且以 p < 0.05 或更好的水平成立。

斜率比任何单个数据点都更重要。从简单到挑战，Spotter 损失了 16.4 个百分点的准确率。仓库原生助手损失 20.2，湖仓代理损失 23.0，前沿 LLM 损失 26.8，编码代理损失 33.5。

每个引擎在简单问题上看起来都很聪明。斜率告诉你该把难题托付给哪一个——而编码代理尚可的 72.5% 总体成绩，恰好掩盖了在问题开始像你的流水线评审时跌至 46.8% 的事实。勉强二分之一。

这很重要，因为中等和挑战难度并不是考试中的边缘情况。它们是企业工作负载：多表连接、不存在于任何列中的定义、按财务部门说了算才开始财年的财政日历，而单表问题只是演示。

模型升级能换来什么？

在 Spotter 的两次运行之间，恰好只有一个变量改变：Claude Opus 4.8 变为 Claude Opus 5。语义模型、提示词和协议完全相同。准确率总体上升 3.4 个百分点，在挑战性问题上上升 4.8 个百分点。全部 11 个数据库都有提升，最大增益落在连接最多的模式上。没有任何回退，每题工具调用次数持平在 2.1，因此增益来自推理质量，而非额外工作。

这就是该实验实际衡量的内容。模型是分析师框架内的一个组件：其下方受治理的语义模型、它在 Spotter Memory 中积累的受指导定义和参考问题，以及在结果交付前检查所生成查询的验证层。

所有这些上下文只构建一次，并在两次运行之间原样沿用。升级是组件替换，而非重建。

这也是增益会复利的原因。将前沿 LLM 直接接入仓库的团队，每次模型发布都要重建他们的提示词脚手架，而他们积累的修复也随旧提示词一同消亡。

框架会保留部署已经学到的一切——每一个学到的定义、每一条经验证的连接路径——每个新模型都叠加在其上。

上下文复利增长；模型则可替换。前沿模型每隔几个月就会改进，而一个能干净地吸收它们的平台，会在第一天把每次发布转化为准确率红利。换掉模型。保留企业知识。

Opus 4.8 → Opus 5：升级换来了什么

这对你意味着什么？

我们测试的每个引擎都轻松通过了简单问题；那个头条数字本可以是任何厂商的。Spotter 在那里保持 70.6%，而其他选手最低跌至 46.8%，而告诉你该把那些问题托付给哪个引擎的，是斜率，不是头条数字。

那些问题所依赖的定义和连接路径存在于语义模型和 Spotter Memory 中，只构建一次，随着每道被教授的问题和每次被吸收的模型发布而不断复利增长。

可以这样理解：模型是商品，数据模型是护城河，而框架是复利资产。

想在你自己的数据上试用 Spotter 吗？申请你的现场演示。

附录：

• 协议与评分。BIRD 开发集划分 dev_20251106；每个数字都是 pass@1：一次尝试，不重试，不做共识采样，生产配置，提示词完全相同。评分对照 BIRD 的黄金答案以二元方式判定：确定性的预检在数值、NULL、日期、大小写和缩放容差内自动通过精确匹配（它只能通过，绝不会失败），然后由评分标准裁判给其余答案打分，裁判看到问题、预期输出和答案数据，但从不看 SQL。BIRD 的官方评分器无法端到端运行，因为它针对 SQLite 执行 SQL，而并非每个引擎都发出可移植 SQL；Spotter 通过其语义层作答。裁判是 [model]，与任何引擎的生成器都属不同模型家族，已对照 [N] 道题的人工审计样本（[X]% 一致率）进行验证，并在两者都能运行的子集上对照官方执行匹配进行验证。
• 统计。总体结果带有约 ±2 个百分点的 95% 置信区间；挑战分档约为 ±6。在我们称为平局的差距上，这些样本量下并不显著。3.9 个百分点的挑战难度差距尚未通过逐题配对检验；无论结果如何，我们都会更新本文。对湖仓代理、前沿 LLM 和编码代理的差距，以及 Opus 4.8 到 Opus 5 的配对增量，均以 p < 0.05 或更好的水平显著。
• 答案键中的已知缺陷。上述审计发现在受审的 BIRD Mini-Dev 示例中有 52.8% 存在标注问题，并表明修正可以使分数变动两位数，并重新排列差距很小的系统。五个引擎都使用了相同的标准答案，因此该误差是对称的，但它是除抽样之外的第二个不确定性来源。它也为本文所持的立场提供了独立证据：基准分数是审查的起点，而非终点。系统内的增量，包括模型升级，在两次运行中都使用相同的标准答案，因此标准答案错误在差值中被抵消。[如果重新评分得以落地：我们依据社区修正后的标注重新评分了全部五个引擎；无论结果如何，都会在此处呈现。]
• 名称与复现。竞争对手以类别形式出现；复现包列出了确切的产品、版本和配置，并附有逐题结果和评判记录，任何客户或分析师均可应要求获取。
• 我们如何评分？本文中的每个数字都是 pass@1：每个问题一次尝试，不重试，不做共识采样，仅使用生产配置，每个引擎使用完全相同的提示词。评分依据 BIRD 的标准答案进行二元通过/失败判定，分两个阶段。确定性预筛在数字、NULL、日期、大小写和量级容差下自动通过精确匹配——从设计上，它只能让答案通过，绝不会判其失败。评分标准评判器对剩余部分评分，并看到三样东西：问题、预期输出和答案数据。从不看 SQL。一个通过丑陋查询得到正确行的引擎会通过；一个返回错误行的优雅查询会失败。这正是你的 CFO 评分的方式。

订阅我们的博客