企业生产级 AI 的数据基座：WPP 案例的 dbt 架构实践

WPP 的文档化模式结合了共享数据项目、分离的处理计算、规范化的受众定义以及编排式管道。

对开发者而言，实践教训很简单：生产级 AI 始于模型层之下。模型需要共享的、有治理的数据骨干，才能支撑可靠的营销工作负载。

构建可复用边界

将身份、同意、血缘和通用人群规则集中化。让领域团队在共享标准下拥有富含上下文的数据产品。

这个边界为企业营销、martech、增长、RevOps、数据平台团队提供了通用基础，而不会剥夺领域团队的所有权。共享治理定义了哪些必须保持一致；领域产品保留了每个工作负载所需的上下文。

将受众语义转化为接口

规范化受众定义应该像受治理的数据契约一样运作，而不是将逻辑复制到每个管道中。

下面是一个厂商无关的 dbt 模式，使这个契约具体化。它阐释的是架构而非 WPP 的确切 schema：

-- models/interfaces/canonical_audience.sql
{{ config(materialized='view') }}

with identity as (
    select customer_id
    from {{ ref('shared_identity') }}
),

consented_customers as (
    select customer_id
    from {{ ref('shared_consent') }}
    where is_marketing_eligible = true
),

cohort_membership as (
    select
        customer_id,
        audience_key,
        audience_name
    from {{ ref('common_cohort_membership') }}
)

select
    identity.customer_id,
    cohort_membership.audience_key,
    cohort_membership.audience_name
from identity
inner join consented_customers
    on identity.customer_id = consented_customers.customer_id
inner join cohort_membership
    on identity.customer_id = cohort_membership.customer_id

这个接口将身份、同意和通用人群依赖显式化。领域团队可以消费它并在下游添加上下文，而不会静默重新定义共享受众。

在预测之前审查管道

在庆祝模型性能之前，审查它周围的操作系统：

• 新鲜度：输入对当前工作负载是否足够新？
• 管道可靠性：编排行为是否一致？
• 重试安全性：失败的工作能否在无副作用风险的情况下重试？
• 血缘：团队能否从输入追溯到输出？
• 成本：工作负载是否作为运营费用可见？
• 服务级合规：系统是否满足与用例相关的承诺？

模型只是一个组件。平台还必须兑现其数据和运营承诺。

按顺序添加能力

从受治理的分析开始。在此基础上工作正常后，添加预测性定向。只有在审查和安全控制能够支撑生成式资产工作流后，才引入它们。

这个顺序迫使平台在添加更复杂工作流之前建立治理和运营纪律。

根据工作负载选择架构

客户数据平台、仓库原生设计和混合设计是实现形态，不是成熟度排名。根据工作负载而非类别标签来选择。

核心权衡是共享控制与本地上下文。将可复用的治理集中化，同时将富含上下文的数据产品留给理解它们的领域团队。

如果分离了计算，必须显式统一可观测性层。在工作负载边界之间保持新鲜度、可靠性、重试安全性、血缘、成本和服务级合规的可见性。

超越模型

WPP 的蓝图指向生产级 AI 营销的更广义定义：一个具有可执行控制的复用数据系统，而非模型演示的集合。

在添加另一个 AI 工具之前，检查基础层。身份和同意是否已共享？受众定义是否规范化？团队能否在分离的计算之间追溯编排工作？他们在评估模型输出之前能否审查运营证据？

在你的技术栈中，你会将规范化受众接口放在哪里，哪些会保留为领域所有？