PAPER DIGEST / PRACTICE LABBILINGUAL FIELD GUIDE
15 SEP 2026 · EDITION 01
Retrieval · Recommendation · Ranking

ML System
Design Practice

Microsoft AI

把模型選擇、資料設計與產品決策,說成一個完整的系統。Turn model choices, data design, and product decisions into a complete system story.

Ad relevanceMultimodalLLM & RAGAgentic systems
22完整案例worked cases6固定回答步驟answer stages45分鐘模擬面試minute rehearsal繁體中文 / English
45:00產品目標Product goals

深入研究與實作Deep dives & implementation

Amazon Product Recommendation System — ML System Design Deep Dive ↗

商品推薦:15 個深入章節、3 張原創架構圖、資料與標籤、召回/排序、實驗與 serving,以及中英口說流程。

Product recommendation: 15 deep chapters, 3 original diagrams, data and labels, retrieval/ranking, experiments and serving, plus bilingual interview scripts.

Anthropic RAG System — ML System Design Deep Dive ↗

私有文件 RAG:14 個深入章節、3 張原創架構圖、Contextual Retrieval、訓練與引用、權限、評估、serving 和中英口說流程。

Private-document RAG: 14 deep chapters, 3 original diagrams, contextual retrieval, training and citations, access, evaluation, serving, and bilingual interview scripts.

Copilot Shopping Assistant — ML System Design Deep Dive ↗

商品推薦+RAG+即時工具:14 個深入章節、重畫架構圖、互動反例與中英口說流程。

Product recommendation + RAG + live tools: 14 deep chapters, original diagrams, interactive counterexamples, and bilingual interview scripts.

01 / The conversation, before the model

每題,用同一條主線回答。One consistent story for every case.

先確認「替誰做什麼決定、怎麼知道成功」,再選模型。每一步都說出一個具體選擇、支持它的理由,以及什麼證據會讓你改變選擇。

First establish whose decision the system improves and how success will be measured. At each stage, state a concrete choice, its rationale, and the evidence that would make you revisit it.

01 · 00–05 MIN

釐清產品目標Clarify product goals

入口、使用者、決策、主指標、護欄、QPS 與延遲。

Surface, users, decision, primary metric, guardrails, QPS, latency.

02 · 05–12 MIN

資料與標籤Data & labels

一筆樣本是什麼?標籤何時成熟?如何避免洩漏?

What is an example? When is its label mature? Where could leakage occur?

03 · 12–22 MIN

Baseline/模型Baseline & models

先給 baseline,再說召回、排序、loss 與升級理由。

Baseline first, then retrieval, ranking, loss, and reasons to add complexity.

04 · 22–32 MIN

訓練與部署Training & deployment

資料流、版本、更新頻率、延遲預算、fallback、rollback。

Pipelines, versions, freshness, latency budgets, fallbacks, rollback.

05 · 32–40 MIN

離線評估/線上實驗Offline / online evaluation

時間切分、切片、主指標、分流、SRM、樣本量與成熟窗口。

Temporal splits, slices, metrics, assignment, SRM, power, label maturity.

06 · 40–45 MIN

失敗案例與取捨Failures & tradeoffs

給具體故障:怎麼發現、如何降級、何時值得增加複雜度。

Give a concrete failure, detection signal, degraded path, and complexity tradeoff.

白板最少畫兩條路徑:線上 request → features/retrieval → scoring → constraints → response;離線 events → labels → training → validation → versioned deployment。用 outcome logs 把兩者接起來。

Draw two paths: online request → features/retrieval → scoring → constraints → response; offline events → labels → training → validation → versioned deployment. Connect them through outcome logs.

可以直接練的轉場句Ready-to-rehearse transitions
  1. 「在選模型前,我想先確認我們要改善哪個決策,以及不能犧牲的護欄。」“Before choosing a model, I would clarify the decision we are improving and the guardrails we cannot compromise.”
  2. 「我會把一筆訓練樣本定義為……,並只使用決策當下已知的特徵。」“I would define one training example as … and use only features available at decision time.”
  3. 「先用這個 baseline 驗證資料;只有錯誤分析顯示需要時,才增加模型複雜度。」“This baseline validates the data pipeline. I would add complexity only when error analysis identifies a limitation it can address.”
  4. 「現在我把它放到線上:這是 critical path、時間預算,以及依賴失效時的回退方式。」“For serving, this is the critical path, its latency budget, and the fallback when a dependency fails.”
  5. 「離線改善是篩選條件;是否真的改善產品,要靠可信的線上實驗。」“Offline improvement is a screening criterion; a trustworthy online experiment establishes product impact.”
  6. 「如果這個指標改善、但護欄退化,我會先檢查……,而不是直接擴大上線。」“If the primary metric improves but a guardrail regresses, I would investigate … before expanding the rollout.”

題目名稱依提供的清單;完整題幹未取得,以下是自行定義範圍的練習方案,不代表公司內部實作、官方解答或考題預測。所有容量、候選數與延遲數字均為示範假設。來源用於支持技術概念,個別案例是綜合設計建議。

Titles follow the supplied list. Full prompts were unavailable, so these are independently scoped practice designs, not internal implementations, official solutions, or interview predictions. All scale, candidate-count, and latency figures are illustrative assumptions. References support concepts; the case designs are a synthesis.

02 / Worked cases

題目與參考回答Cases & worked answers

22 / 22

先收合答案口說,再展開對照。勾選紀錄只保存在這個瀏覽器。列印目前篩選的案例與所選語言。Close answers and rehearse first, then compare. Checkmarks are stored only in this browser. Printing includes the current case filter and selected language.

01最先練的 3 題Start with these 3Meta Ad Click PredictionAd relevance / Ranking / Calibration

設計一個在廣告曝光前預測點擊機率、支援即時排序的系統。

Design a system that predicts click probability before an ad impression and supports real-time ranking.

完整深入篇Full deep dive

14 個章節、3 張原創架構圖、曝光與標籤成熟、抽樣校準、特徵與序列模型、訓練、實驗、serving、程式碼導讀與中英口說稿。

14 chapters, 3 original diagrams, exposure and label maturity, sampling correction, features and sequence models, training, experiments, serving, code guides, and bilingual rehearsal answers.

Meta Ad Click Prediction — Deep Dive ↗

口說開場範例Spoken opening

我會先確認曝光版位、計費方式與主要目標。以下先設計 CPC 廣告的 CTR 預測:以有效曝光為樣本,預測點擊機率,並把它交給受預算、品質與使用者體驗約束的排序服務。我會從可校準的簡單模型開始,再以時間切分、分群評估與線上實驗證明較複雜模型的價值。

I would first clarify the placement, billing model, and primary objective. I will assume CPC ads and focus on predicting click probability for valid impressions. A downstream ranking service combines that estimate with bids, quality, and budget constraints. I would start with a simple calibrated model, then justify additional complexity through temporal validation, slice analysis, and an online experiment.

白板資料流Whiteboard data flow

  1. 請求與資格過濾Request & eligibility
  2. 候選廣告Ad candidates
  3. 即時特徵Online features
  4. CTR 模型與校準CTR model & calibration
  5. 預算/品質約束排序Budget / quality constraints
  6. 曝光與結果日誌Impression & outcome logs

01釐清產品目標Clarify product goals

先定義決策與目標。 問版位是搜尋廣告還是動態消息、CPC 還是 CPA、最佳化有效點擊還是轉換價值。先聚焦 CPC,CTR 是模型輸出,不是唯一產品 KPI。主指標可用每千次有效曝光收入,護欄看轉換品質、隱藏/檢舉、延遲與長期留存。

假設再估容量。 練習假設尖峰 10k requests/s,每次 200 個候選,排序服務 p95 100 ms;這代表約 2M candidate scores/s。先確認能否批次評分、特徵快取,以及候選預篩選。

Define the decision and objective. Ask whether this is search or feed advertising, CPC or CPA billing, and whether value means qualified clicks or conversions. For this exercise, use CPC. CTR is a model output, not the sole product KPI. Consider revenue per thousand valid impressions, with conversion quality, hides/reports, latency, and retention as guardrails.

State scale assumptions. Assume a peak of 10k requests/s, 200 candidates per request, and a 100 ms p95 ranking-service budget. That is about 2M candidate scores/s, motivating batched scoring, cached features, and candidate pruning. These are interview assumptions.

02資料與標籤Data & labels

樣本是曝光,不是所有廣告配對。 impression_id 連結 user/ad/context、曝光位置、候選集合、policy/model version、時間與點擊事件;重複點擊與機器流量需處理。用事先定義的點擊歸因窗口,窗口成熟後才把無點擊標成 0。

只用當時可取得的資訊。 特徵包含歷史偏好、廣告文字/圖片表示、時間、裝置與曝光前統計;做 point-in-time join。以時間做 train/validation/test,轉換另處理延遲。負例下採樣要記錄抽樣率;未曝光廣告沒有可直接觀察的點擊標籤。

Use impressions as examples. Join impression_id to user/ad/context features, position, candidate set, policy/model versions, timestamps, and click events. Deduplicate clicks and handle invalid traffic. Define a click-attribution window and only label a non-click after that window matures.

Use information available at decision time. Features include prior behavior, creative text/image representations, device, time, and pre-impression aggregates. Use point-in-time joins and chronological train/validation/test splits. Handle conversion delays separately. Record negative-sampling rates; unshown ads do not have observed click labels.

03Baseline/模型Baseline & models

先建立能解釋的 baseline。 以版位/廣告類別的平滑 CTR,加 logistic regression 或 GBDT,檢查資料與增益。大規模稀疏類別特徵再用 embedding+特徵交互模型,例如 DLRM 類設計;文字/圖片 encoder 可離線產生表示。

把目標函數說清楚。 用 binary cross-entropy 學 p(click | user, ad, context, shown)。以自然流量分布的獨立驗證集做校準。若多任務學 click/conversion/hide,要解釋 loss 權重、標籤稀疏與不同歸因窗口;不要直接把 click-conditional CVR 當成曝光轉換率。

Start with an interpretable baseline. Use smoothed CTR by placement/category, then logistic regression or GBDT to verify data quality and incremental value. For large sparse feature spaces, consider embeddings and explicit feature interactions, such as a DLRM-style model. Encode text and images offline where feasible.

Specify the learning objective. Binary cross-entropy estimates p(click | user, ad, context, shown). Calibrate on a separate validation set with natural traffic prevalence. A multitask click/conversion/hide model requires explicit loss weights and attribution windows. Click-conditional CVR is not the same as impression-level conversion probability.

04訓練與部署Training & deployment

建立兩條資料路徑。 曝光/點擊事件進串流與離線儲存,經 watermark、去重、標籤成熟與特徵驗證後訓練;近期計數更新線上 feature store。每日重訓可作起點,依 drift 與收益調整頻率。

上線要可回復。 將模型、特徵 schema、校準器一起版本化;離線回放 → shadow → 小流量 canary → A/B。特徵超時時回退到缺失值已訓練的輕量模型;預算、資格與頻控仍由約束服務執行。監控 feature age、缺失率、p95/p99、預測 CTR 與實際 CTR。

Build offline and online data paths. Impression/click streams feed durable storage, deduplication, watermarking, label maturation, and training validation. Recent counters update an online feature store. Daily retraining is a starting assumption; adjust it based on drift and measured value.

Make releases reversible. Version the model, feature schema, and calibrator together. Progress through replay, shadow traffic, a canary, and A/B testing. On feature timeouts, use a lightweight model trained to handle missingness. Eligibility, budgets, and frequency caps remain enforced. Monitor feature age, missingness, p95/p99 latency, and predicted versus observed CTR.

05離線評估/線上實驗Offline evaluation & online experiments

離線分開看排序與機率。 ROC-AUC 看整體區分能力;PR-AUC 要搭配正例率解讀;log loss、Brier score、reliability diagram 檢查機率。依版位、新廣告、裝置、地區與活躍度切片,並在原始分布評估。

線上驗證產品效果。 穩定 user-level 分流,先查 SRM、曝光與點擊日誌完整性;預先定主指標、MDE、樣本量與觀察窗。廣告預算可能造成組間干擾,必要時採 campaign/geo 層級設計。收入提升須同時通過使用者與廣告主護欄;保留快速 rollback。

Separate ranking from probability quality. ROC-AUC measures discrimination; interpret PR-AUC alongside prevalence. Use log loss, Brier score, and reliability diagrams for probability quality. Evaluate on natural traffic and slice by placement, new ads, device, geography, and activity level.

Test product impact online. Use stable user assignment, check SRM and logging completeness, and predefine the primary metric, MDE, sample size, and duration. Shared campaign budgets may create interference, requiring campaign- or geo-level designs. Revenue gains must pass user and advertiser guardrails, with fast rollback available.

06失敗案例與取捨Failures & tradeoffs

AUC 上升但收入下降: 先查校準、分群偏差、候選集合、延遲與預算消耗,不要直接重訓更大模型。新廣告沒曝光: 用內容特徵與受限探索,而非只靠 ID embedding。

主要取捨。 點擊誘餌可能推高 CTR 卻降低轉換和信任;即時特徵增加新鮮度也增加依賴與延遲。以最低必要特徵、分層 fallback、自然分布校準及探索資料減少 feedback loop。隨流量成長,先量測 feature fetch 與 embedding table 瓶頸再擴模型。

AUC rises but revenue falls: inspect calibration, slice shifts, candidate composition, latency, and budget consumption before increasing model size. New ads receive no exposure: add content features and constrained exploration rather than relying only on ID embeddings.

Main tradeoffs. Clickbait can increase CTR while hurting conversions and trust. Fresh features improve responsiveness but add dependencies and latency. Use minimal necessary features, layered fallbacks, natural-distribution calibration, and exploration data to limit feedback loops. Profile feature fetching and embedding tables as traffic grows.

深入拆解Deep dives

下採樣與機率校準Downsampling and calibration

若所有正例保留、負例以 r 的機率保留,抽樣資料預測 q 對應真實 p = r·q / (1−q+r·q)。例如 r=0.1、q=0.2,p≈0.0244。此式假設類別內隨機抽樣;不適用於任意 hard-negative sampling。可用正確 sample weights 直接學原分布,但不要再重複做同一抽樣修正;校準仍須獨立驗證。

If all positives are retained and each negative is retained with probability r, a sampled-data estimate q corresponds to p = r·q / (1−q+r·q). With r=0.1 and q=0.2, p≈0.0244. This assumes random sampling within each class, not arbitrary hard-negative mining. Correct sample weights can target the original distribution directly; do not apply the same correction twice. Validate calibration separately.

預測、價值與拍賣分層Separate prediction, value, and auction policy

簡化 CPC 期望 eCPM = 1000 × bid_per_click × pCTR,單位是每千次曝光的期望出價價值。這不是完整拍賣或實收收入公式。若轉換只能在點擊後發生,pCVR_per_impression = pCTR × p(conversion | click);若有 view-through conversion,需另定義。品質、相關性、預算 pacing 與頻控不能靠同一乘積全部解決。

A simplified CPC expected-value score is eCPM = 1000 × bid_per_click × pCTR. Its units are expected bid value per thousand impressions; it is not a full auction or realized-revenue formula. If conversion requires a click, pCVR_per_impression = pCTR × p(conversion | click). View-through conversions need a separate definition. Quality, relevance, pacing, and frequency constraints require explicit policy handling.

100 ms 如何分配?How would you budget 100 ms?

練習預算:特徵 20 ms、批次推論 40 ms、約束與回應 20 ms、預留 20 ms。這只是 critical-path 設計額度;各階段 p95 不能直接相加當成端到端 p95。以真實負載測試長尾、候選數與 cache miss,超時優先減少候選或回退輕量模型。

An illustrative budget is 20 ms for features, 40 ms for batched inference, 20 ms for constraints/response, and 20 ms of slack. These are critical-path allocations: adding stage p95 values does not produce an end-to-end p95. Load-test tail latency, candidate counts, and cache misses. Reduce candidates or fall back to a lightweight model on deadline pressure.

面試官追問 → 建議回答Follow-up questions → suggested answers

為什麼 AUC 好還需要 calibration?Why calibrate if AUC is strong?

AUC 只看相對排序;相同 AUC 的模型可以輸出差很多的機率。出價價值與預算決策依賴機率絕對值,所以必須另外驗證。

AUC depends on ordering, while bid-value and budget decisions depend on absolute probabilities. Models with identical AUC can have very different calibration.

曝光位置可以當特徵嗎?Can position be a feature?

可以建模展示條件,但必須有一致的 serving 定義;不要把舊排序位置當成內在相關性。用受控探索估計曝光傾向,必要時做偏差修正;低 propensity 會造成高方差。

It can model presentation context if serving semantics are consistent. Do not mistake the old rank position for intrinsic relevance. Controlled exploration can estimate exposure propensities; corrections require care because small propensities create high variance.

02最先練的 3 題Start with these 3Amazon Product Recommendation SystemRecommendation / Retrieval / Multimodal

設計商品推薦系統,從大量商品中選出個人化、可購買而且有幫助的推薦。

Design personalized recommendations that select useful, purchasable products from a large catalog.

完整深入篇Full deep dive

15 個章節、3 張原創架構圖:資料與成熟標籤、特徵工程、item-to-item、two-tower、精排、實驗與 serving,附程式碼導讀與中英口說稿。

15 chapters and 3 original diagrams: data and mature labels, feature engineering, item-to-item, two towers, ranking, experiments, and serving, with code guides and bilingual rehearsal scripts.

Amazon Product Recommendation System — Deep Dive ↗

口說開場範例Spoken opening

我會先限定一個推薦入口,例如首頁商品列,並把目標定為促成滿意的購買,而不是只增加點擊。系統採多路召回、精排與約束重排;先用熱門與 item-to-item 建 baseline,再評估雙塔檢索和多任務排序。我會特別處理曝光偏差、冷啟動與庫存新鮮度,並用線上購買與退貨護欄驗證效果。

I would scope this to one surface, such as a homepage recommendation shelf, and optimize for satisfactory purchases rather than clicks alone. The design uses multiple candidate sources, a ranker, and constrained reranking. I would establish popularity and item-to-item baselines before adding two-tower retrieval and multitask ranking. Exposure bias, cold start, and inventory freshness are central, with purchases and return-related guardrails validating online impact.

白板資料流Whiteboard data flow

  1. 使用者/sessionUser / session
  2. 多路候選召回Multi-source retrieval
  3. 去重與資格過濾Deduplication & eligibility
  4. 多任務精排Multitask ranking
  5. 多樣性與庫存檢查Diversity & inventory check
  6. 推薦與曝光記錄Recommendations & logs

01釐清產品目標Clarify product goals

先限定 surface。 首頁、商品詳情頁、購物車的意圖不同;這題假設首頁個人化商品列。問是否混合贊助內容、登入/匿名比例與推薦更新速度。主指標可用每位使用者的成熟有效訂單;護欄看取消/退貨、滿意度、長期回訪與延遲。

容量假設。 10M 商品、尖峰 5k requests/s、p95 150 ms;召回合併至約 1k 候選,輕排至 200,精排選出 20。實際數量由 recall–latency 曲線決定,不是固定標準。

Scope the surface first. Homepage, product-detail, and cart recommendations express different intents. Assume a personalized homepage shelf. Ask about sponsored content, anonymous traffic, and freshness requirements. A primary metric might be matured valid orders per user, with cancellations/returns, satisfaction, repeat visits, and latency as guardrails.

State scale assumptions. Assume 10M products, 5k peak requests/s, and 150 ms p95. Merge roughly 1k candidates, pre-rank to 200, and select 20. Tune these counts using recall–latency curves rather than treating them as fixed rules.

02資料與標籤Data & labels

分清行為的含義。 記錄 request_id、候選/展示商品、位置、click/cart/order/return、時間與模型版本;只有顯示後無互動才可當弱負例,未展示商品屬未知。購買比點擊稀疏,退貨標籤更晚成熟,需多個標籤窗口。

建立可重現樣本。 特徵用 request 前的購物歷史、session、類別、價格、圖片/文字與庫存快照;不能讀取未來價格或購買後屬性。時間切分並保留新商品/新用戶測試集;同商品變體與重複 listing 要正規化。

Distinguish behavioral signals. Log request_id, candidate and displayed items, positions, clicks, carts, orders, returns, timestamps, and model versions. Displayed-but-ignored items are weak negatives; unshown items are unknown. Purchases are sparser than clicks, and returns mature later, requiring separate label windows.

Make examples reproducible. Use pre-request history, session intent, category, price, text/image features, and inventory snapshots. Do not use future prices or post-purchase attributes. Split chronologically and retain cold-user/item slices. Normalize product variants and duplicate listings.

03Baseline/模型Baseline & models

兩階段模型有不同任務。 先用熱門、同類別與 item-to-item 共購產生候選;再加雙塔 user/session encoder 與 item encoder,以對比或 sampled-softmax 目標學可快速檢索的向量。in-batch negatives 可能是假負例,需考慮熱門度抽樣偏差與同商品變體。

精排用更豐富的交互。 GBDT 或 deep ranker 學 click、cart、purchase、return 等目標;依可解釋的效用組合與硬性約束重排。retrieval 的 dot product 不是購買機率;圖片+文字可補新商品特徵,但高品質 metadata baseline 應先量測。

Give retrieval and ranking distinct jobs. Start with popular items, category candidates, and item-to-item co-purchase signals. Add a two-tower user/session and item model using a contrastive or sampled-softmax objective. In-batch negatives may be false negatives; account for popularity-driven sampling and product variants.

Use richer interactions in ranking. A GBDT or deep ranker predicts clicks, carts, purchases, and returns. Combine these through an explicit utility function and hard constraints. Retrieval dot products are not purchase probabilities. Image/text representations can help new items, but first measure a strong metadata baseline.

04訓練與部署Training & deployment

版本一致的 embedding 與 ANN。 離線產生商品向量,更新主索引;新商品用增量索引,定期合併。user tower、item tower 與 index 必須是相容版本,切換時原子更新並保留上一版。特徵、模型與 index 都可回滾。

新鮮度分層。 商品描述可低頻更新,session 意圖用串流,價格/庫存讀取有明確 TTL 的權威服務;候選生成時先過濾,輸出前再次檢查,不能把舊庫存寫死在 embedding。ANN 故障回退到可購買的熱門/最近瀏覽候選。

Version embeddings and ANN indexes together. Generate item vectors offline, maintain a main index plus incremental updates, and compact periodically. User/item towers and the index must be compatible; switch atomically and retain the previous version. Features, models, and indexes all need rollback paths.

Separate freshness requirements. Descriptions change slowly, session intent updates via streams, and price/inventory comes from an authoritative service with explicit TTLs. Filter during retrieval and recheck before output. Do not encode live stock as a permanent embedding property. Fall back to eligible popular or recently viewed items on ANN failure.

05離線評估/線上實驗Offline evaluation & online experiments

分層診斷。 用已知相關商品量測候選 Recall@K,再量測精排 NDCG@K、purchase log loss 與 calibration;檢查 catalog coverage、類別多樣性與冷啟動切片。ANN recall 是相對 exact-nearest-neighbor 的近似精度,與行為相關性的 retrieval recall 不同。

A/B 以 user 為單位。 預設樣本量與實驗時長,先查 SRM;看 orders/user 與增量收益,同時等待取消/退貨成熟。若只是把首頁購買搬到另一個入口而非新增,要用整體使用者指標辨識 cannibalization。

Diagnose by stage. Measure candidate Recall@K against known relevant items, then ranker NDCG@K, purchase log loss, and calibration. Check catalog coverage, diversity, and cold-start slices. ANN recall measures agreement with exact nearest-neighbor search; it is different from relevance recall.

Randomize by user. Predefine power and duration, check SRM, and measure orders per user and incremental value while allowing cancellation/return labels to mature. Whole-user metrics help distinguish additional purchases from moving purchases between surfaces.

06失敗案例與取捨Failures & tradeoffs

新使用者: 用上下文、session、熱門與可選偏好;新商品: 用 metadata/圖文表示與受限探索。過度個人化: 重排加入類別/品牌多樣性、避免重複商品與已不需要的耐久財。

主要取捨。 ANN 召回速度對長尾 recall;更大 ranker 對延遲;即時行為對噪音與隱私。先分析是「好商品沒召回」還是「召回後排錯」,再投資對應階段。以探索與跨時段評估減少熱門度 feedback loop。

New users: use context, session behavior, popularity, and optional preferences. New products: use metadata, image/text representations, and constrained exploration. Overspecialization: add category/brand diversity and suppress duplicates or no-longer-needed durable goods.

Main tradeoffs. ANN speed competes with long-tail recall; larger rankers compete with latency; real-time behavior adds both freshness and noise. Determine whether useful items were missed by retrieval or misordered after retrieval before investing. Exploration and temporal evaluation help limit popularity feedback loops.

深入拆解Deep dives

記憶體與請求成本估算Memory and request-cost estimates

10M × 128 維 × 2 bytes(FP16)= 2.56 GB 原始向量,尚未包含 ANN 圖、metadata、replica 與暫存空間。5k requests/s × 200 精排候選 = 1M scores/s。以實測每 batch 延遲、硬體吞吐和容錯餘裕推導容量,不能用向量大小直接推估整個服務 RAM。

10M × 128 dimensions × 2 bytes for FP16 gives 2.56 GB of raw vectors, excluding ANN structures, metadata, replicas, and workspace. At 5k requests/s and 200 final-ranker candidates, demand is 1M scores/s. Derive capacity from measured batch latency, hardware throughput, and failover headroom, not raw-vector size alone.

為什麼不是一個模型排全部商品?Why not score every product with one model?

10M 商品逐一做昂貴 cross-feature 計算太慢。雙塔能預先算商品向量,快速找候選;精排則對少量候選使用 user–item 深度交互。代價是兩階段最佳化不完全一致,且召回漏失無法由 ranker 補救,因此要追蹤各召回來源的 coverage 與增量價值。

Expensive cross-feature scoring over 10M products is impractical per request. Two towers permit precomputed item vectors and fast retrieval; the ranker spends richer user–item interactions on a small candidate set. The objectives may differ, and a ranker cannot recover omitted items, so measure coverage and incremental value by candidate source.

如何處理負樣本?How would you sample negatives?

檢索可混合 random、in-batch 與 hard negatives,排除已知正例與重複商品;評估抽樣分布是否偏熱門。精排優先使用同次曝光集合的成熟結果,並區分無互動與明確不喜歡。曝光偏差需額外探索資料或有假設條件的 propensity correction;不是換一種 loss 就消失。

Retrieval can mix random, in-batch, and hard negatives while excluding known positives and duplicates. Inspect popularity bias in sampling. Ranking should use matured outcomes from impression sets and distinguish non-interaction from explicit dislike. Exposure bias requires exploration data or assumption-dependent propensity correction; a new loss alone does not remove it.

面試官追問 → 建議回答Follow-up questions → suggested answers

Recall@1000 很高,購買仍下降?Recall@1000 is high, but purchases fall. Why?

先查 ground truth 是否只代表舊策略、精排和校準是否退化,再看缺貨/價格、展示位置、延遲與多樣性。若商品進了候選卻未展示,是排序或約束問題,不必先換 retriever。

Check whether relevance labels only reflect the old policy, then inspect ranking, calibration, inventory, prices, presentation, latency, and diversity. If useful items enter candidates but are never displayed, investigate ranking or constraints before replacing retrieval.

03最先練的 3 題Start with these 3Anthropic RAG SystemRetrieval / LLM / Groundedness

設計一個能回答私有文件問題、提供可驗證引用並隨資料更新的 RAG 系統。

Design a RAG system that answers questions over private documents with verifiable citations and fresh knowledge.

完整深入篇Full deep dive

14 個章節、3 張原創架構圖:資料與標籤、hybrid/contextual retrieval、訓練 loss、引用與權限、評估與 serving,附 6 個互動案例、程式碼導讀及中英口說稿。

14 chapters and 3 original diagrams: data and labels, hybrid/contextual retrieval, training losses, citations and access, evaluation and serving, with 6 interactive scenarios, code guides, and bilingual rehearsal scripts.

Anthropic RAG System — Deep Dive ↗

口說開場範例Spoken opening

我會先確認文件種類、更新頻率、使用者權限與無答案時的行為。先建立 BM25 加引用的簡單基準,再逐步加入 dense retrieval、fusion 與 reranking。整個系統要分開評估檢索和生成,將權限檢查放在生成之前,並把引用綁定到文件版本與片段;證據不足時明確說明缺口。

I would clarify document types, update frequency, access permissions, and expected behavior when an answer is unavailable. I would establish a BM25-and-citations baseline, then add dense retrieval, fusion, and reranking when evaluation supports them. Retrieval and generation need separate evaluation. Authorization happens before generation, citations identify source versions and spans, and insufficient evidence leads to an explicit limitation or clarification.

白板資料流Whiteboard data flow

  1. 文件解析與版本/ACLParse, version & ACL
  2. 分塊與雙索引Chunk & dual index
  3. 權限過濾的 hybrid retrievalAuthorized hybrid retrieval
  4. Fusion 與 rerankFusion & reranking
  5. 證據與生成Evidence & generation
  6. 引用/拒答檢查Citation / abstention checks

01釐清產品目標Clarify product goals

界定答案契約。 問文件格式/語言、是否含表格、更新頻率、跨文件問題比例及權限模型。輸出要回答問題並附來源;無可用證據時澄清或拒答。主指標是有證據支持的任務完成率,護欄是權限違規、錯誤陳述、延遲與成本。

區分兩種延遲。 練習假設 1M chunks、100 queries/s、p95 first-token 2 s、完整答案 8 s;限制答案長度與工具次數。串流能改善 first-token 體感,不能當成整體生成變快的證據。

Define the answer contract. Ask about formats, languages, tables, update frequency, cross-document reasoning, and permissions. Answers must address the question and cite evidence; missing evidence should trigger clarification or abstention. Optimize supported task completion, with authorization violations, false claims, latency, and cost as guardrails.

Separate latency measures. Assume 1M chunks, 100 queries/s, a 2 s p95 time to first token, and 8 s to completion. Bound answer length and tool calls. Streaming improves responsiveness but does not prove lower total generation latency.

02資料與標籤Data & labels

文件是可追溯資產。 每個 chunk 保存 doc_id、version、章節/頁碼、原文 offset、updated_at、tenant_id 與 ACL。沿段落/標題切塊,表格保留欄名和單位;chunk overlap 與大小由 eval 調整。刪除/撤權要傳播到索引與 cache。

建立有困難案例的 gold set。 收集真實問題、相關片段、必要事實、可接受答案、無答案與權限負例;按文件家族與時間切分避免重複內容洩漏。LLM 合成問題可補 coverage,但需人工抽查,且不能只用同一模型自問自答自評。

Make documents traceable assets. Store doc_id, version, section/page, source offsets, updated_at, tenant_id, and ACL for each chunk. Respect headings and paragraphs; preserve table headers and units. Tune chunk size and overlap through evaluation. Propagate deletions and permission revocations to indexes and caches.

Build a challenging gold set. Include real questions, relevant spans, required facts, acceptable answers, unanswerable cases, and access-denied cases. Split by document family and time to avoid near-duplicate leakage. Synthetic questions can expand coverage, but need human auditing and independent evaluation.

03Baseline/模型Baseline & models

先證明 retrieval。 Baseline 用 BM25+固定 prompt+引用。Dense embeddings 補語意,BM25 保留型號、縮寫與精確字詞;以 Reciprocal Rank Fusion 合併,再用 cross-encoder rerank 少量候選。不同來源分數尺度不一致,不要直接相加。

生成只接收有權且相關的證據。 Prompt 要求以 evidence 作答、保留來源 ID、承認不足;引用再映射至原文。可先固定 generator 做 retriever ablation。只有當代表性標註資料足夠且錯誤分析支持時,才 fine-tune retriever/reranker;RAG 不要求先微調 LLM。

Prove retrieval first. Start with BM25, a fixed prompt, and citations. Dense embeddings add semantic matching; BM25 preserves exact identifiers and terms. Fuse ranks with Reciprocal Rank Fusion, then rerank a bounded candidate set with a cross-encoder. Do not directly add incompatible score scales.

Generate from authorized, relevant evidence. Require source IDs and acknowledgment of missing evidence, and map citations back to source spans. Hold the generator fixed for retrieval ablations. Fine-tune retrievers/rerankers only when representative labels and error analysis justify it; RAG does not require LLM fine-tuning.

04訓練與部署Training & deployment

索引與服務分離。 內容 hash 支援去重與增量更新;索引 snapshot 可回復,embedding 版本一致。Query-time 先確認身分、tenant 與 ACL,再過濾與檢索;重排前/回傳前再次檢查撤權。ACL 要在搜尋範圍內生效,避免只事後過濾導致 recall 崩落。

控制失效邊界。 Cache key 包含權限範圍、query、文件/index 版本;撤權使 cache 失效。檢索/模型 timeout 時回傳有權來源或說明無法完成。文件內容視為資料,不能授權工具或修改系統指令;記錄 retrieval、prompt、model、citation 與每段 latency 的 trace。

Separate indexing from serving. Content hashes support deduplication and incremental updates. Keep reversible index snapshots and consistent embedding versions. Authenticate and enforce tenant/ACL restrictions during search, then recheck revocations before reranking/output. Pure post-filtering can severely reduce recall.

Bound failures. Cache keys include permission scope, query, and document/index versions; revocations invalidate caches. On retrieval/model timeout, return authorized sources or explain that the answer could not be completed. Treat documents as data, not authorization to call tools or change instructions. Trace retrieval, prompt/model versions, citations, and stage latency.

05離線評估/線上實驗Offline evaluation & online experiments

建立可歸因評估。 Retrieval 看 evidence Recall@K、MRR/nDCG、空結果率及 ACL-filtered recall。Generation 看答案正確性、claim-level groundedness、引用正確率/覆蓋率、拒答 precision/recall;引用存在不代表內容被支持。固定 retrieval 比 generator,再固定 generator 比 retrieval。

線上看完成而非只看讚。 A/B 量測任務完成、重新提問、人工轉接、成本、TTFT 與完整答案時間。LLM-as-judge 使用明確 rubric,與人工標註校準、盲測並分析語言/長度偏差;高風險錯誤要人工複核。

Make evaluation attributable. Retrieval metrics include evidence Recall@K, MRR/nDCG, empty-result rate, and recall after ACL restrictions. Generation metrics include correctness, claim-level groundedness, citation precision/coverage, and abstention precision/recall. A citation being present does not mean it supports a claim. Isolate retrieval and generator changes in ablations.

Measure completion online. Test task success, reformulations, escalation, cost, TTFT, and full-response time. Calibrate an LLM judge against human labels with an explicit rubric, blinded comparisons, and language/length bias checks. Human-review consequential errors.

06失敗案例與取捨Failures & tradeoffs

找到對文件卻答錯: 檢查 chunk 邊界、表格單位、互相矛盾版本與 context 使用;找不到文件: 檢查索引、權限 filter、query rewrite 與 BM25/dense 各自 recall。

主要取捨。 更大 K 提升可能 recall,卻增加噪音、token 與 latency;rerank 增加精度與成本。遇到最新價格或庫存,不依靠舊文件,改查權威 API。提示注入、資料過期與答案拼湊都需專門測試,不能把低 temperature 當成防幻覺保證。

Correct document, wrong answer: inspect chunk boundaries, table units, conflicting versions, and context use. Missing evidence: inspect ingestion, ACL filters, query rewriting, and separate BM25/dense recall.

Main tradeoffs. Larger K can increase recall but also noise, tokens, and latency. Reranking trades cost for precision. Live price or inventory requires authoritative APIs rather than stale documents. Test prompt injection, outdated evidence, and unsupported synthesis explicitly; low temperature is not a guarantee against hallucination.

深入拆解Deep dives

證據要有版本與位置Evidence needs versions and spans

回答「保固兩年」時,引用應指向 product_manual v3 的特定段落,而不是只給網站首頁。驗證兩件事:來源是否真的包含該資訊,以及該來源是否適用於問題的商品/時間/地區。來源互相衝突時顯示差異或依事先定義的權威排序,不由 LLM 任意猜選。

For a claim such as “two-year warranty,” cite a specific span of product_manual v3, not a homepage. Verify both that the source supports the claim and that it applies to the product, time, and region in question. Surface conflicting evidence or follow a predefined authority hierarchy instead of letting the model guess.

Hybrid retrieval 的可計算說法A concrete hybrid-retrieval explanation

RRF(d) = Σ 1 / (c + rank_i(d)),未出現在某一路結果則那一路不貢獻分數;c 是調整常數。練習可從 BM25 100+dense 100 合併去重,rerank 50,再選 8 個片段,但 K、c、chunk size 都要以品質/延遲 ablation 決定。保留同一文件的必要上下文,避免八個片段只是同一句的重複。

RRF(d) = Σ 1 / (c + rank_i(d)); a source contributes nothing when d is absent from its list. The constant c controls rank sensitivity. An illustrative setup retrieves 100 BM25 and 100 dense results, reranks 50 deduplicated candidates, and selects 8 chunks. Tune K, c, and chunk size through quality/latency ablations, and avoid filling context with duplicates.

何時加 agent?When would you add an agent?

單次文件問答先用固定流程。只有需要自適應地查詢多個來源、澄清需求或呼叫即時工具時,才加入有步數、成本與時間上限的 controller。工具 schema 要嚴格驗證;購買等有副作用動作需使用者確認與冪等鍵。把成功率按「檢索、工具、推理、輸出」分解。

Use a fixed workflow for straightforward document questions. Add a bounded controller when the task requires adaptive source selection, clarification, or live tools. Enforce step, cost, and time limits; validate tool schemas. Purchases and other side effects require user confirmation and idempotency keys. Decompose failures into retrieval, tools, reasoning, and output.

面試官追問 → 建議回答Follow-up questions → suggested answers

為什麼不直接換更大的 LLM?Why not simply use a larger LLM?

先用 oracle evidence 測試。如果給正確片段後小模型就能回答,瓶頸在 retrieval;若有正確證據仍失敗,才調 prompt、context 或 generator。

Test with oracle evidence. If the smaller model answers correctly once given the right spans, retrieval is the bottleneck. If it still fails, investigate the prompt, context, or generator.

04第一優先補強Priority extensionsFacebook News Feed RankingRecommendation / Ranking / Experimentation

設計個人化動態消息排序,兼顧相關性、內容品質與長期使用者價值。

Design a personalized feed balancing relevance, content quality, and long-term user value.

口說開場範例Spoken opening

我會把一次 feed request 定義為排序單位,先確定有價值互動的定義與負面護欄。候選來自追蹤關係與推薦內容,經多階段排序與多樣性重排。核心難點是舊曝光策略造成的偏差,以及短期互動與長期滿意度的衝突。

I would define a feed request as the ranking unit and clarify valuable engagement and negative guardrails. Candidates come from followed accounts and recommended content, followed by staged ranking and diversity constraints. The main challenges are bias from the previous exposure policy and the conflict between short-term engagement and long-term satisfaction.

白板資料流Whiteboard data flow

  1. 關係/興趣候選Graph / interest candidates
  2. 安全與資格Safety & eligibility
  3. 輕排Pre-ranking
  4. 多目標精排Multi-objective ranking
  5. 多樣性/頻控Diversity / frequency caps
  6. Feed 日誌Feed logs

01釐清產品目標Clarify product goals

問是好友 feed、公開內容還是混合;時間順序是否是可選 baseline。主指標用有價值互動或調查校準的滿意度,保護 hide/report、內容安全與留存。先假設 p95 200 ms、每次輸出 20 則,並定義 freshness。

Clarify whether the feed contains friends, public content, or both, and whether chronological ordering is a baseline. Optimize valuable engagement or survey-calibrated satisfaction, with hide/report, safety, and retention guardrails. Assume 20 items and a 200 ms p95 budget for practice, with an explicit freshness requirement.

02資料與標籤Data & labels

記錄可視曝光而不只下發、位置、停留、分享、hide、report;停留時間可能是困惑而非滿意。用 request-time 特徵與時間切分;未被看見的下方內容不能當強負例。保留舊策略 propensity 與受控探索資料。

Log viewable impressions, not only served items, plus position, dwell, shares, hides, and reports. Dwell can indicate confusion rather than satisfaction. Use request-time features and chronological splits; unseen items lower in the feed are not strong negatives. Retain policy propensities and controlled exploration data.

03Baseline/模型Baseline & models

Baseline 是時間衰減+關係強度,接著 GBDT/多任務 deep ranker 預測有意義互動與負面反應。候選源包含好友、興趣、熱門;精排後依作者/主題多樣性與安全規則重排。多目標權重須有可解釋效用與線上驗證。

Start with recency decay and relationship strength, then a GBDT or multitask deep ranker for valuable actions and negative feedback. Mix friend, interest, and trending candidates. Apply author/topic diversity and safety constraints after ranking. Objective weights need an interpretable utility definition and online validation.

04訓練與部署Training & deployment

串流更新近期互動,離線學長期興趣;高流量作者避免全量 fan-out,可混合預算候選與 request-time 檢索。服務快取候選、批次評分;舊內容刪除需立即失效。超時回退到已過濾的時間序 feed。

Stream recent interactions and learn long-term interests offline. Avoid unconditional fan-out for very high-fanout authors; combine precomputed candidates with request-time retrieval. Cache candidates and batch scoring. Invalidate deleted content promptly, and fall back to an eligible chronological feed on timeout.

05離線評估/線上實驗Offline evaluation & online experiments

離線看分任務 log loss、NDCG、分群 calibration、作者 coverage;反事實估計需 propensity 支持,不能假設可完全消除偏差。線上 user-level A/B 查 SRM,量測滿意度、留存與負面互動;社交互動外溢可能需 cluster 設計或另量干擾。

Offline, evaluate per-task log loss, NDCG, slice calibration, and creator coverage. Counterfactual estimates require propensity support and do not automatically eliminate bias. Online, check SRM and measure satisfaction, retention, and negative actions. Social spillovers may require cluster designs or explicit interference analysis.

06失敗案例與取捨Failures & tradeoffs

高停留內容可能聳動;熱門作者會越來越熱門。採受限探索、曝光集中度監控、多樣性與品質護欄。若離線提升但留存下降,按候選源、作者、新用戶與長短內容切片,檢查效用是否獎勵錯誤行為。

High dwell can reward sensational content, and popular creators can become increasingly dominant. Use constrained exploration, concentration monitoring, diversity, and quality guardrails. If offline gains hurt retention, slice by source, creator, new users, and content length to find misaligned incentives.

面試官追問 → 建議回答Follow-up questions → suggested answers

為什麼不只最大化 watch time?Why not maximize watch time alone?

它偏好長內容,也可能獎勵低品質黏著。需加入內容長度校正、負面訊號與獨立滿意度/留存證據。

It favors long content and can reward low-quality engagement. Add length-aware analysis, negative signals, and independent satisfaction/retention evidence.

05第一優先補強Priority extensionsPinterest Visual SearchMultimodal / Retrieval / Ranking

設計以圖片或局部物件搜尋相似且相關商品的系統。

Design image- or object-based search for visually similar and relevant products.

口說開場範例Spoken opening

我會先區分找同一個商品、找同類商品與找風格靈感。圖片相似不一定符合購買需求,因此我會用視覺 embedding 做召回,再利用類別、文字、屬性與可購買性重排,分別評估檢索與最終結果。

I would distinguish exact-product matching, category similarity, and style inspiration. Visual similarity alone may not satisfy shopping intent. I would retrieve with visual embeddings and rerank with category, text, attributes, and purchasability, evaluating retrieval and final relevance separately.

白板資料流Whiteboard data flow

  1. 圖片/選取區域Image / selected region
  2. 物件裁切與 encoderObject crop & encoder
  3. 向量候選Vector candidates
  4. 屬性/圖文重排Attribute / multimodal rerank
  5. 去重與資格Deduplication & eligibility
  6. 結果Results

01釐清產品目標Clarify product goals

問輸入是整張圖還是可框選物件、是否要 exact SKU、支援哪些類別。主指標是 query 成功率/相關結果互動,護欄是無結果率與延遲。練習先限商品圖,p95 300 ms;多物件時讓使用者選目標。

Clarify whole-image versus selected-object input, exact-SKU requirements, and supported categories. Optimize successful queries and relevant interactions, with no-result rate and latency guardrails. For practice, scope to product images and 300 ms p95; let users select an object in multi-object scenes.

02資料與標籤Data & labels

收集 query–商品 relevance、同款/同類/風格標籤、點擊曝光與圖文對;對近重複圖片與同商品家族做群組切分。hard negatives 要包含外觀近似但材質/功能不同的商品;圖文描述可能缺漏或錯標。

Collect query–item relevance, exact/category/style labels, impression clicks, and image–text pairs. Split by near-duplicate image and product family. Include hard negatives that look similar but differ in material or function, and audit missing or incorrect descriptions.

03Baseline/模型Baseline & models

Baseline 用預訓練視覺 encoder+ANN;再比較 CLIP 類圖文對齊 encoder、domain contrastive fine-tuning 與 crop-level 表示。精排融合顏色、材質、文字與類別。若使用圖關係,可把 PinSage 類表示視為補充候選源,而非假設視覺相似等於圖相近。

Start with a pretrained visual encoder and ANN. Compare image–text aligned encoders, domain contrastive fine-tuning, and crop-level representations. Rerank using color, material, text, and category. Graph-based representations such as PinSage-style embeddings can add candidates, but graph proximity is not identical to visual similarity.

04訓練與部署Training & deployment

商品向量離線編碼,query 線上編碼;模型與索引成對升版。GPU batch 需受 deadline 限制;cache 常見圖片 hash,壞圖/低解析度要回報或退回文字搜尋。增量處理新商品並刪除失效品項。

Encode catalog items offline and queries online, versioning encoders and indexes together. Bound GPU batching by request deadlines. Cache common image hashes; handle corrupt/low-resolution images explicitly or offer text search. Incrementally index new products and remove invalid items.

05離線評估/線上實驗Offline evaluation & online experiments

分 exact match 與 semantic relevance 看 Recall@K、mAP/NDCG;另量 ANN recall、類別與膚色/光線/背景切片。線上 A/B 看成功搜尋與商品互動,監控推論成本、p95/p99、無結果率;只看相似度分數沒有產品意義。

Evaluate exact matching and semantic relevance separately with Recall@K, mAP/NDCG, plus ANN recall and category/lighting/background slices. Audit relevant representation differences such as skin tone for applicable image categories. Online, test successful searches and product interactions with cost, tail-latency, and no-result guardrails.

06失敗案例與取捨Failures & tradeoffs

模型可能只看背景或品牌浮水印;用裁切、背景增強與難例驗證。視覺相似可能忽略尺寸/用途;讓文字修飾需求並用屬性約束。更大 encoder 不一定勝過更好的 crop 與標籤,先做 ablation。

The model may exploit backgrounds or brand watermarks; test crops, background augmentation, and hard cases. Similar appearance can hide size/function differences, so allow text refinements and attribute constraints. Better crops and labels may outperform a larger encoder; verify through ablations.

面試官追問 → 建議回答Follow-up questions → suggested answers

找相同鞋款與找相似風格共用同一模型嗎?Should exact-shoe search and style search share a model?

可以共享 backbone,但 relevance 標籤、loss 或 reranking 權重不同;先分意圖評估,再決定多頭模型或不同檢索路徑。

They can share a backbone, but need different relevance labels, objectives, or reranking weights. Evaluate by intent before choosing multiple heads or retrieval routes.

06依方向補強Specialized practiceOpenAI Distributed TrainingTraining / Infrastructure / Efficiency

設計可靠、有效率且可恢復的大型模型分散式訓練平台。

Design a reliable, efficient, recoverable distributed training platform for a large model.

口說開場範例Spoken opening

我會先確認模型大小、序列長度、token 量、GPU 記憶體與網路拓撲,再用單卡或小規模訓練建立正確性基準。擴展順序由記憶體和 profiler 決定:先資料平行,必要時分片模型狀態,再考慮 tensor 或 pipeline parallel。成功標準是達到目標品質的時間與成本,包含故障恢復。

I would establish model size, sequence length, token budget, GPU memory, and network topology, then build a correctness baseline on one device or a small cluster. Profiling and memory limits determine the scaling strategy: data parallelism first, sharded state when necessary, then tensor or pipeline parallelism. Success means time and cost to target quality, including recovery from failures.

白板資料流Whiteboard data flow

  1. 版本化資料 shardsVersioned data shards
  2. 可重現 dataloaderReproducible loaders
  3. 分散式 workersDistributed workers
  4. 梯度同步/optimizerGradient sync / optimizer
  5. 分片 checkpointSharded checkpoints
  6. 驗證與模型 registryValidation & registry

01釐清產品目標Clarify product goals

問 pretraining 或 fine-tuning、dense 或 MoE、目標 loss、完成期限、硬體與網路。SLO 是 time-to-quality、cost-to-quality、有效 tokens/s 與恢復時間,不只 GPU utilization。先指定 global batch 與 token 計數規則。

Clarify pretraining versus fine-tuning, dense versus MoE, target loss, deadline, hardware, and interconnect. Optimize time/cost to quality, useful tokens/s, and recovery time rather than GPU utilization alone. Define global batch size and token accounting.

02資料與標籤Data & labels

資料做去重、品質篩選、來源/版本記錄與 held-out contamination 檢查;next-token labels 由序列位移產生,padding 要 mask。跨 rank 的 sampler 要避免重複與遺漏;保存 shuffle seed、資料游標與已消耗 tokens。

Deduplicate and filter data, track provenance/versions, and check held-out contamination. Derive next-token labels by shifting sequences and mask padding. Distributed sampling must avoid unintended duplication or omissions. Save shuffle seeds, data cursors, and consumed-token counts.

03Baseline/模型Baseline & models

小模型 FP32/可靠精度做 correctness baseline,再比較 mixed precision。DDP 複製狀態;FSDP/ZeRO 分片減少每卡狀態記憶體但增加通訊;tensor parallel 適合高頻寬互連,pipeline parallel 要處理 bubble。global batch = microbatch × gradient accumulation × data-parallel world size。

Establish a small-model reference at a reliable precision, then compare mixed precision. DDP replicates state; FSDP/ZeRO shard it at communication cost. Tensor parallelism favors fast interconnects; pipeline parallelism introduces bubbles. Global batch equals microbatch × accumulation steps × data-parallel world size.

04訓練與部署Training & deployment

Profile compute、collectives、dataloader 與 I/O;採 activation checkpointing 以重算換記憶體。checkpoint 要包含模型、optimizer、scheduler、RNG、資料游標及分片 metadata;使用完整性 manifest,驗證 restore 才算成功。故障時整個同步 group 一致重啟,避免不同 ranks 使用不同步數。

Profile compute, collectives, data loading, and I/O. Activation checkpointing trades recomputation for memory. Save model, optimizer, scheduler, RNG, data cursor, and shard metadata with a completeness manifest. A checkpoint is useful only after a tested restore. Restart synchronous groups consistently after failures to avoid rank-step divergence.

05離線評估/線上實驗Offline evaluation & online experiments

離線比较相同資料/有效 batch 下的 loss trajectory、梯度與下游品質,再看 tokens/s/GPU、scaling efficiency、MFU 與 dollar/token。線上層面以叢集 canary job、受控負載與故障注入比較成功率與 cost-to-quality;訓練平台本身不適合硬套點擊 A/B。模型上線另做產品實驗。

Compare loss trajectories, gradients, and downstream quality with matched data and effective batches, then measure tokens/s/GPU, scaling efficiency, MFU, and cost/token. Validate the platform with cluster canaries, controlled workloads, and failure injection. A training platform does not need a click-rate A/B test; deployed model behavior gets its own product experiment.

06失敗案例與取捨Failures & tradeoffs

OOM:先確認參數/optimizer/activation 各占多少;NaN:檢查資料、溢位、loss scaling 與學習率;擴卡無加速:找 collective、straggler 或 I/O 瓶頸。更多分片會增加通訊,頻繁 checkpoint 會增加 I/O;以失敗頻率、保存成本與可接受重算量決定間隔。

For OOM, separate parameter, optimizer, and activation memory. For NaNs, inspect data, overflow, loss scaling, and learning rate. Poor scaling may come from collectives, stragglers, or I/O. Sharding adds communication; frequent checkpoints add I/O. Choose checkpoint intervals from failure frequency, save cost, and acceptable recomputation.

深入拆解Deep dives

記憶體估算要講假設State memory-estimation assumptions

以傳統 mixed-precision Adam 粗估:FP16 參數 2 bytes、FP16 gradient 2、FP32 master weights 4、兩個 FP32 moments 8,合計約 16 bytes/parameter;不同實作不一定有 master copy 或相同 gradient dtype。7B 參數約 112 GB 狀態,尚未含 activations、通訊 buffer 與碎片。ZeRO/FSDP 可以分片部分或全部狀態,實際峰值需量測。

A conventional mixed-precision Adam estimate is 2 bytes for FP16 parameters, 2 for gradients, 4 for FP32 master weights, and 8 for two FP32 moments: roughly 16 bytes/parameter. Implementations differ in master copies and gradient dtypes. A 7B model therefore has about 112 GB of such state before activations, buffers, and fragmentation. ZeRO/FSDP can shard state, but peak memory must be measured.

面試官追問 → 建議回答Follow-up questions → suggested answers

為什麼 tokens/s 增加,訓練反而更貴?Why can higher tokens/s still cost more?

可能用了更多 GPU、收斂需要更多 tokens,或故障重算更多。比較達到同一品質的總 GPU-hours、成本與時間。

More GPUs, worse convergence, or more failed-work replay can offset throughput gains. Compare total GPU-hours, cost, and elapsed time to the same quality target.

07依方向補強Specialized practiceByteDance Cost-Optimize PipelineEfficiency / LLM / Infrastructure

練習假設:設計降低 ML/LLM 推論成本的 pipeline,同時維持品質與服務 SLO。

Practice assumption: design an ML/LLM inference pipeline that reduces cost while preserving quality and service SLOs.

口說開場範例Spoken opening

這個題名很廣,我會先問成本主要來自訓練、資料還是推論。以下先聚焦線上 LLM 推論:建立每次成功任務的成本基準,再用 cache、模型路由、batching 與量化逐一做受控比較。每個省成本方案都要通過品質與尾延遲護欄。

The title is broad, so I would ask whether cost comes from training, data, or inference. I will focus on online LLM inference: establish cost per successful task, then compare caching, routing, batching, and quantization in controlled steps. Every saving must pass quality and tail-latency guardrails.

白板資料流Whiteboard data flow

  1. 請求分類Request classification
  2. 權限安全 cachePermission-aware cache
  3. 難度/模型路由Difficulty / model routing
  4. 有界 batchingBounded batching
  5. 推論與驗證Inference & validation
  6. 品質/成本 telemetryQuality / cost telemetry

01釐清產品目標Clarify product goals

定義品質最低門檻、p95/p99 latency、流量尖峰與可用硬體。主指標用 cost/successful task,拆 token、GPU idle、cache、network 與人工重試成本;單看每 token 便宜可能掩蓋失敗重試。

Define minimum quality, p95/p99 latency, peak traffic, and hardware. Optimize cost per successful task, decomposing token, idle GPU, cache, network, and retry/review costs. Cheap tokens can hide expensive failed tasks.

02資料與標籤Data & labels

收集 request shape、input/output tokens、queue time、TTFT、完成時間、模型/cache 路徑、硬體與成功標籤。將敏感內容最小化記錄。代表性 replay set 要含長 context、罕見語言、尖峰和困難題,不能只用容易 cache 的流量。

Log request shape, token counts, queue time, TTFT, completion time, route, hardware, and success labels, minimizing sensitive content. Replay sets must include long contexts, rare languages, peaks, and hard tasks rather than only easily cached requests.

03Baseline/模型Baseline & models

Baseline 是固定模型與標準 serving。先 profile 再改:exact/prefix cache、較小模型處理簡單任務、量化/蒸餾、限制無用 tokens。router 以成功品質與成本為目標,低 confidence 升級;semantic cache 需驗證答案適用性與權限。

Baseline a fixed model and standard serving. Profile before changing exact/prefix caching, small-model routing, quantization/distillation, or unnecessary output length. Train the router for quality and cost, escalating uncertain cases. Semantic caching needs applicability and authorization checks.

04訓練與部署Training & deployment

將 route policy、模型、量化設定與 cache 版本化;小流量逐項切換。動態 batching 設 queue deadline,autoscaling 看 queue depth 與 arrival rate;尖峰時降級有明確品質界線,不無限排隊。cache 失效依資料版本與權限。

Version routing policies, models, quantization, and caches; canary one change at a time. Bound dynamic-batching queues by deadlines and scale using queue depth and arrivals. Define degraded-service quality limits instead of queueing indefinitely. Invalidate caches by data and permission version.

05離線評估/線上實驗Offline evaluation & online experiments

離線用相同任務評估品質、成功率、成本與負載曲線;畫 quality–cost–latency Pareto frontier。線上穩定分流比較成功任務成本與尾延遲,按 cache hit/miss、長短請求與語言切片,包含硬體利用率及 idle 成本。

Evaluate matched tasks for quality, success, cost, and load behavior; construct a quality–cost–latency Pareto frontier. Online, compare cost per successful task and tail latency under stable assignment, sliced by cache hits, request length, and language, including idle infrastructure cost.

06失敗案例與取捨Failures & tradeoffs

大 batch 提升吞吐但增加排隊;小模型可能造成更多重試;量化可能傷特定語言或工具格式。先查總成功成本,而不是只報 GPU 數減少。若實際題目是訓練成本,改看資料效率、checkpoint、硬體利用率與 time-to-quality。

Large batches improve throughput but add waiting; small models can increase retries; quantization can damage specific languages or tool formats. Report total successful-task cost, not just fewer GPUs. If the actual scope is training, shift to data efficiency, checkpointing, utilization, and time-to-quality.

面試官追問 → 建議回答Follow-up questions → suggested answers

Router 錯把困難題交給小模型怎麼辦?What if the router sends a hard task to a small model?

用已驗證的低 confidence/格式失敗訊號升級,設定最多一次升級;把雙次推論成本和額外延遲計入評估,避免無限 retry。

Escalate using validated uncertainty or format-failure signals with a bounded escalation count. Include both inference passes and added latency in evaluation, avoiding retry loops.

08依方向補強Specialized practiceInstagram Visual Product TaggingMultimodal / Classification / Retrieval

設計圖片中商品的偵測、屬性辨識與 catalog tagging。

Design product detection, attribute recognition, and catalog tagging for images.

口說開場範例Spoken opening

我會先區分「找出商品區域」與「連到正確 SKU」兩個任務。系統先偵測物件,再用 crop 做 catalog 檢索與驗證;不確定時顯示類別或請使用者選擇,不直接硬配 SKU。

I would separate locating a product from linking it to an exact SKU. The system detects objects, retrieves catalog candidates from crops, and verifies matches. Uncertain cases should return a category or user choices rather than force an exact SKU.

白板資料流Whiteboard data flow

  1. 圖片Image
  2. 物件偵測Object detection
  3. Crop embeddingCrop embeddings
  4. Catalog retrievalCatalog retrieval
  5. SKU/屬性驗證SKU / attribute verification
  6. Tag 與使用者修正Tags & corrections

01釐清產品目標Clarify product goals

釐清自動標記還是輔助創作者、是否允許多商品、exact SKU 或 generic category。主指標為正確接受的標籤率,護欄為錯配率與延遲;錯連商品通常比少一個 tag 更傷信任。

Clarify automatic versus creator-assisted tagging, multiple objects, and exact SKU versus category labels. Optimize correctly accepted tags, with mismatch and latency guardrails; incorrect links can be worse than missing tags.

02資料與標籤Data & labels

需要 bounding boxes、類別、屬性、SKU 與人工修正;未標註物件不一定是背景。以商品家族/圖片群組切分,加入遮擋、長尾品牌、背景與不同視角。未見過 SKU 保留為 open-set 測試。

Collect boxes, categories, attributes, SKUs, and corrections. Unannotated objects are not necessarily background. Split by product family/image group, including occlusions, rare brands, backgrounds, and viewpoints. Reserve unseen SKUs for open-set evaluation.

03Baseline/模型Baseline & models

Baseline 為現成 detector+image embedding 檢索;再 fine-tune detector 與圖文對比模型。SKU verification 使用 crop、catalog 多角度圖、OCR 和屬性;以 confidence threshold 選擇 exact match、類別或 abstain。

Start with a pretrained detector plus image-embedding retrieval, then fine-tune detection and image–text representations. Verify SKU matches using crops, multi-view catalog images, OCR, and attributes. Threshold confidence to choose exact match, category output, or abstention.

04訓練與部署Training & deployment

圖片上傳後非同步處理可減少互動等待;catalog embedding 離線算。模型、index、taxonomy 版本一起記錄;商品下架要失效。低 confidence 進人工或使用者確認,修正回饋經審核再入訓練。

Process uploads asynchronously where possible and precompute catalog embeddings. Track model, index, and taxonomy versions; invalidate unavailable products. Route low-confidence cases to human/user confirmation and audit corrections before training on them.

05離線評估/線上實驗Offline evaluation & online experiments

離線分開看 detection mAP、attribute F1、SKU Recall@K 和 precision at coverage。線上看正確 tag 接受率、修正率及後續商品互動;用隨機人工抽樣補足「使用者沒修正不代表正確」的盲點。

Evaluate detection mAP, attribute F1, SKU Recall@K, and precision at coverage separately. Online, measure correct acceptance, corrections, and downstream interactions. Random human audits address the fact that an uncorrected tag is not necessarily correct.

06失敗案例與取捨Failures & tradeoffs

遮擋、仿品、同款不同尺寸造成 exact match 不可靠;以多候選與屬性檢查解決。提高 threshold 可減少誤配卻降低 coverage;依風險與人工容量選擇 operating point。

Occlusion, imitations, and size variants can make exact matching unreliable; use alternatives and attribute verification. Higher thresholds reduce errors but reduce coverage. Choose the operating point based on mismatch cost and review capacity.

面試官追問 → 建議回答Follow-up questions → suggested answers

Classification 與 retrieval 的差別?How does classification differ from retrieval?

類別分類有相對固定 taxonomy;catalog retrieval 面對常新增 SKU,可新增向量而不必每次重訓分類頭,但仍需未知商品拒絕能力。

Classification targets a relatively fixed taxonomy. Catalog retrieval can add new SKU vectors without retraining a class head every time, but still needs unknown-product rejection.

09依方向補強Specialized practiceTikTok Content ModerationMultimodal / Safety / Human review

設計結合文字、影像、聲音與人工覆核的內容審核系統。

Design content moderation using text, video, audio, and human review.

口說開場範例Spoken opening

我會先確認政策分類、嚴重程度與可以採取的動作。模型產生各政策的風險與不確定性,決策層依誤判成本與人工容量分流,不用一個分數決定所有內容。評估必須包含漏判、誤殺、申訴與語言差異。

I would clarify policy categories, severity, and available actions. Models estimate category-specific risk and uncertainty; a decision layer routes cases according to error costs and review capacity. One score should not govern all content. Evaluation must include misses, false positives, appeals, and language differences.

白板資料流Whiteboard data flow

  1. 上傳/串流內容Upload / stream
  2. 抽幀+ASR/OCRFrames + ASR / OCR
  3. 多模態風險Multimodal risk
  4. 政策閾值Policy thresholds
  5. 放行/限制/人工Allow / restrict / review
  6. 申訴與審核標籤Appeals & labels

01釐清產品目標Clarify product goals

問是上傳後審核、直播還是推薦前過濾;明確定義 policy taxonomy、嚴重性與處置。主指標是違規曝光 prevalence,護欄看 false-positive rate、申訴恢復率與審核 SLA;直播需要更短期限。

Clarify uploaded video, live streams, or pre-recommendation filtering. Define policy taxonomy, severity, and actions. Track violating-exposure prevalence with false-positive, successful-appeal, and review-SLA guardrails; live streams need shorter deadlines.

02資料與標籤Data & labels

使用有政策版本的多標籤人工審核、時間片段、語言與申訴結果;分歧案例保留不確定性,敏感資料控權。按創作者/近重複影片與時間切分;隨機抽樣正常流量以估真實 prevalence,不能只看檢舉資料。

Use versioned-policy multilabel annotations, time spans, languages, and appeals. Preserve uncertainty in disputed cases and restrict sensitive data. Split by creator/near-duplicate video and time. Random traffic audits estimate prevalence; reports alone are selection-biased.

03Baseline/模型Baseline & models

Baseline 用 hash/規則與單模態分類器,再比較多模態 fusion,對嚴重且稀少類別強化召回。分政策 calibration 與 threshold;不確定和高影響案例送人工,human review 是設計的一部分。

Start with hashes/rules and unimodal classifiers, then evaluate multimodal fusion. Prioritize recall for severe rare categories. Calibrate and threshold by policy, routing uncertain or consequential cases to reviewers as an explicit system component.

04訓練與部署Training & deployment

階梯式檢查:便宜過濾、重模型、人工;影片抽幀與 ASR 須有延遲預算。模型與政策獨立版本化,政策改動先回放。人工 queue 要依風險與 SLA 排序,保留理由與申訴路徑,避免故障時全部自動放行或全部刪除。

Use a cascade of cheap filters, expensive models, and human review, budgeting frame sampling and ASR. Version models and policies separately and replay policy changes. Prioritize review queues by risk/SLA, retain reasons and appeals, and define degraded behavior instead of blindly allowing or removing everything.

05離線評估/線上實驗Offline evaluation & online experiments

看 per-policy PR-AUC、recall at fixed FPR、calibration、語言/群體切片和 reviewer agreement。上線先 shadow 與人工稽核,再受限 canary;不隨意放寬嚴重內容政策做 A/B。以受控 rollout 檢驗 prevalence、申訴與處理時間。

Measure per-policy PR-AUC, recall at fixed FPR, calibration, language/group slices, and reviewer agreement. Start with shadowing and audits, then constrained canaries. Do not casually relax severe-content policy for an A/B test. Use controlled rollouts to track prevalence, appeals, and resolution time.

06失敗案例與取捨Failures & tradeoffs

反諷、引用、方言與背景音可能被誤判;需要上下文、多模態與專家標註。對抗變形與政策 drift 要更新難例集。提高 recall 會增加人工量與誤殺,因此用嚴重度、校準和容量共同決定閾值。

Sarcasm, quotation, dialects, and background audio can cause errors; use context, multimodal evidence, and expert labels. Refresh hard cases for adversarial transformations and policy drift. Higher recall increases review load and false positives, so set thresholds jointly with severity and capacity.

面試官追問 → 建議回答Follow-up questions → suggested answers

被檢舉次數可當違規標籤嗎?Can report counts be violation labels?

只能當弱訊號,可能受到曝光量與惡意檢舉影響;最終標籤需依政策審核,並用隨機抽樣檢查漏判。

Only as a weak signal: exposure volume and coordinated reporting can distort it. Policy-based adjudication and random audits are needed for reliable labels and missed-case estimates.

10依方向補強Specialized practiceYoutube Video Recommendation SystemRecommendation / Retrieval / Ranking

設計大規模影片推薦,兼顧使用者滿意度、探索與內容新鮮度。

Design large-scale video recommendations balancing satisfaction, discovery, and freshness.

口說開場範例Spoken opening

我會用候選生成和排序兩階段處理大目錄,並把推薦目標定義為滿意的觀看體驗。watch time 是訊號,但需搭配跳出、不感興趣與滿意度,避免只推薦長片。新影片與 session 意圖會透過內容特徵和即時更新處理。

I would separate candidate generation from ranking to handle a large catalog and optimize satisfying viewing experiences. Watch time is useful but needs early abandonment, dislikes, and satisfaction measures to avoid favoring long videos. Content features and real-time session updates handle new videos and changing intent.

白板資料流Whiteboard data flow

  1. 觀看/sessionHistory / session
  2. 多源召回Multi-source retrieval
  3. 安全與資格Safety & eligibility
  4. Watch/satisfaction rankerWatch / satisfaction ranker
  5. 多樣性重排Diversity rerank
  6. 曝光與觀看事件Impression & viewing logs

01釐清產品目標Clarify product goals

先分首頁與「接著看」;主指標可用滿意觀看 session,guardrail 是不感興趣、早退、安全與留存。定義時長與觀看完成度如何影響價值,不把總分鐘數當唯一成功。

Distinguish homepage from “up next.” Optimize satisfying viewing sessions, with not-interested actions, abandonment, safety, and retention as guardrails. Define how duration and completion contribute to value rather than using total minutes alone.

02資料與標籤Data & labels

記錄可視曝光、play、watch duration、seek、skip、survey 與影片長度;自動播放不等於主動興趣。時間切分、排除未來觀看歷史,依長短片、新創作者與語言建 slices;survey 缺失可能有偏差。

Log viewable impressions, plays, duration, seeks, skips, surveys, and video length. Autoplay is not active preference. Split chronologically, exclude future history, and slice by duration, new creators, and language. Survey responses may be selection-biased.

03Baseline/模型Baseline & models

Baseline 為熱門+co-watch;召回用 two-tower/序列表示,ranking 學觀看與滿意度多目標。用內容 embeddings 補新片,session context 表示當前意圖;重排處理重複作者、已看內容與探索。

Start with popularity and co-watch. Use two-tower or sequence representations for retrieval and multitask viewing/satisfaction ranking. Content embeddings support new videos and session context captures current intent. Rerank for repeat creators, previously viewed items, and exploration.

04訓練與部署Training & deployment

離線更新影片向量與模型,串流更新近期觀看;以版本一致索引部署。支援影片刪除、安全資格與冷啟動候選。超時回退到符合資格的訂閱/熱門內容,並記錄 fallback 曝光以免污染評估。

Refresh video embeddings and models offline while streaming recent viewing. Deploy compatible index versions, support deletions and eligibility, and maintain cold-start candidates. On timeout, serve eligible subscription/popular content and log fallback exposure for evaluation.

05離線評估/線上實驗Offline evaluation & online experiments

離線測 Recall@K、NDCG、watch prediction error、滿意度 calibration 與新片 coverage。線上 user-level A/B 看滿意 session、留存、早退與創作者集中度;觀察跨 session 的反覆推薦疲勞。

Evaluate Recall@K, NDCG, watch-prediction error, satisfaction calibration, and new-video coverage. Online, measure satisfying sessions, retention, abandonment, and creator concentration, including fatigue across sessions.

06失敗案例與取捨Failures & tradeoffs

只看 watch time 會偏長片或聳動內容;用長度分層、多目標與品質規則。新片無互動先靠內容與受限探索;metadata 可能被操弄,須驗證內容訊號。與商品推薦相比,session sequence 和觀看深度更重要。

Watch time alone can favor long or sensational videos; use duration slices, multiple objectives, and quality constraints. New videos need content signals and constrained exploration; metadata can be manipulated. Compared with commerce, session sequence and viewing depth deserve more attention.

面試官追問 → 建議回答Follow-up questions → suggested answers

為什麼不能只用 completion rate?Why not use completion rate alone?

它容易偏短片。需把絕對觀看、相對完成度和滿意度一起看,並按長度分群評估。

It can favor very short videos. Combine absolute viewing, relative completion, and satisfaction, with duration-based slices.

11共通能力延伸Transfer practiceSpotify Music RecommendationRecommendation / Sequence / Exploration

設計符合當下情境的音樂推薦與連續播放體驗。

Design music recommendations and a coherent continuous-listening experience.

口說開場範例Spoken opening

我會先區分首頁推薦與自動續播。音樂可以反覆聽,skip 也可能只是情境不合,所以我會結合長期偏好、session 及播放序列,並讓探索量受使用者反應控制。

I would distinguish discovery shelves from autoplay. Repetition can be desirable in music, and a skip may reflect context rather than dislike. I would combine long-term preferences, session intent, and sequence context, adjusting exploration based on user response.

白板資料流Whiteboard data flow

  1. Session/偏好Session / preferences
  2. 協同+音訊召回Collaborative + audio retrieval
  3. 情境排序Context ranking
  4. 序列/藝人多樣性Sequence / artist diversity
  5. 播放 queuePlayback queue
  6. 回饋Feedback

01釐清產品目標Clarify product goals

問情境是通勤、運動或探索,是否要接續歌曲與支援離線。目標為滿意 session、save/回訪,護欄為早 skip、重複疲勞與可播放性。

Clarify commute, exercise, or discovery use, sequence continuity, and offline needs. Optimize satisfying sessions, saves, and return visits, with early skips, repetition fatigue, and playability as guardrails.

02資料與標籤Data & labels

記錄播放來源、曝光、播放秒數、skip 時點、save、repeat 與 explicit dislike;不能把所有 skip 當同等負例。按時間與藝人/版本群組測試;音訊與授權地區是商品特徵的一部分。

Log source, exposure, listening duration, skip timing, saves, repeats, and explicit dislikes. Skips are not equally negative. Evaluate temporal and artist/version slices; audio and regional availability are item features.

03Baseline/模型Baseline & models

Baseline 用常聽藝人+熱門,進階採 collaborative retrieval、audio embeddings 與 session sequence ranker。重排兼顧轉場、藝人重複與探索;歌曲重複不一定應完全禁止。

Start with favorite artists and popularity, then collaborative retrieval, audio embeddings, and session sequence ranking. Rerank for transitions, artist repetition, and discovery; repeated songs should not be universally banned.

04訓練與部署Training & deployment

預先算 track embeddings 和候選,串流更新 session;queue 預取降低播放等待。授權失效即過濾,網路失效使用已快取且可播放清單;模型升版保留 queue 一致性。

Precompute track embeddings/candidates and stream session state. Prefetch queues to reduce playback gaps. Filter unavailable tracks promptly and use playable cached queues during outages. Preserve queue consistency across releases.

05離線評估/線上實驗Offline evaluation & online experiments

離線看下一首 Recall@K、skip prediction、save calibration 和 discovery coverage。線上 A/B 看滿意 session、save、早 skip 與回訪,按新歌/老歌、情境與使用者活躍度切片。

Offline, measure next-track Recall@K, skip prediction, save calibration, and discovery coverage. Online, test satisfying sessions, saves, early skips, and repeat visits by new/old tracks, context, and user activity.

06失敗案例與取捨Failures & tradeoffs

音訊相似不等於心情適合;過度探索打斷 session,過少探索讓推薦僵化。使用可控探索比例、情境訊號與明確 dislike;不要把熱門度直接當個人偏好。

Acoustic similarity may not fit the listener's mood. Too much exploration disrupts sessions; too little becomes repetitive. Use controlled exploration, context, and explicit dislikes without equating popularity with preference.

面試官追問 → 建議回答Follow-up questions → suggested answers

Repeat 是正例還是負例?Is a repeat positive or negative?

主動重播通常是喜好,自動 queue 重複可能是系統造成;標籤要包含播放來源與使用者動作。

Intentional replay often signals preference, while an automatically repeated queue may be system-induced. Labels need playback provenance and user actions.

12共通能力延伸Transfer practiceNetflix Recommendation SystemRecommendation / Ranking / Slate

設計串流影音首頁的內容與整列推薦排序。

Design recommendations for titles and rows on a streaming-video homepage.

口說開場範例Spoken opening

我會將首頁看成多列內容組成的 slate,而不是單一影片清單。除了單一 title 分數,還要處理列之間的重複與主題覆蓋;開始播放與最後滿意觀看是不同標籤。

I would treat the homepage as a slate of rows rather than one title list. Beyond title scores, the system must control cross-row duplication and thematic coverage. Starting a title and ultimately enjoying it are different outcomes.

白板資料流Whiteboard data flow

  1. Profile/情境Profile / context
  2. 列與 title 候選Row & title candidates
  3. Title rankingTitle ranking
  4. Row/slate optimizationRow / slate optimization
  5. 可播放性檢查Availability check
  6. 首頁Homepage

01釐清產品目標Clarify product goals

問單一 profile 還是家庭共用,目標是找到想看的內容、減少選擇時間並維持滿意度。護欄看早退、搜尋失敗與長期回訪;不要只追求點開影片。

Clarify individual profiles versus shared households. Optimize successful discovery, time to a satisfying choice, and satisfaction, with early abandonment, failed search, and retention guardrails rather than starts alone.

02資料與標籤Data & labels

記錄 row/title 曝光與位置、start、watch、completion、continue-watching 和評價。內容時長不同,完成率不能直接橫比;profile 混用與未顯示項目要分開。按時間與系列家族切分。

Log row/title impressions and positions, starts, viewing, completion, continuation, and ratings. Completion differs by duration; separate profile mixing and unshown items. Split by time and series family.

03Baseline/模型Baseline & models

Baseline 為熱門+類別+繼續觀看;候選用協同與內容 embeddings,ranker 學滿意觀看。第二層選 row 主題與順序,限制跨列重複,平衡熟悉與探索。

Start with popularity, categories, and continue-watching. Retrieve through collaborative/content embeddings and rank for satisfying viewing. A second layer chooses row themes/order, limits cross-row duplication, and balances familiarity and discovery.

04訓練與部署Training & deployment

離線預算候選與內容特徵,線上融入近期 session;按地區授權、profile 設定和內容狀態過濾。fallback 可用符合資格的熱門與繼續觀看,並維持 row 排序穩定避免畫面跳動。

Precompute candidates/content features and add recent session context online. Filter by regional availability, profile settings, and title status. Fall back to eligible popular and continue-watching rows, preserving visual stability.

05離線評估/線上實驗Offline evaluation & online experiments

離線 title NDCG 加 slate coverage/重複率,線上看成功選片、滿意觀看、早退與回訪。實驗按 profile 或 household 依干擾決定分流,避免不同家庭成員污染結果。

Evaluate title NDCG plus slate coverage/duplication, then online successful choice, satisfying viewing, early abandonment, and repeat visits. Choose profile- or household-level randomization according to interference risk.

06失敗案例與取捨Failures & tradeoffs

系列/熱門片占滿所有列會降低發現;單一 title 更好不代表整頁更好。以 slate 多樣性和跨列去重約束;共用 profile 導致偏好混雜時,降低過度個人化並引入 session context。

Popular titles or series can dominate every row. Better individual titles do not guarantee a better page. Apply slate diversity and cross-row deduplication; shared profiles may need less aggressive personalization and stronger session context.

面試官追問 → 建議回答Follow-up questions → suggested answers

為何 title NDCG 好但首頁體驗差?Why can strong title NDCG produce a poor homepage?

指標忽略列之間重複、位置與主題覆蓋;需要 slate 層級評估和線上選片結果。

It ignores cross-row duplication, presentation, and thematic coverage. Add slate-level evaluation and actual discovery outcomes.

13共通能力延伸Transfer practiceApple Notification RankingRanking / Causal inference / User experience

設計通知選擇、排序與發送時機,平衡價值與打擾成本。

Design notification selection, ordering, and timing while balancing value against interruption cost.

口說開場範例Spoken opening

我會先問哪些通知必須送達,哪些可以延後或不發。對可選通知,我要估計的是「發送相對於不發送的增量價值」,再減去打擾成本;open rate 高不代表通知有幫助。

I would distinguish mandatory notifications from those that can be delayed or suppressed. For optional notifications, the target is incremental value relative to not sending, minus interruption cost. A high open rate alone does not prove usefulness.

白板資料流Whiteboard data flow

  1. 事件候選Event candidates
  2. 必要性/偏好規則Criticality / preferences
  3. 增量價值估計Incremental-value estimate
  4. 時機與頻控Timing & caps
  5. 發送/延後/抑制Send / defer / suppress
  6. 回饋Feedback

01釐清產品目標Clarify product goals

定義通知類型、緊急程度、quiet hours 與跨裝置重複;必要提醒走獨立規則。可選通知主指標為增量有價值活動,護欄為關閉通知、打擾評價與留存。

Define types, urgency, quiet hours, and cross-device duplicates. Route essential alerts separately. Optimize incremental valuable activity for optional messages, with opt-outs, interruption feedback, and retention guardrails.

02資料與標籤Data & labels

記錄候選、是否發送、送達/可見、open、dismiss、延後與 opt-out;未送通知沒有 open 標籤。需隨機 send/no-send holdout 才能估因果 uplift,處理送達延遲與選擇偏差。

Log candidates, send decisions, delivery/visibility, opens, dismissals, delays, and opt-outs. Unsent messages lack open labels. Randomized send/no-send holdouts are needed for causal uplift; handle delivery delays and selection bias.

03Baseline/模型Baseline & models

Baseline 為偏好+頻控+時段規則,再用 response model 排序;有足夠隨機資料後才學 uplift。效用包含增量活動、打擾成本及發送限制,不以未校準開啟率直接選擇所有通知。

Start with preferences, caps, and timing rules, then a response ranker. Train uplift models once adequate randomized data exists. Utility combines incremental activity and interruption cost under constraints, rather than sending everything with a high predicted open rate.

04訓練與部署Training & deployment

線上處理事件去重、TTL 與使用者本地時間;跨裝置用 shared state 避免多發。發送 API 需冪等,排程後仍重查偏好;fallback 只依允許的規則處理,不補發已過期通知。

Deduplicate events, enforce TTLs and local time, and share state across devices. Use idempotent sends, recheck preferences at dispatch, and avoid replaying expired notifications. Fallback follows explicitly allowed rules.

05離線評估/線上實驗Offline evaluation & online experiments

離線看 response calibration 與有隨機標籤的 uplift 評估。線上 user-level holdout 看增量活動、opt-out、留存與每位使用者發送數;實驗必須保留必要通知與既有偏好。

Evaluate response calibration and uplift using randomized labels. Online, measure incremental activity, opt-outs, retention, and sends per user with stable holdouts, preserving essential notifications and user preferences.

06失敗案例與取捨Failures & tradeoffs

頻繁通知短期拉高回訪卻造成長期關閉;加入疲勞特徵與頻控。不同通知互相替代,使獨立逐則分數不準,需以每日通知組合與總打擾成本評估。

Frequent messages can increase short-term returns while causing opt-outs. Add fatigue features and caps. Notifications may substitute for one another, so evaluate daily slates and total interruption cost, not only independent message scores.

面試官追問 → 建議回答Follow-up questions → suggested answers

為什麼預測 open rate 不夠?Why is open-rate prediction insufficient?

高活躍使用者即使沒收到也可能回來;要比較發與不發的差,才知道增量價值。

Active users may return without a notification. The send-versus-no-send difference identifies incremental value.

14共通能力延伸Transfer practiceGoogle AutocompleteRetrieval / Search / Low latency

設計隨打字即時更新的查詢建議,兼顧相關性、速度與安全。

Design query suggestions that update as users type, balancing relevance, speed, and safety.

口說開場範例Spoken opening

我會先把問題定義成「給定 prefix 和情境,回傳少量可接受的完整 query」。先用 prefix index 和熱門度建立低延遲 baseline,再加入個人化與意圖排序。這個系統的 deadline 非常短,所以大模型適合離線補候選,而非每個 keystroke 都生成。

I would define the task as returning a few useful complete queries for a prefix and context. A prefix index with popularity is the low-latency baseline, followed by intent-aware personalization. Tight deadlines favor using large models for offline candidate enrichment rather than generating at every keystroke.

白板資料流Whiteboard data flow

  1. Prefix/localePrefix / locale
  2. Cache/trie 候選Cache / trie candidates
  3. 趨勢與個人化融合Trend & personalization merge
  4. 安全/隱私過濾Safety / privacy filters
  5. Top suggestionsSuggestions
  6. 選擇與搜尋結果Selection & search outcomes

01釐清產品目標Clarify product goals

問語言、拼字修正、熱門趨勢與個人化需求。練習假設 p95 50 ms server budget;主指標為省下輸入後的成功搜尋,護欄是錯誤引導、不當建議與尾延遲。

Clarify languages, typo tolerance, trends, and personalization. Assume a 50 ms server p95 budget for practice. Optimize reduced typing followed by successful search, with misleading/unsafe suggestions and tail latency as guardrails.

02資料與標籤Data & labels

收集 prefix、候選曝光、選取、最終 query 與搜尋成效;位置偏差與自動完成接受偏差需處理。私密或稀有查詢不直接進公共候選,按時間切分並測 unseen prefix。

Log prefixes, suggestion impressions, selections, final queries, and search outcomes, accounting for position/acceptance bias. Keep private or rare queries out of public candidates. Split temporally and test unseen prefixes.

03Baseline/模型Baseline & models

Baseline 是 trie/FST+頻率與時間衰減;ranker 加 locale、session 和 query quality。拼字/語意候選走有界補充路徑;安全規則獨立於 relevance score。

Start with a trie/FST, frequency, and recency decay. Add locale, session, and query-quality ranking. Use bounded typo/semantic expansion, with safety eligibility separate from relevance scores.

04訓練與部署Training & deployment

常見 prefix 放快取,熱門榜增量更新,完整 index 原子替換;採 debounce 和 request sequence ID,丟棄晚到的舊 prefix 回應。超時用本地/快取候選,空 prefix 與輸入法組字狀態需單獨處理。

Cache common prefixes, incrementally refresh trends, and atomically replace indexes. Use debouncing and request sequence IDs to discard stale responses. Fall back to cached suggestions; handle empty prefixes and IME composition separately.

05離線評估/線上實驗Offline evaluation & online experiments

離線看 MRR、Recall@K、可接受 query coverage 與不當候選率。線上量測 keystrokes saved、成功搜尋、改寫率和 latency,不能只看 suggestion acceptance。

Offline, measure MRR, Recall@K, useful-query coverage, and unsafe-candidate rate. Online, measure saved keystrokes, successful searches, reformulations, and latency rather than suggestion acceptance alone.

06失敗案例與取捨Failures & tradeoffs

熱門詞可能含噪音或被操弄;短 prefix 容易暴露不必要資訊。設匿名聚合與候選門檻,對趨勢增長做可靠性檢查;越強個人化越難快取且有隱私成本。

Popular queries may be noisy or manipulated, and short prefixes can reveal inappropriate information. Use privacy-conscious aggregation, candidate thresholds, and trend reliability checks. More personalization reduces cacheability and increases privacy complexity.

面試官追問 → 建議回答Follow-up questions → suggested answers

為什麼要丟掉較晚到達的回應?Why discard a response that arrives late?

它可能對應較短的舊 prefix;用 sequence ID 而非網路到達順序更新 UI。

It may belong to an older, shorter prefix. Update the UI by request sequence, not network arrival order.

15共通能力延伸Transfer practiceLinkedIn People You May KnowGraph / Retrieval / Recommendation

設計可能認識的人推薦,兼顧連結品質、隱私與互動負擔。

Design people recommendations that balance meaningful connections, privacy, and recipient burden.

口說開場範例Spoken opening

我會先定義成功連結:不是送出邀請就算成功,而是雙方接受並有後續價值。候選由共同聯絡人和合意的背景訊號產生,再排除封鎖與不可被推薦的人。排序要同時考慮發送者與接收者。

I would define success as a mutually accepted, useful connection rather than merely sending an invitation. Candidates come from mutual contacts and permitted contextual signals, with blocks and visibility preferences enforced. Ranking must account for both sender and recipient.

白板資料流Whiteboard data flow

  1. 合意 graph/背景訊號Permitted graph / context
  2. 兩跳/embedding 候選Two-hop / embedding candidates
  3. 隱私與封鎖過濾Privacy & block filters
  4. 雙邊排序Two-sided ranking
  5. 曝光頻控Exposure caps
  6. 連結結果Connection outcomes

01釐清產品目標Clarify product goals

問推薦入口、邀請頻率與隱私設定。主指標為接受且有後續價值的連結,護欄是忽略、封鎖、檢舉與接收者負擔;已封鎖或不可見關係必須硬過濾。

Clarify the surface, invitation frequency, and privacy settings. Optimize accepted, valuable connections, with ignores, blocks, reports, and recipient burden as guardrails. Enforce blocked/invisible relationships as hard exclusions.

02資料與標籤Data & labels

建立 recommendation exposure、invite、accept、ignore 和後續互動事件;accepted labels 有延遲,未邀請不是拒絕。以事件時間重建 graph,避免用未來連結預測過去;隱私設定變更要同步。

Record exposures, invitations, acceptance, ignores, and downstream interaction. Acceptance is delayed, and no invitation is not rejection. Reconstruct graphs as of event time to prevent future-edge leakage; propagate privacy changes.

03Baseline/模型Baseline & models

Baseline 用 common neighbors/Adamic–Adar;進階 graph embeddings/GNN 召回加 ranker 預測 invite 與 conditional accept。雙邊效用不能只偏向熱門人物;新用戶可用自願提供的背景與已匯入且允許使用的資料。

Start with common neighbors or Adamic–Adar, then graph embeddings/GNN retrieval and invite/conditional-accept ranking. Two-sided utility should not overwhelm popular recipients. Cold-start candidates can use voluntarily supplied, permitted context.

04訓練與部署Training & deployment

離線算 graph 候選、增量更新新連結;高 degree 節點需限制擴展。線上重查封鎖/隱私、頻控與已連結狀態,cache 需隨撤權失效。fallback 到合格低風險候選或空結果。

Precompute graph candidates and update new edges incrementally, bounding expansion around high-degree nodes. Recheck blocks, privacy, caps, and existing connections online, invalidating caches on revocation. Fall back to eligible candidates or an empty result.

05離線評估/線上實驗Offline evaluation & online experiments

離線看候選 Recall@K、accept calibration 與 degree/cold-start slices。線上觀察高品質連結與負面訊號;graph 干擾可能影響 user A/B,要考慮 cluster randomization 或分析外溢。

Measure candidate Recall@K, acceptance calibration, and degree/cold-start slices. Online, measure useful connections and negative signals. Graph interference may require cluster randomization or spillover analysis beyond ordinary user A/B tests.

06失敗案例與取捨Failures & tradeoffs

高 degree 人物會壟斷曝光並收到大量邀請;用接收者容量與多樣性約束。共同聯絡人可透露敏感關係,解釋文案只用允許公開的訊號;低 precision 時寧可減少推薦。

High-degree people can dominate exposure and receive excessive invitations; enforce recipient-capacity and diversity constraints. Mutual contacts can reveal sensitive relationships, so explanations must use permitted signals. Reduce recommendations when precision is low.

面試官追問 → 建議回答Follow-up questions → suggested answers

為什麼未接受邀請不能立刻標成 0?Why not immediately label an unaccepted invitation as 0?

接收者可能尚未看到;要等標籤窗口成熟,並區分送達、看到、忽略與明確拒絕。

The recipient may not have seen it. Wait for label maturity and distinguish delivery, viewing, ignoring, and explicit rejection.

16共通能力延伸Transfer practiceGmail Spam FilterClassification / Safety / Drift

設計郵件垃圾訊息過濾器,降低漏信與垃圾信干擾。

Design an email spam filter that reduces spam while preserving legitimate mail.

口說開場範例Spoken opening

我會先定義正常郵件被擋的成本與可恢復方式,然後用規則與輕量文字模型建 baseline。系統採多層風險判斷,將不確定郵件放在可復原的隔離區,並持續處理寄件者與語言的 drift。

I would define the cost of blocking legitimate mail and the recovery path, then establish rules and a lightweight text baseline. A layered risk system puts uncertain messages into recoverable quarantine and tracks sender and language drift.

白板資料流Whiteboard data flow

  1. 郵件解析Parse email
  2. 寄件者/信譽與規則Sender / reputation rules
  3. 文字/連結模型Text / link model
  4. 個人化閾值Personalized threshold
  5. Inbox/SpamInbox / spam
  6. 使用者修正Corrections

01釐清產品目標Clarify product goals

區分 spam、phishing 與 malware 的處置;主指標為 inbox 垃圾信 prevalence,護欄是合法郵件 false-positive rate、延遲與可恢復性。個人偏好不應覆寫明確的安全限制。

Separate spam, phishing, and malware actions. Track inbox spam prevalence, with legitimate-mail false positives, latency, and recoverability as guardrails. Personal preferences should not override explicit safety constraints.

02資料與標籤Data & labels

使用 report spam、not spam、人工抽查與寄件者信譽;使用者未動作不是可靠標籤。按時間和攻擊 campaign 切分,避免近重複內容落到兩邊;記錄標籤來源並保護郵件內容。

Use spam/not-spam corrections, audits, and reputation signals; inaction is not a reliable label. Split by time and campaign to avoid duplicate leakage. Track label provenance and protect message content.

03Baseline/模型Baseline & models

Baseline 用規則+TF-IDF logistic regression/Naive Bayes,再比較文字 encoder 與 header/link 特徵。依風險設閾值,對合法信誤判給較大成本;calibration 要在自然流量驗證。

Start with rules plus TF-IDF logistic regression or Naive Bayes, then evaluate text encoders and header/link features. Set risk-aware thresholds with high cost for legitimate-mail false positives; calibrate on natural traffic.

04訓練與部署Training & deployment

接收流程用低延遲模型,較重掃描可後續處理;模型、規則與聲譽獨立版本化。shadow 比較、逐步 canary,保留回復到 inbox 的機制;服務失效依既定 quarantine 政策處理。

Use fast models in delivery and heavier follow-up analysis where appropriate. Version models, rules, and reputation separately. Shadow and canary changes, preserving inbox recovery. Define quarantine behavior for service failures.

05離線評估/線上實驗Offline evaluation & online experiments

離線 PR-AUC、recall at very low FPR、per-language calibration;用人工隨機抽樣估真實錯誤。線上受控 rollout 量測 inbox spam、合法信恢復與申訴,不只看使用者回報數。

Measure PR-AUC, recall at very low FPR, and language calibration, using random audits for real error rates. Controlled rollouts track inbox spam, legitimate-mail recovery, and complaints rather than report counts alone.

06失敗案例與取捨Failures & tradeoffs

攻擊者混淆字元、寄件者輪替或資料投毒造成 drift;維護新 campaign holdout 與人工確認。嚴格 threshold 降 spam 但可能漏掉重要信,隔離與可恢復性是必要取捨。

Obfuscation, sender rotation, and poisoning cause drift; maintain new-campaign holdouts and audited labels. Stricter thresholds reduce spam but may hide important mail, making quarantine and recovery central tradeoffs.

面試官追問 → 建議回答Follow-up questions → suggested answers

Accuracy 99% 有意義嗎?Is 99% accuracy meaningful?

必須先看基準比例;垃圾信稀少時全判正常也可能很高。應看低 FPR 下 recall 與合法信損失。

Only with class prevalence. An all-legitimate classifier may score highly when spam is rare. Evaluate recall at low FPR and the cost of lost legitimate mail.

17共通能力延伸Transfer practiceStripe Real-Time Fraud DetectionClassification / Real time / Delayed labels

設計即時交易風險判斷,平衡詐欺損失、誤擋與審查成本。

Design real-time transaction risk decisions balancing fraud loss, false declines, and review cost.

口說開場範例Spoken opening

我會將問題定義為 approve、challenge、review 或 decline 的成本敏感決策。先用規則與 GBDT 建 baseline,重點放在事件時間特徵、延遲標籤和被拒交易沒有完整結果的選擇偏差。

I would frame this as a cost-sensitive choice among approval, challenge, review, and decline. I would start with rules and GBDT, focusing on event-time features, delayed labels, and missing counterfactual outcomes for declined transactions.

白板資料流Whiteboard data flow

  1. 交易請求Transaction
  2. 即時 velocity/歷史特徵Velocity / history features
  3. 風險模型Risk model
  4. 成本與政策決策Cost / policy decision
  5. 驗證/審查Challenge / review
  6. 成熟交易結果Matured outcomes

01釐清產品目標Clarify product goals

確認授權 deadline、金額分布、可用驗證動作與人工容量。主指標為含詐欺、誤擋與 friction 的總決策成本,護欄是合法交易成功率、p99 與申訴;不能只最大化攔截率。

Clarify authorization deadlines, amount distribution, verification actions, and review capacity. Optimize total decision cost including fraud, false declines, and friction, with legitimate approval, p99 latency, and appeal guardrails.

02資料與標籤Data & labels

串連 transaction_id、device、merchant、歷史 velocity、驗證結果與成熟 chargeback/審查標籤。拒付不一定都是詐欺;標籤需定義。按時間與攻擊群組切分,避免使用決策後資訊;被擋交易結果未知,不能一律當正例。

Join transaction IDs, devices, merchants, historical velocity, verification, and matured dispute/review labels. Define fraud carefully; not every dispute is fraud. Split by time and attack group, exclude post-decision information, and treat blocked outcomes as unobserved rather than automatically fraudulent.

03Baseline/模型Baseline & models

Baseline 規則+GBDT,異常偵測只作補充訊號;序列或 graph 模型須證明增量價值。校準風險機率,依金額、誤擋成本與審查容量選 action;不能對所有交易用相同成本假設。

Start with rules and GBDT; anomaly detection is an additional signal. Sequence/graph models need demonstrated incremental value. Calibrate risk and select actions using amount, false-decline cost, and review capacity rather than identical costs for every transaction.

04訓練與部署Training & deployment

串流特徵需定義 event-time window、去重和 out-of-order 行為;線上 feature store 與訓練 join 一致。逐步 shadow/canary,deadline 失效採明確風險分層政策;保存決策原因、模型版本與回溯能力。

Define event-time windows, deduplication, and out-of-order handling in streamed features. Align online features and training joins. Shadow/canary releases and use explicit risk-tier fallbacks on deadline failures. Retain reasons, versions, and auditability.

05離線評估/線上實驗Offline evaluation & online experiments

離線 PR-AUC、recall at fixed false-decline rate、amount-weighted loss 與 calibration;只用成熟標籤。線上在受控且允許的風險範圍內比較合法成功率、損失及 review load,等待損失窗口成熟,保留人工稽核。

Evaluate PR-AUC, recall at fixed false-decline rate, amount-weighted loss, and calibration on matured labels. Within permitted bounded risk, compare legitimate approvals, losses, and review load online. Wait for outcome maturity and retain manual audits.

06失敗案例與取捨Failures & tradeoffs

攻擊 drift、feature 延遲與資料投毒會降低表現;監控 feature freshness、分群風險與成熟損失。降低 false declines 可能增加 fraud;調整 challenge 路徑和審查容量,而不是只移動單一 threshold。

Attack drift, stale features, and poisoning can degrade performance. Monitor freshness, slice risk, and matured losses. Reducing false declines may increase fraud, so tune challenge paths and review capacity as well as thresholds.

面試官追問 → 建議回答Follow-up questions → suggested answers

沒有被拒交易的真實結果,如何評估?How do you evaluate declined transactions without outcomes?

承認不可辨識的反事實,利用人工審查、驗證結果與風險受限的探索補標籤;不能把 accepted-only test set 當成全流量無偏估計。

Acknowledge unobserved counterfactuals. Use reviews, verification outcomes, and bounded exploration where appropriate; accepted-only test sets are not unbiased estimates for all traffic.

19共通能力延伸Transfer practiceAirbnb Smart PricingForecasting / Optimization / Causal inference

設計提供屋主參考的住宿價格建議,兼顧收益、入住與使用者控制。

Design advisory accommodation pricing balancing revenue, occupancy, and host control.

口說開場範例Spoken opening

我會先把價格預測與價格決策分開。歷史成交價可以做 baseline,但不能直接代表最適價格;需要估計不同價格下的需求與不確定性,並讓屋主設定上下限和覆寫。

I would separate price prediction from pricing decisions. Historical booked prices are a baseline, not proof of the optimal price. We need demand estimates and uncertainty at different prices, with host limits and overrides.

白板資料流Whiteboard data flow

  1. Listing/日期/市場Listing / date / market
  2. 需求與不確定性模型Demand & uncertainty model
  3. 約束價格最佳化Constrained price optimization
  4. 屋主確認/設定Host controls
  5. 展示與訂房Exposure & bookings
  6. 成熟結果Matured outcomes

01釐清產品目標Clarify product goals

問建議價或自動調價、目標是收益還是入住率、時間 horizon 與屋主限制。主指標用每可售晚的成熟淨收益,護欄含取消、入住率、接受率與價格波動。

Clarify advisory versus automatic pricing, revenue versus occupancy goals, horizon, and host constraints. Optimize matured net revenue per available night with cancellation, occupancy, adoption, and volatility guardrails.

02資料與標籤Data & labels

收集 listing/date、當時可售狀態、曝光、價格、訂房、取消與市場情境;沒上架或屋主封鎖的日期不是需求為零。只看已訂房樣本會有 selection bias,價格與需求共同受事件影響。

Collect listing/date, availability, exposure, offered price, bookings, cancellations, and market context. Blocked/unlisted nights are not zero-demand observations. Booked-only data is selected, and events confound both prices and demand.

03Baseline/模型Baseline & models

Baseline 為相似房源季節性中位價;再建需求模型 p(book | price, context) 或多日 hazard 模型,最佳化含費用/取消的期望淨收益並加限制。觀察相關不等於價格彈性,需有識別假設或受控價格變動資料。

Start with seasonal comparable-listing medians. Model p(book | price, context), or a multi-day booking hazard, and optimize constrained expected net revenue including fees/cancellations. Observational association is not price elasticity; identification assumptions or controlled variation are required.

04訓練與部署Training & deployment

每日批次產生日期區間建議,重大活動增量更新;保存資料、模型與價格決策版本。輸出解釋、置信區間與屋主界線,缺資料時回退到保守比較價;發布前重新確認價格上下限。

Generate horizon-based recommendations daily with event-driven updates. Version data, models, and decisions. Show explanations/uncertainty and host bounds. Use conservative comparable prices when data is sparse and recheck limits before publication.

05離線評估/線上實驗Offline evaluation & online experiments

離線看需求 calibration、收入回放和 uncertainty coverage;歷史 backtest 不能證明改價後收入。線上採合適市場/listing cluster 或 switchback 設計,考慮競爭干擾與跨日預訂,待取消/住宿成熟再評估。

Evaluate demand calibration, replayed revenue, and uncertainty coverage, while acknowledging backtests cannot prove counterfactual pricing gains. Consider market/listing clusters or switchbacks online, accounting for competition and booking horizons, and wait for cancellations/stays to mature.

06失敗案例與取捨Failures & tradeoffs

新房源與活動需求不確定、價格劇烈變動傷信任;使用區間、變動幅度限制和人工覆寫。短期高價可能降低入住或長期評價;明確評估 horizon,而非只最大化下一筆交易。

New listings and events add uncertainty, while volatile prices hurt trust. Use intervals, rate-of-change bounds, and overrides. Short-term high prices may hurt occupancy or long-term value; evaluate the defined horizon rather than only the next booking.

面試官追問 → 建議回答Follow-up questions → suggested answers

為什麼「預測歷史成交價」不等於最佳定價?Why is predicting booked prices not optimal pricing?

它只學到舊政策下成功成交的價格;沒有估計其他價格的需求與未成交資料,無法直接識別收入最大值。

It learns successful prices under the old policy without identifying demand at alternatives or unbooked outcomes, so it does not identify the revenue optimum.

20共通能力延伸Transfer practiceUber ETA PredictionRegression / Spatiotemporal / Real time

設計即時抵達時間預測,處理路況變化與不確定性。

Design real-time arrival-time prediction under changing traffic and uncertainty.

口說開場範例Spoken opening

我會先確認是叫車等待時間、接人 ETA 還是行程 ETA。以路由引擎的路段時間總和做 baseline,再學習 residual 與預測區間;更新頻率要兼顧準確和畫面穩定。

I would distinguish dispatch waiting time, pickup ETA, and trip ETA. A routing engine's segment-time sum is the baseline; learned residuals and prediction intervals improve it. Update frequency must balance accuracy with display stability.

白板資料流Whiteboard data flow

  1. 位置/路由Location / route
  2. 即時路況與歷史特徵Live traffic & historical features
  3. ETA/quantile 模型ETA / quantile model
  4. 平滑與區間Smoothing & interval
  5. 顯示/重算Display / refresh
  6. 實際抵達Actual arrival

01釐清產品目標Clarify product goals

定義起終點、prediction timestamp、何謂到達與允許更新頻率。主指標為使用者感知 ETA error,護欄是尾端低估、更新抖動與延遲;等待與行程模型可分開。

Define origin/destination, prediction timestamp, arrival semantics, and refresh frequency. Optimize user-relevant ETA error with tail underestimation, jitter, and latency guardrails; waiting and travel models can differ.

02資料與標籤Data & labels

使用 GPS、map matching、路由、時間、交通與實際到達;標籤是預測當下到到達的剩餘時間。取消行程屬 censoring,不硬當一般完成標籤;按時間/城市切分,不讀取未來路況。

Use GPS, map matching, route, time, traffic, and arrival events. Labels are remaining time from the prediction timestamp. Canceled trips are censored, not ordinary completions. Split by time/city and exclude future traffic.

03Baseline/模型Baseline & models

Baseline 為路段平均時間+轉彎/等候成本;GBDT residual model 容易起步,再比較 graph/sequence 模型。quantile loss 預測 p50/p90 等區間,處理誤差非對稱;檢查 quantile crossing。

Start with segment travel times plus turning/waiting costs, then a GBDT residual model before graph/sequence approaches. Quantile losses estimate p50/p90 and asymmetric uncertainty; check for quantile crossing.

04訓練與部署Training & deployment

路況流更新需處理 GPS 延遲與 outlier,快取路段特徵;模型週期重訓、節日與事故監控。超時回退路由 baseline,對 UI 做適度平滑但不要隱藏實質延誤。

Handle delayed GPS and outliers in traffic streams, caching segment features. Retrain periodically and monitor holidays/incidents. Fall back to routing estimates on timeout and smooth display updates without hiding real delays.

05離線評估/線上實驗Offline evaluation & online experiments

離線 MAE、p90 absolute error、quantile calibration 與城市/路段/雨天 slices,避免短行程 MAPE 爆大。線上 canary/A/B 看實際誤差、取消與使用者信任,模型 ETA 改變行為時也要注意選擇效應。

Measure MAE, p90 absolute error, quantile calibration, and city/route/weather slices; MAPE is unstable for very short trips. Online, track realized error, cancellations, and trust, considering selection effects when displayed ETAs change behavior.

06失敗案例與取捨Failures & tradeoffs

GPS 漂移、臨時封路、長尾事故與重新選路造成錯誤。以資料 freshness、異常偵測、區間與路由重算處理;增加更新頻率會增加成本和抖動,需用體驗指標決定。

GPS drift, closures, rare incidents, and rerouting cause errors. Use freshness checks, anomaly handling, intervals, and route refreshes. Frequent updates add cost and jitter, so choose frequency using experience metrics.

面試官追問 → 建議回答Follow-up questions → suggested answers

為什麼報區間而非只有一個數字?Why provide intervals instead of one number?

相同平均 ETA 在穩定道路和事故風險道路的可信度不同;區間要以實際 coverage 校準,不能只任意加減幾分鐘。

Equal mean ETAs can have very different uncertainty. Calibrate intervals by empirical coverage rather than adding arbitrary minutes.

21共通能力延伸Transfer practiceTesla Autopilot PerceptionMultimodal / Perception / Safety

設計自動駕駛感知子系統,從感測資料估計周遭物件與道路狀態。

Design a driving-perception subsystem that estimates surrounding objects and road state from sensor data.

口說開場範例Spoken opening

我會限定感知範圍與運行條件,明確區分感知、規劃和控制。設計涵蓋時序感測輸入、偵測/追蹤/空間表示與不確定性;驗證需要場景回放、模擬、封閉場地與受控部署,不能把一般網站 A/B 直接套到道路安全。

I would scope the perception task and operating conditions, separating perception from planning and control. The design covers temporal sensors, detection/tracking/spatial representations, and uncertainty. Validation requires replay, simulation, closed-course testing, and controlled deployment rather than ordinary web-style A/B testing for road safety.

白板資料流Whiteboard data flow

  1. 時間同步感測資料Synchronized sensors
  2. 校正與品質檢查Calibration & quality checks
  3. 時序感知Temporal perception
  4. 偵測/追蹤/空間表示Detection / tracking / spatial state
  5. 不確定性介面Uncertainty interface
  6. 規劃/降級策略Planning / degraded mode

01釐清產品目標Clarify product goals

問感測器、operational design domain、天候/道路、輸出類型與端到端 deadline。此題聚焦 perception,不聲稱完整自動駕駛。成功需同時滿足場景風險、漏檢率與最壞情況延遲。

Clarify sensors, operational design domain, weather/roads, output types, and end-to-end deadlines. Scope this to perception rather than a complete autonomous-driving system. Success combines scenario risk, miss rates, and worst-case latency.

02資料與標籤Data & labels

需要同步多視角/時序資料、校正參數、3D boxes/lane/occupancy 標籤與困難場景。按行程、地區、時間切分,避免相鄰影格洩漏;標籤不確定性和合成資料分布要單獨管理。

Collect synchronized multi-view/temporal data, calibration parameters, 3D boxes/lanes/occupancy labels, and hard scenarios. Split by drive, geography, and time to avoid adjacent-frame leakage. Track label uncertainty and synthetic-data domain shift.

03Baseline/模型Baseline & models

Baseline 為可驗證的 detector+tracker;再比較時序融合、多任務空間表示與適用感測器融合。模型輸出物件狀態與 confidence/uncertainty;低信心不能被 downstream 當成「沒有障礙物」。

Start with a validated detector and tracker, then compare temporal fusion, multitask spatial representations, and applicable sensor fusion. Output state and uncertainty; low confidence must not be interpreted downstream as “no obstacle.”

04訓練與部署Training & deployment

訓練可使用分散式平台,部署在車端需量測熱限制、記憶體與確定性 deadline。模型/校正版本追蹤,先 shadow,再依驗證計畫擴大;感測失效或超出條件由整體系統執行預定降級策略。

Training may be distributed, but edge deployment requires thermal, memory, and deterministic-deadline profiling. Version models/calibration, shadow first, and expand under a validation plan. Sensor failures or out-of-domain conditions trigger predefined system-level degraded behavior.

05離線評估/線上實驗Offline evaluation & online experiments

離線看距離/遮擋切片的 3D detection、tracking、occupancy 和 uncertainty calibration,特別統計行人/道路施工等重要場景。線上驗證採 replay、simulation、closed-course 與受控 shadow;aggregate mAP 不足以證明道路安全。

Evaluate 3D detection, tracking, occupancy, and uncertainty by distance/occlusion, emphasizing consequential scenarios such as pedestrians and construction. Validate through replay, simulation, closed-course testing, and controlled shadowing. Aggregate mAP does not establish road safety.

06失敗案例與取捨Failures & tradeoffs

逆光、罕見障礙、校正漂移與 domain shift 是關鍵;維持場景測試庫、主動挑選難例與感測健康檢查。更大模型可能降低 deadline 可靠性;品質改善須和整體系統風險一起評估。

Glare, unusual obstacles, calibration drift, and domain shifts are central failures. Maintain scenario suites, active hard-case selection, and sensor-health checks. Larger models can undermine deadline reliability; evaluate improvements with system-level risk.

面試官追問 → 建議回答Follow-up questions → suggested answers

為什麼 mAP 提升仍不代表更安全?Why does higher mAP not necessarily mean safer behavior?

平均值可能掩蓋少數高風險場景,且未包含時序穩定、校準與端到端行為;需場景風險和系統驗證。

Averages can hide rare consequential failures and omit temporal stability, calibration, and downstream behavior. Scenario risk and system validation remain necessary.

22整合挑戰Integrated challengeCopilot Shopping AssistantRetrieval / Recommendation / LLM / Agentic systems

理解購物需求,檢索商品與廣告,查詢即時價格/庫存,產生可信推薦並清楚標示贊助內容。

Understand shopping needs, retrieve products and ads, verify live prices/stock, and generate trustworthy recommendations with clear sponsorship labels.

完整深入篇Full deep dive

14 個章節、重畫架構圖、資料與 loss、即時工具、贊助排序、評估與 45 分鐘口說流程。

14 chapters, original diagrams, data and losses, live tools, sponsorship, evaluation, and a 45-minute rehearsal.

Copilot Shopping Assistant — Deep Dive ↗

口說開場範例Spoken opening

我會先把助理限制在比較與推薦,購買要另經使用者確認。流程先澄清預算和硬性需求,再檢索、排序並用權威工具驗證價格與庫存;生成內容只引用已驗證證據。商品相關性和贊助身份分開處理,整體以成功完成購物任務及信任護欄衡量。

I would initially scope the assistant to comparison and recommendation, with purchases requiring separate user confirmation. It clarifies budget and hard constraints, retrieves and ranks products, and verifies prices/stock through authoritative tools. Generated claims use verified evidence. Relevance and sponsorship are explicit separate concerns, and success is completed shopping tasks with trust guardrails.

白板資料流Whiteboard data flow

  1. 需求與限制Needs & constraints
  2. 商品/廣告多源檢索Product / ad retrieval
  3. 資格與相關性排序Eligibility & relevance ranking
  4. Live price/stock toolsLive price / stock tools
  5. 有來源的比較Sourced comparison
  6. 贊助標示/確認動作Sponsorship labels / confirmation

01釐清產品目標Clarify product goals

限制可執行範圍。 問只推薦還是能下單、有哪些商家 API、登入和預算單位、配送地區。對「500 美元內輕便筆電」先釐清用途與必要規格。主指標為有證據支持的任務完成;護欄含錯價、缺貨、誤導贊助、錯誤工具操作與成本。

Bound the action scope. Ask whether the assistant recommends or buys, which merchant APIs exist, authentication, currency, and delivery region. For “a lightweight laptop under $500,” clarify intended use and required specifications. Optimize supported task completion, with incorrect prices, unavailable items, misleading sponsorship, tool errors, and cost as guardrails.

02資料與標籤Data & labels

連接對話、商品與工具資料。 保存 turn/request ID、經同意的偏好、候選/展示、商品版本、價格時間戳、工具參數/結果、來源與贊助旗標。標籤含相關性、限制滿足、資訊正確、工具成功、任務完成、退貨/取消;以時間、商品家族及使用者切分避免洩漏。

Connect dialogue, catalog, and tools. Log turn/request IDs, consented preferences, candidate/display sets, product versions, price timestamps, tool parameters/results, citations, and sponsorship flags. Labels include relevance, constraint satisfaction, factual accuracy, tool success, completion, and cancellations/returns. Split by time, product family, and user where appropriate.

03Baseline/模型Baseline & models

先固定 workflow,再考慮 agent。 Baseline 用條件解析+catalog search+模板比較。升級 hybrid/圖文 retrieval、精排與 bounded tool controller;只有需求不完整或工具結果需追查時動態規劃。硬性規格、預算與可售條件先過濾,再以相關性及使用者效用排序;贊助品仍需通過資格/相關性門檻。

Start with a workflow before an agent. Baseline constraint extraction, catalog search, and template comparison. Add hybrid/multimodal retrieval, ranking, and a bounded tool controller. Plan dynamically only when clarification or tool follow-up is needed. Enforce hard specifications, budget, and availability before ranking by relevance and utility; sponsored items must also meet eligibility/relevance thresholds.

04訓練與部署Training & deployment

明確的工具契約。 search_products 回傳 ID 和可追溯資料;get_price_stock(product_id, region) 回傳 currency、price、stock、timestamp。工具具 timeout、schema validation、重試上限與 circuit breaker。若允許下單,先呈現最終價格與明細供確認,再用 idempotency key 執行;供應商文字不能觸發副作用。

Use explicit tool contracts. search_products returns identifiers and traceable metadata; get_price_stock(product_id, region) returns currency, price, stock, and timestamp. Enforce timeouts, schema validation, retry bounds, and circuit breakers. If buying is supported, show the final price/details for confirmation before executing with an idempotency key. Merchant text cannot authorize side effects.

05離線評估/線上實驗Offline evaluation & online experiments

端到端與元件一起評估。 離線測 constraint satisfaction、商品 Recall/NDCG、價格新鮮度、claim groundedness、工具成功率與贊助標示正確性;加入工具失敗、矛盾規格、無適合商品與 prompt injection。線上量測成功任務、滿意度、取消/退貨、成本與 latency,區分有無贊助流量並做人工盲評。

Evaluate components and the whole task. Offline tests cover constraints, product Recall/NDCG, price freshness, claim groundedness, tool success, and sponsorship labeling. Include tool failures, conflicting specs, no valid products, and prompt injection. Online, track task success, satisfaction, cancellations/returns, cost, and latency, separating sponsored traffic and using blinded human review.

06失敗案例與取捨Failures & tradeoffs

價格改變或缺貨: 重新查驗並告知時間戳;工具失效: 不猜價格,回傳可驗證部分與缺口;找不到合格商品: 說明限制並請使用者調整。更自主的 agent 增加工具呼叫、成本與不確定性,只有可量測的任務收益足以支持時才採用。

Price changes or stock-outs: revalidate and expose timestamps. Tool failure: do not invent values; show verified information and the gap. No eligible products: explain conflicting constraints and ask which can change. More autonomous agents add tool calls, cost, and uncertainty; use them only when measurable task gains justify the complexity.

深入拆解Deep dives

用一個例子串起全流程Walk through one complete example

使用者要「US$500 內、13–14 吋、適合文書的輕便筆電」。解析幣別、尺寸和用途 → 檢索 catalog → 篩選規格 → 精排三款 → 查配送地區即時含稅/運費資訊(若 API 有)與庫存 → 列出優缺點及來源 → 標示 sponsored → 如需購買,再確認商品、數量與最終總額。API 不含稅運時須清楚列出未計項目。

A user wants “a lightweight 13–14 inch laptop for office work under US$500.” Parse currency, size, and use → retrieve catalog → enforce specifications → rank three options → check regional price, tax/shipping if available, and stock → explain tradeoffs with sources → label sponsorship → confirm item, quantity, and final total before any purchase. Explicitly identify excluded charges when the API does not provide them.

面試官追問 → 建議回答Follow-up questions → suggested answers

如何避免助理為了廣告收益偏離需求?How do you prevent ad revenue from overriding user needs?

把 eligibility/相關性門檻與硬需求放在 monetization 前,清楚標示贊助,分別監控自然/贊助結果的任務成功與信任;不能讓 generator 自行隱藏或改寫標示。

Enforce eligibility, relevance, and hard constraints before monetization; label sponsorship clearly. Monitor success and trust separately for organic and sponsored results, and prevent the generator from hiding or rewriting labels.

多步工具成功率為何重要?Why does multistep tool reliability matter?

粗略假設每步成功率 0.98 且相互獨立,10 步全成功約 0.98^10 ≈ 0.817;真實失敗可能相關。要減少無價值步驟、限制重試並量測 end-to-end 成功率,不能只報單工具成功率。

Under a simplifying independence assumption, ten steps each succeeding with probability 0.98 yield about 0.98^10 ≈ 0.817 end-to-end success. Real failures may be correlated. Remove unnecessary steps, bound retries, and measure whole-task success rather than only individual tools.

03 / Explain the metric, not just its name

評估速查:每個指標回答什麼?What does each metric actually tell you?

指標Metric定義與用途Meaning & use常見盲點Pitfall
Recall@KTop-K 找回的相關項目數 / 全部已知相關項目數。看候選階段有沒有漏掉好結果。Relevant items in the top K divided by all known relevant items. Diagnoses candidate omissions.真實相關集合常不完整,需說明標籤來源;不是 ANN 與 exact kNN 的一致率。Relevance labels may be incomplete. Specify their source; this is not ANN agreement with exact kNN.
NDCG@K用位置折扣計算排序效用,再除以理想排序。常用 DCG = Σ(2^rel−1)/log₂(rank+1)。Discounts relevance by rank, then normalizes by ideal ranking. A common DCG is Σ(2^rel−1)/log₂(rank+1).需定義 relevance 等級與零 IDCG 的處理;分數好不保證增量產品價值。Define relevance grades and zero-IDCG handling. Gains do not establish incremental product value.
ROC-AUC / PR-AUCROC-AUC 看正例是否排在負例前;PR-AUC 聚焦 precision/recall。ROC-AUC measures positive-versus-negative ordering; PR-AUC summarizes precision/recall.不衡量機率校準;PR-AUC 依正例率而變,不宜跨不同抽樣分布直接比較。Neither measures calibration. PR-AUC depends on prevalence and is not directly comparable across different sampling distributions.
Log loss / BrierBinary log loss = −mean[y log p+(1−y) log(1−p)];Brier = mean[(p−y)²]。衡量機率預測。Binary log loss = −mean[y log p+(1−y) log(1−p)]; Brier = mean[(p−y)²]. Both score probability predictions.混合了校準與區分能力;要搭配 reliability diagram、切片和自然分布評估。They combine calibration and discrimination effects. Add reliability diagrams, slices, and natural-distribution evaluation.
Groundedness / citations檢查可驗證 claim 是否有提供的證據支持;引用 precision 看所引來源是否支持 claim。Check whether verifiable claims are supported by supplied evidence; citation precision checks support from the cited source.有引用不等於來源正確、時效適用或回答完整;正確性、coverage、權限需分開測。Citations do not establish source truth, freshness, or completeness. Evaluate correctness, coverage, and access separately.
MAE / quantile coverageMAE 看平均絕對誤差;預測 p90 應約有 90% 結果低於它,需按切片驗證。MAE measures average absolute error; about 90% of outcomes should fall below a calibrated p90 prediction, including within slices.平均值可掩蓋極端低估;MAPE 對接近零的標籤不穩。Means can hide severe underestimation; MAPE is unstable near zero.
p95 / p99 / cost端到端量測尾延遲,同時報吞吐、錯誤率與每成功任務成本。Measure end-to-end tail latency together with throughput, error rate, and cost per successful task.階段 p95 不能直接相加;平均 latency 與 cache-hit-only 數字會掩蓋長尾。Stage p95 values are not additive. Mean latency and cache-hit-only measurements hide tails.
A/B · SRM · MDE先定分流單位、主指標、最小可偵測效果與樣本量;SRM 檢查實際分組比例是否異常。Predefine randomization unit, primary metric, minimum detectable effect, and sample size. SRM checks anomalous allocation ratios.先修資料問題;重複偷看、組間干擾、樣本不成熟都可能讓結論失真。Resolve data issues first. Peeking, interference, and immature outcomes can invalidate conclusions.

實驗回答要落地:假設主指標為 orders/user,就明確說 user-level 穩定分流、事前以使用者層級變異估 power、定義 MDE 和觀察窗。先查 SRM 與日誌品質,再看效果量和信賴區間;不因某天 p<0.05 就提早結束。若用 sequential testing,需事先定義有效的序列檢定。廣告預算、社交關係或市場供需可能需要不同分流設計。

Make the experiment concrete: for orders/user, use stable user assignment, power calculations based on user-level variance, a predefined MDE, and a fixed observation window. Check SRM/logging before effect sizes and confidence intervals. Do not stop merely because one day's p-value drops below 0.05. Sequential testing needs a valid prespecified procedure. Shared ad budgets, social ties, and marketplaces may require different assignment designs.

Microsoft Research · SRM

04 / Rehearse, diagnose, repeat

口說完,檢查六件事。Six checks after your rehearsal.

01 · 目標有決策單位A concrete decision unit

能說清楚誰、在哪個入口、選擇什麼,以及一個主指標和至少兩個護欄。

Name the user, surface, decision, one primary metric, and at least two guardrails.

02 · 標籤有時間語意Labels have time semantics

能說出一筆樣本、正負例、成熟窗口、抽樣偏差與一個洩漏風險。

Define one example, positives/negatives, maturity, sampling bias, and one leakage risk.

03 · 模型選擇有理由Model choices have reasons

先給 baseline,解釋 loss 與輸出,說清楚何時值得加深模型。

Give a baseline, explain the loss/output, and specify when complexity becomes worthwhile.

04 · 線上路徑可運作Serving is operational

畫出資料流、版本和新鮮度;有容量估算、timeout fallback 與 rollback。

Draw data flow, versions, and freshness. Include capacity, timeout fallback, and rollback.

05 · 評估能辨識問題Evaluation isolates failures

分開元件與端到端指標,說明切分、切片、分流、護欄與實驗可信度。

Separate component and whole-system metrics; explain splits, slices, assignment, and experiment validity.

06 · 取捨可被檢驗Tradeoffs are testable

至少說一個 failure → detection → mitigation,並用品質/延遲/成本決定下一步。

State a failure → detection → mitigation chain, and choose the next step using quality, latency, and cost.

建議練習節奏:先用三次各 45 分鐘練 Ads、Products、RAG。第四次補 Feed+Visual Search 的差異;第五次做購物助理整合。之後依弱點選 Training/Cost/Moderation,其他題目用六步流程練遷移。每次先閉卷,記下卡住的一步,再讀答案重講。

Suggested sequence: use three 45-minute sessions for Ads, Products, and RAG. Next, compare Feed and Visual Search, then tackle the shopping assistant. Add Training, Cost, or Moderation where you need depth; use the remaining cases to practice transfer. Rehearse without answers, identify the stage where you stalled, then read and explain it again.

05 / Primary references

參考資料與概念來源References & concept sources

以下為原始論文與官方技術文件。連結支持對應概念;練習中的架構、SLO 與決策為綜合建議,並非從題庫取得的標準答案。題名清單來源:TensorTonic 題庫頁。

These are original papers and official technical resources. They support the linked concepts; architectures, SLOs, and decisions in the cases are synthesized recommendations, not official answer keys. Title-list reference: TensorTonic system-design page.