如何「不要」用 LLM 生成知識圖譜¶
文章資訊
作者：John Joy 日期：2026-06-15
原文標題：How Not to Generate a Knowledge Graph with an LLM
Medium 原連結：https://medium.com/@john.joy77777/how-not-to-generate-a-knowledge-graph-with-an-llm-6968c293a8e9
📝 重點摘要¶
TL;DR¶
LLM 生成的圖譜看似完整，真正價值在於下游任務表現與抽取分數的落差。
核心問題¶
用 LLM 零樣本抽取實體與關係，產出物表面上結構完整、節點邊俱全，卻在真正用來查詢、檢索、推理時失靈。文章以「反面清單」形式，指出建構流程中那些難以察覺、卻決定圖譜可用性的失敗點。
關鍵發現 / 數據¶
- 一旦要求「實體型別」也必須匹配，表面上的實體 recall 可能瞬間掉約一半（span 對、label 錯）。
- 抽取出的邊數常多於人工黃金標準，但能回答的問題卻更少——覆蓋率是虛榮指標。
- 強語義關係（used-for、type-of）模型處理良好；模糊關係（feature-of、evaluated-for、conjunction）幾乎一律塌縮成較易詞彙化的鄰近關係。
- 近兩年幾乎所有 LLM 建構 KG 的改進都靠「多次 pass」（validator、iterator、檢索增強精修），單次 pass 只是下限。
方法亮點¶
- 預先給定緊湊明確的本體（固定實體型別、固定關係集、單行定義），約束輸出 schema，犧牲「創意」換取可查詢性。
- 將「型別正確性」獨立計分，不藏在 extraction F1 裡。
- 對模糊關係用對比式定義約束 prompt，或接受需事後消歧。
- 避免 LLM 同時當「建構者」與「評審」：測試集應來自非 LLM 來源、確定性查詢圖譜、用不讀答案的 matcher 評分。
對我的研究有用嗎？¶
非常切題。對 GraphRAG 研究者，「同時報告抽取分數與下游任務分數、以兩者落差衡量真實可用性」是個很實用的評估框架。型別漂移、關係塌縮、多跳連通性無法組合等失敗模式，正是檢索/推理鏈斷裂的根因，可作為錯誤分析與消融設計的檢查清單。閉環自評的警示也提醒評測設計要打破 LLM 依賴。
評語¶
值得一讀的實務經驗總結，觀點犀利且可操作；但屬經驗性意見文（AI 輔助寫作），缺實證數據與引用，「掉一半 recall」等數字僅為粗估，不宜當定論引用。
🌐 中英對照¶
Author: John Joy 作者：John Joy Published: 發布日期： Source: https://medium.com/@john.joy77777/how-not-to-generate-a-knowledge-graph-with-an-llm-6968c293a8e9 來源：https://medium.com/@john.joy77777/how-not-to-generate-a-knowledge-graph-with-an-llm-6968c293a8e9 Fetched: 2026-06-15T21:30:48.618310 擷取時間：2026-06-15T21:30:48.618310
How Not to Generate a Knowledge Graph with an LLM / 如何不用大型語言模型生成知識圖譜¶
Press enter or click to view image in full size
按下 Enter 或點擊以檢視完整大小的圖片
Photo by GuerrillaBuzz on Unsplash
照片由 GuerrillaBuzz 拍攝，來自 Unsplash
There is a moment, somewhere around the third demo, when generating a knowledge graph with a language model stops feeling like magic. The model still produces entities. It still produces relations. The output still looks structured. But you start noticing that when you ask the graph to do something — answer a question, support a lookup, drive a retrieval — it doesn’t quite hold up.
大約到了第三次示範的某個時刻，用語言模型 (Language Model) 生成知識圖譜 (Knowledge Graph) 便不再像是魔法。模型依然會產出實體 (entity)，依然會產出關係 (relation)，輸出看起來也依然具有結構。但你開始注意到，當你要求這個圖譜去做某件事——回答問題、支援查找、驅動檢索 (retrieval)——它就有點撐不住了。
I’m not claiming here that LLMs can't handle complex tasks, and very clearly they can. They are plausibly good that failures are hard to detect from everything generated. In terms of the knowledge graph construction, this will work as a guide to check for failures in your pipeline.
我在這裡並不是要主張大型語言模型 (LLM) 無法處理複雜任務——它們顯然辦得到。它們之所以「貌似」很厲害，是因為要從它們生成的所有內容中察覺失敗其實相當困難。就知識圖譜建構而言，這篇文章可以作為一份指南，用來檢查你管線 (pipeline) 中的各種失敗。
Don’t let the model invent the ontology on the go / 別讓模型隨手即興發明本體論¶
Press enter or click to view image in full size
按下 Enter 或點擊以檢視完整大小的圖片
Photo by Angela Loria on Unsplash
照片由 Angela Loria 拍攝，來自 Unsplash
The cheapest way to ruin a knowledge graph is to ask, in the prompt, for “the entities and relations.” Without a fixed schema, the LLM picks its own types and its own relation names — and it picks differently from one document to the next. The same concept gets tagged three different ways across a corpus. New relation labels appear mid-run. By the time you’ve extracted from a thousand abstracts, you don’t have a graph; you have a thousand small ones that happen to share a file.
毀掉一個知識圖譜最廉價的方法，就是在提示詞 (prompt) 裡只要求「實體和關係」。在沒有固定綱要 (schema) 的情況下，大型語言模型會自行挑選類型、自行挑選關係名稱——而且它在不同文件之間挑得都不一樣。同一個概念在整個語料庫 (corpus) 中會被標註成三種不同的方式。執行到一半還會冒出新的關係標籤。等到你從一千篇摘要中抽取完畢時，你手上並沒有一個圖譜；你有的是一千個剛好共用一個檔案的小圖譜。
Hand the model a tight, explicit ontology: a small list of entity types, a fixed relation set, one-line definitions for each. Constrain the output schema. Yes, it makes the model less “creative.” That’s the point. A graph you can query is a graph the model wasn’t allowed to free-style. Everything else in this post assumes you’ve done this; if you haven’t, none of the metrics below means anything because there’s no consistent vocabulary to score against.
給模型一份嚴謹、明確的本體論 (ontology)：一份簡短的實體類型清單、一組固定的關係集合，以及每一項的一行定義。約束輸出的綱要。沒錯，這會讓模型變得比較不「有創意」。這正是重點所在。一個你能查詢的圖譜，正是一個不被允許即興發揮的圖譜。這篇文章後面的一切都假設你已經做到了這一點；如果你還沒做到，下面所有的指標 (metric) 都毫無意義，因為根本沒有一套一致的詞彙可供評分。
Don’t grade the graph by how big it is / 別用圖譜的大小來評分¶
Press enter or click to view image in full size
按下 Enter 或點擊以檢視完整大小的圖片
Photo by Mika Baumeister on Unsplash
照片由 Mika Baumeister 拍攝，來自 Unsplash
The first instinct, after running zero-shot extraction over a corpus, is to count edges. The number is reassuring. It is often larger than a hand-curated reference would give you for the same text. People mistake that for thoroughness.
在語料庫上跑完零樣本 (zero-shot) 抽取之後，第一個直覺就是去數邊 (edge) 的數量。這個數字讓人安心。對於同樣的文本，它往往比人工精選的參考標準所給出的數量更大。人們誤以為這代表完整周全。
It isn’t. A graph can contain more relationships than the gold standard and still answer fewer questions. Surplus extractions tend to be noisy, mistyped, or weakly grounded — the kind of edges that don’t connect to anything useful when you query them. Coverage is a vanity metric. Treat it as one.
並非如此。一個圖譜可以包含比黃金標準 (gold standard) 更多的關係，卻仍然能回答更少的問題。多出來的抽取結果往往是雜訊、類型標錯，或是依據薄弱——這類邊在你查詢時並不會連結到任何有用的東西。覆蓋率 (coverage) 是一個虛榮指標 (vanity metric)。請把它當成虛榮指標看待。
Don’t trust extraction F1 to predict downstream behaviour / 別相信抽取的 F1 能預測下游行為¶
Press enter or click to view image in full size
按下 Enter 或點擊以檢視完整大小的圖片
Photo by Compagnons on Unsplash
照片由 Compagnons 拍攝，來自 Unsplash
Extraction metrics — precision, recall, F1 over triples — measure whether the LLM produced spans and relations that overlap with a reference. They do not measure whether the resulting graph supports the tasks you actually care about.
抽取指標——精確率 (precision)、召回率 (recall)、針對三元組 (triple) 的 F1——衡量的是大型語言模型所產出的文字片段 (span) 和關係是否與參考標準有所重疊。它們衡量的並不是最終產生的圖譜是否能支援你真正在意的那些任務。
The interesting reading is the gap between the extraction F1 and the downstream task accuracy. A small gap means the extraction quality is your ceiling. A large gap means the extraction looks fine and the failures live somewhere else — usually in type assignments or relation semantics. If you only ever report extraction F1, you will optimise the easy half of the problem and ignore the hard one.
值得玩味的解讀，是抽取 F1 與下游任務 (downstream task) 準確率之間的落差。落差小，代表抽取品質就是你的天花板。落差大，代表抽取看起來沒問題，而失敗藏在別的地方——通常是在類型指派或關係語義 (semantics) 之中。如果你永遠只回報抽取 F1，你就只會去最佳化問題中容易的那一半，而忽略困難的那一半。
Don’t conflate “got the span” with “got the entity” / 別把「抓對片段」和「抓對實體」混為一談¶
Press enter or click to view image in full size
按下 Enter 或點擊以檢視完整大小的圖片
Photo by Arturo Añez on Unsplash
照片由 Arturo Añez 拍攝，來自 Unsplash
This is the failure mode that surprised me the most. LLMs are quite good at recovering the right surface form from text — they pull out the entity, often with phrasing that fuzzy-matches the reference. They are noticeably worse at deciding what kind of thing the entity is.
這是最令我意外的一種失敗模式 (failure mode)。大型語言模型相當擅長從文本中還原正確的表面形式 (surface form)——它們會把實體抽出來，而且措辭往往能與參考標準做模糊比對 (fuzzy match)。它們明顯較不擅長的，是判斷這個實體究竟是哪一種東西。
You can lose roughly half of your apparent entity recall the moment you require the entity type to match. The span looks right; the label is wrong; the downstream query that filters by type quietly returns nothing. If your ontology has overlapping-but-distinct categories (“method” vs “task,” “metric” vs “evaluation target”), the model collapses them. Score typing as its own metric, not as a hidden component of “extraction.”
只要你一要求實體類型也必須匹配，你表面上的實體召回率大約就會掉掉一半。片段看起來對；標籤卻是錯的；那個依類型過濾的下游查詢就悄悄地什麼都沒回傳。如果你的本體論中有彼此重疊但又有所區別的類別（「方法 (method)」對「任務 (task)」、「指標 (metric)」對「評估目標 (evaluation target)」），模型就會把它們混為一團。把類型判定 (typing) 當作一個獨立的指標來評分，而不是把它當成「抽取」之中一個被隱藏起來的成分。
Don’t use semantically ambiguous relation labels without help / 別在沒有輔助的情況下使用語義含糊的關係標籤¶
Press enter or click to view image in full size
按下 Enter 或點擊以檢視完整大小的圖片
Photo by Norbert Kundrak on Unsplash
照片由 Norbert Kundrak 拍攝，來自 Unsplash
Some relations carry strong, unambiguous semantics — “used-for,” “type-of.” Models handle them well. Other relations — “feature-of,” “evaluated-for,” “conjunction,” anything that overlaps with several plausible alternatives — collapse, almost without exception, into whichever neighbour is easier to lexicalise.
有些關係帶有強烈、毫不含糊的語義——「用於 (used-for)」、「屬於某類型 (type-of)」。模型處理得很好。其他關係——「是……的特徵 (feature-of)」、「為……而評估 (evaluated-for)」、「並列 (conjunction)」，任何與多個貌似合理的替代選項相重疊的——幾乎無一例外地，會塌縮成那個比較容易詞彙化 (lexicalise) 的鄰近選項。
The cure is not to invent more relations. It’s to either (a) constrain the prompt with explicit, contrastive definitions or (b) accept that you’ll need post-hoc disambiguation. The worst option is to keep the ambiguous labels and pretend the headline F1 is the whole story. It isn’t — those few relations are where it hides its worst behaviour.
解方不是去發明更多的關係。而是要嘛 (a) 用明確、對比性的定義來約束提示詞，要嘛 (b) 接受你將需要做事後的消歧 (disambiguation)。最糟糕的選項，是保留那些含糊的標籤，並假裝那個頭條的 F1 就是故事的全部。它並不是——那少數幾個關係，正是它把最糟糕的行為藏起來的地方。
Don’t let the LLM be the constructor and the judge / 別讓大型語言模型既當建構者又當裁判¶
Press enter or click to view image in full size
按下 Enter 或點擊以檢視完整大小的圖片
Photo by Mika Baumeister on Unsplash
照片由 Mika Baumeister 拍攝，來自 Unsplash
If you use a language model to extract the graph, then use the same family of models to generate the evaluation questions, then use it again to grade the answers, you have built a closed loop that scores itself. The numbers will look stable. They will not reflect anything about the world.
如果你用一個語言模型來抽取圖譜，然後用同一系列的模型來生成評估問題，接著再用它來為答案評分，那你就建立了一個自我評分的閉迴路 (closed loop)。這些數字看起來會很穩定。它們不會反映任何關於真實世界的事情。
The fix is structural: derive your test set from something the LLM didn’t generate, query the graph deterministically, and grade with a matcher that doesn’t read the answer. Any of those steps left to a model recreates the dependency.
修正方法是結構性的：從某個不是大型語言模型生成的東西來導出你的測試集，以確定性 (deterministic) 的方式查詢圖譜，並用一個不會去讀答案的比對器 (matcher) 來評分。這些步驟中只要有任何一步交給模型去做，都會重新製造出那種依賴關係。
Don’t ship a single pass / 別只交付單次處理的成果¶
Press enter or click to view image in full size
按下 Enter 或點擊以檢視完整大小的圖片
Photo by Jordan Opel on Unsplash
照片由 Jordan Opel 拍攝，來自 Unsplash
Zero-shot prompting in one pass is the demo. It is not the system. Almost every published improvement on LLM-based KG construction in the last two years involves more passes — a validator, an iterator, a retrieval-augmented refinement step. Treat the single-pass graph as the floor. Whatever number it gives you is the worst case for what supervision can buy.
單次處理 (single pass) 的零樣本提示是用來示範的。它不是系統。過去兩年間幾乎所有已發表、針對以大型語言模型為基礎的知識圖譜 (KG) 建構的改進，都牽涉到更多次的處理——一個驗證器 (validator)、一個迭代器 (iterator)、一個檢索增強 (retrieval-augmented) 的精修步驟。把單次處理的圖譜當作下限。它給你的任何數字，都是監督 (supervision) 所能買到的成果中的最差情況。
Don’t measure success by what it looks like / 別用外觀來衡量成功¶
Press enter or click to view image in full size
按下 Enter 或點擊以檢視完整大小的圖片
Photo by Daniel Lerman on Unsplash
照片由 Daniel Lerman 拍攝，來自 Unsplash
This is the cumulative version of everything above. A knowledge graph generated by an LLM looks like a knowledge graph. It has nodes, edges, labels, and types. It serialises to triples. It loads into your store. It survives every visual sanity check.
這是上述所有內容的累積版本。一個由大型語言模型生成的知識圖譜看起來就像一個知識圖譜。它有節點 (node)、邊、標籤和類型。它能序列化 (serialise) 成三元組。它能載入你的儲存庫。它能通過每一項目視的合理性檢查 (sanity check)。
It is failing exactly where you can’t see it: in the connectivity that doesn’t quite compose across hops, the entity types that drift toward generic, the relations that flatten into a handful of confident defaults. None of these shows up in a precision-recall printout. All of them show up the moment a downstream system tries to reason over the graph.
它正是在你看不見的地方失敗：在跨越多跳 (hop) 時無法妥善組合的連通性 (connectivity)、漂移向籠統的實體類型、塌縮成少數幾個自信滿滿的預設值的關係。這些都不會出現在精確率—召回率的列印報表上。而它們全都會在某個下游系統試圖對這個圖譜進行推理 (reason) 的那一刻浮現出來。
The summary / 總結¶
If you take only one habit away from this: report two numbers, not one. Whatever extraction score you usually publish, also publish a downstream-task score. The gap between them is the only honest measurement of how much your LLM-generated graph actually works. Most of the time, the gap is larger than the headline suggests, and most of the engineering you have left to do lives inside it.
如果你只從這篇文章帶走一個習慣：回報兩個數字，而不是一個。無論你平常公布的是哪個抽取分數，也請公布一個下游任務分數。兩者之間的落差，是唯一誠實地衡量你那由大型語言模型生成的圖譜究竟有多管用的方法。大多數時候，這個落差都比頭條數字所暗示的還要大，而你剩下要做的大部分工程，都活在這個落差之中。
Coverage is cheap. Utility is the part that has to be earned.
覆蓋率很廉價。實用性 (utility) 才是必須靠努力去掙得的部分。
Original work with AI Assisted Writing 原創作品，並有 AI 協助寫作
🔤 關鍵術語¶
| 英文 | 繁中譯名 | 文章中的脈絡 / 簡短說明 |
|---|---|---|
| Knowledge Graph (KG) | 知識圖譜 | 全文核心；由 LLM 從文本抽取實體與關係構成的結構化圖譜 |
| LLM (Language Model) | 大型語言模型 | 用來生成知識圖譜的工具；文章探討其在 KG 建構上的失敗模式 |
| Ontology | 本體論／本體架構 | 固定的實體類型與關係定義；作者主張應預先給定，勿讓模型臨時自創 |
| Entity | 實體 | 從文本抽取出的節點（如 method、task、metric） |
| Relation | 關係 | 連結實體的邊（如 used-for、type-of、feature-of） |
| Triple | 三元組 | (主體, 關係, 客體) 的圖譜基本單位；抽取指標據此計算 |
| Schema | 結構綱要 | 約束輸出格式的固定模式；無一致 schema 則指標無意義 |
| Zero-shot Extraction | 零樣本抽取 | 不給範例、單次 prompt 直接抽取；作者視為「下限」而非系統 |
| Extraction F1 | 抽取 F1 分數 | precision/recall/F1 over triples，衡量與參考重疊度，但不預測下游表現 |
| Precision / Recall | 精確率／召回率 | 抽取品質的傳統指標；要求型別匹配時 entity recall 可能腰斬 |
| Gold Standard | 黃金標準（標準答案） | 人工標註的參考圖譜；用於比對抽取結果 |
| Entity Type / Typing | 實體型別／型別標註 | 模型擅長抓 span 卻常標錯型別；應作為獨立指標評估 |
| Surface Form / Span | 表面形式／文字片段 | 實體在文本中的字面呈現；「抓對 span」不等於「抓對 entity」 |
| Relation Semantics | 關係語意 | 語意模糊的關係標籤易塌陷成易詞彙化的鄰近選項 |
| Downstream Task Accuracy | 下游任務準確率 | 圖譜實際支援查詢／問答的能力；應與抽取分數並列回報 |
| Retrieval | 檢索 | 圖譜的實際用途之一；驗證圖譜是否真能驅動查詢 |
| Retrieval-Augmented Refinement | 檢索增強精修 | 多回合 KG 建構中的改進步驟（validator、iterator 等） |
| Coverage (vanity metric) | 覆蓋率（虛榮指標） | 以邊數多寡評斷圖譜；作者批為無意義的虛榮指標 |
| Closed Loop (self-evaluation) | 封閉迴圈（自我評分） | 同族模型既建構又出題又評分，數據穩定卻不反映真實 |
| Disambiguation | 消歧 | 對模糊關係標籤的事後處理手段 |