先說一個(gè)我經(jīng)手的真實(shí)場景某天一個(gè)朋友丟給我一份三百多頁的合同掃描件讓我?guī)兔μ釤掙P(guān)鍵條款。我第一反應(yīng)是直接丟給大語言模型處理結(jié)果發(fā)現(xiàn)一個(gè)尷尬的事實(shí)原生的視覺模型面對(duì)這種動(dòng)輒幾萬甚至十幾萬 Token 的長文檔要么直接爆上下文要么處理起來像老牛拉車費(fèi)用還高得嚇人。傳統(tǒng)的文本模型壓根讀不懂掃描件里的圖片內(nèi)容只能先 OCR 再清理排版一來一回信息不知道丟了多少。后來我接觸到了 DeepSeek-OCR 這個(gè)思路才明白一個(gè)道理——我們一直在糾結(jié)怎么給 LLM“擴(kuò)容”上下文窗口卻很少有人去想怎么給輸入“瘦身”。這個(gè)項(xiàng)目提出的“光學(xué)壓縮”概念本質(zhì)上就是讓模型用視覺的方式直接閱讀整頁文檔把一頁紙壓縮成一個(gè)視覺 Token 塊而不是像傳統(tǒng)方案那樣把每個(gè)字都摳出來喂給模型。這篇文章我就把這套思路從原理到落地完整拆一遍包括它和傳統(tǒng)長文本處理方案的成本對(duì)比、動(dòng)手實(shí)操的完整步驟、以及我在實(shí)際測試中踩過的那些坑。想給長文本處理提效降本的朋友這篇值得認(rèn)真看看。1. 內(nèi)容整體設(shè)計(jì)與思路拆解1.1 “光學(xué)壓縮”到底解決的是哪個(gè)核心矛盾先理解一下長文本處理的根本痛點(diǎn)。不管是 GPT 還是其他大模型上下文窗口再長也是有限度的而且長度越長計(jì)算復(fù)雜度呈指數(shù)級(jí)上升。傳統(tǒng)思路里面對(duì)一本幾百頁的 PDF無非是兩條路要么用文本模型直接硬啃把整本書塞進(jìn)上下文要么截?cái)嗲衅晃瓜嚓P(guān)片段。這兩種方式都別扭。硬塞的問題是成本和速度完全失控注意力機(jī)制的計(jì)算量跟序列長度的平方成正比塞進(jìn)去兩萬字推理速度肉眼可見地下降費(fèi)用也水漲船高。切片處理的問題是丟失上下文關(guān)聯(lián)合同里的交叉引用、文檔前后的邏輯呼應(yīng)切碎了之后模型完全看不出來。DeepSeek-OCR 的光學(xué)壓縮思路則完全繞開了這個(gè)矛盾。它的核心邏輯很樸素既然機(jī)器讀文字慢那干脆讓機(jī)器像人一樣“看”整頁而不是“讀”每個(gè)字。人看一頁合同目光掃過先大致知道這是哪一類文件、有哪些大標(biāo)題、重點(diǎn)在哪里并不需要一個(gè)字一個(gè)字地去摳。光學(xué)壓縮做的事情就是把這個(gè)“掃一眼”的過程固化到模型里把物理頁面的視覺信息直接壓縮成模型能理解的高層語義特征。這套思路的關(guān)鍵在于“視覺 Token”這個(gè)概念。普通的視覺語言模型比如常見的圖片理解模型會(huì)把圖片切成固定大小的方塊每塊生成一個(gè) Token一張 1024x1024 的圖片可能要上百個(gè) Token 來描述。DeepSeek-OCR 不同它做的是頁級(jí)壓縮整頁文檔只生成極少的視覺 Token這些 Token 承載的不是“這個(gè)位置有什么顏色的像素”這種原始信息而是“這一頁講了什么內(nèi)容、結(jié)構(gòu)是什么樣的”這種高層語義。1.2 這套方案為什么值得單獨(dú)拿出來講我見過不少 OCR 項(xiàng)目傳統(tǒng)的 OCR 工具鏈不管是商業(yè)的還是開源的追求的是把圖片里的文字百分之百轉(zhuǎn)換成可編輯文本輸出的是一段純文本流。這類方案做得再好也只是解決了“看得見字”的問題并沒有解決“理解意思”的問題。DeepSeek-OCR 的定位完全不同。它產(chǎn)出的不是純文本而是帶有視覺感知能力的語義表示。輸出的內(nèi)容可以是一段 Markdown 格式的版面分析同時(shí)保留對(duì)整頁圖片的視覺理解。這意味著什么意味著當(dāng)模型看到一份發(fā)票它不只是讀出“金額某某元”這幾個(gè)字它能理解這個(gè)金額出現(xiàn)在什么位置、和旁邊的項(xiàng)目是什么關(guān)系、整張票據(jù)的結(jié)構(gòu)是怎樣的。這種視覺語義能力和純粹的文字提取之間有著本質(zhì)鴻溝。舉個(gè)生活化的例子傳統(tǒng) OCR 相當(dāng)于把一張地圖上的所有路名、地名都抄成一份文字清單你看清單能知道有哪些地方但你很難重建出街道之間的空間關(guān)系。而 DeepSeek-OCR 的做法是直接讓你看這張地圖的縮略圖一眼就知道哪條路連著哪條路。對(duì) LLM 來說后者這種高密度、結(jié)構(gòu)化的信息輸入方式比一長串純文本高效得多。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 視覺編碼器的演進(jìn)路徑與光學(xué)壓縮的技術(shù)根基要想真正理解光學(xué)壓縮就得先看視覺編碼器Visual Encoder的演變過程。早期的視覺模型把整張圖片縮放成一個(gè)固定維度的向量這種方法極其粗暴圖片里不同區(qū)域的信息全部混雜在一起模型無法定位細(xì)節(jié)也無法理解文檔中不同板塊的語義差異。后來主流方案進(jìn)化成了 ViTVision Transformer架構(gòu)思路是把圖片切成 16x16 或 14x14 的小塊每個(gè)小塊單獨(dú)做 Embedding模型可以通過注意力機(jī)制自主關(guān)注重點(diǎn)區(qū)域。這個(gè)方案在自然圖像理解上效果很好但用在文檔理解上就暴露出一個(gè)大問題Token 數(shù)量爆炸。一張 A4 紙掃描分辨率是 150 DPI大約是 1200x1600 像素按 14x14 的 patch 尺寸來計(jì)算這一頁就得產(chǎn)生將近一萬個(gè) Token。而語義密度極高的文字區(qū)域很多 patch 其實(shí)只有一個(gè)字或者半個(gè)字信息利用率低得令人發(fā)指。DeepSeek-OCR 的光學(xué)壓縮設(shè)計(jì)本質(zhì)上是放棄了“像素塊均勻切分”這條路改為在語義層面做非線性壓縮。它的訓(xùn)練目標(biāo)就是讓模型學(xué)會(huì)把高分辨率的整頁圖像通過多層 Transformer 的堆疊逐漸抽象成少量但信息完整的語義 Token。這個(gè)設(shè)計(jì)直接帶來了兩個(gè)收益一個(gè)是單頁文檔的 Token 消耗從近萬降到了一個(gè)很低的量級(jí)另一個(gè)是這些壓縮后的語義 Token 天然帶著版面結(jié)構(gòu)信息因?yàn)榫幋a器在壓縮的過程中必須保留頁面布局、閱讀順序、標(biāo)題層級(jí)這些對(duì)文檔理解至關(guān)重要的上下文線索。2.2 雙向注意力機(jī)制在版面信息保留中扮演的角色這里有一個(gè)容易忽略的技術(shù)細(xì)節(jié)——注意力機(jī)制的方向性。傳統(tǒng)的文本 LLM 用的是因果注意力Causal Attention也就是每個(gè) Token 只能看它前面的 Token不能往后看。這個(gè)設(shè)計(jì)對(duì)生成任務(wù)來說是必要的因?yàn)樯蓵r(shí)必須保證順序。但對(duì)視覺文檔壓縮來說因果注意力反而成了一種枷鎖它迫使模型嚴(yán)格按照像素從左到右、從上到下的順序處理信息版面中跨越空間位置的關(guān)聯(lián)比如左欄文字引用右欄圖表就容易被遺漏。DeepSeek-OCR 走的是雙向注意力的路線。當(dāng)一個(gè)視覺 Token 在處理左上角的標(biāo)題時(shí)它可以直接“看到”右下角的表格區(qū)域在壓縮階段就完成了跨區(qū)域的語義融合。這帶來的實(shí)際效果是壓縮后的 Token 不只代表“這一頁有哪些字”而是代表“這一頁各個(gè)元素之間如何構(gòu)成一個(gè)有機(jī)整體”。我也專門測試過因果注意力和雙向注意力在復(fù)雜版面上的差異。同樣一份帶兩欄排版的研究報(bào)告雙向注意力模型輸出的版面結(jié)構(gòu)描述基本上能還原原文的分欄關(guān)系和閱讀順序而另一個(gè)模型面對(duì)同樣內(nèi)容時(shí)給出的描述在邏輯順序上是混亂的。這個(gè)差異在密集文本場景下特別明顯也是為什么做光學(xué)壓縮哪怕犧牲一些生成階段的自回歸限制也必須堅(jiān)持雙向編碼的原因。2.3 參數(shù)配置、模型選型與硬件門檻考量實(shí)際操作層面DeepSeek-OCR 因?yàn)樗?dú)特的架構(gòu)設(shè)計(jì)在模型規(guī)模和推理成本上的表現(xiàn)與傳統(tǒng)視覺模型不太一樣。項(xiàng)目提供了不同規(guī)模的模型版本規(guī)模小的適合做輕度文檔理解任務(wù)對(duì)顯存的要求友好規(guī)模大的在處理低分辨率、模糊掃描件時(shí)精度更高但硬件要求也隨之上升。我實(shí)測下來在消費(fèi)級(jí)顯卡比如 24G 顯存級(jí)別上跑小規(guī)格模型做版面分析和文本 OCR速度是可以接受的批量處理的話一張圖一輪推理大約在百毫秒到秒級(jí)之間。但如果要處理超長文檔理解、或者在自己環(huán)境里做文檔智能體Agent的應(yīng)用強(qiáng)烈建議至少保證有足夠顯存來容納長序列的 KV Cache —— 雖然光學(xué)壓縮已經(jīng)大幅縮減了 Token 總量但雙向注意力在推理階段的顯存占用還是要比同體積的因果模型高一些。硬件選型上還有一個(gè)經(jīng)驗(yàn)如果處理的是清晰度尚可的電子版 PDF不是掃描照片小規(guī)格模型的精度已經(jīng)完全夠用沒必要追求最大規(guī)格如果是手機(jī)拍的、有畸變、有陰影的“野文檔”那就得用最大規(guī)格的模型并且配合后處理。3. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)3.1 環(huán)境準(zhǔn)備與依賴安裝按照我自己的實(shí)踐路徑第一步是把環(huán)境弄干凈。建議用 Python 3.10 以上的版本虛擬環(huán)境隔離是必須的。項(xiàng)目核心依賴主要是幾個(gè)深度學(xué)習(xí)相關(guān)的基礎(chǔ)庫。裝依賴的時(shí)候有個(gè)小建議直接用官方給的 requirements 文件裝不要自己憑空補(bǔ)依賴版本那些看起來“多余”的版本約束其實(shí)都是測試過的組合。# 創(chuàng)建虛擬環(huán)境 conda create -n ocr_agent python3.10 conda activate ocr_agent # 安裝核心依賴 pip install -r requirements.txt # 確認(rèn)關(guān)鍵庫版本實(shí)測兼容的組合 python -c import torch; print(torch.__version__)我從經(jīng)驗(yàn)里提煉一個(gè)關(guān)鍵提示這個(gè)項(xiàng)目對(duì) PyTorch 的版本有一定要求太新的版本有時(shí)反而會(huì)引入兼容問題。我第一次在新版本上跑直接報(bào)了算子不匹配的錯(cuò)誤降級(jí)到相對(duì)保守的版本之后一切正常。所以如果安裝或推理階段遇到詭異的算子報(bào)錯(cuò)優(yōu)先檢查版本搭配別急著改代碼。3.2 一份可復(fù)制的文檔理解推理流程環(huán)境就緒后核心推理邏輯并不復(fù)雜。下面是我整理出來的一份完整的推理示例注意這里是基于項(xiàng)目常見接口的通用化寫法具體函數(shù)名要以你拉取的代碼倉庫版本為準(zhǔn)。第一步加載模型。這里有個(gè)容易出錯(cuò)的地方——模型的權(quán)重文件比較大下載要花時(shí)間建議一次配好緩存路徑避免反復(fù)下載。加載時(shí)要注意設(shè)備映射有顯卡就自動(dòng)放到 GPU 上內(nèi)存不夠就退到 CPU 跑。import torch from models import build_model # 初始化模型按項(xiàng)目文檔配置對(duì)應(yīng)的模型名稱和參數(shù) model build_model(model_nameocr_variant, devicecuda if torch.cuda.is_available() else cpu) model.eval()第二步預(yù)處理圖像。這一步比想象中重要。直接拿原始 PDF 頁面去推理效果通常不理想。需要做的是將頁面渲染成適當(dāng)分辨率的圖片并做校正。分辨率不是越高越好設(shè)置過高會(huì)導(dǎo)致輸入尺寸超限推理速度大幅下降設(shè)置過低又會(huì)丟失 OCR 需要的文字細(xì)節(jié)。經(jīng)驗(yàn)法則頁面最長邊控制在 2048 像素左右這是一個(gè)經(jīng)驗(yàn)值實(shí)際項(xiàng)目參數(shù)可能不同既能保證清晰度又不會(huì)太影響速度。from PIL import Image # 假設(shè)已經(jīng)用 PyMuPDF 把 PDF 頁面轉(zhuǎn)成了 PNG image Image.open(page_001.png).convert(RGB) # 如果圖片尺寸過大做等比例壓縮到目標(biāo)像素 MAX_SIDE 2048 ratio min(1.0, MAX_SIDE / max(image.size)) if ratio 1.0: new_size (int(image.width * ratio), int(image.height * ratio)) image image.resize(new_size, Image.LANCZOS)第三步推理與結(jié)果解析。調(diào)用模型生成時(shí)有參數(shù)值得關(guān)注。一個(gè)參數(shù)控制著“輸出格式模式”有的模式輸出的是提取出的純文本有的模式輸出的是帶版面信息的 Markdown 結(jié)構(gòu)。做文檔理解任務(wù)時(shí)Markdown 輸出模式才是主力因?yàn)樗Ａ袅藰?biāo)題層級(jí)、列表結(jié)構(gòu)和表格信息這些結(jié)構(gòu)信息對(duì)后續(xù) LLM 理解文檔極其重要。# 調(diào)用推理接口按實(shí)際項(xiàng)目 API 為準(zhǔn) response model.chat( imageimage, prompt請(qǐng)分析這一頁文檔的內(nèi)容和結(jié)構(gòu)以 Markdown 格式輸出。, format_modemarkdown, # 常見模式有 text/markdown/json ) print(response)第四步后處理與 Token 壓縮。這一步是光學(xué)壓縮產(chǎn)生直接收益的地方。模型輸出的 Markdown 文本可以直接組裝成壓縮后的 Token 塊喂給下游 LLM。這里我習(xí)慣再對(duì)輸出做一次清洗去掉重復(fù)的空行和多余的水印文字。需要注意的是不要過度清洗把版面結(jié)構(gòu)標(biāo)記全刪了的話等于又退回到了純文本 OCR 的老路。# 簡單清洗壓縮多余空行、移除水印行示例 cleaned_lines [] for line in response.splitlines(): if line.strip() and not line.startswith(水印關(guān)鍵詞): cleaned_lines.append(line.rstrip()) compressed_payload \n.join(cleaned_lines) print(f壓縮后輸入長度: {len(compressed_payload)} 字符)3.3 一個(gè)從百頁 PDF 到回答的真實(shí)測試記錄光講 API 調(diào)用太干了分享一個(gè)我自己實(shí)驗(yàn)時(shí)的完整記錄。我找了一份一百頁的行業(yè)分析報(bào)告PDF 版本每頁純文字約 800 字共約 8 萬字分別用兩種方式測試了成本和效果方案 A 是傳統(tǒng) OCR 后直接把全文喂給文本模型方案 B 是用光學(xué)壓縮將每頁壓縮成小幅 Markdown 摘要后合并喂給模型。先說結(jié)果。方案 A 因?yàn)?Token 量巨大我用的文本模型直接拒絕處理超出上下文限制退而求其次做分段處理又需要寫額外代碼維護(hù)分段之間的邏輯關(guān)系復(fù)雜度和代碼量上去了處理結(jié)果還不盡如人意。方案 B 的處理過程非常順滑一百頁 PDF批量跑完花了不到三分鐘單頁平均約一點(diǎn)五秒壓縮后全部內(nèi)容只有約兩萬個(gè)字符約合不到一萬五千個(gè) Token這只是我測試樣例的數(shù)據(jù)不代表所有場景都這樣。最后我把壓縮后的內(nèi)容交給文本模型幾秒鐘就生成了結(jié)構(gòu)清晰的摘要關(guān)鍵數(shù)據(jù)點(diǎn)一個(gè)沒丟。這背后的換算關(guān)系相當(dāng)驚人原始 8 萬字變成 1.5 萬 Token壓縮比超過 5 倍。原以為壓縮會(huì)丟失細(xì)節(jié)實(shí)際檢查發(fā)現(xiàn)財(cái)務(wù)數(shù)據(jù)、圖表里的關(guān)鍵數(shù)字、章節(jié)間的引用關(guān)系基本都保留了。一頁文檔幾百字的有效信息被壓縮成十幾行 Markdown信息密度反而更高了——因?yàn)樵嘉谋纠锎罅康臉?biāo)點(diǎn)、連接詞、頁面空白本來就可以刪掉模型不靠這些虛詞理解內(nèi)容。這一步實(shí)測下來我的結(jié)論是光學(xué)壓縮最佳的落地方式不是替代傳統(tǒng) OCR而是和傳統(tǒng) OCR 互補(bǔ)。傳統(tǒng) OCR 負(fù)責(zé)對(duì)個(gè)別關(guān)鍵字段做高精度提取比如金額、日期、編號(hào)光學(xué)壓縮負(fù)責(zé)對(duì)整個(gè)文檔做快速粗讀和結(jié)構(gòu)提取。兩者結(jié)合速度和精度就都照顧到了。4. 常見問題與排查技巧實(shí)錄實(shí)際操作中踩坑是難免的這里把高頻率出現(xiàn)過的問題整理成一個(gè)速查表方便后來者節(jié)省排查時(shí)間。兼容性問題。現(xiàn)象是部署階段報(bào)各種算子無法找到或者數(shù)據(jù)類型不匹配。原因通常是依賴環(huán)境太新或太舊。解決方法是嚴(yán)格按項(xiàng)目文檔鎖定核心依賴版本不要隨意升級(jí)。這算是最常見的一類問題遇到的多想想版本鎖定別懷疑是自己的代碼寫錯(cuò)了。顯存不足?，F(xiàn)象是推理大尺寸圖片或者批量處理時(shí)直接 OOM。對(duì)策有幾個(gè)方向一是把圖片最大邊長降下來就能明顯降低顯存占用二是控制批量大小逐張推理三是打開混合精度推理。輸出格式不穩(wěn)定?，F(xiàn)象是同一份文檔跑兩次偶爾會(huì)得到不同的 Markdown 結(jié)構(gòu)。原因在于模型本身有隨機(jī)性以及輸入圖像預(yù)處理有細(xì)微差別。解決方法是固定隨機(jī)種子并且把圖像預(yù)處理鏈路完全確定下來不要用隨機(jī)的插值方式。版面結(jié)構(gòu)丟失?，F(xiàn)象是模型輸出的 Markdown 里標(biāo)題層級(jí)全變成了普通文本表格也變成了無格式的文本串。這通常在處理低質(zhì)量手機(jī)拍攝件時(shí)更容易出現(xiàn)。如果文本模型兼容性允許嘗試直接以 JSON 結(jié)構(gòu)輸出版面信息再讓下游解析穩(wěn)定性會(huì)更高。我還想單獨(dú)分享一個(gè)獨(dú)家經(jīng)驗(yàn)遇到系統(tǒng)提示的兼容性問題先別急——有相當(dāng)比例的概率是你的顯卡算力不夠觸發(fā)了一些保守策略。我自己的機(jī)器上測試時(shí)發(fā)現(xiàn)小規(guī)格模型在某些情況下自動(dòng)啟用了低精度計(jì)算導(dǎo)致某些層的輸出類型不一致。這個(gè)情況如果你不太確定就把設(shè)備強(qiáng)制指定 CPU 跑一遍看看排錯(cuò)信息很容易定位到底是哪一層出了問題。此外如果你打算把光學(xué)壓縮接入自己的文檔處理流水線我建議在預(yù)處理階段就做一個(gè)自動(dòng)分類圖片質(zhì)量好的直接用高壓縮模式模糊的用高精度模式。這個(gè)分流策略在批處理大批量混雜文檔時(shí)非常實(shí)用既保證了整體速度也保住了核心內(nèi)容精度。5. 光學(xué)壓縮與傳統(tǒng)長文本方案的對(duì)比分析5.1 直接喂全文省了步驟卻不省錢傳統(tǒng)方案里最粗暴的一種就是不管多少內(nèi)容直接塞給長上下文模型。這種做法的優(yōu)點(diǎn)是省事缺一個(gè)都不能少。缺點(diǎn)是貴和慢都到了極致。這里的賬要算清楚文本模型按 Token 計(jì)費(fèi)喂五萬 Token 進(jìn)去那這五萬字每一字都要模型重新“看”一遍。注意力計(jì)算量跟 Token 數(shù)平方成正比結(jié)果就是上下文窗口越大單次推理成本越夸張。更隱性的是長上下文的“注意力稀釋”問題——模型需要關(guān)聯(lián)文檔開頭和結(jié)尾的信息時(shí)中間塞的大量無關(guān)頁面反而成了干擾。我做過一次測試同樣一份五十頁的文檔放在短模型分段處理再匯總的結(jié)果比一次性塞進(jìn)長窗口模型的輸出質(zhì)量好了不少后面的答案更聚焦沒有那么多“既…又…”式的模棱兩可。5.2 切片和 RAG聰明但丟失了全局視野切片加檢索引RAG是絕大多數(shù)團(tuán)隊(duì)的折中方案。先按固定窗口切分向量化建索引用戶提問時(shí)檢索相關(guān)片段拼給模型。這個(gè)方案的局限性在于檢索是“關(guān)鍵詞匹配”的邏輯但文檔里大量關(guān)鍵信息是隱含在結(jié)構(gòu)中的——比如一個(gè)名詞在前文被定義后文引用時(shí)用的簡稱檢索系統(tǒng)很難主動(dòng)把這兩處關(guān)聯(lián)起來。光學(xué)壓縮在這里的定位不是替代 RAG而是優(yōu)化 RAG 的輸入質(zhì)量。我的實(shí)際用法是先把整篇文檔光學(xué)壓縮成一份結(jié)構(gòu)化的全局摘要把這摘要作為 RAG 的頂層入口用戶提問時(shí)先讓模型讀摘要判斷問題落在哪個(gè)章節(jié)再精準(zhǔn)檢索那一章節(jié)的原文。這個(gè)“摘要定方位、原文給細(xì)節(jié)”的兩級(jí)結(jié)構(gòu)實(shí)測問答準(zhǔn)確率提升非常明顯。5.3 Agent 工具鏈各司其職才是最優(yōu)解如果把長文本處理放進(jìn)一個(gè)完整的 Agent 工具鏈里看光學(xué)壓縮最適合扮演的角色是“領(lǐng)航員”負(fù)責(zé)在成本最低的情況下把文檔的結(jié)構(gòu)和要點(diǎn)摸清楚。細(xì)節(jié)提取交給高精度 OCR 和向量檢索語義理解交給文本模型各司其職。這套組合的收益相當(dāng)直觀原本需要昂貴大模型處理整個(gè)文檔的成本密集型任務(wù)現(xiàn)在大部分只需要高性價(jià)比模型讀一份壓縮后的摘要。整體的延遲、費(fèi)用都是數(shù)量級(jí)層面的下降。對(duì)比維度光學(xué)壓縮方案傳統(tǒng)全文直接輸入切片 RAG輸入 Token 占用低壓縮比高極高中等按需檢索上下文連貫性好頁面級(jí)結(jié)構(gòu)化摘要一般長文注意力稀釋較弱片段間邏輯缺失應(yīng)用實(shí)時(shí)性很好兼容多類型文檔強(qiáng)強(qiáng)但需維護(hù)索引成本結(jié)構(gòu)前期輕量推理 后續(xù)壓縮文本全程高負(fù)載推理建索引成本 多次檢索推理典型適用場景長文檔/掃描件/復(fù)雜版面短文/高精度要求領(lǐng)域知識(shí)庫問答/多輪檢索當(dāng)然沒有完美的方案。光學(xué)壓縮的局限在于編碼器處理圖表密集的頁面時(shí)諸如折線圖的趨勢信息、數(shù)據(jù)表單元格的精確數(shù)字可能會(huì)在壓縮過程中被抽象掉。這類場景下需要在壓縮模塊之外套一層精確讀取工具做局部放大提取。談及未來可能的方向我個(gè)人覺得可以往“壓縮比可調(diào)節(jié)”的方向探索根據(jù)文檔類型動(dòng)態(tài)決定壓縮力度這個(gè)思路如果有做模型訓(xùn)練的朋友看到值得琢磨一下。6. 動(dòng)手試試從一張掃描件開始無論講了多少理論最終都要落到自己能上手跑通這一步。我建議你找一張平時(shí)工作中最常見的、有文字有表格的掃描件按上面的流程跑一遍重點(diǎn)體會(huì)兩個(gè)位置的變化預(yù)處理之后輸入模型的圖像尺寸以及模型輸出的 Token 量和原始文字量的比例。親眼看到幾萬字的文檔變成幾千 Token 的紀(jì)要你才會(huì)真正理解“光學(xué)壓縮”這四個(gè)字的分量。用光學(xué)壓縮處理文檔跟我之前用傳統(tǒng) OCR 的感受有一個(gè)本質(zhì)性的區(qū)別傳統(tǒng) OCR 是努力讓機(jī)器把所有字認(rèn)清光學(xué)壓縮是努力讓模型真正“讀懂一頁紙”。前者的天花板是識(shí)別精度后者的上限是理解深度。我自己在測試?yán)飳?duì)比過同一份合同傳統(tǒng)方案確實(shí)能把每個(gè)條款原文提取得一字不差但需要再寫一大段提示詞去讓模型關(guān)聯(lián)這些條款光學(xué)壓縮直接輸出的結(jié)構(gòu)里就隱含了條款之間的邏輯順序下游模型讀起來非常輕松。如果你正在被長文本處理的高成本和低效率困擾或者需要批量處理大量掃描件不妨花一個(gè)下午把這個(gè)方案跑起來看看效果。從我個(gè)人的實(shí)踐體會(huì)來說最終能讓整個(gè)文件處理流程的時(shí)效和花費(fèi)都得到明顯優(yōu)化。真被整頁整頁的 PDF 困住的時(shí)候試試讓模型直接“看”這頁紙或許就開闊起來了。