【RAG 】From Local to Global: A Graph RAG Approach to Query-Focused Summarization

--- slideOptions: transition: slide --- # From Local to Global: A Graph RAG Approach to Query-Focused Summarization --- ## 傳統的RAG運作邏輯與缺點 我們熟知的檢索增強生成(RAG)技術，是將外部資料(來自於資料庫、或是非結構化的文檔)切割成一小塊一小塊的chunk，透過文字編碼器轉換為向量空間當使用者查詢時，將提示詞也轉換為向量進行比對，得到最相關的資料做為參考 ![173035768398494_P30757391](https://admin.bentoml.com/uploads/simple_rag_workflow_091648ef39.png) https://www.bentoml.com/blog/building-rag-with-open-source-and-custom-ai-models ---- ### RAG的缺陷 1. RAG不適合應用在聚焦摘要任務(query-focused summarization, QFS)上: 2. 模型本身的上下文長度限制，導致資料遺失: ---- #### RAG不適合應用在聚焦摘要任務由於傳統RAG會將資料文檔作切割才放入向量資料庫內，容易導致在檢索時無法捕捉到全局的語義特打個比方:傳統RAG可以回答出右上方的拼圖是粉色，但卻無法得知整個拼圖拼完後會是一個正方形 ![image](https://hackmd.io/_uploads/SJil5i7wke.png) ---- #### 模型本身的上下文長度限制，導致資料遺失有兩種情況可能導致此問題發生 1. 需要處理的文本量超過了 LLM 的上下文窗口限制，可能會導致資訊遺失 2. 即使在 LLM 的上下文窗口內，較長的上下文也可能導致資訊「遺失在中間」 (但在*LLM In-Context Recall is Prompt Dependent*這篇有表明每個LLM回憶事實的長度都不同) --- ## Graph RAG的運作方式索引階段可以事先完成，也是耗時最久的部分 ![image-39](https://hackmd.io/_uploads/rktFnp7v1g.png) ---- ### 1.來源文件到文本塊 (Source Documents → Text Chunks) ![image](https://hackmd.io/_uploads/SJo0sCmvyl.png) * 從來源文件中提取文本，並將其分割成較小的文本塊 * 文本塊對的影響: * 大:更少的LLM呼叫次數，但上下文回憶率會降低 * 小:可以檢測到更多實體，貴 ---- ### 2.文本塊到元素實例 (Text Chunks → Element Instances) ![image](https://cdn.sanity.io/images/bbnkhnhl/production/6ed38f0c8c1cb015e28a9c3ac6b1feb8bde6c167-1464x680.jpg?w=3840&q=75&fit=clip&auto=format =500x) * 每個Chunk內使用LLM提取所有實體(名詞、描述…)和邊(關係)、聲明(證明) * 可以把所提供資料的領域知識作為樣本進行上下文學習 * 好處:容易理解特定領域的專有名詞(醫療、資訊...) * "拾穗":透過提示詞檢測是否有遺漏的實體，如果有就再執行一次提取 ---- #### 舉個例子: ![o_1dluorltd1gn7m25176e1slkm3u43](https://hackmd.io/_uploads/S1aKSy4v1g.jpg =500x) * 實體:海綿寶寶是比其堡的居民 * 邊:海綿寶寶跟派大星是好朋友 * 聲明:海綿寶寶跟派大星常在比奇堡一起玩 ---- #### 拾穗(gleanings)的詳細步驟 * 1.LLM分析chunk內的文字，提取其中的實體 * 2.評估是否已提取所有實體，將logits bias(LLM的參數，控制是否輸出特定文字)設為100強制讓輸出只有YES或NO * 3.如果為NO，則在下次提取時付加上"MANY entities were missed in the last extraction"這段提示詞 * 4.重複執行直到設定次數上限 ---- ### 3.元素實例到元素摘要 (Element Instances → Element Summaries) ![image](https://hackmd.io/_uploads/HJ-xeJNwkl.png =300x) * 將收集到的實體、邊、聲明做一個整合，合併重複的部分 * 潛在的問題:LLM不一定能以相同格式提取本應該相同的實體 ---- ### 4.元素摘要到圖形社群 (Element Summaries → Graph Communities) ![image](https://miro.medium.com/v2/resize:fit:1400/1*HTpa_ZM5COzCqK03nN60pw.png =350x) * 之前的產生的東西都可以視作一張無向加權圖 * 使用社群檢測演算法(Leiden)挖掘所有圖之間的層級社群結構，相互連接更強的元素被歸類於相同的社區 * 讓每個階層的總結可以實現一個分而治之的全域總結 ---- ### 5.圖形社群到社群摘要 (Graph Communities → Community Summaries) ![image](https://hackmd.io/_uploads/SyM6Ok4w1g.png =300x) * 讓LLM為Leiden階層結構中每個社群作一個總結，獲得不同細粒度上宏觀理解 * 社群摘要的產生方式依社群類型分成兩種: * 葉節點層級社群 (Leaf-level communities) * 較高層級社群 (Higher-level communities) ---- #### 葉節點層級社群 (Leaf-level communities) 處理步驟如下: 1.根據社群內邊的節點度(node 的 subtree 數量?) 來優先處理邊的資訊。節點度越高，表示該節點子樹越多，在社群內越重要 2. 依照邊的優先順序添加到 LLM 的上下文窗口中，直到token上限 ---- #### 較高層級社群 (Higher-level communities) 處理步驟如下: 1.如果所有元素加起來不會超過token上限，就如葉節點一樣處理 2. 如果超出:在此社群下找到一個子社群不會超出token上限的做摘要替代主社群 ---- ### 6.社群摘要到社群答案到全局答案 (Community Summaries → Community Answers → Global Answer) * 用戶提問 * 將社群摘要打亂，將其分為預先指定的 token 大小的區塊，確保相關資訊分佈在各個區塊中 * 每個社群摘要都生成一個答案，並透過LLM對於回答目標問題的幫助程度打分 * 按照幫助程度分數的降序排序，放入context中生成最終回答 --- ## 實驗結果 ---- * 測試資料集 * 科技Podcast對話文字稿約100萬個token，由1669個600-token的文本塊組成 * 各類新聞文章，約170萬個token，由3197個600-token的文本塊組成 * 問題來源 * 根據資料集描述，使用LLM生成關於潛在用戶與任務的可能問題 * 評估指標 * 使用LLM evaluator評估回答的全面性、多樣性、賦能性、直接性，比較出勝者 * 評估對象 * C0~C3高到低社群層級 * TS (文本摘要):使用map-reduce做摘要的RAG * 普通RAG ---- * LLM模型 * gpt-4-turbo * 上下文長度 * 8k,16k,32k,64k，實驗發現8K擁有最高的勝率(58.1%) ---- 全面性和多樣性上GraphRAG在勝率上皆為最佳，TS其次，直接性最好的是普通RAG ![image](https://hackmd.io/_uploads/HyNsw74v1e.png =500x) ---- Graph RAG 在資源消耗方面具有優勢 C3比TS需要少 26-33% 的上下文token C0需要少97%以上的token ![image](https://hackmd.io/_uploads/SJ2RlVVwkg.png) ---- 比較拾穗次數跟區塊大小如何影響提取實體數: 實驗表明600token具有最大提取量，拾穗次數增加也能有效增加實體數 ![image](https://hackmd.io/_uploads/HJjbSlTwye.png) --- ## 總結 * GraphRAG替代了傳統RAG的向量化步驟，使用LLM建構知識樹進行彙整 * 能提升LLM回覆的全面性和多樣性並減少TOKEN消耗量 * 實體收集的穩定性存在問題，且索引階段消耗大量資源 ![image](https://miro.medium.com/v2/resize:fit:1254/1*naZhhiKaw5C_qA7e4vWRvQ.png =500x) (https://medium.aiplanet.com/implement-rag-with-knowledge-graph-and-llama-index-6a3370e93cdd)