AI 工程师系统设计面试实用指南
作者 Aaron Cao · 更新于
它要求你端到端地设计一个机器学习系统：数据与特征、训练与评估、服务与延迟、监控与漂移。近期的面试轮次大量倾向于检索增强生成（RAG）与模型服务。评分标准是你能否为自己的权衡取舍辩护，而不是是否给出唯一正确的架构。
这一轮到底在考察什么
第一次听到这种题目时，它听起来广泛得离谱：设计一个推荐系统，或者设计一个基于公司内部文档的聊天机器人。本节要说明面试官到底在给什么打分，这样“范围太广”就不再是问题本身。简而言之，他们评的是你能否把一个模糊的产品需求，转化为一个带有具体数字的系统。
四件事决定了大部分分数：
- 范围界定。在动笔之前，你是否会问清楚用户是谁、每秒查询量是多少、什么样的质量标准才算成功？
- 数据判断力。训练数据从哪里来，如何标注，训练与服务之间又会泄漏什么？
- 评估。离线指标加上线上护栏。没有评估方案的答案，无论架构多漂亮，听起来都像是初级水平。
- 生产环境意识。延迟预算、每次请求的成本、重训练节奏，以及模型出错时会发生什么。
反复出现的题目类型
五类题目覆盖了大多数 AI 工程师系统设计轮次：
- 基于私有文档的检索增强生成。分块策略、embedding 模型选择、向量索引、重排序，以及当检索结果毫不相关时该怎么办。
- 大规模模型服务。批处理、量化、让 GPU 保持忙碌、缓存，以及你在范围界定阶段就承诺过的 p99 延迟目标。
- 推荐或排序。候选生成再排序、特征存储（feature store）、训练与服务偏差（skew）、冷启动。
- 特征管道。流式处理对比批处理、时间点正确性、回填。
- 智能体（agentic）工作流。工具调用、步数上限、成本上限，以及人工何时介入。更完整的题库见面试类型一节。
这些题目每一个都有一个面试官在等你说出的难点。对于检索，难点是评估——几乎所有人都能说出一个向量数据库的名字，但很少有人能说清楚该如何衡量检索是否真的变好了。对于服务，难点是成本与延迟相对模型大小的权衡。
一套能撑过 45 分钟的答题结构
把最初的五分钟花在需求和数字上，并把它们写在面试官能看到的地方：每秒查询量、可接受的延迟、质量标准、预算。之后的一切都要回指这四个数字，这正是让答案听起来像工程而不是工具巡展的关键。
接着做到广度优先：画一张图，包含数据源、离线训练、制品存储（artifact store）、服务路径和反馈回路。等整幅图都出现之后，再进行深入探讨，并且把选择哪个组件的权利交给面试官。最后，说出两种失效模式，以及你会监控什么来捕捉每一种。
一位应聘某搜索公司高级职位的机器学习工程师，被要求为支持工单设计语义搜索。她用四分钟做范围界定，承诺 200 毫秒的 p95 延迟、并设定固定的月度推理预算，然后用这两个数字否决了一个大型重排序器，转而选择在前 50 个候选项上使用一个小型交叉编码器（cross-encoder）。被打分的是这个权衡取舍本身，而不是模型的选择。
实时助手在设计轮次中能帮上什么忙
系统设计既要说也要画，所以在这一轮里，助手能帮的忙比其他轮次少。它能做的，是把清单一直留在你面前。SubcueAI 会监听会议音频，并在本地悬浮层上给出结构：你还没问到的范围界定问题、被你跳过的评估部分、值得指出的失效模式。macOS 和 Windows 上的桌面应用会同时采集系统音频和你的麦克风；浏览器扩展的侧边栏只采集会议标签页的音频，因此它只听得到面试官，不会转录你说的话。没有任何机器人会加入通话。
在这一轮里，限制条件比大多数轮次都更重要。如果你正在共享屏幕来画图，悬浮层也在你共享的画面之内。有监考的测评和公司托管的机器不在支持范围内，也没有任何工具能做到普遍不可检测。助手同样无法替你凭空构造被打分的架构判断力。在模拟面试页面上，针对 AI 面试官练习这些题目才能真正建立这种判断力；悬浮层只是防止你在第 30 分钟忘记评估这件事。