為文本模型裝上眼睛)
你滿心期待地打開 DeepSeek 的聊天框把一張聊天記錄截圖、一張 Excel 表格截圖拖進(jìn)去然后輸入“幫我把這頁數(shù)據(jù)整理成表格并且統(tǒng)計(jì)出總額?！彼芸旎亓艘痪湓挕拔沂且粋€(gè)純文本模型目前無法直接識別圖片中的內(nèi)容?！边@不是它變笨了而是你越過了它的能力邊界。DeepSeek 在很長一段時(shí)間里都專注于文本輸入輸出它的核心場景是代碼、文檔、推理、對話不是“看圖說話”。但“看圖”的需求又是真實(shí)存在的票據(jù)、截圖、表格、流程圖、UI 草圖這些信息都長在圖片里不轉(zhuǎn)成文字模型就處理不了。于是社區(qū)里冒出一個(gè)既實(shí)用、又有點(diǎn)“取巧”的方案——給 DeepSeek 安上眼睛。嚴(yán)格說這不是原生多模態(tài)更像是一種“偽多模態(tài)”用外部工具把圖像翻譯成文本再讓 DeepSeek 基于文本做推理。這篇文章想把這件事講透包括它的原理、實(shí)現(xiàn)路徑、參數(shù)細(xì)節(jié)以及它到底適合什么場景不適合什么場景。1. 先把“偽多模態(tài)”這件事說清楚它不是模型變聰明而是流程變長了1.1 真正的多模態(tài)和“偽多模態(tài)”差在哪原生多模態(tài)模型的底層是視覺編碼器加語言模型的聯(lián)合訓(xùn)練。圖像會先被編碼成向量再和文本指令一起進(jìn)入模型模型自己就能“看到”圖片。如果 DeepSeek 原生支持識圖API 請求里會直接有圖像字段你不需要在外部做任何轉(zhuǎn)換。偽多模態(tài)沒有這層。它做的事情是先用另一個(gè)模型或工具把圖片轉(zhuǎn)成文本再把文本作為輸入傳給 DeepSeek。換句話說模型本身依然看不到圖片看到圖片的是前面的“翻譯官”。所以“偽”字不是在貶低這個(gè)方案而是在提醒我們一個(gè)事實(shí)模型的能力邊界沒有變變的是整個(gè)調(diào)用鏈路的長度。你從“一張圖片直接提問”變成了“圖片 → 文本 → 提問 → 推理 → 輸出”。鏈路長了靈活性反而高了因?yàn)槟憧梢栽谥虚g插入 OCR、視覺描述、結(jié)構(gòu)化抽取等不同環(huán)節(jié)。記住這個(gè)判斷偽多模態(tài)解決的不是“讓 DeepSeek 擁有視覺”而是“讓 DeepSeek 拿到圖片里的信息”。1.2 為什么這種方式能跑通本質(zhì)是把“視覺問題”轉(zhuǎn)成“文本問題”文本模型最擅長的就是處理文本。截圖里的字被 OCR 提取后變成字符串UI 流程圖被視覺模型轉(zhuǎn)述成“這是一個(gè)登錄頁面包含用戶名框、密碼框和登錄按鈕”票據(jù)里的金額被識別成“人民幣 12,800 元”。DeepSeek 拿到這些文本后照樣能完成推理、總結(jié)、代碼生成。關(guān)鍵在于識圖任務(wù)里真正難的是“圖像理解”但很多業(yè)務(wù)場景要的其實(shí)只是“圖像里的信息和結(jié)構(gòu)”。信息能被文本化結(jié)構(gòu)能被描述清楚文本模型就能接手。舉個(gè)例子。你要 DeepSeek 幫你把一張表格截圖生成 Markdown 表格如果它沒長眼睛這事做不了。但你先用 OCR 把表格里的每一行每一列抽成帶分隔符的純文本再把這段文本交給 DeepSeek它會處理得很好。DeepSeek 不需要看到表格的邊框它只需要看到行列關(guān)系。這也是“偽多模態(tài)”能成立的底層邏輯視覺任務(wù)可以被拆成“感知”和“推理”兩步。感知交給專門的視覺工具推理交給文本模型。兩者各干各的再通過接口串起來。2. 三條給 DeepSeek“裝眼睛”的常見路徑怎么選給 DeepSeek 加上識圖能力不是只有一個(gè)辦法。根據(jù)你的場景、成本和精度要求通常有三條路徑可以走。2.1 路徑一純 OCR適合圖片里主要是文字的場景如果圖片里的核心內(nèi)容就是文字比如截圖、文檔、票據(jù)、表格那么最簡單的方式是 OCR。OCR 把圖片里的文字識別出來變成純文本然后直接交給 DeepSeek。優(yōu)勢是成本低、速度快、實(shí)現(xiàn)簡單。很多 OCR 引擎在本地就能跑不依賴額外的大模型也沒有圖像 token 費(fèi)用。劣勢是它只能提取文字不能理解圖像里的非文字信息。比如一張界面截圖里有紅色按鈕、布局、圖標(biāo)OCR 只能拿到按鈕上的文字拿不到按鈕的位置視覺關(guān)系。純 OCR 適合的場景很明確文字密集、結(jié)構(gòu)清晰、不需要空間關(guān)系推斷。比如“把這張聊天記錄總結(jié)成要點(diǎn)”“把這張發(fā)票的內(nèi)容提取出來”。2.2 路徑二視覺描述模型適合圖片里沒有太多文字但有信息結(jié)構(gòu)如果圖片本身是照片、流程圖、UI 草圖、產(chǎn)品外觀文字很少純 OCR 就失效了。這時(shí)候需要另一個(gè)“眼睛”一個(gè)支持圖像輸入的視覺語言模型把圖片內(nèi)容轉(zhuǎn)述成自然語言描述。操作上你把這個(gè)視覺模型當(dāng)成中間服務(wù)輸入圖片輸出一段描述文本再把描述文本交給 DeepSeek。視覺模型負(fù)責(zé)“看”DeepSeek 負(fù)責(zé)“想”。優(yōu)勢是適用范圍更廣能處理照片、圖表、界面等非純文字信息。劣勢是描述過程中可能丟失細(xì)節(jié)而且多了一層模型調(diào)用成本和耗時(shí)都會增加。選這個(gè)路徑時(shí)視覺模型的描述能力很關(guān)鍵。描述寫得越完整DeepSeek 后面的推理就越準(zhǔn)。2.3 路徑三編排框架適合想把流程固化下來長期使用第三類方式是使用編排框架、插件或客戶端工具把“圖片輸入 → 視覺轉(zhuǎn)換 → DeepSeek 推理 → 結(jié)果輸出”整個(gè)流程封裝起來。這也是社區(qū)里最常被提到的做法。很多第三方客戶端和開源項(xiàng)目已經(jīng)支持給 DeepSeek“掛”一個(gè)視覺 skill 或插件。這種路徑的優(yōu)勢是體驗(yàn)好不需要自己寫代碼用戶直接把圖片拖進(jìn)對話框框架會自動(dòng)調(diào)用視覺模型生成文本再傳給 DeepSeek。劣勢是依賴具體項(xiàng)目版本變化快配置復(fù)雜而且不同項(xiàng)目對隱私、數(shù)據(jù)存儲、密鑰管理的處理方式差異很大。如果你想快速驗(yàn)證效果可以先試這類編排工具如果你想穩(wěn)定落地到自己的業(yè)務(wù)里我更建議自己實(shí)現(xiàn)流程因?yàn)榭煽匦愿摺?.4 三條路徑怎么選路徑適合場景主要成本實(shí)現(xiàn)難度信息保真度純 OCR截圖、文檔、票據(jù)、表格低本地可跑低文字保真非文字信息丟失視覺描述模型照片、流程圖、UI 草圖中額外模型調(diào)用中取決于描述模型能力可能丟細(xì)節(jié)編排框架想快速上手、固化流程視項(xiàng)目而定中到高依賴內(nèi)部封裝的視覺模塊不要一上來就追求“最全”的方案。先看你的圖片里到底有什么是文字多還是結(jié)構(gòu)多還是視覺細(xì)節(jié)多。文字多用 OCR結(jié)構(gòu)多用描述模型兩者都有才考慮組合使用。3. 最小可用流程從一張圖片到一段文本回復(fù)下面我給出一個(gè)最小可用的“偽多模態(tài)”流程。這里不綁定具體工具因?yàn)椴煌h(huán)境下的 OCR 引擎和視覺模型差異很大重點(diǎn)是讓你理解整個(gè)鏈路的關(guān)鍵環(huán)節(jié)。3.1 前置準(zhǔn)備先確認(rèn)你有哪些基礎(chǔ)資源開始之前你需要準(zhǔn)備三樣?xùn)|西一個(gè) DeepSeek API Key以及能正常訪問 DeepSeek 開放平臺的網(wǎng)絡(luò)環(huán)境一個(gè)能把圖片轉(zhuǎn)成文本的工具可以是本地 OCR 庫也可以是一支持圖像輸入的模型接口一段把整條鏈路串起來的小程序Python 腳本足夠。如果原始材料里沒有說明具體依賴版本落地前先確認(rèn)你用的 OCR 庫、視覺模型 SDK 和 DeepSeek SDK 之間的版本兼容關(guān)系。不要盲目升級某一邊容易踩到依賴坑。3.2 第一步把圖片變成文本假設(shè)你選擇 OCR 路徑。你先把圖片讀入調(diào)用 OCR 引擎得到文本。下面是一個(gè)常見寫法的示意結(jié)構(gòu)具體參數(shù)以你實(shí)際使用的庫為準(zhǔn)# 示例結(jié)構(gòu)使用 OCR 庫識別圖片中的文字 from PIL import Image import your_ocr_engine # 換成你實(shí)際使用的 OCR 庫 image_path ./example_table.png img Image.open(image_path) # 這里通常會有語言、格式、是否輸出坐標(biāo)等參數(shù) result your_ocr_engine.recognize(img, langch, output_formattext) print(result)如果你選視覺描述模型路徑這個(gè)環(huán)節(jié)就會變成調(diào)用一個(gè)支持圖像輸入的模型接口讓它輸出圖片的自然語言描述。需要注意一些模型服務(wù)會把圖片當(dāng)作 base64 字符串傳入也可能要求傳入圖片 URL。具體格式要提前查清楚。3.3 第二步把文本交給 DeepSeek拿到圖中文本之后把它拼進(jìn)系統(tǒng)提示詞或用戶消息里。為了讓 DeepSeek 理解“這段文字是從圖片里提取的”最好在提示詞里明確告訴它。# 示例結(jié)構(gòu)調(diào)用 DeepSeek API將 OCR 文本交給模型 from openai import OpenAI client OpenAI( api_key你的_key, base_urlhttps://api.deepseek.com ) ocr_text 這里替換為第一步識別出來的文本 user_message ( 下面是從一張表格截圖中識別出來的原始文本可能帶換行和噪聲。\n 請把它整理成規(guī)范 Markdown 表格并計(jì)算最后一列的總和。\n\n f{ocr_text} ) response client.chat.completions.create( modeldeepseek-chat, # 以你的賬號實(shí)際可用的模型名為準(zhǔn) messages[ {role: system, content: 你是信息整理助手擅長從文本中還原結(jié)構(gòu)化內(nèi)容。}, {role: user, content: user_message} ] ) print(response.choices[0].message.content)這里有兩個(gè)容易踩的坑第一不要把 OCR 結(jié)果原封不動(dòng)丟掉。OCR 輸出可能帶多余換行、空格、亂碼但先別急著清理讓 DeepSeek 做格式化反而更穩(wěn)。你把噪聲清理得越狠越容易誤刪關(guān)鍵信息。第二模型名不要寫死。不同時(shí)間、不同賬號下可用模型可能不同先用開放平臺控制臺里的實(shí)際模型名。3.4 第三步先做單條驗(yàn)證再批量第一次跑通時(shí)不要直接處理 100 張圖。先用一張內(nèi)容最有代表性的圖片驗(yàn)證三個(gè)東西OCR/描述結(jié)果是否完整、DeepSeek 是否理解任務(wù)、輸出格式是否符合預(yù)期。如果 OCR 結(jié)果缺字先調(diào)識別語言或清晰度而不是改 DeepSeek 的提示詞如果 DeepSeek 輸出格式不對修改任務(wù)描述如果鏈路整體沒問題再考慮批量。不要一上來把目標(biāo)圖片當(dāng)作批量任務(wù)直接跑先用一張圖驗(yàn)證三個(gè)東西文字提取是否完整、描述是否準(zhǔn)確、DeepSeek 輸出是否符合預(yù)期。4. 關(guān)鍵參數(shù)與 token 預(yù)算這里決定你能否批量使用很多人第一次跑通后第二件事就是“我要一次處理幾千張圖片”。但在批量之前有幾個(gè)參數(shù)和預(yù)算問題必須弄明白。4.1 圖片壓縮和 base64直接影響等待時(shí)長圖片不是直接發(fā)給 DeepSeek 的它是先發(fā)給視覺模塊。視覺模塊接收圖片時(shí)一般有兩種方式傳本地文件路徑或者傳 base64 字符串。如果你用 API 調(diào)用視覺模型大概率是傳 base64。base64 會把圖片體積增加約 33%。一張 2MB 的圖片base64 后接近 2.7MB上傳和解析都會變慢。實(shí)際上大部分識圖場景根本不需要原圖那么大。比如識別一張截圖里的文字把圖片壓縮到 1280px 寬度甚至 800px 寬度通常會更快識別率也未必下降。建議在進(jìn)入視覺模塊之前先做一次圖片預(yù)處理統(tǒng)一圖片格式為 JPEG 或 PNG把長邊壓縮到 1280px 左右圖片過暗、過模糊時(shí)先做基礎(chǔ)增強(qiáng)如果是批量任務(wù)圖片命名規(guī)范里帶上業(yè)務(wù) ID方便后面追查。4.2 OCR 和描述模型的 prompt 傾向如果是純 OCR盡量用高識別精度的“文本模式”不要把 OCR 引擎的自動(dòng)分段結(jié)果當(dāng)成最終格式。你可以先讓它輸出帶行號或坐標(biāo)的原始文本方便后續(xù)對齊。如果是視覺描述模型提示詞要盡量具體。比如“請描述這個(gè)界面里所有可見的按鈕、輸入框、文本和它們的相對位置”比“描述一下這張圖”要好得多。描述越結(jié)構(gòu)化DeepSeek 越容易完成任務(wù)。視覺模型描述時(shí)你還要注意一個(gè)取舍描述越詳細(xì)token 越多描述越簡單信息丟失越嚴(yán)重。我的建議是在正文內(nèi)容保真和 token 消耗之間取平衡先讓描述模型輸出結(jié)構(gòu)化要點(diǎn)不要輸出散文。4.3 DeepSeek 上下文和成本預(yù)算DeepSeek 處理的是文本所以圖片信息轉(zhuǎn)成文本后會占用它的上下文空間。一張復(fù)雜截圖的 OCR 結(jié)果可能 2000 到 5000 字一段完整的 UI 描述可能 800 到 1500 字。同一批任務(wù)如果一次塞太多張圖很容易超過上下文窗口或者讓單次請求變得很貴。從工程經(jīng)驗(yàn)看批量任務(wù)建議采用“逐步處理”策略每張圖片單獨(dú)跑 OCR/描述得到該圖的文本對文本做質(zhì)量檢查確認(rèn)沒有大面積識別錯(cuò)誤把多張圖的文本合并提交給 DeepSeek 時(shí)先估算總 token如果文本太長優(yōu)先拆成多個(gè)子任務(wù)比如按頁拆分、按業(yè)務(wù)字段拆分。下面是一張粗略的成本估算表具體價(jià)格會隨平臺調(diào)整而變化但思路是通用的環(huán)節(jié)一次調(diào)用的大致消耗批量時(shí)的風(fēng)險(xiǎn)OCR 識別CPU/內(nèi)存占用少量存儲并發(fā)過高時(shí)線程阻塞視覺描述模型圖像 token 輸出文本 token描述過長導(dǎo)致成本膨脹DeepSeek 文本推理輸入文本 token 輸出 token合并多圖時(shí)超上下文文件存儲圖片 文本中間結(jié)果中間結(jié)果沒有留存出問題難排查有一個(gè)很多人忽略的點(diǎn)中間文本最好落盤保存。OCR/描述的中間結(jié)果保存成 JSON 或文本文件DeepSeek 的輸出也留一份。這樣即使 DeepSeek 返回異常你也能定位是視覺模塊的問題還是模型推理的問題。5. 翻車現(xiàn)場常見報(bào)錯(cuò)的排查鏈路偽多模態(tài)鏈路比普通文本調(diào)用多了一個(gè)環(huán)節(jié)所以報(bào)錯(cuò)位置也多了一個(gè)。下面這些現(xiàn)象我在實(shí)際折騰中經(jīng)常遇到。5.1 報(bào)錯(cuò)現(xiàn)象模型不認(rèn)圖片這類報(bào)錯(cuò)的提示通常是“這個(gè)模型不支持圖片輸入”或接口層面提示 image 字段無效。出現(xiàn)這個(gè)報(bào)錯(cuò)說明你把圖片直接傳給了 DeepSeek 的文本接口而 DeepSeek 沒有原生視覺能力。正確的處理方式是把圖片內(nèi)容先轉(zhuǎn)成文本再傳文本。不要跟模型層較勁問題出在輸入階段。5.2 報(bào)錯(cuò)現(xiàn)象OCR 識別出來了但 DeepSeek 答非所問這很可能是“文本質(zhì)量”問題。OCR 識別出了文字但把表格的列和行關(guān)系弄亂了或者把換行搞丟了。DeepSeek 拿到一段沒有結(jié)構(gòu)信息的文本自然很難還原表格。處理方法是先檢查 OCR 輸出而不是反復(fù)改 DeepSeek 的提示詞。你可以在傳給 DeepSeek 之前把 OCR 文本先打印出來看一遍確認(rèn)字段順序、分隔符、換行都還合理。5.3 報(bào)錯(cuò)現(xiàn)象批量任務(wù)中途超時(shí)或限流批量處理時(shí)既有 OCR 引擎的資源消耗又有 DeepSeek API 的并發(fā)限制還可能有文件讀取的 IO 瓶頸。報(bào)錯(cuò)可能表現(xiàn)為部分任務(wù)超時(shí)、全部任務(wù)排隊(duì)很久、結(jié)果缺失。這時(shí)先確認(rèn)瓶頸在哪一層只有一張圖都慢看是 OCR 庫本身慢還是接口網(wǎng)絡(luò)慢多張圖后變慢看是并發(fā)不夠還是接口被限流單張正常、批量偶爾失敗多半是并發(fā)策略需要加退避重試。5.4 穩(wěn)定排查順序無論遇到什么問題我建議按下面的鏈路排查先看現(xiàn)象是報(bào)錯(cuò)、卡住、無輸出還是輸出結(jié)果錯(cuò)誤。再看輸入圖片路徑是否正確、格式是否支持、文字是否清晰、OCR/描述結(jié)果是否完整。再看環(huán)境依賴版本、API Key 權(quán)限、網(wǎng)絡(luò)連通性、磁盤空間是否充足。再看參數(shù)并發(fā)數(shù)、超時(shí)時(shí)間、最大 token、圖片壓縮尺寸是否合理。最后看工具邊界DeepSeek 是否支持當(dāng)前任務(wù)、視覺模型是否真的理解圖片、中間格式轉(zhuǎn)換是否丟失信息。這個(gè)順序幾乎能覆蓋大部分問題。不要一上來就懷疑 DeepSeek 的推理能力大多數(shù)翻車不是因?yàn)槟Ｐ捅慷且驗(yàn)榍懊嫖菇o它的材料就錯(cuò)了。6. 什么時(shí)候該用偽多模態(tài)什么時(shí)候該等原生方案前面講了原理、路徑、流程、參數(shù)和排查最后必須把適用邊界說清楚否則你會被這個(gè)方案“坑”在不合適的地方。6.1 適合偽多模態(tài)的場景第一類是文字型圖片。聊天記錄、文檔截圖、表格截圖、票據(jù)、簡歷、合同掃描件。這些圖片里的核心資產(chǎn)是文字OCR 提取后交給 DeepSeek 整理效果很好。第二類是低復(fù)雜度視覺理解。比如“這個(gè)界面上有哪些功能”“這張海報(bào)上的活動(dòng)規(guī)則是什么”“這個(gè)流程圖描述了什么流程”。只要視覺模型能給出準(zhǔn)確的結(jié)構(gòu)化描述DeepSeek 就能接手。第三類是流程里已經(jīng)需要文本模型的地方。你本來就在用 DeepSeek 做日志分析、文檔生成、代碼編寫只是偶爾需要處理圖片。不值得為了偶爾幾次識圖任務(wù)專門換一個(gè)原生多模態(tài)模型外掛視覺模塊更劃算。6.2 不適合偽多模態(tài)的場景第一類是強(qiáng)空間關(guān)系任務(wù)。比如“這張照片里的人在畫面的哪一側(cè)”“兩個(gè)物體距離遠(yuǎn)不遠(yuǎn)”。視覺模型轉(zhuǎn)成文本時(shí)空間信息會大量丟失DeepSeek 拿到文本后只能猜。第二類是細(xì)粒度視覺差異。比如判斷兩張?jiān)O(shè)計(jì)稿的顏色、像素級對齊、圖標(biāo)形狀差異。這類任務(wù)對視覺編碼要求極高文本化描述遠(yuǎn)遠(yuǎn)不夠。第三類是敏感信息和高錯(cuò)誤容忍成本場景。如果圖片里包含大量隱私數(shù)據(jù)或者識別錯(cuò)誤會產(chǎn)生嚴(yán)重業(yè)務(wù)后果你應(yīng)該優(yōu)先考慮做完整的多模態(tài)方案并做好數(shù)據(jù)脫敏和人工復(fù)核而不是圖省事套一層偽多模態(tài)。6.3 我的建議偽多模態(tài)不是一個(gè)完美方案但它是一個(gè)很實(shí)際的工程取舍。它解決的本質(zhì)問題是在模型能力受限的情況下如何用流程編排讓文本模型完成視覺任務(wù)。它的價(jià)值不在“更快”而在“讓一個(gè)原本不可用的場景變得可用”。如果你只是嘗鮮用編排工具把圖拖進(jìn)去看效果就夠了。如果你想放進(jìn)真實(shí)項(xiàng)目至少要補(bǔ)上圖片預(yù)處理、中間文本留存、日志、異常重試和人工抽檢。先跑通再優(yōu)化最后工程化這個(gè)順序比什么都重要。等到未來 DeepSeek 或其它文本模型真正開放原生視覺能力時(shí)你也不需要推翻現(xiàn)在這套流程。把最前面的“視覺模塊”換成原生圖像輸入后面的文本處理邏輯還可以繼續(xù)復(fù)用。所以今天折騰這套偽多模態(tài)并不是白費(fèi)功夫它是在幫你提前搭好一條可替換的前處理鏈路。 DeepSeek“看圖”指南：用偽多模態(tài)為文本模型裝上眼睛
你滿心期待地打開 DeepSeek 的聊天框把一張聊天記錄截圖、一張 Excel 表格截圖拖進(jìn)去然后輸入“幫我把這頁數(shù)據(jù)整理成表格并且統(tǒng)計(jì)出總額?！彼芸旎亓艘痪湓挕拔沂且粋€(gè)純文本模型目前無法直接識別圖片中的內(nèi)容?！边@不是它變笨了而是你越過了它的能力邊界。DeepSeek 在很長一段時(shí)間里都專注于文本輸入輸出它的核心場景是代碼、文檔、推理、對話不是“看圖說話”。但“看圖”的需求又是真實(shí)存在的票據(jù)、截圖、表格、流程圖、UI 草圖這些信息都長在圖片里不轉(zhuǎn)成文字模型就處理不了。于是社區(qū)里冒出一個(gè)既實(shí)用、又有點(diǎn)“取巧”的方案——給 DeepSeek 安上眼睛。嚴(yán)格說這不是原生多模態(tài)更像是一種“偽多模態(tài)”用外部工具把圖像翻譯成文本再讓 DeepSeek 基于文本做推理。這篇文章想把這件事講透包括它的原理、實(shí)現(xiàn)路徑、參數(shù)細(xì)節(jié)以及它到底適合什么場景不適合什么場景。1. 先把“偽多模態(tài)”這件事說清楚它不是模型變聰明而是流程變長了1.1 真正的多模態(tài)和“偽多模態(tài)”差在哪原生多模態(tài)模型的底層是視覺編碼器加語言模型的聯(lián)合訓(xùn)練。圖像會先被編碼成向量再和文本指令一起進(jìn)入模型模型自己就能“看到”圖片。如果 DeepSeek 原生支持識圖API 請求里會直接有圖像字段你不需要在外部做任何轉(zhuǎn)換。偽多模態(tài)沒有這層。它做的事情是先用另一個(gè)模型或工具把圖片轉(zhuǎn)成文本再把文本作為輸入傳給 DeepSeek。換句話說模型本身依然看不到圖片看到圖片的是前面的“翻譯官”。所以“偽”字不是在貶低這個(gè)方案而是在提醒我們一個(gè)事實(shí)模型的能力邊界沒有變變的是整個(gè)調(diào)用鏈路的長度。你從“一張圖片直接提問”變成了“圖片 → 文本 → 提問 → 推理 → 輸出”。鏈路長了靈活性反而高了因?yàn)槟憧梢栽谥虚g插入 OCR、視覺描述、結(jié)構(gòu)化抽取等不同環(huán)節(jié)。記住這個(gè)判斷偽多模態(tài)解決的不是“讓 DeepSeek 擁有視覺”而是“讓 DeepSeek 拿到圖片里的信息”。1.2 為什么這種方式能跑通本質(zhì)是把“視覺問題”轉(zhuǎn)成“文本問題”文本模型最擅長的就是處理文本。截圖里的字被 OCR 提取后變成字符串UI 流程圖被視覺模型轉(zhuǎn)述成“這是一個(gè)登錄頁面包含用戶名框、密碼框和登錄按鈕”票據(jù)里的金額被識別成“人民幣 12,800 元”。DeepSeek 拿到這些文本后照樣能完成推理、總結(jié)、代碼生成。關(guān)鍵在于識圖任務(wù)里真正難的是“圖像理解”但很多業(yè)務(wù)場景要的其實(shí)只是“圖像里的信息和結(jié)構(gòu)”。信息能被文本化結(jié)構(gòu)能被描述清楚文本模型就能接手。舉個(gè)例子。你要 DeepSeek 幫你把一張表格截圖生成 Markdown 表格如果它沒長眼睛這事做不了。但你先用 OCR 把表格里的每一行每一列抽成帶分隔符的純文本再把這段文本交給 DeepSeek它會處理得很好。DeepSeek 不需要看到表格的邊框它只需要看到行列關(guān)系。這也是“偽多模態(tài)”能成立的底層邏輯視覺任務(wù)可以被拆成“感知”和“推理”兩步。感知交給專門的視覺工具推理交給文本模型。兩者各干各的再通過接口串起來。2. 三條給 DeepSeek“裝眼睛”的常見路徑怎么選給 DeepSeek 加上識圖能力不是只有一個(gè)辦法。根據(jù)你的場景、成本和精度要求通常有三條路徑可以走。2.1 路徑一純 OCR適合圖片里主要是文字的場景如果圖片里的核心內(nèi)容就是文字比如截圖、文檔、票據(jù)、表格那么最簡單的方式是 OCR。OCR 把圖片里的文字識別出來變成純文本然后直接交給 DeepSeek。優(yōu)勢是成本低、速度快、實(shí)現(xiàn)簡單。很多 OCR 引擎在本地就能跑不依賴額外的大模型也沒有圖像 token 費(fèi)用。劣勢是它只能提取文字不能理解圖像里的非文字信息。比如一張界面截圖里有紅色按鈕、布局、圖標(biāo)OCR 只能拿到按鈕上的文字拿不到按鈕的位置視覺關(guān)系。純 OCR 適合的場景很明確文字密集、結(jié)構(gòu)清晰、不需要空間關(guān)系推斷。比如“把這張聊天記錄總結(jié)成要點(diǎn)”“把這張發(fā)票的內(nèi)容提取出來”。2.2 路徑二視覺描述模型適合圖片里沒有太多文字但有信息結(jié)構(gòu)如果圖片本身是照片、流程圖、UI 草圖、產(chǎn)品外觀文字很少純 OCR 就失效了。這時(shí)候需要另一個(gè)“眼睛”一個(gè)支持圖像輸入的視覺語言模型把圖片內(nèi)容轉(zhuǎn)述成自然語言描述。操作上你把這個(gè)視覺模型當(dāng)成中間服務(wù)輸入圖片輸出一段描述文本再把描述文本交給 DeepSeek。視覺模型負(fù)責(zé)“看”DeepSeek 負(fù)責(zé)“想”。優(yōu)勢是適用范圍更廣能處理照片、圖表、界面等非純文字信息。劣勢是描述過程中可能丟失細(xì)節(jié)而且多了一層模型調(diào)用成本和耗時(shí)都會增加。選這個(gè)路徑時(shí)視覺模型的描述能力很關(guān)鍵。描述寫得越完整DeepSeek 后面的推理就越準(zhǔn)。2.3 路徑三編排框架適合想把流程固化下來長期使用第三類方式是使用編排框架、插件或客戶端工具把“圖片輸入 → 視覺轉(zhuǎn)換 → DeepSeek 推理 → 結(jié)果輸出”整個(gè)流程封裝起來。這也是社區(qū)里最常被提到的做法。很多第三方客戶端和開源項(xiàng)目已經(jīng)支持給 DeepSeek“掛”一個(gè)視覺 skill 或插件。這種路徑的優(yōu)勢是體驗(yàn)好不需要自己寫代碼用戶直接把圖片拖進(jìn)對話框框架會自動(dòng)調(diào)用視覺模型生成文本再傳給 DeepSeek。劣勢是依賴具體項(xiàng)目版本變化快配置復(fù)雜而且不同項(xiàng)目對隱私、數(shù)據(jù)存儲、密鑰管理的處理方式差異很大。如果你想快速驗(yàn)證效果可以先試這類編排工具如果你想穩(wěn)定落地到自己的業(yè)務(wù)里我更建議自己實(shí)現(xiàn)流程因?yàn)榭煽匦愿摺?.4 三條路徑怎么選路徑適合場景主要成本實(shí)現(xiàn)難度信息保真度純 OCR截圖、文檔、票據(jù)、表格低本地可跑低文字保真非文字信息丟失視覺描述模型照片、流程圖、UI 草圖中額外模型調(diào)用中取決于描述模型能力可能丟細(xì)節(jié)編排框架想快速上手、固化流程視項(xiàng)目而定中到高依賴內(nèi)部封裝的視覺模塊不要一上來就追求“最全”的方案。先看你的圖片里到底有什么是文字多還是結(jié)構(gòu)多還是視覺細(xì)節(jié)多。文字多用 OCR結(jié)構(gòu)多用描述模型兩者都有才考慮組合使用。3. 最小可用流程從一張圖片到一段文本回復(fù)下面我給出一個(gè)最小可用的“偽多模態(tài)”流程。這里不綁定具體工具因?yàn)椴煌h(huán)境下的 OCR 引擎和視覺模型差異很大重點(diǎn)是讓你理解整個(gè)鏈路的關(guān)鍵環(huán)節(jié)。3.1 前置準(zhǔn)備先確認(rèn)你有哪些基礎(chǔ)資源開始之前你需要準(zhǔn)備三樣?xùn)|西一個(gè) DeepSeek API Key以及能正常訪問 DeepSeek 開放平臺的網(wǎng)絡(luò)環(huán)境一個(gè)能把圖片轉(zhuǎn)成文本的工具可以是本地 OCR 庫也可以是一支持圖像輸入的模型接口一段把整條鏈路串起來的小程序Python 腳本足夠。如果原始材料里沒有說明具體依賴版本落地前先確認(rèn)你用的 OCR 庫、視覺模型 SDK 和 DeepSeek SDK 之間的版本兼容關(guān)系。不要盲目升級某一邊容易踩到依賴坑。3.2 第一步把圖片變成文本假設(shè)你選擇 OCR 路徑。你先把圖片讀入調(diào)用 OCR 引擎得到文本。下面是一個(gè)常見寫法的示意結(jié)構(gòu)具體參數(shù)以你實(shí)際使用的庫為準(zhǔn)# 示例結(jié)構(gòu)使用 OCR 庫識別圖片中的文字 from PIL import Image import your_ocr_engine # 換成你實(shí)際使用的 OCR 庫 image_path ./example_table.png img Image.open(image_path) # 這里通常會有語言、格式、是否輸出坐標(biāo)等參數(shù) result your_ocr_engine.recognize(img, langch, output_formattext) print(result)如果你選視覺描述模型路徑這個(gè)環(huán)節(jié)就會變成調(diào)用一個(gè)支持圖像輸入的模型接口讓它輸出圖片的自然語言描述。需要注意一些模型服務(wù)會把圖片當(dāng)作 base64 字符串傳入也可能要求傳入圖片 URL。具體格式要提前查清楚。3.3 第二步把文本交給 DeepSeek拿到圖中文本之后把它拼進(jìn)系統(tǒng)提示詞或用戶消息里。為了讓 DeepSeek 理解“這段文字是從圖片里提取的”最好在提示詞里明確告訴它。# 示例結(jié)構(gòu)調(diào)用 DeepSeek API將 OCR 文本交給模型 from openai import OpenAI client OpenAI( api_key你的_key, base_urlhttps://api.deepseek.com ) ocr_text 這里替換為第一步識別出來的文本 user_message ( 下面是從一張表格截圖中識別出來的原始文本可能帶換行和噪聲。\n 請把它整理成規(guī)范 Markdown 表格并計(jì)算最后一列的總和。\n\n f{ocr_text} ) response client.chat.completions.create( modeldeepseek-chat, # 以你的賬號實(shí)際可用的模型名為準(zhǔn) messages[ {role: system, content: 你是信息整理助手擅長從文本中還原結(jié)構(gòu)化內(nèi)容。}, {role: user, content: user_message} ] ) print(response.choices[0].message.content)這里有兩個(gè)容易踩的坑第一不要把 OCR 結(jié)果原封不動(dòng)丟掉。OCR 輸出可能帶多余換行、空格、亂碼但先別急著清理讓 DeepSeek 做格式化反而更穩(wěn)。你把噪聲清理得越狠越容易誤刪關(guān)鍵信息。第二模型名不要寫死。不同時(shí)間、不同賬號下可用模型可能不同先用開放平臺控制臺里的實(shí)際模型名。3.4 第三步先做單條驗(yàn)證再批量第一次跑通時(shí)不要直接處理 100 張圖。先用一張內(nèi)容最有代表性的圖片驗(yàn)證三個(gè)東西OCR/描述結(jié)果是否完整、DeepSeek 是否理解任務(wù)、輸出格式是否符合預(yù)期。如果 OCR 結(jié)果缺字先調(diào)識別語言或清晰度而不是改 DeepSeek 的提示詞如果 DeepSeek 輸出格式不對修改任務(wù)描述如果鏈路整體沒問題再考慮批量。不要一上來把目標(biāo)圖片當(dāng)作批量任務(wù)直接跑先用一張圖驗(yàn)證三個(gè)東西文字提取是否完整、描述是否準(zhǔn)確、DeepSeek 輸出是否符合預(yù)期。4. 關(guān)鍵參數(shù)與 token 預(yù)算這里決定你能否批量使用很多人第一次跑通后第二件事就是“我要一次處理幾千張圖片”。但在批量之前有幾個(gè)參數(shù)和預(yù)算問題必須弄明白。4.1 圖片壓縮和 base64直接影響等待時(shí)長圖片不是直接發(fā)給 DeepSeek 的它是先發(fā)給視覺模塊。視覺模塊接收圖片時(shí)一般有兩種方式傳本地文件路徑或者傳 base64 字符串。如果你用 API 調(diào)用視覺模型大概率是傳 base64。base64 會把圖片體積增加約 33%。一張 2MB 的圖片base64 后接近 2.7MB上傳和解析都會變慢。實(shí)際上大部分識圖場景根本不需要原圖那么大。比如識別一張截圖里的文字把圖片壓縮到 1280px 寬度甚至 800px 寬度通常會更快識別率也未必下降。建議在進(jìn)入視覺模塊之前先做一次圖片預(yù)處理統(tǒng)一圖片格式為 JPEG 或 PNG把長邊壓縮到 1280px 左右圖片過暗、過模糊時(shí)先做基礎(chǔ)增強(qiáng)如果是批量任務(wù)圖片命名規(guī)范里帶上業(yè)務(wù) ID方便后面追查。4.2 OCR 和描述模型的 prompt 傾向如果是純 OCR盡量用高識別精度的“文本模式”不要把 OCR 引擎的自動(dòng)分段結(jié)果當(dāng)成最終格式。你可以先讓它輸出帶行號或坐標(biāo)的原始文本方便后續(xù)對齊。如果是視覺描述模型提示詞要盡量具體。比如“請描述這個(gè)界面里所有可見的按鈕、輸入框、文本和它們的相對位置”比“描述一下這張圖”要好得多。描述越結(jié)構(gòu)化DeepSeek 越容易完成任務(wù)。視覺模型描述時(shí)你還要注意一個(gè)取舍描述越詳細(xì)token 越多描述越簡單信息丟失越嚴(yán)重。我的建議是在正文內(nèi)容保真和 token 消耗之間取平衡先讓描述模型輸出結(jié)構(gòu)化要點(diǎn)不要輸出散文。4.3 DeepSeek 上下文和成本預(yù)算DeepSeek 處理的是文本所以圖片信息轉(zhuǎn)成文本后會占用它的上下文空間。一張復(fù)雜截圖的 OCR 結(jié)果可能 2000 到 5000 字一段完整的 UI 描述可能 800 到 1500 字。同一批任務(wù)如果一次塞太多張圖很容易超過上下文窗口或者讓單次請求變得很貴。從工程經(jīng)驗(yàn)看批量任務(wù)建議采用“逐步處理”策略每張圖片單獨(dú)跑 OCR/描述得到該圖的文本對文本做質(zhì)量檢查確認(rèn)沒有大面積識別錯(cuò)誤把多張圖的文本合并提交給 DeepSeek 時(shí)先估算總 token如果文本太長優(yōu)先拆成多個(gè)子任務(wù)比如按頁拆分、按業(yè)務(wù)字段拆分。下面是一張粗略的成本估算表具體價(jià)格會隨平臺調(diào)整而變化但思路是通用的環(huán)節(jié)一次調(diào)用的大致消耗批量時(shí)的風(fēng)險(xiǎn)OCR 識別CPU/內(nèi)存占用少量存儲并發(fā)過高時(shí)線程阻塞視覺描述模型圖像 token 輸出文本 token描述過長導(dǎo)致成本膨脹DeepSeek 文本推理輸入文本 token 輸出 token合并多圖時(shí)超上下文文件存儲圖片 文本中間結(jié)果中間結(jié)果沒有留存出問題難排查有一個(gè)很多人忽略的點(diǎn)中間文本最好落盤保存。OCR/描述的中間結(jié)果保存成 JSON 或文本文件DeepSeek 的輸出也留一份。這樣即使 DeepSeek 返回異常你也能定位是視覺模塊的問題還是模型推理的問題。5. 翻車現(xiàn)場常見報(bào)錯(cuò)的排查鏈路偽多模態(tài)鏈路比普通文本調(diào)用多了一個(gè)環(huán)節(jié)所以報(bào)錯(cuò)位置也多了一個(gè)。下面這些現(xiàn)象我在實(shí)際折騰中經(jīng)常遇到。5.1 報(bào)錯(cuò)現(xiàn)象模型不認(rèn)圖片這類報(bào)錯(cuò)的提示通常是“這個(gè)模型不支持圖片輸入”或接口層面提示 image 字段無效。出現(xiàn)這個(gè)報(bào)錯(cuò)說明你把圖片直接傳給了 DeepSeek 的文本接口而 DeepSeek 沒有原生視覺能力。正確的處理方式是把圖片內(nèi)容先轉(zhuǎn)成文本再傳文本。不要跟模型層較勁問題出在輸入階段。5.2 報(bào)錯(cuò)現(xiàn)象OCR 識別出來了但 DeepSeek 答非所問這很可能是“文本質(zhì)量”問題。OCR 識別出了文字但把表格的列和行關(guān)系弄亂了或者把換行搞丟了。DeepSeek 拿到一段沒有結(jié)構(gòu)信息的文本自然很難還原表格。處理方法是先檢查 OCR 輸出而不是反復(fù)改 DeepSeek 的提示詞。你可以在傳給 DeepSeek 之前把 OCR 文本先打印出來看一遍確認(rèn)字段順序、分隔符、換行都還合理。5.3 報(bào)錯(cuò)現(xiàn)象批量任務(wù)中途超時(shí)或限流批量處理時(shí)既有 OCR 引擎的資源消耗又有 DeepSeek API 的并發(fā)限制還可能有文件讀取的 IO 瓶頸。報(bào)錯(cuò)可能表現(xiàn)為部分任務(wù)超時(shí)、全部任務(wù)排隊(duì)很久、結(jié)果缺失。這時(shí)先確認(rèn)瓶頸在哪一層只有一張圖都慢看是 OCR 庫本身慢還是接口網(wǎng)絡(luò)慢多張圖后變慢看是并發(fā)不夠還是接口被限流單張正常、批量偶爾失敗多半是并發(fā)策略需要加退避重試。5.4 穩(wěn)定排查順序無論遇到什么問題我建議按下面的鏈路排查先看現(xiàn)象是報(bào)錯(cuò)、卡住、無輸出還是輸出結(jié)果錯(cuò)誤。再看輸入圖片路徑是否正確、格式是否支持、文字是否清晰、OCR/描述結(jié)果是否完整。再看環(huán)境依賴版本、API Key 權(quán)限、網(wǎng)絡(luò)連通性、磁盤空間是否充足。再看參數(shù)并發(fā)數(shù)、超時(shí)時(shí)間、最大 token、圖片壓縮尺寸是否合理。最后看工具邊界DeepSeek 是否支持當(dāng)前任務(wù)、視覺模型是否真的理解圖片、中間格式轉(zhuǎn)換是否丟失信息。這個(gè)順序幾乎能覆蓋大部分問題。不要一上來就懷疑 DeepSeek 的推理能力大多數(shù)翻車不是因?yàn)槟Ｐ捅慷且驗(yàn)榍懊嫖菇o它的材料就錯(cuò)了。6. 什么時(shí)候該用偽多模態(tài)什么時(shí)候該等原生方案前面講了原理、路徑、流程、參數(shù)和排查最后必須把適用邊界說清楚否則你會被這個(gè)方案“坑”在不合適的地方。6.1 適合偽多模態(tài)的場景第一類是文字型圖片。聊天記錄、文檔截圖、表格截圖、票據(jù)、簡歷、合同掃描件。這些圖片里的核心資產(chǎn)是文字OCR 提取后交給 DeepSeek 整理效果很好。第二類是低復(fù)雜度視覺理解。比如“這個(gè)界面上有哪些功能”“這張海報(bào)上的活動(dòng)規(guī)則是什么”“這個(gè)流程圖描述了什么流程”。只要視覺模型能給出準(zhǔn)確的結(jié)構(gòu)化描述DeepSeek 就能接手。第三類是流程里已經(jīng)需要文本模型的地方。你本來就在用 DeepSeek 做日志分析、文檔生成、代碼編寫只是偶爾需要處理圖片。不值得為了偶爾幾次識圖任務(wù)專門換一個(gè)原生多模態(tài)模型外掛視覺模塊更劃算。6.2 不適合偽多模態(tài)的場景第一類是強(qiáng)空間關(guān)系任務(wù)。比如“這張照片里的人在畫面的哪一側(cè)”“兩個(gè)物體距離遠(yuǎn)不遠(yuǎn)”。視覺模型轉(zhuǎn)成文本時(shí)空間信息會大量丟失DeepSeek 拿到文本后只能猜。第二類是細(xì)粒度視覺差異。比如判斷兩張?jiān)O(shè)計(jì)稿的顏色、像素級對齊、圖標(biāo)形狀差異。這類任務(wù)對視覺編碼要求極高文本化描述遠(yuǎn)遠(yuǎn)不夠。第三類是敏感信息和高錯(cuò)誤容忍成本場景。如果圖片里包含大量隱私數(shù)據(jù)或者識別錯(cuò)誤會產(chǎn)生嚴(yán)重業(yè)務(wù)后果你應(yīng)該優(yōu)先考慮做完整的多模態(tài)方案并做好數(shù)據(jù)脫敏和人工復(fù)核而不是圖省事套一層偽多模態(tài)。6.3 我的建議偽多模態(tài)不是一個(gè)完美方案但它是一個(gè)很實(shí)際的工程取舍。它解決的本質(zhì)問題是在模型能力受限的情況下如何用流程編排讓文本模型完成視覺任務(wù)。它的價(jià)值不在“更快”而在“讓一個(gè)原本不可用的場景變得可用”。如果你只是嘗鮮用編排工具把圖拖進(jìn)去看效果就夠了。如果你想放進(jìn)真實(shí)項(xiàng)目至少要補(bǔ)上圖片預(yù)處理、中間文本留存、日志、異常重試和人工抽檢。先跑通再優(yōu)化最后工程化這個(gè)順序比什么都重要。等到未來 DeepSeek 或其它文本模型真正開放原生視覺能力時(shí)你也不需要推翻現(xiàn)在這套流程。把最前面的“視覺模塊”換成原生圖像輸入后面的文本處理邏輯還可以繼續(xù)復(fù)用。所以今天折騰這套偽多模態(tài)并不是白費(fèi)功夫它是在幫你提前搭好一條可替換的前處理鏈路。