你刚接触“AI 记忆系统”时，很容易被一堆名词砸晕：RAG、向量库、BM25、KG、Ontology、Entity Linking、Rerank、MMR、Contextual Compression、Agentic RAG……
它们到底是什么关系？谁先谁后？哪些能并行？哪些必须串行？

这篇文章把它们放回同一条“工程流水线”里，用 “动作” 来解释每个名词：它解决什么问题、在流程的哪一段出现、与其它模块如何衔接。

---

你读完能得到什么

• 你会知道：RAG 不是一个单点技术，而是一条“检索→提纯→注入→生成”的在线链路统称
• 你会分清：哪些是“离线建库/写入”，哪些是“在线回答/读取”，哪些是“后台治理/回写”
• 你会掌握：典型的串行骨架 + 常见并行加速点（工程上最重要的性能结构）
• 你会理解：向量检索、BM25、KG 三条路线为何经常“同时存在”，而不是互相替代

---

0) 写入链路：从“内容”到“可检索记忆”（通常离线/异步）

目标：把原始内容变成“以后能搜到、能引用、能注入”的记忆资产。

你可以把“写入链路”理解成：先把书放进图书馆，再建立目录卡、关键词索引、主题关系网。
原文是“权威来源”，索引与结构化信息是“让你以后找得到”的关键。

---

0.1 原始落库（存“原文”）

• [Document Store / 文档库]
  动作：把原始文档/网页/对话日志/图片 OCR 文本等保存为“权威原文”。
  为什么需要：在线检索通常先返回 chunk_id 或 doc_id，再回文档库取原文片段做引用与注入。
  常见实现：Postgres/MySQL、对象存储（S3/OSS）、Elasticsearch（也可兼具全文索引）。
• [Metadata / 元数据过滤]
  动作：同时存储来源、时间、用户/权限、主题标签、会话ID、产品线、语言等元数据。
  为什么需要：后面检索时可以只在“某用户/某会话/某时间段/某知识域”里搜，减少误召回。
  典型坑：没有元数据，检索结果“看似相关但越界”（比如搜到了不该给该用户看的内容）。

---

0.2 预处理成可检索单元

• [Chunk / 切块]（强串行依赖）
  动作：把长文切成 chunk（段落/窗口/语义块），每个 chunk 继承元数据并产生 chunk_id。
  为什么是强依赖：不切块你就很难做向量化、全文索引、甚至无法在 context window 内注入。
  实践建议（新手可直接用）：

• • 按语义切优于固定长度（段落/标题/列表更自然）
  • chunk 太大：注入会爆 token、细节难定位
  • chunk 太小：语义丢失、召回变噪

---

0.3 对同一批 chunk 做“并行建索引”（典型并行点）

切块完成后，下面三路通常可以并行跑（互不依赖，工程上也经常分成不同 worker）：

0.3.1 向量路：Embedding → Vector Store → ANN

• [Embedding / 向量化]
  动作：对每个 chunk 生成 embedding（高维向量）。
  解决什么：语义相似（同义表达、概念接近）召回能力强。
• [Vector Store / 向量库]
  动作：存储向量 + chunk_id + 元数据，并提供相似度检索接口。
  常见实现：FAISS、Milvus、Pinecone、Qdrant、Weaviate、pgvector。
• [ANN / Approximate Nearest Neighbor]
  动作：向量库内部用近似最近邻索引让检索变快（HNSW、IVF、PQ 等）。
  你可以这样记：ANN 就是“向量世界的倒排索引/加速器”。

---

0.3.2 关键词路：BM25（Sparse Retrieval）

• [BM25 / 关键词检索（稀疏检索）]
  动作：对 chunk 建倒排/全文索引，使得按“词项匹配”检索更强。
  什么时候比向量更强：

• • 专名（人名、公司名、接口名）
  • 编号（工单号、订单号、版本号）
  • 精确短语（错误码、字段名）
    常见实现：Elasticsearch/OpenSearch、Postgres FTS、Lucene。

---

0.3.3 结构化路：Ontology/Taxonomy/Entity Linking → KG → Graph DB

• [Taxonomy / 分类体系]
  动作：给概念分层归类（比如“商品→服饰→鞋→运动鞋”）。
  价值：更适合“浏览式检索/聚合统计/权限域隔离”。
• [Ontology / 本体]
  动作：定义类型、属性、关系约束（比如 Person 可以 works_at Company）。
  价值：让图谱更“可控、可校验”，减少乱连关系。
• [Entity Linking / 实体链接]
  动作：把“文本里的张三”对齐到“图里的张三(实体ID)”。
  关键点：它不是简单抽名字，而是解决“同名不同人/同人不同名”的对齐问题。
• [KG / Knowledge Graph]
  动作：写入实体-关系-实体（或实体-属性）的图结构。
  价值：支持多跳推理、关系追溯、路径解释（“为什么推荐/为什么判断”）。
• [Graph Database / 图数据库]
  动作：把 KG 存在图数据库里，支持图遍历与图查询。
  常见实现：Neo4j、JanusGraph、NebulaGraph；也可用关系库模拟（但遍历效率与表达力受限）。

重要提示：很多工程项目并不会把 Ontology/Taxonomy 做到很“学院派”，而是先做“轻量实体/关系 + 后续治理”，这也是一种常见且可落地的路径。

---

1) 对话运行时：短期记忆如何进入模型（在线同步）

目标：保证模型“看得见刚刚发生的事”，这是最基础的记忆。

• [Context Window / 上下文窗口]
  动作：模型一次能吃的 token 上限，是注入阶段的硬约束。
  工程含义：你做再多记忆，如果最后塞不进上下文，就等于没用。
• [Short-term Memory / Working Memory]
  动作：保留最近 N 轮消息直接放进上下文（滑动窗口）。
  特点：

• • 必走在线关键路径（决定能否立即回答）
  • 成本低（不用检索）但 容量有限（受 token 限制）

---

2) 读取链路：RAG 在一次回答里到底怎么走（在线同步关键路径）

你可以把 RAG 理解成：回答前先查资料。
资料来自向量库、关键词索引、或图谱等，然后把“证据”喂给模型生成。

下面是一条典型的“串行骨架 + 并行分叉”。

---

2.1 形成检索问题（可能先做“问题加工”）

• [Query Rewriting / 查询改写]（串行）
  动作：把口语化问题改成更适合检索的形式（补全指代、加关键名词、去噪）。
  例子：

• • 用户问：“他上次说的那个接口怎么调？”
  • 改写为：“上次讨论的 xxx 接口调用方式、参数与示例”

• [Multi-Query / RAG-Fusion]（串行产出，多路并行检索）
  动作：生成多个角度的查询（同义改写/子问题分解），提升召回率；后面再融合结果。
  适用场景：问题含糊、召回不稳、同义表达很多的领域（客服、知识库、研发文档混合）。
• [HyDE]（串行）
  动作：让模型先写一段“假想答案/假想文档”，再用它去做向量检索。
  直觉：让 query 更接近“文档语言”，语义召回更稳。

---

2.2 多路召回（典型并行点：向量 / BM25 / KG 同时搜）

这一段通常可以并行（或至少逻辑上独立），最终汇总成候选证据池：

• [Semantic Search / 语义检索（Dense Retrieval）]（向量路）
  动作：对 query 做 embedding，在向量库用 ANN 找 Top-K 相似 chunk；可叠加元数据过滤。
  优势：同义改写、语义相关召回强。
  劣势：对“精确字符串/编号/专名”可能不如 BM25 稳。
• [BM25 / 关键词检索（Sparse Retrieval）]（关键词路）
  动作：在倒排索引里按词召回 Top-K；同样可做元数据过滤。
  优势：对专名、编号、短语极强。
  劣势：对“语义但不共词”的问题较弱。
• [KG 路（结构化检索）]
  动作：先对问题做 Entity Linking 找到图中实体；再在图数据库里做图查询/多跳扩展。

• • [GraphRAG / KG-RAG]：检索结果不是一堆文本块，而是一段关键子图/路径 + 相关证据，再交给 LLM 组织答案。
    优势：关系推理、可解释路径、跨文档聚合强。
    成本：建图与治理成本更高，Entity Linking 也可能成为瓶颈。

---

2.3 融合与提纯：从“候选很多”到“证据少而准”

• [Hybrid Search / 混合检索]（串行）
  动作：把 Dense（向量）+ Sparse（BM25）+ KG 的候选统一合并（加权打分或融合排序）。
  你可以这样理解：多路召回解决“别漏”，融合解决“谁更准”。
• [MMR / Maximal Marginal Relevance]（串行）
  动作：在相关性与多样性之间取平衡，减少证据重复（避免 Top-N 全是同一段的近义复述）。
  价值：提高“证据覆盖面”，尤其当你要回答的是“总结/对比/列点”。
• [Rerank / 重排]（串行）
  动作：对候选证据再排序（更贵但更准），选出最终注入的 Top-N。
  常见实现：cross-encoder reranker（把 query+doc 一起喂模型打分）。
  工程折中：通常只 rerank Top-50/Top-100，而不是全量候选。
• [Contextual Compression / 上下文压缩]（常可对每条证据并行）
  动作：把每个 chunk/子图压缩成关键句/要点，降低 token 占用，提高“证据密度”。
  典型做法：按 query 进行“针对性摘取”，而不是全文摘要。

---

2.4 注入与生成：RAG 的 “G”（Generation）

• [RAG / Retrieval-Augmented Generation]（串行终段）
  动作：把短期对话（Short-term Memory）+ 检索证据（压缩后）拼装进 prompt，控制在 context window 内，让 LLM 基于证据生成回答。
  关键目标：减少幻觉、提高可追溯性、提升事实正确率。
• [Agentic RAG / 工具型 RAG]（循环版 RAG）
  动作：如果模型判断证据不足，会进入“检索→读证据→再检索”的多轮循环。
  关系：循环之间是串行；但每一轮内部的“多路召回（向量/BM25/KG）”仍可并行。

---

3) 回写链路：把一次对话变成可长期利用的记忆（通常后台异步）

目标：让系统“越用越懂你”，并把对话中出现的稳定信息沉淀下来。

• [Episodic Memory / 情景记忆]
  动作：记录“发生了什么”（对话日志、事件、引用过哪些证据、工具调用结果）。
  价值：可追溯、可审计、可复盘。
• [Conversation Summarization / 对话总结记忆]
  动作：把长对话压成摘要，便于下次注入，也可作为后续巩固的原料。
  常见位置：中期记忆（mid-memory），减少上下文压力。
• [Semantic Memory / 语义记忆] + [Memory Consolidation / 记忆巩固]
  动作：从对话/摘要中抽取稳定事实（偏好、身份信息、长期目标、术语定义），写回到结构化存储（文档库/表/KG），并按需向量化入向量库。
  你可以这样理解：把“经历”提炼成“常识”。
• [Forgetting / Memory Decay]
  动作：按时间、使用频率、价值分级淘汰/降权/归档。
  为什么必须要有：没有遗忘，索引会越来越噪，召回质量会下降，还会带来隐私与成本风险。

---

4) 参数内记忆：把知识“写进模型权重”（离线，不走在线 RAG 关键路径）

这条线不是 RAG 的必需品，但经常和 RAG 互补。

• [Fine-tuning / SFT]
  动作：用数据把知识/风格固化进模型参数。
  优点：推理时不依赖检索；
  缺点：更新慢、成本高、对“事实实时性”不友好。
• [LoRA / Adapter]
  动作：更轻量地注入领域知识/风格（参数高效微调）。
  适合：快速试验、多个领域适配、多租户差异化。
• [Continual Learning / 增量学习]
  动作：持续更新模型参数吸收新知识。
  挑战：稳定性、灾难性遗忘、评估体系与回滚机制。

---

5) 串行 vs 并行：工程视角的一张“骨架图”

你可以用下面这张结构去记“强依赖 vs 可并行”。

写入(后台/离线)
原文入库 -> 切块
           -> [向量索引]  (Embedding -> VectorStore -> ANN)
           -> [关键词索引](BM25/FTS)
           -> [结构化索引](EntityLinking -> KG -> GraphDB)

读取(在线/同步关键路径)
用户问题 -> (可选)Query加工 -> 并行召回{向量 / BM25 / KG}
        -> 融合(Hybrid) -> 去冗余(MMR) -> 重排(Rerank) -> 压缩(Compression)
        -> 注入(Context Window) -> 生成回答(G)

回写(后台/异步)
对话日志/摘要/事实抽取 -> 更新索引/图谱 -> 遗忘治理

• 必然串行（强依赖链）

• • 切块后才能做向量化/全文索引/建图
  • Query 改写/多查询/HyDE 后才能检索
  • 候选合并后才能 Hybrid/MMR/Rerank
  • 证据确定后才能压缩→注入→生成

• 最常见并行（提速关键）

• • 建库时：Embedding、BM25 索引、Entity Linking / KG 可并行
  • 在线时：Dense（向量）/ Sparse（BM25）/ KG 多路召回并行
  • 压缩时：每条证据可并行做压缩
  • 回写时：Summarization/Consolidation/Forgetting 多为后台并行

---

6) 术语速查表（把“名词”翻译成“动作”）

名词	本质动作	主要解决	出现阶段
Chunk	把内容切成可检索单元	可定位、可注入	写入
Embedding	把文本变向量	语义相似召回	写入 + 读取
Vector Store	存向量并检索	规模化语义检索	写入 + 读取
ANN	向量检索加速索引	低延迟	写入（建索引）+ 读取
BM25	倒排索引检索	专名/编号/精确词项	写入 + 读取
Entity Linking	文本实体对齐到ID	多跳推理入口一致	写入（常见）或读取
KG / GraphRAG	图查询/扩展子图	关系推理、解释性	读取
Rerank	二阶段精排	提升 Top-N 准确	读取
MMR	去冗余	提升覆盖与多样性	读取
Contextual Compression	证据压缩	节省 token	读取
Summarization	对话/文档总结	中期记忆与回写原料	回写/后台
Forgetting	记忆衰减与治理	降噪、控成本、合规	回写/后台

---

7) 常见误区（FAQ）

• Q：RAG 是不是一种具体技术？
  A：不是。 RAG 更像“在线回答时的一条流水线总称”，里面可以选用向量、BM25、KG、重排、压缩等不同组件。
• Q：有了向量库就不需要 BM25 了吗？
  A：通常不。 真实系统里经常“向量 + BM25 混合”，因为 BM25 对专名/编号/短语更稳定。
• Q：做 KG 一定要先搞很完整的 Ontology/Taxonomy 吗？
  A：不一定。 很多工程会先做轻量实体/关系抽取与对齐，再逐步引入本体约束与治理。
• Q：Rerank 很贵，为什么还要做？
  A：因为它最直接提升 Top-N 质量。 常见折中是“只对 Top-50/Top-100 rerank”，把成本控制住。
• Q：为什么要做 Contextual Compression？
  A：因为 context window 是硬上限。 证据不压缩，就会“塞不下”或“塞得很稀”，导致回答质量下降。

---

结语：你应该如何使用这条“串烧全链路”？

把这篇文章当成一张“架构地图”即可：真正落地时，你并不需要一次性把所有模块做齐。
一个实用路线通常是：

• 先做：Document Store + Chunk + 向量检索 + 注入
• 再加：Metadata 过滤 + BM25 + Hybrid + Rerank
• 最后再考虑：KG/GraphRAG、对话巩固、遗忘治理、甚至参数内记忆