跳轉到

用於 Graph RAG 抽取的本地端 LLM：什麼方法真正有效

文章資訊

作者：Alexander Shereshevsky　　日期：2026-06-13

原文標題：Local LLMs for Graph RAG Extraction: What Actually Works

Medium 原連結：https://medium.com/graph-praxis/local-llms-for-graph-rag-extraction-what-actually-works-388233dd9eda

🎧 摘要語音

📝 重點摘要

TL;DR

本地小模型找實體沒問題，但抽取結構化關係三元組才是真瓶頸。

核心問題

Graph RAG 的關注多在檢索，但前置的「抽取」更難：在合規受限環境須用本地模型，將文字轉成 (主詞, 述詞, 受詞) 三元組並輸出合法 JSON。作者建 benchmark 探討哪個本地 7–9B 模型、搭配哪種 prompt 最有效。

關鍵發現 / 數據

  • 實體辨識已解決（Entity F1 0.78–0.91），但三元組抽取落後：最佳僅 0.732（Llama 3.1 + few-shot），多數落在 0.52–0.60。
  • 無「最佳模型」，只有取捨：Llama 3.1 品質最高但 few-shot 僅 20% 符合 schema；Mistral 7B 達 100% schema 一致性但品質上限 0.564。
  • Gemma 2 9B 最均衡：few-shot 達 0.653 F1、65% 一致性；schema-in-prompt 達 95% 可靠度。
  • Few-shot 普遍提升品質卻傷可靠度（Qwen 延遲從 10.9s→37.0s，JSON 易壞）；Mistral 是唯一例外。
  • 複雜文本使三元組品質大幅下滑（Qwen 從 0.643 跌至 0.365–0.438），常產生未拆解的複合受詞。

方法亮點

  • 自建 20 段、四種複雜度的資料集，含 150 實體、139 三元組金標準。
  • 三種策略對比：naive、schema-in-prompt、few-shot；統一 RTX 3090 + vLLM 環境。
  • 評估採模糊比對 + 述詞同義詞正規化（~45 組）、助動詞剝離、子字串實體比對，未改輸出即提升 F1 達 15–34%。
  • 提出 fallback 策略：先 few-shot，失敗則退回 schema-in-prompt。

對我的研究有用嗎？

相當有用。它清楚點出 GraphRAG 真正瓶頸在「關係抽取」而非檢索，值得作為動機論述參考。其「品質 vs schema 一致性」的二維取捨框架、以及「評估邏輯與抽取同等重要」（同義述詞正規化）的觀察，對設計 KG 抽取 pipeline 與評測指標很有啟發。建議的 constrained decoding、CoT 抽取方向也指出後續研究空間。

評語

值得快速一讀：實驗紮實、有開源程式碼，誠實揭露取捨；但樣本僅 20 段偏小，模型版本稍舊，結論的統計穩健性需自行驗證。

🌐 中英對照

Author: Alexander Shereshevsky
作者：Alexander Shereshevsky
Published:
發佈日期：
Source: https://medium.com/graph-praxis/local-llms-for-graph-rag-extraction-what-actually-works-388233dd9eda
來源：https://medium.com/graph-praxis/local-llms-for-graph-rag-extraction-what-actually-works-388233dd9eda
Fetched: 2026-06-13T00:47:18.296604
擷取時間：2026-06-13T00:47:18.296604

Local LLMs for Graph RAG Extraction: What Actually Works / 用於 Graph RAG 抽取的本地大型語言模型：哪些方法真正有效

Press enter or click to view image in full size

按 Enter 或點擊以檢視完整大小的圖片

The hidden bottleneck in Graph RAG isn't retrieval. It's extraction. / Graph RAG 隱藏的瓶頸不在於檢索，而在於抽取

Graph RAG has emerged as one of the most promising approaches for building knowledge-grounded AI systems. By structuring documents into knowledge graphs — networks of entities connected by typed relationships — it enables retrieval that understands how things relate, not just what words co-occur.

Graph RAG 已成為建構以知識為基礎的 AI 系統最有前景的方法之一。它將文件結構化為知識圖譜 (Knowledge Graph)——也就是由具型別關係 (typed relationships) 連接的實體 (entity) 所構成的網路——從而實現一種能理解事物之間「如何」關聯的檢索，而不僅僅是「哪些」字詞共同出現。

But there's a problem nobody talks about enough: the extraction step.

但有一個鮮少被充分討論的問題：抽取 (extraction) 這個步驟。

Before you can query a knowledge graph, you need to build one. That means taking raw text and extracting structured entity-relation triples — things like (Marie Curie, born_in, Warsaw) or (CRISPR-Cas9, developed_by, Jennifer Doudna). Most Graph RAG papers assume you'll throw GPT-4 at this and move on. But if you're building production systems, especially in regulated environments where data can't leave your infrastructure, you need local models. And local models have a much harder time with structured extraction than you might expect.

在能夠查詢知識圖譜之前，你必須先建立一個。這意味著要從原始文字中抽取結構化的實體—關係三元組 (entity-relation triples)——像是 (Marie Curie, born_in, Warsaw) 或 (CRISPR-Cas9, developed_by, Jennifer Doudna)。大多數 Graph RAG 論文都假設你會直接拿 GPT-4 來處理然後繼續往下走。但如果你正在建構正式上線的系統，尤其是在資料不能離開自家基礎設施的受監管環境中，你就需要本地模型 (local models)。而本地模型在結構化抽取上的表現，比你想像中要困難得多。

I built a benchmark to find out exactly how hard it is.

我建立了一個基準測試 (benchmark)，要精確找出它到底有多困難。

Why Local Models for Graph RAG? / 為什麼 Graph RAG 要用本地模型？

The case for local extraction models is straightforward. In enterprise settings — healthcare, legal, finance — sending documents to external APIs isn't always an option. Compliance requirements, latency constraints, and cost at scale all push toward running extraction locally.

採用本地抽取模型的理由很直接。在企業環境中——醫療、法律、金融——將文件傳送到外部 API 並非總是可行的選項。法規遵循 (compliance) 要求、延遲 (latency) 限制，以及大規模運作下的成本，全都促使我們在本地端執行抽取。

The question isn't whether to use local models. It's which ones, and how to prompt them.

問題不在於「要不要」使用本地模型，而在於「該用哪些」以及「該如何對它們下提示 (prompt)」。

Graph RAG extraction is a particularly demanding task for small models. You're asking a 7–9B parameter model to simultaneously: identify all entities in a passage, classify their types, determine the relationships between them, express those relationships as structured triples, and output everything as valid JSON. That's a lot of cognitive load for a model that runs on a single GPU.

對於小型模型而言，Graph RAG 抽取是一項格外吃力的任務。你要求一個 7–9B 參數的模型同時做到：辨識段落中的所有實體、為它們的型別分類、判定它們之間的關係、將這些關係表達為結構化的三元組，並把所有內容輸出為有效的 JSON。對於一個在單張 GPU 上運行的模型來說，這是相當沉重的認知負荷。

The Experiment / 實驗

I designed a benchmark specifically for Graph RAG extraction quality. Unlike general-purpose NLP benchmarks, this one focuses on the exact task a Graph RAG pipeline needs: given a text passage, produce structured (subject, predicate, object) triples with typed entities.

我專門為 Graph RAG 的抽取品質設計了一個基準測試。與通用型的 NLP 基準測試不同，這個基準聚焦於 Graph RAG 流程 (pipeline) 真正需要的任務：給定一段文字，產出帶有型別化實體的結構化 (subject, predicate, object)（主詞、謂詞、受詞）三元組。

The dataset: 20 passages spanning four complexity levels — simple (clear entities, few relations), moderate (multiple entities with interconnected relations), complex (dense passages with nested relationships), and edge cases (aliases, abbreviations, empty passages). The dataset covers domains like biography, science, business, technology, and geopolitics, with 150 gold-standard entities and 139 gold-standard triples.

資料集： 20 段文字，橫跨四種複雜度等級——簡單（實體清晰、關係少）、中等（多個實體且關係彼此交織）、複雜（內容密集且關係層層嵌套），以及邊緣案例（別名、縮寫、空白段落）。該資料集涵蓋傳記、科學、商業、科技與地緣政治等領域，包含 150 個黃金標準 (gold-standard) 實體與 139 個黃金標準三元組。

The models:

模型：

+--------------------------+------------+----------------+  
| Model                    | Parameters | Family         |  
+--------------------------+------------+----------------+  
| Qwen 2.5 7B Instruct     | 7B         | Qwen (Alibaba) |  
| Llama 3.1 8B Instruct    | 8B         | Llama (Meta)   |  
| Mistral 7B Instruct v0.3 | 7B         | Mistral        |  
| Gemma 2 9B IT            | 9B         | Gemma (Google) |  
+--------------------------+------------+----------------+

All models ran on a single NVIDIA RTX 3090 (24GB) via vLLM with identical settings: 4096 max context length, prefix caching enabled, 8 concurrent requests.

所有模型都透過 vLLM 在單張 NVIDIA RTX 3090 (24GB) 上以相同設定執行：最大上下文長度 (max context length) 4096、啟用前綴快取 (prefix caching)、8 個並行請求。

The prompting strategies:

提示策略：

  1. Naive — a simple instruction to extract entities and triples as JSON

  2. 樸素法 (Naive)——一個簡單的指令，要求以 JSON 形式抽取實體與三元組

  3. Schema-in-prompt — the same instruction plus the exact JSON schema the output should follow

  4. 提示內附綱要 (Schema-in-prompt)——相同的指令，外加輸出應遵循的確切 JSON 綱要 (schema)

  5. Few-shot — two worked examples showing input text and expected extraction output

  6. 少樣本法 (Few-shot)——兩個示範範例，展示輸入文字與預期的抽取輸出

Evaluation: fuzzy matching with synonym-aware predicate comparison. Models shouldn't be penalized for producing was_born_in instead of born_in — those mean the same thing for a knowledge graph. Entity matching uses token-sort ratio with a threshold of 75, and predicates go through a synonym canonicalization layer with ~45 synonym groups before falling back to fuzzy string matching.

評估方式： 採用具同義詞感知 (synonym-aware) 的謂詞比對的模糊比對 (fuzzy matching)。模型若產出 was_born_in 而非 born_in，不應因此被扣分——對知識圖譜而言它們意義相同。實體比對使用門檻為 75 的 token-sort 比率 (token-sort ratio)，而謂詞則會先經過一個約有 45 個同義詞群組的同義詞正規化 (canonicalization) 層，之後才退回採用模糊字串比對。

The Results / 結果

Finding 1: Entity Recognition Is Solved. Relation Extraction Is Not. / 發現一：實體辨識已經解決，關係抽取尚未

Press enter or click to view image in full size

按 Enter 或點擊以檢視完整大小的圖片

All four models achieve Entity F1 scores between 0.78 and 0.91 — respectable performance that would be usable in production. The models are good at finding things in text.

四個模型的實體 F1 (Entity F1) 分數都落在 0.78 到 0.91 之間——這是相當不錯、足以用於正式環境的表現。這些模型擅長在文字中「找出」東西。

But look at Triple F1:

但再看看三元組 F1 (Triple F1)：

Press enter or click to view image in full size

按 Enter 或點擊以檢視完整大小的圖片

The picture changes dramatically. The best result across all model-strategy combinations is 0.732 (Llama 3.1 + few-shot), and most configurations land between 0.52 and 0.60. The gap between entity recognition and relation extraction is the central challenge: models can identify Marie Curie and Warsaw in a sentence, but reliably extracting (Marie Curie, born_in, Warsaw) as a structured triple is significantly harder.

情況急轉直下。在所有模型—策略組合中，最佳結果是 0.732（Llama 3.1 + 少樣本法），而大多數配置都落在 0.52 到 0.60 之間。實體辨識與關係抽取之間的落差正是核心挑戰：模型能在句子中辨識出 Marie Curie 和 Warsaw，但要可靠地將 (Marie Curie, born_in, Warsaw) 抽取為結構化三元組則明顯困難得多。

Why? Relation extraction requires understanding not just what entities exist, but how they connect. It demands both semantic comprehension and structural discipline — the model needs to decompose compound statements into atomic triples, choose consistent predicate names, and maintain valid JSON throughout.

為什麼？關係抽取不僅需要理解「有哪些」實體存在，還要理解它們「如何」連接。它同時要求語意理解 (semantic comprehension) 與結構紀律 (structural discipline)——模型必須把複合陳述拆解成原子化的三元組 (atomic triples)、選用一致的謂詞名稱，並且全程維持有效的 JSON。

Finding 2: There's No Best Model. There's a Tradeoff. / 發現二：沒有最佳模型，只有取捨

Press enter or click to view image in full size

按 Enter 或點擊以檢視完整大小的圖片

This scatter plot tells the real story. The x-axis shows schema conformance rate (does the model produce valid, parseable output?) and the y-axis shows Triple F1 (when it does produce output, how good is it?). The top-right corner — high quality and high reliability — is empty.

這張散佈圖 (scatter plot) 道出了真實情況。x 軸代表綱要符合率 (schema conformance rate)（模型是否產出有效、可解析的輸出？），y 軸代表三元組 F1（當它確實產出輸出時，品質有多好？）。圖的右上角——同時兼具高品質「與」高可靠性的區域——是空的。

Llama 3.1 8B achieves the highest extraction quality (0.732 Triple F1 with few-shot prompting) but is the least reliable — only 20% of its few-shot outputs conform to the expected schema. When it works, it's excellent. 80% of the time, it doesn't work.

Llama 3.1 8B 達到了最高的抽取品質（採用少樣本提示時三元組 F1 為 0.732），但卻是最不可靠的——它的少樣本輸出中只有 20% 符合預期綱要。當它成功時，表現極佳；但有 80% 的時候，它根本不管用。

Mistral 7B v0.3 is the opposite: 100% JSON validity and 100% schema conformance with schema-in-prompt, but the extraction quality tops out at 0.564 Triple F1. It's the workhorse — predictable, fast (7–14s average latency, roughly 3x faster than others), and never crashes. But it leaves accuracy on the table.

Mistral 7B v0.3 則恰好相反：搭配提示內附綱要時，達到 100% 的 JSON 有效性與 100% 的綱要符合率，但抽取品質最高僅止於 0.564 的三元組 F1。它是任勞任怨的主力——可預測、快速（平均延遲 7–14 秒，約比其他模型快 3 倍），而且從不當機。但它在準確度上有所保留、未能盡其所能。

Qwen 2.5 7B occupies a similar space to Mistral — reliable (100% schema conformance with naive and schema prompting) with moderate extraction quality (0.52–0.58 Triple F1).

Qwen 2.5 7B 所佔據的位置與 Mistral 相近——可靠（在樸素法與綱要提示下達 100% 綱要符合率），抽取品質中等（三元組 F1 為 0.52–0.58）。

Gemma 2 9B offers the best all-around balance. With few-shot prompting, it hits 0.653 Triple F1 at 65% schema conformance. With schema-in-prompt, it gets 95% reliability at 0.571 Triple F1. Its larger parameter count (9B vs 7–8B) seems to help, particularly on complex passages.

Gemma 2 9B 提供了最佳的全方位平衡。採用少樣本提示時，它在 65% 綱要符合率下達到 0.653 的三元組 F1；採用提示內附綱要時，則在 0.571 的三元組 F1 下達到 95% 的可靠性。它較大的參數量（9B 對比 7–8B）似乎有所幫助，尤其在處理複雜段落時。

Finding 3: Few-Shot Helps Quality but Hurts Reliability / 發現三：少樣本法提升品質，卻損害可靠性

Across all four models, few-shot prompting consistently achieves the highest Triple F1. The worked examples help models understand the expected output structure, the granularity of predicates, and the decomposition of compound relations.

在全部四個模型中，少樣本提示始終取得最高的三元組 F1。那些示範範例幫助模型理解預期的輸出結構、謂詞的粒度 (granularity)，以及複合關係的拆解方式。

But the cost is real. Few-shot prompts are 3–5x longer, which increases latency (Qwen goes from 10.9s to 37.0s) and — more critically — reduces output reliability. The longer context seems to confuse smaller models into producing malformed JSON, rambling explanations instead of structured output, or partial extractions.

但代價是實實在在的。少樣本提示的長度是原本的 3–5 倍，這會增加延遲（Qwen 從 10.9 秒上升到 37.0 秒），而且——更關鍵的是——會降低輸出的可靠性。較長的上下文似乎會把小型模型搞糊塗，導致它們產出格式錯誤的 JSON、冗長散漫的解釋而非結構化輸出，或是不完整的抽取結果。

+-----------------+---------------+--------------------------+------------------+  
| Model           | Naive Schema% | Schema-in-Prompt Schema% | Few-Shot Schema% |  
+-----------------+---------------+--------------------------+------------------+  
| Qwen 2.5 7B     | 100%          | 100%                     | 80%              |  
| Llama 3.1 8B    | 50%           | 95%                      | 20%              |  
| Mistral 7B v0.3 | 20%           | 100%                     | 100%             |  
| Gemma 2 9B      | 45%           | 95%                      | 65%              |  
+-----------------+---------------+--------------------------+------------------+

Mistral is the notable exception — it improves with few-shot while maintaining 100% schema conformance. This makes it the only model where few-shot is strictly better than the alternatives.

Mistral 是值得注意的例外——它在少樣本法下「有所提升」，同時維持 100% 的綱要符合率。這使它成為唯一一個「少樣本法嚴格優於其他選項」的模型。

Finding 4: Complexity Degrades Triples More Than Entities / 發現四：複雜度對三元組的劣化甚於對實體

When passages get harder — more entities, nested relationships, temporal qualifiers — entity detection stays relatively stable, but triple extraction falls off sharply. For Qwen with the naive strategy, simple passages get 0.643 Triple F1, but moderate passages drop to 0.365 and complex passages to 0.438. The models struggle to decompose dense text into atomic triples, often producing compound objects such as "Jennifer Doudna at UC Berkeley and Emmanuelle Charpentier at the Max Planck Institute" rather than separate triples for each researcher and their affiliation.

當段落變得更難時——更多實體、嵌套的關係、時間限定詞 (temporal qualifiers)——實體偵測仍維持相對穩定，但三元組抽取卻急遽下滑。以採用樸素策略的 Qwen 為例，簡單段落取得 0.643 的三元組 F1，但中等段落降至 0.365、複雜段落則為 0.438。這些模型難以將密集的文字拆解為原子化三元組，常常產出複合受詞，例如 "Jennifer Doudna at UC Berkeley and Emmanuelle Charpentier at the Max Planck Institute"，而非為每位研究者及其所屬機構各自產出獨立的三元組。

Press enter or click to view image in full size

按 Enter 或點擊以檢視完整大小的圖片

This has practical implications for Graph RAG: if your documents are dense technical or legal text, expect extraction quality to degrade more than simple benchmarks would suggest.

這對 Graph RAG 有實際的影響：如果你的文件是密集的技術或法律文字，可以預期抽取品質的劣化程度會比簡單的基準測試所暗示的更為嚴重。

The Evaluation Problem / 評估的難題

Building this benchmark revealed something important: evaluation is nearly as hard as extraction.

建立這個基準測試揭示了一件重要的事：「評估本身幾乎與抽取一樣困難」。

My initial results showed Triple F1 scores around 0.36–0.48, which seemed alarmingly low. But digging into the raw outputs revealed that the models were actually producing semantically correct extractions — they were just using different words. A model that outputs stands_at instead of height, or is_also_known_as instead of also_known_as, shouldn't be penalized. These mean the same thing in a knowledge graph.

我最初的結果顯示三元組 F1 分數約在 0.36–0.48 之間，看起來低得令人警覺。但深入檢視原始輸出後發現，這些模型其實產出了語意上正確的抽取結果——它們只是用了不同的字詞。一個輸出 stands_at 而非 height，或輸出 is_also_known_as 而非 also_known_as 的模型，不應該因此被扣分。在知識圖譜中，這些意義是相同的。

I went through three iterations of evaluation improvements:

我經歷了三輪評估改進的迭代：

  1. Predicate synonym groups — mapping ~45 groups of semantically equivalent predicates (e.g., born_in, was_born_in, birthplace, place_of_birth all map to the same canonical form)

  2. 謂詞同義詞群組 (Predicate synonym groups)——映射約 45 個語意等價的謂詞群組（例如 born_in、was_born_in、birthplace、place_of_birth 全都映射到同一個正規形式）

  3. Auxiliary verb stripping — automatically removing prefixes like is_, was_, has_been_ before matching, so is_part_of matches part_of

  4. 助動詞去除 (Auxiliary verb stripping)——在比對前自動移除 is_、was_、has_been_ 之類的前綴，使 is_part_of 能與 part_of 相符

  5. Substring entity matching — accepting verbose model outputs like "Jennifer Doudna at UC Berkeley" as a match for the gold entity "Jennifer Doudna" in triple evaluation

  6. 子字串實體比對 (Substring entity matching)——在三元組評估中，接受像 "Jennifer Doudna at UC Berkeley" 這類冗長的模型輸出，視其與黃金標準實體 "Jennifer Doudna" 相符

These three changes improved the measured Triple F1 by 15–34% without changing any model outputs. The lesson: if you're building a Graph RAG evaluation pipeline, invest as much effort in your matching logic as in your extraction prompts. Overly strict evaluation will make your models look worse than they actually are.

這三項變更在完全不改動任何模型輸出的情況下，將實測的三元組 F1 提升了 15–34%。教訓是：如果你正在建構一條 Graph RAG 評估流程，請在比對邏輯上投入與抽取提示同等的心力。過於嚴格的評估會讓你的模型看起來比實際表現更差。

Practical Recommendations / 實務建議

Based on 2000 extraction runs across 4 models and 3 strategies, here's what I'd recommend for production Graph RAG systems:

基於橫跨 4 個模型與 3 種策略共 2000 次抽取執行，以下是我對正式上線的 Graph RAG 系統的建議：

If reliability is your top priority (e.g., automated pipelines with no human review): Use Mistral 7B v0.3 + few-shot. It's the only configuration that achieves 100% schema conformance while still getting reasonable extraction quality (0.564 Triple F1). It's also the fastest model, averaging 14s per extraction.

如果可靠性是你的首要考量（例如沒有人工審查的自動化流程）：使用 Mistral 7B v0.3 + 少樣本法。它是唯一一個能在達到 100% 綱要符合率的同時，仍取得合理抽取品質（三元組 F1 為 0.564）的配置。它也是最快的模型，平均每次抽取耗時 14 秒。

If extraction quality matters most (e.g., building a curated knowledge base with human validation): Use Gemma 2 9B + few-shot. At 0.653 Triple F1 with 65% schema conformance, you'll need to handle failures, but the successful extractions are meaningfully better. The 9B parameter count gives it an edge on complex passages.

如果抽取品質最為重要（例如建構一個經人工驗證、精心整理的知識庫）：使用 Gemma 2 9B + 少樣本法。在 0.653 的三元組 F1 與 65% 綱要符合率下，你會需要處理失敗的情況，但成功的抽取結果在品質上有實質的提升。9B 的參數量讓它在處理複雜段落時具有優勢。

If you need both and can afford retries: Use Llama 3.1 8B + few-shot with a fallback strategy. Try a few-shot first (0.732 Triple F1 when it works), and if the output fails schema validation, retry with schema-in-prompt (95% conformance). This gives you the best of both worlds at the cost of ~2x latency on failures.

如果你兩者都需要、而且承擔得起重試：使用 Llama 3.1 8B + 少樣本法搭配後備策略 (fallback strategy)。先嘗試少樣本法（成功時三元組 F1 為 0.732），如果輸出未通過綱要驗證，再以提示內附綱要重試（符合率 95%）。這讓你兼得兩者之長，代價是在失敗時延遲約增加 2 倍。

For all models: Schema-in-prompt is the safe default. It provides the best reliability-to-quality ratio across every model tested.

對所有模型而言：提示內附綱要是安全的預設選項。在所有受測模型中，它都提供了最佳的可靠性對品質比。

What This Means for Graph RAG / 這對 Graph RAG 意味著什麼

The structured extraction gap — high entity recognition but mediocre relation extraction — is the real bottleneck for local Graph RAG. Closing it likely requires a combination of better prompting (perhaps chain-of-thought extraction where the model reasons about relationships before outputting JSON), constrained decoding (forcing valid JSON output at the token level), and possibly specialized fine-tuning on extraction tasks.

結構化抽取的落差——高水準的實體辨識但平庸的關係抽取——才是本地 Graph RAG 真正的瓶頸。要彌合這道落差，很可能需要結合更好的提示方式（或許是思維鏈 (chain-of-thought) 抽取，讓模型在輸出 JSON 之前先對關係進行推理）、受約束解碼 (constrained decoding)（在 token 層級強制產出有效的 JSON），以及可能針對抽取任務進行的專門微調 (fine-tuning)。

The good news is that these models are already useful. A Triple F1 of 0.55–0.65 means that more than half of the knowledge graph triples that a local model produces are correct and grounded. Combined with human review or confidence-based filtering, that's enough to build production knowledge graphs without sending your data to external APIs.

好消息是，這些模型已經很有用了。0.55–0.65 的三元組 F1 意味著本地模型所產出的知識圖譜三元組中，有超過一半是正確且有依據 (grounded) 的。再搭配人工審查或基於信心度 (confidence-based) 的過濾，這就足以在不將資料傳送到外部 API 的情況下，建構出可正式上線的知識圖譜。

The full benchmark code, dataset, and results are available on GitHub. Run it on your own hardware, add your own models, and help the community understand what works for local Graph RAG extraction.

完整的基準測試程式碼、資料集與結果皆已公開於 GitHub。在你自己的硬體上執行它、加入你自己的模型，並協助社群了解哪些方法對本地 Graph RAG 抽取真正有效。

Benchmarked on a single NVIDIA RTX 3090 using vLLM v0.7.3 with prefix caching. All models are open-weight and available on HuggingFace.

本基準測試在單張 NVIDIA RTX 3090 上、使用啟用前綴快取的 vLLM v0.7.3 進行。所有模型皆為開放權重 (open-weight) 模型，並可於 HuggingFace 取得。

🔤 關鍵術語

英文 繁中譯名 文章中的脈絡 / 簡短說明
Graph RAG 圖譜檢索增強生成 將文件結構化為知識圖譜以進行檢索的 AI 系統，本文核心主題
knowledge graph 知識圖譜 由實體與帶類型關係連結而成的網路，是 Graph RAG 的查詢對象
entity-relation triple 實體關係三元組 抽取的結構化單元，如 (Marie Curie, born_in, Warsaw)
(subject, predicate, object) triple （主語、謂語、賓語）三元組 三元組的標準結構形式，含帶類型的實體
relation extraction 關係抽取 判斷實體間如何連結並表達為三元組，本文指出的真正瓶頸
entity recognition 實體辨識 在文本中找出實體，本文結論為「已被解決」的任務
structured extraction 結構化抽取 從原始文本產生結構化、含類型的三元組之任務
Entity F1 / Triple F1 實體 F1／三元組 F1 衡量實體辨識與三元組抽取品質的評估指標
schema conformance 結構綱要符合率 模型輸出符合預期 JSON schema 的比例，反映可靠度
few-shot prompting 少樣本提示 提供數個範例的提示策略，提升品質但降低可靠度
schema-in-prompt 提示內嵌綱要 在提示中附上 JSON schema 的策略，本文推薦的安全預設
naive prompting 簡易提示 僅給簡單指令抽取實體與三元組的基準策略
atomic triple 原子三元組 將複合語句拆解後的最小不可分三元組
predicate canonicalization 謂語正規化 將同義謂語映射至同一標準形式的評估層
predicate synonym group 謂語同義詞群組 約 45 組語意等價謂語的對應，用於公平評估
fuzzy matching 模糊比對 評估時容許用詞差異的比對方法
token-sort ratio 詞元排序比率 實體比對所用的字串相似度演算法（門檻 75）
constrained decoding 約束解碼 在 token 層級強制產生有效 JSON 的技術
chain-of-thought extraction 思維鏈抽取 模型先推理關係再輸出 JSON 的潛在改進方向
fine-tuning 微調 針對抽取任務做專門訓練以縮小品質差距
vLLM vLLM（推論引擎） 本文用來在單張 RTX 3090 上運行本地模型的推論框架
prefix caching 前綴快取 vLLM 啟用的最佳化，重用共同提示前綴的計算