Paperless-AI：把文件庫變聊天機器人
Paperless-AI 把 Paperless-ngx 變成可聊天的文件庫，結合 RAG、hybrid search、AI 標籤與自架部署，適合大量合約、發票與內部文件。
Paperless-AI 讓 Paperless-ngx 的文件庫能聊天、能自動標籤，也能用 RAG 找出文件裡的答案。
說真的，這東西很實用。Paperless-AI 不是在做花俏 Demo。它是把文件管理系統，直接拉進 AI 工作流。
如果你手上有幾千份發票、合約、信件，人工翻找真的會崩潰。Paperless-ngx 很會存檔，但它不會幫你回答「這份合約的終止條款在哪」。Paperless-AI 就是在補這個洞。
| 項目 | Paperless-AI 做法 | 意義 |
|---|---|---|
| 架構 | Node.js + Express，搭配 Python + FastAPI | 把網頁流程和 AI 運算拆開 |
| 檢索 | Hybrid search，結合 BM25 與 cosine similarity | 關鍵字不同，還是找得到 |
| 向量庫 | ChromaDB | 存 embeddings，做語意查找 |
| 本機狀態 | better-sqlite3 | 設定和處理狀態都放本地 |
| 模型來源 | OpenAI、Azure OpenAI、Ollama | 可選雲端或本機推論 |
這個專案到底在解什麼問題
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
文件系統最常見的痛點，不是存不下。是找不到。你可以把資料塞進伺服器，也可以加上標籤和欄位。但一旦使用者想問「去年那份供應商合約怎麼寫」，搜尋就會卡住。
Paperless-AI 的思路很直接。它不把文件當死檔案。它把文件當資料來源，再接上 AI。這樣一來，文件可以自動分類，也可以被摘要，甚至可以直接對話。
我覺得這種設計比單純加一個聊天框更合理。因為它先處理檢索，再處理回答。模型如果沒有抓到對的段落，講再多都只是亂掰。
- 自動分類新文件
- 抽取自訂欄位
- 對整個文件庫問答
- 可自架，資料不必外流
混合架構才是重點
Paperless-AI 把 Node.js 和 Express 拿來做協調層。Python 和 FastAPI 則負責 AI 任務。這個切法很務實。前端流程、佇列、驗證，和 embeddings、retrieval、模型呼叫，本來就不是同一種工作。
Python 端用 sentence-transformers 做 embeddings，再丟進 ChromaDB。Node.js 端處理登入、文件佇列、EJS 畫面。這樣拆開，維護起來比較不會一團亂。
更重要的是，它不是只靠語意搜尋。它還混了關鍵字檢索。這點很關鍵。因為文件世界很髒，很多內容會有固定名詞、編號、日期，單靠向量相似度常常會漏掉。
“Retrieval-augmented generation is the best way to keep models grounded in your data.” — Harrison Chase
這句是 Harrison Chase 說的。他是 LangChain 的共同創辦人。講白了，Paperless-AI 就是在做這件事：先找對資料，再讓模型回答。
它也支援多種模型來源。你可以接 OpenAI，也可以接 Azure OpenAI，或是用 Ollama 跑本機模型。對有敏感文件的團隊來說，這很重要。
RAG、chunking、hybrid search 在忙什麼
這套系統的核心，不是「把文件丟給模型」。而是先切 chunk，再做索引，再找相關段落。這樣做很土，但有效。因為長文件一多，context 很快就爆掉。
Paperless-AI 還會把既有標籤和 correspondent 塞進 prompt。這個細節很小，但效果很大。模型比較不會自己亂生新分類，導致你的文件夾整個失控。
它也有 token-aware truncation。這是很實際的保護機制。文件太長時，先算 token 再送出，能少掉很多失敗請求。說白了，就是少浪費 API 成本。
- chunking 先縮小內容範圍
- 語意搜尋加關鍵字搜尋，命中率更穩
- 沿用既有標籤，避免分類亂掉
- token 控制，減少 context overflow
跟其他做法比，差在哪
如果只看 Paperless-ngx，它擅長的是存檔、權限、基本搜尋。它不是拿來做文件問答的。你可以說它是文件倉庫，但不是 AI 助理。
如果改用一般雲端 AI 工具，流程會更快，但資料外流風險也更高。很多公司一碰到合約、採購單、內部信件，就不敢把內容直接丟出去。這時候自架方案就有價值。
Paperless-AI 卡在中間，位置很漂亮。它保留原本的文件系統，再補上檢索和聊天。對已經在用 Paperless-ngx 的團隊來說，這比整套重做實際多了。
- Paperless-ngx：強在存檔與 metadata
- Paperless-AI：加上檢索、聊天、標籤
- 雲端 AI 工具：方便，但資料控制較弱
- Ollama 本機部署：較適合敏感文件
這類工具的產業脈絡
文件管理和 AI 的結合，現在已經不是新鮮事。但很多產品都只做半套。不是只有搜尋框，就是只有聊天框。真正有用的方案，通常要同時處理 ingestion、索引、權限、回覆品質。
這也是為什麼 RAG 會一直出現在企業工具裡。因為企業不缺模型。企業缺的是把資料找準的能力。模型本身很會講，但如果上下文錯了，答案也會跟著歪掉。
我覺得 Paperless-AI 的價值，不在於它多炫。它的價值在於它很像真的會被部署的東西。它沒有要求你換掉整個文件流程，只是把 AI 疊上去。
如果你在做內部工具，這個方向很值得參考。先把資料整理好，再讓 AI 接手高摩擦工作。不要反過來。很多團隊就是先追模型，再補資料，最後整個系統都很難維護。
結論：這種文件庫會越來越像知識介面
我猜接下來的文件系統，會把搜尋、標籤、問答放在同一條流程。不是三個功能分開按，而是使用者輸入一句話，系統自己去找、去判斷、去整理。
如果你已經有 Paperless-ngx，下一步不一定是換模型。你更該先問：你的文件能不能被準確檢索，能不能被穩定分類，能不能在不外流的前提下回答問題。這三件事做好，AI 才真的有用。