LLM应用上下文管理实战：从对话窗口到混合模式

做 LLM 应用做到第三个项目的时候我几乎被同一个问题逼疯对话一长模型就开始“失忆”文档一多token 直接爆表用户上一秒还在聊需求下一秒问了个早前的问题模型答得驴唇不对马嘴。后来我才意识到问题不在模型本身而在我们从来没有认真设计过“上下文”这件事。把一套上下文管理模式context-mode真正落到项目里之后这些坑才算一个一个填平。这篇文章想聊聊 context-mode 到底是什么、为什么非做不可以及抛开花哨概念之外怎么用最简单直接的方式把它实现出来。内容偏实战适合正在做 AI 应用、聊天机器人、知识库问答的工程师也适合刚入门、想搞明白“上下文管理”到底在管什么的朋友。我会把原理、计算、代码、踩坑全部揉在一起讲尽量让不同基础的人都能拿走直接用的东西。1. 什么是 Context-Mode从一个老问题说起1.1 没有 Context-Mode 的时候应用长什么样先回忆一下最原始的写法把所有对话历史一股脑拼进 prompt然后丢给模型。demo 阶段这样跑确实没问题两三轮对话效果还像模像样。但只要对话超过十几轮或者中间插入了一段长文档问题就全来了——模型开始忘记用户最早提的需求回答越来越跑偏甚至把之前说过的错误信息当成事实反复引用。我见过一个客服机器人项目上线第一周就翻车了。用户在第十轮问“那我刚才说的那个订单号是多少”模型一本正经地编了一个订单号出来。原因很简单原始对话早就被截断了模型根本没见过那个订单号但它不会承认自己不知道而是会用概率去“猜”一个看起来合理的答案。这种幻觉不是模型不够聪明是上下文管理没做到位。Context-Mode 解决的就是这件事。它本质上是一套“上下文治理”策略什么时候保留哪些信息、保留多少、以什么形式保留、什么时候该丢弃或压缩都由一套明确的规则和流程来控制而不是把决策权交给 prompt 的自然拼接。1.2 Context-Mode 的三种典型落地形态在我实际接触过的项目里context-mode 通常以三种形态出现按复杂度从低到高排第一种是对话窗口模式也是最常见的形态。系统只保留最近 N 轮对话更早的内容要么直接丢弃要么压缩成一段摘要塞进系统提示词里。适合闲聊、客服、日常助手这类对“近期上下文”依赖强的场景。第二种是检索模式。上下文不是靠“记住”而是靠“查”。每次用户提问时先从知识库或历史记录里检索出最相关的几段内容拼到 prompt 里作为上下文。适合知识库问答、文档助手这类需要引用具体事实的场景。第三种是混合模式也是我认为真正能扛住生产压力的方案。系统先判断当前问题是延续型还是新开型延续型走对话窗口直接引用最近几轮内容新开型走检索把窗口里的旧内容压缩掉腾出空间给新检索到的段落。两种模式通过一个路由逻辑动态切换。这三种形态不是互斥的成熟系统往往是三者嵌套。后面我讲实现方案的时候会重点演示混合模式怎么把前两者组合起来。2. 为什么需要 Context-Mode三笔账必须算清楚我见过不少团队觉得这是个“优化项”不是“必做项”。我的观点很明确只要你做的是多轮对话或长文本类应用上下文管理就是刚需。原因不复杂我们一笔一笔算。2.1 第一笔账Token 预算是物理天花板大模型的 context window上下文窗口是硬限制。拿常见的 128K 窗口模型来说128K token 听起来很大但实际用起来缩水严重。我做一个粗略估算一个 128K 窗口system prompt 占掉 2K~4K安全余量留 10%约 13K剩下真正能用的对话和文档空间大概 110K 左右。110K 能放多少对话按中文场景估算1 个汉字约等于 1~1.5 个 token一轮普通问答用户提问 模型回答大约 500~1000 token。110K 也就够 110~220 轮对话。听起来不少但一旦涉及长文档分析情况完全不同——一份 30 页 PDF 转成文本大概 2~3 万个 token两三个文档塞进去窗口已经快满了。模型不是人它没有“选择性注意”机制窗口里塞什么它就看什么。如果你不管控上下文等到窗口满了系统只能做最简单粗暴的处理从中间截断。而截断的位置往往恰好是把关键信息切掉的危险区。Context-Mode 的本质就是把“截断”这个被动行为变成“管理”这个主动行为。2.2 第二笔账成本和延迟随上下文指数级上升Token 不只是容量问题更是钱的问题和速度的问题。大模型的计费直接跟 input token 数量挂钩API 的 attention 计算量也跟序列长度成正比。我把一组真实的计费数据摆出来按主流 API 的常见定价系统提示词和用户消息都算 input token模型回复算 output token而 output token 定价通常是 input 的 3~4 倍。很多团队只盯着 output 费用忽略了 input 端的隐性膨胀。同一个应用context 管理做得好input token 可能稳定在 3K 以内做得不好几轮对话后就膨胀到 10K、20K。同样规模的用户量月成本差三到五倍很正常。延迟方面同样明显。我做过一次压测同样的问题3K 上下文时首 token 延迟约 0.8 秒20K 上下文时涨到 2.5 秒以上。用户感知最明显的就是“转圈时间”而很多转圈其实都是无效上下文拖累的。2.3 第三笔账信息密度决定回答质量上限用一个生活化的类比模型的工作台就那么大context window你摆上去的东西越多它找工具就越慢、出错率越高。但如果工作台上只有一把螺丝刀它能干的活也就有限。所以关键不是“放多少”而是“放什么”。上下文信息密度指的是在有限的 token 预算内能支撑模型完成当前任务的有效信息占比。一段 500 token 的旧会话寒暄信息密度几乎为零但它会挤占原本可以用来承载用户真实需求的 500 token。Context-Mode 的另一个核心目标就是提高窗口内的信息密度——把寒暄压缩掉、把重复内容去重、把背景知识摘要化让每一寸窗口都花在刀刃上。这几笔账算完“为什么要做”基本没有悬念了。真正难的是“怎么做”接下来进入机制层面。3. 核心机制拆解Context-Mode 内部到底做了什么3.1 分块策略怎么把长文本切成合适的 Chunk不管是对话历史还是知识库文档进入上下文之前都得分块。分块的目标不是“切小”而是“切得语义完整”。我见过不少新手直接按固定字符数切比如每 500 字符一刀切下去结果把一句完整的话、一段逻辑、一个代码块从中间劈开检索召回的时候全是残片模型自然答不对。实践下来比较可靠的分块维度有三个。第一是结构维度文档里的章节标题、段落边界、列表项、代码块天然就是分块点优先按这些切。第二是语义维度用分隔符句号、换行、Markdown 标题先做候选切点再评估每块的字数是否落在目标区间。第三是重叠维度相邻两个 chunk 之间保留少量重叠比如 50~100 个字符避免检索时边界内容被漏掉。我常用的参数组合是目标 chunk 长度 800~1200 token重叠 10%。这个区间是我在多个项目里试出来的折中值——太小则碎片化严重、召回时要拼多段太大则单块内部主题混杂、向量检索精度下降。3.2 记忆管理摘要、遗忘与优先级排序对话历史的处理是 context-mode 里最容易出彩也最容易翻车的地方。核心手段有三个摘要、遗忘、优先级。摘要是把早期对话压缩成结构化摘要例如“用户是某电商平台的运营正在咨询 618 大促的优惠券配置偏好低价优先”。摘要不用保留完整原话只要保住对后续回答有影响的关键事实。我建议摘要也分层全局摘要保留用户的长期偏好和目标滑动摘要只覆盖最近几轮。两层配合比一层大摘要效果好得多。遗忘策略不能简单地“时间久了就删”。要给每条历史消息算一个“生存价值”来源有三个维度是否包含用户提供的硬性事实订单号、预算、时间、是否被用户后续明确引用、是否与当前 topic 同主题。满 50 轮或超过 token 阈值时把生存价值最低的一批先压缩成摘要而不是从头一刀切。优先级排序更关键把最新一轮对话、用户当前明确提到的事实、系统需要执行的指令排在窗口最前或最后模型对开头和结尾的注意力通常更强中间放历史背景和参考文档。这个排序策略用好了成本几乎为零效果提升却很直观。3.3 模式切换按场景路由的触发逻辑混合模式的路由逻辑是整套机制的大脑。我实现过一个相对简单的触发规则准确率已经够用先做意图判断区分“延续当前话题”和“开启新话题”。延续型问题的典型信号包括出现指代词“它”“那个”“刚才”、对前文内容的追问、在现有任务列表上追加条件。新开型问题的信号包括提到新实体、以“帮我做XX”开头、涉及之前没出现过的专有名词。实现上不一定要用复杂模型先用正则加少量规则能拦下六成场景剩下的用一个小分类模型或 LLM 调用兜底。规则层的好处是快、省钱、可控模型层负责处理边界情况。路由结果决定走对话窗口还是检索链路同时触发相应的摘要和清理动作。注意模式切换切忌“每次请求都重新判断”导致抖动。我给路由结果加了个 sticky 机制——一旦进入检索模式接下来 2~3 轮优先保持检索模式避免用户连续追问时反复横跳上下文被拆得七零八落。4. 实操从零实现一个可用的 Context-Mode这一部分我直接把项目里跑通过的代码骨架整理出来按三种模式从简到繁拆开讲。环境依赖很简单Python 3.10openai 或任意兼容 SDK加上一个向量库示例用轻量的 Chroma生产可换 pgvector 或 Milvus。4.1 基础架构与数据模型先把上下文会话的数据结构定义清楚。我习惯用统一的消息模型给每条消息打标签这是后面做摘要、遗忘、排序的前提。from dataclasses import dataclass, field from typing import Optional from enum import Enum class MsgType(str, Enum): USER user ASSISTANT assistant SUMMARY summary MEMORY memory FACT fact class MsgRole(str, Enum): ACTIVE active # 当前窗口内 ARCHIVED archived # 已压缩/归档 dataclass class Message: msg_id: str role: str # user / assistant / system content: str msg_type: MsgType token_len: int timestamp: float survival_score: float 0.0 # 生存价值 extra_meta: dict field(default_factorydict) dataclass class Conversation: session_id: str messages: list[Message] global_summary: str # 全局摘要 window_limit: int 8000 # 当前窗口 token 上限每个 session 维护一个 messages 列表active 状态的消息会进入 promptarchived 的只保留在本地日志里。token_len 在写入时就算好避免每次拼 prompt 都重新数一遍性能差距很大。4.2 实现对话窗口模式滑动窗口 摘要压缩滑动窗口的模式好理解维护最近 N 轮超出的部分压缩进摘要。下面这段代码实现了“窗口满时压缩最旧消息”的核心逻辑def compress_old_messages(conv: Conversation, model_fn) - None: 把窗口内最早的一批消息压缩进全局摘要 # 按生存价值排序优先压缩低价值的旧消息 old_msgs [m for m in conv.messages if m.msg_type in (MsgType.USER, MsgType.ASSISTANT) and m.role MsgRole.ACTIVE] old_msgs.sort(keylambda m: (m.timestamp, m.survival_score)) total_token sum(m.token_len for m in old_msgs) if total_token conv.window_limit: return to_compress [] used_token 0 for m in old_msgs: if used_token m.token_len conv.window_limit * 0.6: break to_compress.append(m) used_token m.token_len # 被压缩的消息拼成一段交给摘要模型 raw_text \n.join(f{m.role}: {m.content} for m in to_compress) prompt ( 你是对话摘要器。把下面的对话压缩成简洁的中文摘要 保留硬性事实、用户偏好、尚未完成的指令丢掉寒暄和重复内容。\n f对话内容\n{raw_text} ) summary model_fn(prompt, max_tokens500) merged conv.global_summary \n summary if conv.global_summary else summary # 截断全局摘要避免无限膨胀 conv.global_summary truncate_by_tokens(merged, 1500) # 原消息降级为 archived for m in to_compress: m.role MsgRole.ARCHIVED # 把新摘要作为一条特殊消息插入窗口最前面 conv.messages.insert(0, Message( msg_idfsummary_{int(m.timestamp)}, rolesystem, contentf对话背景摘要{conv.global_summary}, msg_typeMsgType.SUMMARY, token_lenestimate_tokens(conv.global_summary), timestampm.timestamp, ))这段代码里的关键决策有两个。第一不是窗口满了才压缩而是先对消息算生存价值、按时间排序后再挑低价值的压第二插回窗口的不是整段历史而是压缩后的摘要。这两点直接决定了滑动窗口的质量上限。如果直接写“把最早 N 轮砍掉”用户问起 20 轮前提过的需求模型依然一无所知。4.3 实现检索增强模式向量化与召回检索模式负责“从外部资料里找答案”。链路不复杂文档分块 → 向量化入库 → 查询时向量召回 → 按相关性过滤后拼入 prompt。代码骨架如下import chromadb from openai import OpenAI client OpenAI() collection chromadb.Client().get_or_create_collection(kb_docs) def build_index(doc_chunks: list[dict]) - None: chunks: [{chunk_id, text, meta}] embeddings [ client.embeddings.create(modeltext-embedding-3-small, inputc[text]).data[0].embedding for c in doc_chunks ] collection.add( ids[c[chunk_id] for c in doc_chunks], embeddingsembeddings, documents[c[text] for c in doc_chunks], metadatas[c[meta] for c in doc_chunks], ) def retrieve(query: str, top_k: int 4) - list[str]: q_emb client.embeddings.create( modeltext-embedding-3-small, inputquery ).data[0].embedding hits collection.query(query_embeddings[q_emb], n_resultstop_k) docs [h for h in hits[documents][0]] return docs召回之后还有一个容易被忽略的动作相关性过滤。向量检索返回的 top_k 是“近似度”最高的但不代表“相关度”够用。我通常会给召回结果加一道轻量过滤要么用模型打个分要么用关键词/时间戳做硬过滤。比如用户问的是“昨天的报表”那就先过滤掉所有非昨天的文档再送进模型别把向量库当成万能钥匙。注意检索 token 预算要单独设上限。我的项目里检索上下文最多占窗口的 50%剩下空间必须留给对话历史和指令。很多团队把检索结果无脑塞进去结果模型被大段文档淹没连基本指令都执行不好——这是典型的“上下文反噬”。4.4 实现混合模式按意图路由混合模式的核心是路由函数。先判断当前问题该走对话窗口还是检索链路再决定上下文组装方式。代码逻辑如下import re TOPIC_CONTINUE_PATTERNS [ r那|后来|然后|继续|再说|刚才|上面|这个|那个, r^还|^再|^另外, r第\d种方案|上一个问题|你刚才说的, ] TOPIC_NEW_PATTERNS [ r帮我看下|帮我查一下|写一份|整理一下, r什么是|为什么|怎么用, ] def route_query(query: str, recent_msgs: list[Message]) - str: 返回 conversation 或 retrieval if query.startswith(!): # 强制检索指令给用户留一个后门 return retrieval cont_score sum(1 for p in TOPIC_CONTINUE_PATTERNS if re.search(p, query)) new_score sum(1 for p in TOPIC_NEW_PATTERNS if re.search(p, query)) # sticky 机制如果最近一轮是 retrieval且本轮有指代就继续 retrieval if recent_msgs and recent_msgs[-1].extra_meta.get(mode) retrieval: if cont_score 0: return retrieval if new_score cont_score: return retrieval return conversation def build_prompt(session: Conversation, query: str) - str: mode route_query(query, session.messages[-3:]) if mode conversation: # 对话窗口模式摘要 最近N轮 当前提问 recent [m for m in session.messages[-6:] if m.msg_type in (MsgType.USER, MsgType.ASSISTANT)] context_parts [] if session.global_summary: context_parts.append(f背景摘要{session.global_summary}) context_parts.append(\n.join(f{m.role}: {m.content} for m in recent)) else: # 检索模式摘要 检索结果 最近2轮 当前提问 docs retrieve(query, top_k4) context_parts.append(参考资料) context_parts.extend(f- {d} for d in docs) recent [m for m in session.messages[-2:] if m.msg_type in (MsgType.USER, MsgType.ASSISTANT)] context_parts.append(\n.join(f{m.role}: {m.content} for m in recent)) context_parts.append(f用户{query}) prompt \n\n.join(context_parts) return prompt路由层做得“轻”是刻意的。正则模式快、零成本、可解释能覆盖大部分生产请求。更复杂的语义边界才交给模型兜底。这样既保证稳定性又控制成本。4.5 组装请求与参数选择最后是把所有素材拼进 API 请求。这里我给出一个生产环境验证过的组装顺序和参数组合可以直接抄def call_with_context(session: Conversation, query: str, model: str gpt-4o-mini) - str: prompt build_prompt(session, query) response client.chat.completions.create( modelmodel, messages[ {role: system, content: SYSTEM_INSTRUCTION}, {role: user, content: prompt}, ], temperature0.3, # 知识/客服场景建议低温减少幻觉 max_tokens1024, streamFalse, ) answer response.choices[0].message.content # 把本轮交互写回会话供下一轮使用 session.messages.append(Message( msg_idstr(uuid4()), roleuser, contentquery, msg_typeMsgType.USER, token_lenestimate_tokens(query), timestamptime.time(), )) session.messages.append(Message( msg_idstr(uuid4()), roleassistant, contentanswer, msg_typeMsgType.ASSISTANT, token_lenestimate_tokens(answer), timestamptime.time(), )) return answerSYSTEM_INSTRUCTION 建议把模式的说明放进去比如“当参考资料存在时优先引用资料内容当资料与用户问题无关时明确说明”。temperature 我习惯在 0.2~0.4 之间调检索类项目压到 0.2自由问答类可以放到 0.7但别超过这个太多否则同样上下文下幻觉率会明显上升。5. 常见问题与排查技巧实录5.1 上下文被截断后回答质量断崖式下跌症状对话进行到中途模型突然开始重复回答、答非所问甚至声称自己“看不到之前的信息”。排查思路先看截断逻辑。很多团队用的是最简单的“字符截断”比如 prompt 超过 4000 字符就把中间部分直接删掉这是灾难的根源。手动拼 prompt 前先跑一遍 token 统计确认截断位置在哪里——如果截断点恰好落在用户上一轮提问或关键事实附近大概率就是问题所在。修复办法把“截断”改成“压缩”。参考 4.2 的摘要逻辑不要删内容而是把旧内容转成摘要后重新插入。摘要模型可以用小一号的模型成本可以接受效果却天差地别。5.2 上下文污染不相关信息挤占窗口症状用户问 A 领域问题模型却把 B 领域的资料一起引用答案变得混乱又冗长。这是检索模式特有的坑。向量召回很“贪”top_k 设成 5哪怕只有 2 条真正相关它也会凑满 5 条给你。凑数的内容不仅没用还会污染注意力。我踩过的最狠一次是在法律文书问答里模型把“因”和“因果”两个不同概念的文档混在一起引用答出来的结论完全跑偏。修复办法给检索结果加两过滤——先用关键词和元数据硬过滤如时间、来源、领域再用模型或规则做相关性确认。top_k 宁小勿大宁缺毋滥。另外我给每条资料单独标注来源编号让模型在回答时注明“根据[资料2]”既方便审计也减少模型自由发挥的空间。5.3 Token 计费与实际消耗对不上症状后台显示单次请求才 3K token账单却比预期高很多。大部分时候不是计费出问题而是没算对 input token 的构成。system prompt、检索资料、历史对话、摘要全部都会计入 input。我做过一次审计发现某项目每条请求里历史对话占了 60% 以上的 token真正的当前问题只占不到 10%。这就是没做上下文管理的经典特征。修复办法上线前做一个 token 构成仪表盘按“system / 历史 / 检索 / 当前问题”四个维度拆解每次请求的 token 用量。只要历史占比超过 50%就该检讨滑动窗口和摘要策略。另外别忽略 embedding 费用检索模式的向量化调用也是一笔常被遗忘的开支。5.4 多会话状态同步的坑症状用户开了多个会话在 A 会话里设置了一个偏好切到 B 会话提问时模型完全不知道这个偏好。Context-Mode 如果只做“单会话内管理”跨会话就断片了。用户会把应用当作统一助手但每个 session 都是独立窗口。我的处理方式是引入一个全局“用户画像层”每个用户维护一份长期记忆偏好、历史实体、常用指令在每次组装 prompt 时作为背景摘要注入。这个画像层与单会话窗口并行互不干扰。实现上给 Conversation 加一个 user_profile 字段用独立的摘要链路维护只保存“跨会话仍然有效”的信息比如用户的行业、目标、禁忌而不是流水账式的事实堆砌。5.5 问题速查表下面这张表是我在实际项目里沉淀下来的快速定位清单出问题时按这个顺序排查大部分情况都能在十分钟内定位症状常见根因首选排查方向快速缓解动作回答跑题、答非所问窗口被低价值历史占据检查 token 构成占比压低历史占比至 30% 以下关键事实被遗忘截断策略粗暴看截断点是否落在关键消息改为摘要压缩不要硬删引用来源混乱检索结果未过滤检查 top_k 和相关性阈值增加硬过滤和来源编号延迟与成本飙升输入 token 膨胀看历史/检索占比启动滑动窗口 摘要跨会话记忆丢失无全局画像层检查 session 边界增加 user_profile 注入写在最后的一点经验聊完机制和代码分享几条从项目里踩出来的心得体会。第一条Context-Mode 不是一次性搭好就能躺着用的。它的核心挑战在于“动态平衡”——摘要需要更新、检索阈值需要调整、路由规则需要根据线上日志迭代。我建议每两周复盘一次上下文命中率最简单的办法是抽样看 100 条用户问题人工判断模型用到的上下文是否“恰好是当时最该用到的”。我做过一次复盘发现 40% 的问题其实根本不需要历史上下文但我们的系统每次都把 6 轮历史塞进去白白浪费 token 和延迟。第二条给上下文管理体系加“可观测性”比加功能更优先。每次请求记录下路由模式、token 构成、召回文档列表、截断位置这些日志将来就是优化的唯一依据。没有日志的 context-mode 就像闭着眼开车出了问题根本无从排查。第三条先小步跑通再优化。不要一上来就上混合路由和分层摘要先用最简单的滑动窗口跑两周把基准确立了再逐步加检索、加路由、加画像层。我见过太多团队一步到位把系统搞得太复杂最后反而分不清问题出在模型、检索还是路由上。最后再分享一个小技巧给用户在界面上留一个“强制重新开始”的按钮本质上是清空当前上下文。这个功能成本极低但能解决大量因上下文污染导致的低质量回答——与其让模型在混乱上下文里硬撑不如让用户一键重置对口碑的挽回效果立竿见影。Context-Mode 做得再好也要记住它服务的是用户不是模型。