我做了两年多的LLM应用开发越来越觉得上下文这三个字是整个项目里最容易被低估的魔鬼。很多人把精力花在调prompt、选模型上结果一上线就被上下文窗口问题打得措手不及。context-mode这个词最早只是我在代码仓库里给一个上下文管理模块起的名字后来发现它其实代表了一整套设计思路。今天就把我这段时间的实践、踩坑、还有实测数据一起聊聊希望能给正在做复杂对话系统、Agent或者长文档处理项目的朋友一些参考。1. 先搞清楚context-mode到底在解决什么问题在动手设计之前必须把问题定义清楚。很多开发者一提上下文就说把历史消息全塞给模型这在小项目里确实能跑但一旦对话轮数超过50轮、单轮中间结果很大或者需要频繁切换话题这种粗暴方案立刻崩盘。我用一个比较严谨的说法定义一下context-mode是一套关于如何筛选、压缩、组织、注入上下文的运行态策略。它决定了在每一轮生成中哪些信息应该进入模型、以什么形式进入、占多少token预算、哪些信息应该被丢弃或转移到外部存储。为什么需要这个抽象层因为大模型本身是不记事的。它看到的只是你喂给它的那段文本。所谓记住之前的对话完全靠你的应用层去维护状态。而上下文模式就是这个状态管理的中枢交换机。举个具体例子。我在做一个支持多部门知识库问答的内部系统时每个用户会话可能涉及产品文档、工单记录、代码片段。如果每次请求都把全部历史全部检索结果原样塞进去用GPT-4级别模型的话一次请求的token消耗轻松破万。更棘手的是模型会因为上下文过长而注意力稀释对早期内容关注度下降回答质量反而变差。所以我当时的判断是必须给上下文加一个显式的管理模式不能让它隐式地无限膨胀。这个模式至少需要覆盖三件事记忆生命周期哪些消息该短期存在当前任务哪些该长期保留用户偏好、关键结论。信息组织形式是原样拼接还是摘要化、结构化比如转成JSON或表格预算分配策略模型输入有限怎么在历史信息和当前任务信息以及检索补充信息之间分配有限的context窗口2. 我实测过的三种上下文模式及其适用边界在设计context-mode时我最初参考了业界常用的几种做法然后基于自己的场景做了取舍。2.1 全量直装模式这是最无脑的把所有历史打包塞给模型。实现极其简单效果在一两轮对话内很好。但它有几个硬伤Token开销随轮数线性增长10轮对话大约要消耗8k-12k token20轮基本翻倍。存在注意力稀释问题。实验数据显示当输入超过8k token后模型对输入中段内容的召回准确率会明显下降尤其是当关键信息出现在中间位置时。不同模型处理超长上下文的策略不同很多模型在极端长度下会悄悄丢失早期指令的遵从度。所以全量模式只适合短会话、低轮次、高准确率要求的场景比如单轮客服工单生成。2.2 滚动窗口模式Sliding Window它维护一个固定长度的窗口比如最近10轮消息一定保留更早的消息如果还要用就压缩成摘要。这个方案最接近人脑记忆方式近期事件清晰远期事件存摘要。我在实践中给出了一个具体的权衡公式输入token上限T max_prompt_len - max_completion_len - safety_margin 可用窗口W T - system_prompt_len - retrieved_context_len假设模型最大输入是32k我们设置max_completion_len为2k安全缓冲1k系统提示占用1k检索结果占用4k那么留给滚动窗口的只有24k。如果每轮平均占用1.2k token窗口约能覆盖20轮。超过20轮的历史必须进入摘要化流程。这个模式在大多数场景已经够用但它的问题在于窗口之外的信息进入摘要后一旦用户回头问我们三十分钟前提到的那个配置项是什么如果摘要没写好就彻底丢了。2.3 结构化主题槽位模式Slot-based Context这是我最终在复杂场景下选择的方向。它不是按轮次组织上下文而是按主题槽位组织。每个槽位保存一个特定维度的高密度信息比如当前任务目标槽位一句话描述用户当前想完成什么。用户画像槽位用户身份、偏好、历史结论。决策记录槽位每一步的输入输出、关键判断依据。临时草稿槽位本轮正在处理但还没完成的中间状态。每一轮生成时我根据意图分类结果只选择相关槽位注入。比如用户在问售后政策我不会把他昨天问过的产品参数整个塞进去但会把售后结论相关槽位带上。这个模式的优势非常明显Token消耗更可控几乎与对话总长无关只与槽位数量有关。信息密度更高因为槽位里的内容本身就是被提炼过的结论。支持跨会话迁移比如用户离开三天再回来直接从存储中重建槽位。坏处是实现成本高需要自己做意图识别、槽位更新、槽位冲突解决。但如果你的产品要长期运营这部分的投入完全值得。3. 上下文预算分配真正拉开差距的技术细节很多人以为context-mode就是决定留哪些对话,其实真正的难点在于预算分配。模型输入窗口是个稀缺资源你要在系统提示、历史对话、检索增强信息、工具返回结果之间做权衡。我总结了一套比较实用的分配策略。3.1 按任务动态分配不同任务对上下文的依赖度不同。我通常会把任务分成三类解析型任务如提取订单号、识别用户意图只留最近两轮对话检索片段系统提示为其留足空间。生成型任务如写周报、起草邮件需要完整任务背景用户偏好最近对话上下文。决策型任务如售后建议、技术方案选型需要历史决策记录当前约束条件知识库检索结果。我做过一组对照实验三类任务混用同一套上下文策略全量直装时决策型任务的有效率不足65%而按任务做差异化分配后测试集上的平均有效率达到82%以上。具体分配时我习惯先在代码里用tokenizer做一次预裁剪from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(your-tokenizer) max_input_token 28000 def fit_context(parts: list[tuple[str, str]], max_token: int): # parts: [(name, text), ...] # 按优先级从高到低排列依次填充直到预算耗尽 budget max_token used 0 selected_log [] for name, text in parts: n_tok len(tokenizer.encode(text)) if used n_tok budget: selected_log.append((name, text)) used n_tok else: remain budget - used truncated tokenizer.decode( tokenizer.encode(text)[:remain], skip_special_tokensTrue ) selected_log.append((name, truncated)) used remain break return selected_log, used这种由高优先级到低优先级依次填充的逻辑保证系统提示和用户最新指令永远不会被挤掉。3.2 摘要的递归压缩与信息衰减滚动窗口模式下摘要质量直接决定远期记忆的价值。我自己实现了两级摘要即时摘要每3轮生成一次和滚动摘要每5个即时摘要合并一次。这里有个关键坑摘要不能只做压缩**必须做结构化提取**。纯文本式摘要最大的问题是模型在压缩时倾向于保留叙事的最新的那部分而早期提取出的关键实体和数值丢掉。所以我在摘要流程中会强制模型输出固定JSON结构{ key_entities: [订单号, 客户名, 产品型号], decisions: [用户拒绝了升级方案A原因是预算限制], open_questions: [等待客户确认发货时间], facts_metric: {token_estimate: 180, importance_level: high} }这样即使文本摘要被进一步压缩结构化字段里的关键信息依然能被保留。我的测试数据显示加上结构化提取后20轮以上历史的关键信息找回率从54%提升到78%左右。3.3 系统提示的轻量化系统提示是另一个容易浪费预算的地方。很多人把系统提示写得像产品说明书洋洋洒洒上千字结果每轮都占用固定token。我现在的做法是把系统提示拆成固定部分和动态部分。固定部分通常是角色设定和安全约束控制在800 token以内动态部分则是在每轮根据任务类型动态拼装的比如你现在在处理售后升级请求相关的政策条款如下...这部分通常控制在1000-2000 token。这样做的好处是不同任务场景下模型能看到更当下的指引而不是被一篇冗长静态规则淹没。4. 我在context-mode实现中踩过的坑理论说得再多落地时才会发现细节的杀伤力。以下是我亲历过、并且大概率你们也会遇到的一些问题。4.1 窗口截断导致的伪遗忘现象第一次用滚动窗口时我发现一个诡异情况用户在第12轮提到的东西第15轮再问时模型居然答不上来。排查了半天原因不在模型而在我自己的截断逻辑。我的窗口是按轮次切的但有的轮次长有的轮次短。如果按最后10轮来截断可能实际覆盖的token数量远低于预期导致一些关键中期信息被提前挤掉。后来我改成按token数来切窗口不再按轮次。def build_window(messages, max_tokens): tail_msgs [] budget max_tokens for msg in reversed(messages): msg_tok len(tokenizer.encode(msg[content])) if budget - msg_tok 0: break tail_msgs.append(msg) budget - msg_tok return list(reversed(tail_msgs))这个改动之后伪遗忘问题基本消失。注意这里还要不要忘记把系统提示的token也预留出来否则你可能会在窗口构建完以后才发现超限了。4.2 检索结果注入时的上下文污染在接入知识库检索后我发现一个反向问题检索结果本身成了干扰源。早期我的做法是检索到什么就全部塞进去结果有两类问题检索出的多个片段彼此矛盾模型无所适从最后挑了一个错的采信。检索片段信息量太大稀释了用户当前具体指令的重要性。我的解决方案是给检索结果加一个相关性重排取舍步骤。先用重排模型对Top-10结果打分只取Top-4然后在注入时给每段标注来源和置信度[文档A置信度0.92] 关于退换货政策的表述是... [文档B置信度0.71] 另一处相关表述是...并告诉模型优先采信高置信度内容。这样既保持了透明度也降低了污染概率。4.3 槽位冲突的判定在结构化槽位模式里槽位冲突处理是我没想到会花这么多时间的地方。典型场景是用户先说要买A方案过了五轮又改成B方案。如果槽位里还留着当前方案A而本轮对话又说方案B模型会因为自相矛盾而产生幻觉。我引入了一个简单的版本号机制每次槽位更新时递增版本号并保留上一版本作为附录。注入时在主槽位里放最新信息在特殊保留区里放最近一次变更的注释。这个注释可以让模型知道用户改过主意当前以最新为准。简单有效但属于那种你不踩一次就很难提前预判的设计点。5. 进阶优化从单轮context-mode到跨会话持久化如果你的项目需要支持用户多次访问比如AI客服、学习助手、SaaS工作台那就不能只考虑单次会话内的上下文还得考虑跨会话恢复。我的做法是把槽位内容序列化成可持久化的JSON存到数据库或Redis里{ session_id: abc123, user_profile: {industry: saas, tier: enterprise, language: zh}, task_current: 为用户生成月度成本报告, decisions: [ {time: 2024-06-10T10:00:00Z, topic: 成本口径, decision: 按产品线拆分, status: active} ], summary_token: 1246, updated_at: 2024-06-10T10:30:00Z }新会话启动时应用层会把最近一次session的槽位JSON反序列化后注入到新的上下文中。这比让用户重新交代背景的体验好太多而且token开销几乎是固定的1-2k token长期看效率高得多。这里再提醒一个容易忽略的问题跨会话持久化会涉及敏感数据。比如用户画像里有客户企业名、决策记录里有预算数据存储时务必加密并做权限控制不要为了便利牺牲合规。6. 落地效果和我的取舍建议最后一个部分用我自己实践项目的实测数据收尾吧。我维护的一个内部客服助手对比了三种方案在一周内的在线效果数据基于1200个真实会话手动抽样标注有效回答率方案平均每请求token有效回答率20轮以上会话有效回答率实现成本全量直装14.2k82%61%极低滚动窗口7.6k79%72%低槽位模式4.8k84%83%中高数据其实很明显全量直装前期效果最好但会话一长就垮掉滚动窗口是最具性价比的起点槽位模式虽然工程量大但长期会话的表现是最稳的。如果让我给建议1-2轮短任务系统直接全量直装没问题别过度设计10轮上下的一般客服场景先做滚动窗口结构化摘要如果你的目标是做一个复杂的Agent或长期助手别犹豫从第一天就按槽位模式设计。中途切换的迁移成本远大于一开始多写的那些代码。最后分享一个小细节不管用哪种模式我都强烈建议在每轮请求的输入里保留一个debug字段——把本轮注入上下文包含哪些槽位/窗口长度是多少/各部分占多少token存进日志。模型输出错了你排查时只要看这个日志就能定位是不是上下文侧的问题。这个习惯救过我太多次了。