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