技术分享2026年9月4日

RAG：让大模型不再胡说八道的「开卷考试」技术

大模型很强，但它会"编"。RAG 要做的，就是给大模型发一本"课本"，让它先查资料再答题。 一、从一个真实场景说起 假设你是一家公司的产品经理。你们有一款 SaaS 产品，服务手册加起来超过 500 页，客服团队每天要回答几百个重复问题。 你想做一个 AI 客服机器人。最直觉的做法是：打开 Cha...

#RAG

大模型很强，但它会"编"。RAG 要做的，就是给大模型发一本"课本"，让它先查资料再答题。

一、从一个真实场景说起

假设你是一家公司的产品经理。你们有一款 SaaS 产品，服务手册加起来超过 500 页，客服团队每天要回答几百个重复问题。

你想做一个 AI 客服机器人。最直觉的做法是：打开 ChatGPT，把那本 500 页的产品手册复制粘贴进去，然后问它问题。

但 500 页显然一次贴不下。你只好挑几页关键内容贴进去，然后问："我们去年卖给某客户的那批企业版设备，保修期是多久？"

ChatGPT 回答得头头是道："根据一般行业惯例，企业版设备通常提供三年保修服务……"

听起来很专业，但问题是：你根本没把完整手册给它看，它也根本不知道你们公司的具体保修政策。 这个"三年"很可能是它从训练数据里"编"出来的。

这就是大模型在企业场景里的三大软肋：

  1. 知识有截止日期：它不知道今年刚发布的产品、上周更新的政策、昨天才写的内部文档。
  2. 没有你的私有数据：它没见过你们公司的手册、合同、邮件、数据库。
  3. 会一本正经地胡说八道：专业术语叫"幻觉"（Hallucination），也就是编出看似合理但实际错误的内容。

那怎么办？

一种办法是"微调"：用你们公司的数据继续训练这个模型。但这很贵、很慢，而且企业数据进入模型权重后还存在安全和合规风险。

另一种办法，就是今天要讲的 RAG。

二、RAG 是什么？一句话讲清楚

RAG，全称 Retrieval-Augmented Generation，中文通常翻译为"检索增强生成"。

一句话概括：

RAG 是一种让大模型在回答问题前，先从外部知识库中检索相关资料，再把资料作为参考上下文，最终生成答案的技术。

说得再通俗一点：

普通大模型是"闭卷考试"，RAG 是"开卷考试"。

闭卷考试时，学生只能凭记忆答题，记错了就会答错。开卷考试时，学生可以先翻书、查资料，再组织答案。

RAG 就是给大模型配了一套"课本"和"检索系统"，让它答题前可以先查书。

三、为什么需要 RAG？三个痛点，三个价值

痛点一：知识会过时

大模型的训练数据有明确的时间边界。比如 GPT-4 的训练数据不会自动更新到昨天的新闻、上个月的政策、今天上午的股价。

RAG 的解法：把最新资料放进知识库，模型回答时直接引用。知识库更新了，模型的回答能力就同步更新，不需要重新训练模型。

痛点二：企业数据进不了通用模型

公司的合同、客户资料、内部流程、实验数据，不可能拿去喂给 OpenAI 的公共模型。这涉及商业机密、隐私合规、数据主权。

RAG 的解法：模型不"学习"这些数据，只"查阅"这些数据。数据仍然保存在你自己的服务器或向量数据库里，大模型每次只是临时读取相关片段。

痛点三：大模型爱"编"

当大模型遇到不会的问题，它不会说"我不知道"，而是会根据语言规律生成一个"看起来很像答案"的回答。

RAG 的解法：回答必须基于检索到的原文。如果资料里没有，就让它明确说"我不知道"，或者至少说明"现有资料无法确认"。

四、RAG 不是微调，也不是简单的"上传文档"

很多刚接触 RAG 的人会把它和"微调"混淆，或者以为 RAG 就是"把文档上传到 ChatGPT"。

这里需要厘清三个概念：

方式本质数据是否进入模型更新速度成本
直接用大模型靠模型预训练知识否慢（取决于模型版本）低
微调（Fine-tuning）用私有数据继续训练模型是，进入模型权重慢，需重新训练高
RAG给模型配一个可检索的知识库否，仅临时引用快，换文档即可中低

微调更像是"把知识刻进脑子里"，适合改变模型的语气、推理习惯或深度专业能力。

RAG更像是"随身带一本笔记"，适合需要频繁引用最新、私有、可溯源资料的场景。

对企业来说，RAG 通常是成本最低、见效最快的方案。

五、RAG 是怎么工作的？一张图讲明白

一个标准的 RAG 系统，可以分为两个大阶段：

阶段一：准备课本（离线）

原始文档
    ↓
加载（Load）—— 读取 PDF、Word、网页、数据库等
    ↓
切分（Chunk）—— 把长文档切成小段
    ↓
嵌入（Embed）—— 把每段文字变成向量
    ↓
存储（Store）—— 存入向量数据库

阶段二：开卷考试（在线）

用户提问
    ↓
嵌入（Embed）—— 把问题也变成向量
    ↓
检索（Retrieve）—— 在向量数据库里找最相关的几个片段
    ↓
生成（Generate）—— 把片段+问题一起交给大模型，生成答案
    ↓
返回答案 + 引用来源

下面详细拆解每一步。

步骤 1：文档加载（Load）

RAG 的第一步，是把各种来源的资料读进来。

常见来源包括：

  • PDF、Word、TXT 等本地文件
  • 公司官网、帮助中心网页
  • 数据库、CRM、知识库系统
  • Markdown 文档、代码注释

这一步本身不复杂，但经常会遇到"脏数据"：PDF 里的表格乱了、网页里有广告和导航栏、扫描版文档是图片不是文字。

所以真实企业项目里，文档清洗往往要占大量时间。

步骤 2：文本切分（Chunk）

大模型一次能处理的文字长度有限，而且向量搜索在小段落上效果更好。所以不能把 500 页手册直接塞进向量库，而是要切成小块。

常见切分策略：

  • 按固定长度切：比如每 500 字一段，两段之间有 100 字重叠。
  • 按段落/句子切：尽量保持语义完整。
  • 按结构切：对 Markdown、代码等保留标题层级或函数边界。

切分是个技术活。切得太短，可能把一句话的关键信息切断；切得太长，搜索精度会下降。

比如下面这段：

"本公司企业版设备保修期为三年，自交付之日起计算。延长保修服务需在购买时单独购买，价格为设备价格的 15%。"

如果把它切成两段，一段只有"保修期为三年"，另一段只有"延长保修需单独购买"，那么当用户问"延长保修多少钱"时，系统可能只检索到前半段，导致答案缺失关键信息。

所以好的切分策略会保留上下文边界，并在相邻块之间设置重叠区（overlap）。

步骤 3：向量化（Embedding）

切分完后，每一段文字都要变成向量。

向量是什么？可以理解为一段高维空间里的"坐标"。语义相近的文字，在这个空间里的距离就近；语义无关的文字，距离就远。

比如：

  • "企业版设备保修期多久？"
  • "公司产品的质保政策是什么？"
  • "如何申请售后维修？"

这三句话意思接近，它们的向量会在高维空间里靠得很近。

而"今天天气怎么样"这句话，就会离它们很远。

Embedding 模型就是做这个工作的。常见选择包括：

  • OpenAI 的 text-embedding-3 系列
  • 开源的 BGE、GTE、E5
  • 中文场景常用的 M3E、BCEmbedding、Qwen-Embedding

选一个好的 Embedding 模型，对 RAG 效果影响很大。

步骤 4：存储到向量数据库

向量生成后，要存进专门的向量数据库。它不仅能存向量，还能根据向量之间的距离快速做相似度搜索。

常见向量数据库：

向量数据库特点
Chroma轻量，适合本地开发和小项目
FAISSMeta 开源，纯本地，性能强
Pinecone托管云服务，企业常用
Weaviate支持混合检索，功能丰富
Milvus / Zilliz国产背景，适合大规模
QdrantRust 实现，性能优秀

对于公众号读者入门，推荐先用 Chroma 或 FAISS，本地跑通整个流程。

步骤 5：检索 + 生成

当用户提问时，RAG 系统会做三件事：

  1. 把用户问题也变成向量；
  2. 在向量数据库里搜索最相似的 K 个文本片段（比如 Top-5）；
  3. 把这 K 个片段连同用户问题一起，塞进大模型的 Prompt 里，让它生成答案。

Prompt 大致长这样：

你是一位专业的知识库助手。请严格根据以下参考资料回答用户问题。
如果资料中没有相关信息，请明确回答"根据现有资料无法确认"。

参考资料：
[片段1] 本公司企业版设备保修期为三年，自交付之日起计算。
[片段2] 延长保修服务需在购买时单独购买，价格为设备价格的 15%。
[片段3] 保修期内非人为损坏可免费维修，人为损坏需收取零部件成本费。

用户问题：企业版设备的延长保修多少钱？

大模型看到这个问题和片段后，会生成类似这样的回答：

根据资料，延长保修服务需在购买时单独购买，价格为设备价格的 15%。

这个回答的优势是：

  • 不依赖模型预训练知识；
  • 基于你提供的资料；
  • 可以追问"出自哪段资料"。

六、一个最小可用的 RAG 代码示例

下面用 Python + LangChain 写一个最简 RAG 系统。假设你有一个 PDF 手册 company_handbook.pdf。

# 安装依赖：
# pip install langchain openai chromadb pypdf

from langchain.document_loaders import PyPDFLoader
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. 加载 PDF 文档
loader = PyPDFLoader("company_handbook.pdf")
documents = loader.load()

# 2. 切分文档
splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,      # 每段约 1000 字
    chunk_overlap=200     # 相邻段重叠 200 字
)
chunks = splitter.split_documents(documents)

# 3. 生成向量并存储到 Chroma
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_documents(chunks, embeddings)

# 4. 创建检索问答链
qa = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(model="gpt-4o"),
    retriever=vectorstore.as_retriever(search_kwargs={"k": 4}),
    return_source_documents=True
)

# 5. 提问
result = qa({"query": "企业版设备的保修期是多久？"})
print("答案：", result["result"])
print("参考来源：", result["source_documents"])

这段代码虽然只有 30 多行，但已经跑通了一个完整 RAG 流程：

  • PyPDFLoader 负责读 PDF；
  • RecursiveCharacterTextSplitter 负责切分；
  • OpenAIEmbeddings 负责把文字向量化；
  • Chroma 负责存向量和检索；
  • RetrievalQA 把检索和生成串起来。

如果是中文文档，建议把 Embedding 换成中文友好的模型，比如 BGE：

from langchain.embeddings import HuggingFaceEmbeddings

embeddings = HuggingFaceEmbeddings(
    model_name="BAAI/bge-large-zh-v1.5"
)

七、RAG 看起来很美好，但实际有不少坑

RAG 入门容易，但要做好很难。常见挑战包括：

1. 检索不到相关内容

用户的问题和文档里的表述方式不同，导致向量搜索找不到正确片段。

例子：

  • 文档里写："企业版设备保修期为三年。"
  • 用户问："我买的高级版机器能保几年？"

"高级版"和"企业版"、"机器"和"设备"、"保几年"和"保修期"语义相关但表述不同，检索可能失败。

解法：

  • 查询重写：让大模型先把用户问题改写成多种同义表达，再分别检索。
  • 混合检索：向量检索 + 关键词检索（BM25）结合使用。
  • Rerank：先用向量检索召回 50 个候选，再用一个排序模型选出最相关的 5 个。

2. 检索到了，但模型不会用

有时候检索到的片段是对的，但模型没有正确整合，甚至把多个片段的信息"脑补"成错误答案。

解法：

  • 在 Prompt 里明确要求"如果资料里没有，就说不知道"；
  • 要求模型在回答中标注引用来源；
  • 对答案做后校验，比如检查答案是否和原文一致。

3. 文档切分切坏信息

表格、代码、列表、FAQ 等结构化内容，如果一刀切，容易破坏语义。

解法：

  • 对表格保留行列结构；
  • 对代码按函数/类切分；
  • 对 FAQ 按"问题-答案对"切分。

4. 上下文太长塞不下

如果检索到很多片段，总长度超过模型上下文限制，就需要取舍。

解法：

  • 只保留 Top-K 最相关片段；
  • 对片段做摘要压缩；
  • 使用支持更长上下文的模型。

5. 多轮对话丢上下文

用户先问"企业版保修多久？"，再问"那延长保修呢？"

第二个问题里的"那"指代的是前面的"企业版保修"。如果系统只把第二个问题单独向量化，可能检索不到正确内容。

解法：

  • 把对话历史一起用于检索；
  • 让模型先把用户问题改写成完整独立的表达。

八、RAG 的典型应用场景

RAG 不是实验室玩具，它已经是当前大模型落地最常见的架构之一。

1. 企业知识库问答

公司内部的手册、制度、产品文档、项目 wiki，做成 RAG 问答机器人。员工不用翻文档，直接问 AI。

2. 智能客服

把产品 FAQ、售后政策、订单规则接入 RAG，替代或辅助人工客服。

3. 法律/医疗文档助手

律师查判例、医生查指南，RAG 可以快速定位相关条款和研究。

4. 代码文档助手

把项目文档、API 说明、代码注释向量化，开发者问"这个函数是干嘛的""怎么调用某个接口"，AI 直接基于项目内部资料回答。

5. 个人笔记助手

把 Notion、Obsidian、印象笔记里的内容接入 RAG，相当于给自己配了一个"第二大脑"。

九、RAG 与几个热门产品的关系

你可能早就用过 RAG 形态的产品，只是没意识到。

  • ChatGPT 的 GPTs + Knowledge：上传文档后，GPT 可以基于文档回答，底层就是 RAG。
  • Perplexity AI：搜索 + 大模型生成答案，是最典型的"搜索增强生成"产品。
  • 微软 Copilot for Microsoft 365：检索企业内部 OneDrive、SharePoint 文档再生成回答。
  • Claude Projects：上传文件后，Claude 会基于文件内容作答。

这些产品让用户不需要懂技术，就能体验到 RAG 的能力。

十、结语：RAG 是大模型落地的"最后一公里"

大模型本身很强，但它像一个"聪明但记忆力有限、还会偶尔编故事的通才"。

RAG 给它配了一本可以随时翻查的"课本"，让它从"闭卷考试"变成"开卷考试"。

它的核心优势可以总结为三点：

  1. 知识可更新：换文档就行，不用重新训练模型。
  2. 数据更安全：私有数据不进入模型权重，留在自己的知识库。
  3. 答案可溯源：回答基于检索到的原文，更容易验证和审计。

对于想用大模型改造业务流程的企业来说，RAG 通常是最快、最便宜的起点。

当然，RAG 也不是万能的。检索不准、切分不好、模型乱编，都是真实存在的问题。但正因为有这些挑战，RAG 才是一个值得深入研究的领域。

返回文章列表