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 智能体拉取数据语义层将提示中的意图转换为 SQLWiki 确保定义正确并确定数字的含义使用 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 债务问题别说我没警告过你原文链接AI 需要的上下文护城河 - 汇智网