AI Day 48
AI Day 48: 架构面试模拟(2)：AI系统架构题
AI Day 48: 架构面试模拟(2)：AI系统架构题
2026-05-19
架构面试AI反欺诈模型管理多模型路由白板画图Trade-off遗留系统
日期: 2026-05-19 阶段: Phase 4 — 面试冲刺 (System Design + Product + Architecture) 主题: Architecture Interview Simulation — AI System Architecture Questions 进度: Day 1-47 ✅ | Day 48 ← current 标签: #架构面试 #AI反欺诈 #模型管理 #多模型路由 #白板画图 #Trade-off #遗留系统
学习路径 (50-Day Full Tree)
AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15) ✅
│ ├── Day 1-7: Transformer/量化/训练/Prompt/RAG/向量DB/FineTune ✅
│ ├── Day 8-11: 推理优化/长上下文/多模态/Reasoning ✅
│ └── Day 12-15: Agent/MCP/评估/阶段总结 ✅
│
├── 第二阶段：工程实践 (Day 16-30) ✅
│ ├── Day 16-18: 应用架构/安全/可观测性 ✅
│ ├── Day 19-21: 生产级RAG三部曲 ✅
│ ├── Day 22-25: Agent工程化四部曲 ✅
│ └── Day 26-30: 成本/编排/测试/案例/总结 ✅
│
├── 第三阶段：金融零售AI应用 (Day 31-42) ✅
│ ├── Day 31: 金融AI(1)：智能风控与反欺诈 ✅
│ ├── Day 32: 金融AI(2)：智能投顾与量化策略 ✅
│ ├── Day 33: 金融AI(3)：合规科技与监管AI ✅
│ ├── Day 34: 金融AI(4)：信贷全链路AI ✅
│ ├── Day 35: 金融AI总结 — PM视角的AI重塑金融 ✅
│ ├── Day 36: 零售AI(1)：推荐系统与个性化 ✅
│ ├── Day 37: 零售AI(2)：智能客服与对话系统 ✅
│ ├── Day 38: 零售AI(3)：供应链预测与优化 ✅
│ ├── Day 39: 零售AI(4)：智能营销与用户增长 ✅
│ ├── Day 40: 零售AI总结 — PM视角零售智能化全景 ✅
│ ├── Day 41: CeFi × DeFi × AI 融合架构(上) ✅
│ └── Day 42: CeFi × DeFi × AI 融合(下) + 职业定位 ✅
│
└── 第四阶段：面试冲刺 (Day 43-50)
├── Day 43: 系统设计面试(1)：企业LLM平台 ✅
├── Day 44: 系统设计面试(2)：生产级RAG系统 ✅
├── Day 45: 系统设计面试(3)：AI Agent系统 ✅
├── Day 46: 系统设计面试(4)：推荐系统 ✅
├── Day 47: 产品面试模拟(1)：AI产品设计题 ✅
├── Day 48: 架构面试模拟(2)：AI系统架构题 ← 你在这里
├── Day 49: 行为面试 + AI领域特色问题
└── Day 50: 50天总结 — 知识地图与下一步
一、AI架构面试的特点
1.1 架构面试 vs 系统设计面试 vs 产品面试
三种面试的关系:
┌──────────────────────────────────────────────────────┐
│ │
│ 产品面试 架构面试 系统设计面试 │
│ ┌──────┐ ┌──────────┐ ┌──────────┐ │
│ │ Why │ ───► │ How+Why │ ◄── │ How │ │
│ │ What │ │ Trade-off│ │ Detail │ │
│ └──────┘ └──────────┘ └──────────┘ │
│ │
│ "做什么产品" "架构怎么选, "具体怎么实现" │
│ "为什么做" 为什么这样选" "如何保证可靠" │
│ │
└──────────────────────────────────────────────────────┘
架构面试的核心特质:
1. 不考"背方案" → 考"做决策"
2. 没有标准答案 → 关键是Trade-off推理过程
3. 约束条件是核心 → 同一个问题,约束不同,架构完全不同
4. 沟通比技术更重要 → 能画清楚 + 讲清楚 = 高分
1.2 AI架构面试的独特挑战
传统架构面试: "设计一个秒杀系统"
→ 确定性系统: 输入→输出是确定的
→ 核心挑战: 高并发/一致性/可用性
AI架构面试: "为支付系统添加AI反欺诈"
→ 概率性系统: 模型输出有不确定性
→ 核心挑战: 准确率vs延迟/模型演进/AB测试/降级
AI架构的特殊考量:
├── 模型不确定性: 同一输入可能不同输出
├── 模型演进: 模型需要持续更新,架构要支持热切换
├── 特征工程: 实时特征vs离线特征的延迟差异
├── 评估体系: 离线评估≠线上效果
├── 成本结构: GPU推理/API调用/存储的成本模型
└── 降级策略: 模型故障时如何兜底
1.3 面试官评分维度
维度1: 问题拆解 (20%)
├── 能否识别真正的技术挑战
├── 是否考虑了约束条件
└── 需求澄清的质量
维度2: 架构决策 (35%)
├── 方案选择的合理性
├── Trade-off的清晰度
├── 对替代方案的了解
└── 演进路径的思考
维度3: 技术深度 (25%)
├── 关键组件的设计细节
├── 故障场景的处理
├── 性能/成本/安全的考量
└── 对AI特有问题的理解
维度4: 沟通表达 (20%)
├── 图是否清晰易懂
├── 是否主动引导讨论
├── 是否能简洁解释复杂概念
└── 对追问的应对质量
二、题目1：为支付系统添加AI反欺诈
2.1 题目
"Your company has a 10-year-old payment system processing 5M transactions/day. Management wants to add AI-based fraud detection. The current system uses rule-based fraud checks. How would you architect the AI integration?"
2.2 需求澄清
关键澄清问题:
Q1: "现有系统的技术栈是什么?"
→ 假设: Java单体/Oracle DB/MQ消息队列
→ 关键: 这是遗留系统, 不能推倒重来
Q2: "当前规则引擎的效果如何?"
→ 假设: 检出率60%, 误报率5%
→ 目标: 检出率提升到85%+, 误报率降到2%以下
Q3: "延迟要求?"
→ 假设: 支付授权必须在200ms内完成(含反欺诈)
→ 关键约束: AI模型推理延迟必须 < 50ms
Q4: "可以拒绝交易还是只标记?"
→ 假设: 高风险直接拒绝, 中风险标记人工审核
→ 关键: 误拒正常交易 = 收入损失 + 客户流失
Q5: "团队情况?"
→ 假设: 有5人数据科学团队, 但没有MLOps经验
→ 挑战: 需要渐进式建设能力
2.3 架构设计：渐进式AI集成
核心原则: 不替换现有系统, 而是在旁路增强
阶段一架构 — Shadow Mode (旁路观察, 1-3月)
┌─────────────────────────────────────────────┐
│ Payment Gateway │
│ │ │
│ ┌───────────┼───────────┐ │
│ ▼ ▼ │
│ ┌──────────┐ ┌──────────────┐ │
│ │ Rule │ │ AI Fraud │ │
│ │ Engine │ │ Service │ │
│ │ (现有) │ │ (新建,旁路) │ │
│ │ │ │ │ │
│ │ 决策权: │ │ 决策权: │ │
│ │ 有 │ │ 无(只记录) │ │
│ └────┬─────┘ └──────┬───────┘ │
│ │ │ │
│ │ 实际决策 │ 记录预测 │
│ ▼ ▼ │
│ ┌──────────┐ ┌──────────────┐ │
│ │ 支付执行 │ │ 分析数据库 │ │
│ └──────────┘ └──────────────┘ │
└─────────────────────────────────────────────┘
Shadow Mode的价值:
├── AI模型对所有交易做预测, 但不影响实际决策
├── 对比AI预测 vs 规则引擎决策 vs 实际欺诈
├── 积累真实数据, 评估AI模型的真实效果
└── 零风险验证, 团队积累MLOps经验
2.4 阶段二：Champion-Challenger 并行决策
阶段二架构 — Parallel Decision (3-6月)
┌──────────────────────────────────────────────────┐
│ Payment Gateway │
│ │ │
│ ┌───────▼───────┐ │
│ │ Feature Store │ ← 实时特征计算 │
│ └───────┬───────┘ │
│ │ │
│ ┌───────────┼───────────┐ │
│ ▼ ▼ │
│ ┌──────────┐ ┌──────────────┐ │
│ │ Rule │ │ AI Model │ │
│ │ Engine │ │ Service │ │
│ │ Champion │ │ Challenger │ │
│ └────┬─────┘ └──────┬───────┘ │
│ │ │ │
│ └───────────┬───────────┘ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Decision │ │
│ │ Orchestrator │ │
│ │ │ │
│ │ 规则: │ │
│ │ IF 两者都Pass → Pass │
│ │ IF 两者都Reject → Reject │
│ │ IF 不一致 → 用Champion(规则) │
│ │ 但记录差异供分析 │
│ └────────┬────────┘ │
│ ▼ │
│ 支付执行 / 拒绝 │
└──────────────────────────────────────────────────┘
这个阶段的目标:
├── AI开始参与决策(但规则引擎仍是最终仲裁者)
├── 量化AI的增量价值(AI多发现了多少欺诈?)
├── 验证AI的误报率(AI误拒了多少正常交易?)
└── 为阶段三积累信心
2.5 阶段三：AI主导 + 规则兜底
阶段三架构 — AI Primary (6-12月)
交易请求
│
┌────▼────────────────────────────────────┐
│ Feature Engineering │
│ ┌────────────┐ ┌────────────────────┐ │
│ │ 实时特征 │ │ 离线特征 │ │
│ │ (Redis) │ │ (Feature Store) │ │
│ │ │ │ │ │
│ │ ·交易金额 │ │ ·用户历史行为画像 │ │
│ │ ·时间 │ │ ·设备指纹 │ │
│ │ ·IP地理 │ │ ·社交网络特征 │ │
│ │ ·设备ID │ │ ·欺诈标签历史 │ │
│ └─────┬──────┘ └────────┬───────────┘ │
└────────┼──────────────────┼──────────────┘
└────────┬─────────┘
▼
┌──────────────────────────────────────────┐
│ AI Scoring Layer │
│ │
│ Model A Model B Model C │
│ (XGBoost) (Neural) (LLM) │
│ 实时<10ms 实时<30ms 异步分析 │
│ │
│ → Ensemble: 加权融合得出风险分数 │
│ → 分数: 0-1000 │
└──────────────┬───────────────────────────┘
│
┌──────────────▼───────────────────────────┐
│ Decision Layer │
│ │
│ Score 0-200: PASS (自动通过) │
│ Score 200-500: 规则引擎二次验证 │
│ Score 500-800: 人工审核队列 │
│ Score 800+: REJECT (自动拒绝) │
│ │
│ 特殊规则(硬性): │
│ ├── 黑名单 → 无条件拒绝 │
│ ├── 白名单 → 无条件通过 │
│ └── 合规规则 → 无条件执行 │
└──────────────────────────────────────────┘
关键Trade-off:
准确率 vs 误报率:
检出率从60%→85% (↑25%), 但误报率必须<2%
每1%误报 = ~50,000笔正常交易被拒 = 巨大收入损失
→ 宁可放过一些欺诈, 也不能误杀太多正常交易
延迟 vs 模型复杂度:
XGBoost: 5ms推理, 准确率80%
Deep Learning: 25ms推理, 准确率85%
LLM分析: 2s推理, 准确率90%(但太慢)
→ 方案: 简单模型做实时决策, 复杂模型做异步复核
新模型 vs 稳定性:
频繁更新模型 → 效果更好, 但风险更高
→ 方案: Canary发布(5%流量) → 验证1周 → 全量切换
2.6 遗留系统集成的核心挑战
挑战1: 数据访问
问题: Oracle数据库性能有限, 不能让AI服务直连
方案: CDC(Change Data Capture) → Kafka → Feature Store
关键: 特征延迟 < 1min, 不影响主库性能
挑战2: 延迟预算
问题: 总授权时间200ms, 分配给AI的只有50ms
方案:
├── 预计算: 用户画像特征离线预计算, 实时只查缓存
├── 模型优化: ONNX Runtime + 模型量化 + 批推理
└── 超时兜底: AI超时 → 直接用规则引擎结果
挑战3: 团队能力
问题: 数据科学团队没有MLOps经验
方案:
Phase 1: 用MLflow做基础模型管理
Phase 2: 引入Kubernetes做模型服务部署
Phase 3: 建立完整的特征/训练/部署流水线
挑战4: 合规要求
问题: 金融监管要求模型可解释, 且有审计追踪
方案:
├── SHAP值: 每笔决策记录Top 5影响因子
├── 审计日志: 每笔交易的完整决策链路
└── 模型卡片: 每个模型版本的性能/偏差/限制文档
三、题目2：设计AI模型管理平台
3.1 题目
"Your company has 15 ML teams running 50+ models in production. Each team manages models independently, leading to inconsistency, deployment failures, and no centralized monitoring. Design an AI Model Management Platform."
3.2 问题分析
当前痛点:
团队A (风控): Python + sklearn → Docker → 手动部署到EC2
团队B (推荐): PyTorch → 自建serving → K8s
团队C (NLP): HuggingFace → 调API → Lambda
...
问题:
├── 版本混乱: 不知道线上跑的是哪个版本的模型
├── 部署不一致: 每个团队自己的部署方式, 故障频发
├── 无统一监控: 模型漂移/性能下降发现不及时
├── AB测试困难: 没有统一的实验平台
├── 回滚缓慢: 出问题时不知道回滚到哪个版本
└── 合规风险: 无法回答"这个预测是哪个模型做的"
3.3 平台架构
AI Model Management Platform — 四层架构
┌─────────────────────────────────────────────────────────┐
│ Portal Layer │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌───────────┐ │
│ │ Model │ │ Experiment│ │ Deploy │ │ Monitor │ │
│ │ Registry │ │ Tracker │ │ Console │ │ Dashboard │ │
│ └──────────┘ └──────────┘ └──────────┘ └───────────┘ │
├─────────────────────────────────────────────────────────┤
│ Orchestration Layer │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌───────────┐ │
│ │ Version │ │ AB Test │ │ Canary │ │ Rollback │ │
│ │ Control │ │ Engine │ │ Deploy │ │ Manager │ │
│ └──────────┘ └──────────┘ └──────────┘ └───────────┘ │
├─────────────────────────────────────────────────────────┤
│ Serving Layer │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌───────────┐ │
│ │ Model │ │ Feature │ │ Inference│ │ Cache │ │
│ │ Server │ │ Store │ │ Router │ │ Layer │ │
│ └──────────┘ └──────────┘ └──────────┘ └───────────┘ │
├─────────────────────────────────────────────────────────┤
│ Infrastructure Layer │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌───────────┐ │
│ │ GPU │ │ Storage │ │ Logging │ │ Security │ │
│ │ Cluster │ │ (S3/GCS) │ │ (ELK) │ │ (RBAC) │ │
│ └──────────┘ └──────────┘ └──────────┘ └───────────┘ │
└─────────────────────────────────────────────────────────┘
3.4 核心组件设计
组件1: Model Registry (模型注册中心)
功能:
├── 模型版本管理: Git-like版本控制(模型文件+元数据)
├── 模型卡片: 自动生成训练数据/性能/偏差文档
├── 依赖管理: 记录模型依赖的库版本/特征/数据集
├── 审批流程: 模型上线需要通过审批(Owner+Reviewer)
└── 搜索发现: 按名称/团队/任务类型搜索已有模型
数据模型:
Model:
id, name, team, task_type, framework
created_at, owner, status
ModelVersion:
model_id, version, artifact_path
metrics (accuracy, latency, cost)
training_data_ref, feature_set_ref
approval_status, approver, approved_at
ModelDeployment:
model_version_id, environment
traffic_percentage, status
deployed_at, deployed_by
---
组件2: AB Test Engine (实验引擎)
流量分配策略:
┌─────────────────────────────────────────┐
│ Traffic Router │
│ │
│ Request → Hash(user_id) → Bucket │
│ │
│ Bucket 0-79: Model V2 (Champion) │
│ Bucket 80-89: Model V3 (Challenger) │
│ Bucket 90-99: Model V4 (Experiment) │
│ │
│ 规则: │
│ ├── 同一用户始终分到同一Bucket │
│ ├── 流量比例可动态调整 │
│ ├── 紧急情况可立即回滚到Champion │
│ └── 实验结果自动统计显著性 │
└─────────────────────────────────────────┘
显著性检测:
├── 自动计算p-value
├── 达到统计显著性后自动通知
├── 可配置置信度阈值(默认95%)
└── 支持多指标同时评估
---
组件3: Monitor Dashboard (监控面板)
监控维度:
实时指标:
├── QPS/延迟(P50/P95/P99)
├── 错误率/超时率
├── GPU利用率/内存
└── 每分钟推理成本
模型质量指标 (每小时更新):
├── 预测分布变化 (PSI/KL散度)
├── 特征漂移检测
├── 准确率/F1 (如有标注数据)
└── 业务指标 (CTR/CVR/欺诈检出率)
告警规则:
P0: 延迟P99 > 200ms 或 错误率 > 1% → 自动降级
P1: 预测分布偏移 PSI > 0.2 → 通知Owner
P2: 模型准确率下降 > 5% → 触发再训练
---
组件4: Rollback Manager (回滚管理)
回滚触发:
自动触发:
├── P0告警 → 自动回滚到上一版本
├── AB实验中Challenger指标显著差于Champion → 停止实验
└── 新版本部署后5分钟内错误率飙升 → 自动回滚
手动触发:
├── 一键回滚: 选择目标版本 → 确认 → 执行
├── 回滚确认: 回滚后自动验证健康检查
└── 回滚通知: 通知所有相关团队
回滚时间目标: < 2分钟 (从触发到完成)
3.5 多团队协作设计
团队协作模型:
RBAC权限:
├── Platform Admin: 全局配置/审批/安全
├── Team Lead: 本团队模型的部署/回滚审批
├── Data Scientist: 模型训练/注册/实验
├── ML Engineer: 部署/监控/故障处理
└── Viewer: 只读Dashboard
工作流:
1. 数据科学家训练模型 → 注册到Registry
2. 自动触发CI: 单元测试 + 性能基准测试
3. 创建AB实验 → Team Lead审批
4. Canary部署(5%流量) → 观察1天
5. 扩大到50% → 统计显著性检测
6. 全量切换 → 旧版本保留7天(可回滚)
团队隔离 vs 共享:
隔离的: 模型文件/实验数据/部署配置
共享的: Feature Store/基础设施/监控平台/最佳实践
四、题目3：从单模型到多模型的架构演进
4.1 题目
"Your product currently calls GPT-4 for everything. Now you need to support multiple models (GPT-4, Claude, Gemini, open-source) for different use cases. How would you evolve the architecture?"
4.2 演进路径
阶段1: 单模型 (现状)
App → OpenAI SDK → GPT-4
问题: 单点依赖/成本高/无法优化
阶段2: 抽象层 (第一步)
App → LLM Gateway → GPT-4
→ Claude (备选)
价值: 故障切换/统一接口/成本监控
阶段3: 智能路由 (目标)
App → LLM Gateway → Router → 最优模型
价值: 成本优化/质量提升/灵活性
每个阶段的详细架构:
4.3 阶段2：LLM Gateway 设计
LLM Gateway Architecture:
┌────────────────────────────────────────────┐
│ Application │
│ │ │
│ unified_llm.complete( │
│ prompt="...", │
│ task_type="summarize" │
│ ) │
└───────────────────┬────────────────────────┘
│
┌───────────────────▼────────────────────────┐
│ LLM Gateway │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ Rate Limiter │ │
│ │ (per-user / per-team / global) │ │
│ └──────────────┬───────────────────────┘ │
│ │ │
│ ┌──────────────▼───────────────────────┐ │
│ │ Cost Tracker │ │
│ │ (token counting / budget alerts) │ │
│ └──────────────┬───────────────────────┘ │
│ │ │
│ ┌──────────────▼───────────────────────┐ │
│ │ Retry + Fallback │ │
│ │ GPT-4 fail → Claude → Gemini │ │
│ │ Timeout: 30s → retry → fallback │ │
│ └──────────────┬───────────────────────┘ │
│ │ │
│ ┌──────────────▼───────────────────────┐ │
│ │ Provider Adapters │ │
│ │ ┌─────┐ ┌──────┐ ┌──────┐ ┌─────┐ │ │
│ │ │GPT-4│ │Claude│ │Gemini│ │Llama│ │ │
│ │ └─────┘ └──────┘ └──────┘ └─────┘ │ │
│ └──────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ Logging + Observability │ │
│ │ (latency / tokens / cost / quality) │ │
│ └──────────────────────────────────────┘ │
└────────────────────────────────────────────┘
Gateway的核心接口:
interface LLMGateway {
complete(request: {
prompt: string,
task_type: string, // 用于路由
model_preference?: string, // 可选指定模型
max_tokens: number,
temperature: number,
timeout_ms: number,
fallback_models?: string[],
}): CompletionResponse
stream(request): AsyncStream<Token>
}
Fallback策略:
Primary Model: GPT-4
├── 如果成功 → 返回结果
├── 如果超时(30s) → 重试1次
├── 如果重试失败 → Fallback to Claude
├── 如果Claude也失败 → Fallback to Gemini
└── 如果全部失败 → 返回错误 + 缓存最近成功的结果
4.4 阶段3：智能路由
Smart Router Design:
路由维度:
├── 任务类型: 摘要→Claude, 代码→GPT-4, 多模态→Gemini
├── 质量要求: 高→大模型, 低→小模型/开源
├── 延迟要求: 实时→小模型, 异步→大模型
├── 成本预算: 有预算→大模型, 省钱→开源
└── 隐私要求: 敏感数据→自部署模型, 非敏感→API
路由规则示例:
┌─────────────────┬──────────┬────────────┬──────────┐
│ Task Type │ Primary │ Fallback │ Cost/1K │
├─────────────────┼──────────┼────────────┼──────────┤
│ 简单问答 │ GPT-4o-m │ Claude Hai │ $0.15 │
│ 长文摘要 │ Claude │ GPT-4o │ $0.80 │
│ 代码生成 │ Claude │ GPT-4o │ $1.20 │
│ 数据分析 │ GPT-4o │ Gemini │ $1.50 │
│ 多模态理解 │ Gemini │ GPT-4o │ $0.70 │
│ 敏感数据处理 │ Llama-3 │ Mistral │ $0.05 │
│ 批量处理(离线) │ Llama-3 │ Mixtral │ $0.03 │
└─────────────────┴──────────┴────────────┴──────────┘
成本优化效果:
全部用GPT-4: $2.00/1K tokens (平均)
智能路由后: $0.60/1K tokens (平均)
节省: 70% 成本下降
4.5 一致性挑战
多模型一致性问题:
问题: 不同模型对同一输入可能给出不同答案
→ 用户昨天问得到答案A(GPT-4), 今天问得到答案B(Claude)
→ 特别是在有Factual Answer的场景(FAQ/知识库)
解决方案:
方案1: Prompt标准化
├── 统一System Prompt模板
├── 统一Output Format (JSON Schema)
└── 模型切换时保持Prompt不变
方案2: 答案校验层
├── 对关键信息做事实性检查(与知识库对比)
├── 对格式做校验(正则/Schema)
└── 不合格的重新生成
方案3: 缓存热门问答
├── 高频问题的答案缓存(无论哪个模型生成的)
├── 缓存命中率高的场景一致性最好
└── TTL根据内容时效性设置
方案4: 业务分区
├── 同一用户的同一Session用同一模型
├── 关键业务(金融/医疗)固定用最可靠模型
└── 只在非关键场景做模型切换
五、白板画图技巧
5.1 C4 for AI Systems
C4模型在AI系统中的应用:
Level 1 — Context (系统上下文):
画什么: 系统与外部交互方 (用户/第三方API/数据源)
AI特殊: 标注AI模型提供商 (OpenAI/Anthropic/自部署)
时间: 2分钟
Level 2 — Container (容器):
画什么: 主要服务/数据库/消息队列
AI特殊: 区分AI服务(推理/训练/特征计算) vs 业务服务
时间: 5分钟
Level 3 — Component (组件):
画什么: 服务内部的关键模块
AI特殊: 模型版本管理/AB测试/监控/降级
时间: 看面试官要求, 通常选1-2个深入
画图顺序:
1. 先画Level 1 (30秒) → 确认与面试官对齐
2. 画Level 2 → 这是面试核心(5分钟)
3. 面试官追问时深入Level 3
5.2 画图的 Do's and Don'ts
Do's (这样做):
✓ 先画骨架再填细节
✓ 用不同颜色区分: AI组件(蓝色) / 业务组件(绿色) / 数据(黄色)
✓ 标注数据流向(箭头+标签)
✓ 标注关键指标(延迟/QPS/成本)
✓ 标注Trade-off(在方案旁写简短备注)
✓ 留空间(面试官可能让你添加组件)
Don'ts (不要这样做):
✗ 不要画完再讲 → 边画边讲
✗ 不要画得太细 → 粒度适中
✗ 不要只画技术 → 标注业务含义
✗ 不要忘记数据流 → 数据怎么从A到B是关键
✗ 不要把图画满 → 留30%空间给追问
5.3 分层清晰的模板
AI系统通用分层模板:
┌──────────────────────────────────┐
│ Access Layer │ ← 用户/API/Webhook
├──────────────────────────────────┤
│ Business Logic │ ← 业务规则/编排/路由
├──────────────────────────────────┤
│ AI/ML Layer │ ← 模型推理/特征计算
├──────────────────────────────────┤
│ Data Layer │ ← 存储/缓存/消息队列
├──────────────────────────────────┤
│ Infrastructure │ ← GPU/K8s/监控/日志
└──────────────────────────────────┘
每一层回答一个问题:
Access: 谁在调用?
Business: 业务逻辑是什么?
AI/ML: AI在哪个环节, 做什么决策?
Data: 数据怎么存, 怎么流转?
Infrastructure: 怎么部署, 怎么监控?
六、沟通策略
6.1 架构面试沟通的黄金原则
原则1: 先说结论, 再说推导
✗ "我们可以用方案A, 也可以用方案B, A的优点是... B的优点是..."
✓ "我推荐方案A(混合架构). 原因有三: 1... 2... 3...
方案B(纯API)我没选, 因为..."
原则2: 主动提Trade-off
不要等面试官问 "有什么缺点"
✓ "这个方案的主要trade-off是: 牺牲了X换取了Y.
如果约束条件变了(比如预算翻倍), 我会考虑方案B."
原则3: 承认不确定性
✗ "这个方案肯定没问题"
✓ "这个设计基于我对现有负载的假设. 如果流量增长10倍,
这个组件可能成为瓶颈, 到时候需要重新考虑."
原则4: 用数字说话
✗ "这样性能会更好"
✓ "XGBoost推理延迟约5ms, 满足50ms的延迟预算.
Deep Learning模型25ms, 也在预算内, 但留给特征计算的时间就少了."
原则5: 引导面试官
✓ "我现在画了高层架构, 您希望我深入哪个部分?
模型管理? 特征工程? 还是监控告警?"
→ 让面试官选他感兴趣的, 而不是你乱猜
6.2 常见追问的应对
追问1: "如果模型准确率突然下降怎么办?"
回答框架:
检测: PSI/KL散度监控 → 预测分布变化告警
根因: 数据漂移? 特征异常? 模型bug?
应对: 自动回滚到上一版本 → 人工分析根因 → 修复后重新部署
预防: 定期再训练 + Shadow Mode验证 + Canary发布
追问2: "如果GPU不够用怎么办?"
回答框架:
短期: 模型量化(INT8) / 请求排队 / 非关键模型降级
中期: 自动扩缩容 / Spot Instance / 模型蒸馏
长期: 混合云(自有GPU+云GPU) / 模型架构优化
追问3: "如果OpenAI API挂了怎么办?"
回答框架:
L1: Retry(3次, exponential backoff)
L2: Fallback到备用Provider(Claude/Gemini)
L3: 降级到缓存结果 / 规则兜底
L4: 全部失败 → 友好错误提示 + 人工接管
预防: 多Provider SLA监控 + 自部署开源模型作为最后防线
七、今日总结
Day 48 核心收获:
1. AI架构面试的核心: 不是背方案, 是展示决策能力
2. 三道架构题完整解答:
├── 支付系统+AI反欺诈: Shadow→Champion-Challenger→AI主导
│ 关键: 渐进式集成, 不动遗留系统核心
├── 模型管理平台: 四层架构(Portal/Orchestration/Serving/Infra)
│ 关键: 版本控制+AB测试+监控+自动回滚
└── 单模型→多模型: Gateway→Smart Router→一致性保障
关键: 成本降70%的路由策略
3. 白板画图: C4分层 + 先骨架后细节 + 边画边讲
4. 沟通策略: 先结论→主动Trade-off→承认不确定→数字说话→引导面试官
核心心法:
"架构面试不是看你知道多少技术方案,
而是看你在约束条件下能否做出合理的决策, 并讲清楚为什么."
明日预告: Day 49 — 行为面试 + AI领域特色问题 STAR格式回答 + AI领域独特的行为面试题 + 薪资谈判 + 远程面试技巧