风车车知识库

retrieval-memory-infra-learning-roadmap-for-storage-engineers

22分钟阅读

检索 / Memory Infra 学习路线图（面向存储引擎背景工程师）

一句话总结

这不是一次“从零转行”，而是一次有明确杠杆的能力迁移：

把你在 RocksDB / LSM / MQ / 存算分离 / 延迟与成本优化上的系统工程能力，迁移到 AI 时代最稀缺的检索与 Agent Memory 基础设施上。

如果执行得当，4–6 个月后，你不只是“懂 RAG”，而是能拿出一个具有说服力的系统作品：

  • 一个能跑起来的 Mini Memory Service
  • 一个带存储引擎味道的 Disk-ANN 原型
  • 一篇足够硬的技术文章
  • 至少一次主流开源项目的有效参与

原始来源：飞书文档《检索 / Memory Infra 深度学习路径（面向存储引擎背景）》

这篇路线图解决什么问题

很多存储工程师转向 AI Infra 时容易陷入两个误区：

  1. 误以为必须先补很多“纯模型”知识，导致长期停留在论文阅读而不产出
  2. 误以为 RAG / Memory 只是“向量库 + prompt 拼接”，低估了其中的存储、索引、事件流、压缩、回滚、治理和多租户复杂度

这篇路线图的目标不是让你变成“通用 AI 工程师”，而是帮助你成为：

擅长检索、索引、存储、记忆管理、分层缓存和系统优化的 AI Infra / Agent Infra 工程师。

这条路线特别适合：

  • 有 RocksDB / LevelDB / Pebble / LSM 背景的人
  • 做过 MQ、日志系统、事件流、KV 存储的人
  • 熟悉 Compaction、WAL、Snapshot、缓存分层、延迟分析的人
  • 希望进入 RAG、Agent、Memory、Inference Infra 方向的人

最终能力画像

如果路线执行顺利，目标不是“看过很多论文”，而是达到下面这四条。

1. 系统设计能力

你能独立设计一个支持以下能力的 Memory 服务：

  • 向量检索
  • 结构化事实存储
  • 事件时间线
  • 多租户隔离
  • TTL / 遗忘 / 压缩策略
  • 可追溯与可解释

2. 开源阅读与参与能力

你能深入进入下列项目中的至少一个：

  • Milvus
  • Qdrant
  • LanceDB
  • Mem0
  • Letta
  • Zep

不仅能“会用”，而是能理解核心模块、定位关键代码、看懂重要 PR。

3. 推理侧协同能力

你能和推理团队就这些问题进行同一张设计图上的对话：

  • KV Cache 与 Prefix Cache
  • Long Context 与外部检索的边界
  • RAG 召回延迟与推理总延迟预算
  • 热数据驻留在 HBM / DRAM / NVMe / Object Store 的分层策略

4. 对外证明能力

你至少拿得出以下公开成果中的两个：

  • 一篇高质量技术文章
  • 一个可运行 Demo
  • 一个开源 PR
  • 一份完整 design doc
  • 一次内部技术分享 / 面试 talk

你最大的优势，不要浪费

转这个方向时，你的真正竞争力不是“会不会调 embedding 模型”，而是下面这些可迁移资产。

已有能力在 Retrieval / Memory Infra 中的映射
LSM / SST / Compaction向量段合并、索引重建、记忆压缩、分层清理
Block Cache / Bloom FilterPrefix Cache、负样本过滤、冷热数据命中优化
WAL / MVCC / Snapshot事件溯源、记忆回滚、时间旅行查询
存算分离向量计算层与对象存储分离、serverless vector store
MQ 保序 / Exactly-onceAgent 事件写入语义、幂等 memory ingestion
低延迟调优经验ANN latency / recall / memory 三角权衡
资源隔离、多租户Memory 服务的租户治理与 QoS

核心认知是：

AI Infra 里最缺的不是“会调 prompt 的人”，而是能把算法真正落成可维护、可扩展、可控系统的人。

这正是存储工程师的主场。

必须补齐的三类新知识

你的短板不在系统，而在 AI 侧的三个接口层：

A. 表征学习与召回质量

你需要知道：

  • embedding 到底在表示什么
  • cosine / inner product / L2 的差异
  • dual encoder 与 cross encoder 的角色分工
  • rerank 为什么经常决定“好不好用”

够用标准：

  • 能解释“相似”不等于“相关”
  • 能解释为什么 first-stage retrieval 与 rerank 要分开
  • 能比较几种 embedding 模型的 tradeoff

B. ANN 算法与索引工程

你需要真正掌握：

  • HNSW
  • IVF / PQ / OPQ
  • ScaNN
  • DiskANN / SPANN
  • 过滤检索（filtered ANN）

够用标准：

  • 能白板解释 HNSW 和 DiskANN 的差异
  • 能说出 recall、延迟、构建成本、内存占用的结构性 tradeoff
  • 能写出一个简化版索引原型

C. LLM / Agent / Memory 框架

你需要搞懂：

  • RAG pipeline 的标准结构
  • Agent 在什么地方读 memory，什么地方写 memory
  • Memory 为什么不仅是向量库，还包含事实、时间、总结、遗忘和治理

够用标准：

  • 能画出 write_event / consolidate / retrieve / forget 的闭环
  • 能指出“单纯向量库”方案为什么会在真实 agent 中失效

全局时间表：18 周，分 6 个阶段

阶段周数主题关键产出
P0 预热W1–W2LLM / RAG / Embedding 基础跑通本地 RAG demo，写一份基础笔记
P1 检索内核W3–W6ANN 算法与索引结构简化 HNSW 原型 + 论文笔记
P2 系统工程W7–W10向量存储引擎与分层架构Disk-ANN-on-RocksDB 原型
P3 Memory 层W11–W14Agent Memory 系统设计Mini Memory Service
P4 性能与前沿W15–W16KV Cache / Long Context / GraphRAG系统综述笔记 + 架构图
P5 产出封装W17–W18开源、文章、转岗材料1 个 PR + 1 篇文章 + 1 套讲稿

推荐总投入：

  • 平日 3 次轻量学习
  • 周末 1 次重型编码 / benchmark
  • 每周至少 1 次总结

如果工作很忙，优先保住三件事：

  • 每周至少 1 篇论文摘要
  • 每周至少 1 次代码提交
  • 每两周至少 1 个可运行的里程碑

P0：预热期（W1–W2）

目标

建立完整链路直觉： 文本 → embedding → 检索 → rerank / 过滤 → 上下文拼接 → LLM 生成

你需要理解到什么程度

不是做模型训练，而是能准确回答：

  • embedding 为什么能做检索
  • 向量相似度为什么不能直接代表事实正确性
  • RAG 为什么既可能提升正确率，也可能引入噪声
  • KV Cache 与外部检索分别解决什么问题

必读材料

  1. Jurafsky《Speech and Language Processing》里关于词向量、Transformer、检索的相关章节
  2. Sebastian Raschka《Build a Large Language Model from Scratch》前几章
  3. OpenAI embeddings / Cohere rerank 文档
  4. RAG 原始论文：Lewis et al., 2020

必做实践

  1. 本地部署 Ollama + 一个通用 8B 模型
  2. 用 LlamaIndex 或 LangChain 跑通一个本地 markdown RAG demo
  3. 至少替换 2 个 embedding 模型，对比检索结果差异
  4. 用 10 个查询问题手动观察：
    • 哪些 query 找不到正确内容
    • 哪些 query 召回了但答案仍然错

阶段产出

你应该写出一篇自己的预热笔记，至少回答：

  • RAG 的标准组件是什么
  • embedding 模型影响了什么
  • rerank 为什么有用
  • 你对“检索质量问题”的第一批观察是什么

P1：检索内核期（W3–W6）

目标

从“使用向量库”升级到“理解 ANN 索引怎么工作”。

这一阶段最重要的认知

ANN 不是单纯算法题，而是系统工程问题。它永远是在做五项权衡：

  • 查询延迟
  • Recall
  • 内存占用
  • 构建成本
  • 更新能力

必读顺序

  1. HNSW
  2. IVF-PQ
  3. ScaNN
  4. DiskANN
  5. SPANN
  6. FreshDiskANN
  7. Filtered ANN / ACORN

源码建议

先小后大：

  1. hnswlib
  2. Faiss
  3. Milvus / Knowhere
  4. LanceDB

必做实践

任务 1：写一个简化 HNSW

要求：

  • 能插入点
  • 能近似搜索
  • 能调 M / ef_search / ef_construction
  • 能画出 recall-latency 曲线

任务 2：写一个距离计算 microbenchmark

要求：

  • 比较标量实现 vs SIMD / AVX2 优化
  • 记录数据规模、维度、吞吐和延迟

任务 3：读一个真实向量库的索引代码

推荐：

  • hnswlib 的入口、节点结构、搜索路径
  • 或 Milvus / Knowhere 对 HNSW / IVF 的封装层

阶段验收标准

你能清楚解释：

  • HNSW 的层级图为什么有效
  • ef_search 提高时为什么 recall 上升、延迟也上升
  • PQ 为什么能压缩内存
  • DiskANN 为什么更适合 SSD 场景

P2：系统工程期（W7–W10）

目标

把“索引”真正放进“存储系统”里思考。

这阶段的重点不再是 ANN 算法本身，而是：

  • 如何持久化
  • 如何增量构建
  • 如何分层存储
  • 如何支持删除 / 更新 / compaction
  • 如何兼顾吞吐、成本、恢复与治理

关键认知映射

向量系统问题存储工程类比
Growing segment / sealed segmentmemtable / immutable SST
Index rebuild / mergecompaction
Tombstone and delete handling删除标记清理
Hot vector cache / SSD / object store多级缓存 / 存算分离
Filtered ANN谓词下推 + 二级索引

必读内容

  1. Milvus / Manu 相关论文与架构文档
  2. Turbopuffer 的 serverless vector DB 博客
  3. Lance / LanceDB 格式设计
  4. Pinecone 的架构演进文章
  5. DDIA 中与日志、索引、分区、多副本相关部分

关键项目：Disk-ANN-on-RocksDB

这是整个路线中最能体现你背景优势的作品。

最低目标

  • 用 RocksDB 存储向量和图邻接信息
  • 支持插入、查询、基本持久化恢复
  • 支持 beam search
  • 输出缓存命中率与查询路径统计

进阶目标

  • 支持分段组织
  • 支持后台重建 / merge
  • 支持冷热层分离
  • 对比 Faiss IVF / 原生 DiskANN 做 benchmark

你要重点回答的问题

  • 图结构存 KV 时 key 设计怎么做
  • 数据局部性怎么优化
  • block cache 命中率如何影响 P99
  • SSD 随机读和 beam width 的关系是什么
  • rebuild / compact 时如何控制放大

阶段验收标准

你应该能输出：

  • 一张完整架构图
  • 一份 benchmark 报告
  • 一份设计说明：为什么这样组织 RocksDB keyspace / value layout

P3：Memory 层（W11–W14）

目标

建立真正的 Agent Memory 观，而不是停留在“文档检索”。

核心认知

真正的 Memory 系统至少包含五层：

  1. 原始事件流
  2. 结构化事实
  3. 向量语义索引
  4. 压缩与总结层
  5. 遗忘与治理层

如果只有向量库，通常会遇到这些问题：

  • 事实冲突无法解决
  • 时间顺序丢失
  • 长对话写入成本高
  • 召回内容难以解释
  • 没有 TTL / importance / consolidation 机制

必读对象

  • MemGPT / Letta
  • Generative Agents
  • Mem0
  • Zep
  • A-MEM
  • MemoryBank
  • GraphRAG / LightRAG / HippoRAG
  • Self-RAG / CRAG / LongRAG

关键项目：Mini Memory Service

推荐模块划分

  • API Gateway：FastAPI
  • Event Store：RocksDB
  • Fact Store：SQLite 或 DuckDB
  • Vector Store：你自己的 ANN 层或可替换接口
  • Consolidation Worker：负责摘要、反思、抽取
  • Forgetting Policy：TTL / importance / decay

核心接口

  • write_event
  • query_memory
  • consolidate
  • forget
  • get_timeline
  • upsert_fact
  • resolve_conflict

必须做出的设计决策

  1. 事件和事实是否分开存
  2. 事实冲突如何处理
  3. consolidation 何时触发
  4. retrieval 是“先图后向量”还是“先向量后 rerank”
  5. 遗忘是 TTL 驱动还是 importance 驱动

阶段验收标准

你应该能解释：

  • 为什么 Memory 不等于 RAG
  • 为什么“事件”和“事实”不能混为一谈
  • 为什么 consolidation 是必须的，而不是锦上添花
  • 为什么 forgetting policy 是系统的一部分，而不是业务逻辑补丁

P4：性能与前沿（W15–W16）

目标

建立与推理基础设施协同设计的能力。

必读方向

  • vLLM / PagedAttention
  • Mooncake
  • SGLang / RadixAttention
  • LMCache
  • StreamingLLM / H2O
  • Infinite Retrieval / Infini-attention

这阶段最关键的连接点

你要把 Retrieval / Memory 和 Inference 联系起来看：

Retrieval / Memory 问题Inference 侧对应问题
热向量驻留热 KV Cache 驻留
分层索引分层 KV Cache
压缩摘要Context compression
Retrieval latency budgetEnd-to-end token latency budget
Recall / precisionPrefix hit rate / answer quality

阶段产出

建议写一篇综述： 《从 Disk-ANN 到 KV Cache：AI Infra 中的分层存储同构性》

这会帮助你把自己从“检索工程师”拉升成“系统基础设施工程师”。

P5：产出封装（W17–W18）

目标

把前 16 周的学习变成对外可证明资产。

必做三件事

1. 一个真实开源 PR

优先切入点：

  • 持久化
  • 索引构建
  • compaction / cleanup
  • 热冷分层
  • benchmark / profiling

这些最容易发挥你的背景优势。

2. 一篇硬核文章

推荐题目：

  • 从 RocksDB 到 DiskANN：存储引擎视角下的向量检索
  • Agent Memory 的存储引擎视角：为什么向量库不够用
  • 从 LSM 到 Memory Consolidation：压缩思想在 Agent Infra 中的复用

3. 一套讲稿 / 转岗材料

内容至少包括：

  • 问题背景
  • 你的项目设计
  • benchmark 结果
  • 与现有系统对比
  • 未来可以如何演进

每周执行模板

这是推荐的最低可持续节奏：

时间投入内容
周一1–1.5h读 1 篇论文，写 300–500 字摘要
周三1–1.5h读源码或补实验
周五1–1.5h写代码 / 跑 benchmark
周六2–4h重型实践：原型开发、实验、图表
周日1–2h周总结、整理知识库、更新下周计划

每周最小交付

再忙也至少交付这三个：

  • 1 篇论文摘要
  • 1 段可运行代码
  • 1 次 commit

如果某周没做到，下一周不要补“理论债”，而是优先恢复编码节奏。

学习过程中的硬约束

1. 论文阅读不能脱离代码

任何论文阅读如果两周内没有落到代码，就视为吸收不充分。

2. 不要过度沉迷微调与 prompt engineering

这条路线的主线是：

  • 检索
  • Memory
  • 存储与索引
  • 系统工程

不是：

  • RLHF
  • SFT
  • prompt 花活
  • 模型调参比赛

3. 所有阶段都要留下可沉淀材料

每阶段至少留下两种资产：

  • 知识资产：笔记、图、文章、设计说明
  • 工程资产：代码、benchmark、PR、demo

4. 每两周做一次阶段回顾

统一回答这四个问题：

  • 我现在最强的新增能力是什么？
  • 我当前最大的短板是什么？
  • 我离“能讲清楚一个系统设计”还差什么？
  • 下一阶段要把什么东西真正做出来？

成功判据

W6 结束前

你应该已经能够：

  • 清楚解释 HNSW / IVF-PQ / DiskANN 的差异
  • 写出一个简化 ANN 原型
  • 看懂一个主流向量库的索引实现入口

W10 结束前

你应该已经能够：

  • 拿出一个有说服力的 Disk-ANN-on-RocksDB 原型
  • 有 benchmark 数据，而不只是代码
  • 能解释数据布局与缓存策略的设计原因

W14 结束前

你应该已经能够：

  • 跑通 Mini Memory Service
  • 给一个 agent 提供可读写的外部 memory
  • 解释 consolidation / forgetting / conflict resolution

W18 结束前

你应该至少满足以下两条：

  • 有 1 个主流开源 PR 或可提交 patch
  • 有 1 篇高质量技术文章
  • 有 1 套可讲 20–30 分钟的系统分享
  • 有 1 个可演示的项目 repo

风险与纠偏

风险 1：看得多，写得少

症状：

  • 论文收藏越来越多
  • 笔记越来越多
  • 代码几乎没有推进

纠偏：

  • 立刻减少 50% 阅读时间
  • 用两周只做一个小原型
  • 没有 benchmark 的学习都先视为未完成

风险 2：做成“工具使用者”而不是“系统设计者”

症状：

  • 很熟 Milvus / Qdrant 命令
  • 但说不清 segment、索引、分层和恢复流程

纠偏：

  • 强制写架构图
  • 强制回答“为什么这样设计，而不是另一种设计”
  • 强制比较 2–3 个系统

风险 3：没有对外证明

症状：

  • 学了很多
  • 但履历、面试、转岗时拿不出证据

纠偏：

  • 把每个阶段都变成可以展示的材料
  • 越早写文章越好
  • 越早开 repo 越好

推荐输出顺序

如果你只做最关键的 5 个输出，顺序建议如下：

  1. 预热笔记：RAG / embedding / rerank 基本图景
  2. 简化 HNSW 原型
  3. Disk-ANN-on-RocksDB 原型
  4. Mini Memory Service
  5. 一篇系统级技术文章

这是最符合“存储引擎背景转 Memory Infra”的证明路径。

建议的知识库使用方式

如果你真的打算按这条路线学，建议把后续学习材料继续沉淀到知识库里，并按下面的方式组织：

  • 主题综述放 topics/
  • 论文精读放 papers/
  • 某个系统的连续研究放 projects/

推荐你后续继续补这些笔记：

  • papers/diskann-neurips-2019.md
  • papers/memgpt-reading-note.md
  • papers/graphrag-reading-note.md
  • projects/memory-infra/00-overview.md
  • projects/memory-infra/01-architecture-map.md
  • projects/memory-infra/02-open-questions.md

结语

这条路线的真正价值，不在于你“懂了多少 AI 名词”，而在于你能否把自己过去多年在存储系统中形成的工程判断，迁移到一个新战场：

  • 检索
  • 记忆
  • 推理协同
  • 分层存储
  • 延迟与成本
  • 数据生命周期治理

一句话概括：

你要做的不是从存储工程师变成 AI 初学者，而是变成一个能用存储工程方法解决 AI Memory 基础设施问题的人。

关系图谱

反向链接