摘要： AWS 團隊在 2026 年 9 月說明一套以 Amazon Bedrock 打造的儀表板內容驗證系統，用來捕捉基礎設施正常但畫面空白、過期或數字不一致的沉默故障。文章指出視覺檢查每小時執行、數字驗證由確定性程式碼負責比較，平均偵測時間從最長 72 小時降到 1 小時以內。
會議開始前五分鐘，有人打開報表，看到的卻是一張空白的圖表；然而基礎設施監控顯示一切正常，伺服器沒有中斷、API 照常回應、資料管線也準時跑完。真正壞掉的是「內容層」，這正是傳統監控照不到的地方。凡是靠儀表板做決定的團隊，多半都碰過這種場面。
2026 年 9 月，AWS 的 BI 與分析團隊發表了一篇部落格文章，說明他們如何以 Amazon Bedrock 打造一套大規模的「最後一哩」內容驗證系統。系統每小時巡檢數百個儀表板，抓出空白、過期或有誤的視覺元素，同時檢查數字彼此是否一致。上線之後，平均偵測時間由原本最長 72 小時降為 1 小時以內。
內容層驗證為何不能省略
基礎設施監控能回答服務是否還「活著」，卻回答不了畫面上呈現的內容對不對。AWS 團隊在文章中列出兩類傳統監控捕捉不到的失敗：
- 沉默的視覺故障：上游服務一切正常，儀表板區塊卻可能呈現空白、過期資料或錯誤狀態。他們在 30 天內偵測到 802 次內容故障（包括權限錯誤、篩選器跳過紀錄、渲染問題），其中有用戶主動回報的比例不到 1%。
- 未被發現的數字不一致：圖表畫得出來、外表看不出異狀，數字卻是錯的。舉凡篩選器設定有誤、彙總邏輯寫錯、更新時間對不上，都會讓畫面端出錯誤數據。一旦這些數據被餵進 AI 敘事系統，錯誤便會直接左右高階主管的決策。
AWS 團隊也特別說明，這套做法並非要取代 CloudWatch Synthetics 或資料層驗證，它鎖定的是「BI 呈現層」這個尚未補上的缺口。
五階段架構：從排程一路到告警
系統採無伺服器架構，五個階段全部建立在 AWS 代管服務之上，兩次驗證週期之間可以縮到零成本。
-
區段登錄與排程：視覺檢查由 Amazon EventBridge 每小時觸發一次，數字驗證則跟著每週的資料更新啟動。所有受監控區段的設定都存放在 Amazon Redshift。
-
截圖捕捉：視覺檢查由 AWS Lambda 調度無頭瀏覽器，重現使用者實際看到的畫面。數字驗證則需要 agentic browser automation，因為 agent 得親自操作儀表板、套用指定的篩選器。
截圖存入之前會先經過 Amazon Rekognition 的 redaction 處理，把所有文字和數字遮掉，以免敏感資料留在 S3 或 CloudFront。
-
AI 分析：核心階段，兩條驗證機制在此平行運作。
- 視覺內容驗證：由 Anthropic Claude 模型（透過 Amazon Bedrock）檢視截圖，找出空白區塊、錯誤狀態與缺失的視覺元素。當中最棘手的，是分辨「空狀態」屬於正常（篩選器確實篩不到資料）還是故障（管線錯誤造成空白）。模型輸出被限制成結構化的 verdict 與信心分數；碰上模糊地帶就轉交人工審查，不會自動觸發告警。
- 數字交叉驗證：同一個指標往往散落在不同儀表板上，標籤與格式卻各不相同。LLM 的任務是定位指標、讀出數值與單位；至於「比較」一律交由確定性程式碼負責——單位正規化（$1.2B vs $1,200M）與小數精度（58.484 vs 58.5）都包含在內。
-
告警路由：視覺故障一經確認，系統便以 Slack Block Kit 通知該區段負責人，訊息附上截圖、信心分數與調查連結；若故障持續不退，會自動開出 ticket。數字不一致的案例則彙整成報告，交由人工審查。
-
遙測儲存：分析結果寫回 Redshift，用於歷史趨勢分析；系統本身的健康狀況則由 CloudWatch 監控。
從生產環境學到的兩個要點
文章最後，AWS 團隊分享了兩項把系統從 prototype 推向 production 的原則：
先設計對抗 false positives。告警系統最大的敵人就是「狼來了」——假警報一多，負責人乾脆忽略通知。真正難判的並非明顯壞掉的頁面，而是那些模糊案例：區塊之所以空白，可能只是篩選器組合確實沒有資料。為此他們選擇讓每項檢查慢一點，換取更準確的判斷。以每小時一輪的監控而言，準確性和可解釋性遠比即時性重要。
別讓 LLM 做算術。數字驗證最初的設計是兩層 LLM：一個 agent 負責提取和比較數值，另一個 judge agent 獨立核對結果。問題在於 LLM 套用比較規則時並不穩定——什麼時候該四捨五入、容忍度要抓多少、不同單位怎麼處理——這些都不適合交給模型。最終的作法是把 LLM 限定在語意理解（找出指標、讀出數值），數值判斷全部交給確定性程式碼。
值得借鏡的設計思路
這套架構真正可觀之處，不在於用了多先進的模型，而在於它把「AI 該做什麼」與「程式碼該做什麼」分得清清楚楚：需要語意理解的視覺判斷交給 LLM，需要精確度的數字比較交給確定性邏輯。再加上截圖先 redact、輸出結構化、模糊結果轉人工，每一項設計都是為了讓系統在生產環境中可靠運作。
若你也在建置類似的驗證系統，這篇文章至少能給你三個重點：先把「沉默故障」的具體樣貌定義出來、把 AI 侷限在真正需要判斷力的任務上、並且把 false positive 當成首要敵人。說到底，一個沒人信任的監控系統，比沒有監控更糟。