現(xiàn)端側(cè)本地語(yǔ)義搜索的工程實(shí)踐)
前陣子我自己折騰一個(gè)移動(dòng)端的本地語(yǔ)義搜索功能翻來(lái)覆去對(duì)比了好幾種方案最終被一套組合拳吸引住了Flutter 做跨端殼子EmbeddingGemma 2 做端側(cè)向量化再加上所謂“完全本地化 AI Edge Foresight”的思路。這個(gè)組合讓我意識(shí)到端側(cè) AI 不再是 PPT 里的概念而是真的可以在手機(jī)里跑起來(lái)、并且跑得動(dòng)的工程實(shí)踐。這篇文章就圍繞這個(gè)項(xiàng)目標(biāo)題來(lái)拆一拆為什么選 Flutter為什么是 EmbeddingGemma 2以及所謂“AI Edge Foresight”到底解決什么問(wèn)題。文章不會(huì)去貼大段官方文檔而是按照我從零到一接入、踩坑、調(diào)優(yōu)的真實(shí)過(guò)程來(lái)講盡量把每個(gè)關(guān)鍵選擇背后的原因和推理鏈說(shuō)清楚給正在考慮同類方案的朋友一個(gè)可以直接落地的參考。1. 項(xiàng)目概述當(dāng) Flutter 遇上端側(cè)嵌入模型1.1 這個(gè)項(xiàng)目到底解決了什么問(wèn)題先聊需求場(chǎng)景?，F(xiàn)在很多 App 內(nèi)部都有大量非結(jié)構(gòu)化內(nèi)容比如用戶的筆記、收藏的文章、聊天記錄、商品評(píng)論甚至圖片的 OCR 文本。傳統(tǒng)做法是把這些內(nèi)容傳到云端讓服務(wù)器跑一次文本向量化然后存進(jìn)向量數(shù)據(jù)庫(kù)做檢索或聚類。但這么做有一個(gè)繞不開的坎隱私、延遲、離線能力。用戶并不希望自己的每一條日記都被上傳到服務(wù)器也不希望在地鐵上斷網(wǎng)的時(shí)候搜索框直接變成擺設(shè)。因此“端側(cè) AI”就成了一個(gè)很自然的方向把模型放到手機(jī)里把推理過(guò)程放在本地讓數(shù)據(jù)永遠(yuǎn)不出設(shè)備。這樣既解決了隱私合規(guī)的問(wèn)題又能在無(wú)網(wǎng)環(huán)境下繼續(xù)提供智能能力。這套項(xiàng)目標(biāo)題里提到的“AI Edge Foresight”從我理解的角度看并不是某個(gè)神秘的特定軟件包而是一種產(chǎn)品設(shè)計(jì)理念在設(shè)備邊緣提前對(duì)內(nèi)容做理解和預(yù)測(cè)從而在用戶發(fā)起請(qǐng)求前就準(zhǔn)備好一部分答案。它強(qiáng)調(diào)的是一種“預(yù)判式交互”。舉一個(gè)直觀的例子當(dāng)用戶正在輸入法里打了一半字本地模型已經(jīng)通過(guò)對(duì)已輸入文本的向量分析預(yù)判出下一個(gè)可能的實(shí)體或短語(yǔ)并提前把搜索結(jié)果準(zhǔn)備好。這個(gè)動(dòng)作如果放到云端去做光是網(wǎng)絡(luò)往返的時(shí)間就足以讓體驗(yàn)卡頓。但是如果完全用本地模型嵌入向量來(lái)做延遲可以被壓縮到幾十毫秒以內(nèi)用戶體驗(yàn)立刻就不一樣了。所以這個(gè)項(xiàng)目最核心的價(jià)值不是“又是一個(gè)模型”而是把模型的推理能力真正壓進(jìn)了移動(dòng)客戶端的執(zhí)行鏈路里。它解決的問(wèn)題是那些對(duì)隱私、離線、實(shí)時(shí)性要求都很高的場(chǎng)景。而 Flutter 的加入則是為了讓這套能力不必在 iOS 和 Android 上各寫一遍。你可以把 Flutter 理解為一套統(tǒng)一的外殼EmbeddingGemma 2 是殼里的“AI 引擎”二者結(jié)合之后跨平臺(tái)移動(dòng)應(yīng)用可以用一套 Dart 代碼調(diào)用完全本地化的語(yǔ)義理解能力。1.2 為什么偏偏是 Flutter 和 EmbeddingGemma 2說(shuō)實(shí)話一開始我也有點(diǎn)猶豫端側(cè) AI 不是有現(xiàn)成的 Core ML、ML Kit、MediaPipe 這些嗎為什么還要繞道 Flutter后來(lái)我把思路理清了如果你只做單端、只做 iOS那直接用蘋果自家的框架肯定更省事但如果你像我一樣需要同時(shí)覆蓋 Android 和 iOS還要在后期有可能擴(kuò)展到桌面端、嵌入式 Linux 設(shè)備Flutter 的多端一致性優(yōu)勢(shì)就非常關(guān)鍵。Flutter 的渲染引擎可以在各個(gè)平臺(tái)上保持一致的 UI 表現(xiàn)而通過(guò)平臺(tái)通道機(jī)制它能調(diào)用每一端的原生推理接口。換句話說(shuō)Flutter 不是來(lái)替代原生 AI 框架的而是來(lái)當(dāng)“總線”的把底層各種原生推理引擎統(tǒng)一封裝成一個(gè) Dart 層的調(diào)用接口。至于為什么選 EmbeddingGemma 2我當(dāng)時(shí)的判斷依據(jù)有幾個(gè)第一它的模型體積控制得不錯(cuò)適合移動(dòng)端集成第二它主打的是高質(zhì)量的文本嵌入向量也就是把一段文字映射成一串?dāng)?shù)值讓語(yǔ)義相近的內(nèi)容在向量空間里的位置也相近第三它設(shè)計(jì)上不是只能跑在云端框架里而是提供了輕量化、可量化的版本可以通過(guò)轉(zhuǎn)成 TFLite 或 ONNX 格式在端側(cè)運(yùn)行。用生活化的比喻來(lái)說(shuō)EmbeddingGemma 2 就像一臺(tái)小小的“語(yǔ)義翻譯機(jī)”把人類語(yǔ)言翻譯成機(jī)器能計(jì)算的數(shù)學(xué)坐標(biāo)。Flutter 則是連接這臺(tái)翻譯機(jī)和 App 界面的橋梁。再往深一層想這套組合還有一個(gè)隱性優(yōu)勢(shì)生態(tài)的延續(xù)性。Flutter 的 pub.dev 上已經(jīng)有不少機(jī)器學(xué)習(xí)插件的積累雖然質(zhì)量參差不齊但至少證明了社區(qū)在朝著“移動(dòng)端即 AI 運(yùn)行時(shí)”的方向走。EmbeddingGemma 2 雖然不是專為 Flutter 設(shè)計(jì)的但只要你愿意寫一層薄薄的橋接代碼就能把它變成 Flutter 工程里一個(gè)非常好用的能力組件。而且在實(shí)踐里我發(fā)現(xiàn)與其等某個(gè)現(xiàn)成的“全家桶插件”出現(xiàn)不如自己動(dòng)手封裝一套因?yàn)檫@樣可以完全控制線程調(diào)度、內(nèi)存釋放和緩存策略避免被第三方庫(kù)的隱藏設(shè)計(jì)卡住脖子。2. 核心細(xì)節(jié)解析EmbeddingGemma 2 的工作原理與落地要點(diǎn)2.1 嵌入模型到底是什么很多剛接觸的朋友會(huì)把“嵌入”和“生成式大模型”搞混。生成式模型是給你一句話讓它繼續(xù)寫后面的字而嵌入模型是給你一句話讓它輸出一串固定長(zhǎng)度的數(shù)字?jǐn)?shù)組。這串?dāng)?shù)組通常被稱為“向量”它的維度可能是 768、1024也可能是 2048具體取決于模型設(shè)計(jì)。向量的關(guān)鍵在于兩段語(yǔ)義相近的文本它們轉(zhuǎn)換出來(lái)的向量之間的距離會(huì)很近語(yǔ)義風(fēng)馬牛不相及的文本向量之間的距離會(huì)很遠(yuǎn)。這個(gè)特性讓嵌入模型可以非常自然地支撐搜索、分類、聚簇、去重、相似度推薦等任務(wù)。EmbeddingGemma 2 正是這一類模型。它的輸入是一段 tokenized 之后的文本輸出是一個(gè)向量表示。你可以把它看作是一個(gè)“編碼器”把語(yǔ)言的語(yǔ)義壓縮在一組浮點(diǎn)數(shù)中。和其他嵌入模型相比EmbeddingGemma 2 在開源生態(tài)里的一個(gè)優(yōu)勢(shì)是它不僅給出了模型權(quán)重還提供了相對(duì)清晰的部署示例和評(píng)測(cè)基準(zhǔn)方便使用者快速判斷它是否適合自己手頭的業(yè)務(wù)。另外一個(gè)值得注意的點(diǎn)是這一類模型雖然不能直接“說(shuō)話”但它的向量結(jié)果可以被很多傳統(tǒng)機(jī)器學(xué)習(xí)算法直接使用例如余弦相似度計(jì)算、K-Means 聚類、PCA 降維可視化、甚至訓(xùn)練一個(gè)簡(jiǎn)單的邏輯回歸分類器。實(shí)際使用中我發(fā)現(xiàn)很多人會(huì)走入一個(gè)誤區(qū)以為嵌入模型越強(qiáng)越好于是把模型換成更大的版本。但端側(cè)場(chǎng)景恰恰相反模型體積和推理延遲的增長(zhǎng)會(huì)以非線性方式吃掉硬件資源。以我自己的測(cè)試數(shù)據(jù)為例在單臺(tái)中端 Android 設(shè)備上運(yùn)行一個(gè)約 300MB 的嵌入模型單次推理耗時(shí)可能在 80 到 150 毫秒之間而換成一個(gè)量化后不到 100MB 的模型單次推理能降到 30 到 60 毫秒。對(duì)于絕大多數(shù)移動(dòng)端語(yǔ)義搜索、內(nèi)容分類場(chǎng)景多出來(lái)的這百分之幾的精度差異遠(yuǎn)沒(méi)有低延遲和低內(nèi)存占用重要。所以在端側(cè)選嵌入模型的標(biāo)準(zhǔn)不是“最高精度”而是“在預(yù)算范圍內(nèi)的夠用精度”。2.2 關(guān)鍵參數(shù)與向量化實(shí)踐要正確使用 EmbeddingGemma 2有幾個(gè)參數(shù)和概念必須先理清楚。首先是輸入長(zhǎng)度限制。嵌入模型通常不能接收無(wú)限長(zhǎng)的文本一般會(huì)截?cái)嗟?512 或 1024 個(gè) token。如果你的業(yè)務(wù)需要處理超長(zhǎng)文本就必須做分段處理比如按句子、按段落切分然后分別生成向量再通過(guò)平均池化或者加權(quán)合并的方式得到文檔級(jí)向量。我在一個(gè)實(shí)際項(xiàng)目里處理用戶日記時(shí)就是這么干的先按 300 字左右切段每段單獨(dú)向量化再把這些向量加起來(lái)做歸一化最后得到的向量用于全文檢索。這樣做的好處是即使某一段提到關(guān)鍵實(shí)體也不會(huì)被過(guò)長(zhǎng)的上下文稀釋掉。其次是歸一化。很多建模小白在第一次接嵌入模型時(shí)拿到的向量直接就去算點(diǎn)積結(jié)果發(fā)現(xiàn)分?jǐn)?shù)不穩(wěn)定。這是因?yàn)槟Ｐ洼敵龅南蛄磕ｉL(zhǎng)差異較大導(dǎo)致同一條樣本在不同批次之間的點(diǎn)積數(shù)值波動(dòng)明顯。正確做法是先做 L2 歸一化也就是把向量的模長(zhǎng)變成 1然后再算余弦相似度。歸一化之后的向量之間計(jì)算余弦相似度其實(shí)就等于計(jì)算點(diǎn)積。這個(gè)細(xì)節(jié)平時(shí)不顯眼但它直接決定了你存的向量數(shù)據(jù)的質(zhì)量也會(huì)影響后續(xù)聚類、閾值判斷的穩(wěn)定性。第三是批處理策略。在端側(cè)由于 CPU 或 NPU 的資源有限一次性塞入大量文本會(huì)導(dǎo)致內(nèi)存峰值飆升。最佳實(shí)踐是控制批次大小例如每次最多處理 8 個(gè)句子處理完立即釋放結(jié)果并回收臨時(shí)張量。還可以把不同優(yōu)先級(jí)的任務(wù)分開用戶正在輸入的關(guān)鍵詞走實(shí)時(shí)推理通道后臺(tái)批量同步的歷史內(nèi)容走另一個(gè)更慢但更穩(wěn)定的隊(duì)列。我自己的做法是維護(hù)一個(gè) Dart 層面的異步隊(duì)列按優(yōu)先級(jí)調(diào)度任務(wù)底層原生推理接口只負(fù)責(zé)單條或小批量計(jì)算上層通過(guò)并發(fā)控制來(lái)保證 UI 不卡頓。還有一個(gè)容易被忽略的點(diǎn)嵌入模型對(duì)文本的預(yù)處理方式也會(huì)影響結(jié)果。比如是否要保留標(biāo)點(diǎn)、是否需要小寫化、是否需要去除停用詞這些操作看似簡(jiǎn)單但會(huì)直接影響 tokenizer 的切分效果。EmbeddingGemma 2 自帶了一套推薦的分詞方式實(shí)際接入時(shí)盡量復(fù)用它的分詞器不要自己另外搞一套文本清洗管道否則容易出現(xiàn)“你以為模型理解的是這個(gè)意思其實(shí)模型看到的是一堆被打亂的碎片”的情況。2.3 端側(cè)部署的模型壓縮與量化把 EmbeddingGemma 2 放到手機(jī)里不能直接塞原始權(quán)重文件。原始模型大小可能在幾百 MB 量級(jí)App 包體根本吃不消。所以第一步就是做量化。量化的本質(zhì)是把模型里的 32 位浮點(diǎn)參數(shù)變成 8 位整數(shù)甚至 4 位整數(shù)從而用更少的比特存儲(chǔ)同一個(gè)參數(shù)。量化之后模型體積通常能縮小到原來(lái)的四分之一到三分之一推理速度也會(huì)因?yàn)閮?nèi)存訪問(wèn)量下降而變快。代價(jià)是精度會(huì)有少量損失但嵌入模型通常對(duì)量化不算太敏感因?yàn)橄蛄孔罱K還要經(jīng)過(guò)歸一化和相似度計(jì)算輕微的數(shù)值偏移會(huì)被后處理過(guò)程抹平一部分。我實(shí)測(cè)了兩種量化路徑一種是把模型轉(zhuǎn)成 TensorFlow Lite 格式并使用其內(nèi)置的 post-training dynamic range quantization另一種是轉(zhuǎn)成 ONNX Runtime 可以讀取的 int8 量化模型。在一個(gè) Flutter 工程里TFLite 路徑有一個(gè)明顯優(yōu)勢(shì)官方提供了 flutter 插件可以直接加載 .tflite 文件并執(zhí)行推理。不過(guò)它也有一個(gè)坑如果模型包含某些特殊算子比如復(fù)雜的注意力機(jī)制變體轉(zhuǎn)換工具可能會(huì)拒絕導(dǎo)出這時(shí)候就需要手動(dòng)替換算子或者改用 ONNX Runtime。我的平衡策略是優(yōu)先用 TFLite遇到兼容性問(wèn)題再切 ONNX Runtime不在一棵樹上吊死。模型壓縮之外還要考慮初始化時(shí)間。App 冷啟動(dòng)時(shí)如果立刻加載一個(gè)大模型用戶會(huì)明顯感覺(jué)到啟動(dòng)變慢。我的做法是把模型加載放到后臺(tái)線程并且結(jié)合內(nèi)存映射技術(shù)讓模型文件不必一次性全部讀入內(nèi)存。在 Android 上可以用 mmap 的方式加載模型文件在 iOS 上則可以通過(guò) Core ML 的分層加載機(jī)制來(lái)減少初始化開銷。這一步做完之后冷啟動(dòng)時(shí)間可以從原來(lái)的兩三秒降到一秒以內(nèi)已經(jīng)接近用戶可接受的范圍了。3. 實(shí)操過(guò)程Flutter 接入 EmbeddingGemma 2 的完整鏈路3.1 環(huán)境準(zhǔn)備與依賴引入開始動(dòng)手前先把工程結(jié)構(gòu)想明白。我的 Flutter 項(xiàng)目采用標(biāo)準(zhǔn)的分層設(shè)計(jì)Dart 層負(fù)責(zé)業(yè)務(wù)邏輯和 UI 狀態(tài)管理底層是一個(gè)自定義插件負(fù)責(zé)和原生推理引擎通信。這個(gè)插件內(nèi)部再拆成兩部分一部分是 Android 端的 TFLite 推理代碼或 ONNX Runtime 推理代碼另一部分是 iOS 端的 Core ML 封裝。為了讓兩端的調(diào)用接口保持一致我在原生層定義了一個(gè)統(tǒng)一方法入?yún)⑹俏谋咀址团渲脜?shù)出參是浮點(diǎn)數(shù)組或批量的浮點(diǎn)數(shù)組。在 pubspec.yaml 里我引入了幾個(gè)關(guān)鍵依賴flutter_platform_channel 負(fù)責(zé)跨端通道tflite_flutter 用于加載 TFLite 模型path_provider 用于管理模型文件的本地路徑shared_preferences 用來(lái)存一些緩存元信息。如果后續(xù)要上復(fù)雜度更高的任務(wù)比如把向量的存儲(chǔ)和管理也搬到本地?cái)?shù)據(jù)庫(kù)可以再加 drift 或者 sqflite。不過(guò)第一次接入時(shí)不建議一次塞太多東西先把最小鏈路跑通再逐步擴(kuò)展。模型文件的管理也值得單獨(dú)說(shuō)。模型文件不能直接放在 assets 目錄然后指望它被一次性加載尤其是幾個(gè)百 MB 的大文件打包時(shí)會(huì)對(duì)安裝包體積造成很大壓力。我的建議是把模型文件作為獨(dú)立下載資源處理App 首次啟動(dòng)時(shí)通過(guò)網(wǎng)絡(luò)下載模型文件到應(yīng)用私有目錄如果已經(jīng)存在則直接使用。這樣可以讓首次安裝包體小很多也方便后續(xù)模型升級(jí)。下載的校驗(yàn)必不可少我一般會(huì)在后端接口里同時(shí)下發(fā)模型文件的 MD5 值A(chǔ)pp 側(cè)在下載完成后做校驗(yàn)不一致就重新下載。3.2 調(diào)用本機(jī)推理的完整鏈路下面直接給出一段我在 Dart 層封裝的推理調(diào)用示例。先看方法簽名FutureListdouble embed(String text) async { final result await _channel.invokeMethod(embedText, { text: text, maxTokens: 512, normalize: true, }); return Listdouble.from(result as List); }對(duì)應(yīng)的原生 Android 側(cè)在 MethodChannel 的 handler 里執(zhí)行 TFLite 的 run 方法。核心代碼邏輯大致是這樣的override fun onMethodCall(call: MethodCall, result: Result) { when (call.method) { embedText - { val text call.argumentString(text) val maxTokens call.argumentInt(maxTokens) ?: 512 val normalize call.argumentBoolean(normalize) ?: true try { val output embeddingService.embed(text, maxTokens, normalize) result.success(output) } catch (e: Exception) { result.error(EMBED_ERROR, e.localizedMessage, null) } } else - result.notImplemented() } }TFLite 這邊我推薦直接使用 tflite_flutter 的 Interpreter因?yàn)樗鼉?nèi)部已經(jīng)處理了很多復(fù)雜的內(nèi)存管理問(wèn)題。在初始化 Interpreter 時(shí)需要把模型文件路徑傳進(jìn)去同時(shí)指定線程數(shù)。線程數(shù)不建議直接拉滿因?yàn)橐苿?dòng)端 CPU 的核心數(shù)有限盲目調(diào)大線程數(shù)反而會(huì)因?yàn)榫€程切換開銷導(dǎo)致性能下降。我在中端設(shè)備上測(cè)試4 線程通常是最優(yōu)解在旗艦設(shè)備上 6 線程反而表現(xiàn)更好。這個(gè)參數(shù)值得做幾次對(duì)比實(shí)驗(yàn)不同機(jī)型的差異會(huì)超出你想象。iOS 端的封裝思路也類似區(qū)別在于底層換成了 Core ML。我會(huì)先把模型轉(zhuǎn)成 Core ML 格式然后通過(guò) IOService 創(chuàng)建預(yù)測(cè)對(duì)象。由于 Core ML 對(duì)輸入的預(yù)處理也有要求我一般會(huì)在原生層完成 tokenizer 和 padding 操作確保喂給模型的輸入矩陣形狀正確。整個(gè)鏈路的完整性可以用一個(gè)流程來(lái)描述Dart 層拿到統(tǒng)一接口之后先做文本長(zhǎng)度判斷如果超長(zhǎng)則作分段分段結(jié)果逐段通過(guò) MethodChannel 發(fā)送給原生層原生層把文本交給模型執(zhí)行推理拿到一組向量后再返回給 Dart 層Dart 層對(duì)向量做歸一化和相似度計(jì)算。每一步的數(shù)據(jù)傳遞都是標(biāo)準(zhǔn) JSON 可序列化的結(jié)構(gòu)所以調(diào)試起來(lái)也非常方便。3.3 性能優(yōu)化與內(nèi)存管理端側(cè)推理最怕兩件事卡頓和內(nèi)存暴漲?？D的源頭往往不在模型本身而在線程調(diào)度。Flutter 的 UI 線程和后臺(tái)線程之間如果頻繁切換會(huì)引發(fā)不必要的上下文切換開銷。最有效的做法是讓推理全程保持在原生層后臺(tái)線程Dart 層只負(fù)責(zé)發(fā)起請(qǐng)求和接收結(jié)果不做任何密集計(jì)算。Dart 的 Future 本身就是異步模型配合原生層的 Handler 或 DispatchQueue可以做到“UI 無(wú)感知”的推理。內(nèi)存管理方面有一個(gè)容易被忽略的細(xì)節(jié)TFLite 的 Interpreter 每次執(zhí)行完成后會(huì)保留一些中間張量緩存。如果你反復(fù)創(chuàng)建新的 Interpreter 對(duì)象內(nèi)存就會(huì)像滾雪球一樣漲起來(lái)。正確做法是把 Interpreter 設(shè)計(jì)成單例整個(gè) App 生命周期內(nèi)只初始化一次。需要處理不同模型時(shí)可以準(zhǔn)備一個(gè) ModelManager 類按需加載和釋放而不是每次調(diào)用都新建。還有一個(gè)跟垃圾回收相關(guān)的問(wèn)題。Dart 把 List 傳遞給原生層時(shí)會(huì)發(fā)生內(nèi)存拷貝。如果文本批次很大拷貝開銷會(huì)非常明顯。我的優(yōu)化方案是使用 Float32List 這類 TypedData 類型減少裝箱和拷貝成本。原生層返回值時(shí)也盡量使用 Float32Array 之類的緊湊類型而不是 List 或 NSArray這樣可以在通道傳輸時(shí)直接復(fù)用底層內(nèi)存減少一次轉(zhuǎn)換。在設(shè)備發(fā)熱問(wèn)題上我也做了一些取舍。長(zhǎng)時(shí)間連續(xù)調(diào)用模型手機(jī)會(huì)明顯升溫尤其是舊款設(shè)備。我的策略是增加一個(gè)冷卻機(jī)制連續(xù)推理一定次數(shù)后自動(dòng)暫停隊(duì)列并等待幾秒同時(shí)把模型的頻率限制在一個(gè)合理水平。這種限制對(duì)交互型應(yīng)用來(lái)說(shuō)影響不大但對(duì)后臺(tái)批量索引任務(wù)來(lái)說(shuō)非常關(guān)鍵否則會(huì)因?yàn)檫^(guò)熱降頻反而拖慢整體速度。4. 應(yīng)用場(chǎng)景拆解AI Edge Foresight 能做什么4.1 語(yǔ)義搜索與本地知識(shí)庫(kù)把這個(gè)組合用在本地語(yǔ)義搜索上是第一個(gè)讓人眼前一亮的效果。傳統(tǒng)的關(guān)鍵詞搜索只能匹配字面相同的詞比如用戶搜“貓咪”搜不到“貓貓”。但嵌入模型把兩邊都轉(zhuǎn)成向量之后語(yǔ)義上相近的內(nèi)容可以很輕松地被召回。實(shí)際做項(xiàng)目的時(shí)候我在本地用 SQLite 存了向量數(shù)據(jù)和原始文本然后通過(guò)余弦相似度來(lái)排序效果比用 LIKE 查詢好了一個(gè)量級(jí)。SQLite 本身沒(méi)有向量索引但數(shù)據(jù)量在萬(wàn)級(jí)以內(nèi)時(shí)線性掃描幾萬(wàn)條向量的耗時(shí)也就是幾十毫秒完全夠用。如果數(shù)據(jù)量到了十萬(wàn)級(jí)就可以引入本地向量索引例如先聚類再檢索避免每一次都全表掃描。這里要特別強(qiáng)調(diào)一下召回與排序的區(qū)分。EmbeddingGemma 2 生成向量只負(fù)責(zé)“召回”也就是從庫(kù)里找出候選內(nèi)容而最終的排序往往需要結(jié)合其他業(yè)務(wù)規(guī)則比如時(shí)間權(quán)重、用戶偏好、內(nèi)容熱度。千萬(wàn)不要指望一個(gè)向量模型把所有排序問(wèn)題都解決掉。我自己的實(shí)現(xiàn)是兩階段第一階段用向量相似度召回 Top 50第二階段用一套輕量級(jí)打分公式把時(shí)間衰減、點(diǎn)擊反饋、手動(dòng)置頂?shù)纫蛩丶舆M(jìn)去得到最終 Top 10。這套思路在工程上非常好擴(kuò)展也更容易解釋給產(chǎn)品同學(xué)聽。另外在無(wú)網(wǎng)條件下端側(cè)語(yǔ)義搜索的價(jià)值會(huì)被徹底放大。比如在地鐵、飛機(jī)、國(guó)外漫游沒(méi)有流量的時(shí)候用戶依然可以檢索自己的本地筆記、收藏夾、通訊錄。這種能力不是云端方案的簡(jiǎn)化版而是一種全新維度的產(chǎn)品體驗(yàn)。我自己在飛機(jī)上實(shí)測(cè)過(guò)離線狀態(tài)下全文檢索加上本地語(yǔ)義糾錯(cuò)響應(yīng)速度反而比在線搜索更快因?yàn)闆](méi)有網(wǎng)絡(luò)包的封裝、排隊(duì)、傳輸和解析過(guò)程。4.2 內(nèi)容理解與分類打標(biāo)除了搜索內(nèi)容理解是 EmbeddingGemma 2 的第二個(gè)殺手锏。在很多本地筆記類 App 里用戶需要自動(dòng)把筆記分到“工作”、“生活”、“學(xué)習(xí)”等等級(jí)分類中。傳統(tǒng)做法是維護(hù)一個(gè)關(guān)鍵詞詞表然后做規(guī)則匹配但遇到“周末去圖書館看了本關(guān)于營(yíng)銷的書”這種句子規(guī)則匹配很容易失效。向量化之后你可以先用少量標(biāo)注樣本給每個(gè)類別生成一個(gè)“類別原型向量”然后對(duì)待分類文本的向量和類別原型向量做相似度比較選最高的那個(gè)作為預(yù)測(cè)類別。這個(gè)方案不僅輕量而且可解釋性也不錯(cuò)因?yàn)槊總€(gè)類別的原型向量可以可視化出來(lái)方便業(yè)務(wù)同學(xué)理解模型劃分的內(nèi)在邏輯。實(shí)際實(shí)施時(shí)我發(fā)現(xiàn)類別原型向量如果只用少量樣本生成容易有偏差。更好的做法是給每個(gè)類別收集幾十條典型樣本分別向量化然后求平均。類別數(shù)量越多原型向量之間的分界面就越復(fù)雜此時(shí)可以在向量之上再接一個(gè)輕量級(jí)分類器比如邏輯回歸或決策樹。模型本身依然跑在端側(cè)分類器參數(shù)也內(nèi)置在本地文件里整個(gè)過(guò)程仍然可以完全離線完成。這樣既保留了端側(cè)的低延遲也在精度上比簡(jiǎn)單的原型匹配高不少。這個(gè)能力還有一個(gè)延伸應(yīng)用給內(nèi)容做“新鮮度”判斷。對(duì)于新聞?lì)?App用戶希望第一時(shí)間看到新事件對(duì)于知識(shí)庫(kù)用戶可能更看重經(jīng)典內(nèi)容。通過(guò)把時(shí)間信息轉(zhuǎn)化成一種權(quán)重特征再和文本向量拼接就能訓(xùn)練出一個(gè)端側(cè)的小型排序模型。這種方式比純粹用規(guī)則靈活很多因?yàn)樗軌蜃詣?dòng)從用戶的點(diǎn)擊行為中學(xué)習(xí)到底哪些內(nèi)容對(duì)當(dāng)前用戶來(lái)說(shuō)是“新鮮且有用”的。當(dāng)然端側(cè)的個(gè)性化學(xué)習(xí)不能做得太重一般我會(huì)采用每隔一段時(shí)間下載一次增量權(quán)重的方式而不是在設(shè)備上實(shí)時(shí)訓(xùn)練。4.3 個(gè)性化推薦與異常檢測(cè)再往下聊就得說(shuō) AI Edge Foresight 里那個(gè)“Foresight”了。所謂預(yù)判能力我的理解是把用戶的歷史行為向量化然后預(yù)測(cè)下一步可能的意圖。舉個(gè)典型的例子用戶在一個(gè)閱讀類 App 里連續(xù)看了三篇關(guān)于“裝修風(fēng)格”的文章端側(cè)模型就可以提前把“北歐風(fēng)”、“收納”、“采光設(shè)計(jì)”等相關(guān)話題的文章向量加載到本地緩存里等用戶真正搜索時(shí)這些候選已經(jīng)處于“熱備”狀態(tài)點(diǎn)擊即可出現(xiàn)在結(jié)果前列。這個(gè)預(yù)判過(guò)程完全發(fā)生在本地不需要把用戶的閱讀歷史上傳到服務(wù)端隱私邊界非常清晰。異常檢測(cè)是另一個(gè)容易被忽視的場(chǎng)景。比如本地照片應(yīng)用可以用文本向量對(duì)照片備注和 GPS 信息做聚類當(dāng)出現(xiàn)一個(gè)偏離用戶常規(guī)軌跡的聚類時(shí)比如突然出現(xiàn)了大量同一地點(diǎn)的照片可以觸發(fā)一次遷移學(xué)習(xí)或提示用戶整理相冊(cè)。這個(gè)功能聽起來(lái)不算“硬核”但恰恰是端側(cè) AI 的優(yōu)勢(shì)所在它可以持續(xù)地、靜默地在后臺(tái)工作不用在意網(wǎng)絡(luò)可用性也不會(huì)因?yàn)槊看螖?shù)據(jù)上傳而消耗用戶的電量。我自己的體會(huì)是AI Edge Foresight 并不強(qiáng)調(diào)模型本身有多“聰明”而是強(qiáng)調(diào)系統(tǒng)對(duì)用戶意圖的響應(yīng)速度。它像是給 App 裝了一雙“近視眼鏡”能看清用戶手邊的內(nèi)容而不需要每次都抬頭望云端。從產(chǎn)品維度來(lái)說(shuō)離線可用、隱私安全、毫秒級(jí)預(yù)測(cè)這三點(diǎn)結(jié)合起來(lái)才是這套架構(gòu)真正的護(hù)城河。5. 常見問(wèn)題與排查實(shí)錄5.1 模型加載失敗這個(gè)坑估計(jì)所有入坑端側(cè) AI 的朋友都踩過(guò)。現(xiàn)象是 App 啟動(dòng)后調(diào)用原生推理接口立刻拋出一個(gè)類似 “Failed to load model” 的異常。原因通常有兩個(gè)一是模型文件路徑不正確二是模型文件格式損壞。路徑不正確多半是因?yàn)?Flutter 的 assets 目錄在原生層的訪問(wèn)方式不同你需要先把 assets 文件復(fù)制到應(yīng)用私有目錄再傳給原生層不能直接把 “assets/xxx.tflite” 字符串給 Interpreter。我踩過(guò)一次很隱蔽的坑Android 的 assets 解壓時(shí)會(huì)把目錄結(jié)構(gòu)保留但 iOS 的 bundle 里路徑大小寫不敏感一旦文件名寫錯(cuò)大小寫模擬器上能跑真機(jī)上就崩。排查這類問(wèn)題我的建議是分三步走先確認(rèn)文件是否存在檢查文件大小是否正常再用一個(gè)最小的測(cè)試工程直接加載該模型排除 Flutter 層干擾最后檢查模型內(nèi)部是否有自定義算子。如果是自定義算子TFLite 解析時(shí)可能會(huì)報(bào) “Op not found”這時(shí)候就需要重新導(dǎo)出模型時(shí)把這些算子替換成標(biāo)準(zhǔn)算子。不要嫌麻煩多數(shù)模型加載問(wèn)題都是細(xì)節(jié)導(dǎo)致的。5.2 推理速度慢推理速度上不去最直接的原因通常是模型沒(méi)有量化或者設(shè)備沒(méi)有正確使用加速硬件。如果你在桌面級(jí)模擬器上跑得很流暢一到真機(jī)就慢得離譜那多半是原生推理引擎沒(méi)有使用 GPU 或 NPU 代理。TFLite 里可以使用 GPU delegate但并不是所有算子都能在 GPU 上執(zhí)行如果模型里存在不支持的算子TFLite 會(huì)自動(dòng)回退到 CPU而且回退過(guò)程會(huì)打印一行警告很容易被忽略。還有一個(gè)經(jīng)常被忽略的因素設(shè)備過(guò)熱后降頻。我有一臺(tái)測(cè)試機(jī)在連續(xù)跑五分鐘推理后單次推理耗時(shí)從 40ms 漲到了 90ms。后來(lái)我加入了散熱控制和推理任務(wù)分批機(jī)制情況才好轉(zhuǎn)。從架構(gòu)角度看推理性能調(diào)優(yōu)必須結(jié)合具體機(jī)型的算力特點(diǎn)去調(diào)不能只盯著模型本身。建議在實(shí)際測(cè)試時(shí)準(zhǔn)備幾臺(tái)覆蓋中端和旗艦的設(shè)備分別統(tǒng)計(jì)推理耗時(shí)和內(nèi)存占用形成一個(gè)基礎(chǔ)性能基線表。后續(xù)每一次模型版本升級(jí)都用同一組基線數(shù)據(jù)來(lái)做對(duì)比才能客觀判斷模型是不是變慢了。5.3 包體積爆炸這是 Flutter 應(yīng)用接端側(cè)模型最容易遇到的問(wèn)題。一個(gè) 100MB 的模型文件直接放進(jìn) assets打包后 APK 體積瞬間膨脹。解決方式在 3.1 已經(jīng)提過(guò)就是改成動(dòng)態(tài)下載。這里再補(bǔ)充兩個(gè)細(xì)節(jié)一是動(dòng)態(tài)下載需要考慮斷點(diǎn)續(xù)傳和網(wǎng)絡(luò)狀態(tài)變化建議使用后臺(tái)下載服務(wù)而不是簡(jiǎn)單用 HTTP 庫(kù)直接拉二是模型版本管理和 App 版本管理要解耦模型可以單獨(dú)發(fā)布升級(jí)不需要強(qiáng)制用戶升級(jí) App 才能獲得新模型。還有一個(gè)容易被忽視的體積隱患Flutter 插件本身可能引入一些不必要的原生庫(kù)。比如你為了跑 TFLite 引入了全套 TensorFlow Lite 支持庫(kù)其中包含了很多你用不到的算子包。這種情況下你可以通過(guò) Gradle 的 ABI 過(guò)濾只保留 arm64-v8a 架構(gòu)同時(shí)移除 x86_64 等不用的架構(gòu)安裝包能立刻瘦身不少。iOS 端則可以檢查是否引入了冗余的 bitcode 支持配合 Xcode 的編譯設(shè)置把不需要的架構(gòu)裁剪掉。6. 一些經(jīng)驗(yàn)體會(huì)折騰完這個(gè)項(xiàng)目我最深的感觸是端側(cè) AI 真正難的不是算法而是工程整合。Flutter 和 EmbeddingGemma 2 的組合本質(zhì)上是一次“跨端殼層 本地模型運(yùn)行時(shí)”的聯(lián)姻需要你同時(shí)懂 Dart 層的內(nèi)存管理、原生層的線程調(diào)度、模型轉(zhuǎn)換工具鏈的細(xì)節(jié)還要有耐心去一臺(tái)一臺(tái)真機(jī)上驗(yàn)證表現(xiàn)。沒(méi)有哪個(gè)環(huán)節(jié)是能靠讀文檔直接跳過(guò)的。如果讓我給出一個(gè)最想強(qiáng)調(diào)的建議那就是先把最小可用鏈路跑通再考慮性能優(yōu)化和功能擴(kuò)展。我見過(guò)太多人一上來(lái)就研究怎么把模型量化到 4bit、怎么上 NPU、怎么構(gòu)建多模態(tài)識(shí)別結(jié)果基礎(chǔ)通道都沒(méi)打通。先讓一句話進(jìn)入模型再收到一個(gè)像模像樣的向量這個(gè)正向反饋建立起來(lái)之后整個(gè)系統(tǒng)的復(fù)雜度曲線會(huì)變得非常清晰后面不管加什么功能都只是在這個(gè)鏈路上增加分支而已。最后再分享一個(gè)小技巧模型輸出的向量多留一份原始值做備份。端側(cè)模型升級(jí)后新舊向量之間可能出現(xiàn)空間偏移這時(shí)候如果保留舊版本向量可以做向量空間的對(duì)齊測(cè)試快速評(píng)估升級(jí)帶來(lái)的影響。這個(gè)小動(dòng)作不復(fù)雜但能在模型迭代時(shí)省下非常多排查時(shí)間。希望這篇文章能給正在琢磨 Flutter 加端側(cè)嵌入模型的朋友一些參考也歡迎大家在自己的項(xiàng)目里有更巧妙的實(shí)踐時(shí)回頭來(lái)互相印證。 Flutter + EmbeddingGemma 2 實(shí)現(xiàn)端側(cè)本地語(yǔ)義搜索的工程實(shí)踐
前陣子我自己折騰一個(gè)移動(dòng)端的本地語(yǔ)義搜索功能翻來(lái)覆去對(duì)比了好幾種方案最終被一套組合拳吸引住了Flutter 做跨端殼子EmbeddingGemma 2 做端側(cè)向量化再加上所謂“完全本地化 AI Edge Foresight”的思路。這個(gè)組合讓我意識(shí)到端側(cè) AI 不再是 PPT 里的概念而是真的可以在手機(jī)里跑起來(lái)、并且跑得動(dòng)的工程實(shí)踐。這篇文章就圍繞這個(gè)項(xiàng)目標(biāo)題來(lái)拆一拆為什么選 Flutter為什么是 EmbeddingGemma 2以及所謂“AI Edge Foresight”到底解決什么問(wèn)題。文章不會(huì)去貼大段官方文檔而是按照我從零到一接入、踩坑、調(diào)優(yōu)的真實(shí)過(guò)程來(lái)講盡量把每個(gè)關(guān)鍵選擇背后的原因和推理鏈說(shuō)清楚給正在考慮同類方案的朋友一個(gè)可以直接落地的參考。1. 項(xiàng)目概述當(dāng) Flutter 遇上端側(cè)嵌入模型1.1 這個(gè)項(xiàng)目到底解決了什么問(wèn)題先聊需求場(chǎng)景?，F(xiàn)在很多 App 內(nèi)部都有大量非結(jié)構(gòu)化內(nèi)容比如用戶的筆記、收藏的文章、聊天記錄、商品評(píng)論甚至圖片的 OCR 文本。傳統(tǒng)做法是把這些內(nèi)容傳到云端讓服務(wù)器跑一次文本向量化然后存進(jìn)向量數(shù)據(jù)庫(kù)做檢索或聚類。但這么做有一個(gè)繞不開的坎隱私、延遲、離線能力。用戶并不希望自己的每一條日記都被上傳到服務(wù)器也不希望在地鐵上斷網(wǎng)的時(shí)候搜索框直接變成擺設(shè)。因此“端側(cè) AI”就成了一個(gè)很自然的方向把模型放到手機(jī)里把推理過(guò)程放在本地讓數(shù)據(jù)永遠(yuǎn)不出設(shè)備。這樣既解決了隱私合規(guī)的問(wèn)題又能在無(wú)網(wǎng)環(huán)境下繼續(xù)提供智能能力。這套項(xiàng)目標(biāo)題里提到的“AI Edge Foresight”從我理解的角度看并不是某個(gè)神秘的特定軟件包而是一種產(chǎn)品設(shè)計(jì)理念在設(shè)備邊緣提前對(duì)內(nèi)容做理解和預(yù)測(cè)從而在用戶發(fā)起請(qǐng)求前就準(zhǔn)備好一部分答案。它強(qiáng)調(diào)的是一種“預(yù)判式交互”。舉一個(gè)直觀的例子當(dāng)用戶正在輸入法里打了一半字本地模型已經(jīng)通過(guò)對(duì)已輸入文本的向量分析預(yù)判出下一個(gè)可能的實(shí)體或短語(yǔ)并提前把搜索結(jié)果準(zhǔn)備好。這個(gè)動(dòng)作如果放到云端去做光是網(wǎng)絡(luò)往返的時(shí)間就足以讓體驗(yàn)卡頓。但是如果完全用本地模型嵌入向量來(lái)做延遲可以被壓縮到幾十毫秒以內(nèi)用戶體驗(yàn)立刻就不一樣了。所以這個(gè)項(xiàng)目最核心的價(jià)值不是“又是一個(gè)模型”而是把模型的推理能力真正壓進(jìn)了移動(dòng)客戶端的執(zhí)行鏈路里。它解決的問(wèn)題是那些對(duì)隱私、離線、實(shí)時(shí)性要求都很高的場(chǎng)景。而 Flutter 的加入則是為了讓這套能力不必在 iOS 和 Android 上各寫一遍。你可以把 Flutter 理解為一套統(tǒng)一的外殼EmbeddingGemma 2 是殼里的“AI 引擎”二者結(jié)合之后跨平臺(tái)移動(dòng)應(yīng)用可以用一套 Dart 代碼調(diào)用完全本地化的語(yǔ)義理解能力。1.2 為什么偏偏是 Flutter 和 EmbeddingGemma 2說(shuō)實(shí)話一開始我也有點(diǎn)猶豫端側(cè) AI 不是有現(xiàn)成的 Core ML、ML Kit、MediaPipe 這些嗎為什么還要繞道 Flutter后來(lái)我把思路理清了如果你只做單端、只做 iOS那直接用蘋果自家的框架肯定更省事但如果你像我一樣需要同時(shí)覆蓋 Android 和 iOS還要在后期有可能擴(kuò)展到桌面端、嵌入式 Linux 設(shè)備Flutter 的多端一致性優(yōu)勢(shì)就非常關(guān)鍵。Flutter 的渲染引擎可以在各個(gè)平臺(tái)上保持一致的 UI 表現(xiàn)而通過(guò)平臺(tái)通道機(jī)制它能調(diào)用每一端的原生推理接口。換句話說(shuō)Flutter 不是來(lái)替代原生 AI 框架的而是來(lái)當(dāng)“總線”的把底層各種原生推理引擎統(tǒng)一封裝成一個(gè) Dart 層的調(diào)用接口。至于為什么選 EmbeddingGemma 2我當(dāng)時(shí)的判斷依據(jù)有幾個(gè)第一它的模型體積控制得不錯(cuò)適合移動(dòng)端集成第二它主打的是高質(zhì)量的文本嵌入向量也就是把一段文字映射成一串?dāng)?shù)值讓語(yǔ)義相近的內(nèi)容在向量空間里的位置也相近第三它設(shè)計(jì)上不是只能跑在云端框架里而是提供了輕量化、可量化的版本可以通過(guò)轉(zhuǎn)成 TFLite 或 ONNX 格式在端側(cè)運(yùn)行。用生活化的比喻來(lái)說(shuō)EmbeddingGemma 2 就像一臺(tái)小小的“語(yǔ)義翻譯機(jī)”把人類語(yǔ)言翻譯成機(jī)器能計(jì)算的數(shù)學(xué)坐標(biāo)。Flutter 則是連接這臺(tái)翻譯機(jī)和 App 界面的橋梁。再往深一層想這套組合還有一個(gè)隱性優(yōu)勢(shì)生態(tài)的延續(xù)性。Flutter 的 pub.dev 上已經(jīng)有不少機(jī)器學(xué)習(xí)插件的積累雖然質(zhì)量參差不齊但至少證明了社區(qū)在朝著“移動(dòng)端即 AI 運(yùn)行時(shí)”的方向走。EmbeddingGemma 2 雖然不是專為 Flutter 設(shè)計(jì)的但只要你愿意寫一層薄薄的橋接代碼就能把它變成 Flutter 工程里一個(gè)非常好用的能力組件。而且在實(shí)踐里我發(fā)現(xiàn)與其等某個(gè)現(xiàn)成的“全家桶插件”出現(xiàn)不如自己動(dòng)手封裝一套因?yàn)檫@樣可以完全控制線程調(diào)度、內(nèi)存釋放和緩存策略避免被第三方庫(kù)的隱藏設(shè)計(jì)卡住脖子。2. 核心細(xì)節(jié)解析EmbeddingGemma 2 的工作原理與落地要點(diǎn)2.1 嵌入模型到底是什么很多剛接觸的朋友會(huì)把“嵌入”和“生成式大模型”搞混。生成式模型是給你一句話讓它繼續(xù)寫后面的字而嵌入模型是給你一句話讓它輸出一串固定長(zhǎng)度的數(shù)字?jǐn)?shù)組。這串?dāng)?shù)組通常被稱為“向量”它的維度可能是 768、1024也可能是 2048具體取決于模型設(shè)計(jì)。向量的關(guān)鍵在于兩段語(yǔ)義相近的文本它們轉(zhuǎn)換出來(lái)的向量之間的距離會(huì)很近語(yǔ)義風(fēng)馬牛不相及的文本向量之間的距離會(huì)很遠(yuǎn)。這個(gè)特性讓嵌入模型可以非常自然地支撐搜索、分類、聚簇、去重、相似度推薦等任務(wù)。EmbeddingGemma 2 正是這一類模型。它的輸入是一段 tokenized 之后的文本輸出是一個(gè)向量表示。你可以把它看作是一個(gè)“編碼器”把語(yǔ)言的語(yǔ)義壓縮在一組浮點(diǎn)數(shù)中。和其他嵌入模型相比EmbeddingGemma 2 在開源生態(tài)里的一個(gè)優(yōu)勢(shì)是它不僅給出了模型權(quán)重還提供了相對(duì)清晰的部署示例和評(píng)測(cè)基準(zhǔn)方便使用者快速判斷它是否適合自己手頭的業(yè)務(wù)。另外一個(gè)值得注意的點(diǎn)是這一類模型雖然不能直接“說(shuō)話”但它的向量結(jié)果可以被很多傳統(tǒng)機(jī)器學(xué)習(xí)算法直接使用例如余弦相似度計(jì)算、K-Means 聚類、PCA 降維可視化、甚至訓(xùn)練一個(gè)簡(jiǎn)單的邏輯回歸分類器。實(shí)際使用中我發(fā)現(xiàn)很多人會(huì)走入一個(gè)誤區(qū)以為嵌入模型越強(qiáng)越好于是把模型換成更大的版本。但端側(cè)場(chǎng)景恰恰相反模型體積和推理延遲的增長(zhǎng)會(huì)以非線性方式吃掉硬件資源。以我自己的測(cè)試數(shù)據(jù)為例在單臺(tái)中端 Android 設(shè)備上運(yùn)行一個(gè)約 300MB 的嵌入模型單次推理耗時(shí)可能在 80 到 150 毫秒之間而換成一個(gè)量化后不到 100MB 的模型單次推理能降到 30 到 60 毫秒。對(duì)于絕大多數(shù)移動(dòng)端語(yǔ)義搜索、內(nèi)容分類場(chǎng)景多出來(lái)的這百分之幾的精度差異遠(yuǎn)沒(méi)有低延遲和低內(nèi)存占用重要。所以在端側(cè)選嵌入模型的標(biāo)準(zhǔn)不是“最高精度”而是“在預(yù)算范圍內(nèi)的夠用精度”。2.2 關(guān)鍵參數(shù)與向量化實(shí)踐要正確使用 EmbeddingGemma 2有幾個(gè)參數(shù)和概念必須先理清楚。首先是輸入長(zhǎng)度限制。嵌入模型通常不能接收無(wú)限長(zhǎng)的文本一般會(huì)截?cái)嗟?512 或 1024 個(gè) token。如果你的業(yè)務(wù)需要處理超長(zhǎng)文本就必須做分段處理比如按句子、按段落切分然后分別生成向量再通過(guò)平均池化或者加權(quán)合并的方式得到文檔級(jí)向量。我在一個(gè)實(shí)際項(xiàng)目里處理用戶日記時(shí)就是這么干的先按 300 字左右切段每段單獨(dú)向量化再把這些向量加起來(lái)做歸一化最后得到的向量用于全文檢索。這樣做的好處是即使某一段提到關(guān)鍵實(shí)體也不會(huì)被過(guò)長(zhǎng)的上下文稀釋掉。其次是歸一化。很多建模小白在第一次接嵌入模型時(shí)拿到的向量直接就去算點(diǎn)積結(jié)果發(fā)現(xiàn)分?jǐn)?shù)不穩(wěn)定。這是因?yàn)槟Ｐ洼敵龅南蛄磕ｉL(zhǎng)差異較大導(dǎo)致同一條樣本在不同批次之間的點(diǎn)積數(shù)值波動(dòng)明顯。正確做法是先做 L2 歸一化也就是把向量的模長(zhǎng)變成 1然后再算余弦相似度。歸一化之后的向量之間計(jì)算余弦相似度其實(shí)就等于計(jì)算點(diǎn)積。這個(gè)細(xì)節(jié)平時(shí)不顯眼但它直接決定了你存的向量數(shù)據(jù)的質(zhì)量也會(huì)影響后續(xù)聚類、閾值判斷的穩(wěn)定性。第三是批處理策略。在端側(cè)由于 CPU 或 NPU 的資源有限一次性塞入大量文本會(huì)導(dǎo)致內(nèi)存峰值飆升。最佳實(shí)踐是控制批次大小例如每次最多處理 8 個(gè)句子處理完立即釋放結(jié)果并回收臨時(shí)張量。還可以把不同優(yōu)先級(jí)的任務(wù)分開用戶正在輸入的關(guān)鍵詞走實(shí)時(shí)推理通道后臺(tái)批量同步的歷史內(nèi)容走另一個(gè)更慢但更穩(wěn)定的隊(duì)列。我自己的做法是維護(hù)一個(gè) Dart 層面的異步隊(duì)列按優(yōu)先級(jí)調(diào)度任務(wù)底層原生推理接口只負(fù)責(zé)單條或小批量計(jì)算上層通過(guò)并發(fā)控制來(lái)保證 UI 不卡頓。還有一個(gè)容易被忽略的點(diǎn)嵌入模型對(duì)文本的預(yù)處理方式也會(huì)影響結(jié)果。比如是否要保留標(biāo)點(diǎn)、是否需要小寫化、是否需要去除停用詞這些操作看似簡(jiǎn)單但會(huì)直接影響 tokenizer 的切分效果。EmbeddingGemma 2 自帶了一套推薦的分詞方式實(shí)際接入時(shí)盡量復(fù)用它的分詞器不要自己另外搞一套文本清洗管道否則容易出現(xiàn)“你以為模型理解的是這個(gè)意思其實(shí)模型看到的是一堆被打亂的碎片”的情況。2.3 端側(cè)部署的模型壓縮與量化把 EmbeddingGemma 2 放到手機(jī)里不能直接塞原始權(quán)重文件。原始模型大小可能在幾百 MB 量級(jí)App 包體根本吃不消。所以第一步就是做量化。量化的本質(zhì)是把模型里的 32 位浮點(diǎn)參數(shù)變成 8 位整數(shù)甚至 4 位整數(shù)從而用更少的比特存儲(chǔ)同一個(gè)參數(shù)。量化之后模型體積通常能縮小到原來(lái)的四分之一到三分之一推理速度也會(huì)因?yàn)閮?nèi)存訪問(wèn)量下降而變快。代價(jià)是精度會(huì)有少量損失但嵌入模型通常對(duì)量化不算太敏感因?yàn)橄蛄孔罱K還要經(jīng)過(guò)歸一化和相似度計(jì)算輕微的數(shù)值偏移會(huì)被后處理過(guò)程抹平一部分。我實(shí)測(cè)了兩種量化路徑一種是把模型轉(zhuǎn)成 TensorFlow Lite 格式并使用其內(nèi)置的 post-training dynamic range quantization另一種是轉(zhuǎn)成 ONNX Runtime 可以讀取的 int8 量化模型。在一個(gè) Flutter 工程里TFLite 路徑有一個(gè)明顯優(yōu)勢(shì)官方提供了 flutter 插件可以直接加載 .tflite 文件并執(zhí)行推理。不過(guò)它也有一個(gè)坑如果模型包含某些特殊算子比如復(fù)雜的注意力機(jī)制變體轉(zhuǎn)換工具可能會(huì)拒絕導(dǎo)出這時(shí)候就需要手動(dòng)替換算子或者改用 ONNX Runtime。我的平衡策略是優(yōu)先用 TFLite遇到兼容性問(wèn)題再切 ONNX Runtime不在一棵樹上吊死。模型壓縮之外還要考慮初始化時(shí)間。App 冷啟動(dòng)時(shí)如果立刻加載一個(gè)大模型用戶會(huì)明顯感覺(jué)到啟動(dòng)變慢。我的做法是把模型加載放到后臺(tái)線程并且結(jié)合內(nèi)存映射技術(shù)讓模型文件不必一次性全部讀入內(nèi)存。在 Android 上可以用 mmap 的方式加載模型文件在 iOS 上則可以通過(guò) Core ML 的分層加載機(jī)制來(lái)減少初始化開銷。這一步做完之后冷啟動(dòng)時(shí)間可以從原來(lái)的兩三秒降到一秒以內(nèi)已經(jīng)接近用戶可接受的范圍了。3. 實(shí)操過(guò)程Flutter 接入 EmbeddingGemma 2 的完整鏈路3.1 環(huán)境準(zhǔn)備與依賴引入開始動(dòng)手前先把工程結(jié)構(gòu)想明白。我的 Flutter 項(xiàng)目采用標(biāo)準(zhǔn)的分層設(shè)計(jì)Dart 層負(fù)責(zé)業(yè)務(wù)邏輯和 UI 狀態(tài)管理底層是一個(gè)自定義插件負(fù)責(zé)和原生推理引擎通信。這個(gè)插件內(nèi)部再拆成兩部分一部分是 Android 端的 TFLite 推理代碼或 ONNX Runtime 推理代碼另一部分是 iOS 端的 Core ML 封裝。為了讓兩端的調(diào)用接口保持一致我在原生層定義了一個(gè)統(tǒng)一方法入?yún)⑹俏谋咀址团渲脜?shù)出參是浮點(diǎn)數(shù)組或批量的浮點(diǎn)數(shù)組。在 pubspec.yaml 里我引入了幾個(gè)關(guān)鍵依賴flutter_platform_channel 負(fù)責(zé)跨端通道tflite_flutter 用于加載 TFLite 模型path_provider 用于管理模型文件的本地路徑shared_preferences 用來(lái)存一些緩存元信息。如果后續(xù)要上復(fù)雜度更高的任務(wù)比如把向量的存儲(chǔ)和管理也搬到本地?cái)?shù)據(jù)庫(kù)可以再加 drift 或者 sqflite。不過(guò)第一次接入時(shí)不建議一次塞太多東西先把最小鏈路跑通再逐步擴(kuò)展。模型文件的管理也值得單獨(dú)說(shuō)。模型文件不能直接放在 assets 目錄然后指望它被一次性加載尤其是幾個(gè)百 MB 的大文件打包時(shí)會(huì)對(duì)安裝包體積造成很大壓力。我的建議是把模型文件作為獨(dú)立下載資源處理App 首次啟動(dòng)時(shí)通過(guò)網(wǎng)絡(luò)下載模型文件到應(yīng)用私有目錄如果已經(jīng)存在則直接使用。這樣可以讓首次安裝包體小很多也方便后續(xù)模型升級(jí)。下載的校驗(yàn)必不可少我一般會(huì)在后端接口里同時(shí)下發(fā)模型文件的 MD5 值A(chǔ)pp 側(cè)在下載完成后做校驗(yàn)不一致就重新下載。3.2 調(diào)用本機(jī)推理的完整鏈路下面直接給出一段我在 Dart 層封裝的推理調(diào)用示例。先看方法簽名FutureListdouble embed(String text) async { final result await _channel.invokeMethod(embedText, { text: text, maxTokens: 512, normalize: true, }); return Listdouble.from(result as List); }對(duì)應(yīng)的原生 Android 側(cè)在 MethodChannel 的 handler 里執(zhí)行 TFLite 的 run 方法。核心代碼邏輯大致是這樣的override fun onMethodCall(call: MethodCall, result: Result) { when (call.method) { embedText - { val text call.argumentString(text) val maxTokens call.argumentInt(maxTokens) ?: 512 val normalize call.argumentBoolean(normalize) ?: true try { val output embeddingService.embed(text, maxTokens, normalize) result.success(output) } catch (e: Exception) { result.error(EMBED_ERROR, e.localizedMessage, null) } } else - result.notImplemented() } }TFLite 這邊我推薦直接使用 tflite_flutter 的 Interpreter因?yàn)樗鼉?nèi)部已經(jīng)處理了很多復(fù)雜的內(nèi)存管理問(wèn)題。在初始化 Interpreter 時(shí)需要把模型文件路徑傳進(jìn)去同時(shí)指定線程數(shù)。線程數(shù)不建議直接拉滿因?yàn)橐苿?dòng)端 CPU 的核心數(shù)有限盲目調(diào)大線程數(shù)反而會(huì)因?yàn)榫€程切換開銷導(dǎo)致性能下降。我在中端設(shè)備上測(cè)試4 線程通常是最優(yōu)解在旗艦設(shè)備上 6 線程反而表現(xiàn)更好。這個(gè)參數(shù)值得做幾次對(duì)比實(shí)驗(yàn)不同機(jī)型的差異會(huì)超出你想象。iOS 端的封裝思路也類似區(qū)別在于底層換成了 Core ML。我會(huì)先把模型轉(zhuǎn)成 Core ML 格式然后通過(guò) IOService 創(chuàng)建預(yù)測(cè)對(duì)象。由于 Core ML 對(duì)輸入的預(yù)處理也有要求我一般會(huì)在原生層完成 tokenizer 和 padding 操作確保喂給模型的輸入矩陣形狀正確。整個(gè)鏈路的完整性可以用一個(gè)流程來(lái)描述Dart 層拿到統(tǒng)一接口之后先做文本長(zhǎng)度判斷如果超長(zhǎng)則作分段分段結(jié)果逐段通過(guò) MethodChannel 發(fā)送給原生層原生層把文本交給模型執(zhí)行推理拿到一組向量后再返回給 Dart 層Dart 層對(duì)向量做歸一化和相似度計(jì)算。每一步的數(shù)據(jù)傳遞都是標(biāo)準(zhǔn) JSON 可序列化的結(jié)構(gòu)所以調(diào)試起來(lái)也非常方便。3.3 性能優(yōu)化與內(nèi)存管理端側(cè)推理最怕兩件事卡頓和內(nèi)存暴漲?？D的源頭往往不在模型本身而在線程調(diào)度。Flutter 的 UI 線程和后臺(tái)線程之間如果頻繁切換會(huì)引發(fā)不必要的上下文切換開銷。最有效的做法是讓推理全程保持在原生層后臺(tái)線程Dart 層只負(fù)責(zé)發(fā)起請(qǐng)求和接收結(jié)果不做任何密集計(jì)算。Dart 的 Future 本身就是異步模型配合原生層的 Handler 或 DispatchQueue可以做到“UI 無(wú)感知”的推理。內(nèi)存管理方面有一個(gè)容易被忽略的細(xì)節(jié)TFLite 的 Interpreter 每次執(zhí)行完成后會(huì)保留一些中間張量緩存。如果你反復(fù)創(chuàng)建新的 Interpreter 對(duì)象內(nèi)存就會(huì)像滾雪球一樣漲起來(lái)。正確做法是把 Interpreter 設(shè)計(jì)成單例整個(gè) App 生命周期內(nèi)只初始化一次。需要處理不同模型時(shí)可以準(zhǔn)備一個(gè) ModelManager 類按需加載和釋放而不是每次調(diào)用都新建。還有一個(gè)跟垃圾回收相關(guān)的問(wèn)題。Dart 把 List 傳遞給原生層時(shí)會(huì)發(fā)生內(nèi)存拷貝。如果文本批次很大拷貝開銷會(huì)非常明顯。我的優(yōu)化方案是使用 Float32List 這類 TypedData 類型減少裝箱和拷貝成本。原生層返回值時(shí)也盡量使用 Float32Array 之類的緊湊類型而不是 List 或 NSArray這樣可以在通道傳輸時(shí)直接復(fù)用底層內(nèi)存減少一次轉(zhuǎn)換。在設(shè)備發(fā)熱問(wèn)題上我也做了一些取舍。長(zhǎng)時(shí)間連續(xù)調(diào)用模型手機(jī)會(huì)明顯升溫尤其是舊款設(shè)備。我的策略是增加一個(gè)冷卻機(jī)制連續(xù)推理一定次數(shù)后自動(dòng)暫停隊(duì)列并等待幾秒同時(shí)把模型的頻率限制在一個(gè)合理水平。這種限制對(duì)交互型應(yīng)用來(lái)說(shuō)影響不大但對(duì)后臺(tái)批量索引任務(wù)來(lái)說(shuō)非常關(guān)鍵否則會(huì)因?yàn)檫^(guò)熱降頻反而拖慢整體速度。4. 應(yīng)用場(chǎng)景拆解AI Edge Foresight 能做什么4.1 語(yǔ)義搜索與本地知識(shí)庫(kù)把這個(gè)組合用在本地語(yǔ)義搜索上是第一個(gè)讓人眼前一亮的效果。傳統(tǒng)的關(guān)鍵詞搜索只能匹配字面相同的詞比如用戶搜“貓咪”搜不到“貓貓”。但嵌入模型把兩邊都轉(zhuǎn)成向量之后語(yǔ)義上相近的內(nèi)容可以很輕松地被召回。實(shí)際做項(xiàng)目的時(shí)候我在本地用 SQLite 存了向量數(shù)據(jù)和原始文本然后通過(guò)余弦相似度來(lái)排序效果比用 LIKE 查詢好了一個(gè)量級(jí)。SQLite 本身沒(méi)有向量索引但數(shù)據(jù)量在萬(wàn)級(jí)以內(nèi)時(shí)線性掃描幾萬(wàn)條向量的耗時(shí)也就是幾十毫秒完全夠用。如果數(shù)據(jù)量到了十萬(wàn)級(jí)就可以引入本地向量索引例如先聚類再檢索避免每一次都全表掃描。這里要特別強(qiáng)調(diào)一下召回與排序的區(qū)分。EmbeddingGemma 2 生成向量只負(fù)責(zé)“召回”也就是從庫(kù)里找出候選內(nèi)容而最終的排序往往需要結(jié)合其他業(yè)務(wù)規(guī)則比如時(shí)間權(quán)重、用戶偏好、內(nèi)容熱度。千萬(wàn)不要指望一個(gè)向量模型把所有排序問(wèn)題都解決掉。我自己的實(shí)現(xiàn)是兩階段第一階段用向量相似度召回 Top 50第二階段用一套輕量級(jí)打分公式把時(shí)間衰減、點(diǎn)擊反饋、手動(dòng)置頂?shù)纫蛩丶舆M(jìn)去得到最終 Top 10。這套思路在工程上非常好擴(kuò)展也更容易解釋給產(chǎn)品同學(xué)聽。另外在無(wú)網(wǎng)條件下端側(cè)語(yǔ)義搜索的價(jià)值會(huì)被徹底放大。比如在地鐵、飛機(jī)、國(guó)外漫游沒(méi)有流量的時(shí)候用戶依然可以檢索自己的本地筆記、收藏夾、通訊錄。這種能力不是云端方案的簡(jiǎn)化版而是一種全新維度的產(chǎn)品體驗(yàn)。我自己在飛機(jī)上實(shí)測(cè)過(guò)離線狀態(tài)下全文檢索加上本地語(yǔ)義糾錯(cuò)響應(yīng)速度反而比在線搜索更快因?yàn)闆](méi)有網(wǎng)絡(luò)包的封裝、排隊(duì)、傳輸和解析過(guò)程。4.2 內(nèi)容理解與分類打標(biāo)除了搜索內(nèi)容理解是 EmbeddingGemma 2 的第二個(gè)殺手锏。在很多本地筆記類 App 里用戶需要自動(dòng)把筆記分到“工作”、“生活”、“學(xué)習(xí)”等等級(jí)分類中。傳統(tǒng)做法是維護(hù)一個(gè)關(guān)鍵詞詞表然后做規(guī)則匹配但遇到“周末去圖書館看了本關(guān)于營(yíng)銷的書”這種句子規(guī)則匹配很容易失效。向量化之后你可以先用少量標(biāo)注樣本給每個(gè)類別生成一個(gè)“類別原型向量”然后對(duì)待分類文本的向量和類別原型向量做相似度比較選最高的那個(gè)作為預(yù)測(cè)類別。這個(gè)方案不僅輕量而且可解釋性也不錯(cuò)因?yàn)槊總€(gè)類別的原型向量可以可視化出來(lái)方便業(yè)務(wù)同學(xué)理解模型劃分的內(nèi)在邏輯。實(shí)際實(shí)施時(shí)我發(fā)現(xiàn)類別原型向量如果只用少量樣本生成容易有偏差。更好的做法是給每個(gè)類別收集幾十條典型樣本分別向量化然后求平均。類別數(shù)量越多原型向量之間的分界面就越復(fù)雜此時(shí)可以在向量之上再接一個(gè)輕量級(jí)分類器比如邏輯回歸或決策樹。模型本身依然跑在端側(cè)分類器參數(shù)也內(nèi)置在本地文件里整個(gè)過(guò)程仍然可以完全離線完成。這樣既保留了端側(cè)的低延遲也在精度上比簡(jiǎn)單的原型匹配高不少。這個(gè)能力還有一個(gè)延伸應(yīng)用給內(nèi)容做“新鮮度”判斷。對(duì)于新聞?lì)?App用戶希望第一時(shí)間看到新事件對(duì)于知識(shí)庫(kù)用戶可能更看重經(jīng)典內(nèi)容。通過(guò)把時(shí)間信息轉(zhuǎn)化成一種權(quán)重特征再和文本向量拼接就能訓(xùn)練出一個(gè)端側(cè)的小型排序模型。這種方式比純粹用規(guī)則靈活很多因?yàn)樗軌蜃詣?dòng)從用戶的點(diǎn)擊行為中學(xué)習(xí)到底哪些內(nèi)容對(duì)當(dāng)前用戶來(lái)說(shuō)是“新鮮且有用”的。當(dāng)然端側(cè)的個(gè)性化學(xué)習(xí)不能做得太重一般我會(huì)采用每隔一段時(shí)間下載一次增量權(quán)重的方式而不是在設(shè)備上實(shí)時(shí)訓(xùn)練。4.3 個(gè)性化推薦與異常檢測(cè)再往下聊就得說(shuō) AI Edge Foresight 里那個(gè)“Foresight”了。所謂預(yù)判能力我的理解是把用戶的歷史行為向量化然后預(yù)測(cè)下一步可能的意圖。舉個(gè)典型的例子用戶在一個(gè)閱讀類 App 里連續(xù)看了三篇關(guān)于“裝修風(fēng)格”的文章端側(cè)模型就可以提前把“北歐風(fēng)”、“收納”、“采光設(shè)計(jì)”等相關(guān)話題的文章向量加載到本地緩存里等用戶真正搜索時(shí)這些候選已經(jīng)處于“熱備”狀態(tài)點(diǎn)擊即可出現(xiàn)在結(jié)果前列。這個(gè)預(yù)判過(guò)程完全發(fā)生在本地不需要把用戶的閱讀歷史上傳到服務(wù)端隱私邊界非常清晰。異常檢測(cè)是另一個(gè)容易被忽視的場(chǎng)景。比如本地照片應(yīng)用可以用文本向量對(duì)照片備注和 GPS 信息做聚類當(dāng)出現(xiàn)一個(gè)偏離用戶常規(guī)軌跡的聚類時(shí)比如突然出現(xiàn)了大量同一地點(diǎn)的照片可以觸發(fā)一次遷移學(xué)習(xí)或提示用戶整理相冊(cè)。這個(gè)功能聽起來(lái)不算“硬核”但恰恰是端側(cè) AI 的優(yōu)勢(shì)所在它可以持續(xù)地、靜默地在后臺(tái)工作不用在意網(wǎng)絡(luò)可用性也不會(huì)因?yàn)槊看螖?shù)據(jù)上傳而消耗用戶的電量。我自己的體會(huì)是AI Edge Foresight 并不強(qiáng)調(diào)模型本身有多“聰明”而是強(qiáng)調(diào)系統(tǒng)對(duì)用戶意圖的響應(yīng)速度。它像是給 App 裝了一雙“近視眼鏡”能看清用戶手邊的內(nèi)容而不需要每次都抬頭望云端。從產(chǎn)品維度來(lái)說(shuō)離線可用、隱私安全、毫秒級(jí)預(yù)測(cè)這三點(diǎn)結(jié)合起來(lái)才是這套架構(gòu)真正的護(hù)城河。5. 常見問(wèn)題與排查實(shí)錄5.1 模型加載失敗這個(gè)坑估計(jì)所有入坑端側(cè) AI 的朋友都踩過(guò)。現(xiàn)象是 App 啟動(dòng)后調(diào)用原生推理接口立刻拋出一個(gè)類似 “Failed to load model” 的異常。原因通常有兩個(gè)一是模型文件路徑不正確二是模型文件格式損壞。路徑不正確多半是因?yàn)?Flutter 的 assets 目錄在原生層的訪問(wèn)方式不同你需要先把 assets 文件復(fù)制到應(yīng)用私有目錄再傳給原生層不能直接把 “assets/xxx.tflite” 字符串給 Interpreter。我踩過(guò)一次很隱蔽的坑Android 的 assets 解壓時(shí)會(huì)把目錄結(jié)構(gòu)保留但 iOS 的 bundle 里路徑大小寫不敏感一旦文件名寫錯(cuò)大小寫模擬器上能跑真機(jī)上就崩。排查這類問(wèn)題我的建議是分三步走先確認(rèn)文件是否存在檢查文件大小是否正常再用一個(gè)最小的測(cè)試工程直接加載該模型排除 Flutter 層干擾最后檢查模型內(nèi)部是否有自定義算子。如果是自定義算子TFLite 解析時(shí)可能會(huì)報(bào) “Op not found”這時(shí)候就需要重新導(dǎo)出模型時(shí)把這些算子替換成標(biāo)準(zhǔn)算子。不要嫌麻煩多數(shù)模型加載問(wèn)題都是細(xì)節(jié)導(dǎo)致的。5.2 推理速度慢推理速度上不去最直接的原因通常是模型沒(méi)有量化或者設(shè)備沒(méi)有正確使用加速硬件。如果你在桌面級(jí)模擬器上跑得很流暢一到真機(jī)就慢得離譜那多半是原生推理引擎沒(méi)有使用 GPU 或 NPU 代理。TFLite 里可以使用 GPU delegate但并不是所有算子都能在 GPU 上執(zhí)行如果模型里存在不支持的算子TFLite 會(huì)自動(dòng)回退到 CPU而且回退過(guò)程會(huì)打印一行警告很容易被忽略。還有一個(gè)經(jīng)常被忽略的因素設(shè)備過(guò)熱后降頻。我有一臺(tái)測(cè)試機(jī)在連續(xù)跑五分鐘推理后單次推理耗時(shí)從 40ms 漲到了 90ms。后來(lái)我加入了散熱控制和推理任務(wù)分批機(jī)制情況才好轉(zhuǎn)。從架構(gòu)角度看推理性能調(diào)優(yōu)必須結(jié)合具體機(jī)型的算力特點(diǎn)去調(diào)不能只盯著模型本身。建議在實(shí)際測(cè)試時(shí)準(zhǔn)備幾臺(tái)覆蓋中端和旗艦的設(shè)備分別統(tǒng)計(jì)推理耗時(shí)和內(nèi)存占用形成一個(gè)基礎(chǔ)性能基線表。后續(xù)每一次模型版本升級(jí)都用同一組基線數(shù)據(jù)來(lái)做對(duì)比才能客觀判斷模型是不是變慢了。5.3 包體積爆炸這是 Flutter 應(yīng)用接端側(cè)模型最容易遇到的問(wèn)題。一個(gè) 100MB 的模型文件直接放進(jìn) assets打包后 APK 體積瞬間膨脹。解決方式在 3.1 已經(jīng)提過(guò)就是改成動(dòng)態(tài)下載。這里再補(bǔ)充兩個(gè)細(xì)節(jié)一是動(dòng)態(tài)下載需要考慮斷點(diǎn)續(xù)傳和網(wǎng)絡(luò)狀態(tài)變化建議使用后臺(tái)下載服務(wù)而不是簡(jiǎn)單用 HTTP 庫(kù)直接拉二是模型版本管理和 App 版本管理要解耦模型可以單獨(dú)發(fā)布升級(jí)不需要強(qiáng)制用戶升級(jí) App 才能獲得新模型。還有一個(gè)容易被忽視的體積隱患Flutter 插件本身可能引入一些不必要的原生庫(kù)。比如你為了跑 TFLite 引入了全套 TensorFlow Lite 支持庫(kù)其中包含了很多你用不到的算子包。這種情況下你可以通過(guò) Gradle 的 ABI 過(guò)濾只保留 arm64-v8a 架構(gòu)同時(shí)移除 x86_64 等不用的架構(gòu)安裝包能立刻瘦身不少。iOS 端則可以檢查是否引入了冗余的 bitcode 支持配合 Xcode 的編譯設(shè)置把不需要的架構(gòu)裁剪掉。6. 一些經(jīng)驗(yàn)體會(huì)折騰完這個(gè)項(xiàng)目我最深的感觸是端側(cè) AI 真正難的不是算法而是工程整合。Flutter 和 EmbeddingGemma 2 的組合本質(zhì)上是一次“跨端殼層 本地模型運(yùn)行時(shí)”的聯(lián)姻需要你同時(shí)懂 Dart 層的內(nèi)存管理、原生層的線程調(diào)度、模型轉(zhuǎn)換工具鏈的細(xì)節(jié)還要有耐心去一臺(tái)一臺(tái)真機(jī)上驗(yàn)證表現(xiàn)。沒(méi)有哪個(gè)環(huán)節(jié)是能靠讀文檔直接跳過(guò)的。如果讓我給出一個(gè)最想強(qiáng)調(diào)的建議那就是先把最小可用鏈路跑通再考慮性能優(yōu)化和功能擴(kuò)展。我見過(guò)太多人一上來(lái)就研究怎么把模型量化到 4bit、怎么上 NPU、怎么構(gòu)建多模態(tài)識(shí)別結(jié)果基礎(chǔ)通道都沒(méi)打通。先讓一句話進(jìn)入模型再收到一個(gè)像模像樣的向量這個(gè)正向反饋建立起來(lái)之后整個(gè)系統(tǒng)的復(fù)雜度曲線會(huì)變得非常清晰后面不管加什么功能都只是在這個(gè)鏈路上增加分支而已。最后再分享一個(gè)小技巧模型輸出的向量多留一份原始值做備份。端側(cè)模型升級(jí)后新舊向量之間可能出現(xiàn)空間偏移這時(shí)候如果保留舊版本向量可以做向量空間的對(duì)齊測(cè)試快速評(píng)估升級(jí)帶來(lái)的影響。這個(gè)小動(dòng)作不復(fù)雜但能在模型迭代時(shí)省下非常多排查時(shí)間。希望這篇文章能給正在琢磨 Flutter 加端側(cè)嵌入模型的朋友一些參考也歡迎大家在自己的項(xiàng)目里有更巧妙的實(shí)踐時(shí)回頭來(lái)互相印證。