数据 Agent 真正缺的不是更强模型，而是上下文层

关于上下文的上下文

最近，在数据和AI代理的世界中，上下文层和图已成为一个有趣的讨论话题。事实上，如今很难与一个使用数据和AI的组织进行对话而不提到上下文这一话题。

这是有充分理由的。在过去一年中，市场已经意识到，如果没有正确的上下文，数据和分析代理基本上毫无用处——它们无法解析模糊的问题、解读业务定义，也无法有效地跨不同数据进行推理。

当然，这不是它们的错。现代数据栈已经经历了十年以上的转变，从分散的数据源到整合的数据和清洗后的定义（这很好），但即便如此，整合也从来不是完美的，并且引入了很多混乱。整体市场演变如下：

1. 现代数据栈的兴起——我们之前与dbt的Tristan Handy和我们自己的参考架构中讨论过现代数据栈的变革性崛起。过去十年的总体演变已经转变了数据架构，涵盖数据摄取、转换、仓库和存储，以集中数据并使其快速、轻松地访问。其想法是，通过清晰组织的数据，团队可以简单地编写SQL从其数据仓库中获取数据，为图表/仪表板提供支持，并实现整个组织的商业智能。
2. 代理热潮——在2024年进入2025年之际，随着LLM能力的增强，基本上每个组织都希望在其现有数据栈之上构建和部署代理。我们之前讨论过我们如何定义代理，但从组织的角度来看，以更高的效率和更少的时间完成更多工作的自然吸引力自然导致了向代理式工作流的倾斜。公司试图构建“与您的数据聊天”的聊天机器人、支持代理等。这种热潮既是自下而上的，也是自上而下的——开发人员希望利用最新、最闪亮的LLM能力，而领导层则施加AI采用压力以增加自动化和降低成本。
3. 碰壁——尽管最初持乐观态度，但很快人们发现，大多数此类努力都失败了。组织试图部署其代理，但遇到了障碍。麻省理工学院著名地发布了其“2025年商业AI状况”报告，该报告指出，在AI部署中，“大多数都因脆弱的流程、缺乏上下文学习以及与日常运营不一致而失败。”

代理无法正常工作的一个关键原因是缺乏适当的数据上下文。当今企业数据仍然极其分散和混乱——正因为如此，数据代理在跨各种数据架构（包括结构化和非结构化数据）回答像“上季度收入增长是多少？”这样的基本问题时遇到了困难。

就像多年前完全自助式分析的愿景未能实现一样，数据代理的愿景似乎也未能实现。

上下文问题——不仅仅是文本到SQL

那么，为什么最初的代理部署时代会失败呢？起初，许多人认为问题在于模型方面的基本数据推理和SQL/Python代码生成差距。一般的想法是，模型应该能够将自然语言查询作为初始输入，对现有数据系统进行推理，并以传统商业智能（BI）的方式生成相应的SQL代码，以获取正确的数据并相应地回答初始问题。

如果模型失败或不准确，差距就被归咎于模型不擅长SQL，并期望模型性能会提高。

这不是完全错误的。虽然模型在代码生成和数学推理等用例中的能力有了显著提高，但在数据方面仍然落后（如Spider 2.0和Bird Bench等SQL基准所示）。模型的能力无疑有了巨大飞跃，但我们很快了解到，问题不仅仅局限于文本到SQL。

为了更具体地说明并进一步分解收入增长的例子：

1. 假设在组织内部构建了一个数据代理。它旨在利用现代基础模型，连接到所有正确的数据源，并连接到一个漂亮的UI，以接收内部用户的数据问题。
2. 我们的查询来了。“上季度收入增长是多少？”这是一个看似简单的问题，通常通过快速查看Looker或Tableau仪表板就能轻松回答——对于先进的智能代理来说，这应该不是挑战！
3. 挑战1——代理如何知道收入或季度实际上是如何定义的？收入实际上是一个业务定义，并未硬编码到仓库或管道中。用户是在寻找经常性收入还是年化经常性收入？财季报告可能并非针对所有组织标准化，并且根据您询问的公司，可能是完全不同的三个月期间。应该查看的正确时间窗口是什么？
4. 幸运的是，数据平台负责人介入并表示——“我们已经构建了语义层来解决这个问题。我们在那里捕获了我们的收入定义。”而且——代理应该能够摄取所有语义层作为上下文。一个很有前景的潜在解决方案，但团队查看了一些YAML文件，并意识到它们是由去年离开的数据团队成员更新的，BI工具不再使用，并且不包括此后推出的两个新产品线。代理不知道今天收入实际上是如何定义的。
5. 为了克服这个障碍，一名团队成员硬编码了确切的收入和时间范围定义。数据代理继续运行，但很快遇到了挑战2——正确的数据源在哪里？哪些是正确的事实来源？ 原始数据分散在多个表和数仓中。财务团队使用 fct_revenue 表，这可能是正确的，但数据团队创建了物化视图，如 mv_revenue_monthly 和 mv_customer_mrr。

很明显，数据代理需要访问包含最新业务定义和数据来源的存储库，以克服这些问题。

引入上下文层

当前问题的关键是，代理没有被赋予适当的业务上下文来回答即使是最基本的问题。这代表了在组织内构建自动化 AI 系统中存在的更大鸿沟——需要有最新且维护良好的上下文，它不仅理解企业如何运作以及数据系统如何结构，还维护着将一切联系在一起的隐性知识。

这导致了上下文层的演变。当今讨论中出现了许多名称——上下文操作系统、上下文引擎、上下文数据层、本体论等——但底层概念保持不变。将企业所有混乱的数据联系在一起，在其上添加一个帮助代理理解业务逻辑的上下文层，并将其打包以便上下文可以提供给代理。

上下文管理的似曾相识

但等等。我们描述的东西听起来是否与语义层惊人地相似……？确实有一些相似之处，但最终如果代理工作流要真正自主，它们需要的不止是语义层当前所表现的形式。

在 BI 上下文中，传统的语义层非常适合特定指标定义（如收入、流失率、ARPU）。然而，它们通常由数据团队使用非常特定的语法通过专用层（如 LookML）手工构建，并直接连接到 BI 工具（如 Looker）。

现代数据上下文层本质上应该成为传统语义层所覆盖范围的超集。当然，特定指标定义可以被硬编码，但现代上下文层应包含更多内容以确保代理自主性——规范实体、身份解析、分解隐性知识的具体指令、适当的治理指南等。

本文主要关注将传统记录系统联系在一起的的数据上下文。另一个同样重要且重叠的机会是捕获组织的决策和工作流逻辑，以便构建真正多用途的代理，使其恰当地基于组织的所有数据和决策上下文。

整合在一起

根据我们最近与客户的对话以及对他们需求的理解，以下是我们认为现代上下文层与代理式数据系统结合可能呈现的样子，逐步分解如下：

1) 访问正确的数据 – 首要任务是确保所有正确的数据都是可访问的。这是基础。理想情况下，组织应通过湖仓一体架构实现某种形式的现代数据栈，并具有一定程度的统一性。即便如此，我们也希望确保代理能够访问其所需的所有数据，这可能超出仓库和操作应用中可用的范围。这包括在内部系统、GDrive/Slack 等中捕获的隐性知识。

2) 自动化上下文构建 – 一旦所有正确的数据可访问，下一步就是开始构建上下文层。使用 LLM 的好处是，许多初始上下文收集可以自动化完成。重点应放在高信号上下文上——例如，查看过去的查询历史可能是高信号的，用于确定最常被引用的表和最常见的连接，而像 dbt 或 LookML 这样的数据建模解决方案可以为业务指标提供清晰的定义。

3) 人工细化 – 自动上下文构建可能能够形成上下文库的大部分，但不能构建完整的图景。放任代理收集所有内部知识是很诱人的，但一些最重要的上下文是隐性的、有条件的和历史性的，并且仅以团队内部的隐性知识存在。

人工输入提供了最终的关键连接，使真正的代理自动化成为可能。例如——“对于 CRM 数据，查看 Affinity 以获取 2025 年以来的所有新 USCAN 交易，但在此之前的所有全球线索则查看 Salesforce。”

这样，上下文层可以成为一个多维语料库，代码与自然语言并存，捕获代理可能需要的任何上下文。就像开发人员可以设置 .cursorrules 文件来指导代理并控制输出行为一样，数据从业者可以维护规则和指南。

4) 代理连接 – 一旦上下文层构建得当，只需将其暴露给代理并实时可访问。这通常可以通过 API 或 MCP 实现。

5) 自更新上下文流 – 虽然初始系统已正确设置，但数据系统从来不是静态的，因此上下文层也不应静态。数据源和格式可能在上游发生变化，个人可能希望根据不断变化的业务需求添加和修改自定义指令。当数据代理提供错误数据并需要准确性修正时，当然应将其合并回上下文层。这样，上下文层就成为一个活的、不断发展的语料库。

从整个实践中的一个收获是，构建一个合适的数据代理绝非易事。它是与数据基础设施和工程相关的技术挑战，以及与隐性知识收集相关的人类操作挑战的混合体。

OpenAI 团队最近发表了一篇精彩的文章详细说明了他们创建内部数据代理的过程。这是一个非常详细且优雅的实现方式的透明细节——但指出了要达到这一目标所需的漫长旅程。同样，Palantir 在为组织构建本体方面有着悠久的历史，这些本体从杂乱的数据中提供清晰的背景，并且他们通过这样做建立了庞大的业务。

市场方向

自然，这为外部解决方案打开了一个窗口。实际上，并不是每个企业都能（或应该）在内部构建这个，我们已经看到各种解决方案开始进入市场。

虽然我们相信看到解决方案成熟还为时尚早，但以下是正在构建的解决方案的高层次市场地图：

对类别进行细分：

数据引力平台——像 Databricks 和 Snowflake 这样的平台已经完成了数据摄取、转换和存储的过程，数据引力是强大的。他们已经在开发 AI 数据分析产品，如 Databricks Genie 和 Snowflake Cortex Analyst，这些产品构建在数据仓库之上，利用基础模型进行文本到 SQL 的转换，允许用户用自然语言询问关于他们数据的问题。

虽然这些平台本身没有非常复杂的上下文层功能，但它们确实允许轻量级的语义建模，并且通过公司收购或内部开发将上下文层引入平台是一个可行的前进路径。

现有的“AI 数据分析公司”——已经有一波公司利用 AI 让客户与你的数据聊天。许多公司通过在市场上的时间意识到，有效的数据代理的关键在于构建相关的上下文层。因此，一些公司已经演变，将数据上下文构建作为其产品的重要组成部分。

新的、专门的上下文层公司——一个新类别的公司已经出现，从头开始构建上下文层。他们将不得不经历我们上面的旅程：摄取数据、收集群体知识等——并且必须为他们合作的每一个客户这样做。

展望未来

我们正处于市场发展的一个有趣时刻，上下文缺乏的问题已经变得明显，但我们在构建解决方案方面仍处于早期阶段。

未来是令人兴奋的——也许真正自助式分析的愿景可以完全实现，BI、数据分析和数据科学可以通过 AI 转型。

自然，许多开放问题仍然存在。这个上下文层会存在于哪里？它能存在于多个地方吗？它会是一个独立的、单独的产品吗？

我们对这里的创新机会仍然感到兴奋。如果你在这个领域进行构建，我们很乐意交流！请通过 [email protected] 或@jasonscui在 X 上联系我们。