告別後端伺服器：把六百萬位元組的 OCR 模型塞進瀏覽器，怎麼辦到的？

當一名開發者想在企業內部系統加上截圖自動轉文字（OCR）功能時，傳統做法需要在後端伺服器架設 Python 環境，配置 Flask 等網路框架，還得隨時盯著伺服器的記憶體用量與併發連線數。這套流程牽涉大量維運成本。近期在開發者社羣中，一套基於百度的 PaddleOCR 開源模型與瀏覽器端推理引擎的解決方案引起廣泛討論。這套做法讓文字辨識這項喫重的運算工作，直接在使用者的瀏覽器裡完成，完全省去後端伺服器的部署。這項技術轉變意味著前端網頁應用的能力邊界正在大幅度擴張。

要理解這件事的意義，得先看看 OCR 技術在軟體開發裡的傳統困境。光學字元辨識聽起來簡單，就是讓電腦看圖認字，但背後的運算邏輯非常複雜。過去幾年，雖然多模態大型語言模型也能做到看圖識字，但對於精確的排版還原、表格捕捉以及極小字體的辨識，專用 OCR 模型依然佔有準確率上的絕對優勢。

專用 OCR 模型如百度飛槳（PaddlePaddle）團隊開源的 PP-OCRv6，歷經多個版本的迭代，已經具備極高的輕量化與精準度。然而，要在企業內部系統或對外公開的網路服務中引入這套模型，開發者通常面臨兩難。第一種做法是呼叫第三方雲端 API，這會產生持續的費用，且涉及將使用者截圖上傳至外部伺服器的隱私疑慮。第二種做法是自行在後端部署模型，這需要配置具備強大運算能力的伺服器，並處理複雜的環境依賴與高併發時的系統承載量。對於許多中小型專案或企業內部工具而言，這兩種方法的維運成本都太高。

現在，開發者有了第三種選擇：把整個 OCR 流程搬進使用者的瀏覽器。這一切的技術基礎，建立在 ONNX Runtime Web 這套由微軟開源的瀏覽器端推理引擎之上。

網頁應用程式過去主要負責呈現視覺介面與處理簡單的使用者互動，複雜的數學運算都得交回後端伺服器處理。但隨著網頁技術標準的演進，現代瀏覽器已經能夠直接呼叫電腦主機裡的顯示卡（GPU）資源。ONNX Runtime Web 就是利用 WebGL 或更新的 WebGPU 技術，讓網頁裡的 JavaScript 程式碼能夠直接指揮使用者的顯示卡，執行深度學習模型的張量運算。

這套機制帶來的改變是根本性的。當一名使用者打開網頁，上傳一張需要辨識的截圖時，圖片資料不再需要透過網路上傳至遠端伺服器。取而代之的是，網頁會先從伺服器下載一份極度壓縮過的 OCR 模型檔案至使用者的裝置中。下載完成後，所有的圖片解碼、文字框尋找、字元辨識與排版還原工作，全部在使用者自己電腦的瀏覽器記憶體與 GPU 裡運作完畢。

以這次引發關注的 PP-OCRv6 為例，開發者選用了其中最為輕量的 tiny 系列模型。這組模型包含兩個檔案：負責找出文字位置的「文字檢測模型」與負責把圖片轉成文字的「文字識別模型」。檢測模型的參數量僅四十三萬，檔案大小約一點九百萬位元組；識別模型的參數量為一百一十萬，大小約四點四百萬位元組。兩個模型加起來的總體積只有六百萬位元組（6 MB）出頭。

對於現代網路環境而言，六百萬位元組的檔案下載時間幾乎可以忽略不計。這項技術選型徹底打破了過去「端側模型必定龐大且緩慢」的刻板印象。透過高度精密的模型量化與剪枝技術，百度飛槳團隊將一套能夠辨識四十九種語言、應付手寫字與各種彎曲排版的 OCR 系統，壓縮到了極其微小的體積。

要讓這套六百萬位元組的模型在瀏覽器裡發揮作用，開發者需要理解 OCR 的流水線運作邏輯。光學字元辨識從來都不是靠單一模型一次到位，而是由兩個不同的神經網路模型串聯協作。

第一階段稱為文本檢測。當使用者上傳圖片後，系統會先將圖片的長邊等比例縮放至九百六十像素以內。這個尺寸限制是為了配合模型內部的下採樣層，同時也是為了控制瀏覽器端的運算量。檢測模型接收這張圖片後，會輸出一張與原圖比例相同的「機率圖」。這張圖上的每一個像素，都代表該位置屬於文字的機率。

這時需要經過一系列後處理演算法。系統會將機率圖進行二值化，將機率高於零點二的像素標記為白色，其餘標記為黑色。接著透過廣度優先搜尋（BFS）演算法，把相鄰的白色像素連接成區域，這被稱為連通域標記。每一個連通域就是一個潛在的文字區塊。由於神經網路預測的邊界通常會比真實的文字略小，系統還會根據區域面積與周長的比例，向外擴張一點四倍的係數，確保文字筆畫完整被捕捉。最後，系統會過濾掉太小或可信度太低的區域，並根據座標的 Y 軸進行排序，還原人類閱讀的由上到下、由左到右順序。

第二階段則是文本識別。系統會將前一階段找出的每一個文字框裁切下來，統一縮放成高度為四十八像素的圖片，然後送入識別模型。這個模型具備處理簡體中文、繁體中文、英文、日文等多達四十九種語言的能力，還能應對豎排文字與生僻字。模型最後透過 CTC（聯結主義時間分類）解碼技術，將視覺特徵轉換成電腦可以編輯與搜尋的純文字字串。

對於使用者的隱私保護與企業的資料治理來說，這種純前端的技術架構帶來了極大的優勢。在講求資訊安全與隱私合規的當代數位環境裡，許多企業在處理包含敏感資訊的發票、合約截圖或內部表單時，極度排斥將這些資料傳輸至第三方雲端服務。過往開發者若要打造一個截圖轉文字的內部工具，往往需要經歷漫長的資安審核與網路架構調整。

現在，透過純前端的 ONNX Runtime Web 方案，使用者的圖片從頭到尾都不會離開他們的裝置。這項轉變與我們先前在地方教育體系的資料治理盲區探討的議題有異曲同工之妙。當資料不再需要集中上傳至單一伺服器進行處理，許多伴隨資料外洩風險與隱私爭議的治理困境便能從根源獲得緩解。運算能力下放至邊緣裝置，正在重塑軟體服務的資料流動邊界。

有趣的是，這套技術方案的成型，也仰賴了中國本土 AI 開源社羣基礎設施的成熟。在這次討論的案例中，開發者提及自己是透過魔搭（ModelScope）社羣平臺下載所需的 ONNX 模型檔案。魔搭作為一個匯聚眾多預訓練模型的開源模型庫，為開發者提供了穩定且高速的國內下載頻寬，解決了過去存取海外模型庫常見的網路延遲問題。

如果說模型與推理引擎是軟體層面的基礎設施，那麼前端工程師熟悉的開發工具鏈則是讓這項技術得以普及的推手。開發者可以透過 npm 或 bun 等現代化的套件管理工具，輕易將 onnxruntime-web 引入專案中。無論是使用 Vite 還是 Webpack 等建構工具，都能將其打包成標準的靜態檔案。這意味著導入瀏覽器端 OCR 的學習門檻大幅降低，前端開發者不需要重新學習複雜的後端部署邏輯，就能在現有的開發流程中無縫接軌這項人工智慧技術。

將複雜的深度學習模型塞進六百萬位元組的檔案，並讓它在瀏覽器環境裡流暢運行，展現了演算法優化與網頁標準演進的具體成果。這套由百度 PaddleOCR 與微軟 ONNX Runtime Web 共同支撐的前端架構，提供了一個兼顧效能、隱私與維運成本的務實方案。

當運算能力不再是大型伺服器的專屬特權，網頁應用程式將能提供更即時、更安全的離線服務。從單純的畫面呈現到承接繁重的 AI 推理任務，瀏覽器正在證明它作為通用運算平臺的能力。對於面臨功能需求與開發資源兩難的軟體團隊而言，將資料與運算留在使用者端的做法，無疑開啟了全新的產品設計與系統架構思考路徑。