dbt：在数据仓库中开始上下文工程

分析工程师已经知道如何构建企业数据架构：获取原始数据，清洗它，建模它，并以可信的形式提供服务。多年来，目的地一直是一个仪表盘，而输入是结构化表格。现在，团队正从仪表盘转向以AI作为主要接口，是时候进行上下文工程了。

最大的数据使用者已经迅速变成了AI代理，而它们交付业务成果所需的上下文已不仅限于结构化数据，还包括转录文本、工单、PDF和电子邮件。我们现在拥有的技术可以读取大量文本，然后理解、解释并给出回应，速度比某人起身去拿杯咖啡还要快。

这些上下文工程技术带来了一些新词汇和技术实现细节，比如向量和本体。但它们也同样受益于团队已经依赖的dbt工程模式：转换数据以将逻辑构建到模型中，通过将数据与其他系统的相关信息连接来丰富数据，描述不同字段的含义以及如何可靠地查询它们，并治理谁可以看到什么信息。

技术栈也保持不变：Fivetran移入数据，dbt对其进行建模。大多数人尚未充分利用的部分是，仓库提供商一直在大力投资处理非结构化数据，而这对于上下文工程至关重要。

上下文工程极大地提升了数据团队产生影响的潜力。分析工程师过去主要服务于能够编写SQL或构建图表的用户。上下文工程师则通过AI代理服务于整个组织中的每一个人。这篇文章教授一些快速入门的术语和技术，让分析工程师释放他们内在的上下文工程师潜能。

加入我们的会议，从分析工程师到上下文工程师：dbt实战手册，我们将逐步讲解dbt Labs内部用于将非结构化来源转化为受治理、带版本的上下文的确切模式，并介绍dbt_context_engineering包，该包将这些模式付诸实践。在此处预订您的席位。

您的数据仓库已经为上下文工程做好了准备。现在轮到您了。

当AI在2023年开始兴起时，Databricks、BigQuery和Snowflake等大型数据仓库都开始投资，以成为AI基础设施。它们开始添加有用的AI原生能力：在SQL查询中直接调用AI的能力，以及将嵌入和向量余弦相似度搜索作为SQL函数提供支持。

现在，所有主要数据仓库都将这些原生AI函数作为系统的一部分提供给用户。例如，Snowflake Cortex提供AI_EMBED、AI_COMPLETE，以及AI_PARSE_DOCUMENT；Databricks的任务特定函数包括ai_extract（从您定义的schema中提取结构化字段）、ai_classify和ai_summarize。无论数据仓库如何称呼它们，dbt都会继承这些功能，因为dbt是作为运行这些系统的服务来部署的。

那么如何进行上下文工程呢？只需使用数据仓库提供的AI工具！您不需要投资新的提供商，也不需要像图数据库、向量数据库或单独的ML栈这样的独立产品中构建代理基础设施。您可以调用函数，并利用数据仓库已经暴露的工具来精心设计您的架构。问题是，大多数人还没有考虑过开发这些模式。

虽然少数人能够通过尝试数据仓库新增的功能来过渡到在前沿运行AI，但大多数数据从业者尚未意识到这一时刻的重大意义——以及他们抓住它的潜力。我们认为这主要是由于缺乏一些基本词汇和清晰的示例。

第一个缺失的环节：词汇

当大型数据仓库宣布诸如‘我们现在有了向量存储！’之类的内容时，许多传统上为分析用例构建指标和维度的分析工程师可能并不理解这些仓库AI能力所提供的全部潜力。这些函数扩展了他们可以为组织交付的可能性。

内置仓库函数很重要，因为它们是分析工程师成为您企业AI关键驱动力的路径。它们是设计AI系统的极其强大的构建块，可从任何SQL模型调用。不幸的是，数据仓库在教育和赋能用户了解如何以及为何应该学习这些函数方面做得并不好。以下是您需要了解的概念，以便您也能实施这门技艺。

将原始数据转化为建模上下文的入门概念

1. 分块：通过将大量文本分割成足够小以便嵌入和搜索的片段（即文本块），使其可被寻址。或者，将许多小段文本组合成更大、更有用和更有意义的集合。

目前还没有一种被普遍认可的分块方法，但一般原则是将文本组装成有意义的单元，以便当它们被嵌入（下一个词汇术语）时，它们将代表代理搜索空间中有价值的一部分。如果它们太大，含义可能会变得混乱；如果它们太小，它们可能会变成无意义的噪音。一种简单、朴素的分块方法是为一组块设置最小文本量，并拆分或合并文本以使其足够有意义。通常，块之间会相互重叠，这样搜索空间就不会在块中间被 awkwardly 切断而丢失含义。

1. 嵌入：将文本转化为向量以支持搜索。

嵌入（Embedding）是你获取这些分块并为文本含义创建向量搜索空间的方式，这样智能体就能使用语义搜索来找到最相关的上下文。嵌入模型读取一个分块并返回其在向量空间中的坐标，这是一种高度维度的表示，是一个数字列表，表示相对于一千个或更多维度中某一个维度的相对距离。嵌入不会取代源数据；它们与源数据并存，作为含义的查找键，这就是为什么检索管道总是将分块文本存储在向量旁边。此外，这是一个单向过程：你无法从向量中恢复文本。

1. 向量：一个数字数组，将一段文本定位在空间中，使得在该空间中的接近意味着含义上的接近。

从功能上讲，向量是含义的坐标。单个向量是一个数字列表，将一个特定的文本片段相对于来自同一来源的每一个其他片段定位在空间中。与它最接近的其他向量就是最相关的那些。例如：一个关于“无法登录”的查询在与一条写着“密码重置循环”的工单进行相似度比较时会获得高排名，尽管它们没有任何共同的词。向量对人类来说毫无意义，因为它实际上只是一堆数字。但对LLM来说，它是一个搜索空间。

1. 分类（本体论）：用共享词汇表为每个分块附加含义。

在计算机科学中，本体论是结构化框架，定义特定领域内的概念、属性和关系，以帮助机器理解数据。在上下文工程中，分类使用AI来说，‘好吧，这段文本是什么意思，它与我更广泛组织的上下文有何关联？’

我们将发布更多技术，我们很乐意听取社区关于你们在自己的工作中如何着手上下文工程的意见。加入dbt社区的对话：https://www.getdbt.com/community/join-the-community。

第二个缺失的环节：这在DAG中是什么样子

向量、分块、嵌入和其他AI数据建模技术是相当新的概念，但它们不需要新的技术栈。它们都在你已经熟悉的技术栈中运行： 源数据落地，然后是暂存层，然后是基础建模进入数据集市。每个dbt用户都已经构建过一千次了。

现在，AI函数、嵌入和向量搜索已作为SQL原语出现。任何在SQL函数中可用的东西，包括AI工具，都适合放在dbt模型中，并且它还继承了dbt已经做的一切：版本控制、血缘、测试、增量运行、调度。你不需要向量数据库或嵌入的编排层。这一切都在不实质性改变你的数据栈的情况下发生。

新层：分块、分类、嵌入

以销售通话数据为例：分块将一条长单行通话记录变成每次通话多行。嵌入添加一个向量列，这样你就可以在大量通话语料库中搜索。而分类能够将信息与你组织的更广泛上下文关联起来。到最后，你得到一张表，其中每一行都是一段文字，被描述且可搜索，为你提供一个搜索空间，以便你只返回最相关的信息片段。

例如：查看大量客户通话并询问，‘在我们的客户群中，用户谈论登录问题的频率有多高？’分块会将这些通话转变为有意义的搜索单元；嵌入创建了一个搜索空间，这样如果你想在大量通话语料库上进行搜索，你就能找到真正重要的分块。然后，“登录问题”的相似性可以在向量存储中、在仓库内进行搜索。

用于从整个业务中获取额外数据来丰富通话的上下文工程模式已经在dbt中构建得很好。也就是说，这个上下文也会包含你可能需要的其他相关信息，比如它发生在哪次通话上、客户是谁、到底说了什么，以及是谁说的。

请参阅我们的为token建模，而不是为表建模文章，了解我们如何在dbt仓库中应用向量、分块和嵌入来挖掘我们自己的Gong通话记录库，将数据量缩小20倍，并将一次60分钟Gong通话的token消耗从数万个削减到仅几百个。

我们将上下文工程视为数据建模问题的副产品是，我们能够为AI构建更好的上下文结构，首先是为你要问的任何问题创建向量列作为搜索空间。结果是 更高质量的上下文和更少的token数量。

一种哲学，而非一个功能

该模式是一个转换管道，最终以可检索的上下文结束，超越仪表板中的内容：源 → 暂存 → 数据集市 → 分块、分类、嵌入 → 智能体。上下文像任何其他数据产品一样被暂存、转换、测试和版本化。

使其成为一种哲学的原因是，这对dbt用户来说不需要任何新工具。同一个仓库，同一个dbt项目，同样的建模纪律。管道没有改变，而是扩展了：分块、分类、嵌入以及更多都位于建模过去交接的地方，并且它运行在从SQL模型调用的原生仓库AI函数上。

dbt Gong示例只是这种模式的一个实例，它适用于任何持久、token繁重的来源，如支持工单、合同PDF、电子邮件档案、Slack日志或营销材料。来源会变；技术保持不变。

上下文工程的词汇、实践和共享模式仍在构建中。对真实数据运行这些技术会引出第二组问题：将输出追溯到产生它的提示、随着语料库增长限制推理支出、证明智能体使用的上下文可追溯到源数据。

一旦该上下文被建模并标注了语义层，AI 工具就能像人一样查询它——基于含义，而不仅仅是关键词。完整模式如下：摄取 → 为非结构化列建立索引 → 用 dbt 建模 → 用语义层标注 → 将你的 AI 工具连接到该上下文。

最后一步正是 Claude 和 ChatGPT 的用武之地。这一交接正是Fivetran Context Layer（目前处于有限公开预览阶段）所为之打造的，因此你刚刚在数据仓库中构建的、经过建模和治理的上下文，能立即成为 AI 工具可以推理的对象，而不是另起一个集成项目。敬请期待更多内容。

参加我们的会议，从分析工程师到上下文工程师：一份 dbt 实战手册，我们在其中论证上下文工程就是带有全新最后一公里的分析工程。我们将逐一讲解 dbt Labs 内部用来将非结构化来源转化为受治理、有版本的上下文的确切模式，并介绍 dbt_context_engineering 包，将这些模式付诸实践。在此预订席位。