概述
????????跟Function calling一樣，RAG的出現(xiàn)也是因為大模型無法完全滿足實際業(yè)務需求，主要有以下幾方面原因：
- 知識的局限性：模型自身的知識完全源于它的訓練數(shù)據(jù)，而現(xiàn)有的主流大模型的訓練集基本都是構(gòu)建于網(wǎng)絡公開的數(shù)據(jù)，對于一些實時性的、非公開的或離線的數(shù)據(jù)是無法獲取到的，這部分知識也就無從具備。
- 幻覺問題：所有的AI模型的底層原理都是基于數(shù)學概率，其模型輸出實質(zhì)上是一系列數(shù)值運算，大模型也不例外，所以它有時候會一本正經(jīng)地胡說八道，尤其是在大模型自身不具備某一方面的知識或不擅長的場景。而這種幻覺問題的區(qū)分是比較困難的，因為它要求使用者自身具備相應領(lǐng)域的知識。
- 數(shù)據(jù)安全性：對于企業(yè)來說，數(shù)據(jù)安全至關(guān)重要，沒有企業(yè)愿意承擔數(shù)據(jù)泄露的風險，將自身的私域數(shù)據(jù)上傳第三方平臺進行訓練。這也導致完全依賴通用大模型自身能力的應用方案不得不在數(shù)據(jù)安全和效果方面進行取舍。
????????而RAG是解決上述問題的一套有效方案，前段時間參考一個開源的RAG項目，研究了一下RAG的工作流程，簡單記錄如下：
????????本文主要介紹一下RAG（Retrieval-Augmented Generation）的工作流程，包括根據(jù)數(shù)據(jù)類型創(chuàng)建文檔加載器、對加載的文檔進行分割、將分割后的文檔向量化存儲到向量數(shù)據(jù)庫、根據(jù)用戶問題查找相關(guān)向量并還原成原始文本發(fā)送給 LLM 以獲取答案。
關(guān)鍵要點包括：
- 文檔加載：根據(jù)數(shù)據(jù)類型創(chuàng)建不同的 Loader，返回文檔對象。
- 文檔分割：因數(shù)據(jù)量大需分割成塊后存儲。
- 向量存儲：文檔塊經(jīng)嵌入操作轉(zhuǎn)換成向量存儲在向量數(shù)據(jù)庫。
- 向量查找：用戶問題轉(zhuǎn)換成向量與數(shù)據(jù)庫中的向量比較，找出相關(guān)的 n 個向量。
- 答案生成：相關(guān)向量還原成文本發(fā)送給 LLM 生成答案。
整體流程如下：
文件加載分割
????????需要根據(jù)數(shù)據(jù)類型創(chuàng)建不同類型的文檔加載器Loader，加載完外部數(shù)據(jù)以后會返回一個文檔對象；
????????當數(shù)據(jù)被加載以后，接下來就來到了文檔分割(Splitting)的環(huán)節(jié)，由于外部數(shù)據(jù)量可能比較大，如pdf、text、md文檔等產(chǎn)生的文檔數(shù)量或體量比較大，因此需要對外部數(shù)據(jù)文檔進行分割(Splitting)成塊(chunks)；
????????代碼簡單實現(xiàn)如下：
docs = ReadDataFiles('./data').get_content(max_token_len=450, cover_content=50)
向量存儲
????????向量存儲是指被分割的文檔需要先經(jīng)過向量化操作然后存儲到向量數(shù)據(jù)庫的過程，因為大語言模型(LLM)無法理解文字信息(只能理解數(shù)字)，因此必須對文字信息進行編碼，這里編碼指的是只嵌入(Embeddings)，嵌入操作可以將文本轉(zhuǎn)換成數(shù)字編碼并以向量的形式存儲在向量數(shù)據(jù)庫中，如下圖所示：
????????代碼簡單實現(xiàn)如下：
vector = VectorStore(docs)
# 創(chuàng)建EmbeddingModel
embedding = DashscopeEmbedding()
vector.get_vector(EmbeddingModel=embedding)
# 將向量化數(shù)據(jù)和文檔內(nèi)容切片存儲到storage目錄下，使用時可以直接加載本地的數(shù)據(jù)庫
vector.persist(path='storage')
向量查找
????????當文檔被分割成塊(chunks)后，每一個塊都會經(jīng)嵌入(Embedding)操作后轉(zhuǎn)換成向量并存儲在向量數(shù)據(jù)庫中，當用戶對文檔內(nèi)容提出問題時，用戶的問題也會經(jīng)嵌入操作后被轉(zhuǎn)換成向量并與向量數(shù)據(jù)庫中的所有向量做相似度比較，最后找出與問題最相關(guān)的n個向量，如下圖所示：
????????當找到與用戶問題最相關(guān)的n個向量以后，這些向量會被還原成原始文本；
????????代碼簡單實現(xiàn)如下：
content = vector.query(question, EmbeddingModel=embedding, k=3)
????????然后將用戶的問題和這些文本信息發(fā)送給LLM，LLM會針對用戶的問題對這些文本內(nèi)容做提煉和匯總，最后給出正確合理的答案。
????????代碼簡單實現(xiàn)如下：
summary = DashscopeSummary()
answer = summary.summary(question, content)
PROMPT_TEMPLATE = """使用以上下文來回答詢問的問題。如果你不知道答案，就說你不知道。總是使用中文回答。
問題: {question}
可參考的上下文：
···
{context}
···
如果給定的上下文中沒有匹配的內(nèi)容無，則輸出“抱歉，您可以換一個問題”。
有用的回答:"""
msg = [{'role': 'user', 'content': PROMPT_TEMPLATE.format(question=question, context=content)}]
實戰(zhàn)
????????根據(jù)RAG的工作流程，簡單的做了一個嘗試，以Android11.0最新Framework解析.pdf作為知識庫，進行問題查詢，效果如下：
????????本文主要是對RAG的工作流程做了個簡單的介紹，持續(xù)學習中，后續(xù)有新的收獲再進行更新...
