1. 项目背景与痛点拆解1.1 为什么长对话场景必须解决记忆问题用过大模型产品的朋友应该都有同感聊天窗口一旦拉长模型就“开始失忆”。前十分钟还在讨论需求细节二十分钟后你再提同一个事情它要么含糊其辞要么直接说“我没听说过这个需求”。这个问题的根源很直白——大模型的上下文窗口是有限的。虽然有号称百万级上下文的模型但真正把百万token塞进去你会面临三件事第一单次请求的推理成本高到肉疼第二响应速度肉眼可见变慢用户等不起第三模型在超长上下文里的注意力会分散中间部分的信息提取质量断崖式下降业内叫“lost in the middle”。换句话说与其拼命堆窗口大小不如在记忆管理上下功夫。这也是我做这个项目的初衷设计一套务实的长对话记忆压缩策略让模型在有限上下文里记住真正重要的信息丢掉无关紧要的内容。1.2 这个设计解决的是谁的痛点我先说一下这套方案适合谁参考免得你读半天发现跟自己的场景不匹配。在做客服机器人、AI助手、陪伴类对话产品的开发者在使用大模型API开发多轮对话应用、但被上下文长度和成本双重困扰的团队对RAG检索增强生成有基础了解但想做对话级记忆管理的人。坦白说如果你只是在本地跑着玩一次对话不超过二三十轮那直接全量塞进上下文就行没必要做压缩。但只要你打算把对话应用推向真实用户这就是迟早要面对的问题。1.3 记住一个核心矛盾整个项目围绕的矛盾就一句话上下文窗口有限但对话信息量无限。设计记忆压缩策略本质上就是在“保留关键信息”和“丢弃噪声信息”之间做动态权衡。这句话听起来像是废话但做起来你会发现难点全在“怎么判定关键”和“什么时候执行压缩”这两个细节上。2. 整体设计思路与方案选型2.1 压缩策略的三层架构我最终采用的方案不是单一技巧而是分了三层来管理记忆。这个分层思路参考了认知科学里“工作记忆—长期记忆”的区分方式。工作记忆层保存最近的原始对话不经过任何压缩保证模型对当前话题的反应质量和连贯性。摘要记忆层对较早期的对话进行摘要压缩保留语义要点丢弃对话的原始形态。关键事实层从所有对话中抽取出结构化的“硬信息”比如用户偏好、时间约定、项目参数等以键值对或条目的形式单独存储永不清空只在必要时更新。为什么分三层而不是直接上一套“全量摘要”方案因为我踩过坑。第一版我也想过“简单粗暴”——每过N轮就把前面的历史全部丢给大模型生成一段摘要然后只保留摘要。结果很惨用户五分钟前刚说过的关键需求摘要里根本没有体现。后来分析发现摘要模型在压缩过程中会基于自己的理解做“重要性判断”但这个判断经常跟用户的实际意图错位。用户觉得重要的信息模型可能觉得无关紧要就给省略了。所以后来我把“事实提取”从摘要里独立出来用强规则加模型抽取的方式单独处理。事实是硬信息摘要负责软上下文二者互相补位整个系统的鲁棒性才上来。2.2 为什么不用向量检索替代压缩顺便说一个常见误区。很多朋友会问既然上下文放不下为什么不把历史消息向量化存起来需要的时候检索出来再拼进去这个思路在RAG类问答场景没问题但在长对话场景里有三个硬伤。第一对话里的信息不是独立的知识片段它有很强的时序依赖。用户说“改成之前的方案”你得知道“之前的方案”是什么这种指代关系是向量检索很难直接解决的。第二检索有不确定性。今天检索命中了这段明天同样的query可能命中另一段用户体验不稳定。第三对话应用对延迟很敏感。每轮都做检索、重排序、拼装耗时会比直接读摘要高不少。所以我的观点是向量检索适合在知识库场景补充背景知识对话记忆管理还是应该以“压缩结构化”为主检索为辅。这也是本方案跟RAG的本质区别。2.3 压缩触发机制的设计选择再讲一个容易被忽略但很关键的设计点什么时候触发压缩我见过很多方案是“固定步长触发”比如每满20轮就压缩一次。这个做法实现简单但问题也很明显如果这20轮里全是废话寒暄压缩就是浪费如果这20轮里聊了三个重要需求压缩一次可能丢掉大量关键细节。我最终采用的是“双阈值动态触发”硬阈值上下文长度达到预设上限的70%时强制触发一次压缩。软阈值每轮对话结束后计算当前工作记忆层的“信息密度”如果密度持续走高且上下文接近上限的50%提前触发压缩。软阈值的“信息密度”怎么算我用的不是玄学方案而是给每条消息打了一个简单权重——用户主动提供的专有名词越多人名、地名、项目代号、时间数字权重越高纯语气词、口水话、重复表达权重递减。累计加权值超过一个阈值就触发压缩。这样做的好处是压缩时机更贴近真实需求用户聊正事的时候多压缩几次聊闲天的时候少折腾模型。3. 核心实现细节解析3.1 摘要层的两种不同模式摘要听起来简单但“怎么摘”大有讲究。我在项目里区分了两种摘要模式分别应对不同的压缩场景。滚动摘要每次压缩时把旧摘要和新一段原始对话合并生成一个新的摘要。这种模式的优势是摘要始终更新适合话题长期延续、前后关联度高的对话。独立摘要按时间窗或话题边界切分对话每段独立生成摘要互不覆盖。这种模式适合话题切换频繁的对话比如用户一会儿聊工作一会儿聊生活独立摘要能避免相互污染。实际使用下来我的建议是以话题为单位做切分而不是以时间为单位。时间切分的实现成本低但一个长话题被拦腰截断后两段摘要都残缺反而增加后续理解的难度。话题切分可以用一个轻量的分类模型来做或者更简单一点——监控用户消息里专有名词的连续性变化跳跃超过阈值就视为话题切换。3.2 关键词提取和事实抽取怎么落地摘要负责“讲概要”事实抽取负责“抠重点”。我在这块的实现分成两步第一步用规则做离线预筛。对话进来后先跑一遍正则和NER命名实体识别把明显是事实类的内容捞出来时间、地点、数字、型号、身份关系、允诺性动词“我下周给你”“我答应了”“没问题”。这些规则不需要全但胜在稳定、无额外成本。第二步把预筛的结果连同上下文喂给大模型做结构化抽取。Prompt里明确要求模型输出标准JSON格式字段包括用户ID、事实类型、事实内容、时间戳、关联话题ID。这一步的目标不是让模型自由发挥而是把自由文本映射到固定的Schema里方便后续检索和注入。这里有个性能优化的细节不要每轮对话都调模型做事实抽取。我的做法是攒批处理——先把原始对话在本地缓存每触发一次压缩时连带最近几轮的消息一起送去抽取。既省调用次数抽取的上下文也更完整。3.3 记忆衰减与遗忘机制做了事实抽取之后如果事实越来越多全部堆着跟上下文塞满了也没区别。因此我给每条事实设计了一个“活跃度”概念。活跃度 原始权重 × 时间衰减系数。衰减系数按指数衰减但每次被后续对话提到时会重新激活、权重回弹。这个机制跟人的记忆很像长期不提的事逐渐淡忘再次提起又重新记起。那是不是意味着系统会真的“忘掉”某些事实在实现上分两种处理低活跃度但属于全局事实比如用户的语言偏好、称呼方式这些永不删除只在低优先级队列里存放低活跃度且属于局部事实比如某一次讨论的临时细节压缩时合并进摘要但从事实表里清除。3.4 压缩后如何重建即时上下文压缩完之后的上下文不是简单拼一串摘要文本。我采用的组装策略是“金字塔结构”系统指令 关键事实层的命中的高活跃事实条目摘要记忆层中按话题边界挑选与当前话题相关的摘要块工作记忆层最近N轮原始对话。为什么要按话题挑选摘要而不是全放因为摘要积累多了同样超窗口。我的做法是给每个摘要块打标签记录它对应的话题ID和时间范围在新一轮用户请求进来时先对用户当前意图做一次轻量的分类只把相关标签的摘要块拉进上下文。这一步可以不用调模型我用的是一个几千维的向量检索在本地跑延迟可以忽略。4. 实操过程与参数调优记录4.1 实验触发的场景与数据准备我在做这套设计时先用一个模拟项目X的数据来验证效果——构造了一段35轮的产品需求沟通对话包含三个子话题需求变更、进度确认、技术选型讨论中间穿插了寒暄和重复表达等噪声。之所以选择这种构造方式是为了评测压缩算法在“话题混杂”情况下的表现。只测单话题对话所有方案看起来都很好一旦话题混杂摘要和事实抽取的缺陷就暴露了。4.2 压缩时机参数的具体设定参数这个东西给一个绝对值没意义因为不同模型的上下文长度不一样。我给出一套相对值的参考参数设定值说明硬阈值上下文上限的70%触发强制压缩软阈值启动点上下文上限的50%信息密度高时提前压缩工作记忆保留轮数最近10~15轮低于这个值会导致对话连续性受损摘要块最大数4~6块超过后按活跃度淘汰最旧的事实抽取批量大小每5轮或触发压缩时批量处理节省API调用其中“工作记忆保留轮数”最好根据业务微调客服类场景用户反复确认信息多留几轮创作类场景上下文依赖没那么强可以少留。4.3 压缩过程中的三个工程细节细节一摘要必须包含原文中的人称指代消解。压缩前原文里有大量“你”“我们”“那边”这样的代词直接压缩进摘要过几轮模型往往分不清指谁。我的做法是在摘要Prompt里加了一条强制要求不得保留未消解的代词必须写清楚具体的对象名。细节二不是每轮都要做完整压缩流程。如果每轮都做完整摘要抽取重组延迟根本扛不住。我的流水线是异步的当前轮的上下文读的是压缩结果压缩任务在后台排队完成后原子替换旧记忆。用户无感知但系统吞吐量提升明显。细节三压缩过程结果的“回读自检”。压缩完成后我会把摘要丢回模型做一个简单的QA验证——拿压缩前原文中的几个关键事实去问摘要答不出来就重新压缩。这个自检对摘要质量的兜底非常有效。实测数据是未加自检前关键信息遗漏率大约在15%左右加了之后可以压到5%以内。4.4 实际效果与性能数据在我的模拟环境里原始35轮对话约9000字压缩后上下文降到约2600字压缩率在70%左右。同时保留了三轮QA回问的准确率直接全量塞上下文准确率100%但不具有可持续性因为第60轮时窗口已经爆了固定步长压缩方案关键信息追回率约72%本方案三层策略关键信息追回率92%在延迟方面因为触发了异步压缩在线请求的P95延迟反而比全量塞上下文低了40%左右——省下的token传输时间比压缩本身消耗的时间更可观。5. 常见问题与避坑指南5.1 摘要内容被模型“脑补”这是我遇到最坑的问题。摘要模型偶尔会自己“补充”一些原文里根本没有的信息尤其当原文里有模糊表达时模型会倾向用常识去补全。这在记忆管理里是致命的因为一旦错误的“记忆”被固化进摘要后面所有对话都会被污染。我的规避方式不算高科技但很实用给摘要Prompt里加一条负面约束——“如果原文信息不完整请明确标记[缺失]严禁自行推断补全。”同时在回读自检里加了一道核实环节专门抽查摘要内容是否与原文有事实性冲突。5.2 压缩后的上下文仍然超窗有些场景压缩一次不够比如用户连续聊了两小时摘要块本身就已经很多了。我的兜底方案是“二级摘要”当摘要块超过特定数量时把多个摘要块再合并成一个更粗粒度的总摘要同时保留最后两块原始摘要和全部关键事实层。这个方案在极端长对话测试中表现稳定代价是更早期的对话细节基本不可考。5.3 事实抽取的“误抽和漏抽”误抽典型场景用户在开玩笑时说“我要把你公司买下来”抽取模型可能把它当成事实。漏抽典型场景用户间接表述“我不太喜欢那种风格”没有明确说“不要”但其实是明确偏好。我的处理思路是误抽靠“置信度阈值”拦截——抽取时让模型同时输出置信度分数低于0.6的不进入事实层只保留在摘要里。漏抽靠“意图型事实补采”——专门针对偏好、否定、承诺这几类语句走一套修改过的Prompt模板再抽一遍。5.4 不同语言场景的兼容性中文对话里的“指代消解”和英文很不一样。中文大量使用零代词省去主语摘要时如果原文没有明确主语模型容易乱猜。我的做法是压缩前先跑一遍指代消解预处理把能确认的主语补全后再送去摘要。这个预处理不依赖大模型用规则加一个小型序列标注模型就能完成。5.5 一个容易被忽略的体验问题压缩后模型回答的“语气一致性”会变差。原始对话里用户和AI建立的默契比如特定的称呼方式、玩笑语气压缩成干巴巴的摘要后就丢失了。我最后在组装上下文时额外注入了一条“对话风格提示”从工作记忆层的原句中提取几个典型表达风格拼进系统指令里。代价极小但对用户体验的改善很明显。6. 一些经验总结与扩展建议6.1 设计时要先把“丢什么”想清楚做记忆压缩大部分人第一时间想的是“怎么保留关键信息”。但做得久了你会意识到真正体现功力的反而是“怎么确定丢什么”。把决策权完全交给模型的注意力机制代价不可控全靠规则灵活性不够。最好的状态是规则粗筛框架模型在框架内做判断。6.2 从“压缩”到“记忆自治”的演进方向我在实际做完这套系统之后发现它还有两个自然延伸的方向。一个是按用户的对话习惯动态调整压缩偏好——比如有的用户偏好聊细节压缩力度就轻一些有的用户讲话简洁高效压缩力度就大一些。另一个方向是在多轮压缩之后自动生成一份“用户画像摘要”新会话开场时直接加载不需要用户重复自我介绍。6.3 最后一句话长对话记忆压缩设计真正的门槛不在算法而在工程权衡。你在每个决策点做的取舍——压缩多少、何时压缩、丢什么留什么——都会在用户的实际体验上被成倍放大。我的建议是别追求一步到位先用三层结构搭好框架再逐步收紧参数在真实对话数据上反复打磨。这个过程中踩坑是常态但只要把坑记录下来下一版就会明显更顺。
1. 项目背景与痛点拆解1.1 为什么长对话场景必须解决记忆问题用过大模型产品的朋友应该都有同感聊天窗口一旦拉长模型就“开始失忆”。前十分钟还在讨论需求细节二十分钟后你再提同一个事情它要么含糊其辞要么直接说“我没听说过这个需求”。这个问题的根源很直白——大模型的上下文窗口是有限的。虽然有号称百万级上下文的模型但真正把百万token塞进去你会面临三件事第一单次请求的推理成本高到肉疼第二响应速度肉眼可见变慢用户等不起第三模型在超长上下文里的注意力会分散中间部分的信息提取质量断崖式下降业内叫“lost in the middle”。换句话说与其拼命堆窗口大小不如在记忆管理上下功夫。这也是我做这个项目的初衷设计一套务实的长对话记忆压缩策略让模型在有限上下文里记住真正重要的信息丢掉无关紧要的内容。1.2 这个设计解决的是谁的痛点我先说一下这套方案适合谁参考免得你读半天发现跟自己的场景不匹配。在做客服机器人、AI助手、陪伴类对话产品的开发者在使用大模型API开发多轮对话应用、但被上下文长度和成本双重困扰的团队对RAG检索增强生成有基础了解但想做对话级记忆管理的人。坦白说如果你只是在本地跑着玩一次对话不超过二三十轮那直接全量塞进上下文就行没必要做压缩。但只要你打算把对话应用推向真实用户这就是迟早要面对的问题。1.3 记住一个核心矛盾整个项目围绕的矛盾就一句话上下文窗口有限但对话信息量无限。设计记忆压缩策略本质上就是在“保留关键信息”和“丢弃噪声信息”之间做动态权衡。这句话听起来像是废话但做起来你会发现难点全在“怎么判定关键”和“什么时候执行压缩”这两个细节上。2. 整体设计思路与方案选型2.1 压缩策略的三层架构我最终采用的方案不是单一技巧而是分了三层来管理记忆。这个分层思路参考了认知科学里“工作记忆—长期记忆”的区分方式。工作记忆层保存最近的原始对话不经过任何压缩保证模型对当前话题的反应质量和连贯性。摘要记忆层对较早期的对话进行摘要压缩保留语义要点丢弃对话的原始形态。关键事实层从所有对话中抽取出结构化的“硬信息”比如用户偏好、时间约定、项目参数等以键值对或条目的形式单独存储永不清空只在必要时更新。为什么分三层而不是直接上一套“全量摘要”方案因为我踩过坑。第一版我也想过“简单粗暴”——每过N轮就把前面的历史全部丢给大模型生成一段摘要然后只保留摘要。结果很惨用户五分钟前刚说过的关键需求摘要里根本没有体现。后来分析发现摘要模型在压缩过程中会基于自己的理解做“重要性判断”但这个判断经常跟用户的实际意图错位。用户觉得重要的信息模型可能觉得无关紧要就给省略了。所以后来我把“事实提取”从摘要里独立出来用强规则加模型抽取的方式单独处理。事实是硬信息摘要负责软上下文二者互相补位整个系统的鲁棒性才上来。2.2 为什么不用向量检索替代压缩顺便说一个常见误区。很多朋友会问既然上下文放不下为什么不把历史消息向量化存起来需要的时候检索出来再拼进去这个思路在RAG类问答场景没问题但在长对话场景里有三个硬伤。第一对话里的信息不是独立的知识片段它有很强的时序依赖。用户说“改成之前的方案”你得知道“之前的方案”是什么这种指代关系是向量检索很难直接解决的。第二检索有不确定性。今天检索命中了这段明天同样的query可能命中另一段用户体验不稳定。第三对话应用对延迟很敏感。每轮都做检索、重排序、拼装耗时会比直接读摘要高不少。所以我的观点是向量检索适合在知识库场景补充背景知识对话记忆管理还是应该以“压缩结构化”为主检索为辅。这也是本方案跟RAG的本质区别。2.3 压缩触发机制的设计选择再讲一个容易被忽略但很关键的设计点什么时候触发压缩我见过很多方案是“固定步长触发”比如每满20轮就压缩一次。这个做法实现简单但问题也很明显如果这20轮里全是废话寒暄压缩就是浪费如果这20轮里聊了三个重要需求压缩一次可能丢掉大量关键细节。我最终采用的是“双阈值动态触发”硬阈值上下文长度达到预设上限的70%时强制触发一次压缩。软阈值每轮对话结束后计算当前工作记忆层的“信息密度”如果密度持续走高且上下文接近上限的50%提前触发压缩。软阈值的“信息密度”怎么算我用的不是玄学方案而是给每条消息打了一个简单权重——用户主动提供的专有名词越多人名、地名、项目代号、时间数字权重越高纯语气词、口水话、重复表达权重递减。累计加权值超过一个阈值就触发压缩。这样做的好处是压缩时机更贴近真实需求用户聊正事的时候多压缩几次聊闲天的时候少折腾模型。3. 核心实现细节解析3.1 摘要层的两种不同模式摘要听起来简单但“怎么摘”大有讲究。我在项目里区分了两种摘要模式分别应对不同的压缩场景。滚动摘要每次压缩时把旧摘要和新一段原始对话合并生成一个新的摘要。这种模式的优势是摘要始终更新适合话题长期延续、前后关联度高的对话。独立摘要按时间窗或话题边界切分对话每段独立生成摘要互不覆盖。这种模式适合话题切换频繁的对话比如用户一会儿聊工作一会儿聊生活独立摘要能避免相互污染。实际使用下来我的建议是以话题为单位做切分而不是以时间为单位。时间切分的实现成本低但一个长话题被拦腰截断后两段摘要都残缺反而增加后续理解的难度。话题切分可以用一个轻量的分类模型来做或者更简单一点——监控用户消息里专有名词的连续性变化跳跃超过阈值就视为话题切换。3.2 关键词提取和事实抽取怎么落地摘要负责“讲概要”事实抽取负责“抠重点”。我在这块的实现分成两步第一步用规则做离线预筛。对话进来后先跑一遍正则和NER命名实体识别把明显是事实类的内容捞出来时间、地点、数字、型号、身份关系、允诺性动词“我下周给你”“我答应了”“没问题”。这些规则不需要全但胜在稳定、无额外成本。第二步把预筛的结果连同上下文喂给大模型做结构化抽取。Prompt里明确要求模型输出标准JSON格式字段包括用户ID、事实类型、事实内容、时间戳、关联话题ID。这一步的目标不是让模型自由发挥而是把自由文本映射到固定的Schema里方便后续检索和注入。这里有个性能优化的细节不要每轮对话都调模型做事实抽取。我的做法是攒批处理——先把原始对话在本地缓存每触发一次压缩时连带最近几轮的消息一起送去抽取。既省调用次数抽取的上下文也更完整。3.3 记忆衰减与遗忘机制做了事实抽取之后如果事实越来越多全部堆着跟上下文塞满了也没区别。因此我给每条事实设计了一个“活跃度”概念。活跃度 原始权重 × 时间衰减系数。衰减系数按指数衰减但每次被后续对话提到时会重新激活、权重回弹。这个机制跟人的记忆很像长期不提的事逐渐淡忘再次提起又重新记起。那是不是意味着系统会真的“忘掉”某些事实在实现上分两种处理低活跃度但属于全局事实比如用户的语言偏好、称呼方式这些永不删除只在低优先级队列里存放低活跃度且属于局部事实比如某一次讨论的临时细节压缩时合并进摘要但从事实表里清除。3.4 压缩后如何重建即时上下文压缩完之后的上下文不是简单拼一串摘要文本。我采用的组装策略是“金字塔结构”系统指令 关键事实层的命中的高活跃事实条目摘要记忆层中按话题边界挑选与当前话题相关的摘要块工作记忆层最近N轮原始对话。为什么要按话题挑选摘要而不是全放因为摘要积累多了同样超窗口。我的做法是给每个摘要块打标签记录它对应的话题ID和时间范围在新一轮用户请求进来时先对用户当前意图做一次轻量的分类只把相关标签的摘要块拉进上下文。这一步可以不用调模型我用的是一个几千维的向量检索在本地跑延迟可以忽略。4. 实操过程与参数调优记录4.1 实验触发的场景与数据准备我在做这套设计时先用一个模拟项目X的数据来验证效果——构造了一段35轮的产品需求沟通对话包含三个子话题需求变更、进度确认、技术选型讨论中间穿插了寒暄和重复表达等噪声。之所以选择这种构造方式是为了评测压缩算法在“话题混杂”情况下的表现。只测单话题对话所有方案看起来都很好一旦话题混杂摘要和事实抽取的缺陷就暴露了。4.2 压缩时机参数的具体设定参数这个东西给一个绝对值没意义因为不同模型的上下文长度不一样。我给出一套相对值的参考参数设定值说明硬阈值上下文上限的70%触发强制压缩软阈值启动点上下文上限的50%信息密度高时提前压缩工作记忆保留轮数最近10~15轮低于这个值会导致对话连续性受损摘要块最大数4~6块超过后按活跃度淘汰最旧的事实抽取批量大小每5轮或触发压缩时批量处理节省API调用其中“工作记忆保留轮数”最好根据业务微调客服类场景用户反复确认信息多留几轮创作类场景上下文依赖没那么强可以少留。4.3 压缩过程中的三个工程细节细节一摘要必须包含原文中的人称指代消解。压缩前原文里有大量“你”“我们”“那边”这样的代词直接压缩进摘要过几轮模型往往分不清指谁。我的做法是在摘要Prompt里加了一条强制要求不得保留未消解的代词必须写清楚具体的对象名。细节二不是每轮都要做完整压缩流程。如果每轮都做完整摘要抽取重组延迟根本扛不住。我的流水线是异步的当前轮的上下文读的是压缩结果压缩任务在后台排队完成后原子替换旧记忆。用户无感知但系统吞吐量提升明显。细节三压缩过程结果的“回读自检”。压缩完成后我会把摘要丢回模型做一个简单的QA验证——拿压缩前原文中的几个关键事实去问摘要答不出来就重新压缩。这个自检对摘要质量的兜底非常有效。实测数据是未加自检前关键信息遗漏率大约在15%左右加了之后可以压到5%以内。4.4 实际效果与性能数据在我的模拟环境里原始35轮对话约9000字压缩后上下文降到约2600字压缩率在70%左右。同时保留了三轮QA回问的准确率直接全量塞上下文准确率100%但不具有可持续性因为第60轮时窗口已经爆了固定步长压缩方案关键信息追回率约72%本方案三层策略关键信息追回率92%在延迟方面因为触发了异步压缩在线请求的P95延迟反而比全量塞上下文低了40%左右——省下的token传输时间比压缩本身消耗的时间更可观。5. 常见问题与避坑指南5.1 摘要内容被模型“脑补”这是我遇到最坑的问题。摘要模型偶尔会自己“补充”一些原文里根本没有的信息尤其当原文里有模糊表达时模型会倾向用常识去补全。这在记忆管理里是致命的因为一旦错误的“记忆”被固化进摘要后面所有对话都会被污染。我的规避方式不算高科技但很实用给摘要Prompt里加一条负面约束——“如果原文信息不完整请明确标记[缺失]严禁自行推断补全。”同时在回读自检里加了一道核实环节专门抽查摘要内容是否与原文有事实性冲突。5.2 压缩后的上下文仍然超窗有些场景压缩一次不够比如用户连续聊了两小时摘要块本身就已经很多了。我的兜底方案是“二级摘要”当摘要块超过特定数量时把多个摘要块再合并成一个更粗粒度的总摘要同时保留最后两块原始摘要和全部关键事实层。这个方案在极端长对话测试中表现稳定代价是更早期的对话细节基本不可考。5.3 事实抽取的“误抽和漏抽”误抽典型场景用户在开玩笑时说“我要把你公司买下来”抽取模型可能把它当成事实。漏抽典型场景用户间接表述“我不太喜欢那种风格”没有明确说“不要”但其实是明确偏好。我的处理思路是误抽靠“置信度阈值”拦截——抽取时让模型同时输出置信度分数低于0.6的不进入事实层只保留在摘要里。漏抽靠“意图型事实补采”——专门针对偏好、否定、承诺这几类语句走一套修改过的Prompt模板再抽一遍。5.4 不同语言场景的兼容性中文对话里的“指代消解”和英文很不一样。中文大量使用零代词省去主语摘要时如果原文没有明确主语模型容易乱猜。我的做法是压缩前先跑一遍指代消解预处理把能确认的主语补全后再送去摘要。这个预处理不依赖大模型用规则加一个小型序列标注模型就能完成。5.5 一个容易被忽略的体验问题压缩后模型回答的“语气一致性”会变差。原始对话里用户和AI建立的默契比如特定的称呼方式、玩笑语气压缩成干巴巴的摘要后就丢失了。我最后在组装上下文时额外注入了一条“对话风格提示”从工作记忆层的原句中提取几个典型表达风格拼进系统指令里。代价极小但对用户体验的改善很明显。6. 一些经验总结与扩展建议6.1 设计时要先把“丢什么”想清楚做记忆压缩大部分人第一时间想的是“怎么保留关键信息”。但做得久了你会意识到真正体现功力的反而是“怎么确定丢什么”。把决策权完全交给模型的注意力机制代价不可控全靠规则灵活性不够。最好的状态是规则粗筛框架模型在框架内做判断。6.2 从“压缩”到“记忆自治”的演进方向我在实际做完这套系统之后发现它还有两个自然延伸的方向。一个是按用户的对话习惯动态调整压缩偏好——比如有的用户偏好聊细节压缩力度就轻一些有的用户讲话简洁高效压缩力度就大一些。另一个方向是在多轮压缩之后自动生成一份“用户画像摘要”新会话开场时直接加载不需要用户重复自我介绍。6.3 最后一句话长对话记忆压缩设计真正的门槛不在算法而在工程权衡。你在每个决策点做的取舍——压缩多少、何时压缩、丢什么留什么——都会在用户的实际体验上被成倍放大。我的建议是别追求一步到位先用三层结构搭好框架再逐步收紧参数在真实对话数据上反复打磨。这个过程中踩坑是常态但只要把坑记录下来下一版就会明显更顺。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
