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