大廠面試中拉開差距的核心題型。面試官給一個開放場景讓你設計解決方案。評分標準不在答案正確而在結構化思考、權衡取舍、知識廣度。本章提供9個完整系統設計方案每題包含問題界定→架構→權衡→故障模式→評估→追問鏈。回答方法論黃金五步框架Step 1: Problem Framing問題界定 - 明確需求范圍功能 vs 非功能 - 確認約束條件數據量、延遲、可用性、安全 - 指出核心挑戰 Step 2: High-Level Architecture頂層架構 - 畫模塊圖箭頭標注數據流 - 解釋每個模塊職責 Step 3: Component Deep Dive組件深入 - 每個組件的選型理由 - 關鍵接口定義 Step 4: Key Trade-offs權衡討論 - 為什么選A不選B - 當前方案的局限性 - 在什么條件下應該換方案 Step 5: Failure Modes Evaluation異常與評估 - 最可能出問題的地方 - 監控指標面試官評估維度維度權重考察點問題分解能力40%把模糊問題拆成清晰子問題權衡表達35%說出每個選擇的Why可擴展性思維25%方案能應對10x/100x增長三種最常見錯誤跳入細節沒有框架——像背答案只給方案不說權衡——面試官想知道你做過選擇忽略邊界條件——不提超時/檢索不到/幻覺怎么辦D1: 設計基于內部知識庫的問答系統Problem Framing核心需求數萬份內部技術文檔 → 員工自然語言提問 → 精確回答可溯源核心約束數據不能外傳本地部署文檔格式多樣答案必須有引用來源核心挑戰本地有限算力和回答質量的平衡知識持續更新Architecture離線索引管道 文檔解析(PDF/Word) → 語義切分(chunk重疊) → Embedding(bge-large) → 向量庫(FAISSSQL) 每日增量更新 在線推理服務 用戶查詢 → Query改寫(HyDE) → 混合檢索(DenseBM25) → Reranker(Top-50→Top-3) → 生成引用關鍵組件組件選型理由Chunking按標題分割512t切分100t重疊保持語義完整Dense檢索bge-large-zh, FAISS語義匹配BM25檢索jiebaES倒排索引精確匹配融合Dense×0.7 BM25×0.3平衡語義和精確Rerankerbge-reranker-baseCross-encoder精排生成Qwen2.5-14B(int4量化)本地部署質量平衡Trade-offs選擇優勢劣勢何時換方案RAG vs 微調知識實時更新多一次檢索調用文檔不更新→微調chunk512 vs 128上下文完整過多噪聲關鍵字匹配→128DenseBM25 vs 純Dense精確匹配有保障維護兩個索引全英文OpenAI→純Dense追問鏈Q1: “文檔量從數萬漲到數百萬架構哪里先崩”→ FAISS單機內存不夠→分布式向量檢索(Milvus/Qdrant)索引分片異步構建Q2: “10輪對話上下文太長怎么辦”→ 對話歷史壓縮(LLM總結)檢索基于當前query壓縮后歷史摘要Q3: “新文檔上線到能檢索的延時”→ 離線管道每小時增量更新最大延遲1小時。需實時改事件驅動。D2: 訓練100B級LLM的訓練計劃Problem Framing核心需求從零訓練100B參數decoder-only LLM算力512張A100 80GB核心約束3-4個月產出可用模型核心挑戰固定算力下最大化模型質量模型配置參數值層數80層d_model8192n_head64n_kv_head8 (GQA)d_ff21845 (SwiGLU, 8/3×d)位置編碼RoPE, 訓練長度8192歸一化RMSNorm, Pre-LN詞表100K tokens并行策略512 A100 80GB策略配置理由TP8模型單卡放不下跨卡切分PP4層間切分減少通信DP16數據并行512/(8×4)16ZeROZeRO-1分片優化器狀態精度BF16混合精度避免梯度下溢數據計劃數據類型比例Token數網頁(CommonCrawl)40%清洗后過濾書籍/論文20%過采樣2×代碼(GitHub)20%高質量倉庫中文15%百科新聞論壇數學/推理5%過采樣3×總訓練量按Chinchilla比例100B參數需~2T tokens訓練時間估算每步batch_size2M tokens, ~3.5s/step總步數2T/2M 1M步總時間1M×3.5s ≈ 40天加評估/checkpoint開銷 → 約60-90天追問鏈Q1: “訓練中途loss spike怎么辦”→ 回退到最近的穩定checkpoint降低學習率檢查數據質量Q2: “如果只有256卡怎么辦”→ 減少TP到4增加PP到8或減少batch_size增加梯度累積D3: 部署70B模型的服務架構Problem Framing核心需求部署70B模型支持1000 QPSP99延遲5s核心約束GPU資源有限Architecture用戶請求 → API Gateway(限流/認證) → 路由層 → 簡單query → 7B模型(快速響應) → 復雜query → 70B模型(高質量) → 70B模型集群TP4×2組GQA減少KV Cache → vLLM推理引擎 PagedAttention Continuous Batching → 結果緩存(prefix cache語義緩存)GPU估算配置顯存每GPU TPS所需GPU70B FP16140GB~1014冗余2870B INT435GB~258冗余1670B INT4GQA~25GB~306冗余12追問鏈Q1: “流量突增怎么辦”→ 限流隊列降級70B→7B自動擴縮容Q2: “如何保證高可用”→ 多副本健康檢查自動故障轉移預熱新節點D4: 設計Auto Agent系統Problem Framing核心需求能自主使用工具完成復雜任務的Agent系統核心挑戰規劃能力、錯誤恢復、安全控制Architecture用戶指令 → 任務規劃器(分解為子任務) → 執行器(循環) 1. 思考(當前狀態目標→下一步動作) 2. 執行(選擇工具調用) 3. 觀察(解析結果) 4. 判斷(完成/繼續/失敗回退) → 安全監控器(并行運行檢測異常)關鍵設計組件方案理由規劃ReAct/Function CallingFunction Calling更快~2×工具庫搜索/計算/文件/API按需擴展錯誤恢復max_steps重復檢測回退防死循環安全沙箱執行權限控制審計日志防惡意操作Trade-offs選擇優勢劣勢ReAct可解釋性強解析文本格式慢Function Calling結構化快速靈活性低單Agent簡單復雜任務難處理多Agent分工明確協調開銷大D5: 多模型服務平臺設計Problem Framing核心需求支持多個LLM7B/13B/70B/多模態的統一服務平臺核心挑戰資源調度、模型路由、成本優化Architecture請求入口 → 路由分類器(判斷任務難度和類型) → 模型調度器 7B集群(通用/簡單任務) → TP1, 高吞吐 70B集群(復雜推理) → TP4, 高質量 多模態集群(圖文) → TP2, VLM → 共享基礎設施KV Cache管理/模型熱加載/Auto-scaling路由策略策略方法適用場景級聯小模型先答不確定升級大模型成本敏感分類器輕量分類器判斷難度任務差異明顯用戶指定用戶選擇模型專業用戶A/B測試隨機分配比較效果模型選型D6: 實時RAG系統Problem Framing核心需求在新聞/社交媒體等實時更新場景中做RAG核心挑戰文檔持續更新索引必須實時跟上Architecture數據流新文檔 → 實時解析 → 增量Embedding → 向量庫熱更新 查詢流用戶查詢 → 檢索(含最新文檔) → 生成時間標注 關鍵設計 - 流式處理管道(Kafka/消息隊列) - 向量庫熱更新(Milvus支持在線插入) - 時間感知檢索(優先近期文檔)追問鏈Q1: “索引更新延遲要求多低”→ 秒級流式處理在線索引分鐘級微批處理Q2: “舊文檔怎么處理”→ TTL過期定期清理版本管理D7: NL2SQL系統設計Problem Framing核心需求自然語言→SQL查詢用于BI/數據分析核心挑戰Schema理解、復雜SQL生成、準確性驗證Architecture用戶問題 → Schema鏈接(識別表和列) → SQL生成(LLM) → SQL驗證(語法檢查沙箱執行) → 如果執行失敗 → 錯誤反饋→重新生成(最多3次) → 結果格式化→返回關鍵優化優化方法效果Schema注入將表結構作為上下文減少列名錯誤Few-shot提供相似問題的SQL示例提高SQL正確率自修正執行失敗→錯誤信息→重新生成提升30%準確率結果驗證檢查結果合理性(非空/類型/范圍)減少明顯錯誤D8: 金融領域RAG系統Problem Framing核心需求金融報告/公告/法規的精確問答核心挑戰數字精確性、時效性、合規性特殊設計方面設計理由精度數字不截斷保留原始格式金融數字不能近似時效文檔按時間排序優先最新金融信息時效性強引用精確到段落頁碼合規審計需要安全私有部署審計日志數據敏感幻覺控制嚴格限制只基于檢索內容金融不能編造D9: 多Agent代碼系統Problem Framing核心需求多Agent協作完成軟件開發任務需求分析→編碼→測試→Review核心挑戰Agent協調、代碼質量、錯誤傳播ArchitecturePM Agent需求分析 → 任務分解 → 分配 Architect Agent技術方案 → 模塊劃分 → 接口定義 Coder Agent(s)并行編碼 → 單元測試 Reviewer AgentCode Review → 安全審計 → 合并建議關鍵設計每個Agent有獨立上下文和工具集共享代碼倉庫(Git)作為通信媒介Review Agent發現問題→反饋給Coder Agent修改最終集成測試通過才合并補充RAG系統設計詳解企業級RAG系統完整架構┌──────────────────────┐ │ 用戶請求入口 │ └──────────┬───────────┘ │ ┌──────────▼───────────┐ │ Query預處理模塊 │ │ - 意圖識別 │ │ - Query改寫/擴展 │ │ - 權限校驗 │ └──────────┬───────────┘ │ ┌────────────────┼────────────────┐ │ │ │ ┌─────────▼──────┐ ┌──────▼───────┐ ┌──────▼───────┐ │ Dense檢索 │ │ BM25檢索 │ │ 元數據過濾 │ │ (BGE-M3) │ │ (Elastic) │ │ (權限/時間) │ └─────────┬──────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ └────────────────┼────────────────┘ │ RRF融合 ┌──────────▼───────────┐ │ Reranker重排序 │ │ (BGE-Reranker) │ └──────────┬───────────┘ │ Top-K ┌──────────▼───────────┐ │ Prompt組裝 │ │ - System Prompt │ │ - 檢索上下文 │ │ - 對話歷史 │ │ - 用戶問題 │ └──────────┬───────────┘ │ ┌──────────▼───────────┐ │ LLM生成 │ │ (流式輸出) │ └──────────┬───────────┘ │ ┌──────────▼───────────┐ │ 后處理 │ │ - 引用標注 │ │ - 幻覺檢測 │ │ - 格式化 │ └──────────┬───────────┘ │ ┌──────────▼───────────┐ │ 返回用戶 │ └──────────────────────┘關鍵設計決策決策點選項A選項B推薦Chunk大小256 tokens512 tokens512上下文更完整檢索策略純向量Hybrid(DenseBM25)Hybrid召回率更高Reranker無Cross-encoder有精度提升5-10%模型選擇70B FP167B INT4緩存按QPS和成本權衡緩存策略無緩存語義緩存(Redis)有減少30-50%調用幻覺控制無Self-RAG引用必須有追問RAG系統中如何處理多跳推理問題單步檢索無法回答A的CEO曾在哪所大學任教這類多跳問題。方案(1) Query Decomposition——拆成A的CEO是誰該CEO在哪任教兩步(2) Iterative Retrieval——先檢索第一跳答案再用答案作為query檢索第二跳(3) Knowledge Graph輔助——用KG做實體關系推理。補充多輪對話系統設計系統架構多輪對話系統核心模塊: | |-- 對話管理(Dialogue Management) | |-- 對話狀態追蹤(DST): 維護slot值、用戶意圖 | |-- 對話策略(DP): 決定下一步動作 | -- 上下文管理: 短期(buffer) 長期(summary/vector) | |-- NLU模塊 | |-- 意圖識別: 分類當前輪意圖 | |-- 槽位填充: 提取關鍵實體/參數 | -- 指代消解: 它指什么、上一個是哪個 | |-- 生成模塊 | |-- LLM生成: 自然語言回答 | |-- 模板填充: 結構化回答(訂單確認等) | -- 工具調用: 執行查詢/操作 | -- 安全模塊 |-- 敏感內容過濾 |-- 用戶身份驗證 -- 異常行為檢測多輪對話的關鍵挑戰挑戰原因解決方案上下文遺忘Context window有限摘要壓縮向量檢索指代不明“這個”那個指代不清指代消解模型話題切換用戶突然換話題意圖檢測狀態管理多輪一致性前后回答矛盾狀態追蹤約束檢查糾錯處理用戶修改之前的選擇狀態回滾重新確認追問如何處理用戶在中途切換話題的情況方案(1) 話題檢測——用分類器或LLM判斷當前輪是否切換了話題(2) 狀態保存——將當前話題的slot值壓棧(3) 新話題處理——初始化新的對話狀態(4) 話題回溯——用戶說回到剛才的問題時彈棧恢復。實現上可以用LangGraph的狀態管理。補充模型選型決策流程選型決策樹Q1: 任務類型? |-- 文本生成(開放域) | Q2: 質量要求? | |-- 極高(接近GPT-4) → API調用(GPT-4/Claude) | |-- 高(可接受小差距) → 70B本地部署 | -- 中(通用對話) → 14-30B | |-- 文本生成(特定領域) | Q2: 有多少領域數據? | |-- 10萬條 → 繼續預訓練微調 | |-- 1000-10萬 → SFT微調(LoRA) | -- 1000 → RAGPrompt Engineering | |-- 分類/NER/抽取 | Q2: 精度要求? | |-- 95% → 微調專用模型(BERT系) | -- 95% → LLM Few-shot | -- 代碼生成 Q2: 語言覆蓋范圍? |-- 多語言 → CodeLlama-34B / DeepSeek-Coder -- 單語言 → 微調小模型即可成本估算模板部署成本 GPU成本 運維成本 API成本(如有) 示例70B模型在線服務 GPU: 4×A100 80GB (TP4) 云租賃: ~$15/小時/卡 × 4 $60/小時 月成本: $60 × 24 × 30 $43,200/月 吞吐估算: ~3000 tokens/s (batch32) 假設平均請求: 500 input 200 output 700 tokens QPS容量: 3000/700 ≈ 4.3 requests/s 日均請求10000次 → 需要 ~3實例 → 12×A100 月成本: ~$130,000 對比: 7B INT4量化, 單卡A100 QPS容量: ~15 requests/s 月成本: ~$10,800但質量下降10-15%追問什么時候應該用API而不是自建(1) QPS1且對延遲不敏感——API成本遠低于自建(2) 需要最頂級效果——GPT-4/Claude仍領先開源(3) 團隊無GPU運維經驗——自建運維成本被低估(4) 需求不穩定——API按需付費更靈活。反之高QPS/數據安全/長期穩定需求適合自建。補充高并發推理架構架構設計┌──────────────┐ │ 負載均衡 │ │ (Nginx/HAProxy) │ └──────┬───────┘ │ ┌─────────────┼─────────────┐ │ │ │ ┌─────▼─────┐ ┌────▼─────┐ ┌────▼─────┐ │ GPU節點1 │ │ GPU節點2 │ │ GPU節點3 │ │ vLLM │ │ vLLM │ │ vLLM │ │ 70B TP4 │ │ 70B TP4 │ │ 7B INT4 │ └─────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └─────────────┼─────────────┘ │ ┌───────▼───────┐ │ Redis緩存 │ │ (語義緩存) │ └───────────────┘關鍵組件組件作用技術選型負載均衡請求分發、健康檢查Nginx 自定義GPU指標語義緩存相似問題直接返回緩存Redis Embedding相似度級聯路由簡單→小模型復雜→大模型分類器/規則引擎限流保護后端不被打垮令牌桶 并發限制自動擴縮按負載增減GPU節點K8s HPA 自定義GPU指標降級策略超載時的兜底方案預設回復/更小模型追問級聯路由的分類器怎么訓練兩種方案(1) 基于規則——按query長度、關鍵詞、意圖分類(2) 訓練專用分類器——用歷史數據標注難度等級訓練輕量分類器(BERT-tiny即可)。關鍵是分類器本身延遲要10ms否則收益被分類開銷吃掉。高并發架構中的降級策略降級級別觸發條件降級動作L1輕度隊列20拒絕低優先級請求L2中度隊列50全部路由到小模型L3重度GPU OOM切換到備用CPU推理L4極端全部故障返回預設回復告警本章要點速查設計題核心考點關鍵Trade-offD1: RAG問答Chunk/檢索/生成RAG vs 微調D2: 訓練100B并行策略/數據配比算力分配D3: 部署70B量化/TP/Batching成本vs質量D4: Auto Agent規劃/工具/安全ReAct vs FCD5: 多模型平臺路由/調度/擴縮級聯vs分類器D6: 實時RAG流式/熱更新/時效延遲vs一致性D7: NL2SQLSchema/生成/驗證準確率vs延遲D8: 金融RAG精度/時效/合規嚴格vs靈活D9: 多Agent協調/通信/質量單Agent vs 多Agent