Atlan 以企业上下文创造 AI 价值的主张，将关注点从模型转向更广阔领域
Atlan 正在挑战企业 AI 中“模型优先”的方法，认为即使系统能力强大，仍缺少完成有用工作所需的业务理解。10 月 28 日《MIT Technology Review Insights》的一篇文章聚焦以企业上下文创造 AI 价值，并将这一主张置于审视之下。问题在于，组织究竟需要新增一层基础设施、更好地管理既有知识，还是两者兼具。
这一论点本身也带有商业背景。该文章出自 MIT Technology Review 的定制内容部门，而非其编辑部新闻团队。Atlan 的会议材料表明，相关研究是与该公司合作完成的。在评估一项同时支撑供应商产品定位的诊断时，这种关系值得重视。
Microsoft 的 Work IQ 提供了一个有益的对照：另一家供应商同样围绕业务上下文构建其企业 AI 战略。核心张力并不止于供应商竞争。组织希望 AI 能够完成工作，但其定义、权限和运营规则往往仍需人工解释。购买模型访问权限并不能解决这些问题。
以企业上下文创造 AI 价值，超越模型本身
10 月 28 日的企业上下文分析通过 Atlan 所偏好的视角，呈现了一个常见的部署难题。AI 工具可以快速响应，却可能误解其服务的业务。Atlan 联合创始人 Prukalpa Sankar 认为，上下文基础设施能够帮助弥合这一缺口。
上下文层是一种基础设施，为 AI 系统提供业务定义、关系、政策以及解读公司数据所需的其他信息。这一概念之所以重要，是因为查找信息与理解其业务含义是不同的任务。一份文档可能包含答案，却无法说明该答案是否仍具权威性。
这一进展更像是关于企业 AI 价值来源的、更明确的商业论述，而非一项新近获得验证的技术突破。
这一区分有助于恰当地看待这则消息。该文章并未证明仅靠上下文基础设施就能带来更高的财务回报。它提出了对部署效果不佳的解释，以及应对问题的方向。买方应将这一解释与任何具体实施方案分开评估。
以一个销售流程为例。助手找到客户记录，汇总近期对话，并起草续约建议。每份检索到的文档单独来看都可能准确。但如果助手混淆了计费实体与其母公司，或忽略了一项已批准的例外情况，该建议仍可能失效。
更好的模型或许能够识别歧义，并提出有价值的问题。得到维护的业务定义则可能在生成开始前解决歧义。这两种方法相辅相成，但分别处理失败的不同环节。将每一次错误都视为模型问题，会掩盖这种差异。
因此，以企业上下文创造 AI 价值改变了采购对话。买方不应只问哪个系统能产出最强的答案，还必须问：什么使一项答案在其组织内部有效。这包括谁批准了底层规则，以及该规则最近一次变更是在何时。
这一发布关系同样值得关注。Atlan 的上下文研究活动推广了与该公司合作产出的研究早期访问内容。这支持将其论点视为供应商支持的、对这场讨论的一种贡献，但并不意味着应忽视其所指出的底层问题。
实际含义比宏大的销售叙事更为有限。上下文是企业 AI 失败的可信来源，但其重要性必须针对每个工作流程加以确认。组织仍需证明，拟议干预与可衡量的改进之间存在联系。缺少这种联系，上下文就会成为另一种难以验证的解释。
业务负责人承担 AI 可靠性问题
上下文论点不仅让技术团队承压，也让业务负责人面临压力。如果助手误解了一项已批准的政策，改变模型或许有帮助。但若各部门对政策本身存在分歧，组织就必须先解决该分歧，软件才能一致地应用这项政策。
企业 AI 使长期被忽视的知识所有权成为运营问题。
AI 开发人员可以连接文档库，却未必有权决定哪项政策优先于另一项。安全团队可以执行访问限制，却不能决定财务部门如何定义客户。这些责任彼此交叉，但并不属于同一个人。
这与安装一个对话界面相比，带来了不同的实施负担。必须有人识别权威来源、指定负责人、记录例外情况，并维护这些决定。这项工作可能暴露出员工过去通过非正式交流处理的分歧。自动化使这些分歧更难被搁置不管。
对于财务负责人，压力在于一致性。回答收入问题的助手需要采用恰当的会计定义、报告期和组织范围。一段流畅的解释无法弥补指标选错的问题。业务负责人必须让预期的解释可用且可审查。
对于服务负责人，压力在于适用性。智能体，即选择步骤或使用工具完成工作的 AI 系统，需要掌握相关客户情境。一项有效的退款政策可能因合同或地区而异。检索到通用政策只是决策的一部分。
这些例子仅用于说明，并非已报道的客户结果。它们说明了当软件从起草文字转向建议行动时，上下文所有权为何变得关键。错误的摘要会带来修正工作；错误的行动还可能形成需要由其他团队撤销的义务。
采购团队也面临相关挑战。上下文平台可以承诺提供统一定义，但合同无法保证各部门会就这些定义达成一致。买方需要区分供应商责任与组织责任。否则，基础设施采购可能掩盖一项尚未完成的运营决策。
知识工作者会在更小的尺度上遇到同样的问题。可搜索的档案库帮助人们定位材料，而权威知识库则确立哪些材料应当指导工作。当个人记忆影响共享决策时，个人知识与团队知识之间的区别便具有现实意义。
短期应对措施应与所处理的失败类型相匹配。缺少源材料需要更好的覆盖范围。定义冲突需要明确所有权并加以解决。推理错误则需要调整模型或应用。将这些类别合并为单一准确率评分，可能掩盖真正需要干预的位置。
随着时间推移，压力将转向维护。当产品、合同、团队和政策发生变化时，业务上下文也会变化。一项在上线时表现良好的部署，即使模型从未更新，也可能变得不可靠。因此，上下文论点也是对持续运营责任的一种主张。
Microsoft 展示了为何上下文正成为平台问题
Microsoft 提供了一个具体对照，因为它也将企业上下文描述为共享基础设施。在其 6 月 11 日对内部 Work IQ 使用情况的介绍中，该公司解释了组织信息如何支持更相关的 AI 响应。它将上下文视为助手周围环境的一部分。
Microsoft 表示，Work IQ 利用工作场所信号，并遵守现有权限。其内部示例包括将会议信息与参与者关联，以及将员工情境应用于指导建议。这些是公司自行报告的示例，而非对业务回报的独立衡量。但它们仍表明，一家供应商正在处理同一类总体问题。
竞争的关键在于，业务理解应存放在哪里，以及它能够在多大范围内被复用。
Microsoft 的工作场所智能方法描述了其工作场所环境内形成的上下文。Atlan 的论点则以跨系统提供业务理解为核心。即使两家供应商采用相似的语言，这些立场仍会给买方带来不同的问题。
对于集中使用特定软件环境的组织而言，嵌入其中的上下文可能是自然的起点。现有文档、身份信息和协作记录本就位于附近。买方仍需确认覆盖了哪些来源，以及由此得出的解释是否适用于该环境之外。
对于使用多个业务系统的组织，可复用性更加重要。为财务助手维护的一项定义，不应与运营助手使用的定义悄然发生偏离。共享上下文承诺减少这种重复。它能否实现，取决于集成和治理细节。
这并非集中式与分布式架构之间的简单竞争。架构是组件及其职责的安排方式。中央服务可能传播过时的定义，而特定应用的上下文则可能在有限范围内保持准确。仅凭位置无法决定质量。
更有用的比较关乎变更。当定义改变时，哪些应用会收到更新？当访问权限被撤销时，哪些已存储的表示形式会停止暴露该信息？当答案受到质疑时，审查人员能否重建所使用的来源和规则？这些问题将平台设计与运营后果联系起来。
可移植性同样值得关注。买方应询问，已批准的定义能否在工具之间迁移，同时不丢失所有权、版本历史或访问限制。导出文本比保留其权威性容易得多。一次保留了文字却丧失适用性的迁移，可能重现最初的问题。
因此，供应商对比支持一项更广泛的判断，却未证明任何一家供应商的方法更优。上下文正成为平台责任，因为多个应用需要相同的业务理解。这为共享基础设施创造了机会，同时也带来了让许多应用依赖同一个错误的风险。
对于买方，有效的应对方式是考察一个跨越真实组织边界的工作流程。局限于整齐文档集的演示，并未回答核心问题。关键证据在于，当信息在部门、应用和决策负责人之间流动时，上下文能否保持一致。
检索证据支持一项更狭窄的主张
检索增强生成（RAG）会在模型作答前检索相关信息并提供给模型。它是将生成式回答与外部知识连接起来的一种成熟方法。它的局限性有助于解释为何“企业上下文”这一论点受到关注。
Anthropic 在 2024 年 9 月发布的研究提供了一个技术示例。其 Contextual Retrieval 方法会在索引前为文档片段补充说明性信息，目的是保留当段落脱离原始文档后可能丢失的含义。
Anthropic 报告称，结合其上下文技术后，检索失败率降低了 49%；加入重排序后，降低了 67%。重排序是按相关性对检索材料重新排序的第二轮筛选步骤。这些结果来自该公司的评估，而不是对企业财务回报的测量。
更好的检索能够支持上下文论点，但并不能证明完整的企业上下文平台是必要的。
上下文检索研究解决的是一种具体失败：由于片段缺少周边语义，系统错过了相关信息。这与解决相互冲突的公司政策相比范围更窄，也比判断用户是否有权执行某项操作的范围更窄。
这一区别会影响采购决策。如果客服助手因为文档片段缺少识别细节而遗漏答案，检索能力的改进值得研究。若它找到了正确段落却错误应用，问题则出在别处。一项广泛的基础设施提案应说明它要解决的是哪一种失败。
一个说明性的合同案例能更清楚地展现这种区分。一段文字称某客户符合例外条件，但客户名称出现在前一页。保留这种关联可以改善检索。要确认该例外是否仍然有效，则还需要关于日期、修订和授权的额外信息。
因此，系统即使检索准确，仍可能给出错误的业务建议。反过来，采用范围有限且持续维护的信息源的工作流，也可能无需广泛的共享上下文服务便能表现良好。合适的干预措施取决于实际任务、其信息需求以及失败后果。
利用企业上下文创造 AI 价值，应通过这条依赖链来评估。信息源覆盖范围影响系统能找到什么；信息源解读影响它理解什么；决策规则影响它推荐什么；行动控制影响它能执行什么。一处改进并不自动意味着整体改进。
这一推理也改变了我们解读演示的方式。一次成功回答只能证明某个配置在特定条件下处理了某个问题，并不能证明其在各部门中的普遍可靠性。采购方需要的证据应包括模糊输入、变更后的政策和相互冲突的信息源。
最有力的技术论证会指出原始失败、上下文干预措施及其带来的差异。保持模型和任务可比，有助于分离真正发生变化的因素。将检索成功率与决策准确率分别报告，会使结果更易解读，并防止狭义收益被扩展为更广泛的主张。
更多上下文可能让错误答案传播得更远
怀疑论观点始于一个直接的问题：业务上下文可能是错误的。共享定义可能已过时、不完整或存在争议。持续提供这些定义可能让输出更一致，却仍然不正确。一致性是有用的证据，但不足以证明其真实性。
上下文层可以分发权威，却无法证明这种权威本身是正当的。
当组织将非正式知识转化为持续维护的规则时，这一点尤为重要。经验丰富的员工有时知道何时文档化流程并不适用于某种情形。将这种判断编码化，需要决定哪些例外是合理的。自动从一次对话中提取某项说法，并不能解决它是否应成为政策的问题。
会议参与者可能描述的是临时变通方案。另一名员工可能重复了过时的做法。项目文档可能记录了一项已被放弃的提案。每个信息源都提供信息，但其权威程度各不相同。将它们等同对待，会在生成开始之前就造成治理问题。
模型层面也存在局限。NIST 的生成式 AI 风险概览将“虚构”描述为一种特征性风险，即模型自信地生成虚假或错误内容。该机构还指出，生成的解释和引用可能误导用户。相关源材料并不能消除评估输出的必要性。
NIST 的分析支持对上下文论点采取审慎解读。更好的信息可以解决知识缺失，却不能保证推理正确。系统可能错误应用有效规则，或夸大不确定的推断。上下文质量与输出可靠性需要相关但不同的审查。
权限构成另一个压力点。员工能够阅读某份文档，并不必然意味着自动化系统有权依据其内容采取行动。上下文服务需要与管理下游操作的控制机制建立清晰关系。否则，准确的信息也可能支持未经授权的决策。
财务层面的论证同样仍不确定。维护定义、解决争议、检查权限和审查失败都会消耗员工时间。其中部分工作即使不使用 AI，也可能改善现有流程。采购方在评估部署的经济性时仍应将其纳入考虑。
一个组织可能获得更好的答案，却增加了产出这些答案所需的总工作量。另一个组织则可能大幅减少审查工作，从而证明大量维护投入是合理的。有意义的比较应涵盖整个工作流，而非仅看生成过程表面上的速度。这是一项分析要求，而不是源文章报告的结果。
利用企业上下文创造 AI 价值，也需要接受其局限。当政策冲突尚未解决时，有用的助手应揭示这种冲突。当授权不明确时，它应将决策恰当地转交处理。一个始终给出自信答案的系统，可能掩盖了上下文基础设施本应揭示的组织不确定性。
因此，怀疑论立场并不要求拒绝上下文投资。它要求更具体地说明这项投资改变了什么。供应商应明确哪些错误会变得更少、哪些责任仍由客户承担，以及哪些失败模式依然存在。这会使提案可被检验。
下一步证据应将上下文与已完成的工作联系起来
未来数月，最有价值的信号将与部署证据有关，而非新术语。10 月的讨论提出了一个明确命题：除了模型能力，业务理解也值得获得更多关注。下一步是确定这一命题在哪些场景能带来可衡量的收益。
当持续维护的业务知识能在变化条件下改善已完成工作时，上下文论点就会更有说服力。
第一个信号是在真实工作流中的有据可查比较。采购方应寻找展示明确上下文干预前后变化的结果。比较应包括信息源错误、决策错误、人工纠正和完成的任务。能够分离出改进因素的结果会加强这一论点。
只展示经过挑选的成功答案的演示，无法消除核心不确定性。同时改变模型、界面、信息源集合和审查流程的比较也是如此。这些变化可能改善产品，但会使企业上下文所作贡献难以分离。
下一个信号是业务变更后的可靠表现。政策修订、权限撤销或客户改名，都提供了有用的观察点。系统能否在受影响的应用中采纳变更？它是否保留了足够的历史记录来解释先前答案？一致的表现将支持共享基础设施的论点。
持续存在的矛盾将削弱这一论点。如果每个应用仍需人工修复，所提议的通用层就没有消除重复维护。如果过时信息仍留存在派生存储中，组织需要了解修正如何传播。初始设置的质量无法回答这些问题。
最后一个信号是总运营负担。组织应考察，在计入上下文维护后，审查人员是否花更少时间纠正输出。他们还应跟踪未解决案例是否被送达合适的人员。如果隐性的准备工作增长更快，可见审查工作的减少意义不大。
这些信号并不取决于某一家特定供应商获胜。Microsoft、Atlan 和应用开发者都可以通过不同方法提供证据。有用的区分在于：一类是对可用能力的主张，另一类是对持续使用的观察。采购方两者都需要，但不应将其混淆。
对于知识工作者而言，眼前的关联很实际。知道信息存放位置的助手可以节省搜索时间；理解哪些信息适用的助手则可以支持决策。这种额外理解的价值，取决于用户能否检查、质疑并维护它。
从一个错误答案会造成可识别返工的工作流开始。与拥有底层政策的人一起审查失败案例，而不是将每次纠正都视为提示词问题。将信息缺失与定义冲突、推理错误及不当行动区分开来。然后考察所提议的上下文投资是否解决了这些具体失败。对于个人工作，持续维护的个人知识系统可以帮助整理相关材料，而共享决策仍需要共享权威。当这种区分在部署后依然成立时，利用企业上下文创造 AI 价值才会成为可信命题。请下一家供应商展示其系统如何处理一项变更规则、一个存在争议的信息源，以及一个它应当保留为未决的问题。
