结合热点 · 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 --workers 4 --port 8080

# 单次解析请求自动分发到空闲 GPU
curl -X POST http://localhost:8080/parse \
  -F "file=@large_report.pdf" \
  -F "mode=precision"

2.2 架构层的大动作：MinerU-Diffusion

官方 Roadmap 里有一个正在训练中的新版本——MinerU-Diffusion，用扩散模型替代自回归做 OCR，并行解码，速度提升约 4 倍。目前 V1 已发布，V2 在训练中。

这条路线的逻辑：OCR 本质是"逆渲染"而非"写作"，不应该用自回归逐 token 生成，扩散模型天然更适合这种并行任务。

三、和 Kimi K2.6 的关系：Document to Skill

Kimi K2.6 这次发布了一个容易被忽视的功能：Document to Skill——把 Office 文档直接转化为可复用的 Agent 技能。

这和 MinerU 形成了明确的上下游：
在这里插入图片描述

文档质量直接决定 Agent 能力上限。 如果文档解析在第一步就引入了噪声，300 个 Agent 并行只是在放大错误。

四、五工具横评：选哪个？

实测数据（来源：OmniDocBench v1.6 及社区评测）：

工具

综合准确率

公式识别

表格还原

阅读顺序

GPU 速度

扫描件

MinerU 2.5

90.7%

87.4%

85.6%

94.1%

1.8 页/s

✅ VLM

LlamaParse

~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 安装

pip install mineru langchain-mineru langchain-openai langchain-community faiss-cpu

5.2 单文件 RAG：从 PDF 到可问答

import os
from langchain_mineru import MinerULoader
from langchain.text_splitter import MarkdownHeaderTextSplitter
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.chains import RetrievalQA

# ── Step 1: 解析文档 ─────────────────────────────────────────
# mode="precision" → VLM 模式，适合扫描件/复杂版面（精度优先）
# mode="speed"     → pipeline 模式，适合电子 PDF（速度优先）
loader = MinerULoader(source="annual_report.pdf", mode="precision")
docs = loader.load()
print(f"解析完成，共 {len(docs)} 个块，首块预览：\n{docs[0].page_content[:200]}")

# ── Step 2: 按 Markdown 标题切分（保留语义边界，避免切片粗暴）
splitter = MarkdownHeaderTextSplitter(
    headers_to_split_on=[("#", "h1"), ("##", "h2"), ("###", "h3")],
    strip_headers=False,
)
chunks = splitter.split_text(docs[0].page_content)
print(f"切分完成，共 {len(chunks)} 个 chunk")

# ── Step 3: 向量化 + 持久化 ───────────────────────────────────
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = FAISS.from_documents(chunks, embeddings)
vectorstore.save_local("./faiss_index")

# ── Step 4: 问答链 ─────────────────────────────────────────────
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
qa = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=vectorstore.as_retriever(search_kwargs={"k": 4}),
    return_source_documents=True,
)

result = qa.invoke({"query": "2025 年营收同比增长多少？"})
print(result["result"])
# 来源溯源
for src in result["source_documents"]:
    print(f"  来源段落: {src.page_content[:80]}...")

5.3 批量处理（生产环境版，含自动模式判断）

import glob
from pathlib import Path
from langchain_mineru import MinerULoader
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings

def detect_mode(pdf_path: str) -> str:
    """
    简单启发式：文件名含 'scan'/'扫描' 或文件 >5MB 时用 precision
    其余用 speed 节省资源
    """
    name = Path(pdf_path).stem.lower()
    size_mb = Path(pdf_path).stat().st_size / 1024 / 1024
    if "scan" in name or "扫描" in name or size_mb > 5:
        return "precision"
    return "speed"


def build_knowledge_base(pdf_dir: str, index_path: str):
    pdf_files = glob.glob(f"{pdf_dir}/**/*.pdf", recursive=True)
    print(f"发现 {len(pdf_files)} 个 PDF")

    all_docs = []
    stats = {"precision": 0, "speed": 0, "failed": 0}

    for pdf_path in pdf_files:
        mode = detect_mode(pdf_path)
        try:
            loader = MinerULoader(source=pdf_path, mode=mode)
            docs = loader.load()
            for doc in docs:
                doc.metadata.update({
                    "source_file": Path(pdf_path).name,
                    "parse_mode": mode,
                })
            all_docs.extend(docs)
            stats[mode] += 1
            print(f"  ✅ [{mode:9s}] {Path(pdf_path).name}: {len(docs)} 块")
        except Exception as e:
            stats["failed"] += 1
            print(f"  ❌ {Path(pdf_path).name}: {e}")

    print(f"\n汇总: precision={stats['precision']}, speed={stats['speed']}, failed={stats['failed']}")
    
    embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
    vectorstore = FAISS.from_documents(all_docs, embeddings)
    vectorstore.save_local(index_path)
    print(f"知识库写入 {index_path}，共 {len(all_docs)} 个 chunk")
    return vectorstore


# 执行
build_knowledge_base("./company_docs", "./faiss_index")

六、真实踩坑记录（4 条）

坑 1：扫描件必须用 mode=“precision”

mode="speed" 走 pipeline（图像版面分析），依赖 PDF 自带文本层。扫描件没有文本层，输出是空或乱码。判断方法：用 pdfplumber 试提取，如果文字数量 <10，基本可判定为扫描件，强制走 VLM 模式。

坑 2：VLM 模式显存要求 ≥8GB

峰值显存约 6.8GB，4GB 卡会 OOM。只有 CPU 的话用 mode="speed"，速度从 1.8 页/s 降到 0.4 页/s，但能跑。或者用云端 API（mineru.net），省去部署麻烦。

坑 3：首次启动冷加载约 15～20 秒

模型文件约 2～5GB，首次 loader.load() 调用需等待模型加载。批量处理时只加载一次，摊薄后不影响吞吐。生产环境建议提前 warmup：MinerULoader(source="test.pdf").load()。

坑 4：按字数切片是错的

RecursiveCharacterTextSplitter(chunk_size=500) 会在句子中间切断，导致语义碎片。MinerU 输出的是结构化 Markdown，应该用 MarkdownHeaderTextSplitter 按标题切，保留完整语义段。

七、选型决策树

在这里插入图片描述

八、快速上手

# 安装
pip install mineru

# 命令行一行解析
mineru -p your_file.pdf -o ./output --mode precision

# 输出：
# output/your_file.md          ← 结构化 Markdown
# output/images/               ← 提取的图片
# output/your_file_middle.json ← 带坐标信息，供二次开发

3.0 新增：直接解析 DOCX

mineru -p report.docx -o ./output

项目地址：https://github.com/opendatalab/MinerU

总结

Agent 能力再强，喂进去的是噪声，输出就是垃圾。

Kimi K2.6 的 300 Agent 并行让 AI 处理复杂任务成为可能。但在这之前，你需要一个能把文档真正变成结构化知识的工具。MinerU 3.0 就是做这件事的——不是"能提取文字"，而是"能让 AI 读懂文档"。

这两件事，现在正好是同一个时间节点在同时变强。

# 人工智能 # 新媒体运营 # 个人开发 # 大数据 # 产品运营 # 内容运营
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

AtomGit 首发开源｜光轮智能发布全球首个十万小时级全模态人类行为开源数据集 EgoSuite-Open100K

avatar AtomGit开源社区
cover

构筑赋能金融行业应用 Agent｜20 强决战北京，一场金融 Agent 的硬核答卷

avatar AtomGit开源社区
cover

昇腾 0 Day 支持 Hunyuan4-preview，770B MoE 旗舰模型开源即适配

avatar AtomGit开源社区