作者：Jason Cui & Jennifer Li | 来源：SandHill.io

你的数据智能体需要上下文

URL: https://www.a16z.news/p/your-data-agents-need-context

---

是时候开始构建了。
超过 220,000 名订阅者
你的数据智能体需要上下文
市场已经意识到，没有合适的上下文，数据和分析智能体基本上是无用的

关于上下文的上下文

最近，在数据和 AI 智能体的世界里，上下文层和图已经成为一个有趣的讨论话题。事实上，如今与一个处理数据和 AI 的组织进行对话，很难不谈及上下文这个话题。

这是有充分理由的。在过去的一年里，市场已经意识到，没有合适的上下文，数据和分析智能体基本上是无用的——它们无法理清模糊的问题、解读业务定义，以及有效地跨不同数据进行推理。

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

1) 现代数据栈的兴起 – 我们过去曾与 dbt 的 Tristan Handy 以及在我们自己的参考架构中探讨过现代数据栈的变革性崛起。过去十年的总体演变已经改变了数据架构，涵盖了数据摄取、转换、仓储和存储，以集中化数据并使其能够快速便捷地访问。其理念是，有了清晰组织的数据，团队就可以简单地编写 SQL 从他们的数据仓库中派生数据，驱动图表/仪表盘，并在整个组织内实现商业智能。

2) 智能体狂潮 – 随着 LLM 能力在 2024 年至 2025 年间的增强，几乎每个组织都希望在他们现有的数据栈之上构建和部署智能体。我们之前已经讨论过我们如何定义智能体，但从组织的角度来看，以更高效率和更少时间完成更多工作的天然吸引力，自然而然地导致了向智能体工作流的倾斜。公司试图构建“与你的数据聊天”的聊天机器人、支持智能体等。这场狂潮既是自下而上的，也是自上而下的——开发者希望利用最新、最炫的 LLM 功能，而领导层则施加 AI 采用的压力，以增加自动化并降低成本。

3) 撞上南墙 – 尽管最初很乐观，但很快就清楚了，这些努力大多都失败了。组织试图部署他们的智能体，但却撞了南墙。麻省理工学院（MIT）著名地发布了他们的《2025 年商业 AI 状况》报告，其中指出，在 AI 部署方面，“大多数失败是由于脆弱的工作流、缺乏上下文学习以及与日常运营的错位。”

智能体表现不佳的一个关键原因，是缺乏适当的数据上下文。如今的企业数据仍然极其分散和混乱——正因如此，数据智能体在面对“上一季度的收入增长是多少？”这类基本问题时，在汇集了结构化和非结构化数据的各种数据架构中举步维艰。

就像多年前完全自助式分析的愿景未能实现一样，数据智能体的愿景似乎也同样落空了。

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

那么，为什么最初那波智能体部署会举步维艰呢？起初，许多人认为问题在于模型端存在根本的数据推理和 SQL/Python 代码生成差距。普遍的看法是，模型应该能够接收自然语言查询作为初始输入，对现有数据系统进行推理，并以传统的商业智能（BI）方式生成相应的 SQL 代码，以提取正确的数据并相应地回答最初的问题。

如果模型失败或不准确，这个差距就被归咎于模型不擅长 SQL，并期望模型性能会得到改善。

这并非完全错误。虽然模型在代码生成和数学推理等用例上的能力已显著提高，但在数据方面仍然滞后（如 SQL 基准测试 Spider 2.0 和 Bird Bench 所证明）。毫无疑问，模型的能力有了巨大飞跃，但我们很快认识到，问题不仅仅是文本到 SQL。

为了更清晰地说明问题，让我们进一步分解一下收入增长的例子：

假设一个数据智能体在组织内部构建。它被设计为利用现代基础模型，连接到所有正确的数据源，并接入一个漂亮的用户界面，以处理来自内部用户的数据问题。

我们的查询来了。“上一季度的收入增长是多少？”一个看似简单的问题，通常通过快速浏览 Looker 或 Tableau 仪表盘就能轻松回答——对于一个先进的智能体来说，这应该不是挑战！

挑战 #1 – 智能体如何知道收入或季度实际上是如何定义的？收入实际上是一个业务定义，它没有硬编码到仓库或管道中。用户是在寻找 run rate revenue（运营率收入）还是 ARR（年度经常性收入）？财政季度的报告可能并未对所有组织进行标准化，并且根据你问的公司，它可能是一个完全不同的三个月周期。正确的观察时间窗口是什么？

幸运的是，数据平台负责人介入并说——“我们已经构建了语义层来解决这个问题。我们在那里捕获了我们的收入定义。”而且——智能体应该能够将所有语义层作为上下文进行摄取。这是一个很有希望的潜在解决方案，但团队看了一下几个 YAML 文件后发现，这些文件是由去年离职的一位数据团队成员更新的，BI 工具已不再使用，而且也没有包括此后推出的两条新产品线。智能体根本不知道如今的收入是如何定义的。

为了克服这个障碍，一位团队成员硬编码了确切的收入和时间范围定义。数据智能体继续运行，但很快遇到了挑战 #2 – 正确的数据源在哪里？哪些是正确的真实来源？原始数据分散在多个表和仓库中。财务团队使用 fct_revenue 表，这可能是正确的，但数据团队已经创建了像 mv_revenue_monthly 和 mv_customer_mrr 这样的物化视图。

很明显，数据智能体需要访问一个包含最新业务定义和数据源的存储库，以克服这些问题。

进入上下文层

问题的症结在于，智能体没有被给予适当的业务上下文来回答哪怕是最基本的问题。这代表了在组织内构建自动化 AI 系统时存在的一个更大差距——需要有最新且维护良好的上下文，它不仅要理解企业的运作方式和数据系统的结构，还要维护将所有东西联系在一起的部落知识。

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

上下文管理的似曾相识

但是等等。我们所描述的听起来是不是与语义层惊人地相似……？确实有一些相似之处，但归根结底，如果智能体工作流要变得真正自主，它们需要的不仅仅是语义层目前的表现形式。

在 BI 的背景下，传统的语义层对于特定的指标定义（如收入、流失率、ARPU）非常有用。然而，它们通常是由数据团队使用非常特定的语法，通过像 LookML 这样的专用层手工构建的，并直接连接到像 Looker 这样的 BI 工具。

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

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

整合一切

根据我们最近与客户的对话以及对他们需求的理解，以下是我们认为一个与智能体数据系统配对的现代上下文层可能的样子，分步说明：

1) 访问正确的数据 – 首要任务是确保所有正确的数据都是可访问的。这是基本要求。理想情况下，一个组织会实施某种形式的现代数据栈，并通过湖仓一体（lakehouse）架构实现一定程度的统一。即便如此，我们仍希望确保智能体能够访问它需要的所有数据，这可能超出了仓库和运营应用中可用的数据范围。这包括内部系统、GDrive/Slack 等中捕获的部落知识。

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

3) 人工优化 – 自动化上下文构建可能能够形成大部分的上下文语料库，但它无法创建完整的图景。让智能体自由收集所有内部知识是很诱人的，但一些最重要的上下文是隐性的、有条件的、和历史相关的，并且只作为部落知识存在于团队内部。

人工输入提供了实现真正智能体自动化的最后关键环节。例如——“对于 CRM 数据，从 2025 年起的所有新的 USCAN 交易请查看 Affinity，但之前的所有全球潜在客户请查看 Salesforce。”

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

4) 智能体连接 – 一旦上下文层被正确构建，它只需要暴露给智能体并可实时访问。这通常可以通过 API 或 MCP 完成。

5) 自我更新的上下文流 – 虽然初始系统已经正确设置，但数据系统从来都不是静态的，因此上下文层也不应该是。数据源和格式可能会在上游发生变化，个人可能希望根据不断变化的业务需求添加和修改自定义指令。如果数据智能体提供了不正确的数据并需要进行准确性优化，那当然应该被反馈回上下文层。通过这种方式，上下文层成为一个活的、不断演变的语料库。

整个过程的一个启示是，构建一个合适的数据智能体绝非易事。它融合了与数据基础设施和工程相关的技术挑战，以及与部落知识收集相关的人类运营挑战。

OpenAI 团队最近发表了一篇精彩的文章，详细介绍了他们自己内部数据智能体的创建过程。这是一个非常详细和优雅的实现的透明细节——但也指出了要达到这一目标所需的漫长旅程。同样，Palantir 在为组织构建本体方面有着悠久的历史，这些本体从混乱的数据中提供清晰的上下文，并在此基础上建立了一项大业务。

市场方向

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

虽然我们相信我们仍处于解决方案出现的早期阶段，但以下是正在构建的解决方案的高级市场地图：

为了分解这些类别：

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

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

现有的“AI 数据分析师公司” – 已经出现了一批利用 AI 让客户与你的数据聊天的公司。许多公司通过市场实践认识到，有效的数据智能体的关键实际上是构建相关的上下文层。因此，一些公司已经发展到将数据上下文构建作为其产品的关键部分。

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

展望未来

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

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

当然，许多开放性问题仍然存在。这个上下文层将存在于何处？它可以存在于多个地方吗？它会成为一个独立的产品吗？