长历史行为怎么处理?

回答与解析

核心矛盾

长历史导致 显存爆炸（KV Cache线性增长）、推理延迟飙升、注意力稀释（早期信息被淹没）。需分层解耦"即时上下文"与"长期记忆"。

四大策略对比

小红书场景建议

混合架构：

• 近期对话（如50轮）：直接保留原始文本，保证细节
• 中期历史：滑动窗口摘要，每20轮生成一段摘要
• 远期记忆：关键事件（种草商品、决策节点）向量化入库

关键设计：

• 记忆写入：识别"里程碑"（用户明确偏好、购买决策）优先入库
• 记忆读取：当前Query先检索相关历史，再拼接进Prompt
• 成本兜底：超长用户自动降级为纯摘要模式，避免OOM

一句话总结

不要试图记住所有，而要学会忘记——通过分层记忆让模型只加载"此刻需要知道的事"。

学习建议

建议系统学习该知识点

口语版讲法(约4分钟)

• 本质是记忆分层问题
• 截断 vs 摘要 vs 检索的适用边界
• 小红书混合架构例子
• 落地风险与前提
• 工程师取舍与可延伸点

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

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

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

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

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

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

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

关键一句:记忆写入的时机判断：用规则加模型双判，先关键词触发再用小模型判断意图。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做一个电商客服机器人，用户可能聊了上千轮，比如退货流程反复确认。如果直接把所有历史都塞进prompt，模型会爆掉。你会怎么处理这种超长历史？

2. 问法 2 · 层层追问

   用户历史行为序列太长你怎么处理？……比如直接截断后面？……那如果丢掉的关键信息怎么办？有没有更聪明的办法，比如只挑有用的历史出来？

3. 问法 3 · 直球架构

   长历史行为序列下，直接输入大模型受限于上下文长度和计算开销。请设计一个系统来处理数千轮交互，包括截断、摘要、记忆存储或检索等策略，并说明权衡。