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

如今，大多数公司在企业AI部署中都在走捷径，并且陷入数据团队早已非常熟悉的经典陷阱。采取“简单路线”——将AI直接连接到供应商提供的MCP，并将它们直接连接到源数据提供商——正在让公司集体付出数十亿美元的代币消耗、供应商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真正有价值的地方。现在，数据团队不仅可以将结构化数据提供给仪表板，还可以使用PDF和JIRA工单等非结构化数据来设计上下文。LLM的进步使得在数据仓库中移动、存储、建模和处理这些文件成为可能，并将其用作代理式AI的上下文。

这对许多分析师来说是一种新的思维方式，因为历史上数据组织一直对记录等非结构化数据过敏，这有很好的理由：我们的技术并非为支持这类数据而构建。

我们被迫改变，因为我们快要用完Gong的API调用次数了。每个人都在对非常相似的数据提出非常相似的问题，直接去Gong说“给我我所有的记录，现在总结每份记录”。直接的MCP完全绕过了我们传统的建模和数据仓库体系，重复查询原始数据，这造成了多余的token成本并引发了API限制。这时我们意识到“嘿，你知道，我们其实已经有这个过程，将数据建模成可信、治理良好、更有用的形式。为什么我们不将其应用于AI数据呢？”

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

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

如何进行成本效益高的上下文工程

这种方法没有什么神奇之处。数据团队通过他们已经在实践的相同流程将原始数据（无论是定量的、定性的还是半结构化的）转化为代理上下文，而无需对技术栈进行实质性更改：

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

数据团队对上下文进行一次建模，每个工具和代理都从相同的受信任的上下文层读取。分析工程师现在是上下文工程师。这是相同的技能，除了对指标进行建模外，你还在映射整个数据资产，并且现在每个数据源都在发挥作用。

所有这些都在不大幅更改数据栈的情况下完成。数据团队为整个组织构建一个结构化的共享上下文层，在功能上类似于 dbt 当前分层于数据仓库之上，将 AI 分层于原始数据栈之上。现在整个公司都是消费者，因为每个团队及其使用的代理都可以访问此上下文层，而不仅仅是编写 SQL 查询的人。

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

1. 将数据（包括传统表格和非结构化文件）导入数据仓库（Snowflake、BigQuery、Databricks）是 Fivetran 的工作。如果表格数据需要进一步准备（过滤、反规范化、连接和聚合），则 dbt 允许以开放和可移植的方式创建和执行该转换逻辑。
2. 自动化利用目标数据库基于 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 的未来。