M1
異常／品質訊號
沒有主動監控，只能被動發現。
數據缺乏主動監控；一旦活躍度或轉換表現下滑，通常要等到人為發現才開始處理。已知資料品質訊號也缺少一致、可回溯的證據格式，調查品質容易依賴個人經驗。
LEON LAI · BUSINESS-FIRST AWS SA PORTFOLIO
一套雲端系統架構， 解決四個實際營運痛點。
以 Serverless 為主的設計，建構於資料共用、權限邊界與成本控制之上，解決異常偵測、實驗運營、臨時分析與合作夥伴整合支援問題。
Synthetic data · Verified PoC · 不宣稱 production workload 經驗
01 / 07
THE OPERATING REALITY
雲端 AI 技術鏈接實務痛點
針對過去重複耗損資源的四大情境，進行架構設計與 PoC 驗證。
M2
實驗運營
並行實驗的狀態存在每個人的腦中。
不同產品體驗的 A/B testing 同時進行時，沒有中央化方式查看並行實驗狀態，得一個一個問人，或等到站會才知道。
這個核心問題同時還伴隨兩個次要、但會持續增加營運成本的問題：
- SRM、guardrail 依賴人工抽查，異常實驗停止有延遲。
- 相同 data feature 因為由不同組員負責而重複開發。
M3
臨時分析
Dashboard 回答不了突然出現的「為什麼」。
Dashboard 可以回答固定問題，但當老闆、業務或客戶突然詢問「今天核心指標為什麼掉了？」時，現有 dashboard 往往無法直接回答。
這類提問通常伴隨急迫性，又會在不可預期的時間出現，進一步加重分析人員的工作負擔；當客戶數量增加，問題頻率也會隨之上升。
M4
整合支援
重複的整合問題消耗支援與工程資源。
不同時區的合作夥伴經常詢問相似的 API 驗證、Webhook、環境設定、服務更新與維護資訊；常見問題需要反覆回覆，複雜案件則占用工程團隊時間。
02 / 07
SYSTEM SHAPE & BOUNDARIES
三條工作流共用資料湖；第四條走獨立知識路徑。
整合統一資料定義、多租戶隔離與 RAG 輔助決策的完整系統型態。
END-TO-END DATA FOUNDATION
資料生成、治理與發布路徑
DATA PREPARATION
Amazon S3Bronze · Raw JSON
→
Athena CTASSchema cast · 清理 · 可重跑轉換
→
Amazon S3Silver · Typed Parquet
→
PUBLISHED GOLD DATA PRODUCTS
gold_daily_kpiDaily operations
gold_hourly_kpiHourly guardrails
cohort_retentionMature cohorts
entity_featuresAnalysis / ML
Publication marker 驗證完整版本
AUTOMATION & DECISION PATHS
四個模組如何消費資料並交付結果
DETECT
使用異常與品質訊號偵測
EventBridge → Lambda → Athena → SNS
每日活躍度、每週留存與雙訊號品質檢查；告警自動觸發 M3 first-look，需要判讀的紀錄另交人工審查。
ALERT + EVIDENCEEXPERIMENT OPS
實驗生命週期與安全停止
API Gateway → DynamoDB → Step Functions
Lambda 執行 assignment、SRM、guardrail、analysis 與 readout；Gold features 與 registry state 一起決定實驗是否繼續。
SRM hard fail · hourly guardrail · allocation kill switchINVESTIGATE
受治理問答與事件初判
API / SNS → Bedrock → Athena SQL
Guardrails 與 allow-listed templates 限制問題範圍；所有數字由 SQL 產生，無法回答的工作寫入 DynamoDB ticket。
Grounded answer · first-look report · durable ticketCURATED DOCUMENTSVersioned integration guidance
→
INTEGRATION SUPPORT
身份隔離的整合支援
IAM → Relevance → Bedrock Guardrails → Code validator
IAM 身份先限定可用的支援知識；問題通過範圍與安全檢查後才產生回答，資訊不足時要求澄清，不支援的問題則拒絕回答或建立 OPEN ticket。DELIVERYAnswer / Clarify / OPEN ticket不讀取 Gold tables · SNS/SQS 僅作帳號內稽核
USERS
OPSOperations
ANAnalytics
PDProduct
IPIntegration
⇄
GOVERNED INTERFACESDashboard · API · Reports · Integration support
→
HUMAN-OWNED OUTCOMESInvestigate · Decide · Escalate · Validate
Implemented integration
Human decision / escalation
M4 不讀取 Gold tables；它與資料工作流共用控制原則，但不是同一條資料管線。
03 / 07
SYSTEM OWNS REPETITION · PEOPLE OWN JUDGEMENT
四個工作流，改變四種人的工作方式。
每張卡依序說明：原本怎麼做、系統接手什麼、人保留什麼決策，以及這條工作流如何運行。
M1 · DETECTION
KPI 異常與已知品質訊號
原本怎麼做
依賴人主動查看報表，發現下滑後才開始追查；已知資料品質訊號的調查證據也不一致。
系統接手
每日檢查活躍度與互動量的異常模式；每週檢查成熟的 D1／D7 cohort 留存，並附上 baseline、threshold 與證據。
人保留決策
判斷根因、採取營運處置；需要判讀的紀錄進入人工審查，不由系統自動下結論。
M3 · NL ANALYTICS
Analytics NL Assistant
原本怎麼做
突發的 what／why 問題打斷分析師；得先算過去常態是多少、再拆開看是哪幾款產品出問題，最後交叉比對各個相關變數之間是哪裡出錯。
系統接手
允許清單 SQL 回答 what；first-look 與 diagnose 組合證據回答 why；答不了就建 ticket。
人保留決策
判讀營運脈絡、確認根因，並決定後續處置。
M2 · EXPERIMENT OPS
實驗運營平台
原本怎麼做
並行實驗狀態散落在人與站會中；SRM、guardrail 靠人工抽查，共用 feature 重複開發。
系統接手
中央註冊表、IAM 身分權限歸屬、數據品質檢查（SRM）、安全護欄監控、緊急熔斷開關與共享特徵註冊表。
人保留決策
決定假設、指標、是否採納結果，以及異常實驗後的產品處置。
M4 · INTEGRATION SUPPORT
受治理的整合支援
原本怎麼做
合作夥伴反覆詢問相似的整合與服務資訊；複雜問題常在缺少結構化脈絡時直接占用工程資源。
系統接手
系統先以 IAM 確認合作夥伴身份，再檢查問題是否屬於可支援範圍。合格問題由受限制的知識內容與 AWS Bedrock 產生回答；資訊不足時要求澄清，範圍外問題則明確拒絕。
人保留決策
只有需要產品／工程判斷、或安全驗證未通過的案件才建立 OPEN ticket 供人工接手。目前 PoC 將工單存進 DynamoDB，尚未串接 Email、Slack 或 CRM 通知。
04 / 07
FOUR CHAPTERS · TWO MINUTES
兩分鐘實機操作：四組工作流實際運行
實際開啟四組模組介面，操作問題觸發條件並呈現 AWS 自動處置結果。
05 / 07
SYSTEM DESIGN TRADE-OFFS & COST OPTIMIZATION
系統設計取捨與成本最佳化。
從使用頻率、延遲需求與服務完整度三個問題，決定現階段最合適的 AWS 能力；量測條件改變時再升級。
01
WORKLOAD ECONOMICS
依照現有使用頻率，該如何選擇運算模式？
目前的省錢／輕量做法
狀況：現在資料量很小，且使用者只是偶爾查一次。
做法：採用「用多少算多少」或「沒人用就自動降為 0 費用」的元件（例如 Lambda、Athena）。像 Kinesis 這種持續按小時收費的即時串流元件，現在只做短暫展示，不長期開著燒錢。
何時需要調整？
當未來出現持續高併發查詢（幾百個人同時在查）、穩定大流量，或商業上要求低於 1 分鐘的即時資料處理時。
👉 升級動作：這時才正式引入長期開著的 Redshift（大型資料倉庫）、EMR（大數據 Spark 集群）或 Persistent Kinesis（長期資料串流）。
02
DATA ACCESS PATTERN
目前需求需要即時服務，還是批次處理就足夠？
目前的省錢／輕量做法
狀況：目前資料／特徵只是拿來做批次分析（例如每天跑一次分析），而且合作夥伴的文檔庫很小，直接整包塞進 AI 提示詞處理就好。
做法：現階段不需要額外架設即時服務系統與向量檢索系統。
何時需要調整？
當未來前端應用（例如推薦系統）要求毫秒級的即時特徵查詢，或者公司文件量大到再也無法「整包塞給 AI」時。
👉 升級動作：這時才正式引進 SageMaker Feature Store 與 OpenSearch／Vector Store。
03
MANAGED WORKFLOW VS CONTROL
該直接用現成的 AI 套裝工具，還是自己開發並掌握控制權？
目前的控制優先做法
狀況：PoC 階段需精細控管安全性。
做法：採用窄範圍的自訂流程，親自寫程式碼展示 SQL 白名單過濾、數據權限歸屬、多租戶隔離以及敏感數據遮蔽。
何時需要調整？
當未來要推廣給非技術團隊，需要完整的 BI、視覺化報表、企業內部搜尋、內容維護與權限管理介面時（工程團隊不想自己從頭刻 UI 與權限系統）。
👉 升級動作：這時才正式引進 Amazon Quick 與 Amazon Q Business。
06 / 07
THREE IMPLEMENTATION TRAPS
分享實作中遇到的三個小坑。
01AWS
設定 row filter，不代表租戶真的被隔離。
當初天真的假設
在 AWS Lake Formation 設了列級過濾器後，每個客戶就只能看到自己的資料。
IAM_ALLOWED_PRINCIPALS
Glue Table 的向下相容設定和 Athena 可以直接存取 S3 的權限，讓這個過濾器形同虛設。
架構修正
把 Glue Table 上預設的 IAM_ALLOWED_PRINCIPALS 權限移除，拿掉分析師帳號直接讀取 S3 檔案的權限，並使用正向／反向邏輯的雙重驗證。
租戶隔離的資安測試只有在走後門也失敗時，才算真正生效。
02DATA
同一個異常，第一天會響，第三天可能不再響。
當初天真的假設
只要 DAU 持續低迷，EWMA detector 就會持續認為它異常。
2026-06-10 · DAY 1
DAU 91 vs baseline 204
約 3.9σ → ALERT
→
2026-06-12 · DAY 3
2 個低迷日已進入 window
baseline 下移、標準差擴大 → NO ALERT
架構修正
將目前 detector 明確定義為 onset detection：負責盡早觸發第一次調查，不假裝它同時管理持續事件狀態；production 若要持續告警，需另保留不會適應的 reference baseline。
偵測「事件開始」與追蹤「事件仍在發生」是兩個不同問題。
03AI
Prompt 說不能洩漏，模型仍然洩漏了。
當初天真的假設
以為只要在 System Prompt 裡面下達明確指令，LLM 就能 100% 聽話、不會洩漏內部機密。
MODEL OUTPUT · INTERNAL AUDIT ONLY
“Document ID: [internal identifier]”
validation: internal_identifier_leak · fallback: true
架構修正
導入確定性驗證器：在 AI 產生的文字發送給客戶之前，先經過一道用傳統程式碼寫死的驗證過濾器；只要掃描到違規內容就自動調整。
讀寫分離的稽核路徑：完整的洩漏證據只保留在內部安全的 Log 中供工程師除錯，不發給外部使用者。
Prompt 只是軟性要求，程式碼驗證器才是硬性的實體邊界。
07 / 07
CLAIMS NEED EVIDENCE
工程驗證與架構文件
包含單元測試結果、AWS 成本紀錄與核心設計文件。
VERIFICATION01
169 / 169
測試通過率（100%）
離線單元測試、資安邊界與 CDK assertions
AWS COST RECORD02
$0.1156
雲端實測成本 Snapshot
2026-07-29 已部署基線的 Cost Explorer 紀錄
01
Architecture & trade-offsARCHITECTURE.md
↗
02
Cost evidence & scale modeldocs/cost-analysis.md
↗
03
Tenant isolation proofgovernance/README.md
↗
04
Designs changed by testingwhat-i-got-wrong-first.md
↗
Honest scope
這是使用 synthetic data 的 verified PoC。四組 AWS 操作路徑已於 2026-08-03 實際操作驗證；PoC 雲端執行資源於 2026-08-05 完整拆除以避免閒置成本，並可由 CDK 重建。本專案不宣稱 production workload 經驗。
THE TAKEAWAY
如何在實際需求與限制中，評估並設計最合適的 AWS 服務組合。
本專案的核心價值在於：將營運痛點轉化為系統化治理、確保關鍵決策的人工主導權，並在擴充架構前，嚴格評估成本與團隊落地門檻。