GraphGen：用知識圖譜缺口決定要合成哪些 SFT 資料
GraphGen: Enhancing Supervised Fine-Tuning for LLMs with Knowledge-Driven Synthetic Data Generation
秒懂
- 它是什麼？
- GraphGen 先從原始文本建出細粒度知識圖譜，再用期望校準誤差挑出模型真正不會的長尾知識來生成 QA 對。它的價值在選題策略，不在生成速度，代價是整條流程要先付一次圖譜建構的成本。
- 適合誰用？
- GraphGen 適合手上已有一批高品質領域文本、想針對模型長尾知識補資料的團隊，尤其是要接 LLaMA-Factory 或 xtuner 做微調的場景。若你的資料本身品質不穩、或只需要少量通用問答，這條先建圖再生成的路線並不划算。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 30 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
GraphGen 要解的是選題問題，不是生成量問題
合成資料的常見做法是把原文丟給 LLM，要它改寫成問答。這樣生成的題目分佈會跟著原文走，模型已經會的部分被反覆練習，真正不會的長尾知識反而沒被問到。GraphGen 的切入點就在這裡：README 寫明它先從來源文本建構細粒度知識圖譜，再用期望校準誤差（expected calibration error）找出 LLM 的知識缺口，優先產生針對高價值、長尾知識的 QA 對。
目標讀者是做監督微調的工程團隊。README 直接點名生成完的資料可以接 LLaMA-Factory 與 xtuner 訓練，代表它把自己定位在訓練流程的前一段。如果你的瓶頸是「不知道該餵模型什麼」，而不是「資料量不夠」，這個框架才對得上問題。
從文本到圖譜再到 QA 的三段資料流
整條管線可以拆成三段。第一段是圖譜建構，把來源文本轉成知識圖譜，實體與關係是這裡的產物。第二段是缺口定位，用期望校準誤差衡量模型對各節點知識的掌握程度，據此排序生成優先級。第三段是生成，README 提到兩個具體機制：多跳鄰域取樣用來捕捉複雜的關聯資訊，風格控制生成用來讓 QA 資料多樣化。
值得注意的是 2025.12.26 的更新加入了知識圖譜評估指標，涵蓋準確性（實體與關係）、一致性（衝突偵測）與結構穩健性（雜訊、連通性、度分佈）。這意味著圖譜本身被當成可量測的中間產物，而不是生成流程的黑盒副產品。對照之下，直接改寫原文的做法沒有這個中間層，出問題時你很難判斷是抽取錯了還是生成錯了。
2025.12.16 的更新把生成管線改用 ray 重構，並加入 rocksdb 作為鍵值儲存後端、kuzudb 作為圖資料庫後端。這說明資料量成長後，圖譜的存放位置是必須先決定的架構選項，而不是預設就能跑的東西。
安裝與啟動：從 pypi 套件名到 config 與腳本
套件在 PyPI 上的名稱是 graphg，與專案名 GraphGen 不同，這是安裝時第一個容易踩到的點。README 的徽章連到 pypi.org/project/graphg/，因此安裝指令對應的是這個名稱。
生成腳本放在 scripts/generate/ 底下。README 明確給出的例子是視覺問答：執行 bash scripts/generate/generate_vqa.sh。其他模態的腳本命名遵循同一目錄結構，但本文無法從現有材料確認完整清單。
輸入格式方面，2025.10.21 的更新說明可透過 MinerU 支援 PDF 作為輸入，2026.02.04 的更新則加入 HuggingFace Datasets 作為資料來源。設定檔的具體鍵名在提供的材料中沒有列出，只能確定後端是可切換的維度：LLM 客戶端包含 Ollama_client、http_client，本地推論包含 HuggingFace Transformers、SGLang 與 vllm，儲存層包含 rocksdb 與 kuzudb。實際部署前請以官方 cookbook 的設定檔為準，不要憑後端名稱猜鍵名。
搜尋後端也是可選項。2025.07.31 加入 Google、Bing、Wikipedia、UniProt，2025.12.1 再加入 NCBI 與 RNAcentral，後者針對 DNA 與 RNA 資料的抽取。
知識圖譜是前置成本，也是誤差來源
這條路線最大的結構性限制在前置階段。你必須先付一次圖譜建構的成本，才能開始生成資料。如果來源文本本身組織鬆散、術語不一致，抽出的實體與關係會直接影響後續所有 QA 的品質，而且錯誤會沿著管線往下傳。
2025.12.26 加入的圖譜評估指標正視了這個問題：準確性、一致性、結構穩健性都是為了讓你能在生成之前先檢查圖譜。反過來說，如果你的團隊沒有打算做這個檢查，GraphGen 相對直接改寫原文的優勢就會被抵銷。
另一個要留意的點是期望校準誤差需要對模型做評估。這代表流程中有一個環節依賴你指定的 LLM 後端，換後端或換模型都可能改變缺口排序的結果。
還有一種情況不適合用它：你只需要少量通用問答，或領域文本本身品質不穩。此時建圖的工序換不到對應的收益，直接改寫反而更快。
與直接改寫原文的路線差異
最直接的替代做法是把來源文本切塊後交給 LLM 改寫成問答，不建圖、不評估模型缺口。兩者的差別不在生成品質，而在選擇機制：改寫路線的題目分佈由原文結構決定，GraphGen 的題目分佈由期望校準誤差與多跳取樣決定。
GraphGen 另外把預訓練資料增強納入範圍。README 說明它參考 Kimi-K2 技術報告的改寫思路與 ByteDance Seed 的 MGA 框架，加入 rephrase pipeline，用 LLM 驅動的改寫產生同一語料的多樣變體，取代重複餵同一份資料。README 給出的設定是以 Qwen3-0.6B 從零開始在 SlimPajama-6B 上訓練，比較兩輪訓練與加入 Executive-Summary Rephrase 後訓練一輪的結果，涵蓋 ARC-E、ARC-C、HellaSwag、GSM8K、TruthfulQA-MC1 與 MC2 等基準。
這代表 GraphGen 同時覆蓋 SFT 資料與預訓練階段的語料增強，但兩者的管線與評估方式不同，實務上要分開看待。
版本節奏與授權
專案以 Apache-2.0 釋出，預設分支為 main。近期發布的版本包括 v0.1.0.post20250930 與 20250422。從更新紀錄看，2025 年 4 月到 2026 年 4 月之間功能持續增加，範圍涵蓋後端、輸入格式、資料模態與圖譜評估，因此升級時要預期設定檔與相依套件可能變動。
Apache-2.0 允許商業使用與修改，並包含專利授權條款，但這裡不提供法律意見，實際條款請自行確認。
維護成本主要落在兩處：一是 LLM 後端的呼叫費用，整條管線從圖譜建構到生成都會用到；二是圖譜儲存後端的維運，若選 rocksdb 或 kuzudb，就多了一個需要備份與版本管理的元件。若專案同時依賴 MinerU 處理 PDF，該外部工具也構成額外的相依。
2026.04.13 的更新提到基於 GraphGen 的論文 Knowledge-to-Verification 已被 ACL 2026 主會議接收，對應的程式碼在 SeedScientist/K2V。這是研究延伸，與本專案的版本節奏無直接關係。
教育題型與生物資訊抽取是兩個獨立擴充
2026.01.15 的更新讓 LLM benchmark synthesis 支援單選、多選、填空與是非題，README 直接說明這適合教育用途。這與原本的開放式 QA 生成是不同的輸出格式，若你的下游是評測集而非訓練集，這個功能比問答生成更貼近需求。
2025.12.1 加入的 NCBI 與 RNAcentral 搜尋後端，以及 2025.07.31 加入的 UniProt，指向另一個方向：從生物資訊資料庫抽取 DNA、RNA 與蛋白質相關資料。這類來源的資料結構化程度高，圖譜抽取的雜訊相對可控，是這套方法比較容易發揮的場景。
2025.08.14 加入的 Leiden 演算法社群偵測則用於合成 Chain-of-Thought 資料，把圖譜切分成社群後再生成推理鏈。這與單點 QA 生成的機制不同，屬於需要另外驗證的一條支線。
編輯結論
GraphGen 適合手上已有一批高品質領域文本、想針對模型長尾知識補資料的團隊，尤其是要接 LLaMA-Factory 或 xtuner 做微調的場景。若你的資料本身品質不穩、或只需要少量通用問答，這條先建圖再生成的路線並不划算。導入前先確認三件事：graphgen 的 config 是否已指向你實際使用的 LLM 後端與儲存後端（rocksdb 或 kuzudb）、你的領域文本能否穩定抽出實體與關係、以及生成出的 QA 是否真的落在期望校準誤差挑出的高價值區間。
社群筆記