paperless-gpt 評測：用 LLM 重新定義紙本文件的 OCR 與分類流程
Use LLMs and LLM Vision (OCR) to handle paperless-ngx - Document Digitalization powered by AI
秒懂
- 它是什麼？
- paperless-gpt 是一個與 paperless-ngx 搭配的開源工具，利用 OpenAI、Ollama 或 Google 與 Azure 的 OCR 服務，自動產生文件標題、標籤、往來對象與自訂欄位。本文基於其 README 與版本紀錄，分析它的運作機制、部署方式與實際限制。
- 適合誰用？
- 若你已經使用 paperless-ngx，且手上經常有傾斜、低畫質或手寫的掃描檔，希望省下手動命名與分類的時間，paperless-gpt 值得一試。它特別適合願意自行架設 Ollama 以保護隱私的使用者，因為 qwen3:8b 這類推理模型在 README 中被明確推薦為隱私與效能的平衡點。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是 paperless-ngx 使用者的分類痛點
paperless-ngx 本身是一套文件管理系統，但它仰賴傳統 OCR 與人工命名。使用者掃描一堆帳單或合約後，得手動輸入標題、挑選標籤、決定往來對象。paperless-gpt 的定位就是補上這個環節。它不取代 paperless-ngx，而是與之並肩運作，用 LLM 產生文件標題與標籤，並用 LLM 視覺模型強化 OCR。目標使用者很明確：已經用 paperless-ngx 管理紙本文件，但不想花時間在整理 metadata 的人。這個工具假設你的文件量夠大，大到自動化命名能省下可觀時間。若你只有偶爾幾張掃描，手動處理可能還比較快。
OCR 的實際機制：影像轉文字，再產生文字圖層
paperless-gpt 的 OCR 不是傳統的 Tesseract 流程，而是把圖片交給支援視覺的 LLM，請它描述或轉錄內容。根據 README，它支援四種 OCR 提供者：OpenAI、Ollama、Google Document AI、Azure Document Intelligence，以及自架的 Docling Server。處理模式有三種：Image Mode 處理單張圖片，PDF Mode 逐頁處理，Whole PDF Mode 則把整個 PDF 一次交給模型。後者可能較適合文件頁數少且上下文連續的掃描，但對長文件可能超過模型輸入限制。辨識完成後，工具能產生帶透明文字圖層的 PDF，文字層會精準定位在每個字詞上，讓文件在 paperless-ngx 中可搜尋、可選取。這表示 OCR 結果不只是 metadata，而是實質嵌入 PDF 內容。
自動產生的不只是標題，還有標籤、往來對象與自訂欄位
除了 OCR，paperless-gpt 會根據文件內容產生建議的標題、標籤、建立日期與往來對象（correspondent）。最需要留意的是自訂欄位功能。它必須在設定中啟用，且至少要選一個目標欄位。寫入模式有三種：Append 只新增文件上不存在的欄位，絕不覆寫任何既有值，即使該值為空；Update 會新增欄位並覆寫有建議值的既有欄位，但沒有建議的欄位則保留；Replace 會刪除文件上所有自訂欄位，再用建議值完全取代。Replace 模式風險最高，若 AI 誤判，可能清空你原本維護的欄位。Append 最安全，但可能留下重複或空泛的資料。這個設計顯示開發者意識到自動寫入的破壞性，因此提供保守到激進的光譜。
部署方式：環境變數與 Docker Compose
README 強調簡單的 Docker 部署，只需幾個環境變數。實際安裝可以透過 Docker Compose 把 paperless-gpt 與 paperless-ngx 放在同一個 compose 檔。你必須設定連到 paperless-ngx 的 API 位址與 token，以及選擇的 OCR 提供者憑證。若使用 Ollama，則要指定 Ollama 的端點與模型名稱。設定完成後，工具會提供一個統一的 Web UI，讓你在手動模式中審核 AI 建議，或讓自動處理處理大部分文件，只留下邊緣案例給你。自動處理的流程大概是：工具偵測到 paperless-ngx 中新進的文件，執行 OCR，產生建議，然後根據你的設定套用。手動模式則是把建議排入佇列，等你在 Web UI 上確認。
自訂提示詞與安全機制：如何避免 AI 亂搞
所有 AI 提示詞，包括標題、標籤、往來對象的生成，都可以在 Web UI 的 Settings 選單中調整。README 提到它使用安全的 default_prompts 與 prompts 目錄結構，確保你的修改能持久保存，不會被更新覆蓋。這對實際使用很重要，因為每個人的文件類型不同，預設提示詞可能不適合你的發票或合約。另外，README 列有 Safety Features 與 Usage Recommendations，暗示開發者知道 AI 可能出錯。例如，若文件已有 OCR 文字層，工具可能偵測到並略過重新 OCR，避免浪費 API 額度。但關於這些安全功能的細節，README 被截斷，無法確認具體行為。
真正的限制：依賴外部服務與模型品質
paperless-gpt 的效能完全取決於你選的 LLM 或 OCR 服務。若用 OpenAI 或 Azure，每次處理都有 API 成本，大量文件會累積可觀費用。若用 Ollama 自架，則需要足夠的 GPU 或 NPU。README 推薦 qwen3:8b 作為隱私與效能的平衡，但也明說更大的模型會提升體驗，這暗示 8b 模型在複雜掃描上可能不夠準確。另一個限制是 metadata 複製的限制。當工具產生新的 PDF 文字圖層並上傳到 paperless-ngx 時，原始文件的某些 metadata 可能無法完整複製。README 有 Metadata Copying Limitations 一節，但細節被截斷。這表示你不能假設上傳後的 PDF 會保留所有原始屬性。此外，這個工具只處理進入 paperless-ngx 的文件，不適合需要即時 OCR 的獨立工作流程。
替代方案與定位差異
最直接的替代方案是 paperless-ngx 內建的 OCR，它使用 Tesseract，完全免費、離線，但對傾斜或低畫質掃描的準確度較差。另一個替代是 docling，它是一個自架的 OCR 與文件轉換服務，paperless-gpt 甚至可以把它當作 OCR 提供者。這顯示 paperless-gpt 的定位不是取代 OCR 引擎，而是把不同 OCR 引擎整合進 paperless-ngx 的 metadata 工作流程。如果你只需要 OCR 文字，不需要 AI 標題與標籤，那麼直接用 paperless-ngx 的內建功能或 docling 就夠了。若你追求的是「AI 理解文件內容後自動分類」，那 paperless-gpt 的提示詞與自訂欄位機制是其他工具少見的。
維護成本與授權
專案以 MIT 授權釋出，意味著你可以自由修改與商用，但沒有保證。最後一次主要版本 v0.27.0 在 2026 年 7 月釋出，名為 The Clarity Expansion，顯示專案仍在積極開發。v0.26.x 的 Resilience Expansion 與 Patch Release 則暗示開發者重視穩定性修補。使用上，你需要維護的不只是這個工具本身，還有與之搭配的 AI 服務。若使用 Ollama，你得管理模型更新與硬體資源。若使用雲端服務，你得追蹤 API 價格變動。升級 paperless-gpt 時，要注意提示詞目錄結構是否改變，因為你的自訂提示詞存放在 prompts 目錄，而更新可能影響預設值。建議在升級後先檢查 Web UI 中的提示詞是否仍符合你的需求。
編輯結論
若你已經使用 paperless-ngx，且手上經常有傾斜、低畫質或手寫的掃描檔，希望省下手動命名與分類的時間，paperless-gpt 值得一試。它特別適合願意自行架設 Ollama 以保護隱私的使用者，因為 qwen3:8b 這類推理模型在 README 中被明確推薦為隱私與效能的平衡點。反之，如果你的文件全部是清晰的印刷體，且你只想要傳統 OCR 的全文檢索，不需要 AI 命名與標籤，那麼這個工具會帶來多餘的複雜度。採用前你必須先驗證三件事：第一，你的 paperless-ngx API token 權限是否足夠讓工具寫入文件與上傳 PDF；第二，你所選的 OCR 提供者（OpenAI、Ollama、Google 或 Azure）對你的掃描品質的實際辨識結果；第三，自訂欄位的寫入模式（Append、Update、Replace）是否符合你的資料整理習慣，因為 Replace 模式會刪除文件上所有既有自訂欄位。根據 README 的建議，先在小量文件上測試，再全面啟用自動處理。
社群筆記