系统设计面试里的 AI 题——2025 年怎么准备
系统设计面试里的 AI 题——2025 年怎么准备
适读人群：准备 AI 工程岗位面试的工程师 | 阅读时长：约15分钟 | 核心价值：建立 AI 系统设计题的思维框架，不是背答案而是掌握面试官真正想考察的东西
去年帮朋友 Mock 面试，他在准备一家做 AI 产品公司的系统设计轮。他让我出一道 AI 系统设计题，然后他来回答。
我问他：设计一个内部知识库 QA 系统，支持员工查询公司文档。
他答了大概 20 分钟，说了向量数据库、Embedding、LangChain、chunk 分割……听起来关键词都在，但我越听越觉得哪里不对。
最后我问他：你这套系统，如果有员工问了一个敏感问题（比如同事的薪资信息），会怎么处理？
他愣了一下，说"这个没想过"。
然后我问：你的知识库有 100 万条文档，检索一次大概多少毫秒？用户可以接受多长延迟？
他又愣了。
这就是 2025 年 AI 系统设计面试的真实情况：关键词满分，但设计能力为零。
面试官想考的不是你知道哪些工具名字，是你能不能像一个真正要把这个系统上生产的工程师一样思考。
2025 年 AI 系统设计题的变化
传统的系统设计题（设计 Twitter、设计 URL 短链、设计分布式缓存）有成熟的套路，面试备考资料一搜一大把。
AI 系统设计题目前还在形成期，但已经有几个明显的特点：
一、答案不唯一，面试官在看你的决策思路
设计一个 RAG 系统，用 Pinecone 还是 Qdrant？用 OpenAI 还是自部署模型？这些选择没有唯一正确答案，面试官在看：你做这个选择时考虑了哪些维度，你是否理解这个选择的代价。
二、Cost 意识是核心考察点
AI 系统的 API 调用是有成本的，设计方案里如果完全不提成本控制，是非常明显的减分项。每次 LLM 调用的成本、缓存策略、模型选择对成本的影响——这些应该出现在你的设计里。
三、Failure Mode 比 Happy Path 更重要
"当模型返回不正确的信息时怎么处理""当向量数据库挂了怎么降级""当延迟超过 SLA 时怎么办"——这类问题比"如何实现基本检索"更能拉开差距。
四、评估和监控是必答题
上线了，怎么知道效果好不好？怎么发现效果变差了？这两个问题如果答不出来，说明你对 AI 系统的认知还停留在"跑通 Demo"阶段。
三道高频题型和思路框架
题型一：设计一个 RAG 知识库 QA 系统
这是出现频率最高的题型，几乎每家做 AI 的公司都会问这个。
面试官真正在考什么：
- 你是否理解 RAG 的各个组件及其权衡
- 你能否考虑生产级别的挑战（数量级、延迟、成本、数据更新）
- 你如何处理边界情况（问题超出知识库范围、返回结果不可信）
回答框架：
1. 澄清需求（2-3分钟）
- 规模：文档数量？用户 QPS？
- 语言：中文/英文/多语言？
- 实时性：知识库多久更新一次？
- 准确性要求：有 fallback 到人工的机制吗？
- 数据敏感性：有权限控制需求吗？
2. 整体架构（3-4分钟）
离线流程（文档处理）：
文档 → 解析清洗 → Chunking → Embedding → 向量库
在线流程（查询）：
用户问题 → Query 改写 → 向量检索 → 重排序 → 组装 Prompt → LLM 生成 → 结果返回
3. 关键决策点（每个点说清楚为什么）
- Embedding 模型选择：自托管 vs API，中文支持
- Chunk 策略：大小、重叠、按内容结构切
- 检索策略：向量检索 + BM25 混合，top-k 数量
- 重排序：Cross-encoder 精排，对 top-k 结果做二次打分
- LLM 选择：任务复杂度 vs 成本
- Prompt 设计：如何处理无法回答的情况
4. 生产级挑战（重点展示）
- 延迟控制：向量检索 < 100ms，LLM 调用使用流式输出
- 成本控制：缓存高频问题，对简单问题用小模型
- 数据更新：增量更新 vs 全量重建，更新延迟如何处理
- 权限控制：文档级别的权限过滤（检索后过滤，不只是搜索时过滤）
5. 评估和监控
- 离线评估：标注测试集，定期跑 recall@k, MRR
- 在线监控：用户满意度（有没有追问/投诉），答案被引用率
- 效果报警：核心指标下降时告警得分点： 权限控制（很多人忘了）、成本估算（说出具体数字范围）、说出"不知道就不回答"的兜底设计。
题型二：设计一个成本可控的 AI 客服系统
这道题的核心在"成本可控"四个字，考的是你对 AI 系统经济性的理解。
面试官真正在考什么：
- 你是否理解 LLM API 的计费方式及成本控制手段
- 你能否设计一个分层处理的架构（不是所有问题都用最贵的模型）
- 你如何平衡成本和效果
关键框架——分层处理架构：
用户问题
|
意图识别（轻量级分类器）
|
+-- 简单常见问题 → 规则/模板直接回答（零 LLM 成本）
|
+-- 中等复杂度 → 小模型 + RAG（低 LLM 成本）
|
+-- 复杂问题 → 大模型 + RAG（正常成本）
|
+-- 超出范围 → 转人工（零 LLM 成本，但有人力成本）关键成本控制手段：
- 语义缓存：把历史问题和答案缓存，新问题先查缓存，相似度高于阈值直接用缓存答案
- 模型路由：根据问题复杂度动态选择模型（这是最重要的成本控制手段）
- Prompt 优化：减少 System Prompt 长度，不传多余的 context
- 流式输出：减少等待时间，提升用户体验，不直接节省成本但改善感知
需要说出的数字：
面试里说"GPT-4o 比 GPT-4o-mini 贵约 10 倍，但在简单问题上效果相近"，这种具体数字感会让面试官印象深刻。不需要说特别精确，数量级正确就行。
题型三：设计一个代码审查 AI 助手
这个题型考察你对 AI 在实际开发流程里定位的理解，以及对 code context 管理的思考。
面试官真正在考什么：
- 你是否理解 code context 对 LLM 效果的影响
- 你如何处理代码隐私和安全问题
- 你如何设计评估指标（代码 Review 的质量如何量化）
关键设计决策：
代码上下文处理：
- PR 的 diff 可能很大，如何截取有效上下文
- 需要加入：文件类型、项目语言、相关文件（被修改函数的调用者）
- 不需要加入：无关文件、注释、测试文件（取决于场景）
隐私和安全：
- 代码是否可以发给外部 API？（合规问题）
- 如果不能：需要自托管模型
- 如果可以：敏感字符串（API key、密码）需要在发出前脱敏
评估体系：
- 精确率：AI 标注的问题，真正是问题的比例
- 召回率：真实存在的问题，AI 发现了多少
- 有用性：开发者接受 AI 建议的比例通用的回答原则
不管什么 AI 系统设计题，这几条原则通用：
原则一：澄清需求，不要假设
"QPS 是多少""有多少用户""准确率要求是多少""数据能上公有云吗"——这些问题一定要在开始设计之前问。没有这些信息，设计方案就是空的。
不问需求直接开始画架构，是一个非常明显的失误。
原则二：说出你选择的代价
不要只说你选了什么，要说你为什么选，以及这个选择的代价是什么。"我选 Qdrant 而不是 Pinecone，因为我们有数据本地化要求，代价是需要自己运维"——这比"我选 Qdrant"的信息量大得多。
原则三：主动提到 Failure Mode
不要等面试官问"如果 XX 挂了怎么办"，主动说"这里有一个 failure case 需要考虑"。主动发现问题，比被动回答问题，给面试官的信号完全不同。
原则四：给出可量化的设计目标
"系统要快"不是工程设计，"P99 延迟在 2 秒以内，在这个约束下我做了 XX 设计"才是。在 AI 系统里，可量化的目标包括：延迟、成本（每千次请求的 API 成本）、准确率目标、可用性 SLA。
最后一句实用建议：
AI 系统设计面试的准备，和传统系统设计面试一样——做实际项目，比看一百篇面经管用。如果你做过一个真实的 RAG 系统，把它搭起来、出过问题、修复过问题，面试里讲自己踩过的坑，要比背框架更有说服力。
面试官是在评估你能不能来做事，不是在评估你能不能背流程图。