字节跳动内部用了三年的数据分析助手 iDA,最近正式上线火山引擎 — 我们读完它的技术细节后判断:让 AI 写出一段能跑的 SQL 只占两成工作量,剩下八成是方言、口径、权限这些工程脏活。

这是什么

iDA 是字节跳动内部广泛使用的数据智能助手,2024 年前后它的形态还接近 ChatBI — 让模型把自然语言翻译成 SQL,让用户告别拖拽式 BI 取数。真正产品化后团队发现,「会写 SQL」和「能稳定查数」之间隔着一大段工程距离。

现在它正式对外开放,能力覆盖数据查找、数据分析、知识检索、文档撰写。技术细节里藏了三个关键选择:

第一,DSL 还是 SQL。DSL(领域专用语言)即一套自定义语法,工程执行友好但模型不熟悉;iDA 选择让模型直接写 SQL,因为 SQL 在模型训练语料里大量存在,把模型的注意力留给问题拆解更划算。

第二,单 Agent 还是多 Agent。Agent(AI 智能体)即能自主完成多步任务的 AI 助手。多 Agent 协作是当下流行路线,但 iDA 选择主 Agent 独自写 SQL — 实验显示上下文传递成本高于专业化收益。

第三,SQL 跑通之后还有方言适配(不同数据库的语法差异)、枚举值匹配(用户说「北京」,数据库里是「北京市」)、不同团队的口径差异。iDA 的做法是:让模型面对统一的 ANSI SQL,剩余复杂度留给工程层消化。

行业怎么看

支持方认为 iDA 的两条反潮流决策都站得住脚:用 SQL 而非 DSL,是承认模型上下文是稀缺资源;用单 Agent 而非多 Agent,是承认任务边界难以稳定切分时短链路更可靠。

但反对意见同样值得听。这套架构高度依赖字节自研的数据中台 DataWind、内部数据资产治理和向量召回系统。外部企业没有这套基础设施,复制成本极高 — 「工程链路是护城河」换个说法就是「小公司别想抄作业」。

还有一层疑虑:iDA 公开材料没有给出准确率、延迟等关键指标,「速度与准确性来自整个链路的共同收敛」更像工程黑话,普通读者无法独立验证。

对普通人的影响

对企业 IT:数据分析工具的采购标准要变了 — 不能只看模型是不是 GPT-4 级别,要看供应商有没有方言适配、字段值召回、业务口径管理这些苦活能力。

对个人职场:白领做数据查询的门槛在降低,但「问对问题」比「会用工具」更值钱。业务口径的定义权,会向真正懂业务的人集中。

对消费市场:短期看不到影响。这是面向企业的工具,和普通消费者的日常生活关系不大。