当前位置：首页 > news >正文

简单学习 --＞模型的短期记忆

news 2026/5/29 4:09:28

什么是上下文窗口 (Context Window)

概念定义

上下文窗口是大型语言模型（LLM）在一次推理（即生成一次回答）过程中，能够同时处理和“记住”的最大 Token 数量总和。它相当于人类的“工作记忆”或计算机的“内存”。

模型本身是无状态的（Stateless），它不具备原生记忆。每一次你向模型发送消息时，后台系统实际上是将你之前的历史对话与最新问题打包在一起，全量发送给模型。因此，提问、历史记录、模型的生成空间，这三者必须共享同一个固定大小的容量上限。

Token 概念解析与换算

Token 是模型处理文本的最小基础单位，它可以是一个词、词根，甚至是一个字符。

英文规则:1 token 约等于 0.75 个英文单词。
中文规则:由于编码方式不同，1 个汉字通常占用 1 到 2 个 token。
直观感知:以 128K (131,072) tokens 为例，约等于 96,000 个英文单词，或 6-10 万中文字符，大约相当于 2-3 本中篇小说的阅读量。

空间共享机制与资源分配

┌──────────────────────── 128K 上下文窗口总容量 (固定) ────────────────────────┐ │ │ │ [======== 历史对话 ========] [==== 你的当前提问 ====] [..预留给生成的回答..] │ │ (消耗 Context 空间) (消耗 Context 空间) (受限于剩余 Context) │ │ │ │ 情况 A (健康): 历史占 20K + 提问占 50K = 剩余 58K (模型有充足空间长篇大论) │ │ 情况 B (溢出): 历史占 110K + 提问占 17K = 剩余 1K (模型刚开始回答就会被截断)│ └────────────────────────────────────────────────────────────────────────────┘

简单举例：

假设你要求模型写一篇 5000 字的文章（约 8000 tokens）。如果你的输入材料（参考文档+历史对话）已经占用了 125K tokens，模型在写到 3000 tokens 时，总容量就会达到 128K 的硬性上限，模型的输出会戛然而止，这就是典型的“生成截断”。

最佳实践：

在开发或日常使用中，应将输入（历史+系统提示词+当前问题）控制在总容量的 60-75% 以内，给模型回答预留 25-40% 的安全生成空间。

模型“越聊越笨”的原因解析

在长对话中，用户常感觉模型变得健忘、逻辑混乱，甚至胡言乱语。这主要由以下两个底层机制导致：

原因一：滑动窗口机制与 FIFO 遗忘 (硬性丢失)

为了防止超出上下文上限，大多数对话系统在底层采用“先进先出 (First-In-First-Out, FIFO)”的截断策略。当对话总量超过窗口限制时，系统会无情地丢弃最古老的对话轮次。

[ 随时间推移的上下文滑动窗口模型 ] 对话早期 (窗口未满): [ 轮次1 ][ 轮次2 ][ 轮次3 ][ 轮次4 ] ------------------------> 模型知道一切 对话晚期 (达到上限，窗口开始滑动): 已丢弃 <--- [ 轮次5 ][ 轮次6 ][ 轮次7 ][ 轮次8 ] ------------> 轮次1-4的设定丢失

简单举例：

在第 1 轮时，你告诉模型：“接下来的对话中，请你扮演一位脾气暴躁的维多利亚时代侦探”。

到了第 30 轮，由于历史记录太长，包含这句设定的第 1 轮对话被挤出了上下文窗口。此时再提问，模型会恢复成标准 AI 助手的语气，因为它已经“失去”了关于设定的输入数据。

原因二：中间迷失现象 (Lost in the Middle)

即使所有的对话都在上下文窗口内，模型依然可能变笨。研究表明，大语言模型对上下文两端（最开头和最末尾）的信息提取能力极强，但对夹在中间的信息关注度会大幅下降。信息量越大，中间部分的“注意力权重”越稀疏，导致模型忽略了你在对话中途补充的关键条件。

解决方案：混合记忆管理 (Hybrid Memory)

为了突破上下文窗口的物理限制，并解决“越聊越笨”的问题，现代 AI 应用系统通常不依赖模型自带的窗口，而是采用外部工程手段进行记忆管理。

核心策略对比

策略名称	运作原理	核心优点	核心缺点	适用场景
滚动式总结 (Rolling Summary)	当上下文达到阈值（如 80%）时，调用 LLM 将早期的长对话压缩生成一段简短的摘要，用摘要替换原始对话。	极大地节约 Token 空间（可将 10K 压缩至 1K），保持全局连贯性。	会丢失大量细节。例如“我昨天吃了苹果和香蕉”可能被压缩成“用户分享了饮食习惯”。	闲聊、剧情向角色扮演、长线任务的进度记录。
RAG 向量检索 (Vector Retrieval)	将用户的每一轮对话转化为向量，存入外部向量数据库。每次用户提问时，先在数据库中搜索最相关的历史对话，只将这部分作为上下文塞入窗口。	记忆容量几乎无上限（取决于硬盘）；保真度极高，能精准回忆起很久以前的特定细节。	需要额外部署向量数据库和 Embedding 模型；系统架构复杂度显著增加。	知识库问答、专业领域的长期技术支持助理。
结构化记忆 (Structured Memory)	预定义好数据结构（如 JSON Schema）。利用 LLM 提取对话中的关键实体信息，并更新到数据库中（例如用户画像表）。	精确度最高，易于与传统关系型数据库（SQL）结合，方便进行逻辑判断和条件过滤。	缺乏灵活性。只能记录预先定义好的字段，无法捕捉 Schema 之外的意外信息。	客户服务系统（记录用户偏好、订单号、收货地址等）。

最佳实践：三位一体架构

在成熟的 AI Agent 架构中，通常会将上述三种方案组合使用，形成混合记忆中枢。

代码逻辑示意图 (混合架构工作流):

用户新输入: "我还是要上次那个颜色的型号。" │ ├──> [1. 结构化记忆提取] -> 查询用户画像: {"user_id": 102, "pref_color": "Blue"} │ ├──> [2. RAG 向量检索] -> 检索历史数据库: 找到上个月的一条记录："用户购买了 X900 型号" │ └──> [3. 滚动式总结] -> 获取当前对话上下文: "用户正在讨论产品复购" │ [ 组装最终 Prompt 发送给大模型 ] 系统提示词: - 历史摘要: 用户正在讨论产品复购。 - 用户画像: 偏好颜色为 Blue。 - 相关事实: 过去曾购买过 X900 型号。 - 最新问题: 我还是要上次那个颜色的型号。

总结：