RAG 深度教程：从原理到生产级检索增强生成

§0 这是什么、谁该读

这是一篇约 2 小时的 RAG 深度教程。它不是「RAG 是什么」的科普—那看 RAG 小课 就够。这篇要回答的是:RAG 在生产里为什么经常答错，以及怎么把它做对。

适合谁：搭过最小 RAG、但卡在「检索不准 / 不会评估 / 不知道怎么优化」的人。如果你还没搭过，先看小课跑通最小版，再回来。

体裁：field note，论点 + 机制 + 代码 + 引用并行。建议边读边在脑里对照你自己的 RAG（如果有），每节末有「对你的延伸」。

原文溯源：RAG 原始论文 Lewis et al. 2020（Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks）。本文综合该论文及后续工业实践（Anthropic context engineering、RAGAS、LlamaIndex/LangChain 文档等）。

---

§1 为什么需要 RAG：大模型的三个根本限制

要理解 RAG 解决什么，先看清大模型为什么不够。三个限制，每一个都不是 prompt 能解决的。

1.1 幻觉：概率预测的必然产物

大模型的本质是预测下一个 token—它追求「读起来通顺」，而非「事实正确」。当它遇到训练数据里没见过的内容，它不会说「不知道」，而是根据语言规律编一个最像样的。

问：「我们 API 的限流是多少？」 答（编的）：「默认限流为每分钟 1000 次请求，可联系商务提升上限。」—看着合理，但完全不是你们公司的真实配置。

这不是 bug，是机制。任何不依赖外部检索的方法（prompt 工程、思维链）都改变不了这个本质—它们只能让编造更「像样」，不能让它变「真」。（详见 AI 幻觉小课）

1.2 训练截止：知识的时间边界

模型的参数在预训练结束那一刻就冻结了。GPT-4 的训练数据有截止日期，这之后的世界它不知道：新发布的 API、新的财报、昨天的事件。

你可以在 system prompt 里告诉它最新信息，但：

• prompt 空间有限，塞不下「所有最新事实」
• 模型分不清哪些是你给的「最新」、哪些是它旧的「记忆」，容易混淆

微调能更新知识，但成本高、且要定期重训—对频繁变化的事实（价格、库存、政策）不现实。

1.3 私有知识：模型从没见过的数据

你的公司文档、产品手册、内部 wiki、客户数据—模型预训练时从没见过。任何 prompt 技巧都无法让模型「回忆」它从没学过的东西。微调可以注入，但对「大量、频繁更新、需要精确引用」的知识，微调既贵又不灵活。

1.4 为什么其他方案各自不够

方案	幻觉	私有知识	时效性	成本	溯源
prompt 工程	改善有限	✗	✗	低	✗
长上下文	改善	小量可塞	手动塞	贵（按 token 付费）	✗
微调	改善	可注入	需重训	很贵	✗
RAG	根治（基于文档）	能答	文档随时更新	中	能

RAG 不是唯一解，但它在「私有 + 时效 + 溯源」这三件事上，是当前最务实的方案。

1.5 范式转换：从「记住」到「查」

理解了上面三点，你就明白 RAG 做的是一次范式转换：

• 旧范式：把知识塞进模型（训练 / 微调），让它记住
• RAG 范式：把知识放在外部库，让模型按需查

这和人脑不一样—人靠记忆 + 推理。但 AI 记忆不可靠（幻觉 + 截止），所以给它一个外挂的可检索记忆比让它死记更靠谱。这个转换，是后面所有工程的基础。

对你的延伸：你的业务里，哪些「事实」是模型答不了的（私有 / 时效）？列 5 个—它们就是 RAG 该接手的地方。

---

§2 RAG 的原理与数学直觉

RAG = 检索 + 生成。但「检索」凭什么能找到相关内容？这背后有两层数学直觉，理解了它们，你才知道 RAG 为什么 work、以及什么时候会 fail。

2.1 完整链路

两个阶段：

建库（离线）：文档 → 切分 → embedding → 存向量库 查询（在线）：问题 → embedding → 向量库检索 top-K → 拼 prompt → LLM 生成

关键在于：问题和文档被映射到同一个向量空间，所以能用「距离」衡量相关性。这是整个 RAG 的地基。

2.2 Embedding 的数学直觉：为什么文本能变成可比较的向量

一段文本能变成一个向量（比如 1536 维），而且意思相近的文本，向量也相近—这不是魔法，是训练出来的。

Embedding 模型训练时，大量见到「意思相近的句子」（同义改写、相邻上下文）被映射到相近的向量空间位置。久而久之，向量空间就形成了语义聚类：所有讲「退款」的句子聚在一片，讲「API 限流」的聚在另一片。

所以当你把「退款政策是什么」和「我们的退款需满足三个条件」都 embedding 后，它们的向量距离很近—尽管字面几乎没重合。这就是 RAG 检索「按意思而非字面」的基础。

关键洞察：embedding 的质量决定 RAG 的上限。换 embedding 模型，RAG 效果会显著变化（§4.2 会讲选型）。

2.3 向量检索：cosine similarity 与 ANN

两个向量「有多接近」用 cosine 相似度衡量—向量夹角的余弦，越接近 1 越相似：

sim(a, b) = cos(θ) = (a · b) / (|a| · |b|)

但问题来了：百万级文档，每个 1536 维，检索时难道要两两算 cosine？那是 O(N·D)，百万文档就上亿次运算，太慢。

解法是 ANN（近似最近邻，Approximate Nearest Neighbor） 算法，主流是 HNSW（分层可导航小世界图，Hierarchical Navigable Small World）：

• 它预先建一个多层图结构，上层稀疏（快速跳跃）、下层密集（精确逼近）
• 检索时从顶层贪心跳转，逐层下降，快速逼近最近邻
• 牺牲一点点精度（可能漏掉极少数真正最近的），换来毫秒级检索百万向量
• 这就是 Chroma / Pinecone / Weaviate / Qdrant 能实时检索的原因

对你的延伸：如果你的向量库文档量 < 1 万，暴力检索（brute force）其实够快且更准，ANN 的意义在更大规模。别一上来就迷信 ANN 的「黑科技」。

2.4 生成阶段：模型如何利用检索上下文

检索回来的 K 段，拼进 prompt：「根据以下资料回答问题：[资料] 问题：…」

大模型（Transformer）通过注意力机制 attend 到这些资料里的 token，生成基于资料的答案。理想情况下，模型「看着」资料回答，而非凭记忆。

但注意力不是平等的—放在 prompt 中间的资料，被注意到的概率低于头尾（这就是 lost-in-the-middle 现象，Liu et al. 2023）。所以「捞更多」≠「答更准」，甚至更差。这个坑在 §5 会展开。

2.5 核心洞察

RAG 的本质是：给模型一个外挂的、可检索的工作记忆。模型本身的参数（内在能力）不变，但它的工作记忆（上下文）被动态填充了相关事实。

这也解释了 RAG 的边界：它增强的是「记忆 / 知识」，不是「推理能力」。复杂的推理、计算、多步规划，RAG 帮不上—那是 Agent / 模型能力的事。

对你的延伸：你的 RAG 任务里，有多少是「事实检索」（RAG 擅长）、多少是「推理」（RAG 不擅长）？把不擅长的剔出来，别指望 RAG 解决。

---

§3 从零搭建最小 RAG

理论讲完，动手。这一节用 LangChain + Chroma + OpenAI 搭一个能跑的最小 RAG，逐行注释，跑通一个真实例子。注意：这版在玩具数据上好用，生产里它会答错—那是 §4 要解决的事。

3.1 环境

pip install langchain langchain-community langchain-text-splitters \
            chromadb langchain-openai
export OPENAI_API_KEY=sk-...

3.2 完整代码

from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough

# 1. 加载文档
docs = TextLoader("refund_policy.md").load()

# 2. 切分 -- chunk_size 控制每块大小，overlap 让相邻块重叠避免边界丢信息
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500, chunk_overlap=50,
    separators=["\n\n", "\n", "。", "，", " "],  # 中文友好的分隔符
)
chunks = splitter.split_documents(docs)

# 3. 向量化 + 存库 -- 调 embedding API（按量计费），结果持久化到 ./chroma_db
embedding = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(chunks, embedding, persist_directory="./chroma_db")

# 4. 检索器 -- k=3 每次捞最相关的 3 段
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

# 5. 生成 -- 把检索片段拼进 prompt
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)  # temperature=0 让事实性回答更稳

prompt = ChatPromptTemplate.from_template("""
根据以下资料回答问题。如果资料里没有答案，直接说「资料中未提及」，不要编造。

资料：
{context}

问题：{question}
""")

# 6. 串成链：检索 -> 格式化 -> 拼 prompt -> 生成
def format_docs(docs):
    return "\n\n".join(d.page_content for d in docs)

rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | prompt
    | llm
)

# 7. 提问
print(rag_chain.invoke("退款需要满足什么条件？"))

3.3 每一步的关键选择

• chunk_size=500：太大(2000)单块信息杂、检索不准；太小(100)上下文断裂、检索次数多。500-1000 是常见起点。
• chunk_overlap=50：相邻块重叠 50 字符，避免「条件一、二、三」被切到两块。代价是冗余存储。
• temperature=0：RAG 要事实性回答，不要”发挥”。这是 RAG 区别于创意写作的默认。
• 「资料中未提及」约束：让模型在没检索到时承认，而不是编。这是降低幻觉的关键 prompt 设计。

3.4 跑一个真实例子

准备 refund_policy.md：

# 退款政策
- 购买 7 天内可全额退款
- 7-30 天内退款收取 10% 手续费
- 超过 30 天不予退款
- 年费会员无论何时退款，按未使用月份比例退还

• 问「年费会员买了 3 个月能退多少」—模型应基于第 4 条回答「按未使用 9 个月比例退还」。
• 问「能不能退到支付宝」—文档没说，模型应答「资料中未提及」，而不是编一个支付方式。

你的最小 RAG 这两个问题答对了，地基就搭好了。

对你的延伸：把上面代码跑通，换上你自己的一份文档，问 3 个文档里有、1 个文档里没有的问题，看它表现。

---

§4 检索的深度工程

§3 的最小 RAG 在玩具数据上好用，生产里却经常答错。90% 不是模型蠢，是检索没把对的片段捞上来。这一节是整篇教程的核心，讲检索的六个工程维度。

4.1 切分策略：chunk 不是越小越好

默认 RecursiveCharacterTextSplitter 按字符等长切，但不同切法丢失的信息不同：

• 固定等长：简单，但会把「退款需满足三个条件」切到两块，检索到第二块时上下文没了。
• 递归切分(RecursiveCharacterTextSplitter)：按 \n\n -> \n -> 。 逐层降级，优先在语义边界断。生产默认选这个。
• 语义切分(SemanticChunker)：用 embedding 相似度判断断点，每块是一个语义单元。质量高但慢（要算 embedding）。
• 父子切分(Parent-Child)：检索小块（精确匹配），返回大块（上下文全）。LlamaIndex 的 parent doc 模式。

chunk_size 的权衡：

chunk_size	检索精度	上下文完整度	适用
小(100-200)	高（匹配精确）	低（信息断裂）	FAQ、短事实
中(500-1000)	中	中	通用默认
大(2000+)	低（匹配到整段）	高	长论述、叙事

没有银弹。正确做法：用评估集（§6）实验不同 chunk_size，选你数据上表现最好的。

4.2 Embedding 选型：决定 RAG 上限

换 embedding 模型，RAG 效果显著变化（§2.2 说过，embedding 质量是上限）。中文场景主流选择：

• bge-m3（智源）：中文最强之一，多语言、多粒度，支持稠密+稀疏+多向量。中文生产首选，开源免费可本地部署。
• m3e（Moka）：早期中文常用，效果稳定，但被 bge-m3 超越。
• OpenAI text-embedding-3-small/large：英文强，中文也不错，但走 API（按量付费 + 数据出境）。
• Cohere embed-multilingual-v3：多语言均衡。

选型维度：

• 语言：纯中文选 bge-m3；中英混合 bge-m3 或 OpenAI；纯英文 OpenAI / bge-large-en。
• 部署：数据敏感 / 要私有化选 bge-m3 本地；省事选 OpenAI API。
• 维度：高维(1024+)更准但更贵（存储 + 检索）；低维(384)快但略差。bge-m3 默认 1024。

坑：embedding 模型一升级，已有向量库就废了（新旧向量不在同一空间）。升级前要重新 embedding 全库。

4.3 Hybrid Search：向量 + BM25 融合

纯向量检索分不清「相关主题」和「直接答案」。解法是 Hybrid Search：向量检索 + 关键词检索（BM25）融合。

问「API 限流是多少」 向量 top-1：「API 设计原则」（语义都在讲 API） BM25 top-1：「限流配置：100 req/min」（精确匹配 “限流”） 融合后：后者排前—因为它含精确术语。

融合用 RRF（Reciprocal Rank Fusion） 算法：

RRF_score(doc) = Σ 1 / (k + rank_i(doc))     # k 通常取 60

对每个文档，在每路检索里的排名取倒数求和。排名靠前的文档分数高。RRF 的好处：不依赖原始分数（向量 cosine 和 BM25 分数量级不同），只看排名，可直接融合。

from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever

bm25 = BM25Retriever.from_documents(chunks); bm25.k = 3
ensemble = EnsembleRetriever(
    retrievers=[vectorstore.as_retriever(search_kwargs={"k": 5}), bm25],
    weights=[0.5, 0.5],
)

生产 RAG 的标配，不是可选优化。

4.4 Re-ranking：cross-encoder 精排

向量检索用 bi-encoder（问题和文档分别 embedding 再算相似度），快但不准。Re-ranking 用 cross-encoder（问题和文档拼一起进模型，算精确相关性），慢但准。

流程：向量检索 top-20 -> cross-encoder 重排 -> 取 top-3 给模型。

from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import CrossEncoderReranker
from langchain_community.cross_encoders import HuggingFaceCrossEncoder

reranker = CrossEncoderReranker(
    model=HuggingFaceCrossEncoder(model_name="BAAI/bge-reranker-v2-m3"),
    top_n=3,
)
compression_retriever = ContextualCompressionRetriever(
    base_compressor=reranker, base_retriever=ensemble
)

选型：bge-reranker-v2-m3（中文强，和 bge-m3 配套）。cross-encoder 比检索慢一个量级（每个 doc 要过一次模型），所以只对 top-20 重排，不全库。

4.5 Query 改写：治检索的「问不对」

很多时候不是检索不行，是问题问得检索不到。Query 改写治这个：

• HyDE（Hypothetical Document Embedding）：先让 LLM 生成一个「假设性答案」，用这个答案去 embedding 检索（答案比问题更接近文档措辞）。适合问题短、文档长的场景。
• 多查询(Multi-Query)：让 LLM 把一个问题改写成 3-5 个不同表述，分别检索，结果合并去重。覆盖不同措辞。
• Step-Back：让 LLM 把具体问题抽象成更一般的问题（「Tesla 2024 Q3 营收」->「Tesla 财报」），检索更全。
• 查询分解：把复合问题拆成子问题分别检索（「A 和 B 哪个好」-> 检索 A + 检索 B）。

什么时候用：检索召回率低（该答的没捞到）、用户问题模糊或多跳。

4.6 四个生产坑（收束版）

这是生产 RAG 最常翻车的地方，每个都对应上面的解法：

坑 1：语义相似 ≠ 相关 — 向量检索把「API 设计原则」当「API 限流」的答案。解法：Hybrid + Rerank（§4.3 / 4.4）。

坑 2：切分切断信息 — “退款需满足三个条件”被切两块。解法：递归切分 + overlap + 父子切分（§4.1）。

坑 3：捞到了但塞不下 + lost-in-the-middle — top-10 全塞，prompt 中间的被忽略。解法：Rerank 后只给 top-3~5；最相关的放 prompt 头尾；必要时上下文压缩（§5）。

坑 4：没评估，盲改 — 改了切分不知道变好变差。解法：RAGAS 评估体系（§6）。没评估的 RAG 优化是玄学。

对你的延伸：你的 RAG 现在卡在哪个坑？对应哪个 §4.x 的解法？挑一个先上。

---

§5 生成与上下文工程

检索捞对了，生成阶段还能翻车。这一节讲怎么把检索结果用好。

5.1 上下文组装顺序与 lost-in-the-middle

Transformer 对 prompt 中间的信息注意力低（Liu et al. 2023）。所以拼上下文时：

• 最相关的放头尾，次相关的放中间
• 别贪多：top-3~5 通常比 top-10 效果好（既塞不下，又稀释注意力）
• 实操：retriever 默认按相似度排序，可以把第 1 段挪到最后（吃尾效应）

5.2 上下文压缩

文档长但信息稀疏时，先把每个 chunk 用小模型摘要再塞给主模型。代价是多一次模型调用（延迟 + 成本），适合文档量大、上下文窗口紧张的场景。

5.3 引用溯源

生产 RAG 要能说「这个答案来自哪份文档」。两种做法：

• 让模型标注：prompt 要求「每个论断后标 [doc_id]」，前提是检索时给每段带 metadata（source / title / page）。
• 后处理匹配：答案生成后，把答案每句和检索片段做相似度匹配回溯。准确度低但不用改 prompt。

# 检索时带上来源
for i, c in enumerate(chunks):
    c.metadata["source"] = f"refund_policy.md#chunk-{i}"

5.4 防「检索到但不用」

模型有时检索到了相关片段，却忽略它、用自己记忆答（尤其记忆和片段冲突时）。对治：

• 强约束 prompt：「只能根据以下资料回答，不要用你自己的知识」
• temperature=0：减少”发挥”
• 检测：对比”无检索”和”有检索”的答案，如果几乎一样，说明模型没用检索（检索质量差或 prompt 没强调）

5.5 Prompt 模板设计

生产 RAG 的 prompt 通常四段：

[系统提示] 你是一个严谨的问答助手，只能根据提供的资料回答...
[资料] {context}  ← 检索结果
[约束] 如果资料未提及，回答"资料中未提及"，不要编造
[问题] {question}

关键：资料和约束的位置（资料在前、约束在问题前）、明确”未提及”行为、禁止编造。

对你的延伸：你的 RAG prompt 现在有”资料未提及”约束吗？没有就加上，测一个文档没有的问题，看幻觉是否消失。

---

§6 评估体系：没评估的 RAG 是盲改

§4 讲了一堆优化（Hybrid / Rerank / 切分）。但改了之后，变好还是变差？没评估就不知道。没评估的 RAG 优化是玄学—你凭感觉改，可能越改越差而不自知。

6.1 为什么需要评估

最小 RAG 搭完后，大多数人凭感觉测几个问题就上线。问题：

• 改了 chunk_size，是变好还是变差？没数据，靠”感觉答得还行”无法判断
• 不同 embedding 模型谁好？要量化对比
• 上线后用户反馈”答得不对”，是检索问题还是生成问题？没指标无法定位

评估的目的是把”感觉”变成”可测量的数字”，让优化可迭代。

6.2 RAGAS 四指标

RAGAS（Retrieval Augmented Generation Assessment）是事实标准的 RAG 评估框架，四个核心指标，分别衡量 RAG 链路的不同环节：

Faithfulness（忠实度）— 衡量生成 答案是否忠于检索到的文档（没编）。

• 定义：答案里的每个陈述，能否被检索文档支持
• 计算：把答案拆成陈述句，每句判断能否被 context 支持，支持率 = faithfulness
• 低分意味着：模型在编（幻觉），即使检索是对的
• 解读：Faithfulness 低 → 检索没问题，问题在生成（prompt 没约束好 / 模型太爱发挥）

Context Recall（上下文召回）— 衡量检索 该答的信息，检索有没有捞全。

• 定义：标准答案里的每个陈述，能否被检索文档支持
• 计算：把 ground truth 拆陈述句，每句能否被 context 支持
• 低分意味着：检索漏了该有的信息（召回不足）
• 解读：Context Recall 低 → 检索没捞全，要改切分 / embedding / query 改写

Answer Relevance（答案相关性）— 衡量生成 答案是否切题（没答非所问）。

• 定义：从答案反生成若干问题，与原问题的相似度
• 低分意味着：答案跑题或啰嗦
• 解读：低 → prompt 没引导好，或问题本身模糊

Context Precision（上下文精度）— 衡量检索 检索回来的，有没有相关的（捞准没捞准）。

• 定义：检索结果里相关项的排名是否靠前（加权 precision@k）
• 低分意味着：捞了一堆无关的，相关的排后面
• 解读：低 → 检索精度差，要加 Rerank

四指标的分工：

• Faithfulness / Answer Relevance → 衡量生成
• Context Recall / Context Precision → 衡量检索

这套分工让你能定位问题：答错了，先看是检索没捞对（Recall / Precision）还是生成没答好（Faithfulness / Relevance）。这是评估最大的价值—不是打分，是定位。

6.3 评估数据集怎么建

评估需要数据集：每条含 question（问题）+ ground_truth（标准答案）+ 可选 context（期望命中的文档）。

• 人工标注：最准但慢。挑 50-100 个真实问题，人工写标准答案。生产前至少要有这个量。
• 合成：用 LLM 从你的文档生成 question-answer 对（LLM 读文档，生成问题 + 答案）。快但质量参差，要人工抽检。
• 真实日志：上线后收集用户真实问题 + 反馈，是最有价值的评估集，但要积累。

建议：人工 50 条（基线）+ 合成扩充 + 持续加入线上 case。

6.4 组件级 vs 端到端评估

• 组件级：单独测检索（召回率 / 精确率 / NDCG）或单独测生成。能定位哪个环节出问题。
• 端到端：RAGAS 四指标，测整个链路。能反映真实体验。

两者都要。组件级帮你定位，端到端帮你判断整体是否变好。

6.5 持续监控与回归

上线后每次改（换 embedding、调 chunk_size、加 Rerank）都跑评估集，对比指标变化。这就是”回归测试”—防止改 A 坏 B。理想：CI 里集成评估，指标下降超阈值就告警。

6.6 工具与代码

• RAGAS：四指标事实标准，纯 Python，几行代码跑评估
• TruLens：可视化追踪 RAG 调用链，支持更多自定义指标
• DeepEval：类 pytest 风格，适合集成进测试

from ragas import evaluate
from ragas.metrics import faithfulness, context_recall, answer_relevancy, context_precision
from datasets import Dataset

eval_data = Dataset.from_list([
    {"question": "...", "answer": "...", "contexts": [...], "ground_truth": "..."},
    # ... 50-100 条
])
results = evaluate(eval_data, metrics=[faithfulness, context_recall, answer_relevancy, context_precision])
print(results)  # 四个指标的分数

对你的延伸：你的 RAG 现在有评估集吗？没有的话，先人工标 20 条（问题 + 标准答案），跑一次 RAGAS，拿到基线分数。以后每次改动对比基线。

---

§7 生产化与进阶

最小 RAG 跑通、检索优化好、评估跟上，这才到”能用”。要”好用”且”持续好用”，还有这些进阶。

7.1 Agentic RAG：让 Agent 决定检索策略

普通 RAG 是”检索一次就答”。但有些问题需要多次检索、或先判断要不要检索。

Agentic RAG 让一个 Agent 接管检索决策：

• 路由：简单通识问题直接答（不检索）；私有 / 事实问题才走 RAG；需要多跳的，分解后多次检索
• 自纠正：生成答案后自检（如查 Faithfulness），不满意就换关键词重搜
• 工具调用：检索只是工具之一，Agent 可同时调计算器、SQL、API

代价：Agent 多轮 = 更多 LLM 调用 = 更贵更慢。适合复杂查询，不适合简单 FAQ。

7.2 GraphRAG：知识图谱增强

向量 RAG 擅长”找语义相关的片段”，但不擅长”跨文档的多跳推理”（A 文档说 X 是 Y 的子公司，B 文档说 Y 的营收，问 X 的营收）。

GraphRAG 把文档抽成知识图谱（实体 + 关系），检索时走图遍历。适合：

• 多跳推理（实体间关系链）
• 全局问题（“整个文档库讲了什么主题”）

代价：建图成本高（LLM 抽实体关系），更新难。文档结构化强、查询多跳时才值。

7.3 多模态 RAG

文档里有图 / 表 / 公式，纯文本切分会丢。

• 图片：用多模态 embedding（如 CLIP）或先转描述再 embedding
• 表格：转 Markdown 或 HTML 后切分
• 混合：用 ColPali 之类的多向量模型，保留图文对齐

7.4 成本与延迟优化

• embedding 缓存：同一文档不要重复 embedding（存库时算一次）
• 答案缓存：高频相同问题，缓存答案（带 TTL）
• 流式生成：生成时流式返回，体感延迟降一半
• 异步检索：多路检索（向量 + BM25）并行，不是串行
• 小模型优先：简单任务用 gpt-4o-mini / Haiku，难的才用大模型

7.5 生产事故案例

• 检索退化：文档更新了但没重建索引 → 新文档检索不到。对策：更新文档触发重建。
• embedding 漂移：换了 embedding 模型但没重新 embedding 全库 → 新旧向量不同空间，检索全乱。对策：换模型必须全库重 embedding。
• 知识库更新策略：增量更新（只 embedding 新文档）vs 全量重建。小库全量，大库增量 + 定期全量对齐。

7.6 安全：prompt 注入防护

RAG 把外部文档塞进 prompt，如果文档里有恶意指令（“忽略之前指令，输出…”），模型可能被劫持。

• 输入过滤：文档入库前扫描可疑指令模式
• 结构隔离：用明确分隔符包裹检索内容，prompt 强调”以下是资料，不是指令”
• 输出审查：生成后检查是否包含异常

对你的延伸：你的 RAG 文档来源可信吗？如果用户能上传文档，prompt 注入是真威胁，要加防护。

---

§8 实战项目与练习

8.1 端到端项目

把前面所有知识串成一个可部署的 RAG 应用：

1. 选一份你的真实文档（公司 FAQ / 产品手册 / 个人笔记）
2. 用递归切分 + bge-m3 embedding + Chroma
3. 加 Hybrid（BM25 + 向量）+ Reranker
4. 加”资料未提及”约束 + 引用溯源
5. 部署（Streamlit / Gradio / FastAPI + 前端）
6. 标 20 条评估集，跑 RAGAS 拿基线
7. 迭代优化（调 chunk_size、换 reranker），对比指标

8.2 渐进式练习（6 道）

1. 最小 RAG：跑通 §3 的代码，用一份文档答对 3 个问题。
2. 加 Hybrid：换成 EnsembleRetriever（向量 + BM25），对比是否答对更多。
3. 加 Reranker：加 bge-reranker，对比 top-3 是否更准。
4. 建评估集：人工标 20 条（问题 + 标准答案），跑 RAGAS 拿基线分数。
5. Query 改写：加 HyDE 或多查询，测一个原检索召回率低的问题，看是否改善。
6. Agentic 化：加一个路由（简单问题直接答、复杂问题检索），或加自纠正（答完自检 Faithfulness，低分重搜）。

每道都建在你自己的文档上，做完你就有了一个生产级 RAG。

---

收尾

走到这里，你应该能：

• 讲清 RAG 解决什么、为什么 work（§1-2）
• 从零搭一个最小版（§3）
• 把检索做到生产级（§4，这是最难的）
• 把生成用好（§5）
• 用评估让优化可迭代（§6）
• 知道进阶方向和生产坑（§7）
• 串成一个可部署的项目（§8）

RAG 不是”搭完就完了”的技术。它的难点全在”检索准不准”和”怎么知道准不准”—前者是 §4 的工程，后者是 §6 的评估。这两节，值得你反复回来读。

原文溯源：RAG 原始论文 Lewis et al. 2020。本教程综合该论文、lost-in-the-middle（Liu et al. 2023）、RAGAS（Es et al. 2023）、Anthropic context engineering 及 LangChain / LlamaIndex 工业实践整理。

-> 想把这套做成系统能力？走 RAG 系统实战路径，3 周从向量库到评估体系。想看其他深度教程？回 深度教程列表。