EEPW论坛

背景简介

在实际使用大语言模型（LLM）的过程中，我们很快会遇到一些现实问题：模型容易产生“幻觉”、无法直接利用私有数据、知识更新依赖重新训练，以及回答结果缺乏可追溯性。这些问题在工程落地阶段尤为明显，也成为限制大模型在企业场景中广泛应用的重要因素。

为了解决上述问题，**RAG（Retrieval-Augmented Generation，检索增强生成）**逐渐成为当前最主流、也是最实用的大模型落地方案之一。RAG 通过在模型生成答案前引入外部知识检索机制，使大模型能够基于真实、可控的数据进行回答，从而显著提升准确性与可靠性。

在两个月前，我参加了 AWS 举办的 AWM 研讨会。研讨会第一天主要围绕 基于 AWS Bedrock 的 RAG 实践展开，系统讲解了 RAG 的整体架构与使用方式；第二天则聚焦于 GenAI 相关能力与应用场景。会后，我结合 AWS 官方提供的 Demo 代码，对相关方案进行了实际验证，并成功跑通了完整流程，这也让我对 RAG 的工程实现有了更直观的认识。

本文将从工程视角出发，系统介绍 RAG 的整体流程与核心原理，帮助读者快速理解其设计思路及实际应用价值。

RAG 的核心思想其实非常直观：在大模型生成回答之前，先从知识库中检索出与问题最相关的内容，再基于这些内容进行生成。换句话说，大模型不再“凭记忆作答”，而是建立在真实、可控的外部知识之上进行回答。 （AI进行重新整理文章结构）

在宏观上来看RAG的用户交互主要分为以下几个部分

1- 用户提问

2- 将提问的问题进行向量化（使用不同的embedding模型效果不一样）

3- 进行向量化的检索 （欧拉距离等不同的算法，从向量数据库中查看最符合问题的向量）

4- 获得Top K的列表（相关度列表，相关度排序）

5- 将TOK列表 + prompt 给LLM

6- 由LLM来汇总信息并且给出输出。

前置阶段

在上述流程之前需要有一些前置的阶段。

1- 对文档进行收集与清洗

• PDF / Word / Markdown 文档

• 技术手册、需求文档、接口说明

上述的文档都需要转换成TXT的形式。需要做数据清洗比如说删除文件头等等

2. 文档切分（Chunking）

由于大模型有上下文长度限制，文档需要被切分成多个小块：

• 按段落或语义切分

• 常见大小：300~1000 tokens

切分的目标是使其每一块内容都能独立回答一个局部问题（全局问题的话需要消耗大量Token）

3.向量化（Embedding）

将文本转换成嵌入式向量。用于后续的相似度搜索

4. 将向量数据信息保存到向量数据库中

• FAISS

• Milvus （使用过）

• Chroma （使用过）

• Pinecone

到这一步其实用户的知识库已经构建成功了。 

5. 当用户进行提问的时候、会首先将用户的问题使用对文本进行向量化时一样的embedding 模型对用户的问题进行向量化。

6. 根据问题向量化的结果向向量化的数据库进行检索来获得Top K

7. 构建prompt 比如

已知资料：
1. ...
2. ...

问题：
如何在 ESP-IDF 下播放 MP3？

请基于已知资料回答，不要编造内容。

1和2是从向量数据库中检索到的数据， 然后将上述的数据发送给LLM，由LLM进行回答。

大模型和RAG的对比

总结

RAG 并不是要取代大模型，而是帮大模型“补短板”。从实际使用的感觉来看，与其一开始就折腾复杂的模型训练，不如先把 RAG 跑顺。很多时候，只要把数据准备好、检索逻辑设计清楚，大模型就已经能帮上不少忙了。

如果你正在做企业系统、内部工具或者智能助手，那大概率迟早都会接触到 RAG。至少在现阶段，它是一种相对务实、也比较容易落地的选择。在下一篇文章中我们将会来从零开始构建一个简单的RAG问答系统，使其可以读取电子元器件的数据手册，然后对其数据手册内的内容进行回答。