大模型总“失忆”？上下文工程六大组件实战指南

1. 先看病灶LLM的“失忆”是模型缺陷还是工程缺陷做了大半年大模型应用开发我最常听到的一句话就是“这模型怎么又忘了”用户明明五分钟前还在对话里提供了订单号你换个话题再问回来它能一本正经地胡编一个订单号用户在第一轮说过自己是“老会员、怕辣”聊到第十轮推荐菜品时它又给推荐了一堆辣菜。一开始我也以为是模型不行后来把一次典型的“失忆现场”完整抓包分析之后才发现大部分所谓“失忆”根本不是模型傻而是上下文没有被当成一种需要经营管理的资源。大模型本身不是一块无限大的硬盘它能“看到”的内容只限于每次请求时你塞进提示词窗口里的那些文本。窗口之外的过往信息它一律看不见。这就要说到大模型的一个底层机制了。Transformer架构里模型处理文本时要计算每个词和其他所有词之间的注意力权重窗口越长计算量会指数级上升。所以现在的模型基本都有明确的上下文窗口上限比如8K、32K、128K Token。Token可以粗略理解成“字”1个汉字大约对应1到2个Token。窗口是硬性约束超了就截断截断必“失忆”。但真正让问题变复杂的是另一种情况——信息明明还在窗口里模型还是“忘了”。这被称为“Lost in the Middle”意思是模型对长文本开头和结尾的内容记忆得比较好对中间段落的注意力分配明显偏弱。你可能把用户信息放在提示词的第3000个Token处它照样抓不到重点。你看这不单纯是长度问题还是信息摆放位置和重要程度标记的问题。把这两类现象放一块儿就能得出一个结论大模型的“失忆”多数情况下是上下文工程没做到位。上下文窗口就像一张工作台你不在上头把当前任务需要的关键信息放好、放对位置、做上醒目标记模型就只能在有限注意力里“猜”哪些重要。模型没错错的是我们把它当成了什么都会的聊天机器人而不是一个需要你喂齐材料的协作者。这篇文章就是围绕“上下文工程”展开的。这是我在做了若干对话系统、知识库助手和Agent类项目之后觉得最该被系统化讲清楚的东西。下面我会把它拆成六大核心组件每个组件都解释了它解决什么问题、底层原理是什么、以及你在自己的项目里具体该怎么落地。适合正在用大模型API做开发、但总觉得效果时好时坏的同学。就算你现在只写过几百行调用代码看完也能立刻动手改造自己的项目。2. 上下文工程的底牌六大组件的分工地图我接触过不少项目最开始大家都很乐意调Prompt什么“你是专业的客服助手”“请根据以下内容回答”调来调去发现效果提升很有限。为什么因为Prompt只是上下文工程的一个切片。上下文工程要管的是从用户提问进入系统、到模型输出返回用户之间的整条信息链路用什么格式组织历史对话、要不要检索外部资料、检索哪些内容、压缩哪些内容、超长了怎么截断、不同任务走哪条处理路径。这些事打包在一起才叫上下文工程。它也是目前大模型应用开发里真正的瓶颈。模型能力已经被头部厂商卷得很高同一个模型不同团队拿去做同一个场景效果可能天差地别。差别就在上下文工程做得糙不糙。我把这套思路拆成六个组件先给一张总览表后面再逐个展开。组件核心职责解决什么问题典型落地手段窗口预算管理合理分配上下文窗口的Token额度窗口超限、内容被截断、关键信息被挤掉Token统计、动态裁剪、按比例分配预算提示词结构化让模型准确区分指令、数据、历史、输出要求信息堆砌导致理解混乱、关注点漂移分层字段、分隔符、锚点重复关键事实外部知识检索按需把外部资料注入上下文模型不知道私有知识、事实过期、知识幻觉RAG、向量检索、Top-K召回记忆分层管理区分短期、工作、长期记忆并分而治之会话一长就遗忘、重要事实被淹没会话摘要、结构化记忆槽、外部记忆库上下文压缩在保留关键信息的前提下缩减Token历史过长、成本飙升、注意力稀释摘要压缩、实体抽取、KV Cache理解路由与编排让不同请求走不同的上下文策略一刀切Prompt导致复杂问题答不好、简单问题浪费意图路由、多Agent分发、模块化调度这六个组件不是各自独立的工具也不是某个框架里勾选几个选项就完事它们更像同一套思维下的六个工作面。你可以先只在两个组件上下功夫也能立刻见到效果但要打造一个能稳定跑复杂业务的系统六个组件最终都得卷进来。为了让你更好理解可以把LLM一次请求的上下文比作一个剧组拍戏的道具台。窗口预算是道具台最多能放多少东西提示词结构化是给每件道具贴上明确的标签和位次外部知识检索是临时从仓库调取剧本需要的特定道具记忆分层是决定哪些剧情必须在台面上、哪些放后台备用上下文压缩是把已经用完的道具迅速精简化腾出空间路由与编排则是导演决定每场戏应该启用哪个道具方案。一台戏能不能拍好不只看A道具好不好更看整个台面调度。下面我按实际项目中最合理的上手顺序把六个组件逐个拆开讲。先讲最容易立刻见效的“窗口预算管理”和“提示词结构化”再讲解决长期记忆痛点的“外部知识检索”和“记忆分层”最后讲帮你优化成本和性能的“上下文压缩”与“路由编排”。3. 第一组积木窗口预算管理与提示词结构先保住“临时工位”3.1 不要把上下文当“无限容量”先学会数Token很多新手的第一个习惯是把整段历史消息一股脑拼到新请求里。这么做的结果通常有两种一是消息太长直接挤爆窗口请求报错二是登录平台界面看着没超限但关键信息被埋在庞大上下文里模型根本抓不住重点。正确做法是像做预算一样管理Token。每次请求的上下文窗口里实际会有这几类内容系统指令告诉模型它的身份、工作方式、输出规则的系统级内容。用户当前问题这一轮用户真正想问的话。历史对话前面几轮的问答记录。检索资料RAG流程中从外部知识库找回来的相关内容。模型输出预留生成回答要占用的Token空间。这些内容合计不能超过窗口上限。以我常用的一个项目为例模型窗口为32K Token我会这么分配系统指令控制在1K到2K左右用户当前问题加相关历史控制在8K以内检索资料最多给12K输出预留4K到6K剩下的缓冲区间留作安全余量。比例可以根据场景调整但一定要“有预算意识”不能让某一块无限膨胀。但怎么知道现在占了多少Token不能靠感觉数汉字得用分词器。简单示例import tiktoken encoding tiktoken.get_encoding(cl100k_base) text 这是要发送给模型的一段上下文内容 tokens encoding.encode(text) print(fToken数量: {len(tokens)})在接入请求前对每一块内容做统计超限就触发裁剪策略——优先裁剪末尾不重要的历史闲聊而不是裁掉用户刚提供的业务关键信息。3.2 提示词结构化的核心让模型知道“哪句话是铁律”预算管好以后接下来要处理的就是“窗口里放着的东西怎么摆”。同样一段上下文用一口气平铺和用结构化字段分块效果差别很大。原因是模型在长上下文里的注意力不是均匀分布的它需要靠明显的结构信号去判断哪里重要。我现在的项目都会遵循一个基本结构系统指令区在最顶部里面明确写出“你是一名客服助手必须优先使用【当前任务信息】中的订单信息回答当信息冲突时以【当前任务信息】为准”。然后往下依次是【用户画像】【历史对话摘要】【当前任务信息】【检索资料】【用户问题】。关键是这个【当前任务信息】区。以前做某电商客服Demo的时候用户在第一轮说出订单号后面几轮我们就没有刻意保留结果第五轮问“那我那个订单物流到哪了”模型回答“请提供订单号”。后来我们改成从每一轮对话里抽取订单号、商品名、地址、偏好等实体实时维护在【当前任务信息】区并且每一轮都原样带上。改完之后连续对话20轮也不会再犯这种错。你可能想问这不就是“把关键信息重复一遍”吗对本质上就是。你可以把模型想象成一个有阅读障碍但执行力很强的实习生。你把关键信息单独列在一张小纸条上拍到他桌前他就能稳定执行你让他自己在一堆历史聊天记录里翻他就可能漏掉。所以提示词结构化不是花哨技巧而是“显式地降低模型提取关键信息的难度”。这里有一个通用且好用的模板参考{ system: 你是项目X的智能助手回答时严格参考以下分块内容。, user_profile: {偏好: 不吃辣, 会员等级: 老会员}, task_info: {当前订单号: 20250110XXXX}, chat_history_summary: 用户已确认收货地址为某省某市某街道……, retrieved_snippets: [……知识库片段……], user_query: 我的订单到哪了 }注意像“不吃辣”“订单号”这类信息要经常出现在系统指令中提示的位置附近而不是藏在长对话末尾。有人在两个完全相同的项目里只调整了信息摆放位置准确率就提高了十几个百分点这不是个例。4. 第二组积木外部知识检索与记忆分层把“长期档案”搬进来4.1 RAG的本质别让模型凭空猜私有知识模型再强它的“记忆”也停留在训练时见过的公开知识上。你的私有文档、实时订单、内部业务规则它根本不知道。很多团队以为靠加大Prompt篇幅就能教会模型业务但那是另一个维度的误区。RAG检索增强生成之所以重要是因为它把“记住所有事”变成“按需查一份资料”。这和真人的工作方式很像——你不可能记住整个公司的规章制度但你知道出问题时去哪本手册查。RAG就是给LLM配的这个手册。具体落地步骤不复杂先把业务文档切块比如一篇长手册按段落切成256到512 Token的片段再用Embedding模型把这些片段转成向量存进向量数据库每次用户提问时也把问题转成向量在数据库里做相似度检索找出最相关的Top-K条片段最后把这几条片段作为“检索资料区”塞进提示词让模型基于它们回答。有一件事我要专门提醒不要贪多。之前做某知识库助手Demo时我们一度把Top-K设成8结果检索出来一堆关联度不高甚至互相矛盾的片段模型反而开始东拉西扯。后来把Top-K压到3到4同时把检索片段按相关性打分排序回答稳定性立刻上来了。检索资料不是越多越好而是要“精准简洁”因为资料每多一段都会抢占注意力预算。4.2 记忆分层把“什么都塞窗口”改成“三层分治”如果说RAG解决的是“不知道私有知识”的问题那记忆分层解决的就是“对话一长就乱”的问题。很多人处理长对话的方式是把所有历史消息都带着最后窗口爆了或者模型把早期重要信息淹没了。我建议把记忆分成三层来管短期记忆就是当前窗口里最近几轮的原始消息。它的特点是详细但容量小、易被冲掉。工作记忆跨越多轮的、经过提炼的结构化信息。比如“用户已经确认收货地址是A地点”“当前处理中的订单号是XXX”“用户对价格敏感”。这些信息以结构化字段维护每一轮都带入。长期记忆需要落盘到外部存储的历史知识。比如某用户过去一个月所有会话的摘要、偏好演化记录存在数据库里下次新会话开始时再加载。具体操作上可以在每进行5到8轮对话后触发一次“会话摘要”动作调用一次模型把之前几十轮对话压缩成一段200到300字的结构化摘要提取“用户已提供信息”“已解决问题”“待办事项”。更新完毕后窗口只保留摘要加最近两三轮原始消息然后继续对话。这样既保住了关键信息又把窗口Token压力降了一个量级。我见过一个团队把这种策略叫做“Rollup”类比区块链的打包记账非常形象——每次打包旧交易只保留最新状态。大家在自己的项目里也可以这么叫。只要实现了这层你就不太会遇到“换了个话题再回来就全忘了”的情况因为关键事实已经从“原始对话流”抽离成了“持续更新的状态卡”。5. 第三组积木上下文压缩与路由编排让每一次请求都有的放矢5.1 上下文压缩不是简单截断而是“删繁就简”窗口预算再怎么规划长会话里总会有内容超限的时刻。这时候最简单的处理是截断直接删掉最早的消息。但这么做的副作用很明显——早期对话里可能正好有用户的关键事实。所以我更推荐在截断前先做“压缩”。上下文压缩有三种常用手段按成本从低到高排列第一种是原始消息裁剪。只保留每轮消息的前几十个Token把中间冗长部分删掉。适合对完整性要求不高的场景成本最低。第二种是关键词与实体抽取。用正则或模型抽取对话中出现的订单号、日期、姓名、金额等关键实体形成“事实清单”替代原始对话。前面说的【当前任务信息】区就是这么维护的。第三种是模型摘要。调用一次LLM把一段长对话转成摘要。效果好但有额外Token成本适合每隔几轮做一次而不是每轮都做。我在某跨平台系统里把这三种结合用过最新一轮消息保留原始内容历史消息走摘要事实实体独立维护。整体Token消耗比原来下降了约60%而业务指标没有明显回退。压缩的关键评价标准只有一个关键信息有没有丢。所以压缩完最好做一次校验比如确认订单号、地址这类实体是否还存在于新上下文中。5.2 路由编排别让所有请求都走同一条“重型流水线”最后这个组件很多人会忽略但它能直接改善效果、成本和速度。这个思路很朴素不同难度、不同类型的请求不应该套用同一个Prompt和同一个上下文策略。举个例子某知识库助手Demo里用户问“怎么修改密码”和“为什么A配置和B配置连不上具体报错是XXX”二者的复杂度完全不同。前者直接查FAQ回答即可后者可能要检索大量文档、组合多个知识点推理。如果把两个请求都塞进包含8K历史、12K检索资料的巨型Prompt里简单问题答题慢、费Token复杂问题又会被无关的历史干扰。路由编排就是先对用户问题做一次“意图识别分类”再决定调用哪条处理链路。分类可以用模型做也可以用Embedding相似度做甚至可以用关键词规则起步。具体到我的项目里管道长这样接收问题先做意图粗分类闲聊、常见FAQ、复杂业务咨询、需要查用户专属信息。闲聊直接走轻量模型不带检索资料历史只保留最近两轮。FAQ类只检索知识库返回固定片段不携带长历史。复杂业务走全量上下文加载历史摘要、任务信息、检索资料、分步推理。查用户专属信息优先带工作记忆和结构化用户画像而非全量历史。这样下来系统整体Token成本能降低30%到40%而且简单问题的响应速度明显变快复杂问题的成功率也没因为历史信息稀释而掉链子。有些更复杂的项目会引入多Agent编排把“查订单”和“查物流”分别路由给不同子Agent本质上是一样的思路——让正确的上下文在正确的时机到达正确的处理器。6. 从“能跑”到“能打”小白的落地路线与常见坑位六个组件都讲过一遍了但我知道你真正关心的是我现在该怎么动手下面给一条我推荐给所有刚入门同学的落地路线。6.1 四步走先能跑再能打第一步先别急着改代码。在你的项目里加日志记录每一轮请求的Token用量、是否出现截断、模型在哪一步开始“忘事”。这个诊断期建议跑两三天你会很直观看到瓶颈到底在窗口超限还是信息被淹没。第二步从“窗口预算管理”和“提示词结构化”动手。这两个组件改动最小很多时候只需要重写一下Prompt模板和加一段Token统计逻辑效果立竿见影。我见过最典型的情况是一个项目只做了“把用户订单信息抽出来放到系统指令下方附近的独立字段”回答准确率就提升了20%左右。第三步如果做的是多轮对话应用立刻实现“记忆分层”。每5到8轮做一次会话摘要把用户已提供的事实维护成结构化字段。这一步能解决最大的“失忆”痛点而且不需要引入向量数据库。第四步按需引入RAG和路由。知识库场景必须上RAG如果系统已经出现“简单问题也变慢变贵”的迹象就上路由编排。这两步可以放到业务验证了基础体验之后再做。6.2 四个我亲身踩过的坑第一个坑是把记忆和上下文混为一谈。记忆分层是让你把信息存到外部上下文是每轮要显式放进去的内容。如果你只是把用户信息存进数据库但忘了在每轮请求时把它取出来放进Prompt那等于没做。第二个坑是压缩时误伤关键实体。摘要模型有时候会把订单号、金额这类数字细节省略掉因为它觉得“不重要的细节可以模糊处理”。我的解决方案是在摘要指令里强制要求所有数字、日期、ID、地址必须原样保留不得省略或改写。第三个坑是检索片段与用户问题的话题不匹配。这个要靠换更好的Embedding模型、调整切块粒度、或者做检索后的重排序来解决。至少要做到“宁可少不可错”把相关性低的片段筛掉。第四个坑是没有评估全靠体感。上下文工程是一项需要持续迭代的活每一轮改动都必须有可量化的验证。建议你构造一组“用户必须记住的事实”测试集——比如第一轮告诉模型订单号第五轮问它订单号是多少——每次改动后跑一遍回归。上线前至少保证这批测试全部通过。我在实际跟项目时还有一个习惯在提示词里每个信息块加上版本号或更新时间比如“task_info_20250110”。排查问题时能迅速知道是哪一轮引入的脏信息、哪个模块没更新缓存。这个习惯帮我在几个项目里省了大量调试时间。7. 一点个人的收尾体会做了这么多个大模型应用项目之后我越来越觉得上下文工程不像一个具体功能更像一种“对信息流向的感知”。你不再把模型当成一个奇迹生成器而是把它当成一个强大的、但必须要喂对材料的协作者。它能做多好很大程度上取决于你能不能把对的信息、在对的时间、以对的结构、送到对的窗口位置。如果你现在正被LLM“失忆”问题折磨别急着怪模型也别急着换更大的窗口。先把上下文当作一种资源去盘点试着做一次预算分配再做一次提示词结构化大概率就能看到改观。这也是我做这个大模型项目系列的第一篇后续我还会把RAG的切块调优、记忆系统的完整设计、路由策略的工程实现分别单独展开。希望这篇内容对你有实在的帮助。