通读笔记(二):第 3–4 章(PART 1 的中段:RAG 与检索)
接
reading-notes.md。行号即「第 N 段」。 第 3 章 =text/06-ch03…(1654 行)· 第 4 章 =text/07-ch04…(1922 行,全书最长)
第 3 章 Grounding Outputs with RAG
1. 这一章被什么逼出来
第 2 章末尾的原话:提示词技法到头了,因为模型没有训练数据之外的知识。 第 3 章开场立刻给了一个提示词绝对答不出来的问题:
「你们那台 55 寸带音响条的 OLED 电视,今天能 当日达吗?」(
:23)
作者点明:想靠预训练解决,就得把「所有产品 × 所有地点 × 所有配送方式」的组合塞进参数里,
这不只是算力上不可行,而且塞进去的知识一出厂就过期。(:33)
第二个例子更漂亮,值得在拆解里留:
「这台 55 寸 OLED 电视,把后排座椅放倒,塞得进我的丰田普锐斯吗?」(
:46) —— 需要同时取到电视的尺寸和普锐斯的后备箱容积,再做比较。
RAG 的定义(两阶段):先按用户的问题从最新的外部来源检索相关信息,
再把检索到的内容作为上下文喂给模型去生成。(:40)
2. RAG 的架构(三个部件)
| 部件 | 干什么 |
|---|---|
| retriever 检索器 | 系统的「侦察兵」,从数据库/文档/网页/API 里找最相关的片段;数据要事先建索引 |
| generator 生成器 | 就是 LLM,拿「用户问题 + 检索到的内容」生成回答 |
| 知识源 | 被索引过的资料本体 |
四步流程(:127):收到问题 → 检索器在知识库里找 → 生成器同时拿到原问题和检索结果 →
生成器产出把检索内容纳进去的回答。
作者给的完整对照(可直接做走查): 问「用礼品卡买的电子产品退货政策是什么?」
- 无 RAG:「大多数零售商允许 30 天内退货,不过礼品卡购买可能条款不同。」(听起来对,但是 编的)
- 有 RAG:「按我们现行政策,用礼品卡买的电子产品 14 天内可退成店铺积分,
或 30 天内可换货。所有退货都需要原始礼品卡收据。」(
:70–:76)
3. RAG 不是银弹(这一段很诚实,拆解必须保留)
作者在 :88 列了 RAG 自己带来的代价与失效模式:
- 建索引和嵌入有一次性成本 + 持续成本;
- 每次查询都在生成时间之上多加一段检索延迟;
- 检索可能漏掉相关文档,也可能捞上来不相关的;
- 就算给对了上下文,模型照样可能幻觉;
- 向量存储和基础设施带来运维负担;
- 知识库又小又稳定的话,直接把信息写进提示词更简单也更便宜,不必上完整的 RAG 流水线。
另外在 :250 又重申一次:来源可能过期或残缺、检索会漏、模型拿到正确上下文仍会幻觉 ——
「RAG 提高可靠性,但没有消除对监督、护栏和评测的需要」。
4. 索引四步(全书讲得最清楚的一处流程)
图 3.4 的四步(:276–:309):
Load 载入 → 从文本/JSON/网页等各种源头把原始资料读进来
Split 切分 → 长文档切成小块(chunk)
Embed 嵌入 → 每块文字转成一串数字(向量)
Store 存储 → 把向量存进可检索的仓库
书里给「嵌入」的比方(它自己承认是比方,第 4 章才讲真的):
把一屋子书编目 —— 不去记每本书的每个词,而是给每本书做一张卡片,
写上主题、话题和整体「气质」;卡片比整本书好翻得多。「狗」和「小狗」的向量彼此更近,
和「猫」的更远。(:293–:302)
5. 用什么框架
- LangChain:开源 Python 库,把提示词模板、模型、外部 API、记忆串成链条。
书里坦白:前半章只把它当「切文本、加载文档」的工具库,不是被它锁死的框架(
:334)。 - 另外点名的两个:LlamaIndex(专注检索和索引)、Haystack(模块化流水线,生产就绪)。
- 向量索引用 FAISS(Facebook AI Similarity Search)。
书里明确指出 FAISS 是内存里的相似度搜索库,不是托管数据库;进程一退索引就没了,
生产要
faiss.write_index()存盘,或改用 Pinecone / Weaviate 这类自带持久化的托管库。(:1412)
6. 评测 RAG(这一节是第 9 章的前哨)
evaluator LLM(评审模型): 把「用户问题 + 检索到的文档 + 生成的回答」一起喂给另一个模型,
让它按三个标准打分(:600):
① 事实正确性(引的每 MB 资费和官方费率表对得上吗)
② 上下文贴切度(有没有正面回答用户问的那件事)
③ 幻觉迹象(有没有无法核实的说法、有没有和检索内容矛盾)
打 1–5 分,低分的挑出来复核。价值在于能规模化地审。(:617)
评测数据集要放什么(:668–:711):
- 五类问法:基本事实题 / 比较题 / 排障题 / 账单与账户题 / 假设题;
- 权威答案来源(规格书、正式政策文档、排障指南、客服话术与 FAQ)当 ground truth;
- 要专门放「幻觉样例」 —— 书给的例子极好:问「Unlimited Elite 套餐含 5G 吗」,
幻觉回答是「含,而且在部分地区速度高达 10 Gbps,还免费送高清流媒体和热点」
—— 部分为真,但具体的速度数字和免费功能是官方文档里没有的。(
:703)
四个手算得出来的指标(:740–:782):
| 指标 | 算法 | 书给的例子 |
|---|---|---|
| 检索精度 | 相关的块数 ÷ 检索出的块数 | 取 10 块中 7 块相关 = 0.7 |
| 答案相关度 | 问题与答案的嵌入做余弦相似度 | 0.85 |
| 事实准确率 | 答对的题数 ÷ 总题数 | 85/100 = 0.85 |
| 人评分 | 1–5 分量表取平均 | (4+5+4)/3 = 4.33 |
RAGAS(Retrieval Augmented Generation Evaluation Suite)的八个指标(:784–:809),
全部 0–1:faithfulness 忠实度 / context relevancy 上下文相关性 / context precision 上下文精度 /
answer relevancy 答案相关性 / contextual recall 上下文召回 / contextual precision /
answer correctness 答案正确性 / answer similarity 答案相似度。
书给了 ragas.evaluate() 的代码,拿 explodinggradients/amnesty_qa 数据集演示。
⚠️ 书里承认这八个里 context precision 和 contextual precision 定义几乎重合 —— 实际上是它自己写重了,
这是 MEAP 未定稿的又一处毛病。
7. 「Lost in the Middle」—— 本章最硬的一条外部证据
模型对上下文窗口开头和结尾的信息用得最好,放在长上下文中间的信息用得最不可靠, 呈 U 形曲线。所以「检 索一大堆长文档拼起来」反而会降低表现,关键事实被埋在模型最不看的中间。 (
:851,搜「Lost in the Middle」;论文:Liu et al. 2023,arXiv:2307.03172,:1639)
这条直接推出后面所有的「筛」:
- 语义相关性过滤:设一个最低相似度阈值,只留真正回答问题的段落。
例子:问「怎么开国际漫游」,检索到四份文档(开通 FAQ / 资费表 / 各地覆盖对比博文 / 服务条款),
只有 FAQ 里有分步操作,其余三份筛掉。(
:871–:883) - 元数据标签过滤:文档打上 billing / troubleshooting / features 这类标签,
按查询意图限定检索范围。(
:884) - 上下文长度优化:抽取式摘要把长文档压成要点。(
:898)
8. BM25 与元数据过滤实操(Haystack)
BM25(Best Matching 25) 是关键词排序算法,「几十年来一直在给搜索引擎供能」。
和嵌入检索不同,它数查询词在文档里出现的频次,同时压低常见词的权重。
它确定、快、可复现:同一个查询永远返回同一批结果,没有模型推理也没有嵌入漂移。
很多生产系统拿 BM25 做基线,再对精确关键词匹配不够用的查询加语义检索。(:912–:921)
书里的 QueryMetadataExtractor: 用一个 LLM 从自然语言问题里抽出结构化的过滤条件。
问「我用 Mobile Plus 套餐,iPhone 14 Pro 怎么开国际漫游?」→
抽出 topic=international_roaming, plan_name=Mobile Plus, device_type=iPhone 14 Pro, year=2023
→ 把这些当过滤器交给 BM25 检索器。(:975–:1098)
这是「用模型给检索做前处理」的完整可走查例子,拆解里很好用。
9. 进阶手法(3.7,每个一小段)
| 手法 | 干什么 | 关键点 |
|---|---|---|
| 微调嵌入 | 通用嵌入抓不住领域词汇的细微差别 | 造训练集靠人工问答对 + 合成问题生成;第 4 章展开 |
| 元数据补上下文 | 文档被孤立地取出来会丢上下文 | 把来源文件名、标题、章节名嵌进向量,或做二次过滤 |
| 混合检索 | 关键词 + 嵌入相似度一起用 | 还能按查询复杂度在大小模型之间级联 |
| 查询改写/扩写 | 用 LLM 加关键词、重构提示词;生成多个变体做集成检索 | HyDE(Hypothetical Document Embeddings)更进一步:先让模型凭空写出一篇「假想答案文档」,拿它去检索 |
| 查询路由 | 为不同类型的查询建不同的索引,先分类再选索引 | 顺带把简单查询发给小模型,省钱 |
| GraphRAG | 见下 | |
| Agentic RAG | 见下 |
GraphRAG(微软 2024 提出)(:1219–:1304):
标准 RAG 擅长找相 关文本块,但答不了「公司 Q1 的风险和 Q3 提到的缓解措施有什么关系」
这种要跨多份文档连关系的问题。GraphRAG 先从文档里抽出实体和关系建成知识图谱,
再按社区聚类生成分层摘要,从而支持「全局查询」。
书给的对照表(:1236):
- 传统 RAG:找具体事实 / 单文档能答 / 低延迟要求 —— 「我们的退货政策是什么?」
- GraphRAG:跨文档归纳主题 / 多跳推理 / 复杂分析型查询 —— 「各地区的政策有什么不同?」
代码用 Neo4j + Cypher。代价:建索引开销显著变大。
(论文:Edge et al. 2024,arXiv:2404.16130,
:1646)
Agentic RAG(:1306):把检索过程本身交给 agent 控制。
例子:「比较你们电子产品和服装的退货政策,哪个的顾客评价更好?」→
agent 意识到这需要多次检索 → 查电子退货 → 查服装退货 → 查评价库 → 综合。
明说要到第 6 章和第 8 章才建完整的 agentic 系统 —— 这是一处要核对的许诺。
10. 第 3 章的项目与它的毛病
3.8 用 LangChain 从头搭 11 步 RAG(装库 → 导入 → 加载 → 切分 → 嵌入 → 向量库 → 准备模型 → 检索器 → RetrievalQA 链 → 测试 → 评幻觉)。
⚠️ 这个项目有一处明显的技术错误,拆解不能照抄:
第 7 步用 AutoModelForQuestionAnswering.from_pretrained("bert-base-uncased") 当生成模型
(:1421)。BERT 的抽取式问答模型只会从给定段落里划出一个片段,不会生成回答,
把它塞进 RetrievalQA 当 llm 是不成立的。这是 MEAP 稿的缺陷。
⚠️ hallucination_score 函数也很粗糙(:1485):它只做词集合相减 ——
回答里有多少词没在源文档里出现。这会把「换个说法表达同一意思」判成幻觉,
把「照抄原文里的词但拼成假话」判成没幻觉。 书没有说明这个局限。
拆解可以留这个函数当「最朴素的基线」,但必须点出它的两个盲区。
第 4 章 Embeddings and Vector Search(全书最长的一章)
1. 开场的失败案例(全书最好的开头之一)
一家大型医疗公司上线了帮病人查保险方案的 RAG 聊天机器人。 模型好、文档全,可上线后用户问「手术后的物理治疗报销吗」,它要么含糊其辞,要么直接说不知道 —— 而答案明明白白写在它能访问的文档里。
问题不在模型,也不在内容,在检索;而检索失败的根子在嵌入模型。(
:29)
这一句就是第 4 章存在的理由,也是整个 PART 1 的枢纽。
2. 嵌入到底是什么
- 定义:把一段文字(句子/段落/整篇文档)转成一串数字,即高维空间里的一个点,
常见是 384 维或 768 维。(
:72) - 关键不在于「是个点」,而在于点的位置:意思相近的文字落在彼此附近。(
:77) 书给的例子: 「我怎么报销心理治疗费?」和「提交心理健康理赔的流程是什么?」—— 几乎不共用词,但意思一样,好的嵌入模型会把它们映射到相近的位置。(:80) - 怎么量「近」:余弦相似度或点积。
书讲清了区别:余弦相似度量的是两个向量的夹角(方向),因此与长度无关;
点积还会把向量的长度算进去。实际上多数 RAG 系统用余弦相似度,因为它只看语义方向。(
:85) - 心智模型「制图师」(
:92):把每句话丢到一张巨大的「人类想法地图」上 —— 讲休假政策的句子聚成一团,问医疗报销的落在健康类文档旁边, 问辞职/解雇的飘向 HR 和法务那一片。检索 = 把问题也丢上这张图,看它附近有什么。 图 4.3 是这张图的 2D 投影(书自己说 384/768 维没法可视化,这是投影)。
3. 三类嵌入模型(表 4.1 在 :225)
| 类别 | 例子 | 强 | 弱 | 适合 |
|---|---|---|---|---|
| 商业 API | OpenAI text-embedding-3-small、Cohere embed-v4、Google gemini-embedding-001 | 上手快、开箱质量高 | 不知道拿什么数据训的、不能微调、按量收费、有延迟与限流、受监管行业有隐私顾虑;换供应商要把整个语料重新嵌入一遍 | 通用聊天机器人、内部搜索 |
| 开源 | E5、BGE-M3、all-MiniLM、GTE、NV-Embed-v2、Qwen3-Embedding | 免费、可微调、可本地跑 | 要自己养基础设施 | 隐私敏感、要定制 |
| 领域专用 | LegalBERT、SciBERT、PubMedBERT、BioSentVec、CodeBERT | 在本领域内准得多 | 出了领域就差 | 法律工具、医疗问答 |
| 指令调优 | e5-large-v2、BGE、GTE、Qwen3-Embedding | 更懂自然语言式的提问 | 更大更慢 | RAG 助手、对话式系统 |
领域专用为什么必要,书给了一个极好的一句话理由:
「如果你的检索系统认不出『termination(终止/解雇)』在合同里和在医疗报告里 完全是两回事,结果就会很差。」(
:205)
四个选型维度(表之外的正文,:254–:280):
- 维度取舍: 768–1536 维抓得住更多语义细节但更占存储和算力;≤384 维牺牲精度换效率。 百万级文档时,维度降到四分之一意味着可观的基础设施节省。 Matryoshka 表示学习(MRL):训练后可以把 1536 维截断到 256 维而质量损失很小 —— 这是 OpenAI text-embedding-3 支持的能力,部署时才决定精度与成本的取舍。
- 上下文长度: MiniLM 这类老模型只吃 512 token,新的支持 8K+。 截断会丢关键信息,所以长文档要配切块策略。
- 多语言: XLM-RoBERTa、多语版 E5;但在单一语言里通常不如该语言的专用模型。
- 硬件: BERT-base 系要 500MB+ 显存;量化后的模型可以在 CPU 上跑,质量损失很小。
4. Airbnb 案例(4.2.6,本章最长的案例)
问题: 房源上百万条,房东写的描述和房客搜索用的话对不上。
「想找安静的、能看到山、走路能到餐厅的地方」 vs 房源写的「俯瞰阿尔卑斯的静谧藏身处,靠近镇中心」
—— 纯关键词系统会漏掉这条完全合适的房源。(:317)
架构:双塔(dual-encoder / two-tower),基于 BERT。
两个独立的编码器分别处理「查询」和「房源」。
这个架构决定的关键收益:百万条房源的向量可以预先算一次存起来,
每次搜索只需要实时算查询那一个向量。(:338)
而且两侧可以各自优化:查询编码器专门对付短而含糊的搜索短语,
房源编码器对付长而细的描述。(:342)
训练数据:不靠人工标注,靠用户点击的隐式信号。
用户搜索后点了哪条房源,就构成一个「查询-房源」的相关对。
这解决了「哪来那么多高质量训练数据」的问题,而且数据源源不断地反映真实意图。(:347)
⚠️ 但它自带偏差:排在前面的房源天然更容易被点,不管相不相关。
Airbnb 不得不做去偏处理,免得嵌入学到的是「位置偏好」而不是真的语义关系。(:358)
线上分四步(:370):实时算查询向量 → 用 ANN(近似最近邻) 找语义相近的房源 →
和传统过滤条件(价格区间、日期)合并 → 最终排序算法综合语义相似度和其他因素。
这个模式:嵌入负责语义理解,传统方法负责约束和业务规则。(:379)
衡量成功:他们报了技术指标(排序错误减少 16%),但最终看的是业务结果 ——
预订转化率、用户满意度、以及长尾查询的处理能力。
「嵌入模型的最终检验不是学术基准,而是它有没有改善真实的用户体验和业务指标。」(:384)
三个生产难题(有普遍性)(:400):
① 冷启动:新房源没有点击数据 → 先用内容(描述和属性)生成初始向量,
随着点击和预订信号累积再频繁重嵌入;
② 算力预算:预算房源向量 + 优化查询编码器的速度;
③ 持续监控与重训:语言习惯和用户行为会变,嵌入质量会随时间退化。
5. 纯向量检索为什么不够(4.3,本章的推理转折)
书给的具体失败: 问「在加州辞职要提前多久通知?」
系统嵌入这个问题、取最近的 5 个向量,而答案(「提前 30 天」)明明在语料里,
却一条 都没被取到。(:457)
三条原因(:468):
- 语义漂移:嵌入模型看重的是宽泛的主题相似,而不是「能不能回答这个问题」;
- 召回不足:正确答案的排名恰好掉在 top-k 截断线外一点;
- 领域鸿沟:通用嵌入抓不住专业领域的细微区别。
这时 LLM 只剩两个坏选项:编一个答案(幻觉),或者认输说「我不知道」。(:475)
6. 混合检索与多阶段检索(本章的落点)
混合检索 = 稠密 + 稀疏(:481):
- 稠密检索(dense retrieval) = 嵌入那一路,抓语义和主题关系;
- 稀疏检索(sparse retrieval) = BM25 这类关键词方法,擅长具体词项的精确匹配; 其他选项:TF-IDF、以及更新的学习式稀疏方法 SPLADE。 回到加州辞职那题:稠密模型认得「辞职」「通知期」和雇佣政策的概念联系; BM25 直接优先包含「notice period」「resigning」「California」原词的文档。互补。
多阶段检索管的是精度,不是召回(:511):
书给的例子 —— 问「残障员工的远程办公政策」,混合检索确实找到了那条
「员工可依据 ADA 申请远程办公便利」,但它排在第 3 位,上面压着「2023 年假期政策」
和「福利登记截止日」。东西在,但排序不对,这是精度问题。(:527)
三阶段(:540):广检索(冲召回)→ 逐级过滤 → 精排(重排)。
书给的类比很好:在图书馆找一本书 —— 先走到对的区(广检索),
再扫书架找相关主题(过滤),最后翻开具体几本细看(精排)。
bi-encoder 与 cross-encoder 的区别(本章最该讲透的一处机制):
| bi-encoder(双编码器) | cross-encoder(交叉编码器) | |
|---|---|---|
| 怎么做 | 查询编成一个向量、每篇文档各编成一个向量,再比向量 | 把查询和文档拼成一对一起喂进模型,过完所有层,直接输出一个相关性分数 |
| 好处 | 文档向量可以预先算好 | 能捕捉查询词和文档词之间的复杂互动 |
| 命门 | 查询和文档从不直接相互作用 | 慢得多,所以只能用在前面几阶段选出来的少量候选上,绝不能扫全语料 |
书给的例子:cross-encoder 能理解查询里的「work accommodation」和文档里的「ADA」高度相关,
即便这些词根本没有共同出现过。(:572)
动手实现(4.3.4)有完整可跑的代码和真实输出,这是全书最完整的一条走查:
五条员工政策文档 + BM25 + intfloat/e5-base + cross-encoder/ms-marco-MiniLM-L-6-v2。
真实输出(:743–:762):
- 问「加州辞职要提前多久?」→ 命中「California employees must give a 30-day notice before resignation」得分 0.987;第二名「Termination for cause…」只有 0.223。 注意它把查询里的 quitting 连到了文档里的 resignation —— 这就是语义匹配在起作用。
- 问「有带薪领养假吗?」→ 命中 0.965,第二名 0.156。
- 问「因行为不端被解雇会怎样?」→ 把「fired for misconduct」匹配上「termination for cause」,0.912。
三个部件各自的贡献(书自己拆的,:799):
只有 BM25 → 会漏掉第一题,因为文档里没有「quitting」这个词;
只有稠密检索 → 会捞到概念相关但没用的文档;
没有 cross-encoder 重排 → 文档对了但顺序不对。
7. 三项工程优化
① 元数据过滤(4.4.1,比第 3 章讲得深)
纯语义检索只有一个维度:意思。它看不见五种结构性属性(:830):
时效(2023 的政策 vs 2018 的)、权威性(正式 HR 政策 vs Slack 里的闲聊)、
受众(给经理的 vs 给全员的)、地域(加州 vs 纽约)、部门。
书给的前后对照极有说服力(:990–:1015),可直接做走查:
问「加州的陪产假政策是什么?」
- 纯语义检索:第 1 名是 2019 年已归档的全球政策(0.85),第 2 名是纽约的(0.82), 正确答案「加州 12 周带薪陪产假」排第 3(0.78);
- 加上自动过滤
{region: California, status: active}:正确答案升到第 1。
四个组件:抽取 → 存储 → 查询分析 → 施加过滤。
抽取用三条路并用(:855):文件路径解析(/policies/hr/benefits/doc.pdf → 部门)、
正则(抽「Effective Date: 2023-01-01」这类结构化字段)、LLM(抽受众、状态这类语义属性)。
⚠️ 书自己给了成本警告:对大语料每篇都调完整 LLM 太贵,生产上考虑更小的模 型
(GLiNER、小的指令调优模型)。(:876)
还有一个细节值得留:不是所有属性都用硬过滤 —— 归档文档的分数乘 0.5(软降权),
这样偏旧但高度相关的内容仍有机会浮上来。(:967、:986)
② 切块策略(4.4.2)—— 书说这是「RAG 设计里最被低估的一环」(:1021)
书给的具体两难,用的是加州家庭权利法案(CFRA)那段文字:
「CFRA 为符合条件的员工提供最多 12 周的工作保障休假…… 要符合条件,员工须在本公司工作满一年,且在休假前 12 个月内工作满 1250 小时。」
- 小块(100–200 token):资格条件可能和政策名称、目的被切开。 用户问「我符合 CFRA 休假条件吗」,系统可能只取到讲政策存在的那一块, 漏掉第二块里的资格条件;
- 大块(500+ token):政策和资格条件待在一起了,但如果这块里还混着别的政策, 它对具体资格问题的相关度分数会被稀释。
解法:按内容类型切,不是一刀切(:1057):
法律文档按章节切(保住完整的法律概念和定义)/ 叙述性内容按段落切(设最小长度阈值)/
代码文档保住代码块和函数签名(让例子和解释待在一起)/ 兜底用滑动窗口。
另一条现代路线:语义切块 —— 用 spaCy 这类 NLP 库按句子或自然命题切,边界比固定字符窗更有意义。
重叠(overlap)是「边界问题的保险」: 书给了具体的两块对照(:1125),
100 token 的重叠让「CFRA 资格」这个跨边界的信息在两块里都出现。
经验值:政策按节切 + 20% 重叠。(:1146)
③ 向量压缩(4.6.1)
768 或 1536 维 × 上百万文档 = 几十 到几百 GB 内存。三种压缩(:1804):
- 乘积量化(PQ):把向量近似成基于码本的小表示,不再每维存 32 位浮点;
- 标量量化(SQ):每个浮点降成 int8 这类更小的类型;
- 二值量化(BQ):每一维塌成 1 个比特。
书特意说明:这三个词就是你在 Qdrant / Weaviate / FAISS 里配置时会看到的原词。(
:1810) 最佳搭配:压缩向量做第一轮粗筛,候选再交给 cross-encoder 精排 —— 规模和质量兼得。(:1812)
8. 规模化:HNSW、FAISS、向量数据库
问题的量级: 「10 万篇文档就足以让朴素向量检索慢到难受;到几百万篇就完全不可用。」(:1154)
HNSW(Hierarchical Navigable Small World,分层可导航小世界)(:1159):
把向量组织成层数递增的图。顶层稀疏,只连少数向量;每往下一层加入更多向量和连接,
最底层含全部向量。 搜索时从顶层随机一点出发,顺着图的连接朝查询方向走;
在当前层走不动了就下沉一层继续。
效率来自两个性质:小世界结构(任意两点之间几跳可达)+ 分层导航(逐级精化)。
合起来把复杂度从 O(n) 降到 O(log n) —— 在大集合上就是毫秒级和数秒级的差别。(:1177)
两个可调参数: M(每个节点的最大连接数,推荐 16)、
efConstruction(建索引时的彻底程度,推荐 100);调高更准,但更费内存、建得更慢。
FAISS 是 HNSW 等算法最广泛使用的实现(C++ 写、有 Python 绑定、支持 GPU)。
它不提供持久化、元数据过滤、分布式检索 —— 这些要向量数据库。(:1233)
选型提示:文档频繁新增或内存预算紧,IVF(尤其 IVF-PQ)可能更合适;
查询延迟压倒一切、内存吃得起,就用 HNSW。(:1236)
七个向量数据库(表 4.2 在 :1293):
Pinecone(托管,快速起步,规模上来成本高)/ Weaviate(GraphQL,复杂元数据查询,配置复杂)/
Qdrant(Rust 写的,高性能过滤,生态较小)/ Chroma(简单 Python API,生产特性有限)/
pgvector(已有 PostgreSQL 的团队,超大规模受限)/ Milvus(云原生微服务,超大规模,运维复杂)/
Elasticsearch(已有 Elastic 栈的团队,不是为向量而生)。
向量数据库比裸算法多出的五件事(:1266):持久化 / 增量更新(不必重建整个索引) /
水平扩展 / 副本 / 监控与可观测性。
Pinecone 项目(4.5.4) 用医疗保险政策做了完整七步。里面有一条很实在的生产经验:
把原文塞进向量库的 metadata 虽然省一次查库,但百万级切块时会让索引内存暴涨、成本上升;
企业常见做法是向量库里只放向量和块 ID,原文放在便宜的文档库(DynamoDB / MongoDB)里按 ID 取。(:1560)
9. 嵌入漂移(4.6)
就算你的文档一个字没改,人们提问的方式会变。 新的产品功能、政策措辞的演化、 甚至用词的文化变迁,都会让用户的问法和索引里的向量慢慢分开 —— 这叫嵌入漂移。(
:1771)
症状: 以前答得好的问题开始给含糊的回答;以前能精准命中的查询现在只捞到松散相关的东西。
「这不一定是检索器坏了,而是你的嵌入和当下的世界脱节了。」(:1783)
第二种漂移更隐蔽:换了嵌入模型或升级了版本,却没有把文档重新嵌入。
「哪怕模型架构或训练数据只有小改动,文档在向量空间里的位置也会移动。
不一致地重嵌入,查询和文档就会分开 —— 不是语义上分开,是数值上分开。」(:1788)
处置:把嵌入当成活的过程。 有的团队每晚重嵌入,有的每周或每次模型更新后重来。
没有普适的周期,关键是一致:查询用哪个模型版本,文档就得用哪个。(:1793)
第 4 章小结里还补了一条:选一个足够通用的嵌入模型,可以降低重嵌入的频率和成本。(:1883)
新增的「书没讲透」的缺口(累计)
- BERT 抽取式问答被当成生成模型用(
06-ch03:1421)—— 技术错误,拆解不能照抄。 hallucination_score的词集合做法有两个盲区(同义改写误判为幻觉、照抄词拼假话判为无幻觉), 书没说。要么在拆解里点破,要么不用它。- RAGAS 的八个指标里 context precision 与 contextual precision 重复(
06-ch03:793、:802)。 - HyDE 只提了一句名字(
06-ch03:1204),没讲它为什么管用 (让模型先写一篇假想的答案文档,拿这篇文档的向量去检索,比拿短问题的向量检索更接近答案文档的分布)。 这是「出门会撞见的名字」,必须留名且讲透 —— 要补外部来源。 - SPLADE 只有名字(
07-ch04:491),没讲它是什么。 - Matryoshka 表示学习(MRL) 只给了效果(
07-ch04:259),没讲原理 —— 要补。 - Airbnb 案例的引用是一篇 2018 年的 Medium 博文(
07-ch04:1893), 而正文描述的是「双塔 BERT 架构 + 点击信号训练」的 Neural Search。 这两件事时间上对不上(2018 那篇讲的是 listing embeddings,不是 BERT 双塔) —— 需要核实,核不到就写明我们没核到。 - 「排序错误减少 16%」这个数字没有参照物(
07-ch04:386),引用时要补对照。 - MCP 在第 1 章被点名为「新兴标准」,细节留到第 7 章 —— 到第 7 章要看它讲到什么程度,
我们的
ai-protocol-reference书架有完整的 MCP 规范拆解可以补。