北京
AI在飞速前进，每周似乎都有新概念要学。上下文窗口就是这种经常在对话里出现、却很少被简单解释清楚的术语。
上下文窗口是大语言模型在生成回答时，能够同时考虑到的输入与输出token总数。你的提示词、对话历史，甚至模型自己的回复，都共享着同一笔token“预算”。随着对话越来越长，停留在窗口内的token也就越来越多。
目前，每款AI模型都对单次能放进“工作记忆”的token数量设有限制。更有意思的是，当你触达这些限制时会发生什么。
模型限制上下文窗口有几个原因。处理更多token需要更多内存和算力，会让每次请求变得更慢、更贵。除此之外，当下的模型也难以高效利用非常长的上下文。它们天然会更关注对话的开头和结尾，而不是中间部分——这就是所谓的“迷失在中间”问题。
AI模型在两次对话之间并不具备持续的记记。在一段长对话之内，它只能“看见”还塞在上下文窗口里的内容。可以把它想象成一个滑动窗口：新消息不断涌入，旧消息最终滑出窗口，模型再也看不见它们。
这就是为什么一段漫长的对话会让你感觉，模型把一开始告诉它的事情给“忘”了。它其实不是真正的遗忘，只是再也访问不到对话的那一截——除非你正在用的产品在基础模型之上额外构建了什么机制来处理这件事。
RAG，即检索增强生成，听上去挺技术化的，但想法其实很简单：与其靠记记硬猜，不如在回答前先查一查。
试想一下，模型就像一位聪明的实习生，读完了海量的常识资料，但从未见过你公司的内部文档。如果你问这个实习生一个关于自家产品的问题，你不会指望他凭脑袋就能给出答案。
RAG的作业流程大致如下：在生成回答前，系统先检索出最相关的信息片段，然后只把那段信息加进提示词里。这样模型就不必自己在成千上万份文档中翻找，而是直接收到需要的信息。
这能同时解决两个问题：第一，模型不必在巨大上下文中迷失；第二，它给出的答案能基于最新的、它原本不知道的特定知识。
当然，RAG并非魔法。如果检索步骤抓错了页面，模型的回答也会跟着出错。一套RAG系统的上限取决于其检索步骤的质量，而不只取决于最后动笔写答案的模型本身。
更新的模型动辄宣吿支持数十万token的巨型上下文窗口。你很容易觉得，解决这一切的方案很简单：把窗口再做大一点，把所有东西一股脑儿塞进去。
但情况并没有那么理想。即使是超大上下文窗口，仍然存在注意力偏向首尾的固有难题，而且单纯扩大窗口会带来更沉重的计算成本和更慢的响应速度。把信息精准地喂给模型，往往比指望模型自己在庞大的窗口中定位关键内容更可靠。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
