天猫百亿补贴以协调者和专家Agent分析业务数据

天猫百亿补贴团队把百亿补贴场景的取数、波动归因、血缘溯源、Python 分析做成统一的自然语言入口。入口层 Intent Agent 用一次 LLM 调用（重活 qwen-plus、轻活 qwen-turbo）把提问解析成含 intent_type/confidence/metric_field/time_label/scope 的标准化意图参数包，LLM 调用失败时降级到关键词匹配+规则解析，并可输出 secondary_intents 处理多意图组合；调度层 Supervisor 做日期注入、语义计划与记忆召回后分发到 Query（取数专家）、Analysis（分析专家）、Ops（运维专家）、Other（兜底）四个专家 Agent——弃用单 Agent 是因为单个巨大 system prompt 与几十个工具会导致工具选择困难、prompt 膨胀与调用预算浪费。执行层采用 ReAct 循环，以“昨天 GMV 和前天比怎么样”为例，Agent 自主串联 search_metrics → rule_search（发现必须加 WHERE activity_type 的口径）→ build_sql → odps_query → python_analyze 五步后给出结论，并配 harness 刹车系统与 SQL Validator Gate 后置校验，确保语法正确、表名存在、字段合法。 团队认定这是整个系统最关键的技术选型。直接让 LLM 写 SQL 有三个致命问题：幻觉字段（编造不存在的列名）、口径错误（不知道某表必须带什么 WHERE，例如不知道 ads_bybt_flow_sum_di 表必须有 activity_type='百亿补贴'）、不可复用（每次从零生成）。因此引入 WrenAI 的 MDL 语义建模层：mdl.json 声明每张表的表名、字段、expression、关系与描述（如 gmv_amt 的 expression 为 pay_amt），并有 dry_plan（NL→SQL 预演）、recall（查询历史召回）与 fetch_context（给 LLM 补充表结构信息）三件套；Agent 生成 SQL 前先从 MDL 获取表结构，确保只用真实存在的字段，产出的 SQL 经语义层校验保证字段存在、口径正确且可复用。正文 5.4 另给出三种 SQL 构建模式，由 Agent 根据表类型自动选择。 知识按粒度与变更频率分六层：表能力清单 + MDL 语义模型、SQL 片段库（Snippet Store）、SQL 规则库（Rule Store）、血缘知识图谱（LightRAG KG）+ AST 实时解析、指标注册表（Metric Registry）、会话记忆（Session Memory），统一存于 TisPlus3 / mdl.json / LightRAG。Layer 4 的血缘来自基于 sqlglot 的六阶段静态分析管线（Schema Registry → 预处理（全角标准化/DDL 剥离/变量替换/多 INSERT 拆分）→ AST 标准化（展开 SELECT *）→ 节点提取（DFS 按 scope 提 CTE/子查询/UNION）→ 作用域解析（符号表 + alias 消歧）→ 血缘映射（direct/computed/aggregated 三类边）→ 输出 JSON），能处理复杂 ODPS SQL 语法，并内置覆盖 45 张真实表、296 个节点的回归测试框架保障准确性。运行时降级链为 lightrag_column_logic（KG 命中）→ dw_get_table_source + parse_sql_lineage（AST 实时解析）。采集层三条入口（AST 血缘解析、对话产出 SQL 自动暂存、指标接入向导 AI 生成）汇入待审核队列，人工在 Web 平台审核后入库复用，表结构变更会自动 regenerate。 数据分析场景涉及多次递归下钻查询，每次走 ODPS 执行 SQL 耗时 30-120 秒，Agent 完成一次诊断需执行 5-10 次 SQL，总耗时可能超过 10 分钟。团队引入 Hologres 外部表直读 ODPS，将单次查询加速到 3-10 秒。选外部表而非全量同步的理由是不需要 DBA 介入、新表 onboard 自动挂载、首次查询自动创建外部表、后续 LRU 缓存命中。链路实现为：LLM 生成 ODPS SQL → odps_query 工具先过场景闸门（HOLO_ROUTE_MODE 与 holo_scope 标记，仅对 stream_analysis 多步分析编排器生效）→ 变量替换 → 黑名单函数检测（GET_JSON_OBJECT/EXPLODE 等不兼容函数直接走 ODPS）→ sqlglot AST 抽取表名 → ensure_foreign_tables 按需 IMPORTFOREIGNSCHEMA 建外部表（进程内存 set + 持久化 JSON 幂等去重）→ sqlglot 转 PostgreSQL 方言并重写表名 → 经 aistudio HTTP 网关执行，失败则 Fallback 回原 ODPS 路径；并能在 Hologres 实例切库导致 relation does not exist 时自动清空缓存重建外部表重试，全程对 Agent 透明，最多多 3 秒。首次查某表多 1-3 秒建表开销，后续 LRU 命中零开销。 归因诊断的核心是拆解：把 GMV 的波动拆成访客数 × 转化率 × 客单价并逐层下钻找主因。团队没有让 LLM 自己猜、也没有把公式写死在代码里，而是建成声明式指标注册表：MetricDef 以 formula_type（multiplicative 乘法型 / 加法型 / 比率型）描述因子，每个因子用 column 直取或 numerator/denominator 比率定义，并绑定可拆解维度（dim_col 按 perspective 供给/渠道与 axis 业务/流量两个正交轴分类），还配 aliases（如 gmv_amt、交易额、成交额）做同义归一。乘法型有“因子相乘后约分必须恰好等于 total_col”的恒等式铁律以防拆错。指标接入由运营通过 Web 向导完成，AI 依据 MDL schema 自动推导公式类型与因子，并有 perspective/axis 混淆自动修正、Pydantic 逐条校验、注入 table_profile 辅助理解 ROLLUP/CUBE 等容错机制。运行时 formula_registry 把一个指标展开成多套候选公式，归因诊断引擎多路筛选最显著拆解后递归下钻，产出“GMV 环比 -20% → 转化率 -22% 为主因 → 家电行业 -45% 为 Top1 贡献 → 家电下单量 -40% 为主因”的诊断树报告。注：文中该组数值为演示样例数据。 评测从 6 个维度对每次回答打 0-100 分：D1 因子命中（严格 100/模糊 60/方向 30/不匹配 0）、D2 诊断树（深度+分支数+方向）、D3 工具调用（must_call 40 + must_not_call 25 + ordering 20 + step 15）、D4 结论质量（LLM-as-Judge 按意图 Rubric）、D5 SQL 正确性（语法+表名+字段名+WHERE+白名单）、D6 忠实度（规则检查 + LLM 幻觉检测）；并为每个意图配置差异化权重（归因分析不关心 SQL 正确性则 D5 权重为 0 显示为 --）。Golden Dataset 存放于 scripts/eval/datasets/default.json，当前覆盖 6 类意图、15 个用例，样例的 expected 除最终结论外还校验工具调用序列、诊断树结构与 Mustache 关键词，支持模糊匹配兜底（main_factor_fuzzy 部分命中得 60 分）与 Web 界面在线增删。执行时 harness.run_case 收集 SSE 事件流生成结构化 EvalTrace，加权总分低于 60 或任一维度为 0 的进入 badcases/ 归档，并从 7 个关键节点状态做根因归因（如 gate - validation_exhausted 重试 3 次未通过、tool_call - 工具返回错误）。