开源文档框架Kreuzberg发新版,性能碾压同行?

▲ 来源：Reddit LocalLLaMA

兄弟们，开源圈又整新活儿了！一个叫Kreuzberg的文档处理框架，昨天不光发了新版本，还直接扔出来一份“跑分”报告，把市面上几个主流工具都拉出来比划了一下。结果呢？用他们自己的话说，在很多场景下，处理速度是“毫秒级”的，比对手快不少。

这“跑分”报告，玩真的？

讲真，现在开源项目说自己快，已经不稀奇了。但Kreuzberg这次搞得挺像那么回事。他们专门建了个带交互界面的基准测试网站，所有测试都在GitHub Actions上用标准化的Linux环境自动跑，确保大家站在同一起跑线上。

他们测的东西还挺全：吞吐量、处理时长、内存消耗、CPU占用、尾延迟、成功率、提取质量……既有单文件的“冷启动”场景，也有批量处理的“并发”场景。

被拉来对比的也都是熟面孔：Apache Tika、Docling、Unstructured、PDFPlumber、PyMuPDF4LLM、MarkItDown，还有Mineru。说白了，这就是文档处理界的“华山论剑”。报告结论是，在处理PDF、DOCX、PPTX、HTML这些常见格式时，Kreuzberg的吞吐量“显著更高”，处理时间经常是毫秒而不是秒，冷启动时间也更短，安装包还更小。懂的都懂，这对开发者来说意味着部署更简单，跑起来更省资源。

新版本4.3.0，重点照顾东亚语言

发报告的同时，新版本v4.3.0也上线了。这次更新有个重头戏：集成了PaddleOCR。而且是用Rust原生集成的，能自动下载和缓存模型。

目前支持六种语言：英语、中文、日语、韩语、德语和法语。开发团队特别提到，这对处理中文等东亚语言的团队很重要，因为Paddle模型在这些语言上表现很好。你想啊，现在做AI应用，处理中文文档、图片的需求太多了，有个靠谱的OCR工具链，能省不少事。

另外，这个版本还干了一件事：把LibreOffice这个依赖给踢了。以前处理老旧的.doc、.ppt格式可能还得靠它，现在他们自己实现了原生提取。团队说，减少外部依赖是他们一直努力的方向，这样能简化部署，尤其是在用Docker这种容器环境的时候，镜像能小不少。

Kreuzberg到底是个啥？

可能还有朋友不太熟。简单说，Kreuzberg是一个用Rust写的、开源的“多语言文档智能框架”。它支持Python、JavaScript、Java、Go等一大堆编程语言，也能当命令行工具、Docker镜像、REST API服务器来用。

它的活儿就是从75种以上的文档和图片格式里，把文字、元数据、表格这些结构化信息给“挖”出来，做OCR识别，然后把数据准备好，方便你下一步去做搜索、生成向量、或者喂给大模型。说白了，它就是很多AI应用、文档工作流和数据管道前期的“预处理清洁工”。这个工位虽然不起眼，但干得好不好，直接影响到后面所有环节的质量。

这事儿，对咱有啥影响？

首先，对开发者肯定是好事。多了一个性能看起来不错、还专门优化了中文处理的选择，而且是MIT开源协议，用起来没太多包袱。那种需要快速处理海量文档、又对资源消耗敏感的场景，比如云服务或者边缘计算，可能会特别关注这种“毫秒级”的性能提升。

其次，这种公开、可复现的基准测试本身，就挺值得点赞的。现在AI工具满天飞，个个都说自己又快又好，但到底怎么个好法，经常是笔糊涂账。Kreuzberg把测试方法和数据都摊开来，让大家自己看、自己验证，这种透明和较真的态度，在开源社区里应该多来点。

最后，这也说明了一个趋势：AI应用的基础设施正在变得越来越专业和垂直。以前可能拿个通用工具凑合一下，现在针对“文档智能”这种具体场景，都有团队深耕细作，从格式支持、OCR精度到运行效率，一点点抠细节。这对整个行业生态的成熟是好事。

好了，报告和数据都摆在那儿了。你觉得这种公开“跑分”的方式，会不会成为开源项目的标配？你在处理文档时，最头疼的是格式兼容、提取速度，还是OCR的准确率？评论区聊聊你的实战经历。