ep19 · Agent 工程 · 上下文压缩与长期记忆 · 从检索到 RAG

• 模块：M4 Harness 核心
• 课节：6 节（上下文压缩：四层防线 / 长期记忆：向量检索 / 从 Embedding 到 Milvus / Milvus 心智模型 / Milvus 实操 / 从检索到 RAG）
• 来源：xueai.miyang.cn（小山学堂 · 洛小山《学 AI 产品，从入门到精通》）
• 配套音频：pm19-m4-播客.mp3

---

这一集解决什么问题

本集讲 Agent 工程里最容易被低估的一层——记忆与检索。三个核心问题：

1. 上下文窗口有限，用完就崩 → 四层压缩防线
2. 它记不住上个月的事 → 短期记忆（上下文）+ 长期记忆（向量检索）
3. 检索到的片段怎么变成可追责的回答依据 → RAG 链路与两层评测

为什么产品经理要关心：这一层直接决定三件事——Agent 能聊多久才崩、记不记得用户的历史偏好、给出的答案能不能追责。这三个都是产品体验问题，不是工程细节。

---

能力地图

层	本集内容	关键判断
上下文	四层压缩（60% / 75% / 85% / 95%）	信息从哪一层开始丢
长期记忆	向量检索 + topK / minScore	召回数量本质上是预算参数
表示	Embedding → ANN → Top-K	写入与查询必须同模型、同维度、同 metric
存储	Collection / Schema / Entity / Index	Search 按含义找，Query 按条件取
应用	切分 / 元数据 / 过滤 / 融合 / 引用	权限必须在检索阶段执行
验收	Recall@K / 忠实度 / 引用准确率	只看「回答像不像」会掩盖召回失败

---

一、上下文压缩：四层防线

硬约束

• 模型上下文窗口 = 256K Token
• 安全空间 = 200K（预留 56K 给模型回复）
• 一次长对话就能装满

注意：你能用的不是窗口全部，而是窗口减去回复空间。这个差值在设计长对话产品时经常被忘掉。

四层策略

层	触发	动作	损失	示例
① 裁剪 Snip	120K（60%）	删早期工具返回的超长原始数据，只留摘要	用户完全无感	天气接口 1200 Token JSON → 「北京明日多云 12-20°C」（80 Token）
② 微压缩 MicroCompact	150K（75%）	早期长对话 → 简短摘要	轻微损失，关键信息保留	「那个文件不是 PDF，我要 Word，标题改成…」→ 「用户要求换格式、改标题、调配色」
③ 折叠 Collapse	170K（85%）	多轮早期对话 → 一条摘要消息	细节丢失，主线保留	第 1–8 轮（12 条消息，4200 Token）→ 「React + TS 项目，当前修改报表页」（350 Token）
④ 紧急 AutoCompact	190K（95%）	只保留 system + 全局摘要 + 最近 3 轮	明显损失，但避免崩溃	20 轮（38 条消息，18000 Token）→ 2500 Token

关键结论

• 没有压缩，200K 只够一次长对话；有了四层压缩，同样窗口可支撑 5 倍以上对话量。
• 顺序不能乱：越往后，丢的东西越贵。
• 四层都是自动触发——用户不会收到任何提示，信息已经丢了。产品侧需要自己留一份摘要。
• PM 该提前决定：哪类内容绝对不能进压缩区。第一轮说过的核心约束，若没写进摘要，第四层一触发就永久消失。

---

二、长期记忆：向量检索

短期记忆 = 你的桌面（上下文窗口，容量有限）

长期记忆 = 你的档案柜（向量数据库，需要时检索放到桌面）

三个设计决策

1. 什么该存入长期记忆？ 用户偏好、项目配置、历史 Bug、常用操作——这些决定 Agent 的个性化程度。
2. 检索质量取决于 Embedding 模型。「修登录接口」和「登录接口并发 500」能匹配到同一条记忆吗？
3. 记忆太多也是问题：topK = 5 意味着每次最多召回 5 条，怎么保证最重要的排在最前面？

演示配置：8 条历史记忆 / 维度 768 / topK 5 / minScore 0.3——这就是一套长期记忆的全部配置。

类比的下一层：档案柜里的东西必须先放到桌上才能被用到——检索这个动作本身就占用上下文。召回 5 条就占 5 条的上下文。召回多少表面是检索参数，本质是预算参数。

---

三、从 Embedding 到向量数据库

数据链

原始内容（「退款多久到账？」/ 文档 / 图片）
   ↓ Embedding：同一模型编码成固定长度浮点向量
ANN 搜索（近似最近邻，用少量精度换数量级速度）
   ↓
Top-K 文档 → 交给应用或大模型

为什么关键词搜索不够

• 字面不同，意思相近：「如何退钱」和「退款流程」未必共享关键词，但在语义空间里距离很近。

注意：Embedding 捕捉的是统计语义，不是可靠的事实判断。

• 不能逐条硬算：一百万条向量逐一比较成本太高。ANN 索引先缩小候选集再算距离——需要用 Recall 与延迟共同评测。

相似度的方向别弄反

Metric	怎样更相似	适用场景
L2（欧氏距离）	越小越近	关注绝对空间距离
IP（内积）	越大越近	向量模长会影响分数
COSINE	越大越近	关注方向；文本语义常用

关键约束：写入与查询必须使用同一 Embedding 模型、同一预处理方式、同一维度；建索引与搜索的 metric 也必须一致。否则「有结果」不等于「结果可信」。

三个常见坑

1. 把语义相近当成事实相同——两句都像退款说明的话，可能一真一假，但空间里挨得很近。
2. 用关键词思维看待语义搜索——产品型号、错误码、人名恰恰是语义搜索最容易漏的，所以需要混合检索。
3. 度量方式不一致——写入一种、搜索另一种，结果看起来有，实际上不可信。

向量数据库负责什么

职责	说明
存	向量 + 主键 + 来源/类别/时间等标量字段
找	向量索引 Top-K 搜索，并用标量 filter 缩小范围
管	collection、索引、加载与数据生命周期

它不替你生成 Embedding，也不替大模型回答。 把它当成会思考的黑箱，是很多项目失望的起点。

---

四、心智模型：映射到表 / 列 / 行

概念	可类比为	职责
Collection	表	一组具有相同 Schema 的 Entity
Schema / Field	表结构 / 列	约束主键、向量维数与标量类型
Entity	行	一条业务对象；主键必须能稳定定位
Index	索引	加速向量近邻搜索

一条知识库 Entity

{
  "id": 42,                    // 主键：更新、删除、追踪
  "vector": [0.12, ...],       // 向量字段：用于 Search
  "text": "退款通常 3 天到账",
  "category": "refund",        // 标量字段：用于 Filter / Query
  "active": true
}

Search / Query / Load

动作	输入	回答的问题
Search	查询向量 + 可选 filter	语义上谁最像
Query	主键或标量表达式（不传向量）	哪些记录满足条件
Load	—	把索引与数据准备到查询节点；创建成功 ≠ 已可搜

索引选型不是越高级越好

Index	优势	代价 / 场景
FLAT	精确、无需训练	全量比较；小数据集或 Recall 基线
IVF_FLAT	通过聚类缩小候选	需调 nlist / nprobe；数据量较大、成本可控
HNSW	高 Recall、低延迟	占更多内存、建索引较慢；在线检索常用

生命周期：定义 Schema → 创建 Collection → 写 Entity → 建 Index → Load → Search / Query

写入与删除策略

• 写入：批量 insert；稳定主键 + upsert 或业务去重实现幂等（insert 本身不会自动去重）；保留模型名、模型版本与内容版本。内容更新时重新生成向量。
• 删除：需要可撤销时先 active=false 做逻辑删除并在 filter 中排除；物理删除后空间回收依赖 Compaction，不会立刻缩小文件。
• 实操建议：先用 FLAT 做小规模正确性基线，再比较 HNSW 的 Recall 与延迟。没有基线，你判断不出调优是变好还是变差。

---

五、从检索到 RAG

Search 返回「可能相关的片段」，RAG 还要把它们变成有来源、有边界、能被评测的回答依据。

在线链路（四步）

1. Embed Query——用写入时同一个模型编码问题
2. Retrieve——租户/权限过滤 + Top-K 向量检索
3. Rerank——精排、去重，并控制上下文 Token
4. Generate——要求模型只依据证据回答并给出来源

最容易被跳过的是第 3 步。拿到结果就全塞给模型，塞得越多越容易被无关片段带偏——控制长度不只是省钱，更是提高信噪比。

离线摄取决定线上上限

环节	要点
切分	按标题、段落、语义边界切 chunk，保留少量 overlap。太大噪声多，太小上下文断裂——直接决定引用能否「点开对得上」
元数据	保存 source_id、版本、章节、租户、ACL、更新时间。引用、过滤、删除都依赖它
版本	内容或 Embedding 模型变化要重算；蓝绿 collection 切换避免新旧向量混用

检索质量工具箱

方法	解决什么	注意
标量 Filter	租户、权限、时间、语言约束	权限必须在检索阶段执行，不能只靠 Prompt
向量 + 关键词混合	兼顾语义与产品型号、错误码等精确词	两种分数尺度不同，不宜直接相加
RRF 融合	按排名融合多路结果	简单稳健；再用 reranker 精排候选
Partition / TTL	隔离热点、清理过期数据	扩展能力，先用清晰的 collection 与 filter 设计

---

六、评测分两层

第一层：检索

指标	回答的问题
Recall@K	该找的找到了吗
MRR / nDCG	找到的排得对吗
过滤正确性	不该出现的有没有被挡住

第二层：答案

指标	回答的问题
忠实度	回答有没有超出证据
引用准确率	来源对不对得上
拒答率	找不到时敢不敢说不知道

最该记住的一句：只看「回答像不像」会掩盖召回失败。 答案看起来很顺，可能只是模型自己补的，根本没用上检索到的东西。

验收时一定先看检索层指标。召回率本身就低的话，再怎么调提示词，都是在给一个空档案柜擦灰。

---

约束说明（务必读完）

1. 压缩是自动且静默的。用户不会收到提示，信息已丢失。关键约束请固化为系统级记录，不要依赖对话留存。
2. Embedding 捕捉统计语义，不是事实判断。语义相近 ≠ 事实相同，涉及事实仍需核实出处。
3. 一致性是硬约束。同模型、同预处理、同维度、同 metric；否则「有结果」不等于「结果可信」。
4. 权限必须在检索阶段执行。写在 Prompt 里的权限等于没有权限——Prompt 是建议，检索条件是硬约束。
5. Load 前不可搜。创建成功不代表可查询；资源不足时需规划释放。
6. 本页代码与参数为教学示例。端口、模型名、索引参数随环境而异，不要直接复制到生产。

---

审查清单

• 我知不知道信息是从哪一层压缩开始丢的？
• 关键约束有没有固化成系统级记录？
• 长期记忆存的是不是真正决定个性化的内容？
• topK / minScore 是按预算定的，还是拍的？
• 写入与查询是否同模型、同维度、同 metric？
• 权限是否在检索阶段执行，而不是只写在 Prompt 里？
• 切分粒度能否支持引用点开对得上？
• 元数据是否包含来源、版本、租户、ACL、更新时间？
• 有没有先用 FLAT 跑基线再比较 HNSW？
• 验收是否先看 Recall 再看答案？

---

实践提示

提示1 · 把上下文当预算管

四层压缩是防洪堤：先裁工具返回，再压早期对话，最后才动 system。知道哪一层先触发，才知道信息从哪开始丢——这是产品侧的必答题。

提示2 · 权限放在检索里，不要放在提示词里

Prompt 是建议，filter 是硬约束。把安全边界交给一个概率模型，是这个架构里最危险的决定。

提示3 · 先用 FLAT 拿基线

在小规模数据上用精确索引跑一遍，得到 Recall 基线，再比较 HNSW 的召回与延迟。没有基线，调优就是盲调。

提示4 · 把切分当成产品决策

切太大引用没法精确，切太小语义断裂。这个参数看起来是工程细节，实际上决定用户敢不敢信你的引用。

提示5 · 验收先看召回

答案漂亮不代表检索成功。先测 Recall@K 与过滤正确性，再测忠实度与引用准确率——顺序反了，问题会被漂亮话术盖住。

---

常见问题

Q：为什么不能把上下文窗口做得更大来避免压缩？

窗口再大也是有限的，且成本随长度上升。压缩解决的是「单位窗口承载多少对话量」，不是「把窗口做大就行」。

Q：语义搜索能替代关键词搜索吗？

不能。产品型号、错误码、人名这类精确词恰恰是语义搜索最容易漏的，所以要做混合检索。

Q：为什么我搜到了结果，答案还是不对？

先确认召回率。也可能是写入与查询的模型/维度/metric 不一致——有结果不等于结果可信。

Q：Load 是什么，为什么搜不到？

Load 把索引与数据准备到查询节点。创建成功 ≠ 已可搜，资源不足时也需要规划释放。

Q：删掉一条记忆后，空间会立刻释放吗？

不会。物理删除后空间回收依赖 Compaction。需要可撤销时，建议先做逻辑删除并在 filter 中排除。

---

一句话总结

这套系统里最容易出问题的，从来不是模型，而是边界：谁可以看、找不找得到、错了能不能追责。

---

来源：xueai.miyang.cn（小山学堂 · 洛小山《学 AI 产品，从入门到精通》）

本页文字与音频为基于小山学堂原课程的二次演绎版本，仅供学习交流使用。