# 影片筆記：DeepSeek V4視覺模型驚世發布，OpenAI這下真的坐不住了？😱


<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->
## ⚠️ 可先使用，仍有待修正項目

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

- 待修正：逐字稿全文快速校讀未完成（已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

## 一句話總結

DeepSeek 發布實驗性多模態模型 **V4 Flash Vision EXP**，透過開放權重與代碼讓開發者介入輸入處理鏈路；影片強調需謹慎解讀官方測試成績（部分進步僅因獲得新輸入而非推理能力提升），並建議在報銷、文檔等場景採用「模型識別 + 規則驗證 + 人工覆核」的分層架構以控制風險與成本。

## 核心重點

1.  **模型定位與開放性**：
    *   **DeepSeek V4 Flash Vision EXP** 是 V4 家族首個實驗性多模態模型，基於 V4 Flash 架構加入視覺模塊並繼續訓練。
    *   在 Hugging Face 公開倉庫中包含權重、配置、參考推理代碼及提示編碼，賦予開發者檢查與調整輸入處理鏈路的權利，而非僅提供黑盒接口。
    *   採用 **MIT 許可證**，使用者擁有控制權，但也需自行承擔數據隱私、版本維護與成本結構變化的責任。

2.  **測試成績的謹慎解讀**：
    *   **變量控制**：部分測試（如 ApexBench）舊模型未使用多模態輸入，新模型的進步主要反映「獲得新輸入後的表現變化」，而非純推理能力的絕對提升。
    *   **專業與通用的差異**：在專業圖表理解（Chartography）上表現接近閉源模型（Opus 4.8），但在代碼生成（NL to Repo）任務上仍有顯著差距。
    *   **測試條件限制**：成績基於 Deepseek Harness minimal 模式、最高推理強度及特定參數（Temperature 1.0, Top P 0.95），換配置或縮短思考預算可能無法復現。

3.  **技術架構與工程現實**：
    *   **結構**：由視覺編碼器與對齊模塊組成，支持圖像與文字交錯輸入。
    *   **混合專家 (MoE)**：256 個路由專家，每個 token 選擇 6 個。誤區在於不等於只需存儲被選中的專家，實際部署需處理全量權重及運行時資源。
    *   **低精度與上下文**：專家權重採用 FP4，設置 FP8 量化以降低成本，但需驗證精度變化；最大上下文窗口為 1048576 token，但容量不等於能準確利用每一個細節。
    *   **參考實現 vs 生產服務**：公開代碼為參考實現，非生產級引擎，未優化吞吐和調度，長期服務需處理請求排隊與資源分配。

4.  **應用設計與風險控制**：
    *   **分層架構建議**：在報銷單據、文檔整理與網頁測試等場景，建議採用「模型識別 + 規則驗證 + 人工覆核」的架構。
    *   **價值評估**：應關注「減少多少人工搬運」與「增加多少檢查成本」，局部可靠的能力比全能模型更有價值。
    *   **安全與隱私**：截圖可能包含敏感信息，需弄清楚資料去向；圖片中的文字可能夾帶指令注入風險，系統應分清材料和授權。

## 詳細大綱

### I. 發布背景與模型定位
*   **模型名稱**：Deepseek V4 Flash Vision EXP（EXP 代表實驗性質）。
*   **技術基礎**：基於 V4 Flash 架構，加入視覺模塊並繼續訓練。
*   **歷史背景**：Deepseek 此前在 Janus 系列已探索多模態，此次進展在於視覺模塊進入 V4 Flash 路線。
*   **開放內容**：Hugging Face 公開倉庫，包含權重、配置、參考推理代碼及提示編碼。

### II. 視覺能力的重要性與誤區
*   **現實工作需求**：大量信息（圖注、截圖、頁面佈局）無法僅通過文字傳達，需處理位置與關係。
*   **常見誤區**：
    *   不能將「Vision」等同於實時視頻、語音對話或圖片生成。
    *   不能僅憑「會看圖」就認為能解決所有問題。
    *   識別數字不等於理解圖表含義（單位、對象、預測值關係）。
*   **核心價值**：減少信息損失，避免文字流暢但事實關係錯誤的分析。

### III. 官方測試成績的深度解讀
*   **ApexBench (Pass@1)**：
    *   視覺實驗版 (36.5) > V4 Flash 0731 (26.2) > Opus 4.8 (39.4)。
    *   **關鍵腳注**：舊模型 (0731) 忽略了輸入中的多模態元素。
    *   **結論**：進步反映的是「完整系統獲得新輸入後的表現」，而非純推理能力在同等條件下的提升。
*   **Agents Last Exam**：
    *   視覺實驗版 (27.3) > 0731 (25.2) > Opus 4.8 (25.7)。
    *   **結論**：領先幅度有限，非壓倒性勝利。
*   **Chartography (專業圖表)**：
    *   視覺實驗版 (64.3) vs Opus 4.8 (65.0)。
    *   **結論**：成績接近，觸及業務難點（坐標標註、幾何關係），但不可直接等同於行業自動審批通過率。
*   **0Bench (多次嘗試)**：
    *   視覺實驗版 (35.0) > 對照模型 (34.0)。
    *   **結論**：考察「5次嘗試中至少成功1次」，不等於部署時系統能自動篩選正確答案，需人工驗證成本。
*   **文字任務影響**：
    *   新增視覺後，文字任務表現未受犧牲，反而高於對照分數。
*   **CyberGame (代碼/邏輯)**：
    *   視覺實驗版 (75.3) < 0731 (76.7) < Opus 4.8 (78.3)。
    *   **結論**：能力變化方向不同，不能選取上漲項目宣布全面升級。
*   **NL to Repo (自然語言轉代碼)**：
    *   視覺實驗版 (57.7) vs Opus 4.8 (69.7)，相差 12 個百分點。
    *   **結論**：差距明顯，其他項目領先無法補償此類任務的交付損失。
*   **測試條件限制**：
    *   使用 Deepseek Harness minimal 模式，最高推理強度，Temperature 1.0, Top P 0.95。
    *   成績是模型與運行框架的組合結果，換配置或縮短思考預算可能無法復現。

### IV. 技術架構與工程實現細節
*   **結構組成**：視覺編碼器（處理圖像）+ 對齊模塊（將視覺表示接入語言模型）。
*   **輸入處理鏈路**：
    *   圖片需經過尺寸和像素處理。
    *   公開了圖文提示編碼參考，支持圖像與文字交錯。
    *   **關鍵風險**：圖像順序對調（如修改前後界面比較）會導致模型答錯對象，需確保編碼階段保持對應關係。
*   **混合專家結構 (MoE)**：
    *   256 個路由專家，每個 token 選擇 6 個，含共享專家。
    *   **誤區**：不等於只需存儲被選中的專家，實際部署需處理全量權重及運行時資源。
    *   **Flash 含義**：表達產品路線，非硬件配置單，速度受硬件帶寬和推理實現影響。
*   **低精度設置**：
    *   專家權重 FP4，設置 FP8 量化。
    *   目標是降低存儲或計算負擔，但收益取決於實現與硬件支持，需驗證精度變化。
*   **上下文窗口**：
    *   最大位置數 1048576（約百萬 token）。
    *   **區分**：容量不等於能準確利用每一個細節。長報告中多頁圖表、不同口徑指標會增加混淆風險。
*   **參考實現 vs 生產服務**：
    *   代碼為參考實現，非生產服務引擎。
    *   生成循環為直接自回歸採樣，未優化吞吐和調度。
    *   接成長期服務需處理請求排隊、資源分配和失敗恢復。

### V. 應用場景與系統設計建議
*   **報銷單據處理**：
    *   模型提取候選字段，程序核對總額和日期格式，異常部分交给人。
    *   優勢：錯誤易於定位（金額、加總、審批原因）。
*   **文檔整理**：
    *   掃描件排版複雜、表格跨頁、圖注夾雜。
    *   優勢：減少轉純文字時的結構丟失。
    *   要求：保留頁碼與證據位置，便於回溯。
*   **網頁任務測試**：
    *   識別按鈕位置僅是起點，需觀察點擊後是否成功、是否有新確認步驟。
    *   視覺模型參與判斷屏幕內容，但不自動獲得付款權限。
    *   標準：可描述、可複查的要求，而非主觀的「看起來不夠好」。
*   **競爭標準**：
    *   價值應落在「減少多少人工搬運」與「增加多少檢查成本」。
    *   局部可靠的能力比全能模型更有價值。

### VI. 安全、隱私與成本結構
*   **數據隱私**：
    *   截圖可能包含帳號、個人身份、內部系統界面。
    *   上傳後進入新處理鏈，需弄清楚資料去向、記錄保留及故障排查時的複製情況。
    *   自行部署給予控制權，但不自動等於數據安全（需防止日誌記錄敏感圖片或管理權限未分開）。
*   **指令注入風險**：
    *   圖片中的文字可能夾帶試圖改變任務的指令。
    *   系統應分清材料和授權，約束模型能使用這些信息做什麼。
*   **成本結構變化**：
    *   自建服務需承擔計算資源、接入和日常運維。
    *   任務量少時機器空閒產生費用，任務突增需擴容。
    *   使用接口則有計費與服務依賴。
    *   **關鍵指標**：處理完一份達到要求的資料，總共花了多少資源和人工時間。
    *   便宜模型反覆答錯再讓專家補救，未必比一開始選擇合適方案省錢。

### VII. 生態接入與未來展望
*   **Openclaw 2.0**：
    *   發布說明將 Deepseek V4 Flash Vision 實驗模型列進模型發現更新。
    *   **意義**：周邊工具開始識別相關模型，但僅是發現與接入層面，需分別驗收「找得到」與「接上後持續交付」。
*   **社區反饋與驗證**：
    *   成功運行分享僅代表個人環境，失敗報告不能直接證明對所有人不可用。
    *   積累證據需清楚的版本、硬件條件、輸入及可重複結果。
*   **中文場景驗證**：
    *   官方成績表未披露簡體中文票據、繁體字截圖或中英混排文件的專項結果。
    *   錯誤可能發生在字符或對應關係，需單獨驗證。
    *   樣本應區分錯誤嚴重程度（如圖標題多一字 vs 金額小數點看錯）。
*   **最終結論**：
    *   發布的紮實意義在於讓 V4 路線補上可公開研究的視覺理解能力，並給出可討論優劣的測試與實現。
    *   部分項目顯示競爭力，其他項目仍有差距。
    *   實驗狀態、部署成本和業務可靠性應留在同一張判斷表里。
    *   只有真正把某一類工作做可靠了，開源發布才算兌現了價值。

## 工具 / 模型 / 名詞整理

*   **Deepseek V4 Flash Vision EXP**：Deepseek 發布的實驗性多模態模型完整名稱。
*   **Deepseek V4 Flash**：模型架構基礎。
*   **Deepseek V4**：模型家族名稱。
*   **Opus 4.8**：用於對照的閉源模型（逐字稿原文）。
*   **Janus 系列**：Deepseek 此前探索多模態理解與生成的系列。
*   **Hugging Face**：公開模型說明、權重及相關文件的倉庫平台。
*   **ApexBench**：測試基準之一，提及 Pass@1 成績。
*   **Agents Last Exam**：測試基準之一。
*   **Chartography**：關注專業圖表理解的測試基準。
*   **0Bench**：考察多次嘗試中至少成功一次的指標。
*   **CyberGame**：測試項目之一，涉及代碼或邏輯能力。
*   **NL to Repo**：自然語言轉代碼的測試項目。
*   **Deepseek Harness**：官方披露文字代理測試使用的框架，提及 minimal 模式。
*   **FP4**：專家權重的低精度設置。
*   **FP8**：量化信息設置。
*   **Openclaw 2.0**：發布說明中將 Deepseek 模型列進模型發現更新的周邊工具。
*   **MIT 許可證**：官方倉庫使用的開源許可證。

## 操作流程整理

1.  **模型接入與配置檢查**：
    *   從 Hugging Face 獲取 Deepseek V4 Flash Vision EXP 的權重、配置及參考推理代碼。
    *   檢查輸入處理鏈路，確保圖像與文字交錯的提示編碼正確。
    *   驗證硬件支持（如 FP4/FP8 量化效果）及混合專家結構（MoE）的資源分配。

2.  **輸入數據處理**：
    *   對圖像進行尺寸和像素處理。
    *   確保圖像順序與文字描述的對應關係（避免順序對調導致對象錯誤）。
    *   區分數據隱私，確認截圖中的帳號、身份或內部界面信息去向。

3.  **推理與驗證執行**：
    *   運行模型進行識別或生成（如圖表理解、代碼生成）。
    *   若為生產環境，需處理請求排隊、資源分配及失敗恢復（參考實現未優化吞吐）。
    *   對於複雜任務（如報銷、網頁測試），採用「模型識別 + 規則驗證 + 人工覆核」的分層架構。

4.  **結果評估與風險控制**：
    *   核對模型輸出是否符合業務規則（如總額、日期格式、按鈕點擊後狀態）。
    *   評估成本效益：計算處理單份資料的資源與人工時間，判斷是否比直接選擇合適方案更節省。
    *   監控指令注入風險，約束模型對圖片中夾帶信息的處理方式。

## 值得注意的限制或風險

1.  **測試成績的誤導性**：
    *   部分測試（如 ApexBench）舊模型未使用多模態輸入，新模型的進步主要反映「獲得新輸入後的表現變化」，而非純推理能力的絕對提升。
    *   測試基於特定框架（Deepseek Harness minimal 模式）和參數，換配置可能無法復現成績。
    *   在 NL to Repo 等任務上與閉源模型（Opus 4.8）仍有顯著差距。

2.  **工程部署現實**：
    *   公開代碼為參考實現，非生產級引擎，未優化吞吐和調度。
    *   混合專家結構需處理全量權重及運行時資源，不等於只需存儲被選中的專家。
    *   長上下文窗口（1048576 token）容量不等於能準確利用每一個細節，多頁圖表易增加混淆風險。

3.  **安全與隱私風險**：
    *   截圖可能包含敏感信息，自行部署需防止日誌記錄敏感圖片或管理權限未分開。
    *   圖片中的文字可能夾帶指令注入風險，試圖改變任務。
    *   數據上傳後進入新處理鏈，需弄清楚資料去向、記錄保留及故障排查時的複製情況。

4.  **成本與維護責任**：
    *   採用 MIT 許可證賦予控制權，但也要求使用者自行承擔數據隱私、版本維護與成本結構變化的責任。
    *   自建服務需承擔計算資源、接入和日常運維，任務突增需擴容。
    *   便宜模型反覆答錯再讓專家補救，未必比一開始選擇合適方案省錢。

## 逐字稿辨識疑點

*   **OPPO4.8 / Opus 4.8**：逐字稿中交替出現「OPPO4.8」與「Opus 4.8」。根據上下文（與 Deepseek 對照的閉源模型），「OPPO」極大可能是聽寫錯誤，但依規則標記為需查證，不得自行更正。
*   **apexbench**：逐字稿中出現「apexbench」與「ApexBench」，大小寫不一致，標記為需查證標準寫法。
*   **agents last exam**：逐字稿中出現「agents last exam」與「Agents Last Exam」，大小寫不一致，