在這篇文章中，我們來詳細探討知識圖譜（KG）在RAG流程中的具體應用場景。
緣起
關於知識圖譜在現在的RAG中能發揮出什麼樣的作用，之前看了360 劉煥勇的一個分享，簡單的提了使用知識圖譜增強大模型的問答效果的幾個方面：
- 在知識整理階段，用知識圖譜將文檔內容進行語義化組織；
- 在意圖識別階段，用知識圖譜進行實體別稱補全和上下位推理【受控 改寫】
- 在Prompt組裝階段，從知識圖譜中查詢背景知識放入上下文【精準召 回】；
- 在結果封裝階段，用知識圖譜進行知識修正和知識溯源。【自我修正】
這個分享中，只是粗略的介紹了用知識圖譜去語義化組織文檔，缺乏深度，於是查閱相關資料，翻到WhyHow.AI 的聯合創始人(Co-Founder)Chia Jeng Yang的一篇文 Injecting Knowledge Graphs in different RAG stages，這篇文章較爲詳細的介紹了KG在RAG各個階段的可能得應用方式，在這裏分享給大家。
RAG 階段
我們將RAG分爲下面幾個階段：
- 階段1：預處理 ，通常是提取chunk分塊之前的預處理。
- 階段2/D：chunk提取
- 階段3-5：後處理，用檢索到的信息生成答案
查詢增強（Query Augmentation）**
預處理 階段 ，這裏主要 在執行檢索之前，向查詢添加上下文。
爲什麼：有的查詢裏可能包含一些縮寫術語等，需要增加必要的上下文，去修正這些不好的queries
典型的就是，不同的行業有自己專有術語，這個LLM可能並不能準確的理解，從而導致理解錯誤。比如在英語裏，‘beachfront’ homes and ‘near the beach’ homes 代表不同類型的房產（海濱”房屋和“靠近海灘”的房屋），不能互換使用。在預處理階段注入這一上下文，有助於獲得更精確的回答。
KG的一個常見應用場景，也是幫助企業構建縮略詞詞典，以便搜索引擎可以有效識別問題或文檔中的縮略詞。
另外，可以使用KG來幫助做多跳推理，也就是做一些query擴展，簡單的做法就是在KG中存儲實體的查詢規則，通過信息化系統，可以讓非技術用戶也就是運營同學來構建和修改規則及關係，靈活的控制RAG規則。例如，某個規則可以看起來像這樣：“當回答有關休假政策的問題時，首先參考辦公室人力資源政策文件，然後在文件中查看有關假期的部分“。
再擴散一點，對於特定類型的概念，比如搜索企業家，那麼用戶可能瞭解他的個人資料 最新消息 職業生涯等信息，這個可以在kg中建立這種rule。
之前分析過祕塔搜索，應該是基於LLM對query做了一些改寫和擴展，比如下圖：
LLM 有成本和不可控的因素，用KG rule的方式來做的話，或者兩者結合，會更可控，方便運營維護。
chunk 分塊提取
其實這裏就是最早提到的，如何用知識圖譜將文檔內容進行語義化組織。這裏劉的分享裏提到：
文檔中包括圖表、標題、目錄、表格、段落等層級信息，利用知識圖譜結構存儲文檔佈局信息，從文檔中提取出邏輯層級結構、文本內容、表格內容、Key-Value鍵值字段、樣式信息等。基於對文檔的內容信息、版面信息和邏輯信息的分析理解，以結構化數據的形態輸出抽取結果。
ppt的圖裏給了一個示意：
這裏的問題是，這樣組織了，如何有效的使用，分享裏未有效提及。在Yang的文章中，也有提及建立層次化的文檔結構。
相關原因：這用於快速識別文檔層次結構中相關的chunks，並允許你使用自然語言來創建規則，規定在生成響應之前，查詢必須參考哪些文檔/塊。
- KG 可以是文檔描述的層次結構，引用存儲在向量數據庫中的chunk
- KG 也可以是文檔層次結構的規則。例如，在一個風險投資基金的 RAG 系統中，可以編寫一條自然語言規則，“要回答有關投資者義務的問題，首先檢查投資者在投資者投資組合列表中投資了什麼，然後檢查所述投資組合的法律文件”
另外，還有一種 metadata kg（元數據知識圖譜）的方案，也就是建立contextual dictionary，這對於理解重要主題包含在哪些文檔塊中很有用。這類似於書後的索引：
上面的圖片中，給出了重要的概念所在的page，對於RAG系統，其實就是哪些重要的chunk id。比如，可以對於一個實體，定義需要檢索的chunk，擴大一點可以是doc。
舉個例子，你可以加入自然語言規則，“任何與幸福概念有關的問題，你都必須對定義的contextual dictionary相關塊進行詳盡搜索，在執行檢索時，LLM會轉換成一個Cypher 查詢語句，從KG裏查詢關聯的chunk，然後從這些chunk裏去檢索，可以提高速度和準確率。
後處理 遞歸知識圖譜查詢
這裏提到了一個遞歸知識圖譜查詢的概念，大概的意思就是將查詢的信息，存儲到KG中，如果上下文不足，再次檢索，將提取的答案保存在同一KG中，並重復此過程，類似COT一樣，用KG來存儲檢索到的結果，這個感覺demo的意味居多。
實際案例
作者給了一個醫療領域的例子。
比如query：“阿爾茨海默病治療的最新研究是什麼？”利用上述策略來做RAG.
-
查詢增強： 對於問題——“阿爾茨海默病治療的最新研究是什麼？”通過訪問知識圖譜，LLM代理可以持續檢索有關最新阿爾茨海默病治療的結構化數據，比如“膽鹼酯酶抑制劑”和“美蘭汀”。 然後RAG系統隨後就可以將問題增強爲更具體的問題：“關於膽鹼酯酶抑制劑和美蘭汀在阿爾茨海默病治療中的最新研究是什麼？”
-
文檔層次結構和向量數據庫檢索：
- 使用文檔層次結構，確定哪些文檔和chunk塊與“膽鹼酯酶抑制劑”和“美蘭汀”最相關，並返回相關答案。
- 關於“膽鹼酯酶抑制劑”的相關信息塊提取規則有助於指導查詢引擎提取最有用的chunks。
- 文檔層次結構幫助查詢引擎快速識別與副作用相關的文檔，並開始提取文檔內的chunk。
- contextual dictionary字典幫助查詢引擎快速識別與“膽鹼酯酶抑制劑”相關的chunk，並開始提取與該主題相關的chunk。
- 關於“膽鹼酯酶抑制劑”的已建立規則指出，關於膽鹼酯酶抑制劑副作用的查詢還應檢查與酶X相關的chunk，這是因爲酶X是一個不容忽視的已知副作用，相關的塊相應地被包括在內。
-
遞歸知識圖譜查詢： 使用遞歸知識圖譜查詢，初始查詢返回了“美蘭汀”的一個副作用，稱爲“XYZ效應”。 “XYZ效應”被存儲在一個單獨的知識圖譜中，用於遞歸上下文。 LLM被要求檢查帶有XYZ效應附加上下文的新增強查詢。根據以往格式化的答案，它確定需要更多有關 XYZ 作用的信息才能得到滿意的答案。然後，它在知識圖譜中XYZ效應節點內進行更深入的搜索，從而執行多跳查詢。 在XYZ效應節點內，它發現了可以包含在答案中的臨牀試驗A和臨牀試驗B的信息。
-
塊控制訪問 儘管臨牀試驗A和B都包含有用的上下文，但與臨牀試驗B節點相關的元數據標籤指出，該節點的訪問受用戶限制。因此，一個常設的控制訪問規則防止將臨牀試驗B節點包含在對用戶的響應中。 只有關於臨牀試驗A的信息被返回給LLM，以幫助制定其返回的答案。
-
增強響應： 作爲後處理步驟，您還可以選擇使用特定於醫療行業的知識圖譜增強後處理輸出。例如，您可以包含針對美蘭汀治療的默認健康警告，或包含與臨牀試驗A相關的任何額外信息。
-
塊個性化： 存儲了用戶是研發部門的初級員工的額外上下文，並且用戶被限制訪問臨牀試驗B的信息，答案是增強了一張提示信息，說明他們被禁止訪問臨牀試驗B的信息，並被告知向高級經理尋求更多信息。
總結
知識圖譜KG如何更好的利用在RAG裏，是一個值得深入探討的好話題，本文探討了知識圖譜在RAG不同階段能產生的作用，不妨去試一試，後續我們會基於一些案例來實際探討。