Paperclip。回形针。这个英文单词在我这个整天和大语言模型打交道的人眼里第一时间闪过的并不是办公桌上那个小铁夹子而是AI圈里那个著名的思想实验——一个被错误目标函数驱动的AI为了制造回形针而拼命消耗所有资源。不过我今天要聊的“Paperclip”没那么宏大它是我给手头智能客服项目写的一套上下文管理中间件专门解决聊天机器人“记不住、记不全、上下文太长又太贵”的问题。起这个名字没别的意思就是觉得回形针能把一摞散乱的纸夹住而这套工具能把散落在长长对话里的关键信息“夹”起来需要的时候再抽出来用。这篇文章核心讲三层记忆压缩与检索机制、可复现的参数配置和完整代码实现适合正在做大模型应用、被长上下文折磨的开发者参考也适合所有对上下文工程感兴趣的技术读者。1. 不是窗口不够大是“都塞进去”这件事本身出了问题1.1 长上下文的三个真实痛点贵、飘、吵做大模型应用的人几乎都会遇到同一个问题对话一长系统就越用越难受。最直接的是成本。现在主流模型的上下文窗口动辄128K甚至1M tokens听起来很慷慨但事实是每次请求都要把历史对话完整传给模型token是按输入量计费的。我拿自己的客服场景算过一笔账一个用户平均聊50轮每轮往返大约400 tokens历史积累大概2万tokens。每天如果有300个用户日输入量就是600万tokens仅这一项按GPT-4o的输入价格就要几十美元一天如果接的是更贵的模型账单会更难看。第二个痛点是模型的注意力并不像窗口数字那么可靠。长上下文有一个公认的现象叫“迷失在中间”Lost in the Middle就是说当输入文本很长时模型对开头和结尾的内容关注度高对中间部分的内容召回率明显下降。这会导致什么后果用户在第10轮说的一个关键要求到第40轮问相关问题时模型已经想不起来了。注意这不是模型“没看到”而是它在2万tokens的输入里顾不过来。窗口越长越容易顾此失彼。第三痛点是噪声干扰。真实对话里充斥着寒暄、重复确认、临时跑题这些信息对当前回答没有任何帮助还会把真正重要的信息淹没。有时候我发现模型连用户是什么时候下的单都答错原因不是记忆缺失而是上下文里相关线索和无关噪声的比例严重失衡模型被“吵”晕了。这三个问题叠加起来就是做大模型应用时绕不开的坎全量传入贵且效果差直接截断又怕丢关键信息。1.2 常见做法各有各的硬伤一开始我也试过几种常规方案做技术选型时逐个踩了一遍发现都有明显短板。最原始的“全量回放”就不提了成本直接爆炸“滑动窗口”只保留最近N轮成本降下来了但用户三天前提的偏好、上周说过的会员编号这类信息随着窗口滑出去就永久丢失客服机器人分分钟变金鱼记忆。另一种常见做法是“总结式截断”很多开源框架都自带这个功能对话快超限时由模型把旧内容压成一段摘要放进上下文。这个方案比无脑截断强但问题在于摘要容量有限一段几百字的摘要能装下的话题总量就是那么多细节几乎全部丢失。比如用户提到“我老婆喜欢蓝色包装上次买的那个口味”摘要大概率只会留下“用户购买过某产品”至于哪款包装、哪个口味就没了。还有一种思路是上RAG把用户资料和产品文档向量化回答问题前先去检索。这个方法适合外部知识库但对“本次会话过程中产生的临时信息”乏力——客服对话里大部分关键内容根本没有沉淀成知识库文档而是散落在实时对话里。这就让我意识到我需要的是会话内部的“记忆管理层”而不是一个只会截断或只会外部检索的部件。1.3 Paperclip的定位不做模型只做夹住信息的那只手Paperclip的设计定位是在应用逻辑和模型调用之间插一个轻量级代理层。它监视对话流维护一份“热信息”窗口同时把超出窗口的旧内容做压缩和结构化提取再配合检索把必要信息按需放回上下文。用大白话讲它就是个记忆管家近期对话原样保留中期对话压成摘要长期细节转到检索库回答新问题时再把跟问题最相关的几段内容捞回来。我给自己定的设计目标只有四个一是省token目标压缩比至少达到5比1以上也就是把2万tokens的历史压到4000以内二是低延迟压缩和检索的总耗时不能影响正常对话体验单次最好控制在300毫秒内三是信息可追溯摘要和记忆条目要保留原始线索不能张冠李戴四是无侵入在不改主模型、不换模型供应商的前提下以配置文件方式接入现有项目。这四条就像回形针的四道弯一点不能少。2. 三层记忆结构为什么压缩不能只是“把内容变短”2.1 第一层结构化提取关键细节不能被摘要抹掉很多人对压缩的理解就是“拿模型把长对话重写一遍”。我在早期原型里确实这么干过然后发现坑很大大模型做摘要时天然倾向于保留“故事主线”丢掉数字、姓名、型号、偏好这类微观信息”。比如这段对话“用户A说下周三之前必须到货如果做不到就退款另外他之前办过白金卡卡号尾号8865。”摘要很可能变成“用户对到货时间有要求是老客户”——卡号、期限、退款条件全没了而这些恰恰是客服场景里最要命的信息。所以Paperclip的第一层是结构化提取不走摘要而是让模型把记忆点抽成一组固定字段。我用的抽取模板核心思路是让模型输出JSON字段包括用户显式表达的需求、实体姓名/单号/卡号/产品名、时间约束、偏好信息、待办事项。这一步相当于把对话里的“干货”单独挑出来装进一个固定的记忆槽位。跟摘要比结构化提取的优点是信息密度高、可检索、可程序化处理缺点是依赖模型抽取质量所以Prompt里要明确要求“只抽取用户明确表达过的内容不做推断”。2.2 第二层滚动摘要控制token预算的核心手段第二层是滚动摘要专门负责控制成本。我的实现思路不是一次性压缩全部历史而是维护一个“压缩水位线”当最近对话超出预设的recent_window_tokens阈值时把窗口中最旧的一半拿出来压成摘要新对话保持原样。这样每次压缩的规模可控压缩过程也更平滑不会出现某轮请求突然多出几百毫秒延迟的毛刺。滚动摘要本身也分两级第一级是“对话段摘要”把一批消息压成200到300字第二级是“摘要的摘要”当摘要链总长度超过summary_budget_tokens时把最旧的几段摘要再合并压缩形成金字塔结构。这样做的好处是模型每次只需要读取最近的若干段摘要最久远的信息只保留最粗粒度的时间线和结论。我用生活化的方式理解它是“重要的话先说次要的细节靠翻档案”——既保证核心信息常驻又不让历史包袱拖垮每次请求。2.3 第三层外部检索低频细节按需取回摘要再怎么做也一定会丢掉细节这是压缩的本质决定的。所以Paperclip的第三层是外部检索它的职责是当用户的问题涉及旧细节时把压缩时转移出去的信息再捞回来。压缩发生时被压缩的原始对话片段不会直接删除而是进入一个记忆索引库库里的每条记录包含三部分原始文本片段、摘要文本、向量表示。用户每次发起新问题时Paperclip会先在记忆库做混合检索。混合的意思是向量相似度检索和关键词检索并行进行然后按加权分数合并排序。向量检索负责“语义相近但字面不同”的召回比如用户问“我之前要的那个蓝色的还有货吗”能匹配到“用户想要蓝色包装那款”BM25关键词检索负责精确定位比如订单号、型号、人名这类符号信息向量模型经常对这类精确匹配不敏感但关键词检索能命中。融合公式我用的比较简单final_score 0.6 * vector_sim 0.4 * bm25_score归一化后取Top-K。这个比例我用下来比较均衡不会让某一类检索单独主导结果。2.4 三层背后的逻辑信息访问频率分层管理为什么非要三层而不是一层搞定的原因我想用缓存的思路解释。一个系统中CPU访问寄存器比访问硬盘快几个数量级但我们不会把所有数据都放寄存器里原因无他贵的要命且空间有限。对话信息也一样访问频率天然分成三档近期信息几乎每轮都要用到属于热数据必须原样放在上下文里中期信息时用时不用属于温数据适合压成摘要常驻远期细节偶尔才翻一次属于冷数据放进检索库按需取回。Paperclip的三层结构本质就是对信息访问频率的分层管理热数据放窗口、温数据放摘要、冷数据放检索库。这样既不会因为全量塞入让模型被噪声淹没也不会因为粗暴截断把关键信息丢掉。3. 从零到一搭一套能跑的Paperclip代码可直接参考3.1 环境准备依赖其实少得可怜这套中间件的依赖比我最初预想的要少得多核心就四个模块调用大模型的OpenAI兼容SDK、本地向量化组件、BM25检索组件、SQLite存储。我的环境是Python 3.10及以上装好openai、sentence-transformers、rank-bm25、jieba、sqlite-vec这几个包就够了。embedding我刻意选了本地方案bge-small-zh-v1.5而不是调用云端接口原因有两个一是低频但批量大的索引任务云端调用会积少成多地产生费用二是对话数据里常有用户手机号、地址等隐私信息本地向量化可以减少数据出域。如果你对本地模型的精度不满意换成text-embedding-3-small这类云端模型也只是一行配置的事架构上完全兼容。3.2 关键参数先抄为敬默认值加踩坑提示参数配置是Paperclip里能直接影响成本和效果的部分我踩了好几版坑才定下现在的默认值。第一次我图省事把recent_window_tokens设成8000结果每轮请求的token开销根本没降下来后来狠心调到2000又发现压缩太频繁模型抽摘要也忙不过来。反复试下来4000算是一个兼顾成本和体验的甜点值。下面这张表是我目前项目里的生产配置默认可抄但记得根据自己的对话轮次密度调一下。参数默认值作用踩坑提示recent_window_tokens4000保留原始对话的token上限设太小触发频繁压缩设太大成本降不下去summary_budget_tokens2500滚动摘要链总预算超出后必须做二级摘要否则摘要越滚越大memory_top_k5检索记忆回填条数设定太多会反噬主窗口设定太少查不准compression_modelgpt-4o-mini压缩专用小模型别用主对话模型去压缩贵且性能溢出temperature0压缩和抽取的采样温度摘要任务必须禁掉随机性否则会脑补事实embed_batch_size32向量化批量大小索引不频繁批量设大一点也无妨3.3 核心实现五十行代码讲清三个关键动作Paperclip真正的核心逻辑其实可以浓缩成三个动作加消息时判断是否要压缩压缩时把旧消息一分为三结构化记忆、摘要、索引片段用户提问时检索并拼装上下文。下面这段代码是我抽出来的最简可运行版本去掉了并发和持久化的细节保留完整思路你可以直接抄走改改用在自己的项目里。这里有个重要的工程细节compression_model和主对话模型是分开的压缩走小模型回答走大模型这样能显著拉低成本。代码里的_call_summary_model是占位符实际接的是OpenAI兼容接口的chat.completions.create调用参数temperature传0。import json import sqlite3 class Paperclip: def __init__(self, config: dict): self.recent_window [] self.summary_chain [] self.cfg config # 生产环境建议接SQLitesqlite-vec这里用list暂存演示 self.memories [] def _count_tokens(self, messages): # token数估算按文本字符数除以1.5够用且比数词快得多 text json.dumps(messages, ensure_asciiFalse) return int(len(text) / 1.5) def _call_summary_model(self, messages): # 真实实现换成对compression_model的HTTP调用 # Prompt核心只删减合并不添加新事实输出200字内摘要 return 这里是压缩摘要用户要求蓝色包装款急需3天内发货否则退款。 def _extract_memories(self, messages): # 结构化抽取返回JSON列表例如 # [{type: 时间约束, content: 下周三前必须到货}] return [ {type: 时间约束, content: 下周三前必须到货, source: message_index12}, ] def _should_compress(self): return self._count_tokens(self.recent_window) self.cfg[recent_window_tokens] def add_message(self, message): self.recent_window.append(message) if self._should_compress(): self.compress_oldest_half() def compress_oldest_half(self): half_len len(self.recent_window) // 2 old_part self.recent_window[:half_len] self.summary_chain.append(self._call_summary_model(old_part)) self.memories.extend(self._extract_memories(old_part)) del self.recent_window[:half_len] # 原始片段做切片后进入索引用embeddings这里省略向量化入库 def retrieve(self, query): # 这里是混合检索向量召回加BM25加权合并 # 演示版直接用关键词做简单过滤真实工程需替换成索引检索 hits [m for m in self.memories if query in m[content]] return hits[: self.cfg[memory_top_k]] def build_context(self, new_user_message): memories self.retrieve(new_user_message) summary_block \n.join(self.summary_chain[-3:]) recent_block json.dumps(self.recent_window[-6:], ensure_asciiFalse) system_prompt ( [长期摘要]\n summary_block \n\n[检索记忆]\n json.dumps(memories, ensure_asciiFalse) \n\n[最近对话]\n recent_block ) return [{role: system, content: system_prompt}] self.recent_window[-6:] # 使用示例 paperclip Paperclip({recent_window_tokens: 4000, memory_top_k: 5}) paperclip.add_message({role: user, content: 我要蓝色包装那款周三前必须到}) print(paperclip.build_context(上次那单还能改地址吗))真放到生产环境代码还需要加强三块一是索引库得换成es或sqlite-vec查询走SQL而不是内存过滤二是向量化要异步批次做不要阻塞对话主流程三是摘要链要做长度检查超出预算时递归压缩最旧摘要。但这五十行足以说明Paperclip的全貌。3.4 实测效果压缩后准确率反而更高我知道光说原理很难让读者信服所以放一组我在本地测试环境跑出来的数据用的是客服场景的模拟对话集一共50轮真实风格对话外加20个埋点问题覆盖订单状态、用户偏好、时间承诺三类信息。测试期间采用三种模式对比全量回放、滑动窗口只保留最近10轮、Paperclip。成本按每千次请求测算模型按GPT-4o类输入价格约2.5美元每百万tokens计算。模式第51轮请求上下文tokens每千次请求输入成本20个埋点问题答对平均首字延迟全量回放约20500约51美元15高窗口太长滑动窗口约4200约10.5美元11低窗口太短Paperclip约7500约18.8美元18中最有意思的不是成本而是准确率。全量回放模式在长上下文下答对15个滑动窗口只有11个而Paperclip答对了18个。原因其实很好理解全量模式下模型被大量无关历史干扰注意力涣散导致漏掉关键细节滑动窗口则干脆把关键细节滑走了Paperclip通过摘要和检索把跟当前问题相关度最高的信息提到了前面模型反而更容易抓住重点。这说明一句话上下文不是越长越好是越“准”越好。4. 我实际验证过的四个场景Paperclip可以这么用4.1 多轮客服与销售场景把用户偏好长期钉住客服和销售是Paperclip最顺手的场景因为这类对话有两个鲜明特征轮次多、细节碎。做过客服机器人的同学都懂用户经常在第3轮说“我上个月买的那个绿色的还有吗”第3轮的信息到第30轮才被重新问起。如果中间没有记忆管理模型大概率只能遗憾地告诉用户“我不记得了”。接入Paperclip后用户的颜色偏好、购买型号、时间承诺会在第一轮就被结构化提取出来放进记忆库后面无论聊到第多少轮只要问题里带“那个绿色”检索系统就能把原始片段捞回上下文。实测结果体现在我的测试集里埋点问题“上次买的是哪一款”的召回率直接从62%提升到94%。4.2 长文档问答与知识库场景对话记忆和知识文档叠着用很多人觉得RAG就能解决知识库问答但对长文档场景RAG和对话记忆是两件事。用户读论文时会连环追问第一问拍在论文第三章第二问跳到第五章第三问可能反回来质疑第三章的结论。如果只做RAG模型只记得当前检索到的片段用户说“刚才你说的那个实验条件”模型根本不知道“刚才”指的是哪段。把Paperclip叠在RAG外层就很顺RAG负责从文档里捞知识Paperclip负责记住用户已经看过哪些内容、对上一段内容的反馈是什么。两个系统各管一段互不干扰又互相补充。4.3 多智能体系统共享记忆比各自上下文更靠谱多智能体场景是我今年开始关注的方向因为在这个场景下的记忆问题会放大好几倍。想象三个Agent协作处理一个订单一个负责导购、一个负责物流、一个负责售后。如果每个Agent各自维护一份上下文物流Agent改地址后售后Agent还在旧地址上做判断信息不同步就成了事故。更好的做法是让所有Agent通过Paperclip读写同一个共享记忆库。任何一个Agent的结论、用户的最新要求都会写入记忆库其他Agent发起新问题时自动检索到相关更新。这样每个Agent的上下文窗口依然很短但系统层面拥有了“完整记忆”该知道的关键事实一个都不会少。4.4 个人长期助理跨天跨会话的记忆续接最后一个场景是个人助理类应用特征是会话结束之后还要记得下回。用户昨晚说“明早提醒我带护照”今天新开一个会话问“我今天出门要带什么”如果系统没有跨会话记忆就完全答不上来。Paperclip处理这个场景的办法是把结构化记忆在会话结束后落到长期存储下次新建会话时根据用户当天第一条消息做检索预热把相关的老记忆放进开头。这个模式体验上的差异是“我还是我”和“金鱼遇到新朋友”的区别做好这一步助理类应用的用户留存能差出一大截。5. 踩坑实录Paperclip最容易翻车的五个位置5.1 压缩时机没控制好延迟出现刺眼突刺第一次我把压缩动作放在收到用户消息之后、调用主模型之前而且是同步执行。结果就是某一轮响应突然慢了两秒用户体验直接崩掉。原因很简单压缩模型再小也是模型一次压缩几百毫秒到一两秒都很正常。后来我把压缩改成双轨策略大部分压缩在异步队列里完成只有“必须马上腾窗口”时才同步执行一次同时把压缩触发点放在每轮对话结束后而不是下一轮请求开始时等于用上一轮回答的空闲时间偷偷干活。改完之后用户侧的响应延迟几乎不再受压缩影响。5.2 摘要漂移模型脑补出来的假事实比丢信息更危险压缩摘要的一个隐藏风险是“摘要漂移”就是模型在压缩时把自己推断出的内容混进摘要而且说得像真实发生过一样。比如原始对话里用户说“蓝色包装看起来挺高级”压缩后变成“用户喜欢蓝色”这还算轻的更严重的是把“未确认收货”压成“已收货”下面所有决策全跟着错。要治这个问题我的办法是硬性规定摘要规则Prompt里明确写“只允许删减和合并不允许补充任何原文未出现的事实”同时把压缩模型的temperature设成0。另外我在结构化提取时会加一个字段conflict_flag当某条记忆与已有记忆冲突时打上标记宁可在上下文里多显示一句话让用户确认也不要让系统拿着一份可能错的历史记忆自信作答。5.3 检索不到向量和关键词都失灵时的最后一招检索召回失败会直接导致摘要丢失的细节找不回来。我一次测试遇到的问题是用户问“那我上次说的那个保温杯呢”记忆原文其实写的是“用户咨询316不锈钢保温杯型号”_msg因为“保温杯”和“316不锈钢保温杯”两个文本差异较大向量相似度偏低BM25也没有命中关键词“保温杯”对应的具体内容。后来我给检索前加了一步“查询改写”先让小模型把用户口语化提问改写成更完整的检索表达式“保温杯”改写为“保温杯 316不锈钢 型号 咨询记录”召回率立刻上一个台阶。这也算一个额外开销但对检索质量的提升值这个价。5.4 token预算设得太满时刻要留检索回填的余量我把summary_budget_tokens设成2500recent_window_tokens设成4000加起来6500 tokens看似没超过模型窗口但忽略了检索回填的部分每次提问检索会带回来最多5条记忆每条100到200 tokens加上最近对话展开总输入可能冲到9000以上。一开始我吃过这个亏summary预算设到6000结果整轮请求直奔15000 tokens成本曲线瞬间反弹。所以参数之间不是孤立关系——检索预算和摘要预算共享的是一个总上下文池子强烈建议在配置里预留10%到15%的缓冲区间给检索回填别在预算问题上卡得太死。5.5 问题排查速查表按症状定位十秒搞定我在项目和社区讨论里把高频问题整理成一张速查表遇到对应症状可以按图索骥。特别提醒一句如果碰到“压缩后回答质量下降”先别急着否定压缩方案多数情况是摘要或检索环节出了问题而不是记忆管理思路本身有问题。症状可能原因排查与解决回答里出现从未发生过的细节摘要漂移检查压缩Prompt是否允许改写temperature设为0摘要结果加入原文引用模型说“我不记得用户之前提过”检索召回失败看检索日志中的Top-K分数低于阈值时启用查询改写某一轮等待时间突然变长压缩任务同步执行把压缩挪到异步等待队列峰值前提前触发token成本下降不明显recent_window_tokens偏大在日志里按轮次统计平均输入token按比例调低窗口阈值多轮后摘要越来越长摘要链缺乏二级压缩对summary_chain做回溯压缩超出预算时合并最旧段6. 做这个项目过程中的三点体会如果这段内容能给读者一些启发我想说三个来自实践的真实体会。第一记忆管理对体验的影响比花里胡哨的提示词技巧大得多用户感知不到你用了多精巧的Prompt但能明确感知你到底“记没记住我上句话”。第二压缩的真正价值不是省钱而是让模型把注意力集中在真正重要的信息上它丢掉的是噪声救回的是精度——一个长上下文管理做得好不好评判标准不是压缩得有多狠而是压缩后回答质量有没有提升。第三上下文工程会成为大模型应用的基本功就像缓存对后端系统一样以前我们设计系统时考虑数据库索引和缓存过期策略现在做AI应用同样要认真考虑该往上下文里放什么、不该放什么、哪些信息用完了可以移出去。最后再分享一个小技巧是我自己测试时无意发现的在摘要Prompt里让模型为每条摘要事实附一个source字段标明这段摘要出自第几轮对话。平时这个字段不起眼但当摘要之间出现冲突时source字段能让你追到最原始的对话内容是谁说的、在什么语境下说的排查问题省一大半功夫。下一步我计划给Paperclip加一个轻量自动评估集把每轮检索召回率、摘要压缩比、事实一致性做成可视化的报表让每个接入项目的开发者都能一眼看到这套记忆管家的工作效果——毕竟回形针好不好用得夹过才知道。