分享一下给 AI Agent 挑解析工具的经验

[cs1707]

现在用大模型做文档问答、做摘要，已经是很多人的日常操作了。但是要做成能上线的 Agent 产品，或者搭一套企业级的 RAG 系统，就不太够用了。一是生产环境的文档往往没有那么简单，二是单纯使用大模型有点太贵了。所以，我一般会挑解析工具，来进行辅助。

接下来讲讲怎么挑。

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

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

生产环境的文档，大致有以下几类：

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

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

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

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

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

然后是看看你的 Agent 要完成什么任务。不同任务对解析结果的要求差别很大，大致可以分成三类：

- 检索型任务：例如研究助手和知识库问答。重点是找到正确片段，并给出可信的出处。

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

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

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

二、常见的几种技术路线

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

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

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

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

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

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

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

三、常见的解析工具介绍



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

四、按场景选择工具

- 科研论文和学术资料

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

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

- 财报、年报和研究报告

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

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

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

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

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

- 企业知识库和内部搜索

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

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

- 个人知识库和桌面 Agent

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

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

五、选型和测试

评价一个解析工具靠不靠谱，我们一般看以下几个指标：

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 消耗、人工校对和失败重跑算进去，才能看到真实成本。

最后，敲定了方向，应该怎么测试呢？

1. 用自己的文档做评测

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

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

2. 评估下游效果

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

- 检索命中率；

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

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

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

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

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

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

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

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

总结一下，选 PDF 解析工具，不是说要找一个全能冠军，只要它能满足你的业务需求，成本又可以接受，那就 OK 。

我自己的话也是这么操作的，面对复杂 PDF 较多、又希望保留页码引用和文档结构的科研场景，我会把 Knowhere 作为前置解析层，再接入已有的 RAG 或 Agent 框架。先用真实文档验证解析和检索效果，再决定是否扩大使用范围，通常比一开始重构整套系统更稳妥。

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

同行的朋友如果有需要，可以试试： https://knowhereto.ai/github?utm_source=v2ex