題幹與適用場景
一個網頁應用希望在瀏覽器本地執行影像分類模型，減少上傳圖片的隱私風險和網路延遲。團隊考慮採用 2026 年 5 月的 W3C Web Neural Network API Candidate Recommendation Draft。該 API 以計算圖為核心，支援 CPU、GPU 和 NPU 等執行裝置；規範仍在演進，不能把候選推薦草案當成所有瀏覽器都已穩定支援的產品介面。
請從模型轉換、圖建構與編譯、推理執行、裝置選擇、回退和上線驗證完整回答。
面試官考察點
面試官觀察候選人是否理解「圖建構一次、執行多次」的生命週期，能否區分 MLGraphBuilder.build() 的非同步編譯與 MLContext.dispatch() 的非同步執行；是否把 WebNN 當成硬體無關抽象，而不是保證所有算子在所有裝置上效能一致的魔法層。
強回答會主動討論模型算子覆蓋、輸入輸出張量綁定、主執行緒阻塞、裝置能力探測、隱私與指紋風險、瀏覽器相容矩陣以及可撤銷的灰度策略。
回答前需要釐清的問題
- 模型是固定輸入尺寸，還是要支援動態形狀和多種精度？
- 目標瀏覽器和作業系統是否提供同一組算子與後端？
- 推理必須離線完成，還是允許安全地回退到伺服器？
- 目標是首屏速度、每幀延遲、吞吐、能耗還是隱私？
- 模型是否包含個人敏感影像，是否允許使用硬體能力作為指紋訊號？
30 秒回答框架
「我會把 WebNN 當作候選執行後端，先驗證模型算子和張量布局，再把圖建構與編譯移出每次推理路徑。編譯和 dispatch 都是非同步的，輸入輸出透過命名張量綁定。上線前按瀏覽器、裝置和模型版本建立相容矩陣；能力不足或編譯失敗時回退到 WebAssembly 或伺服器，並讓使用者知道資料邊界。效能評估同時測首輪編譯、穩態推理、記憶體、功耗和主執行緒回應，先小流量灰度並保留關閉開關。」
分步驟深入解答
先凍結模型契約
固定輸入尺寸、資料類型、布局、正規化、輸出標籤和精度容差。把模型轉換為 WebNN 支援的算子子圖；不支援的算子要在建構階段檢測，而不是等到使用者裝置上執行一半才失敗。保存一份可由 WebAssembly 或伺服器執行的參考實作，用於逐層結果對比。
建構並編譯計算圖
透過 navigator.ml 建立上下文和 MLGraphBuilder，用 input、常量和算子組合計算圖。build() 編譯圖並回傳 Promise；每個 builder 只應負責建構一個圖。把編譯放到預熱階段或 Worker 中，避免把首次編譯時間混入每次點擊的互動延遲。
const context = await navigator.ml.createContext({ deviceType: 'gpu' });
const builder = new MLGraphBuilder(context);
const input = builder.input('image', {
dataType: 'float32',
dimensions: [1, 224, 224, 3],
});
const weights = builder.constant(weightDescriptor, weightBuffer);
const logits = builder.conv2d(input, weights, convOptions);
const graph = await builder.build({ logits });範例中的裝置選項只是候選策略，不能假設每個實作接受完全相同的裝置值；實際程式應以目標瀏覽器實作和規範版本驗證。
設計非同步執行與記憶體路徑
dispatch() 把圖執行提交到執行時間線並立即返回。透過命名輸入和輸出張量綁定資料，執行結束後再讀取結果。重複推理應重用編譯後的圖、上下文和可重用緩衝區，避免每幀重新建立物件。對相機串流要設定背壓：上一幀未完成時丟棄或合併新幀，不能無限排隊。
處理裝置選擇與回退
先探測 API、算子和模型版本，再決定 CPU、GPU 或 NPU。裝置可用不代表目標算子高效；應以端到端測量選擇。回退鏈可以是 WebNN → WebAssembly → 伺服器，但每一級都要重用相同的預處理和結果校驗。伺服器回退涉及影像上傳，必須在 UI 和網路層明確告知，並遵守使用者同意與資料保留策略。
保持主執行緒與互動體驗
圖建構、編譯、預處理和結果後處理都可能影響互動。把重工作放入 Dedicated Worker，主執行緒只處理輸入採集和 UI 狀態；透過取消令牌或序號丟棄過期結果。不能只看平均推理時間，還要測長工作、輸入突發和頁面切到背景後的復原。
建立正確性與相容矩陣
按瀏覽器版本、作業系統、裝置類型、模型精度和算子集合建立矩陣。使用參考後端比較輸出誤差、分類準確率和邊界輸入；記錄編譯失敗、未實作算子、裝置遺失和上下文銷毀。W3C 規範仍是 Candidate Recommendation Draft，上線策略必須允許版本變化和實作差異。
處理隱私、權限與指紋風險
本地執行可減少影像上傳，但模型檔案、快取和遙測仍可能洩露資訊。只快取必要權重，限制日誌中的輸入特徵，不把裝置類型作為使用者識別。規範提醒裝置排程可能引入指紋訊號；因此能力探測結果應最小化、短時使用，並提供伺服器或軟體後端替代路徑。
灰度、觀測與回滾
先對非敏感模型和少量瀏覽器版本開啟，比較首輪編譯、穩態 P50/P95、主執行緒長工作、記憶體、能耗、失敗率和回退率。模型或瀏覽器升級時重新跑相容矩陣。發現裝置崩潰、準確率漂移、功耗過高或隱私邊界不滿足時，關閉 WebNN 開關並回退參考後端；保留版本、裝置和模型雜湊用於復盤。
高品質示範回答
「我會先凍結模型輸入輸出和誤差契約，再驗證算子是否能映射到 WebNN。圖只建構和編譯一次，build() 與 dispatch() 都按非同步流程處理，推理迴圈重用上下文和緩衝區。上線按瀏覽器、裝置和模型版本做能力矩陣，主執行緒只負責互動，Worker 承擔編譯和預處理。WebNN、WebAssembly、伺服器形成可觀測回退鏈；伺服器回退前明確影像上傳邊界。灰度階段測首輪與穩態延遲、長工作、記憶體、功耗、準確率和失敗率，發現問題立即關閉開關並保留參考實作。」
常見錯誤
- 把 Candidate Recommendation 當成普遍可用 → 瀏覽器或算子不相容 → 建立版本與能力矩陣。
- 每次請求重新編譯圖 → 首輪成本反覆出現 → 預熱並重用編譯後的圖。
- 只測 GPU 理想裝置 → CPU 或 NPU 路徑無法工作 → 對每個後端測端到端結果和成本。
- 把 dispatch 當成同步函式 → 主執行緒卡頓或結果順序錯亂 → 使用非同步狀態和序號。
- 無限排隊相機影格 → 延遲不斷累積 → 設定背壓，丟棄過期影格。
- 把裝置能力上報為使用者識別 → 增加指紋風險 → 最小化探測結果並提供軟體回退。
追問及應對
追問一：為什麼不直接用 WebGPU？
WebGPU 暴露更底層的資源和著色器控制，適合需要自訂算子或精細排程的團隊；WebNN 提供更高層的神經網路圖抽象，便於框架映射和跨硬體後端。選擇取決於算子覆蓋、團隊維護能力、效能目標和隱私邊界。
追問二：圖編譯十秒，如何避免使用者等待？
把模型和編譯放到 Worker，使用頁面閒置時間預熱並快取經過完整性校驗的權重。首輪仍不可用時顯示清晰狀態，並先走 WebAssembly 或伺服器回退；不能用假結果掩蓋編譯失敗。
追問三：GPU 結果偶爾與參考實作不同，怎麼辦？
先區分浮點捨入、精度轉換、算子實作差異和真正的模型錯誤。用固定輸入、逐層中間值和容差閾值重現；若誤差超過產品閾值，降級到另一後端並記錄瀏覽器、驅動和模型版本。
追問四：使用者拒絕上傳圖片，WebNN 又不可用怎麼辦？
提供本地 WebAssembly 或明確的不可用狀態，不繞過使用者選擇。產品可以降低模型複雜度或提供手動流程，但必須保持資料邊界透明。