什么是RAG？如何搭建简单的检索增强生成系统

作者：很酷cat2026.11.03 19:37浏览量：0

简介：RAG（检索增强生成）是在大模型生成回答前，先从外部知识库检索相关内容并注入提示词的架构模式。本文梳理RAG的定义、背景与价值，拆解文档加载、分块、向量化、检索与生成的完整链路，介绍常见分块策略与向量数据库的作用，对比其与长上下文、微调的区别，并附搭建实践要点，助你理解并落地一套简单可用的RAG系统。

rag-">一、RAG是什么：概念定义

RAG（Retrieval-Augmented Generation，检索增强生成）是一种将外部知识检索与大模型文本生成结合起来的应用架构。它的核心思路是：在大语言模型（LLM）回答用户问题之前，先根据问题从外部知识库（文档、手册、网页、数据库等）中检索出若干最相关的内容片段，再把这些片段连同问题一起组装进提示词，交给模型基于这些”参考资料”生成最终回答。

可以从三个视角理解这一定义：

  • 技术视角：一个最小化的RAG系统由检索模块（负责”找到资料”）、生成模块（负责”写出答案”）以及衔接两者的上下文组装环节构成，中间以向量数据库作为知识的存储与检索载体。
  • 业务视角：RAG让企业能把私有知识、领域知识与时效性知识”外挂”到大模型上，随时更新、即查即用，而不必为每类知识重新训练模型。
  • 使用视角：对最终用户而言，RAG表现为一个”先查资料、再作回答”的问答系统，答案有出处、可追溯，可信度更高。

无论底层使用的是云端托管的大模型服务，还是可私有化部署的开源推理模型，RAG的搭建方法都是一致的。因此，”如何基于大模型搭建一个简单的RAG系统”，本质上就是理解并打通下面这条完整链路。

二、为什么需要RAG：背景与价值

面对”让大模型回答其训练知识之外的问题”这一需求，最朴素的做法是把所有可能用到的资料一次性写进提示词发给模型。这种”一股脑全给”的方式在文档规模很小时勉强可用，但随着知识规模增长，会暴露出几类典型问题：

  1. token浪费与成本上升：文档越大，每次请求都要重复传输并计算这些内容，推理成本与响应延迟随之增长，而其中大部分信息与当前问题并无关系。
  2. 冗余信息放大幻觉：当上下文中充斥无关内容时，模型的注意力被稀释，更容易在无关信息之间”脑补”出错误关联，幻觉率随之上升。
  3. Lost in the Middle现象：多项公开研究表明，大模型处理长上下文时，对开头与结尾信息的利用效率明显高于中间部分，位于长文档中部的关键内容可能被忽略。这意味着单纯堆长上下文并不能保证信息被有效利用。
  4. 知识无法及时更新：模型的参数化知识停留在训练截止时刻，新知识要么重新训练，要么依赖提示词注入。

RAG针对这些问题给出的解法是：在需要的时候，只把与当前对话相关的信息交给模型，尽量排除无关信息的干扰。其价值可归纳为：

  • 精准供给：每次只送入少量高相关内容，token开销可控、噪声更少；
  • 知识动态化：知识库可随时增删改，检索即生效，无需重训模型；
  • 可溯源：回答可关联到具体文档分块，便于审核与信任建立；
  • 数据可控：私有资料保存在自己的知识库中，配合权限体系更加安全。

三、核心组成：两个阶段、五个环节

一套典型的RAG系统分为离线（索引）阶段与在线（检索生成）阶段：

  1. 离线阶段：文档加载 → 分块（Chunking）→ 向量化（Embedding）→ 写入向量数据库
  2. 在线阶段：问题向量化 → 相似度检索 → 上下文组装 → 大模型生成回答

3.1 文档加载

将PDF、Word、网页、Markdown等不同格式的资料统一抽取为纯文本。解析质量决定了整个系统的上限：目录、表格、脚注等结构处理不当，会直接污染后续的分块与检索。

3.2 分块（Chunking）

分块是检索的最小单位，也是影响召回质量最直接的环节。常见策略有三种：

  • 递归字符分块：设定块大小上限，先按段落切分；段落超长则退一级按句子切分；句子仍超长再按词切分。通常在相邻块之间保留一定重叠（overlap），避免关键语义恰好被切断。
  • 语义分块：通过计算相邻文本片段的语义相似度，在主题发生明显变化的位置切分，使每个块在语义上尽量自洽。
  • 规则分块：利用文档自身结构切分，如按标题层级、编号条目或特定分隔符。如果文档本身就是按要点罗列的，每个要点就是一个天然分块。

以”按分隔符切分”为例，一个不依赖任何第三方库的通用实现如下：

  1. from pathlib import Path
  2. from typing import List
  4. def load_rag_chunks(doc_path: Path) -> List[str]:
  5.     """读取文档，按全角左方括号「【」切分为 RAG 分片。"""
  6.     text = doc_path.read_text(encoding="utf-8")
  7.     segments = [seg.strip() for seg in text.split("【") if seg.strip()]
  8.     return ["【" + seg for seg in segments]

3.3 向量化（Embedding）

向量化模型负责把文本转换成高维向量。可以把向量直观理解为多维空间中的坐标：语义相近的文本，转换出的坐标彼此接近；语义无关的文本，坐标相距很远。需要注意，文档分块与用户问题必须使用同一个向量化模型编码，二者才处于同一坐标空间，才具备可比性。

3.4 向量数据库

为什么传统数据库难以胜任这个场景？例如用户问”AI是什么”，我们希望检索到的不只是包含”AI”字样的文档，”深度学习””人工智能”这类语义相近的内容也应被召回，这超出了关键词匹配的能力范围。向量数据库专门解决语义近邻检索问题，通常具备：

  • 基于近似最近邻（ANN）算法（如HNSW、IVF等常见索引结构）的Top-K检索，可在海量向量中实现毫秒级响应；
  • 余弦相似度、内积、欧氏距离等相似度度量方式；
  • 元数据过滤能力，可按来源、时间、权限等条件缩小检索范围。

3.5 检索与生成

完整的端到端流程可用如下通用伪代码概括：

  1. # ---- 离线：构建知识库索引 ----
  2. chunks = load_rag_chunks(doc_path)
  3. vectors = [embed(text) for text in chunks]     # 文本向量化模型编码
  4. vector_db.upsert(chunks, vectors)              # 写入向量数据库
  6. # ---- 在线：检索增强问答 ----
  7. def answer(question: str) -> str:
  8.     q_vec = embed(question)                    # 与建库使用同一向量化模型
  9.     hits = vector_db.search(q_vec, top_k=3)    # 检索最相近的若干分块
  10.     context = "\n".join(h.text for h in hits)
  11.     prompt = f"请仅依据以下资料回答问题：\n{context}\n\n问题：{question}"
  12.     return llm.generate(prompt)

四、工作原理：一次请求中发生了什么

以用户提问”AI是什么”为例，完整走一遍在线链路：

  1. 问题向量化：用与建库时相同的向量化模型，把问题编码为向量；
  2. 近邻检索：在向量数据库中查找与该向量距离最近的若干分块，语义上与”人工智能”相关的段落（即使不含”AI”字样）也会被召回；
  3. 上下文组装：将召回分块按相似度排序拼接，与问题一起填入提示词，并通常附带”请仅依据资料回答”的约束指令；
  4. 生成回答：大模型在给定资料的约束下生成答案，减少凭空发挥。

离线链路则是一次性的准备工作：加载、分块、向量化、入库。知识更新时只需对新文档重复该流程，旧内容可按版本管理淘汰。

五、典型应用场景

  • 企业知识库问答：将内部制度、产品手册、FAQ入库，员工或客户以自然语言提问即可获得带出处的回答；
  • 智能客服与售后支持：客服机器人检索产品文档后作答，答案随文档更新而自动更新；
  • 合规与制度查询：在大量条款类文档中快速定位相关条款并生成解释；
  • 研发与运维知识检索：对内部技术文档、故障处理手册做语义检索与问答；
  • 时效性知识场景：新闻、政策等持续更新的内容，通过定期重建索引保持知识新鲜；
  • 代码与领域助手：检索API说明、领域规范后辅助编写或解释。

如果不想从零搭建，主流云平台（如百度智能云）也普遍提供大模型推理、文本向量化与向量数据库等托管能力，可将上述环节以产品化方式接入，降低运维负担。

六、与相关概念的区别

  • RAG vs 长上下文：长上下文的思路是”全量塞入”，RAG的思路是”按需检索”。长上下文受成本随长度增长、Lost in the Middle等约束；RAG上下文精简可控。两者并不互斥，可先用检索缩小范围，再利用较大窗口容纳召回结果。
  • RAG vs 微调：微调改变模型参数，适合塑造回答风格与领域表达能力，但知识内化成本高，更新需重新训练；RAG不动模型参数，知识外挂在数据库中，动态更新。常见组合是：微调解决”怎么答”，RAG提供”答什么”。
  • RAG vs 智能体（Agent）：Agent强调模型自主决定何时调用哪些工具，可多轮规划；经典RAG是固定的”检索→生成”两步流程。可以把RAG看作Agent工具箱中最常用的工具之一。

七、搭建与使用注意事项

  1. 分块大小需要权衡：块过大，单个分块含过多无关信息，召回粒度变粗；块过小，语义碎片化、上下文不完整。可从数百token量级起步，依据检索效果调整，并保留适度重叠。
  2. 向量化模型选型与一致性：文档与问题必须使用同一向量化模型；选型时关注语义区分度、向量维度、推理开销与语言覆盖。
  3. Top-K与相似度阈值：召回过少可能漏掉答案，过多会引入噪声；可在召回后引入重排（Re-ranking）环节，对候选分块二次排序精筛。
  4. 查询理解：用户提问常口语化，检索前可先做问题改写或扩展，也可结合关键词检索做多路召回提升召回率。
  5. 评估闭环：建立测试问题集，从”检索命中率”（找没找对资料）与”回答忠实度”（是否忠于资料）两个维度持续评估，避免只凭主观感受调参。
  6. 权限与数据安全：权限过滤应在检索阶段完成，确保不同用户检索不到越权内容，而非依赖生成阶段”自觉”忽略。
  7. 成本与延迟：离线索引是一次性成本；在线链路每次包含一次向量检索加一次模型生成，需监控端到端延迟与token开销。
  8. 知识库治理：对入库文档做去重、版本管理与过期清理，防止陈旧内容长期污染回答。

八、总结

RAG（检索增强生成）= 检索 + 生成：在大模型回答前，先从外部知识库按语义召回相关内容，再交由模型参考作答。它以”按需供给相关上下文”的方式，缓解了长提示词带来的token浪费、冗余诱发的幻觉与Lost in the Middle问题，同时让知识可随时更新、回答可溯源。搭建一套简单RAG系统只需打通”加载→分块→向量化→存储→检索→生成”六个环节；而走向生产的关键，在于分块策略、召回质量与评估闭环的持续打磨。当需求以”让模型基于既有知识准确作答”为主时，RAG通常是性价比最高的首选方案。

最热文章