正在加载，请稍候
解析提速 20–25% 只是入口。真正要重算的是单文档摄入、扫描件返工与向量库重建这三笔账，以及先定口径再换解析器的落地顺序。
官方基线是 2.76 毫秒/页，而你的一台 300 页设备手册可能要几分钟才能进库。企业知识库 AI 的召回上限，在切片之前就被解析层定死了。
调 RAG 的力气大多花在 embedding 模型、重排和提示词上，但召回失败最常见的形态是：原文里根本没有这段文字。双栏版式被按行读错、表格被拍平成一串数字、页眉页脚混进正文、扫描件压根没有文本层——这些错误在解析阶段就产生了，后面任何重排都救不回来。
切片器只能切它拿到的文本。解析质量必须和检索质量分开归因：前者看字符级准确率与版面还原，后者才看召回率。混在一起，就永远分不清是解析器读错了，还是模型选错了片段。RAG 检索不到内容的六个常见坑 里，一半以上其实发生在这一层。
2.14.6 版本在 9 月 22 日发布，官方口径是文本提取耗时下降 20–25%。拆开看，真正影响架构决策的是三点。
维护方把 PDFium 拿来自维护，并在内部换上了 mimalloc 这类更适合短生命周期对象的分配器。落到数字上：文本提取均值 2.76 毫秒/页，markdown 渲染 3.94 毫秒/页。该库的项目说明给的整体定位是每页 2–5 毫秒级别的本地解析，全部在本地跑、不依赖云端。
含义很直接：解析从「需要排队」变成「几乎不占墙钟时间」，摄入瓶颈随之前移到 OCR 与向量写入——这两段是要花钱的。
新增的复杂页判定可以在全量解析之前，廉价地判断一页要不要走 OCR 或更重的通道，然后路由、拒绝或预估成本。对一个混着电子版与扫描件的语料库，这等于把「要不要花这笔钱」提前到了批处理开始之前。
配合边界框输出，命中片段的原文定位也能一并落库，前端可以直接把用户指回原页原位置。
版本记录里持续在补的一类问题，是并发与异常文档的处理。官方文档明确写着：PDFium 本身会把并发解析串行化。worker pool 模式用常驻进程绕开这一点，换来真并行与单文档硬超时。坏文档会被杀掉、按文件名识别，不会卡死整条流水线。
对「让用户自由上传 PDF」的知识库，这条比提速 20% 更值钱。
| 账目 | 变化方向 | 测量口径 | 隐藏风险 |
|---|---|---|---|
| 单文档摄入与增量更新 | 解析 CPU 时间下降 | 每千页端到端耗时（含 OCR 与 embedding） | 墙钟时间未必等比例下降，瓶颈前移 |
| 扫描件与复杂表格 | 准确率不变，成本可控性上升 | 字符级准确率 + 表格结构还原率 + 返工工单 | 两条通道口径不一致会造成召回漂移 |
| 向量库与 embedding 重建 | 重建窗口重新计算 | 向量条数 × 单条写入 + 评测回归时间 | 自托管编排跳版升级可能静默破坏检索 |
别把 20–25% 直接乘到端到端上。解析变快之后，摄入里剩下的时间大多是 OCR 和向量写入。该量的是每千页端到端耗时，并单独记录增量更新路径：新版本进来时，你只重算变化的那几页，还是整篇重切？
这个选择决定了索引体积会不会慢慢膨胀，也和记忆分层策略有关——知识库 AI 的记忆分层怎么设计 里有更细的取舍。
提速不解决准确率。复杂页路由把这类页面送进视觉或 OCR 通道，但两条通道的输出格式若不一致，检索时会看到风格不同源的片段。内置的 Tesseract 是零配置方案，也支持挂外部 OCR 服务；选哪条取决于你对表格结构的容忍度。
返工成本要单独记账：一页表格错切，可能带来一次人工复核工单，而工单的时间成本远高于解析本身。
解析器换了，切片边界就变了，文本分布也跟着变。老向量不是「错」，而是与新的切片口径不同源。混在同一个集合里，检索会返回口径不一致的片段——所以换解析器几乎总要跟一次重建，窗口大致等于向量条数乘以单条写入耗时，再加上评测回归的时间。原生向量搜索在选型上的三个影响 值得先读一遍再动手。
模型换代本身是重建窗口的另一个来源：2026 年 9 月 11 日的一轮嵌入模型目录盘点统计了 37 个条目，可选空间还在扩大。换 embedding 等于换向量空间，和换解析器叠加，重建成本是相乘的。
这里有个反复被提到的坑：自托管 Dify 使用内置 Weaviate 时，跨 12 个次要版本不支持跳版升级。直接拉新镜像重启，可能静默地让向量检索失效——表面现象是「库还在，就是搜不到东西」。这类升级必须先在副本上跑冒烟测试并逐条核对检索结果，容器健康状态说明不了任何事。编排层面的细节可以先参考 Dify 私有化部署的落地经验。
顺序反了，代价不是多花一天，而是两周查不出问题出在哪一层。这三步和 RAG 落地的六个工程决策 是同一套节奏。
最常见的一种翻车是这样的：团队看到解析提速 20–25%，顺手把 embedding 也一起升级了。上线后召回从 0.72 掉到 0.61，查了两周——两个变量同时动，任何归因都不成立。
纪律只有一条：一次只动一层，动手之前留一份基线快照。解析层的基线是准确率与失败页清单，检索层的基线是召回与命中位置。
不能。解析只是链路的一段。如果你的管道里 embedding 调用与 OCR 占了大头，端到端提升会被摊薄。先量清楚自己管道里各段的耗时占比。
两者并存。该库自带 Tesseract 做零配置 OCR，也可以接外部 OCR 服务；路由负责决定哪一页走哪条通道，而不是取代它们。
只要切片边界或文本分布变了，就一定要。判断标准是新旧两版切出来的片段能否逐条对齐，不能对齐就重建。
三张表：字符级准确率、表格结构还原率、失败页清单。前两张决定召回上限，第三张决定运维成本。
如果你正在评估解析层换代，可以把语料样本与现有切片口径发过来。蓝曜炬辉 的工程团队会先跑一轮解析质量基线与重建窗口评估，再给换与不换的判断。联系我们 开始，也可以先看 已交付的知识库项目。