從荷馬《伊利亞德》建構知識圖譜：開放域 vs. Schema 引導式抽取¶
文章資訊
作者：Alexander Shereshevsky 日期：2026-06-13
原文標題：Building Knowledge Graphs from Homer’s Iliad: Open-Domain vs. Schema-Guided Extraction
📝 重點摘要¶
TL;DR¶
Schema 引導式抽取較乾淨可查詢，開放域較豐富但語意碎裂，混合式最佳。
核心問題¶
用 LLM 從非結構化文本抽取知識圖譜時，面臨根本抉擇：要預先定義實體與關係型別（schema 引導），還是讓 LLM 動態發現（開放域）？作者以 80 萬字的《伊利亞德》全文實測兩種路線的差異與取捨。
關鍵發現 / 數據¶
- 開放域抽取找到 2.1 倍實體（1,828 vs 873）、2.4 倍關係（3,604 vs 1,524），但代價是型別爆炸。
- 實體型別：schema 6 種 vs 開放域 141 種；關係型別：19 種 vs 1,356 種。
- 開放域產生語意冗餘：KILLED(160) 與 KILLS(53) 因時態被當成不同關係；PLACE/LOCATION、GOD/GODDESS/DEITY 各自分裂。
- 引用研究：schema 引導精度更高（G-F1 約 36% vs 開放域 GPT-4 約 30%）；謂語佔抽取錯誤 40.17%。
- Apple ODKE+ 混合法提升 context precision 12–15%；CORE-KG 的型別感知共指消解降低節點重複 28.32%。
方法亮點¶
- 使用 LlamaIndex
PropertyGraphIndex+ FalkorDB；schema 用SchemaLLMPathExtractor（strict Pydantic 驗證），開放域用DynamicLLMPathExtractor。 - 混合式兩階段流程：先開放域發現本體 → 人工精煉 → 套用 schema 引導全量抽取 → 後處理正規化。
- Chunking 建議：開放域需更大 chunk（1,200 token）提供型別推斷脈絡，schema 可用較小 chunk。
對我的研究有用嗎？¶
對 GraphRAG 研究者很實用：清楚示範「語意等價導致 schema 碎裂」這一開放域核心痛點，並以實測數字佐證 schema/open/hybrid 的權衡。混合式「先發現後約束」流程、共指消解降重、chunk 大小對 coreference 的影響，都可直接借鑑於抽取 pipeline 設計。引用的 T2KG、CORE-KG、ODKE+、GraphRAG 也是值得追的參考。
評語¶
值得快讀。實作清晰、數據具體、串接學界研究得宜；但屬部落格層級非嚴謹評測，缺正式 ground truth，引用數字宜回查原文核實。
🌐 中英對照¶
Author: Alexander Shereshevsky
作者：Alexander ShereshevskyPublished:
發布日期：Source: https://medium.com/graph-quill/building-knowledge-graphs-from-homers-iliad-open-domain-vs-schema-guided-extraction-ef0bf3874a33
來源：https://medium.com/graph-quill/building-knowledge-graphs-from-homers-iliad-open-domain-vs-schema-guided-extraction-ef0bf3874a33Fetched: 2026-06-13T01:01:35.535724
擷取時間：2026-06-13T01:01:35.535724
Building Knowledge Graphs from Homer's Iliad: Open-Domain vs. Schema-Guided Extraction / 從荷馬的《伊利亞德》建構知識圖譜：開放領域擷取與架構導引擷取的比較¶
Press enter or click to view image in full size
按 Enter 或點擊以檢視完整大小的圖片
A practical comparison of two LLM-powered approaches for transforming ancient epic poetry into queryable knowledge
針對兩種以大型語言模型 (Large Language Model, LLM) 驅動的方法進行實務比較，將古代史詩轉化為可查詢的知識
It started the way many technical experiments do — with a deceptively simple question. I was preparing material for the fifth article in my Knowledge Graphs for Enterprise AI Memory series, and I needed a substantial, complex text to demonstrate knowledge graph extraction at scale. My mind wandered to the bookshelf.
這一切就像許多技術實驗一樣，始於一個看似簡單的問題。當時我正在為「企業 AI 記憶的知識圖譜」(Knowledge Graphs for Enterprise AI Memory) 系列的第五篇文章準備素材，我需要一份份量充足、結構複雜的文本，來示範大規模的知識圖譜 (Knowledge Graph) 擷取。我的思緒飄向了書架。
The Iliad.
《伊利亞德》(The Iliad)。
I hadn't read it since college. So I did what any reasonable person would do: I re-read the entire 800,000-character epic, this time through the lens of entities and relationships. Achilles isn't just a hero — he's a node. His rage isn't just a theme-it's an event that CAUSES other events. Hector's death isn't just a climax — it's a KILLS relationship with attached properties.
從大學以來我就沒再讀過它。所以我做了任何理性的人都會做的事：重新讀完這整部 80 萬字的史詩，但這次是透過實體 (entity) 與關係 (relationship) 的視角。阿基里斯 (Achilles) 不只是個英雄——他是一個節點 (node)。他的憤怒不只是個主題——它是一個會「引發」(CAUSES) 其他事件的事件。赫克托 (Hector) 之死不只是個高潮——它是一個帶有附加屬性的「殺死」(KILLS) 關係。
What emerged from this experiment reveals fundamental truths about how we extract structured knowledge from unstructured text-and the tradeoffs every AI engineer faces when building knowledge graph pipelines.
這個實驗所揭示的，是關於我們如何從非結構化文本中擷取結構化知識的根本真理——以及每位 AI 工程師在建構知識圖譜流程 (pipeline) 時所面對的取捨。
The Core Question: Discover or Define? / 核心問題：發現還是定義？¶
When extracting knowledge graphs from text using LLMs, you face a fundamental architectural decision:
當你使用 LLM 從文本中擷取知識圖譜時，會面臨一個根本性的架構決策：
Schema-guided extraction constrains the LLM to predefined entity types (CHARACTER, DEITY, LOCATION) and relationship types (KILLS, PROTECTS, SON_OF). You tell the model exactly what to look for.
架構導引擷取 (Schema-guided extraction) 將 LLM 限制在預先定義的實體類型（CHARACTER、DEITY、LOCATION）與關係類型（KILLS、PROTECTS、SON_OF）之內。你明確告訴模型該尋找什麼。
Open-domain extraction lets the LLM discover types dynamically. You say "extract entities and relationships" and see what emerges.
開放領域擷取 (Open-domain extraction) 讓 LLM 動態地發現類型。你只說「擷取實體與關係」，然後看看會產生什麼結果。
Both approaches use the same underlying technology-LlamaIndex's PropertyGraphIndex but they produce dramatically different results. I ran both against the complete text of Homer's Iliad (Samuel Butler's translation) to see exactly how different.
這兩種方法使用相同的底層技術——LlamaIndex 的 PropertyGraphIndex——但它們產生的結果卻天差地遠。我用荷馬《伊利亞德》的完整文本（Samuel Butler 的譯本）同時執行這兩種方法，以精確了解差異有多大。
The Implementation: LlamaIndex + FalkorDB / 實作方式：LlamaIndex + FalkorDB¶
For both experiments, I used LlamaIndex's PropertyGraphIndex with FalkorDB as the graph store. LlamaIndex emerged from my research as the strongest option for this use case, offering native FalkorDB integration via FalkorDBPropertyGraphStore and flexible extraction patterns.
在這兩項實驗中，我都使用了 LlamaIndex 的 PropertyGraphIndex，並以 FalkorDB 作為圖譜儲存（graph store）。經過我的研究，LlamaIndex 成為這個使用情境下最強的選項，它透過 FalkorDBPropertyGraphStore 提供原生的 FalkorDB 整合，並具備靈活的擷取模式。
Schema-Guided Approach / 架構導引方法¶
The schema-guided extractor uses SchemaLLMPathExtractor with strict Pydantic validation:
架構導引擷取器使用 SchemaLLMPathExtractor，並搭配嚴格的 Pydantic 驗證：
from typing import Literal
from llama_index.core.indices.property_graph import SchemaLLMPathExtractor
# Entity types tailored for epic literature
EntityType = Literal[
"CHARACTER", # Heroes, warriors, kings
"DEITY", # Gods and goddesses
"LOCATION", # Places
"ARMY", # Military forces
"ARTIFACT", # Important objects
"EVENT", # Battles, duels, ceremonies
]
# Relationship types capturing narrative structure
RelationType = Literal[
"ALLIES_WITH", "FIGHTS_AGAINST", "COMMANDS", "SERVES",
"FATHER_OF", "MOTHER_OF", "SON_OF", "DAUGHTER_OF",
"MARRIED_TO", "LOVES", "PROTECTS", "ANGERS",
"KILLS", "WOUNDS", "LOCATED_IN", "RULES_OVER",
"POSSESSES", "PARTICIPATES_IN", "CAUSES",
]
kg_extractor = SchemaLLMPathExtractor(
llm=llm,
possible_entities=EntityType,
possible_relations=RelationType,
strict=True, # Pydantic validation enforces schema
max_triplets_per_chunk=15,
)
The key parameter is strict=True, which ensures that every extracted triple conforms to the defined schema. Invalid types are rejected.
關鍵參數是 strict=True，它確保每一個被擷取出的三元組 (triple) 都符合定義好的架構（schema）。無效的類型會被拒絕。
Open-Domain Approach / 開放領域方法¶
The open-domain extractor uses DynamicLLMPathExtractor with no constraints:
開放領域擷取器使用 DynamicLLMPathExtractor，且沒有任何約束：
from llama_index.core.indices.property_graph import DynamicLLMPathExtractor
kg_extractor = DynamicLLMPathExtractor(
llm=llm,
max_triplets_per_chunk=20, # Allow more since types are unrestricted
num_workers=4,
)
No allowed_entity_types. No allowed_relation_types. The LLM discovers everything from context.
沒有 allowed_entity_types，也沒有 allowed_relation_types。LLM 從上下文中發現所有東西。
The Results: Two Very Different Graphs / 結果：兩個截然不同的圖譜¶
After processing the 807,836-character text through both pipelines, the numbers tell an interesting story:
在透過這兩條流程處理完這份 807,836 字的文本後，數字訴說了一個有趣的故事：
+-----------------+---------------+--------------------+
| Metric | Schema-Guided | Open-Domain |
+-----------------+---------------+--------------------+
| Entity nodes | 873 | 1,828 |
| Relationships | 1,524 | 3,604 |
| Entity types | 6 (defined) | 141 (discovered) |
| Relation types | 19 (defined) | 1,356 (discovered) |
| Processing time | ~7 minutes | ~10 minutes |
+-----------------+---------------+--------------------+
The open-domain extractor found 2.1x more entities and 2.4x more relationships, but across an explosion of 141 entity types versus 6.
開放領域擷取器找出了多 2.1 倍的實體與多 2.4 倍的關係，但代價是實體類型暴增到 141 種，相較之下架構導引方法只有 6 種。
Schema-Guided: Clean and Queryable / 架構導引：乾淨且易於查詢¶
The schema-guided graph produced precisely what we asked for:
架構導引的圖譜精確地產出了我們所要求的東西：
Entity Distribution:
實體分佈：
- CHARACTER: 505 (58%)
- CHARACTER（角色）：505（58%）
- EVENT: 174 (20%)
- EVENT（事件）：174（20%）
- ARTIFACT: 86 (10%)
- ARTIFACT（器物）：86（10%）
- ARMY: 52 (6%)
- ARMY（軍隊）：52（6%）
- LOCATION: 46 (5%)
- LOCATION（地點）：46（5%）
- DEITY: 10 (1%)
- DEITY（神祇）：10（1%）
Top Relationships:
主要關係：
- PARTICIPATES_IN: 288
- PARTICIPATES_IN（參與）：288
- KILLS: 252
- KILLS（殺死）：252
- SON_OF: 144
- SON_OF（是……之子）：144
- ALLIES_WITH: 143
- ALLIES_WITH（與……結盟）：143
- POSSESSES: 123
- POSSESSES（擁有）：123
Open-Domain: Rich but Chaotic / 開放領域：豐富但混亂¶
The open-domain graph reveals the LLM's unconstrained interpretation:
開放領域圖譜揭示了 LLM 不受約束的詮釋：
Top Entity Types (of 141 discovered):
主要實體類型（在 141 種被發現的類型中）：
- PERSON: 557
- PERSON（人物）：557
- OBJECT: 163
- OBJECT（物件）：163
- GROUP: 155
- GROUP（群體）：155
- EVENT: 117
- EVENT（事件）：117
- PLACE: 111
- PLACE（地方）：111
- ACTION: 94
- ACTION（行動）：94
- LOCATION: 50
- LOCATION（地點）：50
- ANIMAL: 46
- ANIMAL（動物）：46
Notice the redundancy: PLACE (111) and LOCATION (50) are separate types. DEITY (33), GODDESS (21), and GOD (15) are all distinct. The LLM discovered meaningful distinctions but also created noise through inconsistent naming.
注意其中的冗餘：PLACE（111）與 LOCATION（50）是各自獨立的類型。DEITY（33）、GODDESS（女神，21）與 GOD（男神，15）也都被視為不同類型。LLM 發現了有意義的區別，但同時也因為命名不一致而製造了雜訊。
Top Relationships (of 1,356 discovered):
主要關係（在 1,356 種被發現的關係中）：
- SON_OF: 173
- SON_OF（是……之子）：173
- KILLED: 160
- KILLED（殺死，過去式）：160
- FATHER_OF: 56
- FATHER_OF（是……之父）：56
- LEADS: 54
- LEADS（率領）：54
- KILLS: 53
- KILLS（殺死，現在式）：53
Wait-both KILLED (160) and KILLS (53)? The LLM used past and present tense as different relationship types. This is the core challenge of open-domain extraction: semantic equivalence creates schema fragmentation.
等等——KILLED（160）和 KILLS（53）兩者都有？LLM 把過去式與現在式當成了不同的關係類型。這正是開放領域擷取的核心挑戰：語意上等價的概念造成了架構的碎片化。
Question 1: Achilles' Ego Network / 問題一：阿基里斯的自我網路¶
The most connected entity in the entire graph is Achilles with 517 connections. Visualizing his ego network-all entities directly connected to him-reveals why he dominates the epic:
整個圖譜中連結最多的實體是阿基里斯，共有 517 個連結。將他的自我網路 (ego network)——也就是所有與他直接相連的實體——視覺化後，便能揭示他為何主宰了整部史詩：
Press enter or click to view image in full size
按 Enter 或點擊以檢視完整大小的圖片
The visualization shows a classic star topology with Achilles at the center. Different edge types radiate outward:
這個視覺化呈現出經典的星狀拓撲 (star topology)，阿基里斯位於中心。不同類型的邊 (edge) 向外輻射：
- Gold edges (KILLS): His 36 victims spread across the graph
- 金色邊（KILLS）：他的 36 名受害者散佈於整個圖譜
- Green edges (SON_OF, FATHER_OF): Family connections to Peleus, Thetis, Neoptolemus
- 綠色邊（SON_OF、FATHER_OF）：與佩琉斯 (Peleus)、忒提斯 (Thetis)、涅俄普托勒摩斯 (Neoptolemus) 的家族連結
- Blue edges (ALLIES_WITH): Patroclus, the Achaeans, fellow Greek heroes
- 藍色邊（ALLIES_WITH）：帕特羅克洛斯 (Patroclus)、阿開亞人 (the Achaeans)、其他希臘英雄夥伴
- Yellow edges (FIGHTS_AGAINST): Hector, the Trojans, Agamemnon (yes, his own commander)
- 黃色邊（FIGHTS_AGAINST）：赫克托、特洛伊人 (the Trojans)、阿伽門農 (Agamemnon)（沒錯，正是他自己的統帥）
This single visualization explains the Iliad's structure: Achilles touches everything. His withdrawal from battle (breaking ALLIES_WITH edges) and return (activating KILLS edges) drives the entire narrative. The knowledge graph makes this architectural truth visible.
這單一張視覺化圖便解釋了《伊利亞德》的結構：阿基里斯牽動著一切。他退出戰局（切斷 ALLIES_WITH 邊）與重返戰場（啟動 KILLS 邊）驅動了整個敘事。知識圖譜讓這個結構上的真相變得可見。
Question 2: The Death Toll Network / 問題二：死亡人數網路¶
The Iliad is fundamentally a war story, and the KILLS relationship captures its violent heart. This network shows all CHARACTER-to-CHARACTER kill relationships:
《伊利亞德》本質上是一個戰爭故事，而 KILLS 關係捕捉了它暴力的核心。這個網路顯示了所有角色對角色 (CHARACTER-to-CHARACTER) 的殺戮關係：
Press enter or click to view image in full size
按 Enter 或點擊以檢視完整大小的圖片
The visualization reveals the asymmetric nature of Homeric combat:
這個視覺化揭示了荷馬式戰鬥的不對稱本質：
Hub Warriors (multiple outgoing KILLS edges):
樞紐戰士（具有多條向外的 KILLS 邊）：
+-----------+------------+
| Killer | Kill Count |
+-----------+------------+
| Achilles | 36 |
| Patroclus | 25 |
| Hector | 22 |
| Diomed | 21 |
| Ulysses | 17 |
| Teucer | 13 |
| Agamemnon | 12 |
| Ajax | 11 |
+-----------+------------+
Structural Insights:
結構性洞察：
The graph has a clear hub-and-spoke structure. A handful of elite warriors (Achilles, Patroclus, Hector, Diomed) form densely connected hubs, while most minor warriors appear only as leaf nodes-victims with a single incoming edge and no outgoing ones.
這個圖譜具有清晰的軸輻 (hub-and-spoke) 結構。少數幾位菁英戰士（阿基里斯、帕特羅克洛斯、赫克托、狄俄墨得斯 (Diomed)）構成了密集連結的樞紐，而大多數次要戰士只以葉節點 (leaf node) 的形式出現——他們是只有一條向內邊、沒有任何向外邊的受害者。
The Greek side shows more distributed killing: multiple heroes contribute significant body counts. The Trojan side concentrates deaths around Hector, reflecting his role as Troy's primary defender.
希臘一方呈現出較為分散的殺戮：多位英雄都貢獻了可觀的死亡人數。特洛伊一方則將死亡集中在赫克托身上，反映出他作為特洛伊主要捍衛者的角色。
Most striking: the graph captures narrative sequence. Patroclus has 25 kills, but also receives an incoming edge from Hector. Hector has 22 kills but receives an incoming edge from Achilles. The kill chain-Patroclus kills many → Hector kills Patroclus → Achilles kills Hector-is visible as a path through the network.
最引人注目的是：這個圖譜捕捉到了敘事的順序。帕特羅克洛斯有 25 次殺敵，但同時也接收到一條來自赫克托的向內邊。赫克托有 22 次殺敵，但接收到一條來自阿基里斯的向內邊。這條殺戮鏈——帕特羅克洛斯殺死眾多敵人 → 赫克托殺死帕特羅克洛斯 → 阿基里斯殺死赫克托——可以在網路中以一條路徑的形式被看見。
Question 3: Core Characters Subgraph / 問題三：核心角色子圖¶
To compare schema-guided versus open-domain extraction quality, we can examine the same five central characters across both graphs:
為了比較架構導引與開放領域擷取的品質，我們可以在兩個圖譜中檢視同樣的五位核心角色：
MATCH (n:CHARACTER)-[r]->(m:CHARACTER)
WHERE n.name IN ['Achilles', 'Hector', 'Agamemnon', 'Patroclus', 'Priam']
AND m.name IN ['Achilles', 'Hector', 'Agamemnon', 'Patroclus', 'Priam']
RETURN n, r, m
Press enter or click to view image in full size
按 Enter 或點擊以檢視完整大小的圖片
Schema-Guided Result:
架構導引的結果：
The subgraph shows clean, consistent relationships:
這個子圖顯示出乾淨、一致的關係：
- Achilles → KILLS → Hector
- 阿基里斯 → KILLS（殺死）→ 赫克托
- Achilles → ALLIES_WITH → Patroclus
- 阿基里斯 → ALLIES_WITH（與……結盟）→ 帕特羅克洛斯
- Hector → KILLS → Patroclus
- 赫克托 → KILLS（殺死）→ 帕特羅克洛斯
- Agamemnon → FIGHTS_AGAINST → Achilles
- 阿伽門農 → FIGHTS_AGAINST（與……對抗）→ 阿基里斯
- Hector → SON_OF → Priam
- 赫克托 → SON_OF（是……之子）→ 普里阿摩斯 (Priam)
- Agamemnon → COMMANDS → Achilles (implicit through army structure)
- 阿伽門農 → COMMANDS（統領）→ 阿基里斯（透過軍隊結構隱含表達）
Each relationship type appears once per semantic meaning. The graph is immediately interpretable.
每種關係類型在每個語意上只出現一次。這個圖譜可以立即被解讀。
Open-Domain Result (same query):
開放領域的結果（相同查詢）：
Press enter or click to view image in full size
按 Enter 或點擊以檢視完整大小的圖片
The subgraph becomes cluttered:
這個子圖變得雜亂無章：
- Achilles → KILLS → Hector
- 阿基里斯 → KILLS（殺死）→ 赫克托
- Achilles → KILLED → Hector (duplicate!)
- 阿基里斯 → KILLED（殺死，過去式）→ 赫克托（重複！）
- Achilles → SLAYS → Hector (triplicate!)
- 阿基里斯 → SLAYS（殺戮）→ 赫克托（三度重複！）
- Achilles → ALLIED_WITH → Patroclus
- 阿基里斯 → ALLIED_WITH（曾與……結盟）→ 帕特羅克洛斯
- Achilles → FRIEND_OF → Patroclus
- 阿基里斯 → FRIEND_OF（是……的朋友）→ 帕特羅克洛斯
- Achilles → COMPANION_OF → Patroclus
- 阿基里斯 → COMPANION_OF（是……的同伴）→ 帕特羅克洛斯
- Agamemnon → QUARRELS_WITH → Achilles
- 阿伽門農 → QUARRELS_WITH（與……爭吵）→ 阿基里斯
- Agamemnon → ANGERED → Achilles
- 阿伽門農 → ANGERED（激怒）→ 阿基里斯
- Agamemnon → THREATENED → Achilles
- 阿伽門農 → THREATENED（威脅）→ 阿基里斯
The open-domain extraction captures nuance (QUARRELS_WITH is more specific than FIGHTS_AGAINST), but at the cost of consistency. Querying "who killed whom" requires knowing all variants: KILLS, KILLED, SLAYS, SLEW, MURDERED.
開放領域擷取捕捉到了細微差異（QUARRELS_WITH 比 FIGHTS_AGAINST 更具體），但代價是一致性。要查詢「誰殺了誰」就必須知道所有的變體：KILLS、KILLED、SLAYS、SLEW、MURDERED。
The Tradeoff:
取捨：
Side-by-side, these subgraphs illustrate the fundamental choice:
並排比較之下，這些子圖闡明了根本性的抉擇：
- Schema-guided: 8 edges, 5 relationship types, immediately queryable
- 架構導引：8 條邊、5 種關係類型，可立即查詢
- Open-domain: 23 edges, 18 relationship types, richer but fragmented
- 開放領域：23 條邊、18 種關係類型，更豐富但較為碎片化
Industry Research Context / 產業研究背景¶
These findings align with broader research on LLM-powered knowledge graph extraction:
這些發現與更廣泛的 LLM 驅動知識圖譜擷取研究相符：
T2KG Benchmark Results / T2KG 基準測試結果¶
The Text-to-Knowledge-Graph (T2KG) benchmarks reveal that schema-guided extraction consistently achieves higher precision. Fine-tuned models with 7-shot examples achieve approximately 36% exact graph match (G-F1), while zero-shot GPT-4 in open-domain mode scores around 30%. The gap comes from inconsistent entity types, exactly what we observed with KILLED vs. KILLS.
文本到知識圖譜 (Text-to-Knowledge-Graph, T2KG) 的基準測試揭示，架構導引擷取始終能達到更高的精確度。使用 7 個範例 (7-shot) 微調過的模型可達到約 36% 的精確圖譜匹配 (exact graph match, G-F1)，而在開放領域模式下零樣本 (zero-shot) 的 GPT-4 大約只得 30%。這個差距來自於不一致的實體類型，正是我們在 KILLED 與 KILLS 之間所觀察到的現象。
Error Distribution Analysis / 錯誤分佈分析¶
Research shows that predicates account for 40.17% of extraction errors, objects for 35.98%, and subjects for 23.85%. Open-domain extraction amplifies predicate errors because the LLM must invent relationship types without guidance. Our observation of 1,356 relationship types (vs. 19 in the schema-guided approach) confirms this finding.
研究顯示，謂語 (predicate) 佔擷取錯誤的 40.17%，受詞 (object) 佔 35.98%，主詞 (subject) 佔 23.85%。開放領域擷取會放大謂語錯誤，因為 LLM 必須在沒有指引的情況下自行發明關係類型。我們觀察到的 1,356 種關係類型（相較於架構導引方法的 19 種）證實了這項發現。
The Hybrid Approach / 混合式方法¶
Apple Research's ODKE+ methodology demonstrates that hybrid approaches improve context precision by 12–15% over pure open-domain extraction. The workflow:
蘋果研究院 (Apple Research) 的 ODKE+ 方法論證明，混合式方法 (hybrid approach) 相較於純粹的開放領域擷取，能將上下文精確度提升 12–15%。其工作流程為：
- Run open-domain discovery on a document sample
- 在文件樣本上執行開放領域探索
- Review and refine the generated ontology
- 審視並精煉所產生的本體論 (ontology)
- Apply the refined schema to guide full extraction
- 套用精煉後的架構來導引完整的擷取
- Post-process for normalization
- 進行後處理以正規化 (normalization)
This matches intuition: let the LLM discover what matters, then constrain it to produce consistent output.
這符合直覺：先讓 LLM 發現重要的東西，再約束它以產生一致的輸出。
Entity Resolution Challenge / 實體解析的挑戰¶
The CORE-KG framework shows that type-aware coreference resolution reduces node duplication by 28.32%. Our open-domain graph likely contains many duplicate entities with different IDs — "Son of Atreus" and "Agamemnon" referring to the same person. Schema-guided extraction mitigates this through type constraints, but doesn't eliminate it.
CORE-KG 框架顯示，類型感知的指代消解 (type-aware coreference resolution) 能減少 28.32% 的節點重複。我們的開放領域圖譜很可能包含許多具有不同 ID 的重複實體——例如「阿特柔斯之子」(Son of Atreus) 與「阿伽門農」指的是同一個人。架構導引擷取透過類型約束來緩解這個問題，但無法完全消除它。
Practical Recommendations / 實務建議¶
Based on this experiment, here's guidance for choosing between approaches:
根據這次實驗，以下是在兩種方法之間做選擇的指引：
Choose Schema-Guided When: / 在以下情況選擇架構導引：¶
- You have domain knowledge (you know what entities matter)
- 你擁有領域知識（你知道哪些實體重要）
- Query patterns are defined in advance
- 查詢模式 (query pattern) 已預先定義好
- Data quality trumps coverage
- 資料品質的重要性勝過涵蓋範圍
- Downstream systems expect consistent types
- 下游系統預期會收到一致的類型
- You need to merge graphs from multiple sources
- 你需要合併來自多個來源的圖譜
Choose Open-Domain When: / 在以下情況選擇開放領域：¶
- You're exploring unknown document types
- 你正在探索未知的文件類型
- Discovery is more important than precision
- 發現比精確度更重要
- You plan to refine the schema based on the results
- 你打算根據結果來精煉架構
- The corpus is small enough for manual review
- 語料庫 (corpus) 夠小，可以人工審查
- You're building a prototype before defining requirements
- 你正在定義需求之前先建構原型 (prototype)
Consider Hybrid When: / 在以下情況考慮混合式：¶
- Processing large document collections
- 處理大型文件集合
- You need both discovery and consistency
- 你同時需要發現性與一致性
- You can afford a two-pass pipeline
- 你能夠負擔兩階段 (two-pass) 的流程
- Domain expertise is limited, but quality matters
- 領域專業知識有限，但品質很重要
The Chunking Decision / 切塊的決策¶
Both pipelines use SentenceSplitter with chunk overlap, but the settings differ:
兩條流程都使用帶有區塊重疊 (chunk overlap) 的 SentenceSplitter，但設定有所不同：
+---------------+---------------+--------------+
| Parameter | Schema-Guided | Open-Domain |
+---------------+---------------+--------------+
| Chunk size | 1,024 tokens | 1,200 tokens |
| Chunk overlap | 128 tokens | 200 tokens |
+---------------+---------------+--------------+
Open-domain extraction benefits from larger chunks because the LLM needs more context to infer entity types correctly. Schema-guided extraction can work with smaller chunks because the type system provides disambiguation.
開放領域擷取能從較大的區塊 (chunk) 中受益，因為 LLM 需要更多上下文才能正確推斷實體類型。架構導引擷取則可以使用較小的區塊運作，因為類型系統本身就提供了消歧 (disambiguation) 的作用。
Research suggests that 1,200-token chunks with 100–200-token overlap offer the best balance for book-length documents. Smaller chunks lose coreference information; larger chunks distract the LLM with irrelevant context.
研究指出，對於書籍長度的文件而言，採用 1,200 個 token 的區塊搭配 100–200 個 token 的重疊能提供最佳平衡。較小的區塊會遺失指代 (coreference) 資訊；較大的區塊則會以無關的上下文分散 LLM 的注意力。
The Human Element / 人文層面¶
The most surprising insight from this experiment wasn't technical-it was literary.
這次實驗中最令人驚訝的洞察並非技術性的——而是文學性的。
Re-reading the Iliad with graph extraction in mind revealed patterns I'd missed as a student. The epic isn't just about Achilles' rage-it's a network of obligations, betrayals, and interventions that propagate through generations. Agamemnon dishonors Achilles (ANGERS), which causes Achilles to withdraw (CAUSES), which leads to Patroclus' death (CAUSES), which triggers Achilles' return (CAUSES), which results in Hector's death (KILLS).
帶著圖譜擷取的思維重讀《伊利亞德》，揭示了我學生時代所錯過的模式。這部史詩不只關乎阿基里斯的憤怒——它是一張由義務、背叛與介入所構成、並跨越世代傳播的網路。阿伽門農羞辱了阿基里斯（ANGERS），這導致阿基里斯退出戰局（CAUSES），進而引致帕特羅克洛斯之死（CAUSES），再觸發阿基里斯的重返戰場（CAUSES），最終造成赫克托之死（KILLS）。
The knowledge graph doesn't just represent the story-it reveals its causal structure.
知識圖譜不只是呈現了故事——它揭示了故事的因果結構。
Homer was building knowledge graphs 2,800 years before we had the term.
早在我們有這個術語的 2,800 年前，荷馬就已經在建構知識圖譜了。
Conclusion: Structure Enables Understanding / 結論：結構使理解成為可能¶
The comparison between open-domain and schema-guided extraction illuminates a fundamental principle of knowledge engineering: structure is not the opposite of discovery-it enables it.
開放領域擷取與架構導引擷取之間的比較，闡明了知識工程 (knowledge engineering) 的一項根本原則：結構並非發現的對立面——它使發現成為可能。
Open-domain extraction with 141 entity types and 1,356 relationship types captures more raw information. But the schema-guided graph with 6 entity types and 19 relationship types tells a clearer story. We can immediately query who killed whom, which gods protect which heroes, and how family relationships drive the narrative.
具有 141 種實體類型與 1,356 種關係類型的開放領域擷取捕捉到了更多原始資訊。但具有 6 種實體類型與 19 種關係類型的架構導引圖譜，卻訴說了一個更清晰的故事。我們可以立即查詢誰殺了誰、哪些神祇保護哪些英雄，以及家族關係如何驅動敘事。
Both approaches have their place. The choice depends on whether you're exploring or producing, discovering or deploying, prototyping or processing at scale.
兩種方法都有各自的用武之地。選擇取決於你是在探索還是在生產、在發現還是在部署、在製作原型還是在大規模處理。
For my money, the hybrid approach offers the best of both worlds: use open-domain to discover what matters, then constrain with schema to extract it consistently. The Iliad deserves both the richness of discovery and the clarity of structure.
依我之見，混合式方法兼具兩者之長：用開放領域去發現重要的東西，再用架構加以約束以求一致地擷取。《伊利亞德》既值得擁有發現的豐富性，也值得擁有結構的清晰性。
And sometimes, the best way to understand a 2,800-year-old text is to turn it into a property graph.
而有時候，理解一部 2,800 年歷史文本的最佳方式，就是把它轉化成一張屬性圖 (property graph)。
Technical Appendix / 技術附錄¶
Tools Used / 使用的工具¶
- LlamaIndex PropertyGraphIndex (May 2024 release)
- LlamaIndex PropertyGraphIndex（2024 年 5 月版本）
- FalkorDB for graph storage
- FalkorDB 用於圖譜儲存
- OpenAI and local LLM models
- OpenAI 與本地端 LLM 模型
Source Text / 來源文本¶
- Homer's Iliad, Samuel Butler translation
- 荷馬《伊利亞德》，Samuel Butler 譯本
- 807,836 characters
- 807,836 個字元
- 24 books
- 24 卷
References / 參考資料¶
Text2KGBench: A Benchmark for Ontology-Driven Knowledge Graph Generation from Text (ISWC 2023)
Text2KGBench：一個用於本體論導向、從文本生成知識圖譜的基準測試（ISWC 2023）
Fine-tuning or Prompting on LLMs: Evaluating Knowledge Graph Construction Task (Frontiers, 2025)
在 LLM 上進行微調還是提示：評估知識圖譜建構任務（Frontiers, 2025）
CORE-KG: An LLM-Driven Knowledge Graph Construction Framework (arXiv 2025)
CORE-KG：一個由 LLM 驅動的知識圖譜建構框架（arXiv 2025）
深入 CORE-KG：評估知識圖譜的結構化提示與指代消解（arXiv 2025）
Microsoft GraphRAG：從局部到全域——一種以查詢為核心的摘要之圖式 RAG 方法（arXiv 2024）
Code Availability / 程式碼取得¶
The complete extraction scripts are available in the GitHub repository accompanying this series.
完整的擷取腳本可在隨附於本系列的 GitHub 儲存庫 中取得。
Questions or implementation war stories? Find me on LinkedIn.
有問題或實作上的甘苦談嗎？在 LinkedIn 上找我吧。
🔤 關鍵術語¶
| 英文 | 繁中譯名 | 文章中的脈絡 / 簡短說明 |
|---|---|---|
| Knowledge Graph | 知識圖譜 | 將非結構化文本轉成由實體（節點）與關係（邊）組成的可查詢結構 |
| Schema-Guided Extraction | 結構綱要導引式抽取 | 限制 LLM 只能使用預先定義好的實體與關係類型來抽取知識 |
| Open-Domain Extraction | 開放域抽取 | 不設限，讓 LLM 從上下文中自行動態發現實體與關係類型 |
| Entity / Node | 實體／節點 | 知識圖譜中代表人事物的基本單位，如 Achilles 是一個節點 |
| Relationship / Triple | 關係／三元組 | 連接實體的邊（如 KILLS），三元組為（主詞-謂詞-受詞）結構 |
| PropertyGraphIndex | 屬性圖索引 | LlamaIndex 用於建構與查詢屬性圖的核心索引元件 |
| SchemaLLMPathExtractor | 綱要式路徑抽取器 | 搭配嚴格 Pydantic 驗證、強制符合預定綱要的抽取器 |
| DynamicLLMPathExtractor | 動態路徑抽取器 | 無類型約束、動態發現所有類型的開放域抽取器 |
| FalkorDB | FalkorDB（圖資料庫） | 本文採用的圖儲存後端，透過 FalkorDBPropertyGraphStore 整合 |
| Pydantic Validation | Pydantic 驗證 | 以 strict=True 強制每個抽取三元組符合綱要，拒絕不合法類型 |
| Schema Fragmentation | 綱要碎片化 | 語意等價卻產生多種類型（KILLS/KILLED/SLAYS）造成的分裂問題 |
| Semantic Equivalence | 語意等價 | 同義但寫法不同的關係，是開放域抽取一致性問題的根源 |
| Ego Network | 自我中心網路 | 某節點與其所有直接相連實體構成的子圖（如 Achilles 的星狀拓樸） |
| Coreference Resolution | 指涉消解 | 辨識「Son of Atreus」與「Agamemnon」指同一人；型別感知可降低重複 |
| Entity Resolution | 實體解析 | 合併指向同一對象的重複實體節點 |
| Chunking / Chunk Overlap | 文本切塊／切塊重疊 | 以 SentenceSplitter 切分長文，重疊區段保留跨塊指涉資訊 |
| Hybrid Approach | 混合式方法 | 先開放域發現再以綱要約束的兩階段管線（如 ODKE+） |
| T2KG Benchmark | 文本轉知識圖譜基準 | 評估 LLM 知識圖譜抽取的基準，顯示綱要式精準度較高 |
| G-F1 (Exact Graph Match) | 圖完全匹配分數 | 衡量抽取圖與標準答案完全一致程度的指標 |
| GraphRAG | 圖譜檢索增強生成 | 結合知識圖譜的 RAG 方法（參考文獻 Microsoft GraphRAG） |
| Ontology | 本體論／本體 | 經審閱精煉後用以導引完整抽取的實體與關係類型定義集 |