本篇通译自：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 等方式进一步解决这个问题，并且在未来，持续提升上下文提示语的数量、容量大小、文本类型等还是非常有必要的一项工作！
我们不断发现：成长与发展是学习与工作的主旋律 ，说到这里，自荐一下我和机械工业出版社联合出版的 《程序员成长手记》 一书：全书分为3大模块、8个章节：从入门程序员到程序员自驱成长，回归纸质阅读，相信能给你一个更全局的程序员视野，提供成长帮助。京东搜"程序员成长手记"
OK，以上便是本次分享，希望各位喜欢~ 欢迎点赞、收藏、评论 🤟 我是安东尼 🤠 人气技术博主 💥 坚持千日更文 ✍ 关注我，安东尼陪你一起度过漫长编程岁月