当前位置：首页 > news >正文

RAG 入门：检索增强生成是什么，解决什么问题

news 2026/7/6 5:31:28

RAG 入门：检索增强生成是什么，解决什么问题

大模型很聪明，但有两个硬伤：知识过时、不知道你的私有数据。RAG（检索增强生成）就是解决这个问题的——先从知识库检索相关内容，再让大模型基于检索结果回答。这篇讲 RAG 的基本概念、能解决什么问题、整体架构长什么样。

大家好，我是黒漂技术佬。

做企业知识库的时候，一开始想直接把文档喂给大模型，结果发现：

文档太长，塞不下上下文窗口
文档更新了，模型还在用旧知识
私有数据不可能拿去微调模型
回答经常一本正经胡说八道，没法溯源

后来上了 RAG，这些问题基本都解决了。

RAG 是目前落地企业级 AI 应用最主流的方案，简单、可控、成本低。这篇从零讲起，RAG 是什么、为什么需要它、整体架构是怎样的。

一、RAG 是什么？

全称

Retrieval-AugmentedGeneration，检索增强生成。

核心思想

用户提问 → 从知识库检索相关文档 → 把文档+问题一起塞给大模型 → 大模型基于文档回答

不是让大模型凭「记忆」回答，而是先「查资料」再回答。

类比

就像开卷考试：

普通大模型 = 闭卷考试，全靠记忆，容易记错
RAG = 开卷考试，先翻书找相关章节，再组织答案

答案来自你提供的资料，不是模型自己瞎编的。

二、RAG 解决什么问题？

问题 1：大模型知识过时

GPT-4 的训练数据截止到某个时间点，之后的事它不知道。

→ RAG 用最新的知识库回答，知识实时更新。

问题 2：私有数据无法进入模型

企业内部文档、产品手册、客户资料，不可能拿去训练大模型。

→ RAG 检索私有知识库，数据不出企业，安全可控。

问题 3：大模型幻觉（胡说八道）

大模型有时候会编造事实，说得跟真的一样。

→ RAG 的答案基于检索到的文档，可以溯源，有据可查。

问题 4：长文档塞不下上下文

一份手册几百页，大模型上下文窗口装不下。

→ RAG 只检索相关的几段，塞进上下文，精准高效。

问题 5：数据更新成本高

知识变了，微调模型成本高、周期长。

→ RAG 更新知识库就行，分分钟搞定。

三、RAG 的整体架构

两大阶段

阶段一：索引构建（离线）

原始文档 → 文档解析 → 文本分块 → 向量化 → 存入向量数据库

把所有文档处理好，存到向量库里，准备好被检索。

阶段二：检索生成（在线）

用户问题 → 问题向量化 → 向量库检索TopK → 拼接Prompt → 大模型生成答案

用户提问时实时检索、实时生成。

完整流程图

┌───────────────────────────────┐ │ 离线索引阶段 │ │ │ │ PDF/Word/网页/Markdown │ │ ↓ 文档解析 │ │ 纯文本 │ │ ↓ 文本分块 │ │ 文本块（Chunk） │ │ ↓ Embedding 模型 │ │ 向量 + 原文 │ │ ↓ 存储 │ │ 向量数据库（带原文索引） │ └───────────────────────────────┘ ┌───────────────────────────────┐ │ 在线问答阶段 │ │ │ │ 用户问题 │ │ ↓ Embedding │ │ 问题向量 │ │ ↓ 相似度检索 │ │ Top K 相关文本块 │ │ ↓ 拼接 Prompt │ │ 系统提示 + 参考文档 + 问题 │ │ ↓ 大模型 │ │ 带引用的答案 │ └───────────────────────────────┘

四、核心模块拆解

1. 文档加载与解析

支持各种格式：PDF、Word、Markdown、HTML、TXT、PPT……

每种格式有对应的解析工具：

PDF：PyPDF2、pdfplumber、Unstructured
Word：python-docx
HTML：BeautifulSoup
通用：LangChain Document Loaders

2. 文本分块（Chunking）

文档太长，不能整个存。切成一段一段的，叫 Chunk。

分块策略很重要，太大太小都影响效果：

太大：噪声多，上下文占得多
太小：语义不完整，检索不准

常见分块大小：256、512、1024 tokens，根据场景选。

3. 向量化（Embedding）

把文本变成向量（一串数字），语义相近的文本向量距离近。

用 Embedding 模型来转：

开源：bge、m3e、text2vec
闭源：OpenAI text-embedding、通义千问 embedding

4. 向量数据库

专门存向量，支持相似度检索。

常见选型：

轻量：FAISS、Chroma
生产级：Milvus、Pinecone、Weaviate、Qdrant
数据库扩展：PGVector（PostgreSQL插件）

5. 检索器（Retriever）

根据问题向量，从向量库里找最相似的 Top K 个文本块。

最简单的是向量相似度检索，进阶的还有关键词检索混合、重排序等。

6. Prompt 拼接

把检索到的文档和用户问题拼成一个 Prompt：

你是一个客服助手，请根据以下参考资料回答用户问题。 如果资料里没有答案，就说不知道，不要编造。 【参考资料】 1. ... 2. ... 3. ... 【用户问题】 xxx 【回答】

7. 大模型生成

把拼好的 Prompt 发给大模型，拿到答案。

关键是让模型「基于资料回答」「不知道就说不知道」，减少幻觉。

五、最简单的 RAG 长什么样？

用 LangChain 几十行代码就能搭一个：

fromlangchain.vectorstoresimportFAISSfromlangchain.embeddingsimportOpenAIEmbeddingsfromlangchain.chat_modelsimportChatOpenAIfromlangchain.chainsimportRetrievalQA# 1. 加载文档并分块fromlangchain.document_loadersimportTextLoaderfromlangchain.text_splitterimportCharacterTextSplitter loader=TextLoader("knowledge.txt")documents=loader.load()text_splitter=CharacterTextSplitter(chunk_size=500,chunk_overlap=50)texts=text_splitter.split_documents(documents)# 2. 构建向量库embeddings=OpenAIEmbeddings()db=FAISS.from_documents(texts,embeddings)# 3. 创建 RAG 问答链qa=RetrievalQA.from_chain_type(llm=ChatOpenAI(model="gpt-3.5-turbo"),chain_type="stuff",retriever=db.as_retriever(search_kwargs={"k":3}),)# 4. 提问answer=qa.run("产品怎么退货？")print(answer)

基础版就这么简单。但要做到生产级好用，还差得远。

六、RAG 的常见痛点

基础 RAG 很容易搭，但效果往往一般：

1. 检索不准

问的是 A，检索出来的是 B
关键词匹配不上，语义相近但向量距离远

2. 上下文不完整

答案需要跨多个 chunk 才能拼全
分块切开了，检索只拿到一半

3. 大模型不按资料回答

模型还是会自己编
忽略检索内容，用训练知识回答

4. 性能问题

文档多了检索慢
并发高了扛不住

5. 效果评估难

怎么衡量 RAG 系统好不好？
检索准不准？答案对不对？

这些都是生产级 RAG 需要解决的问题，也是这个系列要讲的内容。

七、RAG vs 微调，怎么选？

维度	RAG	微调（Fine-tuning）
知识更新	快，更新文档就行	慢，重新训练
私有数据安全	数据不出本地	需要训练数据
答案溯源	可以引用来源	不能
实现成本	低	高（数据+算力）
回答风格	取决于基础模型	可以定制风格
适合场景	知识库问答、文档检索	风格迁移、任务定制