040、 对话记忆管理滑动窗口与摘要记忆上个月排查一个线上客服 bot现象很怪用户聊到第 12 轮机器人开始把用户早先报过的订单号当成新的还一本正经地回复“请核对您的订单号”。翻日志发现prompt 拼接出来的 messages 数组已经 4000 多 token而模型上下文上限是 4096。再往下查工程实现里用的是最无脑的截断策略超过 20 条就messages.pop(0)。订单号正好在第 3 轮被弹出去模型当然不认识。这就是典型的内存管理事故——不是模型笨是喂进去的上下文已经残废了。很多朋友一开始都掉进“上下文窗口很大全塞进去就行”的幻想。等上线后并发一高token 成本烧得肉疼延迟也随聊天轮数线性增长。更隐蔽的问题是模型对超长上下文的任务注意力会衰减尤其中间部分很容易被忽略。你塞了 20 页聊天记录模型只记住了头和尾。所以对话记忆管理不是脏活是正经的工程架构问题。滑动窗口是第一个该想到的方案。核心思想很直白只保留最近 N 条对话更早的直接丢掉。但这里的 N 不能是“条数”必须是“token 数”。按条数截断会坑死你因为用户一句“好”和一句长故事可能差几百倍 token。要按 token 预算来算窗口。用 OpenAI 的话就用tiktoken做编码本地估算 token 数。其他模型也有各自的 tokenizer。写一个滑动窗口的伪代码给你看importtiktoken enctiktoken.get_encoding(cl100k_base)defcount_tokens(text:str)-int:returnlen(enc.encode(text))defslide_window(messages,max_tokens3000):# 别上来就砍 messages先把每条消息的 token 数算好budgetmax_tokens window[]# 从尾部往前扫保住最近的上下文formsginreversed(messages):msg_tokenscount_tokens(msg[content])4# 4个token是消息格式开销ifmsg_tokensbudget:# 单条消息超过预算只能硬截断内容这里要小心# 实在没办法时对这条消息做截断但千万别只截尾部# 最好保留开头和结尾中间用省略但模型不一定吃这套continuewindow.append(msg)budget-msg_tokensifbudget0:breakreturnlist(reversed(window))打眼一看没问题但实际跑起来会发现一个尴尬场景用户第 1 轮说了自己的名字第 2 轮说了需求第 3 轮又改了需求。第 15 轮你想让模型记住用户名字滑动窗口早把第 1 轮冲掉了。你只能安慰自己“记住名字是另一个模块的事”但用户不这么想他以为你记性很好因为大模型看起来像真人。所以滑动窗口只能解决基本生存问题解决不了长期依赖。这里就该上摘要记忆了。思路也简单被滑动窗口挤出去的历史不是直接扔而是让大模型把旧对话浓缩成一段摘要然后把这摘要放到上下文最前面相当于给模型一个“过去发生了什么”的记忆锚点。摘要可以是一个 system message也可以是一条 role: “system” 的虚拟消息。工程上怎么落地我习惯把 messages 分成三块固定 system prompt摘要区最近窗口区。摘要区在最前面最近窗口区在最后。每次新用户消息进来先塞进最近窗口区然后检查总 token 数是否超阈值。超过了就把当前窗口从中间劈成两半前一半丢给 LLM 生成摘要后一半保留为最近窗口再把新生成的摘要合并到旧的摘要里。注意摘要不能每次都重新生成旧的整个历史那样成本爆炸。要增量摘要。举个例子写个compress_and_summarizedefcompress_and_summarize(messages,summary_so_far,threshold2000):# messages 是当前完整上下文包含 summary# 先把摘要独立出来剩余是真实对话dialog[mforminmessagesifm[role]!system]# 检查总 tokentotal_tokenscount_tokens(json.dumps(messages,ensure_asciiFalse))iftotal_tokensthreshold:returnmessages,summary_so_far# 超过阈值把对话按 token 分成 old 和 recent# old 占 60%recent 占 40% 看你的业务# 这里我一般按最近 10 条或者最近 1000 token 作为 recentrecentdialog[-10:]# 最近10条保留原样olddialog[:-10]# 前面的全部送进摘要器ifnotold:returnmessages,summary_so_far# 没有可压缩的# 拼一个临时的 prompt 让大模型浓缩summarize_promptf 这是历史对话片段请生成简洁的中文摘要保留关键实体人名、订单号、时间、情绪、反复确认的偏好。 已有摘要{summary_so_faror无}新对话{json.dumps(old,ensure_asciiFalse)}输出一句到三句话即可不要寒暄。 new_summarycall_llm(summarize_prompt)# 这里用便宜的模型也行# 别让 summary 无限膨胀限制最大 500 tokenifcount_tokens(new_summary)500:new_summarynew_summary[:200]# 粗暴截断但比没有强# 返回新的 messages 结构compressed[{role:system,content:f对话摘要{new_summary}}]recent# 注意旧摘要已经融合进 new_summary 了别再保留 old 内容returncompressed,new_summary这里有几个坑必须提醒。第一摘要生成也是要调用 LLM 的耗时和成本不可忽略。如果每轮都压缩那每轮多一次模型调用延迟直接翻倍。你可以设置“压缩触发条件”比如消息条数超过 20 并且 token 超预算才触发。或者更懒一点只在用户发完一轮超长消息后触发一次。别用小模型生成摘要真的会漏关键信息。我试过用 3.5 来 summarize结果把用户说过“不要打电话联系”给漏了后来客服真的打了电话用户投诉。第二摘要合并会导致信息二次失真。第一次摘要丢掉细节第二次基于摘要再摘要可能把最初的重要事实扭曲。比如“用户是上海人”可能被逐步淡化成“用户在南方”。解决思路是单独维护一个“不可压缩事实”列表如姓名、订单号、偏好禁忌。这个列表不放到对话历史里而是放在 system prompt 的固定区域。每次新对话进来用正则或一个分类模型把关键实体抽出来更新事实列表。摘要只管那些不太关键但有助于理解语气脉络的对话。这么做以后“用户名字被冲掉”的问题就根治了。第三滑动窗口和摘要的协作顺序有讲究。不要先截断再摘要那样反正已经丢了。正确顺序是先判断是否超阈值超了就把旧的一半摘出来生成摘要塞回头部再丢弃已经摘要过的原始消息。另一条经验是摘要区要放在最近窗口区之前但不要离 system prompt 太远。有些模型对 system prompt 和后续消息之间的位置很敏感你可以在 system prompt 里告诉模型“最前面有一段历史摘要是较早的聊天记录当前对话在摘要之后。”这样模型不会把摘要当成当前用户的问题。实际代码里我常常把 messages 组织成final_messages[{role:system,content:system_prompt},{role:system,content:f历史摘要{summary}},{role:user,content:...},# 最近窗口里的消息{role:assistant,content:...}]有的模型只认一个 system 消息那就把 system_prompt 和摘要拼在一起用 “\n\n” 分隔。千万别搞成两个 system有些 OpenAI 兼容接口会报错或者只取最后一个。还有一个很值得注意的点摘要的更新时机。如果你在每次压缩时都让模型重新读取“旧摘要新旧对话”那么摘要会越来越像“故事梗概”丢失具体性。我推荐“分层摘要”维持一个短期摘要比如最近 5 轮的核心当短期摘要累积到一定程度再把它合并到长期摘要。这有点像 CPU 的 L1/L2 缓存。但对一般项目两层就够了。长期摘要存内存或 Redis短期摘要放进上下文里。再说说滑动窗口的窗口大小怎么定。别拍脑袋写个 2000。得看你的应用场景如果是客服用户平均会话 8 轮窗口留 3000 token 够了。如果是代码助手上下文里要留很大的空间给代码片段和工具返回值窗口就留 1500。建议根据你的最大上下文长度动态计算窗口预算。比如模型上下文是 8k固定 system prompt 占 1k工具定义占 1k摘要预留 500那窗口预算就是 8k - 1k - 1k - 500 5.5k。再留 10% 安全余量防止响应 token 溢出。核心公式就是窗口 总上下文 - 固定开销 - 摘要开销 - 最大响应长度。代码里我一般用常量配置但写清楚注释。MAX_CONTEXT8192MAX_RESPONSE1024SYSTEM_PROMPT_TOKENS800TOOL_DEF_TOKENS600# 摘要最多给 500 token多了就截断SUMMARY_BUDGET500WINDOW_BUDGETMAX_CONTEXT-MAX_RESPONSE-SYSTEM_PROMPT_TOKENS-TOOL_DEF_TOKENS-SUMMARY_BUDGET# 最后再留出 512 token 给格式和意外情况WINDOW_BUDGET-512最后聊点个人经验。别迷信“无限记忆”。大模型对话系统本质上是给模型喂一个适合它浏览的上下文环境。记忆管理的目标不是回忆一切而是让模型在有限的注意力里做出最佳表现。滑动窗口和摘要是一对搭档窗口负责近期精确摘要负责长期模糊。当精度要求高的信息订单号、日期、人名必须跳出摘要机制用结构化的“事实库”单独存否则迟早要出事故。调试这类系统时最好在日志里打印每次压缩前的消息数、token 数、摘要文本。我见过太多人只看最终回复对不对不知道模型其实已经被自己的摘要带偏了。在开发环境里你可以把每一次摘要存下来做 diff看看哪一轮开始“记忆漂移”。也可以做回放测试用同样的问题问系统对比有摘要和无摘要的输出差异。这块没有标准答案但一个朴素原则是摘要越短丢的细节越多但模型越容易遵从指令摘要越长保留的信息越全但会挤压窗口空间。我一般把摘要控制在 300-500 token超过就交给分层摘要机制继续压缩。另一个容易被忽视的问题是并发。多个用户会话共享同一个 LLM 实例摘要生成如果放在请求线程里会导致 TP98 延迟暴涨。更合理的是把“压缩摘要”做成异步任务用户请求结束后在后台跑。实现上可以用 Redis 列表存消息历史后台 worker 拉取并压缩再把摘要写回。这样用户感知不到摘要延迟但缺点是可能在你压缩的时候用户又发了新消息造成竞态。你得用版本号或时间戳保证顺序。最简单的做法是每次用户发消息时先检查消息数是否超过阈值超过就同步阻塞做摘要但只对当前会话阻塞其他会话不受影响。听起来还是同步但你可以把摘要模型换一个低延迟的小模型或者干脆用规则抽关键信息做轻量摘要等用户空闲再让大模型精修。我最近比较喜欢的结构是三分法短时缓冲最近 20 条原始消息中层摘要每 20 条压缩成 200 token长期事实表从所有消息中抽取的 key-value。响应生成时把事实表 中层摘要 短时缓冲拼接起来。短时缓冲用滑动窗口中层摘要每隔几轮自动更新长期事实表用正则和简单的 NER 维护。这一套组合下来用户体验是“模型记性真好”成本只增加了大概 15% 的额外 LLM 调用。别小看这 15%如果每天 100 万次请求那也是一笔不小的开销。所以摘要触发条件要写得狠一点消息少于 20 条或者 token 少于 3000 时绝不触发摘要。写代码的时候还有个小技巧把摘要生成也暴露成独立的 API 函数这样可以单独压测。压测时注意摘要模型不是用来对话的温度应该调低0 到 0.3否则每次摘要结果不稳定你会看到模型一会记住用户名一会记不住。另外摘要 prompt 里面千万别说“请总结以下对话”模型会产生“总结腔”输出“用户询问了…”。我想要的是客观的关键信息列表所以 prompt 改成“提取对话中的可用信息人物、数字、决策、偏好、承诺。避免废话。”这样得到的东西更像结构化的摘要后面拼接进上下文也不会扰乱了模型的语气。多说一句有些对话系统是用向量数据库做长期记忆每次检索 top-k 相关历史片段塞回上下文。那个方向也不错但那是“检索式记忆”跟本章的“压缩式记忆”搭配使用才能发挥最大效果。滑动窗口负责时间近因摘要负责全局脉络检索负责语义相关。如果你只搞一个摘要遇到用户问“三天前你说过什么”还能应付但遇到“上个月我哪个项目卡住了”这种摘要可能已经把它抹掉了。检索式记忆可以作为补充。不过那是后续章节的内容这里不展开。回到文章开头的那个订单号事故。后来我怎么修的首先把订单号抽出来放进了事实表然后给对话历史加了一个基于 token 的滑动窗口窗口大小设置为 3000超过就触发异步摘要。修完之后用户聊 50 轮也不会再丢订单号。而且我注意到一个意外收获因为窗口变短了模型回应延迟直接降了一半用户投诉还少了。你看记忆管理不只是防止模型失忆还能改善性能和成本。这活干得值。
040、 对话记忆管理滑动窗口与摘要记忆上个月排查一个线上客服 bot现象很怪用户聊到第 12 轮机器人开始把用户早先报过的订单号当成新的还一本正经地回复“请核对您的订单号”。翻日志发现prompt 拼接出来的 messages 数组已经 4000 多 token而模型上下文上限是 4096。再往下查工程实现里用的是最无脑的截断策略超过 20 条就messages.pop(0)。订单号正好在第 3 轮被弹出去模型当然不认识。这就是典型的内存管理事故——不是模型笨是喂进去的上下文已经残废了。很多朋友一开始都掉进“上下文窗口很大全塞进去就行”的幻想。等上线后并发一高token 成本烧得肉疼延迟也随聊天轮数线性增长。更隐蔽的问题是模型对超长上下文的任务注意力会衰减尤其中间部分很容易被忽略。你塞了 20 页聊天记录模型只记住了头和尾。所以对话记忆管理不是脏活是正经的工程架构问题。滑动窗口是第一个该想到的方案。核心思想很直白只保留最近 N 条对话更早的直接丢掉。但这里的 N 不能是“条数”必须是“token 数”。按条数截断会坑死你因为用户一句“好”和一句长故事可能差几百倍 token。要按 token 预算来算窗口。用 OpenAI 的话就用tiktoken做编码本地估算 token 数。其他模型也有各自的 tokenizer。写一个滑动窗口的伪代码给你看importtiktoken enctiktoken.get_encoding(cl100k_base)defcount_tokens(text:str)-int:returnlen(enc.encode(text))defslide_window(messages,max_tokens3000):# 别上来就砍 messages先把每条消息的 token 数算好budgetmax_tokens window[]# 从尾部往前扫保住最近的上下文formsginreversed(messages):msg_tokenscount_tokens(msg[content])4# 4个token是消息格式开销ifmsg_tokensbudget:# 单条消息超过预算只能硬截断内容这里要小心# 实在没办法时对这条消息做截断但千万别只截尾部# 最好保留开头和结尾中间用省略但模型不一定吃这套continuewindow.append(msg)budget-msg_tokensifbudget0:breakreturnlist(reversed(window))打眼一看没问题但实际跑起来会发现一个尴尬场景用户第 1 轮说了自己的名字第 2 轮说了需求第 3 轮又改了需求。第 15 轮你想让模型记住用户名字滑动窗口早把第 1 轮冲掉了。你只能安慰自己“记住名字是另一个模块的事”但用户不这么想他以为你记性很好因为大模型看起来像真人。所以滑动窗口只能解决基本生存问题解决不了长期依赖。这里就该上摘要记忆了。思路也简单被滑动窗口挤出去的历史不是直接扔而是让大模型把旧对话浓缩成一段摘要然后把这摘要放到上下文最前面相当于给模型一个“过去发生了什么”的记忆锚点。摘要可以是一个 system message也可以是一条 role: “system” 的虚拟消息。工程上怎么落地我习惯把 messages 分成三块固定 system prompt摘要区最近窗口区。摘要区在最前面最近窗口区在最后。每次新用户消息进来先塞进最近窗口区然后检查总 token 数是否超阈值。超过了就把当前窗口从中间劈成两半前一半丢给 LLM 生成摘要后一半保留为最近窗口再把新生成的摘要合并到旧的摘要里。注意摘要不能每次都重新生成旧的整个历史那样成本爆炸。要增量摘要。举个例子写个compress_and_summarizedefcompress_and_summarize(messages,summary_so_far,threshold2000):# messages 是当前完整上下文包含 summary# 先把摘要独立出来剩余是真实对话dialog[mforminmessagesifm[role]!system]# 检查总 tokentotal_tokenscount_tokens(json.dumps(messages,ensure_asciiFalse))iftotal_tokensthreshold:returnmessages,summary_so_far# 超过阈值把对话按 token 分成 old 和 recent# old 占 60%recent 占 40% 看你的业务# 这里我一般按最近 10 条或者最近 1000 token 作为 recentrecentdialog[-10:]# 最近10条保留原样olddialog[:-10]# 前面的全部送进摘要器ifnotold:returnmessages,summary_so_far# 没有可压缩的# 拼一个临时的 prompt 让大模型浓缩summarize_promptf 这是历史对话片段请生成简洁的中文摘要保留关键实体人名、订单号、时间、情绪、反复确认的偏好。 已有摘要{summary_so_faror无}新对话{json.dumps(old,ensure_asciiFalse)}输出一句到三句话即可不要寒暄。 new_summarycall_llm(summarize_prompt)# 这里用便宜的模型也行# 别让 summary 无限膨胀限制最大 500 tokenifcount_tokens(new_summary)500:new_summarynew_summary[:200]# 粗暴截断但比没有强# 返回新的 messages 结构compressed[{role:system,content:f对话摘要{new_summary}}]recent# 注意旧摘要已经融合进 new_summary 了别再保留 old 内容returncompressed,new_summary这里有几个坑必须提醒。第一摘要生成也是要调用 LLM 的耗时和成本不可忽略。如果每轮都压缩那每轮多一次模型调用延迟直接翻倍。你可以设置“压缩触发条件”比如消息条数超过 20 并且 token 超预算才触发。或者更懒一点只在用户发完一轮超长消息后触发一次。别用小模型生成摘要真的会漏关键信息。我试过用 3.5 来 summarize结果把用户说过“不要打电话联系”给漏了后来客服真的打了电话用户投诉。第二摘要合并会导致信息二次失真。第一次摘要丢掉细节第二次基于摘要再摘要可能把最初的重要事实扭曲。比如“用户是上海人”可能被逐步淡化成“用户在南方”。解决思路是单独维护一个“不可压缩事实”列表如姓名、订单号、偏好禁忌。这个列表不放到对话历史里而是放在 system prompt 的固定区域。每次新对话进来用正则或一个分类模型把关键实体抽出来更新事实列表。摘要只管那些不太关键但有助于理解语气脉络的对话。这么做以后“用户名字被冲掉”的问题就根治了。第三滑动窗口和摘要的协作顺序有讲究。不要先截断再摘要那样反正已经丢了。正确顺序是先判断是否超阈值超了就把旧的一半摘出来生成摘要塞回头部再丢弃已经摘要过的原始消息。另一条经验是摘要区要放在最近窗口区之前但不要离 system prompt 太远。有些模型对 system prompt 和后续消息之间的位置很敏感你可以在 system prompt 里告诉模型“最前面有一段历史摘要是较早的聊天记录当前对话在摘要之后。”这样模型不会把摘要当成当前用户的问题。实际代码里我常常把 messages 组织成final_messages[{role:system,content:system_prompt},{role:system,content:f历史摘要{summary}},{role:user,content:...},# 最近窗口里的消息{role:assistant,content:...}]有的模型只认一个 system 消息那就把 system_prompt 和摘要拼在一起用 “\n\n” 分隔。千万别搞成两个 system有些 OpenAI 兼容接口会报错或者只取最后一个。还有一个很值得注意的点摘要的更新时机。如果你在每次压缩时都让模型重新读取“旧摘要新旧对话”那么摘要会越来越像“故事梗概”丢失具体性。我推荐“分层摘要”维持一个短期摘要比如最近 5 轮的核心当短期摘要累积到一定程度再把它合并到长期摘要。这有点像 CPU 的 L1/L2 缓存。但对一般项目两层就够了。长期摘要存内存或 Redis短期摘要放进上下文里。再说说滑动窗口的窗口大小怎么定。别拍脑袋写个 2000。得看你的应用场景如果是客服用户平均会话 8 轮窗口留 3000 token 够了。如果是代码助手上下文里要留很大的空间给代码片段和工具返回值窗口就留 1500。建议根据你的最大上下文长度动态计算窗口预算。比如模型上下文是 8k固定 system prompt 占 1k工具定义占 1k摘要预留 500那窗口预算就是 8k - 1k - 1k - 500 5.5k。再留 10% 安全余量防止响应 token 溢出。核心公式就是窗口 总上下文 - 固定开销 - 摘要开销 - 最大响应长度。代码里我一般用常量配置但写清楚注释。MAX_CONTEXT8192MAX_RESPONSE1024SYSTEM_PROMPT_TOKENS800TOOL_DEF_TOKENS600# 摘要最多给 500 token多了就截断SUMMARY_BUDGET500WINDOW_BUDGETMAX_CONTEXT-MAX_RESPONSE-SYSTEM_PROMPT_TOKENS-TOOL_DEF_TOKENS-SUMMARY_BUDGET# 最后再留出 512 token 给格式和意外情况WINDOW_BUDGET-512最后聊点个人经验。别迷信“无限记忆”。大模型对话系统本质上是给模型喂一个适合它浏览的上下文环境。记忆管理的目标不是回忆一切而是让模型在有限的注意力里做出最佳表现。滑动窗口和摘要是一对搭档窗口负责近期精确摘要负责长期模糊。当精度要求高的信息订单号、日期、人名必须跳出摘要机制用结构化的“事实库”单独存否则迟早要出事故。调试这类系统时最好在日志里打印每次压缩前的消息数、token 数、摘要文本。我见过太多人只看最终回复对不对不知道模型其实已经被自己的摘要带偏了。在开发环境里你可以把每一次摘要存下来做 diff看看哪一轮开始“记忆漂移”。也可以做回放测试用同样的问题问系统对比有摘要和无摘要的输出差异。这块没有标准答案但一个朴素原则是摘要越短丢的细节越多但模型越容易遵从指令摘要越长保留的信息越全但会挤压窗口空间。我一般把摘要控制在 300-500 token超过就交给分层摘要机制继续压缩。另一个容易被忽视的问题是并发。多个用户会话共享同一个 LLM 实例摘要生成如果放在请求线程里会导致 TP98 延迟暴涨。更合理的是把“压缩摘要”做成异步任务用户请求结束后在后台跑。实现上可以用 Redis 列表存消息历史后台 worker 拉取并压缩再把摘要写回。这样用户感知不到摘要延迟但缺点是可能在你压缩的时候用户又发了新消息造成竞态。你得用版本号或时间戳保证顺序。最简单的做法是每次用户发消息时先检查消息数是否超过阈值超过就同步阻塞做摘要但只对当前会话阻塞其他会话不受影响。听起来还是同步但你可以把摘要模型换一个低延迟的小模型或者干脆用规则抽关键信息做轻量摘要等用户空闲再让大模型精修。我最近比较喜欢的结构是三分法短时缓冲最近 20 条原始消息中层摘要每 20 条压缩成 200 token长期事实表从所有消息中抽取的 key-value。响应生成时把事实表 中层摘要 短时缓冲拼接起来。短时缓冲用滑动窗口中层摘要每隔几轮自动更新长期事实表用正则和简单的 NER 维护。这一套组合下来用户体验是“模型记性真好”成本只增加了大概 15% 的额外 LLM 调用。别小看这 15%如果每天 100 万次请求那也是一笔不小的开销。所以摘要触发条件要写得狠一点消息少于 20 条或者 token 少于 3000 时绝不触发摘要。写代码的时候还有个小技巧把摘要生成也暴露成独立的 API 函数这样可以单独压测。压测时注意摘要模型不是用来对话的温度应该调低0 到 0.3否则每次摘要结果不稳定你会看到模型一会记住用户名一会记不住。另外摘要 prompt 里面千万别说“请总结以下对话”模型会产生“总结腔”输出“用户询问了…”。我想要的是客观的关键信息列表所以 prompt 改成“提取对话中的可用信息人物、数字、决策、偏好、承诺。避免废话。”这样得到的东西更像结构化的摘要后面拼接进上下文也不会扰乱了模型的语气。多说一句有些对话系统是用向量数据库做长期记忆每次检索 top-k 相关历史片段塞回上下文。那个方向也不错但那是“检索式记忆”跟本章的“压缩式记忆”搭配使用才能发挥最大效果。滑动窗口负责时间近因摘要负责全局脉络检索负责语义相关。如果你只搞一个摘要遇到用户问“三天前你说过什么”还能应付但遇到“上个月我哪个项目卡住了”这种摘要可能已经把它抹掉了。检索式记忆可以作为补充。不过那是后续章节的内容这里不展开。回到文章开头的那个订单号事故。后来我怎么修的首先把订单号抽出来放进了事实表然后给对话历史加了一个基于 token 的滑动窗口窗口大小设置为 3000超过就触发异步摘要。修完之后用户聊 50 轮也不会再丢订单号。而且我注意到一个意外收获因为窗口变短了模型回应延迟直接降了一半用户投诉还少了。你看记忆管理不只是防止模型失忆还能改善性能和成本。这活干得值。
)
)
