场景 1 · 记忆好不好，看三层 3.1.1
记住事实只是第一层，能主动预警才是第三层
尺度不同、问题相同：用户记忆面向个体，知识库面向群体
自检： 你的产品停在第几层？大多数「有记忆」的产品，其实只做了第 ① 层。第 ② 层要靠多会话检索消歧（两辆车先问哪辆），第 ③ 层靠场景 11 的组合拳实现。
场景 2 · 两个「张医生」 3.1.3
同一条记忆，越结构化越分得清「是谁的事」
同一个「张医生」，在两套表示里是两个人
关键： 一条记忆不是一句话，而是一条带「谁 / 何时 / 为何」的记录。补上 backstory / person / relationship 才分得清两位张医生。
场景 3 · 把冲突推迟到检索时 3.1.6 重点
写入时就忙着合并，不如只追加、留时间戳
一个架构选择题，换来 20 分以上的涨幅
可迁移的启发： 很多「合并逻辑」的复杂度，都可以靠保留原始记录 + 延迟决策消掉。改的只是「何时处理冲突」这一件事。
场景 4 · 切文档切出岔子 3.2.1
块太大混主题，块太小丢上下文
切分的本质：在「信息完整」与「主题单一」之间找平衡
经验值： 512 token 切分、50–100 token 重叠是常见起点；真正的分水岭是给块补元信息（见场景 10）。
场景 5 · 国王 − 男性 + 女性 ≈ 女王 3.2.2
意思近的词，在向量空间里离得近
实际用 768 维甚至更高——人脑想象不了，但机器算得很快
注意： 稠密嵌入把「词」压成「义」，擅长同义改写，却在精确匹配专名、编号、错误码时掉链子 —— 这就是要配稀疏检索的原因。
场景 6 · 稀有词更值钱 3.2.3
TF 看谁出现得多，IDF 看谁更稀有
# TF：谁出现得多
"模型" 出现 5 次 → 贡献高 "蒸馏" 出现 3 次 → 贡献低
# IDF：谁更稀有
"蒸馏" 在语料里罕见 → IDF 高
BM25 总分 doc_1 = 3.67 排第一 —— 赢在稀有词（k1=1.5, b=0.75）
稀疏嵌入的两面： 它忽略词序，分不出「狗咬人」和「人咬狗」；但对型号、代码标识符的精确召回，稠密嵌入替代不了。
场景 7 · kitty 就是猫 3.2.4 重点
稠密懂语义、稀疏抠字眼，两路都跑再融合
召回 → 融合 → 精排，少了最后一段，前面召回得再全也白搭
生产级三段式： 召回（稠密+稀疏）→ 融合（RRF，Σ 1/(k+rank)，k 常取 60）→ 精排（Reranker）。少了最后一段，前面召回得再全也白搭。
场景 8 · 一百只猫，模型数错 3.3 重点
平铺案例进库，模型会数错、会瞎猜边界
客服问「护士算医护人员吗」—— 边界判定类也得提前写一张规则卡
反直觉结论： 有些问题检索不是最优解——聚合类、统计类、边界判定类，应该提前算好写成一张卡。
场景 9 · 顺着关系跳一步 3.3.1
多跳查询和同名消歧，图比扁平文本强
多跳查询「我的医生所在医院的地址」—— 图只需顺着边走
但别神化知识图谱： 三元组会丢条件逻辑 ——「若下雨就取消海边改博物馆」这种规则，图里存不下。
场景 10 · 给每个块补一句「我是谁」 3.3.5 重点
一句前缀，检索失败率降一半
不改模型、不改库，入库时加一句来源上下文就行
性价比最高的一招： 不改模型、不改库，只在入库时给块加一句来源上下文，失败率就砍掉一半以上。
场景 11 · 常驻概览 + 抽屉细节 3.3.5 汇合
关键事实常驻，细节按需取 —— 才能主动服务
常驻的事实负责「提醒」，抽屉里的细节负责「取证」
呼应场景 1： 第 ③ 层「主动服务」的实现方式，就是「常驻事实 + 按需细节」这套组合拳。