Hyper-Extract：用一個命令把文件抽成知識圖、超圖與時空圖
Hypergraph is more powerful. Transform unstructured text into structured knowledge with LLMs. Graphs, hypergraphs, and spatio-temporal extractions — with one command.
秒懂
- 它是什麼？
- 這個專案把「非結構化文本轉知識結構」包成一支 CLI，內建 9 種結構、11 種以上抽取引擎與 80 多個 YAML 模板。它的賣點不是模型，而是把模板、增量更新與溯源做進同一條流水線；代價是你要接受 LLM 抽取的召回邊界，以及一個尚未宣告的授權條款。
- 適合誰用？
- 需要把大量文件轉成可查詢知識結構、且願意用 YAML 模板控管抽取口徑的團隊，可以從 he parse 加 he show 這條最小路徑開始驗證；只想做向量檢索、不打算維護 schema 的人則不必引入。動手前先確認三件事：LICENSE 檔案的實際條款內容、你選用的 provider 是否同時提供 LLM 與 embedding、以及 he feed 對既有輸出的更新行為是否符合你對事實回溯的期待。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它想解決的不是抽取，而是抽取之後的維護
多數人寫抽取腳本的順序是這樣：找一個 prompt，呼叫模型，把 JSON 存成檔案，然後在文件更新時重跑一次。第三次重跑之後，你已經不記得哪個節點來自哪份文件，也不知道上一版的結論該不該留。Hyper-Extract 針對的正是這一段。README 把增量演進與溯源列為核心功能，並宣稱餵入更新版本時「old facts roll back automatically」，同時提供 he info --sources 稽核、he remove --document 回滾。這代表它把來源文件當成知識庫的一等公民，而不是用完即丟的輸入。目標讀者是已經在做 RAG 或知識庫、但被版本同步困住的人：研究文件的研究者、要從財報抓公司與高管的分析師、以及必須把資料留在內網的團隊。如果你的文件集是一次性的、之後不再變動，這個專案的溯源機制對你沒有價值。
模板與引擎分離：YAML 決定抽什麼，引擎決定怎麼抽
README 把 80 多個 YAML 模板與 11 種以上抽取引擎分成兩層，這是整個設計的關鍵。模板用路徑表示，例如 general/biography_graph、general/academic_graph、finance/earnings_graph，決定輸出的結構與欄位語意；引擎則是 chunk_rag、GraphRAG、LightRAG、Hyper-RAG、KG-Gen 等實作，決定用什麼方法產生節點與邊。he parse 的 -t 參數吃的是模板路徑，不是引擎名稱。這個切法的好處是換模型或換抽取策略時，下游查詢與匯出不必改；代價是模板與引擎之間存在隱性耦合，README 沒有說明任意模板能否搭配任意引擎，這一點在文件裡查不到，選型時要自己試。chunk_rag 被描述為 zero-cost baseline，適合先確認資料形狀再決定要不要付模型費用。所謂 9 種知識結構，從 chunk 語料、List 一路到 Graph、Hypergraph、Spatio-Temporal Graph，跨度很大：前幾種幾乎只是切塊與列表，後幾種才涉及超邊與時間維度。看到「9 種」時要意識到其中有一部分是樸素結構。
從安裝到第一次查詢的四個命令
安裝走 uv 或 pipx：uv tool install hyperextract，或 pipx install hyperextract。要處理 PDF、Word、PowerPoint、Excel、HTML、EPUB 等格式，需要額外裝 hyperextract[ingest]。設定 provider 有三種典型組合。最省事的是 he config init -p openai -k YOUR_OPENAI_API_KEY，一個 key 同時涵蓋 LLM 與 embedding。想壓成本可以拆開：he config llm -p deepseek -k YOUR_DEEPSEEK_API_KEY 搭配 he config embedder -p openai -k YOUR_OPENAI_API_KEY，README 稱 DeepSeek 是 LLM-only，需搭配 OpenAI 相容的 embedder。完全在地端則是 he config llm -p vllm -u http://localhost:8000/v1 -k dummy -m Qwen/Qwen3.5-9B 與 he config embedder -p vllm -u http://localhost:8001/v1 -k dummy -m BAAI/bge-m3，README 註明本地方案免費但需要 GPU。抽取與查詢是 he parse examples/en/tesla.md -t general/biography_graph -o ./output/ -l en，接著 he search ./output/ "What are Tesla's major achievements?"，視覺化用 he show ./output/。Python API 走 Template.create 與 ka.parse，或用 create_client 指定 llm 與 embedder 字串。
he feed 與來源標籤是這個專案最值得看的部分
增量更新在 CLI 上具體表現為 he feed ./output/ updated-tesla.md --source tesla.md，語意是把新文件掛在同一個來源底下，讓舊事實被取代。來源標籤則是 he tag ./output/ --source tesla.md --add biography，之後用 he search ./output/ "inventions" --tag biography 把檢索範圍限縮到特定來源。這兩個機制合起來，等於把「這條知識從哪來」變成可查詢的維度，而 he info ./output/ --sources 則回答哪些文件貢獻了什麼。從 v0.8.1 的 Scoped Search & Source Tags 到 v0.8.2 的 Source Tags & Scoped Search，兩個相鄰版本名稱幾乎相同，看得出這塊在短期內被反覆調整，介面可能還在收斂。實際使用時要留意：標籤是掛在來源層級，不是節點層級，所以「同一份文件裡只有某一段該被排除」這種粒度需求，靠標籤做不到，得靠 he remove --document 整份移除。
輸出到 Obsidian 之前，先想清楚誰要讀這份圖
he export obsidian ./output/ -o ./vault/ 會產生 Markdown 筆記並以 [[wikilinks]] 互連。這個功能的實際價值取決於你的下游是人還是程式。給人看，Obsidian vault 的瀏覽體驗比 he show 的圖更適合閱讀長文本。給程式用，Markdown 加 wikilinks 不是穩定的資料介面，解析成本反而比直接讀 JSON 高。README 沒有說明匯出時節點命名衝突如何處理，也沒有描述超圖的邊在 Markdown 裡怎麼表示，這在超圖模板下是個明顯的資訊損失點。另一個現實問題是規模：vault 適合數十到數百份文件，累積到數千份時，Obsidian 的圖檢視會變成雜訊。把匯出當成階段性交付物，而不是知識庫的唯一介面，會比較務實。
限制在於抽取本身，而不是工具鏈
這個專案的所有結構都來自 LLM 抽取，所以它的品質上限就是模型在該領域的召回與精度。財報、病歷、法律條文這類術語密集的文本，實體邊界容易切錯，而 README 沒有提供任何評測數據、準確率或人工校驗流程來說明錯誤率落在哪裡。模板能約束輸出欄位，卻不能保證欄位被填對。第二個限制是成本結構：README 提到 DeepSeek 約每頁 0.001 到 0.005 美元，這個數字只涵蓋 LLM 呼叫，沒有計入 embedding 與重跑的次數，而 he feed 的增量更新在文件頻繁變動時會反覆觸發抽取。第三，超圖與時空圖的抽取比一般圖更依賴模型對多元關聯的理解，若你的文本裡關聯本來就稀疏，換成超圖不會無中生有。最後，這個專案不適合當成即時查詢層：它是一條批次流水線，文件進來、知識出去，中間沒有串流處理的設計。
和 LangChain 式組合相比，差別在於誰定義 schema
常見的替代做法是用 LangChain 或 LlamaIndex 自己串 LLM、embedding 與向量庫，抽取邏輯寫在 prompt 與 parser 裡。兩者的差異不在功能清單，而在 schema 由誰定義。自行組合時，schema 散落在程式碼各處，改一個欄位要動多個檔案；Hyper-Extract 把它收斂到 YAML 模板，代價是你被綁在它的模板格式與 CLI 介面上，要脫離就得改寫。另一個實質差異是溯源：自行組合通常要另外設計來源追蹤，而這裡的 he feed、he tag、he info --sources 是內建的。反過來說，如果你的需求只是「把文件切塊、存進向量庫、做相似度檢索」，LangChain 那條路更短，Hyper-Extract 的模板與圖結構都是多餘的抽象。選擇的判準是：你需要的是關聯結構，還是只需要語意相似度。
授權與維護成本要先確認再投入
倉庫標示的 License 是 NOASSERTION，但 README 的徽章與連結指向 Apache 2.0。這兩個訊號不一致，取用前應該直接讀 LICENSE 檔案的內容，而不是依賴徽章。若實際條款與 Apache 2.0 相符，商用與修改的空間較大；若不然，散布與衍生作品的條件可能不同。這不是法律意見，只是提醒這個不一致存在。維護成本方面，從版本節奏可以看出專案仍在快速變動：v0.8.1 到 v0.8.2 相隔一天，v0.9.0 則帶來 Rich Document Ingestion 與 chunk_rag baseline。這種頻率意味著 CLI 參數與模板路徑有調整的可能，把它寫進 CI 或自動化流程時，建議鎖定版本，例如在 uv tool install 時指定版本號，而不是永遠抓最新版。Python 需求是 3.11 以上，這會限制部署環境的選擇。
編輯結論
需要把大量文件轉成可查詢知識結構、且願意用 YAML 模板控管抽取口徑的團隊，可以從 he parse 加 he show 這條最小路徑開始驗證；只想做向量檢索、不打算維護 schema 的人則不必引入。動手前先確認三件事：LICENSE 檔案的實際條款內容、你選用的 provider 是否同時提供 LLM 與 embedding、以及 he feed 對既有輸出的更新行為是否符合你對事實回溯的期待。
社群筆記