AI系统设计高频追问与深度题¶

决策矩阵:

┌──────────────┬──────────┬──────────┬──────────────┐
│ 维度         │ 自建模型  │ 调API     │ 选择依据     │
├──────────────┼──────────┼──────────┼──────────────┤
│ 数据安全     │ ✅ 全控  │ ❌ 出域   │ 金融/医疗→自建│
│ 延迟         │ ✅ 可控  │ ❌ 不可控 │ <100ms→自建  │
│ 成本(低量)   │ ❌ 固定高│ ✅ 按量付 │ <10K QPS→API │
│ 成本(高量)   │ ✅ 边际低│ ❌ 线性增 │ >100K QPS→自建│
│ 迭代速度     │ ❌ 慢    │ ✅ 即用   │ 早期验证→API │
│ 定制化       │ ✅ 全定制│ ❌ 有限   │ 领域模型→自建 │
│ 可用性       │ ❌ 自担  │ ✅ SLA保障│ 看团队能力   │
└──────────────┴──────────┴──────────┴──────────────┘

实际策略(多数公司):
  阶段1(验证期): 全部调API → 快速验证产品价值
  阶段2(增长期): 核心能力自建, 非核心继续API
  阶段3(成熟期): 大部分自建, API做降级备份

关键指标: 任务复杂度 × 延迟要求 × 成本预算

经验法则:
  - 分类/NER/提取 → 7B足够(甚至3B)，微调后接近大模型
  - RAG问答/摘要 → 14B-32B是性价比甜点
  - 复杂推理/数学/代码 → 70B+有明显优势
  - 多模态理解 → VLM通常7B-72B

成本对比(自建, A100 80GB):
  7B INT4:   1张A10G, 0.5元/千次
  70B FP8:   2张A100, 5元/千次
  API GPT-4o: 约10元/千次(输入+输出)

→ 10x成本差距! 必须根据任务需求选择

典型场景:
  训练时: 特征用Spark从Hive计算(T+1, 完整历史)
  推理时: 特征用在线服务从Redis读取(实时, 可能缺失/延迟)

  → 同一个用户的"购买次数"特征，训练时是100，推理时可能是98
  → 微小差异导致模型效果下降

解决方案:
  1. 统一特征计算逻辑(Feature Store): 训练和推理用同一套DSL定义
  2. 离线特征直接灌入在线存储: 训练用啥，推理用啥
  3. 定期一致性检查: 对比训练数据特征分布 vs 在线特征分布
  4. 模型鲁棒性训练: 训练时加入特征噪声/缺失的augmentation

多层质量保障:

  L1 自动化:
    - 一致性检查(同样数据多人标注, Fleiss' Kappa > 0.7)
    - 明显错误自动过滤(规则+小模型)
    - 标注时长异常检测(太快→没认真看)

  L2 抽样复审:
    - 每批次10%随机抽样由高级标注员审核
    - 错误率>5%则整批返工

  L3 模型辅助:
    - 用当前模型预标注 → 人工纠正(比从零标注快3-5x)
    - 模型置信度低的样本优先标注(主动学习)
    - 反差样本重点审核(模型预测与标注不一致)

A/B测试三要素:

1. 分流:
   - 用户级分流(hash(user_id) % 100): 保证同一用户持续在同一组
   - 不能用请求级分流(同一用户在A/B之间跳来跳去→无法归因)
   - 分层实验: 多个实验同时进行时，流量按层正交划分

2. 指标:
   - 核心指标(North Star): 日活/留存/GMV等业务指标
   - 护栏指标: 不能恶化的指标(如用户投诉率、延迟)
   - 调试指标: 辅助分析(如CTR、完播率、分享率)

3. 显著性:
   - 样本量: 最少7天(覆盖周期性), VIP用户过滤
   - 统计检验: t检验/Mann-Whitney, p < 0.05
   - 提防: 辛普森悖论(分组看效果好, 合并看效果差)
   - Peeking问题: 不要反复查看中间结果做决定

常见原因:

1. 离线数据分布偏移:
   - 训练数据是历史数据, 线上用户行为已变化
   - 解决: 使用最近的数据做离线评估, 定期重训

2. 特征穿越(Data Leakage):
   - 离线评估时不小心用了"未来信息"
   - 例: 用用户的全部历史行为预测过去某个时刻的行为
   - 解决: Point-in-time Join, 严格时间切割

3. 位置偏差(Position Bias):
   - 离线数据中排第一的内容点击率天然高(用户倾向点第一个)
   - 新模型排序不同, 但离线评估用的是老排序下的点击数据
   - 解决: 反事实评估(IPS/DR), 或先在线小流量验证

4. 系统因素:
   - 延迟增加导致用户流失(模型大了→慢了→用户体验差)
   - 缓存命中率变化
   - 解决: 系统指标和业务指标一起看

优化策略(按效果排序):

1. 模型蒸馏(节省80%+):
   大模型(70B) → 蒸馏 → 小模型(7B)
   特定任务上, 7B微调后可达70B 90%+效果

2. 量化(节省50-75%):
   FP16 → INT8(2x) → INT4(4x)
   GPTQ/AWQ对LLM友好, 质量损失可控

3. 模型路由(节省50-70%):
   简单请求 → 小模型(7B, 每千次0.5元)
   复杂请求 → 大模型(70B, 每千次5元)
   路由分类器: 基于查询复杂度/用户等级/任务类型

4. Caching(节省20-50%):
   语义缓存: 相似Query的回答复用
   Prefix Caching: System Prompt的KV Cache复用
   结果缓存: 幂等请求直接返回缓存结果

5. 弹性伸缩(节省20-30%):
   白天峰值: 扩容到N个GPU
   夜间低谷: 缩容到N/3
   + Spot实例(折扣50-70%, 可能被中断)

QPS 100(起步期):
  - 2张A100, 单vLLM实例
  - 前面一个Nginx负载均衡
  - Redis做缓存
  - 够用, 简单

QPS 1000(增长期):
  - 20张A100, 多vLLM实例
  - K8s管理, HPA自动扩缩
  - 请求队列(Redis Stream)做削峰
  - 分模型池(7B/70B)
  - 加监控(Prometheus+Grafana)

QPS 10000(成熟期):
  - 200张A100 → 需要多区域部署
  - 全局负载均衡(DNS/Anycast)
  - 完善的模型路由(减少大模型调用)
  - 多级缓存(CDN→Redis→本地)
  - 语义缓存命中率优化(目标>30%)
  - 完善的降级策略(GPU不足时降级到小模型)
  - SLA分级(VIP通道保障)

需求: 企业内部不同部门需要构建各种Agent, 需要统一的平台支撑

平台架构:
┌─────────── 开发层 ─────────────────────────┐
│ Agent Studio(低代码/代码):                   │
│   - 可视化流程编排(拖拽式)                   │
│   - Prompt模板管理                           │
│   - 工具市场(MCP协议标准化)                  │
│   - 知识库接入(RAG配置)                      │
│   - 版本管理(Git-like)                       │
└──────────────┬────────────────────────────┘
               ↓
┌─────────── 运行时层 ───────────────────────┐
│ Agent Runtime:                               │
│   - 工作流引擎(Temporal/Airflow)             │
│   - LLM调用层(多模型路由+负载均衡)           │
│   - 工具执行沙箱(Docker/gVisor)              │
│   - 记忆管理(短期Redis + 长期向量库)          │
│   - Human-in-the-loop(需人工确认的步骤)      │
└──────────────┬────────────────────────────┘
               ↓
┌─────────── 治理层 ─────────────────────────┐
│   - 安全护栏(输入/输出过滤)                   │
│   - 成本管控(Token预算/部门配额)             │
│   - 审计日志(所有Agent行为可追溯)             │
│   - 质量评估(自动化测试+人工抽检)             │
│   - 权限管理(谁能用哪些工具/数据)             │
└──────────────────────────────────────────┘

AI系统ROI框架:

收益:
  - 直接收益: 自动化替代人工(节省工时 × 时薪)
  - 效率收益: 响应速度提升 → 用户体验 → 留存/转化
  - 增量收益: AI推荐/搜索优化 → GMV/广告收入提升
  - 质量收益: 错误率降低 → 售后成本降低

成本:
  - GPU/算力(通常占50-70%)
  - 数据标注
  - 工程团队人力
  - 第三方API/工具
  - 运维成本

ROI = (年化收益 - 年化成本) / 年化成本 × 100%

实际估算示例(客服AI):
  替代50个客服 × 年薪15万 = 750万/年
  系统成本: GPU 200万 + 人力(3工程师)150万 + 其他50万 = 400万/年
  ROI = (750-400)/400 = 87.5%
  回收期 < 1年 ✓

维度1: 你能不能"算清楚"？
  → 容量估算(QPS/存储/GPU)做得对不对

维度2: 你能不能"画出来"？
  → 端到端架构图，数据流清晰

维度3: 你能不能"权衡取舍"？
  → 为什么选A不选B，成本/性能/复杂度的tradeoff

维度4: 你能不能"想到边界case"？
  → 冷启动/故障恢复/数据偏差/安全问题

维度5: 你有没有"落地过"？
  → 真实项目中遇到的问题和解决方案
  → 这是2028年面试中，区分度最大的因素