1. 為什么要在 Windows 上折騰 MinerU 4.0先說(shuō)結(jié)論如果你手頭有一堆 PDF 要喂給 RAG 系統(tǒng)又不想把文件傳到別人的服務(wù)器上那 MinerU 4.0 在 Windows 本地跑起來(lái)是目前性價(jià)比最高的方案之一。我自己從 MinerU 2.x 一路用到 4.0中間踩過(guò)的坑能寫滿一頁(yè) A4 紙今天就把整套流程和避坑經(jīng)驗(yàn)一次性講清楚。MinerU 是上海人工智能實(shí)驗(yàn)室開(kāi)源的一個(gè)文檔解析工具核心能力是把 PDF 里的文字、表格、公式、圖片、版面結(jié)構(gòu)全部提取出來(lái)輸出成 Markdown 或 JSON。它跟普通的 PDF 提取庫(kù)比如 PyPDF2、pdfplumber最大的區(qū)別在于它用的是深度學(xué)習(xí)模型做版面分析和公式識(shí)別能處理雙欄排版、跨頁(yè)表格、LaTeX 公式這些傳統(tǒng)工具搞不定的場(chǎng)景。4.0 版本相比之前最大的變化是模型架構(gòu)升級(jí)了解析精度明顯提升尤其是表格和公式的識(shí)別準(zhǔn)確率。那為什么非要本地部署原因很直接。第一數(shù)據(jù)安全。很多場(chǎng)景下的 PDF 是內(nèi)部文檔、合同、研究報(bào)告上傳到云端解析等于把數(shù)據(jù)交出去了。第二成本。云端 API 按頁(yè)收費(fèi)量大了一個(gè)月下來(lái)費(fèi)用不低。第三可控性。本地部署之后你可以隨意調(diào)整參數(shù)、批量處理、集成到自己的流水線里不用受 API 限流和格式限制。這篇文章適合誰(shuí)看如果你正在搭建 RAG 知識(shí)庫(kù)發(fā)現(xiàn)文檔預(yù)處理這一步質(zhì)量太差導(dǎo)致檢索效果拉胯那這篇就是寫給你的。如果你只是偶爾解析幾個(gè) PDF那用在線工具就夠了沒(méi)必要折騰本地部署。但如果你要處理成百上千份文檔或者對(duì)數(shù)據(jù)隱私有要求那接著往下看。注意MinerU 4.0 對(duì)硬件有要求建議至少 16GB 內(nèi)存 8GB 顯存的 NVIDIA 顯卡。純 CPU 也能跑但速度會(huì)讓你懷疑人生。2. 部署前的環(huán)境準(zhǔn)備與方案選型2.1 硬件與系統(tǒng)要求MinerU 4.0 的模型推理依賴 PyTorch所以顯卡這塊基本綁定了 NVIDIA。我實(shí)測(cè)下來(lái)不同配置的表現(xiàn)差距很大配置項(xiàng)最低要求推薦配置我的實(shí)測(cè)體驗(yàn)操作系統(tǒng)Windows 10 64位Windows 11 22H2Win11 對(duì) WSL2 支持更好內(nèi)存16GB32GB處理大文件時(shí) 16GB 會(huì)爆顯卡GTX 1060 6GBRTX 3060 12GB顯存越大能并行處理的頁(yè)數(shù)越多顯存6GB12GB8GB 是舒適線硬盤20GB 可用空間50GB SSD模型文件本身就占十幾個(gè)GPython3.103.10 或 3.113.12 有兼容性問(wèn)題這里重點(diǎn)說(shuō)一下顯存。MinerU 4.0 的版面分析模型和公式識(shí)別模型是分開(kāi)加載的如果你顯存不夠可以設(shè)置成按需加載模式但速度會(huì)慢一些。我自己的機(jī)器是 RTX 3060 12GB處理一份 50 頁(yè)的學(xué)術(shù)論文大概需要 40 秒左右純 CPU 模式下同樣的文件要跑 8 分鐘以上。2.2 安裝方式選擇pip 還是源碼MinerU 提供了兩種安裝方式我兩種都試過(guò)各有優(yōu)劣pip 安裝適合快速上手一條命令搞定pip install mineru但問(wèn)題是 pip 包更新不及時(shí)有時(shí)候新版本發(fā)布了但 pip 源還沒(méi)同步。而且如果你想改源碼或者調(diào)試pip 安裝的方式很不方便。源碼安裝適合需要定制化的場(chǎng)景git clone https://github.com/opendatalab/MinerU.git cd MinerU pip install -e .源碼安裝的好處是你可以隨時(shí) git pull 更新也能直接改配置文件。缺點(diǎn)是依賴比較多安裝過(guò)程中可能會(huì)遇到各種編譯問(wèn)題。我建議第一次接觸的話先用 pip 裝跑通了再考慮源碼方式。如果你需要用到最新的模型或者想改推理參數(shù)那就直接上源碼。2.3 CUDA 與 PyTorch 版本匹配這是最容易翻車的一步。MinerU 4.0 要求 PyTorch 2.0 以上而 PyTorch 版本又必須和你的 CUDA 驅(qū)動(dòng)匹配。我的建議是先運(yùn)行nvidia-smi查看驅(qū)動(dòng)支持的 CUDA 版本去 PyTorch 官網(wǎng)找到對(duì)應(yīng)的安裝命令先裝 PyTorch再裝 MinerU比如你的驅(qū)動(dòng)支持 CUDA 12.1那就pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install mineru實(shí)操心得千萬(wàn)不要先裝 MinerU 再裝 PyTorch因?yàn)?MinerU 的依賴?yán)飼?huì)拉一個(gè) CPU 版本的 PyTorch裝完之后你會(huì)發(fā)現(xiàn) GPU 用不了還得卸載重裝。2.4 模型文件下載與存放MinerU 4.0 首次運(yùn)行時(shí)會(huì)自動(dòng)下載模型文件但國(guó)內(nèi)網(wǎng)絡(luò)環(huán)境下這個(gè)下載過(guò)程可能非常慢甚至中斷。我的做法是手動(dòng)下載模型然后放到指定目錄。模型默認(rèn)存放在~/.cache/mineru目錄下Windows 是C:\Users\你的用戶名\.cache\mineru。你可以通過(guò)設(shè)置環(huán)境變量MINERU_MODEL_SOURCE來(lái)切換模型下載源。如果自動(dòng)下載實(shí)在不行可以去 HuggingFace 或者 ModelScope 手動(dòng)下載對(duì)應(yīng)的模型文件然后按照目錄結(jié)構(gòu)放好。模型文件大概包括版面分析模型、公式識(shí)別模型、OCR 模型、表格識(shí)別模型加起來(lái)差不多 10-15GB。建議提前預(yù)留好空間。3. 核心配置與參數(shù)調(diào)優(yōu)實(shí)戰(zhàn)3.1 配置文件詳解MinerU 4.0 的配置文件是一個(gè) JSON 文件通常叫magic-pdf.json放在用戶目錄下。這個(gè)文件控制著所有的解析行為我挑幾個(gè)最關(guān)鍵的參數(shù)來(lái)說(shuō){ device-mode: cuda, layout-config: { model: layoutlmv3 }, formula-config: { enable: true, model: unimernet }, table-config: { enable: true, model: rapid_table }, ocr-config: { enable: false } }device-mode這個(gè)參數(shù)決定用 GPU 還是 CPU有顯卡就填cuda沒(méi)有就填cpu。formula-config和table-config里的enable控制是否啟用公式和表格識(shí)別如果你處理的文檔里沒(méi)有這些內(nèi)容關(guān)掉能省不少時(shí)間。ocr-config這個(gè)要注意如果你的 PDF 是掃描版的也就是圖片型 PDF必須開(kāi)啟 OCR否則提取出來(lái)全是空白。但如果是原生電子版 PDF關(guān)掉 OCR 能大幅提速。3.2 批量處理與并發(fā)控制MinerU 4.0 支持批量處理整個(gè)目錄的 PDF命令行方式mineru -p ./input_pdfs -o ./output_md --batch但批量處理時(shí)要注意并發(fā)數(shù)。默認(rèn)情況下它會(huì)一張一張串行處理速度比較慢。你可以通過(guò)設(shè)置--workers參數(shù)來(lái)增加并發(fā)但并發(fā)數(shù)不是越大越好。我的經(jīng)驗(yàn)是顯存 8GB 的話設(shè) 2 個(gè)并發(fā)12GB 設(shè) 3-4 個(gè)再多了反而會(huì)因?yàn)轱@存不足導(dǎo)致頻繁切換速度不升反降。還有一個(gè)技巧是先把 PDF 按頁(yè)數(shù)分組小文件10頁(yè)以內(nèi)和大文件50頁(yè)以上分開(kāi)處理。因?yàn)榇笪募加蔑@存多如果和小文件混在一起并發(fā)容易導(dǎo)致小文件等大文件釋放顯存整體效率反而低。3.3 輸出格式選擇與后處理MinerU 4.0 支持輸出 Markdown、JSON、中間格式等多種類型。做 RAG 的話我強(qiáng)烈建議輸出 JSON因?yàn)?JSON 里保留了版面結(jié)構(gòu)的元信息比如每個(gè)文本塊的位置、類型標(biāo)題/正文/表格/公式、層級(jí)關(guān)系。這些信息在后續(xù)的 chunk 切分時(shí)非常有用。Markdown 適合直接給人看但做 RAG 的話會(huì)丟失結(jié)構(gòu)信息。比如一個(gè)跨頁(yè)表格Markdown 里就是兩個(gè)獨(dú)立的表格但 JSON 里會(huì)標(biāo)注它們是同一個(gè)表格的延續(xù)。輸出之后還需要做一步后處理清理掉頁(yè)眉頁(yè)腳、頁(yè)碼、水印這些噪聲。MinerU 本身會(huì)做一些過(guò)濾但不可能百分百準(zhǔn)確。我的做法是寫一個(gè)簡(jiǎn)單的 Python 腳本根據(jù)文本塊的位置信息比如頁(yè)面頂部 5% 和底部 5% 的區(qū)域來(lái)過(guò)濾頁(yè)眉頁(yè)腳。4. 完整實(shí)操流程從 PDF 到 RAG 可用的知識(shí)庫(kù)4.1 單文件解析全流程先從一個(gè)最簡(jiǎn)單的例子開(kāi)始。假設(shè)你有一個(gè)test.pdf想把它轉(zhuǎn)成 Markdownmineru -p test.pdf -o ./output執(zhí)行完之后./output目錄下會(huì)出現(xiàn)test.md和相關(guān)的圖片文件夾。打開(kāi) Markdown 文件檢查一下重點(diǎn)看幾個(gè)地方標(biāo)題層級(jí)是否正確一級(jí)標(biāo)題、二級(jí)標(biāo)題有沒(méi)有識(shí)別對(duì)表格是否完整有沒(méi)有跨頁(yè)斷裂公式是否轉(zhuǎn)成了 LaTeX 格式圖片有沒(méi)有被正確提取出來(lái)如果發(fā)現(xiàn)某類內(nèi)容識(shí)別效果不好可以回到配置文件調(diào)整對(duì)應(yīng)的模型參數(shù)。比如表格識(shí)別不準(zhǔn)可以試試換一個(gè)表格識(shí)別模型或者調(diào)整表格檢測(cè)的置信度閾值。4.2 批量處理腳本編寫實(shí)際項(xiàng)目中不可能一個(gè)一個(gè)文件手動(dòng)跑肯定要寫腳本批量處理。我用的是 Python 的 subprocess 調(diào)用 MinerU 命令行核心邏輯大概是這樣import subprocess import os from pathlib import Path input_dir Path(./pdfs) output_dir Path(./outputs) output_dir.mkdir(exist_okTrue) pdf_files list(input_dir.glob(*.pdf)) for i, pdf in enumerate(pdf_files): print(f[{i1}/{len(pdf_files)}] Processing: {pdf.name}) result subprocess.run( [mineru, -p, str(pdf), -o, str(output_dir)], capture_outputTrue, textTrue ) if result.returncode ! 0: print(fFailed: {pdf.name}) print(result.stderr)這個(gè)腳本很粗糙但能跑通。實(shí)際使用中我加了幾個(gè)改進(jìn)失敗重試機(jī)制、處理進(jìn)度記錄避免中斷后從頭再來(lái)、日志輸出到文件方便排查。踩坑記錄MinerU 在處理某些加密 PDF 時(shí)會(huì)直接報(bào)錯(cuò)退出不會(huì)跳過(guò)繼續(xù)處理下一個(gè)。所以腳本里一定要加 try-except把出問(wèn)題的文件記錄下來(lái)單獨(dú)處理。4.3 解析結(jié)果的質(zhì)量校驗(yàn)批量處理完之后不能直接就把結(jié)果喂給 RAG 系統(tǒng)必須先做質(zhì)量校驗(yàn)。我的校驗(yàn)流程分三步第一步是完整性檢查看每個(gè) PDF 是否都有對(duì)應(yīng)的輸出文件輸出文件是否為空。有時(shí)候 MinerU 處理到一半崩潰了會(huì)生成一個(gè)空文件這種要挑出來(lái)重新處理。第二步是內(nèi)容抽樣檢查隨機(jī)抽取 10% 的輸出文件人工檢查解析質(zhì)量。重點(diǎn)看表格和公式的識(shí)別準(zhǔn)確率以及有沒(méi)有大段文字丟失。第三步是自動(dòng)化指標(biāo)計(jì)算我寫了一個(gè)簡(jiǎn)單的腳本統(tǒng)計(jì)每個(gè)文件的字符數(shù)、圖片數(shù)、表格數(shù)如果某個(gè)文件的字符數(shù)明顯低于同類文件那大概率是解析出了問(wèn)題。4.4 與 RAG 系統(tǒng)的對(duì)接解析出來(lái)的 Markdown 或 JSON 要接入 RAG 系統(tǒng)還需要做 chunk 切分。這里有個(gè)關(guān)鍵點(diǎn)不要用固定長(zhǎng)度的切分方式要利用 MinerU 輸出的結(jié)構(gòu)信息做語(yǔ)義切分。比如 JSON 輸出里每個(gè)文本塊都有類型標(biāo)注你可以把同一章節(jié)下的文本塊合并成一個(gè) chunk表格單獨(dú)作為一個(gè) chunk公式單獨(dú)處理。這樣切出來(lái)的 chunk 語(yǔ)義完整性更好檢索時(shí)的召回質(zhì)量明顯更高。我實(shí)測(cè)過(guò)兩種切分方式的效果差異固定 512 token 切分的檢索準(zhǔn)確率大概在 65% 左右而基于結(jié)構(gòu)信息的語(yǔ)義切分能到 82% 以上。這個(gè)差距在 RAG 系統(tǒng)里是非常顯著的。5. 常見(jiàn)問(wèn)題排查與性能優(yōu)化5.1 啟動(dòng)報(bào)錯(cuò)與依賴沖突問(wèn)題一ImportError: DLL load failed這是 Windows 上最常見(jiàn)的問(wèn)題通常是 Visual C Redistributable 沒(méi)裝或者版本不對(duì)。去微軟官網(wǎng)下載最新的 VC 運(yùn)行庫(kù)裝上就行。問(wèn)題二CUDA out of memory顯存不夠。解決辦法有三個(gè)減小并發(fā)數(shù)、降低處理分辨率、或者切換到 CPU 模式處理大文件。我一般會(huì)準(zhǔn)備兩套配置小文件用 GPU 跑大文件用 CPU 慢慢跑。問(wèn)題三模型下載卡住不動(dòng)前面說(shuō)過(guò)手動(dòng)下載模型放到緩存目錄。另外可以設(shè)置HF_ENDPOINT環(huán)境變量來(lái)加速下載。5.2 解析質(zhì)量問(wèn)題的排查思路解析質(zhì)量差通常表現(xiàn)為文字丟失、表格錯(cuò)亂、公式識(shí)別錯(cuò)誤。排查思路是這樣的先確認(rèn) PDF 類型。用 Adobe Acrobat 或者 Foxit 打開(kāi) PDF看看文字能不能選中。如果能選中說(shuō)明是原生電子版問(wèn)題出在版面分析模型上如果不能選中說(shuō)明是掃描版需要開(kāi)啟 OCR。然后檢查模型配置。不同的版面分析模型對(duì)不同排版的文檔效果差異很大。學(xué)術(shù)論文用layoutlmv3效果好但如果是報(bào)紙雜志這類復(fù)雜排版可能需要換其他模型。最后看分辨率設(shè)置。MinerU 默認(rèn)的 PDF 渲染分辨率是 200 DPI對(duì)于小字號(hào)的文檔可能不夠可以調(diào)到 300 DPI。但分辨率越高處理越慢需要權(quán)衡。5.3 速度優(yōu)化實(shí)戰(zhàn)技巧如果你要處理大量文檔速度就是生命線。我總結(jié)的幾個(gè)優(yōu)化點(diǎn)優(yōu)化手段效果代價(jià)開(kāi)啟 GPU 加速提升 10-20 倍需要 NVIDIA 顯卡關(guān)閉不需要的模型提升 30-50%可能丟失部分內(nèi)容降低渲染分辨率提升 20-30%小字識(shí)別率下降增加并發(fā)數(shù)提升 50-100%顯存占用增加預(yù)處理拆分 PDF提升 10-20%需要額外腳本我自己的最佳實(shí)踐是先把 PDF 按頁(yè)數(shù)拆分成小文件每份不超過(guò) 20 頁(yè)然后用 3 個(gè)并發(fā)跑關(guān)閉 OCR針對(duì)電子版渲染分辨率保持 200 DPI。這套組合下來(lái)1000 頁(yè)的文檔大概 15 分鐘能處理完。5.4 常見(jiàn)問(wèn)題速查表現(xiàn)象可能原因解決方法輸出為空PDF 是掃描版但沒(méi)開(kāi) OCR開(kāi)啟 ocr-config.enable文字亂碼字體嵌入問(wèn)題嘗試開(kāi)啟 OCR 或換渲染引擎表格斷裂跨頁(yè)表格識(shí)別問(wèn)題后處理合并或換表格模型公式識(shí)別錯(cuò)誤公式模型精度不夠換 unimernet 模型或手動(dòng)修正處理速度極慢用了 CPU 模式檢查 device-mode 是否為 cuda程序崩潰顯存不足降低并發(fā)或換小模型中文識(shí)別差OCR 語(yǔ)言設(shè)置不對(duì)設(shè)置 OCR 語(yǔ)言為 ch圖片丟失圖片提取未開(kāi)啟檢查配置中的 image-config6. 從解析到知識(shí)庫(kù)RAG 預(yù)處理的關(guān)鍵細(xì)節(jié)6.1 文檔結(jié)構(gòu)信息的利用MinerU 輸出的 JSON 里包含了豐富的結(jié)構(gòu)信息這些信息在做 RAG 預(yù)處理時(shí)價(jià)值極高。我舉幾個(gè)實(shí)際用到的場(chǎng)景標(biāo)題層級(jí)重建JSON 里每個(gè)文本塊都有type字段標(biāo)注了它是標(biāo)題還是正文。你可以根據(jù)標(biāo)題的層級(jí)關(guān)系重建文檔的目錄樹(shù)然后在 chunk 的元數(shù)據(jù)里記錄每個(gè) chunk 所屬的章節(jié)路徑。檢索時(shí)如果命中了某個(gè) chunk可以順帶把它的父章節(jié)標(biāo)題也返回給大模型幫助模型理解上下文。表格與正文的關(guān)聯(lián)表格在 JSON 里是獨(dú)立的對(duì)象但表格前后通常有說(shuō)明文字。我寫了一個(gè)邏輯把表格和前后的段落綁定在一起作為一個(gè) chunk這樣檢索到表格時(shí)能同時(shí)拿到它的說(shuō)明文字。公式的 LaTeX 化MinerU 會(huì)把公式轉(zhuǎn)成 LaTeX 格式這比圖片格式的公式好太多了。LaTeX 可以直接被大模型理解而圖片需要額外的多模態(tài)模型來(lái)處理。6.2 Chunk 切分策略基于 MinerU 的輸出我總結(jié)了一套 chunk 切分策略效果比樸素的固定長(zhǎng)度切分好很多第一步按標(biāo)題層級(jí)切分。每個(gè)最小標(biāo)題單元比如三級(jí)標(biāo)題下的內(nèi)容作為一個(gè)候選 chunk。第二步如果某個(gè) chunk 超過(guò)最大長(zhǎng)度限制比如 1024 token就按段落進(jìn)一步切分。切分時(shí)保持段落的完整性不要把一段話從中間截?cái)唷５谌饺绻硞€(gè) chunk 太短比如少于 100 token就把它和相鄰的 chunk 合并。太短的 chunk 在檢索時(shí)容易產(chǎn)生噪聲。第四步給每個(gè) chunk 添加元數(shù)據(jù)所屬章節(jié)、文檔標(biāo)題、頁(yè)碼、內(nèi)容類型正文/表格/公式。這些元數(shù)據(jù)在檢索時(shí)可以用于過(guò)濾和排序。6.3 與向量數(shù)據(jù)庫(kù)的對(duì)接切分好的 chunk 需要向量化之后存入向量數(shù)據(jù)庫(kù)。這一步跟 MinerU 本身沒(méi)關(guān)系但有幾個(gè)注意點(diǎn)Embedding 模型的選擇很重要。中文場(chǎng)景下我推薦用 BGE 系列或者 M3E英文場(chǎng)景可以用 OpenAI 的 text-embedding-3 或者開(kāi)源的 e5 系列。如果你在本地部署了大語(yǔ)言模型比如用 Ollama 跑的模型也可以用它自帶的 embedding 接口。向量數(shù)據(jù)庫(kù)的選擇看你的數(shù)據(jù)量。幾萬(wàn)條 chunk 用 FAISS 就夠了上百萬(wàn)條可以考慮 Milvus 或者 Qdrant。Windows 上部署這些數(shù)據(jù)庫(kù)都沒(méi)什么問(wèn)題Docker 方式最簡(jiǎn)單。實(shí)操心得存入向量數(shù)據(jù)庫(kù)時(shí)一定要把 MinerU 輸出的結(jié)構(gòu)信息作為元數(shù)據(jù)一起存進(jìn)去。后面檢索時(shí)你會(huì)發(fā)現(xiàn)這些元數(shù)據(jù)非常有用比如你可以限定只在某個(gè)章節(jié)內(nèi)檢索或者只檢索表格類型的 chunk。7. 我踩過(guò)的那些坑與最終建議7.1 三個(gè)讓我印象最深的坑第一個(gè)坑模型版本不匹配。有一次我更新了 MinerU 的代碼但沒(méi)更新模型文件結(jié)果解析出來(lái)的結(jié)果全是亂碼。排查了半天才發(fā)現(xiàn)是模型版本和代碼版本不兼容。所以每次更新 MinerU 之后記得檢查模型文件是否需要同步更新。第二個(gè)坑路徑里有中文。Windows 用戶特別容易遇到這個(gè)問(wèn)題。MinerU 的某些依賴庫(kù)對(duì)中文路徑支持不好如果 PDF 放在中文目錄下可能會(huì)報(bào)一些莫名其妙的錯(cuò)誤。解決辦法很簡(jiǎn)單所有路徑都用英文。第三個(gè)坑PDF 加密。有些 PDF 設(shè)置了權(quán)限密碼雖然能打開(kāi)但禁止復(fù)制文字。MinerU 處理這種文件時(shí)會(huì)失敗。我的做法是先用 qpdf 這類工具去掉 PDF 的限制然后再處理。7.2 給不同場(chǎng)景的建議如果你只是偶爾用用處理幾十份文檔那 pip 安裝 默認(rèn)配置就夠了不用折騰太多。如果你要搭建生產(chǎn)級(jí)的 RAG 系統(tǒng)處理成千上萬(wàn)份文檔那我建議源碼安裝 自定義配置 批量處理腳本 質(zhì)量校驗(yàn)流程一套組合拳下來(lái)才能保證穩(wěn)定性和效率。如果你沒(méi)有 NVIDIA 顯卡只能用 CPU 跑那建議把 PDF 拆小一點(diǎn)每次處理幾頁(yè)然后耐心等待?；蛘呖紤]用云端的 GPU 實(shí)例來(lái)處理處理完再把結(jié)果下載下來(lái)。7.3 后續(xù)可以擴(kuò)展的方向MinerU 解析出來(lái)的結(jié)構(gòu)化數(shù)據(jù)除了做 RAG 之外還有很多用途。比如你可以用它來(lái)構(gòu)建知識(shí)圖譜把文檔里的實(shí)體和關(guān)系抽取出來(lái)。也可以用它來(lái)做文檔比對(duì)把兩個(gè)版本的文檔解析成結(jié)構(gòu)化數(shù)據(jù)后做 diff。還可以用它來(lái)做文檔摘要把解析結(jié)果喂給大模型生成摘要。我現(xiàn)在正在嘗試的一個(gè)方向是把 MinerU 和本地部署的大語(yǔ)言模型結(jié)合起來(lái)做一個(gè)完全離線的文檔問(wèn)答系統(tǒng)。PDF 解析用 MinerU向量化用本地的 embedding 模型問(wèn)答用 Ollama 跑的模型整條鏈路不依賴任何外部服務(wù)。跑通之后再來(lái)分享經(jīng)驗(yàn)。最后分享一個(gè)小技巧MinerU 的日志文件里會(huì)記錄每個(gè)處理步驟的耗時(shí)如果你發(fā)現(xiàn)某個(gè)步驟特別慢可以針對(duì)性地優(yōu)化。比如我發(fā)現(xiàn)版面分析這一步經(jīng)常是瓶頸后來(lái)?yè)Q了一個(gè)更輕量的模型速度提升了將近一倍精度只下降了不到 2%。這種權(quán)衡在實(shí)際項(xiàng)目中非常值得做。