RAG 是什么：为什么大模型需要“查资料”？

一、RAG 是什么：为什么大模型需要“查资料”？

在传统的大语言模型（LLM）应用中，模型基于其训练数据生成回答，这带来了几个核心痛点：知识固化（无法获取训练截止日期后的信息）、幻觉问题（一本正经地编造事实），以及领域适配难（对特定企业内部文档一无所知）。检索增强生成（Retrieval-Augmented Generation, RAG） 就是为了解决这些问题而提出的一种架构范式。

它的核心思想非常直观：在生成答案之前，先从一个外部知识库中“检索”出与用户问题最相关的几段文本，然后将这些文本作为“上下文”连同用户问题一起，交给大模型，最后由大模型“阅读”并“参考”这些材料来生成更准确、有据可依的回答。你可以把它想象成：大模型考试时可以开卷查阅参考资料，而不是仅凭记忆作答。

二、RAG 核心工作流程：检索与生成的协奏曲

一个标准的 RAG 系统工作流主要包含两个阶段：离线处理（索引构建） 和 在线处理（检索与生成）。

离线处理阶段：将原始知识库（如PDF、Word文档、网页）进行分块，通过嵌入模型将文本块转换为向量，并存储到向量数据库中。这个过程像是为知识库编排一个语义索引。
在线处理阶段：当用户提问时，系统将问题也转换为向量，在向量数据库中进行相似性检索，找出最相关的K个文本块。然后，将原始问题和检索到的文本块拼接成一个提示词（Prompt），发送给LLM，由其生成最终答案。

提示：分块是关键一步，块太大可能包含无关信息，太小可能丢失上下文。通常使用重叠分块策略，在块之间保留一些重叠文本以保持语义连贯。

三、动手实践：用 LangChain 和 ChromaDB 构建一个简易 RAG 系统

下面我们用 Python 生态中流行的 LangChain 框架和 ChromaDB 向量数据库，来演示一个最基础的 RAG 实现。

首先，安装必要的库：

pip install langchain chromadb tiktoken openai

以下代码演示了核心流程：加载文档、分块、创建向量数据库、检索并生成。

from langchain.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA

# 1. 加载并分块文档
loader = TextLoader("my_knowledge.txt", encoding="utf8")
documents = loader.load()
text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
docs = text_splitter.split_documents(documents)

# 2. 创建向量存储
embeddings = OpenAIEmbeddings() # 使用OpenAI的嵌入模型
vectorstore = Chroma.from_documents(docs, embeddings, persist_directory="./chroma_db")

# 3. 创建检索器与问答链
retriever = vectorstore.as_retriever(search_kwargs={"k": 3}) # 检索最相关的3个块
llm = ChatOpenAI(model_name="gpt-3.5-turbo", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff", # 将检索到的所有文档“塞进”一个提示词
    retriever=retriever,
    return_source_documents=True # 返回引用的源文档
)

# 4. 提问并获取答案
query = "什么是RAG的向量检索？"
result = qa_chain({"query": query})
print("答案：", result["result"])
print("\n参考的源文档片段：")
for doc in result["source_documents"]:
    print(f"- 来自《{doc.metadata['source']}》: {doc.page_content[:100]}...")

四、RAG 的关键组件与优化技巧

一个生产级的 RAG 系统远不止上文那么简单，每个环节都值得深入优化：

嵌入模型：选择高质量的嵌入模型（如 BGE, GTE, text-embedding-3-small）对检索效果至关重要。中文场景可考虑专门的中文嵌入模型。
向量数据库：除了 ChromaDB，还有 Pinecone、Weaviate、Qdrant 等专业选项，它们在大规模数据下性能更优。
检索策略：不仅仅是简单的向量相似度检索。可以结合混合检索（同时考虑关键词BM25和语义相似度）、重排序（用另一个模型对初步检索结果精排）来提升准确率。
提示工程：精心设计给LLM的提示词，明确指示其“仅根据提供的上下文回答问题”，并要求其“如果上下文中没有相关信息，请明确告知”。

提示：当检索结果不理想时，问题可能出在分块不合理或嵌入模型未能捕捉查询意图。尝试调整分块大小，或为文档添加更多元数据（如标题、章节）以辅助检索。

五、从 Naive RAG 到 Advanced RAG：进阶之路

基础 RAG 被称为 Naive RAG，而当前业界正在向 Advanced RAG 发展，其核心是引入更多模块化、自适应的策略：

预检索优化：在检索前对用户查询进行查询转换或查询扩展，使其更清晰、更符合向量检索的语义习惯。例如，让LLM先生成一个独立、明确的查询语句。
检索优化：采用自适应检索，根据问题类型动态决定检索源和检索数量。例如，事实性问题精确检索，总结性问题广泛检索。
后检索优化：对检索到的文档进行压缩、过滤或重排，去除噪音信息，确保输入LLM的上下文最相关、最精炼。
生成优化：引入对话记忆，在多轮对话中结合历史对话和新检索结果进行生成，使对话更连贯。

六、RAG 的挑战与未来展望

尽管 RAG 效果显著，但它也面临一些挑战：检索质量瓶颈（如果检索不到相关文档，生成质量无从谈起）、对长篇文档和复杂逻辑的处理能力有限、以及系统复杂度与延迟增加。

未来，RAG 可能会与模型的长期记忆、工具调用等能力更深度地融合。例如，模型可以自主决定何时需要检索外部知识，检索什么类型的知识（结构化数据、网络实时信息、专业数据库），并将结果用于推理和行动，迈向更自主的智能体（Agent） 架构。

七、总结：RAG 的价值与适用场景

RAG 并非万能，但它极大拓展了大模型的应用边界。它特别适用于需要处理实时信息、私有领域知识以及对回答准确性有高要求的场景，如企业知识库问答、客服机器人、技术文档助手、法律/医疗咨询等。

其核心价值在于：可控性（知识来源可追溯）、经济性（无需频繁微调模型）、时效性（易于更新知识库）。对于开发者而言，理解并掌握 RAG，是构建可靠、可信、可落地的大模型应用的关键一步。