【大白话讲RAG】 1/n 为什么需要RAG？
Retrieval-Augmented Generation 召回增强生成
答案很简单，给大模型回答问题所需要的知识。

现在把RAG类型的技术研究神化过多，而RAG是一个浅显易懂没有什么神秘色彩的简单道理。召回增强生成（RAG）即在回答问题时给大模型找到相关的文档信息。

用实习生来比喻大模型。大模型经过了大量的数据训练，它理解了语义、语法、通识知识，就像一个刚毕业的大学生一样，ta懂很多通识课程知识，也听得懂人话，但刚刚来实习，对业务数据、实际生产环境都不甚了解。大模型具备了实习生的各种特点：

- 懂通识知识，具备推理能力
- 不会企业里面的知识，只会课本知识
- 不知道自己不知道什么，也不知道自己知道什么
- 不会借助外部知识库（书籍）的力量，需要外人告诉ta你应该做什么
- 教导一句，就回应一句；教导越详细，效果越好
- 学的很慢，最新知识记不住

而实习生虽然不会企业知识，但ta会翻书呀。

把书摆在ta的旁边，每次让ta回答问题的时候，都去书里面找到相关的信息再回答。而且告诉ta，你不能根据你的经验回答问题，必须根据书籍中的内容回答。实习生就知道了，哦，我根据你给的书籍知识回答问题，让我看一眼书，好的，我知道答案了。

这就是RAG的过程，根据问题翻书，根据书中内容回答问题。

这里的书，可以是海量互联网知识，可以是企业内部知识库。

那么，为什么要RAG呢？

- 类比人：找相关信息就是翻书。实习生不需要记住所有书中的内容，但ta会翻书找到相关内容即可。

- 上下文限制：LLM只有4k-128k的阅读窗口，没办法放进去企业整个文档知识库信息。即便可以放进去，推理速度也会随着放的越多而减慢。基于算力成本、推理时间的考虑，适时取用知识更优。

- 实时性：企业知识更新迭代非常快。模型训练成本大于召回，可以训练模型让模型“记住”一些知识，但是这个耗时长、数据工程难、实时性差。对于一直在更新的企业数据，提供更便捷的召回引擎可以不用动LLM参数就能获得优质答案。

- 模型不知道企业数据：企业的数据一般都是私有的，通用大模型本身是不会训练这些数据的，对于领域问题的数据它根本不知道。

RAG的主要两个步骤：

- 找到相关内容：根据问题（经过各种算法）找到该问题的相关文档。这个过程类似于人搜索谷歌，搜索excel表格……

- 根据相关内容回答问题：LLM根据问题+相关文档回答问题。

第一个步骤，就是面向大模型回答的搜索引擎。现在主流的使用embedding检索，只是一种基于语义的召回模式，然而无论使用关键词搜索、混合搜索、谷歌搜索、结构化知识搜索，完全都不影响，本质就是检索文本的推荐算法罢了。

第二个步骤，就是将所有内容按照prompt的最优组装方式组合起来，大模型根据prompt进行推理。

搜准了，才能答准。

可以看看我画的图，其实RAG的prompt也好，组装的文档切片也好，都简单明了，只要你看见最终发给大模型的prompt输入，你就基本知道发生了什么。

所以，尽管很多博主鼓吹RAG 130行就可以写完代码，是因为真的很简单，这个流程。

看似没有什么壁垒不是吗？并不是，因为它背后的细节问题可太繁琐了：

怎样才能搜索到该问题相关的文本？
上下文放不下这么多切片文本怎么办？
搜索出来的多段文本无关信息太多了怎么办？
有一些问题根本没说清要查询的内容？
有一些问题需要多次查询怎么办？
有些问题要数学计算但是大模型算不准？
……

下一篇继续讲讲里面RAG遇到的问题 + 推荐我看的信息源。

RAG我看的最多的资料来自Twitter中Llamaindex的post，包括llamaindex CEO Jerry Liu发的帖子。如果你是刚刚起步，可以先从他们的推开始看。

llamaindex: twitter.com
jerryliu: twitter.com