synthetic-data-generator：從元資料到十億列資料的合成資料框架評估
SDG is a specialized framework designed to generate high-quality structured tabular data.
秒懂
- 它是什麼？
- 本文檢視 hitsz-ids 的 synthetic-data-generator（SDG），一個以 Python 撰寫、Apache-2.0 授權的表格資料合成框架。它涵蓋 CTGAN、GaussianCopula 與 LLM 模型，並內建資料處理器與中繼資料系統，適合需要合成資料但對記憶體用量敏感的工程團隊。
- 適合誰用？
- SDG 適合需要處理大型表格資料、且重視記憶體控制的團隊，尤其是當你打算用 CTGAN 訓練數百萬列資料，或想利用 LLM 從中繼資料直接生成資料時。它不適合需要成熟多表關聯生成、或依賴豐富生態系與穩定 API 的專案，因為其文件與版本演進仍屬早期，0.2.x 的 API 可能變動。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 15 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
為何需要另一個合成資料框架
合成資料不是新概念，但多數框架在處理大型表格時會碰到記憶體牆。SDG 的出發點很明確：讓 CTGAN 能訓練十億級別的資料，同時保持輸出品質。這不是行銷語言，而是從其 benchmarks 對 SDV 的比較可以看出，團隊宣稱 SDG 在相同任務下消耗更少記憶體且避免訓練中崩潰。對工程師而言，這代表一個實際痛點：當你有一張數百萬列的使用者行為表，傳統 GAN 實作往往會因批次處理或資料預載而耗盡 RAM。SDG 的目標族群是那些需要合成資料來做模型訓練、系統測試或資料共享，但原始資料規模超出單機記憶體容量的團隊。它同時也服務另一個需求：當你完全沒有訓練資料，只有中繼資料（欄位名稱、型態、關聯）時，仍能生成合成資料，這正是 LLM 整合的賣點。
架構拆解：資料處理器、中繼資料與模型層
從 README 的敘述與 repository 結構可以看出，SDG 分成三個主要層次。首先是 sdgx.data_models.metadata，它負責描述單表與多表的結構，並支援自動推斷資料型態。這個中繼資料不只是欄位清單，它還能記錄欄位之間的關聯，這在後續的 GaussianCopula 模型中用來提升合成品質。第二層是 Data Processor，這是一個可插拔的預處理與後處理系統。它的作用是將原始資料轉換成模型可接受的格式，例如把 Datetime 欄位轉成數值，避免模型把它當作離散類別。生成之後，它再把輸出轉回原始格式。這解決了一個常見的合成資料問題：模型對日期或時間的處理往往粗糙，導致合成結果失真。第三層是模型本身，包括 CTGAN、GaussianCopula，以及單表 GPT 模型。三層之間透過中繼資料串接，讓使用者可以只定義結構，不必手動處理每個欄位的轉換。
LLM 整合：沒有資料也能生成
SDG 最特別的設計是 sdgx.models.LLM.single_table.gpt.SingleTableGPTModel。這個模型允許兩種用法：第一種是基於中繼資料生成合成資料，完全不需要訓練資料。第二種是「Off-Table Inference」，從表格之外的資訊推斷特徵，例如從欄位名稱或外部描述來補齊資料。這背後的機制是讓 LLM 理解表格的語意，而非只是統計分布。傳統 GAN 或統計模型只能從既有資料學習，無法處理從未出現的類別或欄位。LLM 的優勢在於它可以利用預訓練知識來填補空缺。但這也帶來限制：LLM 的輸出品質高度依賴中繼資料的完整度與描述的精確度。如果欄位名稱模糊或型態定義不清，生成的資料可能語意正確但數值分布不合理。另外，執行 LLM 需要外部 API 或本地模型，這會增加成本與延遲，不像 CTGAN 可以完全在本地 GPU 上執行。
實際安裝與基本用法
SDG 以 Python 套件 sdgx 發布，支援的 Python 版本可從 PyPI 標籤得知，但 README 未列出明確版本範圍。安裝方式是標準的 pip install sdgx，這可以從套件名稱推斷。使用上，你需要先建立一個中繼資料物件，描述你的表格結構。例如，你可以用 sdgx.data_models.metadata 來定義欄位名稱與型態，或讓它自動推斷。接著，選擇一個模型，例如 CTGAN 或 GaussianCopula，然後將資料與中繼資料餵入訓練。Data Processor 會在背後處理型態轉換。以 GaussianCopula 為例，團隊在 2024 年 11 月整合該模型時，特別強調了對離散資料的記憶體最佳化，讓數千個類別項目也能在 2C4G（雙核 4GB）的環境下訓練。這表示你不需要高階工作站就能跑基本的統計模型。但 CTGAN 這種深度學習模型仍然需要 GPU 或較大的 CPU 記憶體，尤其是處理大型資料時。
記憶體最佳化的具體手段
SDG 對記憶體的控制是其最值得注意的技術特點。從新聞與 benchmarks 的敘述來看，團隊在 CTGAN 實作上做了特別處理，使其能處理十億級資料。一般 CTGAN 實作會將整個訓練集載入記憶體，這在大型資料上不可行。SDG 的做法可能是分批載入或使用延遲資料迭代，但 README 沒有揭露細節。我們只能從結果推斷：它宣稱比 SDV 消耗更少記憶體且避免崩潰。另外，GaussianCopula 的離散資料處理也被特別最佳化，這暗示他們對類別編碼或相關性矩陣的儲存方式做了改進。對工程師而言，這意味著你可以在較小的機器上執行，但你需要自己驗證實際的記憶體峰值，因為文件沒有提供具體的 benchmark 數字。
真正的限制與不適用的場景
SDG 的文件仍然偏薄，這是它最明顯的限制。README 提供了概念與連結，但缺乏完整的 API 參考與錯誤處理指南。如果你遇到資料型態轉換失敗或模型不收斂，除錯的依據不多。另外，多表生成雖然在中繼資料層被提及，但模型層的支援似乎仍以單表為主，README 的新聞只提到 single_table 的模型與 metadata。如果你的需求是生成具有外鍵關聯的多張表，SDG 可能不是最佳選擇。還有，LLM 整合需要外部服務或大型模型，這對隱私敏感的場景可能造成矛盾：你為了避免資料外洩而生成合成資料，卻又需要將中繼資料或部分資料送到 LLM API。最後，版本更新頻率不高，0.2.4 是 2024 年 12 月釋出，之後沒有後續版本，這可能代表開發放緩或正在重構。
與 SDV 的比較：不同的設計哲學
SDG 在 benchmarks 中直接與 SDV 比較，這是一個明確的參考點。SDV 是一個成熟的合成資料生態系，提供多種模型、多表生成、評估工具與較完整的文件。SDV 的設計偏向易用與整合，而 SDG 則專注於單一目標：在有限記憶體下處理大型資料。SDV 的 CTGAN 實作在大型資料上容易崩潰，這是 SDG 團隊指出的痛點。但 SDV 的優勢在於其 API 穩定、社群廣大、且提供資料品質評估與隱私度量。SDG 則選擇將這些功能拆散，讓使用者自行組合。如果你需要一個開箱即用的解決方案，SDV 可能更合適；如果你的資料規模大到 SDV 無法負荷，SDG 值得嘗試。此外，SDG 的 LLM 整合是 SDV 目前較少著墨的方向，這讓 SDG 在「無資料生成」的場景有獨特位置。
維護成本與授權考量
SDG 採用 Apache-2.0 授權，這對商業使用相對友善，允許修改與再發布，只需保留版權聲明。從 repository 的 CI 與 pre-commit 設定來看，專案有基本的品質控管，但沒有提到長期維護承諾。最後一次 push 是 2026 年 8 月，但這不代表活躍，因為實際的 release 停在 2024 年 12 月。這是一個警訊：如果你採用 SDG，你需要準備自行維護或 fork。升級成本方面，由於版本仍為 0.2.x，API 可能變動，升級時需要檢查 changelog。Data Processor 與 metadata 的設計是為了模組化，理論上可以減少升級的破壞性，但沒有文件保證向後相容。建議在採用前先閱讀 ROADMAP.md 與 CONTRIBUTING.md，了解專案的規劃方向，並在你的環境中測試從 0.2.2 升級到 0.2.4 的相容性。
編輯結論
SDG 適合需要處理大型表格資料、且重視記憶體控制的團隊，尤其是當你打算用 CTGAN 訓練數百萬列資料，或想利用 LLM 從中繼資料直接生成資料時。它不適合需要成熟多表關聯生成、或依賴豐富生態系與穩定 API 的專案，因為其文件與版本演進仍屬早期，0.2.x 的 API 可能變動。採用前應先驗證：你的資料型態（日期、類別、缺失值）能否被 Data Processor 正確轉換，以及你是否能接受以 Python API 為主、缺乏圖形介面的操作方式。若你的需求只是快速產生統計上相似的單表資料，GaussianCopula 已足夠；若需要深度學習模型且資料量不大，SDV 的成熟度可能更佳。最終判斷：SDG 的價值在於其記憶體最佳化與 LLM 整合，但這需要你願意投入時間理解其資料處理管線與模型設定，而非開箱即用。
社群筆記