11 · 检索与 RAG

⏱ 30 分钟 ｜ ⭐ 核心 ｜ 学过《推荐算法》的话这节会很快

🔗 可运行实践： 入库、检索调优与引用诊断 。

🎯 一句话

模型不知道你的私有数据。RAG = 提问时临时去查资料，把相关片段塞进上下文再让它回答。 它是第 4 章渐进式披露在"知识"上的应用。

🔄 一、基本流程

实现结构（下面是骨架；完整启动、数据与运行命令见11b和11c）：

# 🧩 骨架：docs、split_documents、llm 与模型名称须由自己的工程提供。
from sentence_transformers import SentenceTransformer
import numpy as np

model = SentenceTransformer("...")            # 任选一个 embedding 模型
chunks = split_documents(docs)                # 切分
emb = model.encode(chunks, normalize_embeddings=True)   # ⭐ 归一化后点积=余弦

def answer(question, k=5):
    q = model.encode([question], normalize_embeddings=True)
    scores = emb @ q.T                        # 相似度
    top = np.argsort(-scores.ravel())[:k]
    context = "\n\n---\n\n".join(chunks[i] for i in top)
    prompt = (f"只根据以下资料回答。资料里没有的，直接说没有。\n\n"
              f"<资料>\n{context}\n</资料>\n\n问题：{question}")
    return llm(prompt)

🔗 如果你学过推荐算法：这就是召回。向量库 = ANN 索引， Embedding = 双塔模型的物品向量。整套基础设施完全相同。

⚠️ 二、Demo 和生产的鸿沟

🧱 三、环节一：切分（最被低估）

⭐ 上下文检索（Contextual Retrieval）

一个简单但效果显著的技巧：给每个块补一句「它在讲什么」再做向量化。

在 Anthropic 的原实验中，Contextual Embeddings 使 top-20 检索失败率相对下降 35%；加 Contextual BM25 后为 49%，再加重排为 67%。这是特定数据与配置下的相对变化，不是业务保证。原始实验与条件。

成本是用小模型给每个块生成一句上下文——一次性投入，长期收益。

🔍 四、环节二：混合检索（别只用向量）

结论：两路都要，然后融合。 常用 RRF（倒数排名融合）：

$$\text{RRF}(d) = \sum_{r}\frac{1}{k + \text{rank}_r(d)}$$

💡 人话：每个文档在各路检索里排名越靠前得分越高，加起来排序。 好处是不需要分数可比——只用排名，天然解决了"向量分数和 BM25 分数量纲不同"的问题。

🎯 五、环节三：重排（性价比最高的一步）

🔗 完全是推荐算法的「双塔召回 + 精排交叉」，同一套思想。

🔑 实践判断：正确证据已进入候选但排序错误时，先做固定候选的重排对照；漏召回或模型语种不符时，优先修对应环节， 而且成本可控（只在几十条上跑）。正确证据已经进入候选集时再测它；没召回的文档不能靠重排找回。

🔄 六、环节四：查询侧处理

💡 HyDE 的巧妙之处：问题「怎么申请报销」和文档「报销流程：第一步…」 在向量空间里未必近；但模型编的假答案「报销需要先填单据…」和真文档就很近了。

📊 七、环节五：评估（最容易跳过，也最致命）

必须分开评估两段，否则你不知道问题出在哪：

⚠️ 最常见的诊断错误：答案不对就去调提示词。 先查检索——如果正确文档根本没被召回，提示词再怎么调都没用。

# 最小可用的检索评估
def eval_retrieval(qa_pairs, k=10):
    hits = 0
    for q, gold_chunk_id in qa_pairs:
        retrieved = retrieve(q, k)
        if gold_chunk_id in retrieved:
            hits += 1
    print(f"Recall@{k} = {hits/len(qa_pairs):.1%}")

造评估集的最省力办法：让模型读每个块，生成一个「只有这块能回答的问题」， 就得到了 (问题, 正确块) 对。人工抽查 10% 即可。

🕸️ 八、进阶方向

🤔 上下文变长了，还需要 RAG 吗

需要。四个理由：

🔗 九、和站内其他章的关系

⭐ 一个很多人会在这一章之后立刻掉进去的坑：把 Memory 当成「RAG 换个名字」。

检索那一半确实是同一套——04b · Agent 记忆里的长期记忆照搬这一章的切分、混合检索、重排，一行不用改。 但另一半完全不同，而且这一章一个字都没讲：

	RAG（这一章）	Memory（04b）
谁写进去的	你，离线批量灌	⭐ Agent 自己，在线随时写
写什么	已有文档，原样切块	要先判断「这条值不值得记」 —— 判据是什么？
旧内容怎么办	文档更新就重灌	⭐ 新旧冲突谁赢？过期的怎么忘掉？
写错了	重建索引即可	错误会一直被检索出来，自我强化 💀

写入和治理是 Memory 独有的那一半，也是它真正难的地方。 🔗 那一章还会把「短期 / 工作 / 长期 / 情景」四层记忆分开——这一章的 RAG 只对应其中的「长期」一层， 而你在第 12 章会用到的 progress.json 是另一层（工作记忆）。先分清是哪一层，再决定用什么技术。

🕳️ 十、六个常见坑

📚 延伸阅读

• 上下文检索（Contextual Retrieval）
• AI Agent 的有效上下文工程（即时检索部分）

👉 这一节对应的框架：LlamaIndex 封装的就是这条管线（切分 → 嵌入 → 检索 → 重排）。它替你做了什么、又没替你做什么，见 16b · 框架这层皮。

✅ 检查点

1. RAG 的两个阶段各做什么？
2. 为什么必须混合检索而不能只用向量？举个具体例子。
3. 上下文检索（Contextual Retrieval）做了什么？效果如何？
4. 为什么说重排是性价比最高的一步？
5. RAG 答案不对，第一步该查什么？
6. HyDE 的原理是什么？
7. 上下文能装 100 万 token 了，为什么还需要 RAG？

🛑 可以停在这里

⚡ 走神救援

下一节 👉 12-Harness-长时任务的骨架.md