知識圖譜與 GraphRAG - Cupoy

知識圖譜與 GraphRAG

Neo4j × NetworkX 雙實作，破解數據難題，打造智能金融儀表板！

• 1. 知識圖譜的基礎與 GraphRAG 概念

  • 1. 知識圖譜概論

    1. 引言與背景 什麼是知識圖譜？ 知識圖譜（Knowledge Graph, KG）是一種能以圖狀結構表示現實世界中的「實體」及其「關係」的資料表示方式。 與只注重數值或文字欄位的傳統資料表不同，知識圖譜能更直觀地呈現「誰與誰之間有什麼關係」。 為什麼需要知識圖譜？ 整合性：能統一不同來源（如企業內部、外部公開資料）的資訊。 易理解：圖狀結構更能幫助人們理解複雜關係。 語意推理：可透過定義好的規則或本體（Ontology）進行推理，進而得到隱含資訊。 發展背景與應用範圍 早期由 AI 與語意網（Semantic Web）概念所啟發，2012 年 Google 推出「Knowledge Graph」讓此名詞廣受矚目。 應用範圍：搜尋引擎、推薦系統、企業資料整合、虛擬助理與聊天機器人等。 2. 知識圖譜的核心組成 2.1 節點 (Node) 定義：代表現實世界中的「實體」或「概念」，如人物、公司、地點、物品等。 範例： 人物節點：馬斯克 (Elon Musk) 公司節點：IBM 概念節點：行銷 意義：節點是構成知識圖譜的基礎元素，每個節點皆可附帶屬性，如名稱、時間、地點等。 2.2 邊 (Edge) 定義：表現節點之間的「關係」，通常會有語意意義，如「僱用」、「屬於」、「合作」、「作者-作品」、「父母-子女」等。 範例： IBM → 僱用 → 馬斯克 馬斯克 → 創辦 → SpaceX 電影 A → 續作 → 電影 B 特性： 關係可具方向性（有向邊）或無方向性（無向邊）。 在某些圖資料庫或語意網標準中，也能對邊本身附加屬性（例如起始日期、權重等）。 2.3 屬性 (Property / Label) 定義：為節點或邊附加描述資訊。例如，人名、出生日期，或關係的起始時間等。 用途： 幫助搜尋與推理：可根據屬性值篩選節點或推論新關係。 提高查詢效率：如依「職稱 = 執行長」快速找到所有執行長節點。 舉例： 節點屬性：公司名稱、成立年份、地址。 邊屬性：合作合約日期、投資金額、合作範圍。 圖片來源：https://zhuanlan.zhihu.com/p/37057052 3. 知識圖譜與傳統資料庫比較 資料模型 關係型資料庫（RDB）：以表格、行、列為核心；關係透過外鍵 (Foreign Key) 或多對多關聯表 (Join Table) 來表達。 知識圖譜（KG）：以節點與邊為核心，更自然表達實體與關係。 圖片來源：https://vocus.cc/article/6496b466fd897800018a4515 可擴充性 RDB：結構變動需修改 Schema，牽涉到資料庫設計與系統改動。 KG：新增新類型的節點或關係，只需在圖結構中加入對應的節點及關係即可，彈性較高。 關係表達 RDB：需要撰寫複雜的 SQL Join 來查詢多表關係。 KG：直接使用圖查詢語言（如 Cypher、SPARQL），更直觀地表達實體關係。 推理能力 RDB：主要靠 SQL 與程式邏輯，缺乏語意層面的推理。 KG：可透過本體 (Ontology) 與推理規則產生隱含知識。 適用場景 RDB：適用在高度結構化且交易頻繁的系統，如銀行、電商交易。 KG：適用在強調資料關聯、需整合多樣數據來源並進行語意推理的場合，如知識管理、智慧搜尋、複雜推薦系統。 4. 應用範例與挑戰 4.1 應用範例 搜尋引擎 Google、Bing 等運用知識圖譜，對人名、地點、組織等提供結構化資訊及關聯搜索結果。 推薦系統 電商或影音平台根據使用者歷史行為以及商品/內容之間的圖狀關係，實現更準確的推薦。 企業資料整合 大型組織將 CRM、ERP、HR 等系統資料整合到同一知識圖譜中，跨部門查詢更容易。 聊天機器人與虛擬助理 透過圖結構進行語意理解，提高對使用者問題的正確解讀與回答。 4.2 面臨的主要挑戰 規模化 (Scalability) 隨著節點和關係不斷增加，圖查詢的效率、索引設計將成為關鍵議題。 資料品質 (Data Quality) 原始資料若有錯誤或不一致，會導致圖中資訊失真，必須進行持續的清洗與驗證。 動態更新 (Dynamic Nature) 新數據的加入、舊數據的修改都需要保持圖的完整性與正確性。 推理與本體設計 (Reasoning & Ontology) 不同行業、不同應用領域都需要自訂或擴充本體，推理規則也需隨需求而調整。 5. 總結與 Q&A 課程重點回顧 知識圖譜透過節點、邊、屬性來呈現實體與關係，結構靈活且能支援語意推理。 與關係型資料庫相比，知識圖譜在資料關係的可視化、彈性擴充、推理功能上更具優勢。 應用廣泛，但也需面對資料品質、規模化等挑戰。 未來發展方向 與大數據、人工智慧（特別是自然語言處理）的結合會更加緊密。 越來越多企業正在導入知識圖譜進行智慧搜尋、知識管理、決策支持。 開放問答 (Q&A) 鼓勵學生就任何不清楚的概念、實際應用疑問或技術細節提出問題。 參考資料（進階閱讀與學習資源） Knowledge Graph – Turing Institute What is a Knowledge Graph? – Ontotext Knowledge Graph (Wikipedia) What is a Knowledge Graph? – Neo4j Blog

  • 2. GraphRAG 概論

    第一章：基礎回顧 1.1 RAG (Retrieval-Augmented Generation) 簡介 傳統 RAG 流程 收集文本並建立索引（可能使用向量檢索或關鍵字索引）。 接收問題後從索引中檢索出最相關的文本片段。 最後由生成模型 (Generative Model) 根據檢索內容生成回答。 局限性：當問題需要跨多個文件或需要多跳推理時，傳統 RAG 容易缺少「實體關係」的全貌。 1.2 知識圖譜（Knowledge Graph）基礎 概念：由「實體 (Entities)」與「關係 (Relations/Edges)」組成的圖結構，用以表示資訊的網路關係。 優勢：對資料之間的邏輯關係能有更直觀的表現，例如人-地點-事件等的連結。 常見應用：搜尋引擎（如 Google Knowledge Graph）、企業資源管理、智慧客服等。 1.3 GraphRAG 與傳統 RAG 的差異 多跳推理：GraphRAG 更容易在圖結構中沿著多個關係節點做推理。 可解釋性：能在圖上直接追蹤為什麼會得到某個答案。 更精準上下文：傳統 RAG 容易被「相似度」誤導，而 GraphRAG 可以利用關係資訊進一步過濾。 第二章：GraphRAG 的核心原理 2.1 Multi-Hop Reasoning（多跳推理） 場景說明：例如要查詢某人在哪一年在哪個國家創辦了某公司；若文本分散在不同文件中，需要串聯多處信息才能回答。 如何實現：GraphRAG 透過圖上的邊，逐步沿著實體之間的連結找出完整資訊。 2.2 可解釋性的實現方式 可視化路徑：透過圖資料庫的視覺化工具 (如 Neo4j Bloom) 展示從問題到答案路徑上的所有實體與關係。 自動生成推理鏈：使用 LLM 或其他 NLP 方法，將推理過程用自然語言描述出來。 2.3 GraphRAG 對回答品質與上下文的影響 更豐富的上下文：不再僅依賴文字相似度，而是透過圖中「who, what, where, how」的關聯為基礎。 減少誤判：若某些文件內容互相矛盾或不相關，透過圖結構能快速剔除或標記。 圖片來源：https://neo4j.com/blog/graphrag-manifesto/ 第三章：GraphRAG 的資料處理與建構流程 3.1 前處理與索引 (Pre-processing and Indexing) 資料清理：移除重複內容、格式轉換 (如 PDF -> 文字檔)、基本斷詞等。 實體 & 關係擷取：使用 NLP 工具 (如 spaCy、Hugging Face Transformers) 或定制 LLM Prompt 來擷取。 索引與儲存：將文本片段進行向量化（矢量索引）或關鍵字索引；並記錄實體與關係對應的文本位置。 3.2 階層式群集 (Hierarchical Clustering) Leiden / Louvain 分群：依據實體之間的共同關係程度或文本相似度，形成群落 (Communities)。 應用：幫助理解哪些實體主題相關；有助於後續在回答不同領域或子領域時快速聚焦。 3.3 知識圖譜建構 (Knowledge Graph Generation) 節點與邊的落實：透過抽取出的實體（人名、地名、機構名…）作為節點，並將關係 (如「創立」、「屬於」、「發生於」) 作為邊。 圖資料庫選擇：最常見為 Neo4j，也可使用 AWS Neptune、Azure Cosmos DB (Gremlin API) 或其他開源圖資料庫。 結構維護：建議定期更新或在資料流入時動態更新。 3.4 答案生成 (Answer Generation) 的機制 圖結構檢索：依據問題分析所需實體與關係，從圖中找到候選路徑或相關節點。 文本檢索：同時從向量索引 (或全文檢索) 中找出相符段落，輔助 LLM 生成完整回答。 融合與總結：LLM 將檢索到的多重資訊組織成自然語言回答；可附帶解釋推論路徑 (Chain of Thought)。 圖片來源：https://gradientflow.substack.com/p/graphrag-design-patterns-challenges 第四章：GraphRAG 的效能評估與優化 4.1 準確率、召回率與 F1 Score 傳統問答衡量：若有標準答案，可用精確度(Precision) / 召回率(Recall) / F1。 開放式生成：可用 BLEU、ROUGE 等度量生成的文字與參考答案的相似度。 4.2 多跳推理的評估方法 Chain-of-thought 分析：檢查系統在推理過程中是否能正確串連實體關係。 人工審核：對多跳答案進行抽樣檢查。 4.3 細節優化：如何挑選關鍵節點 / 邊 社群 / 聚類分析：可優先挑選與問題上下文最密切的社群。 **信任度 (Confidence Score) **：設定若關係的抽取信度過低則忽略，以降低雜訊。 第五章：進階應用與案例分析 5.1 企業內部知識庫應用 痛點：文件分散、版本眾多、員工跨部門溝通困難。 GraphRAG 解法：搭建知識圖譜將組織結構、產品線、客戶資訊等串起，對複雜內部問題可多跳檢索。 5.2 醫療、法律與金融等領域的複雜查詢 醫療：將症狀、藥物、副作用等做知識圖譜，回答精準且可追蹤來源。 法律：根據條文之間的參照關係或判例關聯性，進行推理與解釋。 金融：跨多個報告、數據表，分析投資風險或交易關係。 5.3 多語言 / 跨文化整合 挑戰：同一家公司在中文、英文文件中的譯名不同。 對策：在圖結構中維護「同義實體」的映射關係；檢索時自動串接。 5.4 實際案例展示 案例：根據 Microsoft Research 或 Neo4j 提供的實際場景做介紹。 第六章：常見問題 實體歧義：同一名稱指不同事物（如「Apple」是公司還是水果？）。 關係抽取不完整：導致圖中重要的邊缺失。 Neo4j 連線或版本衝突：注意套件與資料庫版本的相容性。 生成答案不連貫：可能是 LLM model size / prompt 設計不足。 參考資源 Microsoft GraphRAG 介紹 Deepset — Graph RAG 實踐 Neo4j — What is GraphRAG? Microsoft Research — GraphRAG 用於私有數據檢索 Ontotext — Graph RAG 基礎 LinkedIn 技術分享 — Sparkbit GraphRAG 案例 spaCy Hugging Face Transformers Neo4j 官方文件

• 2. 知識圖譜構建與雙軌實作

  • 3. 知識圖譜理論、圖論

    1. 基本概念與背景 研究動機在處理大規模圖數據（如知識圖譜）時，理解圖的內部結構和特性成為關鍵。圖結構理論為這一問題提供了數學和算法上的依據。 核心定義圖由節點和邊構成，研究內容包括連通性、遍歷、子圖結構等基本問題。這些概念構成了後續理論探討的基礎。 研究方法利用數學工具（例如集合論、矩陣表示和譜分解）來描述和分析圖的結構特點，從而為高效算法設計提供理論支持。 理論意義這些基礎理論不僅是理解圖數據結構的關鍵，也為後續進行更複雜的結構分解與優化提供了必備工具。 2. 圖的小元 (Graph Minor) 2.1 引言 圖論是研究節點（點）和邊之間關係的數學分支。在眾多圖論問題中，如何從一個複雜的圖中提取出具有代表性的簡化結構是一個核心問題。圖的小元理論（Graph Minor）正是解決這一問題的重要工具，它不僅在圖分類、圖同構檢測等領域有廣泛應用，還對設計高效算法、分析知識圖譜等具有深遠影響。 2.2 圖的小元基本概念 定義 圖的小元指的是：如果存在一個圖 (G)，我們可以通過一系列“簡化操作”得到另一個圖 (H)，那麼圖 (H) 就被稱作圖 (G) 的一個小元。換句話說，(H) 可以看作是從 (G) 中「抽取」或「嵌入」出來的一個子結構。 簡化操作 在將一個複雜圖 (G) 簡化成一個較小結構 (H) 的過程中，主要包含以下兩種操作： 節點或邊的刪除（Deletion）移除圖中的部分節點或邊，使圖的結構變得更簡單。這一操作同時也是子圖（Subgraph）構造過程中所使用的方法。 邊收縮（Edge Contraction）選取一條邊，將該邊連接的兩個節點合併成一個節點。這個操作在降低圖的複雜度方面十分有效，因為它不僅減少了節點數，還可能使原本不直接相連的節點在收縮後變得鄰接。 透過這些操作，我們可以保留圖中最關鍵的結構信息，同時去除冗餘或不必要的細節。 2.3 Graph Minor 與 Subgraph 的差異比較 定義上的差異 子圖（Subgraph）： 定義：若圖 (H) 的節點和邊均屬於圖 (G) 的節點和邊的子集，則 (H) 為 (G) 的子圖。 操作：僅允許刪除操作，即僅通過選取部分節點和邊構成 (H)，不涉及任何結構改變。 圖的小元（Graph Minor）： 定義：若圖 (H) 能夠通過對圖 (G) 進行一系列操作（包括節點和邊的刪除以及邊收縮）得到，則 (H) 為 (G) 的小元。 操作：除了刪除操作外，還允許邊收縮操作，這使得小元的概念更為靈活，能夠捕捉圖中的更抽象和隱含的結構。 操作與結果的影響 子圖： 僅保留原圖中的部分結構，不改變剩餘結構之間的連接關係。 典型應用在直接搜索或匹配圖中是否存在某些特定模式。 圖的小元： 通過邊收縮，原圖中原本不直接相連的節點可以合併為鄰接節點，使得小元在結構上可能與原圖有較大不同。 更適合用於捕捉圖中隱含的抽象結構，有助於圖分類、圖同構檢測以及設計高效算法。 實例說明 假設圖 (G) 包含一個三角形（由三個節點構成且兩兩相連）： 子圖情況：如果直接從 (G) 中選取構成三角形的三個節點及其邊，則得到的三角形即為 (G) 的一個子圖。 小元情況：即使 (G) 中三角形的部分結構被其他節點和邊所干擾，通過適當的刪除和邊收縮操作，我們仍可抽取出這個三角形作為 (G) 的一個小元。這裡的小元可能並不是直接的子集，而是經過“變形”後保留的核心結構。 3. 圖結構定理 研究動機當需要從理論上描述所有不包含固定圖 (H) 的大圖結構時，圖結構定理提供了一個統一的構造框架。 定理內容對於任意固定圖 (H)，存在一個整數 (k)，使得所有 H-free 圖都可以通過以下步驟構造： 選取一組嵌入在特定曲面上的基礎圖； 在每個基礎圖上加入不超過 (k) 個局部結構（例如渦旋）； 添加不超過 (k) 個額外節點（頂點），並通過特定方式與原圖連接； 最終通過 (k)-團簇和連接這些結構，形成一個複雜的大圖。 構造方法利用遞歸分解與合併技術，從簡單的圖開始，逐步添加局部結構並進行連接，從而嚴格證明這一結構定理。 實際意義這一定理幫助我們理解複雜圖結構中的潛在簡化現象，指導設計出更高效的圖算法和結構分解策略，對知識圖譜優化同樣具有啟示作用。 4. 理論應用與實際意義 實際需求在設計圖算法、組合優化及跨數據源整合時，需要對圖的結構特性有深入理解，從而制定針對性的解決方案。 應用範例 在算法設計中，利用樹寬較小的圖進行動態規劃或分治策略，提高求解效率。 在數據分解中，通過識別圖的小元和 H-free 性質，將大圖拆分成更易處理的小圖，從而實現高效數據查詢與推理。 在拓撲圖論研究中，分析圖在不同曲面上的嵌入性質，應用於平面圖測試等問題。 技術與價值這些理論工具不僅幫助我們從數學上剖析圖的內部結構，還能夠指導實際系統的優化設計，提高知識圖譜及相關系統在大規模數據處理中的表現。 結論 隨著大數據和智能應用需求的不斷上升，知識圖譜與圖結構理論成為了解決複雜數據組織和高效信息檢索的關鍵技術。講義從技術背景、基本定義、構建方法到理論意義，全面介紹了知識圖譜如何通過結構化表示實體與關係，並從數學與算法角度探討了圖結構理論中的核心概念和定理。這不僅幫助我們理解現有技術的運作原理，也為未來進一步提升系統性能和推動技術創新提供了理論支持。 參考文獻 IBM Think: Knowledge Graph TechTarget: Knowledge Graph in ML Turing: Knowledge Graphs AltexSoft Blog: Knowledge Graph WiseCube: Primer on Knowledge Graphs Blue Brain Nexus: Understanding Knowledge Graphs Built In: Knowledge Graph TextMine: An Introduction to Knowledge Graphs 另外，關於圖結構理論的參考資料包括： Wikipedia - Graph Structure Theorem Dániel Marx, ADFOCS 2013 Paper DTIC Document - Graph Minor Theory ResearchGate: A Survey of Linkless Embeddings arXiv Paper on Graph Structure AMS Bookstore arXiv PDF

  • 4. 圖資料庫 Neo4j 與 Cypher 語言基礎訓練

    模組 1：圖資料庫與 Neo4j 基礎 1. 教學目標 了解圖資料庫的核心概念與應用場景。 認識 Neo4j 的基本組成與運作模式。 能夠在本機或雲端環境安裝並啟動 Neo4j。 了解 Neo4j 提供的工具（Neo4j Browser、Neo4j Bloom）並能簡單操作。 2. 圖資料庫 vs 關聯式資料庫 關聯式資料庫 (RDBMS) 圖資料庫 (Graph DB) 結構 表 (Table)、行 (Row) 節點 (Node)、關係 (Relationship) 主從關係 透過外鍵關聯 直接使用關係 (edges) 查詢語言 SQL Cypher (Neo4j) 擴充性 擴充通常較困難 天生可以水平擴充 (Scale-out) 適用場景 交易型系統、列舉型查詢 圖形關係分析、路徑搜尋、推薦系統等 3. Neo4j 的架構與核心概念 3.1 Neo4j 架構 圖引擎：Neo4j 以高效的圖資料結構儲存資料，可快速進行關係查詢。 存儲層：使用原生圖儲存方式。 查詢層：使用 Cypher 語言進行查詢和操作。 3.2 Neo4j 核心元素 節點 (Node) 圖中的「實體」(例如：人、產品、城市)。 可以包含多個「屬性 (Properties)」。 關係 (Relationship) 節點與節點之間的連結 (例如：朋友關係、購買行為)。 也可以包含「屬性」。 標籤 (Label) 用於將節點分類。 例如：Person、Movie、Company。 關係類型 (Relationship Type) 表示關係的種類。 例如：FRIEND_OF、WORKS_AT、ACTED_IN。 索引 (Index) 與 約束 (Constraint) 用於加速查詢或保證資料一致性。 常見的索引範例：基於節點屬性的索引，如 CREATE INDEX FOR (n:Person) ON (n.name) 4. 安裝與環境設定 4.1 本地安裝（Neo4j Desktop 或 Community Edition） 下載 Neo4j Desktop 前往 Neo4j 官方網站 下載對應作業系統版本。 安裝完成後啟動 Neo4j Desktop。 建立並啟動資料庫 在 Neo4j Desktop 中，新增一個 Project。 新增一個 Local Database，設定好密碼後啟動。 連線到資料庫 使用 Neo4j Browser 或 Neo4j Desktop 內建的瀏覽器連線到 bolt://localhost:7687。 使用安裝時設定的帳號密碼登入。 4.2 雲端部署（Neo4j Aura） 前往 Neo4j Aura 註冊或登入帳號。 建立一個 Neo4j Aura DB，系統會自動產生連線資訊。 使用 Neo4j Browser 或其他工具連線到此雲端資料庫。 4.3. 雲端沙盒版本 5. 使用 Neo4j Browser 與 Neo4j Bloom 5.1 Neo4j Browser 進入方式：若在本機安裝，可透過 http://localhost:7474/ 進入；或是在 Neo4j Desktop 內部的瀏覽器。 功能重點： 輸入 Cypher 查詢指令。 查看圖形化結果或表格式結果。 可以使用 :help 指令查看教學與常見命令。 5.2 Neo4j Bloom 可視化探索工具：支援更直覺的「節點-關係」拖曳與操作。 使用場景： 資料探索：透過關鍵字或篩選器快速找到想要的資料。 可視化報告：將複雜關係以圖型的方式展示。 6. 初步操作示例 查看現在資料庫內所有的節點與關係 MATCH (n) RETURN n LIMIT 25 由於目前可能沒有資料，結果會是空的或僅有系統內建的節點。 創建一個節點 CREATE (p:Person { name: "Alice", age: 25 }) RETURN p 建立一個標籤為 Person，屬性包含 name 和 age 的節點。 檢查剛剛創建的節點 MATCH (p:Person) WHERE p.name = "Alice" RETURN p 若看到節點圖示或表格即可確定資料成功寫入。 刪除一個節點（僅示範用） MATCH (p:Person { name: "Alice" }) DELETE p 若要刪除的節點有關係，需使用 DETACH DELETE 一併刪除所有關係。 7. 實作練習 練習 1：安裝 Neo4j 請學員選擇最適合自己的環境（本機安裝或 Docker）。 啟動 Neo4j 並進入 Neo4j Browser，確認可以輸入查詢。 練習 2：創建基本節點與關係 在 Neo4j Browser 中，創建兩個節點： (p1:Person { name: "Alice", age: 25 }) (p2:Person { name: "Bob", age: 27 }) 為 Alice 與 Bob 之間建立一個關係： CREATE (p1)-[:FRIEND_OF]->(p2) 查詢並顯示這些節點與關係： MATCH (n) RETURN n; 驗證關係是否正確。 練習 3：使用 Neo4j Bloom（若環境允許） 進入 Neo4j Bloom。 找到先前創建的 Person 節點並標記顏色或做分組。 觀察節點與關係的可視化結果。 9. 小結 圖資料庫的基本概念：節點、關係、屬性是理解後續課程的關鍵。 Neo4j 的安裝：可選擇本機、雲端或 Docker，視需求與環境而定。 Neo4j Browser 與 Bloom：提供直觀的查詢介面與圖形化視圖。 在完成本模組後，你已經能夠： 了解為什麼要用圖資料庫，以及與傳統 RDBMS 的差異。 在自己的電腦或雲端啟動並連線 Neo4j。 透過 Neo4j Browser 或 Bloom 進行基礎的圖操作與視覺化。 參考連結 Neo4j 官方文件 Neo4j Desktop 下載 Docker Hub - Neo4j Neo4j Aura 雲端服務 模組 2：Cypher 基礎查詢 1. 教學目標 學會使用 Cypher 的基本查詢語法（MATCH, RETURN, WHERE）。 理解並能執行新增、修改、刪除圖資料的常用指令（CREATE, MERGE, SET, DELETE 等）。 能在 Neo4j 環境中使用 Cypher 建立基礎的圖模型（節點、關係）。 了解如何使用條件過濾與簡單的聚合函數來處理資料。 2. Cypher 語言概觀 Cypher 是 Neo4j 提供的宣告式圖形查詢語言，用來針對節點（Node）與關係（Relationship）進行： 查詢：透過模式匹配（pattern matching）篩選出想要的資料。 建立 / 更新 / 刪除：對圖資料庫做增刪改。 2.1 為什麼使用 Cypher？ 類似 SQL 的結構，容易上手：MATCH 類似 SQL 的 SELECT。 專門為圖關係設計，可快速表達「節點–關係–節點」的匹配邏輯。 高可讀性，對新手較為友善。 3. 基本查詢語法 3.1 MATCH 與 RETURN MATCH：用來描述要在圖中「尋找」何種節點或關係。 RETURN：用來指定要輸出的結果。 範例 MATCH (p:Person) RETURN p 語意：在圖中尋找所有標籤為 Person 的節點，將其回傳。 可能的顯示：在 Neo4j Browser 中看到多個人形節點。 3.2 WHERE 條件過濾 透過 WHERE 可指定屬性、關係等條件來過濾結果。 範例 MATCH (p:Person) WHERE p.age > 25 RETURN p.name, p.age 語意：尋找所有 Person 並篩選出 age > 25 的節點，只回傳名字與年齡。 4. 建立與修改資料 4.1 CREATE 用於建立節點或關係，若資料庫中尚無符合的節點 / 關係，便會新建。 創建節點 CREATE (p:Person { name: "Alice", age: 25 }) RETURN p 創建關係 MATCH (a:Person { name: "Alice" }), (b:Person { name: "Bob" }) CREATE (a)-[:FRIEND_OF]->(b) RETURN a, b 語意：先找到名為 Alice 與 Bob 的節點，然後在兩者之間建立一條 FRIEND_OF 關係。 4.2 MERGE 用於「如果不存在就創建，如果存在就使用」的模式匹配。 避免重複建立相同節點或關係的好工具。 範例 MERGE (p:Person { name: "Charlie" }) RETURN p 若圖中尚未有標籤為 Person、name = "Charlie" 的節點，會自動建立；否則，會直接匹配到現有節點。 4.3 SET 用於設定 / 更新節點或關係的屬性。 範例 MATCH (p:Person { name: "Alice" }) SET p.age = 26, p.city = "Taipei" RETURN p 更新 Alice 的 age 屬性、新增 city 屬性。 4.4 REMOVE 移除節點的標籤或屬性。 範例 MATCH (p:Person { name: "Alice" }) REMOVE p.city // 移除屬性 REMOVE p:Person // 移除標籤 RETURN p 5. 刪除與變更資料 5.1 DELETE 用於刪除節點或關係。 若直接刪除節點，但該節點還有關係存在，Cypher 會報錯。 範例 MATCH (p:Person { name: "Alice" })-[r:FRIEND_OF]->(b) DELETE r 只刪除 Alice 與 Bob 之間的 FRIEND_OF 關係。 5.2 DETACH DELETE 當要連同節點與該節點的所有關係一起刪除時，使用 DETACH DELETE。 範例 MATCH (p:Person { name: "Alice" }) DETACH DELETE p 會刪除 Alice 以及其所有關係。 6. 實作示例與練習 6.1 示例：建立簡易社群圖 步驟 1：建立節點 CREATE (alice:Person { name: "Alice", age: 25 }) CREATE (bob:Person { name: "Bob", age: 27 }) CREATE (charlie:Person { name: "Charlie", age: 30 }) RETURN alice, bob, charlie 步驟 2：建立關係 MATCH (alice:Person { name: "Alice" }), (bob:Person { name: "Bob" }), (charlie:Person { name: "Charlie" }) CREATE (alice)-[:FRIEND_OF]->(bob), (bob)-[:FRIEND_OF]->(charlie), (alice)-[:FRIEND_OF]->(charlie) RETURN alice, bob, charlie 步驟 3：查詢並顯示關係 MATCH (p:Person)-[r:FRIEND_OF]-(q:Person) RETURN p, r, q 檢查社群關係是否正確。 6.2 練習 1：資料新增與修改 新增一個節點，標籤為 Movie，並指定屬性 title 為 "The Matrix"，year 為 1999。 更新該節點的屬性 year 為 1999 改為 2000。 將節點的標籤由 Movie 改為 Film（先 REMOVE，再 SET）。 6.3 練習 2：條件篩選 查詢所有 Person，挑選出 age > 26 的名單。 回傳名單裡每個人的 name 與 age。 篩選結果後，若有需要，將符合條件的人加上標籤 Senior。 6.4 練習 3：刪除操作 嘗試使用 DELETE 刪除某個有關係的節點，觀察系統回應（預期會出錯）。 使用 DETACH DELETE 成功刪除該節點與相關關係。 驗證是否刪除成功。 7. 常見問題與注意事項 CREATE vs MERGE CREATE：每次執行都會產生全新的節點或關係。 MERGE：若已存在符合條件的節點或關係，則不重複建立。 大小寫敏感度 參考預設：屬性名稱區分大小寫，而標籤與關係類型也區分大小寫。 查詢效能 剛開始資料量不大時不明顯，但實務上會使用索引（CREATE INDEX）優化查詢。 刪除資料 請小心操作 DETACH DELETE，因為會連帶刪除所有關係，無法復原。 8. 小結 本模組介紹了 Cypher 的基本查詢、資料建立與刪除等語法。 透過 MATCH ... RETURN ...，我們可以很直觀地取得節點及關係；使用 CREATE、MERGE、SET、DELETE 等指令，能對圖中的資料進行靈活操作。 重點：理解 MATCH 與 MERGE 的差異、學會使用 WHERE 做條件篩選，以及掌握基本的增刪改查工作流程。 參考連結 Neo4j Official Cypher Manual Neo4j Developer Guides Cypher Refcard (官方速查表) 模組 3：進階 Cypher 操作 1. 教學目標 熟悉進階模式匹配技巧（OPTIONAL MATCH, WITH, UNWIND 等）。 了解常用聚合函數（COUNT(), AVG(), SUM(), COLLECT()）並應用於統計分析。 學會使用索引與檢查查詢計劃（EXPLAIN, PROFILE）來優化查詢效能。 能運用複雜查詢模式（FOREACH, CASE）以及批量寫入方法（CALL apoc.periodic.iterate）。 2. 進階模式匹配與變數 2.1 OPTIONAL MATCH 用途：在查詢關係/節點時，若相關資料不存在，也不會中斷整個查詢，而是返回 null 值。 適用情境：查詢某個使用者的「選擇性」關係，如使用者可能沒有朋友、或沒有指定某屬性時。 範例 // 若 p 沒有繼續關係存在，不會報錯，只是回傳 null MATCH (p:Person) OPTIONAL MATCH (p)-[r:FRIEND_OF]->(q:Person) RETURN p.name AS person, q.name AS friend 若 p 沒有朋友，就會看到 friend 欄位是 null。 2.2 WITH 管道操作 功能：將前一次查詢的結果傳遞給下一個查詢，可用來分段處理、聚合後再進行操作。 避免變數衝突：在大型查詢中，使用 WITH 能將階段性結果命名後再使用。 範例 MATCH (p:Person)-[:FRIEND_OF]->(q:Person) WITH p, COUNT(q) AS friendCount WHERE friendCount > 2 RETURN p.name AS person, friendCount 第一步：找到所有 Person 與朋友之間的關係，計算朋友數。 第二步：只篩選朋友數大於 2 的人並回傳。 2.3 UNWIND 功能：將列表 (List) 的資料「展開」成多筆獨立的記錄，常用於批量寫入或處理陣列資料。 範例 WITH ["Alice", "Bob", "Charlie"] AS names UNWIND names AS name CREATE (p:Person { name: name }) RETURN p 將 names 列表中的 3 個名稱逐一展開並各自建立節點。 3. 聚合函數與資料統計 3.1 常用聚合函數 COUNT()：計算資料筆數 SUM()：對某屬性數值做加總 AVG()：對某屬性數值做平均 COLLECT()：將多筆記錄彙整成列表 範例：計算每個人朋友數 MATCH (p:Person)-[:FRIEND_OF]->(q:Person) RETURN p.name AS person, COUNT(q) AS numFriends ORDER BY numFriends DESC 依照朋友數做降冪排序。 3.2 組合使用 COLLECT() MATCH (m:Movie)<-[:ACTED_IN]-(actor:Person) RETURN m.title AS movie, COLLECT(actor.name) AS actors 回傳每部電影的演員清單，COLLECT() 產生一個列表。 4. 索引與效能優化 4.1 索引 (Index) 目的：加速查詢。例如，當我們常以 name 屬性搜尋 Person 節點時，可對 name 建立索引。 範例：CREATE INDEX person_name_index FOR (p:Person) ON (p.name) Neo4j 4.x/5.x 之後的語法會有不同版本，也可能支援 CREATE TEXT INDEX、CREATE RANGE INDEX 等。 4.2 檢查查詢計劃：EXPLAIN 與 PROFILE **EXPLAIN**：不會執行查詢，但顯示執行計劃。 **PROFILE**：執行查詢並顯示實際執行計劃與運行統計。 範例 EXPLAIN MATCH (p:Person) WHERE p.name = "Alice" RETURN p 查看是否有使用索引或做了全圖掃描 (NodeByLabelScan)。 5. 複雜查詢技巧 5.1 FOREACH 處理批量更新 適用於需要對已經「匹配」到的結果做批次操作時。 範例 MATCH (p:Person { city: "Taipei" }) WITH COLLECT(p) AS persons FOREACH (onePerson IN persons | SET onePerson.city = "Taipei City" ) 將所有在 Taipei 的人更新為 Taipei City。 5.2 CASE 條件判斷 用於查詢結果中的邏輯判斷，類似 SQL 中的 CASE WHEN THEN ELSE END。 範例 MATCH (p:Person) RETURN p.name AS name, CASE WHEN p.age >= 18 THEN "Adult" ELSE "Minor" END AS ageGroup 5.3 交易與批量寫入：CALL apoc.periodic.iterate APOC（Awesome Procedures on Cypher）為 Neo4j 的常用外掛庫，提供許多實用工具。 apoc.periodic.iterate：在大量資料操作時，能分批處理以避免單次交易量過大。 範例 CALL apoc.periodic.iterate( "MATCH (p:Person) RETURN p", "SET p.active = true", {batchSize:1000, parallel:true} ) 分批（每次 1000 筆）對所有 Person 設定 active = true。 6. 實作示例與練習 6.1 練習：計算社群中每個使用者的朋友數並篩選 建立或使用既有的社群圖，例如 Person 與 FRIEND_OF 關係。 撰寫查詢，使用 MATCH 與 COUNT() 計算每個使用者的朋友數。 篩選出朋友數大於 2 的使用者，並使用 WITH 配合條件過濾。 回傳符合條件者的名字與朋友列表（可用 COLLECT()）。 6.2 練習：建立索引並測試效能 建立一個索引： CREATE INDEX person_name_index FOR (p:Person) ON (p.name) 使用 PROFILE 對比索引前後查詢時間： PROFILE MATCH (p:Person) WHERE p.name = "Alice" RETURN p 觀察執行計劃中是否顯示使用索引掃描。 6.3 練習：使用 FOREACH 或 UNWIND 進行批量更新 準備一個名稱列表，批量建立節點或更新節點屬性。 使用 OPTIONAL MATCH 來處理資料不完整或關係不存在的狀況。 7. 常見問題與注意事項 OPTIONAL MATCH 陷阱 使用 OPTIONAL MATCH 後，若沒有匹配到資料，返回的資料欄位會是 null；後續操作需考慮 null 處理邏輯。 WITH 的資料範圍 WITH 會分隔查詢階段，只有在 WITH 之後被明確帶過去的變數，才能在下一階段使用。 大批量更新 建議善用 FOREACH、UNWIND 或 apoc.periodic.iterate 分批執行，避免單次交易過大導致記憶體不足或超時。 索引與節點數量 建立索引雖能優化查詢，但也會佔用空間並增加寫入成本，需權衡建立哪些索引最有效。 8. 小結 在本模組，你學習了： 進階模式匹配（OPTIONAL MATCH, WITH, UNWIND）的原理與用途。 聚合函數（COUNT(), AVG(), SUM(), COLLECT()）應用於圖形資料的統計分析。 效能優化：如何使用索引、EXPLAIN 與 PROFILE 分析查詢計劃。 複雜查詢：FOREACH, CASE 以及大量更新的 apoc.periodic.iterate。 參考連結 Neo4j Cypher Manual - Advanced Queries APOC Library (Awesome Procedures on Cypher) Neo4j Performance Tuning 模組 4：圖分析與推薦系統 1. 教學目標 了解常見的圖演算法（最短路徑、PageRank、社群偵測等）及其應用場景。 學習使用 Neo4j 提供的 Graph Data Science (GDS) Library 或其他工具來執行圖分析。 能夠利用圖演算法成果，設計與實作簡易的推薦功能（朋友推薦、產品推薦等）。 掌握常見的推薦系統概念與在 Neo4j 中的實際落地方法。 2. 常見圖演算法與應用 2.1 最短路徑 (Shortest Path) 意義：計算兩個節點之間路徑的最小成本（可依權重或邊數計算）。 用途： 尋找社群中兩個人最短的「關係距離」。 地理/物流路徑最佳化。 Cypher 基本示例（僅適用於簡單最短路徑）：MATCH (start:Person {name: "Alice"}), (end:Person {name: "Bob"}), p = shortestPath((start)-[:FRIEND_OF*]-(end)) RETURN p [:FRIEND_OF*] 表示可以走零到多段 FRIEND_OF 關係。 shortestPath() 只能處理無權重的路徑。若需要權重計算，建議使用 GDS 函式。 2.2 PageRank 原理：源於網頁排名演算法，衡量每個節點的「重要性」或「影響力」。 用途： 社群網路：找出「最具影響力」的使用者。 研究引用關係：找出「最具影響力」的文獻。 GDS Library 示例（假設已安裝 GDS 外掛）：CALL gds.pageRank.write({ nodeProjection: 'Person', relationshipProjection: 'FRIEND_OF', writeProperty: 'pagerank' }) 為每個 Person 寫入屬性 pagerank，用以表示該節點的影響力分數。 2.3 社群偵測 (Community Detection) 目標：根據節點與關係的結構，將節點分成不同的社群。 常見演算法：Louvain、Label Propagation 等。 用途： 社群網路分群：找出興趣相近或互動頻繁的使用者群組。 推薦與行銷：對同一社群的用戶推送類似商品或內容。 GDS Library 示例（使用 Louvain）：CALL gds.louvain.write({ nodeProjection: 'Person', relationshipProjection: 'FRIEND_OF', writeProperty: 'community' }) 為每個 Person 寫入屬性 community，表示該人所屬的社群。 2.4 連通成分分析 (Connected Components) 意義：找出圖中哪些節點彼此相連，屬於同一「連通子圖」。 用途： 檢查圖是否有互不連通的區塊。 針對大型網路，做區塊分割與獨立分析。 GDS Library 示例：CALL gds.wcc.write({ nodeProjection: 'Person', relationshipProjection: 'FRIEND_OF', writeProperty: 'componentId' }) 為每個人寫入 componentId，標示其屬於哪個連通子圖。 3. 推薦系統在 Neo4j 的應用 3.1 推薦系統基礎概念 過濾方式 **協同過濾 (Collaborative Filtering)**：根據相似用戶的行為做推薦。 **內容過濾 (Content-based)**：根據產品或內容本身的屬性（標籤、類別）做推薦。 **混合過濾 (Hybrid)**：結合協同過濾與內容過濾。 在圖資料庫中的優勢 自然地表達用戶與物品（或內容）之間的關係，並輕鬆延伸至社群關係。 快速查詢「朋友喜歡哪些商品」、「相似用戶還喜歡哪些內容」。 3.2 朋友推薦 (Friend Recommendation) 邏輯： 透過「朋友的朋友」(Friend-of-Friend) 進行推薦； 若許多共同朋友，則推薦可能性更大。 Cypher 範例：MATCH (me:Person {name: "Alice"})-[:FRIEND_OF]->(friend:Person)-[:FRIEND_OF]->(fof:Person) WHERE fof <> me // 排除自己 RETURN fof.name AS recommendedFriend, COUNT(*) AS mutualFriends ORDER BY mutualFriends DESC 簡單依「共同好友數量」決定推薦度。 3.3 物品推薦 (Item Recommendation) 邏輯： 若多人 (User) 同時喜歡 (LIKES) 相同產品 (Item)，這些人之間可視為相似度較高； 可找到與自己相似的人所喜愛的其它產品，進行推薦。 Cypher 示例：MATCH (me:Person {name: "Alice"})-[:LIKES]->(item:Item)<-[:LIKES]-(other:Person)-[:LIKES]->(otherItem:Item) WHERE NOT (me)-[:LIKES]->(otherItem) RETURN otherItem.name AS recommendedItem, COUNT(other) AS similarityScore ORDER BY similarityScore DESC 依「多少人同時喜歡該產品」作為相似度分數。 4. 實作範例：社群推薦場景 以下是一個綜合示例，透過社群網路 + 共同喜好來推薦朋友或電影。 4.1 準備數據 建立一些使用者 (Person) 節點、電影 (Movie) 節點，以及「觀看 / 評分」等關係： CREATE (a:Person {name: "Alice"}), (b:Person {name: "Bob"}), (c:Person {name: "Charlie"}), (m1:Movie {title: "Inception"}), (m2:Movie {title: "Interstellar"}); // 建立朋友關係 CREATE (a)-[:FRIEND_OF]->(b), (b)-[:FRIEND_OF]->(c); // 建立喜好或觀看關係 CREATE (a)-[:LIKES {rating: 5}]->(m1), (a)-[:LIKES {rating: 4}]->(m2), (b)-[:LIKES {rating: 4}]->(m1), (c)-[:LIKES {rating: 3}]->(m1); 檢查資料是否成功建立： MATCH (n) RETURN n LIMIT 25 在 Neo4j Browser 檢視圖形。 4.2 試用 PageRank / 社群分析 PageRank（針對朋友關係）： CALL gds.pageRank.write({ nodeProjection: 'Person', relationshipProjection: 'FRIEND_OF', writeProperty: 'pagerank' }) 完成後可透過以下查詢查看 Pagerank：MATCH (p:Person) RETURN p.name, p.pagerank ORDER BY p.pagerank DESC 社群偵測（Louvain）： CALL gds.louvain.write({ nodeProjection: 'Person', relationshipProjection: 'FRIEND_OF', writeProperty: 'community' }) 檢視結果：MATCH (p:Person) RETURN p.name, p.community 4.3 朋友推薦與電影推薦示例 朋友推薦： MATCH (me:Person {name: "Alice"})-[:FRIEND_OF]->(friend:Person)-[:FRIEND_OF]->(fof:Person) WHERE fof <> me RETURN fof.name AS recommendedFriend, COUNT(friend) AS mutualFriends ORDER BY mutualFriends DESC 電影推薦（若 Alice 尚未看過的電影）： MATCH (me:Person {name: "Alice"})-[:LIKES]->(commonMovie:Movie)<-[:LIKES]-(other:Person)-[:LIKES]->(newMovie:Movie) WHERE NOT (me)-[:LIKES]->(newMovie) RETURN newMovie.title AS recommendedMovie, COUNT(DISTINCT other) AS similarityScore ORDER BY similarityScore DESC 5. 常見問題與注意事項 GDS Library 安裝 需確保安裝對應版本的 Graph Data Science Plugin，並與 Neo4j 主版本相容。 大資料量的效能 圖演算法對記憶體與計算資源要求較高，需考量叢集方案或進行分批分析。 演算法參數調整 PageRank 的阻尼係數 (damping factor)、Louvain 的最低社群門檻等參數可能需要調校，才能得出較佳結果。 資料清理與前處理 需先確保節點與關係定義明確、屬性格式正確，避免演算法執行時產生大量錯誤或失真。 6. 小結 在本模組，你將學到： 圖分析：最短路徑、PageRank、社群偵測等演算法，並理解其核心概念與應用範圍。 Neo4j GDS：透過 Graph Data Science Library 快速執行圖演算法並將結果寫入節點屬性。 推薦系統：如何利用圖結構關係（例如：共同朋友、共同喜好）實作好友推薦或產品推薦。 實戰演練：整合圖分析、推薦邏輯，體會圖資料庫在社群分析與推薦場景的優勢。 參考連結 Neo4j Graph Data Science Library Neo4j Documentation - GDS Algorithms Neo4j Recommendation Use Cases Collaborative Filtering in Neo4j Blog 模組 5：Neo4j 與外部系統整合 1. 教學目標 學習如何使用程式語言（Python、Node.js 等）連接 Neo4j 並進行 CRUD 操作。 了解如何整合資料分析工具（如 Pandas）進行資料匯入或匯出。 掌握 Neo4j 與 Web Framework（Flask、Django、Express 等）組合，開發 RESTful API 或後端服務。 瞭解 Neo4j 在 RAG（Retrieval-Augmented Generation）應用中的角色與常見整合模式（GraphRAG）。 2. Neo4j 驅動與程式語言整合 2.1 官方驅動 (Official Drivers) Neo4j 提供多種官方驅動程式，如 Java、Python、JavaScript、**.NET、Go** 等，可直接透過程式碼與 Neo4j 通訊。 連線方式：透過 bolt:// 或 neo4j:// 協定進行連接。 認證與安全：提供基本的帳密驗證，也能設定 TLS/SSL 加密連線。 Python 範例 (neo4j 驅動) from neo4j import GraphDatabase uri = "bolt://localhost:7687" driver = GraphDatabase.driver(uri, auth=("neo4j", "password")) def create_person(tx, name): tx.run("CREATE (p:Person {name: $name})", name=name) with driver.session() as session: session.write_transaction(create_person, "Alice") driver.close() 重點：先建立 GraphDatabase.driver，再用 session 執行寫入或讀取交易 (write_transaction / read_transaction)。 2.2 第三方套件 (Python - py2neo) py2neo 是一個友善的 Python 庫，提供更高階的 API 進行操作。 範例： from py2neo import Graph, Node, Relationship graph = Graph("bolt://localhost:7687", auth=("neo4j", "password")) alice = Node("Person", name="Alice") bob = Node("Person", name="Bob") rel = Relationship(alice, "FRIEND_OF", bob) graph.create(alice | bob | rel) 3. 與資料分析工具整合 3.1 Pandas DataFrame 轉換 常見場景： 匯入 CSV / Excel 資料到 Neo4j 匯出 Neo4j 查詢結果到 DataFrame 做進一步分析 Python 範例：將查詢結果轉為 DataFrame import pandas as pd from neo4j import GraphDatabase uri = "bolt://localhost:7687" driver = GraphDatabase.driver(uri, auth=("neo4j", "password")) cypher_query = """ MATCH (p:Person) RETURN p.name AS name, p.age AS age """ with driver.session() as session: result = session.run(cypher_query) records = list(result) df = pd.DataFrame([r.data() for r in records]) print(df) driver.close() 重點：先執行 Cypher，取得 result，再將其轉為 DataFrame。 3.2 匯入 CSV 資料到 Neo4j 方法 1：利用 Neo4j 提供的 LOAD CSV 語句 LOAD CSV WITH HEADERS FROM "file:///people.csv" AS row CREATE (:Person {name: row.name, age: toInteger(row.age)}) 方法 2：透過程式語言讀取 CSV，再使用程式迴圈 CREATE 或 MERGE 節點。 4. 與 Web Framework 整合 4.1 Python - Flask 範例 安裝套件：pip install flask neo4j 建立簡易 API： from flask import Flask, request, jsonify from neo4j import GraphDatabase app = Flask(__name__) driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "password")) @app.route('/persons', methods=['GET']) def get_persons(): cypher_query = "MATCH (p:Person) RETURN p.name AS name, p.age AS age" with driver.session() as session: results = session.run(cypher_query) persons = [r.data() for r in results] return jsonify(persons) if __name__ == '__main__': app.run(debug=True) 啟動 API： 執行 python app.py 後，可在瀏覽器或 Postman 上測試 http://127.0.0.1:5000/persons。 5. Neo4j 與 RAG (Retrieval-Augmented Generation) 5.1 RAG 概念 RAG：在 Large Language Model (LLM) 無法儲存龐大資料的情況下，將外部知識庫（如資料庫、檔案系統、向量資料庫、圖資料庫）與 LLM 結合。 用圖資料庫的好處： 能表達複雜的關係與上下文。 更直覺地做知識圖譜 (Knowledge Graph) 的連結查詢。 5.2 GraphRAG 的應用 GraphRAG：藉由圖資料庫提供的關聯路徑或上下文資料，讓 LLM 在生成答案時能引入更豐富且準確的資訊。 實作思路： 使用者的問題 -> 先到 Neo4j 查詢相關節點與關係 -> 將結果打包成上下文 -> 再送到 LLM 做回答。 在 LLM 的 Chain 或 Agent 中，加上一個「圖查詢」工具，如 cypher_query_tool，自動生成並執行 Cypher Query。 5.3 簡易範例 # 假設有個函式 run_cypher(query) 能執行 Cypher 並回傳結果 # 1. 接收使用者輸入 user_question = "請問 Alice 的朋友都住在哪些城市？" # 2. 生成 Cypher（此處只是示意，可透過程式自動生成） cypher_query = """ MATCH (a:Person {name: 'Alice'})-[:FRIEND_OF]->(f:Person) RETURN f.name AS friendName, f.city AS city """ # 3. 執行查詢 results = run_cypher(cypher_query) # 4. 將查詢結果整理成文字上下文 context_text = "" for record in results: context_text += f"{record['friendName']} 住在 {record['city']}\n" # 5. 將 context_text 與 user_question 一起餵給 LLM 做回答 # pseudo-code: answer = LLM.generate_answer(user_question, context_text) 透過此流程，就能讓 LLM 具備「即時」且「圖形化」的關係知識檢索能力。 6. 實作練習與示例 6.1 Python 整合練習 建立一個簡易的 Python 腳本，透過 neo4j 官方驅動連接本機 Neo4j。 撰寫函式 create_person(name, age) 與 find_person_by_name(name)，並在程式中測試。 顯示查詢結果，將其轉為 Pandas DataFrame 後做基本分析。 6.2 Web API 練習 使用 Flask 建立一個能查詢 Person 資料的 API。 在 Postman 或瀏覽器中呼叫 API，並確認能正確回傳結果。 若有時間，可加入「新增 / 更新 / 刪除」等端點，完成一個簡易的 CRUD 服務。 6.3 RAG 整合練習 (選用) 構建一個簡單的知識圖，包含數個主題、關鍵字、關係。 用程式碼撰寫一個「先查圖，再問 LLM」的流程。 可測試 ChatGPT API 或其他 LLM，給它查詢結果作為上下文，觀察回答是否更準確。 8. 小結 在本模組，你學習了： 官方與第三方驅動：如何透過程式語言（Python、Node.js 等）與 Neo4j 建立連線並操作圖資料。 資料分析整合：使用 Pandas 或 LOAD CSV 進行資料匯入與查詢結果的匯出。 Web Framework：整合 Flask、Django、Express 等，開發 RESTful API 或 Web 後端服務。 RAG 應用：利用圖資料庫作為知識庫，協助 LLM 查詢並生成更精準的回答。 參考連結 Neo4j Drivers & Language Guides py2neo Flask 官方文件 / Django 官方文件 Node.js Neo4j Driver LangChain Graph RAG Example

  • 5. NetworkX 基礎實作教學

    1. NetworkX 套件概述 簡介： NetworkX 是一個 Python 套件，用來建立、操作及分析圖資料結構與網絡。 支援多種圖類型與豐富的圖論演算法（例如最短路徑、中心性分析等）。 官方文件與教程： NetworkX 官方文件 NetworkX Tutorial 安裝方式： pip install networkx 2. NetworkX 基本操作 2.1 建立與操作圖 建立一個簡單的無向圖： import networkx as nx import matplotlib.pyplot as plt # 建立無向圖 G = nx.Graph() # 新增節點 G.add_node("A") G.add_nodes_from(["B", "C", "D"]) # 新增邊 (可同時新增節點) G.add_edge("A", "B") G.add_edges_from([("A", "C"), ("B", "D")]) # 顯示圖形 nx.draw(G, with_labels=True, node_color='lightblue', edge_color='gray') plt.show() 2.2 設定節點與邊的屬性 為節點與邊添加屬性： # 節點屬性 G.nodes["A"]['role'] = "中心節點" # 邊屬性 G["A"]["B"]['weight'] = 2.5 # 查詢屬性 print(G.nodes(data=True)) print(G.edges(data=True)) 3. 進階圖論操作與分析 3.1 常見圖論算法 最短路徑： # 計算從 A 到 D 的最短路徑 path = nx.shortest_path(G, source="A", target="D") print("最短路徑：", path) 中心性分析： # 計算各節點的度中心性 degree_centrality = nx.degree_centrality(G) print("度中心性：", degree_centrality) 圖遍歷（例如 BFS）： bfs_nodes = list(nx.bfs_tree(G, source="A")) print("BFS 遍歷結果：", bfs_nodes) 3.2 實戰案例：知識圖譜構建 案例背景： 建立一個電影知識圖譜，包含電影、演員與導演三種實體及其關係 實作範例： # 建立有向圖 (知識圖譜通常會使用有向圖表達關係) KG = nx.DiGraph() # 新增節點（實體） KG.add_node("電影A", type="電影") KG.add_node("導演X", type="導演") KG.add_node("演員Y", type="演員") KG.add_node("演員Z", type="演員") # 新增邊（關係） KG.add_edge("導演X", "電影A", relation="執導") KG.add_edge("演員Y", "電影A", relation="主演") KG.add_edge("演員Z", "電影A", relation="配角") # 可視化知識圖譜 pos = nx.spring_layout(KG) nx.draw(KG, pos, with_labels=True, node_color='lightgreen', arrows=True) # 顯示邊的標籤 edge_labels = nx.get_edge_attributes(KG, 'relation') nx.draw_networkx_edge_labels(KG, pos, edge_labels=edge_labels) plt.show() 4. 圖形視覺化與佈局調整 不同佈局方式： Spring Layout（彈簧佈局） Circular Layout（圓形佈局） Shell Layout（同心圓佈局） 調整視覺化參數： pos = nx.spring_layout(G) nx.draw_networkx(G, pos, node_color='lightblue', edge_color='gray', node_size=800, font_size=12) plt.title("NetworkX 圖形示例") plt.show() 互動視覺化工具： 可考慮結合 Plotly、Bokeh 或其他互動式視覺化工具，提供動態圖形展示 5. 延伸應用與實際案例 5.1 資料預處理與匯入 從 CSV、JSON 或資料庫讀取圖資料： import csv G_data = nx.Graph() with open('edges.csv', 'r', encoding='utf-8') as f: reader = csv.reader(f) for row in reader: node1, node2 = row[0], row[1] G_data.add_edge(node1, node2) 5.2 與其他圖資料庫的比較 NetworkX vs Neo4j： NetworkX 適合用於記憶體中圖資料的處理與分析 Neo4j 適合大規模、持久化的圖資料管理 5.3 實戰專案 專案設計： 選取一個主題（如社群網絡、知識圖譜、網絡爬蟲） 從網路或公開資料集中擷取資料，進行預處理後利用 NetworkX 建構圖 分析圖中關鍵節點、社群結構或路徑信息，並製作報告 6. 參考資源與延伸閱讀 官方文件： NetworkX Documentation 線上文章： 搜尋關鍵字：「Python NetworkX 教學」、「NetworkX 實例」等，可參考 Medium、CSDN 等平台上的實作文章 影片教學： YouTube 搜尋「NetworkX 教學」或「Python 網絡分析」，例如 Data Science 或 Python 教學頻道 GitHub 專案： 搜尋「NetworkX tutorial」、「NetworkX examples」，參考實作案例與完整範例程式碼 書籍推薦： “Network Science” by Albert-László Barabási（輔助理解圖論概念） 與 Python 相關的圖論與網絡分析書籍（書中通常附有 NetworkX 的案例）

• 3. 財務金融知識圖譜儀表板

  • 6. 實戰演練 - 財務金融知識圖譜

    學習目標 認識財務報告相關資料 從 0 至 1 建構知識圖譜 資料來源：公開資訊觀測站 前處理完成的資料：📎和泰汽車2023年公司投資關係.xlsx 開發目標 抓取公司投資關係資料 將投資資料轉換成 Graph 型態，並匯入至 Neo4j 資料庫 根據查詢需求，顯示出知識圖譜 程式碼

• 4. GraphRAG 的應用與未來發展

  • 7. GraphRAG 理論

    第一章：GraphRAG 的系統架構 1. 索引建立（Indexing Time） GraphRAG 的第一階段是將原始文本資料建構成圖索引（Graph Index），透過分塊、實體關係抽取、社群檢測等流程，為後續查詢做準備。 A. 文本分塊（Text Chunking） 目的 將大規模文本資料切分成較小片段（chunks），以適配 LLM 的上下文長度限制 同時避免過度切割造成關鍵資訊斷裂 分塊策略 固定長度切割： 每個 chunk 約 600～1000 tokens 適用於一般性文本 語義切割： 利用段落、標題或斷句等結構分割 適合段落結構明確的領域文本（如論文、技術報告） 混合式策略： 先依語義切割，再輔以固定長度控制，確保文本量相對均衡 建議：針對技術文件、新聞報導等，嘗試 600～800 tokens 的固定長度切割並保留 50～100 tokens 重疊，通常能兼顧上下文完整性與LLM 容量。 代碼示例 def split_into_chunks(text, chunk_size=600, overlap=100): chunks = [] start = 0 while start < len(text): end = min(start + chunk_size, len(text)) chunk = text[start:end] chunks.append(chunk) start += (chunk_size - overlap) # 保留部分重疊 return chunks 小結 透過合理的分塊策略，可確保後續的實體／關係抽取不會因關鍵資訊被截斷而遺漏，同時能有效使用 LLM 的上下文容量。 B. 實體／關係抽取（Entity & Relation Extraction） 目的 使用 LLM 從文本塊中提取「實體」（如人名、機構、產品）與「關係」（如合作、投資、競爭） 建立知識圖譜所需的節點與邊 Prompt 設計建議 明確列出目標：請 LLM 尋找重要的實體和它們之間的關聯 格式化輸出：可使用 JSON、三元組、TSV 等，後續便於程式處理 多輪檢查（Gleanings）：再次詢問 LLM 是否遺漏了某些實體或關係 實體合併（Entity Merging） 挑戰：相同實體可能以不同名稱出現（如「Google LLC」與「Google」） 對策： 擬定規則或利用 LLM embeddings 判斷相似度，將重複實體進行合併 可在抽取後進行一次全局掃描，將相似度高的節點標記為相同實體 常見錯誤與處理方法 LLM 幻覺：模型可能捏造關係；可透過要求來源佐證或多輪驗證減少此情況 抽取過於籠統：Prompt 不明確導致 LLM 只回傳非常籠統的實體，需在提示中指定要辨識的對象屬性、範圍 小結 實體／關係抽取是建構圖索引的關鍵步驟，成功與否取決於 Prompt 設計、重複實體合併，以及對模型幻覺的防範措施。 C. 建構圖索引與屬性處理 節點（Nodes） 即抽取出的實體，每個節點可包含多種屬性（如描述、時間） 邊（Edges） 即實體之間的關係，可設定加權（如關聯度、共現次數） 屬性（Attributes） 包括事件、狀態、地理資訊等，用於豐富圖的可查詢度 性能優化 若實體／關係數量極大，可考慮用資料庫（如 Neo4j、NebulaGraph）來儲存 排序或過濾「低頻節點」以減少雜訊 小結 建構圖索引是將抽取結果結構化的過程，良好的資料結構與資料庫選擇能提高後續查詢效率並減少維護成本。 D. 社群檢測（Community Detection） Leiden 演算法 目的：將圖拆分成若干「社群（Communities）」，使得社群內節點連結緊密、社群間連結較弱 多層級（C0~C3）： C0：根社群或較粗粒度主題 C1、C2：依序深入細分領域 C3：最細節的主題分群 參數調整指南 Resolution：決定社群的大小與數量 Randomization：多次迭代以取得穩定且高模組化度（Modularity）的劃分 社群品質評估 Modularity：越高代表社群更具凝聚力 Node Coverage：確保大多數節點分配到合理的社群中 人工作驗：針對重要主題進行人工抽樣驗證 社群摘要 將每個社群內容再次用 LLM 壓縮成簡短描述，後續查詢可直接引用 若層級深，摘要層層相依，可避免 Token 過度消耗 可視化示例 +-----------+ +-----------+ | 社群A | <----->| 社群B | +-----------+ +-----------+ | \ / | | \ / | | \ ... / | | +-----------+ | | 社群C | +-------------------------+ 圖中顯示各社群之間的邊連結程度，C0~C3 則視不同粒度切換。 小結 社群檢測是 GraphRAG 與傳統 RAG 最大的差異之一，能夠將龐大的知識圖分門別類，進而支援更精準的「全局」或「局部」查詢。 2. 查詢處理（Query Time） 在完成索引建立後，查詢處理階段則透過社群摘要與 Map-Reduce 生成最終答案。 A. 查詢解析與社群選擇 查詢解析 分析查詢的主題、範圍、細節需求 若查詢較宏觀，可直接從 C0 或 C1 社群著手 若查詢需要細節，考慮 C2、C3 社群選擇標準 語義相似度：用嵌入檢索找最符合查詢意圖的社群 社群大小：確保答案不會因社群過大而過度冗長，也不會過度切割失去上下文 小結 合適的社群選擇能大幅降低 Token 消耗，也提高答案的聚焦度；對更複雜的查詢，可以多個社群同時參與。 B. Map-Reduce Summarization Map 步驟 針對每個相關社群摘要，分別詢問 LLM：「此社群對該查詢有何回答？」 要求 LLM 輸出回答及打分（score, 0-100），分數過低者直接排除 Reduce 步驟 將分數高的部分答案，依序加入新上下文 在 Token 容許範圍內，融合所有局部答案，讓 LLM 最終總結成全局回答 代碼示例（簡化） def map_reduce_query(query, community_summaries, llm): partial_answers = [] # Map for summary in community_summaries: ans, score = llm.answer_with_score(query, summary) if score > 0: partial_answers.append((ans, score)) # Sort by score desc partial_answers.sort(key=lambda x: x[1], reverse=True) # Reduce final_context = "" for ans, sc in partial_answers: if len(final_context) + len(ans) < TOKEN_LIMIT: final_context += ans + "\n" else: break global_answer = llm.generate_final(query, final_context) return global_answer 小結 透過 Map-Reduce，不同社群內容能被同時考量，在降低 Token 消耗的同時，最大程度保留全局細節。 3. 實踐練習／思考問題 文本分塊實踐 選擇一份 2,000 字的新聞文件，嘗試以 固定長度 和 語義切割 兩種方式分塊，比較抽取到的實體／關係是否有差異 Prompt 設計探索 針對同一份 chunk，嘗試不同的 Prompt（如要求輸出 JSON、要求來源佐證、限制回答語氣等），觀察實體抽取精度、幻覺比例 Leiden 參數調整 使用 Python 庫（如 networkx、igraph）對同一份知識圖進行社群偵測，觀察 Resolution 參數改變如何影響社群大小與數量 Map-Reduce 模擬 模擬多社群並行回答並彙整，觀察最終答案的全面性與 Token 開銷 思考：在什麼情況下，會需要更精細的社群劃分（C3），而非使用較高層的 C1 或 C2？ 4. 常見問題（FAQ） Q：如果在抽取時，LLM 一直產生「不存在的實體」怎麼辦？A：可在 Prompt 中強調「只限於文本明確提及的內容」，並加入多輪驗證或來源引用。 Q：社群檢測後，某些社群節點數極少或過大怎麼辦？A：可調整 Leiden 演算法的 Resolution，或進行手動合併／拆分。 Q：Map-Reduce 時，若某個社群回答重複度極高，會導致 Token 浪費嗎？A：可以利用同義檢測或打分機制過濾重複答案，同時縮短長度後再整合。 Q：每次查詢都要跑 Map-Reduce，計算量會很大嗎？A：可以先使用語義檢索篩選最相關的社群，再對這些社群進行 Map-Reduce，即可避免遍歷所有。 小結 在本章，我們從 文本分塊、實體／關係抽取、圖索引建構 到 社群檢測 與 查詢處理（Map-Reduce Summarization）做了完整且深入的說明。善用這些技術細節、策略與優化方法，能顯著提升 GraphRAG 在大規模文本分析上的效率與回答品質。 第二章：GraphRAG 與其他方法的比較 1. Naïve RAG 優點：直接性強、實作簡單； 缺點：對「全局、跨文件」問題較差，全面性欠缺。 2. 全文摘要（TS, Text Summarization） 優點：可整體概括所有內容； 缺點：每次都要處理整個文本，Token 耗費大；易導致重複或過度摘要。 3. GraphRAG 優勢： 結合圖結構＋社群檢測，可以在大規模文本上做系統化切分； 透過多層級摘要確保兼顧細節與效率。 挑戰： 圖構建的品質依賴 LLM 抽取效果； 需解決重複實體、幻覺等技術問題。 第三章：實驗與評估 評估指標 Comprehensiveness：答案的覆蓋度 Diversity：是否包含多重面向 Empowerment：是否能幫助使用者更好地理解並判斷 Directness：答案是否直接且切題 常見數據集範例 Podcast transcripts（約百萬 tokens） News articles（約百萬～數百萬 tokens，涵蓋多領域） 比較結果概述 GraphRAG 在「全面性、多樣性」上明顯優於 Naïve RAG； 與全文摘要相比，在效率與可擴充性上也有更佳表現。 第四章：GraphRAG 演算法詳細說明 1. 為何需要子圖（Subgraph）？ 在 GraphRAG 的實作中，我們已建立「整體知識圖（Graph Index）」並進行了社群檢測。但當用戶提出複雜或具體問題時（例如「X 企業與 Y 企業的競合關係？」），將整個知識圖直接丟給 LLM 既不現實，也容易引起 Token 限制與無關資訊干擾。因此，需要對知識圖做子圖提取（Subgraph Extraction），只取與查詢最相關的那一小部分，能更有效率且生成更精準的答案。 2. 如何提取 Subgraph？ 子圖提取的核心在於「從大圖中篩選出與查詢相關的節點、屬性與邊」，確保查詢上下文足夠而不冗餘。 A. 主要步驟 文本拆分與知識圖構建 透過前幾章所述的步驟（分塊、實體／關係抽取、社群檢測）得到整體知識圖 每個節點皆能連結相應屬性（如描述、時間、引用片段）與邊（如投資、合作、競爭） 查詢與圖的匹配 可利用關鍵詞或語義嵌入（Embedding）先篩選出最相關的節點 以該節點為「起點」，擴張一兩層邊，萃取和查詢強相關的領域 社群檢測結合 若已經有階層化社群（C0, C1, C2, C3），可直接鎖定對應社群並將整個社群當作子圖 或先用語義匹配找到「候選社群」，再擴散到其相鄰社群 過濾與精修 對子圖中出現的低頻節點、多餘關係進行過濾 合併重複實體，並確認邊的方向與描述是否完整 B. 混合式子圖提取：社群 + 語義檢索 社群檢測 先以 Leiden 演算法取得一批主題社群 使用「查詢 → 社群摘要」比對語義相似度，選出前幾名最吻合社群 子圖擴張 針對該社群內最相關的節點擴張 1～2 層，取得完整關係 形成子圖 將此社群內節點、關係與屬性整合成一個局部知識圖供 LLM 查詢 3. 挑選出合適的子圖 即使能提取子圖，仍需要判斷「哪一部分」最能回答特定問題。這牽涉到社群分層、語義匹配與圖結構的綜合考量。 A. 社群檢測角度 高層級社群（C0, C1） 適合：宏觀、大範圍問題（如「整個新聞語料中最常討論的主題是什麼？」） 好處：節點少、摘要短 限制：細節不足 中層或低層社群（C2, C3） 適合：需要深入了解特定子領域或事件（如「GPT-4 與 Gemini 在訓練方法上有哪些差異？」） 好處：可保留更多細節 限制：Token 使用量大 B. 語義匹配角度 直接匹配查詢關鍵詞 計算節點名稱、描述、屬性與查詢的相似度 快速過濾絕大部分不相關節點 擴展搜索 若查詢為「X 與 Y 在 AI 領域的合作」，可優先匹配「AI」、「X」、「Y」，並找出它們之間的邊 若圖結構顯示 X 與 Y 間同時連到 Z，則擴展到 Z 形成更完整上下文 C. 綜合策略 先用 語義檢索 找到與查詢最相似的社群 依需求深度決定用 C1（較抽象）還是 C2/C3（更細緻） 針對該社群或該節點做 1～2 層邊的擴張，最終形成合適的子圖 關鍵思維：避免「子圖過小導致資訊不足」與「子圖過大導致 Token 浪費與噪音」。 4. 取出子圖後，如何轉變成 LLM 提示字？ 獲得子圖（包含節點、屬性與邊）後，仍需轉換成 LLM 可理解並給出適當回答的Prompt。這關鍵步驟包括： A. 選擇合適的表示格式 自然語言描述 用一般文字敘述子圖內容，如「OpenAI 與 Microsoft 之間的合作關係…」 優點：易於大多數 LLM 理解 缺點：若子圖龐大，可能造成 Token 過度消耗 JSON（結構化格式） { "Entities": [ {"Name": "OpenAI", "Type": "Company"}, {"Name": "GPT-4", "Type": "AI Model"} ], "Relations": [ {"Source": "OpenAI", "Relation": "開發", "Target": "GPT-4"} ] } 優點：LLM 工具介面或 Function Calling 容易解析 缺點：需要 LLM 具備良好的 JSON 處理能力 三元組（Triples） (OpenAI, "開發", GPT-4) (Google, "開發", Gemini) (OpenAI, "競爭", Google) 優點：精簡且適合圖邏輯推理 缺點：有時需要更多敘事描述，LLM 才能產生流暢文本 B. Prompt 設計與上下文控制 上下文控制 明確向 LLM 說明：「以下是一個子圖資訊，請基於此回答問題…」 若子圖資訊量大，可依 Token 限制拆分成多段進行Map-Reduce Summarization 保留關鍵屬性 指明實體的核心屬性（如「發表年份: 2023」） 盡量避免過量細節淹沒關鍵資訊 對齊查詢需求 若查詢為比較兩家公司的合作與競爭，Prompt 中必須清晰標示它們之間的邊關係 5. 必須同時匹配 Entity、Attribute、Edge 的原因 在提取子圖與 Prompt 設計時，往往不只匹配節點（Entity），還需要同時匹配節點屬性（Attribute）與邊（Edge）： 確保查詢上下文的完整性 僅有節點名稱往往不夠，需要屬性（如時間、角色）與邊（關係敘述）來回答「誰做了什麼？何時？為何？」等 提供 LLM 足夠的語義線索 關係對於推斷因果、比較及歸納性問題尤其重要 6. 綜合範例：子圖提取與 Prompt 轉換 假設查詢為：「2023 年有哪些科技公司發布 AI 模型？它們在新聞裡被如何比較？」 語義檢索： 找到與「AI 模型」「2023」「科技公司」相關度高的社群（如 C2） 提取子圖： 在該社群中匹配「OpenAI, GPT-4, Microsoft, Google, Gemini」，萃取它們互相的關係 過濾、合併： 可能合併「Microsoft」和「MS」，移除不相關節點 轉成 Prompt（JSON 格式範例）： { "Entities": [ {"Name": "OpenAI", "Type": "Company"}, {"Name": "GPT-4", "Type": "AI Model", "Released": 2023}, {"Name": "Google", "Type": "Company"}, {"Name": "Gemini", "Type": "AI Model", "Released": 2023} ], "Relations": [ {"Source": "OpenAI", "Relation": "開發", "Target": "GPT-4"}, {"Source": "Google", "Relation": "開發", "Target": "Gemini"}, {"Source": "OpenAI", "Relation": "競爭", "Target": "Google"} ] } LLM 回答： 針對該 JSON Prompt，LLM 得以生成對比敘述：哪幾家於 2023 年發布模型，模型差異何在，市場反響如何等 7. 常見問題（FAQ） Q：只抽取最相似的節點而忽略邊會怎樣？A：容易失去上下文與關聯線索，LLM 無法理解實體之間關係，導致回答不完整或錯誤。 Q：社群劃分顆粒度如何拿捏？A：可先用高層（C1）回答宏觀問題，若使用者需更深層細節，再下鑽到 C2/C3。 Q：子圖中重複實體太多，怎麼處理？A：可使用相似度方法合併重複實體，或透過命名標準（Normalize）精準比對。 Q：Prompt 是否越長越好？A：不盡然。過度冗長會消耗 Token、分散注意力；需在「訊息完整度」與「語料大小」之間取得平衡。 8. 小結與建議 子圖提取是 GraphRAG 中將「大型知識圖」轉化為「與查詢緊密相關子集」的關鍵。 挑選合適子圖需要考慮社群層次、語義檢索結果，以及查詢本身所需的細節深度。 轉換成 LLM 提示字時，可選「自然語言」「JSON」「三元組」等格式，並控制上下文長度與重點屬性。 同時匹配 Entity、Attribute、Edge才能讓 LLM 充分理解子圖的意涵，回答複雜問題時尤其必要。 第五章：未來發展與研究方向 與對話式系統結合 支援多輪對話，動態選取或下鑽（Drill-down）至更細社群。 Causal/Temporal Reasoning 在知識圖上增加因果關係或時間序列分析，回答「為什麼」「何時」類問題。 跨模態擴充 支援影像、音訊等多模態資料，建立圖索引時同時整合文字與視覺資訊。 事實驗證（Fact-checking） 引入引用與佐證機制，防止 LLM 幻覺影響回答正確性。 第六章：總結 GraphRAG 的核心價值：透過「知識圖索引 + 社群檢測 + Map-Reduce Summarization」機制，有效解決 RAG 在「全局性查詢」上的不足。 主要貢獻： 階層式社群摘要：可依查詢需求選擇適當粒度； Map-Reduce：兼顧回答的廣度與深度； 可拓展：可與現有語義搜索或圖演算法整合。 未來趨勢： 結合大模型與知識圖譜的應用正迅速發展，GraphRAG 是一條新興路徑，有潛力應用於智慧企業、媒體分析、科學研究等多方領域。 參考文獻與延伸讀物 From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Preprint, 2024) Lewis et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks Traag et al. (2019). From Louvain to Leiden: guaranteeing well-connected communities Fortunato (2010). Community detection in graphs: A survey Ram et al. (2023). In-Context Retrieval-Augmented Language Models

  • 8. GraphRAG 實戰演練

    使用 LangChain + Neo4j 實現 GraphRAG 使用 Microsoft GraphRAG 實現 GraphRAG