Kreuzberg：用 Rust 构建的文档提取层，75+ 格式通吃的 RAG 基础设施

RAG 时代的"最后一公里"难题

在 2026 年的 AI 基础设施版图中，RAG（检索增强生成）架构已经从实验室概念变成了企业 AI 的标配。向量数据库、嵌入模型、重排序算法——这些词汇早已烂熟于每个后端工程师的心中。然而，有一个环节长期被低估、被凑合、被各种临时方案糊弄过去：**文档解析**。

把一份 PDF 的内容准确喂进大模型，听起来简单，做起来是个深坑。扫描版 PDF 需要 OCR，Word 文档有嵌套样式，Excel 里有合并单元格，PowerPoint 的内容藏在形状对象里，邮件有附件套附件……现实世界里的文档格式是一场灾难，而大多数 Python 库的应对方式是"能跑就行"。

Kreuzberg 的出现，正是为了终结这种将就。

Kreuzberg 是什么

Kreuzberg 是一个用 **Rust** 编写的文档文本提取库，核心定位是：成为 RAG 管线中文档预处理环节的生产级基础设施。

项目名字取自柏林著名的创意街区 Kreuzberg，这个名字本身就带着一种"多元融合"的气质——恰如其分地描述了这个库的野心：支持 **75+ 种文档格式**，一个统一的 API，覆盖几乎所有人类会产出的文件类型。

支持的格式矩阵

| 文档类别 | 支持格式 |

|---------|---------|

| 文档类 | PDF、Word（.docx/.doc）、RTF、ODT |

| 表格类 | Excel（.xlsx/.xls）、CSV、ODS |

| 演示类 | PowerPoint（.pptx/.ppt）、ODP |

| 图片类 | PNG、JPEG、TIFF、BMP（OCR 提取） |

| 邮件类 | EML、MSG、MBOX |

| 压缩包 | ZIP、TAR、GZ、7Z（递归解包） |

| 学术类 | LaTeX、BibTeX、Markdown |

| 代码/数据 | HTML、XML、JSON、YAML、纯文本 |

这个覆盖范围几乎可以对应企业文档管理系统里你能想到的每一种文件。

为什么用 Rust，而不是 Python

这是一个值得深入讨论的技术选择。Python 生态里不是没有文档解析库：`pdfplumber`、`python-docx`、`mammoth`、`camelot`……但这些库的问题是：

1. **各自为政**：每种格式需要一个独立的库，版本冲突、接口不一、行为差异是日常

2. **性能瓶颈**：处理大规模文档语料库时，Python 的单线程 GIL 和高内存占用会成为瓶颈

3. **错误处理参差不齐**：碰到格式稍有异常的文件，许多库直接抛异常或静默失败

Kreuzberg 选择 Rust 的理由是显而易见的：

性能优势

Rust 的内存安全模型和零成本抽象让 Kreuzberg 在基准测试中比等效 Python 实现快 **5-10 倍**，内存占用更低。对于需要批量处理数万份文档的企业场景，这个差距直接转化为计算成本和处理延迟。

安全性与可靠性

文档解析是一个高风险领域——恶意构造的文件可能触发解析器漏洞。Rust 的所有权系统从语言层面消除了大量内存安全问题（缓冲区溢出、use-after-free），这对于处理来源不可控的用户上传文件尤为重要。

跨语言调用

Rust 编译为本地二进制，可以通过 FFI 轻松暴露给 Python、Node.js、Go 等语言调用，不需要重写业务逻辑就能引入 Rust 级别的性能。

零配置 OCR：扫描文档的救星

Kreuzberg 的一个亮点功能是**零配置 OCR**：对于图片格式的文件（PNG、JPEG、TIFF、BMP）或扫描版 PDF，库会自动识别并触发 OCR 流程，无需开发者手动判断文件类型或配置额外参数。

这个设计决策看似微小，实则直接影响了系统的健壮性。在真实的企业文档库中，PDF 文件"是否包含可选取文本"往往无法提前知晓——有些是原生 PDF，有些是扫描后 PDF，还有些是混合型（前几页是扫描的封面，后面是电子文本）。自动检测并降级到 OCR 的能力，意味着系统不会在边缘案例上悄悄失败。

OCR 质量与配置

虽然"零配置"，但 Kreuzberg 仍然保留了对 OCR 引擎参数的精细控制接口，允许高级用户调整：

• 语言提示（对中文、日文等非拉丁文字的识别至关重要）
• 分辨率和预处理策略
• 置信度阈值过滤

RAG 管线中的定位

理解 Kreuzberg 的价值，需要把它放在完整的 RAG 架构中来看：

原始文档 → [文档提取层] → 纯文本 → [分块] → [嵌入] → 向量数据库 → 检索 → LLM
↑
Kreuzberg 的战场

Kreuzberg 解决的是最前端的"文档提取层"问题。它的输出是**结构化纯文本**，保留了文档的逻辑结构（标题层级、表格、列表），而不是把所有内容压成一行。这对下游的文本分块（chunking）质量至关重要——如果提取结果一团乱麻，再精妙的分块策略也无从下手。

与现有生态的集成

Kreuzberg 的设计考虑了与主流 RAG 框架的集成：

• **LangChain / LlamaIndex**：可作为 Document Loader 的底层引擎替换
• **自定义管线**：通过 Python 绑定（PyO3）直接调用
• **微服务架构**：编译为独立可执行文件，提供 HTTP API 接口

开源生态的"向下沉淀"趋势

Kreuzberg 的出现不是孤立现象，它代表了 AI 基础设施开源生态的一种趋势：**向更底层、更专业化的方向沉淀**。

2023-2024 年，开源社区的注意力集中在上层：向量数据库、编排框架、Agent 系统。2025 年之后，随着 RAG 应用大规模落地，底层的"脏活累活"开始被认真对待：

• 文档解析（Kreuzberg、Unstructured.io、MinerU）
• 表格理解（TableTransformer、TAPAS）
• 多模态文档处理（ColPali、DocOwl）

这些项目共同构成了企业 AI 落地的真实基础设施，而不是 Demo 层的包装。

使用场景与适合谁

Kreuzberg 特别适合以下场景：

企业知识库系统：处理内部 Wiki、合同文件、财务报表等多格式混杂的文档库，Kreuzberg 的统一接口大幅降低集成成本。

合规与审计：法律、金融行业需要处理大量扫描文件，OCR 集成和格式覆盖广度是核心需求。

多租户 SaaS 平台：用户上传文件格式不可控，需要一个能处理"任何文件"的健壮解析层，Kreuzberg 的错误处理和格式覆盖正是为此设计。

学术研究数据集构建：处理 arXiv 论文（LaTeX + PDF）、会议邮件列表（MBOX）、数据附件（Excel/CSV）等异构数据源。

总结：沉没在管线里的价值

最好的基础设施往往是透明的——用户感知不到它的存在，但一旦缺失，整个系统就会崩溃。Kreuzberg 的目标正是成为这样的存在：静静地待在 RAG 管线的最前端，把任何格式的文件变成干净的文本，让下游的嵌入模型和大模型不再为"读不懂文件"而烦恼。

对于正在搭建或优化 RAG 系统的工程师来说，Kreuzberg 值得认真评估——不是因为它解决了什么高深的 AI 问题，而是因为它**把一件基础但重要的事做对了**。