你為什么要用GraphGAG？
其實我這個問題不算瞎問。在你的項目里，你是真覺得GraphRAG有用，還是就圖個新鮮勁，這個是非常重要的思考。
RAG能干啥，其實不用復雜的解釋了。
傳統的方式就是基于向量余弦近似度的查找，當然BM25其實也是傳統RAG（別把它當新東西），常見一點的基本都有向量查找，或者向量+BM25關鍵字集成查找，為了方便我就畫向量的了。
如下圖：
通用LLM里不太存在專用領域的知識，RAG可以作為外掛知識庫的補充，補充新的知識，另外有些問題，不一定讓你回復標準答案（你懂的）
現在舉幾個場景，比如說，你問一句，肯德基全家桶多少錢一桶，這你問RAG系統指定是沒啥問題。
為啥沒問題呢？
因為你的問題指向特別具體，SKU====>價格，銀貨兩訖。
那么下一個問題來了，你所在的團隊去年有哪些貢獻？
這咋答啊？太宏觀了
要硬來也不是不行，比如搜索你所在的團隊有誰？然后找這些人的各個lead的項目的chunk，最后把所有chunk one by one塞給LLM，讓LLM總結，總結的出來的中間態還應該有個外置的memory吧，比如redis存著，最后所有人的貢獻全出來，再過一遍LLM 刷總結。早上問的，這一套下來可能都吃中午飯了（夸張的修辭手法），主要是大概率這效果肯定不好，受限于每次生成的結果優劣，就有一個疊加效應，另外也受限于token數的限制，每人總結，再疊加總結可能還好一點，要一股腦的送進LLM讓它亂處理，可要了親命了....
圖片
其實，上一段所做的操作，嚴格來說，可以理解為就是構建知識圖譜的一個過程，只是毫無章法而已，而且你必須要把RAG系統Agentic化，否則RAG是做不了這個事的。
那構建知識圖譜這事，其實挺費時費力的，GraphRAG這個軟件也好，框架也好，主要干得第一件事就是用LLM來構建知識圖譜。
- 原始文檔（Source Documents）：
- 系統從原始文檔開始，通過文本提取和分塊（chunking）將文檔拆分成較小的文本片段。
- 文本片段（Text Chunks）：
- 將這些文本片段經過領域定制的摘要化處理，以提取關鍵的實體、關系和相關屬性。
- 元素實例（Element Instances）：
- 在這一步，系統識別并提取出圖節點（如實體）和邊（如關系），這些信息將被進一步處理為元素摘要。
- 元素摘要（Element Summaries）：
- 系統為每個提取的元素（節點和邊）生成獨立的摘要，這些摘要提供了每個元素的獨立描述。
- 圖社區（Graph Communities）：
- 通過社區檢測算法（如Leiden算法），將圖劃分為多個社區，每個社區包含彼此之間關系緊密的節點和邊。
- 社區摘要（Community Summaries）：
- 為每個社區生成一個綜合的摘要，描述該社區內的所有元素及其關系。這些摘要在查詢時可以獨立使用。
- 社區回答（Community Answers）：
- 在接到用戶查詢后，系統會利用這些社區摘要來生成部分回答。每個社區摘要獨立處理，并生成與查詢相關的回答。
- 全局回答（Global Answer）：
- 最終，將所有部分回答匯總生成一個綜合性的全局回答，來滿足用戶的查詢需求。
索引時間 vs. 查詢時間：
- 索引時間：在這段時間內，系統構建知識圖譜并生成所有相關的社區摘要。這是一個預處理步驟，使得系統能夠更快速地響應未來的查詢。
- 查詢時間：當用戶發出查詢時，系統利用預先生成的社區摘要并并行處理，最終生成全局性的答案。這一步是針對用戶查詢的實時處理。
這里面LLM都參與了哪幾部分呢？
主要是以下4個部分
1. 元素實例提取（Element Instances Extraction）：
- 對每個文本片段，使用大語言模型（LLM）來提取圖中的元素實例。具體來說，LLM被用來識別和提取以下內容：
a.實體（Entities）：如人、地點、組織等。
b.關系（Relationships）：描述實體之間的連接或關聯。
c.協變量（Covariates）：其他相關的描述或聲明，例如主語、賓語、關系類型等。
- 這些元素實例被表示為圖的節點和邊，形成一個初步的圖結構。
2. 元素摘要生成（Element Summarization）：
- 在提取了元素實例之后，LLM還負責生成這些元素的摘要。每個節點或邊的實例被獨立地總結為一個描述塊，這些描述塊提供了對每個圖元素的獨立理解。
3. 社區摘要生成（Community Summarization）：
- 對于每個社區，LLM生成一個社區摘要。這些摘要描述了社區內部所有節點和邊的關系及其重要性。社區摘要可以用于后續的查詢回答生成過程。
4. 生成回答（Answer Generation）：
- 在查詢時間，系統首先根據查詢問題選擇相關的社區摘要。然后，LLM利用這些社區摘要生成部分回答。
- 最后，將所有部分回答整合成一個綜合性的全局回答，提供給用戶。
左邊的圖都好理解，就是構建圖里的邊和節點的過程，一度，二度啥的。
右邊的是干啥的呢？就是層級回答，這是干啥的呢？
這就是今天要說的題目的重點，你為啥要用graphRAG
假設有一連串的問題
1.你去年的工作結果是什么？
2.你團隊的工作貢獻有啥？
3.你們大部門的貢獻？
4.整個公司的產品GTM的狀態？
這靈魂四問，用傳統的RAG基本是不太現實的，但是借助Graph RAG的圖譜能力和層級化能力則可以提前生成了關于 2,3,4問題的答案和關聯性（Summarization）
GraphRAG主要的能力就是干這事的
所以我們總結一下：
應用場景：
- 傳統RAG：適用于需要從大規模文檔庫中檢索并生成內容的應用，如問答系統、摘要生成等。
- Graph RAG：由于其對復雜關系的建模能力，更適用于需要理解和生成復雜知識結構的應用，如知識圖譜問答、關系推理等。
而你的應用如果不太涉及下面的業務，我勸你別用GraphRAG
原因有這么幾點：
- 錢，我前文中說的要LLM參與的幾個點，那沒一個是省token的，而且是預加載過程，也就是說只要你想玩GraphRAG，那這錢是省不了的，基于VectorDB和BM25的都沒不需要這個。
- 新的數據加入，圖這玩意兒不同于向量數據庫，你愿意新增幾條，大可新增幾條，只要performance夠就行，你每次加新數據，如果和多條邊或者節點相關，就會大規模重構圖的結構，又是新折騰輪回的開始。
- 圖譜構建的問題，這個嚴格說不是GraphRAG的問題，是圖系統本身的問題，一個良好的知識圖譜構建不太可能靠LLM就全程搞定，所以你圖譜構建的魯棒性和健壯性，對LLM要求極高。這東西出很久了，相信你們測過的也知道，效果是不錯，因為你們平常問的問題，往往標準rag cover不住，但是它也僅僅是占這塊的便宜而已。其它的針對性問答，關于具體問題，它不會比傳統rag有什么特別大的優勢。
最后一點，傳統rag不能回答靈魂四問嗎？
1.你去年的工作結果是什么？
2.你團隊的工作貢獻有啥？
3.你們大部門的貢獻？
4.整個公司的產品GTM的狀態？
答案是當然可以，你提前有這個問題不就完了嗎？咋么有呢？讓LLM生成唄。
有兄弟會說，你說這不本末倒置嗎？哪有先有答案后有問題的？
本文轉載自微信公眾號「??熵減AI???」，可以通過以下二維碼關注。轉載本文請聯系??熵減AI???公眾號。??微博：Transformer-周
純研究O1的論文都發出來了，讓我想起來研究紅樓夢的紅學-AI.x社區
本文轉載自 ??熵減AI??，作者： 周博洋
