你应该懂的AI大模型之RAG

从本篇开始笔者会尽量多使用一些英文缩写和单词，不是笔者为了装X，是为了大家在后面遇到的时候不至于被别人装到。

一、什么是RAG

1.1 大模型的局限性

大模型的知识不是实时的，比如现在《藏海传》已经完结了，但是我问deepseek给我的回答却是：

        除了知识不是实时的之外，大模型可能也不知道你当前所在业务领域的知识。这就是大模型目前所固有的局限性。

1.2 检索增强生成

为了解决大模型所固有的局限性，就有了 RAG（Retereval Augmented Generation），通过检索的方法来增强模型的能力。

再直白点大模型的能力不值得信任，微调的成本太高，所以才会用 RAG 的出现。

ps：笔者不知道哪种读法是对的，有的读 RAG 的英文字母，笔者有认识的大佬读[ræɡ]，即 ruai ge，笔者觉着跟随者大佬读应该更能装到。）

        我们现在使用的 LLM（Large Language Model）是通过海量文本数据训练得来，能够理解和生成人类语言。也就是说当我们问大模型问题的时候大模型会从它先有的知识中得出答案回答我们，但是如果我们问一些时事或者专业领域问题的时候大模型没有这部分知识，那么大模型就有可能会自由发挥来回答我们问题，因此我们引入 RAG 相当于给大模型进行一场开卷考试，当我们问问题的时候，大模型会“先翻书”再回答问题。

        其实这就相当于给LLM戴上了紧箍咒。强制要求回答问题必须从给定的知识库中检索到的内容生成答案，不让LLM凭空想象捏造答案，大大降低了模型出现幻觉的概率。

二、RAG系统的基本搭建流程

        在上图中有两个比较新的东西，一个是Embedding模型和VectorDB，解释以下这两个概念：

• Embedding模型，即嵌入式模型，它的作用是将非结构化的数据（如文本、图像、音频）转换成可计算的数值向量；

• Vector DB：向量数据库，顾名思义可以理解为存储Embedding生成的向量数据的数据库。

        抛开这两个概念，RAG搭建的过程可以总结为以下四步：

1、文档加载，按照一定的条件和规则将文档切割成片段；

2、将切割的文本片段灌入检索引擎；

3、封装检索接口；

4、构建调用流程：Query->检索->Prompt->LLM->回复

三、向量检索

3.1、什么是向量

        向量是一种有大小和方向的数学对象。它可以表示为从一个点到另一个点的有向线段。例如，二维空间中的向量可以表示为 (x,y)，表示从原点 (0,0) 到点 (x,y) 的有向线段。

        从数学的角度看，向量是一个“有方向和大小的东西”，可以用数字坐标来描述。在计算机世界中，我们可以把向量简单地理解为一组“有意义的数字”，用来表示事物的特征

        例如我们描述一只猫的可以描述为有胡须、有毛、会喵喵叫，这些信息转换成向量就可以用一堆数字来表述[有胡须：0.981，有毛：0.193，会喵喵叫：0.453]，每个数字都代表一个特征，这样猫的特性就被向量化了，就能被计算机检索出来。

        文本向量就是将文本转成一组N维的浮点数，即文本向量又叫Embeddings，向量之间可以计算距离，距离的远近对应语义相似度的大小。

PS：文本向量是怎么计算得到的，这不是本文能讲解明白的，不是笔者不想写，是想要把这个话题拿来写着实是有点难度。

3.2、向量间的相似度计算

        向量的相似性通常通过计算向量之间的距离来比较。 距离越小，相似性越高。常用的算法比如余弦距离和欧式距离来判断向量距离。

        假设我们有两个文本的向量：

文本1：“我感冒了” → 向量为 [0.82, 0.61, 0.97]

文本2：“我流感了” → 向量为 [0.90, 0.73, 0.98]

        通过余弦相似度公式计算余弦相似性，结果越接近1，说明两个文本的语义高度相似。

欧氏距离：越小越相似。

余弦距离：越大越相似，余弦值越大夹角越小，距离越近。

3.3、向量数据库

Embedding Modle（嵌入模型）负责计算向量，向量数据库负责存储和比较向量。向量数据库是专门为向量检索设计的中间件！

读到这里大家可能会觉着向量数据真厉害，简直可以秒杀传统的关系型数据库，在这里告诉大家：

• 向量数据库的意义是快速的检索；

• 向量数据库本身不生成向量，向量是由 Embedding 模型产生的；

• 向量数据库与传统的关系型数据库是互补的，不是替代关系，在实际应用中根据实际需求经常同时使用。

大家不要盲目迷信学习大模型我们带来的新的技术视野。

下面为大家列举几个常见的向量数据库，这些向量数据库的特点大家可自行总结：

• Chroma

• Deep Lake (Activeloop)

• Elasticsearch & OpenSearch（没想到吧，Elasticsearch也支持向量检索）

• Faiss (Facebook AI Similarity Search)

• LanceDB

• Milvus

• Pinecone

• PgVector (PostgreSQL 扩展)

• Qdrant

• ScaNN (Scalable Nearest Neighbors)

3.4、认识几个Embedding模型

建议大家去HuggingFace上瞅瞅吧。。。正好不知道的同学可以了解下HuggingFace是啥，除了HuggingFace还可以逛逛阿里的魔塔社区。

四、其他可以装到的话题

4.1、企业中落地RAG常用的向量数据库

        milvus和Qdrant。

4.2、大模型的两个流派

        RAG派和上下文窗口扩大派，这两派的论调大家自行搜索查看就好。

        在笔者看来，目前做项目能够简单落地的还就是RAG。

4.3、Hybird Search 混合检索

        在实际生产中，传统的关键字检索（稀疏表示）与向量检索（稠密表示）各有优劣。举个具体例子，比如文档中包含很长的专有名词，关键字检索往往更精准而向量检索容易引入概念混淆。所以，有时候我们需要结合不同的检索算法，来达到比单一检索算法更优的效果。这就是混合检索。

4.4、处理PDF文档中的表格

PDF中的表格我们怎么处理抽取，大家放心，我们能遇到的问题，大佬们肯定早就碰到了，因此有很多面向RAG的文档解析辅助工具：

• PyMuPDF: PDF 文件处理基础库，带有基于规则的表格与图像抽取（不准）

• RAGFlow: 一款基于深度文档理解构建的开源 RAG 引擎，支持多种文档格式（火爆）

• Unstructured.io: 一个开源+SaaS形式的文档解析库，支持多种文档格式

• LlamaParse：付费 API 服务，由 LlamaIndex 官方提供，解析不保证100%准确，实测偶有文字丢失或错位发生

• Mathpix：付费 API 服务，效果较好，可解析段落结构、表格、公式等，贵！

五、GraphRAG

·通过知识图谱来增减检索，即在检索中利用图谱的关联性捕捉深层语义，弥补依赖向量相似度的不足。特点是小公司玩不起，都是大公司在玩。

关于为什么不写具体实践。笔者会在后面的篇章中专门拿出几章来扫盲开发过程，那时就能看到这些技术大概是怎么落地的了。