iDA ------字节跳动内部员工广泛使用的数据智能助手。它可以链接企业内部数据与知识体系，能够高效支撑从简单查询到复杂分析的多类任务，广泛覆盖数据查找、数据分析、知识检索、文档撰写等高频工作场景。目前，同名同款能力正式上线火山引擎。
本文将系统解读 iDA 的技术架构设计，梳理其从 ChatBI 向专业级数据智能助理演进的整体路径，并重点解读其在数据工程优化、工具能力调用等关键模块上的架构选型与工程实践。
起点：ChatBI 的理想与现实
iDA 发展的早期形态更接近 ChatBI，目标很直接：让模型把自然语言翻译成 SQL，让用户不必再通过传统 BI 的拖拽配置来取数。2024 年前后，这个想法看起来离落地很近，但真正产品化时，团队很快发现"会写 SQL"和"能稳定查数"之间隔着一大段工程距离。
早期模型写出的 SQL 经常存在语法错误，很多查询看起来比较常规，但执行时却直接报错。随着不同系列的模型能力提升，简单问数开始变得可用，比如查询昨天支付 GMV、环比增长这类单点问题。但这只是第一步。
专业数据分析不只要求模型写出一段 SQL。它还要面对复杂口径、多数据源、不同查询引擎、权限体系、图表二次分析、字段枚举值、增量表与全量表差异，以及执行资源和性能约束。iDA 真正的演进，就是围绕这些真实问题展开的。
第一道选择题：DSL 还是 SQL
要让模型完成数据查询，团队最早面对的是两条路线。
DSL 路线要求模型输出一份自定义的结构化描述，再由执行层转换成查询。它对工程执行很友好，但对模型不友好。复杂查询往往需要定义维度、指标、聚合、同环比、筛选、排序、TopN、合计和图表类型；这些自定义规则不在模型的通用训练语料里，只能依赖有限的上下文临时理解。
SQL 路线则相反。模型直接生成 SQL，工程层负责解析、改写和执行。工程工作明显增加，但 SQL 是模型熟悉的通用语言，也能自然表达分位数、组内排序、复杂聚合等需求。
团队最终选择了 SQL。这个选择背后的判断很朴素：模型的上下文和注意力是稀缺资源，不该消耗在理解一套自定义语法上。 与其让模型记住更多规则，不如让工程系统多做一些确定性的工作，把模型能力留给问题拆解和数据探索。
第二道选择题：子 Agent 还是主 Agent
多 Agent 流行之后，团队也尝试过让专门的 SQL 子 Agent 负责查询。这个方案看起来合理：可以为子 Agent 注入 SQL 指南，甚至换用更擅长编码的模型，还能把多轮纠错留在独立上下文里。
实验暴露了另一面。SQL 往往只是复杂任务的第一步，主 Agent 需要把用户目标完整传给子 Agent；任务描述一旦遗漏上下文，结果就可能偏离。上下文传递本身也会增加耗时，而随着基础模型的 SQL 能力提升，额外 SQL 指南带来的收益越来越小。
因此，iDA 回到由主 Agent 直接写 SQL 的路线。它并不意味着子 Agent 没有价值，而是说明架构不能只追求形式上的"多智能体"。当任务边界难以稳定切分、上下文传递成本高于专业化收益时，更短的链路反而更可靠。
SQL 能运行，只是起点
Text-to-SQL 真正困难的部分，往往发生在 SQL 看起来已经正确之后。数据分析系统需要处理的，不只是语法，还有方言、口径、枚举值、权限和表语义。
把多种方言收敛成一种语言
MySQL、PostgreSQL、Hive、ClickHouse、Doris 都有自己的 SQL 方言。若让模型在一次任务中来回切换，冷门语法和跨引擎混用很容易出错。
iDA 的做法是尽量让模型只写 ANSI SQL，再由工程层改写成目标引擎方言。团队持续收集线上案例并补齐函数与语法适配。模型面对的是相对统一的语言，工程系统则负责吸收底层差异。
用户说"北京"，数据里可能写"北京市"
自然语言和真实枚举值经常不一致。用户问"北京的 GDP"，字段值却可能是"北京市"。如果让模型通过多轮试探自己找值，虽然最终可能查到，但会付出额外的查询和模型调用。
团队为此加入字段值召回：离线阶段将高频维度值向量化，在线阶段根据问题检索最相关的真实值，再把结果交给模型。这个方案需要 Embedding 服务、向量存储和在线检索，却能减少无效探索，让模型更快写出正确过滤条件。
同一份数据，不同团队有不同口径
数据生产者理解字段背后的计算逻辑，数据消费者更关心业务问题。一个大型数据集可能服务多个团队，各自使用不同字段与口径。把几千个字段一次性塞给模型，既浪费上下文，也容易选错。
iDA 引入垂类智能体和语义层配置：同一数据集可以面向不同人群提供不同字段逻辑和业务知识。这里解决的已经不只是技术问题，而是数据生产与消费之间长期存在的知识断层。
BI平台与 数仓 场景里的三个"隐形坑"
抖音集团内部的BI平台允许在底表字段之上创建自定义表达式。若把复杂表达式全部交给模型，超长的 CASE WHEN 或 ID 列表可能耗尽上下文；若只给字段名，模型又可能写出 sum(count(distinct user_id)) 这样的聚合套聚合。iDA 选择不传完整表达式，而由工程层判断字段聚合状态，只把"能否二次聚合"这类必要信息告诉模型。
用户也很少真的从零开始分析。更常见的动作是基于已有图表改日期、粒度或筛选条件。iDA 会把图表配置反向解析成可读 SQL，让模型在原口径上改写，而不是重新猜测字段与过滤逻辑。
全量表和增量表则是另一个容易被忽略的风险。两者一旦混淆，查询结果可能膨胀多个数量级。团队在离线阶段结合历史查询模式、同步行数和上游元信息为数据集打标，再把表类型作为提示交给模型。
这些处理方式看似零散，实质上都遵循同一条边界：只把模型做判断所需的最小信息交给它，其余复杂度留在工程链路里消化。
今天的 iDA：从单点问数到完整分析
经过以上的考量，目前，iDA 的数据分析能力形成了三层结构：
暂时无法在飞书文档外展示此内容
模型层向 Agent 提供查询工具和精简上下文；执行层负责将 SQL 运行在DataWind（智能数据洞察）、Presto 或用户指定的计算队列上；数据接入层连接企业数据资产及 Hive、ClickHouse 等数据源，更多数据源支持正在推进中。
查询工具也围绕真实任务设计：既支持直接执行 SQL，也支持通过文件承载超长 SQL；大结果会保存为 CSV，方便后续用 Python 聚合分析；当用户只有图表权限而没有底层数据集权限时，系统还能按图表筛选条件读取结果。
这套设计带来的体验可以概括为三个变化：查询链路更短，原生兼容数据源与权限体系，模型拥有更多上下文空间完成探索和复杂分析。速度与准确性并不是只靠换一个更强模型获得的，它们来自整个链路的共同收敛。
下一站：从"找数"到"复用分析"
iDA 接下来有两个升级方向。
第一个是 "找查一体" 。找查一体已初步具备，下一步将继续提升知识与数据资产的找准率。业务口径可能散落在文档、图表配置和上游 SQL 中，用户提问里还包含大量内部简称。系统需要先找到正确的数据资产和业务定义，再执行查询。比"会写 SQL"更难的，是知道应该查什么。
第二个是数据分析全链路闭环。一次分析不应在回答结束后消失，而应沉淀为可复用的资产。团队希望将链路从"找数、查数、分析"继续延伸到"沉淀、复用"，相关能力仍在探索中。
这也意味着，专业数据分析助手的终点不是替人写 SQL。它需要理解业务语义，继承可信口径，完成多步探索，并把有效的方法留给下一次任务。
结语
从 ChatBI 到 iDA，团队做的并不是一条单纯的模型升级路线。DSL 与 SQL、子 Agent 与主 Agent、模型生成与工程改写，每一次取舍都在回答同一个问题：有限的模型注意力，究竟应该用在哪里？
iDA 给出的阶段性答案是，把语法适配、字段状态、枚举召回、权限和执行交给工程，把任务理解、归因探索和复杂分析留给模型。
当模型能力继续提升，今天的一些方案也许会被替换。但这条经验不会很快过时：专业 AI 产品的竞争力，不只取决于模型有多聪明，也取决于系统是否知道该让模型做什么，以及该替模型做好什么。 （文/抖音集团分析洞察工程与架构师 松岚）