券商研报 PDF 解析器选型与改造实战：MarkItDown / MinerU / Marker 对比与四层解析链落地

• 金融科技
• 示例工程

本文围绕 broker-research-analyst skill（egs_skill/broker-research-analyst）的 PDF 解析链路展开：先对 pdfplumber、MarkItDown、MinerU、Marker 四类工具做面向券商研报场景的系统对比，再给出"按需分层"的选型策略，最后结合仓库中已落地的 pdf_parser.py 四层解析链实现与实测数据，说明如何用 MarkItDown 升级主解析路径、保留 pdfplumber 兜底、按需启用 MinerU。读完本文，你将掌握研报 PDF 场景下的工具选型方法论、分层解析架构设计，以及可直接复用的命令行与配置实践。

一、调研背景：为什么评估替换 pdfplumber

broker-research-analyst skill 的定位是"研报获取 → 结构化提取 → 多机构观点对比 → 风险识别 → 决策辅助"全链路。其中研报 PDF 的文本抽取原本依赖pdfplumber + PyPDF2，核心痛点是：

• 段落结构保留弱：投资要点/盈利预测/风险提示等固定段落难以精确定位；
• 复杂表格识别弱：财务预测表（EPS/PE/营收预测）容易文本散乱；
• 格式兼容性差：实测中部分 PDF 直接报No /Root object错误而整体失败（见第八节实测数据）。

因此调研评估是否升级为MarkItDown / MinerU / Marker等新一代工具。调研时间为 2026-06-27，改造实施已于同日完成方案 A。

二、主流工具对比矩阵

下表从开发方、License、部署难度、速度、中文支持、表格/公式/OCR、结构保留、多格式与 MCP 集成等维度，完整对比四个候选工具：

注：上述 Star 数、速度、准确率等指标来自调研报告原始记录，具体数值会随版本演进变化，落地前应以实测为准。

三、券商研报场景适配性分析

3.1 研报 PDF 特征

• 语言：中文为主；
• 格式：多数为文本型 PDF（非扫描件），少数深度报告含扫描图表；
• 结构：相对规范，含"投资要点/盈利预测/风险提示"等固定段落；
• 关键内容：
  • 文本段落（投资逻辑）→ 需段落级提取；
  • 财务预测表格（EPS/PE/营收预测）→ 需精准表格识别；
  • 评级/目标价（散落正文）→ 需文本+上下文；
• 篇幅：10-50 页；
• 公式：罕见（金融研报基本无数学公式）。

3.2 各工具适配评分（针对研报场景）

四、推荐方案：按需分层，而非"一刀切"替换

不建议直接替换现有解析器，采用按需分层策略最优。

方案 A：MarkItDown 为主 + pdfplumber 兜底（轻量推荐）⭐⭐⭐⭐

研报 PDF ↓ MarkItDown 转换（默认） → 产出 LLM 友好的 Markdown ↓ 失败/表格复杂时 pdfplumber 兜底（现有逻辑）

优点：

• 安装极简（pip install markitdown[pdf]），无 GPU 依赖；
• 微软维护、MIT 许可，商用无风险；
• 专为 LLM 设计，输出 token 高效；
• 有 MCP Server，可与 TRAE/Claude 原生集成。

缺点：

• 复杂表格识别一般（财务预测表可能丢格式）；
• 需 Azure Document Intelligence 才能处理扫描件（付费）。

适合：MVP 阶段、轻量部署、多数文本型研报。

方案 B：MinerU 为主（高精度推荐）⭐⭐⭐⭐⭐

研报 PDF ↓ MinerU 解析 → 产出 Markdown + HTML 表格 ↓ LLM 基于 结构化 Markdown 做观点提取

优点：

• 中文研报解析最强（专为中文优化）；
• 财务预测表格 → HTML 嵌入，合并单元格、跨页表格完整保留；
• 章节层级保留，"投资要点/盈利预测/风险提示"段落精准定位；
• 内置 OCR，扫描件也能处理；
• 准确率 98.7%。

缺点：

• CPU 慢（12 页需 21 分钟），需 GPU 才实用（推荐 8GB+ 显存）；
• 模型大（首次下载 GB 级）；
• 部署复杂度高；
• 模型 AGPL 协议（代码 Apache 2.0，但模型权重有 AGPL 限制）。

适合：有 GPU 服务器、追求极致解析质量、商业化产品。

方案 C：分层混合（企业级推荐）⭐⭐⭐⭐⭐

研报 PDF ↓ 快速判断：是否含复杂表格/扫描图表？ ├─ 否 → MarkItDown（快、轻） → 90% 研报走此路 └─ 是 → MinerU（精、重） → 10% 复杂研报走此路 ↓ 统一输出 Markdown + 结构化字段

优点：兼顾速度与精度，按需调度。缺点：需维护两套解析器，复杂度最高。

五、改造建议与决策路径

5.1 短期（MVP 增强）：方案 A

改造pdf_parser.py，将 MarkItDown 作为主解析器，pdfplumber 作为兜底，伪代码如下：

# 优先级：MarkItDown > pdfplumber > PyPDF2 def parse_pdf(file_path): try: from markitdown import MarkItDown md = MarkItDown() result = md.convert(str(file_path)) return ParsedReport(full_text=result.text_content, ...) except Exception: # 回退到现有 pdfplumber 逻辑 return _try_pdfplumber(file_path)

改动量：小（仅 pdf_parser.py 一个文件）；收益：LLM 友好度提升、段落结构更清晰、社区维护更好；风险：低（pdfplumber 兜底，不会比现在差）。

5.2 中期（精度提升）：方案 B/C

当确认有 GPU 资源时，集成 MinerU 处理复杂表格：

# 检测到表格密集型研报时调用 MinerU def parse_pdf_with_mineru(file_path): import mineru result = mineru.parse(str(file_path)) # result.markdown 含 HTML 表格，财务预测表完整保留 return ParsedReport(full_text=result.markdown, tables=result.tables, ...)

改动量：中（新增 mineru_adapter.py，路由层增加判断）；收益：财务预测表格提取准确率从 ~60% → 98%+；前提：需 GPU 环境。

5.3 推荐决策路径

是否立即改造？ ├─ 是 → 采用方案 A（MarkItDown 为主 + pdfplumber 兜底） │ 改动小、收益明确、风险低 └─ 否 → 保持现状，待以下条件触发再升级： - 实测 pdfplumber 对财务表格丢失率 > 30% - 获得 GPU 服务器资源 - 此时直接上方案 C（MinerU + MarkItDown 分层）

六、关键验证点（改造前需实测）

建议在改造前，用 3-5 篇真实研报 PDF 实测以下指标：

1. 段落完整性：投资要点/盈利预测/风险提示段落是否完整提取；
2. 表格保真度：财务预测表（EPS/PE 多年数据）是否能正确识别行列；
3. 评级/目标价：散落正文的数字能否被上下文关联；
4. 处理速度：单篇研报解析耗时是否可接受（< 30 秒）；
5. 失败率：批量处理 20 篇研报的成功率。

七、结论：针对券商研报场景的明确建议

1. 首选 MarkItDown 作为默认解析器（方案 A）：轻量、LLM 友好、微软背书、MIT 许可，与当前 skill 架构契合度高。研报多为文本型 PDF，可规避其扫描件短板；
2. 保留 pdfplumber 作为兜底：现有逻辑不删，确保稳定性；
3. MinerU 作为可选增强：当用户有 GPU 且需要极致表格精度时（如提取复杂财务预测表），通过配置开关启用，不作为默认依赖，避免部署门槛过高；
4. 不推荐 Marker：中文支持弱 + GPL 商用限制，与研报场景不匹配。

一句话总结：用 MarkItDown 升级主解析路径，pdfplumber 兜底，MinerU 按需启用——这是研报场景下速度、精度、部署成本的最优平衡。

八、落地实现：仓库中的四层解析链（方案 A 已实施）

调研报告提出的方案 A 已在仓库中完整落地，核心实现在 pdf_parser.py，实际架构比调研方案更进一步，演化为四层文本解析链 + 独立图片提取链。

8.1 四层文本解析链

解析优先级定义于 pdf_parser.py：

PARSER_MINERU = "mineru" # 高精度路径（中文最强、表格HTML，默认关闭） PARSER_MARKITDOWN = "markitdown" # 默认主路径（微软，LLM友好，保留表格结构） PARSER_PDFPLUMBER = "pdfplumber" # 兜底1 PARSER_PYPDF2 = "pypdf2" # 兜底2 DEFAULT_TEXT_CHAIN = [PARSER_MARKITDOWN, PARSER_PDFPLUMBER, PARSER_PYPDF2]

parse_pdf()按链顺序依次尝试，任一解析器产出非空文本即返回并记录parser_used；未安装的解析器（ImportError）与 MinerU CLI 缺失（FileNotFoundError）会被自动跳过，其余异常记入 error 后继续下一层（pdf_parser.py）。

各层实现要点：

• MinerU（_try_mineru）：为避免 Python API 版本差异，通过 CLImineru -p input.pdf -o out -b pipeline调用（10 分钟超时），从输出目录读取{pdf_name}/auto/{pdf_name}.md，并兼容不同版本的输出路径；其 Markdown 已内嵌 HTML 表格（pdf_parser.py）；
• MarkItDown（_try_markitdown）：基于 pdfminer.six 中文支持良好，输出保留标题层级、列表与表格结构，页数用文本规模估算（pdf_parser.py）；
• pdfplumber / pypdf：分别提供真实页数与最简纯文本保障（pdf_parser.py）。

8.2 独立图片提取链（PyMuPDF 主 + pdfplumber 兜底）

文本解析与图片提取完全解耦：extract_images()用PyMuPDF（fitz）作主路径（速度快约 20x、按 xref 自动去重、保留 JPEG/PNG 原格式），失败时回退 pdfplumber（按内容哈希去重、强制转 PNG）；默认过滤宽度/高度 < 80px 的小图标（页眉 logo 等），图片按{pdf名}_images/p{页码}_img{序号}.{ext}命名（pdf_parser.py）。该设计的关键原因已在 SKILL.md 中注明：MarkItDown 不支持 PDF 图片提取（源码层面不调用 page.images），因此图片必须独立提取，供 LLM 多模态分析研报图表（营收走势、毛利率趋势等）。

8.3 结构化输出：ParsedReport 与段落识别

解析结果统一封装为ParsedReportdataclass，包含full_text、sections、page_count、char_count、parse_success、parser_used（可追溯实际解析器）、images等字段（pdf_parser.py）。

段落识别extract_sections()用正则定位"投资要点/盈利预测/风险提示/估值"等标题，截取到下一个标题或文末，单段落上限 3000 字（pdf_parser.py）：

SECTION_PATTERNS = { "investment_points": r"(投资要点|核心观点|投资建议|要点总结)", "earnings_forecast": r"(盈利预测|业绩预测|财务预测)", "risk_warning": r"(风险提示|风险因素|风险揭示|风险分析)", "valuation": r"(估值|目标价|估值分析)", }

8.4 配置驱动：settings.json 的 pdf_parser 段

解析行为完全由 config/settings.json 的pdf_parser配置段控制：

"pdf_parser": { "prefer_parser": "", "enable_mineru": false, "mineru_backend": "pipeline", "mineru_timeout_sec": 600, "text_chain": ["mineru", "markitdown", "pdfplumber", "pypdf2"], "image_chain": ["pymupdf", "pdfplumber"], "image_min_width": 80, "image_min_height": 80 }

• prefer_parser：空 = 自动按链选择；指定mineru/markitdown/pdfplumber/pypdf2时，该解析器被提升到链首（_build_parser_chain实现，见 pdf_parser.py）；
• enable_mineru：默认false，避免部署门槛过高；设为true才把 MinerU 纳入解析链；
• mineru_backend/mineru_timeout_sec：MinerU CLI 的 pipeline 模式与 600 秒超时；
• image_min_width/height：小图标过滤阈值。

report_router.py 在启动时会读取该配置中的enable_mineru，并透传给parse_pdf()，因此无需改代码即可一键开启 MinerU 高精度路径。

8.5 依赖与部署

依赖清单见 requirements.txt，核心包括：

markitdown[pdf]>=0.1.8 # 默认主解析器（微软，LLM 友好，保留表格/结构） pdfplumber>=0.11.10 # 兜底解析器 1 + 图片提取兜底 pypdf>=3.15.0 # 兜底解析器 2（PyPDF2 继任者，修复无限循环 DoS） PyMuPDF>=1.28.2 # 图片提取主路径（fitz，快、自动去重、保留原格式） Pillow>=12.3.0 # pdfplumber 图片提取依赖（PIL）

MinerU 为可选依赖，注释中给出部署与启用方式：pip install "mineru[all]" && mineru-models-download，然后在config/settings.json中设pdf_parser.enable_mineru = true。

8.6 CLI 独立测试入口

pdf_parser.py 提供独立 CLI，便于单独调试解析效果：

# 自动选择最优解析器并打印识别到的段落 python egs_skill/broker-research-analyst/scripts/pdf_parser.py 研报.pdf --sections # 强制指定解析器 python egs_skill/broker-research-analyst/scripts/pdf_parser.py 研报.pdf --parser markitdown # 仅打印前 2000 字、跳过图片提取 python egs_skill/broker-research-analyst/scripts/pdf_parser.py 研报.pdf --excerpt 2000 --no-images # 启用 MinerU 高精度路径（需已部署 mineru） python egs_skill/broker-research-analyst/scripts/pdf_parser.py 研报.pdf --mineru

8.7 与报告生成、路由链路的集成

• generate_report.py 新增"研报 PDF 解析摘要"章节：将解析结果前 1500 字渲染为代码块，供 LLM 深度分析；同时渲染"研报图表提取"章节，列出提取的图片路径（每篇前 5 张），支持 LLM 视觉模型读取图表；
• report_router.py 在批量解析时按[parser: {parsed.parser_used}]前缀把实际解析器标识写入摘要，保证解析链路可追溯；
• 下载环节由 pdf_downloader.py 负责：命名规则{机构}_{代码}_{日期}_{infoCode}.pdf、缓存去重、过期清理，并针对东方财富 pdf.dfcfw.com 的 JS 反爬挑战页，用 node 执行其 JS 解算 cookie 后重试，且校验响应首字节为%PDF才落盘，避免把挑战页误存为 PDF。

九、实测验证（茅台研报，2026-06-27）

关键发现：实测中 pdfplumber 对部分 PDF（5/8）报No /Root object错误完全失败，而 MarkItDown 全部成功解析——主路径反而比兜底更稳健，三层（实际四层）架构的价值得到验证。

十、待观察项与后续演进

• 复杂财务表格的 Markdown 化质量（合并单元格、跨页表格）仍不如 MinerU；
• 后续若引入 GPU 资源，可按方案 C 集成 MinerU 处理高精度场景，当前代码已预留enable_mineru配置开关与_try_mineru实现，无需改动主链路即可切换；
• 工具版本与指标（Star、准确率、速度）会持续演进，升级前建议按第六节的关键验证点重新实测。

延伸阅读：完整的 Skill 用法与运行链路见 egs_skill/broker-research-analyst/README.md，图片提取方案的专项调研见 egs_skill/PDF_IMAGE_RESEARCH.md。

• 金融科技
• 示例工程