如同前面所說，資料模型需要運用到實際環境中才會發揮價值
延續之前輔助決策的初始條件，如果想使用資料來做自動決策，最重要的一樣是要釐清想解決的問題是什麼。
常見的問題像是：
「明天會不會下雨？」
「使用者會不會點擊？」
「使用者是不是本人？」
面對這些問題，其實在技術上都有不只一種方式來回答。這時候就是要根據目前持有的前三層的資料品來決定可行的解決方案（沒錯上面這段都是直接 Ctrl+C, Ctrl+V）。
再來才是自動決策的重點：要自動做什麼事？
「如果明天會下雨，自動準備雨衣。」
「自動換成使用者會點擊的廣告。」
「如果使用者是本人，自動將手機解鎖。」
由於是自動決策，除了資料產品需要準備好之外，也要確認自動化是可行的。
上一篇我們提到了通常輔助決策會建立門檻值來協助使用者做決策。自動決策就是進一步將使用者決策這段自動化，在設計上需要多著墨這段，特別是當自動化這段超出軟體範疇、需要做軟硬體整合的時候。
延續上面的例子，像是。
「如果明天會下雨，讓機器人自動將雨衣送到客人門口。」
「如果透過前置鏡頭辨識出使用者為本人，自動將手機解鎖。」
這個時候牽扯到的事情就不只是區區「資料」了。
在輔助決策時提到，這些模型可以使用 BI 報表或是 APIs 來跟使用者溝通。到了自動決策，就會更依賴這些 APIs 了。這些 APIs 會跟用來做自動決策的工具（不管是相機還是其他軟體）相互溝通，而這些自動決策系統的 SLA 往往又比輔助系統更高（你絕對希望更快的人臉解鎖、不希望自動駕駛在路上發生系統性的問題、或是網站因為人太多就讓推薦系統當掉），在設計上就需要考量到實務被使用的狀況，例如 latency, capacity 等系統性的要求。
部署階段一樣除了考量前幾層的資料產品外呢，需要特別注意整個自動決策產品的 SLA(Service Level Aggrement)。單一產品要做到 99.9% 的 uptime 都不是簡單的事，何況資料產品層層疊疊，從原始資料一路疊到 Model 和 API，每個單一產品都需要有極高的穩定程度，才有辦法讓最終的自動決策系統達到 99.9% 的穩定度。（這段也是複製貼上啦）
評估階段基本上也是在處理兩個層面問題：
信度(Validaty)：除了結果的準確率是否足夠？
不同的問題可以被接受的準確率（或錯誤率）是不同的。像是 Iphone 人臉辨識解鎖你絕對不希望有任何錯誤可能；但是像颱風路徑預測，就可以接受相對較大的誤差。
效度(reliability)：結果是否穩定、能夠重複實現？就像之前談到的，模型不能只有上線那天好，而是希望能夠穩定發揮效果；系統面的穩定也是一樣，我們會希望每天資料都可以順利處理、不會因為突然的過量使用者造成系統停機或當掉。
自動化系統的特色就在於當模型產生預測結果後，自動化系統就會根據條件做後續的處理（像是解鎖、或是控制汽車左轉、右轉），因此對於模型的穩定度以及預測率都會更為要求，讓整個流程評估的複雜度和難度大大提升。
越上層的資料產品迭代起來也就越麻煩，下層產品的任何迭代都會影響到上層產品。可以很簡單的想像這個情境：當原始資料更新格式，卻沒有被妥當處理時，就會連帶影響後續的加工資料、模型、以及輔助決策。更麻煩的事情，每個下層資料產品都可能會被多個上層資料產品使用，當有需求會改動到下層資料產品時，都需要特別小心意想不到的 side effect。
由於自動化機制反應速度都比人類快許多，更需要考慮當自動決策失誤時可能造成的風險，來決定自動化的程度以及標準。例如推薦系統如果發生問題，頂多就是造成一些商業損失；反之，如果自動駕駛發生問題，可能會造成嚴重的人命損失。
從以下自動駕駛的分級來看就很清楚，風險越高的控制，會先以輔助決策為主、自動化的標準也越高；風險越低的也就越容易優先自動化。
iThome鐵人賽
看影片追技術