BP4 · 上下文压缩与长期记忆#

定位：面试官追问上下文管理与偏好记忆时的拷问预备。

---

核心口述（30 秒）#

“Cache Breakpoint：较旧区截断冻结做缓存前缀，最近 K 轮保全文。核心洞察——盲目压缩破坏 cache 前缀，综合成本反升 3 倍。偏好记忆：curator 会话结束后统一提取 like/dislike，dedup_key 代码派生不靠 LLM。like 走偏好词并入检索词，dislike 走关键词双档（硬淘汰仅限用户授权 / 软减分 Attenuator）。“

---

拷问链——压缩#

Q: 为什么说”脱离缓存谈压缩，省下的都是假的”？#

实际计费 = 总 token × (1 - 命中率 × 折扣)。压缩省 token 但破坏前缀降低命中率。盲目压 30%→命中率 85%→15%→综合成本 +297%。

Q: cache_control 只有 4 个 breakpoint 够吗？#

System prompt 1 个 + 较旧区末尾 1 个 + 2 个预留。10-20 轮购物对话够用。

Q: 本项目走 OpenAI 兼容端点，cache_control 有效吗？#

仅 Anthropic 原生消费。标记逻辑做全默认关。保留为可移植性。

拷问链——记忆#

Q: 为什么 LLM 只提供 slug 而不是完整 key？#

LLM 生成的 key 不稳定——同一偏好可能产出不同 key。slug 是原子标识，dedup_key 由 polarity/category/domain/slug 代码派生。

Q: like 和 dislike 为什么走不同通道？#

embedding 对否定编码弱——“不要塑料”和”要塑料”距离近。like 走偏好词并入检索词（拼进 query 一起编码），dislike 走关键词匹配（硬淘汰或 Attenuator 减分）。向量级 user 塔融合原先做了但零调用已删。

Q: rejected_options 为什么不经 curator？#

item_picker 精确知道哪些被淘汰、因为什么。机械灌入不需要 LLM 猜测。

---

压力题#

Q: 偏好会不会越积越多影响检索？#

dislike-hard（blocking=True）永远全量（安全类不能漏），其余超阈值（默认 20 条）走裁剪。不会无限增长。矛盾消解：新偏好与已有极性冲突 → 覆盖合并（_merge_on_collision）。