从分析模式到确定性查询：Meta 如何构建 AI-native Analytics

很多团队第一次把自然语言接入数据分析时，都会从“让模型写 SQL”开始。问题在于，SQL 能执行并不代表指标口径正确：同一个留存、漏斗或增长问题，可能因为数据源、时间窗口、过滤条件和维度选择不同而得到不同答案。

Meta 的一篇工程文章描述了另一条路径：先找出反复出现的分析模式，把它们封装成参数化、受治理的分析库；每条管道同时产出可供 Agent 读取的数据模型；查询阶段由 Agent 选择结构化输入，再由确定性工具按规则选择数据源并生成 SQL。后续的分析配方和仪表盘可以继续复用这套模型与查询接口。

从文章描述的组件关系看，它讨论的不只是一个 SQL 生成器，而是如何让人和 Agent 共用一组稳定的测量原语，并让管道、查询和分析消费沿着同一套模型衔接。

一、分析需求往往是少数模式的重复组合

Meta 作者首先描述了一个常见问题：团队不断重新实现指标、留存计算、实验表、增长核算和漏斗等测量原语。随着产品发布和测量组合增加，数仓中会出现大量近似重复的管道，口径不一致的速度可能超过团队把数据转化为洞察的速度。

文章把这种现象概括为“测量中的幂律”：少数分析模式覆盖产品团队的大部分需求。Meta 因此将常见测量原语归纳为七个核心模式。原文随后用图片展示具体目录，但正文没有逐项说明这些模式的完整定义，本文也不把图片内容扩展为一份确定的模式清单。

这里的关键不是七这个数字，而是一个设计判断：如果同一类分析问题反复出现，就不必让每个分析师或 Agent 从空白 SQL 开始。可以把重复部分提炼成可复用的测量接口，把差异收敛到有限的参数中。

二、Analytics Libraries：把分析逻辑变成参数化资产

Meta 对 Analytics Libraries 的定义，是为每个经典分析模式提供可复用、参数化、受治理的实现。分析师不再为留存或漏斗重新编写完整 SQL，而是声明活动事件、时间窗口和关键维度等需求，由库生成底层 SQL 和管道任务。

这种方式有三个变化。

第一，分析请求从自由文本或自由 SQL 变成结构化输入。第二，容易写错的测量逻辑只需要在库中实现和审查一次。第三，管道和数据模型可以由同一份声明生成，避免“计算逻辑是一套、文档又是另一套”。

作者以 Metric Materialization 为例：指标不再散落在不同团队的 SQL 片段里，而是成为使用统一逻辑生产的受治理资产。文章称该库支持超过 3,250 条生产管道，完整 Analytics Libraries 目录支持超过 9,000 条管道。这个数字是作者对 Meta 内部规模的披露，本文不把它当作其他组织可以直接复制的 benchmark；原文没有提供计算口径、对照组或独立验证材料。

从工程角度看，Analytics Libraries 的价值不只是减少 SQL 重复，更在于把指标定义、管道生成和治理责任放到同一个可复用边界内。库维护团队承担的是一次性的逻辑建设和持续维护，使用团队则通过参数配置获得稳定的生产资产。

三、Agent-readable model：让管道产物成为可查询契约

如果分析库只生成物化表，Agent 仍然需要猜测每个字段的含义、指标口径和数据来源。Meta 的做法是：每条管道除了产出物化表，还产出一个 YML 数据模型，用强类型结构描述维度、指标和数据源。

这个模型在架构上承担了两个作用：

• 对人：提供可以被目录注册、发现和治理的分析资产说明。
• 对 Agent：提供选择指标、维度和数据源时可以依赖的结构化接口。

因此，数据模型不是附在表旁边的说明文档，而是连接生产与消费的契约。它告诉查询工具哪些输入是合法的、某个指标如何被识别，以及不同字段之间可以如何组合。原文没有给出完整 YML schema，因此本文只讨论其职责，不补写具体字段规范。

这也解释了为什么标准化输出能够支持仪表盘、分析配方和指标问答：这些消费场景不必各自重新理解一堆无文档的表，而是共享同一套可发现、可描述的模型。

四、确定性查询：Agent 选择结构化输入，工具生成 SQL

文章把“信任”称为分析型 AI 最难的问题之一。语言模型可能生成一段看起来合理、能够执行，却实际返回错误数字的 SQL。Meta 的应对方式不是继续堆叠提示词，而是把 SQL 生成暴露为一个确定性命令行工具。

按文章的描述，链路可概括为：

1. Agent 理解分析问题，并为查询生成器选择结构化输入。
2. 查询生成器结合数据模型和预设规则选择数据源。
3. 工具生成 SQL，Agent 不直接自由编写查询语句。
4. 查询结果交给后续分析配方或仪表盘消费。

图中展示的是文章描述的逻辑链路，不是 Meta 内部部署拓扑，也不表示所有环节都由一个 Agent 单独完成。

Meta 还描述了数据源选择逻辑。同一个指标可能同时存在于 cube table 和 fact table 等多个来源，工具会根据表的保留期、分区行数和存储层等条件优先选择数据源。将这些选择规则集中在生成器中，可以减少每次由模型重新解释数据源优先级的需要；其维护、测试和审计方式则取决于具体实现，原文没有展开。

知识库中已有的“确定性执行外壳”概念可以帮助理解这一结构：让 LLM 保留意图理解和参数选择，把 SQL、格式、状态和规则执行交给代码。不过，这只是本文的分析类比，Meta 原文并没有使用“确定性执行外壳”这个术语。

同时也要保留边界。确定性 SQL 生成主要解决分析口径和查询生成问题，它并不自动解决数据访问权限、行动授权、事务一致性或生产系统写回安全。一个查询工具是可靠的，不代表它已经成为完整的企业语义层或权限系统。

五、从查询到洞察：分析配方与自助仪表盘

查询得到数字之后，用户通常还会继续问：“为什么留存下降了？”“哪个漏斗环节发生了变化？”“这个增长来自哪一类用户？”这类问题不仅需要取数，还需要一套调查顺序。

Meta 将资深分析师通常采用的步骤编码为 Analysis Recipes。配方通过确定性查询生成器依次取数，再由 LLM 帮助分析和总结结果。文章称，针对指标变化、漏斗流失和新产品中的用户画像等问题，编码过程的配方比自由提问更可靠。

这项“更可靠”的判断属于作者对内部实践的经验陈述，文章没有给出样本量、评估指标或自由提问基线。因此，可以确认的是它的工程结构，而不能把它写成已经被独立实验验证的普遍结论。

在消费侧，标准化模型和确定性查询接口还可以支持仪表盘模板。指标调查、增长、留存和漏斗分析都可以使用共享模型生成不同的展示体验。这里的复用链条是：同一份规范先生成管道，再生成查询，再被配方和仪表盘消费。

六、标准化的边界：什么时候不该建库

标准化并不是把所有分析都塞进固定 schema。Meta 作者明确指出，它更适合重复、高信任的测量；当团队需要探索性、灵活或一次性的分析时，过早固定模式可能限制发现和创新。

可以用下面的矩阵理解这种取舍：

这张表是基于原文边界的分析性整理，不是 Meta 发布的正式决策表。真正是否值得标准化，需要结合复用频率、错误代价、指标稳定性、维护团队和治理成本判断。

七、可迁移的工程抽象与未解决问题

从这篇文章的链路看，可供其他团队评估的不是“照着 Meta 建七个库”，而是三个工程抽象。它们是否适用，仍取决于本地分析需求和治理条件。

第一，先盘点重复需求，再决定哪些逻辑值得被封装。没有稳定复用场景时，标准化只是提前支付维护成本。

第二，让共享模型成为生产和消费之间的接口。管道、查询、分析和展示如果各自维护一套指标含义，Agent 只是把重复工作做得更快，不能消除口径分裂。

第三，把高风险的确定性部分从自然语言生成中拿出来。Agent 可以理解“看一下上个月按国家拆分的留存”，但数据源选择、时间口径、SQL 模板和校验规则更适合由结构化模型和程序负责。

这套抽象仍留下几个没有被文章充分回答的问题：七个模式的完整定义是什么？YML 模型如何版本化？当指标定义变化时，历史管道如何迁移？确定性查询生成器如何评估错误率？不同数据源之间的优先级规则如何接受业务审查？分析配方在不同领域是否仍然可靠？

因此，Meta 的案例可以作为一条架构路线参考：用受治理的分析模式承接重复需求，用类型化模型连接 Agent 和数据资产，用确定性工具承接查询执行，再把分析步骤和消费体验建立在同一接口之上。但它不是一份可以脱离组织数据治理、指标体系和维护能力直接复制的实施清单。

结语

AI-native analytics 的重点不是让 Agent 生成更多 SQL，而是减少它必须自由生成的部分。把常见分析模式、数据模型、数据源选择和查询生成封装进可治理的资产后，Agent 才能把更多能力用在理解问题、选择输入和解释结果上。

从 Meta 作者描述的方案看，自然语言分析的可靠性并非只取决于模型生成能力；共享的测量原语、数据模型和查询生成规则也构成了这套系统的重要部分。文章没有提供独立评估数据，因此这应理解为对其架构设计的归纳，而非普遍因果结论。

来源：Analytics at Meta / Benjamin Wan Rothschild，《Scaling AI-Native Analytics Patterns at Meta》，2026-10-20。Medium 原文。