雖然我們說大模型的特點(diǎn)之一是知識豐富，但這里的知識僅限于通用的知識，也就是網(wǎng)上能夠很容易找到的知識。對于一些特定的知識，比如你所在業(yè)務(wù)領(lǐng)域的知識，它就一無所知了。個中緣由，不言而喻，大模型訓(xùn)練時，根本不可能拿到你們公司的數(shù)據(jù)。如果我打算為自己的業(yè)務(wù)開發(fā)一個聊天機(jī)器人，也就是說，讓聊天機(jī)器人知道我的業(yè)務(wù)，該怎么辦呢？拋開訓(xùn)練一個屬于自己的大模型這種成本高昂的辦法，常見的解決方案有兩種：模型微調(diào)：使用業(yè)務(wù)信息對已經(jīng)訓(xùn)練好的模型進(jìn)行微調(diào)。RAG：在上下文中帶有業(yè)務(wù)信息，讓大模型據(jù)此進(jìn)行整合。相比于模型微調(diào)，RAG 的方案成本要低一些，而且更加靈活，實現(xiàn)起來也更簡單一些，所以，它也成為了現(xiàn)在解決這個問題的首選。這一講，我們就來了解一下 RAG。

RAG

RAG 是 Retrieval-Augmented Generation 的縮寫，也就是檢索增強(qiáng)生成。這是什么意思呢？就是通過檢索的方式，對要處理的內(nèi)容進(jìn)行增強(qiáng)之后再去生成。

我們把大模型應(yīng)用和檢索增強(qiáng)結(jié)合起來理解一下。大模型有很多不知道的東西，比如，我們的業(yè)務(wù)。怎么讓大模型了解我們的業(yè)務(wù)呢？最簡單的方式就是每次請求時，把業(yè)務(wù)相關(guān)的內(nèi)容放在提示詞里告訴大模型。

問題是，業(yè)務(wù)相關(guān)的內(nèi)容從何而來？這就是我們要在本地檢索的內(nèi)容。換言之，所謂檢索增強(qiáng)生成，就是我們在本地檢索到相關(guān)的內(nèi)容，把它增強(qiáng)到提示詞里，然后再去做內(nèi)容生成。

下面是一個 RAG 系統(tǒng)處理用戶請求的極簡流程示意圖：

圖片

1. 用戶發(fā)起請求
2. 根據(jù)用戶的問題在相關(guān)資料中進(jìn)行查詢
3. 獲取到資料中的相關(guān)內(nèi)容
4. 組成完整的提示詞發(fā)給大模型
5. 將大模型的回復(fù)發(fā)給用戶

對比普通的聊天機(jī)器人，差別就是在這個過程中，要去到相關(guān)資料中進(jìn)行查詢，再將查詢得到的相關(guān)信息和用戶問題拼裝成完整的提示詞發(fā)給大模型。

有了對 RAG 流程的初步認(rèn)識，接下來的問題就是，怎樣到相關(guān)資料中查詢。既然要查詢，必然是有個地方能夠存儲這些資料的。對于程序員來說，最熟悉的存儲方案一定是數(shù)據(jù)庫。

對于大模型應(yīng)用開發(fā)而言，我們要根據(jù)文本去找相關(guān)內(nèi)容。在業(yè)務(wù)系統(tǒng)開發(fā)中，我們經(jīng)常做的文本匹配是用 SQL 語句的 like。但是，這種匹配對于大模型應(yīng)用而言，就顯得非常單薄了，因為它只能進(jìn)行“字面”意義上的匹配，無法進(jìn)行“語義”層面的匹配。如果想進(jìn)行“語義”的匹配該怎么做呢？這就輪到向量登場了。

向量和向量數(shù)據(jù)庫

向量，我們說過，許多 AI 算法處理的都不是文字，而是向量。采用向量的方案，“語義”的匹配程度就轉(zhuǎn)換成了向量之間的相似程度。計算向量相似度的算法有很多，比如，余弦相似度、內(nèi)積、歐氏距離等等。

有了向量，當(dāng)用戶提出問題時，處理過程就變成了將問題轉(zhuǎn)換為向量，然后計算向量之間的距離，找到與問題向量最接近的文檔向量，從而實現(xiàn)“語義”的匹配。

在開源社區(qū)里，已經(jīng)有很多人提供了這樣的模型，我們需要做的就是把模型部署起來，然后，調(diào)用這個模型。當(dāng)然，也有人把已經(jīng)訓(xùn)練好的模型部署成一個服務(wù)，這樣，我們就可以直接調(diào)用現(xiàn)成的服務(wù)。

OpenAI 就提供了一個專門負(fù)責(zé)將文本轉(zhuǎn)換成向量的 API——Embeddings。

我們可以根據(jù)需要，選擇自己部署模型，或是選擇別人提供的服務(wù)。不同的 Embedding 模型之間的差異主要取決于訓(xùn)練樣本，比如有的模型會在中文處理上表現(xiàn)得比較好。到這里，我們知道了可以用向量進(jìn)行文本內(nèi)容的匹配。但是，我們要到哪里去匹配呢？

正如我們處理任何業(yè)務(wù)數(shù)據(jù)一樣，在使用數(shù)據(jù)之前，第一步需要做的是，存儲業(yè)務(wù)數(shù)據(jù)。在 RAG 系統(tǒng)中，我們要把數(shù)據(jù)存放到哪里呢？我們需要一個數(shù)據(jù)庫，只不過，我們需要的既不是 Oracle、MySQL 這樣的關(guān)系數(shù)據(jù)庫，也不是 MongoDB、Redis 這樣的 NoSQL 數(shù)據(jù)庫。因為我們后續(xù)處理的都是向量，所以，我們需要的是向量數(shù)據(jù)庫。

向量數(shù)據(jù)庫并不是突然冒出來的。2000 年左右，加州大學(xué)伯克利分校的研究人員開始嘗試開發(fā)向量數(shù)據(jù)庫，用來存儲和查詢高維向量。2010 年，VectorWise 公司發(fā)布了第一個商業(yè)向量數(shù)據(jù)庫。隨著 AI 應(yīng)用的興起，人們對于向量數(shù)據(jù)庫的興趣日漸濃厚。在大模型興起之后，隨著 RAG 的蓬勃發(fā)展，向量數(shù)據(jù)庫一下子站到舞臺中央，開始成為許多大模型應(yīng)用的重要組件。

向量數(shù)據(jù)庫與傳統(tǒng)數(shù)據(jù)庫有很大的差別，在使用方式上，傳統(tǒng)數(shù)據(jù)庫搜索信息傾向于精確匹配，而向量數(shù)據(jù)庫的匹配則是語義上的接近。

在實現(xiàn)上二者也存在不小的差別，比如，由于向量本身通常維度會很多，如果按照傳統(tǒng)數(shù)據(jù)庫的方式直接進(jìn)行存儲，將會帶來很多問題。向量數(shù)據(jù)庫需要把向量數(shù)據(jù)作為一個完整的單元處理，底層存儲結(jié)構(gòu)也需要根據(jù)這個特點(diǎn)進(jìn)行規(guī)劃。另外，向量數(shù)據(jù)格式也相對單一，每個維度的數(shù)據(jù)往往都是固定的數(shù)據(jù)格式（浮點(diǎn)數(shù)、二進(jìn)制整數(shù)等）。

所以，向量數(shù)據(jù)庫就可以有針對性地找到一些優(yōu)化手段，比如，相關(guān)的數(shù)學(xué)運(yùn)算可以更好地利用 CPU 緩存機(jī)制加速，甚至可以利用 CPU/GPU 的硬件特性；再比如，采用高效的數(shù)據(jù)壓縮技術(shù)，這樣就能夠顯著地減少存儲空間。

索引

到這里，我們講的都是怎樣使用數(shù)據(jù)，也就是檢索的過程。其實，還有一個關(guān)鍵的問題沒有解決，這些數(shù)據(jù)從何而來，怎么跑到向量數(shù)據(jù)庫里去的。這就是 RAG 另外一個重要的過程：索引（Indexing）。

下面是一個常見的索引過程：

圖片

在這個過程里面，我們會先對信息源做一次信息提取。信息源可能是各種文檔，比如 Word 文檔、PDF 文件，Web 頁面，甚至是一些圖片。從這些信息源中，我們把內(nèi)容提取出來，也就是其中的文本。

接下來，我們會把這些文本進(jìn)行拆分，將其拆分成更小的文本塊。之所以要拆分，主要是原始的文本可能會比較大，這并不利于檢索，還有一點(diǎn)重要原因是，我們前面說過，要把檢索到的信息拼裝到提示詞里，過大的文本可能會造成提示詞超過模型有限的上下文窗口。

再來，就是把文本塊轉(zhuǎn)換成向量，也就是得到 Embedding 的過程。前面我們說過，這個過程往往是通過訓(xùn)練好的模型來完成的。到這里，我們就把信息轉(zhuǎn)換成了向量。最后一步，就是把得到的向量存儲到向量數(shù)據(jù)庫中，供后續(xù)的檢索使用。

至此，我們對常見的 RAG 流程已經(jīng)有了基本了解。但實際上，RAG 領(lǐng)域正處于一個快速發(fā)展的過程中，有很多相關(guān)技術(shù)也在不斷地涌現(xiàn)：

雖然采用向量搜索對于語義理解很有幫助，但一些人名、縮寫、特定 ID 之類的信息，卻是傳統(tǒng)搜索的強(qiáng)項，有人提出混合搜索的概念，將二者結(jié)合起來；

通過各種搜索方式，我們會得到很多的候選內(nèi)容，但到底哪個與我們的問題更相關(guān)，有人引入了重排序（Rerank）模型，以此決定候選內(nèi)容與查詢問題的相關(guān)程度；

除了在已有方向的努力，甚至還有人提出了 RAG 的新方向。我們前面討論的流程前提條件是把原始信息轉(zhuǎn)換成了向量，但這本質(zhì)上還是基于文本的，更適合回答一些事實性問題。它無法理解更復(fù)雜的關(guān)系，比如，我的朋友里誰在 AI 領(lǐng)域里工作。所以，有人提出了基于知識圖譜的 RAG，知識圖譜是一種結(jié)構(gòu)化的語義知識庫，特別適合找出信息之間的關(guān)聯(lián)。

由此你可以看到，想要打造一個好的 RAG 應(yīng)用并不是很容易的一件事，但在一些技術(shù)框架支持下，上手編寫一個 RAG 應(yīng)用卻不是什么難事。

總結(jié)

RAG 是 Retrieval-Augmented Generation 的縮寫，也就是檢索增強(qiáng)生成的意思。它主要是為了解決大模型本身知識匱乏的問題。RAG 應(yīng)用的主要流程包括索引、檢索和生成。

目前常見的 RAG 技術(shù)是依賴于將文本轉(zhuǎn)換成向量，以實現(xiàn)語義上的匹配。將文本轉(zhuǎn)成向量，我們通常會使用專門的 Embedding 模型，而對向量進(jìn)行檢索，則使用向量數(shù)據(jù)庫。索引就是把信息放到向量數(shù)據(jù)庫中，而檢索就是把信息提取出來，提取出來的信息與用戶提示詞合并起來，再到大模型去完成生成的過程。

如果今天的內(nèi)容你只能記住一件事，那請記住，RAG 是為了讓大模型知道更多的東西。