RAG技术原理深度解析：为什么检索质量决定AI回答上限

RAG 是什么？一句话说清楚

RAG（Retrieval-Augmented Generation，检索增强生成）是目前解决大模型「知识截止」和「幻觉」问题最主流的工程方案。简单说，就是在大模型生成答案之前，先去外部知识库把相关内容捞出来，塞进提示词，让模型「有据可查」地回答。

不用 RAG 的模型就像一个读过很多书但记忆会模糊的人——知识有截止日期，细节可能混淆。用了 RAG 的模型更像一个手边有参考书的人——随时翻，现查现答。

RAG 的核心三步：检索、融合、生成

一个典型的 RAG 流水线分三步走：

Step 1：向量化与索引构建（Indexing）

把你的知识库（文档、PDF、网页、数据库）切成 chunk（通常 256-512 个 token 一段），用 Embedding 模型转成向量，存入向量数据库（Chroma、Pinecone、Qdrant、Weaviate……）。这一步是离线预处理，只做一次。

# 用 LangChain 切分文档并建索引的最简示例
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings

splitter = RecursiveCharacterTextSplitter(chunk_size=512, chunk_overlap=64)
chunks = splitter.split_documents(docs)
vectorstore = Chroma.from_documents(
    chunks,
    embedding=OpenAIEmbeddings(),
    persist_directory="./db"
)

Step 2：语义检索（Retrieval）

用户提问 → 同样的 Embedding 模型把问题转成向量 → 在向量库里做余弦相似度搜索 → 召回 Top-K 个最相关的 chunk。这里有个坑：默认的 Top-K 语义检索只看相似度，对多跳推理（需要跨多个文档片段才能回答的问题）效果很差。

进阶方案：HyDE（先让模型生成假设答案再检索）、MMR（最大边际相关性，避免召回一堆内容高度重复的 chunk）、混合检索（向量 + BM25 关键词双路召回）。

Step 3：生成（Generation）

把检索到的 chunk 和原始问题拼成提示词，交给大模型生成最终回答。提示词工程在这步至关重要——怎么让模型「只根据提供的资料回答」，不要自由发挥，是个需要反复调的问题。

SYSTEM_PROMPT = """
你是一个严谨的知识助手。请只根据以下参考资料回答问题。
如果资料中没有相关信息，请明确说「根据现有资料无法回答」，不要猜测。

参考资料：
{context}
"""

RAG 的核心痛点：召回质量决定上限

RAG 的天花板不在大模型，而在检索。模型再强，召回的 chunk 质量差，答案就一定差。我们在 SFD 内部测试时发现几个高频问题：

chunk 切割不合理：段落中间硬切，把完整的代码块或列表撕裂，语义上下文丢失
Embedding 模型选错：用英文为主训练的 text-embedding-ada 处理中文文档，效果比 BGE-large-zh 差 15-30%
向量库未更新：文档更新了，向量库没同步，模型还在用旧知识回答
Top-K 设太小：K=3 时经常漏掉关键信息，K=10 又让 context 太长噪音多

经验值：中文文档用 BGE-m3 或 text-embedding-3-small，chunk 大小 400-600 token + 64 token 重叠，Top-K 初始设 5，根据问题类型动态调整。

Advanced RAG：不只是简单的 Top-K

2024-2026 年 RAG 领域最大的进步是从「朴素 RAG」升级到「Advanced RAG」，主要包含：

Self-RAG：模型自己判断是否需要检索、检索结果是否有用、最终答案是否有事实支持
Corrective RAG（CRAG）：检索后先评估相关性，低分 chunk 触发网络搜索补充
GraphRAG：微软开源的方案，把文档知识构建成知识图谱，处理复杂多跳问题效果显著提升
Agentic RAG：把检索做成 Agent 工具，让模型自主决定检索策略和次数

我们在 SFD 怎么用 RAG

SFD 实验室的知识库 RAG 已经在内部跑了 3 个月。主要用 Qdrant 做向量存储（本地部署，支持混合检索），Embedding 用 text-embedding-3-small（性价比高，中英文都能用），chunk 策略按文档类型差异化处理：

代码文档：按函数/类切割，保持代码块完整
API 文档：按 endpoint 切割，附带请求示例
内部 wiki：按段落切割，加上元数据（作者、日期、项目）方便过滤

最大的收益是减少了「重复问问题」——以前团队成员总是问同样的配置问题，现在 AI 能直接从内部文档里找到答案，准确率在测试集上达到 87%。

如果你在做 RAG 踩坑，最建议先做的一件事：把你的测试问题集和 ground truth 答案整理出来，用 RAGAS 框架量化评估。盲调参数效率太低，得有数据说话。

SFD编者注：我们目前在测试 GraphRAG 处理跨项目文档查询的效果，后续会出专文分享踩坑记录。RAG 不是银弹，但目前来说是生产级知识问答最靠谱的工程方案。