大模型应用上下文管理模式（context-mode）设计与实践

做 LLM 应用的人应该都有过这种经历：对话稍微长一点，模型就开始"失忆"，要么答非所问，要么把前面的信息重复一遍，更有甚者直接告诉你"我记不清了"。我最近在重构一个基于大语言模型的私有知识库问答系统，这个问题整整困扰了我两周，直到我把"上下文管理"从一锅粥式的拼接，改造成了一套明确的context-mode机制，整个系统的可用性才真正上了一个台阶。

这篇文章不谈虚的，就记录我这次改造的完整过程和踩坑实录。内容围绕 context-mode 这个核心概念展开，涉及上下文窗口的预算分配、消息压缩策略、检索增强与记忆裁剪的组合打法，以及一套可以直接抄走的代码实现。适合正在做 LLM 应用开发、被长对话上下文问题折磨过的工程师，也适合刚接触 RAG 和提示词工程、想理解"上下文到底怎么管"的初学者。读完你至少能分清"全量模式、摘要模式、检索模式"各自的适用场景，并且知道在什么节点切换模式、怎么切换、切换后怎么保证记忆不丢。

1. 项目缘起：我被"无脑拼上下文"坑惨了

先交代一下背景。我手上这个项目是一个面向内部团队的文档问答机器人，知识库里有几百篇技术文档，用户会连续追问、来回讨论。最初版本非常简单：把用户最近 N 轮对话 + 检索到的文档片段，一股脑拼进 system prompt 和 messages 里，然后调大模型接口。

一开始只有几十个用户，效果还行。等到日活上两百、对话轮次变多之后，问题集中爆发了。

1.1 三个最典型的失控场景

第一个场景是"答非所问"。用户在第 1 轮问了一个需求，中间聊了七八轮其他话题，到第 9 轮追问"那刚才那个方案的成本呢"，模型完全不知道"刚才那个方案"指什么。原因很直接：我的截断策略是简单保留最近 20 条消息，早期信息被粗暴切掉了。

第二个场景是"成本爆炸"。为了不让模型忘事，我把窗口调大，结果每轮请求的 token 数居高不下。按当时的调用量算了一下，光上下文 token 一个月就要烧掉几千块，而且响应延迟从 1.2 秒飙到 2.8 秒。产品那边直接来找我，问这个功能是不是被限流了。

第三个场景是"幻觉加重"。检索模块召回 5 个文档片段，每个片段 1000 字，再加上完整历史对话，一次性全塞进去。模型在超长上下文里注意力被稀释，经常抓住某个并不相关的片段大做文章，甚至会自己编造文档里没有的数据。我后来逐条对日志，发现很多错误回答都出在上下文过载的情况下。

1.2 为什么"多塞一点"不是解决办法

很多人下意识的想法是：上下文不够就加窗口，还不行就换更长窗口的模型。但这里面有个容易被忽略的事实——上下文窗口是渐进退化而非突然失效的。研究发现，模型在上下文中间位置的信息记忆显著弱于开头和结尾，这个现象俗称"lost in the middle"。也就是说，你硬塞进去的 8 万 token，模型真正有效利用的可能只有前 20% 和后 20%。

这就像一个人同时听 20 个人讲话，他大概率只记得第一个开口的和最后一个收尾的，中间全被噪音盖住。与其无脑扩大窗口，不如把"给模型看什么"这件事当成一个核心功能来设计。这正是我引入 context-mode 的初衷：把上下文划分为多种模式，不同场景走不同的组装策略。

2. 核心方案设计：三种 context-mode 的拆解与选型

在设计 context-mode 之前，我先把需求列了一遍。这个问答系统需要支持三类典型交互：单轮精准问答、多轮连续追问、跨会话的历史回溯。单一上下文策略不可能同时满足三者，所以我最终把上下文管理拆成了三种模式。

2.1 三种模式的定义与定位

我把三种模式分别命名为：full（全量）、summary（摘要）、retrieval（检索）。它们解决的是不同层面的问题，可以互相组合，并不互斥。

• full 模式：保留完整对话历史，不压缩不裁剪。适用于对话早期、关键细节密集的阶段。成本最高，但信息保真度也最高。
• summary 模式：把早期历史对话实时压缩为结构化摘要，只保留近期 N 轮完整消息。适用于对话中后期，信息增量变少的阶段。
• retrieval 模式：不依赖完整历史，而是把用户当前问题向量化，从历史对话和知识库中检索最相关的片段注入。适用于跨会话回归、长对话中途打断恢复等场景。

选型逻辑其实很简单：信息密度高的时候用 full，信息密度低的时候用 summary，信息不在当前连续对话里的时候用 retrieval。这个判断可以在每一轮请求前动态计算，而不是写死。

2.2 三种模式的成本与效果对比

我做完第一版对比测试后，整理了下面这张表，基本能说明问题（基于我项目里的实际数据，模型为 GPT-4o 级别的接口，文档平均长度 800 字）：

从数字能看到，summary 模式在成本上比 full 模式省了 64%，准确率只下降了 6 个百分点。retrieval 模式最轻量，但准确率受召回质量影响很大，必须配合一个可靠的向量检索模块。这个结果坚定了我在系统里做动态模式切换的决心——能用检索解决的绝不用全量硬扛。

2.3 组合打法的核心思路

我的最终方案不是"每一轮选一种模式"，而是"每轮以主模式为基础，叠加辅助策略"。具体来说：

• 对话轮次 ≤ 5：主走 full，可以叠加 retrieval 补充文档片段。
• 对话轮次 > 5：主走 summary，把前 5 轮之后的旧消息压缩成摘要，近期 8 轮保持完整。
• 用户明确提到之前聊过的某个话题（通过关键词匹配触发）：切换到 retrieval，从历史向量库检索对应片段，然后拼到当前 prompt 里。

这样既保住了连续的对话体验，又控制了成本。后面我会详细讲每一层的实现细节。接下来先看关键参数的设定逻辑。

3. 关键细节与实操要点：参数怎么定才靠谱

在这个系统里，最核心的三组参数是：token 预算分配、消息优先级、摘要触发阈值。参数绝对不是拍脑袋定的，每个数字背后都有计算和实测。

3.1 Token 预算分配方案

我采用的模型上下文窗口是 128k，但我不可能用满。原因有两个：一是窗口越满，延迟越高；二是模型在接近上限时表现不稳定。所以我给自己定了85% 的软上限，也就是实际可用的有效上下文预算为 100k token 左右，剩余 28k 留给模型输出和接口预留。

在这 100k 里面，我按角色做了分配：

这套分配方案的核心逻辑是"给检索留最大空间"。因为知识库文档才是这个问答系统的核心资产，对话历史只是辅助信息。如果对话历史把预算吃完了，文档片段只能挤进来一两个，回答质量必然崩。

3.2 消息优先级排序与裁剪阈值

不是所有历史消息都值得保留。我按信息密度给消息打了四个优先级：高优先级是包含具体数据、结论、用户确认过的信息；中优先级是问题与答复对比清晰的内容；低优先级是寒暄、追问、无关讨论；可丢弃的是重复提问、情绪化表达、系统内部报错。

裁剪时机是这样的：每当累计 token 超过预算的 70%，就触发一次压缩。压缩时先掉可丢弃级别，再对低优先级消息做摘要化处理。如果压缩后仍然超过预算，就对中优先级消息做二次摘要，直到低于 60% 阈值为止。这个"70% 触发、60% 收手"的机制，避免了一压缩就压过头、把重要信息全丢的情况。

3.3 摘要触发的时机与摘要结构设计

摘要不是对话进行中实时做的，而是在每一轮请求完成后异步执行。理由很简单：实时摘要意味着每次用户提问都要先等摘要跑完，延迟受不了。异步的好处是不阻塞主链路，上一轮结束后把新增消息丢进摘要队列，下一轮请求过来时摘要可能已经就绪。

摘要格式我采用了固定的 JSON 结构，方便后续检索时直接解析：

{ "topics": ["文档权限设置", "成本估算", ...], "decisions": [ {"topic": "文档权限设置", "decision": "最终采用按部门分组授权", "reason": "便于审计"} ], "pending_questions": ["是否支持外部协作者访问"], "timeline": ["用户确认A方案", "用户否决B方案", ...] }

这个结构比让模型自由写一段自然语言摘要好很多。因为 JSON 字段是固定的，后面的 retrieval 模式可以直接按字段检索，比如用户问"之前那个决定是什么"，我只需要在 decisions 字段里做语义匹配，不用全文翻。这个小小的设计调整，让跨会话回溯的准确率提升了大约 12%。

4. 实操过程与核心实现：一套可复制的 context-mode 框架

说了这么多理念，落到代码上才是真本事。我下面把这个系统的核心实现按模块拆开讲，代码经过脱敏和简化，不含项目内部逻辑，但结构可以直接搬到自己的项目里。

4.1 整体架构与数据流

系统整体分四层：入口层负责接收用户请求，模式决策层根据对话统计信息选择主模式，上下文组装层负责按模式拼装 messages，模型调用层负责统一调接口。

入口层每轮请求进来后，先做三件事：更新对话轮次计数、计算历史 token 总量、判断用户问题是否包含历史话题关键词。然后把结果交给模式决策层。

模式决策层的判定逻辑如下：如果轮次 ≤ 5 且 token 未超阈值，走 full；如果轮次 > 5，走 summary；如果检测到历史话题关键词且对应向量片段命中，则改写为 retrieval 模式，并把对应片段注入。判定过程在毫秒级完成，不调模型，纯规则计算。

4.2 模式路由与上下文组装代码

这是模式决策层和组装层的核心代码，我用 Python 实现。先看路由部分：

from dataclasses import dataclass @dataclass class ConversationState: turns: int = 0 total_tokens: int = 0 recent_messages: list = None summary: dict = None pending_keywords: list = None def decide_mode(state: ConversationState) -> str: # 1. 历史话题回溯优先 if state.pending_keywords: return "retrieval" # 2. 早期对话走全量 if state.turns <= 5 and state.total_tokens < 30000: return "full" # 3. 中后期走后端压测稳定下来的摘要模式 return "summary"

decide_mode 返回模式名之后，进入组装函数。组装函数要区分三种情况，关键是保证返回的 messages 列表结构始终符合 OpenAI 接口的格式：

def build_messages(state: ConversationState, mode: str, retrieved_snippets: list) -> list: system = build_system_prompt(mode) messages = [{"role": "system", "content": system}] if mode == "full": messages.extend(state.recent_messages) elif mode == "summary": # 插入结构化摘要作为 system 附加内容 summary_text = json.dumps(state.summary, ensure_ascii=False) messages[0]["content"] += "\n\n[历史摘要]\n" + summary_text # 只保留最近 8 轮完整消息 messages.extend(state.recent_messages[-8:]) elif mode == "retrieval": # 检索片段直接注入 system，避免自言自语式的伪对话 snippet_text = "\n\n".join(retrieved_snippets) messages[0]["content"] += "\n\n[相关历史记录]\n" + snippet_text messages.extend(state.recent_messages[-3:]) return messages

这里有个我踩过坑之后特意做的设计：检索片段不塞进 messages，而是追加进 system prompt。因为如果检索片段以 user/assistant 消息的形式塞进对话，模型会把它误认为是由用户或助手产出的真实对话，容易导致立场混淆。塞进 system prompt 则明确了"这只是参考资料"的属性，模型更不容易被误导。

4.3 历史摘要的异步生成与增量合并

摘要模块是整套机制里最复杂的一块。最开始我的方案是把整个历史对话一次性交给模型重新生成摘要，每 10 轮做一次。但这样做有两个问题：一是摘要生成本身的 token 开销大；二是新摘要可能覆盖掉旧摘要里已有的决策点，导致信息丢失。

后来我改成了增量化。每一轮对话结束后，只把新增的 2-4 条消息扔给摘要模型，同时把上一次的摘要 JSON 一起传入，让模型在旧摘要基础上做合并和更新：

def update_summary(old_summary: dict, new_messages: list) -> dict: prompt = f""" 现有摘要（JSON格式）： {json.dumps(old_summary, ensure_ascii=False)} 新增对话： {format_messages(new_messages)} 请基于新增对话更新摘要结构，保持字段不变。 如果要修改已有"decisions"中的内容，必须先说明原因。 """ response = call_llm(prompt, temperature=0.2) return parse_json(response)

temperature 我刻意调低到 0.2，就是为了让摘要尽量稳定，避免每次生成时措辞漂移、结构变形。实际运行下来，增量合并在 20 轮对话内的 token 消耗比全量重新生成少了 70%，而且摘要质量更连贯，因为模型有旧摘要做锚点，不会漏掉前面的关键决策。

4.4 检索注入时的重排序处理

retrieval 模式的关键在于检索质量。最初我从本地方向量库里取相似度 top-5 的片段，结果经常出现四个片段讲的是同一件事、一个片段跑偏的情况。后来我在语言模型调用前加了一个轻量级重排序环节，用一个小模型对 5 个候选片段按"与当前问题的相关性"重新打分，只保留 top-2 到 top-3 片段。

这个重排序的目标不是为了提升拟合同类问题的能力，恰恰是为了防止不相关片段浪费上下文预算。重排序模型很小，单次调用只有不到 200 token 的消耗，但能把进入大模型上下文的文档片段从 5 个压缩到 3 个，token 预算省出来的空间让模型对核心片段的注意力更集中。实测下来，问答准确率反而比塞 5 个片段时高了一些。

5. 常见问题与排查技巧实录

这套 context-mode 机制上线后，并没有立刻完美运行。我整理了踩过的几个典型问题，连同排查思路和解决方案一起列出来，给后面做类似系统的朋友做个参考。

5.1 问题速查表

5.2 三个值得警惕的坑

第一个坑是摘要 JSON 被模型输出损坏。增量摘要是异步跑的，如果模型输出里夹杂了多余文本，parse_json 就会失败，然后整个摘要队列就卡住了。我的对策是解析失败时保留旧摘要，并把失败消息记入日志，而不是重试三次把队列堵死。宁可某一轮摘要没更新，也不能让主链路崩溃。

第二个坑是频繁模式切换导致的"记忆断崖"。我在灰度测试时发现，有的用户在 summary 模式下聊了好几轮，某次提问触发了 retrieval 模式，模型给出的回答风格和之前不一致，用户明显感觉"换了个助手"。后来我在 retrieval 模式的消息构建里，特意把最近 3 轮完整消息也带上，同时保留摘要，让模型有足够的连续性锚点，体验就好了很多。

第三个坑是摘要更新与对话写入的并发冲突。异步摘要任务和主请求可能同时写同一个会话状态文件，导致互相覆盖。我最终引入了基于会话 ID 的版本号，每次写入前检查版本号，摘要任务只能基于最新版本做增量合并。这个问题排查了一整个下午，最后发现是并发写导致的，提醒大家对话状态的读写一定要做好并发控制，哪怕只是单机多线程。

5.3 我现在的默认配置参数

基于这些调试经验，我现在项目里跑的参数如下，供参考：

• 对话轮次判定阈值：5 轮切 summary，不搞一刀切，按 token 量二次确认
• 完整消息保留：最近 8 轮，最后 2 轮永不裁剪
• 摘要触发：token 总量达到预算 70% 时异步执行
• 检索触发：命中历史话题关键词且相似度得分 > 0.72
• 重排序保留：top-3 片段，每片段 800 字以内
• 软上限：窗口的 85%，缓冲 5% 给计数误差

这套参数在我的场景下效果最好，但不同项目差异会很大。如果你的知识库文档特别长，或者用户对话特别碎，阈值都需要重新调。建议上线前用真实对话数据做一批回归测试，重点观察准确率和单轮成本两个指标。

6. 写在最后：一点个人体会

整个 context-mode 改造做完之后，我最深的感受是：大模型应用的瓶颈往往不在模型能力，而在我们投喂信息的方式。上下文窗口再大，也不如给模型喂对的信息、按合适的结构组织信息。把"全量对话"从默认选项，变成了经过计算的、动态选择的模式组合，系统成本和准确率的改善是立竿见影的。

如果你正在做类似的 LLM 应用，建议先从最简单的开始：确定自己的对话和知识库信息比例，设置 token 预算，然后只加一种模式（比如摘要模式），跑一周看数据。等效果稳定了，再考虑加检索模式。不要一上来就上三模式组合，因为问题排查会变得很复杂。

另外一个小技巧：所有模式决策都要留日志。我后来做回归测试时，全靠这些日志定位问题。每一轮请求记下当前模式、token 组成、摘要版本号，后续无论是优化参数还是排查幻觉，都会轻松非常多。

这套方案我后续还会继续演进，比如把摘要的字段结构做得更细，加入用户意图识别来提前触发检索等。路还长，但方向已经确认了：上下文管理，是值得当作正经工程来做的。