当前位置: 首页 > news >正文

破局与进化:火山引擎Data Agent从落地实践到架构未来

本文为火山引擎技术专家陈硕,在AICon全球人工智能与机器学习技术大会上的演讲分享。本文围绕以下五部分展开:
  • Data Agent整体介绍
  • 智能分析Agent产品演进
  • 智能分析Agent技术架构演进
  • 智能分析Agent落地新进展
  • Data Agent未来架构展望
 
大家好,很荣幸能参加这次分享,跟大家聊一聊我们在火山引擎Data Agent-智能分析Agent方向的一些落地实践和踩坑经验。让我们直接进入主题。
 
我想从一个“四象限”框架开始谈起。
 
自ChatGPT支持上传Excel文件以来,许多数据从业者就开始思考:能否利用Agent或大模型来替代传统的数据分析工作?这个四象限划分了不同的技术路径:第一象限是纯大模型(Bare Metal),直接调用API生成文本;第四象限代表传统数据产品,如BI工具和归因分析系统;第二象限则是通用Agent,例如Deep Research这类能撰写报告、进行调研的产品。
 
然而,通用Agent在处理数据分析任务时往往力不从心。一个典型的例子是SQL代码生成:如果没有经过精心设计,其生成正确代码的成功率可能像“抽卡”一样随机,十次尝试中或许只有两三次能写对。更关键的问题在于企业知识的融合——公司的指标平台是一个复杂的系统工程,通用Agent难以理解和接入这种专业的数据知识体系。
 
正因如此,Data Agent的价值得以凸显。它需要既能无缝对接企业的知识基座,又能在数据领域通过精细化的流程设计和工具链优化,切实提升业务适用性和数据结果的准确性。
 
那么,什么是数据分析Agent?
 
简而言之,数据分析Agent第一代可以理解为“Chat BI”,即聊天式的商业智能交互;第二代则更接近通用Agent在数据领域的深度应用,能够执行端到端的自动化分析任务。在火山引擎,我们构建了完整的产品体系来支持这些能力,包括Chat BI数据洞察报告、开放的数据分析Agent接口,以及自动生成仪表盘等功能。
 
这套产品的能力是分层构建的。
 
最底层负责适配各种模型底座,如火山引擎内部系统或兼容OpenAI协议的外部模型;向上是数据能力底座,解决企业最核心的数据连接、权限管控等基础问题;再上一层是配置管理层,致力于将散乱的数据命名和描述进行语义化处理,并结合业务知识库和知识图谱,使模型能够真正理解企业的数据内涵;最顶层则是面向用户的数据消费产品,例如支持多轮追问的Chat BI界面,以及今年新推出的深度研究模式。
 
这些能力不仅可以通过原生的用户界面使用,也能通过开放的API集成到企业的OA系统或工作流平台中。
 
谈到产品演进,一个关键概念是“Product Model Fit”——产品形态必须与模型能力相匹配。在Pre-LM(前大模型)时代,人们尝试用BERT等小模型做Text-to-SQL,效果如同玩具,难以实际落地;进入前大模型时代后,BI产品开始加入归因预测等增强分析功能,但对用户要求过高,普通人难以驾驭。直到2023年底ChatGPT 3.5的出现,催生了一批Chat BI产品,但其应用场景仍显局限,灵活性不足。
 
 
真正的转折点出现在2024年。O3推理模型的出现,让Deep Research这类产品展现出令人惊艳的能力,它让我第一次感受到AI在数据分析领域接近L3/L4级自动驾驶的智能水平。今年之所以被称为“Agent元年”,正是因为模型能力终于能够支撑开放式的Agent设计理念。
 
我们的第一代产品“智能问数”就是在ChatGPT 3.5时期诞生的。在设计时,我们特别关注了数据分析师的实际工作流程:他们使用仪表盘等工具时,并非直接创建仪表盘,而是先灵活地查询数据、寻找洞察,再将有价值的结论固化为报表。因此,我们的产品让用户先通过主动提问进行灵活分析,接着系统自动进行归因和下钻以发现关键维度,最后用户可以将有价值的问题收藏并自动生成日报或周报。这看似是一个简单的聊天机器人(Chatbot),实则完整还原了从临时性洞察到例行化监控的业务闭环。
 
 
当然,任何产品都有其局限性。Chat BI能否真正发挥作用?关键在于找到合适的应用场景。它可能无法完全替代专业分析师的全套工具链,但对于一线业务人员来说却非常适用。例如,我们为抖音地推团队部署后,八千多名成员可以随时在移动端查询数据,其灵活性远超传统BI工具。这引出了一个核心矛盾:产品开发不能一味追求技术先进性,更要解决“Product Market Fit”(产品市场契合度)——即明确谁需要这个产品,在什么场景下使用?这才是决定产品能否成功落地的关键。
 
引入新产品后,关键在于找准它能替代哪些现有场景。例如,Chat BI能否替代传统BI系统?对于熟练的数据分析师而言可能不行,他们已精通现有工具。但在我们火山引擎落地的案例中,像抖音地推团队这样的一线人员,规模达八千人且常年在户外奔波,传统BI根本无法在移动端灵活支持他们实时查询数据、服务客户。恰恰是这种移动端、临时性的查询场景,成为了Chat BI大放异彩的舞台。
 
这涉及到三种替代逻辑:产品替代要看目标用户,场景替代要看任务复杂度。例如,分析师需要同时计算同环比、占比并进行归因分析,当前Chat BI的架构尚难以支撑如此复杂的任务;技能替代则要看用户角色,决策层和一线员工可能是最合适的受益者。归根结底,Chat BI并非万能钥匙,无法通吃所有场景,找准其“Product Market Fit”(PMF)的突破口至关重要。
 
因此,我们在2025年推出了“深度分析模式”,它更接近通用Agent的形态:用户只需提出一个开放性问题,系统便能自动生成分析计划、拆解子任务、执行到底,最终输出Markdown报告或网页。
 
 
虽然看起来能处理更开放的问题,但也带来了新的挑战,其中“领域知识”是首要障碍。人类语言本身存在局限性,例如广告行业的“消耗”一词,外行人可能完全不解其意。为此,我们构建了结构化知识库来解决专业术语问题。
 
此外,分析框架也需要专门沉淀,因为在拆解开放性问题时,模型的理解可能与企业惯用的分析逻辑存在偏差;还有领域常识,例如电商行业的“黑话”往往散落在飞书文档中,我们通过对接企业知识库,挖掘出这些“冰山下的知识”。
 
数据准确性更是硬性要求。Chat BI偶尔算错一个数字或许尚可容忍,但当深度分析报告涉及二十个数据点时,即使每个点有99%的准确率,其整体准确率经过连乘也会骤降至82%。更不用说用户提问本身可能模糊不清,结果也难以校验。
 
 
我们引入了反问澄清机制和自动化校验手段,如同给Agent配备了一位“质检员”,逐步将准确度打磨提升。带着这些思考,接下来我们探讨技术架构如何支撑这些需求。
 
在技术架构层面,Data Agent的整体框架与我们之前提到的产品能力矩阵是匹配的:最底层处理模型集成、数据接入、智能配置等基础工作;向上则通过Open API、MCP(模型控制平面)甚至谷歌的A to A协议,使企业能够灵活地将Agent能力嵌入其自有系统中。
 
 
这里需要重点介绍“智能问数”架构的演进。1.0版本大家可能比较熟悉:用户提问后,系统首先进行Schema Linking(理解问题并定位相关数据),接着通过语义粗排和精排选择数据集,再结合知识库和Prompt生成代码,最后将代码转换成不同引擎可执行的语句并可视化结果。这套流程在学术论文中常见,但在实际应用中发现泛化能力不足。事实证明,在模型能力提升之后,过于清晰的流程反而会显得僵化。
 
 
因此我们升级到2.0版本:将原先固定的模块拆解为工具包,例如数据集选择工具、图表洞察工具、SQL/Python沙箱等。用户问题输入后,系统动态规划执行流程,像搭积木一样按需调用工具。这更接近真正的Agent理念,模型能够理解上下文,并能采用类似React架构的思路进行自我优化,提升输出质量。简而言之,架构从“流水线”进化为了“智能调度站”。
 
深度分析模式的架构在短短半年内就迭代了三次。今年5月在北京分享的版本是“Plan-and-Execute”模式:先由Coordinator生成计划,再分派给Worker工具执行。听起来合理,但实际运行中暴露了问题:第一个工具生成的SQL筛选条件,在传递给第二个工具时可能丢失。上下文传递如同掉入黑洞,第一步设定的全局规则在后续执行中可能被忽略。这种架构在需要动态调整时尤其吃力,一旦计划生成便难以中途优化。
 
另一个棘手的问题是动态调整能力。之前的架构一旦生成计划就僵化执行,中途优化困难重重。因此,我们从“Plan-and-Execute”升级到“One Agent”模式。但在落地时发现,用户需求存在显著差异:开放性问题需要启发式思路,而日报周报等模板化任务更看重稳定性。新架构对这两类需求进行了分流处理,同时优化了工具设计,确保模型在编写SQL等操作时能记住上下文规则,即使经过二十步操作也不会丢失关键信息。
 
 
架构升级后,数据准确性确实得到了提升,但客户的需求不止于此,他们希望报告能提供有价值的业务洞察。我们发现“One Agent”在“举一反三”、结合业务场景提出建议方面仍有不足。
 
 
于是我们更进一步:拆分出专门负责数据探查的Agent和专注于数据洞察的Agent,各司其职;配备了上下文引擎来管理记忆;并重新设计了Agent Workspace,本质上是为模型打造一个更趁手的“工作台”,让它能够以更自然的方式调用工具。这就是我们当前3.0架构的核心思想。
 
 
谈到落地效果,在电商场景中,一线运营人员使用Chat BI进行数据查询和归因分析,能够将高频问题沉淀为自动化报告;另一个智能投顾案例中,Agent生成的营销活动报告直接提升了投资顾问的工作效率。
 
最后,分享两点核心思考:
 
首先,错误会指数级放大。单步99%的准确率,在二十步操作后可能骤降至82%。架构设计必须直面这一数学规律,通过冗余校验、多重验证等手段与之对抗。
 
其次,团队需要并行实验。过去半年我们架构迭代三次,正是依靠多线并行的验证策略。如果死磕单一方案,一旦模型能力升级,原有方案很容易掉队。搞Data Agent开发,敏捷比完美更重要。
 
我的分享就到这里,谢谢大家!
http://www.hskmm.com/?act=detail&tid=17168

相关文章:

  • 五项能力斩获满分!天翼云云WAF获IDC权威认可!
  • 什么样的代码可以称得上是好代码? - 浪矢
  • 微软Teams Channel Agent上线:中国卖家AI赋能品牌出海新机遇与实战策略(2025前瞻) - 详解
  • docker制作
  • lvgl 9.3 style使用导致内存泄漏问题
  • 【AI领域】如何写好Prompt提示词:从新手到进阶的完整指南 - 详解
  • 11_Reactor网络模型
  • 「LNOI2022」盒
  • 【文摘随笔】从业开发工作五年后,再读短篇《孔乙己》——年少不懂孔乙己,长大已成孔乙己
  • 为什么我选择了 PSM 敏捷认证?
  • 外键
  • 菜油
  • 索引
  • 存储过程
  • 编写msyql8.0.21 数据库批量备份脚本
  • 完整教程:基础算法---【差分】
  • Android 源码中如何生成一个platform JKS 文件?
  • WPF小知识
  • 后端面试八股(go 方向)
  • ArcGIS 不重叠且无缝的拓扑检查和修改
  • 2025/9/25
  • 读书笔记:揭开索引的两个常见误区
  • 国标GB28181平台EasyGBS如何赋能路网数字化管理与应急指挥?
  • 获取用户ip所在城市
  • 【Proteus仿真】AT89C51单片机串行数据转换为并行仿真 - 实践
  • 第13章 day14-15 Webpack逆向
  • Viper远程配置踩坑记录
  • 国产智能体脂秤PCBA方案设计
  • 第15章 day18 Ast系列篇
  • 微波雷达模块在智能家居中的具体应用案例有哪些?