---
# System prepended metadata

title: '【RAG 】From Local to Global: A Graph RAG Approach to Query-Focused Summarization'
tags: [論文, VLM, 大語言模型]

---

---
slideOptions:
  transition: slide
---


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

---

## 傳統的RAG運作邏輯與缺點

<font size=5>
我們熟知的檢索增強生成(RAG)技術，是將外部資料(來自於資料庫、或是非結構化的文檔)切割成一小塊一小塊的chunk，透過文字編碼器轉換為向量空間

當使用者查詢時，將提示詞也轉換為向量進行比對，得到最相關的資料做為參考
</font>
![173035768398494_P30757391](https://admin.bentoml.com/uploads/simple_rag_workflow_091648ef39.png)
<font size=3>
https://www.bentoml.com/blog/building-rag-with-open-source-and-custom-ai-models</font>

----

### 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)


* <font size=5>從來源文件中提取文本，並將其分割成較小的文本塊</font>
* <font size=5>文本塊對的影響:</font>
    * <font size=5>大:更少的LLM呼叫次數，但上下文回憶率會降低</font>
    * <font size=5>小:可以檢測到更多實體，貴</font>


----

### 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)


* <font size=5>每個Chunk內使用LLM提取所有實體(名詞、描述…)和邊(關係)、聲明(證明)</font>
* <font size=5>可以把所提供資料的領域知識作為樣本進行上下文學習</font>
* <font size=5>好處:容易理解特定領域的專有名詞(醫療、資訊...)</font>
* <font size=5>"拾穗":透過提示詞檢測是否有遺漏的實體，如果有就再執行一次提取</font>

----

#### 舉個例子:

![o_1dluorltd1gn7m25176e1slkm3u43](https://hackmd.io/_uploads/S1aKSy4v1g.jpg =500x)

* <font size=5>實體:海綿寶寶是比其堡的居民</font>
* <font size=5>邊:海綿寶寶跟派大星是好朋友</font>
* <font size=5>聲明:海綿寶寶跟派大星常在比奇堡一起玩</font>


----

#### 拾穗(gleanings)的詳細步驟

* <font size=5>1.LLM分析chunk內的文字，提取其中的實體</font>
* <font size=5>2.評估是否已提取所有實體，將logits bias(LLM的參數，控制是否輸出特定文字)設為100強制讓輸出只有YES或NO</font>
* <font size=5>3.如果為NO，則在下次提取時付加上"MANY entities were missed
 in the last extraction"這段提示詞</font>
* <font size=5>4.重複執行直到設定次數上限</font>

----

### 3.元素實例到元素摘要 (Element Instances → Element Summaries)

![image](https://hackmd.io/_uploads/HJ-xeJNwkl.png =300x)

* <font size=5>將收集到的實體、邊、聲明做一個整合，合併重複的部分</font>
* <font size=5>潛在的問題:LLM不一定能以相同格式提取本應該相同的實體</font>

----

### 4.元素摘要到圖形社群 (Element Summaries → Graph Communities)
![image](https://miro.medium.com/v2/resize:fit:1400/1*HTpa_ZM5COzCqK03nN60pw.png =350x)


* <font size=5>之前的產生的東西都可以視作一張無向加權圖</font>
* <font size=5>使用社群檢測演算法(Leiden)挖掘所有圖之間的層級社群結構，相互連接更強的元素被歸類於相同的社區</font>
* <font size=5>讓每個階層的總結可以實現一個分而治之的全域總結</font>


----

### 5.圖形社群到社群摘要 (Graph Communities → Community Summaries)

![image](https://hackmd.io/_uploads/SyM6Ok4w1g.png =300x)

* <font size=5>讓LLM為Leiden階層結構中每個社群作一個總結，獲得不同細粒度上宏觀理解</font>
* <font size=5>社群摘要的產生方式依社群類型分成兩種:</font>
    * <font size=5>葉節點層級社群 (Leaf-level communities)</font>
    * <font size=5>較高層級社群 (Higher-level communities)</font>

----

#### 葉節點層級社群 (Leaf-level communities)
處理步驟如下:
1.<font size=5>根據社群內邊的節點度(node 的 subtree 數量?) 來優先處理邊的資訊。節點度越高，表示該節點子樹越多，在社群內越重要</font>
2. <font size=5>依照邊的優先順序添加到 LLM 的上下文窗口中，直到token上限</font>

----

#### 較高層級社群 (Higher-level communities)
處理步驟如下:
1.<font size=5>如果所有元素加起來不會超過token上限，就如葉節點一樣處理</font>
2. <font size=5>如果超出:在此社群下找到一個子社群不會超出token上限的做摘要替代主社群</font>


----

### 6.社群摘要到社群答案到全局答案 (Community Summaries → Community Answers → Global Answer)

* <font size=5>用戶提問</font>
* <font size=5>將社群摘要打亂，將其分為預先指定的 token 大小的區塊，確保相關資訊分佈在各個區塊中</font>
* <font size=5>每個社群摘要都生成一個答案，並透過LLM對於回答目標問題的幫助程度打分</font>
* <font size=5>按照幫助程度分數的降序排序，放入context中生成最終回答</font>


---

## 實驗結果

----

* <font size=5>測試資料集</font>
    * <font size=5>科技Podcast對話文字稿約100萬個token，由1669個600-token的文本塊組成</font>
    * <font size=5>各類新聞文章，約170萬個token，由3197個600-token的文本塊組成</font>
* <font size=5>問題來源</font>
    * <font size=5>根據資料集描述，使用LLM生成關於潛在用戶與任務的可能問題</font>
* <font size=5>評估指標</font>
    * <font size=5>使用LLM evaluator評估回答的全面性、多樣性 、賦能性、直接性，比較出勝者</font>
* <font size=5>評估對象</font>
    * <font size=5>C0~C3高到低社群層級</font>
    * <font size=5>TS (文本摘要):使用map-reduce做摘要的RAG</font>
    * <font size=5>普通RAG</font>

----

* <font size=5>LLM模型</font>
    *  <font size=5>gpt-4-turbo</font>
* <font size=5>上下文長度</font>
    *  <font size=5>8k,16k,32k,64k，實驗發現8K擁有最高的勝率(58.1%)</font>


----

全面性和多樣性上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)


---

## 總結

* <font size=5>GraphRAG替代了傳統RAG的向量化步驟，使用LLM建構知識樹進行彙整</font>
* <font size=5>能提升LLM回覆的全面性和多樣性並減少TOKEN消耗量</font>
* <font size=5>實體收集的穩定性存在問題，且索引階段消耗大量資源</font>

![image](https://miro.medium.com/v2/resize:fit:1254/1*naZhhiKaw5C_qA7e4vWRvQ.png =500x)
<font size=3>(https://medium.aiplanet.com/implement-rag-with-knowledge-graph-and-llama-index-6a3370e93cdd)</font>
