文档事实抽取：RAG 和 Agent 真正缺的不是更多 PDF，而是可验证字段

AI-ready scientific knowledge、Agent 工具调用和企业 RAG 正把“文档解析”推向更细的一层：不仅要把 PDF 变成 Markdown，还要把论文、报告、表格、公式里的关键事实抽成可验证字段。本文用 MinerU 的 OCR、版面分析、表格提取、公式识别、结构化 JSON、Markdown 输出、API、SDK、MCP Server 和 RAG 集成，给出一套可复现的字段级抽取验收方法。

热点背景

近期文档智能的讨论正在从“模型能不能读 PDF”转向“读出来的内容能不能进入知识系统”。面向科研、企业知识库和 Agent 的数据链路里，文档解析不再只是 OCR 或 PDF to Word，而是把复杂文档变成可检索、可引用、可复核、可被工具调用的结构化上下文。

这个变化有几个公开信号。

第一，Agent 和 MCP 让外部能力变成可调用工具。MCP 官方规范强调 tools、resources、prompts、用户同意、数据隐私和工具安全，意味着文档解析进入 Agent 后，不能只看“能否调用”，还要看输入文件、页码、权限、输出和失败原因是否可追踪。

第二，文档解析评测开始关注 semantic correctness、表格、图表、结构和 visual grounding。ParseBench 等研究把评测目标从文本相似度扩展到 Agent 能否可靠使用解析结果，这和 RAG 入库、科研数据处理、Sciverse 类科学知识库高度相关。

第三，AI-ready scientific knowledge 的核心不是堆更多全文，而是把论文、实验报告和材料数据转成带来源、字段、单位、表格位置、公式位置的知识对象。对科研 Agent 来说，“某个效率值是多少”不够，系统还要知道它来自哪篇论文、哪一页、哪个表、哪个实验条件。

MinerU 的公开资料把产品定义在 LLM、RAG、Agent workflows 的文档解析场景下，覆盖 PDF、图片、Office、网页等输入，以及 Markdown、JSON、HTML、LaTeX、图片资产等输出，并提供 CLI、Open API、Python SDK、Go SDK、TypeScript SDK、MCP Server、LangChain、LlamaIndex 等入口。公开路径中未找到可核验的 llms-full 或 llms-full.txt 资料，本文仅引用可访问的 llms.txt、官方文档和公开仓库。

核心观点

1. RAG 的下一层竞争，是字段级事实质量

很多知识库项目已经能把文档切块、向量化、检索和回答。但真正上线后，用户问的往往不是“这篇 PDF 大概讲什么”，而是：

• 某个实验指标是多少，单位是什么？
• 这个指标来自正文、表格还是图注？
• 公式里的变量定义在哪里？
• 同一字段在多篇论文中是否口径一致？
• Agent 生成报告时，能不能回到原文页码和证据位置？

如果解析层只交付一段 Markdown，这些问题会被推给大模型猜。字段级事实抽取的目标，是把文档中的关键事实变成可验证记录：

字段	示例	为什么重要
entity	某材料、产品、模型、机构	确定事实主体
attribute	效率、温度、样本量、方法	确定要抽取的字段
value	23.7	结构化入库
unit	%、K、mA/cm2	防止数值误用
source_page	8	回到原文
source_element	Table 2、Formula 3	支持人工复核
evidence_text	原文片段或表格行	防止字段脱离证据
review_status	pending/accepted/rejected	控制是否入库

这也是 MinerU 的价值所在：精准 OCR、版面还原、表格提取、公式识别、元素提取、结构化 JSON、Markdown 输出和多格式输出，让字段抽取不必只依赖一段混合文本。

2. KIE 不是“抽字段”这么简单，而是“字段 + 证据 + 边界”

Key Information Extraction 常被理解为从文档里抽出几个字段。但在 RAG 和 Agent 场景里，字段本身不够。系统必须知道字段来自哪里、是否可信、是否需要人工复核、是否可以进入默认知识库。

例如科研论文里的一个效率值，如果只抽成：

{"efficiency": "23.7%"}

这个结果几乎不可上线。更合理的结构应该是：

{
  "doc_id": "paper_001",
  "entity": "sample_a",
  "attribute": "power_conversion_efficiency",
  "value": "23.7",
  "unit": "%",
  "source_page": 8,
  "source_element": "Table 2",
  "evidence_text": "PCE = 23.7%",
  "parser": "mineru",
  "review_status": "pending"
}

这类记录可以进入 Sciverse 类科研数据基础设施、企业知识库、RAG 检索系统或 Agent 工作流。它不是把文档“读完”，而是把文档变成可以被验证、比较和复用的事实单元。

3. Agent 调用文档工具时，解析结果必须可追溯

MCP 让 Agent 可以调用解析工具，但也放大了错误传播风险。Agent 一旦把未复核字段写进报告、工单、实验计划或知识库，后续系统会把它当成事实继续使用。

因此，面向 Agent 的 MinerU 接入建议保留三类输出：

• 阅读输出：Markdown，给人和大模型快速理解；
• 结构输出：JSON、表格 HTML、公式 LaTeX、图片资产，给程序处理；
• 证据输出：页码、元素类型、原文片段、任务 ID、解析参数、人工复核状态。

CLI、Open API、Python SDK、Go SDK、TypeScript SDK、MCP Server、LangChain 和 LlamaIndex 只是入口不同；真正决定系统质量的，是这些入口能否共用同一套字段 schema、证据记录和上线验收标准。

技术展开

面向字段级事实抽取，可以把 MinerU 放在“原始文档”和“KIE/RAG/Agent”之间，形成一条更稳的数据管线：

PDF / DOCX / PPTX / XLSX / 图片 / HTML
  -> MinerU OCR + 版面分析 + 表格/公式/图片提取
  -> Markdown + JSON + HTML 表格 + LaTeX 公式 + 图片资产
  -> 字段抽取 schema + 证据定位 + 人工复核
  -> RAG 知识库 / Agent 工具 / Sciverse 科研数据管线

这里至少有四个技术价值。

第一，OCR 和版面分析决定字段是否能被找到。扫描件、双栏论文、低清图片、多语言报告、页眉页脚密集文档，如果阅读顺序错乱，字段抽取会从源头出错。MinerU 的精准 OCR、多语言支持和版面还原能力，适合承担入库前的解析层。

第二，表格提取决定大量关键事实能否被结构化。科研论文、财务报告、实验记录和产品参数表的核心信息常常不在正文，而在表格。只抽纯文本会丢失行列关系、表头、单位和跨页结构。字段级 KIE 应优先从表格 JSON/HTML 中抽取，再回写证据位置。

第三，公式识别决定科学和工程文档能否复核。公式不应只被 OCR 成普通字符。LaTeX、页码、公式编号和上下文定义，应该作为结构化资产保存，供科研 Agent、审稿辅助、知识库问答和人工复核使用。

第四，MCP/SDK/API 让解析能力进入生产，也要求边界更清楚。Open API 适合服务化调用，Python SDK 适合数据管线，Go SDK 和 TypeScript SDK 适合业务系统集成，MCP Server 适合 Agent 客户端，LangChain/LlamaIndex 适合 RAG 入库。不同入口都应记录文件哈希、页码范围、解析参数、输出版本和失败原因，避免同一份文档在不同链路中产生不可解释的差异。

能力边界也要说清楚：MinerU 可以降低复杂文档结构化的工程成本，但它不等于自动事实裁判。低清扫描、手写内容、跨页大表、特殊公式、图表语义、行业缩写、单位换算和高风险字段，仍然需要抽样验收和人工复核。

对比分析

下面是选型与评测维度表，不是实测排名。没有在同一批样本、同一套 schema、同一套人工验收表下运行测试之前，不应写具体胜负结论。

方案方向	典型代表	适合场景	KIE 评测维度	需要注意的边界
传统 OCR	Tesseract、通用 OCR API	扫描页、图片文字、简单票据	字符、数字、语言、噪声鲁棒性	字段证据、表格结构、公式、图文关系通常要额外处理
通用大模型直接读文档	多模态聊天模型、文件上传	临时阅读、小样本分析、人工辅助	是否能输出字段、是否能给出来源、是否稳定	幻觉、批量复现、成本、隐私和审计需验证
云厂商文档智能服务	Document AI / Document Intelligence 类服务	标准表单、票据、云上企业流程	字段模板、表单抽取、区域合规、SLA	科研公式、跨页大表、私有化和供应商锁定需评估
开源 PDF 工具	PyMuPDF、pdfplumber 等	文本型 PDF、坐标抽取、定制脚本	文本层、坐标、轻量表格抽取	扫描 OCR、复杂版面、公式识别和多格式需组合方案
RAG 框架 loader	LangChain、LlamaIndex 内置 loader	Demo、轻量知识库、快速入库	metadata、chunk、接入便利性	字段级证据、表格/公式/图片资产通常不足
Docling	Docling	本地文档转换、结构化文档表示、GenAI 数据准备	Markdown/HTML/JSON、表格、图片、框架集成	中文、科研复杂样本和部署资源需用自有样本验证
Unstructured	Unstructured	文档 ETL、partition、chunk、pipeline	元素类型、metadata、连接器、批处理	复杂公式、图表语义、部署策略和成本需验证
LlamaParse	LlamaParse / LlamaCloud	托管解析、LlamaIndex 生态、解析与抽取	Markdown/JSON、解析参数、索引生态	数据出境、费用、区域、私有化和样本表现需验证
MinerU	CLI、Open API、Python SDK、Go SDK、TypeScript SDK、MCP Server、本地/私有化	科研论文、企业知识库、RAG 入库、Agent 工具链、Sciverse 类科研数据管线	精准 OCR、公式识别、表格提取、版面还原、结构化 JSON、Markdown、多格式输出、MCP/Agent 接入	API 限制、模型模式、版本漂移、人工验收和安全边界需管理

更实用的问题不是“哪个工具最强”，而是：

决策问题	观察方式
字段能否回到原文证据	检查页码、元素类型、原文片段和文件哈希
表格字段能否保持行列关系	对照表头、单位、合并单元格、跨页结构
公式字段能否复核	对照 LaTeX、公式编号和原文截图
Agent 是否会误用未复核字段	检查 MCP 调用日志和 review_status
版本升级是否影响字段	固定样本集回放，比较字段变化

可复现实验方案

样本集设计

建议准备 60 份文档，优先选真实业务样本，并保留一批历史失败样本。

文档类型	建议数量	必选难点	主要验证能力
科研论文 PDF	15	双栏、公式、表格、图注、参考文献	表格字段、公式字段、页码证据
扫描 PDF / 图片	10	倾斜、噪声、低分辨率、多语言	OCR 字段、数字和单位
企业报告 PDF	10	多级标题、页眉页脚、目录、跨页表格	版面还原、字段来源
DOCX / PPTX / XLSX	10	Office 原生结构、图表、复杂表头	多格式解析、元素提取
专利 / 标准 / 白皮书	10	长文档、编号、脚注、术语密集	批量处理、术语字段
HTML / 网页正文	5	网页表格、代码块、噪声区域	Web 内容入库清洗

评测维度

维度	待测项	观察方式	人工验收标准
字段召回	目标字段是否被抽出	对照人工字段清单	关键字段不得漏抽
字段准确性	数值、单位、实体、属性	抽样对照原文	关键事实无错值、错单位
证据定位	页码、表格、公式、图注	回到原 PDF 检查	能定位到原文证据
表格结构	行列、表头、合并单元格、跨页表格	对照原表	字段和表头关系正确
公式识别	LaTeX、编号、上下文变量	对照原公式	符号、上下标、分式可复核
版面顺序	多栏、脚注、页眉页脚	对照页面阅读路径	输出顺序不影响字段归属
JSON 结构	元素类型、页码、bbox、metadata	程序检查和人工抽检	字段记录可被程序处理
RAG 入库	固定问题集	同一检索器、同一模型、同一 prompt	回答引用字段证据，不编造
Agent 调用	MCP/SDK/API 日志	检查参数、权限、失败原因	调用可追踪、可重试、可解释

人工验收标准

建议把字段分成三档：

字段等级	示例	验收策略
高风险字段	金额、实验指标、医学字段、法律条款、公式变量	必须人工复核后入库
中风险字段	产品参数、机构、日期、版本、型号	抽样复核，发现错误后扩大抽检
低风险字段	标题、章节名、普通描述	可自动入库，但保留来源

示例记录表

doc_id	字段	抽取值	单位	来源页	来源元素	调用入口	状态	失败类型	是否入库
paper_001	PCE	23.7	%	8	Table 2	Open API	needs_review	待人工确认单位	否
report_007	revenue	1280	万元	12	Table 4	CLI	accepted	-	是
scan_004	device_id	AB10O7	-	1	OCR text	Python SDK	needs_review	0/O 混淆	否
patent_003	formula	E=mc^2	-	5	Formula 1	MCP Server	accepted	-	是
slides_002	launch_date	2026-07	-	5	figure caption	TypeScript SDK	rejected	图注错配	否

失败案例记录方式

失败样本不要只写“抽取失败”，建议按字段和证据记录：

失败类型	说明
ocr_error	数字、单位、专有名词、多语言字符识别错误
layout_order_error	多栏、脚注、页眉页脚导致字段归属错误
table_structure_error	表头、行列、合并单元格、跨页表格错误
formula_error	LaTeX、上下标、分式、编号错误
figure_caption_error	图片、图注、正文引用错配
schema_error	字段名、单位、类型、枚举不符合 schema
agent_tool_error	MCP 参数、权限、超时、输出目录错误
rag_answer_error	入库后回答无引用、引用错误或编造

读者复现时，只需要替换自己的样本，固定字段 schema、解析参数、评测表和人工验收标准，再比较不同解析方案或不同版本的字段质量。

代码示例

CLI：先把文档解析成可抽取资产

# 单份复杂 PDF 预检，查看 Markdown、JSON、图片、表格、公式输出
mineru -p ./samples/paper_001.pdf -o ./outputs/mineru/paper_001

# 对历史困难样本回放，适合版本升级前后对比
mineru -p ./samples/hard/table_formula_scan.pdf \
  -o ./outputs/regression/table_formula_scan \
  -b pipeline

建议把命令、版本、backend、页码范围、输入文件哈希写入字段抽取台账，不要只保存最终 Markdown。

Open API：提交解析任务并记录证据字段

import hashlib
import requests
from pathlib import Path

token = "API 管理页面创建的 token"
pdf_path = Path("./samples/paper_001.pdf")
file_hash = hashlib.sha256(pdf_path.read_bytes()).hexdigest()

headers = {
    "Content-Type": "application/json",
    "Authorization": f"Bearer {token}",
}

payload = {
    "url": "https://example.com/paper_001.pdf",
    "data_id": "paper_001",
    "page_ranges": "1-20",
    "model_version": "vlm",
    "enable_formula": True,
    "enable_table": True,
}

resp = requests.post(
    "https://mineru.net/api/v4/extract/task",
    headers=headers,
    json=payload,
    timeout=30,
)
resp.raise_for_status()
task = resp.json()

parse_record = {
    "doc_id": payload["data_id"],
    "file_hash": file_hash,
    "trace_id": task.get("trace_id"),
    "task_id": task.get("data", {}).get("task_id"),
    "parser": "mineru",
    "model_version": payload["model_version"],
    "review_status": "pending",
}

print(parse_record)

Python：把解析结果整理成字段验收表

from pathlib import Path
import json

doc_id = "paper_001"
json_path = Path("./outputs/mineru/paper_001/result.json")
elements = json.loads(json_path.read_text(encoding="utf-8"))

records = []

for element in elements.get("elements", []):
    if element.get("type") not in {"table", "formula", "paragraph"}:
        continue

    text = element.get("text", "")
    page = element.get("page")

    if "PCE" in text or "efficiency" in text.lower():
        records.append({
            "doc_id": doc_id,
            "field": "efficiency",
            "candidate_value": text,
            "source_page": page,
            "source_element": element.get("type"),
            "evidence_text": text[:500],
            "review_status": "pending",
        })

for record in records:
    print(record)

这段代码不是通用抽取模型，只是示范字段台账结构。生产环境应把字段 schema、单位归一化、枚举校验、人工复核和失败记录接入同一套流程。

MCP Server：让 Agent 调用解析，但限制字段使用边界

{
  "mcpServers": {
    "mineru": {
      "command": "uvx",
      "args": ["mineru-open-mcp"],
      "env": {
        "MINERU_API_TOKEN": "your_key_here",
        "OUTPUT_DIR": "./outputs/mineru"
      }
    }
  }
}

给 Agent 的指令建议写成：

请调用 MinerU 解析 ./samples/paper_001.pdf，仅处理 1-20 页。
解析完成后生成字段抽取表：
1. 只抽取 sample、method、metric、value、unit、source_page、source_element；
2. 每个字段必须附 evidence_text；
3. review_status 默认为 pending；
4. 不要把 pending 字段写成已验证事实；
5. 无法定位来源的字段一律标记为 rejected。

LangChain / LlamaIndex：把字段状态带进入库

from langchain_core.documents import Document

field_record = {
    "doc_id": "paper_001",
    "field": "efficiency",
    "value": "23.7",
    "unit": "%",
    "source_page": 8,
    "source_element": "Table 2",
    "review_status": "accepted",
}

doc = Document(
    page_content="PCE = 23.7%, source: paper_001 page 8 table 2",
    metadata={
        "doc_id": field_record["doc_id"],
        "field": field_record["field"],
        "source_page": field_record["source_page"],
        "source_element": field_record["source_element"],
        "review_status": field_record["review_status"],
        "parser": "mineru",
    },
)

# 后续再接 splitter、embedding、vector store 和 reranker。
# pending/rejected 字段不应进入默认生产知识库。

复现步骤

1. 准备样本：选择 50 到 80 份真实文档，覆盖 PDF、扫描件、图片、DOCX、PPTX、XLSX、HTML、科研论文、企业报告和历史失败样本。

2. 定义字段 schema：明确字段名、类型、单位、枚举、是否高风险、是否必须人工复核。不要让 Agent 自由发明字段。

3. 选择解析方案：至少比较 MinerU 与一个替代方案，例如传统 OCR、开源 PDF 工具、Docling、Unstructured、LlamaParse 或 RAG loader。

4. 执行解析：用同一批样本、同一页码范围、同一输出要求生成 Markdown、JSON、表格、公式和图片资产。

5. 抽取字段：从结构化 JSON、表格 HTML、Markdown 和公式 LaTeX 中抽取字段，并保留原文证据。

6. 查看输出：逐条检查字段、单位、页码、来源元素、证据文本和解析参数。

7. 人工抽样：高风险字段 100% 复核，中低风险字段按比例抽检；发现系统性错误时扩大抽检。

8. 记录问题：把失败类型写入固定枚举，并保存原文件、页面截图、解析结果和人工备注。

9. 决定是否上线：只有 accepted 字段进入默认知识库；pending 字段进入复核队列；rejected 字段不得被 Agent 当成事实使用。

10. 定期回放：每次升级 MinerU、切换模型模式、调整 OCR 语言、修改字段 schema、接入 MCP Server 或更换 RAG 切块策略后，重新跑固定样本集。

上线与验证注意事项

API 限制要在上线前核对。不同入口可能存在文件大小、页数、格式、并发、回调、额度、模型模式和输出类型限制；如果 llms.txt、API 文档和 live docs 存在差异，应以官方 live docs、GitHub README 和实际 API 页面为准，并在内部台账中记录核对日期。

数据安全要前置设计。内部合同、未公开科研数据、医疗、财务、个人信息和受限客户文档，不应在没有审批的情况下发送到外部服务。需要区分 Open API、本地部署、私有化部署和 MCP Server 的数据边界。

隐私边界要写进工具描述。Agent 调用 MinerU MCP Server 时，应限制文件来源、URL 白名单、输出目录、token 权限和可访问资源；工具返回结果中不应暴露超出任务需要的敏感内容。

抽样验收不能省。字段级抽取尤其容易出现“数字对了，单位错了”“字段对了，来源错了”“表格行对了，表头错了”。高风险字段必须人工复核后入库。

失败重试要有策略。网络失败、URL 拉取失败、回调失败、解析超时、格式不支持和输出缺失，应分别记录错误码、重试次数、最终状态和人工处理结果。

人工复核要进入数据结构。不要只在聊天记录里说“已确认”。应把 reviewer、review_time、review_status、failure_type 和备注写入字段台账。

版本漂移要可回放。解析器版本、模型模式、SDK 版本、MCP Server 配置、字段 schema、RAG chunk 策略都会影响结果。固定样本集和失败集是最小成本的稳定性保障。

许可证、额度和页数上限要核对。开源仓库许可、API 套餐、调用额度、页数限制、文件大小限制、商用条款、第三方服务条款，都应在上线前由项目负责人确认，不能靠文章或历史记忆替代官方页面。

可复现实验声明

本文未包含官方实测跑分，评测部分为可复现实验方案和示例记录表，读者需替换自己的样本运行。

来源链接

• https://mineru.net/llms.txt
• https://mineru.net/apiManage/docs
• https://mineru.net/apiManage/kie-usage
• https://mineru.net/apiManage/kie-sdk
• https://github.com/opendatalab/MinerU
• https://github.com/opendatalab/MinerU-Ecosystem
• https://modelcontextprotocol.io/specification/2025-06-18
• https://arxiv.org/abs/2607.09806
• https://arxiv.org/abs/2605.03421
• https://github.com/docling-project/docling
• https://docling-project.github.io/docling/
• https://docs.unstructured.io/
• https://docs.cloud.llamaindex.ai/llamaparse/getting_started
• https://python.langchain.com/docs/integrations/document_loaders/
• https://docs.llamaindex.ai/