我试了各种PDF解析工具为我的聊天应用——只有一个是管用的

作者供图

作为KDB.AI的开发者支持者，我对向量数据库、嵌入式技术和语义搜索非常熟悉。所以，当我决定开发一个免费开源的应用程序时，我认为这应该不难。毕竟，我过去曾深入研究过PDF处理，并且对此有很多研究和写作。

但我错了，非常错误。

在预算内创建一个全栈PDF聊天应用结果发现相当有挑战性。这里我尝试了所有不起作用的方法，还有最后奏效的那个方法。

这里就是这款应用的样子，你可以免费在pdfgpt.dev上试试看！无需注册即可上传任意数量的PDF文件——至少目前是这样子，直到有人让我后悔做这个决定为止。

作者供图

我尝试了各种方法，从最明显的入手。

1. LlamaParse：质量很棒，用到大规模时就比较贵

我首先使用了LlamaParse，它提供了出色的解析质量。我跳过了Unstructured，因为它一开始的价格就显得过高。实施非常快，结果也确实很好。问题是免费层很快就用完了，甚至在我完成开发之前就用完了。以每1,000页1美元的价格，对于一个需要保持免费的开源演示应用来说，这样的费用是不可行的。考虑到用户可以一次上传数百页，而如果有VLM的话，成本至少会增加六倍。

2. Chunkr：质量还可以，不过速度太慢了

接下来，我试用了Chunkr，它的价格比LlamaParse更便宜。解析质量非常好，，但是即使在最快模式下，处理时间仍然过长，对于交互式应用来说，处理时间仍然过长。用户不会等待10-20秒甚至更长时间上传小型PDF文件。我不确定它为什么比LlamaParse慢，也不排除我没有正确配置它。

3. PDF.js 客户端解析：速度快但质量较差

为了去掉服务器成本，我尝试用PDF.js在浏览器中解析。这种方法意外地快，而且不需要服务器处理！不过，输出质量明显不如服务器端的方法。

其中一些具体的问题有：

• 错误的字母处理方式
• 较差的词边界识别
• 缺少的文本元素
• 混乱的格式

如果我能找到一种方法让质量提高50%，那可能就是最好的办法。

4 服务器端 Next.js 和 LangChain：受限于无服务器约束

于是我尝试了通过Next.js API路由进行服务器端处理PDF，使用了LangChain的PDFLoader（它底层使用了pdf-parse库）。处理效果比在客户端使用PDF.js要好，但是遇到了无服务器架构的限制。

Next.js 的 API 路由有一个 4.5MB 的大小限制，用户上传多个 PDF 文件时会很快触及这个限制。我本应一开始就能预料到这个限制。这使得使用 Next.js 进行服务器端处理变得不太可能。此外，这个加载器表现也不太好，仅仅比 PDF.js 稍微好一点。不过它可能在底层使用了 PDF.js，我也不太确定。

Python后端解决方案：用于PDF处理

注：原文标题中使用了“#”符号，此处保留以示与原文格式一致。但实际上在中文中不常用此符号。

尝试了所有这些选项后，我最终选择了最显而易见的方案：一个专门用于PDF处理的Python后端服务。相比之下，JavaScript生态系统缺乏像Python那样的优秀PDF解析工具。

我实现了一个使用LangChain和PyPDF作为底层技术的FastAPI后端，该方法最终为我提供了我所需要的性能与质量的平衡。它仍然比我期望的要慢一些，但解析质量还是使其值得的。

    ┌────────────┐       ┌────────────┐       ┌─────────────┐  
    │            │       │            │       │             │  
    │   PDF 文件 │ ─────▶│  FastAPI   │ ─────▶│  处理的块   │  
    │            │ 上传至│  后端      │ 解析 │             │  
    └────────────┘       └────────────┘       └─────────────┘  
                                                     │  
                                                     ▼  
    ┌────────────┐       ┌────────────┐       ┌─────────────┐  
    │            │       │            │       │             │  
    │ 带有上下文的│◀──────│   向量搜索  │◀──────│   KDB.AI    │  
    │ LLM 回复   │       │            │ 查询 │   数据库    │  
    └────────────┘       └────────────┘       └─────────────┘

经验教训

要是能让我重新来过，我就会从一开始就用Python后端。JavaScript世界现在还不适合高质量的PDF解析，。几点关键心得：

1. 不要对抗生态系统：使用适合工作的正确工具，哪怕这意味着要在你的技术堆栈中引入新的语言或服务。
2. 客户端解析具有潜力：虽然这会导致质量下降，客户端解析在免费应用中扩展性非常好，因为处理是在用户的机器上进行的。这种方法在经过更多努力后可以得到优化。
3. 尽早考虑你的限制：如果我早点了解无服务器的限制，就能节省很多时间，并且从一开始就缩小选择范围。
4. Python在文档处理方面更胜一筹：Python生态系统中用于文档处理的工具更加成熟。这些Python库的表现远远优于它们的JavaScript同类库。

接下来会是什么呢？

我仍然在维护带有Python后端解决方案的PDF Chat应用，一切运行得都很不错。我的最终目标是创建一个开源工具，任何人都可以部署，无需API密钥，也无需承担高昂费用。

我也在尝试运行自己的PDF解析微服务，可能使用纯Gemini来做解析，但这留待以后再谈。纯Gemini（vanilla Gemini）

朋友们，访问GitHub仓库看看是怎么应对这些挑战的。

你有没有在处理PDF时遇到过类似的挑战？我很想听听你在评论区或GitHub上的经历和解决方案。让我们一起努力，让网页上的应用中的PDF处理更好起来！