LLM 中的长上下文窗口具有欺骗性（迷失在中间问题）🧐
OpenAI 和 Anthropico 似乎在过去一年多的时间里一直在争夺上下文窗口的控制权。
2023 年 5 月，Anthropic 激动地宣布：“我们已将 Claude 的上下文窗口从 9K 扩展到100K 个标记，相当于大约 75,000 个单词！”
（注：75,000字约合300页）
为了不甘示弱，OpenAI 于 2023 年 11 月发布了其128K上下文窗口。
直到 2024 年 3 月，Anthropic 的20 万个上下文窗口才使其寡不敌众。
这种为了调整上下文窗口大小而反复拉锯的争论真的有必要吗？
什么是上下文窗口？
上下文窗口是指 LLM 在生成信息时可以处理的围绕目标标记（一个标记是指一个词）的文本范围。
人们通常认为，上下文窗口越大，可以输入的文本就越多，例如，就可以进行搜索。
然而，LLM 中的长上下文窗口具有误导性，因为许多用户认为，如果上下文窗口足够大，就不需要 RAG。
迷失在中间的问题
然而，研究和实验表明，LLM 中较长的上下文窗口在查找特定事实或文本时会带来挑战。
对我来说，这个问题最生动的例证出现在这个 YouTube 视频中。
在这里，实验者仅使用 2k 个词元的上下文长度（请记住 GPT-4 的词元限制为 128k 个），来搜索中间的简单句子，该句子内容为：
“星场理论使人们对非天体现象有了正常的理解。”
你猜怎么着？大约三分之二的模型都无法通过这项测试！它们竟然无法在仅有的 2000 个词元中找到这句话！
赢家和输家
🏆 以下是通过2k 上下文窗口测试的模型列表：ChatGPT Turbo、Open Hermes 2.5 - Mistral 7B、Mistral 7b Instruct（在 10:43 通过一次，在 3:47 失败一次）以及 Yi 34B Chat
👎 以下是测试未通过的型号列表：Mixtral 8x7B Instruct、Mistral Medium、Claude 2.0、GPT 4 Turbo、Gemini、Mistral 7B Instruct、Zephyr 7B Beta、PPIX 70B、Starling 7B - alpha、Llama 2 - 70B chat、Vicuna 33B 和 Mixtral 8x7B Instruct
使用 RAG 进行相同的实验
现在我要简单介绍一下我自己——我是一个开源项目的创始人，我们在该项目中也制作 Hugging Face 模型，以及一个名为 LLMWare 的基于 LLM 的工作流程平台。
我受到启发，决定重现这个实验，于是我们制作了一份关于天体物理学的文档，其中包含大约 11,000 个标记（远多于 2,000 个），在文档中间的某个地方添加了正在查询的句子“天体场创造了对非天体现象的正常理解”，并在我们的 LLMWare 平台上运行了 RAG。
然后我们用 3 款机型进行了测试——LLMWare BLING Tiny Llama 1.1B、LLMWare DRAGON Yi-6b 以及 Zephyr 7B Beta（该机型在 YT 视频中测试失败）。
以下是一些结果截图。正如你所看到的，通过 RAG 算法和微调，即使是 11 亿字节的模型也能找到答案。
LLMWare Bling Tiny Llama 1.1B：
轻松找到此内容。💯
LLMWare 龙易 6B：
也能轻松找到此内容。💯
Zephyr 7B Beta（未针对 RAG 进行微调，因此日志输出略多，但仍然能够找到之前无法找到的 RAG 目标）：
教训：大型上下文窗口在搜索中效率低下。
从我们的实验可以看出，即使是最小的 10 亿参数模型，在基于事实的 RAG 搜索中也能比 GPT-4 Turbo 表现更好。如果配合合适的 RAG 工作流程，使用小型模型进行 RAG 搜索远比仅仅依赖较大的（或者像本例中只有 2000 个词元的）上下文窗口要好得多。
我希望这次实验能凸显基于 RAG 的良好 LLM 工作流程的重要性。如果您想了解 RAG，这里有一篇我最近在 Dev.to 上发表的文章，可以帮助您入门。
所以，下次如果有人试图仅凭一个很长的上下文窗口就给你留下深刻印象时，请仔细查看周围的工作流程，以确保你得到了想要的答案。
请加入我们的 LLMWare Discord 社群，了解更多关于 RAG 和 LLM 的信息！https://discord.gg/5mx42AGbHm
请访问我们的网站llmware.ai了解更多信息和最新动态。
文章来源：https://dev.to/llmware/why-long-context-windows-for-llms-can-be-deceptive-lost-in-the-middle-problem-oj2