我對純向量 RAG 的看法錯了——GraphRAG 讓我的準確率翻了 3.4 倍¶
文章資訊
作者：Aniruddha Kawarase 日期：2026-06-13
原文標題：I Was Wrong About Vector-Only RAG. GraphRAG Just 3.4x’d My Accuracy.
📝 重點摘要¶
TL;DR¶
在相同語料、模型與提示下，混合式 GraphRAG 把多跳查詢準確率從 16.7% 拉到 56.2%。
核心問題¶
純向量 RAG 把每個 chunk 視為獨立語意單位，能處理單跳事實查詢，卻無法捕捉 chunk 之間的關係。面對多跳、多實體、重 schema 的查詢（如合約條款追蹤、跨工單關聯），向量檢索常漏掉第二跳而導致答案錯誤。作者想證明：瓶頸不在模型，而在檢索層。
關鍵發現 / 數據¶
- 同語料整體準確率從向量法 65% 提升至混合 GraphRAG 86.9%（+22 分）。
- 多跳子集：LLM 無 KG 接地 16.7% vs 有 KG 接地 56.2%（3.4 倍）。
- 各法多跳表現：向量 41.2%、向量+BM25 47.5%、微軟 GraphRAG 78.8%、作者混合棧 81.3%。
- 微軟 GraphRAG 在單跳反而輸給純向量（86.2% vs 88.5%），因社群摘要平滑掉具體事實。
- 索引成本：純向量 $4.1、微軟 GraphRAG $87（Opus）、作者混合 $38（Sonnet）；50K 查詢/月總帳單僅多 $90。
方法亮點¶
- 三路並行檢索（向量 k=12、BM25 k=12、圖 2-hop 遍歷），由 cross-encoder reranker 融合，圖串流貢獻約 25% 最終 chunk。
- 用 Sonnet 4.6 做實體抽取（實體召回僅低 Opus 2%、便宜 30%），存入 Neo4j。
- 限制 2-hop 遍歷涵蓋約 85% 多跳查詢；Cypher 生成需 5–10 個範例，成功率從 50–60% 升至 91%。
- 用 Haiku 查詢分類器（80ms）路由，讓單跳查詢繞過圖，成本才划算。
對我的研究有用嗎？¶
混合式「路由 + 三路融合」架構值得參考：與其二選一，不如依查詢類型選檢索器，並用 reranker 統一融合。多跳 vs 單跳的取捨、2-hop 噪訊權衡、schema drift 監控、Cypher few-shot 接地等都是 GraphRAG 落地的實務洞見，benchmark 拆分（單跳/多跳/schema-heavy）也適合借鏡評估設計。
評語¶
工程實務經驗紮實、成本拆解誠實，值得一讀；但數據出自單一客戶語料與合成 eval，16.7→56.2% 引自微軟論文而非自測，需謹慎對待外推性。
🌐 中英對照¶
Author: Aniruddha Kawarase Published: Source: https://medium.com/@anupkawarase.akz/i-was-wrong-about-vector-only-rag-graphrag-just-3-4xd-my-accuracy-f58a7c7c1eab Fetched: 2026-06-13T00:15:26.436768
I Was Wrong About Vector-Only RAG. GraphRAG Just 3.4x'd My Accuracy. / 我對「純向量 RAG」的看法錯了。GraphRAG 讓我的準確率提升了 3.4 倍。¶
From 16.7% to 56.2% on the same corpus, the same model, the same prompts. The shift was the retrieval layer — and the cost story isn't what most blogs claim.
在相同的語料庫 (corpus)、相同的模型、相同的提示詞 (prompts) 條件下，準確率從 16.7% 提升到 56.2%。改變的是檢索層 (retrieval layer)，而其中的成本問題也跟大多數部落格所宣稱的不一樣。
GraphRAG vs Vector RAG Accuracy Showdown:
GraphRAG 與向量 RAG 的準確率對決：
Press enter or click to view image in full size
按 Enter 或點擊以全螢幕檢視圖片
In April 2025, I told a client he didn't need a knowledge graph. He had a 12,000-document corpus, well-chunked, with a tuned hybrid retriever (BM25 + dense vectors + a cross-encoder reranker). Recall@10 was 0.82. End-to-end answer accuracy on his eval set was 67%. "GraphRAG is heavyweight," I said. "You'd pay 10x indexing cost for 5% accuracy."
在 2025 年 4 月，我告訴一位客戶他不需要知識圖譜 (Knowledge Graph)。他有一個包含 12,000 份文件的語料庫，切塊 (chunk) 處理得很好，並搭配了一個調校過的混合檢索器 (hybrid retriever)（BM25 + 密集向量 (dense vectors) + 交叉編碼器重排序器 (cross-encoder reranker)）。Recall@10 是 0.82。在他的評估集 (eval set) 上，端到端 (end-to-end) 答案準確率為 67%。「GraphRAG 太笨重了，」我說，「你會付出 10 倍的索引 (indexing) 成本，卻只換來 5% 的準確率。」
I was right about the indexing cost. I was wrong about the accuracy ceiling.
我對索引成本的判斷是對的，但我對準確率上限的判斷錯了。
Twelve months later, I ran the same corpus through Microsoft GraphRAG's entity-extraction + community-summarization pipeline. Same model. Same prompts. Same eval set. End-to-end answer accuracy went from 67% to 89%. On the multi-hop subset specifically, an LLM-with-knowledge-graph grounding scored 56.2% — versus 16.7% for the LLM-only baseline. That's a 3.4x jump on the queries that matter most.
十二個月後，我將同一個語料庫放進 Microsoft GraphRAG 的實體抽取 (entity-extraction) + 社群摘要 (community-summarization) 流程中。相同的模型、相同的提示詞、相同的評估集。端到端答案準確率從 67% 提升到 89%。特別是在多跳 (multi-hop) 子集上，有知識圖譜接地 (grounding) 的大型語言模型 (LLM) 拿到 56.2% 的分數，而僅有 LLM 的基準線 (baseline) 只有 16.7%。這是在最關鍵的查詢上達到了 3.4 倍的躍升。
This post is the data, the architecture, and the honest tradeoff math. If you're running vector-only RAG today and your accuracy plateaus around 65–75%, this is what's on the other side.
這篇文章會呈現數據、架構，以及誠實的取捨 (tradeoff) 計算。如果你今天正在運行純向量 RAG，而準確率停滯在 65–75% 左右，那麼這就是另一邊的風景。
What I Got Wrong — The Vector RAG Plateau
我錯在哪裡——向量 RAG 的瓶頸
Press enter or click to view image in full size
按 Enter 或點擊以全螢幕檢視圖片
The vector-RAG worldview goes like this: chunks are independent units of meaning, retrieval finds the relevant chunks, the LLM does the synthesis. This is true for **single-hop, fact-lookup queries**. It is false for **multi-hop, multi-entity, schema-heavy queries**.
向量 RAG 的世界觀是這樣的：每個切塊 (chunk) 都是獨立的意義單元，檢索負責找出相關的切塊，LLM 負責做綜合整理。對於單跳 (single-hop)、事實查找 (fact-lookup) 類查詢而言，這是成立的；但對於多跳 (multi-hop)、多實體 (multi-entity)、重結構 (schema-heavy) 類查詢而言，這就不成立了。
What does multi-hop look like in production?
在實際生產環境中，多跳查詢長什麼樣子？
-
"Which customers had three or more support tickets across the last quarter where the resolution involved Team X, and what was the average resolution time delta vs Team Y?"
-
「過去一季中，哪些客戶有三張以上、且解決過程涉及 X 團隊的客服工單，並且其平均解決時間相對於 Y 團隊的差值是多少？」
-
"Which contracts have an indemnification clause modified after the 2024 amendment, signed by the same VP, in jurisdictions with arbitration carve-outs?"
-
「哪些合約的賠償條款 (indemnification clause) 在 2024 年修訂後被改動過、由同一位副總裁簽署，且位於設有仲裁排除條款 (arbitration carve-outs) 的司法管轄區？」
-
"Trace every change to the FAISS index initialization in our codebase across the last three releases, and identify the engineer responsible."
-
「追蹤我們程式碼庫中 FAISS 索引初始化在過去三個版本中的每一次變更，並找出負責的工程師。」
Vector RAG handles each chunk in isolation. The relationship between chunks — who signed what, which function calls which, which ticket relates to which engineer — disappears in embedding space. The model can only reason over what comes back. If the retrieval misses the second hop, the answer is wrong.
向量 RAG 是孤立地處理每一個切塊。切塊之間的關係——誰簽了什麼、哪個函式呼叫哪個函式、哪張工單關聯到哪位工程師——在嵌入空間 (embedding space) 中消失了。模型只能就檢索回傳的內容進行推理。如果檢索漏掉了第二跳，答案就會是錯的。
The Microsoft GraphRAG paper put a number on this gap that I dismissed at the time: an LLM without knowledge-graph grounding scored 16.7% accuracy on a multi-entity reasoning benchmark. The same LLM with KG grounding scored 56.2%. The 3.4x improvement isn't from a better model. It's from giving the model a retrievable structure of relationships, not just bags of text.
Microsoft GraphRAG 的論文為這個差距給出了一個數字，而我當時對它不以為然：一個沒有知識圖譜接地的 LLM 在多實體推理基準測試 (benchmark) 上得到 16.7% 的準確率；而同一個 LLM 加上知識圖譜 (KG) 接地後得到 56.2%。這 3.4 倍的提升並非來自更好的模型，而是來自給模型一個可檢索的關係結構，而不只是一堆文字。
I dismissed it because I was solving simpler problems. By April 2026, my clients were not.
我之所以不以為然，是因為我當時在解決比較簡單的問題。但到了 2026 年 4 月，我的客戶面對的已經不是簡單問題了。
The Architecture — GraphRAG Hybrid Stack
架構——GraphRAG 混合技術棧 (Hybrid Stack)
Press enter or click to view image in full size
按 Enter 或點擊以全螢幕檢視圖片
Here is the production stack I now use for any corpus where multi-hop reasoning is on the eval set. It is **not** Microsoft GraphRAG vanilla — that runs ~$50–200 per corpus to index, which is real money on a large doc set. It is a hybrid that takes the GraphRAG idea and bolts it onto a vector-first foundation.
以下是我現在針對任何評估集中包含多跳推理的語料庫所使用的生產技術棧。它並不是原版 (vanilla) 的 Microsoft GraphRAG——原版每個語料庫的索引成本約為 50–200 美元，對於大型文件集而言這是一筆實在的開銷。它是一個混合方案，把 GraphRAG 的理念嫁接到一個以向量為先 (vector-first) 的基礎之上。
┌────────────────────────────────────────────────────────┐
│ INGESTION │
│ ├─ Document parser (Unstructured / Docling) │
│ ├─ Chunker (semantic, 800-token windows) │
│ ├─ Vector embedder (text-embedding-3-large) │
│ └─ Entity + relation extractor (Sonnet 4.6) │
│ → entities, relations, claims into Neo4j │
└────────────────────────────────────────────────────────┘
│
┌────────────────────────────────────────────────────────┐
│ RETRIEVAL (parallel) │
│ ├─ Vector top-k (k=12) │
│ ├─ BM25 top-k (k=12) │
│ └─ Graph 2-hop traversal from query entities │
│ → reranker fuses all three streams │
└────────────────────────────────────────────────────────┘
│
┌────────────────────────────────────────────────────────┐
│ GENERATION │
│ ├─ Top-12 fused chunks │
│ ├─ Subgraph in JSON (entities + relations) │
│ └─ Claude Opus 4.7 with cached subgraph │
└────────────────────────────────────────────────────────┘
Key design choices and why:
關鍵的設計選擇與原因：
**1. Entity extraction with Sonnet, not GPT-4.** I switched to Sonnet 4.6 for the extraction step in February. Output quality is within 2% of Opus on entity recall and 30% cheaper. Indexing a 12K-document corpus costs $34 with Sonnet vs $87 with Opus. For nightly re-indexing, that math matters.
1. 用 Sonnet 做實體抽取，而非 GPT-4。 我在二月把抽取步驟切換到 Sonnet 4.6。它在實體召回 (entity recall) 上的輸出品質與 Opus 相差不到 2%，但便宜 30%。索引一個 12K 文件的語料庫，用 Sonnet 花費 34 美元，而用 Opus 要 87 美元。對於每晚重新索引 (re-indexing) 而言，這筆帳很重要。
**2. Neo4j, not LanceDB or in-memory graph.** I tested LanceDB's graph features and FalkorDB. Neo4j wins on Cypher expressiveness, which is what the LLM-in-the-loop graph query generation needs. A model generating Cypher against an unfamiliar schema fails 60% of the time. Against Neo4j with a clean schema and example queries in the prompt, it succeeds 91% of the time.
2. 用 Neo4j，而非 LanceDB 或記憶體內 (in-memory) 圖。 我測試過 LanceDB 的圖功能以及 FalkorDB。Neo4j 在 Cypher 的表達能力上勝出，而這正是「LLM 參與迴圈 (LLM-in-the-loop)」的圖查詢生成所需要的。一個模型在面對不熟悉的結構 (schema) 時，生成 Cypher 有 60% 的機率會失敗；而面對結構乾淨、且提示詞中附帶範例查詢的 Neo4j，它有 91% 的成功率。
**3. Two-hop traversal limit.** Three hops blows up combinatorially and introduces noise. Two hops covers ~85% of multi-hop queries I see in client corpora. The remaining 15% I let the model decide with a structured tool call back to the graph.
3. 兩跳遍歷 (traversal) 上限。 三跳會在組合上爆炸增長並引入雜訊。兩跳就涵蓋了我在客戶語料庫中看到的約 85% 的多跳查詢。剩下的 15%，我會讓模型透過一次回到圖的結構化工具呼叫 (structured tool call) 來決定。
**4. Reranker fuses all three streams.** Cross-encoder reranker (bge-reranker-v2-m3) takes the top-12 from each stream — vector, BM25, graph — and produces a final top-12 fused. The graph stream contributes ~25% of the final chunks on average. Without it, multi-hop accuracy stays at the vector-only plateau.
4. 重排序器融合所有三條資料流。 交叉編碼器重排序器（bge-reranker-v2-m3）從每條資料流——向量、BM25、圖——各取前 12 名，產生最終融合後的前 12 名。圖這條資料流平均貢獻了最終切塊的約 25%。少了它，多跳準確率就會停留在純向量的瓶頸上。
Benchmarks — Vector vs GraphRAG vs Hybrid
基準測試——向量 vs GraphRAG vs 混合方案
Press enter or click to view image in full size
按 Enter 或點擊以全螢幕檢視圖片
Here's the head-to-head on the client corpus I mentioned. 12,000 documents, mixed contracts and support logs. Eval set: 240 questions hand-labeled by a domain expert, split into single-hop (130), multi-hop (80), and schema-heavy (30).
以下是我先前提到的那個客戶語料庫上的正面對決。12,000 份文件，混合了合約與客服紀錄。評估集：240 個由領域專家手動標註的問題，分為單跳（130 題）、多跳（80 題）與重結構（30 題）。
| Retrieval Stack | Single-hop | Multi-hop | Schema-heavy | Overall |
|----------------|------------|-----------|--------------|---------|
| Vector-only (BGE-large, k=10) | 88.5% | 41.2% | 26.7% | 65.0% |
| Hybrid (Vector + BM25 + rerank) | 91.5% | 47.5% | 30.0% | 67.4% |
| Microsoft GraphRAG (vanilla) | 86.2% | 78.8% | 70.0% | 79.6% |
| **My hybrid GraphRAG stack** | **92.3%** | **81.3%** | **76.7%** | **86.9%** |
Three observations:
三點觀察：
-
**Vector-only and hybrid vector+BM25 are nearly tied on multi-hop.** This is the trap. People add BM25 thinking it'll fix multi-hop. It doesn't. BM25 fixes keyword recall, not relationship reasoning.
-
純向量與「向量+BM25」混合方案在多跳上幾乎打成平手。 這就是陷阱。人們加上 BM25，以為它能解決多跳問題，但它並不能。BM25 解決的是關鍵字召回，而非關係推理。
-
**Microsoft GraphRAG vanilla loses to vector-only on single-hop.** Community summarization smooths out specific facts. This is a known weakness.
-
原版 Microsoft GraphRAG 在單跳上輸給純向量。 社群摘要會把具體事實平滑掉。這是一個已知的弱點。
-
**The hybrid stack wins on every category.** That's the whole argument for hybrid: don't pick a retriever, pick a router that uses the right retriever per query type.
-
混合技術棧在每一個類別上都勝出。 這正是支持混合方案的全部論點：不要去挑一個檢索器，而要挑一個路由器 (router)，讓它針對每種查詢類型使用正確的檢索器。
The Cost Story Most Blogs Get Wrong
大多數部落格搞錯的成本問題
The argument against GraphRAG is always cost. The cost story is more nuanced than "10x more expensive."
反對 GraphRAG 的論點永遠都是成本。但成本問題遠比「貴 10 倍」要細膩得多。
**Indexing cost (12K-document corpus):**
索引成本（12K 文件的語料庫）：
-
Vector-only: $4.10 (embedding only)
-
純向量：4.10 美元（僅嵌入）
-
Vanilla Microsoft GraphRAG: $87 (Opus extraction + community summaries)
-
原版 Microsoft GraphRAG：87 美元（Opus 抽取 + 社群摘要）
-
My hybrid stack: $38 (Sonnet extraction, no community summary layer)
-
我的混合技術棧：38 美元（Sonnet 抽取，沒有社群摘要層）
**Per-query cost (50K queries/month):**
每次查詢成本（每月 5 萬次查詢）：
-
Vector-only: $0.0023/query × 50K = $115/month
-
純向量：每次查詢 0.0023 美元 × 5 萬 = 每月 115 美元
-
My hybrid stack: $0.0029/query × 50K = $145/month
-
我的混合技術棧：每次查詢 0.0029 美元 × 5 萬 = 每月 145 美元
**Total monthly bill at scale:**
規模化後的每月總帳單：
-
Vector-only: $4.10 indexing + $115 retrieval + $? answering = roughly $1,200
-
純向量：4.10 美元索引 + 115 美元檢索 + ? 美元回答 = 大約 1,200 美元
-
My hybrid stack: $38 indexing + $145 retrieval + $? answering = roughly $1,290
-
我的混合技術棧：38 美元索引 + 145 美元檢索 + ? 美元回答 = 大約 1,290 美元
The delta is **$90/month** at 50K queries. For a 22-point overall accuracy lift on a workload where multi-hop and schema-heavy queries are 46% of traffic, that's the cheapest accuracy you'll ever buy.
在 5 萬次查詢下，差額是每月 90 美元。對於一個多跳與重結構查詢佔流量 46% 的工作負載而言，換來整體準確率提升 22 個百分點，這會是你買過最便宜的準確率。
The "GraphRAG is expensive" argument was true in 2024 when entity extraction ran on GPT-4 at $30/M tokens. At Sonnet 4.6 pricing ($3/M tokens), the entire argument collapses.
「GraphRAG 很貴」這個論點在 2024 年是成立的，那時實體抽取跑在每百萬 token 30 美元的 GPT-4 上。但在 Sonnet 4.6 的定價（每百萬 token 3 美元）之下，整個論點就站不住腳了。
Production — Three Things to Watch
生產環境——三件需要留意的事
Press enter or click to view image in full size
按 Enter 或點擊以全螢幕檢視圖片
**1. Schema drift will kill you slowly.** Your entity types and relation types need a schema. When new entity types creep in via extraction, the graph schema drifts. Old Cypher queries start returning nothing. I run a weekly job that diffs the entity-type distribution against last week and alerts if any type changes by more than 15% of volume.
1. 結構漂移 (Schema drift) 會慢慢拖垮你。 你的實體類型與關係類型需要一個結構 (schema)。當新的實體類型透過抽取悄悄混進來時，圖的結構就會漂移。舊的 Cypher 查詢開始什麼都回傳不了。我跑一個每週的工作排程，將實體類型分佈與上週做比對，若任何類型的數量變化超過 15% 就發出警報。
**2. Cypher generation needs a teaching prompt.** The LLM that writes Cypher queries against your graph needs 5–10 example queries with expected outputs in the system prompt. Without that, success rate drops to 50–60%. With it, 90%+.
2. Cypher 生成需要一段教學式提示詞。 負責針對你的圖撰寫 Cypher 查詢的 LLM，需要在系統提示詞 (system prompt) 中放入 5–10 個附帶預期輸出的範例查詢。沒有這些，成功率會掉到 50–60%；有了它們，成功率可達 90% 以上。
**3. Don't try to ground every query in the graph.** Single-fact lookups should bypass the graph entirely. Use a query classifier (Haiku, 80ms, $0.0001/query) to decide which retrievers fire. Half my queries skip the graph entirely. The math only works because of that.
3. 不要試圖讓每個查詢都接地到圖上。 單一事實查找應該完全繞過圖。使用一個查詢分類器（Haiku，80 毫秒，每次查詢 0.0001 美元）來決定要啟動哪些檢索器。我有一半的查詢完全跳過圖。正是因為這樣，那套成本帳才算得通。
The Honest Take
誠實的觀點
Press enter or click to view image in full size
按 Enter 或點擊以全螢幕檢視圖片
If your corpus is mostly independent documents and your queries are mostly single-hop lookups, vector-only RAG is still the right answer. Don't over-engineer.
如果你的語料庫大多是彼此獨立的文件，而你的查詢大多是單跳查找，那麼純向量 RAG 仍然是正確的答案。不要過度設計 (over-engineer)。
If your corpus has rich entity relationships — contracts, codebases, support histories, medical records, financial filings — and your eval set has multi-hop questions, you're leaving 20+ accuracy points on the table by sticking with vector-only. The cost premium in 2026 is small. The accuracy premium is large.
如果你的語料庫有豐富的實體關係——合約、程式碼庫、客服歷史、病歷、財務申報文件——而你的評估集中有多跳問題，那麼固守純向量就等於白白放棄了 20 個以上的準確率百分點。在 2026 年，多付的成本很小，而換來的準確率提升很大。
The companion repo includes the full hybrid stack — ingestion pipeline, Neo4j schema, retriever fusion, Cypher prompt templates, and the 240-question eval set I used (synthetic data, not the client corpus). Clone it, point it at a sample corpus, and you can have your own A/B in an afternoon.
配套的程式碼倉庫 (repo) 包含了完整的混合技術棧——攝取 (ingestion) 流程、Neo4j 結構、檢索器融合、Cypher 提示詞範本，以及我所使用的 240 題評估集（合成資料，並非客戶語料庫）。把它複製下來，指向一個範例語料庫，你就能在一個下午內完成屬於你自己的 A/B 測試。
I was wrong for a year. The wrongness cost zero deals because I was solving simpler problems. As the problems got harder, the math flipped. If you're in the same place I was in April 2025, this is your 12-month head start.
我錯了一年。這個錯誤沒有讓我損失任何一筆生意，因為我當時在解決比較簡單的問題。隨著問題變得更難，這套成本帳就翻轉了。如果你正處在我 2025 年 4 月時的同一個位置，那麼這就是你領先 12 個月的起跑優勢。
Repo: https://github.com/AniruddhaPKawarase/graphrag-hybrid-stack
程式碼倉庫：https://github.com/AniruddhaPKawarase/graphrag-hybrid-stack
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
Aniruddha Kawarase ships production AI systems for construction, healthcare, and ed-tech clients. He writes about what shipped, not what should ship. Follow for Mon/Wed/Fri engineering deep-dives. LinkedIn.
Aniruddha Kawarase 為營造、醫療與教育科技 (ed-tech) 領域的客戶交付生產級 AI 系統。他寫的是真正上線交付的東西，而非「應該」交付的東西。追蹤他，可在每週一/三/五讀到工程深度文章。LinkedIn。
🔤 關鍵術語¶
| 英文 | 繁中譯名 | 文章中的脈絡 / 簡短說明 |
|---|---|---|
| GraphRAG | 圖譜檢索增強生成 | 以知識圖譜的實體與關係結構作為檢索層，將多跳查詢準確率提升 3.4 倍 |
| Vector RAG | 向量檢索增強生成 | 將文件切塊嵌入向量空間檢索的傳統做法，單跳查詢有效但多跳會遇到準確率天花板 |
| Knowledge Graph (KG) | 知識圖譜 | 提供可檢索的實體關係結構，作為 LLM 的 grounding，使多跳推理從 16.7% 提升到 56.2% |
| Multi-hop query | 多跳查詢 | 需跨多個實體與關係推理的查詢，是 GraphRAG 相較向量 RAG 的最大優勢所在 |
| Single-hop query | 單跳查詢 | 單純事實查找，向量 RAG 已足夠；vanilla GraphRAG 在此類反而略遜 |
| Entity extraction | 實體抽取 | 索引階段用 Sonnet 4.6 從文件抽取實體、關係與 claims 寫入 Neo4j |
| Community summarization | 社群摘要 | Microsoft GraphRAG 的核心步驟，會平滑掉具體事實，導致單跳表現變差 |
| Entity traversal / 2-hop traversal | 實體遍歷 / 兩跳遍歷 | 從查詢實體出發在圖上做兩跳遍歷，涵蓋約 85% 多跳查詢，三跳則組合爆炸 |
| Vector embeddings | 向量嵌入 | 用 text-embedding-3-large 將語意切塊嵌入，但塊間關係在嵌入空間中消失 |
| Hybrid retriever | 混合檢索器 | 結合 BM25 + dense vectors + cross-encoder reranker 的調校檢索方案 |
| BM25 | BM25 關鍵詞檢索 | 修正關鍵詞召回，但無法解決關係推理，故對多跳幾乎無幫助 |
| Cross-encoder reranker | 交叉編碼器重排序器 | 以 bge-reranker-v2-m3 融合 vector、BM25、graph 三路結果並產生最終 top-12 |
| Recall@10 | 前十召回率 | 原向量檢索的召回指標達 0.82，但端到端準確率仍卡在 67% |
| Dense vectors | 稠密向量 | 混合檢索中與 BM25 並用的語意向量檢索成分 |
| Cypher | Cypher 查詢語言 | Neo4j 的圖查詢語言，LLM 在乾淨 schema 與範例提示下生成成功率達 91% |
| Neo4j | Neo4j 圖資料庫 | 因 Cypher 表達力勝出而被選為知識圖譜儲存，優於 LanceDB / FalkorDB |
| Schema drift | Schema 漂移 | 新實體類型混入導致圖 schema 偏移、舊 Cypher 查詢失效，需每週監控告警 |
| Query classifier | 查詢分類器 | 用 Haiku（80ms）判斷哪些檢索器啟動，讓單純查找略過圖譜以控制成本 |
| Semantic chunking | 語意切塊 | 以 800-token 視窗做語意切塊作為 ingestion 階段的一環 |
| Retriever fusion | 檢索器融合 | 將向量、BM25、圖三路檢索流融合，圖譜路平均貢獻約 25% 最終切塊 |