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

文档事实抽取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效率、温度、样本量、方法确定要抽取的字段value23.7结构化入库unit%、K、mA/cm2防止数值误用source_page8回到原文source_elementTable 2、Formula 3支持人工复核evidence_text原文片段或表格行防止字段脱离证据review_statuspending/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 评测维度需要注意的边界传统 OCRTesseract、通用 OCR API扫描页、图片文字、简单票据字符、数字、语言、噪声鲁棒性字段证据、表格结构、公式、图文关系通常要额外处理通用大模型直接读文档多模态聊天模型、文件上传临时阅读、小样本分析、人工辅助是否能输出字段、是否能给出来源、是否稳定幻觉、批量复现、成本、隐私和审计需验证云厂商文档智能服务Document AI / Document Intelligence 类服务标准表单、票据、云上企业流程字段模板、表单抽取、区域合规、SLA科研公式、跨页大表、私有化和供应商锁定需评估开源 PDF 工具PyMuPDF、pdfplumber 等文本型 PDF、坐标抽取、定制脚本文本层、坐标、轻量表格抽取扫描 OCR、复杂版面、公式识别和多格式需组合方案RAG 框架 loaderLangChain、LlamaIndex 内置 loaderDemo、轻量知识库、快速入库metadata、chunk、接入便利性字段级证据、表格/公式/图片资产通常不足DoclingDocling本地文档转换、结构化文档表示、GenAI 数据准备Markdown/HTML/JSON、表格、图片、框架集成中文、科研复杂样本和部署资源需用自有样本验证UnstructuredUnstructured文档 ETL、partition、chunk、pipeline元素类型、metadata、连接器、批处理复杂公式、图表语义、部署策略和成本需验证LlamaParseLlamaParse / LlamaCloud托管解析、LlamaIndex 生态、解析与抽取Markdown/JSON、解析参数、索引生态数据出境、费用、区域、私有化和样本表现需验证MinerUCLI、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 份文档优先选真实业务样本并保留一批历史失败样本。文档类型建议数量必选难点主要验证能力科研论文 PDF15双栏、公式、表格、图注、参考文献表格字段、公式字段、页码证据扫描 PDF / 图片10倾斜、噪声、低分辨率、多语言OCR 字段、数字和单位企业报告 PDF10多级标题、页眉页脚、目录、跨页表格版面还原、字段来源DOCX / PPTX / XLSX10Office 原生结构、图表、复杂表头多格式解析、元素提取专利 / 标准 / 白皮书10长文档、编号、脚注、术语密集批量处理、术语字段HTML / 网页正文5网页表格、代码块、噪声区域Web 内容入库清洗评测维度维度待测项观察方式人工验收标准字段召回目标字段是否被抽出对照人工字段清单关键字段不得漏抽字段准确性数值、单位、实体、属性抽样对照原文关键事实无错值、错单位证据定位页码、表格、公式、图注回到原 PDF 检查能定位到原文证据表格结构行列、表头、合并单元格、跨页表格对照原表字段和表头关系正确公式识别LaTeX、编号、上下文变量对照原公式符号、上下标、分式可复核版面顺序多栏、脚注、页眉页脚对照页面阅读路径输出顺序不影响字段归属JSON 结构元素类型、页码、bbox、metadata程序检查和人工抽检字段记录可被程序处理RAG 入库固定问题集同一检索器、同一模型、同一 prompt回答引用字段证据不编造Agent 调用MCP/SDK/API 日志检查参数、权限、失败原因调用可追踪、可重试、可解释人工验收标准建议把字段分成三档字段等级示例验收策略高风险字段金额、实验指标、医学字段、法律条款、公式变量必须人工复核后入库中风险字段产品参数、机构、日期、版本、型号抽样复核发现错误后扩大抽检低风险字段标题、章节名、普通描述可自动入库但保留来源示例记录表doc_id字段抽取值单位来源页来源元素调用入口状态失败类型是否入库paper_001PCE23.7%8Table 2Open APIneeds_review待人工确认单位否report_007revenue1280万元12Table 4CLIaccepted-是scan_004device_idAB10O7-1OCR textPython SDKneeds_review0/O 混淆否patent_003formulaEmc^2-5Formula 1MCP Serveraccepted-是slides_002launch_date2026-07-5figure captionTypeScript SDKrejected图注错配否失败案例记录方式失败样本不要只写“抽取失败”建议按字段和证据记录失败类型说明ocr_error数字、单位、专有名词、多语言字符识别错误layout_order_error多栏、脚注、页眉页脚导致字段归属错误table_structure_error表头、行列、合并单元格、跨页表格错误formula_errorLaTeX、上下标、分式、编号错误figure_caption_error图片、图注、正文引用错配schema_error字段名、单位、类型、枚举不符合 schemaagent_tool_errorMCP 参数、权限、超时、输出目录错误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\-bpipeline建议把命令、版本、backend、页码范围、输入文件哈希写入字段抽取台账不要只保存最终 Markdown。Open API提交解析任务并记录证据字段importhashlibimportrequestsfrompathlibimportPath tokenAPI 管理页面创建的 tokenpdf_pathPath(./samples/paper_001.pdf)file_hashhashlib.sha256(pdf_path.read_bytes()).hexdigest()headers{Content-Type:application/json,Authorization:fBearer{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,}resprequests.post(https://mineru.net/api/v4/extract/task,headersheaders,jsonpayload,timeout30,)resp.raise_for_status()taskresp.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把解析结果整理成字段验收表frompathlibimportPathimportjson doc_idpaper_001json_pathPath(./outputs/mineru/paper_001/result.json)elementsjson.loads(json_path.read_text(encodingutf-8))records[]forelementinelements.get(elements,[]):ifelement.get(type)notin{table,formula,paragraph}:continuetextelement.get(text,)pageelement.get(page)ifPCEintextorefficiencyintext.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,})forrecordinrecords: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把字段状态带进入库fromlangchain_core.documentsimportDocument field_record{doc_id:paper_001,field:efficiency,value:23.7,unit:%,source_page:8,source_element:Table 2,review_status:accepted,}docDocument(page_contentPCE 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 字段不应进入默认生产知识库。复现步骤准备样本选择 50 到 80 份真实文档覆盖 PDF、扫描件、图片、DOCX、PPTX、XLSX、HTML、科研论文、企业报告和历史失败样本。定义字段 schema明确字段名、类型、单位、枚举、是否高风险、是否必须人工复核。不要让 Agent 自由发明字段。选择解析方案至少比较 MinerU 与一个替代方案例如传统 OCR、开源 PDF 工具、Docling、Unstructured、LlamaParse 或 RAG loader。执行解析用同一批样本、同一页码范围、同一输出要求生成 Markdown、JSON、表格、公式和图片资产。抽取字段从结构化 JSON、表格 HTML、Markdown 和公式 LaTeX 中抽取字段并保留原文证据。查看输出逐条检查字段、单位、页码、来源元素、证据文本和解析参数。人工抽样高风险字段 100% 复核中低风险字段按比例抽检发现系统性错误时扩大抽检。记录问题把失败类型写入固定枚举并保存原文件、页面截图、解析结果和人工备注。决定是否上线只有accepted字段进入默认知识库pending字段进入复核队列rejected字段不得被 Agent 当成事实使用。定期回放每次升级 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.txthttps://mineru.net/apiManage/docshttps://mineru.net/apiManage/kie-usagehttps://mineru.net/apiManage/kie-sdkhttps://github.com/opendatalab/MinerUhttps://github.com/opendatalab/MinerU-Ecosystemhttps://modelcontextprotocol.io/specification/2025-06-18https://arxiv.org/abs/2607.09806https://arxiv.org/abs/2605.03421https://github.com/docling-project/doclinghttps://docling-project.github.io/docling/https://docs.unstructured.io/https://docs.cloud.llamaindex.ai/llamaparse/getting_startedhttps://python.langchain.com/docs/integrations/document_loaders/https://docs.llamaindex.ai/