为什么我们需要 RAG？ - 代码学习笔记

一、为什么我们需要 RAG？

在接触 RAG（Retrieval-Augmented Generation）之前，我们通常直接使用大语言模型（LLM）进行对话。这种方式简单直接，但存在一个显著的瓶颈：知识滞后与幻觉。模型的内部知识源于其训练数据，它无法知晓训练截止日期之后发生的任何事，也无法访问你公司内部私有的、实时更新的数据库。当被问及这些问题时，它要么坦诚“不知道”，要么更糟糕地——基于其模式匹配能力，“自信地编造”一个看似合理但完全错误的答案，这就是所谓的“幻觉”。

RAG 正是为解决这一核心矛盾而生的。它的核心思想非常巧妙：既然模型本身的知识不可靠，那我们就给它配一个可靠的、可随时更新的“外部大脑”——检索器。在回答问题前，先由检索器从外部知识库（如最新的文档、网站、数据库）中查找最相关的资料，然后将这些资料连同用户的问题一起“喂”给模型，让它基于这些新鲜、准确的资料来生成答案。这就像是给一个博学的教授配备了一个专业的图书管理员，教授的回答将建立在管理员提供的最新、最准确的文献基础上，从而大大降低了胡说八道的风险。

二、RAG 的核心原理剖析

RAG 的架构可以清晰地拆解为两个核心组件：检索器 与 生成器，它们协同工作，形成一个“先查后答”的流水线。

检索器 的任务是根据用户的问题，从庞大的外部知识库中快速找到最相关的一小段文本。这通常通过向量检索技术实现。首先，使用一个嵌入模型（如 text-embedding-ada-002）将知识库中的所有文档切块并转换为数字向量（Embeddings），这些向量捕捉了文本的语义信息。当用户提出问题时，同样将问题转换为向量，然后在向量空间中通过余弦相似度等算法，找到与问题向量最“接近”的文档块向量。这些对应的文档块就是检索出的相关上下文。

生成器 就是大语言模型本身，它接收两个输入：用户原始的 Query（查询） 和检索器返回的 Context（上下文）。在精心设计的提示词模板引导下，模型被要求“仅基于以下提供的上下文来回答问题”。通过这种方式，模型的“创造力”被约束在了事实依据的范围内，其输出便具备了准确性、时效性和可溯源性。

三、RAG 的典型工作流程

一个完整的 RAG 应用，从搭建到运行，通常遵循以下步骤，它是一个端到端的数据处理与问答流程：

知识库构建（离线）：这是基础。你需要收集并准备好所有希望模型能参考的文档（PDF、网页、Markdown、数据库记录等）。
文档切分与向量化：长文档需要被智能地切割成较小的、语义连贯的文本块。然后使用嵌入模型将每个文本块转换为向量，存入向量数据库（如 FAISS, Chroma, Pinecone 等）中，构建起可检索的索引。
用户查询处理（在线）：当用户提出一个问题时，系统将其向量化。
检索：在向量数据库中执行相似性搜索，获取 Top-K 个最相关的文本块。
增强生成：将检索到的文本块作为上下文，与用户问题一起填入提示词模板，发送给 LLM。
答案返回：LLM 生成最终答案，返回给用户。

提示：文档切分（Chunking）是 RAG 效果的关键。切块太大，可能包含太多无关信息干扰模型；切块太小，又可能丢失必要的上下文连贯性。实践中通常需要根据数据类型反复试验，找到最佳切分策略（如固定长度切分、按语义切分）。

四、动手实践：用 LangChain 构建简易 RAG

理论说再多，不如亲手一试。下面我们用 Python 和流行的 LangChain 框架，构建一个最简单的本地 RAG 问答系统。假设我们有一个关于公司产品的 knowledge.txt 文本文件。

首先，安装必要的库：pip install langchain langchain-community langchain-openai faiss-cpu

from langchain_community.document_loaders import TextLoader
from langchain.text_splitter import CharacterTextSplitter
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.chains import RetrievalQA

# 1. 加载并切分文档
loader = TextLoader('knowledge.txt', encoding='utf-8')
documents = loader.load()
text_splitter = CharacterTextSplitter(chunk_size=500, chunk_overlap=50)
docs = text_splitter.split_documents(documents)

# 2. 创建向量存储（以 FAISS 为例）
embeddings = OpenAIEmbeddings() # 需要设置 OPENAI_API_KEY 环境变量
vectorstore = FAISS.from_documents(docs, embeddings)

# 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, retriever=retriever)

# 4. 开始提问
query = "我们的产品支持哪些支付方式？"
result = qa_chain.invoke({"query": query})
print(result['result'])

这段代码清晰地展示了上述流程：加载文档 -> 切分 -> 向量化存储 -> 创建检索QA链 -> 查询并生成回答。你会看到，模型的回答是基于你的 knowledge.txt 文件内容生成的，而不是它的通用知识。

五、优化与进阶思考

一个生产级的 RAG 系统远不止于此，需要从多个维度进行优化：

检索质量优化：
混合检索：结合关键词检索（如 BM25）和向量检索。关键词擅长精确匹配术语，语义检索擅长理解同义表述。两者结合可以召回更全面的结果。
重排序：使用一个更精细的模型（如 CohereRerank）对初次检索出的结果进行重新排序，将最相关的结果排到前面。
查询改写：利用 LLM 将用户模糊的、口语化的问题，改写成更精确、更适合检索的句子。

生成过程优化：
提示词工程：精心设计提示词，明确指示模型如何使用上下文，何时应该承认“根据提供的资料，我无法找到相关信息”。
结果溯源：在回答中明确指出答案来源于哪份文档的哪个章节，增强可信度和可调试性。

系统架构优化：
增量索引：当知识库更新时，能够高效地新增或删除文档索引，而不是每次全量重建。
缓存：对高频、相同的问题及其答案进行缓存，提升响应速度并降低成本。

关键提示：RAG 的效果极度依赖于“检索”环节的质量。如果检索器没能找到正确的文档，再强的 LLM 也无法给出正确答案。因此，评估和优化检索的召回率与准确率，通常是构建 RAG 系统中投入精力最大的部分。

六、总结与展望

RAG 是一项极具实践价值的技术，它将大模型的语言理解与生成能力，同外部知识库的准确性与时效性完美结合，有效缓解了幻觉问题，并让模型能够处理私有、实时的专有数据。它更像是为大模型安装了一个可动态更新的“知识扩展坞”。

从学习角度，理解 RAG 是你深入应用大模型的一把关键钥匙。它涵盖了文本嵌入、向量数据库、提示工程、链式调用等大模型应用开发的核心概念。随着技术的发展，RAG 本身也在进化，例如出现了多模态 RAG（检索图像、表格）、图 RAG（基于知识图谱）等变体。掌握其基本原理，你便拥有了理解和构建未来更复杂智能应用的基础。