把 ML 嵌进文档柜：paperless-ngx 如何用一台贝叶斯分类器管理十万份文件
2026 年 9 月，paperless-ngx 再次登上 GitHub Trending。这个项目不新——它是 2021 年从 paperless-ng fork 出来的社区维护版——但它代表了一类被低估的 ML 部署模式：ML 不是产品卖点，而是基础设施。它嵌在文档管理的流水线里，用户甚至感觉不到它的存在。
2026 年 9 月，paperless-ngx 再次登上 GitHub Trending。这个项目不新——它是 2021 年从 paperless-ng fork 出来的社区维护版——但它代表了一类被低估的 ML 部署模式：ML 不是产品卖点，而是基础设施。它嵌在文档管理的流水线里，用户甚至感觉不到它的存在。
一个场景：十万份纸质文件的命运
假设你有一柜子纸质文件——银行对账单、税单、保险单、医疗记录、水电费账单、合同。十年攒下来的，大概十万份。
你想把它们数字化。需求很简单： 1. 扫描成 PDF 2. 提取文字（OCR） 3. 自动分类（这是银行、这是税单、这是医疗） 4. 全文搜索
前两步是确定性的——扫描仪扫，OCR 提。第三步是概率性的——一份文件到底是"银行对账单"还是"投资报告"，有时候人都不好分。第四步是工程问题——倒排索引。
paperless-ngx 做的就是把这四步串起来，其中第三步用 ML。
核心机制：OCR + ML 分类 + 全文搜索
paperless-ngx 的流水线长这样：
扫描/PDF → OCR (Tesseract) → 文本提取 → ML 分类 → 元数据 → 数据库 + 全文索引
OCR 层：用 Tesseract 把扫描件和 PDF 里的文字提取出来。支持 100+ 种语言，包括中文。OCR 不是 paperless-ngx 自己做的，它只是封装了 Tesseract。
ML 分类层：这是 paperless-ngx 自己实现的部分。它用三种分类器：
- 对应方分类器——识别文件来自哪个机构（工商银行、平安保险、市一医院）
- 文档类型分类器——识别文件是什么类型（发票、合同、病历）
- 标签分类器——给文件打标签（税务相关、年度报告）
全文搜索层：用 Whoosh（Python 的全文搜索引擎）或 PostgreSQL 的全文搜索功能。OCR 提取的文本被索引，用户可以搜索任何词。
"ML 作为基础设施"的特征
paperless-ngx 的 ML 部署有几个特征，和"AI 产品"截然不同：
1. ML 是手段，不是目的。用户买 paperless-ngx 不是因为"它有 AI"，而是因为"它能管理文档"。ML 分类只是流水线的一环，和 OCR、全文搜索一样。如果 ML 分类不好用，用户可以关掉它，手动分类——功能不残废，只是效率低一点。
2. 模型小、本地跑。朴素贝叶斯模型只有几 KB 到几 MB，不需要 GPU，不需要 API 调用。在树莓派上都能跑。这和现在动辄几十 GB 的 LLM 形成鲜明对比。
3. 用户训练模型。分类器不是预训练好的通用模型，而是用户在使用过程中"训练"出来的。用户手动给一份文件分类，系统学习这个分类模式，下次自动分类。这是"在线学习"——模型随着用户使用越来越准。
4. ML 的失败是可恢复的。如果分类错了，用户改一下就行。不会像 LLM 幻觉那样产生不可预测的输出，最坏情况就是分错类，用户找到它改过来。
这四个特征让 paperless-ngx 的 ML 部署非常"稳"——它不会成为系统的单点故障，不会因为模型升级而出问题，不会因为 API 涨价而不可用。
用户实践：有人关掉分类器，换成 local-AI
但 paperless-ngx 的 ML 分类也有局限。一位用户在博客里写道：
"Paperless-ngx stores documents well and classifies them badly, so I turned off its classifier and put a local-AI layer in front of them."
这位用户的做法是：关掉 paperless-ngx 的内置分类器，在前面加一层本地 LLM（可能是 Ollama + Llama 3），让 LLM 来分类。LLM 理解文档语义的能力比朴素贝叶斯强得多——它能区分"银行对账单"和"投资报告"，即使两者都来自银行、都包含金额。
这个实践揭示了一个张力：嵌入式 ML 的天花板。
paperless-ngx 的朴素贝叶斯分类器在 2021 年是合理选择——那时 LLM 还不普及，本地跑 LLM 不现实。但到了 2026 年，本地 LLM 已经可以在消费级 GPU 上跑，用户开始用更强的 ML 替换嵌入式 ML。
这不是 paperless-ngx 的失败，而是"ML 作为基础设施"的必然命运——当 ML 是基础设施时，它会被更先进的 ML 替换。就像城市的水管会被更好的水管替换一样，但水管本身不是产品的卖点。
和"AI 产品"的对比
| 维度 | paperless-ngx（嵌入式 ML） | AI 产品（如 Claude/GPT） |
|---|---|---|
| ML 角色 | 流水线一环 | 产品核心 |
| 模型大小 | KB-MB | GB-TB |
| 运行环境 | 本地、CPU | 云端、GPU |
| 用户感知 | 几乎无感 | 核心体验 |
| 失败代价 | 分错类，可改 | 幻觉，不可预测 |
| 升级方式 | 用户训练 | 模型迭代 |
paperless-ngx 的文档分类是确定性任务——答案有对错，错了可以改。这种任务用朴素贝叶斯就够了，用 LLM 反而过度。但"理解一份合同的核心条款"是创造性任务——需要语义理解，朴素贝叶斯做不到。
为什么 2026 年还在 Trending
paperless-ngx 不是新项目，为什么 2026 年 9 月还在 Trending？
几个可能的原因：
1. AI 疲劳。用户看多了"AI 产品"，开始重新关注"传统工具"。paperless-ngx 是一个"做实事"的项目——它不吹 AI，但确实用 ML 解决问题。 2. 数据主权意识。随着 AI 公司收集用户数据，越来越多的人开始关注"数据不离开本地"。paperless-ngx 是自托管的，文档不离开你的服务器。 3. LLM 集成可能性。用户发现可以在 paperless-ngx 前面加一层 LLM，让分类更准。这让老项目有了新玩法。 4. 文档数字化需求。疫情后远程办公成为常态，纸质文件数字化的需求持续增长。
这四个原因共同作用，让一个 2021 年的项目在 2026 年还在被关注。
收尾：被低估的"ML 基础设施化"
paperless-ngx 代表了一类被低估的 ML 部署模式：ML 作为基础设施，嵌入到非 AI 产品里，用户甚至感觉不到它的存在。
这种模式在 2026 年的 AI 狂热里显得朴素，但它有几个被低估的优势：
- 可预测：朴素贝叶斯的输出是概率分布，不是黑盒
- 可维护：模型小、本地跑、不依赖外部 API
- 可降级：ML 挂了，系统还能用，只是要手动分类
- 可替换：用户可以用更强的 ML 替换内置 ML
paperless-ngx 提醒我们：不是所有 ML 都需要是"AI 产品"。有些 ML 只需要是"基础设施"——安静地工作，出错了能改，升级了能换。这种朴素的部署模式，可能比花哨的 AI 产品更持久。
当 AI 狂热退潮，留下的可能不是最炫的 AI 产品，而是像 paperless-ngx 这样把 ML 嵌进基础设施的项目。毕竟，城市离不开水管，但没人会炫耀水管。
项目地址：https://github.com/paperless-ngx/paperless-ngx 文档：https://docs.paperless-ngx.com Demo：https://demo.paperless-ngx.com（用户名/密码：demo/demo）