完整学习LLM(六):上下文窗口是什么,为什么模型会忘东西

请根据这份部署文档,告诉我 battle monitor 怎么上线.RAG 检索到了 5 段资料.历史对话里还有我前面问过的问题.系统提示词里还写着回答规则.这些东西最后都要放到哪里?答案就是:放进上下文窗口.所以今天这篇就专门聊一个很基础,但很容易误解的概念:上下文窗口是什么?为什么模型会忘东西?为什么不是窗口越大就一定越好?0.背景:为什么要学上下文窗口我最开始用大模型时,对它的感觉是:它好像能记住我刚才说过什么.比如我先说:我现在在写一篇关于 RAG 的文章.然后我再问:帮我把刚才那个主题换一个标题.模型通常能知道刚才那个主题指的是 RAG.这就很像记忆.但用久了以后会发现:聊太长,它会忘.资料太多,它会漏.前面明明说过,后面它却像没看见.这个时候就不能只说一句:模型记性不好.更准确的说法是:这次请求里,模型能看到的内容是有限的.这个有限范围,就是上下文窗口.1.先给一个直觉:上下文窗口就是这次请求的可见范围我现在对上下文窗口的理解是:上下文窗口 模型在一次请求里能够看到和处理的 token 范围.注意这里有两个关键词:一次请求token 范围也就是说,模型不是把我们所有聊天内容都永久放在脑子里.每次调用模型时,系统会把一批内容打包给它.这批内容可能包括:系统提示词开发者提示词历史对话用户当前问题RAG 检索出来的资料工具调用结果预留给模型输出的空间这些内容加起来,不能超过模型允许处理的上下文范围.可以先看这张图:这张图想表达的是:对话和资料是一条很长的流.上下文窗口只覆盖其中一段.新问题和新资料进来时,太早的内容可能会离开窗口.所以模型忘了,很多时候不是它真的产生了人类意义上的遗忘.而是:那段内容没有被放进这一次请求里.2.上下文窗口里到底装了什么很多人会把上下文窗口理解成:聊天记录长度.这不算错,但不完整.上下文窗口不只是聊天记录.它更像一次请求的总预算.里面装的东西可能很多:系统规则- 你要怎么回答,哪些不能做历史对话- 用户前面问过什么,模型前面答过什么当前问题- 用户这一次真正要问什么检索资料- RAG 找回来的文档片段工具结果- 数据库查询结果,接口返回内容,代码执行结果输出空间- 模型接下来要生成答案的位置这些东西都要占 token.所以一个很现实的问题是:窗口不是只给输入用的.输出也要占空间.比如一个模型的上下文窗口最多能处理一批 token.如果输入已经塞得很满,那留给输出的空间就会变少.反过来,如果希望模型输出很长,输入就不能无限塞.这就是为什么我说上下文窗口更像预算:这张图里最重要的是第二条:RAG 资料塞太多时,模型不一定更聪明.因为塞进去的内容越多,模型越需要在里面找重点.如果资料里混进了很多无关内容,模型反而可能被干扰.这也是为什么 RAG 系统不能只做一件事:把所有搜索结果都扔给模型.它通常还需要:召回重排过滤低分片段压缩摘要控制 TopK说白了:上下文窗口有限,所以要把最有价值的内容放进去.3.为什么模型会忘东西这里可以拆成三种情况.第一种:内容根本没进这次请求这是最常见的.比如我前面很早说过:我的项目叫 Lighter.但后面聊了很长.如果系统为了控制上下文长度,把早期对话裁掉了.那模型这次请求里就看不到这句话.它自然可能不知道 Lighter 是什么.这不是参数忘了.而是:这次输入里没有这条信息.第二种:内容进来了,但太靠前或太分散有些时候,内容确实在上下文里.但上下文太长.关键信息埋在中间.模型可能没有稳定抓住它.这就涉及一个很有名的问题:Lost in the Middle简单说就是:长上下文里,模型不一定能同等有效地利用每个位置的信息.有些信息放在开头或结尾更容易被用到.埋在中间时,模型可能更容易漏掉.所以长上下文不是万能药.窗口变大以后,还要考虑:哪些内容放前面哪些内容放后面哪些内容要压缩哪些内容要重复强调第三种:用户以为它是长期记忆还有一种误解是:我告诉过模型一次,它以后就应该一直记得.但大多数普通调用里,模型并不会因为一次聊天就改写自己的参数.它能利用的通常是:这次请求里的上下文如果系统有记忆功能,那也是另外一层工程能力.比如:把用户偏好保存到数据库下次聊天前再取出来重新塞进上下文这和模型参数本身记住不是一回事.可以用这张图区分:这张图里我想强调一句话:上下文窗口是临时工作台.外部资料是资料库.模型参数是训练时形成的能力.这三件事不要混成一个东西.4.用一个例子理解:为什么它前面知道,后面又不知道假设我们在写一个后端部署文档问答助手.一开始用户说:我的项目是 battle monitor.它由 Go API、PostgreSQL、Nginx 组成.然后用户问了很多问题:数据库怎么配置?Nginx 怎么反代?Docker Compose 怎么写?日志怎么看?健康检查接口是什么?聊到后面,用户突然问:那这个项目上线前还要检查什么?如果系统把所有历史都完整塞进上下文,模型大概率知道这个项目指 battle monitor.但如果历史太长,系统只保留最近几轮:用户: 日志怎么看?助手: ...用户: 健康检查接口是什么?助手: ...用户: 那这个项目上线前还要检查什么?这时候模型可能只知道:有日志有健康检查可能是某个项目但它不一定知道: