原文:How the context layer creates enterprise ROI

作者:Travis Kassay, Jack Rohrer, Jared Brickman · Insight Onsite

来源:SandHill.io #302 推荐阅读 · Industry | RecodeX 编译

AI 账单到了。两年工具采购与 token 燃烧之后,董事会问一个简单问题:我们实际得到了什么?

答案复杂。PwC 发现 56% CEO 报告 AI 无显著财务收益。但 WRITER* 发现 92% 公司看到个人生产力提升,而只有 29% 报告显著组织 ROI。对企业意味着什么?个人贡献者更快了,但组织没变。更进一步,工具工作正常,却没有任何对它们所在业务的共享理解。那不是 AI 问题。是上下文问题。

本文来自 Insight 的 Onsite Hour 上下文层系列——由 Insight 100+ 内部专家为投资组合公司创建的每周虚拟活动系列,包括 Travis Kassay、Jack Rohrer 与 Jared Brickman 主持的场次。

我们处于 AI 时代的第三阶段

第一阶段是 AI 命令。董事会说“做 AI”。人人匆忙。

第二阶段是 tokenmaxxing。每个职能需要 AI 计划,于是团队买工具、烧 token。排行榜出现。用量指标攀升。

现在我们进入第三阶段:ROI 在哪?账单到了。影响是临时的,非企业级。个人贡献者更高效。但组织整体运作方式没变。

多数团队获得个人生产力收益,但上下文层才是把那变成企业收益的东西。

上下文层实际是什么

上下文层坐在你 AI 栈中间。下面是数据:CRM、数据仓库、ERP。上面是 AI 工具:实际做工作的助理、Agent 与自动化。上下文层从你的系统读取并写回。每个工具从同一真相源汲取。“想想你第一天最好的新员工,”Kassay 说。“绝对聪明,但约一个月没用,因为没有上下文。今天每个 AI 会话都是那个新员工,多数公司每次会话从零重新简报他们。”

“今天每个 AI 会话都是那个新员工,多数公司每次会话从零重新简报他们。”

没有它,失败模式可预测。想象一个战略账户进入 90 天续约窗口。你派 AI Agent 调查并建续约计划。因为没有上下文层,Agent 直接去原始记录——CRM、支持系统、产品用量数据——试图拼出图景。数据不一致。Agent“临时编造 ARR 定义,意外包含服务收入,”Brickman 描述。“它把测试用户解释为活跃用户。它重新推理一堆东西,拉取通话记录并从零重写续约 playbook。”产出与财务 Agent 或客户管理会说的不匹配。它活在自己的泡泡里。

“失败不是 Agent 缺乏数据访问,”Brickman 说。“是它缺乏对业务的预备理解。”

上下文层如何复利

Insight Partners 在投资组合中观察到一种模式:两个公司同一用例——交易辅导与分析——做非常不同的押注。

第一家买单点方案。往往互相矛盾的断开工具。按席位定价很快变贵,仅单一供应商就数百万。部署快,但对跨职能任务盲目,并被供应商产品路线图封顶。新用例需要新合同。

第二家投资上下文层。一个统一层喂每个工具。Agent 与技能执行用例。内部构建,用现有工程产能。每个新用例建立在上一个之上。

Atlan 联合创始人兼联合 CEO Prukalpa Sankar 与客户(包括大企业)花了 18 个月构建上下文层,很好地概括了动态:“我们在建单星球员 Agent。但梦之队从不建在单星上。梦之队实际建在共享上下文上——共享知识、共享专业知识、共享学习循环。”

单点方案按席位租能力。上下文层复利。优势随每个添加的用例增长。如 Tricentis 首席架构师 Jakob Marsala 指出,财务理由不只关乎用例:“每次推理循环运行,都在烧 token,那是失控 AI 支出。你越能把那类东西左移,也是非常快的财务节省。”

上下文层里面有什么

上下文层有四个组件:知识库、知识图谱、词汇表与记忆。治理把它们粘在一起。“陷阱是避免营销建自己的知识库、销售建自己的、产品建自己的,”Rohrer 解释。“那只是在公司内重现我们历史上有过的同样问题与孤岛,所以你要从第一天起朝一个共享地方构建。”

知识库。 你公司的知识,写下来并组织好,以便 AI 使用。想想你会在第一天交给新员工的一切——公司身份、理想客户画像(ICP)定义、产品概述、品牌声音、竞争卡片。格式重要:不是 PDF 与电子表格,而是例行更新的结构化 markdown 文件。最佳实践按范围组织:组织级、职能级、用户级。早期知识库可能是整个上下文层,那是很好的起点。

知识图谱。 业务中事物如何连接的地图。不是数据本身,而是关系:客户 → 合同 → 负责人 → 续约日。有了图谱,AI 可跨业务推理,而非只从单一系统返回摘要答案。你的 CRM 与数据目录已是丰富起点。

词汇表。 你公司的词典。什么算 ARR、线索、流失、赢回?数字不一致时哪个系统赢?Marsala 解释:“人人有一种做 ARR 的方式,然后有你业务做的方式。Claude、OpenAI——大概不会知道那意味着什么。”

词汇表防止 AI 自信地对错误定义跑分析,并充当语义层。

记忆。 让 AI 保留所学而非每次会话重来。决策、纠正与结果被写回。每次交互使下一次更聪明。开始简单;例如,维护良好的决策日志就有效。最终 AI 自行写回所学。

治理。 保持其他一切为真的所有权与维护。没有所有者的上下文默认会过期。每个文件需要具名所有者与更新节奏,有清晰触发:定价变更、大客户丢失、产品发布。

端到端上下文层长什么样

触发甚至到来之前,CRM 已被挖掘并经统一本体拉取。续约风险 playbook 已组装。账户简报技能精确定义 Agent 应从知识库拉取什么——客户细分、产品定义、业务规则——以及与实时数据联结什么:近期支持问题、近期通话关键人物、当前用量趋势。

Agent 读知识库、遍历知识图谱、查词汇表,起草每条主张可追溯到来源的简报。销售代表审阅。“太长——给我一页要点。”那偏好写入记忆。下次她不要求就得到一页要点。

“别让 Agent 每次运行从原始记录重新发现业务,”Brickman 总结。“让 Agent 把运行时花在推理什么变了、该做什么上。”

“别让 Agent 每次运行从原始记录重新发现业务。”

每次交互使下一次更好。在 Atlan,Sankar 报告实施上下文层后客户 token 成本最多改善 75%,并对准确性有“巨大影响”。与 apiphani* 首席总监 James Kendrick 合作的一家大型能源公司描述了预先构建上下文基础设施的复利效应:产品以 30% 成本、快 90% 发布,AI 项目通过用结构化上下文丰富数据目录至少提前三个月。“它显然使我们的项目至少提前 3 个月进入 AI 世界,”他解释。

从哪里开始构建上下文层

专家在序列上一致:别等架构完美。上下文层是进展,不是前提。

Insight 团队把它框为三阶段成熟之旅,各有现实到价值时间:

阶段 1:知识库(数天到价值)。 从你会第一天交给新员工的东西开始:公司身份、产品概述、ICP 定义、竞争卡片。用结构化 markdown 写。按范围组织:组织级、职能级、用户级。给每个文件具名所有者与审查节奏,有清晰触发。那单一产物,加载进你用的任何 AI 工具,将改善产出相关性与准确性。早期这可能是整个上下文层,那是很好的起点。

阶段 2:数据库支持的检索(数周到数月)。 添加真正检索层:让 AI 跨数据资产搜索而非依赖静态文件的向量数据库。产品文档与代码库索引是强起点:准确产品知识跨组织可查询,并随你发布保持更新。这是使知识库动态的一步。

阶段 3:上下文操作系统(数月)。 完全成熟层,有版本化知识图谱、治理记忆、实时数据馈送与自主写回。每次交互使系统更聪明。每个新用例建立在上一个之上。

风险,如 Marsala 所学,是从错误的东西开始。“数据不是赋能;数据是熵,”他说。“AI 使每个人成为热心开发者,从事影子 IT。”他从推出 Tricentis AI Business Studio 的来之不易教训:开始构建前把发现做对,把细粒度定制当作阶段三问题,而非阶段一野心。

* 编者注:Insight Partners 投资了 apiphani、Tricentis、WRITER 与 Atlan。

本文由 RecodeX 编译自 How the context layer creates enterprise ROI(作者:Travis Kassay, Jack Rohrer, Jared Brickman · Insight Onsite),首发于 SandHill.io #302 推荐阅读。译文仅供学习交流,观点不代表本站立场,版权归原作者所有。