AI 系统设计面试题
AI 技术 ⭐⭐⭐ 高级 🔥🔥 中频
💡 核心要点
AI 系统设计面试考察候选人将 LLM 能力整合到生产系统的端到端工程能力——不仅要了解模型原理，还要能设计可扩展、可维护、成本可控的完整架构。关键在于：明确需求 → 选择合适的架构模式 → 识别核心组件 → 讨论权衡取舍。
AI 系统设计面试框架
与传统系统设计面试类似，AI 系统设计也遵循结构化流程，但需要额外考虑模型选择、Prompt 设计、评估体系等 AI 特有环节。
五步框架
设计题：智能客服系统
题目：设计一个面向电商平台的智能客服系统，能自动回答用户的订单查询、退换货政策、商品问题等，复杂问题需转人工。
需求分析
| 需求类型 | 详情 |
|---|---|
| 功能需求 | 多轮对话、订单查询、知识库问答、人工转接 |
| 非功能需求 | 首回复 < 2s、7×24 可用、支持中英文 |
| 规模 | 日活 10 万用户、峰值 QPS 500 |
| 约束 | 不能泄露其他用户数据、回答需准确（涉及金额） |
架构设计
关键技术决策
| 决策点 | 选择 | 理由 |
|---|---|---|
| 架构模式 | RAG + Agent (Tool Use) | 需要检索知识库 + 调用业务 API |
| 模型选择 | Claude Sonnet / GPT-4o-mini | 性价比优，速度快，足以胜任客服场景 |
| 知识库 | 向量数据库 + BM25 混合检索 | 语义检索 + 关键词检索互补 |
| 转人工策略 | 置信度阈值 + 规则触发 | 涉及投诉、金额争议、连续未解决时自动转人工 |
权衡讨论
准确率 vs 延迟：订单金额查询必须 100% 准确（通过 API 直接查询，不用 LLM 生成）；政策类回答可容忍小幅不准确，通过 RAG + 引用原文提高可信度。
成本控制：
- 常见问题使用语义缓存（相似问题命中缓存）
- 简单意图（查快递）走规则引擎，不调用 LLM
- 复杂问题才使用 LLM Agent
安全防护：
- 输入过滤：防止 Prompt 注入
- 输出过滤：不输出其他用户数据、不给出超范围承诺
- System Prompt 明确限定角色和能力边界
设计题：代码补全系统
题目：设计一个 IDE 内的智能代码补全系统，在用户编写代码时实时提供续写建议。
需求分析
| 需求类型 | 详情 |
|---|---|
| 功能需求 | 实时代码补全（行级 / 块级）、上下文感知 |
| 非功能需求 | 延迟 < 200ms（不能打断打字节奏）、低误补率 |
| 规模 | 10 万开发者并发、每秒数百万次触发 |
| 约束 | 代码隐私、多语言支持（Python/JS/Java/Go...） |
架构设计
关键技术决策
| 决策点 | 选择 | 理由 |
|---|---|---|
| 模型大小 | 1B~7B 专用代码模型 | 延迟 < 200ms 硬约束，大模型无法满足 |
| 补全模式 | FIM (Fill-in-the-Middle) | 需要同时利用光标前后的上下文 |
| 部署方式 | 自建推理服务 + GPU 集群 | 代码隐私要求高、请求量大，API 成本不可控 |
| 触发策略 | Debounce + 智能触发 | 避免无效请求，减少服务端压力 |
延迟优化
代码补全对延迟极为敏感（>300ms 用户体验明显下降），需要多层优化：
| 优化层 | 技术 | 效果 |
|---|---|---|
| 客户端 | Debounce、请求取消（新输入取消旧请求） | 减少 60%+ 无效请求 |
| 网络 | gzip 压缩、边缘节点就近推理 | 减少网络延迟 |
| 推理 | Prefix Caching（文件头 KV 缓存） | 减少 30%+ 计算 |
| 推理 | 推测解码 | 加速 2~3x |
| 推理 | INT4 量化 | 减少显存，提高吞吐 |
| 生成 | 提前终止（遇到自然断点停止） | 减少无用生成 |
权衡讨论
模型大小 vs 质量：1B 模型延迟低但补全质量有限（适合行级补全）；7B 模型质量更高但延迟增加（适合块级补全）。可采用级联策略——先用小模型快速补全，用户停顿时用大模型提供更高质量建议。
代码隐私：企业用户要求代码不离开内网。解决方案：私有化部署推理服务，或使用本地小模型（如 Ollama + CodeLlama）。
LLM 工程权衡
AI 系统设计面试中，权衡讨论往往比架构设计本身更能体现候选人的工程成熟度。
准确率 vs 延迟 vs 成本
三角不可能定理：不可能同时最优化准确率、延迟和成本三者，必须根据场景取舍。
| 场景 | 优先级 | 策略 |
|---|---|---|
| 医疗/法律问答 | 准确率 > 成本 > 延迟 | 大模型 + RAG + 多轮验证 |
| 实时聊天助手 | 延迟 > 准确率 > 成本 | 小模型 + 流式输出 |
| 批量数据处理 | 成本 > 准确率 > 延迟 | 小模型 + 批处理 + 异步 |
| 代码补全 | 延迟 > 准确率 > 成本 | 小模型 + 推测解码 + 缓存 |
自建 vs API
| 维度 | 自建部署 | 第三方 API |
|---|---|---|
| 初始成本 | 高（GPU 采购/租用） | 低（按用量付费） |
| 边际成本 | 低（固定硬件费用） | 线性增长 |
| 数据隐私 | 完全可控 | 数据离开内网 |
| 灵活性 | 可自定义模型/微调 | 受限于 API 提供的能力 |
| 运维负担 | 高 | 零 |
| 适用场景 | 高 QPS、隐私敏感、需微调 | 早期验证、低 QPS、快速上线 |
决策建议：早期用 API 快速验证产品价值，QPS 超过盈亏平衡点后考虑自建。
级联架构 Model Cascade
用小模型处理简单请求，只将复杂请求路由到大模型：
效果：可降低 50~70% API 成本，同时保持与纯大模型接近的质量。
常见陷阱
⚠️ 常见误区
一上来就选最大的模型：不同任务对模型能力的要求不同。简单分类/提取用小模型即可，只有开放域生成、复杂推理才需要大模型。先明确任务需求再选模型。
忽视成本分析：面试时只讨论技术架构不讨论成本，显得不成熟。应该估算 QPS × 平均 Token 数 × 单价，给出月度成本量级。
缺少降级方案：当 LLM 服务不可用时怎么办？应设计降级策略——如切换到备用模型、返回缓存结果、或转人工处理。
过度依赖 LLM：并非所有环节都需要 LLM。确定性逻辑（订单查询、价格计算）用规则引擎更可靠；只有需要自然语言理解/生成的环节才用 LLM。
面试真题详解
Q1：设计一个电商平台的智能客服系统
要点：
架构选择：RAG + Agent（Tool Use）架构，因为需要同时具备知识库检索和业务 API 调用能力。
核心组件：
- 意图识别：判断用户诉求类型（查订单、问政策、投诉、闲聊）
- RAG 知识库：存储退换货政策、商品信息、FAQ，使用向量+关键词混合检索
- Tool Use：调用订单查询 API、退换货系统 API，获取精确数据
- 对话管理：维护多轮对话上下文和用户会话状态
- 转人工判断：置信度低于阈值、涉及投诉/金额争议、用户主动要求时转人工
关键权衡：
- 涉及金额/订单数据的查询必须走 API，不能让 LLM 生成数据
- 使用语义缓存减少 LLM 调用成本
- System Prompt 严格限定角色边界，防止越权承诺
Q2：设计一个 IDE 内的代码补全系统
要点：
核心约束：延迟 < 200ms，这决定了整个架构选择。
架构设计：
- 模型选择：1B~7B 专用代码模型（CodeLlama / StarCoder2），延迟优先
- 补全模式：FIM（Fill-in-the-Middle）——同时利用光标前后的上下文
- 上下文构建：当前文件光标前后 N 行 + import 依赖文件 + 最近编辑片段
- 触发策略：Debounce 300ms + 智能触发（行尾、函数签名后）
延迟优化栈：
- 客户端：Debounce + 请求取消（新输入取消旧请求）
- 推理层：Prefix Caching（文件头 KV 缓存）+ 推测解码 + INT4 量化
- 生成层：提前终止（遇到自然断点停止）
权衡讨论：小模型适合行级补全、大模型适合块级补全，可用级联策略——快速小模型响应即时输入，用户停顿时大模型提供更高质量建议。