为什么 LLM 搞不定数据分析
LLM 能写代码、能聊天，但让它分析数据库里的数据，效果往往很差。用户问一句”为什么上周收入下降了”，理论上 Agent 可以自动查数据库、跑分析、给答案。但实际上，大多数时候结果一团糟。
这篇文章整理了几个原因，以及 Tinybird 的一些解决思路。
问题在哪里
LLM 本质上是文本预测模型，擅长处理有逻辑的文字，但数据库里的表格不是故事。
1. 宽表理解能力差
面对一张有 50 列的表，LLM 很容易搞混列之间的关联关系，忽略真正重要的字段。它没有办法像有经验的分析师一样，凭直觉判断哪些列是关键的。
2. SQL 生成不稳定
LLM 能写 SQL，但第一次就写对并不容易，尤其碰到复杂的 JOIN、ClickHouse 方言或物化视图。斯坦福的研究也证实，即使顶尖模型出错率也不低。更糟的是，它出错时还格外”自信”。
3. 上下文撑爆、查询太慢
分析场景动辄几百万行数据。如果直接把查询结果塞进上下文，不仅 token 成本暴涨，还容易超长度限制。再加上写出了低效 SQL，查询跑几分钟，整个交互体验就崩了。
怎么解决：给 LLM 更好的上下文
光扔一个 Schema 给 LLM 是不够的。关键是把数据库包装成 LLM 能理解的形式。
静态上下文：描述资源是什么
- 给每个表、每个字段写清楚业务含义，不只是字段名。比如明确写”计算总销售额用
sum(revenue)，必须加timestamp过滤”。 - 别把全量数据扔进去，用一个小查询返回 5-10 行样本，让 LLM 感知数据格式。
- 提前算好常用的聚合指标（时间序列、唯一值计数等），让模型直接调用，别每次从原始表算起。
Tinybird 的做法是在每个 Data Source 里加一个 DESCRIPTION 块，这个描述不是给人看的注释，而是直接作为 Agent 的上下文喂进去。
动态上下文：按需注入相关信息
用户提问时，系统先用向量搜索从几百张表里找出最相关的几张，再把这几张表的元数据注入 Prompt。这比把所有表一口气塞进去效率高得多。
另一个思路是引入语义层：预先定义好业务指标（比如 AOV 怎么算），LLM 只需要表达意图，系统自动映射到正确的公式。
其他几点建议
- 让 LLM 自己改错：SQL 跑失败就把报错返回给它，让它重试。这个循环能显著提升成功率。
- 用第二个 LLM 做校验：专门跑一个模型检查第一个模型的结论是否符合数据事实，过滤幻觉。
- 用 MCP 标准化工具调用：Anthropic 的 Model Context Protocol 可以把数据库资源标准化成 LLM 能直接调用的 Tool，Tinybird 已经用 MCP Server 实现了这个。
小结
让 LLM 做好数据分析，关键不是模型有多大，而是给它的上下文质量有多高。静态上下文解决”数据是什么”，动态上下文解决”该用哪些数据”。两者配合，才能让模型真正有效地回答数据问题。
