做 RAG 应用时，我受够了数据预处理的各种坑
写在前面
去年开始做 RAG 项目，遇到的第一个问题不是模型选型，也不是向量数据库，而是：怎么把各种格式的文档转成 AI 能用的数据？
PDF 里的表格识别不出来，Word 文档的格式乱七八糟，扫描件 OCR 效果一言难尽。试了一圈开源工具，要么只能处理单一格式，要么需要自己写一堆胶水代码把不同的工具串起来。
更头疼的是，公司要求私有化部署，不能把文档传到第三方 API。而且我们有多张 GPU 卡，但大部分解析工具要么不支持 GPU，要么就是多卡调度一团糟，经常爆显存。
于是，我决定自己做一个工具，解决这些问题。
这就是 MinerU Tianshu（天枢）的由来。
它能做什么？
简单说，把各种格式的数据，转成 AI 能直接用的结构化格式。
📄 文档处理
支持 PDF、Word、Excel、PPT、HTML 等常见格式，输出 Markdown 或 JSON。
- MinerU Pipeline：完整的文档解析，表格、公式、图片都能识别
- PaddleOCR-VL：支持 109+ 种语言，中英日韩都不在话下
🎙️ 音频处理（NEW）
这是最近刚加的功能。用的是 SenseVoice 引擎，效果超出预期：
- 多语言识别：中文、英文、日语、韩语、粤语
- 说话人识别：自动区分不同说话人
- 情感识别：能识别出中性、开心、生气、悲伤
- 事件检测：语音、掌声、背景音乐、笑声
最关键的是，转写结果会自动用 emoji 标注情感和事件，比如 😊、😠、🎵，可读性特别好。
🖼️ 图片处理
JPG、PNG 直接提取文字，支持多种 OCR 引擎，GPU 加速。
为什么要做这个？
市面上的文档解析工具其实不少，但在实际使用中，总会遇到各种问题：
1. 工具分散，接口不统一
做 RAG 应用需要处理各种格式的数据，但市面上没有一个工具能覆盖所有场景： 这意味着要维护好几套代码，每个工具的调用方式、参数格式、输出结构都不一样。想统一处理？得自己写一层封装。 更麻烦的是，这些工具的依赖经常冲突。某个 OCR 库要 PyTorch 1.13，某个 PDF 工具要 2.0，为了兼容性得建好几个虚拟环境。每次部署到新机器，光装环境就要折腾半天。
2. 多 GPU 并发是个大坑
公司有多张 GPU 卡，想着可以并行处理文档提高效率。但实际跑起来发现：
- 多个进程同时调用模型，显存很容易爆
- 手动分配 GPU？得自己写调度逻辑，处理各种边界情况
- 用
CUDA_VISIBLE_DEVICES限制？任务一多，配置就乱了
试过用多进程 + 固定 GPU 编号，结果某个任务卡住了，对应的 GPU 就一直被占着，其他任务排队等着。
也试过用 Ray 做分布式调度，但为了处理文档专门搭一套 Ray 集群，感觉有点重。而且 Ray 对 GPU 的管理还是得自己写不少代码。
最理想的状态是：我只管提交任务，系统自动把任务分配到空闲的 GPU 上，出错了自动重试。 但大部分开源工具都没有这个能力。
3. 没有生产级的任务管理
开源工具基本都是"一次性脚本"的思路，没考虑生产环境的需求：
- 批量处理：没有队列机制，只能一个一个文件处理，或者自己写多进程
- 错误重试：某个文档解析失败了，得手动找出来重新跑
- 优先级：老板要的紧急任务，只能等前面的任务跑完
- 进度追踪：不知道任务跑到哪了，是卡住了还是在正常处理
有一次处理了几千个文档，跑了一晚上，早上来看发现中间出错了，前面的结果也没保存。又得重新跑一遍。
4. 对 RAG 应用不友好
做 RAG 最看重的是数据质量和格式统一，但很多工具在这方面做得不够：
- 输出格式乱：有的输出纯文本，有的输出 HTML，有的是自定义格式。接到 RAG 系统之前，得先写一堆清洗脚本
- 结构信息丢失：标题、列表、表格这些结构信息没了，后续很难做语义分块
- 元数据缺失：不知道这段文字来自第几页，是表格还是正文，对 RAG 检索的准确率有影响
- 私有化部署难：很多商业 API 效果不错，但企业的敏感文档不能传到外部服务器
最后就是维护成本的问题。工具一多，环境依赖就复杂，Python 版本冲突、CUDA 版本不兼容、依赖库冲突……每次换台机器部署，都要折腾半天。
5. 商业方案太贵，开源方案太散
商业方案（比如各种 OCR API）确实省心，但有几个问题：
- 成本高：按量付费，处理量大了账单吓人
- 数据安全：金融、医疗、法律这些行业的文档，不能传到外部
- 功能受限：只能用它提供的功能，不能定制
开源方案虽然免费，但太分散：
- 不同格式要用不同工具
- 每个工具要单独部署、单独维护
- 工具之间没有统一的接口和输出格式
- 出了问题不知道是哪个环节的锅
我就在想，能不能有一个工具，把这些痛点都解决掉？
不需要大而全，但至少要覆盖 RAG 应用最常见的数据类型。不需要完美无缺，但至少要在生产环境中用得舒服。
于是就有了天枢。
所以，我是怎么做的？
🎯 多引擎集成
不重复造轮子。市面上已经有很多优秀的开源引擎了，比如 MinerU、DeepSeek OCR、PaddleOCR、SenseVoice。我要做的是把它们整合在一起，让用户可以根据场景选择最合适的引擎。
⚡ GPU 负载均衡
用 LitServe 做 GPU 调度，支持多卡并发，避免显存冲突。任务自动分配到空闲的 GPU 上，利用率能到 90%+。
📦 完整的任务管理
- 任务队列：支持批量提交，自动排队
- 优先级管理：紧急任务可以插队
- 自动重试：失败了会自动重试，不用手动干预
- 实时监控：Web 界面可以看到所有任务的状态
🔗 MCP 协议支持
这个是后来加的，但我觉得特别有用。
MCP 是 Anthropic 提出的开放协议，AI 助手可以通过它调用外部工具。集成之后，Claude Desktop 可以直接调用天枢来处理文档，不用再手动上传下载。
一些使用场景
- 法律文书处理：批量 OCR 扫描版判决书，私有化部署保证数据安全
- 多语言文档：统一处理中英日韩等多语言技术文档，输出标准 Markdown
- 会议记录：录音转文字 + 说话人识别 + 情感标注，自动生成会议纪要
- 知识库构建：批量处理企业内部文档，为 RAG 检索系统准备数据
为什么叫"天枢"？
天枢是北斗七星的第一颗星，在古代被用来指引方向。
做 RAG 应用时，数据预处理就像这颗"天枢"，它决定了整个系统的数据质量。数据准备好了，后面的检索、生成才能顺利进行。
另外，项目的核心能力是 引擎调度，就像天枢在天空中"调度"其他星星一样。
开源协议和贡献
项目采用 Apache 2.0 协议，欢迎任何形式的贡献：
- 🐛 报告 Bug
- 💡 提出新功能建议
- 📝 改进文档
- 🔧 提交代码
GitHub: github.com/magicyuan87…
写在最后
做这个项目的初衷很简单：解决自己的问题。
我不是想做一个大而全的平台，也不是要跟商业产品竞争。我只是希望，当其他开发者遇到和我一样的问题时，能有一个开箱即用的工具，不用再踩我踩过的坑。
如果你也在做 RAG 应用，也被数据预处理折磨过，欢迎试试天枢。
如果你觉得这个项目有用，点个 Star 就是对我最大的支持。
如果你有任何建议或问题，欢迎在 GitHub 上提 Issue，我会尽快回复。
