RAG面臨的挑戰和問題

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

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

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

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

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

由于這三個環節是串行的，準確率最終是三者的乘積，因而任何一個環節的短板都將導致整體的準確率完全無法保證。

目前來看，業界針對RAG的優化也主要是圍繞這三個環節開展

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

然而由于最終結果是三者的乘積，即便是耗費大量精力將每個環節都優化到90%，最終乘積也只有72%。

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

基于結構化數據來RAG

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

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

結構化數據的特點是數據的特征和屬性都是明確的，可以用有限的標簽集進行描述，可以用標準的查詢語言進行檢索。不用向量也可以RAG的方法的基本思路就是利用結構化數據和LLM的交互，避免數據向量化和語義搜索的問題，直接使用標準查詢和原始數據進行回復。

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

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

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

• 查詢結構化數據。LLM用這個查詢語句去檢索結構化數據，得到相關的數據記錄，例如：

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

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

這就是基于結構化數據RAG的基本流程，它的優勢和特點有以下幾點：

• 「準確」。基于結構化數據RAG避免了數據向量化和語義搜索的問題，直接利用原始數據和LLM的交互，提高了RAG的準確率。因為結構化數據的特征和屬性都是明確的，可以用有限的標簽集進行描述，可以用標準的查詢語言進行檢索，因此不會出現信息損失或語義不匹配的情況。而且，LLM只需要根據用戶的問題，提取出核心的信息和條件，并形成標準的查詢語句，而不需要理解整個文檔的語義，因此也減少了LLM的幻覺的可能性。
• 「高效」。基于結構化數據RAG提高了RAG的效率，因為它省去了數據向量化和語義搜索的過程，直接使用標準查詢和原始數據進行回復。數據向量化和語義搜索的過程是非常耗時和資源密集的，因為它們需要對海量的文本數據進行處理和計算，而且還需要存儲和更新大量的向量數據。而結構化數據RAG只需要對結構化數據進行標準查詢，這是一個非常快速和簡單的過程，而且結構化數據的存儲和更新也比向量數據更容易和更節省空間。
• 「靈活」。基于結構化數據RAG提高了RAG的靈活性，因為它可以適應不同的數據源和查詢需求，只要數據是結構化的，就可以用這種方法進行RAG。結構化數據是一種非常通用和廣泛的數據格式，它可以表示各種各樣的信息和知識，例如表格、數據庫、XML等。而且，結構化數據的查詢語言也是非常標準和通用的，例如SQL、SPARQL等。因此，結構化數據RAG的方法可以應用于不同的領域和場景，只要將用戶的問題轉化為相應的查詢語言，就可以實現RAG。
• 「易擴展」。基于結構化數據RAG提高了RAG的易擴展性，因為它可以方便地增加或修改數據和查詢，而不需要重新進行數據向量化和語義搜索。數據向量化和語義搜索的過程是非常固定和封閉的，一旦數據或查詢發生變化，就需要重新進行數據向量化和語義搜索，這是一個非常耗時和復雜的過程，而且可能會影響已有的數據和查詢的結果。而結構化數據RAG只需要對結構化數據進行增加或修改，就可以實現數據的更新，而且不會影響其他數據的查詢。而且，結構化數據RAG也可以方便地增加或修改查詢，只要修改查詢語句，就可以實現查詢的更新，而且不會影響其他查詢的結果。

基于結構化數據來RAG實戰

為了更好地展示結構化數據來RAG的方法的實際效果，我們以餐飲生活助手為例，給出用戶提問和回復的示例，以及餐飲生活助手RAG的代碼實戰。

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

為了實現餐飲生活助手RAG的Langchain代碼實戰，我們需要完成以下幾個步驟：

• 定義餐飲數據源。我們需要將餐飲數據集轉化為Langchain可以識別和操作的數據源，例如數據庫、文件、API等，注冊到Langchain中，并提供統一的接口和方法，讓LLM的代理可以方便地訪問和查詢數據源。例如，我們可以將餐飲數據封裝為一個API后，并結構化描述該接口的調用方式，并通過以下的代碼，將其注冊到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的代理，它可以根據用戶的問題，提取出核心的信息和條件，并形成標準的查詢語句，然后用這個查詢語句去檢索餐飲數據源，得到相關的數據記錄，再根據這些數據記錄，生成最合適的答案，輸出給用戶。這可以通過Langchain的代理（Agent）來實現。代理管理器可以讓開發者通過簡單的編程，定義不同的LLM的代理，以及它們的功能和邏輯，并提供統一的接口和方法，讓用戶可以方便地與LLM的代理進行交互。

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

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

餐飲生活助手

本文直接通過Langchain內置的openapi-function call來實現，代碼僅作為演示，實際業務情況可能得結合代碼內置業務流程來實現。比如通過function call解析用戶問題之前還需要判斷用戶的問題是否與餐廳咨詢相關，當解析到的查詢維度太少時，需要引導式提問等等。

總結和展望

隨著chatbot的流行，基于向量化的RAG模型似乎已然形成了RAG的標準模式。本文試圖跳出向量化的RAG模型的模式束縛，從RAG的基礎定義出發提出不用向量也可以RAG的想法。通過結構化數據和LLM的交互，這并非一種新穎的RAG模式，但在現階段，卻是讓chatbot達到可落地目標的最優手段。

本文轉載自 ??AI小智??，作者： AI小智