模型上下文窗口管理，避免超长对话超限

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

摘要
解决LLM应用在处理长对话或海量文档时引发的上下文超限、API报错、延迟激增及幻觉频发问题。适用于需构建高可用长上下文AI应用的后端与算法工程师。读完可获得基于滑动窗口、摘要压缩与RAG检索回填的系统级管理策略，以及Token精准计数与上下文裁剪的可运行代码。

关键词
上下文窗口、Token超限、滑动窗口、摘要压缩、RAG、tiktoken、上下文裁剪

2.2 关键术语
Lost in the Middle：模型对上下文开头（系统指令）和结尾（最新问题）的注意力最高，中间部分易被忽略的现象。

Token预算（Token Budget）：单次请求允许的最大Token数。必须为模型输出（Completion）预留至少 20%-30% 的空间。

滑动窗口（Sliding Window）：保留最近N轮对话或最近M个Token，丢弃最老的历史，保证O(1)的上下文更新。

摘要压缩（Summarization）：将历史消息交给小模型生成摘要，以极少的Token保留核心语义，代价是信息有损。

file: context_management.py

pip install tiktoken langchain

import tiktoken

def manage_context(
messages: list[dict],
model_name: str = “gpt-3.5-turbo”,
max_tokens: int = 4096,
completion_reserve: int = 1024
) -> list[dict]:
“”"
根据Token预算裁剪对话历史，优先保留System和最近消息。
“”"
encoding = tiktoken.encoding_for_model(model_name)

# 1. 计算系统指令与最新问题的Token
system_msg = [m for m in messages if m["role"] == "system"]
latest_msg = messages[-1:] if messages[-1]["role"] != "system" else []

fixed_tokens = sum(len(encoding.encode(m["content"])) for m in system_msg + latest_msg)

# 剩余可用Token预算
available_budget = max_tokens – completion_reserve – fixed_tokens
if available_budget <= 0:
raise ValueError("System指令与最新消息过长，超出基础预算")

# 2. 从后往前遍历历史消息，填满剩余预算
history = [m for m in messages if m not in system_msg and m not in latest_msg]
trimmed_history = []
current_tokens = 0

for msg in reversed(history):
msg_tokens = len(encoding.encode(msg["content"]))
if current_tokens + msg_tokens <= available_budget:
trimmed_history.insert(0, msg)
current_tokens += msg_tokens
else:
break # 预算耗尽，丢弃更早的历史

# 3. 重新拼装：System + 裁剪后的历史 + 最新消息
return system_msg + trimmed_history + latest_msg

测试用例

if name == “main”:
long_messages = [
{“role”: “system”, “content”: “你是一个技术文档助手。”},
{“role”: “user”, “content”: “请详细解释微服务架构。” * 10},
{“role”: “assistant”, “content”: “微服务是一种架构模式…” * 10},
{“role”: “user”, “content”: “那么服务网格（Service Mesh）呢？” * 10},
{“role”: “user”, “content”: “总结一下刚才讨论的微服务优缺点。”} # 最新问题
]

trimmed = manage_context(long_messages, max_tokens=1000, completion_reserve=200)
print(f"裁剪后消息数: {len(trimmed)}")
for m in trimmed:
print(f"[{m['role']}] {m['content'][:30]}…")

入口命令：

bash
python context_management.py
预期输出：

text
裁剪后消息数: 4
[system] 你是一个技术文档助手。…
[user] 那么服务网格（Service Mesh）呢？…
[user] 总结一下刚才讨论的微服务优缺点。…
(注：最早的一条微服务定义因超出Token预算被自动滑窗丢弃，保证了最新问题能送入模型。)

3.2 四种上下文管理策略对比
策略实现复杂度Token削减率信息完整度适用场景
滑动窗口低（O(N)遍历）视窗口大小仅保留近期，远期丢失闲聊、高频即时问答
截断（Truncation）最低（直接切）极高最差，易丢系统指令极低频兜底，不推荐
摘要压缩中（需调用小模型）70%-90%叙事连贯，细节丢失长剧情生成、个人助理
RAG检索回填高（需向量库）90%以上仅保留与当前问题相关片段企业知识库、客服工单
3.3 避坑清单
风险点触发条件处置方式
裁剪导致“失忆”系统提示词或关键实体被截断强制将 System 消息与最新 User 消息设为不可裁剪的“锚点”
摘要发生幻觉用小模型压缩事实型数据摘要仅用于压缩叙事/闲聊；UUID、金额、代码路径等存入结构化数据库按需注入
输出截断API报错未预留 max_tokens 空间每次请求的计算公式：输入Token + max_tokens <= 模型上下文上限
多模态Token计算错误图片/音频直接计入文本Token需使用特定模型的 tokenizer 且按 image_tokens 规则单独累加
4. 常见问题与排错
现象：按照字符数截断，但API仍报 context_length_exceeded。
原因：中英文Token密度不同（1个汉字约占1.5-2个Token），字符数与Token数不成正比。
解决：必须使用官方提供的 tiktoken 或对应模型的 tokenizer 进行精准计算，禁止用 len(text) 估算。

现象：长对话进行到第10轮后，模型开始重复前文或逻辑混乱。
原因：典型的“Lost in the Middle”现象，上下文过长导致注意力机制失效。
解决：不要塞满整个上下文窗口。将实际使用的Token量控制在模型上限的50%-70%左右，留出注意力余量。

现象：RAG检索后，首尾带有大量无关的段落。
原因：检索出的片段未做二次裁剪或排序，直接拼接占满窗口。
解决：对召回结果进行 Rerank 重排，仅保留 Top-3 片段；并对片段进行语义去重。

现象：流式输出刚开始就突然终止。
原因：输入Token恰好等于 max_tokens，模型没有剩余空间生成回答。
解决：动态调整 max_tokens 参数，确保 模型上限 – 输入Token 始终大于200。

上下文缓存（Prefix Caching）：在多轮对话中，系统提示词和历史前缀是不变的。利用 vLLM 等引擎的前缀缓存特性，可以大幅降低长上下文的TTFT。

提示词压缩（Prompt Compression）：使用 LLMLingua 等工具，在保持语义的前提下，直接剔除提示词中的停用词、冗余修饰语，实现无损/近无损压缩。

边界：代码分析、合同审查等任务严禁使用有损压缩（如摘要），必须依赖大窗口模型（如128K）或 RAG 精准定位，确保每一行代码或条款的绝对准确性。

如何精确计算Prompt的Token消耗？
思路：禁止按字数估算。使用对应模型的 Tokenizer（如 tiktoken, sentencepiece）进行编码计算。不同语言的Token密度差异巨大。

滑动窗口与摘要压缩各自的优缺点是什么？
思路：滑动窗口实现简单、延迟低，但丢失远期信息；摘要压缩保留语义连贯性，但需额外推理开销且可能引入幻觉。

在RAG架构中，如何控制填入上下文的Token数？
思路：使用语义分割（Chunking）控制单块大小；使用Rerank模型只取Top-K；限制最终拼接进入Prompt的总Token预算。

系统提示词（System Prompt）在裁剪时应遵循什么原则？
思路：绝对保留原则。System Prompt 定义了模型的角色和红线，必须作为“锚点”锁定，不参与滑窗裁剪。

如何在后台实现不阻塞主线程的长对话摘要压缩？
思路：将旧对话扔进消息队列（如Kafka/RabbitMQ），由后台Worker（如Celery）调用轻量LLM生成摘要，完成后更新数据库，下次请求时直接读取最新摘要。

总结
精准计算Token是管理上下文的先决条件，必须使用 tiktoken 等工具杜绝字符估算。

滑动窗口是成本最低的保底策略，但必须将 System Prompt 与 最新User输入 设为不可裁剪锚点。

摘要压缩适合叙事场景，事实型数据（ID、数值、代码）必须走结构化存储，严防摘要幻觉。

RAG是解决超长外挂知识的最佳路径，但需配合 Rerank 避免无效片段塞满窗口。

切忌塞满上下文窗口，保留 30%-50% 的余量能有效缓解“Lost in the Middle”导致的注意力衰减。