从 PDF 到答案:Kreuzberg 如何撑起在线文档问答的第一公里

我们是谁

我们在做一个 AI 工作助理（飞书机器人），用户通过自然语言和机器人对话来处理日常工作——任务管理、日程安排、文档处理等。

其中一个高频场景是：用户发一份 PDF 过来，问一个问题，期望立刻拿到答案。

这要求我们的文档处理管道必须足够快、足够稳定，因为用户在聊天窗口里等着。

为什么选择 Kreuzberg

我们评估过多种文档提取方案，最终选择 Kreuzberg 作为在线管道的提取层。核心原因：

1. 启动快、冷启动开销低

在线 AI 系统是请求驱动的——用户发一条消息，系统必须在几秒内响应。文档提取只是整个链路的第一步，后面还有语义过滤、LLM 推理、回复生成。如果提取阶段就吃掉大量时间预算，后续环节的质量就要打折扣。

Kreuzberg 的实测表现：

• 文本型 PDF 提取：~10ms 级别
• 图片 OCR（PaddleOCR 后端）：平均 ~2.2s/张
• 90+ 种文件格式统一入口

2. 智能路由，按需 OCR

不是所有 PDF 都需要 OCR。Kreuzberg 会自动检测文本层——有文本层的直接提取（快路径），没有的才走 OCR（慢路径）。在真实业务流量中，大部分文档是有文本层的，这意味着大多数请求走的是快路径。

3. 统一 CLI，减少编排复杂度

一个 kreuzberg extract 命令处理 PDF、Word、PPT、图片、扫描件。不需要针对不同文件类型写分支逻辑，运维和排障都简单。

我们怎么用：提取 + 语义过滤管道

我们的管道模式很简单——两个阶段：

Stage A: kreuzberg extract（文档 → 文本）Stage B: 语义过滤/重排（文本 → 和问题最相关的段落）

通用模板：

kreuzberg extract <文件>[--force-ocr true] --output-format markdown \|sed'/^\s*$/d'\| jina-grep "<自然语言查询>" --top-k <K>--threshold<T>

这个分离架构的好处是：Kreuzberg 专注提取，不需要理解查询意图；语义层可以独立升级，换模型、换重排器都不影响提取阶段。

6 个真实业务场景

1. 售后支持——产品手册快速定位

场景：客服收到用户问题”设备离线后怎么恢复”，需要从 200 页产品手册中找到答案。

管道：

kreuzberg extract manuals/device_troubleshooting.pdf --output-format markdown \|sed'/^\s*$/d'\| jina-grep "设备离线后如何恢复连接，需要哪些检查步骤" --top-k 5--threshold0.30

价值：用户在聊天窗口等着。Kreuzberg ~10ms 完成文本提取，语义过滤立刻开始——没有冷启动延迟吃掉响应预算。

2. 合同条款风险筛查

场景：法务需要在供应商合同中查找”自动续约条款、提前通知期限、单方解约条件”。部分合同是扫描件。

管道：

kreuzberg extract contracts/vendor_agreement_scan.pdf \  --force-ocr true --output-format markdown \|sed'/^\s*$/d'\| jina-grep "自动续约条款、提前通知期限、单方解约条件" --top-k 8--threshold0.25

价值：扫描件走 OCR，电子合同走快路径，同一条命令处理混合合同集。法务从”逐页翻阅”变成”审核候选条款列表”。

3. 项目复盘——周报要点提炼

场景：项目经理准备复盘会，需要从 12 份周报 PDF 中找到”延期原因、关键阻塞、已采取措施”。

管道：

forfin reports/weekly/*.pdf;do  kreuzberg extract "$f" --output-format markdowndone\|sed'/^\s*$/d'\| jina-grep "项目延期原因、关键阻塞、已经采取的改进动作" --top-k 10--threshold0.28

价值：12 份 PDF 批量提取在数秒内完成（大多是文本型）。复盘准备从”全量阅读”变成”重点核对 10 个最相关段落”。

4. 技术文档问答——设计文档检索

场景：研发问”重试策略和幂等要求在哪里定义的”，需要从 RFC 和设计文档中定位。

管道：

forfin docs/rfc/*.pdf;do  kreuzberg extract "$f" --output-format markdowndone\|sed'/^\s*$/d'\| jina-grep "接口重试策略、幂等键、失败补偿机制" --top-k 6--threshold0.30

价值：替代手动 grep 关键词搜索。语义过滤能找到概念相关但用词不同的段落，减少漏看风险。

5. 审计合规——证据采集

场景：内审需要在制度文档中查找”权限审批流程、操作留痕要求、例外处理闭环”等证据。

管道：

forfin compliance/*.pdf;do  kreuzberg extract "$f" --output-format markdowndone\|sed'/^\s*$/d'\| jina-grep "权限审批流程、日志留痕要求、例外审批闭环" --top-k 12--threshold0.22

价值：审计人员面对大量制度文档，快速提取 + 语义过滤把”人工盲查”变成”审核排序候选清单”。

6. 招投标——标书要点提取

场景：售前需要快速定位招标文件中的”投标资质要求、交付里程碑、违约责任与罚则”。

管道：

kreuzberg extract tenders/rfp_2026Q1.pdf --output-format markdown \|sed'/^\s*$/d'\| jina-grep "投标资质要求、项目交付里程碑、违约责任和罚则" --top-k 8--threshold0.26

价值：投标响应时间紧张。文档分析从数小时缩短到数分钟，直接缩短投标准备周期。

我们的实测数据

基于 Runner 容器内 x86_64 CPU + PaddleOCR 后端的实测结果：

指标	数据
文本型 PDF 提取	~10ms（无需 OCR）
图片 OCR 耗时	平均4.8s，纯英文可低至 ~188ms）
识别准确率	10 组测试中 8/10 完全正确，2/10 轻微空格/标点偏差
中文 OCR 内存峰值	~229MB
英文 OCR 内存峰值	~87MB
PDF 文本提取内存	~19MB
二进制 + Runtime 体积	kreuzberg ~42MB + ONNX Runtime ~22MB + 中文模型 ~86MB

为什么不用更重的方案

市面上有些文档解析方案提供更深度的版面分析，但也带来更高的运行时和启动开销。对于离线批处理、追求极致精度的场景，那是合理的。但对于在线 AI 助手，我们的优先级是：

1. 延迟可预测 — 用户在等
2. 提取质量足够用于检索 — 不需要完美还原版面
3. 运维可靠 — 部件越少越好
4. 规模成本可控 — 不能为提取预热大量资源

Kreuzberg 和这个优先级完全对齐。

一句话总结

对于”文档多、问题明确、用户在等”的在线场景，Kreuzberg 的启动速度和务实的提取策略是战略优势。我们把它作为在线知识管道的默认提取基座。