LLM 连接数据库：实测准确率仅 21%

在几乎每一次早期沟通中，我都会听到同一个问题：既然我可以直接让 Claude 连接 Postgres 并开始提问，为什么还需要一个平台？

这是个合理的问题。连接器是真实存在的。Claude 接入 Snowflake 和 Postgres，ChatGPT 通过 MCP 桥接访问数据仓库，Gemini 内置于 BigQuery。演示确实令人印象深刻。

但现在我们有了关于演示之后会发生什么的公开数据。

Anthropic 在自己的分析工作负载上做了测试："没有 Skills 的情况下，Claude 准确回答分析问题的能力在评估中不超过 21%。" 就是你会连接到数据库的同一个模型。他们的数据，他们的问题，21%。

基准测试也证实了这一点。Spider 2.0 来自真实的企业数据仓库工作流：千列schema、百行查询、多种 SQL 方言。GPT-4o 在上面得分 10.1%。o1-preview 达到 17.1%。同样的模型在旧的学术基准上能クリア 85%，这就是为什么演示看起来像魔法，而第四周就不行了。

BIRD 解释了这种崩塌。BIRD 的每个问题都附带一条手写的提示，解释各个字段的含义。去掉提示后，GPT-4 从 54.89% 跌到 34.88%。你的用户不会写提示。他们问"我们有多少活跃客户"，然后假设模型知道 active 是什么意思。它不知道。它选出你的四十多个候选列中的一个，然后自信地求和。

这才是危险的部分。一个错误的数字看起来并不像错误的。Anthropic 称之为静默失败，并承认他们加固过的技术栈能减少它，但无法消除它。

那 74 分的代价

Anthropic 把这个差距从 21% 缩小到 95% 以上。不是靠更大的模型，也不是靠更多的数据访问：他们给 Agent 提供了数千条自己过去正确的查询记录供 grep 访问，准确率移动了不到一点。

真正起作用的是结构。受治理的规范数据集。一个语义层，人类拥有每个指标定义的所有权。数据血缘。编码了谨慎分析师工作方式的 Skills。一个评估工具链监控这一切。四层结构，由世界上最好的数据团队之一构建和维护。这篇文章刚发布时，我写过谁有资格在产品中构建这种脚手架。

其他厂商也在产品中内置了同样的结论。Snowflake 将自己的 MCP server 限制在语义视图上，因为原始 schema 缺乏分析师需要的含义。Google 用 Knowledge Catalog 和 Looker 语义层包裹 Gemini，然后把这个捆绑包称为产品。连接器是界面；下面的治理层才是他们卖的东西。

连接器永远构建不了的东西

除了准确性之外，这个卖点里还有一个类别错误。连接器读取表。而你的数据问题是：没有人真正在构建这些表。

连接器不会把你的数据源落地到仓库。不会建模 Raw → Clean → Ready。它在你打开聊天时运行，关闭聊天时停止：ChatGPT 会话在断开时丢弃状态，不会按计划运行任何东西。它整夜不监控任何东西。它每个会话都重新学习你的业务，因为聊天记忆不是语义层。

而且管道本身需要你自己搞定。Anthropic 把那个没有查询超时、行数限制、列黑名单的参考 Postgres MCP server 归档了，放在一个简单的警告后面：没有安全保证。它每个月仍有大约 31.2 万次安装，主要来自那些正好接入了演示中那种设置的人。

OptimaFlo 运行在同样的模型上。你带来你自己的 Claude、GPT 或 Gemini key。我对引擎没有异议。

我们卖的是那 74 分：受治理的数据集、语义层、数据管道、质量检查，以及 Anthropic 组建团队构建的评估规范——打包成一个数据负责人可以运行的产品，运行在你自己云中的开放 Iceberg 表上。在 SQL 触及你的表之前，有人类审批。聊天界面也在里面。它是最后一步，也是最简单的一步。

如果你的仓库已经被建模和治理了，上面加一个 20 美元的聊天座位是一笔划算的交易，我在我们的对比表里也这么说了。如果没有人真正在构建那个仓库，那个座位就无处站立。

21% 是模型带来的。剩下的才是工作。欢迎来看看我们怎么做，或者在 7 天试点里先试试水。