入门 8 分钟RAG

RAG 是什么以及它是如何工作的（指南 初学者）

什么是 RAG？简短地说，它是一套将 LLM 连接到您的文档的系统，让模型依据真实事实回答，而不是编造。详细答案就在本指南中。不涉及数学，也不强制使用任何框架，只介绍基本组件（嵌入、向量数据库、LLM）以及它们如何依次衔接。读完后，您将了解为什么构建得当的 RAG 能大幅减少幻觉，以及如何在本地起步。

作者： Mohamed Meguedmi·更新于 2026-08-27·已在 Windows、macOS 和 Linux 上测试

#30 秒了解 RAG

RAG 是 Retrieval-Augmented Generation 的缩写，即检索增强生成：通过检索来增强文本生成。不是直接向 LLM 说「回答这个问题」，而是先在文档库中查找最相关的段落，再把这些段落放进提示词，并告诉模型：「以下是来源资料，请依据这些资料回答。」

可以用一个贴切的比喻来理解：单独使用的LLM，就像一个聪明的学生在考试时凭记忆作答。RAG则像是同一个学生获准翻阅桌上的课程资料。他会更少编造内容，引用正确的页面；即使给他的是从未见过的课程资料（您的PDF、电子邮件或内部wiki），他仍然能根据这些资料回答问题。

i
一句话总结
RAG = 在大语言模型生成回答前，从您的文档中检索出合适的段落并注入上下文。仅此而已。其余部分都是围绕这两个核心理念展开的工程实现。

#为何（以及何时）需要它

本地 RAG 套件

你的文档，你的 AI：基于你的 PDF、笔记和邮件的可靠本地 RAG——无需向云端发送任何内容。

  • 在线空间，终身可用
  • PDF + 文件
  • 终身更新
本地 RAG 套件 →或 所有套件终身使用权 — 49 € →

一个大语言模型有两个明显缺陷，一旦认真使用就会暴露出来：它在不知道答案时会自行编造（也就是所谓的‘幻觉’），以及它仅知晓训练时所见的数据。Qwen 3.5 9B 从未阅读过您的合同、Notion 知识库或事件记录。直接要求它回答这些内容，就好比要求一个人去想象一本他从未打开过的书里的内容。

RAG 同时解决两个问题：将正确的片段注入提示中，LLM 以此作为事实基础，回答变得可追溯——您可以显示来源。

与您的 PDF 对话
技术文档、合同、科研论文、手册——所有超出上下文窗口承载能力的内容
团队内部助手
Wiki、客服知识库、产品文档。不再只是用 Ctrl+F 粗略查找，而是获得引用正确页面的法语回答。
信息跟踪与综合分析
为数百篇文章或报告建立索引，提出综合性问题，比较不同来源。
近期或私有数据
LLM未见过的内容：您的代码、邮件、以及其截止日期之后的发布内容。
→
当RAG无法提供帮助时
对于纯生成任务（自由写作、头脑风暴、翻译、短代码重构），不带 RAG 的 LLM 已经绰绰有余。不要仅仅因为 RAG 流行就使用它——当您拥有模型不了解的语料库时，它才有用；在此之前无需使用。

#4 步流水线

一个RAG包含两个阶段：索引（预先执行一次）和查询（每次提问时执行）。以下是依次连接的四个核心组件。

  1. 01
    1. 分块 —— 切分文档
    您的PDF、Markdown文件或网页内容首先会被分割成约200至800词的片段（chunks）。无法一次性嵌入整本书，而且我们只想找到准确回答问题的段落，而非整个文档。
  2. 02
    2. 向量嵌入 —— 将文本转换为向量
    每个文本块都会经过嵌入模型，被转换成一个由数字组成的向量（通常为 384 到 1024 维）。讨论同一主题的两个段落会在这个空间中生成彼此接近的向量——这正是实现语义搜索的奥妙所在。
  3. 03
    3. 向量数据库存储
    向量 + 原始文本被存储到一个专用数据库（Chroma、Qdrant、FAISS 等）中，该数据库能够快速回答问题「哪些向量与我的最接近？」。
  4. 04
    4. 检索 + 生成
    针对用户问题，计算其嵌入向量，获取最接近的3到10个片段，将这些片段加入LLM的提示中，并附带指令如‘根据这些摘录回答’，然后由LLM生成最终回答。
完整管道的伪代码
# Phase 1 : INDEXATION (une fois)
for doc in documents:
    chunks = split(doc, taille=500)              # 1. chunking
    for chunk in chunks:
        vector = embedder.embed(chunk)            # 2. embedding
        vector_db.add(vector, chunk)              # 3. stockage

# Phase 2 : INTERROGATION (à chaque question)
question = "Quel est le délai de résiliation ?"
q_vector = embedder.embed(question)               # même modèle qu'à l'indexation
top_chunks = vector_db.search(q_vector, k=5)      # 4a. retrieval

prompt = f"""Réponds en t'appuyant uniquement sur les extraits ci-dessous.

Extraits :
{top_chunks}

Question : {question}"""
reponse = llm.generate(prompt)                    # 4b. génération
i
大语言模型不会‘搜索’——它只会阅读
许多示意图让人以为 LLM 会“查询数据库”。这不对。检索是在调用 LLM 之前完成的。当 LLM 开始处理时，它收到的是一个普通提示词，其中已经插入了检索出的文本片段。从模型的角度看，这只是一次补充了内容的普通对话。

#嵌入向量：检索的核心

嵌入模型是一个专注于单一任务的轻量级 LLM：将一段文本转换为一个由数字组成的向量，用来捕捉文本的“含义”。即使两句话没有任何共同词汇，只要谈论的是同一主题，它们生成的向量就会相近。这正是 RAG 与简单的 Ctrl+F 查找之间的区别。

RAG的最终质量取决于嵌入模型的程度，与取决于背后的LLM的程度相当，甚至往往更高。糟糕的嵌入模型会召回错误的文本片段，即使是世界上最好的LLM，也无法根据偏离主题的文本片段正确作答。

nomic-embed-text
1.37 亿参数，768 维，上下文长度为 8192 个 token。Ollama 提供的一个稳妥的默认选择。英语表现良好，法语表现尚可。
mxbai-embed-large
335M 参数，1024 维。更精确，但耗时为原来的 3 倍。当检索质量成为瓶颈时适用。
multilingual-e5-large
560M，1024维。若您的文档为法语或多语言，此为最佳选择。
bge-m3
法语表现优秀，支持长上下文。运行所需资源更多，但在多语言内容处理方面是标杆。
!
在法语文本上使用英文嵌入的陷阱
在处理法语PDF时，使用法语或英文的嵌入模型会使检索相关性降低1.5到2倍。您将获得与主题略微相关的内容，而非真正匹配的内容。对于法语语料库，建议一开始就使用multilingual-e5-large或bge-m3——额外的延迟可以忽略不计。

#向量数据库：存储向量的地方

向量数据库是一种专门执行特定操作的数据库：“找出与这个向量最接近的 N 个向量”。它在后台使用 HNSW、IVF 等算法，即使面对数百万个向量，也能快速完成检索。入门时，您完全不需要理解这些算法，只需知道该选择哪种向量数据库。

Chroma
开源向量数据库，可嵌入您的 Python 项目，也可作为服务器运行。非常适合入门：零配置，数据可持久化存储到磁盘。
Qdrant
用于生产环境时更稳健：专用服务器、过滤器、多租户支持。一条命令即可让它在 Docker 容器中运行。
FAISS
Facebook（Meta）开发的库。速度很快，但只是一个索引，不提供元数据管理。适合对性能要求严苛的场景。
存储于工具中
Open WebUI、AnythingLLM 和 LM Studio 都内置了各自的向量数据库。处理过程在后台完成——您上传一个 PDF，它就会被建立索引。非常适合无需编写代码就能入门。

#LLM：引导式生成

LLM 是最后的环节。它接收到的提示类似于：‘以下是来自文档的 5 个片段。请仅基于这些片段回答问题。如果信息不在片段中，请明确指出。’

这种方式改变了一切。没有注入上下文时，LLM 会凭训练中学到的知识作答——如果其中存在空缺，就会编造。提示中有了合适的摘录，它便有了可供参考的事实依据，只需改写或归纳即可。

该选多大规模的 LLM？
对于简单的 RAG，2026 年能够装入 8GB 内存的小模型（Qwen 3.5 9B、Granite 4.2 8B）就绰绰有余。检索质量比 LLM 的规模更重要。
上下文窗口是多少？
至少需要 4096 个 token。检索到的文本片段 + 问题 + 系统指令很容易就占用 2000–3000 个 token。上下文窗口达到 8192 个 token 或更多时，就比较宽裕了。
该用什么系统提示词？
类似这样的提示：「你必须用法语回答，仅依据提供的片段内容。若信息缺失，需明确指出。」

#本地 RAG 与云端 API 对比

您可以使用OpenAI或Claude API搭建RAG（部署快速，性能最优），或者完全本地化部署 Ollama + 向量数据库 + 嵌入模型（零数据泄露，零使用成本）。选择取决于文档的敏感程度和您的预算。

通过云 API 实现 RAG
您的文档会在建立索引及每次提问时发送给服务提供商（OpenAI、Anthropic、Mistral 等）。性能和质量一流，但与保密数据的使用要求不相容（GDPR、医疗保密、客户合同）。
RAG 100% 本地运行
Ollama 用于 LLM，nomic 或 bge 用于嵌入向量，Chroma 或 Qdrant 用于向量数据库。任何数据都不会离开这台机器。非常适合专业人士（法律专业人士、医生、人力资源人员）、受 GDPR 约束的企业，以及所有希望保有控制权的人。
混合
本地嵌入向量，LLM 通过 API 调用：限制数据暴露（完整文档保留在本地，仅与问题相关的片段上传至云端）。这是一种务实的折中方案，但如果片段本身敏感，则不推荐使用。
→
本地RAG在低端硬件上可运行
您并不需要 RTX 4090。一台配备 16 GB 内存和较新 CPU 的电脑，就能运行完整的 RAG 系统（Qwen 3.5 9B + nomic-embed-text + Chroma），速度为每秒 5–10 个 token。配备 8 GB 显存的 GPU（RTX 3060、4060）后，速度可达到每秒 30–50 个 token。这完全足以让您与自己的文档对话。

#具体从哪里开始

根据您的使用场景，有三条路径。所有路径均在本地设备上 100% 运行。

  1. 01
    无需编程，通过界面（Open WebUI 或 AnythingLLM）
    您安装 Ollama，在 Docker 中启动 Open WebUI 或 AnythingLLM，将 PDF 上传到“Knowledge Base”，即可开始对话。分块、嵌入、检索——这些操作都会自动为您完成。从开始到结束只需 30 分钟。
  2. 02
    无需编程，采用一体化模式（LM Studio）
    自 0.3 版本起，LM Studio 提供了“Chat with Documents”功能：将文件附加到聊天中，它就会负责处理。限制：每个聊天最多 5 个文件，且支持的格式有限（文本型 PDF、DOCX、TXT、MD）。非常适合偶尔针对某份文档提问。
  3. 03
    在 Python 中使用 LangChain 或 LlamaIndex
    完全掌控：可选择分块器、嵌入模型、数据库、LLM 和提示词。为做出第一个规范的原型预留半天时间；如果还想优化（重排序器、混合检索等），则需要更多时间。
基于 Ollama 的最简本地 RAG 技术栈
# 1. Installer Ollama (https://ollama.com)
# 2. Récupérer un LLM et un modèle d'embeddings
ollama pull qwen3.5:9b
ollama pull nomic-embed-text

# 3. Vérifier que le daemon répond
curl http://localhost:11434/api/tags

# 4. Lancer Open WebUI (interface ChatGPT-like avec RAG intégré)
docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

# Ouvrir http://localhost:3000
# Settings -> Documents -> uploader des PDF
# Dans un chat : taper # pour attacher une Knowledge Base

#初学者常踩的坑

嵌入模型面向英语，文档却是法语
法国 RAG 效果不佳的第一大原因。请检查您的嵌入模型是否支持法语（multilingual-e5, bge-m3）。
分块过大或过小
以 500 个词为一个分块是不错的起点。分块太小（少于 100 个词）会失去上下文；太大（超过 1500 个词）则会让嵌入将所有内容平均化，降低精确度。
更换嵌入模型却不重新建立索引
不同模型的向量不可互操作。从 nomic 切换到 bge 时，必须重新索引所有数据——否则检索结果将完全无意义。
上下文中的分块过多
上下文中的文本块（chunk）超过 8–10 个时，LLM 就开始抓不住重点。5 个高度相关的文本块比 20 个相关性一般的文本块更好（在更进阶的用法中，这正是重排序器发挥作用的地方）。
不显示引用
要验证 RAG 是否真正有效，请为每次回答显示所使用的来源。如果看不到这些来源，您就无法区分好的回答和看似可信的幻觉。

#深入了解

现在您已经了解什么是 RAG，接下来可以通过以下指南开始实践。

使用 Ollama 实现本地 RAG，无需写代码
使用 Open WebUI + AnythingLLM 的分步教程，帮助您在 30 分钟内搭建首个 RAG 系统，即使没有 GPU 也可以。
最佳法语嵌入模型
根据您的语料库，详细对比 nomic、multilingual-e5、bge-m3 和 Solon 的适用性。
本地 RAG：简介
深入讲解概念的指南：分块（chunking）、检索（retrieval）、重排序（reranking）、评估指标。
Ollama 是什么以及它如何工作
如果您尚未安装 Ollama，请参见此处。
这份指南对您有帮助吗？

有反馈、发现了错误，或想补充说明？请告诉我们，让这份指南对每个人都更有帮助。