现代文档流水线不只需要“读出文本”,还需要一致的元数据、多格式稳定处理和批量性能。Kreuzberg 的定位正是这一层:Rust 内核 + Python 绑定,便于直接接入现有 Python 系统。
步骤 1:安装
python -m pip install kreuzberg
步骤 2:同步提取单个 PDF
from kreuzberg import extract_file_syncresult = extract_file_sync('document.pdf')print(result.content)print(f"Pages: {result.metadata['page_count']}")
步骤 3:原生异步示例
import asynciofrom pathlib import Pathfrom kreuzberg import extract_fileasyncdefmain(): pdf_path = Path('document.pdf')if not pdf_path.exists():raise FileNotFoundError(f'File not found: {pdf_path}') result =await extract_file(str(pdf_path))print(result.content[:200])print(f"Pages: {result.metadata['page_count']}")if __name__ =='__main__': asyncio.run(main())
步骤 4:批量处理多个 PDF
from pathlib import Pathfrom kreuzberg import batch_extract_files_syncpaths =list(Path('documents').glob('*.pdf'))results = batch_extract_files_sync([str(p)for p in paths])for path, result inzip(paths, results):print(f"{path.name}: {len(result.content)} characters")
步骤 5:扫描件 OCR
from kreuzberg import extract_file_sync, ExtractionConfig, OcrConfigconfig = ExtractionConfig( ocr=OcrConfig(backend='tesseract', language='eng'))result = extract_file_sync('scanned.pdf', config=config)print(result.content)
运行 Tesseract 示例前,需要准备语言数据文件(例如 eng.traineddata),并确保环境变量 TESSDATA_PREFIX 指向对应目录,否则会出现 Failed loading language 'eng' 之类的初始化错误。
步骤 6:PaddleOCR 示例(中文文档)
from kreuzberg import extract_file_sync, ExtractionConfig, OcrConfigconfig = ExtractionConfig( ocr=OcrConfig(backend='paddleocr', language='zh'))result = extract_file_sync('scanned.pdf', config=config)print(f'Extracted content (preview): {result.content[:100]}')print(f'Total characters: {len(result.content)}')
如果你要让这段代码在新环境里直接运行,记得先安装运行时依赖:
python -m pip install--upgrade onnxruntime
如果仍报 libonnxruntime.so 加载失败,再把 onnxruntime/capi 目录加入 LD_LIBRARY_PATH(Linux)。
Kreuzberg 支持 Tesseract / EasyOCR / PaddleOCR,适合多语言场景中按文档质量切换后端。
扫描 PDF
扫描件不含可选择文本,必须依赖 OCR。成熟流水线通常会先判断是否缺失文本,再按需触发 OCR 并与结构信息合并。OCR 质量受语言、分辨率和图像噪声影响很大,因此可切换后端非常关键。
表格与结构化内容
表格是另一个难点。即使单元格文本提取成功,行列关系也容易丢失。对财报、论文、运营报表而言,保留表格结构往往直接决定下游可用性。
性能与扩展
当规模从几十份上升到成千上万份文档时,解析阶段的低效会立刻放大成成本问题。影响性能的核心包括:解析引擎实现方式、内存管理策略、并发模型。很多现代工具选择“编译型核心 + 语言绑定”,就是为了在吞吐和稳定性上更可控。
在现代流水线中的位置
提取只是第一步。后续通常是:切分(chunking)-> 嵌入(embeddings)-> 向量库检索。可靠的提取质量是整个搜索 / RAG 系统的地基。
常见坑
- 误以为所有 PDF 都类似
- 用单一数据集评估,忽略扫描件 / 多栏 / 长报告
- 忽略元数据(页码、标题、来源结构)
这些问题会在上线后迅速暴露,且直接影响引用、可追溯性和答案质量。
总结
在 2026 年,Python 做 PDF 提取比过去容易很多,但结构恢复和排版复杂性并没有消失。选对工具能显著提升后续搜索、RAG、分析系统质量。
为什么我们做 Kreuzberg
我们做 Kreuzberg 的起点很直接:在实际流水线里,文档提取反复成为瓶颈。现有工具要么在真实文档上失败率高、要么吞吐不够、要么成本不匹配。最终我们选择 Rust 核心 + 多语言绑定架构,来平衡性能、稳定性与可用性。