2023 年以来，RAG 已成为基于大模型的人工智能系统中应用最为广泛的架构之一。因此对 RAG 应用的性能、检索效率、准确性的研究成为核心问题。
本文首先介绍什么是 RAG、为什需要 RAG、介绍 Naive RAG 工作流程及Naive RAG 存在的问题和挑战！
为什么需要 RAG？
大家思考一个问题：既然已经有了大模型，为什么还需要RAG呢？
在大模型的快速发展过程中，大家发现仅仅依靠LLMs会有很多地方制约着我们前进，以下四点比较突出：
- 幻觉问题：LLMs底层基于概率推理，所以LLMs有时候会一本正经的胡说八道，编造看似合理的事实。
- 知识缺乏问题：LLMs都是预训练，就拿ChatGPT3.5来说训练数据是2021年，但是对于2021年之后的事情，它将一无所知。另外还可能会产生过时的知识和缺乏一些特定领域的知识。
- 数据安全问题：对于企业来说，企业的经营数据，商业机密数据都是非常重要的，直接使用大模型可能会有数据安全泄露风险。
- 可信度问题：不透明、无法追踪的推理过程，导致回答问题可信度问题。
因此检索增强生成(RAG)技术应运而生，通过整合外部知识，提高LLMs生成的答案的准确性和可信度。特别是对于知识密集型任务，并允许持续的知识更新和特定领域信息的整合的场景。
大家可能会问，为什么使用 RAG 而不是大模型微调的方式，RAG的主要使用场景有哪些？
- 数据变动频繁的场景，频繁变动导致微调成本过高。
- 回答问题需要给出出处的场景，比如该回答参考的哪篇文章等
- 对产生幻觉敏感的场景，微调之后也无法避免产生幻觉
- 节省GPU训练成本的场景
- ......
什么是 RAG？
检索增强生成（Retrieval Augmented Generation，RAG）是通过整合来自外部知识源的额外信息来改进大语言模型（Large Language Models，LLMs）应用能力的一种技术。这种技术能够帮助 LLMs 产生更精确和更能感知上下文的回复，同时也能减轻幻觉现象。
简短的公式帮你理解RAG：RAG = 检索 + LLMs
RAG分为两个阶段：第一个阶段：索引，第二个阶段：检索。有的地方理解为离线处理和在线处理
索引阶段（离线）
索引阶段是将文本、图片、音视频等格式的内容进行解析、分割、向量化处理，并最终向量化后的内容存储到向量数据库。
「 我的理解是：事实上也并非一定向量化，某些场景可以仅使用精确/关键词搜索，具体还是的看场景，但是一般情况下还是需要的 」
检索阶段（在线）
检索阶段主要是将用户提问向量化，然后将向量化的提问去向量数据库中进行相似度查询并返回语义相近的信息，然后组将该信息作为上下文发送给大模型。
Naive RAG 工作流程
Naive RAG 的典型工作流程，引用一篇技术文章中的一张非常好看并且也非常的形象的图，如下所示：
图来引自：https://ai.plainenglish.io/advanced-rag-part-01-problems-of-naive-rag-7e5f8ebb68d5
- Indexing（索引）：索引是
RAG应用环节的第一步也是关键一步，其处理的质量将直接决定RAG应用的性能。- 首先对原始数据进行清理和提取，将 PDF、HTML 和 Word 等各种文件格式转换为标准化的纯文本。
- 其次对文本进行分块，也就是Chunking。
- 最后对Chunking的块进行向量化处理，并将其存储到向量数据库中。
- Retrieval（检索）：检索方式有多种，关键字检索、语义相似检索以及混合检索方式，在实际的应用场景中根据不同的场景选择不同的检索方式，并不一定非的是语义相似度检索。
- 首先将用户输入的提示词进行向量化处理，然后在向量数据库中进行相似度搜索，选择TopK数据。
- Generation（生成）：这个没啥可说的，大模型正常处理过程。
- 根据用户提示词 + 相似上下文 通过提示词模板生成一个增强提示词，发送给LLMs
从整个工作流程上看，实现还是比较简单，但在RAG圈有句名言“一天搭建RAG，一年上不了线”。也从另外一个角度说明想达到生产级别还是相当困难的。
Naive RAG 存在问题
RAG 8个问题
Naive RAG 在索引、检索和内容生成这三个核心步骤中都存在诸多问题，下面将问题一一列举，只有知道了问题才能解决问题。
-
Indexing（索引）
- 信息提取不完整、信息提取难度大（文档格式多），数据清洗质量差等等问题，都会导致RAG应用的失败。
- 文档分块大小不合理，切分后上下文语义丢失或者包含不完整的内容，没有考虑到一些重要细节。
- 索引结构未优化，比如索引类型、索引的大小等问题
- 嵌入模型语义表达能力弱。【后面会介绍在RAG应用落地时如何选择合适的嵌入模型】
-
Retrieval（检索）
- 用户发送的请求表述模糊、不明确或者嵌入模型表达能力弱，导致无法检索到有价值的信息。
- 外部知识库检索内容与用户提问相关性较低，检索信息的准确率也比较低。
- 检索召回率低，无法检索到所有相关段落，从而影响了 LLMs 生成全面答案的能力。
- 当检索到的多个来源信息时，上下文会包含相似信息，会出现信息冗余，从而导致生成的答案中出现重复内容。
- 没有结合不同类型的检索方法或算法，如关键词、语义和向量检索（keyword, semantic, and vector retrieval）的组合。
- 将检索到的信息与不同的任务集成可能具有挑战性，有时会导致输出脱节或不连贯。
- 面对复杂的问题，基于原始查询的单个检索可能不足以获取足够的上下文信息。
-
Generation（生成）
- 上下文整合不佳、过度依赖检索信息、存在生成错误/不当内容的风险，降低响应的质量和可靠性
- 生成模型可能过度依赖增强信息，导致输出只是回显检索到的内容，而不添加有洞察力或综合的信息。
RAG 12个痛点
参考文章：12-rag-pain-points-and-proposed-solutions
| 痛点序号 | 痛点内容 | 解决方案 |
|---|---|---|
| 痛点 1 | 内容缺失 | 清洗数据 && 精心设计提示词 |
| 痛点 2 | 关键文档被遗漏 | HyDE 和 重排序（排序模型的选择） |
| 痛点 3 | 文档整合长度限制-超LLM窗口大小 | 调整检索策略 & 嵌入模型调优 |
| 痛点 4 | 提取困难 | 数据清洗，提示词压缩，长内容优先排序 |
| 痛点 5 | 格式错误 | 改进提示词，格式化输出，pydantic program(处理json)，大模型的Jsonmode |
| 痛点 6 | 缺乏具体细节 | 先进的检索策略 （从小到大的聚合检索/基于句子窗口/递归式检索） |
| 痛点 7 | 回答不全面 | 查询转换 （路由/查询改写/细分问题/ReAct提示） |
| 痛点 8 | 数据摄取的可扩展性 | 并行处理，提升处理速度 |
| 痛点 9 | 结构化数据问答 | 链式思维表格包/混合自洽查询引擎包 |
| 痛点 10 | 从复杂 PDF 提取数据 | 嵌入式表格检索技术 |
| 痛点 11 | 备用模型策略 | Neutrino 路由器 （能够处理你提出的各种查询的大语言模型集群）/OpenRouter |
| 痛点 12 | LLM 安全 |
其中 7 个来自 Seven Failure Points When Engineering a Retrieval Augmented Generation System 论文。对于一些痛点本人也有些不理解，先列举在此，知道有这个事情，后续慢慢详细研究。
本文就不对解决方案进行详细说明了，后续文章会对每一个痛点或者存在问题进行详细分析，给出相应的技术解决方案。希望读者关注本专栏，文章会持续不定期更新。
