首页 / 文章 / RAG详解：让大语言模型获取外部知识

rag embeddings vector-search llm hybrid-search retrieval

RAG详解：让大语言模型获取外部知识

专为初学者设计的RAG入门指南——涵盖分块处理、嵌入模型、向量搜索、混合检索，以及为何RAG仍会出现幻觉问题，并附有清晰的架构图解。

2065 词

大型语言模型从训练数据中获取答案。这些数据虽然强大，但并不完整：它可能遗漏内部手册、过时的政策以及从未出现在公开文本中的事实。检索增强生成（RAG）通过首先获取相关的外部资料，再让模型基于这些资料作答，从而弥补了这一缺陷。

什么是RAG？

在没有检索功能的情况下，问题会直接传递给模型：

User Question
      ↓
     LLM
      ↓
   Answer

而使用RAG时，系统会在生成答案之前先找到相关信息：

User Question
      ↓
Find Relevant Information
      ↓
Give Information to the LLM
      ↓
     LLM
      ↓
   Answer

最终文本仍由模型撰写，只不过新增了来自知识库的上下文作为依据。

为什么需要RAG？

训练截止时间、私有语料库以及快速变化的政策都会打破“仅依赖记忆”的回答方式。上周更新的员工手册内容不会存储在前沿模型的权重中。RAG使得助手能够在被询问时直接查阅该手册，而无需重新训练。

一个简单的RAG示例

有员工询问关于假期结转的问题。处理流程如下：

Employee asks a question
          ↓
Search the employee handbook
          ↓
Find the relevant section
          ↓
Give that section to the LLM
          ↓
LLM generates the answer

助手应当引用手册中的内容，而非编造“听起来合理”的政策。

RAG是如何工作的？

有两个关键阶段：离线准备知识，然后在线回答问题。

1. 准备知识

导入文件、将其拆分、对片段进行嵌入，并存储向量以便检索。

2. 回答问题

对问题进行嵌入，获取最相关的片段，将它们整合到提示词中，进而生成答案。

第一部分：准备知识

人力资源助手常用的资料来源包括：

Employee Handbook
Vacation Policy
Benefits Guide
Leave Policy

准备流程：

Documents
    ↓
Extract Text
    ↓
Break into Smaller Pieces
    ↓
Create Embeddings
    ↓
Store for Search

步骤1：获取信息

从每个来源中提取纯净的文本：

Employee Handbook
        ↓
    Extract text
        ↓
"Employees receive..."
"Vacation requests..."
"Leave policy..."

页眉、页脚以及导航栏应尽早去除，避免它们成为“事实”内容。

步骤2：将文档拆分成块

过长的手册会超出上下文范围，导致相关段落被淹没。通过拆分可以生成可搜索的单元：

Employee Handbook
       ↓
 ┌───────────────┐
 │    Chunk 1    │
 ├───────────────┤
 │    Chunk 2    │
 ├───────────────┤
 │    Chunk 3    │
 ├───────────────┤
 │      ...      │
 └───────────────┘

为何拆分很重要？

块过大会降低相关性；块过小则会丢失周围的规则（尤其是否定词和例外情况）。相邻块之间的重叠有助于保留边界上下文。可以先从固定大小且带有重叠的简单方式开始，待评估出现遗漏后再进行调整。

步骤3：生成嵌入向量

嵌入向量可将文本映射为向量，从而使语义相似的短语即便没有共同关键词也能位于相近位置。

问题文本：

"What is my vacation allowance?"

表达相同含义的改写版本：

"How many annual leave days do I get?"

经过嵌入处理后，两者都可能落在相近的休假政策数据块附近：

"What is my vacation allowance?"
              ↓
          Embedding
              ↓
       Numerical representation

索引和查询应使用相同的嵌入模型；混用不同模型会破坏最近邻搜索功能。

第4步：存储信息以供检索

每个数据块及其向量都会被存入向量索引（或混合存储结构）中：

Document Chunk
      ↓
   Embedding
      ↓
Vector Database

元数据——如来源标题、页面信息、访问权限、生效日期等——应与数据块一同存储，以便日后用于过滤和引用。

第2部分：回答用户问题

在线处理路径：

User Question
      ↓
Understand the question
      ↓
Search the stored information
      ↓
Find relevant chunks
      ↓
Give those chunks to the LLM
      ↓
Generate an answer

第5步：检索相关信息

通过问题嵌入可以获取最相关的数据块，例如：

Chunk 147 → Vacation carryover policy
Chunk 148 → Vacation request process
Chunk 62  → Employee benefits
Chunk 300 → Security policy

此处的排序质量决定了最终答案的质量。糟糕的检索结果无法通过更优的提示来弥补。

第6步：将信息提供给大语言模型

获取的文本将成为提示词上下文：

Context:Employees may carry over up to 5 unused
vacation days into the following year.
Question:How many vacation days can I carry over?

指令应要求模型基于上下文回答问题，并在上下文缺失时承认不足。

第7步：生成答案

Retrieved Information
        +
User Question
        ↓
       LLM
        ↓
      Answer

模型会根据检索到的内容来组织回复，而非依赖通用的HR经验法则。

完整的RAG架构

离线准备阶段：

KNOWLEDGE PREPARATION

端到端流程图：

        Documents
            ↓
      Extract Text
            ↓
         Chunking
            ↓
        Embeddings
            ↓
      Vector Database
            │
            │
            │
            ▼
        USER QUESTION
            ↓
        Query Embedding
            ↓
         Retrieval
            ↓
    Relevant Information
            ↓
     Question + Context
            ↓
            LLM
            ↓
          Answer

提问之前

Documents
   ↓
Chunks
   ↓
Embeddings
   ↓
Vector Database

问题出现时

Question
   ↓
Retrieval
   ↓
Relevant Context
   ↓
LLM
   ↓
Answer

RAG仅使用向量搜索吗？

不是。实际应用系统通常会结合多种方法。

关键词搜索

词汇匹配器（如BM25等）擅长处理精确的文本片段：政策代码、SKU编号、错误标识符、专有名词等。

语义搜索

向量搜索能够捕捉到关键词遗漏的意译词和同义词。

混合搜索

将两者结合后再合并排序结果：

Keyword Search
       +
Semantic Search
       ↓
  Hybrid Search

当流量中既有精确的标识符也有自然语言查询时，混合搜索是出色的默认选择。

RAG无法消除幻觉

检索功能可以减少无依据的编造内容，但无法完全消除它。可能出现的问题包括：

获取了错误的片段：

User Question
      ↓
Wrong information retrieved
      ↓
LLM
      ↓
Wrong answer

未找到相关内容，模型仍会给出答案：

User Question
      ↓
No relevant information found
      ↓
LLM
      ↓
Unsupported answer

缓解措施包括：更严格的检索、重新排序、拒绝回答的指令、引用信息，以及以准确性而非流畅度作为评估标准。

RAG与微调

RAG

在知识更新频繁、需要引用来源，或相关知识不在训练数据中时最为适用。更新只需重新建立索引，无需重新训练。

微调

当行为、风格或任务格式需要变更，或者相关知识足够稳定且简洁可嵌入系统时，这种方案最为适用。但若政策频繁变动，则更新成本会很高。

许多产品同时采用这两种方法：利用微调处理技能相关内容，用RAG处理事实类信息。

RAG在哪些场景有用？

客户支持

基于产品文档和工单模板生成的智能助手。

医疗保健

具备严格引用规范和访问控制机制的流程与指南查询系统（仍需遵循领域规则）。

金融行业

需要依据最新获批文本来提供政策、披露信息及产品规则相关解答的场合。

人力资源

手册、福利政策、休假规则——与上述员工咨询场景完全一致。

软件开发

除公开文档外，还包括内部解决方案、操作手册及API参考资料。

何时应该使用RAG？

当答案需要基于比提示更庞大的特定语料库、该语料库的更新速度快于微调周期，或需要追溯来源时，应使用RAG。对于基础模型已掌握的纯常识问题、纯粹的创意内容，或是无法承受检索步骤的超低延迟场景，则无需使用RAG。

什么会让RAG变得困难？

分块边界问题、嵌入向量漂移、过时的索引、访问控制漏洞以及评估标准缺失。一个具体的错误案例：

用户提问：

User asks:
"What is the vacation carryover policy?"

系统检索到了错误的政策类别：

             ↓System retrieves:
"Health insurance policy"             ↓LLM receives wrong context             ↓Poor answer

随后模型在解释健康保险时表现得十分自信，却将其误当作假期保险的延续。在指责生成器之前，应先修复检索和元数据过滤机制。

构建RAG需要学习什么？

一套实用的技能进阶路径：

RAG Fundamentals
       ↓
Document Processing
       ↓
Chunking
       ↓
Embeddings
       ↓
Vector Databases
       ↓
Retrieval
       ↓
Prompt + Context
       ↓
LLM
       ↓
Evaluation

文档处理、分块策略、嵌入模型、向量存储、提示词构建、评估以及相关操作（重建、访问、监控）都至关重要。

整体概览

Knowledge
                 ↓
            Find relevant
            information
                 ↓
           Give it to LLM
                 ↓
             Generate
              answer

知识存在于模型之外；数据获取功能负责搭建连接桥梁；而生成环节则是最后的步骤。

分块方式与嵌入维度及索引类型相互影响：当查询内容同时包含普通文本和标识符时，仅使用密集向量的HNSW架构与混合BM25+向量存储的表现会有所不同。需制定书面的重建触发规则——包括新手册版本的发布、页面删除、权限变更等情况，并确保被删除的内容真正从索引中移除，而不会以孤立向量的形式残留。引用格式也应在生成规范中明确：如果用户界面承诺提供页面级的来源信息，那么提示词和后处理模块就必须输出稳定的源标识符，而非毫无实际用途的装饰性脚注。

即使在入门阶段，重新排序这一环节也值得简要提及。使用双编码器进行初筛成本较低；而对前五十个候选项再用交叉编码器处理，通常就能解决那些导致演示效果异常的“文档大致正确但章节错误”的问题。此外，当相似度得分低于设定阈值时，还可结合简单的拒绝规则。那些跳过评估的团队往往会在利益相关者面前才发现这些问题，而非在笔记本中。

最后，请记住RAG的经济模型：随着语料库的不断扩展，索引成本会持续产生，而微调成本则是分批支付的。对于政策类领域而言，持续的索引费用通常比每周的微调成本更低——而且还能确保能够提供审计人员要求的精确段落。这种可审计性往往是“构建聊天机器人”这一需求背后真正的产品要求。

在将RAG整合到现有的支持体系中时，应从一个语料库和一个问题类别开始，而非试图面面俱到。在全面引入Confluence空间之前，先针对该部分数据衡量答案偏移、问题升级以及错误答案相关的投诉情况。小范围测试有助于确定哪些数据块大小和混合权重有效；而大规模部署则往往表明，缺乏准确性指标的仪表板会掩盖功能退化的问题。在初期几周内，应为有争议的答案设置人工审核队列，以便编辑人员区分“检索良好/生成不佳”与“检索不佳”这两种情况，因为它们的修复方法不同。随着时间推移，这些标签可成为用于重新排序的训练信号，同时也有助于判断某个主题是否应退出RAG体系，转而采用确定性工作流程。

最终结论

Store external knowledge
        ↓
Find relevant information
        ↓
Give that information to an LLM
        ↓
Generate a grounded response

存储外部知识，为每个问题查找相关内容，然后再进行生成。这个三步循环就是RAG——构思简单，但要良好运行却颇具挑战性，同时也是让助手在处理私密及不断变化的事实时保持准确性的最实用方法。

操作规范是区分临时演示工具与可靠辅助系统的关键：锁定问题集，同时衡量检索命中率与答案准确性，并根据源材料更新频率设定索引重建计划。在采用混合搜索、重新排序或元数据过滤时，应保持相同的评估标准，以便让改进成果有据可查而非仅凭主观感受。从一开始就将访问权限标签视为数据块内容的一部分；若事后才添加权限，就会导致私人人力资源记录泄露到公开聊天中。最后，当核心数据块表现不佳时，与其给出看似合理的猜测，不如直接拒绝并要求提供参考依据——用户更信任经过验证的沉默，而非华丽的编造。

除了正常流程图之外，还需保留索引重建、访问权限审核以及已知故障模式的操作手册，这样操作人员获得的就不只是简单的演示文稿而已。

将索引重建、访问审查以及已知故障模式的操作手册与正常流程图放在一起，这样操作人员获得的就不只是幻灯片内容而已。

请将索引重建、访问审核以及已知故障模式的操作手册与标准流程图放在一起，这样操作人员获得的就不只是几页幻灯片而已。

全部文章发送简报