最初发布于 拉夫克什.com
我还记得一年前，当模型能够在上下文中容纳一百万个词元时的那种兴奋。这大约相当于七十五万个单词，或者十本普通小说的内容塞进单个提示中。演示效果令人印象深刻，研究人员也发布了基准测试结果，但不久后，各团队意识到，拥有巨大的上下文窗口与知道如何利用它是两个截然不同的问题。
我并非否定这种能力；在上下文中容纳一百万个词元是一项真正的技术成就。然而，我认为目前有一种观点将窗口大小视为终点线，这一点值得反驳。
我所看到的常见模式是，一个团队获得了长上下文模型的访问权限，加载大型文档或代码库，发送查询，然后返回的结果尚可，有时不错，但往往难以诊断，令人沮丧。从技术上讲，模型看到了提示中的所有内容，但它是否使用了正确的部分则是另一个完全不同的问题。
研究人员已经发现了一种称为“中间迷失”的现象，即模型倾向于对上下文窗口开头和结尾的内容给予不成比例的关注，而低估中间部分的材料。因此，如果你输入一份两百页的文档，而关键细节位于第九十四页，你可能无法得到想要的答案。
这就是为什么即使上下文窗口不断增大，检索增强生成（RAG）也没有消失的原因。针对性检索让你能更好地控制模型处理的内容，从而产生更一致的结果。然而，RAG 也引入了自身的一系列问题，例如维护分块策略、嵌入模型、向量存储和检索管道。
长上下文确实能很好地处理特定类型的任务，在这些任务中，信号并不集中在某一个地方，且文档各部分之间的关系至关重要。例如，审查整个代码仓库中的代码、分析合同或总结长篇研究转录稿。
成本维度也值得坦诚讨论。长上下文推理成本高昂，输入词元的费用迅速累积。许多团队经历了对长上下文的热情阶段，进行了成本建模，然后悄悄地回归到基于检索的方法，因为后者更经济且可预测。
此外还有延迟因素；长提示需要更长的处理时间，为交互式应用程序增加了摩擦。对于批量工作流而言，这一点影响较小，但它是另一个不会出现在基准测试数据中的变量。
这项能力正在向前发展，上下文窗口不断增大，模型也在更好地利用其中的内容。目前正积极研究如何改善中间上下文的注意力机制，并帮助模型更可靠地处理长输入。
目前，规格参数表与实际生产中可依赖的表现之间存在显著差距。从事最有趣工作的团队并未将大上下文窗口视为已解决的输入问题；他们谨慎地选择输入内容，并为长上下文的失败模式构建评估管道。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
