第 0 章 项目导览与学习路线
文档摘要
第 0 章 项目导览与学习路线 RAG（检索增强生成）的成败，七成取决于"能不能又准又快地把相关知识捞出来"。这一章回答一个问题：为什么 Zvec 是搭建一套轻量、可控、可落地 RAG 系统时值得首先尝试的向量数据库。 0.1 这是什么：一句话定位 Zvec 是阿里巴巴开源的进程内（in-process / embedded）向量数据库。它以"库"的形式直接嵌入你的应用程序进程—— 就能用，没有独立的服务进程、没有守护进程、没有外部基础设施。它基于阿里淘宝规模生产级检索引擎 Proxima 构建，在阿里内部经过实战检验。 如果用一句话打比方：Zvec 之于向量数据库，就像 SQLite 之于关系型数据库。 你不需要先 起一个向量服务，再去连它的端口；
第 0 章 项目导览与学习路线
RAG（检索增强生成）的成败，七成取决于"能不能又准又快地把相关知识捞出来"。这一章回答一个问题：为什么 Zvec 是搭建一套轻量、可控、可落地 RAG 系统时值得首先尝试的向量数据库。
0.1 这是什么：一句话定位
Zvec 是阿里巴巴开源的进程内（in-process / embedded）向量数据库。它以"库"的形式直接嵌入你的应用程序进程——import zvec 就能用，没有独立的服务进程、没有守护进程、没有外部基础设施。它基于阿里淘宝规模生产级检索引擎 Proxima 构建，在阿里内部经过实战检验。
如果用一句话打比方：Zvec 之于向量数据库，就像 SQLite 之于关系型数据库。
- 你不需要先
docker run起一个向量服务，再去连它的端口； - 你的向量数据和你的应用跑在同一个进程里，读写就是一次函数调用；
- 数据落在一个文件夹里，整个文件夹可以拷贝、迁移、备份，到哪都能打开。
这种形态，恰恰是 RAG 最舒服的落地形态——尤其是端侧 RAG、企业内网 RAG、个人知识库 RAG 这类不想引入一堆中间件、只想把"知识检索 + 大模型"拼起来的场景。
0.2 为什么值得用它做 RAG
先看 RAG 的本质。一个 RAG 系统的骨架是：
用户提问 ──► ① 把问题变成向量 ──► ② 在知识库里找最相关的几段 ──► ③ 拼进 Prompt ──► ④ 交给 LLM 生成 ▲ └── 这一步，就是向量数据库的活儿
第②步的"找最相关的几段"，是整个 RAG 里最影响最终效果、也最考验工程化的一环。它要解决三个问题：
| RAG 的真实痛点 | Zvec 怎么解 |
|---|---|
| 语义召回要准：光靠关键词搜不到"意思相同但字面不同"的内容 | 稠密向量做语义检索，HNSW 索引低延迟高召回 |
| 关键词召回要稳：专有名词、产品型号、人名错一个字就召不回 | 稀疏向量 + 全文检索（BM25），中英文都能精确匹配 |
| 两路结果要合：语义和关键词各有盲区，得融合起来 | 多向量查询 + 重排序融合（Weighted / RRF）一步到位 |
| 部署要轻：不想为了一个 demo 起一整套微服务 | 进程内嵌入，pip install zvec 即用，零运维 |
💡 RAG 召回的黄金组合是"语义检索 + 关键词检索 + 融合重排"。很多团队卡在召回率上，不是模型不行，而是只做了纯语义检索，丢掉了关键词这条腿。Zvec 把这三件事都做进了一个库，这正是本教程要带你走通的完整链路。
0.3 技术栈一览
| 层 | 角色 | 本教程涉及 |
|---|---|---|
| Zvec | 进程内向量数据库（建库/写入/检索） | 全程核心 |
| Embedding 模型 | 把文本转成向量 | 第 3、9 章重点（OpenAI、BGE、Sentence-Transformers 思路通用） |
| 分词器 | 全文检索把中文切词 | 第 6 章（内置 Jieba） |
| LLM | 拿到检索结果生成答案 | 第 9 章端到端集成 |
| 语言/运行时 | 应用层 | Python 为主（贴合 RAG 生态），关键处提及 Node.js 对照 |
⚠️ 本教程代码以 Python 为主线。Zvec 同样提供官方 Node.js SDK（
@zvec/zvec），API 形态高度一致（Python 的collection.query(...)↔ Node 的collection.querySync({...})），学会一套即可迁移。
0.4 你能学到什么：能力—章节对照表
| 你想学会的能力 | 去哪一章 |
|---|---|
| 5 分钟跑通第一个向量检索 | 第 1 章 |
| 看懂 Collection / Document / Schema 是什么 | 第 2 章 |
| 区分稠密 / 稀疏向量，选对度量 | 第 3 章 |
| 为知识库设计正确的字段与索引 | 第 4 章 |
| 选对索引类型，调出高召回低延迟 | 第 5 章 |
| 写出语义检索、标量过滤、全文检索 | 第 6 章 |
| 把语义 + 关键词融合，召回率再上一个台阶 | 第 7 章 |
| 上线前的性能调优、可观测、选型取舍 | 第 8 章 |
| 拼出 Embedding + Zvec + LLM 的端到端 RAG | 第 9 章 |
0.5 建议学习顺序
┌──────────────────────────────────────────────────────────────┐ │ 第一阶段：打地基（第 0~2 章） │ │ 先跑通一遍，再搞懂四件套（Collection/Document/Schema/索引） │ └──────────────────────────────┬───────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────────┐ │ 第二阶段：建好库（第 3~5 章） │ │ 理解向量与度量 → 设计 Schema → 选索引与调参 │ └──────────────────────────────┬───────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────────┐ │ 第三阶段：会检索（第 6~7 章） │ │ 语义 / 过滤 / 全文 → 混合检索融合（RAG 召回的胜负手） │ └──────────────────────────────┬───────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────────┐ │ 第四阶段：能上线（第 8~9 章） │ │ 工程实践 → 端到端 RAG 集成 │ └──────────────────────────────────────────────────────────────┘
0.6 学习心法
- 先跑通，再深究原理。 RAG 是个强反馈链路——你跑通一个能问能答的 demo，对每个参数的理解都会快十倍。第 1 章就让你跑通。
- 召回质量 > 模型能力。 一个 70 分的模型配 90 分的召回，往往胜过 90 分的模型配 60 分的召回。本教程第 6、7 章是性价比最高的章节。
- 度量必须对齐。 Embedding 模型用什么距离训练，检索就必须用什么距离——这是 RAG 里最隐蔽也最致命的 bug（详见第 3 章）。
- 索引是 Recall 与速度的交易。 没有银弹，只有取舍。第 5 章会给你一张决策表。
- 进程内 ≠ 玩具。 进程内意味着低延迟、易部署，但要懂得用
optimize()、只读共享等手段管理好生命周期（第 8 章）。
本章小结
- Zvec 是进程内嵌入式向量数据库，"向量数据库领域的 SQLite"，零运维，适合轻量级 RAG。
- RAG 的核心是"又准又快地捞知识"，Zvec 用稠密检索 + 稀疏/全文检索 + 融合重排三件套覆盖了这条链路。
- 本教程以 Python 为主线，按"跑通 → 建库 → 检索 → 混合 → 上线"五阶段推进。
- 记住心法：召回质量决定 RAG 上限，度量对齐是底线。
下一章，我们用 5 分钟把第一个向量检索跑起来。详见第 1 章。