大厂面试中拉开差距的核心题型。面试官给一个开放场景让你设计解决方案。评分标准不在答案正确而在结构化思考、权衡取舍、知识广度。本章提供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