RSS dbt Blog 发布 2026-08-06 21:00 25

从分析工程师到上下文工程师

dbt Labs 发文探讨企业 AI 部署从“为仪表盘建模数据”转向“为 Agent 建模上下文”。文章以自身为例，起初直接使用供应商 MCP 连接 Gong 等数据源，导致单次通话分析消耗高达 5 万 Token（约 0.25 美元），总数据量超 5 亿 Token。他们随后将原始数据摄入数仓并通过建模总结，以降低成本和掌控上下文层。

推荐理由：数据从业者应关注这一从 analytics engineering 到 context engineering 的范式转变，它直接关系到 AI Agent 如何高效、可控地连接企业数据资产。

Data Agent 语义层dbt LabsGongSalesforce

译文 AI 逐段翻译

博客

/ 洞察

/ 从分析工程师到上下文工程师

从分析工程师到上下文工程师

布里顿·斯坦珀最后编辑于2026年8月6日

如今，大多数公司在企业AI推广中都在走捷径，陷入了数据团队早已熟悉的一个经典陷阱。采取“简单路线”——将AI直接连接到供应商提供的MCP，再直接连接到源数据提供商——总体上导致公司在token消耗、供应商API费用以及数据所有权和可移植性缺失方面损失数十亿美元。

在dbt Labs，我们最初也不例外。我们使用供应商的MCP，直到我们发现这些隐藏成本实际上有多么巨大。

那时我们意识到，将AI连接到数据的最有效、可扩展的方式是我们一直倡导的：在数据仓库中集中数据并直接工程化上下文，这为我们拥有AI的上下文层并扩展数据团队职责提供了巨大机会。

事情是如何开始的

随着Claude在我们组织中的推广，最大的用户群之一是销售团队连接到Gong、Salesforce和其他丰富的上下文来源来分析他们的交易。当我们的GTM团队请求客户洞察以防止流失并识别高价值账户时，我们当然同意，并通过原生MCP连接AI代理直接分析Gong数据。

由于数百名销售人员每天多次使用这些数据，成本迅速增加。分析一次通话消耗高达50,000个token；仅是AI阅读一份转录文本就需要0.25美元的token成本。我们有超过5亿token的Gong转录数据可以利用。随着许多销售人员整天运行多个Claude会话，我们的AI总支出在规模上显著上升。

我们知道需要一种新方法。那时我们决定将原始Gong数据摄取到数据仓库中，并使用数据建模来总结每次通话。通过主动进行上下文工程，去除噪声并提取信号，我们将数据量缩小了20倍，并将60分钟通话的token消耗从数万个削减到仅几百个。问题是，如果我们能将任何数据转化为更有意义的上下文，我们如何设计出最小、最有意义的上下文层，但仍能回答大多数查询？

dbt如何降低token成本

当我们的数据团队之前为BI建模Gong数据时，ROI并不理想。但现在，Claude和ChatGPT代理解锁了新的用例，使我们能够大规模进行定性数据分析，通话转录表成为数据仓库中价值最高的资产之一。

通过数据仓库获取上下文远比直接从MCP中提取要高效得多。从仓库摘要提供通话转录数据使token成本降低了约98%，同时保持或提高了上下文质量。

在本系列博客中，我们将分享为AI高效建模可信上下文的核心模式，我们Gong试点项目的端到端技术演练，一次读取数据服务所有代理的基础知识，以及为什么您可以将传统的分析工程转变为上下文工程而无需更换技术栈。

使用工程化上下文进行大规模定性数据分析

在AI出现之前，以有意义的规模处理文本数据需要简单但低效的正则表达式技术（如关键词匹配）或高级统计和数据科学。为定性数据源（如通话录音或支持工单）维护复杂转换对数据团队来说根本不可行。

然而，正如我们的Gong突破所示，我们已经跨越了一个门槛，以前被忽视的数据和数据源现在可以构成一些最有用的、有价值的代理上下文。团队可以为AI构建模型和高效的上下文层，只要应用我们在分析工程中开创的一般原则，并考虑到AI的需求。

分析团队多年来一直为BI建模定量数据。上下文工程只是为代理建模数据，而该数据远不止指标：

分析工程	上下文工程
消费者	单个用户查看仪表板并运行查询	整个组织使用的AI代理，如Claude和Codex
数据源/格式	定量数据：结构化表和指标	定量数据 + 定性数据（如电子邮件和转录文本等文本；PDF；通话录音；支持工单；聊天日志）+ 半结构化/JSON
目的	将大量数据建模为KPI，通过图表和仪表板了解发生了什么	为代理提供业务上下文，以便它们能够提供准确的响应并大规模执行可信操作

仪表板需要指标。代理需要上下文。

未开发的定性数据是AI真正发挥作用的地方。数据团队现在不仅可以将结构化数据提供给仪表板，还可以利用PDF和JIRA工单等非结构化数据来工程化上下文。LLM的进步使得在这些文件在数据仓库内移动、存储、建模和处理成为可能，并将其用作代理AI的上下文。

这对许多分析师来说是一种新的思维方式，因为从历史上看，数据组织一直对转录文本等非结构化数据过敏，这是有充分理由的：我们的技术并非为其构建。

我们被迫改变，因为我们的Gong API调用即将用尽。每个人都在相似的数据上询问非常相似的问题，直接去找Gong说：给我所有转录文本，现在总结每份转录文本。直接使用MCP绕过了我们整个传统的数据建模和仓库世界，反复查询原始数据，这造成了冗余的token成本和API限制。那时我们意识到：嘿，你知道吗，我们实际上已经有了这个过程，将数据建模成可信、治理良好、更有用的形式。为什么我们不为AI的数据应用这个过程呢？

在与Fivetran合并后，我们意识到移动和建模非结构化数据已经是我们擅长的领域。像 Salesforce、Zendesk 或 Gong 这样的平台现在提供了关键的业务背景。在仓库中建模这些定性数据并缓存预构建的 AI 摘要，可以提供可靠、确定性的上下文，同时消除大量消耗 token 的 MCP 调用、工具泛滥和 API 限制。

用户通过上下文层中的单一上下文连接器（通过 MCP）无缝访问这些建模数据。这大大降低了 token 成本，将用户体验简化为简单的聊天，并在整个组织中开放可重复使用、社区驱动的数据模式。

如何实施经济高效的上下文工程

这种方法并不神奇。数据团队通过他们已经在实践的过程，将原始数据（无论是定量、定性还是半结构化）转化为代理上下文，而无需实质性改变技术栈：

压缩： 将大量语料库缩减为仅包含相关内容的最小形式
丰富： 将数据与其他相关信息连接起来，以便更容易访问所需的一切，例如机会详情和定性的交易历史。
描述： 提供关于数据含义及其适用时间的信息
治理： 精确决定每个代理被允许查看哪些内容以完成其工作

数据团队一次建模上下文，每个工具和代理都从相同的可信上下文层读取。分析工程师现在是上下文工程师。这仍然是相同的技能组合，除了建模指标外，你还要映射整个数据资产，现在所有数据源都发挥作用。

所有这些都在不实质性改变你的数据技术栈的情况下发生。数据团队为整个组织构建一个结构化共享上下文层，以与 dbt 当前分层于数据仓库之上的相同方式，在原始数据技术栈之上功能性地分层 AI。现在整个公司都是消费者，因为每个团队及其使用的代理都可以访问这个上下文层，而不仅仅是编写 SQL 查询的人员。

但从功能上讲，如何将结构化、半结构化和非结构化数据移动、转换并管理到上下文层中？

获取数据（包括传统表和非结构化文件）到数据仓库（Snowflake、BigQuery、Databricks）是 Fivetran 的工作。如果需要进一步准备表格式数据（过滤、反规范化、连接和聚合），那么 dbt 允许以开放和可移植的方式创建和执行该转换逻辑。
自动化利用目标平台基于 SQL 的 AI 功能的管道是 dbt 的工作。例如，Snowflake Cortex 提供了 SQL 函数，如 AI_EMBED、AI_COMPLETE 和 AI_PARSE_DOCUMENT，这些函数可以作为 dbt 模型的一部分执行并编排。BigQuery 和 Databricks 也提供类似功能。

原始文本字段、电子表格等文件中的结构化数据，甚至复制的非结构化文件（如 PDF）都变成了可查询、可检索的上下文，可供人类数据用户和 AI 代理在共享上下文层中使用。他们寻求信息的文档和数据源已经在同一平台上，由 Fivetran 自动移动和索引，并作为 dbt 模型的一部分进行处理。

上下文层之下的技术栈保持不变：Fivetran 移动数据；dbt 建模数据。但现在，这包括使 AI 系统强大的非结构化上下文。所有一直存在但从未进入管道的 Salesforce 电子邮件正文、Jira 工单附件、通话记录和合同 PDF 现在都是完全可引用、可信的上下文。

最佳实践开始出现

我们正在继续构建分析工程师进行上下文工程所需使用的词汇、包和开源项目。我们总结出一些可以分享的最佳实践，未来还会有更多。以下是我们团队使用的一些实践预览：

不要聚合上下文，而是生成它：使用仓库原生 AI 通过解析、分块、嵌入、转换和连接相关信息来创建新上下文，形成代理可以查询的建模数据对象。聚合可能导致上下文丢失，因此在整个管道中保持上下文质量至关重要。
上下文层架构： 一个共享、结构化、受治理、开放格式的规范上下文层，每个引擎都可以写入，每个代理都可以读取。数据行业一直关注的同一单一事实来源现在指向 AI 作为主要消费者。
读一次，写多次：读取是上下文工程中最昂贵的部分。使用 LLM 在批处理中进行一次昂贵的读取（成本更低）；然后在上下文层中为每个代理提供建模后的形式
增量式上下文维护：代理执行操作，它们需要正确、最新的信息来行动。上下文不能仅仅是快照，必须随着新事件和信息的到来进行更新。增量模型（通过构建管道捕获状态变化以便可审计）对于更新上下文的当前状态至关重要。

直到最近，最简单的上下文路径是直接获取原始 API 并连接 MCP 服务器。现在，数据分析师可以介入并说：“使用我们现有的数据。我们将用你要求的一些 AI 功能来增强这些数据，处理一次，然后让所有人可以无限次使用。”现在，数据团队拥有 AI，并成为下一个商业时代的关键团队。

Fivetran + dbt Labs 正在为你信任的代理构建数据基础。加入我们的 dbt Summit，数据从业者和领导者齐聚一堂，共同塑造数据和 AI 的未来。