https://yennj12.js.org/yennj12_blog_V4/tags/recommendation/Recent content in Recommendation on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 20 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part3-realtime-recommendation-zh/Mon, 20 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part3-realtime-recommendation-zh/大部分人做推薦系統:離線跑個協同過濾,把結果算好塞進一張表,前端去查。上線第一天很香,第三天發現使用者剛剛看過、剛剛買過的東西還一直被推——因為推薦是「昨天算好的」,而使用者是「此刻在變的」。 真正的個人化推薦難在「即時」:使用者這一秒點了什麼,下一個畫面就要反映。這要求你把「離線訓練的模型」跟「線上即時的特徵」接起來,而且兩邊算特徵的邏輯必須一模一樣,否則線上線下不一致,模型準確度直接崩。 AWS 原生的解法:Kinesis 收即時事件、Feature Store 同時服務線上/離線且保證一致、SageMaker Endpoint 毫秒級推論、DynamoDB 撐高併發查詢。 這是 Part 3:當 AI 系統要在「使用者還在線上」的當下做決策時,架構長什麼樣。 一、情境與痛點:個人化的即時性 推薦系統無所不在:電商的「你可能也喜歡」、影音的「接下來播放」、新聞的資訊流、外送 App 的餐廳排序。它的商業價值最直接——推得準,轉換率、停留時間、GMV 直接漲。 但「推得準」有一個常被低估的維度:即時性(recency)。 使用者剛把一台筆電加入購物車 → 下一頁還在推同一台筆電,體驗很蠢。 使用者剛看完一部恐怖片 → 首頁應該立刻多一點同類,而不是等明天的批次。 使用者是新用戶,沒有歷史 → 冷啟動,你拿什麼推? 這帶出推薦系統最核心的工程難題,不是模型,而是特徵的即時性與一致性: 離線訓練時: 用「過去 30 天的行為」算出特徵 → 訓練模型 線上服務時: 用「此刻的即時行為」算出特徵 → 餵給同一個模型 如果兩邊算特徵的邏輯不一致(training-serving skew), 模型在線上看到的特徵分佈,跟它訓練時看到的不一樣 → 準確度崩盤。 這就是為什麼推薦系統不是「訓練一個模型」那麼簡單,而是要蓋一整套特徵基礎設施。 二、系統目的:功能與非功能需求 功能需求: 收集即時行為事件(點擊、瀏覽、加購、購買、停留時長)。 即時更新使用者特徵(近期偏好、即時 session 行為)。 給定 user,回傳個人化排序後的推薦清單(Top-N)。 支援冷啟動(新用戶 / 新商品)。 支援 A/B 測試:多個模型版本並行,分流量比較效果。 非功能需求: 面向 目標 為什麼 線上延遲 P99 < 100ms 推薦要嵌在頁面載入路徑上 特徵一致性 線上/離線特徵零 skew 否則模型準確度不可信 即時性 行為 → 特徵更新 < 數秒 「剛剛看過」要立刻反映 併發 尖峰數萬 QPS 首頁流量 可實驗 模型可灰度、可 A/B、可秒級回滾 推薦是持續迭代的 「P99 < 100ms」+「特徵零 skew」這兩條,是整個架構的靈魂。前者逼你用線上特徵快取 + 低延遲 endpoint;後者逼你用同一套特徵定義同時服務訓練與推論——這正是 SageMaker Feature Store 存在的理由。