更大的上下文窗口并未解决企业记忆问题——原因如下

每隔几个月就会有关于扩展上下文的新公告：128K、200K、100万tokens，其隐含的承诺是，你最终可以将整个公司的知识塞进上下文并获得完美的答案。然而，即使在非常大的上下文长度下，这并不能像人们预期的那样工作。原因如下。 问题1：检索质量随上下文长度下降。有确凿证据表明，与开头或结尾附近的信息相比，LLM从非常长的上下文中间可靠使用信息的能力会下降，这就是中间丢失问题。加倍上下文窗口并不能加倍可靠的工作记忆。 问题2：企业数据无法放入上下文窗口。一家中型公司的重要运营数据、合同、电子邮件、会议记录、内部政策很容易达到数百GB。即使上下文无限，你仍然面临选择问题：哪些tokens实际上与本次查询相关？ 问题3：原始文档是错误的表示。即使你能把所有内容都放入上下文，一个扁平的文档转储也无法编码使机构知识有用的关系和时间结构。对于大多数查询来说，2024年的合同修正案比2019年的基准更重要，但同样，如果没有明确的元数据，模型无法知道这一点。扩展上下文窗口无法解决核心问题。关键在于如何在检索之前就对知识进行建模。企业信息需要首先通过关系、意图和来源路径进行映射，这样模型接收到的信息已经是围绕意义和决策进行结构化处理的，而不是原始的文本块。 你可以在一些较新的知识层平台的定位中看到这一点：像60x、Glean或Kagi的内部搜索这样的工具，与其说它们像巨大的草稿本，不如说它们更像是对公司内部知识进行建模和路由的基础设施。它们底层仍然使用RAG和长上下文模型，但重点在于构建一个关于组织知道什么、信息在哪里、以及当信息冲突时哪个版本应该胜出的图表或模式。当你深入研究企业AI系统时，你会越发觉得真正的竞争发生在模型层之下。更大的窗口在边际上有帮助，但它们不能替代知识层。