當我第一次看到 QCS6490 上的 AI Detection 成功跑起來時,確實很有成就感。
從影像串流、Video Pipeline,到 QNN / HTP 加速,再到 Person Detection、Geofence 和 Event Trigger,原本散落在不同技術環節的東西,終於串成了一個可以實際運作的流程。
我們也在 4 樓無人區進行了超過一週的驗證,確認這個 Use Case 不只是簡報上的架構圖,而是真的能在現場運作。
但 Demo 成功之後,我開始問自己一個問題:
如果明天把這套系統交給客戶,我真的可以放心嗎?
答案是:還不行。
以目前的 PoC 為例,我們已經可以接收影像、進行人物偵測、判斷是否進入指定區域,並觸發後續事件。
但這只代表主要流程已經串通,不代表所有使用情境都經過驗證。
例如:
這些問題不一定會在 Demo 時出現,卻會直接影響客戶能不能真正使用這個產品。
我們不能只看 Model 的 FPS,還要看完整的 End-to-End Pipeline。
從影像進入系統、解碼、前處理、AI 推論,到事件判斷與通知,每個環節都可能影響最後的反應時間。
因此,接下來要驗證的不只是推論速度,而是整體延遲、可支援的串流數量,以及不同負載下的資源使用情況。
真實場域不會一直配合 Demo。
RTSP 可能斷線,Container 可能異常,設備也可能重新啟動。
產品化需要進一步驗證斷線重連、服務自動恢復、錯誤紀錄與異常告警,而不是每次發生問題都要工程師到現場重新操作。
目前的功能包含影像來源設定、Model 選擇、Confidence 與類別篩選、Tripwire、Geofence、追蹤、警示、錄影及上傳。
但功能存在,不代表操作就足夠簡單。
客戶真正想做的,是設定「哪個區域不能有人進入」,而不是理解 QNN、HTP、Model Artifact 或 Runtime 的差異。
產品需要把底層技術複雜度藏在合理的操作流程後面,讓客戶可以完成任務,而不是要求客戶先學會工程師的工作。
如果客戶想換一個 Model,或我們需要更新 Application,能不能確認版本相容性?
新版本上線前,有沒有經過驗證?更新失敗時,能不能回復到上一個穩定版本?
這也是為什麼前面幾天一直討論 Model Registry、Model Artifact、Device Profile 與 Validation。
它們不是為了讓架構看起來更完整,而是要解決產品交付之後,版本如何管理、如何部署,以及如何降低更新風險的問題。
回到我們的專案,只有一位 PM、一位工程師,以及一片 QCS6490 開發板。
我們不可能在三個月內,把所有硬體組合、所有 Model、所有異常情境與完整的企業級維運能力全部做完。
所以我必須區分三件事:
這三件事不能畫上等號。
例如,Geofence 已經可以運作,不代表所有攝影機角度、光線條件與人員移動情境都經過驗證;Container 可以部署,也不代表系統已經具備完整的遠端維運能力。
對 AI PM 來說,重要的不是把所有待辦事項都標記成完成,而是清楚知道目前已經證明什麼、還有哪些風險,以及下一步應該優先投入什麼。
回頭看這段開發歷程,我認為這個 PoC 最重要的成果,不是我們做出了多少個功能。
而是我們已經把原本抽象的想法,轉變成可以實際運作、可以測試,也能持續改善的系統。
我們知道影像如何進入 Pipeline,AI 如何透過 QNN / HTP 執行,偵測結果如何轉成事件,也知道當 Model、Runtime、Container 與硬體組合改變時,還需要面對哪些整合與驗證問題。
這些經驗讓下一階段的工作不必再從零開始猜測。
Demo 證明這個想法做得到;產品化則要證明它在客戶需要的條件下,能持續、可靠而且容易地運作。
對我來說,這才是從 AI PoC 走向 Edge AI Product,真正需要跨過的那段距離。