1. 先搞清楚長(zhǎng)文本處理到底卡在哪光學(xué)壓縮能解決什么問(wèn)題1.1 LLM 吃長(zhǎng)文的三座大山我見(jiàn)過(guò)太多人做長(zhǎng)文檔問(wèn)答第一反應(yīng)就是把一份幾十頁(yè)的合同、論文或者產(chǎn)品手冊(cè)直接塞進(jìn) Prompt讓 LLM 一口氣讀完。這個(gè)方案在最簡(jiǎn)單的小樣上確實(shí)能跑通但只要內(nèi)容一多問(wèn)題就一個(gè)接一個(gè)地冒出來(lái)。第一座大山是 token 成本。一頁(yè) A4 紙的正常排版純文本大概有 500 到 800 個(gè)漢字但對(duì)大模型來(lái)說(shuō)一頁(yè)就對(duì)應(yīng) 1500 到 2500 個(gè) token如果再做字符級(jí)別的切分?jǐn)?shù)字還會(huì)往上漲。一份 30 頁(yè)的 PDF隨隨便便就是 5 萬(wàn)到 8 萬(wàn) token。按現(xiàn)在主流模型的計(jì)費(fèi)方式這還沒(méi)開(kāi)始干活光是把資料喂進(jìn)去就已經(jīng)花掉一大筆錢。第二座大山是上下文窗口的物理限制。現(xiàn)在不少模型對(duì)外宣傳支持 128K、256K 甚至更長(zhǎng)上下文但你真把十幾萬(wàn) token 一次性塞進(jìn)去模型在生成時(shí)每一步都要重新計(jì)算注意力顯存占用和響應(yīng)延遲立刻失控。更麻煩的是很多號(hào)稱支持超長(zhǎng)上下文的模型實(shí)際在長(zhǎng)文本中后段的召回準(zhǔn)確率會(huì)肉眼可見(jiàn)地下降細(xì)節(jié)藏在第 8 頁(yè)問(wèn)答時(shí)就容易一本正經(jīng)地胡說(shuō)八道。第三座大山是“中間迷失”問(wèn)題。注意力機(jī)制在處理超長(zhǎng)序列時(shí)本質(zhì)上對(duì)離當(dāng)前位置越遠(yuǎn)的內(nèi)容感知越弱。你讓模型從第 1 頁(yè)找到第 29 頁(yè)的一句話它往往被中間大量的無(wú)關(guān)段落干擾最后給出一個(gè)模棱兩可的答案。這個(gè)不是調(diào) Prompt 能解決的而是架構(gòu)層面的固有短板。正是因?yàn)檫@三座大山我開(kāi)始留意“光學(xué)壓縮”這條完全不同的路徑。簡(jiǎn)單說(shuō)就是不讓 LLM 直接讀原始文本而是先用 OCR 模型把文檔內(nèi)容做一次“精簡(jiǎn)提煉”只把最有價(jià)值的結(jié)構(gòu)化信息交給 LLM。DeepSeek-OCR 就是這條路徑里非常關(guān)鍵的一環(huán)。1.2 光學(xué)壓縮的底層邏輯拍照速記而不是原文謄抄先解釋一下“光學(xué)壓縮”這個(gè)詞。它并不是一個(gè)嚴(yán)格意義上的學(xué)術(shù)術(shù)語(yǔ)而是在工程圈里流傳開(kāi)的一種叫法。核心思路是把文本內(nèi)容先渲染成圖像再把圖像交給 OCR 模型讓模型用視覺(jué)理解的方式把頁(yè)面上的信息提取成文本。整個(gè)過(guò)程相當(dāng)于給信息做了一次“降維再還原”卻不會(huì)保留原文檔的全部冗余表達(dá)。我用一個(gè)生活化的類比來(lái)說(shuō)你面前有一本 500 頁(yè)的參考手冊(cè)你不需要把它整本復(fù)印給同事只需要花十分鐘翻一遍然后把關(guān)鍵流程、參數(shù)表和注意事項(xiàng)寫成一頁(yè)筆記交給對(duì)方。這個(gè)“翻一遍并做筆記”的動(dòng)作就是光學(xué)壓縮。原文還在但你交出去的是壓縮后的信息。傳統(tǒng)做法是把 PDF 里的文本流直接抽出來(lái)這種辦法遇到掃描件、圖片型 PDF、雙欄排版、頁(yè)眉頁(yè)腳混雜的情況就基本失效。而光學(xué)壓縮路線恰好繞開(kāi)了這個(gè)痛點(diǎn)不管源文檔是掃描件、網(wǎng)頁(yè)截圖還是表格圖片只要我能把它變成一張清晰的圖片OCR 模型就能處理。DeepSeek-OCR 在其中的角色就是那個(gè)“會(huì)做筆記的同事”——它能看懂構(gòu)圖、理解版面、識(shí)別文字并以 Markdown 這樣的結(jié)構(gòu)化格式輸出。在實(shí)際使用中我一般把整個(gè)處理流程設(shè)計(jì)成三段式頁(yè)面渲染、OCR 提取、LLM 整合。第一段把 PDF 轉(zhuǎn)成圖片第二段用 DeepSeek-OCR 把圖片變成精簡(jiǎn)文本第三段把多頁(yè)得到的精簡(jiǎn)文本拼裝起來(lái)交給大模型。由于第二步已經(jīng)去掉了大量頁(yè)面裝飾、重復(fù)段落和格式噪音LLM 面對(duì)的輸入量往往只有原來(lái)的五分之一甚至十分之一這就給后續(xù)的問(wèn)答、摘要和檢索留下了充足的計(jì)算余量。1.3 DeepSeek-OCR 在整個(gè)鏈路里的準(zhǔn)確定位很多人一聽(tīng)到 OCR第一反應(yīng)是“不就是文字識(shí)別嗎”覺(jué)得這技術(shù)已經(jīng)很老了。但從我實(shí)際折騰下來(lái)的感受看傳統(tǒng) OCR 和 DeepSeek-OCR 之間的差距比想象中大得多。傳統(tǒng) OCR 解決的是“把圖片里的文字變回字符串”這個(gè)單一任務(wù)它的輸出結(jié)果通常是純文本流沒(méi)有段落結(jié)構(gòu)、沒(méi)有標(biāo)題層級(jí)、沒(méi)有表格關(guān)系。你把這種文本交給 LLM模型等于在看一坨沒(méi)有標(biāo)點(diǎn)的流水賬理解效果自然打折。DeepSeek-OCR 這類新一代視覺(jué)語(yǔ)言 OCR 模型則把“看圖片”和“理解文檔”兩件事揉在了一起。它不僅能識(shí)別字還能同時(shí)完成版面分析、閱讀順序排序、表格重組和結(jié)構(gòu)化輸出。最終給出來(lái)的不是一串裸文字而是一份保留了標(biāo)題層級(jí)、列表嵌套、表格字段關(guān)系的 Markdown 文檔。所以它在整個(gè)長(zhǎng)文本處理鏈路里的定位是“信息前置壓縮器”。它負(fù)責(zé)把笨重的原始文檔轉(zhuǎn)換成輕量、結(jié)構(gòu)清晰的中間表示讓 LLM 把寶貴的上下文空間留給真正需要推理的部分。如果你還在糾結(jié)怎么用 Prompt 讓模型“忽略無(wú)關(guān)內(nèi)容”那不如先把無(wú)關(guān)內(nèi)容從源頭上剪掉。2. 核心原理拆解DeepSeek-OCR 憑什么能做到高效率提取2.1 視覺(jué)編碼與語(yǔ)言解碼它先把圖片“看”成特征再“說(shuō)”成文字如果只看輸入輸出DeepSeek-OCR 干的事很樸素輸入一張圖片輸出一段文字。但它的內(nèi)部機(jī)制是典型的視覺(jué)語(yǔ)言模型結(jié)構(gòu)而不是老式 OCR 那種“單字識(shí)別”的套路。我在一個(gè)模擬項(xiàng)目里試著分析過(guò)它的行為邏輯可以這樣理解圖片輸入后會(huì)先經(jīng)過(guò)視覺(jué)編碼器把整張圖切成一個(gè)個(gè)視覺(jué)塊每個(gè)塊變成一個(gè)特征向量保留位置信息、紋理信息、邊緣信息。這些特征向量帶著“我看到了什么”的語(yǔ)義被送到后面的語(yǔ)言解碼器里。語(yǔ)言解碼器做的事情不是逐字做模板匹配而是根據(jù)視覺(jué)特征和語(yǔ)言概率一起推斷出最可能的文字序列。這個(gè)設(shè)計(jì)的聰明之處在于它把 OCR 問(wèn)題變成了一個(gè)條件文本生成問(wèn)題。模型不是在“認(rèn)字”而是在“看圖說(shuō)話”。它能結(jié)合上下文判斷一個(gè)模糊字符到底是“已”還是“己”能根據(jù)周圍文字推斷出一處被水印蓋住的字大概率是什么。這種能力是傳統(tǒng)識(shí)別方案不具備的。實(shí)操中的感受也很直接。我用它處理過(guò)手機(jī)拍攝的斜角照片、光線不均勻的文件掃描件、甚至是帶褶皺的紙張照片都能得到相對(duì)穩(wěn)定的結(jié)果。當(dāng)然圖片質(zhì)量越差識(shí)別置信度越低但 DeepSeek-OCR 的容錯(cuò)空間明顯比傳統(tǒng) OCR 大得多這也是視覺(jué)語(yǔ)言模型做 OCR 的核心優(yōu)勢(shì)。2.2 版面理解與結(jié)構(gòu)化輸出Markdown 不是裝飾而是給 LLM 的“路標(biāo)”DeepSeek-OCR 另一個(gè)讓我覺(jué)得物超所值的點(diǎn)是它對(duì)版面結(jié)構(gòu)的還原能力。傳統(tǒng) OCR 遇到雙欄論文文字提取順序經(jīng)常亂掉左欄還沒(méi)讀完就跳到右欄遇到表格直接變成一行行沒(méi)有分隔的字符串字段對(duì)應(yīng)關(guān)系全丟。這些東西對(duì) LLM 來(lái)說(shuō)都是災(zāi)難性輸入。而我實(shí)測(cè) DeepSeek-OCR 時(shí)它對(duì)版面的處理分為幾個(gè)層次先做區(qū)域檢測(cè)識(shí)別哪些地方是正文、哪些是標(biāo)題、哪些是圖片、哪些是表格再做閱讀順序預(yù)測(cè)讓文字按照人類閱讀的自然順序排列最后做結(jié)構(gòu)重建把識(shí)別出的文本歸納成 Markdown標(biāo)題套一級(jí)二級(jí)列表歸納成 bullet表格重新恢復(fù)成帶表頭的二維結(jié)構(gòu)。這就給后續(xù)的邏輯鏈路帶來(lái)兩個(gè)直接好處。第一LLM 能更快定位關(guān)鍵信息因?yàn)闃?biāo)題和段落的層級(jí)關(guān)系會(huì)讓長(zhǎng)文本的語(yǔ)義骨架顯式化。第二表格類信息不再是一坨廢字模型可以直接按“行-列”去理解字段對(duì)應(yīng)關(guān)系這在做合同比對(duì)、財(cái)報(bào)分析、問(wèn)卷統(tǒng)計(jì)時(shí)非常關(guān)鍵。我自己做的一個(gè)實(shí)際對(duì)比實(shí)驗(yàn)同一份 20 頁(yè)的雙欄報(bào)告直接把 PDF 抽取文本交給 LLM 做摘要輸出的要點(diǎn)經(jīng)常抓錯(cuò)欄目先經(jīng)過(guò) DeepSeek-OCR 轉(zhuǎn)成 Markdown再交給同一個(gè) LLM摘要質(zhì)量明顯上升而且出錯(cuò)率降了一大截。原因很簡(jiǎn)單Markdown 等于給模型畫了一條清晰的閱讀路徑它不需要自己在亂序文本里猜結(jié)構(gòu)。2.3 多語(yǔ)言、圖表、手寫混合它到底扛不扛得住我在評(píng)估 OCR 模型時(shí)最看重的是混合場(chǎng)景下的表現(xiàn)。實(shí)際業(yè)務(wù)文檔永遠(yuǎn)不可能是干凈的純印刷體更多時(shí)候是中文正文里夾英文術(shù)語(yǔ)、表格里帶數(shù)字、頁(yè)腳有手寫批注。所以我很早就拿混合材料試過(guò) DeepSeek-OCR。從效果看它對(duì)中文簡(jiǎn)體、中文繁體、英文以及多種常用拉丁字母類語(yǔ)言的支持都不錯(cuò)跨語(yǔ)言混排時(shí)的識(shí)別順序也基本正確。中英文切換處不會(huì)出現(xiàn)串行行尾英文單詞被正確切分標(biāo)點(diǎn)符號(hào)的還原度也比較高。對(duì)于表格里的純數(shù)字內(nèi)容它也能保持字段位置不像一些舊模型會(huì)把數(shù)字串?dāng)D成一團(tuán)。但要說(shuō)完全沒(méi)有短板那也不現(xiàn)實(shí)。手寫內(nèi)容仍然是難點(diǎn)尤其行書、連筆字識(shí)別正確率比印刷體明顯下降。數(shù)學(xué)公式中的復(fù)雜上下標(biāo)、積分符號(hào)、矩陣結(jié)構(gòu)DeepSeek-OCR 可以部分識(shí)別但精確還原 LaTeX 級(jí)別的公式還有距離。彩色背景、藝術(shù)字體、水印疊字這類極端情況也會(huì)影響最終效果。這些問(wèn)題不需要回避在工程化應(yīng)用時(shí)是必須納入預(yù)期的。3. 實(shí)操落地把 DeepSeek-OCR 接進(jìn) LLM 長(zhǎng)文本處理管線3.1 部署準(zhǔn)備本地加載還是走服務(wù)怎么選開(kāi)始動(dòng)手之前先解決跑在哪里的問(wèn)題。DeepSeek-OCR 這類模型體積都不小如果只是偶爾處理幾份文檔完全可以走現(xiàn)成的推理服務(wù)如果經(jīng)常大批量調(diào)用我建議本地部署可以省去不少按次計(jì)費(fèi)的成本也方便在內(nèi)部網(wǎng)絡(luò)里做流水線。本地部署的核心依賴無(wú)非就是 PyTorch、Transformers 和對(duì)應(yīng)的視覺(jué)語(yǔ)言模型組件。我用的模擬配置是 Python 3.10 環(huán)境、一張 12G 顯存的顯卡模型加載半精度版本后大概占 6 到 8G跑單頁(yè)文檔識(shí)別在可接受范圍內(nèi)。如果你沒(méi)有顯卡用純 CPU 也能跑就是速度會(huì)慢一些更適合離線批量任務(wù)。裝好環(huán)境之后我一般先跑一次最小化調(diào)用驗(yàn)證環(huán)境沒(méi)問(wèn)題再進(jìn)入正式流程。這一步雖然簡(jiǎn)單卻能在后面幫你省掉很多區(qū)分“是環(huán)境問(wèn)題還是代碼問(wèn)題”的調(diào)試時(shí)間。3.2 最小化 OCR 調(diào)用一張圖一段代碼跑通全部邏輯這里分享一段我壓箱底的最小可用代碼。它對(duì)著一張本地圖片調(diào)用 OCR 服務(wù)并輸出 Markdown 格式的識(shí)別結(jié)果?；谖覍?shí)際項(xiàng)目中的常見(jiàn)接入方式調(diào)整而成你可以把它當(dāng)成腳手架import base64 import requests image_path page_01.png with open(image_path, rb) as f: image_bytes f.read() image_b64 base64.b64encode(image_bytes).decode(utf-8) resp requests.post( http://127.0.0.1:8000/v1/ocr, json{ image_base64: image_b64, language: auto, output_format: markdown, }, timeout120, ) if resp.status_code 200: data resp.json() print(data[text]) else: print(調(diào)用失敗狀態(tài)碼, resp.status_code, resp.text)這段代碼的核心邏輯很簡(jiǎn)單把圖片轉(zhuǎn)成 base64 傳給服務(wù)指定格式為 Markdown拿到文本結(jié)果。我在實(shí)際項(xiàng)目里遇到過(guò)一次問(wèn)題圖片過(guò)大時(shí)會(huì)超出請(qǐng)求體限制所以通常會(huì)在傳參前加一個(gè)壓縮處理把圖片長(zhǎng)邊限制在 2000 像素以內(nèi)既能保證識(shí)別精度又能避免請(qǐng)求超時(shí)。另外如果你要處理的是 PDF需要先把 PDF 按頁(yè)渲染成 PNG再用上面的邏輯逐頁(yè)跑再把結(jié)果合并。3.3 接入 LLM從冗長(zhǎng) PDF 到精準(zhǔn)問(wèn)答的完整鏈路OCR 跑通之后真正的重頭戲是把結(jié)果接入 LLM 處理鏈路。我以一次典型的“文檔問(wèn)答”為例給你看完整的處理思路。第一步先把 PDF 按頁(yè)渲染成圖片。這一步我習(xí)慣用 150 DPI 左右的清晰度太低了小字號(hào)會(huì)糊太高了圖片體積大、傳輸慢。第二步逐頁(yè)調(diào)用 DeepSeek-OCR得到每頁(yè)的 Markdown 文本。第三步把多頁(yè) Markdown 合并成一個(gè)上下文塊但要不要全量合并取決于文檔長(zhǎng)度。如果總共不到一萬(wàn) token直接合并即可如果更多我會(huì)先按章節(jié)粗切再結(jié)合向量檢索或關(guān)鍵詞定位把最相關(guān)的段落挑出來(lái)。合并后的上下文給到 LLM 時(shí)我通常會(huì)在 Prompt 里加一句說(shuō)明讓它知道這份文本不是完整原文而是經(jīng)過(guò) OCR 提取的結(jié)構(gòu)化版本避免它對(duì)缺失的頁(yè)眉頁(yè)腳產(chǎn)生困惑。這樣做的好處非常明顯模型的輸入量小了注意力更集中回答的細(xì)節(jié)準(zhǔn)確性明顯提升。而且因?yàn)檩敵鍪?MarkdownLLM 能直接從表格字段中取數(shù)省去了原來(lái)那套反復(fù)讓模型“從上文中找到對(duì)應(yīng)行”的 Prompt 工程。4. 常見(jiàn)問(wèn)題與排查我在實(shí)際跑 OCR 管線時(shí)踩過(guò)的坑4.1 識(shí)別錯(cuò)字、丟字、亂序先檢查圖片再懷疑模型我剛開(kāi)始用 DeepSeek-OCR 時(shí)遇到最多的就是個(gè)別字識(shí)別錯(cuò)誤尤其是中文里長(zhǎng)得像“未”和“末”、“己”和“已”這類。起初我以為是模型問(wèn)題后來(lái)仔細(xì)排查才發(fā)現(xiàn)大部分錯(cuò)字都出在圖像質(zhì)量不好的場(chǎng)景里。拍照抖動(dòng)、光線陰影、字體太小都會(huì)讓視覺(jué)特征混淆。所以我的第一條排查建議是先看原圖。如果圖片拍歪了先做透視矯正如果背景有陰影先用圖像處理工具增強(qiáng)對(duì)比度如果字體太小就提高渲染分辨率。多數(shù)錯(cuò)字問(wèn)題在圖片預(yù)處理階段就能解決完全不用換模型。如果你已經(jīng)在處理高清掃描件但還是有文字錯(cuò)誤那才是真的需要進(jìn)一步確認(rèn)模型版本或考慮在局部區(qū)域用更高分辨率重識(shí)別的階段。另外多欄版面的亂序問(wèn)題也很常見(jiàn)。如果 OCR 結(jié)果出現(xiàn)左右欄內(nèi)容穿插優(yōu)先檢查圖片是否被正確旋轉(zhuǎn)很多掃描件帶微小的傾斜角度會(huì)影響版面分析的結(jié)果。我做了一個(gè)很土但有效的預(yù)處理檢測(cè)頁(yè)面文字主體的整體傾斜角超過(guò) 0.5 度就先糾正一次再送入 OCR實(shí)測(cè)有效降低了亂序概率。4.2 顯存不足和內(nèi)存溢出批量任務(wù)最容易翻車的地方批量處理長(zhǎng)文檔時(shí)最容易翻車的不是識(shí)別精度而是資源耗盡。我印象里踩過(guò)一次最大的坑是一次性把 50 頁(yè) PDF 全部轉(zhuǎn)成高分辨率大圖然后循環(huán)提交 OCR。結(jié)果程序跑到第 30 頁(yè)時(shí)顯卡顯存直接被打滿進(jìn)程崩潰。原因很簡(jiǎn)單我沒(méi)控制圖片批量處理速度和顯存釋放機(jī)制。后來(lái)我把方案改成“兩兩處理、用后即清”的節(jié)奏。每次只處理兩頁(yè)圖片得到結(jié)果后立刻把圖片和中間變量釋放掉再處理下一頁(yè)。如果還是緊張就在調(diào)用里顯式指定使用半精度推理。對(duì)于離線大批量任務(wù)還可以用隊(duì)列控制并發(fā)數(shù)比如同一時(shí)刻最多跑兩個(gè)進(jìn)程避免資源爭(zhēng)搶。如果你在 CPU 環(huán)境下跑內(nèi)存溢出也是常見(jiàn)問(wèn)題。大圖片轉(zhuǎn) base64 的過(guò)程本身就會(huì)占用大量?jī)?nèi)存我的做法是先用 Pillow 把圖片縮放到合理尺寸再轉(zhuǎn)編碼處理完后主動(dòng)釋放變量。這些資源管理的意識(shí)甚至比模型選擇本身更能決定項(xiàng)目成敗。4.3 表格和公式識(shí)別不準(zhǔn)針對(duì)場(chǎng)景做后處理修補(bǔ)表格識(shí)別是 DeepSeek-OCR 相對(duì)薄弱的環(huán)節(jié)尤其當(dāng)表格跨度很大、單元格內(nèi)文字很多時(shí)偶爾會(huì)出現(xiàn)列錯(cuò)位或字段錯(cuò)行。我這個(gè)領(lǐng)域的經(jīng)驗(yàn)是如果文檔里表格是核心信息載體最好在 OCR 輸出之后加一個(gè)簡(jiǎn)單的后處理校驗(yàn)統(tǒng)計(jì)每行的分隔符數(shù)量檢測(cè)是否存在明顯的字段缺失再用固定規(guī)則或二次 Prompt 修正。公式識(shí)別就更依賴場(chǎng)景了。對(duì)于包含大量數(shù)學(xué)公式的理工科論文我會(huì)把 DeepSeek-OCR 輸出中公式部分單獨(dú)標(biāo)記出來(lái)再用專門的公式識(shí)別組件去二次處理然后把結(jié)果重新插回 Markdown 里。這么做雖然多了一步但對(duì)最終質(zhì)量提升很大。如果你處理的是社科類文檔公式占比極低可以省掉這一步直接依賴 OCR 的原始輸出也不會(huì)對(duì)最終 LLM 理解造成實(shí)質(zhì)影響。4.4 實(shí)用排查速查表我把平時(shí)最常遇到的問(wèn)題整理成了一張表放在這里方便你自查現(xiàn)象優(yōu)先排查方向常用解決手段個(gè)別字識(shí)別錯(cuò)誤圖片清晰度、字體大小、背景干擾提升分辨率、增強(qiáng)對(duì)比度、局部重識(shí)別多欄順序錯(cuò)亂圖片傾斜、掃描方向透視矯正、旋轉(zhuǎn)檢測(cè)、重新渲染表格字段錯(cuò)位單元格長(zhǎng)度、表格跨頁(yè)增加后處理校驗(yàn)、列分隔符統(tǒng)計(jì)請(qǐng)求超時(shí)圖片過(guò)大、并發(fā)過(guò)高壓縮圖片、控制并發(fā)、提高超時(shí)時(shí)間顯存溢出批量任務(wù)資源未釋放分頁(yè)分批處理、用后即清、半精度推理公式識(shí)別一般模型本身能力邊界單獨(dú)抽出公式交給專用組件處理手寫內(nèi)容出錯(cuò)書寫風(fēng)格復(fù)雜降低預(yù)期、結(jié)合人工校對(duì)或輔助模型復(fù)核這張表是我在多次項(xiàng)目迭代里慢慢積累出來(lái)的能覆蓋大多數(shù)常規(guī)問(wèn)題。一旦你遇到表里面沒(méi)有的情況我通常會(huì)建議先跑通最小化復(fù)現(xiàn)再逐層排查而不是一上來(lái)就去換模型或者改方案。5. 我的實(shí)操心得與擴(kuò)展建議5.1 光學(xué)壓縮什么時(shí)候用什么時(shí)候別硬用這里我想多說(shuō)一點(diǎn)掏心窩子的話。光學(xué)壓縮這個(gè)路線雖然效果好但它并不是所有場(chǎng)景的銀彈。我最初也走過(guò)一段“所有文檔都要過(guò)一遍 OCR”的彎路后來(lái)才慢慢摸清邊界。如果文檔本身就是純文本 PDF文字層清晰完整那么直接用文本抽取會(huì)更便宜、更快。OCR 適合的是圖片型 PDF、掃描件、復(fù)雜排版、混排非結(jié)構(gòu)化內(nèi)容。換句話說(shuō)當(dāng)傳統(tǒng)方式提取不了或者提取質(zhì)量太差時(shí)再上光學(xué)壓縮。我的原則是先抽文本抽出來(lái)干凈就直接用抽出來(lái)是亂碼或者結(jié)構(gòu)爛才考慮走 OCR 管線別一上來(lái)就把所有東西都轉(zhuǎn)圖片。另外一個(gè)需要想清楚的點(diǎn)是OCR 本身也是成這成本的。每一步多引入一個(gè)模型就多一份延遲和資源開(kāi)銷。所以在設(shè)計(jì)系統(tǒng)時(shí)我習(xí)慣把“是否需要 OCR”做成一個(gè)可配置的路由開(kāi)關(guān)。比如用戶上傳 PDF先檢測(cè)是否帶文字層有就直接走純文本通道沒(méi)有再走渲染加 OCR。這樣既兼顧了效率也保證了覆蓋面。5.2 管線還可以怎么延展向量檢索與多模態(tài)文檔智能光學(xué)壓縮做完之后得到的 Markdown 其實(shí)還可以做很多延展。我最常做的一件事是把這些結(jié)構(gòu)化文本繼續(xù)喂給 embedding 模型做主檔向量化。因?yàn)槲谋疽呀?jīng)被提煉過(guò)向量檢索時(shí)命中的內(nèi)容更聚焦回答質(zhì)量比直接對(duì)原始超大文本切片要好。如果你要處理的是大量重復(fù)結(jié)構(gòu)文檔比如簡(jiǎn)歷、合同、票據(jù)還可以考慮在 OCR 輸出的 Markdown 上做字段抽取模板。比如先把不同版面的合同轉(zhuǎn)成統(tǒng)一的 Markdown 模板再讓 LLM 按模板抽取出“甲方、乙方、金額、條款編號(hào)”這樣能極大提升結(jié)構(gòu)化錄入的效率。從更長(zhǎng)遠(yuǎn)的角度看視覺(jué)語(yǔ)言模型的能力還在快速迭代未來(lái) OCR 模型可能會(huì)直接理解圖表語(yǔ)義輸出更接近人類閱讀筆記的結(jié)果。而“把復(fù)雜文檔先變成精煉結(jié)構(gòu)化信息再交給推理模型”這個(gè)思路不會(huì)變。它背后的原則其實(shí)是讓每種模型做自己最擅長(zhǎng)的那部分工作視覺(jué)模型負(fù)責(zé)看語(yǔ)言模型負(fù)責(zé)想。各司其職整個(gè)系統(tǒng)才能又快又穩(wěn)。如果你手上正好有長(zhǎng)文檔問(wèn)答或者文檔解析的需求不妨按這個(gè)路線試一遍。先用 DeepSeek-OCR 把文檔壓成精煉的 Markdown再把 Markdown 交給 LLM你大概率會(huì)發(fā)現(xiàn)原來(lái)那些動(dòng)不動(dòng)就超時(shí)、答非所問(wèn)的問(wèn)題竟然安靜了不少。這里唯一要提醒的是敢于動(dòng)手做一次端到端的測(cè)試比讀十篇解讀文章都有用。