我们花了一些时间修复 PipesHub 中的 PDF 解析问题。分享一下哪些方法有效，哪些无效。

大家好，我是 PipesHub 的创始人之一。先介绍一下背景：PipesHub 是一个面向 AI 智能体的开源上下文层。它连接 Slack、Drive、Jira、GitHub、Microsoft 365 等平台，让用户和智能体能够在遵守访问权限的前提下搜索公司知识，并获得引用来源。你可以自行部署，也可以通过 MCP 或 SDK 接入自己的智能体。PipesHub 需要能在从普通笔记本电脑到大型服务器的各种设备上运行。PDF 解析让支持笔记本电脑这件事变得相当困难。在我们的环境中，有些大型 PDF 用 Docling 就是无法完成解析。内存占用会变得过高，而且即使能完成，解析也要花很长时间。我们尝试了多种解决办法，包括将 PDF 拆成更小的部分，但对于我们希望支持的机器来说，负担依然太重。因此，我们基于 pdfplumber 构建了另一条 PDF 解析流程。读取 PDF 中已有的文本，使用规则处理版面，并在需要的页面上运行版面分析模型。实际上，这里我们仍然使用 Docling 的 heron 模型。第一个版本速度很快，却遗漏了重要内容。一些财务表格被当成了图片，导致其中的数字根本没有进入索引。我们必须先解决这个问题，速度提升才真正有意义。修复这些问题后，部分结果如下：解析耗时中位数：在对 58 份文档连续进行的测试中，从每页 0.98 秒降至 0.48 秒。工作进程峰值内存的第 95 百分位数（P95）：在 1,228 份文档中，从 2.91 GB 降至 1.97 GB。丢失超过一半文本的页面占比：2.9% → 1.2%。Docling 在图形检测、表格结构和图表说明文字方面仍然表现更好。对于我们的工作负载——主要是已有文本层的 PDF——这是一个有价值的取舍。我们写了一篇文章，介绍具体方法、基准测试以及没能奏效的尝试：完整文章 代码：github.com/pipeshub-ai/pipeshub-ai 还有人在尝试让配置较低的机器也能完成 PDF 数据导入吗？很想听听哪些方法对你们有效。