20 min · 向量召回原理、混合检索与重排、以及 2026 年的新答案：让 agent 自己读
🎒 预备知识：完成上一课「A7 结构化输出」（零基础入口：第 0 课）
embedding 模型把一段文本映射成一个高维向量（比如 1536 个数）。训练目标是： 语义相近的文本，向量夹角小。经典关系"国王 − 男人 + 女人 ≈ 女王"就是这种几何的体现。 于是"怎么退货"和"退款流程"不需要共享任何字面词，向量距离就近——这是它优于关键词搜索的地方。 但反过来，精确匹配是它的弱项：查"报错 ERR-300012"，向量可能把"常见错误处理"排前面， 因为语义"更近"；而关键词搜索一击命中。
① query：用户问题（或模型生成的检索词）
② embed：query → 向量
③ retrieve：向量库里找余弦距离最近的 k 个块
④ augment：块进上下文 → 模型基于它回答chunk（分块）是工程上最难的部分，三种主流策略与失败模式：
| 策略 | 做法 | 失败模式 |
|---|---|---|
| 固定窗口 | 每 500 字一块 | 句子拦腰斩断，块内语义残缺 |
| 重叠窗口 | 相邻块重叠 10–20% | 缓解截断，但块间重复浪费 token |
| 按结构切 | 沿标题/段落/函数边界切 | 需要语料有结构——首选，能用则用 |
原则：chunk 的边界应该和"一个完整语义单元"对齐。检索回来的是块，块烂，后面全烂—— 调 RAG 先调 chunking，别急着换 embedding 模型。
混合检索解决"向量 vs 关键词"各有所短的问题：向量出语义候选，BM25 类 关键词算法出精确候选，两路结果用 RRF（倒数排名融合）合并—— 一个结果在两路都靠前，融合分就高。这是生产 RAG 的标配，不是可选项。 重排（rerank）解决"召回 ≠ 相关"：第一步宽召回（top 50，求别漏）， 第二步用专门的 reranker 模型对 50 个候选逐个精排，取前 5 进上下文（求准）。 两阶段架构——宽召回 + 精排序——和搜索引擎同构，直接照抄。
还有两招检索前的加工：查询改写（用户口语"那个东西怎么弄"→ 改写成规范检索词， 用一次便宜的 LLM 调用）和 HyDE（让模型先虚构一个理想答案，拿虚构答案去检索—— 答案和文档的相似度天然高于问题和文档）。
| 路线 | 适合 | Easel 的取舍 |
|---|---|---|
| 全量进窗口 | 语料 ≤ 几千 token | 画像六维文件直接整读（L05）——零检索成本零召回风险 |
| 传统 RAG | 海量无结构语料、问法多变 | OpenClaw memory index 支持向量索引 |
| agent 化检索 | 有结构、可导航的知识 | 默认路线：技能按需读 references；未配向量 API 时显式退化关键词检索 |
agent 化检索为什么常胜：模型看到"有什么可读"（目录/索引/frontmatter）， 自己决定读哪块——检索词的语义理解、多跳查找（读完 A 发现要看 B）、不够再读， 全交给 loop 本身（A3），不需要独立的检索管道和它的调参地狱。代价是多几次模型调用。 决策口诀：语料小→整读；有结构→agent 化；大而乱→才上 RAG。
RAG 有自己的评测指标：建一个"问题 → 应命中的文档块"的金标集，测 召回率@k（答案块在 top-k 里的比例）和精确率（top-k 里多少是垃圾）。 调 chunking、换 embedding、调 k，每次跑一遍金标集——不建金标集的 RAG 调优全是玄学。
坑 1：切太碎。chunk 100 字一条，检索命中 10 条拼不出完整语义—— 召回率高了，答案质量降了。坑 2：只有向量没有关键词。专有名词、错误码、 型号精确查询全部翻车。混合检索是标配。坑 3：top-k 原文直接塞。 检索回来 5 段 × 800 字全进上下文——违反 A5 蒸馏原则：进摘要或首句 + 指针，模型需要细节自己取。
三个场景选路线并说理由：① 1000 页法规库问答；② 六份用户画像文件； ③ 你的代码仓库问答（提示：grep 和目录树算不算"可导航结构"？）。 再答一题：你的产品文档要做客服机器人，chunking 按什么边界切、检索用不用混合？ 发到对话里我批改。