現代 AI 聊天機器人常常依賴 Retrieval-Augmented Generation (RAG)，也就是檢索增強生成技術。這種技術讓機器人能從外部數據中提取真實信息來支撐回答。如果你用過“與你的文檔聊天”之類的工具，你就見過 RAG 的實際應用：系統會從文檔中找到相關片段，喂給大語言模型（LLM），讓它能用準確的信息回答你的問題。

RAG 大大提升了 LLM 回答的事實準確性。不過，傳統 RAG 系統大多把知識看成一堆互不關聯的文本片段。LLM 拿到幾段相關內容后，得自己把它們拼湊起來回答。這種方式對簡單問題還行，但遇到需要跨多個來源串聯信息的復雜查詢，效果就不理想了。

這篇文章會深入淺出地解釋兩個能讓聊天機器人更上一層樓的概念：ontologies（本體論） 和 knowledge graphs（知識圖譜），以及它們如何與 RAG 結合，形成 GraphRAG（基于圖的檢索增強生成）。我們會用簡單的語言說明它們是什么，為什么重要。

為什么這很重要？你可能會問。因為 GraphRAG 能讓聊天機器人的回答更準確、更貼合上下文、更有洞察力，比傳統 RAG 強多了。企業在探索 AI 解決方案時很看重這些特質——一個真正理解上下文、避免錯誤、能處理復雜問題的 AI 可以徹底改變游戲規則。（不過，這需要完美的實現，實際中往往沒那么理想。）

通過把非結構化文本和結構化的知識圖譜結合起來，GraphRAG 系統能提供感覺上更“有學問”的回答。把知識圖譜和 LLM 結合起來，是讓 AI 不僅能檢索信息，還能真正理解信息的關鍵一步。

什么是 RAG？

Retrieval-Augmented Generation，簡稱 RAG，是一種通過外部知識來增強語言模型回答的技術。RAG 系統不是僅靠模型記憶里的東西（可能過時或不完整）來回答，而是會從外部來源（比如文檔、數據庫或網絡）抓取相關信息，喂給模型來幫助生成答案。

簡單來說，RAG = LLM + 搜索引擎：模型先檢索支持數據，增強對主題的理解，然后結合內置知識和檢索到的信息生成回答。

如上圖所示，典型的 RAG 流程包含幾個步驟，就像一個智能查找過程：

1.索引知識：系統先把知識來源（比如一堆文檔）分成小塊文本，為每塊生成vector embeddings（向量嵌入）。這些嵌入是文本含義的數字表示，存進一個向量數據庫或索引中。

2.查詢嵌入：用戶提出問題時，查詢也會用同樣的技術轉成向量嵌入。

3.相似性搜索：系統把查詢向量和存儲的向量對比，找出與問題最“相似”或相關的文本塊。

4.結合上下文生成：最后，語言模型拿到用戶問題和檢索到的文本片段作為上下文，生成包含這些信息的回答。

RAG 讓 LLM 在現實場景中變得更實用。像 Bing Chat 或各種文檔問答機器人就是靠 RAG 提供最新、具體的答案，還能附上參考資料。通過用檢索到的文本來“錨定”回答，RAG 減少了 hallucinations（模型瞎編），還能訪問超出 AI 訓練截止日期的信息。不過，傳統 RAG 也有一些明顯的局限：

? 它把檢索到的文檔基本上當作獨立的、非結構化的文本塊。如果回答需要綜合多個文檔的信息或理解它們之間的關系，模型得在生成時自己完成這個重活。

? RAG 的檢索通常基于semantic similarity（語義相似性）。它能找到相關段落，但不一定理解內容的真正含義，或者一個事實如何與另一個事實關聯。

? 沒有內置機制來推理或確保檢索數據的一致性；LLM 只是拿到一堆文本，盡力把它們串起來。

在實際中，對于簡單的事實查詢，比如“這家公司什么時候成立的？”，傳統 RAG 表現很好。但對于復雜問題，比如“比較第一季度銷售和營銷支出的趨勢，并找出相關性”，傳統 RAG 就可能掉鏈子。它可能返回一段關于銷售的文本，另一段關于營銷的，但邏輯整合得靠 LLM 自己來，可能不一定能連貫成功。

這些局限性指向一個機會。如果我們不只是給 AI 一堆文檔，而是再給它一個 knowledge graph（知識圖譜），也就是實體和它們關系的網絡，作為推理的框架呢？如果 RAG 檢索不只是基于相似性返回文本，而是返回一組相互關聯的事實，AI 就能順著這些聯系生成更有洞察力的回答。

GraphRAG 就是把基于圖的知識整合進 RAG 流程。通過這樣做，我們希望解決上面提到的多來源、歧義和推理問題。

在深入 GraphRAG 的工作原理之前，我們先搞清楚 knowledge graphs（知識圖譜） 和 ontologies（本體論） 是什么——它們是這種方法的基礎。

知識圖譜（Knowledge Graphs）

知識圖譜 是一種對現實世界知識的網絡化表示，圖中的每個 node（節點） 代表一個實體，每條 edge（邊） 代表實體間的關系。

如上圖所示，知識圖譜以圖的形式組織數據，而不是表格或孤立的文檔。這意味著信息天然就捕捉了聯系。一些關鍵特點：

?靈活性：你可以隨時添加新的關系類型或實體的屬性，不會搞亂整個系統。圖可以輕松擴展以適應新知識。

?語義化：每條邊都有含義，這讓沿著圖遍歷并提取有意義的推理鏈成為可能。圖不僅能表示內容，還能表示上下文。

?支持多跳查詢：如果你想知道兩個實體如何關聯，圖數據庫可以遍歷鄰居、鄰居的鄰居，依此類推。

知識圖譜通常存儲在專門的 graph databases（圖數據庫） 或 triplestores（三元存儲） 中。這些系統專為存儲節點和邊、運行圖查詢而優化。

知識圖譜的結構對 AI 系統（尤其在 RAG 場景中）是個大加分項。因為事實是相互關聯的，LLM 能拿到一整個相關信息的網絡，而不是孤立的片段。這意味著：

? AI 系統能更好地消除歧義。比如，如果問題提到“Jaguar”，圖可以通過關系明確是汽車還是動物，提供文本單獨無法給出的上下文。

? AI 系統可以通過“連接”或遍歷收集相關事實。圖查詢可以提供一個全相關的子圖，而不是零散的段落，為模型提供一個預先拼好的拼圖，而不是單個碎片。

? 知識圖譜保證一致性。比如，如果圖知道產品 X 包含部件 A 和 B，它就能可靠地只列出這些部件，不像文本模型可能會瞎編或漏掉信息。圖的結構化特性讓事實的聚合更完整、更準確。

? 圖通過追蹤推理鏈的節點和邊提供explainability（可解釋性），讓推理過程清晰，增加答案的可信度。

總結來說，知識圖譜為 AI 的上下文注入了意義。它不是把數據當一堆詞袋處理，而是當作一個知識網絡。這正是我們希望 AI 在回答復雜問題時擁有的：一個可以導航的、豐富的關聯上下文，而不是每次都要硬解析一堆文檔。

現在我們了解了知識圖譜是什么，以及它如何助力 AI 系統，接下來看看 ontologies（本體論） 是什么，以及它們如何幫助構建更好的知識圖譜。

本體論（Ontologies）

在知識系統的語境中，ontology（本體論） 是一個特定領域的知識的正式規范。它定義了該領域中存在的實體（或概念）以及這些實體之間的關系。

本體論通常將概念組織成層級或分類體系，但也可能包含邏輯約束或規則。比如，可以聲明“每個訂單必須至少包含一個產品項目”。

為什么本體論重要？你可能會問。本體論為一個領域提供了共享的理解，這在整合多個來源的數據或構建需要推理該領域的 AI 系統時特別有用。通過定義一組通用的實體類型和關系，本體論確保不同團隊或系統用一致的方式指代事物。比如，如果一個數據集把人叫“Client”，另一個叫“Customer”，通過映射到同一個本體論類（比如 Customer 作為 Person 的子類），就能無縫合并這些數據。

在 AI 和 GraphRAG 的語境中，本體論是知識圖譜的藍圖——它決定了圖中會有哪些節點和鏈接。這對復雜推理至關重要。如果你的聊天機器人知道在你的應用中“Amazon”是一個 Company（公司）（而不是河流），而 Company 在本體論中有定義（包含 headquarters、CEO 等屬性，以及 hasSubsidiary 等關系），它就能更精確地錨定答案。

現在我們了解了知識圖譜和本體論，來看看如何把它們整合進類似 RAG 的流程中。

GraphRAG

GraphRAG 是傳統 RAG 的進化版，它明確將知識圖譜納入檢索過程。在 GraphRAG 中，用戶提問時，系統不只是對文本做向量相似性搜索，還會查詢知識圖譜中相關的實體和關系。

我們來高層次地走一遍典型的 GraphRAG 流程：

1.索引知識：輸入包括結構化數據（比如數據庫、CSV 文件）和非結構化數據（比如文檔）。結構化數據通過數據轉換，將表格行轉為三元組。非結構化數據被拆成可管理的文本塊，從中提取實體和關系，同時計算embeddings（嵌入），生成帶嵌入的三元組。

2.問題分析與嵌入：分析用戶查詢，識別關鍵術語或實體，用相同的嵌入模型將這些元素轉為嵌入。

3.圖搜索：系統查詢知識圖譜，找到與關鍵術語相關的節點，不只是檢索語義相似的項目，還利用關系。

4.結合圖上下文生成：生成模型使用用戶查詢和檢索到的圖增強上下文生成答案。

在底層，GraphRAG 可以用多種策略整合圖查詢。系統可能先做常規的語義搜索，找 top-K 文本塊，然后遍歷這些塊的圖鄰居以收集額外上下文，再生成答案。這確保了即使相關信息分散在不同文檔中，圖也能把它們拉到一起。在實際中，GraphRAG 可能涉及額外步驟，比如 entity disambiguation（實體消歧）（確保問題中的“Apple”鏈接到正確的節點，可能是公司或水果）和圖遍歷算法來擴展上下文。但總體思路如上：搜索 + 圖查詢，而不只是搜索。

對非技術讀者來說，你可以把 GraphRAG 想象成給 AI 增加了一個“類腦”知識網絡，除了文檔庫之外。AI 不再孤立地讀每本書（文檔），而是有一本事實及其關聯的百科全書。對技術讀者來說，你可以想象一個架構，里面既有向量索引又有圖數據庫，兩者協同工作——一個檢索原始段落，另一個檢索結構化事實，都喂進 LLM 的上下文窗口。

構建用于 RAG 的知識圖譜：方法

構建支持 GraphRAG 系統的知識圖譜有兩種主要方法：Top-Down（自上而下） 和 Bottom-Up（自下而上）。它們不完全互斥（通常會混用），但區分它們有助于理解。

方法 1：自上而下（優先本體論）

自上而下的方法從定義領域的本體論開始，由領域專家或行業標準建立類、關系和規則。這個模式加載到圖數據庫中作為空的框架，指導數據提取和組織，相當于一個藍圖。

一旦本體論（模式）就位，接下來是用真實數據填充它。有幾種子方法：

?使用結構化來源：如果你有現有的結構化數據庫或 CSV 文件，就把它們映射到本體論。如果映射簡單，可以通過自動化ETL 工具將 SQL 表轉為圖數據。

?通過本體論從文本提取：對于非結構化數據（比如文檔、PDF），你會用NLP 技術，但以本體論為指導。這通常涉及編寫提取規則或用 LLM 配合引用本體論術語的提示。

?手動或半手動整理：在關鍵領域，可能需要人工驗證每個提取的三元組，或手動輸入一些數據到圖中，特別是一次性設置的關鍵知識。比如，公司可能手動輸入組織架構或產品層級到圖中，因為這些數據相對靜態且非常重要。

關鍵在于，自上而下的方法中，本體論在每一步都起到指導作用。它告訴提取算法要找什么，確保輸入的數據符合一個連貫的模型。

使用正式本體論的一大優勢是你可以利用 reasoners（推理器） 和 validators（驗證器） 保持知識圖譜一致性。本體論推理器可以自動推斷新事實或檢查邏輯矛盾，而像 SHACL 這樣的工具可以強制執行數據形狀規則（類似更豐富的數據庫模式）。這些檢查能防止矛盾事實，并通過自動推導關系豐富圖。在 GraphRAG 中，這意味著即使多跳連接不明確，本體論也能幫助推導出來。

方法 2：自下而上（數據優先）

自下而上的方法直接從數據生成知識圖譜，不依賴預定義的模式。NLP 和 LLM 的進步讓從非結構化文本中提取結構化三元組成為可能，這些三元組隨后被輸入圖數據庫，實體成為節點，關系成為邊。

在底層，自下而上的提取可以結合傳統 NLP 和現代 LLM：

?Named Entity Recognition (NER，命名實體識別)：識別文本中的人名、組織、地點等。

?Relation Extraction (RE，關系提取)：識別這些實體之間是否有提到的關系。

?Coreference Resolution（共指消解）：弄清楚段落中代詞的指代對象，以便三元組使用完整名稱。

有像 spaCy 或 Flair 這樣的傳統方法庫，也有整合 LLM 調用的新庫用于 IE（信息提取）。另外，像 ChatGPT 插件 或 LangChain 代理 這樣的技術可以設置來填充圖：代理可以逐個讀取文檔，找到事實時調用“圖插入”工具。另一個有趣的策略是用 LLM 通過讀取文檔樣本建議模式（這有點像本體論生成，但自下而上）。

自下而上提取的一個大問題是，LLM 可能不完美，甚至會“創造性”輸出。它們可能瞎編一個不存在的關系，或錯誤標記一個實體。因此，驗證很重要：

• ? 對關鍵事實與源文本交叉檢查。
• ? 使用多輪提取：比如第一輪提取實體，第二輪驗證和填充關系。
• ? 人工抽查：讓人審閱一部分提取的三元組，尤其是那些影響大的。

這個過程通常是迭代的。你運行提取，找到錯誤或缺失，調整提示或過濾器，再運行一次。久而久之，這能大幅提高知識圖譜的質量。好消息是，即使有些錯誤，知識圖譜對很多查詢仍然有用——你可以優先清理對用例最重要的部分。

最后，記住，發送文本進行提取會將你的數據暴露給 LLM/服務，所以要確保符合隱私和保留要求。

GraphRAG 生態中的工具和框架

構建 GraphRAG 系統聽起來可能有點復雜，你得管理向量數據庫、圖數據庫、運行 LLM 提取流程等。好消息是，社區正在開發工具讓這事變得更簡單。我們來簡單提一些工具和框架，以及它們的作用。

圖存儲

首先，你需要一個地方存儲和查詢知識圖譜。傳統的圖數據庫如 Neo4j、Amazon Neptune、TigerGraph 或 RDF triplestores（如 GraphDB 或 Stardog）是常見選擇。

這些數據庫專為我們討論的操作優化：

? 遍歷關系

? 查找鄰居

? 執行圖查詢

在 GraphRAG 設置中，檢索流程可以用這些查詢來獲取相關的子圖。一些向量數據庫（像 Milvus 或帶 Graph 插件的 Elasticsearch）也開始整合類圖查詢，但通常專用圖數據庫提供最豐富的功能。重要的是，你的圖存儲要能高效檢索直接鄰居和多跳鄰居，因為復雜問題可能需要抓取整個事實網絡。

新興工具

一些新工具正在將圖與 LLM 結合：

?Cognee：一個開源的“AI 記憶引擎”，為 LLM 構建和使用知識圖譜。它作為代理或聊天機器人的語義記憶層，將非結構化數據轉為結構化的概念和關系圖。LLM 能查詢這些圖以獲得精確答案。Cognee 隱藏了圖的復雜性：開發者只需提供數據，它就生成可查詢的圖。它與圖數據庫整合，提供數據攝取、圖構建和 LLM 查詢的流程。

?Graphiti（由 Zep AI 提供）：一個為需要實時、動態記憶的 AI 代理設計的框架。與許多靜態數據的 RAG 系統不同，Graphiti 能在新信息到達時增量更新知識圖譜。它存儲事實及其時間上下文，使用Neo4j存儲，提供面向代理的 API。與早期基于批處理的 GraphRAG 系統不同，Graphiti 能高效處理流式數據，適合持續學習的長期運行代理，確保答案始終反映最新數據。

?其他框架：像LlamaIndex和Haystack這樣的工具添加了圖模塊，盡管不是以圖優先。LlamaIndex 能從文檔提取三元組并支持基于圖的查詢。Haystack 實驗了整合圖數據庫來擴展問答功能，超越向量搜索。云服務商也在增加圖功能：AWS Bedrock Knowledge Bases支持 GraphRAG，通過托管攝取到Neptune；Azure Cognitive Search也與圖整合。生態系統發展很快。

無需從頭開始

重點是，如果你想嘗試 GraphRAG，不用從零開始。你可以：

? 用Cognee處理知識提取和圖構建，省去自己寫提示和解析邏輯的麻煩。

? 如果需要即插即用的記憶圖，尤其是對話或時間相關數據的代理，用Graphiti。

? 用LlamaIndex或其他工具，只需幾行代碼就能獲得基本的知識圖譜提取功能。

? 依靠成熟的圖數據庫，省去寫自定義圖遍歷引擎的麻煩。

總之，雖然 GraphRAG 處于前沿，但周邊生態正在快速成長。你可以利用這些庫和服務快速搭建原型，然后迭代優化知識圖譜和提示。

結論

傳統 RAG 適合簡單的事實查詢，但在需要深入推理、準確性或多步回答的查詢上會吃力。這時 GraphRAG 就大顯身手了。通過結合文檔和知識圖譜，它用結構化事實錨定回答，減少 hallucinations（瞎編），支持多跳推理，讓 AI 能以標準 RAG 無法做到的方式連接和綜合信息。

當然，這種能力也有代價。構建和維護知識圖譜需要模式設計、提取、更新和基礎設施開銷。對于簡單用例，傳統 RAG 仍是更簡單高效的選擇。但當需要更豐富的回答、一致性或 explainability（可解釋性） 時，GraphRAG 的優勢顯而易見。

展望未來，知識增強的 AI 正在快速發展。未來平臺可能直接從文檔自動生成圖，LLM 直接在圖上推理。對于像 GoodData 這樣的公司，GraphRAG 將 AI 與分析結合，帶來超越“發生了什么”到“為什么發生”的洞察。

最終，GraphRAG 讓我們更接近于不僅能檢索事實，還能真正理解和推理事實的 AI，就像人類分析師，但規模和速度更大。雖然這條路有復雜性，但目標（更準確、可解釋、更有洞察力的 AI）絕對值得投資。關鍵不僅在于收集事實，而在于連接它們。