unstructured：把 PDF、HTML、Word 拆成 LLM 可用的結構化區塊
Convert documents to structured data effortlessly. Unstructured is open-source ETL solution for transforming complex documents into clean, structured formats for language models. Visit our website to learn more about our enterprise grade Platform product for production grade workflows, partitioning, enrichments, chunking and embedding.
秒懂
- 它是什麼？
- 這個 Apache-2.0 授權的 Python 套件把 60 多種檔案格式轉成帶 metadata 的元素串流，供 RAG 前處理使用。它的價值在格式覆蓋率，代價是依賴鏈很重，而且官方真正的產品線在付費平台那一側。
- 適合誰用？
- 如果你要自己組一條 RAG 前處理管線，而且檔案格式雜到不值得逐一寫解析器，unstructured 值得先做一次格式盤點再決定。做法是對你手上每一種副檔名各挑一份最醜的樣本，用 partition 跑一遍，檢查 element 的 category 與 metadata 是否足以支撐你的切塊策略，再決定要不要留。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 HTML（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是文件格式碎片化，不是檢索品質
餵給 LLM 的資料很少長得像訓練語料。真實世界送進來的是掃描 PDF、帶合併儲存格的 Word、滿版表格的 HTML、還有轉寄過三手的 email。每一種格式都有自己的解析器，每一種解析器的輸出結構都不一樣，於是你花在對齊格式上的時間比花在檢索邏輯上還多。unstructured 要處理的就是這一段：README 把它定位成「Open-Source Pre-Processing Tools for Unstructured Data」，把 PDF、HTML、Word 等文件統一轉成結構化輸出。它的目標讀者是正在建 RAG 或資料管線的工程團隊，而不是終端使用者。判斷要不要用它的關鍵，在於你手上到底有幾種格式。三種以內，自己寫解析器通常更快也更好控；十種以上而且還會增加，這個套件的格式覆蓋率才開始產生價值。
partition 把檔案拆成帶 metadata 的元素串流
核心抽象是 element。文件進來之後被拆成一連串元素，每個元素帶 category 與 metadata，而不是一整塊純文字。這個設計的意義在於下游可以按語意邊界切塊，而不是按字元數硬切。文件裡提到的 enrichment、chunking、embedding 屬於同一條處理鏈的後段環節，但它們在開源套件與託管平台之間的歸屬並不清楚，README 主要把這些描述掛在平台產品上。你應該把開源部分理解為「解析與標記」這一層，後續的切塊與向量化要自己接。另外一個容易被忽略的細節：repository 標示的主要語言是 HTML。這通常表示倉庫裡有相當比例的說明文件或測試 fixture，不代表執行邏輯是 HTML。真正的解析邏輯是 Python，套件也是從 PyPI 安裝的。
安裝與最小可用路徑
套件名稱是 unstructured，發佈在 PyPI，README 的 badge 直接連到 pypi.python.org/pypi/unstructured。標準安裝方式是 pip install unstructured。要注意的是這個套件處理 PDF、圖片與掃描件時會用到 OCR 與視覺模型相關的相依套件，這些在 README 裡沒有展開成完整清單，實際安裝時常需要額外補裝系統層級的函式庫。這件事沒有寫在 README 的安裝段落裡，屬於必須自己驗證的部分。MCP 這條路徑的文件相對完整：README 給的步驟是先選一個支援 MCP 的客戶端，例如 Claude Code、Cursor、Codex CLI，再用客戶端的 mcp add 指令或直接改 MCP 設定檔加入 Transform MCP server，第一次連線時完成一次登入授權，之後就能把本機檔案或 URL 交給 agent 處理。這裡的關鍵差異是：MCP 路徑走的是 Unstructured 的託管服務，不是你在本機跑開源套件。兩者混為一談會讓你對成本與資料流向產生錯誤預期。
依賴負擔與解析失敗是主要成本
這類工具最現實的問題不是功能，是安裝體積與版本衝突。文件解析會牽扯到 PDF 渲染、影像處理、機器學習推論等不同領域的套件，它們對 Python 版本與底層函式庫的要求經常互相牽制。README 沒有提供依賴清單或版本矩陣，只給了 PyPI 的 Python 版本 badge，所以升級前你只能自己實測。第二個問題是失敗模式。掃描品質差的 PDF、雙欄排版、跨頁表格，這些在解析階段都可能產生順序錯亂或元素遺漏，而錯誤不會以例外形式炸出來，而是安靜地變成一份看起來正常、內容卻錯位的元素串流。這種錯誤在檢索階段很難察覺，因為向量檢索只會回傳語意相近的片段，不會告訴你段落被切斷了。如果你的資料裡掃描件占比很高，這一點必須優先驗證，不能等到上線後才發現。
和自建解析層的差別在哪裡
最直接的替代方案是自己用各格式的專門套件組一條管線：PDF 用一組、HTML 用一組、docx 用一組，各自輸出再統一成你自訂的 schema。這樣做的優點是依賴可控、除錯路徑清楚、出問題時你知道是哪一層壞掉。代價是格式數量一多，維護成本會線性上升，而且每加一種格式就要重寫一次正規化邏輯。unstructured 走的是相反的路：用一層統一的 element 抽象吸收格式差異，你付出的是依賴鏈的複雜度與對上游維護節奏的依賴，換來的是新增格式時不必改動下游程式碼。這個交換划不划算，取決於你的格式數量會不會繼續成長。還有一個常被忽略的選項是直接用它的託管平台，README 明確把 production grade 的 workflow、partitioning、enrichments、chunking 與 embedding 放在平台產品上。如果你的團隊沒有餘裕維護解析層，這條路徑在工程上更省事，只是資料要離開你的環境。
版本節奏與 Apache-2.0 的實際含義
從 release 記錄看，這個專案在 2026 年 8 月連續發佈了 0.27.0、0.27.1 與 0.27.5，patch 版本在數週內推進多次。這代表上游變動頻繁，你如果鎖定某個版本，要預期升級時可能遇到行為變化；如果跟著升，就要有回歸測試的準備。授權是 Apache-2.0，這是寬鬆授權，允許商業使用與修改，通常也包含專利授權條款。但這裡有一個必須分清楚的界線：Apache-2.0 涵蓋的是這個開源 repository，不涵蓋 Unstructured 的託管平台服務。README 大量篇幅在推廣平台產品，兩者的授權與商業條件是分開的。另外，套件本身是寬鬆授權，但它依賴的某些模型或元件可能有各自的授權條件，這部分 README 沒有交代，採用前需要自行確認。以上不是法律意見，涉及商業部署請找專業人士確認。
什麼情況下它會變成錯的工具
第一種情況是格式單一。如果你的來源全部是結構良好的 HTML 或純文字，用這個套件等於為了通用性付出依賴成本卻拿不到對應好處。第二種情況是你需要嚴格的可重現性。文件解析涉及模型推論時，同一份輸入在不同版本之間產生不同切分結果是可能的，而 README 沒有提供任何關於穩定性的承諾。第三種情況是資料不能離開你的環境，但你又不打算自架整套依賴，這時候開源與託管兩條路都不順。最後一種，也是最常見的誤判：把 unstructured 當成檢索品質的解法。它只負責把文件變成結構化元素，切塊策略、嵌入模型、檢索排序全都不在它的範圍內。前處理做得好，只是讓後面的檢索有機會做對，不會自動讓結果變準。
編輯結論
如果你要自己組一條 RAG 前處理管線，而且檔案格式雜到不值得逐一寫解析器，unstructured 值得先做一次格式盤點再決定。做法是對你手上每一種副檔名各挑一份最醜的樣本，用 partition 跑一遍，檢查 element 的 category 與 metadata 是否足以支撐你的切塊策略，再決定要不要留。反過來說，如果你的來源只有乾淨的純文字或單一格式，或你需要的是穩定的託管服務而非自架依賴，這個套件會讓你付出不必要的安裝與升級成本，應該直接跳過。決定採用前務必確認兩件事：你的 Python 版本是否落在 PyPI 標示的支援範圍內，以及授權條款對你打算部署的方式是否成立。
社群筆記