RAG面臨的挑戰(zhàn)和問題

在當(dāng)前AI的落地應(yīng)用中，最火熱的應(yīng)用首推檢索增強(qiáng)生成（Retrieval-Augmented Generation）。它的目的是根據(jù)用戶的問題，從一個大規(guī)模的文檔集合中檢索出相關(guān)的文檔，并從中抽取出最合適的答案。RAG的應(yīng)用場景非常廣泛，例如智能客服、知識圖譜構(gòu)建、對話系統(tǒng)等。

然而，幻覺是籠罩在RAG應(yīng)用上，揮之不去的烏云。一般來說RAG會經(jīng)歷，原始數(shù)據(jù)向量化->語義搜索數(shù)據(jù)召回->大模型整合輸出。RAG因此也面臨著一些挑戰(zhàn)和問題，其中最主要的有以下三個方面：

• 「數(shù)據(jù)向量化的信息損失」。為了實(shí)現(xiàn)高效的文檔檢索，通常需要將原始的文本數(shù)據(jù)轉(zhuǎn)化為數(shù)值向量，這一過程又稱為數(shù)據(jù)向量化（Data Embedding）。數(shù)據(jù)向量化的目的是將文本數(shù)據(jù)映射到一個低維的向量空間中，使得語義相似的文本在向量空間中的距離較近，而語義不相似的文本在向量空間中的距離較遠(yuǎn)。然而，數(shù)據(jù)向量化也會導(dǎo)致一定程度的信息損失，因?yàn)槲谋緮?shù)據(jù)的復(fù)雜性和多樣性很難用有限的向量來完全表達(dá)。因此，數(shù)據(jù)向量化可能會忽略一些文本數(shù)據(jù)的細(xì)節(jié)和特征，從而影響文檔檢索的準(zhǔn)確性。
• 「語義搜索的不準(zhǔn)確」。在RAG中，語義搜索（Semantic Search）是指根據(jù)用戶的問題，從文檔集合中檢索出與問題語義最相關(guān)的文檔，這一過程又稱為數(shù)據(jù)召回（Data Retrieval）。語義搜索的難點(diǎn)在于如何理解用戶的問題和文檔的語義，以及如何衡量問題和文檔之間的語義相似度。目前，語義搜索的主流方法是基于數(shù)據(jù)向量化的結(jié)果，利用向量空間中的距離或相似度來度量語義相似度。然而，這種方法也存在一些局限性，例如向量空間中的距離或相似度并不一定能反映真實(shí)的語義相似度，而且向量空間中的噪聲和異常值也會干擾語義搜索的結(jié)果。因此，語義搜索的準(zhǔn)確率也無法有100%的保證。
• 「LLM的幻覺」。在RAG中，LLM（Large Language Model）是指一個大規(guī)模的預(yù)訓(xùn)練語言模型，它的作用是根據(jù)用戶的問題和檢索到的文檔，生成最合適的答案，這一過程又稱為數(shù)據(jù)整合（Data Integration）。LLM的優(yōu)勢在于它能夠利用海量的文本數(shù)據(jù)進(jìn)行自我學(xué)習(xí)，從而具備強(qiáng)大的語言理解和生成能力。然而，LLM也存在一些問題，例如LLM可能會產(chǎn)生一些與事實(shí)不符或者邏輯不通的答案，這種現(xiàn)象又稱為LLM的幻覺（Hallucination）。LLM的幻覺的原因有很多，例如LLM的預(yù)訓(xùn)練數(shù)據(jù)可能存在一些錯誤或偏見，LLM的生成過程可能存在一些隨機(jī)性或不確定性，LLM的輸出可能受到一些外部因素的影響等。因此，LLM的準(zhǔn)確率也是不可靠的。

綜上所述，我們可以得到這樣一個公式，

RAG的輸出的準(zhǔn)確率=
向量信息保留率 * 語義搜索準(zhǔn)確率 * LLM準(zhǔn)確率

由于這三個環(huán)節(jié)是串行的，準(zhǔn)確率最終是三者的乘積，因而任何一個環(huán)節(jié)的短板都將導(dǎo)致整體的準(zhǔn)確率完全無法保證。

目前來看，業(yè)界針對RAG的優(yōu)化也主要是圍繞這三個環(huán)節(jié)開展

• 通過COT等方式提升LLM對問題的理解程度
• 使用sentence window retrive、rerank等方式提升語義搜索的準(zhǔn)確率
• 通過針對的選擇和優(yōu)化embedding算法來最大化的保留原始數(shù)據(jù)的信息。

然而由于最終結(jié)果是三者的乘積，即便是耗費(fèi)大量精力將每個環(huán)節(jié)都優(yōu)化到90%，最終乘積也只有72%。

那么，有沒有一種方法，可以避免數(shù)據(jù)向量化和語義搜索的問題，直接利用原始數(shù)據(jù)和LLM的交互，提高RAG的準(zhǔn)確率和效率呢？本文的目的就是介紹一種不用向量也可以RAG的方法，它基于結(jié)構(gòu)化數(shù)據(jù)和LLM的交互，實(shí)現(xiàn)了一種新穎的RAG模式，具有準(zhǔn)確、高效、靈活、易擴(kuò)展等優(yōu)勢。

基于結(jié)構(gòu)化數(shù)據(jù)來RAG

我們不妨換個思路，上文拆解的三個環(huán)節(jié)，LLM是自然語言對話的根基無可替代，但是RAG是否必須向量化，必須基于語義召回呢？

并非如此，在未引入LLM之前，傳統(tǒng)檢索信息的方式是通過將數(shù)據(jù)結(jié)構(gòu)話，將特征提前抽象為列，通過有限的標(biāo)簽集進(jìn)行描述，最終通過行式數(shù)據(jù)庫存儲，以標(biāo)準(zhǔn)sql來查詢。傳統(tǒng)數(shù)據(jù)檢索的方式勝在準(zhǔn)確且高效，弱勢則在于查詢存在一定門檻，交互上缺少人味。如果原始數(shù)據(jù)本身就是結(jié)構(gòu)化，標(biāo)簽化的，那么我們大可不必將這部分的數(shù)據(jù)做embeding。

結(jié)構(gòu)化數(shù)據(jù)的特點(diǎn)是數(shù)據(jù)的特征和屬性都是明確的，可以用有限的標(biāo)簽集進(jìn)行描述，可以用標(biāo)準(zhǔn)的查詢語言進(jìn)行檢索。不用向量也可以RAG的方法的基本思路就是利用結(jié)構(gòu)化數(shù)據(jù)和LLM的交互，避免數(shù)據(jù)向量化和語義搜索的問題，直接使用標(biāo)準(zhǔn)查詢和原始數(shù)據(jù)進(jìn)行回復(fù)。

基于這個思路，以餐飲生活助手為例，整體的交互處理思路如下：

• 用戶提問。用戶輸入一個自然語言的問題，例如“我們3個人想找個人均50左右的重慶火鍋店”。
• LLM提取核心信息并形成標(biāo)準(zhǔn)查詢。LLM根據(jù)用戶的問題，提取出核心的信息和條件，例如人數(shù)、價格、類型等，并形成一個標(biāo)準(zhǔn)的查詢語句，例如

{
    "numOfPeople": 3,
    "avgOfAmount": 50,
    "type": "重慶火鍋"
}

• 查詢結(jié)構(gòu)化數(shù)據(jù)。LLM用這個查詢語句去檢索結(jié)構(gòu)化數(shù)據(jù)，得到相關(guān)的數(shù)據(jù)記錄，例如：

{
    "shopType": 10,
    "shopName": "居民樓火鍋",
    "branchName": "萬松園店",
    "address": "萬松小區(qū)",
    "phoneNo": "17771857933",
    "phoneNo2": "18871569657"
}

• LLM整合回復(fù)。LLM根據(jù)這些數(shù)據(jù)記錄，生成最合適的答案，輸出給用戶，例如“按您的要求，我找到了居民樓火鍋店，位于萬松小區(qū)，電話是17771857933或18871569657，是一家重慶火鍋店，人均消費(fèi)50元，適合3個人用餐?！?/li>

這就是基于結(jié)構(gòu)化數(shù)據(jù)RAG的基本流程，它的優(yōu)勢和特點(diǎn)有以下幾點(diǎn)：

• 「準(zhǔn)確」?；诮Y(jié)構(gòu)化數(shù)據(jù)RAG避免了數(shù)據(jù)向量化和語義搜索的問題，直接利用原始數(shù)據(jù)和LLM的交互，提高了RAG的準(zhǔn)確率。因?yàn)榻Y(jié)構(gòu)化數(shù)據(jù)的特征和屬性都是明確的，可以用有限的標(biāo)簽集進(jìn)行描述，可以用標(biāo)準(zhǔn)的查詢語言進(jìn)行檢索，因此不會出現(xiàn)信息損失或語義不匹配的情況。而且，LLM只需要根據(jù)用戶的問題，提取出核心的信息和條件，并形成標(biāo)準(zhǔn)的查詢語句，而不需要理解整個文檔的語義，因此也減少了LLM的幻覺的可能性。
• 「高效」?；诮Y(jié)構(gòu)化數(shù)據(jù)RAG提高了RAG的效率，因?yàn)樗∪チ藬?shù)據(jù)向量化和語義搜索的過程，直接使用標(biāo)準(zhǔn)查詢和原始數(shù)據(jù)進(jìn)行回復(fù)。數(shù)據(jù)向量化和語義搜索的過程是非常耗時和資源密集的，因?yàn)樗鼈冃枰獙Ａ康奈谋緮?shù)據(jù)進(jìn)行處理和計(jì)算，而且還需要存儲和更新大量的向量數(shù)據(jù)。而結(jié)構(gòu)化數(shù)據(jù)RAG只需要對結(jié)構(gòu)化數(shù)據(jù)進(jìn)行標(biāo)準(zhǔn)查詢，這是一個非常快速和簡單的過程，而且結(jié)構(gòu)化數(shù)據(jù)的存儲和更新也比向量數(shù)據(jù)更容易和更節(jié)省空間。
• 「靈活」。基于結(jié)構(gòu)化數(shù)據(jù)RAG提高了RAG的靈活性，因?yàn)樗梢赃m應(yīng)不同的數(shù)據(jù)源和查詢需求，只要數(shù)據(jù)是結(jié)構(gòu)化的，就可以用這種方法進(jìn)行RAG。結(jié)構(gòu)化數(shù)據(jù)是一種非常通用和廣泛的數(shù)據(jù)格式，它可以表示各種各樣的信息和知識，例如表格、數(shù)據(jù)庫、XML等。而且，結(jié)構(gòu)化數(shù)據(jù)的查詢語言也是非常標(biāo)準(zhǔn)和通用的，例如SQL、SPARQL等。因此，結(jié)構(gòu)化數(shù)據(jù)RAG的方法可以應(yīng)用于不同的領(lǐng)域和場景，只要將用戶的問題轉(zhuǎn)化為相應(yīng)的查詢語言，就可以實(shí)現(xiàn)RAG。
• 「易擴(kuò)展」?；诮Y(jié)構(gòu)化數(shù)據(jù)RAG提高了RAG的易擴(kuò)展性，因?yàn)樗梢苑奖愕卦黾踊蛐薷臄?shù)據(jù)和查詢，而不需要重新進(jìn)行數(shù)據(jù)向量化和語義搜索。數(shù)據(jù)向量化和語義搜索的過程是非常固定和封閉的，一旦數(shù)據(jù)或查詢發(fā)生變化，就需要重新進(jìn)行數(shù)據(jù)向量化和語義搜索，這是一個非常耗時和復(fù)雜的過程，而且可能會影響已有的數(shù)據(jù)和查詢的結(jié)果。而結(jié)構(gòu)化數(shù)據(jù)RAG只需要對結(jié)構(gòu)化數(shù)據(jù)進(jìn)行增加或修改，就可以實(shí)現(xiàn)數(shù)據(jù)的更新，而且不會影響其他數(shù)據(jù)的查詢。而且，結(jié)構(gòu)化數(shù)據(jù)RAG也可以方便地增加或修改查詢，只要修改查詢語句，就可以實(shí)現(xiàn)查詢的更新，而且不會影響其他查詢的結(jié)果。

基于結(jié)構(gòu)化數(shù)據(jù)來RAG實(shí)戰(zhàn)

為了更好地展示結(jié)構(gòu)化數(shù)據(jù)來RAG的方法的實(shí)際效果，我們以餐飲生活助手為例，給出用戶提問和回復(fù)的示例，以及餐飲生活助手RAG的代碼實(shí)戰(zhàn)。

餐飲生活助手是一個基于結(jié)構(gòu)化數(shù)據(jù)RAG的方法的應(yīng)用，它的目的是根據(jù)用戶的需求，從一個大規(guī)模的餐飲數(shù)據(jù)集中檢索出最合適的餐廳，并提供相關(guān)的信息和服務(wù)。餐飲數(shù)據(jù)集是一個結(jié)構(gòu)化的數(shù)據(jù)集，它包含了各種各樣的餐廳的信息，例如名稱、類型、地址、電話、價格、評分、評論等。餐飲生活助手的核心是一個LLM，它能夠根據(jù)用戶的問題，提取出核心的信息和條件，并形成標(biāo)準(zhǔn)的查詢語句，然后用這個查詢語句去檢索餐飲數(shù)據(jù)集，得到相關(guān)的數(shù)據(jù)記錄，再根據(jù)這些數(shù)據(jù)記錄，生成最合適的答案，輸出給用戶。

為了實(shí)現(xiàn)餐飲生活助手RAG的Langchain代碼實(shí)戰(zhàn)，我們需要完成以下幾個步驟：

• 定義餐飲數(shù)據(jù)源。我們需要將餐飲數(shù)據(jù)集轉(zhuǎn)化為Langchain可以識別和操作的數(shù)據(jù)源，例如數(shù)據(jù)庫、文件、API等，注冊到Langchain中，并提供統(tǒng)一的接口和方法，讓LLM的代理可以方便地訪問和查詢數(shù)據(jù)源。例如，我們可以將餐飲數(shù)據(jù)封裝為一個API后，并結(jié)構(gòu)化描述該接口的調(diào)用方式，并通過以下的代碼，將其注冊到Langchain中：

from langchain.chains.openai_functions.openapi import get_openapi_chain

fucntion_call_template = '{"openapi":"3.0.1","info":{"version":"v1","title":"Restaurant Query API"},"servers":[{"url":"https://www.example.com"}],"paths":{"/restaurant":{"post":{"tags":["restaurant-query"],"summary":"Query restaurants","operationId":"queryRestaurants","requestBody":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/QueryRequest"}}}},"responses":{"200":{"description":"Query results","content":{"application/json":{"schema":{"$ref":"#/components/schemas/QueryResponse"}}}}}}}},"components":{"schemas":{"QueryRequest":{"type":"object","properties":{"numOfPeople":{"type":"integer","description":"Number of people dining"},"avgOfAmount":{"type":"integer","description":"Average spending amount per person"},"type":{"type":"string","description":"Cuisine type"}}},"QueryResponse":{"type":"object","properties":{"shopType":{"type":"integer","description":"Restaurant type code"},"shopName":{"type":"string","description":"Restaurant name"},"branchName":{"type":"string","description":"Branch name"},"address":{"type":"string","description":"Address"},"phoneNo":{"type":"string","description":"Phone number"},"phoneNo2":{"type":"string","description":"Secondary phone number"}}}}}}'

chain = get_openapi_chain(
    spec = fucntion_call_template
)

• 定義LLM的代理。我們需要定義一個LLM的代理，它可以根據(jù)用戶的問題，提取出核心的信息和條件，并形成標(biāo)準(zhǔn)的查詢語句，然后用這個查詢語句去檢索餐飲數(shù)據(jù)源，得到相關(guān)的數(shù)據(jù)記錄，再根據(jù)這些數(shù)據(jù)記錄，生成最合適的答案，輸出給用戶。這可以通過Langchain的代理（Agent）來實(shí)現(xiàn)。代理管理器可以讓開發(fā)者通過簡單的編程，定義不同的LLM的代理，以及它們的功能和邏輯，并提供統(tǒng)一的接口和方法，讓用戶可以方便地與LLM的代理進(jìn)行交互。

# 通過Langchain內(nèi)置的openapi-function call來實(shí)現(xiàn)復(fù)雜邏輯內(nèi)置在函數(shù)內(nèi)了
chain("我們3個人想找個人均50左右的重慶火鍋店")

• 運(yùn)行LLM的代理。我們需要運(yùn)行LLM的代理，讓用戶可以與之進(jìn)行交互，將LLM的代理部署到不同的平臺和渠道，例如Web、微信、Telegram等，并提供統(tǒng)一的接口和方法，讓用戶可以方便地與LLM的代理進(jìn)行交互。

餐飲生活助手

本文直接通過Langchain內(nèi)置的openapi-function call來實(shí)現(xiàn)，代碼僅作為演示，實(shí)際業(yè)務(wù)情況可能得結(jié)合代碼內(nèi)置業(yè)務(wù)流程來實(shí)現(xiàn)。比如通過function call解析用戶問題之前還需要判斷用戶的問題是否與餐廳咨詢相關(guān)，當(dāng)解析到的查詢維度太少時，需要引導(dǎo)式提問等等。

總結(jié)和展望

隨著chatbot的流行，基于向量化的RAG模型似乎已然形成了RAG的標(biāo)準(zhǔn)模式。本文試圖跳出向量化的RAG模型的模式束縛，從RAG的基礎(chǔ)定義出發(fā)提出不用向量也可以RAG的想法。通過結(jié)構(gòu)化數(shù)據(jù)和LLM的交互，這并非一種新穎的RAG模式，但在現(xiàn)階段，卻是讓chatbot達(dá)到可落地目標(biāo)的最優(yōu)手段。

本文轉(zhuǎn)載自 ??AI小智??，作者： AI小智