GraphRag解決了什么問題

在樸素的RAG（自我檢索生成模型）中，我們使用一個向量庫作為我們的知識庫。當用戶提出查詢時，該系統(tǒng)從向量庫中匹配頂部K個元素作為上下文，并將這個上下文與提示和查詢一起交給大型語言模型(LLM)進行回答。

現(xiàn)在，讓我們假設(shè)這個向量庫是指向企業(yè)知識的。有兩個示例查詢:

1. xx產(chǎn)品的價格是多少？
2. 去年技術(shù)團隊的成果有哪些？

對于第一個問題，由于它是非常具體的，知識庫的搜索可能會找到相應(yīng)的信息塊或常見問題解答。對于這種類型的問題，樸素的RAG通常會表現(xiàn)得很好。

對于第二個問題，這是一個宏觀層面的查詢，需要將企業(yè)知識庫中所有與技術(shù)團隊相關(guān)的項目收集起來并進行總結(jié)。關(guān)鍵在于找到與技術(shù)團隊成果相關(guān)的各類信息，然后以某種方式關(guān)聯(lián)起來以得出答案。這種方法也被稱為 "connecting the dots"。你可以參考這篇文章了解更多：https://blog.curiosity.ai/?-connecting-the-dots-how-to-improve-rag-with-knowledge-graphs-092c32024326

在這里，“dots”指的是分散在不同地方的關(guān)鍵信息。那么，樸素RAG能否有效解決這類問題？雖然我們可以強制使用樸素RAG來尋找答案，但其效果很可能不會十分理想。

對于這類問題，我們的一種解決策略是預(yù)先整理信息。例如，我們首先抽取與技術(shù)團隊相關(guān)的所有信息。當我們提出相關(guān)問題時，可以基于這些已經(jīng)抽取的信息進一步進行總結(jié)。這個過程實際上就是構(gòu)建知識圖譜的過程。

舉個例子，假設(shè)我們有大量文本，其中包含了技術(shù)團隊執(zhí)行的各種項目的信息。在我們構(gòu)建的知識圖譜中，我們有多個節(jié)點，代表技術(shù)團隊和項目，并通過關(guān)系將它們連接起來。這樣，當我們想了解他們完成了哪些工作時，只需關(guān)注與這些節(jié)點相關(guān)的部分，便可獲悉技術(shù)團隊已完成的任務(wù)。

這個構(gòu)建知識圖譜的過程通?？梢杂么笮湍Ｐ蛠硗瓿桑@也是GraphRAG模型提出的一個重要思想：預(yù)先提取并整理好信息，然后基于這些整理后的信息進行回答。

進一步來說，對于第二個問題，相關(guān)的提問方式有很多。例如：

• 張三的成果有哪些？我們可以找到與張三關(guān)聯(lián)的節(jié)點，了解他相關(guān)的項目信息。
• 張三所在的后端團隊的工作成果是什么？我們需要整合這個團隊所有人員的工作成果。
• 進一步上升層次，整個技術(shù)團隊的成果是什么？類似地，我們需要將各個技術(shù)團隊的成果集中起來。

這里呈現(xiàn)的是一個層次結(jié)構(gòu)，因此在GraphRAG模型中，做了進一步的操作: 創(chuàng)建這種層次結(jié)構(gòu)。我們預(yù)先整理出相關(guān)的關(guān)鍵信息，這樣的層次結(jié)構(gòu)是基于知識圖譜獲取的。因此，我們對這個知識圖進行了類似的聚類，然后將這些實體的信息合并在一起，再對這些合并后的信息進行整理。從知識圖譜到這里，GraphRAG采用了一些社區(qū)挖掘算法，這是GraphRAG的第二個重要思想。

那么，這套方法能否在商業(yè)環(huán)境中實施呢？我認為目前來說更像是一個原型。

1. 首先，構(gòu)建知識圖譜的過程會產(chǎn)生大量噪聲，這需要大量的人工清洗和校正，成本高昂。
2. 其次，在計算方面，聚類過程消耗資源較大。
3. 再者，新數(shù)據(jù)的加入也是問題。當有關(guān)鍵信息加入時，我們可能需要從頭開始重建整個結(jié)構(gòu)，這會產(chǎn)生大量的計算。這在知識圖譜領(lǐng)域?qū)嶋H上是一個比較難解決的問題。

盡管如此，GraphRag作為一個新的RAG流程還是有必要學(xué)習(xí)一下的。

GraphRAG入門

環(huán)境配置

下載源碼，安裝依賴

git clone https://github.com/microsoft/graphrag.git
cd graphrag
poetry install

如果你本地poetry install比較慢，可以在項目的pyproject.toml文件末尾添加:

[[tool.poetry.source]]
name = "aliyun"
url = "https://mirrors.aliyun.com/pypi/simple/"

并執(zhí)行poetry lock重新生成poetry.lock, 再執(zhí)行poetry install即可

對數(shù)據(jù)建索引

首先讓我們準備一個示例數(shù)據(jù)集：

mkdir -p ./ragtest/input

現(xiàn)在讓我們從可靠的來源獲取查爾斯·狄更斯的《圣誕頌歌》的副本

curl https://www.gutenberg.org/cache/epub/24022/pg24022.txt > ./ragtest/input/book.txt

在當前目錄準備初始化：

poetry run poe index --init --root ./ragtest

它會在當前目錄創(chuàng)建output、prompts目錄，以及.env文件和settings.yaml配置文件。

• output目錄，存儲生成的圖、以及總結(jié)、日志等信息。
• prompts目錄，存儲默認的4個提示詞文件：claim_extraction.txt、community_report.txt、entity_extraction.txt、summarize_descriptions.txt。
• .env文件中只包含一個GRAPHRAG_API_KEY，用于設(shè)置你的LLM API_KEY。
• settings.yaml 文件較為復(fù)雜，配置項目也較多，運行本項目只需要修改兩個llm和embeddings，我這里直接使用OpenAI, 沒錯，就是這么土豪！

接著我們執(zhí)行一條命令會自動索引數(shù)據(jù)，構(gòu)建知識圖譜，只是過程比較慢，耐心等待即可：

poetry run poe index --root ./ragtest

查詢

GraphRag的查詢分為兩種類型:

1. 全局檢索：可以簡單理解為 用于回答需要聚合信息的問題
2. 本地檢索/局部檢索：可以簡單理解為 用于回答特定實體的問題

全局查詢

poetry run poe query --root ./ragtest --method global '這個故事的主題是什么？'

輸出結(jié)果如下：

SUCCESS: Global Search Response: ### 故事主題概述

本故事的核心主題圍繞著**轉(zhuǎn)變與救贖**，通過Ebenezer Scrooge從吝嗇鬼到慷慨大方的典范的轉(zhuǎn)變，展現(xiàn)了個人改變的可能性和重要性。Scroogts (12, 15, 16, 20)]。

### 人物互動與社會關(guān)系

故事通過Scrooge與Cratchit家庭以及各種鬼魂的互動，強調(diào)了慈悲、善良以及個人改變的重要性。這些互動不僅展示了個人改變的可能性，還突出, 16, 18, 20)]。

### 社會影響與個人行為

Scrooge的旅程揭示了個體通過善行和慷慨對社區(qū)產(chǎn)生的積極影響。故事探討了希望、韌性和圣誕精神的主題，通過Tiny Tim和Cratchit家庭的形象，展示了即使在困難中也能體現(xiàn)出圣誕精神的典范 [Data: Reports (16, 18)]。

### 超自然引導(dǎo)與反思

故事還探討了超自然向?qū)г诖偈狗此己透淖冎械淖饔?，通過圣誕節(jié)過去、現(xiàn)在和未來的鬼魂的訪問，促使Scrooge反思自己的生活和行為。此外，故警告來體現(xiàn) [Data: Reports (12, 21)]。

### 社會正義與家庭社區(qū)的重要性

最后，故事還深入討論了社會不公和家庭及社區(qū)的重要性。Scrooge與Bob Cratchit和Tiny Tim的互動，不僅揭示了社會不公的主題，也強調(diào)了家庭和社區(qū)在個人生活中的價值 [Data: Reports (12)]。

綜上所述，本故事通過Scrooge的轉(zhuǎn)變之旅，探討了救贖、慈悲、社會責任和個人改變的重要性，以及這些主題如何在個人、家庭和更廣泛社區(qū)中產(chǎn)生深遠影響。

局部檢索

poetry run poe query --root ./ragtest --method local 'Scrooge 這個故事的主人公是誰，他的主要關(guān)系是什么？'

輸出結(jié)果如下：

SUCCESS: Local Search Response: # 主人公與主要關(guān)系

## 主人公簡介

故事的主人公是Ebenezer Scrooge，他是《A Christmas Carol》中的中心人物。Scrooge最初被描繪為一個貪婪、吝嗇的老人，對圣誕節(jié)和周圍人的苦難漠不關(guān)心。他的性格和態(tài)度通 (18, 23)]。

## 主要關(guān)系

### 與Bob Cratchit的關(guān)系
Bob Cratchit是Scrooge的職員，一個收入微薄但心地善良的人。Scrooge最初對Cratchit的待遇冷酷無情，但在故事的結(jié)尾，Scrooge提高了Cratchit的工資，并成為了他家庭的恩人 [Data: Relationships (14); Entities (9, 28)]。

### 與Jacob Marley的關(guān)系
Jacob Marley是Scrooge已故的商業(yè)伙伴，他的鬼魂在圣誕夜訪問Scrooge，警告他改變自己的生活方式，以免死后遭受同樣的命運。Marley的訪問為Scrooge的轉(zhuǎn)變開啟了序幕 [Data: Relationships (63, 41); Entities (50, 44)]。

### 與三個圣誕鬼魂的關(guān)系
三個圣誕鬼魂（圣誕節(jié)的過去、現(xiàn)在和未來）分別訪問Scrooge，展示了他的過去、現(xiàn)在和可能的未來。這些訪問深刻影響了Scrooge，促使他反思自己的生活并最終改變了他的行為和態(tài)度 [Data: Relationships (72, 86); Entities (47)]。

### 與Tiny Tim的關(guān)系
Tiny Tim是Bob Cratchit的兒子，他的健康狀況和幸福成為Scrooge改變的一個重要動力。Scrooge從一個冷漠的旁觀者變成了Tiny Tim的守護者和家庭的支持者 [Data: Relationships (86)]。

### 與侄子Fred的關(guān)系
Scrooge的侄子Fred代表了圣誕節(jié)的精神和樂觀態(tài)度，盡管Scrooge最初拒絕了Fred的圣誕邀請，但最終他接受了Fred的善意，并與他和其他家庭成員建立了積極的關(guān)系 [Data: Entitiationships (52)]。

## 結(jié)論

Ebenezer Scrooge的故事是一個關(guān)于救贖和轉(zhuǎn)變的經(jīng)典故事。通過與Bob Cratchit、Jacob Marley、三個圣誕鬼魂、Tiny Tim和他的侄子Fred等關(guān)鍵角色的互動，Scrooge從一個孤獨、間的聯(lián)系、同情和理解的重要性。

總結(jié)

本文首先介紹了GraphRAG相比傳統(tǒng)的樸素RAG的優(yōu)勢以及其在商業(yè)落地上的局限性，然后講解了GraphRAG的基本使用，在實際操作過程中發(fā)現(xiàn)還是比較耗費token的，那token到底耗費在哪，其內(nèi)部運行的流程又是怎么樣的呢？帶著這些問題，接下來我會用兩篇圖文并茂的文章詳細介紹一下:

1. GraphRAG如何構(gòu)造知識圖譜
2. 全局檢索和局部檢索的流程

本文轉(zhuǎn)載自公眾號AI 博物院 作者：longyunfeigu

原文鏈接：??https://mp.weixin.qq.com/s/hqIJgYbiV1V3B-V3WEtPfw??