AI 系统设计高频追问与深度题¶
真正决定系统设计面试上下限的，往往不是你主答案里的那张架构图，而是面试官压深度时你还能不能讲稳。到 2028，AI 岗位的深度追问已经明显集中到
模型选择、数据与评测、稳定性、安全、成本、Agent 平台化这些点。
这章解决什么问题¶
很多人系统设计主线讲得还可以，但一旦被追问就会崩：
- 为什么选这个模型
- 为什么不直接调 API
- 如果离线好、线上差怎么办
- 成本扛不住怎么办
- 出事故怎么降级
所以这一章的目标是：给你一套高频追问的思考骨架，而不是零散答案。
先记住一个原则¶
深度追问通常不是在考你“知道多少名词”，而是在考你 3 件事：
- 有没有 trade-off 意识
- 有没有真实生产感
- 有没有职业判断力
很多回答失败，不是知识不会，而是没有把答案组织成权衡。
5 大类高频追问¶
| 类别 | 面试官真正想看什么 |
|---|---|
| 模型与方案选择 | 你是否会做取舍 |
| 数据与评测 | 你是否懂 AI 特有闭环 |
| 稳定性与安全 | 你是否考虑上线后真实问题 |
| 成本与容量 | 你是否有业务现实感 |
| 平台与组织化 | 你是否能从单点系统上升到平台视角 |
一、模型与方案选择类¶
这类问题最看重判断框架，因为面试官想知道你是不是在用约束条件选方案，而不是背名词。
Q1：自建模型 vs 调 API，怎么选¶
你不要答成“看情况”，要答成维度对比。
常用维度¶
- 数据安全
- 延迟要求
- 调整和定制空间
- 流量规模
- 团队能力
- 成本结构
一个成熟回答¶
早期验证阶段，我倾向先调 API，因为产品迭代速度更重要；
但如果涉及强隐私、强低延迟、高 QPS 或领域定制，我会逐步转向自建或托管部署。
本质上这是速度、成本、控制力之间的权衡。
Q2：为什么选 7B，不选 70B¶
不要只说“成本低”，还要说明任务匹配。
更完整的回答结构：
- 任务复杂度
- 延迟要求
- 质量门槛
- 路由策略
一个更好的说法¶
Q3：为什么不是单模型，而是模型池¶
答这类问题时，核心在于你是否知道系统不是论文。
要点：
- 用户请求复杂度不同
- 成本目标不同
- SLA 不同
- 故障和降级需要备选模型
二、数据与评测类¶
如果你想把系统设计讲得像真实项目，数据和评测这组问题通常躲不过去。
Q4：离线效果很好，为什么线上不涨¶
这是高频中的高频。
你可以从下面 5 个方向答：
- 数据分布漂移
- 离线指标和线上目标不一致
- 训练-推理不一致
- 位置偏差 / 选择偏差
- 系统层副作用（延迟、缓存、失败率）
一个成熟表达¶
Q5：如何避免 Training-Serving Skew¶
答题要点：
- 统一特征定义
- 训练和推理共用同一套逻辑
- point-in-time join
- 分布对齐监控
如果你答到 feature store、统一 DSL 或同源计算逻辑，成熟度会更高。
Q6：RAG / Agent 系统如何评测¶
不要只说“人工看效果”。
建议拆层：
- 检索层
- 生成层
- 端到端层
一个合格表达¶
三、稳定性与安全类¶
这部分最容易把“能做 Demo”与“能上线”区分开来，因为它直接对应线上事故成本。
Q7：如果线上错误率突然飙升，你先看什么¶
建议回答顺序固定下来：
- 看入口错误率和流量变化
- 看下游依赖和队列
- 看模型或检索层延迟
- 看最近发布或配置变化
- 决定是否降级或回滚
这比泛泛说“先看日志”更有条理。
Q8：如果检索服务挂了怎么办¶
这是 RAG 题最常见的稳定性追问。
要点：
- 关键词检索 fallback
- 直接返回保守答案
- 只返回文档摘要或搜索结果
- 限流和熔断
Q9：如何处理 prompt injection 或工具越权¶
这类题最重要的是“分层防御”。
你可以答：
- 输入检查
- 工具白名单
- 参数校验
- 输出过滤
- 审计日志
- 高风险动作人工确认
如果能再补“最小权限原则”，会更完整。
Q10：Agent 死循环怎么办¶
标准回答要点：
- 最大轮数
- 重复输出检测
- token / tool budget
- 超时
- manager 重新规划或人工接管
四、成本与容量类¶
大模型系统一旦进生产，成本和容量问题就不是附加项，而是核心约束。
Q11：成本太高怎么办¶
这类问题不要只答“量化”。
更完整的思路：
- 模型路由
- 缓存
- prompt / context 压缩
- 量化
- 低峰缩容
- 只在高价值请求上启用高成本模块
一个成熟表达¶
Q12：QPS 从 100 涨到 10000，架构怎么变¶
答这类题时，不要一次讲成“上大集群”。
更好的结构是分阶段：
- 起步期
- 增长期
- 成熟期
你要体现的是演进能力，而不是一开始就过度设计。
Q13：容量怎么估¶
至少应该讲：
- 平均和峰值 QPS
- 输入/输出 token
- 模型池比例
- 缓存命中率假设
- 冗余和故障预留
哪怕是粗估，只要逻辑自洽就比不估强很多。
五、平台与组织化类¶
越往高阶岗位走，越会被追问这部分，因为团队规模一上来就必须考虑平台化和治理。
Q14：如何设计一个 Agent 平台，而不是单个 Agent¶
这是 2028 越来越高频的题。
这类答案建议分成 4 层：
- 开发层：prompt、流程、工具编排
- 运行时层：agent runtime、状态、工具执行
- 治理层：权限、审计、预算、评测
- 观测层：trace、日志、质量指标
如果你能把它讲成“平台”，而不是“另一个 agent”，会明显更强。
Q15：如何评估一个 AI 系统的 ROI¶
这类问题特别能体现业务感。
建议分成：
- 收益
- 成本
- 回收期
- 风险
一个好用的表达¶
一套万能答题骨架¶
当你被追问时，可以按下面顺序组织：
- 先说明这是一个 trade-off 问题
- 给出 2 到 4 个关键维度
- 说明在当前场景下你会怎么选
- 补一句风险和后续验证方式
例如¶
这本质上是效果、延迟和成本之间的权衡。
在当前场景里，我更优先保证延迟和可用性，所以会先做模型分层和缓存，而不是默认所有请求都走最大模型。
上线时再通过灰度和指标对比确认是否需要调整策略。
这类结构几乎可以覆盖大量深度追问。
最值得提前准备的 10 个追问¶
- 为什么选这个模型
- 为什么不直接调 API
- 离线好线上差怎么办
- 如何做训练和推理一致性
- 如何控制幻觉和越权
- 如果一个核心依赖挂了怎么办
- 成本太高怎么优化
- QPS 翻十倍怎么办
- 如何做平台化而不是单点工具
- 这个系统的 ROI 怎么算
如果你把这 10 个问题提前准备好，系统设计面试的稳定性会明显提升。
本章小结¶
- 深度追问真正考的是 trade-off、生产感和职业判断
- 你要学会把每个追问答成“维度 -> 选择 -> 风险 -> 验证”的结构
- 2028 更高频的追问已经明显偏向
平台化、治理、评测、安全、成本
下一步¶
- 回看 01-AI 系统设计面试指南，把这章答案嵌回主框架
- 再结合 02-RAG 系统设计深入、03-多 Agent 系统设计、04-LLM 推理服务架构设计 做专项准备