8月中旬的時(shí)候，我去MinerU的辦公室交流過(guò)一次。當(dāng)時(shí)對(duì)方有位工作人員表示，接下來(lái)會(huì)很快基于視覺(jué)模型的路線實(shí)現(xiàn)全面 SOTA。說(shuō)實(shí)話，那個(gè)時(shí)候我還挺懷疑的。畢竟，那個(gè)時(shí)候MinerU2.0從6月中旬算起，已經(jīng)發(fā)布了快兩個(gè)月。但我在手頭一些復(fù)雜布局的項(xiàng)目文檔測(cè)試發(fā)現(xiàn)，實(shí)際和Textin這種閉源產(chǎn)品還是有不小差距。

然后，MinerU2.5.4 在9月26 號(hào)更新后，我又上手測(cè)試了些之前的 corner cases，這次不得不說(shuō)效果驚艷了很多。雖然依然因?yàn)閅OLO的許可協(xié)議限制，沿用了 AGPL-3.0 的許可證，但是作為開源項(xiàng)目還是值得拆解學(xué)習(xí)下其中的很多工程思路。

這篇試圖說(shuō)清楚：

MinerU2.5的性能評(píng)測(cè)效果、雙后端架構(gòu)設(shè)計(jì)梳理、核心實(shí)現(xiàn)原理源碼拆解、部署與許可證注意事項(xiàng)，以及企業(yè)集成與擴(kuò)展參考。

1、MinerU2.5評(píng)測(cè)效果

1.1基準(zhǔn)測(cè)試情況

根據(jù)官方發(fā)布的技術(shù)報(bào)告文檔（https://arxiv.org/abs/2509.22186），MinerU 2.5 在權(quán)威的 OmniDocBench 基準(zhǔn)測(cè)試中，實(shí)現(xiàn)了全面 SOTA，尤其是在布局檢測(cè)、文本識(shí)別、表格識(shí)別、公式識(shí)別等關(guān)鍵指標(biāo)上，也超過(guò)了 Gemini 2.5-Pro、GPT-4o 等模型。

同時(shí)，相比開源文檔解析方案（如 MonkeyOCR、PP-StructureV3），MinerU2.5 在解析精度、結(jié)構(gòu)完整性和格式自然度方面也表現(xiàn)出了明顯的領(lǐng)先優(yōu)勢(shì)。

1.2迭代效果一覽

首先看下復(fù)雜的數(shù)學(xué)公式解析效果，傳統(tǒng)方案很容易出現(xiàn)符號(hào)遺漏或者結(jié)構(gòu)錯(cuò)亂，MinerU2.5 最新版本能夠比較準(zhǔn)確識(shí)別長(zhǎng)難公式，并輸出 LaTeX 代碼，直接渲染為完整公式。這點(diǎn)也算是小試牛刀了下。

其次，對(duì)于財(cái)報(bào)中的復(fù)雜表格而言，傳統(tǒng)模型往往輸出結(jié)構(gòu)散亂，而 MinerU2.5 能夠完整保持原始表格結(jié)構(gòu)。

不過(guò)值得注意的是，在這個(gè)英文財(cái)報(bào)中對(duì)于一個(gè)比較簡(jiǎn)單的文本段落，MinerU2.5 丟失了其中的美元符號(hào)，并莫名的把字體變成了紅色表示，這說(shuō)明其微調(diào)數(shù)據(jù)中，獨(dú)立的數(shù)字比"$+數(shù)字"的組合更常見，所以模型傾向于只輸出數(shù)字。

其次，這個(gè)例子中也出現(xiàn)了比較嚴(yán)重的文本重復(fù)和日期混亂問(wèn)題，原文中是提到了兩種假設(shè)情況，視覺(jué)模型可能試圖同時(shí)表達(dá)這兩種情況，但因?yàn)槿狈γ鞔_的結(jié)構(gòu)化約束，導(dǎo)致生成時(shí)兩種描述被錯(cuò)誤地融合，這也算是端到端模型的原罪了。

最后貼張官方公眾號(hào)的一些解析效果匯總圖示，總的來(lái)說(shuō)這次MinerU2.5比較能打。但如果需要處理金融、法律等精確性要求極高的文檔，還是不要完全依賴端到端視覺(jué)模型。

2、雙后端架構(gòu)設(shè)計(jì)

MinerU 2.5 采用了雙后端互斥選擇的機(jī)制，這種設(shè)計(jì)體現(xiàn)了不同技術(shù)路徑在文檔解析領(lǐng)域的本質(zhì)差異。

傳統(tǒng)的 Pipeline 后端代表了現(xiàn)在業(yè)界有充分共識(shí)的“多模型協(xié)作”思路，通過(guò) 8 個(gè)專業(yè)子模型分工合作，每個(gè)模型專注于特定任務(wù)，如布局檢測(cè)、公式識(shí)別、OCR 等。這種方式的優(yōu)勢(shì)在于可控性強(qiáng)、問(wèn)題定位精確，每個(gè)環(huán)節(jié)都可以獨(dú)立優(yōu)化。

而 MinerU2.0 版本開始引入的 VLM 后端，選擇了端到端的路線。也就是使用單一的視覺(jué)大模型處理整個(gè)文檔解析流程。這種方式的核心優(yōu)勢(shì)是模型間的信息傳遞更加順暢，避免了傳統(tǒng)流水線中的誤差累積問(wèn)題。

2.1Pipeline 后端

Pipeline 后端采用了經(jīng)典的分而治之策略，把復(fù)雜的文檔解析任務(wù)分解為 8 個(gè)相對(duì)獨(dú)立的子任務(wù)。這種做法追求的是識(shí)別準(zhǔn)確率和錯(cuò)誤可控性。在源碼中，這 8 個(gè)子模型通過(guò) mineru/bckend/pipeline/model_list.py 文件進(jìn)行統(tǒng)一定義：

class AtomicModel:
    Layout = "layout"              # 布局檢測(cè)
    MFD = "mfd"                   # 數(shù)學(xué)公式檢測(cè)
    MFR = "mfr"                   # 數(shù)學(xué)公式識(shí)別
    OCR = "ocr"                   # 文字識(shí)別
    WirelessTable = "wireless_table"  # 無(wú)線表格
    WiredTable = "wired_table"        # 有線表格
    TableCls = "table_cls"            # 表格分類
    ImgOrientationCls = "img_ori_cls" # 圖像方向分類

這個(gè)類定義看似簡(jiǎn)單，實(shí)際上是整個(gè) Pipeline 后端的“協(xié)議規(guī)范”。每個(gè)字符串常量都對(duì)應(yīng)著一個(gè)專門的深度學(xué)習(xí)模型，這些模型在mineru/backend/pipeline/model_init.py中被具體實(shí)例化。 

以下是 Pipeline 后端的處理流程圖。

每個(gè)子模型的技術(shù)選型也都體現(xiàn)了在特定任務(wù)上的最佳實(shí)踐，以下選擇三個(gè)模型簡(jiǎn)要描述下：

布局檢測(cè)模型

這部分采用的是 DocLayoutYOLO 架構(gòu)，源碼位于mineru/mod/layout/doclayoutyolo.py。選擇 YOLO 系列當(dāng)然是因?yàn)槠湓谀繕?biāo)檢務(wù)上的成熟性和實(shí)時(shí)性優(yōu)勢(shì)，能夠快速準(zhǔn)確地識(shí)別文檔中的各種區(qū)域類型。

數(shù)據(jù)公式處理

這部分采用了“檢測(cè)+識(shí)別”的兩階段策略。MFD 使用 YOLOv8 進(jìn)行公式區(qū)域定位，MFR 使用 UniMERNet 進(jìn)行公式內(nèi)容識(shí)別。這種分離設(shè)計(jì)的優(yōu)勢(shì)在于可以針對(duì)性地優(yōu)化每個(gè)階段的性能。

表格處理

這部分實(shí)現(xiàn)了三層處理架構(gòu)，具體來(lái)說(shuō)，先通過(guò) TableCls 進(jìn)行表格類型分類，然后根據(jù)是否有邊框選擇不同的識(shí)別模型。有線表格使用 UNet 架構(gòu)，無(wú)線表格使用 SLANet Plus 架構(gòu)，這種差異化處理是種很成熟的工程實(shí)踐，實(shí)測(cè)是可以顯著提升表格識(shí)別的準(zhǔn)確率。

從mineru/backend/pipeline/model_init.py中可以看到這些模型的導(dǎo)入關(guān)系：

# mineru/backend/pipeline/model_init.py:7-15 - 核心模型導(dǎo)入
from ...model.layout.doclayoutyolo import DocLayoutYOLOModel
from ...model.mfd.yolo_v8 import YOLOv8MFDModel
from ...model.mfr.unimernet.Unimernet import UnimernetModel
from ...model.ocr.paddleocr2pytorch.pytorch_paddle import PytorchPaddleOCR
from ...model.ori_cls.paddle_ori_cls import PaddleOrientationClsModel
from ...model.table.cls.paddle_table_cls import PaddleTableClsModel
from ...model.table.rec.slanet_plus.main import RapidTableModel
from ...model.table.rec.unet_table.main import UnetTableModel

從這段導(dǎo)入代碼可以看出 MinerU 在技術(shù)棧選擇上的務(wù)實(shí)做法，既有基于 PyTorch 的現(xiàn)代架構(gòu)（如 UniMERNet），也有基于 PaddlePaddle 的成熟方案（如 PaddleOCR），體現(xiàn)了選擇最適合的工具而非統(tǒng)一技術(shù)棧的工程哲學(xué)。

2.2VLM 后端

不同于 Pipeline 后端的經(jīng)典做法，VLM 后端代表了當(dāng)前文檔解析領(lǐng)域的一個(gè)重要技術(shù)路線。也就是從多模型協(xié)作轉(zhuǎn)向單模型端到端處理。這種方式的核心理念是利用大型視覺(jué)-語(yǔ)言模型的理解能力，讓模型直接從原始文檔圖像生成結(jié)構(gòu)化輸出。

vlm 的三種啟動(dòng)方式

VLM 后端提供了三種不同的啟動(dòng)方式，這種設(shè)計(jì)體現(xiàn)了對(duì)不同部署場(chǎng)景的靈活選擇。在mineru/cli/client.py:53-60中定義了這些選項(xiàng)：

@click.option('-b', '--backend',
    type=click.Choice(['pipeline', 'vlm-transformers', 'vlm-vllm-engine', 'vlm-http-client']),
    help="""the backend for parsing pdf:
    pipeline: More general.
    vlm-transformers: More general.
    vlm-vllm-engine: Faster(engine).
    vlm-http-client: Faster(client).""",
    default='pipeline'
)

vlm-transformers：這是最直接的方式，基于 HuggingFace Transformers 框架進(jìn)行本地推理。選擇這種方式的場(chǎng)景通常是開發(fā)調(diào)試階段，或者對(duì)數(shù)據(jù)安全有嚴(yán)格要求的離線環(huán)境。優(yōu)勢(shì)在于配置簡(jiǎn)單、依賴關(guān)系清晰，但推理速度相對(duì)較慢。

vlm-vllm-engine：這種是性能優(yōu)化的方案，使用 vLLM 引擎進(jìn)行推理加速。通過(guò) PagedAttention、連續(xù)批處理等技術(shù)，理論上能把推理速度提升 20-30 倍。這種方式適合高性能生產(chǎn)環(huán)境，特別是需要處理大批量文檔的場(chǎng)景。

vlm-http-client：最后這種是分布式部署的解決方案，采用客戶端-服務(wù)器分離的架構(gòu)。服務(wù)器端運(yùn)行模型推理服務(wù)，客戶端通過(guò) HTTP 接口調(diào)用。這種方式的最大優(yōu)勢(shì)是資源共享，多個(gè)用戶可以共享同一套 GPU 資源，顯著降低部署成本。

VLM 兩階段推理

VLM 后端最具創(chuàng)新性的設(shè)計(jì)應(yīng)該算是"兩階段推理"機(jī)制。從源碼中可以看到，在mineru/backend/vlm/vlm_analyze.py:151調(diào)用了關(guān)鍵方法： 

# mineru/backend/vlm/vlm_analyze.py:151
results = predictor.batch_two_step_extract(images=images_pil_list)

這個(gè)batch_two_step_extract方法明確體現(xiàn)了兩階段處理架構(gòu)。雖然使用的是同一個(gè)視覺(jué)大模型，但通過(guò)不同處理策略實(shí)現(xiàn)了布局分析與內(nèi)容識(shí)別的邏輯解耦。

第一階段：結(jié)構(gòu)理解與區(qū)域定位

模型接收 PDF 頁(yè)面圖像，輸出結(jié)構(gòu)化的區(qū)域信息。每個(gè)區(qū)域塊包含以下關(guān)鍵字段：

# 第一階段輸出的數(shù)據(jù)格式（從vlm_magic_model.py:20-36分析得出）
block_info = {
    "bbox": [x1, y1, x2, y2],    # 相對(duì)坐標(biāo)(0-1范圍)
    "type": "text|image|table|equation|title|...",  # 區(qū)域類型
    "content": "具體文本內(nèi)容或HTML",   # 識(shí)別的內(nèi)容
    "angle": 旋轉(zhuǎn)角度              # 區(qū)域旋轉(zhuǎn)信息
}

第二階段：內(nèi)容提取與后處理

第二階段通過(guò)MagicModel類處理第一階段的輸出，進(jìn)行分類映射和內(nèi)容優(yōu)化：

# mineru/backend/vlm/vlm_magic_model.py:51-84 - 內(nèi)容分類映射
if block_type in [
    "text", "title", "image_caption", "image_footnote",
    "table_caption", "table_footnote", "code_caption",
    "ref_text", "phonetic", "header", "footer",
    "page_number", "aside_text", "page_footnote", "list"
]:
    span_type = ContentType.TEXT
elif block_type in ["image"]:
    block_type = BlockType.IMAGE_BODY
    span_type = ContentType.IMAGE
elif block_type in ["table"]:
    block_type = BlockType.TABLE_BODY
    span_type = ContentType.TABLE
elif block_type in ["equation"]:
    block_type = BlockType.INTERLINE_EQUATION
    span_type = ContentType.INTERLINE_EQUATION

整了張圖示，方便理解 vlm 兩階段推理的完整流程：

這種設(shè)計(jì)的巧妙之處在于，把復(fù)雜的文檔理解任務(wù)分解為“先理解結(jié)構(gòu)，再提取內(nèi)容”兩個(gè)相對(duì)簡(jiǎn)單的子任務(wù)。第一階段專注于空間布局和語(yǔ)義分類，第二階段專注于內(nèi)容標(biāo)準(zhǔn)化和后處理優(yōu)化。通過(guò)這種方式，既保持了端到端模型的信息傳遞優(yōu)勢(shì)，又避免了一次性處理過(guò)于復(fù)雜任務(wù)導(dǎo)致的性能下降問(wèn)題。

3、核心實(shí)現(xiàn)原理

前面一章介紹了MinerU的架構(gòu)設(shè)計(jì)和 VLM 兩階段推理機(jī)制，這部分內(nèi)容我挑了四個(gè)覺(jué)得比較重要的核心技術(shù)實(shí)現(xiàn)原理進(jìn)行下拆解。

注意，這部分更多是算法原理層面的分析，不感興趣的直接跳到最后一段。

3.1批處理機(jī)制

MinerU在處理大批量文檔時(shí)采用了很有特色的批處理策略，不同模型根據(jù)其計(jì)算特性采用不同的批大小配置，實(shí)現(xiàn) GPU 資源的最優(yōu)利用。

其中，Pipeline 后端通過(guò)動(dòng)態(tài)批處理優(yōu)化性能，在mineru/backend/pipeline/batch_analyze.py:17-22中定義了各模型的基礎(chǔ)批大?。?/span>

# mineru/backend/pipeline/batch_analyze.py:17-22 - 批處理配置
YOLO_LAYOUT_BASE_BATCH_SIZE = 1      # 布局檢測(cè)：復(fù)雜度高，批大小為1
MFD_BASE_BATCH_SIZE = 1              # 公式檢測(cè)：精度要求高，批大小為1
MFR_BASE_BATCH_SIZE = 16             # 公式識(shí)別：可并行處理，批大小為16
OCR_DET_BASE_BATCH_SIZE = 16         # OCR檢測(cè)：高并行度，批大小為16
TABLE_ORI_CLS_BATCH_SIZE = 16        # 表格方向：輕量模型，批大小為16
TABLE_Wired_Wireless_CLS_BATCH_SIZE = 16  # 表格分類：輕量模型，批大小為16

批處理類的核心設(shè)計(jì)體現(xiàn)了對(duì)性能和資源的精確控制：

# mineru/backend/pipeline/batch_analyze.py:25-31 - 批處理控制器
class BatchAnalyze:
    def init(self, model_manager, batch_ratio: int, formula_enable, table_enable, enable_ocr_det_batch: bool = True):
        self.batch_ratio = batch_ratio          # 批處理倍率，根據(jù)GPU內(nèi)存動(dòng)態(tài)調(diào)整
        self.formula_enable = get_formula_enable(formula_enable)  # 公式識(shí)別開關(guān)
        self.table_enable = get_table_enable(table_enable)        # 表格識(shí)別開關(guān)
        self.model_manager = model_manager      # 統(tǒng)一的模型管理器
        self.enable_ocr_det_batch = enable_ocr_det_batch  # OCR批處理開關(guān)

這種設(shè)計(jì)很合理，畢竟不同模型的計(jì)算復(fù)雜度和內(nèi)存需求差異很大。布局檢測(cè)和公式檢測(cè)需要處理高分辨率圖像，內(nèi)存占用大，所以批大小設(shè)為 1；而公式識(shí)別和 OCR 處理的是裁剪后的小圖像區(qū)域，可以大批量并行處理，顯著提升吞吐量。

3.2內(nèi)存管理和 GPU 優(yōu)化策略

MinerU 實(shí)現(xiàn)了智能的內(nèi)存管理機(jī)制，根據(jù) GPU 顯存動(dòng)態(tài)調(diào)整批處理參數(shù)。VLM 后端在mineru/backend/vlm/vlm_analyze.py:72-84中展示了顯存自適應(yīng)邏輯： 

# mineru/backend/vlm/vlm_analyze.py:72-84 - 顯存自適應(yīng)批處理
try:
    vram = get_vram(device)
    if vram is not None:
        gpu_memory = int(os.getenv('MINERU_VIRTUAL_VRAM_SIZE', round(vram)))
        if gpu_memory >= 16:
            batch_size = 8      # 16GB+顯存：批大小8
        elif gpu_memory >= 8:
            batch_size = 4      # 8-16GB顯存：批大小4
        else:
            batch_size = 1      # <8GB顯存：批大小1
        logger.info(f'gpu_memory: {gpu_memory} GB, batch_size: {batch_size}')
    else:
        # 無(wú)法檢測(cè)顯存時(shí)的保守策略
        batch_size = 1
except Exception as e:
    logger.warning(f'Error determining VRAM: {e}, using default batch_ratio: 1')
    batch_size = 1

這種自適應(yīng)機(jī)制確保了 MinerU 能夠在不同硬件配置上穩(wěn)定運(yùn)行，避免了 OOM（內(nèi)存溢出）錯(cuò)誤。同時(shí)通過(guò)環(huán)境變量MINERU_VIRTUAL_VRAM_SIZE戶手動(dòng)限制顯存使用，適應(yīng)容器化部署環(huán)境。 

3.3多尺度圖像處理與坐標(biāo)轉(zhuǎn)換

MinerU 采用了多尺度圖像處理策略來(lái)平衡識(shí)別精度和處理速度。在圖像裁剪過(guò)程中，通過(guò)scale參數(shù)控制輸出圖的分辨率：

# mineru/utils/cut_image.py:6-21 - 多尺度圖像裁剪
def cut_image_and_table(span, page_pil_img, page_img_md5, page_id, image_writer, scale=2):
    def return_path(path_type):
        return f"{path_type}/{page_img_md5}"     # 基于MD5的路徑管理


    span_type = span["type"]


    if not check_img_bbox(span["bbox"]) or not image_writer:
        span["image_path"] = ""
    else:
        span["image_path"] = cut_image(
            span["bbox"], page_id, page_pil_img,
            return_path=return_path(span_type),
            image_writer=image_writer, scale=scale   # scale=2表示2倍分辨率
        )
    return span

scale=2的設(shè)計(jì)體現(xiàn)了很好的工程權(quán)衡：2 倍分辨率既能保證 OCR 和表格識(shí)別的精度要求，又不會(huì)過(guò)度消耗存儲(chǔ)空間。對(duì)于數(shù)學(xué)公式等高精度需求的內(nèi)容，高分辨率圖像能夠保留更多細(xì)節(jié)信息，提升識(shí)別準(zhǔn)確率。坐標(biāo)有效性檢查確保了系統(tǒng)的健壯性：

# mineru/utils/cut_image.py:23-27 - 坐標(biāo)合法性驗(yàn)證
def check_img_bbox(bbox) -> bool:
    if any([bbox[0] >= bbox[2], bbox[1] >= bbox[3]]):  # x1>=x2 或 y1>=y2
        logger.warning(f"image_bboxes: 錯(cuò)誤的box, {bbox}")
        return False
    return True

這種檢查防止了無(wú)效坐標(biāo)導(dǎo)致的圖像裁剪失敗，提升了系統(tǒng)在處理異常 PDF 時(shí)的容錯(cuò)能力。

3.4表格識(shí)別的分類算法

MinerU 在表格處理上采用了創(chuàng)新的分類算法，通過(guò)統(tǒng)計(jì)分析自動(dòng)判斷表格類型。在mineru/model/table/rec/unet_table/main.py:326-331中實(shí)現(xiàn)了基于非空單元格數(shù)量的智能分類：

# mineru/model/table/rec/unet_table/main.py:326-331 - 表格類型智能判斷
wired_table_scale = round(wired_non_blank_count  0.5)  # 有線表格復(fù)雜度因子
wired_scale_plus_2_cols = wired_non_blank_count + (wired_table_scale * 2)  # 有線表格列數(shù)估算
wired_scale_squared_plus_2_rows = wired_table_scale * (wired_table_scale + 2)  # 有線表格行數(shù)估算


# 基于復(fù)雜度對(duì)比選擇最優(yōu)識(shí)別算法
if (wireless_non_blank_count + 3) >= max(wired_scale_plus_2_cols, wired_scale_squared_plus_2_rows):
    # 選擇無(wú)線表格算法

這個(gè)算法的數(shù)學(xué)原理是：通過(guò)非空單元格數(shù)量的平方根計(jì)算表格的“復(fù)雜度因子”，然后比較有線和無(wú)線兩種算法的預(yù)期處理能力，自動(dòng)選擇最適合的識(shí)別方案。

這種自適應(yīng)選擇機(jī)制不得不說(shuō)很聰明，避免了傳統(tǒng)方法中需要人工預(yù)設(shè)表格類型的問(wèn)題，明顯提升了表格識(shí)別的自動(dòng)化程度和準(zhǔn)確率。特別是對(duì)于復(fù)雜的學(xué)術(shù)論文和技術(shù)文檔中的表格，這種智能分類算法表現(xiàn)出了明顯的優(yōu)勢(shì)。

4、部署與擴(kuò)展

4.1AGPL-3.0 許可證注意事項(xiàng)

根據(jù)官方 README 的說(shuō)明，MinerU 選擇 AGPL-3.0 許可證主要是受 YOLO 算法的限制。由于 Pipeline 后端中的多個(gè)核心模型（如布局檢測(cè)、公式檢測(cè)等）依賴 YOLO 算法，而 YOLO 本身遵循 AGPL 協(xié)議，因此 MinerU 必須采用相同的許可證。官方也提到未來(lái)會(huì)探索替換為許可條款更寬松的模型。

不過(guò)大多數(shù)情況下，把 MinerU 作為獨(dú)立工具使用（如命令行調(diào)用、容器化部署、API 調(diào)用等）是相對(duì)安全的。但如果你修改了 MinerU 的源代碼，并把它作為網(wǎng)絡(luò)服務(wù)提供，或者將其深度集成到商業(yè)產(chǎn)品中進(jìn)行分發(fā)，則需要按照 AGPL-3.0 的要求開源相關(guān)代碼。如果需在商業(yè)環(huán)境中深度使用，建議通過(guò) API 方式調(diào)用以降低許可證風(fēng)險(xiǎn)，或咨詢法務(wù)部門確保合規(guī)。

4.2企業(yè)級(jí)部署考慮

對(duì)于生產(chǎn)環(huán)境，推薦使用 Docker 容器化部署 MinerU，確保環(huán)境一致性和可擴(kuò)展性。同時(shí)需要考慮多實(shí)例負(fù)載均衡，特別是 VLM 后端的 http-client 模式天然支持分布式架構(gòu)?？梢酝ㄟ^(guò) Nginx 或 Kubernetes 實(shí)現(xiàn)請(qǐng)求分發(fā)，確保單點(diǎn)故障時(shí)的服務(wù)連續(xù)性。

此外，對(duì)于敏感文檔的解析，建議使用 HTTPS 加密傳輸、實(shí)施訪問(wèn)權(quán)限控制、定期審計(jì)處理日志、考慮數(shù)據(jù)脫敏需求。

4.3微調(diào)投入產(chǎn)出比問(wèn)題

雖然 MinerU 理論上支持模型微調(diào)，但在實(shí)際應(yīng)用中需要謹(jǐn)慎評(píng)估投入產(chǎn)出比。一方面官方迭代速度可能是快于大部分團(tuán)隊(duì)的微調(diào)周期，其次，單就 VLM 模型微調(diào)而言，因?yàn)樾枰罅?PDF 頁(yè)面圖像配合高質(zhì)量的結(jié)構(gòu)化 JSON 標(biāo)注數(shù)據(jù)。一個(gè)有效的微調(diào)數(shù)據(jù)集動(dòng)輒上萬(wàn)頁(yè)標(biāo)注數(shù)據(jù)，這也是不差錢的團(tuán)隊(duì)才有的選擇。

簡(jiǎn)言之，MinerU 的通用模型已經(jīng)在 OmniDocBench 等權(quán)威評(píng)測(cè)中達(dá)到 SOTA 水平，理論上能夠覆蓋 90%以上的實(shí)際應(yīng)用場(chǎng)景。對(duì)于特殊垂直領(lǐng)域的需求，更務(wù)實(shí)的做法是通過(guò)后處理和規(guī)則優(yōu)化來(lái)解決。

4.4RAGFlow 集成預(yù)告

MinerU 作與 RAGFlow 等成熟的 RAG 框架具有天然的互補(bǔ)性，通過(guò)把 MinerU 集成到 RAG 工作流中，可以顯著提升文檔預(yù)處理的質(zhì)量，為后續(xù)的向量化和檢索提供更精確的文本內(nèi)容。具體的集成策略、性能優(yōu)化配置以及最佳實(shí)踐案例，我會(huì)在下一篇文章中詳細(xì)介紹。

5、寫在最后

記得上次在MinerU現(xiàn)場(chǎng)交流時(shí)，我問(wèn)到說(shuō)如何看待MinerU和Textin這種很多年技術(shù)積累的傳統(tǒng)Pipeline 產(chǎn)品競(jìng)爭(zhēng)，對(duì)方回答是會(huì)基于研究院的人才密度在VLM這種路線上實(shí)現(xiàn)彎道超車。

客觀來(lái)說(shuō)，VLM 終歸是生成模型，幻覺(jué)問(wèn)題和同樣輸入的不一致性輸出問(wèn)題仍然是繞不開的原罪。其次，視覺(jué)模型雖然可以解決 90%的場(chǎng)景，但剩下的 10%場(chǎng)景的微調(diào)可能會(huì)顧此失彼。且不說(shuō)邊緣 case 本就數(shù)據(jù)稀少，也很難形成有效訓(xùn)練。所以，可以預(yù)見的是在未來(lái)幾年內(nèi)，對(duì)于高精度要求的場(chǎng)景 Pipeline 方法依然會(huì)占主導(dǎo)。

當(dāng)然，MinerU 提供雙后端的設(shè)計(jì)也很明智。讓用戶根據(jù)場(chǎng)景自主選擇，而不是強(qiáng)推某一種技術(shù)路線。長(zhǎng)期來(lái)看，預(yù)計(jì)會(huì)出現(xiàn)混合架構(gòu)，就是用 VLM 做粗粒度理解，用專門模型做精細(xì)化處理?；蛘?VLM 作為“調(diào)度器”，根據(jù)文檔復(fù)雜度混合使用不同工具。再或者，可以使用 VLM 增強(qiáng)的 Pipeline，就是 VLM 對(duì) Pipeline 輸出結(jié)果進(jìn)行審核修正，或許也是一種值得考慮的解法。

Anyway，多源異構(gòu)的文檔解析是個(gè)很重要的辛苦活，MinerU那句“Tokenize Anything”的slogan想想確實(shí)沒(méi)錯(cuò)，這事可能是得官方團(tuán)隊(duì)出手可能干的才更加技術(shù)普惠些。