1. RAG
先从记忆系统中检索相关内容，再通过 LLM 生成回复，这种模式就是 RAG（Retrieval-Augmented Generation），也被称为检索增强生成
而在记忆系统中，我们可以通过多种方式存储记忆，例如关系型数据库、向量数据库、键值存储等
数据库直接存储的缺陷是：无法进行语义检索，无法进行相似度匹配，因此，在特性的需求之下，我们需要使用向量数据库来存储记忆，并使用语义检索来检索记忆。
但是，向量数据库并不是万能的，它也有自己的局限性，例如：
用户询问：“我的生日是几月几号？”
向量检索可能召回 用户生日当天去了 Blue Note 爵士酒吧庆祝。这段记忆确实和生日有关，却没有回答具体日期。此时应该直接查询结构化的用户画像表，取出 birthday: "03-14"，而不是继续比较文本的语义相似度
时间范围查询也有相似的问题，用户问：上周我们聊了什么？
其中的上周是一个明确的时间条件，向量检索本身并不理解这个范围。虽然可以像第四篇文章中提到的那样增加元数据过滤，但如果上周积累了 200 条对话，只返回相似度最高的 Top-5，依然无法概括那一周的完整内容
又比如全文关键词查询。用户说： 我之前提到过一本叫《三体》的书
三体 属于专有名词，Embedding 模型处理这类词语时并不总是稳定。它可能把查询映射到 物理学 或 科幻 一类更宽泛的语义方向，却没有精确匹配 三体 这两个字。面对这种查询，传统关键词搜索反而更可靠
这三类问题分别指向精确事实、时间范围和专有名词，它们需要的是精确匹配或结构化查询。因此，记忆系统不能只依赖向量检索，还需要把向量检索、关键词检索和结构化查询组合起来。这就是本篇要介绍的混合检索架构。
2. 记忆分类与存储策略
设计混合检索之前，我们需要先分清系统中有哪些记忆。不同记忆的访问方式并不相同，自然也不应该全部放进同一种存储介质。
| 记忆类型 | 示例 | 存储介质 | 检索方式 |
|---|---|---|---|
| 事实（Fact） | 生日 03-14、喜欢巧克力蛋糕 | D1 关系型数据库 | 结构化查询 |
| 事件（Event） | 去 Blue Note 听爵士、第一次吵架 | Vectorize + D1 | 语义 + 关键词 |
| 偏好（Preference） | 讨厌被忽视、喜欢被夸聪明 | D1 + Vectorize | 结构化 + 语义 |
| 对话摘要（Summary） | "上周主要聊了工作压力和追剧" | D1 关系型数据库 | 时间范围查询 |
| 情绪快照（Mood） | 昨天 23:00 心情指数 35/100 | CloudFlare KV | 键值查询 |
| 短期上下文（Context） | 最近 10 轮对话 | CloudFlare KV | 直接读取 |
这里选择存储介质时，判断依据是访问模式*，而不是单纯看数据量*
CloudFlare KV 负责热数据。最近 N 轮对话、当前情绪状态、亲密度数值等内容体量不大，却几乎每次请求都要读取，很适合放在 KV 中。KV 是全球分布的键值存储，读取延迟在个位数毫秒，但它只能按照 key 精确读取，不支持复杂查询。
CloudFlare D1 负责结构化数据。用户画像中的姓名、生日和职业，对话摘要中的时间段索引，键值形式的偏好标签，以及用于关键词检索的记忆条目，都需要条件查询能力。D1 是边缘 SQLite 数据库，支持完整的 SQL，WHERE、LIKE、ORDER BY、GROUP BY 都可以使用，但它无法计算语义相似度。
CloudFlare Vectorize 负责语义数据。事件记忆、情感片段和长文本记忆更关心“意思是否相近”，适合放入向量数据库。这一层的具体实现已经在第四篇文章中讲过。它的优势是理解语义，短板则是精确匹配和条件过滤。
这里还有一个很重要的架构选择：事件记忆要同时写入 D1 和 Vectorize。同一条数据保存两份，Vectorize 用来做语义检索，D