想象你考下了一级注册建筑师证书，朋友介绍来一位低调的客户。他在电话里只说了一句话：“我想盖栋房子，周末喝咖啡时你帮我看看。”然后就挂了。你不知道他想要别墅还是写字楼，不知道预算有多少，不知道地块在市中心还是郊区——但你们约好，45分钟咖啡时间，你要给他一份完整的设计方案。这听起来像天方夜谭？不，这正是机器学习（ML）系统设计面试的日常：面试官抛出“设计一个短视频推荐系统”这种开放命题，考的不是谁背的模型论文多，而是你在需求模糊、约束不清时，如何像一个成熟建筑师那样，把一栋楼从需求问到地基、从建材选到结构、从验收到交付，一步步搭出让客户放心的完整方案。 这篇文章不讲算法推导，也不用你提前会写代码。我会借“小林建筑师接活”的故事，带你把ML系统设计面试的标准施工流程走一遍：如何开场澄清需求、如何估算数据规模、如何设计特征、如何选择模型、如何定评估指标、如何画部署架构，最后用两道真题做全流程演练。读完你能建立一张清晰的答题地图——面试官想看的，正是你从“问题”走向“架构”的完整轨迹。

岗位关联

ML系统设计面试是大厂算法岗的“分水岭”关卡。掌握这套从需求澄清到部署监控的系统设计方法论，你就能在45分钟内展示自己的工程判断力，从“会调参”升级为“能架构”，显著提升拿offer的概率。

目录
  1. 可视化演示
  2. 面试概览
  3. 问题定义
  4. 数据设计
  5. 特征工程
  6. 模型方案
  7. 评估体系
  8. 部署架构
  9. 真题实战
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

动态演示ML系统设计面试的核心机制，通过基础/核心/应用/扩展四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

ML系统设计面试：ML系统 ML系统设计面试题型分类 六步答题框架详解 核心机制可视化 ML系统设计面试整体架构与关键组件

面试概览

小林建筑师接到客户电话后，第一件事不是翻图纸，而是打开日程表：45分钟能做什么？他心里迅速排了个序——先听客户讲需求，再问地块情况，中间留足时间选结构，最后一定留几分钟讲维护。他知道，一份烂设计往往不是画工差，而是根本没规划时间。ML系统设计面试也一样，开考瞬间，考官心里就有一张评分表：结构化思维、工程判断、需求澄清、方案落地。

所谓面试概览，就是先明白这场45分钟“施工交底”的游戏规则。常见题型翻来覆去就三类：推荐系统（短视频、资讯流、商品推荐）、搜索排序（电商搜索、文档检索）、广告排序（竞价广告、CTR预估）。考官不指望你45分钟写出一套生产级代码，他看的是你如何从模糊需求出发，一步步收敛出可讨论的架构方案。

答题节奏可以按比例拆开：开场5~8分钟澄清需求，中间15分钟设计数据与特征，接着15分钟讲模型与评估，最后10分钟画部署架构并聊扩展。把时间预算写出来，你就掌握了面试的第一把钥匙：

小林合上日程表笑了笑：45分钟规划下来，每个环节都有了着落。面试不是即兴演讲，而是一场有节奏的工程汇报——先控场，再深入。

T总=T澄清+T数据特征+T模型评估+T部署T_{\text{总}} = T_{\text{澄清}} + T_{\text{数据特征}} + T_{\text{模型评估}} + T_{\text{部署}}
这个公式提醒你：面试时间是稀缺资源，每个环节都该有预算，而不是兴致所至地发挥。
  1. 总面试时间 T 总面试全程约45~60分钟，先规划好每个环节的花费。
    T总=45 60 min\displaystyle T_{\text{总}} = 45\text{~}60\,\text{min}
  2. 澄清时段 T 澄清开局前5~8分钟用来提问、澄清需求与约束。
    T澄清=5 8 min\displaystyle T_{\text{澄清}} = 5\text{~}8\,\text{min}
  3. 数据特征时段 T 数据特征中间15分钟重点估算数据规模并构思特征体系。
    T数据特征=15 min\displaystyle T_{\text{数据特征}} = 15\,\text{min}
  4. 模型评估时段 T 模型评估再花15分钟选定模型、设计评估指标。
    T模型评估=15 min\displaystyle T_{\text{模型评估}} = 15\,\text{min}
  5. 部署时段 T 部署收尾10分钟画架构图、聊监控与模型更新。
    T部署=10 min\displaystyle T_{\text{部署}} = 10\,\text{min}

问题定义

咖啡馆里，小林没有立刻掏出笔，而是老实发问：“您这房子是自住还是投资？家里几口人？地块面积多大？预算量级？有没有必须满足的条件？”客户愣住了，随即点头。ML系统设计面试的第一个分水岭，就是你敢不敢在画架构图之前，先问一堆“外行问题”。

技术人说“设计推荐系统”，至少要把需求澄清成以下维度：用户是谁（新用户还是老用户？什么年龄段？）、使用场景（App内信息流还是搜索结果页？）、请求量级（DAU多少？QPS多少？）、硬约束（实时性要求？成本敏感？）。这些信息直接决定数据管道、模型复杂度和部署架构的选型——就像地块面积决定了你能不能盖五层楼。

澄清之后是把业务目标翻译成机器学习目标。短视频推荐的目标是“观看时长最大化”，电商搜索的目标是“GMV最大化”，广告系统的目标是“收入最大化”。目标不同，监督信号、样本构造、评估指标全都不一样。这就是目标量化的价值：

小林在纸上写下“目标=总观看时长”几个字，客户眼睛亮了——原来盖房子前先问清楚“住几个人”，比任何炫技都重要。需求澄清不是浪费时间，而是让方案不跑偏的定盘星。

优化目标=∑i=1nCTRi×价值i\text{优化目标} = \sum_{i=1}^{n} \text{CTR}_i \times \text{价值}_i
这条公式把业务语言翻译成了数学语言：对每个推荐位 \(i\)，用点击率（CTR）乘以单次点击带来的价值，求和后就是要优化的总目标。
  1. CTR 点击率用户看到推荐内容后点击的概率，衡量“吸不吸引人”。
    CTRi=点击次数i曝光次数i\displaystyle \text{CTR}_i = \frac{\text{点击次数}_i}{\text{曝光次数}_i}
  2. 价值 单次点击的价值不同业务对点击赋予不同权重，比如电商里是成交概率与客单价。
    价值i=转化率i×客单价i\displaystyle \text{价值}_i = \text{转化率}_i \times \text{客单价}_i
  3. 求和符号 Σ把推荐流上每一个位置的贡献加起来，就是整体业务收益。
    ∑i=1n(⋅)=位置1+位置2+⋯+位置n\displaystyle \sum_{i=1}^{n} (\cdot) = \text{位置}_1 + \text{位置}_2 + \cdots + \text{位置}_n
  4. 目标函数选定目标函数一旦确定，后面所有环节都以它为准绳做取舍。

数据设计

客户带小林看了地块。小林没急着画图，而是蹲下来挖了一铲土：土质松软还是坚硬？地下水位高不高？周边有没有高楼遮挡采光？数据之于ML系统，就是地基之于房子——模型再漂亮，地基不行一样塌。

ML系统设计中的数据设计有四件事：数据来源（用户行为日志、内容属性库、外部知识库）、规模估算（日活多少、每人每天产生多少条记录、数据增长速度）、数据质量（缺失率、噪声、采集偏差）、标注策略（人工标注成本、半监督/弱监督方案）。面试中，规模估算是必考题，面试官想看你有没有基本的量级感。

估算存储量可以用一条乘法公式——每天产生多少、每条多大、保留多久，三者的乘积就是你需要准备的存储空间：

小林在土里捡起一块碎石掂了掂，很快判断出地基预算。数据设计就是这么朴实——把量级算清楚，把质量摸明白，后续的特征和模型才有得聊。

存储量=DAU×人均请求×单条记录大小×保留天数\text{存储量} = \text{DAU} \times \text{人均请求} \times \text{单条记录大小} \times \text{保留天数}
数据规模不是拍脑袋，而是几个关键数字乘出来的量级判断。这个量级决定了你是用单机MySQL还是分布式数仓，是离线批量还是实时流式计算。
  1. DAU 日活跃用户数一天内使用产品的用户数量，数据量的基数。
    DAU=每日打开App的去重用户数\displaystyle \text{DAU} = \text{每日打开App的去重用户数}
  2. 人均请求数每个用户平均每天触发多少次行为（曝光、点击、播放）。
    人均请求=日总请求数DAU\displaystyle \text{人均请求} = \frac{\text{日总请求数}}{\text{DAU}}
  3. 单条记录大小一条日志占多少字节，通常几百字节到几KB。
    单条记录大小≈0.5 2 KB\displaystyle \text{单条记录大小} \approx 0.5\text{~}2\,\text{KB}
  4. 保留天数日志需要存多久，一般30~90天，用于训练与回溯。
    存储量=日增数据量×保留天数\displaystyle \text{存储量} = \text{日增数据量} \times \text{保留天数}

特征工程

地基勘察完，小林带客户去建材市场。水泥有325标号、425标号，钢筋有6毫米、8毫米、10毫米，木材分一、二、三等品。特征就是模型的建材：什么样的料配什么样的活，选错材料，结构再合理也扛不住风雨。

ML系统里的特征主要分三路：用户特征（年龄、城市、历史点击序列）、物品特征（类目、价格、文本和图片内容）、上下文特征（当前时间、网络环境、设备型号）。这三路特征拼在一起，模型才知道“谁在什么时候对什么东西感兴趣”。

拿到原始特征不能直接用，得先“加工”：数值特征做归一化或分桶，类别特征做独热编码或嵌入，缺失值要决定填充还是置零。高维稀疏类别特征（比如几千万个物品ID）通常用嵌入降维：

建材选好，还要解决“线上和线下用同一批料”的问题——训练时特征怎么算，线上推理时也必须一模一样，否则模型上线就“水土不服”。小林提醒客户：好房子不仅靠设计，靠的是每一根钢筋都按图纸放到位。

嵌入维度=∑k=1Kdk×1[采用特征k]\text{嵌入维度} = \sum_{k=1}^{K} d_k \times \mathbb{1}[\text{采用特征}_k]
嵌入（Embedding）就是把一个高维稀疏的类别ID映射成一个低维稠密向量。总维度由你决定采用哪些特征、每个特征用多少维嵌入相加得到。
  1. 特征索引 k遍历候选特征集合，每个特征都有自己的编号。
    k=1,2,⋯ ,K\displaystyle k = 1, 2, \cdots, K
  2. 指示函数 1[……]如果采用这个特征，记为1，否则为0。
    1[⋅]=1  当且仅当条件成立\displaystyle \mathbb{1}[\cdot] = 1 \;\text{当且仅当条件成立}
  3. 单特征维度 d_k每个类别特征映射成多少维向量，常用8~64维。
    dk∈{8,16,32,64}\displaystyle d_k \in \{8, 16, 32, 64\}
  4. 求和得到总维度所有被采用特征的维度之和，就是模型输入层的大小。

模型方案

建材定了，该决定结构了。六层小楼用砖混就够，二十层高层必须框架剪力墙——不是越贵的结构越好，是越匹配的越好。模型选型同理：没有万能模型，只有场景匹配。

经典选型经验：逻辑回归（LR）可解释性强、训练快，适合做粗排或baseline；GBDT这类树模型擅长处理表格特征，在中小规模数据上依然能打；深度神经网络（DNN）适合海量稀疏特征和序列行为建模，是精排主力。面试中别只堆一个模型，要讲清楚两阶段漏斗：召回从千万级物品中快速筛出几千候选，粗排用轻量模型筛到几百，精排用复杂模型逐条精打分。三层漏斗各司其职，才扛得住大规模流量：

新用户没有历史行为怎么办？这就是冷启动问题——像一栋没人住过的空房子，没有水电数据可供参考。解法是先用内容属性（价格便宜、热度高、覆盖面广的物品）做猜测，等用户产生几条行为后再切换到个性化模型。结构选型是面试重头，但记住：面试官想听的是“为什么选它”，而不是模型列表背诵。

∣C召回∣>∣C粗排∣>∣C精排∣|C_{\text{召回}}| > |C_{\text{粗排}}| > |C_{\text{精排}}|
漏斗的核心思想：越是靠近决策的环节，计算越贵，候选数量必须越小。召回管够、粗排管快、精排管准。
  1. 召回候选集 C 召回从全量物品中快速筛选出几千个候选，常用双塔向量召回或热门兜底。
    ∣C召回∣≈103 104\displaystyle |C_{\text{召回}}| \approx 10^3\text{~}10^4
  2. 粗排候选集 C 粗排用轻量模型从数千筛到几百，特征少、计算快。
    ∣C粗排∣≈102 103\displaystyle |C_{\text{粗排}}| \approx 10^2\text{~}10^3
  3. 精排候选集 C 精排用完整特征的复杂模型精打分，最终只保留几十个结果。
    ∣C精排∣≈101 102\displaystyle |C_{\text{精排}}| \approx 10^1\text{~}10^2
  4. 规模严格递减数量从大到小，计算成本从低到高，保证延迟可控。

评估体系

房子盖好，小林递给客户两张表：一张是图纸对照清单，一张是入住体验问卷。模型好不好，不能靠直觉，要有一套验收标准。评估体系分三层，层层递进。

第一层离线指标：数据集上直接算，比如分类里的精确率（Precision）、召回率（Recall）、F1分数，排序里的AUC、Precision@K。第二层在线指标：真实流量下的业务表现，如CTR、人均观看时长、次日留存。第三层业务指标：公司真正关心的钱，如GMV、广告收入。离线指标只是“图纸”，在线和业务指标才是“住进去的感受”。离线最常用的综合指标是F1：

光有指标还不够，怎么证明提升是模型带来的？答案是AB实验：把用户随机分两组，一组用旧模型、一组用新模型，跑足够长时间，用统计检验看差异是否显著。像验收房子不能只看晴天——要等一场暴雨，看墙面渗不渗水。评估体系完整，面试官才敢相信你的方案不是纸上谈兵。

F1=2×Precision×RecallPrecision+RecallF1 = \frac{2 \times \text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}}
F1是精确率和召回率的调和平均。它惩罚“偏科”的模型——只求准不求全，或只求全不求准，F1都会难看。
  1. 精确率 Precision预测为正的样本里，有多少是真的正例。
    Precision=TPTP+FP\displaystyle \text{Precision} = \frac{TP}{TP + FP}
  2. 召回率 Recall所有真实正例里，模型找回了多少。
    Recall=TPTP+FN\displaystyle \text{Recall} = \frac{TP}{TP + FN}
  3. 分子 2 倍乘积给精确率和召回率一个“均衡”的奖励信号。
    2×Precision×Recall\displaystyle 2 \times \text{Precision} \times \text{Recall}
  4. 分母相加两者之和作为归一化，保证F1在0到1之间。

部署架构

交房那天，小林递给客户一把钥匙和一份《物业手册》：电梯坏了找谁、配电房多久巡检一次、外墙渗水报修流程。客户愣住了：“建筑师还管这个？”小林说：“不管物业的房子，三个月就该后悔了。”ML系统的部署架构，就是这栋楼交付后的物业保障。

部署架构要讲清四件事。服务分层：客户端→网关→推荐服务→特征服务（KV存储）→模型推理，每层职责单一、可水平扩展。延迟预算：一次推荐请求端到端不能超200毫秒，其中网络传输、特征读取、模型推理各占多少，要在设计时写清楚。监控告警：除了常规的延迟、错误率，还要监控数据漂移（线上特征分布和训练时不一致）和模型效果衰减。模型更新：每周周期性重训还是实时在线学习，取决于数据变化速度。

延迟预算是部署架构里的核心计算题，画成公式就是：

监控发现有异常怎么办？灰度发布与回滚：新模型先放5%流量观察，指标平稳再全量。这套架构讲完，面试官看到的不只是模型，而是一个能长期稳定运行的系统。

L总=L网络+L特征+L推理+L其他≤200 msL_{\text{总}} = L_{\text{网络}} + L_{\text{特征}} + L_{\text{推理}} + L_{\text{其他}} \leq 200\,\text{ms}
200毫秒是移动端推荐的常见体验红线。每个环节都要报出预算，加起来不能超标——这和装修预算一样，哪项超支都要从别处省回来。
  1. 网络传输 L 网络客户端到服务器的往返时间，通常20~50ms。
    L网络≈20 50 ms\displaystyle L_{\text{网络}} \approx 20\text{~}50\,\text{ms}
  2. 特征读取 L 特征从KV存储取特征的时间，通常10~30ms。
    L特征≈10 30 ms\displaystyle L_{\text{特征}} \approx 10\text{~}30\,\text{ms}
  3. 模型推理 L 推理模型前向计算的时间，通常在30~80ms。
    L推理≈30 80 ms\displaystyle L_{\text{推理}} \approx 30\text{~}80\,\text{ms}
  4. 预算约束各环节相加，必须控制在用户体验可接受的红线内。
    L总≤200 ms\displaystyle L_{\text{总}} \leq 200\,\text{ms}

真题实战

故事最后，客户终于说出他的真实需求：“我家是二胎家庭，想在城市公园旁边盖一栋小别墅。”小林笑了——现在，把前面所有流程串起来，现场演练一遍。

真题一：设计短视频推荐系统。 澄清：目标是什么？“人均观看时长最大化。”数据：DAU 3亿，人均每天刷50条，单条曝光日志0.5KB，保留30天，存储量就是 \(3亿 \times 50 \times 0.5KB \times 30\)。特征：用户历史观看序列、视频标签与时长、当前时间。模型：召回用双塔向量检索，精排用DNN预估观看概率与时长。评估：离线看AUC和Recall@K，在线看人均时长和留存，AB实验验证。部署：特征走KV存储，推理走GPU集群，延迟预算150ms，监控播放失败率与时长漂移。五段走完，架构图跃然纸上。

真题二：设计电商搜索排序。 目标从“点击最大化”改成“GMV最大化”：

客户听完，感慨道：“原来盖房子不只是画图纸。”踩坑提醒也藏在故事里：不澄清需求直接建模、只讲模型不讲数据、忽略评估部署、时间分配失衡——这四个坑，每一个都是面试官的扣分点。面试官最看重的，是你能不能把一个问题从头讲到尾，讲成一个可落地的系统。

GMV=曝光量×CTR×转化率×客单价\text{GMV} = \text{曝光量} \times \text{CTR} \times \text{转化率} \times \text{客单价}
  1. 曝光量搜索结果页展示的商品次数，是流量入口基数。
    曝光量=搜索PV×每页商品数\displaystyle \text{曝光量} = \text{搜索PV} \times \text{每页商品数}
  2. CTR 点击率吸引用户点击的能力。
    CTR=点击次数曝光次数\displaystyle \text{CTR} = \frac{\text{点击次数}}{\text{曝光次数}}
  3. 转化率点击之后实际成交的比例。
    转化率=成交次数点击次数\displaystyle \text{转化率} = \frac{\text{成交次数}}{\text{点击次数}}
  4. 客单价每笔订单的平均金额，衡量商品的“含金量”。

AI 应用场景

电商推荐系统重构

阶段：问题定义 → 数据设计 → 特征工程 → 模型方案 → 评估体系

解决的问题：某电商平台的“猜你喜欢”一直用物品协同过滤，只能覆盖热销品，长尾商品几乎没有曝光。算法团队重构时，第一步不是换模型，而是和业务方对齐目标——从“点击率提升”改为“GMV提升”。接着盘点数据：用户行为日志、商品属性、价格库存，估算日增数据量后设计了实时特征管道。模型采用召回+精排两阶段架构，离线用AUC与Recall@K验收，上线后通过AB实验验证GMV提升效果。

具体案例：重构后首页推荐位CTR提升12%，长尾商品曝光量提升3倍，整体GMV提升8%。关键成功因素正是按“澄清目标→盘点数据→设计特征→选模型→AB验证”的顺序完整走了一遍，没有跳步。

内容App冷启动策略

阶段：问题定义 → 数据设计 → 模型方案

解决的问题：新用户没有行为数据，个性化模型无法生效，传统做法是简单推荐热门内容，但留存率很低。解决方案是设计一个“两段式冷启动”：新用户前20次请求走基于内容属性（频道、标签、热度）的探索策略，同时快速积累行为；积累足够后再切换到个性化DNN。数据管道记录用户每次曝光和点击，特征服务实时更新用户短期兴趣画像。

具体案例：一款新闻App通过冷启动策略，新用户次日留存提升5个百分点，7日留存提升3个百分点。同时团队搭建了数据漂移监控，观察“新用户画像分布”是否偏离训练集，确保冷启动策略长期有效。

Python 演示

python49 行
import random def generate_data(n_users=100, n_items=50):    """生成模拟用户物品交互数据: (用户ID, 物品ID, 评分)"""    data = []    for u in range(n_users):        for i in range(n_items):            if random.random() < 0.05:                data.append((u, i, random.randint(1, 5)))    return data def recall(user_id, data, k=10):    """召回阶段: 热门物品兜底 + 该用户交互过的物品"""    pop = {}    for u, item, r in data:        pop[item] = pop.get(item, 0) + 1    interacted = {item for u, item, r in data if u == user_id}    recalls = set(interacted)    for item in sorted(pop, key=pop.get, reverse=True):        recalls.add(item)        if len(recalls) >= k:            break    return list(recalls)[:k] def rank(user_id, candidates, data):    """精排阶段: 热门度加权 + 类目亲和力修正"""    pop = {}    for u, item, r in data:        pop[item] = pop.get(item, 0) + 1    def score(item):        affinity = 0.3 if item % 3 == user_id % 3 else 0.0        return pop.get(item, 0) * 0.7 + affinity    return sorted(candidates, key=score, reverse=True) def precision_at_k(true_items, rec_items, k=5):    """计算推荐结果的Precision@K"""    hits = len(set(true_items) & set(rec_items[:k]))    return hits / k if __name__ == "__main__":    random.seed(42)    data = generate_data(100, 50)    test_user = 0    true_items = {item for u, item, r in data if u == test_user}    cands = recall(test_user, data, k=10)    ranked = rank(test_user, cands, data)    print("Top-5 推荐:", ranked[:5])    print("真实交互:", sorted(true_items))    print("Precision@5:", precision_at_k(true_items, ranked, k=5))
目的：用不到40行代码模拟一个“召回→精排→评估”的完整推荐流水线，演示系统设计中各环节如何衔接。
  1. generate_data(100, 50)生成100个用户、50个物品的稀疏交互数据，模拟真实行为日志。
  2. pop[item] = pop.get(item, 0) + 1统计每个物品的交互次数作为“热度”，这是召回兜底的基础。
  3. recalled = set(interacted)召回阶段先拿用户交互过的物品，再用热门物品补齐到k个。
  4. sorted(pop, key=pop.get, reverse=True)按热度排序物品，热度高的优先进入候选集。
  5. def score(item)精排打分公式：热度权重0.7 + 用户对类目的亲和力修正0.3。
  6. precision_at_k(true_items, ranked, k=5)用Precision@5评估推荐质量，正是正文评估体系的落地实现。

常见误区

误区“面试官问设计推荐系统，我直接开讲Transformer和FFM，把深层交叉、注意力机制全甩出来，结果面试官表情越来越凝重。”

正解系统设计面试不是模型炫技比赛。面试官最看重的是你能否从需求出发一步步收敛。不澄清“用户是谁、目标是什么、量级多大”，再先进的模型也只是空中楼阁。正确顺序永远是：需求→数据→特征→模型→评估→部署。

为何常见：求职者花大量时间背模型论文，误以为越前沿越能打动面试官，忽略了系统设计考察的是工程全局观。

误区“训练数据反正是公司日志里现成的，标注找外包就行，这部分不用花时间讲。”

正解数据是ML系统最重要的地基。面试官会追问：数据从哪来？每天产生多少？要不要标注？标注成本多少？数据稀疏怎么办？答不上来，方案就没有落地性。规模估算体现的是你的量级感，标注策略体现的是你的成本意识。

为何常见：算法工程师日常习惯了现成的数据集，很少从零思考“数据从哪来”的问题，面试时自然想不起来。

误区“评估模型好坏，看准确率就行了，准确率95%说明效果很好。”

正解推荐和搜索场景高度不平衡——用户点击的物品占比极低。准确率在这里毫无意义，必须用Precision@K、Recall@K、AUC、NDCG等排序类指标，再配合在线CTR、时长、留存等业务指标。离线指标是图纸，在线指标是入住体验，两者都要讲。

为何常见：准确率是分类课程里最先学的指标，惯性思维让人忽略了它的适用边界。

误区“系统设计嘛，画个模型结构图不就行了？输入特征、输出预测，完事。”

正解一个完整的ML系统包括数据管道、特征服务、模型推理、评估监控、模型更新五大块。只画模型意味着你只理解了算法的5%。面试官期待看到：特征存在哪、服务怎么分层、延迟怎么控制、模型怎么更新、线上怎么监控数据漂移。

为何常见：平时做离线实验接触不到工程链路，容易把“模型训练”等同于“系统设计”。

误区“前面聊得很细，特征讲了三十分钟，最后面试官问部署架构，我只能说'这块不太熟'。”

正解45分钟是固定预算，每个环节都要有产出。推荐时间表是：澄清5~8分钟、数据特征15分钟、模型评估15分钟、部署10分钟。哪怕某个环节很熟，也要克制，保证全流程完整——结构完整永远比局部深入重要。

为何常见：人在熟悉的话题上容易失控，越讲越兴奋，把面试变成了单点技术分享。

面试题

Q1. ML系统设计面试的第一步应该做什么？

单选题 · easy

  • A.选择最新模型
  • B.澄清业务需求← 正确答案
  • C.部署监控服务
  • D.计算评估指标

答案：B。系统设计面试第一要务是澄清需求——用户是谁、场景是什么、目标是什么。像建筑师先问客户“住几个人”再画图一样，跳过需求直接谈模型是踩坑率最高的行为。

Q2. 召回阶段的主要目标是什么？

单选题 · easy

  • A.训练复杂深度学习模型
  • B.清洗无效点击日志数据
  • C.快速缩小候选物品范围← 正确答案
  • D.精确打分排序全部物品

答案：C。召回是从海量物品中快速筛选出候选集合，追求“够快、别漏”，而非“绝对精准”。相当于在整座城市里先圈出几个街区，再入户精查。

Q3. 面试中踩坑率最高的行为是下列哪一项？

单选题 · easy

  • A.不澄清需求就给方案← 正确答案
  • B.不评估指标就上线模型
  • C.不使用框架就写网络
  • D.不画流程图就开始口述

答案：A。需求澄清是系统设计的起点。不澄清用户、场景、量级就给出具体的模型和架构，等于盲人摸象。面试官把你拉回问题本身，就是考察你有没有先把“客户需求”问清楚。

Q4. 排序类任务应优先采用哪个评估指标？

单选题 · mid

  • A.全局准确率高低
  • B.排序头部命中质量← 正确答案
  • C.模型参数量大小
  • D.训练收敛速度快慢

答案：B。推荐/搜索关心的是排序结果前几位是否命中，因此用Precision@K、Recall@K这类头部命中指标，而非全局准确率。准确率会被大量负样本稀释，看起来很高但没意义。

Q5. 粗排加精排的两阶段设计核心优势是什么？

单选题 · mid

  • A.减少模型特征数量
  • B.省去人工标注环节
  • C.降低全量精算开销← 正确答案
  • D.简化离线数据管道

答案：C。千万级候选全用精排模型打分，延迟和计算成本不可接受。先用轻量粗排筛到几百，再让精排做精细打分，本质是用计算量换延迟，和漏斗逐级收窄同理。

Q6. 训练数据与线上实际分布不一致时会发生什么？

单选题 · mid

  • A.模型的训练速度变快
  • B.训练集上准确率下降
  • C.线上效果与离线评估出现偏差← 正确答案
  • D.特征维度自动发生变化

答案：C。训练分布和线上分布不一致叫“数据漂移”。离线指标很漂亮，上线后CTR反而下降，这是因为模型学到的规律在线上不成立了，所以部署后要持续监控特征分布。

Q7. 新用户没有历史行为记录，最合理的冷启动策略是什么？

单选题 · mid

  • A.直接拒绝新用户的访问请求
  • B.利用内容属性做热门推荐← 正确答案
  • C.把模型随机参数冻结等待
  • D.要求用户手动填写全部偏好

答案：B。冷启动的经典解法是用物品内容属性（类目、标签、热度）做探索式推荐，快速积累行为后再切换到个性化模型。相当于新房没人住过，先按户型图推最优配置，住进去再按习惯调整。

Q8. 一个完整的ML系统设计通常包含哪些环节？

多选题 · mid

  • A.数据管道与特征服务← 正确答案
  • B.模型训练与离线评估← 正确答案
  • C.在线推理与监控告警← 正确答案
  • D.公司团建与考勤管理

答案：ABC。完整ML系统是数据→特征→模型→评估→部署的闭环，每个环节都要在面试中覆盖。团建考勤是干扰项，工程落地性才是考察重点。

Q9. 搜索排序场景下应当重点关注的评估指标有哪些？

多选题 · hard

  • A.排序位置的归一化折损← 正确答案
  • B.前K个结果的召回质量← 正确答案
  • C.模型训练参数量大小
  • D.点击率预估的离线AUC← 正确答案

答案：ABD。排序任务重点关注NDCG（归一化折损累计增益）、Recall@K、CTR预估AUC。参数量只是工程实现细节，不是评估搜索效果的指标。

Q10. 线上CTR突降时，按监控链路应优先排查哪些方面？

多选题 · extreme

  • A.检查特征数据是否分布漂移← 正确答案
  • B.查看服务延迟与错误率告警← 正确答案
  • C.确认近期模型版本与发布记录← 正确答案
  • D.询问测试同学是否改过文案

答案：ABC。CTR突降是典型的系统异常，按监控链路排查优先级是：特征数据漂移→服务健康状态→模型版本变更。测试同学改文案虽然可能影响，但优先级低于前三项，且不是ML监控链路的常规检查项。