AI为什么记不住长对话?上下文窗口的原理与代价
几乎每个长期用AI的人都被同一件事坑过:前面明明说好了”全文用第一人称、不要小标题”,聊到第二十轮,它突然开始用第三人称分点作答。你以为它”忘了”,其实它从来没有”记住”过——从头到尾,它只是在读一份越来越长的临时材料。
搞清这件事,你才知道该怎么和它协作。
第一步:模型没有记忆,只有”这一次的输入”
大模型是自回归的:每生成一个词,就把”之前所有的文字 +
刚生成的这个词”一起重新读一遍,预测下一个词。所谓”对话记忆”,全靠客户端把历史消息拼成一段长文本,每轮重新塞进模型。
所以”记住”是一个前端工程问题,不是模型能力问题。一旦历史被截断——不管是超出长度上限,还是产品为了省钱只保留最近几条——被截掉的部分对模型来说就等于从未发生。它不会”想起来”,因为它没有可以想起来的地方。
第一个结论:任何你希望它遵守的约束,都要在当轮重新说一遍,而不是指望它记着。
第二步:长度是有硬上限的,因为计算量是平方级
上下文窗口(context window)就是这个上限,常见规格是
8K、32K、128K、200K token。限制它的不是存储,是注意力机制的成本。
Transformer 里每个词都要和前面所有词算一次相关性,长度 n 的序列要做
n×n
次比较。长度翻倍,计算量变四倍。真正的瓶颈还在显存:为了不重复计算,推理时会缓存每个
token 在每一层的 Key 和 Value 向量,业内叫 KV cache。
这个开销可以精确算出来。以一个 32 层、隐藏维度 4096、采用 8 组 KV
头的 7B 模型为例:每个 token 在每层要存 2×8×128 = 2048
个数值,半精度下约 4KB,乘 32 层就是每 token 约 128KB。十万 token
的上下文,光缓存就要吃掉约 12.8GB 显存——比模型权重本身还大。
这就是”长上下文很贵”的真实含义:不是厂商小气,是每多聊一句,显存账单都在涨。
第三步:就算塞得下,中间那段也容易被忽略
更麻烦的是,长度够不代表用得上。位置编码在超长外推时会失真,实测表现是一条
U
形曲线:放在开头和结尾的信息召回率最高,塞在中间大段的位置最容易被跳过。业内把这种现象叫”迷失在中间”。
对实际使用的影响很直接:如果你把关键要求写在五千字需求文档的第三页,命中率明显低于写在第一段或最后一段。
第四步:能绕开这个限制的四种做法
工程上已经有成熟对策,个人也能直接用:
一是检索增强。不要把所有资料一次性喂进去,先按关键词或向量检索出最相关的几段,只把这几段放进来。资料库越大,这一步越必要。
二是分段摘要。长文档先让模型压成结构化的要点清单(三百字以内),再基于清单做任务。信息密度提高,长度自然下降。
三是锚点复述。在长对话中途主动发一条”确认一下,目前设定是A、B、C”,等于手动给它做一次快照。这比指望它自觉靠谱得多。
四是任务拆分。一次只让它做一件事:先列提纲、再逐节写、最后统一改口吻。单轮上下文变短,稳定性立刻上升。
结语
“记不住”不是缺陷,是这套架构的必然结果。把它当成一个阅读速度极快、但每轮都从零开始读材料的合作者,你的提示词写法会自然改变:少讲背景故事,多给当前约束;少堆长文,多做检索和摘要。
在做 AI广告制作
这类需要长流程协作的项目时,这一点尤其关键——分镜脚本、产品卖点、品牌调性这些信息,我们不会指望模型”记得上一轮说过”,而是固化成一份可复用的简报,每轮随任务一起投喂。流程稳定,输出才稳定。想了解我们怎么组织这套
AIGC广告
生产流程,可以在官网看具体说明。