RAG是什么?面向初学者的工作原理与用途详解

“想让ChatGPT参考公司手册回答问题”“想检索并总结新论文”——这些任务可能需要模型已学知识之外的资料。可以在回答时把相关材料提供给模型。

其中一种方法是RAG (Retrieval-Augmented Generation/检索增强生成)。它从外部资料中检索相关信息,加入模型回答时使用的上下文。现成的AI功能也能参考文档,但上传文件并不意味着所有功能都使用相同的检索流程。

本文将用3个步骤图解RAG的工作原理,从向量数据库、LangChain实现到与微调的区别,面向初学者讲清楚,但同时保持技术层面的准确性。

1. RAG是什么——Retrieval-Augmented Generation

RAG(Retrieval-Augmented Generation) 直译就是“用检索(Retrieval)增强(Augmented)的生成(Generation)”。中文里通常译为“检索增强生成”。

一句话概括,RAG是让LLM (大语言模型)在生成回答时参考从外部检索到的相关信息的机制。本文图示介绍先检索、再回答的基本形式。检索来源也可以是现有数据库或关键词搜索,并非必须使用独立的向量数据库。

用做菜来类比

单独的LLM就像是“靠记忆做饭的厨师”。手艺虽好,但不知道的菜谱做不出来,也不清楚冰箱里有什么。

RAG则相当于“给厨师一本菜谱,再告诉他冰箱里有什么食材,然后让他做菜”。厨师可以一边翻菜谱,一边用现有食材做出最合适的菜。

“Retrieval”、“Augmented”、“Generation”各自的角色

关键不是重新训练LLM,而是每次提问时从外部提供所需的信息。这与下文的微调不同。

LangChain的检索指南介绍了这一基本形式,以及如何使用现有SQL数据库或文档系统作为检索来源。

2. 为什么需要RAG——LLM自身的3个局限

仅靠ChatGPT、Claude这样的LLM,有3个问题难以解决。

局限1:知识截止(信息时效性)

仅靠模型已学到的知识,无法核实训练后发生变化的信息。知识截止日期因模型而异,之后的事件需要通过资料或检索结果核实。

• “讲讲昨天发布的新产品” → 核实发布资料
• “上周更新的使用条款有哪些变化” → 核实新条款
• “今天的汇率是多少” → 核实带时间标记的数据

RAG可以使用从新闻、数据库或API获取的信息,但旧资料仍可能导致旧答案。需要更新资料并检查检索结果。

局限2:幻觉(看似合理的胡编)

LLM被问到不知道的事情时,常常会编出看起来很可信的答案。这就是所谓的幻觉(hallucination)。

例如,未提供公司私有规则时询问休假天数,模型可能编造一个看似合理的数字。这只是说明机制的例子,并非本文实际运行或观察到的回答。

RAG检索实际资料,帮助回答建立在依据之上。保留来源元数据后,可以显示文档名或页码。但显示引用不代表答案正确,仍可能漏检资料或误读内容。

局限3:无法访问公司内部数据与私有数据

不能假定公开模型知道公司的私有手册或合同。提供资料之前,也要核实使用权限和数据发送对象。

RAG用于选择相关资料交给模型,它本身不保证机密保护。即使数据库在公司内部,外部嵌入API或LLM API仍会接收资料、问题或检索片段。请核实检索阶段的用户权限、发送对象、保存与日志条件,具体区别见常见问题。

3. 工作原理——3步运转的RAG

RAG的运行可以分为“预处理(建索引)”和“运行时(问答)”两个阶段。

预处理阶段——把文档向量化并保存

1. 收集文档:PDF、Word、HTML、Markdown等,把要用到的文档收集起来
2. 分块切分:把文档切成合适的长度(如500~1000字)
3. 嵌入(Embedding):用嵌入模型(如OpenAI text-embedding-3-small)把每个分块转成1536维等的向量(数值数组)
4. 存入向量数据库:把分块和对应的向量存进专用的向量库(Pinecone、Qdrant等)

这一步在文档新增或更新时执行。

运行时阶段——回答问题的3个步骤

用户提问到来时,处理流程如下。

1. Step 1: Retrieval(检索)
   • 用同一个嵌入模型把问题文本向量化
   • 在向量数据库中获取与问题相关的Top-K个分块 (本例为3个)
   • 相似度计算常用cosine similarity(余弦相似度)
2. Step 2: Augmented(增强)
   • 把取出的分块作为“参考信息”嵌入提示词
   • 形如:“请基于以下信息回答问题:[检索结果] 问题:[用户提问]”
3. Step 3: Generation(生成)
   • 由LLM(GPT、Claude、Gemini等)基于参考信息生成回答
   • 必要时附带“参考了哪份文档”的引用

具体例子:在ChatGPT里查询公司员工手册

以下天数、工龄和条文编号属于用于解释机制的虚构公司规则,并不表示实际的休假制度。

“年假有几天?”的处理流程:

1. 问题被嵌入模型转成向量 → [0.12, -0.45, 0.78, ...]
2. 从向量库中取出与“假期”、“年假”相关的3个分块
3. 取出的分块如:“第15条 年休假:入职满6个月的员工享有10天...”、“根据工龄最多20天...”等
4. 组装提示词:“参考信息:第15条... 问题:年假有几天?”
5. LLM回答:“入职6个月起10天,根据工龄最多20天(参见员工手册第15条)”

4. RAG的核心组件

下面看构成RAG的5大组件。

① 嵌入模型(Embedding Model)

把文本转换成数值向量的AI模型。训练目标是让语义相近的文本在向量空间中靠近;实际检索效果仍需评估。

OpenAI模型的默认维度和缩短方式见官方嵌入指南。比较候选模型时,应评估自有资料的检索结果,而非只看维度。

② 向量数据库

用于保存向量并检索相似向量的数据库或扩展,下一节详细介绍。

③ 检索引擎(Retriever)

除了向量检索,常常还会结合关键词检索(如BM25)或混合检索一起使用。

④ LLM(生成端)

负责生成最终回答的大语言模型。GPT、Claude、Gemini、Llama等。商用API或开源本地模型都能跑。这些系列的版本都在不断更替,当前具体的模型名请查看主要AI模型一览。

⑤ 提示词模板

把检索结果和用户提问拼起来交给LLM的模板。它对RAG的精度有举足轻重的影响。

你是一名熟悉公司规章的助手。
请仅根据以下参考信息回答问题。
若参考信息中没有答案，请回答"暂无相关信息"。

【参考信息】
{retrieved_chunks}

【问题】
{user_question}

【回答】

5. 什么是向量数据库

向量数据库提供存储高维向量和检索相似向量的索引与功能。可以使用专门服务,也可以通过pgvector等扩展现有PostgreSQL。速度和精度取决于索引、数据量和设置。

主流向量数据库对比

该选哪个

Pinecone和Weaviate价格于2026年10月9日依据官方价目表核实。免费软件仍需服务器和维护资源;云端总价会因容量、查询量、额外AI功能和备份等变化。

• 用Python试验检索: Chroma等,需准备包和模型
• 已有PostgreSQL: pgvector可统一数据库管理
• 让服务方管理基础设施: Pinecone等托管服务,仍需配置索引、容量与权限
• 自行托管: Qdrant、Weaviate等,自行管理运维与权限
• 资料量较大: 把Milvus等列为候选,用实际数据评估索引、容量和检索性能

顺便一提,如果你在为部署位置犯愁,可以参考 PaaS(Vercel等)与共享主机、VPS、云的对比。

6. 主要用途——RAG用在哪里

RAG可以用于参考公司文档、商品信息等资料作答的系统。以下介绍可能的用途。

用途1:公司内部文档QA(知识库)

检索员工手册、业务手册、技术规格、会议纪要和销售资料,作为回答员工问题的参考。需要按用户区分可访问的资料,并把文档变化反映到索引中。

用途2:客服自动化

把FAQ与历史工单做成RAG,由聊天机器人完成一线响应。人工客服可以集中处理复杂问题。

用途3:法律、医疗等专业问答

检索判例、医学论文和指南,整理供专业人员核实的参考信息。需要显示来源,并由人核实资料的适用条件和回答内容。有引用不代表判断正确或安全。

用途4:研究论文检索与摘要

检索获准使用的论文或摘要,为研究趋势或相关方法的问题提供参考。应标明取得资料的范围与发布日期,并到原文核实结果和研究条件。

用途5:电商网站的商品检索与FAQ

把商品手册、评论、退换政策等整合成RAG。“这款吸尘器对宠物毛发友好吗?”这样的自然语言检索就能跑通。

用途6:面向开发者的文档对话

检索软件库的官方文档,回答“这项操作有示例代码吗”等问题。把目标版本加入检索条件,避免混用不兼容的文档。

用途7:公司代码库的检索与解释

检索代码和设计资料,辅助回答函数用法或类似逻辑所在文件的问题。GitHub Copilot Chat与Cursor、Claude Code等开发AI也能受益于代码参考,但各产品内部处理不一定与本文图示相同。

用途8: llms.txt等资料导航

llms.txt是用文本提供网站资料导航的提案。它可为搜索和资料收集提供线索,但不保证AI会读取或正确引用。

7. RAG vs 微调——该如何选择

“让LLM拥有专属知识”的方法中,与RAG并列被反复讨论的是 微调(Fine-tuning)。两者的思路从根本上就不同。

根本差异

RAG适合的场景

• 知识更新频繁(新闻、内部文档、商品信息)
• 必须标注回答依据(法律、医疗、金融)
• 不同问题需要不同资料,想评估检索相关片段,而非每次传入全文
• 希望无需再训练模型,就试作参考资料回答的系统

微调适合的场景

• 想让回答带特定文体或语气(企业品牌、人设)
• 想让模型掌握专业领域的语言风格(医学、法律措辞)
• 想评估缩短提示词或换用较小模型的节省,同时计入训练费用
• 能够准备期望回答的训练示例和独立评估数据

微调的提供条件因服务而异。2026年10月9日核实的OpenAI官方资料说明,微调不向新用户提供。请先核实支持的模型和合同条件。

必要时组合使用并评估

RAG可以与微调组合,例如用追加训练调整回答格式,用检索提供更新资料。但组合不保证质量一定提高。

先确定期望回答与评估方法,再试验改善指令或添加资料是否足够。需要参考资料时考虑RAG,需要调整输出倾向时考虑微调。用实际输入比较费用、速度与质量。OpenAI的优化指南也从评估和改善指令开始,再针对合适用途考虑微调。微调后的模型能否本地运行,取决于权重发布、许可证和运行环境。

8. 自己搭建之前——先用手头的资料试一试

在自己搭建 RAG 之前,先用手头的资料确认“先检索再回答”这种形式到底有没有用,可以少走弯路。多数情况下,第一步的确认不用写代码就能完成。

步骤1: 估算能否传入全部资料

资料整体能放入所用模型的上下文时,也可以不检索而直接传入。Anthropic在2024年的Contextual Retrieval说明中,介绍了将少于20万token (约500页)的资料整体加入提示词,并使用提示词缓存的做法 (官方说明)。20万token不是所有模型共用的门槛,应按当前输入上限、资料长度、回答质量与费用判断。

步骤2:把资料放进现成的“项目”功能里提问

Claude 的 Projects 在资料接近上下文上限时,会自动切换为 RAG,最多可容纳 10 倍的内容。这是付费方案的功能,切换后界面上会有提示,回答时会使用“project knowledge search”工具(Claude 帮助中心)。ChatGPT 的 Projects 同样可以放入文件并提问,文件数量等上限按方案而定。

步骤3:用 10 个已知答案的问题来检验

准备 10 个你知道答案在资料哪里的问题,记录以下 3 点。

1. 答案是否正确
2. 作为依据给出的出处是否对得上
3. 问资料里没有的内容时,是否会回答“资料中没有”

第3项出现编造时,重新指示“资料里没有就说没有”后再测。10个问题只是初次试验,即使多数正确也不证明生产适用性或安全性。应增加重要问题、相似资料、矛盾和访问权限等测试条件。

步骤4: 需要更多控制时,比较自建与托管方案

作为检索改善的例子,Anthropic报告称,Contextual Embeddings与Contextual BM25组合使前20个分块的检索失败率降低49%,结合重排序后降低67% (该公司的实验条件和结果)。这是在厂商评估数据上进行的检索测量,不保证自有系统的回答错误会按同样比例减少。

最小自建示例见下一节;混合检索和重排序等生产改进见RAG与向量数据库实现指南。

9. 实现方法——用LangChain搭建RAG

先介绍主流的RAG实现框架,再给出Python的最小示例代码。

主流框架

用LangChain写一个最小的RAG

这是检索PDF相关片段并交给模型回答的学习示例。LangChain 1.x需要Python 3.10或以上。把API密钥设置在环境变量OPENAI_API_KEY中,并准备能访问所用OpenAI API模型的环境。不要把密钥写进代码或公开仓库。

本例把PDF文本和问题发送到嵌入API,把检索结果和问题发送到LLM API。即使Chroma在本地运行,也不代表全程本地处理。API的收费与条件需与ChatGPT订阅分别核实,请使用获准发送的非机密资料。此代码为未验证运行的学习用示例。动手运行前,请对照所用库版本的官方写法进行核对。

# pip install -U langchain-openai langchain-chroma langchain-text-splitters langchain-community pypdf
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_chroma import Chroma

# 1. 加载文档
loader = PyPDFLoader("handbook.pdf")
docs = loader.load()

# 2. 分块切分
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500, chunk_overlap=50
)
chunks = splitter.split_documents(docs)

# 3. 嵌入 + 构建向量库
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(chunks, embeddings)
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

# 4. 检索（取与问题最接近的3个分块）
question = "年假有几天？"
found = retriever.invoke(question)
context = "\n\n".join(d.page_content for d in found)

# 5. 传入依据并生成回答
llm = ChatOpenAI(model="gpt-6-luna")
answer = llm.invoke([
    {"role": "system", "content": "只根据下面的资料回答。资料里没有的，就回答“资料中没有”。\n\n" + context},
    {"role": "user", "content": question},
])
print(answer.content)
print("引用源:", [d.metadata for d in found])

本例的设计是检索PDF相关片段,再把参考信息交给GPT-6 Luna回答,最后输出取得文档的元数据。页码等信息取决于原资料与加载器,回答中的引用是否正确仍需单独核实。

gpt-6-luna是2026年10月9日在官方模型页面核实的ID。使用前请在官方模型列表核实支持的API、使用条件和价格。用相同资料和问题比较依据理解、回答质量、速度与费用。

代码采用LangChain 1.x的包结构。LangChain 1.0把旧示例中的langchain.chains (包括RetrievalQA)移入独立的langchain-classic包。本例从langchain_text_splitters导入切分功能,把官方的“2-Step RAG”写成先检索、再传入依据生成回答的两步。导入路径和Python要求见官方迁移指南。实现时应记录包版本,并在可复现环境中验证。

面向生产环境的扩展

• 分块切分的优化(语义切分、层级切分等)
• 混合检索(向量 + 关键词BM25组合)
• 重排(rerank)(用Cohere Rerank、voyage-rerank等对检索结果重新排序)
• 查询改写(HyDE、Multi-Query等提升检索精度)
• 评估管线(用RAGAS做自动评估)

10. RAG的挑战与对策

实际运行RAG时,应检查以下方面。

挑战1:分块切分的难题

如何切分文档,会显著影响检索精度。切得太短上下文会丢,切得太长检索精度又会下降。

对策:

• 语义切分(按意义单元切)
• 设置重叠(让相邻分块部分重合)
• 层级切分(父子结构存储,检索用子,引用用父)

挑战2:Retrieval(检索)精度

会取到看似相关其实不同的分块、漏掉重要信息等。

对策:

• 混合检索(向量 + BM25关键词)
• 用重排模型在检索后重新排序
• 多查询生成(用不同表述对同一问题检索)

挑战3:上下文长度限制

能传给LLM的token数有上限,无法塞入大量分块。

对策:

• 限制K值(取Top 3~5)
• 先做摘要再传入
• 使用长上下文LLM(上限因模型而异,如今已有百万token级的模型;所用模型的上限请以官方文档为准)

挑战4:评估困难

RAG回答的质量很难客观度量,标注数据怎么做也是难题。

对策:

• 使用 RAGAS(专门做RAG评估的开源框架)
• 自动计算回答正确性、回答相关性、检索忠实度等指标
• LLM-as-a-Judge(用另一个LLM打分)

挑战5:多语言与多模态

中英文混排的文档、含图PDF、表格图表等都不好处理。

对策:

• 多语言嵌入模型(BGE-M3、Cohere Multilingual)
• 把图像与表格预先用LLM转成文本(OCR + VLM)
• 多模态嵌入(CLIP、Nomic等)

11. 主要工具与服务一览

下面把构建RAG常用的工具按类别汇总。

框架与库

• LangChain ——集成检索、模型与数据来源
• LlamaIndex——专注数据接入
• Haystack——面向企业
• DSPy——提示词自动优化

向量数据库(托管)

• Pinecone ——托管的向量检索服务
• Weaviate Cloud——支持GraphQL
• Qdrant Cloud ——Qdrant的托管服务
• Zilliz Cloud——Milvus的托管版

向量数据库(开源 · 自托管)

• Chroma ——可从Python使用的向量检索
• Qdrant ——向量检索与过滤
• Weaviate——开源版
• Milvus ——向量数据库
• pgvector——PostgreSQL扩展

嵌入模型

• OpenAI text-embedding-3 ——通过API生成嵌入
• Voyage AI——Anthropic 文档中有介绍
• Cohere Embed——多语言
• BGE-M3 ——支持多语言的本地运行候选

无代码 / 托管RAG服务

• ChatGPT Projects / 既有Custom GPTs ——参考资料的现成功能,需分别核实处理方式与条件
• Claude Projects——Anthropic的RAG功能
• Notion AI——Notion内文档检索
• Microsoft Copilot (Microsoft 365) ——参考内部资料的候选,需核实合同、连接和权限
• Dify——开源的无代码AI构建平台
• Vertex AI Agent Builder——Google Cloud的RAG构建服务
• Amazon Bedrock Knowledge Bases——AWS的托管RAG

评估工具

• RAGAS——开源RAG评估框架
• TruLens——综合评估LLM应用
• LangSmith——LangChain官方的追踪与评估工具

想深入了解微调,可一并阅读什么是微调:它面向初学者讲解微调与 RAG 的取舍以及 LoRA/QLoRA 等方法。

常见问题

2026年10月9日已依据官方资料复核价格、产品提供条件和API数据处理的说明。本文未验证代码和API执行、实际收费或真实环境的机密保护。实现前请核实各服务的最新条件。