paperless-gpt
用AI大模型自动为paperless-ngx文档打标签、命名、提取字段
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
用AI大模型自动为paperless-ngx文档打标签、命名、提取字段
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
图1：paperless-gpt Web界面，支持AI审阅与手动修正文档分类建议
想象这样一个场景：你是自由职业者，每月收到几十张发票、银行对账单、合同协议，全部堆在桌上等着手动录入。你花了整整两小时分类归档，手指酸痛，眼睛发涩。paperless-gpt 正是为解决这个痛点而生——它让 AI 自动为你的文档打标签、命名、提取关键字段，把文档管理的繁琐工作从手动变成半自动甚至全自动。
paperless-ngx 是开源文档管理领域的明星项目，GitHub 星标超过 2.7 万，专门帮助用户数字化管理纸质文件。它支持 PDF 上传、OCR 识别、全文搜索、标签管理，几乎是自托管文档管理的首选方案。然而，paperless-ngx 的核心短板在于：文档来了之后，分类、打标签、命名这些工作仍然需要人工完成。
开发者 icereed 在日常使用 paperless-ngx 时被这个问题困扰，于是萌生了用大语言模型接管这部分工作的想法。项目于 2023 年底发布，迅速获得了广泛关注——目前已累计 2400+ 星，fork 数超过 170，issue 列表长期保持在 200 条左右，说明社区活跃、功能迭代快速。
paperless-gpt 并不是简单调用一下 GPT API 那么简单。它构建了一套完整的文档处理流水线，涵盖 OCR 识别 → 文本提取 → LLM 智能分析 → 结果写入 paperless-ngx 的全过程。
这是 paperless-gpt 最具差异化的特性。传统 OCR 工具（如 Tesseract）只能识别文字，却无法理解文档结构。LLM-OCR 的思路是：把文档图像直接发给 GPT-4o 或 Ollama（本地模型），让模型"看"图理解内容。这种方式在模糊扫描件、手写潦草字体、表格密集型文档上表现显著优于传统方案。
支持多种 OCR Provider：
文档上传后，paperless-gpt 会自动调用 LLM 分析文档内容，生成：
特别值得一提的是 自定义字段的三种写入模式：Append（只追加空字段，最安全）、Update（追加并覆盖已有字段）、Replace（完全替换）。这种分层的安全设计让用户可以根据场景灵活选择，避免意外覆盖重要数据。
paperless-gpt 可以将原始扫描件转换为带透明文字层的 PDF，文字精确覆盖在对应图像区域上方——这样既能保持原始视觉效果，又能让 PDF 支持复制文字和全文搜索。这个功能基于 MuPDF（开源 PDF 引擎）和 pdfcpu 库实现。
如果你对数据隐私有要求，项目推荐使用 Ollama 本地部署推理模型（如 qwen3:8b）。作者在文档中明确提到：推理模型（如 qwen3、qwq 等）能显著提升准确率，在隐私性和精度之间达到良好平衡。这说明项目在设计时充分考虑了企业级用户的需求。
paperless-gpt 后端采用 Go 语言开发，主要技术栈：
代码结构清晰，按功能模块划分：app_llm.go（LLM调用）、ocr.go（OCR处理）、paperless.go（与paperless-ngx交互）、jobs.go（后台任务调度）、background.go（后台处理逻辑）、settings.go（配置管理）。
Web UI 基于 React + TypeScript 构建，使用 Vite 构建工具和 TailwindCSS 样式框架。前端采用 Node.js 24 Alpine 镜像构建，与后端一同打包进 Docker 镜像中——用户无需单独部署前端服务。
项目提供多阶段 Dockerfile（两个阶段）：
最终镜像基于 Alpine Linux，大小可控。docker-compose.yml 提供了与 paperless-ngx 联动部署的参考配置，用户只需配置 .env 文件（API Key 和 paperless-ngx 地址）即可启动。
部署难度中等，主要门槛在于两点：
对于已有 paperless-ngx 实例的用户，在已有 docker-compose 基础上加入 paperless-gpt 服务是最快路径。项目还提供了 build-and-run.sh 和 docker-build-and-push.sh 脚本，简化构建流程。
硬件要求方面，纯 CPU 运行即可（无 GPU 依赖），内存约 1GB，磁盘 200MB，非常轻量。唯一的变数是 LLM 推理——如果你用 Ollama 本地模型，则需要相应规格的 GPU。
任何工具都有其局限性，paperless-gpt 也不例外：
1. LLM API成本：使用 OpenAI GPT-4o 处理大量文档会产生 API 费用。作者建议对于大批量场景改用 Ollama 本地模型，但本地模型对硬件有一定要求。
2. 隐私风险：将文档图像发给第三方 LLM API 存在数据泄露隐患，尽管项目支持 Ollama 私有部署，但配置复杂度增加。
3. 对 paperless-ngx 的强依赖：项目设计上需要与 paperless-ngx 配合使用，独立使用价值有限。
4. 200+ open issues：说明项目虽然活跃，但仍有不少待解决的问题，用户在生产环境使用前需关注 issue 区。
paperless-gpt 代表了 AI 落地的一种务实路径：不替代已有成熟工具，而是作为增强层叠加其上。它没有重新发明文档管理系统，而是专注于"文档来了之后怎么办"这个细分问题，用 LLM 填补了 paperless-ngx 在智能分类上的短板。
从开源社区的响应来看（2400+ stars，持续迭代），这种"AI增强现有工作流"的思路得到了广泛认可。对于已经在使用或计划使用 paperless-ngx 的用户来说，paperless-gpt 是值得一试的配套工具——它可能无法做到 100% 准确，但能将你从繁琐的手动分类中解放出来，把精力聚焦在真正需要判断力的事务上。
适合人群：有大量文档管理需求的个人用户、小型办公室、隐私敏感且有技术能力的团队。
不适合：完全没有 paperless-ngx 基础、期望零配置开箱即用、对 AI 准确性有 100% 要求的场景。