Quartz 5

AI 系統設計框架

Properties1
tagsai, llm, system-design, architecture, interview, cost

14 min read

對應原題（Common ‧ AI System Design，11 題）
Anthropic / OpenAI / Google DeepMind / Meta / xAI / Microsoft / Amazon / Databricks /
Perplexity / Cursor / Sierra / Character.AI / Palantir 等幾乎每一家都有系統設計輪。

🎯 什麼情境該想到我

當你「面前是一個開放式的『設計一個 X』，而 X 裡面有 LLM」的時候。

⚙️ Part 1：★ AI 系統設計和傳統系統設計差在哪

傳統的骨架（需求 → 容量估算 → API → 資料模型 → 架構 → 擴展 → 瓶頸）仍然適用，但多了四件事——而這四件事就是你的差異化得分點：

#新增的維度要問/要講的
1★ 品質是需求的一部分「多準才夠？」「錯了會怎樣？」「可以拒答嗎？」
沒問這幾個問題，後面的架構全是憑空的
2★ 評估與資料飛輪要在設計裡不是「做完再評估」。資料怎麼回流、評估集怎麼長出來，是架構的一部分
3★ 成本是每請求可變的容量估算要算 token，不只算 QPS。$/月 常常是真正的設計約束
4★ 非決定性需要護欄、人類把關、可回退、可審計

面試時主動把這四點講出來，會立刻和「把 LLM 當成一個 API 呼叫」的答案區分開。

⚙️ Part 2：七步答題骨架

步驟重點
1. 澄清需求與規模使用者數、QPS、資料量、延遲 SLO、★ 品質門檻與失敗成本、合規要求
2. 容量與成本估算QPS、token/請求、$/月、GPU 數、儲存
3. 高層架構分成資料面（離線：索引、訓練）與服務面（線上：查詢、生成）
4. 逐元件深入挑面試官追問的那一塊講細（通常是檢索或服務）
5. ★ 評估與監控這一段最容易拿分，因為多數人會跳過
6. 護欄、權限、失敗模式降級路徑、超載、供應商掛掉
7. 演進路徑v0（最簡可用）→ v1 → v2。展現工程判斷力

⚙️ Part 3：★ 一個可複用的容量與成本估算

題目：10M 份文件的企業 RAG，5 萬名員工。

【索引規模】
10M 文件 × 平均 5 chunks         = 50M chunks
50M × 768 維 × 4 bytes (fp32)    = 154 GB   ← 單機裝不下
  → HNSW 圖（M=16）再加 6.4 GB   = 160 GB   → 分片 or 量化
  → 改用 IVF-PQ（m=96）           = 4.8 GB   ← ★ 30 倍差距（見 [[向量索引 ANN]]）

【流量】
5 萬人 × 10 次查詢/天 = 500k 次/天
分散在 8 小時         → 平均 ≈ 17 QPS
尖峰 5×               → ≈ 85 QPS

【每請求 token】
輸入：system 500 + 5 chunks × 400 + 問題 100 ≈ 2,600
輸出：≈ 300

【每日 token】
輸入 500k × 2,600 = 1.3B
輸出 500k × 300   = 0.15B

【成本】（假設 $2/M 輸入、$10/M 輸出——示意用的假設單價，非任何廠商報價）
輸入 1.3B/1e6 × 2  = $2,600/天
輸出 0.15B/1e6 × 10 = $1,500/天
                     ─────────────
                     ≈ $4,100/天 ≈ $123k/月   ← ★ 這個數字會決定整個設計

★ 算完要立刻接降本（見 服務棧選型與降本）：

  • 前綴快取 → system + 工具定義那 500 token 的成本降 10 倍
  • 模型路由 → 簡單查詢走小模型，可能砍掉 5 倍
  • 縮短上下文 → reranker 把 5 chunks 降到 3 chunks
  • 快取常見問答 → 企業內部的查詢重複率很高

★ 「先算出一個嚇人的數字，再展示怎麼把它降下來」是這類題目最好的敘事結構。

⚙️ Part 4：11 道題的骨架與關鍵取捨

① 企業 RAG（10M 文件 + 逐使用者權限）

OpenAI / Microsoft / Amazon / Databricks / Scale AI

架構：連接器 → 解析 → 切塊（帶 ACL） → 雙索引（BM25 + 向量） → hybrid 檢索 + ACL 前過濾 → rerank → 生成 + 引用。
★ 關鍵取捨：權限必須是 filtered ANN 不是後過濾，而且撤銷延遲要有明確 SLA（見 權限感知檢索與引用歸因）。
陷阱：filtered search 會讓 HNSW 圖斷連（見 向量索引 ANN）；ACL 欄位第一天就要設計進 schema。

② 程式碼助手（Cursor）

架構：repo 索引（AST 邊界切塊，增量靠 git diff）→ 上下文組裝（開啟的檔案 + 語意檢索 + 符號表）→ 編輯套用（精確取代而非重寫）→ 驗證（型別檢查 + 測試）。
★ 關鍵取捨：編輯的粒度——重寫整檔簡單但 diff 大、不可審；精確取代省 token 且可審，但要處理「找不到 old_string」。
陷阱：chunk ID 要用內容 hash 才能做到分鐘級增量（見 RAG 評估與營運）；符號幻覺要用 language server 驗（見 幻覺偵測）。

③ 客服 Agent（能執行真實動作 + 升級給人）

Consumer-Scale ML / Sierra
架構：意圖路由 → RAG 回答 或 Agent 執行 → 動作分級與授權 → 升級判斷 → 交接。
★ 關鍵取捨：升級的時機。太早 → 沒有省到人力；太晚 → 使用者已經生氣。判準要包含：信心低、重複失敗、情緒偵測、明確要求、涉及金額。
陷阱：交接時要把完整脈絡給真人（見 可逆性、審計與人類把關）；動作要冪等且可逆。

④ 商品目錄語意搜尋（Character.AI）

架構：商品文字 + 屬性 + 圖片 → hybrid 索引 → 過濾（庫存、價格、類別）→ rerank（含商業排序）。
★ 關鍵取捨：語意相關性 vs 商業目標（毛利、庫存、促銷）——純語意排序不會是最終排序。
陷阱：精確查詢（型號、SKU）必須靠 BM25；屬性過濾是主要路徑，別全丟給向量。

⑤ 內容審核（分類器 + LLM）（Meta）

架構：★ 分層——規則/雜湊比對 → 小分類器 → LLM（只看模糊的） → 人工（只看高風險與申訴）。
★ 關鍵取捨：成本 vs 覆蓋率。LLM 不可能跑全量；它只該處理分類器不確定的那 1–5%。
陷阱：要分語言/地區評估誤判率；要有申訴流程；審核人員的心理健康（見 PII、紅隊與公平性稽核）。

⑥ 文件智慧管線（掃描 PDF → 結構化欄位，10M 份）（Palantir）

架構：OCR + 版面分析 → 欄位抽取（結構化輸出 + schema 驗證）→ 信心分級 → 低信心送人工 → 回流成訓練資料。
★ 關鍵取捨：自動化率 vs 準確率。設一個信心門檻，門檻上全自動、門檻下人工——門檻的位置就是產品決策。
陷阱：OCR 錯誤會一路傳播；多欄版面（見 切塊與文件解析）；人工複核的產出必須回流，否則沒有飛輪。

⑦ Text-to-SQL（數千張表）（Databricks / Palantir）

架構：★ schema 檢索（不可能把幾千張表的 schema 全塞進 prompt）→ 生成 SQL → 靜態驗證（語法、表/欄位存在、唯讀）→ dry-run/EXPLAIN → 執行（逾時 + 列數上限）→ 結果解釋。
★ 關鍵取捨：要不要讓模型直接寫 SQL。替代方案是受限的查詢建構器（模型只填參數）——安全得多但表達力低（見 工具集設計 的第 8 條規則）。
陷阱：語意層（哪張表才是「營收」的真相來源）比語法更難；一定要唯讀 + 資源上限。

⑧ 會議助理（錄音 → diarisation → 摘要 → 行動項 → 整合）（Microsoft）

架構：串流 ASR → diarisation + 角色歸屬 → 分段摘要 → 全域彙整 → 行動項抽取（結構化輸出）→ 寫回日曆/工單。
★ 關鍵取捨：長會議的階層式處理——不可能一次進上下文。
陷阱：角色歸屬 ≠ 聚類（見 級聯與原生語音）；行動項的寫回是有副作用的動作，需要人類確認；錄音是高敏感 PII。

⑨ LLM Gateway（多供應商路由、failover、快取、預算、限流）（Perplexity / Palantir）

架構：統一 API → 路由（依模型能力/成本/延遲/可用性）→ 快取（精確 + 語意）→ 限流與配額（per-tenant）→ failover → 遙測與成本歸因。
★ 關鍵取捨：failover 的語意——換一家供應商就是換一個模型，行為會變。要不要為了可用性犧牲一致性？
陷阱：串流的 failover 很難（已經吐一半了）；語意快取會回傳「相似但不同問題」的答案；per-tenant 預算是必需品不是加分（見 OWASP LLM Top 10 的 Unbounded Consumption）。

⑩ 消費級聊天服務棧（數億使用者）

Anthropic / OpenAI / Google DeepMind / Meta / xAI
架構：邊緣接入 → 路由 → 連續批次 + PagedAttention 的推論叢集 → 前綴快取 → 串流回傳。
★ 關鍵取捨：吞吐 vs 延遲（見 Prefill 與 Decode）——定 goodput 目標，往上推 batch 直到 SLO 快破。
要講到：連續批次 Continuous Batching、PagedAttention 與 vLLM、前綴快取 Prompt Caching、chunked prefill、PD 分離、多區部署與容量規劃（見 服務棧選型與降本）。

⑪ 十億文件、百萬 QPS 的分散式搜尋（Anthropic）

架構：分片 + 副本 → 分散式查詢（scatter-gather）→ 各分片本地 top-k → 全域合併 → rerank。
★ 關鍵取捨：尾延遲——百萬 QPS 下 p99 由最慢的分片決定。對策：對沖請求（hedged requests）、部分結果容忍。
陷阱：這題偏傳統分散式系統，別全部往 LLM 講。

⚠️ 注意 / 什麼時候不適用

  • ★ 先問再畫。品質門檻、失敗成本、合規要求沒問清楚就開始畫架構，是這類題最常見的失分。
  • ★ 一定要講評估與監控。多數候選人會跳過，這是最容易的得分點。
  • ★ 一定要算成本。$/月 常常比 QPS 更能決定架構。
  • 給演進路徑。「v0 用託管 API + pgvector 驗證需求，v1 再自架」比直接上完整架構更顯成熟。
  • 別過度設計。10M 文件不需要自建向量資料庫；1000 QPS 不需要 PD 分離。
  • 講取捨不講結論。「我會選 X，因為在這個約束下 Y 的代價是 Z」勝過「業界最佳實踐是 X」。
  • 承認不確定。「這個數字我會用壓測驗證」比編一個精確的假數字好。

🧪 我實際套用的紀錄

  • 2026-09-20：從面試題庫展開，尚未實際套用。

🔗 相關

Graph View

Backlinks