Kimi K3 之后，多模态 RAG 更需要解析器适配层

Kimi K3 近期把长上下文、原生多模态和 Agent 工作流重新推到技术讨论中心。模型可以吞下更多上下文并不等于企业知识库可以跳过文档解析。PDF、Office、扫描件、表格、公式和图表进入 RAG 前仍需要一层可替换、可验收、可追踪的解析器适配层。MinerU 的 CLI、Open API、Python SDK、Go SDK、TypeScript SDK、MCP Server、LangChain、LlamaIndex 与结构化输出正适合放在这层入库底座里。热点背景近期最热的模型信号来自 Kimi K3。Moonshot 官方博客将 Kimi K3 描述为 2.8T 参数、原生视觉能力、1M token 上下文窗口的旗舰模型面向长程编程、知识工作和推理Kimi Code 文档也列出k3与k3-256k两个模型配置其中k3对应 1M 上下文窗口。这类长上下文模型会改变开发者对 RAG 的预期过去很多团队担心“放不下”现在更容易相信“直接塞进去就行”。但文档工程的问题没有因此消失。长上下文解决的是窗口容量不自动解决 OCR 错字、双栏阅读顺序、跨页表格、公式上下标、图注归属、页码证据、版本漂移和隐私边界。模型可以读更多内容但如果入库前的文档已经被解析成错序文本RAG 和 Agent 只会在更大的上下文里继承更隐蔽的错误。与此同时RAG-Anything 把多模态 RAG 的另一条趋势讲得很清楚文档不再被当成纯文本容器而是被拆成文本、图片、表格、数学公式、图表、页面层级和跨模态关系。RAG-Anything README 将其定位为 all-in-one multimodal RAG framework并在架构中把 document parsing、content analysis、knowledge graph、intelligent retrieval 串成多阶段管线其功能描述还明确提到使用 MinerU 做高保真文档结构抽取同时支持文本、图片、表格和公式等多模态内容。这件事和 MinerU 的关系很直接。MinerU 官方llms.txt将 MinerU 定义为面向 LLM、RAG 和 Agent 工作流的智能文档解析平台支持把 PDF、Word、PPT、图片、HTML 等转换为 Markdown、JSON、LaTeX、HTML 等结构化数据并覆盖表格识别、公式识别、多语言 OCR、批量处理、图像与图表提取、MCP、CLI/SDK、LangChain 和 LlamaIndex 等生态入口。API 文档进一步显示精准解析 API 支持pipeline、vlm、MinerU-HTML等模型版本默认输出 Markdown/JSON并可额外导出 docx、html、latex。公开路径中未找到可核验的llms-full、llms-full.txt或llms-full.md资料本文不引用不存在的完整模型资料。对 Sciverse / SciBase 这类科研数据基础设施来说这个趋势尤其关键。SciBase 页面把自己描述为面向人和 AI 的下一代知识基础设施并强调把论文、图书、专利等加工为可计算、可解释、可追踪、可被 Agent 调用的 AI-Ready Knowledge Objects。换句话说科研 Agent 需要的不是“把 PDF 读成一段话”而是稳定的解析、标准化、证据层和索引治理链路。核心观点1. Kimi K3 让“长上下文可用”变得更现实但不能替代解析层Kimi K3 的 1M 上下文窗口会让很多知识工作场景变得更顺手长代码仓库、长报告、长论文、复杂推理链和多轮 Agent 任务都更容易放进同一个上下文窗口。但“能放进去”和“能可靠入库”是两件事。如果原始 PDF 是扫描件模型仍需要 OCR如果论文是双栏版式模型仍需要正确阅读顺序如果报告里有跨页表格模型仍需要行列结构如果页面包含公式模型仍需要 LaTeX / MathML如果图片和图注分离模型仍需要资产路径和页码证据。长上下文模型会提高上层推理空间但底层文档结构仍由解析质量决定。所以多模态 RAG 的第一层抽象不是 chunk而是 parser adapter。更稳的抽象是解析器适配层PDF / DOCX / PPTX / XLSX / 图片 / HTML - Parser Adapter - MinerU / Docling / Unstructured / LlamaParse / OCR / 自研规则 - 统一 Document Element Schema - RAG / Agent / Sciverse 科研数据层这个适配层不强行假设某个工具永远适合所有文件也不把 Kimi K3 这类长上下文模型当成解析器替代品而是把“选择哪个解析器、用什么参数、输出什么结构、如何验收失败、哪些内容交给模型推理”标准化。MinerU 可以作为复杂 PDF、Office、扫描件、公式、表格、图片资产和 MCP/Agent 接入的主解析器Kimi K3 这类模型更适合在结构化上下文之上做长程分析、代码生成、科研问答和 Agent 编排。2. RAG 效果的上限取决于入库前的元素级结构纯文本 chunk 会把很多关键信息压平。科研论文里的公式编号、企业报告里的跨页表格、专利里的图注、PPT 里的标题层级、Excel 里的工作表边界一旦被压成普通段落后面再靠 Kimi K3、通用大模型或 prompt 很难恢复。解析器适配层至少要交付这些元素元素推荐结构对 RAG / Agent 的价值段落typeparagraph、页码、bbox、标题路径可切块、可引用、可过滤标题层级、章节号、父子关系保留上下文边界表格HTML/Markdown/CSV、行列、表头、单位支持结构化问答和数值复核公式LaTeX / MathML、编号、上下文支持科研检索和公式引用图片/图表资产路径、图注、页码支持多模态索引和证据回看元数据doc_id、来源、哈希、解析版本、参数支持复现、重跑和审计MinerU 的价值在这里更具体精准 OCR 处理扫描页和图片文字版面还原保留多栏阅读顺序表格提取减少行列关系丢失公式识别输出 LaTeX / MathML元素提取与结构化 JSON 让程序能追踪每个内容块Markdown 输出方便人审和向量化MCP/Agent 接入让解析能力可以作为工具被调用。3. 长上下文 Agent 更需要 MCP 工具边界MCP 官方工具规范强调服务器可以向模型暴露可调用工具每个工具有名称、描述和输入 schema同时也建议在安全和信任场景中保留 human-in-the-loop。放到文档解析里这意味着 Agent 不应直接拥有“任意读文件并入库”的能力而应调用受控的解析工具。一个更合理的 MCP 工具边界可以是{tool:parse_document,arguments:{source:approved://paper_001.pdf,parser:mineru,model_version:vlm,page_ranges:1-20,outputs:[markdown,json,html,latex],review_required:true}}Agent 负责提出任务解析器适配层负责执行策略文件是否允许解析、是否可调用 Open API、是否必须本地 CLI、是否需要 OCR、是否开启表格/公式、输出是否进入人工验收队列。Kimi K3 这类长上下文模型可以接收更大的结构化上下文但工具调用边界仍应由 MCP Server、权限策略、输出目录和人工复核共同约束。4. Sciverse 式科研数据管线需要可替换解析层科研数据基础设施的输入来源很杂论文 PDF、补充材料、专利、实验说明、网页、图书、表格和图片。不同来源的结构差异很大解析层不能写死成某个一次性脚本。Sciverse / SciBase 页面强调 evidence spans、source provenance、standardization parsing、knowledge objects 和 index governance。要做到这些解析器适配层必须记录每份文档如何被解析、哪些元素进入证据层、哪些页需要人工复核、哪一版解析器生成了当前索引。MinerU 可以承担其中的高保真解析入口但上线架构应保留对比、回退和版本治理能力。技术展开解析器适配层可以按五个部分设计。Kimi K3 让上层模型推理能力更强但这五层仍然不能省。第一部分是文件路由。根据文件类型、密级、页数、大小、语言、是否扫描、是否包含表格/公式/图片选择解析路径。公开论文和 demo 文档可以走 Open API内部合同、财务、医疗、未公开科研数据应优先本地 CLI、本地服务或私有化部署网页和 HTML 可以使用对应的 HTML 解析模式PPT、Excel 和 Word 需要保留原生结构边界。第二部分是解析执行。MinerU 提供 CLI、Open API、Python SDK、Go SDK、TypeScript SDK、MCP Server、LangChain、LlamaIndex 等入口。适配层的任务不是让每个业务系统各自拼参数而是把model_version、page_ranges、is_ocr、enable_formula、enable_table、language、extra_formats、callback、data_id等关键参数统一登记。第三部分是输出标准化。不要只保存full.md。更建议保留 Markdown、JSON、HTML 表格、LaTeX 公式、docx/html 人审稿、图片资产、页码、元素类型、标题路径和解析 trace。对 LangChain、LlamaIndex、自研 RAG 或 Kimi K3 长上下文分析来说统一的DocumentElement比原始 Markdown 更适合做过滤、切块、证据引用和上下文压缩。第四部分是验收与失败集。每个解析器都可能失败OCR 数字混淆、双栏错序、跨页表格断裂、公式上下标丢失、图注错配、扫描件旋转、页眉页脚污染、URL 缓存导致内容漂移。适配层要把失败记录成可回归样本而不是把错误 chunk 静默写入知识库。第五部分是 Agent 工具治理。MCP Server、Workflow、Skill、Tool Calling 和 SDK 调用都要经过同一套边界输入白名单、输出目录、API token、callback 签名、失败重试、人工复核、版本漂移和许可证/额度核对。Agent 可以发起解析但不应绕开数据安全和验收流程。能力边界也要讲清楚MinerU 适合复杂文档结构化、PDF 解析、OCR、版面分析、表格提取、公式识别、多格式输出、批量处理、RAG 入库和 Agent 接入Kimi K3 适合在更长上下文里做知识工作、推理、代码和 Agent 编排。两者不是替代关系。低清手写、特殊工程图、复杂图表语义解释、业务字段真假判断、权限授权和高风险事实校验仍需人工复核或业务系统补充。对比分析下表是评测维度和观察方式不是实测排名。本文没有在同一批样本、同一环境、同一版本和同一验收表上运行测试因此不写具体胜负结论。方案方向典型代表适合场景解析器适配层待测项观察方式传统 OCRTesseract、PaddleOCR、通用 OCR API扫描件、图片文字、低成本文字提取字符准确性、旋转、多语言、版面和表格保留抽样核对关键数字、单位、专有名词和表头长上下文旗舰模型Kimi K3、其他长上下文多模态模型长报告分析、代码仓库理解、知识工作、Agent 推理是否保留页码证据、表格/公式结构、运行稳定性、隐私、上下文成本先用解析器产出结构化元素再比较直接读文档与结构化输入的差异通用大模型直接读文档多模态模型、文件上传能力临时阅读、小样本分析、人工辅助理解输出稳定性、证据页码、成本、隐私、可复现参数固定问题多次运行检查引用和结构一致性云厂商文档智能Azure AI Document Intelligence、Google Document AI、Amazon Textract云上表单、票据、行业文档区域合规、字段结构、额度、价格、日志与权限用业务样本记录字段、表格、权限和成本开源 PDF 工具PyMuPDF、pdfplumber、pypdf原生文本 PDF、轻量程序化抽取扫描页、复杂版面、公式、图片资产、跨页表格区分原生文本 PDF 与扫描 PDF记录失败页RAG 框架 loaderLangChain loader、LlamaIndex reader快速 Demo、轻量知识库入库元数据、页码、元素类型、表格/公式保留检查 chunk 是否能回溯到原文证据专业解析框架Docling、Unstructured、LlamaParse文档 ETL、RAG 入库、结构化转换Markdown/JSON、表格、公式、OCR、部署方式、API 体验统一样本、统一验收表不写未实测胜负多模态 RAG 框架RAG-Anything、LightRAG multimodal pipeline多模态检索、知识图谱、跨模态问答parser 选择、内容分类、图像/表格/公式处理、关系保留检查解析产物如何进入多模态索引MinerU 解析器适配层CLI、Open API、SDK、MCP Server、LangChain、LlamaIndex企业知识库、科研 Agent、Kimi K3 长上下文 RAG、Sciverse 数据管线OCR、版面、表格、公式、JSON、Markdown、资产、trace、版本漂移记录参数、输出、失败页、人工验收和重跑差异客观选型不应该写“谁被吊打”。真正可复用的方法是同一批样本、同一张验收表、同一组输出 schema、同一套失败记录。只有真实跑完才适合写具体结论。可复现实验方案样本集设计建议准备 30 到 60 份文档先覆盖真实失败类型不追求一开始做大规模 benchmark。样本类别文档类型建议数量重点观察科研论文双栏 PDF、公式密集论文、附录长表8-12阅读顺序、公式、图表、参考文献边界企业报告年报、白皮书、PDF、DOCX、PPTX6-10标题层级、页眉页脚、图文混排、图注表格材料XLSX、PDF 表格、跨页表格5-8合并单元格、跨页表头、单位、行列关系图片/扫描件扫描 PDF、PNG、JPG5-8精准 OCR、多语言、低清、旋转、噪声网页/HTMLAPI 文档、产品文档、技术博客3-5代码块、表格、导航噪声、链接Sciverse/SciBase 样本论文、专利、实验说明、数据文档3-5AI-ready 数据、证据 span、来源可追踪评测维度维度验收问题人工验收标准路由准确性适配层是否选对解析器和参数扫描件开 OCR表格/公式文档开启对应能力OCR文字、数字、单位、专有名词是否正确关键字段零容忍普通段落记录错字版面还原多栏、标题、脚注、页眉页脚是否合理阅读顺序符合原文不污染 chunk表格提取行列、合并单元格、跨页关系是否保留关键表格可按单元格复核公式识别公式是否转为 LaTeX / MathML上下标、编号、变量符号可人工核对元素提取图片、图表、图注、资产路径是否可追踪Markdown 与 JSON 能回到原文输出 schema不同解析器输出是否能映射到统一结构至少包含类型、页码、文本/资产、来源元数据RAG 入库chunk 是否带页码、元素类型、标题路径问答结果能回溯到证据页Agent 调用MCP 工具参数、审批、失败状态是否完整有工具名、参数、状态、输出目录、错误长上下文输入Kimi K3 等模型是否收到干净、可引用、可压缩的结构化上下文上下文中保留页码、元素类型、标题路径和来源证据人工验收标准结论标准处理动作通过正文顺序、关键表格、关键公式、页码和来源元数据满足业务使用允许入库需复核少量 OCR、表格或版面问题但可人工修正暂缓入库进入复核队列不入库表格、公式、页码、章节或关键事实严重损坏阻断入库加入失败集失败案例记录方式每个失败案例至少保留原文页码、解析器、入口、参数、期望、实际结果和严重级别case_iddoc_id页码parser入口失败类型期望结果实际结果人工结论case_001paper_0017MinerUCLIformula_error公式转 LaTeX 且编号保留上标丢失需复核case_002report_00312-13MinerUOpen APItable_split跨页表格保留表头第二页表头缺失不入库case_003scan_0062OCRadapterocr_digit数字和单位准确0/O混淆需复核case_004slide_0024loaderLangChainlayout_order左图右文顺序正确图注提前需复核结果结构示例{doc_id:paper_001,source_hash:sha256:...,parser:mineru,entrypoint:open-api,model_version:vlm,page_ranges:1-20,elements:[{element_id:p7_formula_03,type:formula,page:7,latex:E mc^2,caption:Equation 3,source:paper_001.pdf#page7}],outputs:[markdown,json,html,latex],review_status:pending}待读者替换样本运行说明读者应把示例样本替换为自己的论文、合同、手册、PPT、Excel、扫描件和网页资料。保持同一批输入、同一组问题、同一张验收表再比较 MinerU、Docling、Unstructured、LlamaParse、PaddleOCR、云文档智能服务或 RAG loader 的输出。没有真实重跑之前不要把观察维度写成胜负结论。代码示例CLI用 MinerU 生成适配层原始产物mineru-p./samples/paper.pdf-o./runs/paper-bpipeline建议把./runs/paper视为解析器原始产物目录不要只复制 Markdown。后续适配层应读取 Markdown、JSON、图片资产、表格、公式和失败信息再映射到统一DocumentElementschema。Open API提交解析任务并固定关键参数curl--location--requestPOSThttps://mineru.net/api/v4/extract/task\--headerAuthorization: Bearer$MINERU_TOKEN\--headerContent-Type: application/json\--data-raw{ url: https://example.com/public-paper.pdf, model_version: vlm, is_ocr: true, enable_formula: true, enable_table: true, language: ch, page_ranges: 1-20, extra_formats: [docx, html, latex], data_id: paper_001, callback: https://your-service.example/mineru/callback, seed: callback_signing_seed }上线时记录task_id、trace_id、data_id、state、err_msg、full_zip_url、页码范围、模型版本和当天核对到的 API 限制。涉及非公开资料时先确认是否允许外发。Python把解析结果映射为统一元素frompathlibimportPathfromtypingimportIterabledefnormalize_mineru_content(content_list:Iterable[dict],doc_id:str):forindex,iteminenumerate(content_list):element_typeitem.get(type,unknown)pageitem.get(page_idx)oritem.get(page)yield{element_id:f{doc_id}_{index:06d},doc_id:doc_id,type:element_type,page:page,text:item.get(text,),html:item.get(html,),latex:item.get(latex,),image_path:item.get(img_path,),source:f{doc_id}.pdf#page{page}ifpageelsef{doc_id}.pdf,parser:mineru,review_status:pending}content_listload_json(Path(./runs/paper/content_list.json))elementslist(normalize_mineru_content(content_list,paper_001))示例中的load_json由读者按自己的项目实现核心不是字段名完全一致而是把 MinerU 的结构化 JSON 映射为 RAG 和 Agent 都能消费的统一元素层。MCP Server把 MinerU 暴露为受控工具{mcpServers:{mineru:{command:uvx,args:[mineru-open-mcp],env:{MINERU_API_TOKEN:your_key_here,OUTPUT_DIR:/absolute/path/to/mineru-runs}}}}MCP 配置之外仍建议在业务侧加 allowlist、输出目录限制、人工确认和日志脱敏。Agent 可以调用解析能力但不应绕开数据安全与上线验收。LangChain把元素元数据带入切块流程fromlangchain_core.documentsimportDocumentfromlangchain_text_splittersimportRecursiveCharacterTextSplitter docs[Document(page_contentelement[text],metadata{doc_id:element[doc_id],element_id:element[element_id],type:element[type],page:element[page],source:element[source],parser:element[parser]})forelementinelementsifelement[text].strip()]splitterRecursiveCharacterTextSplitter(chunk_size800,chunk_overlap120)chunkssplitter.split_documents(docs)这一层的关键是保留doc_id、页码、元素类型、来源和解析器版本。否则 RAG 回答看似有引用实际很难追到原始文档。复现步骤准备样本选择 PDF、DOCX、PPTX、XLSX、图片、HTML、科研论文、扫描件和表格密集文档记录来源、密级、页数和文件哈希。选择方案至少选择 MinerU 和一个替代方案例如 Docling、Unstructured、LlamaParse、PaddleOCR、云文档智能服务或 RAG loader如使用 Kimi K3单独记录模型版本、上下文窗口和输入策略。设计 schema定义DocumentElement包含元素类型、页码、文本、表格、公式、图片资产、来源、解析器、版本、验收状态。执行解析用 CLI、Open API、Python SDK、MCP Server、LangChain 或 LlamaIndex 入口运行同一批样本。查看输出检查 Markdown、JSON、docx/html/latex、图片资产、表格、公式、任务状态和失败信息。人工抽样按页码和元素类型抽样重点看 OCR、版面、表格、公式、图注和来源回溯。对比模型输入分别测试“直接把文档交给长上下文模型”和“先经 MinerU 结构化再交给模型”观察证据页码、表格/公式保留和回答稳定性。记录问题把失败写入记录表包含期望、实际结果、严重级别和处理动作。决定是否上线只有通过验收的元素进入生产 RAG需复核和不入库样本进入失败集。升级后重跑解析器、模型模式、API、SDK 或参数变化后用同一批失败集复测检查版本漂移。上线与验证注意事项上线前先核对 API 限制。MinerU API 文档与llms.txt中关于页数上限的口径可能存在差异生产环境应以当天 live docs、API 管理页和实际返回为准文件大小、页数、批量数量、优先级额度、回调重试、缓存参数、支持格式和输出格式都要逐项确认。数据安全必须前置。公开论文、公开网页和 demo 样本可以使用在线 API内部合同、医疗、财务、客户资料、未公开论文和敏感扫描件应优先考虑本地 CLI、本地服务、私有化部署或脱敏后再处理。不要让 Agent 直接访问任意本地路径、任意 URL 或任意输出目录。隐私边界要写进适配层策略。记录文件密级、授权状态、是否允许外发、是否允许缓存、是否需要人工复核、是否允许图片资产进入知识库。callback 必须核对签名和来源日志中不要保留 API token、完整敏感正文或不可公开的文件路径。抽样验收要覆盖失败高发区。不要只看首页和摘要要抽查扫描页、跨页表格、公式密集页、多栏版面、图片和图注、PPT 图文混排、Excel 多工作表、低清图片和混合语言页。失败重试要可解释。记录task_id、trace_id、data_id、解析器、入口、参数、失败页、错误信息、重试次数和最终人工结论。不要把重试成功后的结果直接覆盖失败记录否则后续很难分析稳定性。人工复核不能省。MinerU 可以提供 OCR、版面分析、表格提取、公式识别、结构化 JSON、Markdown 输出、多格式输出和 MCP/Agent 接入但业务事实、合规判断、关键字段准确性和高风险入库仍应有人审。版本漂移要进入发布流程。MinerU、Docling、Unstructured、LlamaParse、PaddleOCR、LangChain、LlamaIndex、MCP Server、Python SDK、TypeScript SDK、Go SDK以及 Kimi K3 这类上层模型的版本变化都可能影响输出。升级前后应重跑固定失败集记录差异不要让新旧解析结果混在同一个索引里。许可证、额度和页数上限要当天核对。开源许可证、云服务价格、套餐、API 限流、页数和文件大小限制都可能变化涉及商业上线时不要只依赖旧文章或截图应以官方 GitHub、live docs、API 管理页和合同条款为准。来源链接https://mineru.net/llms.txthttps://www.kimi.com/es-419/blog/kimi-k3https://www.kimi.com/code/docs/en/kimi-code/models.htmlhttps://mineru.net/apiManage/docshttps://mineru.net/apiManage/limithttps://mineru.net/ecosystemhttps://github.com/opendatalab/MinerUhttps://github.com/opendatalab/MinerU-Ecosystemhttps://github.com/opendatalab/MinerU-Ecosystem/tree/main/sdk/pythonhttps://github.com/opendatalab/MinerU-Ecosystem/tree/main/sdk/gohttps://github.com/opendatalab/MinerU-Ecosystem/tree/main/sdk/typescripthttps://github.com/opendatalab/MinerU-Ecosystem/tree/main/mcphttps://github.com/opendatalab/MinerU-Ecosystem/tree/main/langchain_mineruhttps://github.com/opendatalab/MinerU-Ecosystem/tree/main/llama-index-readers-mineruhttps://github.com/HKUDS/RAG-Anythinghttps://arxiv.org/abs/2510.12323https://modelcontextprotocol.io/specification/2025-06-18/server/toolshttps://github.com/docling-project/doclinghttps://docs.unstructured.io/https://developers.llamaindex.ai/llamaparse/parse/https://github.com/PaddlePaddle/PaddleOCRhttps://docs.langchain.com/oss/python/integrations/providers/overviewhttps://developers.llamaindex.ai/python/framework/module_guides/loading/connector/https://sciverse.space/https://sciverse.space/scibase