GPT4-Turbor 128k ？ 还不够？还不够！
本篇通译自：dev.to/maximsaplin…
OpenAI 去年11月 推出的GPT-4 Turbo模型，具有128K的上下文窗口，这比此前 GPT4 的最大上下文值 32K 提升了四倍。
128K 上下文提示语，是一个什么样的概念？
这个大小可以容纳 1684 条推文或 123 个 StackOverflow 问题；
但却只有 Linux 内核中最大的源文件的 1/540 。
这里带来了一些数据对比，看看 128K 能容纳哪些内容：
完整的对比数据在这里：docs.google.com
核心观点
所以，先来阐述一下本篇文章的核心观点：
- 目前 128K 的上下文对于许多实际处理任务来说仍然不够
- 它勉强能够容纳单个网页的原始HTML，或者搜索一个复杂知识的文档内容。
- RAG（检索增强生成）是一种解决方案，但输入的文本片段不足以支撑检索复杂知识库，它们可能是无序的、不相关的。
- 不能期望 100% 的上下文窗口内容都能被有效利用，在达到 50% 的时候，LLM 的性能就开始下降。
- 提升上下文窗口容量（10-100倍）或扩充多模态，可能是一种前进的方向。
文本的转换问题
LLM 大型语言模型只能处理文本，虽然可以通过多种方式可以将给定的文档/对象/实体转换为文本，但并没有很完美的方式，能保留所有信息的同时转换不同类型的对象。
例如：转换文档为文本可能会丢失样式、结构、媒体内容，甚至某些文本信息本身（例如超链接的URL）。
例如，这个 StackOverflow 问题：
如果我在浏览器中选择部分内容并复制/粘贴到文本编辑器，它显示如下：
可以看到：点赞计数变成了单一数字，代码块没有格式化，链接的URL也缺失了。
Markdown 格式的文本有细微差异：
将源文本（而不是纯文本）提供给 LLM ，LLM 能够理解结构化的输入，这在 XML、HTML、JSON 等源文本提示中，
而不是屏幕上看到的纯文本提供给LLM是有意义的。LLM能够理解结构化输入，在XML、HTML、JSON等格式提示中有很多例子，LLM 有更好的表现。
从 TXT 复制到源文件复制，大小就会发生变化，并不是所有源文件都想 Markdown 那样轻量。
示例 | Token 数 | 大小差异 |
|---|---|---|
Google Results Page (copy/paste, txt) | 975 | |
Google Results Page (source, HTML) | 246781 | 253x |
apple.com(copy/paste, txt) | 997 | |
apple.com(source, HTML) | 92091 | 92x |
Wikipedia page (Albania, copy/paste, txt) | 42492 | |
Wikipedia page (Albania, source, wikitext) | 76462 | 1.8x |
这里，我深有感触，比如写 提示语 直接复制到 GPT 对话框中，某些纯文本的提示语，就不会保存链接格式，要先复制到 markdown 中。这个替代方案某些情景适用，但并不是所有源文件，markdown 都支持，GPT 为什么不能进一步支持源文件格式的文本呢？
比如：HTML 源文件很大，里面包含了 JS、CSS，需要更大的上下文窗口容量支持。
RAG
以下是 Google 的检索 Google 结果：
它包含了：搜索框、搜索结果、侧边栏、图块等等，像这样的页面，纯用粘贴复制功能，贴到 GPT 上下文提示语框中，128K 的大小限制是足够的，因为它会丢失样式、链接、布局、交互性等信息；
如果是贴源文件，那么 128K 的大小就不够用了。
这个时候，如果用到 RAG —— 生成式检索增强，它能通过 API 调用，请求页面或读取文件，优化检索数据，缩小文本或标记梳理，同时保留必要信息；然后使用文本分割器，将文档转换为段落、代码块，确定每段落大小；接着进行语义索引、并存储在向量数据库；在回复用户生成的内容前，选择与用户初始请求语义相关的段落块，插入到提示中。
这里的关键就是：细化结果并保留信息，嵌入相关性片段并连接相关信息。
假设我们想读取任意网页，并不清楚其中的结构，根本无法实现提取特定信息，比如：提取都带有 search-result CSS类的<div>元素；RAG 则可以帮我们解决这一问题，是一种较好的解决方案，帮助理解页面结构，也无需太大的上下文提示语容量。
一图胜千言
我们如何构建一个通用的、上述 RAG 代理，它能爬取网页、分析结构、深入分析，再提取相关数据？
在这篇 《The Dawn of LMMs: Preliminary Explorations with GPT-4V(ision)》 探索GPT-4V(ision)能力的论文中，有一个很好的“图形用户界面导航”使用案例：
“一图胜千言”这句话本身就体现了：如何通过改变信息模态将成百上千的 token 转变为可操作的信息片段的。
上下文长度限制的“骗局”
首先我们想想为什么提示语有长度限制？
当进行推理时，输入提示双倍增加（请求中的token数量）会使CPU和内存需求增加4倍；并且会延长2倍的请求时间、4倍的完成时间。
为了让大模型在理解、操作更多的上下文时仍保证有效，就必须在更大的上下文窗口上进行训练，这也需要更多的计算资源。
个别开发者通过实证研究和测试，宣传的上下文数量限制与实际有效上下文数量限制之间的严峻差异；当越接近上下文的最大限制时，LLM 越会忘记或错过提示中的某些信息。
GPT-4 Turbo的一项测试表明，只有当上下文不超过 71k token长度，约最大值的 55% ，才有可能一直保持上下文的信息处理能力。
这项测试现象在 GPT-3.5 也被得到证明；
虽然说极值是 128K，但实际到一半的时候，就开始出现前后不连贯的情况了。。
小结
所以，本瓜认为：我们几乎可以断定，目前的 128K 上下文提示语容量还有点“虚”，并且还不够！
期待通过 RAG 等方式进一步解决这个问题，并且在未来，持续提升上下文提示语的数量、容量大小、文本类型等还是非常有必要的一项工作！