结合热点· 2026.04.22 | Kimi K2.6 开源炸场300 个 Agent 并行、13 小时连续编码——但 Agent 能力再强喂进去的文档是垃圾输出也是垃圾。这两天 Kimi K2.6 开源的消息刷屏了。300 个子 Agent 并行、连续编码 13 小时、SWE-Bench Pro 超越 GPT-5.4……看起来 Agent 时代真的来了。但我想聊一个没人提的问题Agent 再强它处理的第一手材料是你喂进去的文档。文档解析这一环崩了后面全白搭。我接触过十几个企业 RAG 项目问题惊人地相似——不是模型不够强是文档在进向量库之前就已经烂掉了。一、RAG 失效的真实原因某甲方 100 多份 PDF 直接丢进知识库上线后问什么都答非所问。排查下来发现30% 的检索命中内容是页眉页脚和目录。这不是个案。文档解析的典型失效场景场景传统工具的表现对 RAG 的实际影响双栏 PDF论文/报告左右栏交叉混读语义碎片化检索全是噪声含合并单元格的表格结构丢失变成乱序文字财报/合同数据全错数学公式截图或乱码技术文档/论文不可用扫描件/手写稿pdfplumber 直接报空历史档案、合同扫描件完全失效页眉页脚/水印原样保留进向量库每个 chunk 都带噪声污染召回结论文档解析不是 RAG 的前处理它是决定 RAG 天花板的核心环节。二、MinerU 3.0这次有几个真实的变化MinerU 是上海 AI Lab 开源的文档解析引擎4 月 11 日刚发布 3.0不是小升级。2.1 三个值得关注的变化① DOCX 原生解析速度提升数十倍之前 DOCX 要转成 PDF 再解析现在直接端到端处理。实测 100 页 Word 文档从 ~40 秒降到 2 秒。② 长文档流式落盘 线程安全3.0 引入滑动窗口 流式落盘解决了上万页文档的内存峰值问题。以前跑 500 页 PDF 容易 OOM现在稳了。③ mineru-router多 GPU 负载均衡一键部署# 启动多 GPU 路由服务mineru-router--workers4--port8080# 单次解析请求自动分发到空闲 GPUcurl-XPOST http://localhost:8080/parse\-Ffilelarge_report.pdf\-Fmodeprecision2.2 架构层的大动作MinerU-Diffusion官方 Roadmap 里有一个正在训练中的新版本——MinerU-Diffusion用扩散模型替代自回归做 OCR并行解码速度提升约 4 倍。目前 V1 已发布V2 在训练中。这条路线的逻辑OCR 本质是逆渲染而非写作不应该用自回归逐 token 生成扩散模型天然更适合这种并行任务。三、和 Kimi K2.6 的关系Document to SkillKimi K2.6 这次发布了一个容易被忽视的功能Document to Skill——把 Office 文档直接转化为可复用的 Agent 技能。这和 MinerU 形成了明确的上下游文档质量直接决定 Agent 能力上限。如果文档解析在第一步就引入了噪声300 个 Agent 并行只是在放大错误。四、五工具横评选哪个实测数据来源OmniDocBench v1.6 及社区评测工具综合准确率公式识别表格还原阅读顺序GPU 速度扫描件MinerU 2.590.7%87.4%85.6%94.1%1.8 页/s✅ VLMLlamaParse~76%65%74%78%云端 API✅PyMuPDF~82%❌54%85%3.2 页/s⚠️pdfplumber~71%❌62%76%2.1 页/s❌Unstructured~74%~40%58%72%~1.2 页/s✅一句话选型纯文字 PDF 且格式规范 → PyMuPDF最快含公式/表格/扫描件的复杂文档 → MinerU不想部署只要 API → LlamaParse但收费且无法本地化。五、完整 RAG Pipeline 代码5.1 安装pipinstallmineru langchain-mineru langchain-openai langchain-community faiss-cpu5.2 单文件 RAG从 PDF 到可问答importos from langchain_mineruimportMinerULoader from langchain.text_splitterimportMarkdownHeaderTextSplitter from langchain_community.vectorstoresimportFAISS from langchain_openaiimportOpenAIEmbeddings, ChatOpenAI from langchain.chainsimportRetrievalQA# ── Step 1: 解析文档 ─────────────────────────────────────────# modeprecision → VLM 模式适合扫描件/复杂版面精度优先# modespeed → pipeline 模式适合电子 PDF速度优先loaderMinerULoader(sourceannual_report.pdf,modeprecision)docsloader.load()print(f解析完成共 {len(docs)} 个块首块预览\n{docs[0].page_content[:200]})# ── Step 2: 按 Markdown 标题切分保留语义边界避免切片粗暴splitterMarkdownHeaderTextSplitter(headers_to_split_on[(#,h1),(##,h2),(###,h3)],strip_headersFalse,)chunkssplitter.split_text(docs[0].page_content)print(f切分完成共 {len(chunks)} 个 chunk)# ── Step 3: 向量化 持久化 ───────────────────────────────────embeddingsOpenAIEmbeddings(modeltext-embedding-3-small)vectorstoreFAISS.from_documents(chunks, embeddings)vectorstore.save_local(./faiss_index)# ── Step 4: 问答链 ─────────────────────────────────────────────llmChatOpenAI(modelgpt-4o-mini,temperature0)qaRetrievalQA.from_chain_type(llmllm,retrievervectorstore.as_retriever(search_kwargs{k:4}),return_source_documentsTrue,)resultqa.invoke({query:2025 年营收同比增长多少})print(result[result])# 来源溯源forsrcinresult[source_documents]: print(f 来源段落: {src.page_content[:80]}...)5.3 批量处理生产环境版含自动模式判断importglob from pathlibimportPath from langchain_mineruimportMinerULoader from langchain_community.vectorstoresimportFAISS from langchain_openaiimportOpenAIEmbeddings def detect_mode(pdf_path: str)-str: 简单启发式文件名含scan/扫描或文件5MB 时用 precision 其余用 speed 节省资源 namePath(pdf_path).stem.lower()size_mbPath(pdf_path).stat().st_size /1024/1024ifscaninname or扫描inname or size_mb5:returnprecisionreturnspeeddef build_knowledge_base(pdf_dir: str, index_path: str): pdf_filesglob.glob(f{pdf_dir}/**/*.pdf,recursiveTrue)print(f发现 {len(pdf_files)} 个 PDF)all_docs[]stats{precision:0,speed:0,failed:0}forpdf_pathinpdf_files: modedetect_mode(pdf_path)try: loaderMinerULoader(sourcepdf_path,modemode)docsloader.load()fordocindocs: doc.metadata.update({source_file:Path(pdf_path).name,parse_mode:mode,})all_docs.extend(docs)stats[mode]1print(f ✅ [{mode:9s}] {Path(pdf_path).name}: {len(docs)} 块)except Exception as e: stats[failed]1print(f ❌ {Path(pdf_path).name}: {e})print(f\n汇总: precision{stats[precision]}, speed{stats[speed]}, failed{stats[failed]})embeddingsOpenAIEmbeddings(modeltext-embedding-3-small)vectorstoreFAISS.from_documents(all_docs, embeddings)vectorstore.save_local(index_path)print(f知识库写入 {index_path}共 {len(all_docs)} 个 chunk)returnvectorstore# 执行build_knowledge_base(./company_docs,./faiss_index)六、真实踩坑记录4 条坑 1扫描件必须用 mode“precision”modespeed走 pipeline图像版面分析依赖 PDF 自带文本层。扫描件没有文本层输出是空或乱码。判断方法用 pdfplumber 试提取如果文字数量 10基本可判定为扫描件强制走 VLM 模式。坑 2VLM 模式显存要求 ≥8GB峰值显存约 6.8GB4GB 卡会 OOM。只有 CPU 的话用modespeed速度从 1.8 页/s 降到 0.4 页/s但能跑。或者用云端 APImineru.net省去部署麻烦。坑 3首次启动冷加载约 1520 秒模型文件约 25GB首次loader.load()调用需等待模型加载。批量处理时只加载一次摊薄后不影响吞吐。生产环境建议提前 warmupMinerULoader(sourcetest.pdf).load()。坑 4按字数切片是错的RecursiveCharacterTextSplitter(chunk_size500)会在句子中间切断导致语义碎片。MinerU 输出的是结构化 Markdown应该用MarkdownHeaderTextSplitter按标题切保留完整语义段。七、选型决策树八、快速上手# 安装pipinstallmineru# 命令行一行解析mineru-pyour_file.pdf-o./output--modeprecision# 输出# output/your_file.md ← 结构化 Markdown# output/images/ ← 提取的图片# output/your_file_middle.json ← 带坐标信息供二次开发3.0 新增直接解析 DOCXmineru-preport.docx-o./output项目地址https://github.com/opendatalab/MinerU总结Agent 能力再强喂进去的是噪声输出就是垃圾。Kimi K2.6 的 300 Agent 并行让 AI 处理复杂任务成为可能。但在这之前你需要一个能把文档真正变成结构化知识的工具。MinerU 3.0 就是做这件事的——不是能提取文字而是能让 AI 读懂文档。这两件事现在正好是同一个时间节点在同时变强。