最近在做一个多轮问答项目被上下文怎么管这个问题折腾得不轻。同一个模型同样的知识库有时候回答得像个专家有时候前言不搭后语甚至干脆把用户早先说过的信息忘得一干二净。后来我把Context Mode上下文模式这个模块从头到尾梳理了一遍才发现大部分问题根本不是模型不行而是我们根本没搞明白该怎么给模型喂上下文。这篇文章就围绕我这次项目里的Context Mode设计与落地经验展开把思路、参数、代码和踩坑记录完整摊开希望能给正在做类似事情的你一点参考。Context Mode在LLM应用里其实不是一个标准库或固定算法它更像是一套关于上下文的处理策略集合。一句话概括就是决定在每次调用模型时给它看哪部分历史信息、看多少、以什么形态看。别小看这个看字它直接决定了你的应用是烧钱还是省钱、是聪明还是糊涂、是快还是慢。适合谁来读如果你是刚接触大模型应用开发的工程师或者正在做知识库问答、智能客服、AI写作助手这类产品这篇文章的内容基本能帮你少走一大半弯路。1. 为什么要单独谈Context Mode上下文管理的核心矛盾1.1 一个客服机器人的血泪史全量塞入带来的成本与效果失衡先说个很典型的失败案例。我最早做的那个客服机器人逻辑简单粗暴把用户的历史对话全部拼接起来加上系统提示词一股脑丢给大模型。初期测试效果不错因为对话轮次少、信息量小模型当然能表现得很好。可一旦真实用户聊到十几轮、几十轮问题就全冒出来了。首先是费用。那会儿用的是按Token计费的接口上下文越来越长每次请求的成本几乎是线性上涨。用户没问几个问题后台账单先撑不住了。其次是响应速度输入Token过多首字返回时间明显变长用户体验直线下降。最要命的是效果模型在超长上下文里会迷失早期对话里的关键信息反而被大量噪音淹没经常出现用户明明在第二句就说过我是安卓手机聊到后面机器人却在推荐iOS的解决方案。这件事让我意识到上下文不是越多越好而是越恰当越好。很多人对大模型的印象是给它越多信息它越聪明实际恰恰相反信息过载会造成注意力稀释。Context Mode要解决的第一个核心矛盾就是如何用尽量少的Token保留尽量多的关键信息。1.2 Context Mode的本质决定给模型看什么、看多少、怎么看把问题抽象出来Context Mode本质上做的是三件事。第一件是筛选从全部历史信息里挑出当前这轮对话真正需要的部分。第二件是裁剪控制进入模型的内容长度让它在Token预算内运行。第三件是结构化决定信息的组织方式是原始文本、摘要、还是向量检索结果。打个比方就好比你给一位新来的实习生交代工作。把所有资料都甩给他他大概率抓不住重点你告诉他只看用户反馈里和设备相关的部分别的先别管他反而能很快给出有效结论。大模型就是这样一位读得多反而懵的实习生Context Mode就是你给他划重点、限篇幅、定格式的管理方法。这三种动作对应着不同的实现模式。筛选靠规则和检索裁剪靠窗口和摘要结构化靠Prompt设计和数据格式。它们可以单独使用也经常组合使用。我在项目里把它们落成了三种具体可运行的Context Mode长上下文模式、滑动窗口模式、压缩与检索模式。下面逐个拆开讲。2. 三种主流Context Mode的原理拆解与选型2.1 长上下文模式Long Context Mode上限高但钱也烧得快长上下文模式是最直接的做法尽可能把全部历史内容都塞进模型。现在很多模型的上下文窗口已经做到了128K甚至200K Token理论上塞下几十页文档没问题。听起来很省心对吧实际用起来有四个坑。第一个坑是成本非线性增长。接口计费是跟着输入Token走的上下文翻倍单次调用成本也翻倍。如果一个用户平均对话20轮每轮按300 Token算那就是6000 Token的历史加上系统提示词和当前问题单次可能到7000 Token。如果每个用户每天触发50次请求一个月下来光上下文费用就是一笔不小的数字。第二个坑是响应延迟Token越多模型需要处理的前缀越长TTFT首Token时间会明显变慢。第三个坑是长上下文中的Lost in the Middle现象——模型对中间部分内容的关注度远低于开头和结尾。用户在第10轮说的关键信息恰好落在中间位置就很容易被模型忽略。第四个坑更隐蔽超出窗口的内容会被硬截断早期关键信息直接消失而且程序员往往不容易察觉因为报错并不明显只是回答质量悄悄变差。所以长上下文模式的适用场景其实很有限。一般来说它适合单轮超长文档分析比如让模型通读一份PDF合同再回答问题或者做长文档翻译。它不适合高频多轮的交互场景也不适合需要精确引用早期信息的场合。如果你非要用建议配合后端的内容裁剪和优先级标记别真把什么都往窗口里塞。2.2 滑动窗口模式Sliding Window Mode平衡对话场景的默认答案滑动窗口模式是我最常用也最推荐起步的模式。核心思想很朴素只保留最近N轮对话作为上下文更早的内容要么丢弃要么做粗粒度摘要。为什么有效因为大部分对话场景里用户当前的问题和最近几轮的信息关联最强。比如用户问那它支持蓝牙吗前面几轮聊的是某款耳机它指代的就是刚才讨论的那个产品根本不需要翻到一周前的历史记录。实现上滑动窗口的关键是选好N。N太小指代消解会出问题模型不知道它是谁N太大又会退化成伪长上下文模式成本降不下来。我的经验值是一个区间快速问答场景窗口保持在6到10轮比较合适需要上下文连贯的创作场景可以放到15到20轮超过20轮效果提升就很有限了主要是在烧钱。滑动窗口模式的实现成本很低一个简单的队列或循环数组就能搞定。你在把消息列表传给模型之前手动截取最后N条即可。但它也有明显的软肋它只按时间最近来筛选完全不考虑内容是否重要。如果用户在20轮前提过一个非常关键的需求滑动窗口会毫不犹豫地把它丢掉。这个时候就需要更聪明的信息筛选策略也就是压缩与检索模式。2.3 压缩与检索模式Compression / Retrieval Mode让上下文瘦身压缩与检索模式是应对重要信息在很早之前这类场景的方案也是我这次项目里投入精力最多的一块。思路是不把所有历史都留着而是先压缩再按需检索。压缩分为两种。一种是摘要压缩定期用模型把前面的对话浓缩成几句话比如每过5轮就把之前的记录总结成用户偏好黑色、预算5000元以内、已经排除了品牌A和B。下次请求时用这段摘要替代原始记录既保住了核心信息又把Token压到了十分之一。另一种是结构化信息提取把对话中的关键实体和属性抽出来存成JSON格式比如用户信息、商品偏好、当前进度。这种做法更适合客服、售前这类需要持续记录用户特征的场景。检索模式则是给历史对话建立索引每次请求前用当前问题去检索最相关的几条历史片段拼接进上下文。实现的时候我用的是向量检索加关键词检索的混合方式。向量检索擅长语义相似关键词检索擅长精确匹配两者结合命中率更高。这一套组合下来效果最理想但实现成本也最高需要维护向量库、写索引更新逻辑、处理检索失败时的降级。三种模式的选型没有绝对优劣取决于你的场景和团队投入。我画过一张内部对比表基本判断依据是这个模式实现成本上下文保真度单次调用成本适合场景长上下文低高但有注意力衰减最高单次长文档分析滑动窗口极低中最近信息保真较低多轮日常对话压缩检索高高关键信息保真低知识库问答、长期记忆3. 实操从0到1实现一个带Context Mode的问答系统3.1 环境准备与基础链路搭建我这次项目的技术栈选的是Python LangChain OpenAI兼容接口。选LangChain不是因为它的抽象多先进而是因为它内置了多种内存管理组件改造成本低适合快速验证思路。不管你是用LlamaIndex还是自己手写请求核心链路都是相通的接收用户问题→组装上下文→调用模型→得到回答→更新上下文存储。先把最基础的依赖装上pip install langchain langchain-openai faiss-cpu然后定义核心的上下文管理器。这个类的职责是维护一段对话的全部状态其他业务代码只需要跟它要当前应该给模型看什么。from dataclasses import dataclass, field from typing import List, Dict, Any import json dataclass class ContextItem: role: str content: str timestamp: int class ContextManager: def __init__(self, mode: str sliding_window, window_size: int 8): self.mode mode self.window_size window_size self.history: List[ContextItem] [] self.summary: str self.entity_store: Dict[str, Any] {} def add_message(self, role: str, content: str): self.history.append(ContextItem( rolerole, contentcontent, timestamplen(self.history) )) def build_context(self, current_question: str) - List[Dict[str, str]]: raise NotImplementedError这里我把build_context留作抽象方法三种模式各自实现一套build_context逻辑上层业务完全不用改代码切换Context Mode只需要改一个字符串参数。这种设计在后期调试时帮了大忙值得参考。3.2 Token预算的计算方法与参数设定在写具体的build_context之前先解决一个绕不开的问题到底给上下文留多少Token这直接决定窗口大小和压缩策略的配置。一个好的做法是从预算反推窗口而不是拍脑袋定数字。模型上下文窗口假设是128K Token但你不能把它当成可用预算。因为模型输出也要占Token系统提示词也要占Token一堆JSON格式和历史消息也要占Token。我习惯按这样一个公式估算可用历史Token 模型窗口 × 单次占用比例 - 系统提示词Token - 输出Token预算我的经验是把历史上下文的占用控制在模型窗口的50%到60%是比较健康的。超过这个比例模型会有两个明显反应一是响应变慢二是容易迷失在长文本里。以128K窗口为例给历史信息的预算大约在65K到75K Token之间。输出预算留2K到4K系统提示词通常1K到2K剩下就都是历史内容的可用空间。Token到底怎么估算最准确的方式是用模型的Tokenizer工具比如OpenAI的tiktokenimport tiktoken enc tiktoken.encoding_for_model(gpt-4) message 你好我想了解这款产品的保修政策 tokens enc.encode(message) print(len(tokens)) # 大概是12~15个实践中我有一个粗略的换算公式中文1个字约等于1.5到2个Token英文1个单词约等于1.3个Token代码和URL会偏多。所以如果有人告诉你给我传最近50轮对话你自己拿这个公式心算一下就知道这个需求合不合理了。合理的话继续不合理就得赶紧上压缩方案。3.3 不同Context Mode的代码实现与切换先说滑动窗口模式这是最简实现也是我线上跑得最稳的版本。class SlidingWindowContext(ContextManager): def build_context(self, current_question: str) - List[Dict[str, str]]: recent_items self.history[-self.window_size:] messages [{role: item.role, content: item.content} for item in recent_items] messages.append({role: user, content: current_question}) return messages这段代码的核心就是切片操作self.history[-self.window_size:]。但用的时候有细节系统提示词不要放这里面应该单独放在messages列表的最前面。另外如果窗口里的内容加上当前问题后还是太长我建议先裁掉最早的消息块而不是截断单条消息的内容。截断单条消息会让半句话喂给模型语义断裂非常严重。压缩模式稍微复杂一点核心是定期总结 摘要替换。class CompressedContext(ContextManager): def __init__(self, mode: str compressed, compress_interval: int 5): super().__init__(modemode) self.compress_interval compress_interval self.raw_recent: List[ContextItem] [] def add_message(self, role: str, content: str): super().add_message(role, content) self.raw_recent.append(ContextItem(rolerole, contentcontent, timestamplen(self.history))) if len(self.raw_recent) self.compress_interval: self._compress() def _compress(self): # 这里调用模型把raw_recent压缩成摘要 batch \n.join([f{item.role}: {item.content} for item in self.raw_recent]) prompt f请把下面这段对话压缩成不超过80字的摘要保留所有关键事实、偏好和已确定事项\n{batch} # 实际调用LLM返回summary_text summary_text self._call_llm(prompt) self.summary summary_text self.raw_recent.clear()这个方案里最需要小心的不是代码而是压缩时机和摘要内容。压缩太频繁模型调用成本会反超省下的Token压缩太粗糙关键信息照样丢。我的经验是5轮压缩一次比较合适而且压缩用的Prompt要明确给出哪些信息必须保留的清单用户明确表达的偏好、承诺过的行动、已经排除的选项、任何数字和金额。这些东西丢了之后很难补救。检索模式是我最后实现也最满意的一个。基本流程是每轮对话都切成小块向量化后存入FAISS向量库每次请求时先拿当前问题去检索Top-K条历史片段与最近几轮原始对话合并再组装给模型。class RetrievalContext(ContextManager): def __init__(self, mode: str retrieval, top_k: int 3): super().__init__(modemode) self.top_k top_k self.vector_store None # 实际使用FAISS def build_context(self, current_question: str) - List[Dict[str, str]]: # 1. 检索相关历史 retrieved self._search_history(current_question, self.top_k) retrieval_messages [ {role: item.role, content: item.content} for item in retrieved if item.timestamp len(self.history) - self.window_size ] # 2. 加上最近窗口内容 recent_items self.history[-self.window_size:] recent_messages [ {role: item.role, content: item.content} for item in recent_items ] # 3. 合并检索结果放前面最近对话放后面 messages retrieval_messages recent_messages messages.append({role: user, content: current_question}) return messages注意合并顺序。我把检索到的历史片段放在前面最近对话放在后面。为什么这样排因为模型对越靠后的内容权重越高最近的对话必须占据高位检索到的早期片段只是作为背景补充放前面不会干扰主线又能在需要时被模型取用。这个顺序在多个项目中验证下来效果不错。3.4 参数配置与调优经验参数调优我只说三个最关键的窗口大小、压缩间隔、检索Top-K。窗口大小和模型上下文长度强相关。如果你的模型窗口只有8K窗口开8轮可能就吃掉大半预算了这时候必须配合压缩。我的建议是从一个安全值开始窗口大小等于8的倍数附近比如8、12、16然后根据线上Token监控来调整。看两个信号平均每次请求的Token消耗以及回答内容的连贯性评分可以用人工抽检或LLM评估。压缩间隔我建议从5开始观察摘要质量。如果发现摘要经常丢失信息就缩短到3或4如果摘要内容太多冗余就延长到6或7。这个参数很敏感改一次往往要跑几百条真实对话才能看出规律所以千万别上线第一天就频繁调。检索Top-K的影响最直接K太小相关信息找不到K太大噪音混进来。我常用的起点是3如果知识库内容密集、问题具体可以升到5如果是开放性的闲聊2就够了。对了检索结果最好做去重同一信息在多条历史片段里重复出现时会导致这部分Token被白白浪费。4. 常见问题与排查技巧把踩过的坑一次性讲完4.1 症状定位输出断裂、逻辑错乱、答案陈旧分别指向什么一个通用排查思路先看症状再定位是上下文的量出了问题还是质出了问题。症状一模型回答前后矛盾比如用户说我住上海过几轮模型又说您的位置我们不太清楚。这基本就是上下文丢失。打开后台看输入的Messages列表如果里面根本没有用户说过这句话的记录那就是滑动窗口太小或者压缩摘要里没保留这条信息。解决方式是调大窗口或者在压缩Prompt里把用户地理位置、账号类型、核心偏好列为强制保留项。症状二模型回答逻辑跳跃前言不搭后语。常见原因是最近几轮消息被检索片段插入后打乱了顺序。检查一下你的build_context返回的Messages顺序确保时间顺序在最近对话部分仍然正确。我遇到过把检索片段插在中间导致模型把历史消息的先后关系搞反的案例后来强行规定检索内容一律放头部最近对话一律按时间顺序放中部问题就消失了。症状三回答内容陈旧总是漏掉用户刚说的最新条件。这个往往是缓存层干的坏事。很多人为了省费用会对相同问题做缓存但如果缓存Key没包含上下文状态就会导致用户的后续操作被完全忽略。排查方法连续发两轮消息第二轮改一个关键约束条件如果回答没变去查缓存Key的拼接逻辑。4.2 排查工具与调参建议我建议从上线的第一天就做上下文日志这是最重要的一件事。每条请求把最终是否被截断、Messages结构、Token总数、模式类型都记录下来。不然后面出问题就只能靠猜。我在项目里加的日志模板大概是这样的{ request_id: xxx, context_mode: retrieval, total_tokens: 4523, history_count: 12, retrieved_count: 2, truncated: false, model_response_quality: human_review_needed }有了日志之后很多问题都能用量化数据说话。比如某个用户群体频繁出现高Token消耗就去查是不是他们对话轮次多但窗口也大这时可以考虑对这批用户启用更积极的压缩如果发现某个问题的检索命中率长期偏低不要急着调K值先去看是不是知识库的分块方式不合理。另外还有一条特别实用的建议Context Mode必须做成可配置项永远不要在代码里写死。同一套产品不同场景、不同模型、不同用户量级最优模式可能完全不一样。我用一个字典做配置注册中心线上可以动态切换CONTEXT_MODES { long: LongContext, sliding: SlidingWindowContext, compressed: CompressedContext, retrieval: RetrievalContext, }切换只需要改接口传来的一个字段灰度发布的时候特别方便。这个设计虽然简单但在实际运维中帮我省了非常多的事。4.3 性能陷阱与成本优化心得压缩模式和检索模式都会引入额外的模型调用和向量库查询这是隐性成本很多人忽略。算一笔账压缩模式每5轮对话就要额外调用一次模型做摘要如果用户量是10万那一天就是2万次额外调用费用相当可观。优化思路有两个一是把摘要调用换成更便宜的小模型摘要任务对模型能力要求不高二是压缩任务异步执行不要阻塞正常问答流程。检索模式的隐性成本在于向量化。每轮对话都要embedding一次如果嵌入接口限流或慢会直接影响用户体验。我的做法是给embedding加本地缓存重复内容直接读缓存结果同时把向量化操作放到消息入库阶段而不是请求阶段。还有个典型陷阱是消息数量过多导致的协议开销。即使你压缩后的总Token数不大但如果Messages数组里有几十条小消息每次请求的序列化开销和模型端的注意力计算也会变慢。我经常把3到5条连续的短消息合并成一条多行文本Token不变但处理效率提升明显。合并的时候注意保留角色信息可以用用户说xxx\n助手答xxx的形式压成一条。4.4 上下文管理经验速查表把这次项目里的经验浓缩成一张速查表方便你对着排查场景推荐模式关键参数注意点单次长文档问答长上下文控制在窗口60%以内关键信息放开头和结尾日常多轮客服滑动窗口窗口6~10轮一定要保留系统提示词长期用户画像积累压缩模式每5轮压缩一次摘要强制保留实体和数字大型知识库问答压缩检索Top-K3向量检索加关键词混合超长项目文档压缩检索分层摘要先章节摘要再汇总最后再分享一个体会Content Mode听起来像个不起眼的工程模块但它实际上决定了LLM应用的天花板。我见过不少团队把精力全扑在Prompt工程和模型选型上却忽略了上下文管理结果模型参数调得再好喂进去的是一团乱麻输出自然不会好到哪去。我自己的体会是把Context Mode想清楚很多这个模型不够聪明的抱怨其实都是上下文没喂对的问题。你先用滑动窗口跑通再加压缩控制成本最后用检索解决长程记忆这三步走完绝大多数场景都够用了。还是那句话上下文不是越多越好是越恰当越好。