北京
你最喜欢的那个大语言模型，现在支持100万token的上下文窗口了。宣传页面上到处写着：“能装下整部《哈利·波特》系列！两遍！还带脚注！”
一个拥有百万token上下文窗口的模型听起来很强——实际上它也的确很强。但这里有件事得先说清楚：一个模型有100万token上下文能力，意味着它能接收大量输入。至于它是否记得住、找得到、关联得上、或者正确使用这些信息，完全是另一回事。
这就是本文想拆解的核心问题：上下文容量和实际能力不是同一个概念。上下文长度=模型能接收多少信息，能力=模型能多好地运用这些信息。能塞进去，不代表能理解透彻。
“模型能读很多东西，那它自然能理解很多东西吧？”不一定。阅读≠准确记忆，阅读≠在关键时刻正确运用读到的所有内容。
那么，长上下文是坏事吗？当然不是。长上下文极其有用——它减少了激进的文本切块需求，对处理大型文档和庞大代码库很有帮助，也让很多工作流变得更顺畅。问题不出在长上下文本身，而在于人们期待长上下文同时完成完美记忆、完美检索、完美推理和完美摘要。现实世界的AI系统不是这么运作的。一套好的AI系统通常组合了长上下文、检索、记忆、摘要、结构化上下文和评估机制。
目前长上下文模型有三个已知问题值得关注。第一是“遗忘”，也叫“中间丢失”现象。关于长上下文模型的研究发现一个很有意思的规律：模型很擅长记住一大段输入的开头和结尾部分，对中间位置的内容却差得让人意外。如果你把那80页文档里最关键的一段文字埋在第40页的正中间，模型可能根本没注意到——尽管它技术上“读”过了。
第二是“大海捞针”式的遗漏。把一句特定的信息——比如“密钥是4471”——藏在一大堆文字里，然后让它找出来。有时候它精准命中，有时候却给一个自信满满的错误答案。token越多，草垛就越大，针能藏的地方也就越多。
第三是多跳推理的断裂。多跳推理意味着模型需要把散布在不同位置的多个事实串联起来——比如要同时关联第3页的事实A、第250页的事实B和第800页的事实C才能回答问题。事实链条拉得越长、位置越分散，模型就越可能在某个环节掉链子。更麻烦的是，它往往不会说“我不知道”，而是凭空编造一个听起来很合理的关联——也就是幻觉。
那有没有实际可用的应对方法？有的，这反而是本文更实用的一半内容。解决方案说起来简单：别再盲目信任，开始系统评估。在把模型放进你的应用或业务流程之前，针对你的长上下文使用场景做充分评估。相关消息显示，业内实践者正在强调：与其追求“更大的上下文窗口”这种听起来光鲜的方案，不如踏踏实实建立一套适合自己业务场景的评估体系。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
