https://yennj12.js.org/yennj12_blog_V4/tags/graphrag/Recent content in GraphRAG on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 29 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part4-llm-graphrag-zh/Mon, 29 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part4-llm-graphrag-zh/大多數人遇到 RAG 答不準，第一反應是換更強的 embedding 模型。 正確答案是：多跳問題的瓶頸不在召回相似度，而在缺少「關係結構」。 大多數人以為知識圖譜和 LLM 是兩個世界。 正確答案是：LLM 負責語言理解，知識圖譜負責事實與推理，合起來才完整。 接續前文 Part 3 我們確立了「知識圖譜與向量庫互補」。這一篇把它落地到 LLM 系統：解釋 GraphRAG 為什麼出現、它如何運作、以及用 LangChain + Neo4j 寫出可跑的程式碼。 一、核心問題：純向量 RAG 在哪裡失敗？ 標準 RAG（Retrieval-Augmented Generation）流程是：把文件切塊（chunk）→ 算 embedding → 存向量庫 → 查詢時找最相似的塊 → 塞進 prompt。這對「事實型單跳問題」很有效，但有兩個致命弱點： 弱點一：多跳推理（multi-hop） 問題：「全面啟動的配樂家，還為哪位導演的哪部片配過樂？」 純向量 RAG 的困境： Query embedding ──▶ 找最相似的塊 │ ▼ 只會召回「提到全面啟動配樂」的段落 但「配樂家 → 其他作品 → 那部片的導演」這條關係鏈 分散在不同文件、不同塊裡，相似度檢索串不起來 ✗ 向量檢索本質是「單跳相似」。它無法沿著「實體 A → 關係 → 實體 B → 關係 → 實體 C」的鏈條走，因為這需要的是結構，不是相似度。https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part5-end-to-end-project-zh/Mon, 29 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part5-end-to-end-project-zh/大多數人學完知識圖譜，卡在「我的文件那麼多，難道要手動建圖？」 正確答案是：在 LLM 時代，抽取交給模型，你只需設計好流程與驗收。 大多數 demo 跑得起來，上線就垮。 正確答案是：把建圖、查詢、校驗拆成可演進的三個階段（POC → MVP → Scale）。 這是系列的最後一塊拼圖 前四篇我們學了概念（Part 1）、建構管線（Part 2）、技術比較（Part 3）、與 LLM 結合（Part 4）。這一篇把它們串成一個端到端、可實際執行的專案： 目標：丟進一批純文字文件 → LLM 自動抽成知識圖譜 → 存進 Neo4j → 用自然語言問答。 一、整體架構：四個階段 ┌─────────────┐ ┌──────────────┐ ┌─────────────┐ ┌──────────────┐ │ 1. 文件載入 │─▶│ 2. LLM 抽取 │─▶│ 3. 寫入 Neo4j │─▶│ 4. GraphRAG │ │ 切塊 │ │ 三元組 + 消歧 │ │ MERGE 去重 │ │ 自然語言問答 │ └─────────────┘ └──────────────┘ └─────────────┘ └──────────────┘ Part 2 Part 2+4 Part 2 Part 4 我們會用：Python、LangChain、langchain-experimental 的 LLMGraphTransformer（把文件直接轉成圖文件）、Neo4j。https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part5-production-zh/Wed, 20 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part5-production-zh/前言 你的 RAG 系統「感覺」不錯，但你能量化它有多好嗎？ 這是生產環境中最常見的盲區：工程師花大量時間優化 Chunking、調整 Reranker，卻沒有客觀的指標來驗證改動是否真的有效。 這篇是系列的最後一篇，涵蓋三個主題： RAG 評估（RAGAS）：如何量化 RAG 品質 GraphRAG：當向量搜尋不夠用時的替代方案 Agentic RAG：RAG + Agent，讓 AI 自己決定如何搜尋 Part 1：RAG 評估——RAGAS 框架 為什麼評估很難？ RAG 的輸出是自然語言，沒有標準答案可以直接比對。 「這個答案好不好」，需要從多個維度判斷。 RAGAS 的四個核心指標 RAGAS（RAG Assessment） 是目前最流行的 RAG 評估框架，定義了四個指標： 1. Faithfulness（忠實度） 答案是否只根據 context，沒有幻覺？ 計算方式： Step 1: 把答案分解成一組陳述句（claims） Step 2: 對每個陳述，判斷 context 是否支持它 Step 3: Faithfulness = 有 context 支持的陳述數 / 總陳述數 理想值：接近 1.0 2. Answer Relevancy（答案相關性） 答案是否真的回答了問題？ 計算方式： Step 1: 讓 LLM 根據答案生成 N 個「可能的問題」 Step 2: 計算這些問題與原始問題的向量相似度 Step 3: Answer Relevancy = 平均相似度 理想值：接近 1.