菜单
积墨AI

积墨AI

自然语言驱动的全流程数据分析:多智能体协同架构实战

背景与痛点

在数据驱动决策的日常工作中,业务团队面临一个普遍困境:取数需求排队等待、数据口径不统一、波动归因依赖人工经验、知识经验难以沉淀复用。传统的数据分析模式存在四大核心痛点:

  • 取数慢:业务人员提出取数需求后,需要等待数据工程师编写SQL,通常需要数小时甚至数天
  • 口径乱:同一指标在不同报表中定义不一致,导致数据对不上,排查成本高昂
  • 归因难:当关键指标出现波动时,需要人工层层下钻分析,效率低且依赖个人经验
  • 知识散:分析师的经验和结论散落在个人笔记或即时通讯工具中,无法形成组织资产

本文将深入解析一款面向电商补贴场景的数据分析智能体系统,探讨其如何通过多智能体协同架构,实现从自然语言提问到完整数据分析报告的全流程自动化。

系统能力概述

该数据分析智能体的核心目标是实现“你问它答”的智能化数据服务。用户用自然语言提问,系统自主完成从找表、编写SQL、执行查询到深度分析的全流程。具体而言:

基础取数场景:当用户询问“昨天GMV多少?”时,系统自动完成找表→生成SQL→执行→返回结果的完整链路。

归因分析场景:当用户询问“GMV为什么跌了?”时,系统自动进行波动归因,逐层下钻分析,最终输出因果链报告。

血缘溯源场景:当用户询问“这个指标怎么计算的?”时,系统追溯上游字段,揭示完整的计算逻辑和数据依赖关系。

高级分析场景:当用户提出“各行业GMV做帕累托”等复杂分析需求时,系统调用Python分析沙箱完成取数→图表生成的完整流程。

技术架构设计

整体架构分层

系统的技术架构采用分层设计,从上到下依次为:

意图识别层:作为系统的“大脑前哨”,在Agent执行前首先解析用户提问。通过单次LLM调用,同时完成意图分类、时间解析、指标识别和维度推断,最终输出标准化的JSON参数包。

调度路由层:Supervisor根据意图识别结果,结合日期注入、语义计划和记忆召回,将问题分发到对应的专家Agent。系统设计了四类专家Agent:取数专家、分析专家、运维专家和兜底处理。

保障层:SQL Validator Gate对所有生成的SQL进行后置校验,确保语法正确、表名存在、字段合法。同时包含答案净化和SQL自动暂存机制。

知识底座:作为整个系统的数据基础,包含MDL语义层、SQL片段库、规则库、血缘图谱和会话记忆五个核心组件。

多智能体协同设计

系统采用多Agent协同架构,而非单Agent模式。这是因为单Agent模式存在明显缺陷:一个巨大的system prompt需要包含几十个工具定义,导致工具选择困难、prompt膨胀、调用预算浪费。

多Agent协同让每个专家只看自己相关的工具和指令,选择更精准。例如,取数专家Agent专注于表结构检索、SQL片段匹配、规则查询等工具;分析专家Agent专注于归因诊断、Python分析等能力。

ReAct推理循环

Agent执行任务时采用ReAct(Reasoning + Acting)推理循环,而非简单的固定流程。以“昨天GMV和前天比怎么样?”为例:

第一轮推理:Agent思考需要先找到GMV所在的表,调用search_metrics工具定位到ads_flow_sum_di表。

第二轮推理:Agent知道表信息后,调用rule_search确认口径规则,发现必须添加WHERE条件。

第三轮推理:Agent根据表信息和规则,调用SQL构建工具生成查询SQL。

第四轮推理:Agent执行SQL,获取昨天和前天的GMV数据。

第五轮推理:Agent意识到用户关心环比变化,调用Python分析计算环比并生成结论。

ReAct循环让Agent自主决定调用什么工具、传什么参数、什么时候收敛,这是系统能够处理复杂场景的关键。

NL2MDL2SQL语义层

为什么不直接用Text-to-SQL

直接让LLM生成SQL存在三个致命问题:

幻觉字段:LLM可能编造不存在的列名,导致SQL执行失败。

口径错误:LLM不知道某表必须添加特定的WHERE条件,例如activity_type=‘百亿补贴’,导致数据口径不一致。

不可复用:每次从零生成,没有沉淀,相同问题可能得到不同结果。

WrenAI语义层的引入

WrenAI引入了MDL(Model Definition Language)——类似dbt的语义建模层。MDL定义了每个表的结构化语义信息,包括表名、字段名、字段类型、计算逻辑、描述说明等。

用户提问后,系统先将自然语言转换为MDL语义查询,再由语义层生成最终SQL。这个过程确保:

字段存在性:生成的SQL使用的字段必须存在于MDL定义中。

口径正确性:语义层内置了表级别的规则约束,确保SQL包含必要的过滤条件。

结果可复用:相同语义查询总是生成相同结果的SQL。

SQL构建策略

系统根据表类型自动选择SQL构建策略:

A类预聚合表:直接应用MDL定义和规则,快速生成查询。

B类普通明细表:需要更复杂的规则匹配和上下文推断,生成定制化SQL。

Hologres查询加速

数据分析场景涉及多次递归下钻查询,每次走ODPS执行SQL耗时30-120秒。当Agent需要执行5-10次SQL才能完成一次诊断时,总耗时可能超过10分钟,用户体验严重下降。

系统引入Hologres外部表直读ODPS,将单次查询加速到3-10秒。技术实现上:

按需创建外部表:系统不预先生成所有表的外部表(成本高),而是根据SQL中实际使用的表,按需动态创建。首次查询某表增加1-3秒建表开销,后续查询通过LRU缓存命中实现零开销。

场景闸门控制:Hologres加速仅对复杂分析场景生效,普通NL2SQL查询和运维查询仍然走原ODPS链路。

自动故障恢复:当Hologres实例切库导致外部表丢失时,系统自动检测错误,清空缓存后重新创建外部表并重试,对Agent完全透明。

六层知识体系

知识是智能体的“记忆”。系统构建了六层知识存储体系,从不同粒度和维度管理数据知识:

第一层:表能力清单与MDL语义模型。定义每张表的结构、字段、业务含义,是知识体系的顶层基础。

第二层:SQL片段库。存储常见查询的SQL模板,支持快速复用。

第三层:SQL规则库。记录每张表的编写规则,例如必须添加的WHERE条件、过滤逻辑等。

第四层:血缘知识图谱。基于ETL源代码自动解析字段级血缘关系,支持血缘溯源查询。

第五层:指标注册表。定义每个业务指标的拆解公式,是波动归因的核心知识源。

第六层:会话记忆。管理当前对话上下文,支持多轮交互的连贯性。

AST血缘解析引擎

血缘知识的数据来源于AST血缘解析引擎——一套基于sqlglot的SQL静态分析管线。引擎从ETL源代码中自动提取字段级血缘关系,采用六阶段解析管线:

预处理阶段:全角标准化、DDL剥离、变量替换、多INSERT拆分。

AST标准化阶段:sqlglot解析SQL,将SELECT *展开为显式列列表。

节点提取阶段:DFS遍历AST,按scope提取CTE、子查询、UNION分支。

作用域解析阶段:符号表消歧,拓扑序逐层解析裸列名。

血缘映射阶段:生成直接传递、表达式引用、聚合函数三类血缘边。

输出构建阶段:生成标准化JSON,包含目标表、源表、字段依赖、JOIN条件、WHERE条件。

指标注册体系

指标注册表是波动归因诊断的核心知识源。每个指标定义了三种拆解公式类型:

乘法公式:定义指标的因子拆解关系。例如GMV = 曝光UV × 转化率 × 客单价。

加法公式:定义指标的维度拆解关系。例如GMV = Σ(各行业GMV)。

比率公式:定义指标的比率关系。例如GMV/总流量。

系统还支持AI辅助接入,运营同学通过Web向导即可接入新指标,AI根据表结构自动推导公式类型和因子。

深度分析能力

波动归因诊断

当用户询问“昨天GMV为什么跌了20%”时,系统自动构建诊断树。诊断过程采用五步法:

第一步:漏斗拆解,将GMV分解为访客数、转化率、客单价三个因子。

第二步:因子定位,确定转化率是环比下降22%的主因。

第三步:行业下钻,将转化率按行业维度拆分,发现家电行业转化率下降45%是Top1贡献。

第四步:因子再拆,对家电行业的转化率继续下钻,发现下单量下降40%是主因。

第五步:生成结论,输出完整的归因诊断报告。

血缘溯源

当用户询问“GMV这个字段是怎么计算的”时,系统通过两条路径形成降级链:

KG优先路径:直接查询知识图谱,获取字段映射和WHERE条件。

AST降级路径:当KG未命中时,实时解析ETL源代码,提取血缘关系。

Python分析沙箱

当查询结果需要二次加工时(帕累托分析、排名、环比计算等),Agent调用Python分析沙箱执行用户生成的分析代码。沙箱提供隔离的安全环境,支持pandas数据处理和可视化输出。

安全保障机制

SQL后置校验

所有Agent生成的SQL都经过SQL Validator Gate校验,确保语法正确、表名存在、字段合法。校验不通过的SQL自动进入重试流程,最多重试3次。

运行时安全守卫

Agent运行时配备了“安全带”机制,防止无限循环调用、异常工具调用等风险场景。系统记录完整的工具调用序列,支持事后审计和问题排查。

新表接入流程

新表接入采用自动化五步流水线:表结构同步→表类型探查→规则抽取→SQL模板生成→知识入库。整个过程支持Web界面操作和CLI脚本两种方式。

评测体系

系统建立了完整的评测体系,采用6D评分维度:

  • D1因子命中:归因结果是否命中正确的拆解因子
  • D2诊断树深度:归因树的结构是否符合预期
  • D3工具调用:Agent是否调用了正确的工具序列
  • D4结论质量:最终回答的语义质量
  • D5 SQL正确性:生成的SQL是否语法和逻辑正确
  • D6事实一致性:回答是否与数据一致,无幻觉

不同意图类型配置了差异化权重——归因分析不关心SQL正确性,取数不关心因子命中,使评测结果更加客观准确。

总结

本文深入解析了一款面向电商场景的数据分析智能体系统。其核心技术创新包括:

多Agent协同架构:通过意图识别、调度路由和专家Agent分工,突破单Agent模式的局限性,实现精准的工具调用和高效的推理决策。

NL2MDL2SQL语义层:引入WrenAI模型定义语言,通过语义建模层统一数据口径,消除LLM幻觉,确保SQL生成的准确性和一致性。

六层知识体系:构建从表结构到会话记忆的完整知识分层,配合AST血缘解析引擎和指标注册体系,为智能体提供丰富的领域知识支撑。

Hologres查询加速:通过外部表按需创建和LRU缓存机制,将复杂分析查询从分钟级缩短到秒级,显著提升用户体验。

该系统展示了大模型在数据分析领域的深度应用潜力,为企业构建智能化数据分析平台提供了可参考的技术路径和架构范式。

#多Agent协同#NL2MDL2SQL#ReAct推理循环#WrenAI语义层#Hologres加速查询#六层知识体系
分享文章

相关文章推荐

试用咨询
企业微信二维码

扫码添加企业微信