跳轉到

診斷 GraphRAG 錯誤：抽取 vs 檢索 vs 生成

文章資訊

作者：QuarkAndCode　　日期：2026-06-12

原文標題：Diagnosing GraphRAG Errors: Extraction vs Retrieval vs Generation

Medium 原連結：https://medium.com/@QuarkAndCode/diagnosing-graphrag-errors-extraction-vs-retrieval-vs-generation-fbd57b271c74

🎧 摘要語音

📝 重點摘要

TL;DR

把 GraphRAG 的失敗拆成抽取、檢索、生成三層分別診斷，才能對症下藥。

核心問題

GraphRAG 答錯時，「模型幻覺了」這種說法太模糊、無助於修復。文章主張應將失敗明確歸類為三個階段的錯誤——建圖時的抽取錯誤、查詢時的檢索錯誤、生成答案時的生成錯誤，並逐層檢查而非只看最終答案。

關鍵發現 / 數據

  • GraphRAG 並非永遠較佳：標準 RAG 在單跳、細節密集的查找題更強，GraphRAG 在多跳推理與跨資料整合、高層摘要題更勝。
  • 研究發現社群型 GraphRAG 在需要細節答案時，local 模式常優於 global 模式。
  • Global search 的靜態階層選取會浪費 token 在無關社群報告上，擠掉真正關鍵的證據（故有 dynamic community selection 改良）。
  • 開啟 allow_general_knowledge 雖偶有幫助，卻會增加幻覺。
  • 部分 LLM 摘要評測存在明顯的 position bias，低分不必然代表生成器有問題。

方法亮點

  • 三層歸因框架，對應 GraphRAG-Bench 對建圖／檢索／生成的分別評估。
  • 診斷流程：先查索引（text_units、entities、relationships、community_reports）→ 同題比較 local/global/DRIFT/basic 四種檢索模式 → 檢視檢索到的證據而非只看答案。
  • 修復對策分層：抽取錯誤調 prompt tuning／chunking／建圖；檢索錯誤換搜尋模式或階層；生成錯誤靠 claim 抽取與來源追溯（Claimify、VeriTrail）。

對我的研究有用嗎？

對 GraphRAG 研究者頗有參考價值：三層歸因與「檢視中間產物而非最終答案」的除錯思路，可直接用於 pipeline 評估設計。local vs global、dynamic community selection、position bias 等觀察都指向具體的檢索與評測改進方向，VeriTrail 的可追溯性概念也值得借鏡。

評語

偏實務的綜述型文章，無原創實驗，但框架清晰、引用紮實（含 Microsoft 官方文件與多篇 benchmark），值得快速一讀建立除錯心智模型。

🌐 中英對照

Author: QuarkAndCode 作者：QuarkAndCode Published: 發布日期： Source: https://medium.com/@QuarkAndCode/diagnosing-graphrag-errors-extraction-vs-retrieval-vs-generation-fbd57b271c74 來源：https://medium.com/@QuarkAndCode/diagnosing-graphrag-errors-extraction-vs-retrieval-vs-generation-fbd57b271c74 Fetched: 2026-06-12T23:54:07.954849 擷取時間：2026-06-12T23:54:07.954849

Diagnosing GraphRAG Errors: Extraction vs Retrieval vs Generation / 診斷 GraphRAG 錯誤：抽取 vs 檢索 vs 生成

Press enter or click to view image in full size

按 Enter 或點擊以檢視全尺寸圖片

GraphRAG stands out because it does more than just pull nearby text. Microsoft’s original GraphRAG system builds an entity-focused graph from documents, creates summaries for groups of related content, and uses different search methods — local, global, or DRIFT — to answer questions.

GraphRAG 之所以突出，是因為它不只是擷取鄰近的文字而已。微軟最初的 GraphRAG 系統會從文件中建立以實體為核心的圖譜 (entity-focused graph)，為相關內容的群組建立摘要，並使用不同的搜尋方法——區域 (local)、全域 (global) 或 DRIFT——來回答問題。

This approach can outperform basic vector RAG on tough tasks, like broad questions about an entire collection or multi-step reasoning. However, later studies show GraphRAG is not always better: standard RAG often works best for simple lookups or detail-heavy questions, while GraphRAG excels when you need to connect scattered information or create broader summaries.

這種方法在困難任務上可以勝過基本的向量 RAG (vector RAG)，例如針對整個文件集合的廣泛問題，或是多步驟推理。然而，後續研究顯示 GraphRAG 並非總是比較好：標準 RAG 在簡單查詢或細節密集的問題上往往表現最佳，而 GraphRAG 則在需要連結零散資訊或建立更宏觀摘要時表現出色。

This is why it’s important to figure out why GraphRAG gives a bad answer. Saying “the model hallucinated” is usually too vague to help. It’s more useful to break failures into three types: extraction errors during graph construction, retrieval errors at query time when selecting evidence, and generation errors during answer generation. This matches how GraphRAG research describes the process: indexing with graphs, retrieving with graph guidance, and generating answers using the graph. GraphRAG-Bench also evaluates these steps separately, instead of treating the final answer as a mystery.

這就是為什麼弄清楚 GraphRAG 為何給出糟糕答案如此重要。光說「模型產生了幻覺 (hallucinated)」通常太過模糊，沒有幫助。將失敗拆解為三種類型會更有用：圖譜建構期間的抽取錯誤 (extraction errors)、查詢時挑選證據階段的檢索錯誤 (retrieval errors)，以及答案生成期間的生成錯誤 (generation errors)。這與 GraphRAG 研究描述其流程的方式一致：用圖譜進行索引、在圖譜引導下進行檢索、並利用圖譜生成答案。GraphRAG-Bench 也會分別評估這些步驟，而不是把最終答案當成一個謎團。

What GraphRAG is Doing Before It Answers / GraphRAG 在回答之前在做什麼

In a typical GraphRAG setup, documents are broken into smaller text units. The system pulls out entities, relationships, and sometimes claims from these units, then summarizes what each entity and relationship is about. It also identifies groups of related items in the graph and generates reports that summarize each group’s content. When you ask a question, GraphRAG can use local search for questions about specific entities, global search for questions about the whole collection, DRIFT search for wider local exploration, or a basic vector-RAG method for comparison.

在典型的 GraphRAG 設置中，文件會被拆解成較小的文字單元 (text units)。系統會從這些單元中抽取出實體 (entities)、關係 (relationships)，有時還有主張 (claims)，然後摘要每個實體與關係的內容。它也會辨識圖譜中相關項目所組成的群組，並產生摘要每個群組內容的報告。當你提問時，GraphRAG 可以對特定實體的問題使用區域搜尋 (local search)、對整個集合的問題使用全域搜尋 (global search)、對更廣泛的區域探索使用 DRIFT 搜尋 (DRIFT search)，或使用基本的 vector-RAG 方法來作對照。

This setup helps GraphRAG seem much smarter than basic RAG when you ask the right kind of question. But it also means there are more ways for things to go wrong. If the system misses an entity, the graph can be flawed. Even a good graph can be searched the wrong way. And sometimes, even with good retrieval, the answer generator might give an incomplete, overconfident, or unsupported response.

這種設置讓 GraphRAG 在你提出對的那類問題時，顯得比基本 RAG 聰明許多。但這也意味著出錯的方式變得更多。如果系統漏掉了某個實體，圖譜就可能有缺陷。即使是一個好的圖譜，也可能用錯誤的方式去搜尋。而且有時候，即便檢索良好，答案生成器仍可能給出不完整、過度自信，或缺乏佐證的回應。

Extraction Errors: When The Graph Is Wrong Before Retrieval Even Starts / 抽取錯誤：在檢索開始之前圖譜就已經錯了

An extraction error happens when the system creates the wrong internal version of the source material. In GraphRAG, this usually occurs during text-unit analysis, entity and relationship extraction, description summarization, or community reporting. Since community reports are based on these descriptions, an early mistake can spread to higher-level summaries and affect later answers.

當系統為來源材料建立了錯誤的內部表徵時，就會發生抽取錯誤 (extraction error)。在 GraphRAG 中，這通常發生在文字單元分析、實體與關係抽取、描述摘要，或社群報告 (community reporting) 階段。由於社群報告是建立在這些描述之上的，早期的一個錯誤可能會擴散到更高層的摘要，並影響後續的答案。

In real use, extraction errors might seem minor at first but cause big problems later. For example, the system might miss a key term, merge two different entities, or list the same entity under several names. Sometimes a relationship is found but described too vaguely to aid retrieval. A community report might focus on the wrong topic because the graph was messy. In these cases, the query engine isn’t just missing the answer — the answer was never represented correctly to begin with.

在實際使用中，抽取錯誤一開始可能看起來無關緊要，卻會在之後造成大麻煩。例如，系統可能漏掉一個關鍵詞、把兩個不同的實體合併，或把同一個實體用好幾個名稱列出。有時找到了一個關係，卻描述得太模糊而無助於檢索。社群報告可能因為圖譜雜亂而聚焦在錯誤的主題上。在這些情況下，查詢引擎不只是漏掉了答案——而是答案從一開始就從未被正確表徵出來。

One sign of an extraction problem is when every search mode — local, global, and DRIFT — misses the same important idea, or when the entities and relationships tables look strange. This usually means the issue started earlier in the process. GraphRAG lets you see outputs like text_units, entities, relationships, and community_reports, so you can check what’s actually in the index instead of guessing from the final answer.

抽取問題的一個徵兆是：當每一種搜尋模式——區域、全域與 DRIFT——都漏掉了同一個重要概念，或當實體與關係的資料表看起來很奇怪時。這通常代表問題在流程更早的階段就出現了。GraphRAG 讓你能查看像 text_units、entities、relationships 與 community_reports 等輸出，因此你可以檢查索引中實際有什麼，而不是從最終答案去猜測。

To fix extraction errors, you usually need a better indexing setup, not just a better answer prompt. Microsoft’s GraphRAG docs suggest tuning prompts for your specific domain, since generic prompts don’t always work well for specialized content. The auto-tuning process helps create prompts that fit your data. How you split text into chunks also matters, since extraction works at the text-unit level. If you use FastGraphRAG, the types of errors can change again, because it uses NLP noun-phrase extraction and co-occurrence edges instead of some LLM-based reasoning.

要修正抽取錯誤，你通常需要一個更好的索引設置，而不只是一個更好的答案提示詞 (prompt)。微軟的 GraphRAG 文件建議針對你的特定領域調校提示詞，因為通用的提示詞並不總是能在專業內容上運作良好。自動調校 (auto-tuning) 流程有助於建立符合你資料的提示詞。你如何把文字切分成區塊 (chunks) 也很重要，因為抽取是在文字單元層級進行的。如果你使用 FastGraphRAG，錯誤的類型可能又會改變，因為它使用的是 NLP 名詞片語抽取 (noun-phrase extraction) 與共現邊 (co-occurrence edges)，而非某些基於 LLM 的推理。

Retrieval Errors: When The Graph Is Usable but The System Brings Back the Wrong Evidence / 檢索錯誤：圖譜可用，但系統取回了錯誤的證據

A retrieval error occurs when the required information is in the graph or summaries, but the system fails to bring the relevant evidence into the model’s context during a query. In GraphRAG, retrieval can work in several ways. Local search finds related entities, expands to connected items, and reports. Global search uses a map-reduce approach across community reports. DRIFT search adds more context and follow-up exploration to broaden local reasoning. Each method has its own weaknesses.

當所需資訊存在於圖譜或摘要中，但系統在查詢過程中未能把相關證據帶入模型的上下文 (context) 時，就會發生檢索錯誤 (retrieval error)。在 GraphRAG 中，檢索可以有多種運作方式。區域搜尋會找出相關實體、擴展到相連的項目與報告。全域搜尋則在社群報告之間使用 map-reduce 方法。DRIFT 搜尋會加入更多上下文與後續探索，以拓寬區域推理。每種方法都有各自的弱點。

Many poor GraphRAG answers are due to using the wrong method, not because the whole system failed. If you use a detail-focused method for a broad question, the answer may be too narrow. If you use a high-level method for a detailed question, the answer might sound good but lack specifics.

許多糟糕的 GraphRAG 答案是因為使用了錯誤的方法，而不是因為整個系統失效。如果你對廣泛的問題使用聚焦細節的方法，答案可能會過於狹隘。如果你對細節性的問題使用宏觀層級的方法，答案可能聽起來不錯卻缺乏具體內容。

Studies show that GraphRAG and standard RAG work best for different tasks. RAG is better for single-hop, detail-heavy questions, while GraphRAG performs better on multi-hop questions. The same research found that community-based GraphRAG often works better in local mode than global mode when you need detailed answers.

研究顯示 GraphRAG 與標準 RAG 各自最擅長不同的任務。RAG 較適合單跳 (single-hop)、細節密集的問題，而 GraphRAG 在多跳 (multi-hop) 問題上表現較佳。同一份研究發現，當你需要詳細答案時，基於社群的 GraphRAG 在區域 (local) 模式下往往比全域 (global) 模式運作得更好。

Microsoft’s later research on dynamic community selection highlights a similar issue. Static global search selects a hierarchy level in advance and summarizes many community reports at that level. This can waste tokens on irrelevant information and push out the evidence that really matters for the question. So, even if the graph is good, the retrieval method can still be inefficient or not fit the question.

微軟後來關於動態社群選擇 (dynamic community selection) 的研究凸顯了類似的問題。靜態全域搜尋會預先選定一個層級 (hierarchy level)，並摘要該層級上的許多社群報告。這可能在不相關的資訊上浪費 token，並把對問題真正重要的證據擠出去。因此，即使圖譜很好，檢索方法仍可能效率低落或不符合問題。

To debug retrieval errors, compare different search modes side-by-side. If switching from global to local search brings up the right answer, the graph is likely fine, but the retrieval strategy needs work. If using lower-level communities helps, your chosen hierarchy level was probably too broad. If DRIFT works when local search does not, the problem may be that the query was not broad enough, not that extraction failed.

要除錯檢索錯誤，可以把不同的搜尋模式並排比較。如果從全域搜尋切換到區域搜尋就能帶出正確答案，那麼圖譜很可能沒問題，但檢索策略需要改進。如果使用較低層級的社群有幫助，那你選擇的層級大概太過廣泛。如果在區域搜尋失敗時 DRIFT 卻有效，問題可能在於查詢不夠廣泛，而不是抽取失敗。

GraphRAG’s documentation also notes that global search quality depends on the community level you choose: lower levels provide more detail but take more time and tokens.

GraphRAG 的文件也指出，全域搜尋的品質取決於你選擇的社群層級：較低的層級提供更多細節，但會耗費更多時間與 token。

Generation Errors: When The Evidence Is Good but The Answer Is Still Bad / 生成錯誤：證據良好，但答案仍然糟糕

A generation error occurs after retrieval, when the model has sufficient or nearly sufficient evidence, but the final answer is still wrong, incomplete, unsupported, or poorly reasoned. Research on GraphRAG treats generation as a separate step from indexing and retrieval.

生成錯誤 (generation error) 發生在檢索之後，此時模型擁有足夠或近乎足夠的證據，但最終答案仍然是錯誤的、不完整的、缺乏佐證的，或推理不佳的。GraphRAG 的研究將生成視為一個與索引和檢索分開的步驟。

RAG-X also argues that teams should check evidence access separately from the final answer, or they might fix the wrong part. Other studies separate hallucination errors from coverage errors, whereas Mindful-RAG examines reasoning mistakes that occur even when the right context is present.

RAG-X 也主張團隊應該把「能否取得證據」與「最終答案」分開檢查，否則他們可能修錯了部分。其他研究則把幻覺錯誤 (hallucination errors) 與覆蓋率錯誤 (coverage errors) 區分開來，而 Mindful-RAG 則檢視即使在正確上下文存在時仍會發生的推理錯誤。

GraphRAG has some common generation pitfalls. One is compression: global search creates intermediate points from community report chunks, ranks and filters them, and then asks the model for a final answer. This process is helpful, but it can miss important details or fail to capture rare cases. Another issue is allowing the model to use external knowledge. Microsoft’s global-search documentation warns that enabling allow_general_knowledge can lead to more hallucinations, even if it sometimes helps.

GraphRAG 有一些常見的生成陷阱。其一是壓縮 (compression)：全域搜尋會從社群報告的區塊產生中間要點，對它們進行排序與過濾，然後請模型給出最終答案。這個流程有幫助，但它可能漏掉重要細節，或無法捕捉到罕見案例。另一個問題是允許模型使用外部知識。微軟的全域搜尋文件警告，啟用 allow_general_knowledge 可能導致更多幻覺，即使它有時確實有幫助。

The easiest way to tell a generation problem from a retrieval problem is to check the retrieved context. If the needed fact is in the retrieved material but the answer is still wrong, it’s a generation issue. At this stage, verifying claims is more helpful than changing retrieval.

要區分生成問題與檢索問題，最簡單的方法是檢查被檢索出的上下文。如果所需的事實存在於被檢索的材料中，但答案仍然是錯的，那就是生成問題。在這個階段，驗證主張比修改檢索更有幫助。

Microsoft’s Claimify project suggests breaking long answers into simple, checkable claims and reviewing them for coverage and context. VeriTrail takes this further by tracing where unsupported content was added and how accurate information can be tracked through each step.

微軟的 Claimify 專案建議把長答案拆解成簡單、可查核的主張，並針對覆蓋率與上下文加以審查。VeriTrail 則更進一步，追溯缺乏佐證的內容是在哪裡被加入的，以及準確資訊如何能在每個步驟中被追蹤。

Why Final-Answer Accuracy Alone Is a Weak Diagnostic / 為什麼單看最終答案準確度是個薄弱的診斷指標

A final score can hide the real problem. GraphRAG-Bench checks graph construction, retrieval, and generation separately because just looking at the overall result does not explain why a system failed. RAG-X makes a similar point in another field, warning that a good result can still lack solid evidence. Another study on RAG versus GraphRAG found strong position bias in some LLM-based summarization tests, showing that a lower score does not always mean the generator is at fault.

最終分數可能掩蓋了真正的問題。GraphRAG-Bench 之所以分別檢查圖譜建構、檢索與生成，是因為光看整體結果並無法解釋一個系統為何失敗。RAG-X 在另一個領域提出了類似的觀點，警告說一個好的結果仍可能缺乏紮實的證據。另一份關於 RAG 與 GraphRAG 對比的研究，在某些基於 LLM 的摘要測試中發現了強烈的位置偏誤 (position bias)，顯示較低的分數並不總是代表生成器才是問題所在。

A Simple Diagnostic Workflow for GraphRAG / GraphRAG 的簡單診斷工作流程

  1. Start by checking the index. Check whether the required concept is present in text_units, entities, relationships, or community_reports. If it’s missing or not represented well, the problem started earlier and is an extraction issue.

  2. 先從檢查索引開始。檢查所需的概念是否出現在 text_units、entities、relationships 或 community_reports 中。如果它遺失了或表徵得不好，那麼問題在更早的階段就出現了，屬於抽取問題。

  3. Compare different retrieval modes using the same question. Try local, global, DRIFT, and basic search with the same prompt. If one mode finds the right evidence and another does not, the graph is probably fine, and the issue is with the retrieval method.

  4. 用同一個問題比較不同的檢索模式。 用相同的提示詞嘗試區域、全域、DRIFT 與基本搜尋。如果某個模式找到了正確證據而另一個沒有，那麼圖譜大概沒問題，問題出在檢索方法上。

  5. Look at the retrieved evidence, not just the answer. If the context already includes the missing or corrected fact, the problem is now in the generation step. At this point, extracting claims and tracing their sources is more helpful than changing the index.

  6. 檢視被檢索出的證據，而不只是答案。 如果上下文已經包含了那個遺失或經修正的事實，那麼問題現在就出在生成步驟。在這個時候，抽取主張並追溯其來源，比修改索引更有幫助。

  7. Make sure your fix matches the type of problem. For extraction issues, improve prompt tuning, parsing, chunking, or graph building. For retrieval issues, choose better search modes, adjust hierarchy levels, or use a broader context. For generation issues, focus on stronger grounding, less guesswork in prompts, and checking answers after they’re made.

  8. 確保你的修正方式符合問題的類型。對於抽取問題，改善提示詞調校、解析、分塊或圖譜建構。對於檢索問題，選擇更好的搜尋模式、調整層級，或使用更廣泛的上下文。對於生成問題，著重於更強的接地 (grounding)、在提示詞中減少臆測，並在答案產生後加以查核。

FAQ / 常見問題

Is GraphRAG better than standard RAG?

GraphRAG 比標準 RAG 更好嗎？

Not in every case. The original GraphRAG paper showed big improvements for broad, whole-corpus questions. Later studies found a more mixed result: standard RAG is often better for simple, detail-focused lookups, while GraphRAG is usually stronger for multi-step reasoning or creating more varied, higher-level summaries.

並非每種情況都是。最初的 GraphRAG 論文顯示，它在廣泛、針對整個語料庫 (whole-corpus) 的問題上有很大的改善。後續研究則得到較為參差的結果：標準 RAG 在簡單、聚焦細節的查詢上往往較佳，而 GraphRAG 通常在多步驟推理，或建立更多元、更宏觀的摘要時較為強大。

Can GraphRAG eliminate hallucinations?

GraphRAG 能消除幻覺嗎？

No. GraphRAG can help with grounding by organizing evidence, but it still has a generation step that can make things up or miss key details. Microsoft’s documentation warns that letting the model use general world knowledge during global search can increase hallucinations, and VeriTrail explains why multi-step systems still need to be traceable.

不能。GraphRAG 可以透過組織證據來協助接地 (grounding)，但它仍然有一個可能憑空編造或漏掉關鍵細節的生成步驟。微軟的文件警告，在全域搜尋過程中讓模型使用一般世界知識可能會增加幻覺，而 VeriTrail 則解釋了為什麼多步驟系統仍然需要具備可追溯性。

What should I inspect first when GraphRAG gives a bad answer?

當 GraphRAG 給出糟糕答案時，我應該先檢查什麼？

Begin by checking the index and the retrieved context, not just the final answer. If the knowledge is missing from the graph, it’s an extraction problem. If it’s in the graph but not in the retrieved context, it’s a retrieval problem. If the evidence is there but the answer is still wrong, it’s a generation problem. This order is much more reliable than just guessing from the answer.

先從檢查索引與被檢索出的上下文開始，而不只是最終答案。如果知識在圖譜中缺失，那是抽取問題。如果它存在於圖譜中卻不在被檢索的上下文裡，那是檢索問題。如果證據都在，但答案仍然是錯的，那是生成問題。這個順序遠比單純從答案去猜測來得可靠。

Closing Thought / 結語

The most common mistake teams make with GraphRAG is treating every bad answer as the same problem. In fact, GraphRAG works in layers: it extracts structure, retrieves evidence based on that structure, and then generates a final answer. When you break these steps down, debugging becomes much easier.

團隊在使用 GraphRAG 時最常犯的錯誤，就是把每一個糟糕答案都當成同一種問題。事實上，GraphRAG 是分層運作的：它抽取結構、根據該結構檢索證據，然後生成最終答案。當你把這些步驟拆解開來，除錯就會變得容易許多。

You stop changing answer prompts to fix broken graphs, stop rebuilding indexes to fix search issues, and stop blaming retrieval when the real problem is in reasoning or unsupported generation. That’s the difference between thinking “GraphRAG is unreliable” and knowing exactly which part to improve next.

你不再為了修復有缺陷的圖譜而去改答案提示詞，不再為了解決搜尋問題而去重建索引，也不再在真正問題出在推理或缺乏佐證的生成時去怪罪檢索。這就是「認為 GraphRAG 不可靠」與「確切知道接下來該改進哪個部分」之間的差別。

References / 參考文獻

  1. GraphRAG documentation: Query Overview, Local Search, Global Search, DRIFT Search, Dataflow, Outputs, and Methods — Microsoft GraphRAG Docs.

  2. GraphRAG 文件：查詢概觀、區域搜尋、全域搜尋、DRIFT 搜尋、資料流、輸出與方法 — 微軟 GraphRAG 文件。

  3. Graph Retrieval-Augmented Generation: A Survey — Journal of the ACM / arXiv mirror.

  4. 圖檢索增強生成：綜述 (Graph Retrieval-Augmented Generation: A Survey) — ACM 期刊 / arXiv 鏡像。

  5. GraphRAG-Bench: Challenging Domain-Specific Reasoning for Evaluating Graph Retrieval-Augmented Generation — benchmark paper.

  6. GraphRAG-Bench：以具挑戰性的領域特定推理來評估圖檢索增強生成 — 基準測試論文。

  7. RAG-X: Systematic Diagnosis of Retrieval-Augmented Generation for Medical Question Answering — diagnostic framework.

  8. RAG-X：針對醫療問答之檢索增強生成的系統性診斷 — 診斷框架。

  9. Detecting Hallucination and Coverage Errors in Retrieval Augmented Generation for Controversial Topics — error-analysis paper.

  10. 偵測爭議性主題之檢索增強生成中的幻覺與覆蓋率錯誤 — 錯誤分析論文。

  11. GraphRAG auto-tuning provides rapid adaptation to new domains, and GraphRAG: Improving global search via dynamic community selection — Microsoft Research blog posts.

  12. GraphRAG 自動調校提供對新領域的快速適應，以及 GraphRAG：透過動態社群選擇改善全域搜尋 — 微軟研究院部落格文章。

  13. Towards Effective Extraction and Evaluation of Factual Claims and VeriTrail: Closed-Domain Hallucination Detection with Traceability — Microsoft Research publications.

  14. 邁向事實性主張的有效抽取與評估，以及 VeriTrail：具可追溯性的封閉領域幻覺偵測 — 微軟研究院出版品。

🔤 關鍵術語

英文 繁中譯名 文章中的脈絡 / 簡短說明
GraphRAG 圖譜檢索增強生成 從文件建構以實體為核心的知識圖譜，再用圖譜引導檢索與生成的 RAG 方法
Vector RAG 向量檢索增強生成 基於向量相似度檢索鄰近文本的傳統 RAG，文中作為 GraphRAG 的對照基準
Extraction error 抽取錯誤 圖譜建構階段就產生錯誤內部表徵（漏實體、合併實體、關係描述模糊等）
Retrieval error 檢索錯誤 圖譜可用但查詢時未把相關證據帶入模型脈絡，常因選錯搜尋模式
Generation error 生成錯誤 證據充足但最終答案仍錯誤、不完整或缺乏支撐
Local search 局部搜尋 針對特定實體的查詢，找相關實體並擴展到相連項目與報告
Global search 全域搜尋 對整個語料的查詢，用 map-reduce 方式彙整社群報告
DRIFT search DRIFT 搜尋 加入更多脈絡與後續探索以拓寬局部推理的搜尋方式
Entity extraction 實體抽取 從文本單元中抽出實體、關係（有時含主張）的步驟
Text units 文本單元 文件切分後的最小處理單位，抽取在此層級進行
Community reports 社群報告 圖譜中相關項目分群後產生的摘要報告
Multi-hop reasoning 多跳推理 需串連分散資訊的多步推理任務，GraphRAG 表現較佳
Single-hop question 單跳問題 細節導向的單步查詢，標準 RAG 通常較佳
Map-reduce 映射歸約 全域搜尋跨社群報告彙整答案所用的計算策略
Dynamic community selection 動態社群選擇 微軟提出的改良，避免靜態全域搜尋浪費 token 於不相關層級
Hierarchy level 階層層級 社群階層的選取層級，越低層越詳細但耗時與 token 越多
Hallucination 幻覺 模型生成無依據內容；啟用一般知識會增加此風險
Coverage error 覆蓋率錯誤 答案遺漏應涵蓋資訊的錯誤，與幻覺錯誤區分
Position bias 位置偏誤 LLM 摘要評測中因內容位置而產生的評分偏差
Claim extraction 主張抽取 將長答案拆成可驗證的簡單主張以檢查覆蓋與脈絡（Claimify／VeriTrail）
Noun-phrase extraction 名詞片語抽取 FastGraphRAG 用 NLP 名詞片語與共現邊取代部分 LLM 推理