当前位置：首页 > news >正文

基于LLM的智能文档处理：从OCR到元数据生成的自动化实践

news 2026/5/3 9:29:57

1. 项目概述

如果你和我一样，是个被各种纸质文件、扫描件和电子文档淹没的人，那么“无纸化办公”这个概念听起来就像个遥不可及的乌托邦。我尝试过很多文档管理工具，从简单的文件夹分类到复杂的数据库系统，但最终都卡在了同一个环节：信息录入。给成百上千份扫描件手动命名、打标签、填写日期，这活儿不仅枯燥，还极其耗时，更别提那些字迹模糊、排版混乱的文档，光是辨认内容就让人头疼。

直到我遇到了paperless-ngx，一个开源的文档管理系统，它确实帮我解决了存储和检索的问题。但它的OCR（光学字符识别）能力，坦率地说，面对一些质量不佳的扫描件时，表现并不总是尽如人意。标题和标签的自动生成也相对基础，很多时候还是需要我手动介入。就在我几乎要放弃寻找“一键归档”的幻想时，paperless-gpt出现了。这个项目不是一个独立的系统，而是一个专门为 paperless-ngx 设计的“智能增强插件”。它的核心思想非常直接：用现代大语言模型（LLM）的“理解”能力，去弥补传统OCR的“识别”短板，并在此基础上，让AI帮你完成文档的智能归类工作。

简单来说，paperless-gpt 扮演了一个“超级助理”的角色。它守在 paperless-ngx 旁边，一旦有新的、未经处理的文档进来（通过特定的标签标记），它就会启动工作流：首先，调用你配置的AI服务（可以是云端如OpenAI GPT-4o，也可以是本地如Ollama上的Qwen2.5）对文档图像进行“视觉阅读”，提取出高精度的文本；然后，基于提取的文本，再让另一个LLM（可以是同一个，也可以是不同的）去理解内容，自动生成一个人类可读的标题、相关的标签、发件人（Correspondent）甚至自定义字段；最后，将这些建议提交回 paperless-ngx，等待你的最终审核或直接自动应用。

这个项目的价值在于，它将前沿的AI能力无缝集成到了一个成熟、稳定的文档管理生态中。你不需要改变使用 paperless-ngx 的习惯，只是多了一个无比强大的预处理环节。对于个人用户、小型工作室或是任何有大量文档处理需求的组织来说，它能将文档归档从一项繁琐的“体力劳动”，转变为一个高效、准确且可监督的“脑力辅助”过程。接下来，我将带你深入拆解它的设计思路、各种配置的实战细节，并分享我在部署和使用过程中踩过的坑和总结的经验。

2. 核心架构与设计思路解析

2.1 为何是“GPT”赋能“无纸化”？

在深入配置之前，理解 paperless-gpt 的设计哲学至关重要。它没有重新发明轮子，而是巧妙地采用了“增强”与“协同”的策略。

传统OCR的瓶颈：像Tesseract这样的传统OCR引擎，本质上是基于模式匹配的。它们擅长识别清晰、规整的印刷体，但在面对以下情况时往往力不从心：

低质量图像：光线不均、阴影、褶皱、低分辨率。
复杂布局：多栏排版、表格、图片环绕文字。
非常规字体或手写体：艺术字、潦草的手写笔记。
上下文依赖：一个单词单独看可能模糊，但结合句子语境就很容易推断。

LLM的降维打击：现代的多模态大语言模型（如GPT-4V, Claude-3.5 Sonnet, MiniCPM-V）完全不同。它们经过海量图文数据的训练，具备强大的视觉理解和上下文推理能力。给它们一张文档图片，它们不只是“认字”，而是在“阅读并理解”。这意味着它们可以：

纠正OCR错误：根据上下文推断被污渍遮挡的单词。
理解文档结构：区分标题、正文、页眉页脚、表格数据。
提取语义信息：不仅读出文字，还能理解这是一份“2023年第三季度的水电费账单”，从而为自动命名和打标签提供基础。

paperless-gpt 的核心创新点就在于，它将LLM作为OCR引擎来使用（通过其llmOCR提供者）。这并非简单的替换，而是一种能力上的跃升。当然，它也保留了对接专业OCR服务（如Google Document AI、Azure Document Intelligence）的接口，让你可以根据需求、预算和隐私要求灵活选择。

2.2 双阶段处理流程：从“看到”到“理解”

项目的工作流清晰地分为两个主要阶段，这两个阶段可以配置使用相同或不同的AI模型，这提供了极大的灵活性。

第一阶段：视觉文本提取（OCR阶段）这个阶段的目标是“看清纸上有什么”。输入是文档图像（或PDF），输出是尽可能准确的纯文本。

提供者：可以是llm(GPT-4o, MiniCPM-V),google_docai,azure,docling。
关键配置：OCR_PROVIDER,VISION_LLM_PROVIDER,VISION_LLM_MODEL。
我的经验：对于绝大多数复杂文档，LLM作为OCR提供者的准确率显著高于传统方法。特别是gpt-4o，在理解扭曲文本和复杂表格方面表现惊人。如果追求隐私和零成本，在Ollama上运行minicpm-v模型是一个极佳的折中方案。

第二阶段：语义理解与元数据生成（LLM阶段）这个阶段的目标是“理解文字是什么意思并组织起来”。输入是第一阶段提取的文本，输出是结构化元数据（标题、标签等）。

提供者：可以是openai,ollama,mistral,anthropic,googleai。
关键配置：LLM_PROVIDER,LLM_MODEL。
我的经验：这个阶段对模型的“推理”和“遵循指令”能力要求更高。标题生成需要简洁概括，标签生成需要准确分类。我发现在这个阶段使用一个更强的“推理模型”收益很大，例如在Ollama上使用qwen2.5:14b或llama3.2:3b，效果比同体量的纯聊天模型要好。当然，如果第一阶段已经用了GPT-4o，第二阶段继续用它，效果是最丝滑的。

这种解耦设计的好处是，你可以进行“混搭”。例如，用本地的、免费的minicpm-v做OCR提取文本（这通常消耗大量视觉token，比较贵），然后将文本发送给云端更强大的gpt-4o-mini来生成元数据（纯文本token便宜很多）。这种组合能在成本和效果之间找到很好的平衡点。

2.3 与Paperless-ngx的协同模式：手动与自动

paperless-gpt 通过 tags（标签）与 paperless-ngx 进行通信，这种方式非常优雅，无需修改 paperless-ngx 的核心代码。

手动模式（Manual Review）：
- 你在 paperless-ngx 中为需要处理的文档打上MANUAL_TAG（默认是paperless-gpt）。
- paperless-gpt 会定期扫描带有此标签的文档。
- 处理完成后，在 paperless-gpt 的Web界面（默认端口8080）中，你可以看到AI生成的所有建议（标题、标签、日期、发件人）。
- 你可以逐一审核、修改，并点击“提交”将元数据写回 paperless-ngx。
- 适用场景：初期调试、处理重要或格式特殊的文档、希望完全掌控结果。
自动模式（Auto Processing）：
- 你在 paperless-ngx 中为希望全自动处理的文档打上AUTO_TAG（默认是paperless-gpt-auto）。
- paperless-gpt 处理这些文档后，不会进入待审核队列，而是直接将其建议应用到 paperless-ngx，并移除该自动标签。
- 适用场景：大量格式规范、重复性高的文档（如每月的水电费账单、银行对账单）。一旦你信任AI在该类文档上的处理能力，就可以放手让它自动完成。

提示：我强烈建议从手动模式开始。用几十份不同类型的文档测试AI的生成效果，观察它在哪些地方做得好，哪些地方会出错。这个过程能帮助你调整提示词（Prompts），也能建立对系统的信任。之后，再为那些表现稳定的文档类型开启自动模式。

3. 实战部署与核心配置详解

理论说再多，不如动手搭一个。下面我将以最常用的Docker Compose方式，详细讲解如何将 paperless-gpt 与 paperless-ngx 一起部署，并针对几种典型场景给出配置方案。

3.1 基础环境准备

假设你已经有一个运行中的 paperless-ngx 实例（通过Docker Compose部署）。你的docker-compose.yml文件可能看起来像这样（仅展示关键部分）：

services: paperless-webserver: image: ghcr.io/paperless-ngx/paperless-ngx:latest container_name: paperless-webserver # ... 端口、卷、环境变量等配置

首先，你需要从 paperless-ngx 获取一个API Token，这是 paperless-gpt 与其通信的钥匙。

登录你的 paperless-ngx 管理后台（通常是http://你的IP:8000/admin）。
导航到AUTHENTICATION AND AUTHORIZATION->Tokens。
点击Create token，为其命名（例如paperless-gpt），并复制生成的密钥字符串。这个字符串只显示一次，请妥善保存。

3.2 Docker Compose 集成部署

我们将把 paperless-gpt 作为一个新的服务添加到现有的docker-compose.yml文件中。以下是几种不同需求的配置示例。

场景一：使用云端OpenAI API（最快速上手）这是最简单的方式，适合希望立即体验最强效果的用户。

services: # 你原有的 paperless-ngx 服务 paperless-webserver: image: ghcr.io/paperless-ngx/paperless-ngx:latest # ... 你原有的配置保持不变 # 新增的 paperless-gpt 服务 paperless-gpt: image: icereed/paperless-gpt:latest container_name: paperless-gpt restart: unless-stopped environment: # 1. 连接Paperless-ngx PAPERLESS_BASE_URL: "http://paperless-webserver:8000" # 注意使用Docker内部服务名 PAPERLESS_API_TOKEN: "你的Paperless_API_Token" # 替换为刚才获取的Token # PAPERLESS_PUBLIC_URL: "https://paperless.yourdomain.com" # 如果你有反向代理，可在此设置公网地址 # 2. 配置主LLM（用于生成标题、标签等） LLM_PROVIDER: "openai" LLM_MODEL: "gpt-4o-mini" # 性价比高，足够智能。也可用 gpt-4o 获得更好效果。 OPENAI_API_KEY: "你的OpenAI_API_Key" # 3. 配置OCR提供者（这里也用OpenAI，即GPT-4o的视觉能力） OCR_PROVIDER: "llm" VISION_LLM_PROVIDER: "openai" VISION_LLM_MODEL: "gpt-4o" # OCR强烈推荐使用视觉能力最强的 gpt-4o # 4. 基础设置 LLM_LANGUAGE: "Chinese" # 文档主要语言，帮助AI理解 LOG_LEVEL: "info" ports: - "8080:8080" # paperless-gpt的Web管理界面 depends_on: - paperless-webserver volumes: - ./paperless_gpt_prompts:/app/prompts # 挂载提示词目录，方便自定义

关键点解释：

PAPERLESS_BASE_URL：在Docker Compose网络内，直接用服务名paperless-webserver和内部端口8000访问，这是最可靠的方式。
LLM_MODEL与VISION_LLM_MODEL：这里我做了区分。元数据生成用了更便宜的gpt-4o-mini，而OCR用了更强大的gpt-4o。因为OCR任务对视觉精度要求极高，多花点钱值得。你也可以全用gpt-4o。
volumes：将本地的./paperless_gpt_prompts目录挂载到容器的/app/prompts。这样你可以在宿主机上编辑提示词模板，修改会即时生效。

场景二：使用本地Ollama（追求完全隐私与零成本）如果你所有文档都涉及敏感信息，或者不想产生API费用，本地部署是唯一选择。

services: paperless-webserver: # ... 原有配置 # 先启动Ollama服务 ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped volumes: - ./ollama_data:/root/.ollama # 持久化模型数据 ports: - "11434:11434" paperless-gpt: image: icereed/paperless-gpt:latest container_name: paperless-gpt restart: unless-stopped environment: PAPERLESS_BASE_URL: "http://paperless-webserver:8000" PAPERLESS_API_TOKEN: "你的Paperless_API_Token" # 主LLM使用本地Ollama上的推理模型 LLM_PROVIDER: "ollama" LLM_MODEL: "qwen2.5:14b" # 一个在理解指令和生成方面表现很好的模型 OLLAMA_HOST: "http://ollama:11434" # 指向Ollama服务 TOKEN_LIMIT: 1000 # 限制生成token，防止输出过长 # OCR也使用Ollama上的视觉模型 OCR_PROVIDER: "llm" VISION_LLM_PROVIDER: "ollama" VISION_LLM_MODEL: "minicpm-v" # 优秀的开源多模态模型 # OLLAMA_HOST 已在上方设置，这里无需重复 LLM_LANGUAGE: "Chinese" LOG_LEVEL: "info" ports: - "8080:8080" depends_on: - paperless-webserver - ollama volumes: - ./paperless_gpt_prompts:/app/prompts

部署后关键操作：

启动服务：docker-compose up -d。
拉取模型：进入Ollama容器或直接在宿主机（如果安装了Ollama）执行：
```
docker exec -it ollama ollama pull qwen2.5:14b docker exec -it ollama ollama pull minicpm-v
```
这个过程可能需要较长时间，取决于你的网络和磁盘速度。
重要提示：本地LLM的性能极度依赖硬件。minicpm-v和qwen2.5:14b对GPU内存有一定要求。如果处理速度慢或出错，请查看日志，并考虑使用更小的模型（如llama3.2:3b用于文本生成），或升级硬件。

场景三：混合模式（平衡成本、隐私与效果）这是我个人目前采用的方案，兼顾了质量、速度和成本。

environment: # ... Paperless 连接配置 # 主LLM：使用便宜的云端小模型做文本理解 LLM_PROVIDER: "openai" LLM_MODEL: "gpt-4o-mini" OPENAI_API_KEY: "你的OpenAI_API_Key" # OCR：使用本地Ollama，避免上传敏感图片到云端，也节省视觉API费用 OCR_PROVIDER: "llm" VISION_LLM_PROVIDER: "ollama" VISION_LLM_MODEL: "minicpm-v" OLLAMA_HOST: "http://ollama:11434" # 限制OCR页面，提升速度（尤其是本地模型） OCR_LIMIT_PAGES: 5 # 只处理前5页，对于多页文档，通常关键信息在前几页

这个方案的逻辑是：最敏感的“图像识别”环节在本地完成，转化为文本后，再将这些“已脱敏”的文本发送到云端进行智能分析。文本API调用的成本远低于视觉API，且隐私风险更低。

3.3 高级功能配置：打造可搜索的PDF

paperless-gpt 一个杀手级功能是能与Google Document AI结合，生成带透明文本层的可搜索PDF。传统OCR只是提取文本，而这项功能能在原版PDF上叠加一层精准定位的、不可见的文字，让你既能保持原文档的版式，又能复制、搜索文字。

配置步骤：

启用Google Cloud并创建凭证：你需要一个Google Cloud项目，启用Document AI API，并创建一个服务账号密钥（JSON文件）。

修改Docker Compose配置：

environment: # ... 其他配置 OCR_PROVIDER: "google_docai" GOOGLE_PROJECT_ID: "your-project-id" GOOGLE_LOCATION: "us" # 或 asia-northeast1 等 GOOGLE_PROCESSOR_ID: "your-processor-id" # 在Document AI中创建的处理器ID GOOGLE_APPLICATION_CREDENTIALS: "/app/credentials.json" # 启用增强PDF功能 CREATE_LOCAL_PDF: "true" # 在本地生成增强版PDF LOCAL_PDF_PATH: "/app/pdf" PDF_UPLOAD: "true" # 上传到Paperless PDF_COPY_METADATA: "true" # 复制原文档的元数据 PDF_REPLACE: "false" # ！！！危险，设为true会删除原文档，初期务必设为false PDF_OCR_TAGGING: "true" PDF_OCR_COMPLETE_TAG: "paperless-gpt-searchable-pdf" volumes: - ./paperless_gpt_prompts:/app/prompts - ./gcp_credentials.json:/app/credentials.json # 挂载服务账号密钥 - ./pdf_output:/app/pdf # 挂载PDF输出目录

处理流程：当处理一个带AUTO_TAG的PDF文档时，paperless-gpt会调用Google Document AI进行OCR，生成带坐标的文本信息（hOCR），然后合成一个新的、可搜索的PDF，上传到Paperless作为一个新文档，并尽可能复制原文档的元数据。

警告：PDF_REPLACE: "true"选项会删除原文档。只有在经过充分测试，完全信任整个流程后，才考虑启用。建议始终保留CREATE_LOCAL_PDF: "true"作为备份。

4. 提示词（Prompts）定制与优化实战

paperless-gpt 的强大之处在于其可定制的提示词系统。默认的提示词已经不错，但针对你的特定文档类型（如中文合同、英文发票、技术报告）进行微调，能大幅提升准确率。

4.1 理解提示词结构

在 paperless-gpt 容器内的/app/prompts目录（我们已将其挂载到宿主机）下，你可以创建自定义提示词文件。系统采用“安全默认”机制：它会先加载内置的default_prompts，然后覆盖以你自定义的prompts目录下的同名文件。

核心的提示词文件包括：

title.txt：用于生成文档标题。
tags.txt：用于生成标签。
correspondent.txt：用于识别和生成发件人/对应方。
created_date.txt：用于提取文档创建日期。
custom_fields.txt：用于填充自定义字段（需在Paperless-ngx中预先定义）。

4.2 定制标题生成提示词

默认的标题提示词可能生成类似“Document about invoice”这样的通用标题。我们希望它更具体。例如，针对“发票”，我们可以修改prompts/title.txt：

You are an expert document archivist. Analyze the provided text extracted from a document and generate a concise, descriptive, and filename-friendly title. CRITICAL REQUIREMENTS: 1. The title MUST be in the same primary language as the document content (e.g., Chinese content -> Chinese title). 2. The title should capture the core essence: document type, main parties, key subject, and date (if present and relevant). 3. Format: `[YYYY-MM-DD] [Entity A] 与 [Entity B] 关于 [Subject] 的 [Document Type]`. 4. If the document is a contract or agreement, include the signing parties. 5. If it's a bill or invoice, include the payer, payee, period, and amount. 6. If no clear date is found, omit the date part. 7. Output ONLY the title string, no explanations, no markdown, no quotes. Document text: {{ text }} Generated title:

关键技巧：

明确指令：使用“CRITICAL REQUIREMENTS”、“MUST”等强语气词。
提供格式范例：LLM非常擅长遵循示例。[YYYY-MM-DD] [Entity A] 与 [Entity B] 关于 [Subject] 的 [Document Type]这个模板能极大规范输出。
语言锚定：in the same primary language as the document content这一指令能有效防止中英文混合。
变量注入：{{ text }}是 paperless-gpt 注入OCR文本的地方。

4.3 定制标签生成提示词

标签是文档分类检索的关键。一个好的标签系统应该层次清晰。修改prompts/tags.txt：

You are a meticulous librarian. Analyze the document text and suggest relevant tags for categorization. INSTRUCTIONS: 1. **Language**: Generate tags in the document's primary language (e.g., Chinese -> Chinese tags). 2. **Categories**: Think in these hierarchies: - **Document Type**: 发票, 合同, 银行对账单, 水电费账单, 体检报告, 保单, 简历, 论文, 手册, 收据, 税务报表, 法律文书, 信件, 备忘录, 报告。 - **Entity**: 涉及的主要机构或个人，如 `腾讯`, `招商银行`, `北京市税务局`, `协和医院`。 - **Topic/Subject**: 核心主题，如 `云计算服务`, `个人贷款`, `增值税`, `年度体检`, `房屋租赁`。 - **Status**: 状态，如 `已支付`, `待审核`, `已过期`, `有效期内`。 - **Year/Month**: 时间标签，如 `2024`, `2024-01`。 3. **Selection**: Pick 3-8 tags. Prioritize accuracy over quantity. Do NOT invent tags that are not strongly supported by the text. 4. **Format**: Output tags as a comma-separated list. Example: `发票, 腾讯, 云计算服务, 已支付, 2024-01` Document text: {{ text }} Suggested tags:

我的心得：

预先定义分类体系：在提示词中明确给出标签的类别和例子，能引导AI生成结构化、一致的标签，而不是随机的名词。
控制数量：Pick 3-8 tags避免了AI生成过多无关标签。
利用Paperless-ngx的标签特性：在Paperless-ngx后台预先创建好这些标签，并设置颜色。当paperless-gpt建议的标签不存在时，它会在Paperless中自动创建。保持标签体系的整洁需要定期在Paperless后台进行维护。

4.4 调试与迭代

查看原始文本：在 paperless-gpt 的Web界面审核建议时，一定要点击查看Extracted Text。很多时候生成结果不理想，是因为OCR提取的文本质量差（有乱码、换行错误）。这时你需要优化OCR阶段（换更好的模型或提供商），而不是修改LLM提示词。
小批量测试：每次修改提示词后，用少量（5-10份）具有代表性的文档进行测试。在手动模式下观察生成结果。
利用“Ad-hoc Analysis”：paperless-gpt 界面提供了一个“Ad-hoc Analysis”功能。你可以选择一批已处理的文档，输入一个自定义的提示词（例如：“总结所有这些文档涉及的总金额”），让AI进行一次性分析。这是测试复杂提示词的绝佳沙盒。

5. 常见问题排查与性能优化实录

在实际部署和长期使用中，你肯定会遇到各种问题。以下是我踩过的一些坑和解决方案。

5.1 连接与基础问题

问题1：paperless-gpt 无法连接到 paperless-ngx，日志显示连接错误或超时。

排查：检查PAPERLESS_BASE_URL。在Docker Compose内，必须使用服务名称（如paperless-webserver）而非localhost或公网IP。确保网络是互通的（depends_on仅控制启动顺序，不保证网络健康）。
解决：在 paperless-gpt 容器内执行curl http://paperless-webserver:8000/api/测试连通性。确认 paperless-ngx 的API可以访问。

问题2：API Token 无效。

排查：日志中会出现401 Unauthorized或403 Forbidden。
解决：在 paperless-ngx 后台重新生成一个Token，并确保在环境变量中正确配置。Token字符串不要有多余的空格或换行。

问题3：Ollama 模型加载慢或报错 “context length” 相关问题。

排查：查看 paperless-gpt 和 ollama 容器的日志。常见错误是模型未下载或GPU内存不足。
解决：
- 确认模型已拉取：docker exec ollama ollama list。
- 对于视觉模型minicpm-v，如果GPU内存不足（例如小于8GB），尝试增加OLLAMA_CONTEXT_LENGTH环境变量为8192，或换用更小的视觉模型（如llava:7b）。
- 考虑在docker-compose.yml中为 ollama 服务添加GPU支持：deploy: resources: reservations: devices: - driver: nvidia ...。

5.2 处理性能与成本优化

问题：处理速度慢，尤其是使用本地Ollama时。

优化策略：
1. 限制页面：对于动辄几十页的PDF，使用OCR_LIMIT_PAGES: 5。大部分关键信息（如发票抬头、金额、日期）都在前几页。
2. 调整处理模式：如果使用Google Document AI，尝试OCR_PROCESS_MODE: "pdf"或"whole_pdf"，可能比默认的"image"模式更快。
3. 模型降级：在效果可接受的前提下，为文本生成阶段使用更小的模型（如从qwen2.5:14b降到llama3.2:3b）。
4. 硬件升级：这是最根本的。本地LLM推理是计算密集型任务，GPU是硬需求。

问题：使用OpenAI等云端API，费用增长较快。

优化策略：
1. 采用混合模式：如前所述，用本地模型做OCR，云端模型做文本理解。
2. 使用更便宜的模型：OCR阶段是费用大头（视觉token贵）。如果文档质量尚可，可以尝试用gpt-4o-mini代替gpt-4o做OCR，虽然精度可能略有下降。
3. 设置速率限制：使用LLM_REQUESTS_PER_MINUTE和VISION_LLM_REQUESTS_PER_MINUTE环境变量，防止意外的大量文档涌入导致巨额账单。
4. 善用“手动模式”审核：不要一开始就给所有文档打上AUTO_TAG。先用手动模式处理一批，确认AI在该类文档上表现稳定后，再将其加入自动处理队列。

5.3 内容生成质量问题

问题：生成的标题或标签不准确、太笼统或包含幻觉信息。

排查：首先检查Extracted Text。如果OCR文本本身有大量错误，后续生成就是“垃圾进，垃圾出”。
解决：
1. 优化OCR源：这是根本。换用更强的OCR提供者（如从本地minicpm-v切换到gpt-4o或Google Document AI）。
2. 精炼提示词：参考第4节，让你的提示词更具体、更具约束力。明确禁止AI虚构信息（例如，在提示词末尾加上Do NOT hallucinate or generate information not present in the text.）。
3. 提供示例：在提示词中提供一两个完美的输入输出示例（Few-Shot Learning），能极大提升LLM的表现。
4. 调整LLM参数：尝试降低temperature（如果环境变量支持）。更低的温度值（如0.2）会使输出更确定、更少“创造性”，对于事实提取任务更合适。

问题：对于中文文档，日期提取格式混乱（如将“2023年12月5日”识别为“05/12/2023”）。

解决：在prompts/created_date.txt中明确指定输出格式。例如：
```
... (其他指令) If you find a date, output it STRICTLY in ISO 8601 format: YYYY-MM-DD. If no clear date is found, output "NOT_FOUND". ...
```
同时，在LLM_LANGUAGE环境变量中设置为Chinese，有助于模型优先使用中文语境理解日期。

5.4 高级功能故障

问题：启用PDF_UPLOAD: "true"后，paperless-ngx 中出现重复文档，或原文档未被删除。

排查：这是最需要小心的环节。检查 paperless-gpt 日志，看上传和删除步骤是否报错。
解决：
- 重复文档：确保PDF_COPY_METADATA: "true"工作正常。检查新文档的标题、标签是否与原文档一致。有时因为网络问题，上传成功但删除原文档失败，导致两者并存。
- 原文档未删除：PDF_REPLACE: "true"是删除操作的开关。但paperless-ngx的API可能因为权限或文档状态（如被锁定）而拒绝删除。务必先在测试环境，用不重要的文档，将PDF_REPLACE设为false运行一段时间，确认整个“生成-上传-复制元数据”流程完美无误后，再谨慎开启替换功能。
- 始终保留本地备份：设置CREATE_LOCAL_PDF: "true"和LOCAL_PDF_PATH，这样即使云端操作出错，你本地还有增强版PDF的副本。