kg-gen 實測前評估：把任意文字變成知識圖譜，代價是什麼
[NeurIPS '25] Knowledge Graph Generation from Any Text
秒懂
- 它是什麼？
- kg-gen 用 LiteLLM 串接任意模型，把純文字或對話訊息抽成 entities、edges、relations 三件套，再用 clustering 合併同義詞。這篇談它的資料流、可調參數、以及什麼情況下你根本不該用它。
- 適合誰用？
- 如果你已經有 LLM API 額度，想快速把一批文字或對話紀錄轉成可查詢的三元組，而且能接受每次重建圖譜都要重跑模型，kg-gen 的介面夠短，值得先在 tests/ 目錄的腳本上試一輪。反過來說，需要穩定 schema、可審計血緣、或不想把原文送進第三方端點的情境，這個工具不會替你解決。
- 可以商用嗎？
- 未經許可不行。GitHub 在這個儲存庫中沒有找到授權檔案；沒有授權，預設即「保留所有權利」：你可以閱讀程式碼，但不能重複使用。使用前請看看 README，或先取得作者同意。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 175 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是抽取，不是圖資料庫
多數人第一次看到 kg-gen 會誤以為它是一套圖譜基礎設施。不是。它處理的是最前段那一步：把一段沒有結構的文字，轉成 entities、edges、relations 三個集合。README 的範例把這件事講得很清楚，輸入「Linda is Josh's mother. Ben is Josh's brother. Andrew is Josh's father.」，輸出就是四個實體、三種邊、三條關係。沒有 schema 定義、沒有索引、沒有儲存層。
所以它的目標使用者是兩種人。第一種是正在做 RAG、發現向量檢索抓不準多跳關係的人，想在中間插一層圖。第二種是需要合成圖資料來訓練或測試模型的人。README 開頭列的四個用途基本上就是這兩類的展開。如果你要的是查詢引擎、圖分割、或圖神經網路訓練框架，這一步做完之後還有很長的路。
LiteLLM 與 DSPy 撐起的三段流程
kg-gen 本身不含模型。模型呼叫全部經過 LiteLLM 路由，格式是 {model_provider}/{model_name}，README 給的例子包括 openai/gpt-5、gemini/gemini-2.5-flash、ollama_chat/deepseek-r1:14b。這意味著本地模型與雲端 API 走同一條程式路徑，切換成本只是改一個字串。結構化輸出則交給 DSPy，這是它能把自由文字收斂成固定欄位的關鍵。
generate() 是主入口，吃單一字串或一串 Message 物件。長文本走 chunk_size 參數切塊，範例用 5000 字元。切塊之後若打開 cluster=True，會多做一輪實體與關係的聚類，把 neural nets、neural networks、NN 收進同一個 cluster key。輸出因此多兩個欄位：entity_clusters 與 edge_clusters。
另外兩個方法是 aggregate() 與 cluster()。前者把多次 generate() 的結果併起來，後者單獨對既有圖譜做聚類。README 的範例四示範了這個組合：兩段文字分別生成後合併，Joe 與 Joseph 在聚類後被歸為同一實體。這個設計合理，因為跨文件的別名消解本來就不該綁在單次抽取裡。
從安裝到第一次生成的四行指令
最短路徑是 pip install kg-gen，然後從 kg_gen 匯入 KGGen。建構子吃 model、temperature、api_key 三個參數，temperature 預設 0.0。api_key 可以省略，前提是環境變數已設好，或你用的是本地模型。
想從 repository 開發的話，README 寫的是 clone 後執行 pip install -e '.[dev]'，再從根目錄跑 python tests/test_basic.py 驗證，這支腳本會另外產出 tests/test_basic.html 的視覺化結果。視覺化本身是類別方法 KGGen.visualize(graph, output_path, open_in_browser=True)，可以單獨呼叫。
MCP 這條路徑則是 pip install kg-gen 之後執行 kggen mcp，README 說可搭配 Claude Desktop 或其他 MCP client，細節指向 mcp/ 目錄。若要接自架端點，base_url 參數可以覆寫，範例在 tests/test_custom_api_base.py。這幾個檔案名稱值得先讀，因為 README 對參數的說明就到這裡為止。
聚類是機率性的，不是規則性的
cluster=True 這一步值得單獨拿出來談。它讓模型判斷哪些實體指涉同一件事，輸出是一個 dict，key 是代表詞，value 是成員集合。README 的範例裡，artificial intelligence 底下掛著 AI，machine learning 底下掛著 ML。看起來很乾淨，但這個乾淨來自範例文字本身寫得夠規矩。
真實語料不會這樣。同一份文件裡若同時出現「蘋果」指水果與指公司，聚類結果取決於模型當下的判斷，而 temperature 預設 0.0 只降低隨機性，不保證跨次執行一致。release 列表裡有一項 MINE-deduplication-scikitlearn-vs-faiss，標題顯示團隊比較過兩套去重實作，這說明他們自己也知道這一步是整個流程最不穩的地方。
實務上的意思是：不要把 entity_clusters 直接當成節點表寫進資料庫。先跑一次，人工抽查幾組，再決定要不要用。大型語料上這個步驟的成本也不好估，因為它需要額外的模型呼叫。
什麼時候該改用別的方案
如果你的文本有明確的領域 schema，例如病歷、法律條文、或工業設備日誌，用固定規則或細調過的小模型抽取會比通用 LLM 可靠。kg-gen 的優勢在於不挑文本型態，代價就是它不保證欄位一致性，同一批文件跑兩次可能得到不同的邊標籤措辭。
另一個對照是 spaCy 這類傳統 NLP 工具鏈。差別在方法論：spaCy 靠標註資料訓練出的統計模型做命名實體辨識與依存句法分析，邊的類型由你事先定義，輸出穩定且可重現，但遇到沒有訓練過的實體類型就會漏。kg-gen 反過來，靠 LLM 的常識覆蓋未知領域，代價是每次結果都略有浮動，而且你得付模型費用。
還有一個現實問題：kg-gen 預設把原文送給模型供應商。若文本含個資或合約內容，這條路徑本身就不成立。改用 ollama_chat/ 開頭的本地模型可以繞開，但本地模型的抽取品質要自己驗證，README 沒有提供這方面的對照數據。
維護成本與授權的不確定性
這個 repository 的授權在提供的資料裡沒有標示。這不是小事。要放進商業產品之前，必須自己去 PyPI 頁面與 repository 根目錄確認 LICENSE 檔案，本文無法代替你判斷。
維護面上，專案在 2026 年 3 月仍有推送，近期 release 集中在評估資料集與去重實驗，看得出研究團隊還在活躍。但它的依賴鏈不輕：LiteLLM、DSPy 都是變動頻繁的套件，兩者任何一邊改動 provider 介面或結構化輸出 API，kg-gen 就得跟著調整。升級前建議先跑 tests/ 目錄下的腳本，尤其是 test_basic.py 與 test_custom_api_base.py，確認你的模型字串在新版本下仍能解析。
成本結構上還有一點：這個工具沒有快取層。同一份文本重新生成就是重新呼叫模型。文件量大的話，這筆帳要算進預算，而不是當成一次性支出。
編輯結論
如果你已經有 LLM API 額度，想快速把一批文字或對話紀錄轉成可查詢的三元組，而且能接受每次重建圖譜都要重跑模型，kg-gen 的介面夠短，值得先在 tests/ 目錄的腳本上試一輪。反過來說，需要穩定 schema、可審計血緣、或不想把原文送進第三方端點的情境，這個工具不會替你解決。動手前先確認三件事：專案授權條款（README 未標示，PyPI 頁面與 repository 需自行核對）、你選的模型在 LiteLLM 下的 provider 字串是否正確、以及 cluster 步驟在小樣本上是否真的收斂。最後這點最容易被忽略，因為它直接決定 entities 集合能不能拿去當圖資料庫的節點表。
社群筆記