长历史行为怎么处理?

这道题其实问的是，当用户历史长到模型装不下的时候，我们怎么把记忆分层，让模型只看到它该看的东西。核心矛盾就是，上下文窗口有限，[[KV Cache]] 会线性膨胀，推理延迟飙升，而且早期信息会被注意力稀释掉。说白了，我们不能指望模型记住所有，得帮它学会忘记。

先说几种常见策略的适用边界。截断最简单，只保留最近几十轮，适合短会话、实时性要求高的场景，比如客服的即时对话。但缺点很明显，用户一周前的关键偏好可能就被丢掉了。摘要压缩呢，定期用轻量模型把历史总结成几句话，适合中等长度、需要语义连贯的场景，但摘要质量依赖模型，信息损失是硬伤。[[检索增强]]，也就是把历史[[向量化]]，按需检索 Top-K，适合超长历史但用户访问稀疏的场景，比如用户只偶尔翻看以前的订单。不过检索本身有延迟，还得维护向量索引。

真正落地的时候，往往是混合着来。我举个小红书这样的场景。近期对话，比如最近50轮，直接保留原始文本，保证细节不丢。中期历史，用[[滑动窗口]]摘要，每20轮生成一段摘要，压缩但保留关键脉络。远期记忆，只把里程碑事件，比如用户明确说喜欢某个商品、或者做了购买决策，这些向量化入库。这样模型每次加载的 prompt 里，近期是完整对话，中期是几行摘要，远期是检索到的几条相关事件，长度可控，信息也不丢。

这里有个落地风险得特别注意。检索增强的前提是用户行为里有可检索的关键事件，如果用户全是碎片化闲聊，没有明确的偏好或决策点，那向量化入库就是白费功夫，检索出来的也是噪音。常见失败场景就是，摘要模型质量不够，把关键信息漏了，或者检索召回率低，模型看不到重要历史，反而产生[[幻觉]]。上线前我会特别关注，用离线评估集测一下，在关键事件上的 Recall 和摘要的 [[Faithfulness]]，不达标就回滚。

所以我的倾向是，把长历史处理看成记忆架构设计，而不是单纯的技术选型。我更愿意用分层记忆，工作记忆存短期、episodic 记忆存长期，写入时识别里程碑，读取时让当前 query 先去检索，再拼接进 prompt。成本兜底也很重要，比如超长用户自动降级为纯摘要模式，避免 OOM。

这里有个延伸点，就是记忆写入的时机怎么判断。比如用户说了句“这个口红颜色不错”，算不算里程碑？如果算，那所有类似表达都入库，索引会膨胀；如果不算，又可能漏掉关键信号。我倾向于用规则加模型双判，先关键词触发，再用小模型判断意图，这样成本可控。

说白了，这道题就是教我们，不要试图记住所有，而要设计一套遗忘和检索的机制，让模型只加载此刻需要知道的事。