RAG文档预处理怎么做：ocrbase先转Markdown再喂大模型的LLM省Token实战

做 RAG 文档预处理时，最大的成本陷阱是把 PDF 直接丢给大模型——二进制和错乱的文本既浪费 Token，答案质量也差。开源项目 ocrbase 是一个可自托管的 PDF → Markdown / JSON 的 API & SDK，基于 PaddleOCR-VL 模型把文档先转成干净、结构化的 Markdown，再交给 LLM，显著降低 Token 消耗、提升 RAG 检索准确性。本文用一套三步流程，带你把它落地到 RAG 预处理管道里。

为什么 RAG 文档预处理要先解决"PDF 转 Markdown"

大多数团队的 RAG 数据源都是 PDF：合同、发票、财报、扫描件。直接处理通常遇到三个问题：

ocrbase 的思路是：OCR 只负责"看清"，大模型只负责"理解"。它的parse接口调用 PaddleOCR-VL-1.5 对每一页做版面解析（layout detection），输出带标题层级和表格结构的 Markdown；你的 RAG 管道拿到的就是干净文本，分块（chunking）和向量化都建立在可靠的基础上。

快速认识 ocrbase：两大核心能力

ocrbase 的 API 只有两个核心操作，都是异步任务（提交请求 → 拿到 job ID → 轮询或 WebSocket 拿结果），完整接口说明见 apps/web/content/docs/api/parse.mdx：

工程实现上，OCR 与 LLM 解耦：OCR 调用在 apps/server/src/services/ocr.ts 中完成（开启useLayoutDetection与prettifyMarkdown），任务编排（OCR → LLM 抽取 → 写回结果）则在 apps/server/src/workers/job.worker.ts 的 Worker 里，通过 BullMQ 队列消费，天然支持批量与重试。

实战：3步把 ocrbase 接入 RAG 预处理管道

第 1 步：安装 SDK，上传文档解析

安装ocrbase-sdk，并在环境变量中配置 API Key：

npm install ocrbase-sdk # .env OCRBASE_API_KEY=sk_xxx

一行代码解析文档（SDK 封装在 packages/sdk/src/index.ts）：

import { parse } from "ocrbase-sdk"; const result = await parse("./contract.pdf"); console.log(result.text); // 干净的 Markdown

也支持直接传 URL 或图片文件（PNG、JPEG、TIFF 等，单文件上限 50MB）。不想用 SDK，一条 curl 也能提交：

curl -X POST https://api.ocrbase.dev/v1/parse \ -H "Authorization: Bearer sk_xxx" \ -F "file=@contract.pdf"

第 2 步：拿到 Markdown，做 RAG 分块

SDK 的返回值已经把结果按页拆好了，非常适合按页分块入库：

result.pages; // [{ number: 1, text: "# 合同标题\n..." }, ...]

• 想要部分页面：parse("./large.pdf", { pages: [1, 2, 5] })
• Markdown 自带#标题与表格结构，分块时保留标题前缀，能显著提升向量召回质量

第 3 步：向量入库，喂给 LLM 省 Token

把每页（或按标题切分的段落）向量化存入向量数据库。之后大模型处理的输入是精简 Markdown 而非原始 PDF 字节：

官方 README 中也明确建议：在把文档发给 LLM 之前先用 ocrbase 解析——原始 PDF 二进制既浪费 Token 又效果差，而 ocrbase 输出的干净 Markdown 能以更低的成本得到更好的回答（见 README.md）。

进阶：让 ocrbase 直接输出结构化 JSON

如果你的 RAG 场景是"从单据里取字段"（发票金额、合同双方、订单行项目），可以跳过自己写 Prompt 的环节，用extract接口 + 一个简单 Schema：

import { extract } from "ocrbase-sdk"; const { object } = await extract("./invoice.pdf", { vendor: "string", invoiceNumber: "string", total: "number", });

内部流程是：先 OCR 成 Markdown，再让 LLM 按 Schema 抽取并校验（任务状态会经过processing→extracting→completed）。结果里还会带上tokenCount与llmModel，方便你核算每份文档的真实成本。

批量处理与实时进度：大规模文档不慌

• 异步任务：提交即返回jobId，用GET /v1/jobs/{id}轮询，或通过 SSE/WebSocket 订阅实时状态，详见 apps/web/content/docs/api/jobs.mdx
• 队列架构：任务经 Redis + BullMQ 排队，Worker 并发可配（WORKER_CONCURRENCY），数千份文档也能排队稳定处理
• 失败自动重试：网络超时、429/5xx 等瞬时错误会自动重试，无法恢复的错误才会标记失败，逻辑见 apps/server/src/workers/job.worker.ts

如何自托管 ocrbase（私有化部署）

数据不出内网时，整套服务可以用 Docker 一键拉起，完整环境变量见 docs/SELF_HOSTING.md：

git clone https://gitcode.com/gh_mirrors/oc/ocrbase cd ocrbase bun install cp .env.example .env # 配置 PADDLE_OCR_URL 指向你的 PaddleOCR 实例 docker compose up -d # 启动 postgres / redis / minio bun run db:push bun run dev

依赖组件：Bun、Docker Desktop，以及一个 PaddleOCR-VL 推理端点；服务启动后 API 位于http://localhost:3000。

总结

把 RAG 文档预处理拆成"OCR 转 Markdown → 分块入库 → LLM 问答"三段，是关键一步：

1. Parse：用 ocrbase 把 PDF 转成带版面的 Markdown，RAG 检索的基础质量有保障
2. 省 Token：大模型只读干净文本，成本与噪声同时下降
3. Extract：固定格式单据直接抽 JSON，连 Prompt 工程都省了
4. 可自托管：Docker 一键部署，私有化场景数据不出域

按上面的三步流程跑通后，你的 RAG 系统就会在"看得清"和"算得起"之间找到平衡点。