iT邦幫忙

2026 iThome 鐵人賽

DAY 28
0
AI Engineering

30 天打造 Edge AI Product:一個 PM 從 0 到 1 的 AI Engineering 實戰系列 第 28 篇

POC 真的跑起來了,但離產品還有多遠?

  • 分享至 

  • xImage
  •  

當我第一次看到 QCS6490 上的 AI Detection 成功跑起來時,確實很有成就感。

從影像串流、Video Pipeline,到 QNN / HTP 加速,再到 Person Detection、Geofence 和 Event Trigger,原本散落在不同技術環節的東西,終於串成了一個可以實際運作的流程。

我們也在 4 樓無人區進行了超過一週的驗證,確認這個 Use Case 不只是簡報上的架構圖,而是真的能在現場運作。

但 Demo 成功之後,我開始問自己一個問題:

如果明天把這套系統交給客戶,我真的可以放心嗎?

答案是:還不行。

一、能跑起來,只代表第一關通過了

以目前的 PoC 為例,我們已經可以接收影像、進行人物偵測、判斷是否進入指定區域,並觸發後續事件。

但這只代表主要流程已經串通,不代表所有使用情境都經過驗證。

例如:

  • 效能: 單次 Model Inference 可以達到約 31 FPS,不代表整個影像到事件的流程都能維持 31 FPS。
  • 穩定性: Demo 當下正常,不代表長時間執行、網路中斷或服務重啟後,系統仍然能正常運作。
  • 準確性: 偵測到一個人,不代表每次入侵都能正確判斷,也不代表不會出現誤報。
  • 資源使用: 單一串流可以運作,不代表增加攝影機後,NPU、CPU、記憶體與影像處理資源仍然足夠。
  • 維運能力: 系統發生錯誤時,能不能找到原因?更新 Model 或 Container 之後,能不能恢復到上一個可用版本?

這些問題不一定會在 Demo 時出現,卻會直接影響客戶能不能真正使用這個產品。

二、從 Demo 到產品,我會再看四件事

1. Performance:效能是否符合實際需求?

我們不能只看 Model 的 FPS,還要看完整的 End-to-End Pipeline。

從影像進入系統、解碼、前處理、AI 推論,到事件判斷與通知,每個環節都可能影響最後的反應時間。

因此,接下來要驗證的不只是推論速度,而是整體延遲、可支援的串流數量,以及不同負載下的資源使用情況。

2. Reliability:系統能不能長時間穩定運作?

真實場域不會一直配合 Demo。

RTSP 可能斷線,Container 可能異常,設備也可能重新啟動。

產品化需要進一步驗證斷線重連、服務自動恢復、錯誤紀錄與異常告警,而不是每次發生問題都要工程師到現場重新操作。

3. Usability:客戶能不能自己操作?

目前的功能包含影像來源設定、Model 選擇、Confidence 與類別篩選、Tripwire、Geofence、追蹤、警示、錄影及上傳。

但功能存在,不代表操作就足夠簡單。

客戶真正想做的,是設定「哪個區域不能有人進入」,而不是理解 QNN、HTP、Model Artifact 或 Runtime 的差異。

產品需要把底層技術複雜度藏在合理的操作流程後面,讓客戶可以完成任務,而不是要求客戶先學會工程師的工作。

4. Maintainability:之後要怎麼更新與維護?

如果客戶想換一個 Model,或我們需要更新 Application,能不能確認版本相容性?

新版本上線前,有沒有經過驗證?更新失敗時,能不能回復到上一個穩定版本?

這也是為什麼前面幾天一直討論 Model Registry、Model Artifact、Device Profile 與 Validation。

它們不是為了讓架構看起來更完整,而是要解決產品交付之後,版本如何管理、如何部署,以及如何降低更新風險的問題。

三、兩個人的團隊,不可能一次把所有事情做完

回到我們的專案,只有一位 PM、一位工程師,以及一片 QCS6490 開發板。

我們不可能在三個月內,把所有硬體組合、所有 Model、所有異常情境與完整的企業級維運能力全部做完。

所以我必須區分三件事:

  • Implemented: 功能已經完成。
  • Validated: 功能已經在特定條件下驗證。
  • Product-ready: 已經達到明確的交付標準,包含穩定性、操作、維運與支援需求。

這三件事不能畫上等號。

例如,Geofence 已經可以運作,不代表所有攝影機角度、光線條件與人員移動情境都經過驗證;Container 可以部署,也不代表系統已經具備完整的遠端維運能力。

對 AI PM 來說,重要的不是把所有待辦事項都標記成完成,而是清楚知道目前已經證明什麼、還有哪些風險,以及下一步應該優先投入什麼。

四、PoC 的價值,不是證明產品已經完成

回頭看這段開發歷程,我認為這個 PoC 最重要的成果,不是我們做出了多少個功能。

而是我們已經把原本抽象的想法,轉變成可以實際運作、可以測試,也能持續改善的系統。

我們知道影像如何進入 Pipeline,AI 如何透過 QNN / HTP 執行,偵測結果如何轉成事件,也知道當 Model、Runtime、Container 與硬體組合改變時,還需要面對哪些整合與驗證問題。

這些經驗讓下一階段的工作不必再從零開始猜測。

Demo 證明這個想法做得到;產品化則要證明它在客戶需要的條件下,能持續、可靠而且容易地運作。

對我來說,這才是從 AI PoC 走向 Edge AI Product,真正需要跨過的那段距離。


上一篇
客戶只想偵測入侵,為什麼還要管這麼多 Model?
下一篇
Demo 可以跑,但不代表客戶會用?
系列文
30 天打造 Edge AI Product:一個 PM 從 0 到 1 的 AI Engineering 實戰 共 29 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言