LLM 虽有强大文本生成能力,但受限于训练数据,知识是静态的,无法包含实时或专有数据,导致响应可能过时、不准确或缺乏特定场景所需的上下文。RAG(Retrieval-Augmented Generation)模式通过连接 LLM 与外部知识源来解决这一问题。
核心思想:先检索,再生成 —— 收到查询后,先从知识库检索相关片段,附加到提示中,让 LLM 从"闭卷"变为"开卷"推理。
RAG 基本流程
用户查询 → [检索器:从知识库找相关片段] → [增强:片段 + 原始查询] → [LLM 生成] → 回答
包含两个核心步骤:
- 检索(Retrieval):搜索知识库中与查询最相关的信息片段
- 增强(Augmentation):将检索到的片段加入 LLM 提示,丰富上下文
核心概念
文本嵌入(Embedding)
将文本转换为高维数值向量,捕捉语义含义。语义相近的文本在向量空间中距离更近。
例:"a furry feline companion" 和 "a domestic cat" 虽词汇不同,但嵌入向量距离很近。
文本相似度与语义搜索
| 类型 | 说明 | 示例 |
|---|---|---|
| 表层相似度 | 词汇重叠 | "capital of France" vs "France capital" |
| 语义相似度 | 含义相近 | "What is the capital of France?" vs "Which city is France's capital?" |
RAG 的语义搜索就是寻找与用户查询语义距离最小的文档,正是这种"智能搜索"让 RAG 能在措辞不同的情况下找到相关信息。
文档分块(Chunking)
将大文档拆分为更小、更易处理的片段。RAG 系统无法将整本大文档输入 LLM,而是处理这些小块。
- 分块策略对保留信息的上下文和意义至关重要
- 例:将 50 页用户手册按章节、段落或句子分块,"故障排查"与"安装指南"分别为独立块
- 用户提问时,RAG 能检索最相关的块而非整本手册
检索方法
| 方法 | 原理 | 特点 |
|---|---|---|
| 向量搜索 | 利用嵌入和语义距离 | 理解语义,能匹配措辞不同的查询 |
| BM25 | 基于关键词频率 | 精确匹配,不理解语义 |
| 混合检索 | BM25 + 向量搜索 | 兼顾精确匹配和语义理解 |
向量数据库
专为高效存储和查询嵌入设计。文档分块并转为嵌入后,这些高维向量存入向量数据库。用户查询也转为向量,数据库用高效算法(如 HNSW)在海量向量中快速查找"最接近"的含义。
主流实现:
| 专用向量库 | 支持向量检索的通用数据库 | 底层检索库 |
|---|---|---|
| Pinecone、Weaviate、Chroma DB、Milvus、Qdrant | Redis、Elasticsearch、Postgres(pgvector) | FAISS、ScaNN |
RAG 的进阶形式
图 RAG(GraphRAG)
利用知识图谱而非简单向量数据库进行信息检索。通过遍历知识图谱中实体(节点)间的显式关系(边)来回答复杂问题,能整合分散在多个文档的信息。
| 优势 | 劣势 |
|---|---|
| 理解数据间的连接关系 | 构建和维护知识图谱成本极高 |
| 能回答需多源综合的复杂问题 | 需要专业领域知识 |
| 提供更具上下文的答案 | 延迟可能高于简单向量检索 |
应用场景:复杂金融分析、企业与市场事件关联、科学研究(如基因与疾病关系发现)。
智能体 RAG(Agentic RAG)
引入推理和决策层,智能体作为关键把关者和知识精炼者主动参与检索过程:
| 能力 | 示例 |
|---|---|
| 反思与来源验证 | 检索到 2020 年博客和 2025 年官方政策,智能体识别后者为最新权威来源,丢弃过时内容 |
| 调和知识冲突 | 检索到初步方案 €50,000 和最终报告 €65,000,智能体优先采用财务报告 |
| 多步推理 | "产品功能和定价与竞争对手 X 对比"→ 拆分为 4 个子查询,分别检索后综合 |
| 识别知识空缺 | 内部知识库无最新数据 → 调用 Web 搜索 API 获取实时信息 |
智能体 RAG 的挑战:设计和维护决策逻辑需大量工程投入,计算开销更高,延迟增加,智能体本身也可能成为新错误源(推理失误、误解任务、错误丢弃相关信息)。
RAG 的挑战
- 信息碎片化:答案所需信息可能分散在多个块或文档中,检索器难以获取完整上下文
- 检索质量依赖:若检索到无关块则会引入噪声,干扰 LLM
- 信息矛盾:如何有效整合可能矛盾的信息
- 预处理成本:需将整个知识库预处理并存入专用数据库,且需定期同步
- 性能开销:增加延迟、运维成本和最终提示的 Token 数量
实践应用与场景
| 场景 | 说明 |
|---|---|
| 企业搜索与问答 | 利用 HR 政策、技术手册等内部文档回答员工问题 |
| 客户支持与服务台 | 基于产品手册、FAQ、工单提供精准答复 |
| 个性化内容推荐 | 根据用户偏好语义检索相关内容 |
| 新闻与时事摘要 | 集成实时新闻源,生成最新摘要 |
经验法则
当需要 LLM 基于最新、专有或训练数据之外的信息回答问题或生成内容时,建议采用此模式。适用于构建内部文档问答系统、客户支持机器人,以及需可验证、带引用的事实型响应应用。
代码示例
LangChain + LangGraph 实现(9.1RAG示例_LangChain.py)
完整演示 RAG 流程:从文本文档创建知识库,分块嵌入存入向量库,通过 LangGraph 管理检索和生成。
用户查询 → [retrieve 节点:向量库检索相关块] → [generate 节点:LLM 生成回答] → 输出
核心组件:
- 文档加载与分块:
TextLoader加载文本,CharacterTextSplitter按 500 字符分块(50 字符重叠) - 向量存储:
Chroma向量数据库 +OpenAIEmbeddings嵌入模型 - LangGraph 工作流:
StateGraph定义两个节点retrieve_documents_node:根据查询从向量库检索相关文档块generate_response_node:将检索内容拼接为上下文,结合提示模板调用 LLM 生成回答
RAGGraphState:TypedDict 管理状态,包含question、documents、generation三个字段
app.stream 方法运行 RAG 查询,逐步输出检索和生成过程。
关键要点
- 知识检索(RAG)让 LLM 能访问外部、最新、专有信息
- 包含检索(搜索知识库相关片段)和增强(将片段加入 LLM 提示)两步
- RAG 帮助 LLM 克服训练数据过时、减少"幻觉",实现领域知识集成
- RAG 支持可归因答案,响应基于检索来源
- GraphRAG 利用知识图谱理解信息间关系,能回答需多源综合的复杂问题
- 智能体 RAG 通过智能体主动推理、验证和精炼外部知识,确保答案更准确可靠
- 实践应用涵盖企业搜索、客户支持、法律检索、个性化推荐等场景
总结
RAG 通过连接 LLM 与外部、最新数据源,解决了其静态知识的核心局限。嵌入、语义搜索和向量数据库等基础技术让系统能基于语义而非关键词查找信息。通过以可验证数据为基础,RAG 显著减少事实错误,支持专有信息使用,提升可信度。
智能体 RAG 进一步引入推理层,主动验证、整合和综合检索知识。GraphRAG 则利用知识图谱,能处理复杂、关联性强的问题。虽然这些高级方法增加了系统复杂性和延迟,但已在企业搜索、客户支持、个性化内容等领域带来变革。RAG 是让 AI 更智能、可靠和实用的关键模式,最终让 LLM 从"闭卷对话者"变为强大的"开卷推理工具"。
相关笔记
- 上一章:目标设定与监控
- 下一章:资源感知优化
- RAG 专题导航 — 建库、检索优化、评测与面试速记
- AI MOC