现在用大模型做文档问答、做摘要，已经是很多人的日常操作了。但如果你想把这套东西真正做成能上线的 Agent 产品，或者搭一套企业级的 RAG 系统，却没有那么容易。因为到了生产环境，很多问题并不出在模型上，而是出在更前面的一步——文档解析。

Agent 能力再强，也只能根据拿到的上下文工作。金融行业的财报、招股书，科研领域的论文和实验报告，往往包含复杂表格、脚注、公式和跨页内容。解析时一旦打乱结构，后面的检索和推理就失去了可靠基础。

今天我们就来对比一下 Reducto、LlamaIndex、Unstructured.io、MinerU 和 Knowhere 五款工具，帮你在不同场景找到合适的选型。

一、选工具前，先看文档和任务

做文档解析，不是只看“哪款工具最强”这么简单，而是要先看看：手里的文档是什么样的，Agent 要拿它做什么？

文档是什么样、从哪里来

现实中的资料很少整整齐齐地放在一种格式里。PDF、PPT、Word、网页、扫描件、表格和图片往往混在一起，质量也参差不齐。

常见文档大致有以下几类：

金融文档：年报、季报、授信备忘录、贷款协议、结构化融资披露等。表格密集、脚注复杂，跨页内容很多。

科研与技术文档：多栏论文、带公式和图表的技术报告、实验记录等。难点在阅读顺序、公式识别以及正文和图表之间的引用关系。

医疗与政务文档：扫描病历、表单、政府文件等。低清图片、手写内容和不统一的格式比较常见。

企业知识库：制度文件、流程手册、项目报告、邮件和会议纪要。格式多、来源散、更新频率高。

创作类文本：小说、世界观设定、游戏策划案等。需要保留人物、地点、事件和时间线之间的关系。

这些文档可能来自业务系统、邮件附件、云盘，也可能是多年前留下的扫描件。选型前最好先盘点文件类型、来源和质量，再设计完整流程：接入、转换、清洗、切片、向量化和分发。只比较一次解析的结果，通常看不出工具在真实环境里的表现。

Agent 要完成什么任务

不同任务对解析结果的要求差别很大，大致可以分成三类：

检索型任务：例如研究助手和知识库问答。重点是找到正确片段，并给出可信的出处。解析时如果弄错标题层级、阅读顺序或页码，检索结果也会跟着偏。

决策支持型任务：常见于金融、医疗和合规场景。Agent 不仅要回答问题，还要根据抽取字段和业务规则作出判断。这类任务通常需要固定的数据结构、字段置信度和原文引用。

工作流型任务：Agent 需要生成工单、更新系统或发送通知。解析结果必须稳定、结构明确，才能安全地交给下游系统。

当然，还要考虑出错的代价。个人知识库漏掉一段内容，可能只是多花几分钟核对；医疗或合规文件中识别错一个字段，却可能带来业务、监管甚至法律风险。任务越重要，对可追溯性、稳定性和人工复核机制的要求就越高。

二、评价 PDF 解析工具，看哪些指标

文档解析的目标不是把 PDF 变成一堆文字，而是尽可能保留原文结构，并输出适合后续检索和处理的数据。可以重点看以下七项。

1. 文档还原度

解析器能否正确识别标题层级、段落顺序、页眉页脚、分栏和脚注？对多栏论文和复杂财报来说，这决定了内容还能不能被正确阅读。

2. 表格和公式处理

表格最怕“数字还在，关系没了”。如果行列、表头、单位或币种被拆散，后续计算很容易出错。跨页表格、合并单元格和公式，也是拉开解析工具差距的地方。

3. OCR 和多模态能力

扫描件没有可直接提取的文本，必须依赖 OCR；复杂图表和图片型文档还需要视觉模型参与。MinerU 在视觉模型与 OCR 结合方面投入较多，适合图片型 PDF、多语种和复杂版式。Unstructured 则把 OCR 放进更完整的数据预处理流程中。

4. 输出结构

输出纯文本、Markdown、通用 JSON，还是已经切好的 RAG 数据，差别很大。LlamaParse 更方便接入 LlamaIndex 的 RAG 流程；Unstructured 输出通用的结构化数据；Knowhere 侧重生成可直接用于 RAG 的切片和结构化 JSON。选择时要看它能否顺畅接入现有技术栈，而不是只看展示页面是否漂亮。

5. 可追溯性和置信度

在金融、医疗和合规场景，答案必须能回到原文。页级引用、字段置信度和人工复核队列都很重要。只有“抽取结果”而没有来源位置，很难用于高风险业务。

6. 规模、稳定性和数据治理

批量处理时要看并发能力、失败重试、监控、服务等级协议以及权限管理。Reducto 更强调大规模处理和企业级服务；Unstructured 支持私有云、VPC 和裸金属部署，更适合重视数据治理和数据主权的组织。

7. 总成本

价格不能只看每页多少钱。Reducto、LlamaParse 和 Unstructured 的云服务通常按用量或页数收费；MinerU 虽然开源，但需要承担 GPU、存储、运维和工程投入；Knowhere 同时提供 API 和本地部署方案。还要把后续的 token 消耗、人工校对和失败重跑算进去，才能看到真实成本。

三、几种常见的技术路线

目前的 PDF 解析方案大致有五类：

纯文本抽取：速度快、成本低，适合排版规整的普通 PDF；遇到多栏、复杂表格和扫描件时能力有限。

版式感知解析：根据页面布局恢复标题、段落、表格和阅读顺序，是处理财报和科研论文的核心能力。

OCR 优先：先识别图片中的文字，再做结构恢复，主要用于扫描件和历史文档。

智能抽取：让大模型根据任务动态选择抽取策略，对复杂表格或多来源内容做多步处理。Reducto 的 DeepExtract 和 LlamaIndex 的智能检索都体现了这种方向。

混合流程：按文档类型组合不同工具。企业实际使用时，通常还会加入清洗、切片、向量化、路由和人工审核，不会只依赖一个解析器完成所有工作。

技术路线没有绝对高下。文档简单、量大、要求低时，轻量方案往往更划算；文档复杂、错误代价高时，则要优先考虑结构还原、可追溯性和人工复核。

四、五款工具分别适合什么场景

这五款产品定位不同，不宜只按解析准确率排一个总榜。

工具	核心定位	适合谁	典型场景	部署方式
Reducto	企业级智能文档平台，覆盖解析、分类、拆分和抽取等流程	有成熟 AI 基础设施，并且需要规模化处理和合规审计的中大型机构	财报、合同、保险文件等高价值文档	托管云服务，按用量计费，提供企业方案
LlamaIndex / LlamaParse	面向开发者的 RAG 与 Agent 框架，串联解析、索引、检索和答案生成	独立开发者和中小型技术团队	内部知识库、客服机器人、轻量 Agent	开源框架加 LlamaCloud，LlamaParse 按用量计费
Unstructured.io	多格式文档的数据预处理基础设施	企业数据团队和传统 IT 部门	多来源文档接入、清洗和标准化	公有云按页计费，也支持自托管、VPC 和裸金属部署
MinerU	开源多模态解析引擎，强调视觉模型与 OCR	有自建算力和工程能力的团队、研究者	科研 PDF、图片型报表、多语种和复杂排版	开源、自托管，也提供有限额的 API
Knowhere	面向 Agent 与 RAG 的知识预处理层，输出可追溯的结构化切片	金融和科研 RAG、企业知识库、桌面 Agent 的开发团队与个人	财报和论文解析、表格保留、页级引用	开源版本加托管 API，支持 MCP 集成

它们并不完全互斥。比如，团队可以用 Knowhere 处理复杂 PDF，用 LlamaIndex 负责索引、检索和工具编排，再让 MinerU 补充某些扫描件、多语种或复杂版式。这种组合是否值得，取决于文档种类和维护成本。

如果你的重点是把财报、研报、论文等复杂 PDF 变成可检索、可追溯的知识，而不是只拿到一段纯文本，Knowhere 可以作为独立的文档预处理层使用。它更适合放在 RAG 和 Agent 之前：先保留文档层级、表格和页码引用，再把整理后的内容交给 LlamaIndex、向量数据库或现有的 Agent 框架。

对团队来说，这种分层方式的好处是，解析能力不必和后续的检索、模型或业务工作流绑定在一起。后续即使替换 RAG 框架或模型，已经处理好的文档资产仍可继续复用。

Knowhere：github.com/Ontos-AI/knowhere

五、按场景选择工具

科研论文和学术资料

科研场景通常不满足于“生成摘要”，还需要准确定位章节、公式、图表和实验结果，并保留它们之间的引用关系。

希望深度控制模型和解析流程的团队，可以考虑 MinerU；想快速搭建论文问答和检索系统，可以使用 LlamaIndex；既需要结构化切片，又重视页码引用和结果溯源时，可以把 Knowhere 作为论文解析层。

财报、年报和研究报告

金融文档的难点主要在复杂表格、脚注、单位和交叉引用。银行、私募和资产管理机构如果已有成熟的 AI 基础设施，并且需要批量处理和审计能力，可以考虑 Reducto。它提供按结构抽取、字段置信度和原文引用等能力。

如果重点是把年报和研究报告整理成适合检索的结构化切片，Knowhere 可以作为高价值 PDF 的专用处理层，减少下游检索中的无效内容和人工核对。

医疗、政务和其他高合规文档

这类文档往往包含低清扫描件、手写内容和敏感信息。部署位置、权限管理与审核流程，通常和解析精度同样重要。

有私有化部署要求时，可以关注 MinerU、Knowhere 或支持私有环境的 Unstructured。解析结果进入业务系统前，还应设置置信度阈值和人工复核，确保审查人员能直接查看字段对应的原文和页码。

企业知识库和内部搜索

企业知识库通常同时包含 PDF、PPT、网页、邮件和工单，不太可能由一个工具处理所有问题。

Unstructured 适合负责多格式文档的接入和标准化；LlamaIndex 负责索引、检索和路由；Knowhere 可以专门处理财报、技术报告等结构复杂的 PDF。三者对应的分别是数据预处理、检索编排和复杂文档解析。

个人知识库和桌面 Agent

个人用户最常见的需求，是把小说、笔记和报告解析一次，之后按需检索，而不是每次对话都把整份 PDF 塞进上下文。

LlamaIndex 适合搭建本地知识助理，并接入文件、网页和 SaaS 数据；Knowhere 的解析 API 和 MCP 接口，则适合把文档预先整理成可复用的结构化知识。选择云端还是本地方案，要看隐私要求、使用频率和维护能力。

六、如何测试和决定

1. 用自己的文档做评测

不要只看厂商 Demo。挑一批真实文档组成评测集，其中既要有普通 PDF，也要有扫描件、多栏论文、跨页表格、脚注密集页面和长文档。针对每类文档，提前定义什么算解析成功、哪些错误可以接受。

同一套评测集既可以比较 Reducto、LlamaParse、Unstructured、MinerU 和 Knowhere，也可以用来判断自建方案与托管 API 的差距。

2. 评估下游效果

字段识别准确率只是一个指标，更重要的是解析结果进入 RAG 或 Agent 后表现如何。建议至少记录：

• 检索命中率；

• 答案是否能追溯到原文；

• 每份文档的人工校对时间；

• token 消耗、延迟和总体成本；

• 失败类型、重试次数和修复成本。

有些工具解析结果看上去很整齐，但切片不适合检索；有些工具单页成本较高，却能明显减少人工校对和后续 token 消耗。只有放到完整流程里测试，才能判断是否划算。

3. 决定用单一平台还是组合方案

已经有成熟 AI 平台、文档量大且合规要求高的机构，可以围绕 Reducto 或 Unstructured 建立主流程，再用专用解析器补充复杂文档。

以开发者为主、场景变化较多的团队，可以用 LlamaIndex 负责 RAG 和 Agent 编排，再按需接入 Knowhere、MinerU 等工具。个人项目则不必一开始就搭复杂架构，先用少量真实文档验证解析质量和检索效果，再决定是否增加组件。

最后

选 PDF 解析工具，关键不是找一个“全能冠军”，而是你得看：它能否处理你的文档，输出能否满足 Agent 的任务要求，整体成本是否可接受。

对复杂 PDF 较多、又希望保留页码引用和文档结构的团队，可以考虑把 Knowhere 作为前置解析层，再接入已有的 RAG 或 Agent 框架。先用真实文档验证解析和检索效果，再决定是否扩大使用范围，通常比一开始重构整套系统更稳妥。

Knowhere：github.com/Ontos-AI/knowhere

把这一步做好，Agent 才能拿到结构清楚、来源可信、真正可用的上下文。

参考资料

Unstructured 官方博客：《Understanding What Matters for LLM Ingestion and Preprocessing》

LinkedIn：《LlamaIndex: From Simple Usage to Agentic AI Workflows》

《Agentic RAG with LlamaIndex: Multi-Step Reasoning Capability》

LlamaIndex 官方博客：《RAG is Dead, Long Live Agentic Retrieval》

Y Combinator 相关动态：《Deep Extract from Reducto》