AI 需要的上下文护城河
无论你喜不喜欢，AI 已经来了。
虽然看起来好像每个人都在用他们的新 AI 智能体或工具大杀四方，好吧，其实并没有。
原因有很多，其中很多我已经写过了：
- 匆促的实施
- 缺乏培训
- 糟糕的变革管理
- 没有治理或护栏
- 技术优先于流程和人
但说实话，阻碍大多数组织 AI 进步的主要原因是他们的人工智能实际上并不智能。
为什么？从我的角度来看，归结于缺乏上下文。
AI 建立在大量数据之上，所有这些数据即使在最好的模型中也会产生一种普遍的噪音感。就像创造了一个有史以来最聪明的存在，它对什么都了解很多，但对某一个特定事情了解不多。
正是那个特定的事情——那个上下文——才是真正驱动你组织中 AI 质量的力量。
因此，建立在上周对 AI 战略的重新定位基础上，作为一个双轨战略实施过程，我们要探讨数据与 AI 生态系统中你需要了解的下一个关键概念——上下文层。
1、AI 世界，上下文碎片化日益严重
我与每位数据领导者的每一次对话都以一个共同的问题开始：数据在整个组织中是孤立的和碎片化的，KPI 或标准没有统一的定义。
好吧，这是两个问题。但你明白我的意思……
即使公司已经在"现代数据栈"上投入了数百万美元，数据和知识仍然分散在 dbt 模型、BI 语义层、仪表板、Notion 页面、Slack 线程，以及（最大的罪魁祸首）高级分析师和业务利益相关者的头脑中。除非你做得非常好，否则这些来源中很少有彼此通信的。而且——在这个 AI 实施的新时代——几乎没有一个能以有凝聚力的方式与你组织刚刚接入的 AI 工具对话。
虽然人们似乎认为 Claude Code、Cursor 或 GPT Codex 是魔法，但事实是这样的：MCP 连接器、插件和智能体并不能解决碎片化问题。它们暴露了它。
我对此的反对意见通常是："当然，但我们过去三年一直在把所有东西统一到 Snowflake / BigQuery / Databricks 中。数据在一个地方。把智能体指向仓库就行了。"
如果真那么简单就好了。统一的仓库解决了物理碎片化，但没有解决语义碎片化。智能体仍然不知道你的六个收入列中哪一个是财务实际报告使用的。它不知道哪些连接是安全的，哪些连接会在客户有两个地址时悄悄地将订单重复计算。它不知道"活跃客户"对营销团队和对 CFO 意味着不同的东西。仓库告诉智能体哪些表存在。它不告诉智能体应该信任什么。
无论智能体指向五个不连接的来源还是一个统一的仓库，结果都是一样的：没有正确上下文的自信答案。 从我的角度来看，这比没有答案更糟，因为用户会信任它。
顺便说一下，这些用户不再只是数据分析师，而是高级主管或领导者。嵌入式 AI 意味着每个人都可以与数据交互并获得快速、自信的回答。非数据的业务用户可能会假设底层管道是连通的，数据质量是高的。然而，更可能的结果是上下文已过时、不完整或不适用，而现在它直接连接到业务决策中，却没有确保其准确性。
现实是这样的：孤立的数据和知识是阻碍大多数组织 AI 发展的因素。
不是模型质量。不是算力。是上下文。 你可能更有生产力了，但如果你的工作输出在上下文上不正确，那这还算是生产力吗？而且出错的代价已经开始在输出准确性和质量失败中显现了。
正在兴起以解决这个问题的类别是上下文层。虽然大多数早期工具是闭源的或附加在现有 BI 产品上的，但有一个值得信赖的名为 ktx 的开源选项，我将在本文后面深入探讨。
2、从 AI 战略到上下文 AI
我最近与一家中型消费品公司的 CEO 会面。他一直在尽一切可能阅读关于 AI 的内容，想知道如何战略性地实施它。他的第一个问题是什么？
"我应该用什么模型？"
我们已经讨论过工具不是战略，特别是对于 AI。实际上，我认为过去 30 年来这个观点已经被反复提及。尽管如此，这仍然是每位高管都在问的问题。
而且你确实无法避免。每位高管都想要一个能提供即时收益的工具或解决方案。这就是为什么他们总是关注技术角度。
那么中间立场是什么？好吧，正如我上周所写的，那就是从纯粹的 AI 战略思维转变为 AI 战略实施思维，在你积极地将 AI 嵌入到战略讨论的同时推进。事实上，这就是我与那位 CEO 找到的中间立场：我正在帮助使用他们已经购买的工具开发 AI 流程和工作流，同时概述更长期的运营 AI 路线图。这样一来，AI 不只是一份战略文件或一个独立附加的工具；它找到了理想的中间地带，你立即看到了价值。
但这种方法还需要一个额外的层面才能真正成功——业务的底层上下文。
在当今世界中，上下文就是王道。它是 KPI、数据库模式、指标定义和业务规则。
问题在于，上下文历来存在于个人的头脑中，需要几十次访谈、会议或研讨会才能提取关键信息。如果我们想大规模嵌入 AI，让这种上下文达到可用状态是很困难的。因为无论我们怎么努力，单一真相来源并不存在。 而且这不是把你的 AI 接到数据库上就算完事。
相反，你需要开始思考上下文 AI：从不同来源构建一个意义层，让 AI 开发出一个能够支持所有 AI 工作流的基础理解，同时从中学习。
你可以自己推断其中的好处，但我只想说一点：这些好处不局限于你的数据团队或智能 AI 用户。上下文帮助每个人更聪明地工作，这不就是我们想要从 AI 中得到的吗？如果你的上下文不正确，那不就消除了 AI 的好处，导致不信任了吗？
我的朋友们，这就是为什么每个人目前都对上下文层着迷，它是在你的组织中实现规模化上下文的工具。 你们知道我不是一个大型工具推广者，但这个不是炒作。它是公司需要的下一个基础组件。也是决定 AI 是否在你的组织中提供可靠价值，还是快速产生泛化答案（可能对也可能不对）的那个组件。
3、什么是上下文层？
直接的定义：上下文层是位于你的数据栈和查询它的智能体之间的受信任的知识面。它捕获业务对数据的实际含义（例如指标、连接、定义、注意事项），并将这些含义提供给任何提出要求的 AI 工具或员工。
随着一切都在向组织使用智能体的方向发展（事实确实如此），需要一个被管理的连接来确保智能体拉取正确的信息。否则，你会得到一个意义的蛮荒西部（我现在在大多数组织中都看到了这种情况，在没有正确的上下文架构的情况下匆忙实施 AI）。
上下文分层的概念并不新鲜。每个组织可能都有一些帮助促进这一过程的工具，如 Confluence、Jira、Word 文档、Notion 等。然而，这些工具是为人类构建的，不是为 AI 构建的。而且你可以肯定，组织和维护它们从来都不是任何组织的强项。
现在存在的软件帮助把这些东西整合在一起并呈现公认的/官方指标，哪些连接是安全的，业务对"活跃客户"等术语的实际含义是什么，同时显示每个定义来自哪里。没有它，AI 智能体将不会反映现实（那么，AI 驱动的工作流还有什么意义？）。
那么上下文层如何帮助解决这个问题呢？它有三个组件：
语义层（结构化知识）： 这些是表、列、连接、度量、维度、分段、验证规则等，全部通过经过审查的 YAML 文件整合在一起，创建关于你的数据是什么的模式层面的真相。它作为统一的业务层，帮助标准化定义和 KPI，将你的意图编译为 SQL 以查询你的请求。基本上，你的 AI 智能体声明"是什么"（"显示新产品 X 本月的收入"），语义层定义"怎么做"（连接哪些表、如何聚合数据、仓库的具体语法、如何保持数据干净/高质量）。许多数据团队已经在他们的 BI 工具中手动完成了这项工作，但它被卡在上游太远的地方，无法在组织中获得可信度或可复用性。一个合适的语义层将其从 BI 工具中拉出来，放入一个任何工具都可以查询的被治理模型中，从而提高任何数据请求（通过 SQL 或 LLM 查询）的准确性。
Wiki（非结构化知识）： 这个上下文层组件处理散文部分；组织组织中持有的大量非结构化数据来定义业务术语、指标、报告策略，汇总仪表板注释，提供团队特定的上下文等。这些存储为 Markdown 页面，智能体可以搜索并跟踪引用（个人也可以访问和验证）。在幕后，检索使用混合管道（关键词搜索 + 语义嵌入 + 术语重叠回退），因此同义词、改述和不熟悉的措辞都能找到正确的页面。对于使用 Notion、Slack 或任何有入职文档的公司（所以……每家公司），这是实际业务推理被捕获并使智能体（或员工通过 AI 聊天界面）可以查询的地方。这意味着这种企业级搜索不需要一次又一次地手动进行。
审计追踪（来源/血缘）： 要信任上下文，你需要看到它来自哪里。来源是证明和证据的来源（例如原始源快照、搜索索引、回溯到原始来源的引用）。我见过的最强模式是将来源编织到其他两个组件中，而不是作为单独的文档维护。通过你的 AI 界面，你可以问"这个数字到底来自哪里？"并得到答案，无论是来自数据仓库的引用、wiki 中的指标定义还是指向其主要来源的链接。正如 ktx 团队在其审查指南中所说：wiki 页面引用证据，不重复 YAML。这是你在评估上下文基础设施时要寻找的设计模式，因为它使审计追踪真实化，减少持续维护，并在幻觉和准确性是常见现实的 AI 输出中建立信任。
现在，这些东西都已经存在了一段时间，但将它们整合在一起为智能 AI 使用才是真正的价值所在。想想看：业务利益相关者正在积极地查询他们的 Claude、ChatGPT 或 Copilot，这些工具正在运行 Python 或 SQL 引擎从主数据库拉取信息。
没有上下文层，AI 智能体可能用错误的定义查询数字。或者使用公司 Notion 找到上下文，但并不真正理解如何正确查询仓库。
一个正确构建的上下文层以 AI 应该工作的方式将这些东西组合在一起：
- 销售副总裁想了解团队是否达到了某款新产品本月的销售目标
- 他们让 AI 智能体拉取数据
- 语义层将提示中的意图转换为 SQL
- Wiki 确保定义正确并确定数字的含义，使用 AI 工具提供任何额外的洞察和影响
- 来源提供数据和定义的审计追踪，以便副总裁可以验证这些数字
- 副总裁对自己的数字感到自信（全部在几分钟内完成，而不是几小时或几天）
所以这不是关于你的新 AI 模型更好或更快；它是关于添加上下文使其基于你自己的业务上下文变得更聪明和更有影响力。
如果没有所有三个组件，你只有部分上下文。而部分上下文产生部分准确性，这在当今的 AI 环境中是不够的。
4、通向上下文 AI 的路径
这仍然是一个非常快速发展的领域，大多数公司不确定在他们的 AI 工具或上下文层方面应该走向何方。然而，我想说这种不确定性不应该导致公司暂停投资于上下文层。恰恰相反；他们需要在为时已晚之前设置它，否则会有太多遗留的 AI 债务，以至于撤销旧上下文变得不可能。
我讨厌供应商锁定，而这是一个供应商锁定可能非常危险的领域（因为你连接了太多的数据和工具）。
所以 Kaelio 很高兴能与我合作这篇文章，这简直太完美了。在意识到 AI 世界的走向后，Kaelio 团队构建并开源了 ktx，一个专门为 AI 智能体构建的上下文层。 它是免费的，采用 Apache 2.0 协议，你用一条命令就能安装，让你立即连接到你的结构化数据库（Postgres、Snowflake、BigQuery、MySQL 等）、dbt 模型、语义层工具（MetricFlow、LookML）以及 Notion 中的非结构化知识。
由于大多数公司仍在涉入智能 AI 的世界，很多还没准备好签约一个昂贵的语义或上下文层工具，这让开源成为完美的解决方案。 如上所述，你需要一个被跟踪的上下文仓库，你的 AI 智能体可以通过 MCP 或 CLI 查询它，以确保输出的准确性和相关性，这就是 ktx 免费开箱即用为你提供的。
5、为什么上下文是新的护城河
人们最近经常谈论护城河（保护 AI 企业免受竞争对手影响的可持续竞争优势）。
好吧，我想以声明我的观点来结束这篇文章：上下文是你公司的护城河！但要做到这一点，你需要将其嵌入到你 AI 驱动的业务运营方式中。
这来自我在 AI 领域看到的三个趋势：
基础模型成本将上升，而不是下降： 对于 OpenAI 和 Anthropic，我们开始看到价格上涨和使用限制。更不用说，随着组织中越来越多的人使用 AI，总支出将随着使用量的增加而上升。如果这些查询在没有上下文的情况下运行，智能体会在数据库查询上浪费更多的 token，然后重试、自我怀疑，或者产生错误答案然后被重新运行。智能体预先拥有的上下文越多，它浪费的 token 就越少，第一次答案正确的频率就越高。
人们正在变得依赖 AI： 我见过很多高级领导团队说他们更有生产力了，但正在依赖将工作交给 AI。这导致了大量次优的输出。这是不可持续的，企业会开始注意到。但他们不会想回到手动工作，他们会希望公司的 AI 智能体更聪明，产生更高质量的输出。因此，需要上下文层。无论公司知不知道（大多数还不知道），这就是 AI 工作的方向。
智能体变得更强大，责任增加： 这在前一点的基础上展开，但角度不同。公司开始为智能 AI 的企业计划投入真金白银。既然智能体现在能够推理、熟练地写作、执行代码、调用工具并链接复杂的工作流，期望也在增加。当它们表现不佳时，领导层首先会寻找的将是另一个工具（不幸的是，他们不会考虑培训或重新创建流程）。那个工具就是上下文层，因为让上下文隐式地融入这些智能体的工作方式将是通往价值的最快路径。
所以我的观点是，如果公司想要嵌入 AI 并成为真正的 AI 原生企业，他们的技术投资（除了流程和人之外）应该从 token 最大化转向上下文最大化。 这才是持久优势所在，也是未来五年分析投资的方向。
如果我们朝这个方向走，什么是好的样子？从我看到的来看，强上下文基础设施的属性是：
- 跨栈的统一集成——将数据库、转换工具、语义层和知识文档/来源的所有内容整合在一起。这种可移植性至关重要，因为大多数组织拥有所有这些数据源，但几乎没有一个能彼此通信。
- 版本控制和本地化——Git 支持的，所以上下文像代码一样演进。通过为指标定义设置拉取请求或变更的审计追踪，你已经为 AI 嵌入了上下文治理。
- 智能体无关性——人们使用多个模型，所以通过 MCP 和 CLI 暴露你的上下文层允许任何智能体接入。不要让 AI 成为另一个供应商锁定策略。而且你不想每次智能体格局变化时都重建你的上下文（AI 版本的数据迁移）。
- 开源——我相信上下文基础设施是你需要测试和试验以确定它是否适合你的东西。如果工具是一个黑盒，你怎么知道它运作良好？
- 结构化和非结构化结合——在设置这个时，你必须超越语义层来思考（它们没有独立普及是有原因的）。Wiki 层——非结构化数据——是业务推理所在的地方，所以要确保将其嵌入以获得你需要的准确性。
- 被治理和更新的上下文——与清晰、确定性的护栏集成，防止上下文过时。上下文层只有在它是真实的时候才有用。当它开始偏离业务的实际运作方式时，下游的 AI 智能体就会变得更差（尽管它们一样自信）。
关于如何构建这个的一个例子是 Gladia，一家音频 AI 基础设施公司。作为 AI 原生公司，他们想以更直接的方式做 BI，但遇到了准确性问题。当他们直接将智能体指向仓库（BigQuery）来回答业务问题时，输出是不可靠的——这是许多公司在生产中经历的同样的语义碎片化失败。主要问题是智能体不知道哪些指标是可信的，哪些连接是有效的，或者业务对这些东西的实际含义是什么。ktx 上下文层帮助为他们提供了一个更受治理的、语义感知的路径，智能体通过上下文层而不是原始仓库进行查询。
你可能会怀疑我在这里试图向你推销什么，但实际上，我唯一想推销给你的就是上下文 AI 是未来。我现在在自己的机器上使用 ktx，虽然我没有使用大量数据，但我的生活轻松多了。相信我，我做咨询、写书、写通讯、发 LinkedIn 帖子等等，所以组织我的上下文并与我的 Claude Code 对齐对我来说保持生产力和避免倦怠至关重要。
归根结底，你不应该用更多的提示词或 token 最大化来解决 AI 幻觉或智能体准确性问题。相反，在所有你有价值的现有数据之上，为未来构建正确的上下文基础。如果你在几年后遇到了"AI 债务"问题，别说我没警告过你！
原文链接：Issue #60 – The Context Moat AI Needs
汇智网翻译整理，转载请标明出处