譯者 | 李睿

審校 | 重樓

將RAG與知識圖譜相結合可以提高生成式人工智能應用程序的準確性，可以使用現有的數據庫來完成。

生成式人工智能依賴于數據來構建對用戶查詢的響應。而訓練大型語言模型(LLM)需要使用大量數據，例如OpenAI公司的GPT-3使用了CommonCrawl數據集進行訓練，該數據集擁有570GB字節的數據和4000億個令牌。雖然這些數據集的規模龐大，但都是時間快照，無法響應圍繞當前發生的事件的查詢。人工智能的反應也可能包括“幻覺”——提供看似合理但并不真實的信息。根據Vectara公司發布的幻覺排行榜，即使是表現最好的LLM系列 (目前是OpenAI公司開發的產品)，也存在1.5%至1.9%的幻覺率。

因此，單獨使用LLM面臨兩個問題：答案可能過時或者錯誤。為了克服這些潛在的問題，組織可以使用數據流將新信息獲取到他們的數據集中，并部署檢索增強生成（RAG）以與生成式人工智能一起使用的方式對業務數據進行編碼。

RAG創建了一組數據，可以搜索與用戶查詢相關的語義匹配，然后將這些匹配與LLM共享，以便包含在響應中。隨著時間的推移，向量數據集可以添加新的或額外的數據，因此可以將相關和及時的數據包含在響應中。

RAG面臨的挑戰

盡管RAG使組織能夠將自己的數據與生成式人工智能服務結合使用，但它并不完美。在將RAG部署到生產環境中遇到的一個挑戰是，它無法處理包含相似或相同信息的大量文檔之間的搜索。當這些文件被分塊并轉換成向量嵌入時，每個文件都有可供搜索的數據。當這些文件中的每一個都有非常相似的塊時，找到與該請求匹配的正確數據會變得更加困難。當查詢的答案存在于多個相互交叉引用的文檔中時，RAG也會遇到困難。而RAG不知道這些文檔之間的關系。

例如，假設組織已經開發了一款聊天機器人服務，它可以調用其產品數據來回答客戶的查詢。組織已經將小部件目錄轉換為向量數據，但是這些小部件都非常相似。當客戶查詢聊天機器人時，即使有RAG，如何確保提供的響應是準確的？如果這些目錄包含指向其他具有額外場景的文檔的鏈接怎么辦？提出不準確的建議或提供不準確的查詢將影響客戶互動。

回答這個問題是考慮采用一種不同的知識管理方法，為RAG所擅長的工作提供補充。微軟研究院在今年早些時候發布了一份關于將知識圖譜和RAG結合使用的研究報告，其中包括一種名為GraphRAG的技術。

知識圖譜將數據點表示為“節點”和“邊”，而不是將數據存儲在傳統搜索的行和列中，也不是作為向量搜索的嵌入。節點將是一個獨特的事實或特征，并且邊將連接與該事實有相關關系的所有節點。在產品目錄的示例中，節點可能是單個產品，而邊將是每個產品所具有的相似特征，例如尺寸或顏色。

向知識圖譜發送查詢涉及查找與該搜索相關的所有實體，然后創建一個知識子圖，將這些實體匯集在一起。這樣可以檢索出與查詢相關的信息，然后將其返回給LLM并用于構建響應。這意味著可以處理具有多個相似數據源的問題。與其將每個源視為不同的源并多次檢索相同的數據，不如只檢索一次數據。

在RAG中使用知識圖譜

要在RAG應用程序中使用知識圖譜，組織可以使用現有的、經過測試且已知事先正確數據的知識圖譜，也可以創建自己的知識圖譜。當組織使用自己的數據（例如產品目錄）時，需要整理數據并檢查其準確性。

組織可以使用自己的生成式人工智能方法來幫助實現這一目標。LLM的構建是為了從內容中提取信息，并在需要時對數據進行匯總。對于知識圖譜，可以自動地以正確的格式構建數據，并且隨著時間的推移添加更多的數據，支持對知識圖譜的任何更新或更改。流行的LangChain服務上有多個工具可以查詢文件，然后提供知識圖譜，包括LLM Graph Transformer和Diffbot，而知識提取工具REBEL是另一種選擇。

對于專用的圖分析項目，可能需要采用一個完整的圖數據庫，該數據庫可以使用Gremlin和Cipher等圖形語言運行完整的查詢。然而，為了支持作為RAG應用程序一部分的知識圖譜請求，只需要運行同時覆蓋兩三個節點的小搜索。這意味著請求通常會表示為幾輪簡單的查詢（每步一個）或SQL連接的形式。在更大的數據集中進行搜索不太可能返回正確的響應——事實上，這可能會導致查詢失控，這些查詢處理時間過長或實際上無法改善整體響應。

因此，可以使用現有的數據庫來存儲知識圖譜數據，而不是部署額外的圖數據庫。這也簡化了數據運營方面的工作，因為可以減少隨時間推移而需要更新新數據的數據平臺數量。

將知識圖譜與RAG相結合可以提高生成式人工智能應用程序在響應用戶查詢時的準確性。通過將不同的數據管理技術相結合，可以在數據性能和請求中的語義理解方面獲得兩全其美的效果。

原文標題：Overcoming AI hallucinations with RAG and knowledge graphs，作者：Dom Couldwell