Analytics AI 的问题不是访问数据，而是判断力

现在关于 AI 和 analytics 有一种很流行的乐观叙事，我认为它完全错过了重点。它大概是这样说的：只要给模型更多上下文，更多表、更多 metadata、更多 lineage 文档，它就能可靠地回答业务问题。

不会。

过去一年，我一直在构建用语言模型回答数据仓库问题的 analytics 系统。我的经验是：访问数据是容易的部分。真正难的，是 query 前后的事情：你是否知道现在有没有足够上下文来写 query，以及返回的答案到底是不是对的。

我合作过最好的 analytics engineers，并不是因为 SQL 写得更快而显得厉害。他们厉害的地方，是知道什么时候信息还不够，甚至根本不该开始写 SQL。

他们会在碰键盘之前先问澄清问题。他们会先判断 30% 的收入下跌是真实业务事件，还是 backfill 延迟，而不是立刻把问题升级给管理层。他们会同时保留几个相互竞争的假设，直到证据真正收敛。

这些能力，不会因为你给模型更多 table schema 就自动出现。

---

真正缺失的东西

我认为，今天几乎所有 analytics AI 工具都缺三件事。

1. 生成和评估必须分离

Analytics agent 有一个自我评估问题：当你让它判断自己的输出时，它通常会觉得自己的输出还挺合理。这不是单纯的模型能力问题，而是结构问题。生成 query 的那个 agent，天然会为自己生成的 query 辩护。

解决办法不是换一个更聪明的模型，而是换一种架构：把负责执行工作的 agent 和负责审核工作的 agent 分开。后者要检查 row count 是否符合预期，对照已知 benchmark，标记那些历史上从没大幅波动、却突然周环比跳升 40% 的指标。

2. 对话结束后仍然存在的 artifacts

一次 analytics investigation 往往会跨多个 session、多人参与，也会经历多轮假设变化。但大多数 AI analytics 工具都把每次交互当成全新的开始。过程中建立的 institutional knowledge，比如考虑过哪些表、做过哪些假设、哪些解释被排除以及为什么，都会在 chat window 关闭时消失。

设计良好的系统应该留下结构化 artifacts：

• 一个 brief，记录请求以及它可能的解释
• 一条 evidence trace，记录看过什么、放弃过什么
• 一份 plausibility report，记录系统检查了哪些东西

这些东西会把“和 AI 聊天”变成“可以被 review 的 investigation”。它让人，或者未来的另一个 session，可以准确接上之前的工作。

3. 对成功 query 提出正确问题

一个 query 能成功执行，几乎不能说明分析是正确的。用错 timestamp column，join 错 key，某个 filter 静默排除了关键人群，或者从两个 source table 混用了不同 metric definition。这些都会产出语法正确、表面合理的结果。直到某个有 domain expertise 的人仔细看，问题才会显出来。

---

这对实践意味着什么

我构建 analytics AI 工具，也每天把它们用在真实问题上。我不断回到的架构，不是一个更聪明的 chat interface，而是一个控制层。它管理从模糊业务问题到经过验证答案的完整 loop。

这个 loop 里有明确 checkpoint：

• 现在是否有足够上下文继续，还是必须先澄清问题？
• 这个结果是否通过基本 plausibility checks，还是有什么地方看起来可疑？
• 系统是否用人类能阅读、审核和挑战的形式记录了自己的假设？

这些 checkpoint 不是对智能的限制。它们是让智能变得可信的结构。

Senior analyst 会自然地这样工作：进入问题时自由探索多个假设，离开问题时严格收敛到一个结论。手艺在于知道这两种模式的区别，并且有意识地切换。一个设计良好的系统会把这种纪律编码进架构里，而不是指望模型刚好从训练数据里学会。

真正重要的工具，不是 SQL generation 最强的工具，而是知道什么时候 SQL 还不是答案的工具。

当一个问题模糊到可以产生三个不同但都合理的 query。当结果怪得统计规则抓不到，但判断力能察觉。当正确动作不是继续生成，而是停下来，暴露假设，问一个人。

---