邊緣AI應用程式開發的核心在於平衡效能、可靠性和資源消耗。設計初期需明確定義評估指標，並與專案目標緊密結合，同時考量現有系統的指標作為基準。設計目標需根據價值導向，與領域專家共同制定最低效能標準，確保產品的可靠性。長期支援計畫的規劃同樣重要，需考量模型漂移和效能下降等因素。邊緣AI架構設計涉及硬體、軟體和服務的整合，從簡單的應用迴圈到複雜的多裝置級聯和雲端整合，需根據應用需求選擇合適的架構。常見的設計模式包括整合、平行、串列和級聯流程，以及感測器融合，這些模式可以結合異質硬體架構，實作效能和能耗的最佳平衡。此外，人機協作架構在特定應用中至關重要，確保AI決策的安全性與可靠性，並提供優雅降級機制以應對ML元件失效。最後，設計過程中需時刻注意潛在的偏差，並透過迭代設計不斷最佳化系統。
績效評估與設計目標的重要性
在開發邊緣AI（Edge AI）應用程式時，定義明確的評估指標和設計目標至關重要。這些指標和目標不僅幫助衡量系統的效能，也確保了產品的品質和可靠性。
績效評估指標
為了評估AI系統的效能，需要定義合適的評估指標。這些指標應該與專案的目標相一致，並且能夠在實際應用中被測量。如果難以確定如何衡量應用程式的效能，那麼可能需要重新考慮專案的可行性。
在某些情況下，現有的系統已經具備一些評估指標，這些指標可以用來評估新的AI驅動系統。這樣可以提供一個比較的基準，有助於評估新系統的改程式度。
由於AI開發具有迭代性，因此需要考慮可用的時間。目標應該是提高系統的效能，直到達到預定的最低可行效能水平。如果進展停滯，就需要決定是否嘗試不同的方法或終止專案。
根據價值的設計目標
為了建立一個負責任的應用程式，需要建立代表所期望價值的設計目標。例如，在開發醫療診斷系統時，醫療專家可能會同意，低於某個閾值的診斷準確度是不可接受的。
因此，需要與利益相關者和領域專家共同確定負責任產品所需的最低效能。這可以用來建立一套明確的透過/不透過標準，用於控制專案的發布。
在開發過程中，測量和記錄描述系統效能的指標至關重要。這些資料將有助於做出是否繼續專案的決定。組織和個人之間的壓力往往會推動專案向前發展，而明確的品質標準可以使決策過程更加客觀。
長期支援目標
另一個關鍵的設計過程部分是長期支援計畫。大多數AI佈署在實際應用中需要觀察和維護。漂移（Drift）是不可避免的，並且會隨著時間的推移導致效能下降。所選擇的應用程式和硬體應該能夠回報一些指標，幫助瞭解漂移發生的速度。
這將有助於判斷何時需要收集更多資料並訓練新的模型。設計目標應該包括長期支援產品的目標。
架構設計
邊緣AI系統的架構是指其各個組成部分如何組合在一起，以創造一個有效的解決方案。有許多可能的架構方式，每種架構都有其獨特的權衡。系統架構師的任務是分析情況並選擇能夠最大化技術優勢的架構。
硬體、軟體和服務
邊緣AI應用程式由三個主要組成部分：硬體、軟體和服務。
- 硬體包括邊緣裝置本身及其處理器、記憶體和感測器。
- 軟體是使系統運作起來的關鍵，包括驅動程式、訊號處理和AI演算法，以及應用邏輯。
- 服務是邊緣AI系統可以介接的外部系統，例如通訊網路、無線系統、IoT管理平台、Web API和雲端應用程式。
有效的邊緣AI架構需要將這三個組成部分以創造性的方式結合起來，以提供特定情況下最佳的權衡平衡。
基本應用架構
簡單性始終是一個好的選擇，應該從最簡單的架構開始。圖8-1顯示了一個典型的邊緣AI應用程式結構。
核心是應用迴圈（Application Loop），這是一系列重複的步驟，包括捕捉和處理訊號、執行AI演算法、解釋輸出結果，並根據結果做出決策和觸發動作。
圖8-1. 邊緣AI應用程式架構
此圖示呈現了一個典型的邊緣AI應用程式架構，包括應用迴圈、裝置韌體或作業系統層，以及硬體層之間的互動關係。
圖表翻譯： 圖8-1詳細展示了邊緣AI應用程式的基本架構，包括從感測器資料的擷取到最終決策執行的整個流程。其中，應用迴圈是核心元件，負責不斷處理輸入資料並作出相應反應。裝置韌體或作業系統層提供了硬體與軟體之間的抽象層，使得上層應用邏輯可以更方便地控制硬體資源。
應用迴圈得到了裝置韌體或OS部分的支援。這些元件在硬體和軟體之間提供了一個抽象層，通常提供方便的API供應用迴圈使用，以控制硬體。典型的任務包括讀取感測器資料、傳送和接收通訊，以及控制連線的裝置（如燈光、揚聲器和執行器）。
邊緣AI應用架構的多樣性
在探討邊緣AI硬體架構時，我們瞭解到許多裝置具備多個處理器。硬體API層提供了抽象化，使計算可以在選擇的處理器上執行。例如，深度學習模型的運算可以轉移到獨立的神經網路核心，以提高速度和效率。
基本流程
最基本的應用程式中，軟體流程是單一的，執行在同一裝置上，從感測器取得資料、處理資料並做出決策，如圖8-2所示。
圖8-2：基本邊緣AI應用流程
此圖示展示了基本的邊緣AI應用流程。
圖表翻譯： 圖8-2描述了一個基本的邊緣AI應用流程，包括從感測器取得資料、進行資料處理、執行AI推論、後處理以及業務邏輯決策等步驟。
許多成功的應用採用此流程，這應該是開發軟體架構時的起點。通常，AI演算法是一個單一的機器學習模型。例如，智慧型安防攝影機可能會使用這個流程，並搭配一個視覺模型來檢測人物，以觸發警示。圖8-3顯示了同樣的圖表，並疊加了真實世界的步驟。
圖8-3：智慧型攝影機設計的基本流程
此圖示展示了智慧型攝影機設計的基本流程。
圖表翻譯： 圖8-3展示了基本流程在智慧型攝影機設計中的應用，包括從攝影機取得影像、進行影像處理、執行人物檢測、後處理以及傳送警示等步驟。
整合流程
另一種常見的方法是使用多個演算法或模型的整合，如「結合演算法」中所述。在這種情況下，相同的感測器資料被輸入到多個模型中，這些模型產生相同型別的輸出，並將結果結合起來。如圖8-4所示。
圖8-4：整合流程
此圖示展示了整合流程。
圖表翻譯： 圖8-4描述了一個整合流程，其中多個模型平行處理相同的輸入資料，並將結果結合起來以提高整體效能。
在整合中，演算法通常都會產生相同型別的輸出。例如，可以建立一個由三種不同型別的影像分類別器組成的整合，每個分類別器都經過訓練，可以預測影像中是否存在人物。透過結合三種不同型別的演算法的輸出，可以平均每個演算法的優缺點，從而得到比任何單一演算法更少偏差的輸出。
平行流程
也可以結合執行不同功能的演算法。例如，可以將分類別模型與異常檢測模型結合。異常檢測模型的輸出可以用於理解輸入資料是否超出分佈範圍，因此分類別器不可信。如圖8-5所示。
圖8-5：平行流程
此圖示展示了平行流程。
圖表翻譯： 圖8-5描述了一個平行流程，其中多個模型平行處理輸入資料，並將結果結合起來以支援業務邏輯決策。
在平行流程（圖8-5）中，模型的輸出可以在後處理步驟或業務邏輯中結合。例如，如果一個模型的輸出用於調節另一個模型的輸出（如分類別和異常檢測例子），這種調節可以在後處理步驟中完成。如果多個模型的輸出用於驅動業務邏輯決策，則模型的輸出將在業務邏輯中結合。
串列流程
將模型串聯起來也很有用。在這種流程中，如圖8-6所示，一個演算法的輸出被饋入另一個演算法，無論是否有後處理。
圖8-6：串列流程
此圖示展示了串列流程。
圖表翻譯： 圖8-6描述了一個串列流程，其中一個模型的輸出被用作另一個模型的輸入，以實作更複雜的功能。
串列流程在需要使用一個模型從原始輸入中提取特徵，然後使用另一個模型來理解特徵變化時非常有用。例如，可以使用姿勢估計模型從照片中識別人物的手臂和腿部位置，然後將這些位置傳遞給分類別模型，以確定他們正在進行哪種瑜伽姿勢。
級聯流程
在級聯中使用串列演算法是另一種聰明的方法。級聯流程如圖8-7所示。
圖8-7：級聯流程
此圖示展示了級聯流程。
圖表翻譯： 圖8-7描述了一個級聯流程，其中多個模型被串聯起來，以最小化推論的成本和能耗。
級聯流程旨在最小化執行推論的延遲和能耗。例如，假設在電池供電的裝置中，有一個始終開啟的關鍵字檢測系統。關鍵字檢測所需的模型可能相對較大和複雜，這意味著一直執行它會迅速耗盡電池。
相反，可以執行一個更小、更簡單的模型，僅用於檢測語音。這是我們級聯的第一層。當檢測到語音時，輸入被傳遞給級聯的第二層，即完整的關鍵字檢測模型。由於完整的關鍵字檢測模型的執行頻率降低，因此節省了能耗。
級聯可以根據需要具有任意多層。根據應用程式的不同，級聯中的每一層也可以有自己的獨立訊號處理演算法。在某些情況下，到達級聯的某個階段甚至可能觸發從另一個來源捕捉資料，例如提供更好訊號但消耗更多能量的更高品質麥克風。
通常，為了達到更好的效果，會調整級聯中較早的模型，以使其具有較高的召回率（見「精確率和召回率」），這意味著在判斷是否為潛在匹配時，它會傾向於樂觀。這種組態仍將比單一大模型節省能耗，但會降低較不準確的早期模型丟棄有效輸入的風險。
工作週期
工作週期是指處理器處於活動狀態的時間百分比。當不處於活動狀態時，可以將其置於低功耗狀態，以節省能耗。級聯之所以能夠節省能耗，是因為它們允許降低工作週期。
這是因為較小的模型比大模型執行時間更短。由於模型只需要定期執行（例如，當感測器資料緩衝區變滿時），處理器可以在其他時間關閉。在級聯中，最小的模型是執行最頻繁的模型。這導致比執行大模型的情況具有更低的工作週期。
感測器融合流程
到目前為止，我們所看到的所有架構都適用於單一輸入。在感測器融合流程中，如圖8-8所示，來自多個感測器的輸入被饋入相同的AI演算法。
圖8-8：感測器融合流程
此圖示展示了感測器融合流程。
圖表翻譯： 圖8-8描述了一個感測器融合流程，其中來自多個感測器的輸入被結合起來，以支援更複雜的AI應用。
透過結合多個感測器的資料，可以提高AI模型的準確性和魯棒性，從而實作更複雜的應用場景。
複雜應用架構與設計模式
在邊緣運算的世界中，將基礎的應用架構與不同的硬體架構結合，可以創造出更為複雜且具有價值的系統。這些經過驗證的設計模式可以應用於眾多不同的專案中，為開發者提供寶貴的參考。
異質級聯（Heterogeneous Cascade）
在異質硬體架構中（參見「異質運算」），單一裝置內可能具備多個處理器或協處理器。例如，一個裝置可能同時具備節能的中階微控制器（MCU）以及更強大但耗能更高的高階 MCU。這種硬體架構可以與軟體中的級聯流程（圖 8-9）結合，實作異質級聯。級聯的前幾層執行在較低階的處理器上，以最大化節能效果；而後續涉及更複雜演算法的層則執行在更高階的處理器上。在任何給定的時刻，只有一個處理器被啟動並消耗大量能量。
異質硬體架構越來越多地包含專為高效執行深度學習模型而設計的加速器。這些加速器非常適合用於執行級聯的不同階段。這種方法在許多關鍵字辨識應用中得到了廣泛應用。
圖 8-9. 異質級聯示意圖
此圖示呈現了異質級聯的運作流程，說明瞭不同層級的處理器如何協同工作。
圖表翻譯： 圖 8-9 詳細展示了異質級聯的結構，從低功耗處理器到高效能處理器的逐步升級，充分利用了不同處理器的優勢，以達到最佳的能耗與效能平衡。
多裝置級聯（Multi-Device Cascade）
級聯架構並不侷限於單一裝置，可以跨越多個裝置，如圖 8-10 所示。例如，一個智慧感測器可以使用簡單的機器學習模型檢查資料，若檢測到特定狀態，則喚醒更強大的閘道器裝置進行更深入的分析。
圖 8-10. 多裝置級聯示意圖
此圖示闡述了多裝置級聯的工作原理，展現了不同裝置之間的協作關係。
圖表翻譯： 圖 8-10 清晰地展示了多裝置級聯如何跨裝置協同工作，第一階段的智慧感測器檢測資料並在必要時喚醒第二階段的閘道器裝置，以進行進一步的資料分析。
第二階段的裝置既可以使用第一階段傳輸的資料，也可以透過自身的感測器捕捉新的資料。這些裝置可以是物理上獨立的，例如智慧感測器和閘道器裝置；也可以在同一個物理產品中以不同的印刷電路板（PCB）形式存在。
在某些情況下，甚至可以將完全不同的產品安排成級聯結構。例如，一個廉價的市售相機陷阱（透過紅外線感測器檢測到運動後拍攝照片）可以作為級聯的第一階段，隨後喚醒連線到同一個儲存裝置上的強大 SoC，以根據照片內容決定是否保留或刪除照片。
級聯至雲端（Cascade to the Cloud）
在頻寬不是主要問題的情況下，級聯可以跨越裝置和雲端。這是在具備數位助理功能的智慧音箱中的典型模式，這些音箱使用始終開啟的關鍵字辨識模型，在裝置上以盡可能低的延遲檢測關鍵字。一旦檢測到關鍵字，它們就會將隨後的音訊直接串流到雲端，由更大、更複雜的模型轉錄並解讀使用者的語音。
圖 8-11. 級聯至雲端的關鍵字辨識
此圖示呈現了一個複雜的四階段級聯流程，結合了多個裝置上的模型和雲端運算。
圖表翻譯： 圖 8-11 詳細展示了從裝置到雲端的整個級聯流程，包括多個階段和不同處理器的協同工作，展現了現代智慧裝置如何高效地處理語音辨識任務。
在圖 8-11 中，展示了一個複雜的四階段級聯流程，結合了裝置上的多個模型和雲端運算。儘管看起來複雜，但這與現代手機使用的流程類別似。前三個階段發生在裝置上，跨越兩個不同的處理器：一個低功耗始終開啟的處理器和一個深度學習加速器。當低功耗處理器上執行的模型檢測到語音時，會喚醒更強大的處理器來尋找關鍵字。如果檢測到關鍵字，裝置上的轉錄模型會嘗試將隨後的音訊轉換成文字。一旦轉錄完成，文字就會被傳送到雲端，由大型自然語言處理模型來確定其含義並給出相應的回應。
這裡的主要權衡涉及能耗、頻寬和隱私，以及維護雲端系統的長期需求。作為交換，我們可以使用太大而無法佈署在裝置上的模型，或者出於安全原因不想本地佈署的模型。確保這些權衡是值得的非常重要，因為作為交換，我們放棄了邊緣 AI 的大部分優勢。
智慧閘道器（Intelligent Gateway）
在某些情況下，將 AI 邏輯放置在靠近邊緣但不在實際葉節點的位置可能更為合理。例如，一個由 IoT 感測器組成的網路可能會收集有關工廠營運的多種不同型別的資料。沒有任何一個感測器能夠存取所有資料，但它們都將資料傳送回閘道器裝置。
透過在閘道器裝置上執行邊緣 AI 演算法，可以一起分析所有資料，從而更深入地瞭解整個系統的運作。透過在閘道器處進行處理，感測器可以保持小巧、廉價和節能。它們只需要捕捉並轉發資料；閘道器可以負責處理智慧任務。
人機協作（Human-in-the-Loop）
在某些情況下，不一定安全地讓 AI 演算法無檢查地做出決定。通常情況下，這些場景涉及錯誤決策可能帶來極為嚴重的後果。以下是一些鮮明的例子：
- 醫療應用，其中錯誤的診斷或不良的操作可能危及生命。
- 諸如自動駕駛汽車或工廠裝置等大型機械，可能對人員造成傷害。
程式碼範例：人機協作流程
def human_in_the_loop_decision(ai_decision, confidence_threshold):
"""
結合 AI 決策與人工審核的人機協作流程
:param ai_decision: AI 模型的決策結果
:param confidence_threshold: AI 信心閾值
:return: 最終決策結果
"""
if ai_decision.confidence >= confidence_threshold:
# 當 AI 信心超過閾值時，直接採用 AI 決策
return ai_decision.result
else:
# 當 AI 信心不足時，交由人工審核
return human_review(ai_decision)
def human_review(ai_decision):
"""
人工審核流程
:param ai_decision: 需要審核的 AI 決策
:return: 人工審核後的最終決策
"""
# 省略具體實作細節
pass
# 使用範例
ai_result = AI_Decision(result="Approve", confidence=0.8)
final_decision = human_in_the_loop_decision(ai_result, 0.9)
print(f"最終決策: {final_decision}")
內容解密：
此程式碼範例展示了人機協作的基本流程。首先，human_in_the_loop_decision 函式根據 AI 模型的信心水平決定是否直接採用 AI 的決策結果。當信心水平超過設定的閾值時，直接使用 AI 的結果；否則，將決策交由人工審核。human_review 函式代表了人工審核的流程，具體實作會根據實際需求進行細化。這個機制有效地結合了 AI 的高效處理能力和人類的判斷力，在需要高度可靠性的場景中提供了額外的安全保障。
邊緣AI系統設計的核心挑戰與解決方案
在開發邊緣AI系統時，我們面臨著多項技術挑戰，尤其是在安全、可靠性和效能等方面。這些挑戰要求我們在設計系統時必須謹慎考慮各種可能的情況，並採取適當的措施來確保系統的穩定運作。
人機協作架構的重要性
在許多應用場景中，單純依賴AI系統可能導致不公平或有害的結果。例如，在體育比賽中用於檢測犯規行為的AI系統，如果存在偏差，可能會對參賽者造成不公平的待遇。同樣，在醫療診斷領域，AI系統提供的診斷結果必須經過醫生的專業判斷才能做出最終決定。
為瞭解決這些問題，我們可以採用人機協作（Human-in-the-Loop）架構。這種架構有多種實作方式，包括：
完全人機協同：每一個決策都需要人類的直接參與。例如，醫療診斷裝置可能會提示某位患者患有特定疾病，但最終的診斷仍需由醫生根據自己的專業判斷來完成。
被動監督模式：人類扮演觀察者的角色，除非發現需要干預的情況，否則不會主動介入。例如，自動駕駛汽車在正常情況下可以自主行駛，但駕駛員仍需保持注意力，並在必要時隨時接管駕駛權。值得注意的是，這種模式的有效性仍存在爭議，因為人類在無需互動的情況下容易失去注意力，從而影響其干預能力。
事後審核模式：系統在執行過程中不直接接受人類監督，但會定期將演算法的決策結果送交人類審核，以確保系統的可靠性。這種方法對於長期監控應用程式至關重要。
優雅降級（GRACEFUL DEGRADATION）機制
在實際生產環境中，可能會出現需要關閉機器學習（ML）元件的情況。例如，當發現ML模型不再有效時，可能需要暫時停用它。此時，系統必須具備一定的容錯能力，以確保在ML元件關閉後仍能保持可接受的執行狀態。
為此，我們需要在應用程式中加入可組態的條件邏輯，用於決定是否啟用ML元件。具體實作方式可以是建立一個「拒絕列表」（Deny List），列出會導致ML元件被跳過的輸入型別。例如：
if matches_something_in_deny_list(input):
return non_ml(input)
else:
return ml(input)
內容解密：
這段程式碼展示瞭如何透過條件判斷來決定是否使用ML元件。matches_something_in_deny_list(input) 函式檢查輸入是否在拒絕列表中。如果是，則呼叫 non_ml(input) 函式處理輸入；否則，使用 ml(input) 進行處理。這種設計允許系統在必要時繞過ML元件，確保系統的持續運作。
理想情況下，這些拒絕列表應該能夠動態更新，例如透過網路組態更新。如果邊緣應用程式無法支援遠端更新，也可以考慮透過硬體方式（如開關或跳線）來更改組態。
設計模式的應用與迭代
在開發邊緣AI系統時，我們可以參考多種設計模式來指導我們的開發工作。然而，實際情況往往比教科書上的模式更為複雜，因此我們需要根據具體情況調整這些模式。
以下是使用設計模式的建議步驟：
- 深入瞭解資料集，並確定所需的演算法型別。
- 從最簡單的設計模式開始，通常是單裝置架構。
- 嘗試將問題對映到所選的設計模式，並撰寫相關檔案，包括圖表和利弊分析。
- 在開發過程中不斷迭代，同時參考所選的設計模式。
- 根據需要調整設計模式，逐步增加複雜度，直到找到合適的解決方案。
設計選擇中的偏差考量
我們的設計選擇往往受到個人或團隊偏見的影響。此外，架構本身也可能存在固有的偏差。因此，在設計系統時，我們需要意識到這些潛在的偏差，並盡量減少其對系統結果的影響。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title 邊緣AI應用程式設計與效能評估
package "安全架構" {
package "網路安全" {
component [防火牆] as firewall
component [WAF] as waf
component [DDoS 防護] as ddos
}
package "身份認證" {
component [OAuth 2.0] as oauth
component [JWT Token] as jwt
component [MFA] as mfa
}
package "資料安全" {
component [加密傳輸 TLS] as tls
component [資料加密] as encrypt
component [金鑰管理] as kms
}
package "監控審計" {
component [日誌收集] as log
component [威脅偵測] as threat
component [合規審計] as audit
}
}
firewall --> waf : 過濾流量
waf --> oauth : 驗證身份
oauth --> jwt : 簽發憑證
jwt --> tls : 加密傳輸
tls --> encrypt : 資料保護
log --> threat : 異常分析
threat --> audit : 報告生成
@enduml
圖表翻譯：
此圖示展示了系統根據輸入決定是否使用ML元件的流程。首先，系統會檢查是否應該使用ML元件。如果是，則呼叫 ml(input)；如果否，則呼叫 non_ml(input)。最後，無論採用哪種處理方式，流程都會結束。