RAG 从 0 到 1 · 第 1 篇
RAG 检索增强生成：从 0 到 1
为什么需要 RAG
大模型的知识被冻结在训练时刻，而且容易一本正经地胡说。RAG（Retrieval-Augmented Generation）的思路很朴素：先查资料，再回答问题。
它把流程拆成两段：
- 检索：从你的私有知识库里找出和问题最相关的片段
- 生成：把这些片段塞进 Prompt，让 LLM 基于它们作答
一句话理解
RAG = 开卷考试。LLM 是考生，向量库是课本，检索器是翻书的手。
整体链路
从用户提问到最终回答，数据依次流经五个环节。
RAG 处理流程 Mermaid
各阶段耗时占比
在一套典型配置下（Top-20 召回 + bge-reranker），实际耗时分布如下。
各阶段平均耗时（ms） ECharts
性能瓶颈
LLM 生成占了 60%+ 的时间。想压延迟，优先换更小的生成模型或做流式输出，而不是优化检索。
召回质量随时间的变化
三种检索策略在不同数据规模下的召回率对比。
召回率对比（%） ECharts
最小可跑示例
用 LangChain + Chroma，十几行就能跑通：
from langchain_chroma import Chroma
from langchain_openai import OpenAIEmbeddings
vectorstore = Chroma(
collection_name="kb",
embedding_function=OpenAIEmbeddings(),
)
retriever = vectorstore.as_retriever(
search_kwargs={"k": 5}
)
docs = retriever.invoke("什么是 RAG")三种检索策略对比
适合语义相近、表达多样的查询。缺点是长尾精确匹配（如错误码、函数名）容易漏。
混合检索，兼顾语义和关键词。实现成本略高，但召回提升明显，是当前主流方案。
两阶段检索：先召回 Top-50，再用 cross-encoder 精排。效果最好，但延迟增加 200–400ms。
常见坑
chunk 切分太大
chunk 超过 1000 token 后，语义会被稀释，检索精度掉得很快。建议 256–512 token，并保留 10–20% overlap。
只做向量检索，不做 rerank
向量召回 Top-1 经常不准。加一层 rerank 后，Top-1 命中率通常能从 55% 提升到 80%+。
把整个文档塞进上下文
token 爆炸，成本飙升，而且模型会「迷失在中间」。只塞最相关的 3–5 个片段即可。
演进时间线
2023 Q1
朴素 RAG
单路向量检索 + Prompt 拼接，召回率约 60%
2023 Q4
加入 Rerank
两阶段检索，召回率提升到 82%
2024 Q2
Hybrid Search
向量 + BM25 混合，长尾查询明显改善
2025 Q1
Agentic RAG
让模型自己决定检索几次、检索什么
召回能力雷达
三种策略能力对比 ECharts
知识图谱
知识图谱 可拖拽
相关概念
检索决定下限，重排决定上限，生成决定体验。