增长 Data Agent 产品设计

WITH monthly AS (
  SELECT
    DATE_TRUNC('month', order_date)  AS 月份,
    SUM(revenue_usd)                 AS 销售额,   -- revenue_usd 口径为退款后净额
    COUNT(order_id)                  AS 订单量,
    ROUND(AVG(revenue_usd), 0)       AS 客单价
  FROM   orders
  WHERE  region           = 'North America'
    AND  product_category = '升降桌'
    AND  order_date BETWEEN '2024-01-01' AND '2025-12-31'   -- 多取一年，供同比回看
  GROUP  BY 1
)
SELECT
  月份, 销售额, 订单量, 客单价,
  ROUND(
    ( 销售额 - LAG(销售额, 12) OVER (ORDER BY 月份) )
    / LAG(销售额, 12) OVER (ORDER BY 月份) * 100
  , 1)                               AS 同比增长
FROM   monthly
WHERE  月份 >= DATE '2025-01-01'                              -- 仅输出 2025
ORDER  BY 月份;

该能力规划中，详见第六章路线图 …

该能力规划中，详见第六章路线图 …

该能力规划中，详见第六章路线图 …

2.5 编排层：Workflow 与 Agent 的边界

这是工程上最关键的决策点。两者融合使用，判断标准是"问题路径是否可预定义"：

原则：能用 Workflow 解决的，绝不交给 Agent。 Workflow 路径确定，更容易造验算器；Agent 是兜底，承接 Workflow 覆盖不到的长尾。

Meta：Inside Meta's Home-Grown AI Analytics Agent

Meta 的 Analytics Agent 是一个从内部需求出发、完全自研的数据分析智能体，最终成为全公司最高频使用的内部工具之一。

Analytics Agent 是如何工作的

核心设计哲学：利用上下文丰富用户提示词（数据发现 + 背景收集），再提供正确的推理逻辑（迭代推理循环）。答案呈现时，把透明度作为信任的基石。

Step 1 — 发现数据与收集上下文

用户的问题往往是模糊的，数据则极其复杂（成百上千张表、互相嵌套的指标定义）。Analytics Agent 的第一步不是直接生成 SQL，而是先把问题说清楚：

• 语义搜索数据目录，自动找到相关表和指标
• 拉取该领域的 Cookbook，了解这个业务域的惯用分析套路
• 查找匹配的 Recipe，看有没有现成的分析 SOP 可复用
• 解析 Ingredient 中的字段口径（如"l7_active = 近 7 天活跃且排除流失账号"）

Step 2 — 迭代推理循环

生成计划 → 执行（SQL / Python）→ 验证结果 → 发现问题 → 修正 → 再执行

每一步执行结果都会反馈给下一步用于校正，agent 能在循环中自我纠错。遇到数据异常、逻辑矛盾或结果超出常识范围时，会主动触发澄清追问或重试。

Step 3 — 全透明原则（非确定性 LLM 的最务实解法）

"在分析场景里，一个被自信地给出的错误数字，比没有数字更糟糕。"

每一个呈现给用户的数据点，背后生成它的 SQL 都被放在最显眼的位置。用户随时可以核对口径，把验算的能力部分还给用户。

三层知识系统：Cookbook / Recipe / Ingredient

知识由专家录入一次，所有对话复用。这比单纯堆 RAG 文档更有结构，更重要的是：它让业务方从使用者变成共建者。

核心启示与落地数据

Meta 在正式立项前，先分析了一批历史业务问题，发现其中 88% 的分析类问题在上下文充分的情况下 LLM 能稳定回答。这个数字是项目成立的硬依据——证明了问题是"有界的"。

1. 速度优于完美："最大的风险不是发得太早，而是发得太晚"
2. 把早期用户当共建者，而非小白鼠：让用户能录入 Recipe / Ingredient，贡献知识资产
3. Sanity Check 是性价比最高的自动验算器：如"WAU 不可能 > 80 亿""环比波动 > 500% 需复核"

原文：Inside Meta's Home-Grown AI Analytics Agent — Medium ↗

4.2 智能数据查询：数据目录与元数据管理

建立数据目录和元数据管理系统，对数仓统一梳理标注。这是智能选表与 Text2SQL 准确率的地基，涵盖：

1. 数仓概述：分层架构、数据来源、表的种类、业务场景等高层描述。
2. 表的详细说明：每张表的功能及在数据产品中的应用场景。
3. 表的选择逻辑：明确适用范围与不适用场景，避免误用导致分析偏差。
4. 字段详情：字段类型、是维度还是指标、含义、取值范围；维度字段标注关联维度表。
   • 衍生指标：解释计算逻辑与业务含义（如"新客户 = 统计期内首次下单的客户"）。
5. 字段唯一性保障：梳理跨表同名/同义字段，明确语义一致性，特殊情况详细标注。
6. SQL 限制条件：列出查询限制，如敏感字段访问限制、特定业务逻辑下的检索约束，确保合规与准确。

如何把目录"喂"得更准

仅靠人工标注的静态目录会很快过时、覆盖不全。第三章 OpenAI 的六层上下文给了参考方法——靠多层信号自动组装，而非全靠人写。

真正的工程难点在"上下文组装"这层基础设施，而非 agent 架构本身——OpenAI 的 agent 架构其实很"朴素"（单 LLM + 运行时 + 上下文组装 + 精简工具集），强大的能力来自统一扎实的数据底座。

为什么不直接用 Markdown？ 表少、业务知识较少时完全可以用 Markdown 静态注入，类似索引文件的方式构建知识库，简单有效。随着数据源扩展、表数量增多，全量注入成本急剧上升，且"客单价"→ avg_revenue_usd 这类语义映射靠关键词匹配会直接 miss。Embedding 动态召回只把语义最相关的少量表元数据送给 LLM，精准、省 token、降噪。

5.2 取数评估：三层验算器

1. 语法层：SQL 静态语法审查（可自动，零成本）。
2. 执行层：在沙箱/受限库实际执行，验证可跑通、无超时（可自动）。
3. 结果正确性层：维护 golden dataset（业务专家标注的「问题→正确 SQL/结果」对），新生成结果与之比对。
   • golden dataset 的建设是一项持续工程：从线上真实问题中采样、由业务专家标注、纳入回归测试，每次模型/prompt 迭代跑一遍，防止"改好一个、改坏三个"。

加一层"业务常识校验"（借鉴 Meta）。 在结果呈现给用户前，用独立的规则/AI 做体检，例如"WAU 不可能 > 80 亿""环比波动 > 500% 需复核"。这类轻量 sanity check 成本极低，却能拦住大量离谱结果，是自动验算器里性价比最高的一层。

5.3 分析评估：如何评"洞察质量"这种主观的东西

这是最难的部分（缺乏标准答案），采用三管齐下：

1. LLM-as-judge：用更强模型按预设 rubric（逻辑是否自洽、是否引用了正确数据、结论是否回答了问题）打分，规模化、低成本，但需先与人工标注校准一致性。
2. 人工专家标注：抽样由数科/数分同事评估洞察的正确性与有用性，作为 LLM-judge 的"金标准"与校准锚点。
3. 业务采纳率（线上）：用户是否采纳了这条洞察、是否基于它做了决策——这是最诚实的评估信号。

5.4 在线评估与反馈闭环

把线上每一次交互变成"人造验算信号"：

• 显式反馈：👍/👎、"这个口径不对"等；
• 隐式反馈：用户是否追问、是否复制 SQL、是否导出报告；
• 闭环：反馈 → 归因（是意图识别错？选表错？SQL 错？）→ 沉淀进 golden 集 / 优化 prompt / 补充数据目录 → 回归验证。

这正是开篇第一性原理那个缺失闭环的最终落地：我们用评估体系 + 反馈闭环，为 data agent 人工补上了 coding agent 天生就有的验算器。

5.5 发布门禁与版本管理（借鉴 OpenAI）

把评估固化进发布流程，而非靠人主观经验：

• 测试集覆盖三类风险：correctness（对错）、bias（口径/样本偏差）、leakage（越权/数据泄露）；
• 回归门禁：每次模型或 prompt 变更，必须跑通测试集才能发布；
• 版本化与血缘快照：模型版本、指标定义、数据血缘都打快照，出问题可追溯、可回滚。