AI Day 43
AI Day 43: 系统设计面试(1)：设计一个企业LLM平台
AI Day 43: 系统设计面试(1)：设计一个企业LLM平台
2026-05-14
系统设计LLM平台RESHADED多租户模型路由RAG成本控制面试冲刺
日期: 2026-05-14 阶段: Phase 4 — 面试冲刺 (System Design + Product + Architecture) 主题: System Design Interview — Design an Enterprise LLM Platform 进度: Day 1-42 ✅ | Day 43 ← current 标签: #系统设计 #LLM平台 #RESHADED #多租户 #模型路由 #RAG #成本控制 #面试冲刺
学习路径 (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-49: 产品/架构面试模拟
└── Day 50: 总结与作品集
一、面试框架: RESHADED
45分钟系统设计面试的黄金框架，适用于所有AI系统设计题
RESHADED Framework (每步时间预算):
R — Requirements (需求澄清) 5 min
E — Estimation (规模估算) 3 min
S — Storage (存储设计) 3 min
H — High-level Design (高层架构) 8 min
A — API Design (接口设计) 5 min
D — Detailed Design (深入设计) 12 min
E — Evaluation (评估与权衡) 5 min
D — Deployment (部署与运维) 4 min
总计: 45 min
关键原则:
1. 不要急着画架构 → 先把R和E搞清楚
2. 面试官关心的是你的思维过程 → 边画边讲Why
3. 没有完美方案 → 讲清楚Trade-off比答案本身更重要
4. AI系统特殊性 → 必须涉及模型选择/成本/评估/安全
RESHADED vs 传统系统设计
传统系统设计 (设计Twitter/Uber):
关注点: 高并发 / 数据一致性 / 可用性 / 分布式存储
核心难点: Scale(规模) + Consistency(一致性)
AI系统设计 (设计LLM平台/RAG/Agent):
关注点: 模型选择 / 推理延迟 / 成本控制 / 输出质量 / 安全
核心难点: Quality(质量) + Cost(成本) + Latency(延迟)
AI系统设计额外关注:
├── Model Selection: 不同场景用不同模型
├── Cost Engineering: Token计费, 缓存策略
├── Quality Assurance: 幻觉检测, 评估循环
├── Safety & Guardrails: 内容过滤, PII保护
└── Observability: Token用量, 延迟分布, 质量指标
二、面试题: 设计一个企业LLM平台
"Design an Enterprise LLM Platform that serves multiple teams across the organization. It should support different use cases like chatbot, code generation, document Q&A, etc."
Step 1: Requirements 需求澄清 (5 min)
功能性需求 (Functional Requirements):
├── 多租户: 支持不同团队/部门使用
├── 多模型: GPT-4o / Claude / Llama / Gemini 等
├── 多用例: Chat / Code Gen / Doc QA / Summarization / Translation
├── 对话管理: 多轮对话, 上下文管理
├── 知识库: 各团队可上传私有文档(RAG)
├── 提示词管理: Prompt版本控制, A/B测试
└── 用量追踪: 按团队/项目统计用量和成本
非功能性需求 (Non-Functional Requirements):
├── 延迟: 首token < 500ms, 流式输出
├── 可用性: 99.9% (单个模型不可用时自动降级)
├── 安全: PII过滤, 输入/输出审计, RBAC
├── 成本: 按部门计费, 总月预算控制
├── 扩展: 支持10个→100个团队平滑扩展
└── 合规: 数据不出境(如有要求), 审计日志
面试时必须问的澄清问题:
Q1: "用户规模? 多少团队, 每团队多少用户?"
→ 假设: 50个团队, 5000名用户
Q2: "需要自部署模型还是只调用API?"
→ 假设: 以API为主, 支持自部署(安全敏感场景)
Q3: "延迟要求? 实时还是异步?"
→ 假设: Chat实时(流式), 批量任务可异步
Q4: "数据安全等级?"
→ 假设: 金融企业, 需PII过滤, 审计日志, 不允许训练数据被模型提供商使用
Step 2: Estimation 规模估算 (3 min)
用户与请求估算:
DAU: ~2000 (5000用户, 40%日活)
每用户每天: ~20次请求
日请求量: 2000 × 20 = 40,000 requests/day
峰值QPS: 40000 / 86400 × 5 (峰值系数) ≈ 2.3 QPS
→ 这不是高并发系统, 核心挑战在成本和质量
Token用量估算:
平均每次请求:
Input: ~500 tokens (Prompt + Context)
Output: ~300 tokens
每日Token: 40000 × 800 = 32M tokens/day
每月Token: 32M × 30 = ~960M tokens/month ≈ 1B tokens/month
成本估算 (按GPT-4o价格):
Input: 1B × 0.6 × $2.5/1M = $1,500/month (60% input)
Output: 1B × 0.4 × $10/1M = $4,000/month (40% output)
总计: ~$5,500/month (纯API成本)
加上RAG/向量库/基础设施: ~$10,000/month
→ 成本可控, 但需要预算管理机制
存储估算:
对话历史: 40K/day × 2KB = 80MB/day → ~2.4GB/month
文档知识库: 假设50个团队 × 1GB = 50GB
向量索引: 50GB文档 → ~5GB向量 (10:1压缩)
审计日志: ~5GB/month
Step 3: Storage 存储设计 (3 min)
存储层设计:
PostgreSQL (主数据库):
├── users / teams / projects (用户管理)
├── conversations / messages (对话历史)
├── prompts / prompt_versions (提示词管理)
├── usage_records (用量记录)
└── audit_logs (审计日志)
Vector Database (向量存储):
├── 选型: Qdrant / Weaviate / Pgvector
├── 用途: RAG文档检索
└── 按租户隔离: Collection per tenant
Object Storage (S3/MinIO):
├── 原始文档 (PDF/DOCX/etc)
├── 处理后的Chunks
└── 模型输出的缓存
Redis:
├── 语义缓存 (Semantic Cache)
├── 会话状态 (Session State)
├── 速率限制 (Rate Limiting)
└── 预算计数器 (Budget Counters)
Step 4: High-level Design 高层架构 (8 min)
┌─────────────────────────────────┐
│ Client Layer │
│ Web App / API / SDK / Slack Bot │
└─────────────┬───────────────────┘
│
┌─────────────▼───────────────────┐
│ API Gateway │
│ Auth / Rate Limit / Routing │
└─────────────┬───────────────────┘
│
┌───────────────────────┼───────────────────────┐
│ │ │
┌─────────▼─────────┐ ┌──────────▼──────────┐ ┌──────────▼──────────┐
│ Chat Service │ │ RAG Service │ │ Batch Service │
│ (Streaming) │ │ (Doc QA) │ │ (Async Jobs) │
└─────────┬─────────┘ └──────────┬──────────┘ └──────────┬──────────┘
│ │ │
└───────────────────────┼───────────────────────┘
│
┌─────────────▼───────────────────┐
│ LLM Orchestration Layer │
│ Prompt Mgmt / Context Window │
│ Guardrails / PII Filter │
└─────────────┬───────────────────┘
│
┌─────────────▼───────────────────┐
│ Model Router │
│ Route by: cost/latency/quality │
│ Fallback / Load Balance │
└─────────────┬───────────────────┘
│
┌───────────────────────┼───────────────────────┐
│ │ │
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ OpenAI │ │ Anthropic│ │ Self-host│
│ GPT-4o │ │ Claude │ │ Llama │
└───────────┘ └───────────┘ └───────────┘
核心服务说明:
1. API Gateway:
├── 认证: JWT + API Key
├── 限流: 按团队/用户配额
├── 路由: 根据请求类型分发到对应服务
└── 审计: 记录所有请求
2. Chat Service:
├── 处理实时对话请求
├── SSE/WebSocket流式返回
├── 上下文窗口管理
└── 对话历史存取
3. RAG Service:
├── 文档上传和处理
├── 向量检索
├── 上下文注入
└── 答案生成+引用
4. Batch Service:
├── 大批量翻译/摘要
├── 异步队列处理
├── 结果回调通知
└── 利用低峰期cheaper pricing
5. LLM Orchestration Layer:
├── Prompt模板管理
├── System Prompt注入
├── Guardrails(输入/输出过滤)
├── PII检测与脱敏
└── 上下文压缩
6. Model Router:
├── 基于规则/ML的模型选择
├── 故障转移(Provider A挂了用B)
├── 成本优化(简单问题用小模型)
└── 负载均衡
Step 5: API Design 接口设计 (5 min)
核心API:
POST /v1/chat/completions
{
"model": "auto", // auto = 智能路由
"messages": [
{"role": "system", "content": "..."},
{"role": "user", "content": "..."}
],
"stream": true,
"project_id": "team-alpha",
"options": {
"temperature": 0.7,
"max_tokens": 2048,
"rag_enabled": true,
"rag_collection": "team-alpha-docs",
"guardrails": ["pii_filter", "toxicity_filter"]
}
}
Response (SSE Stream):
data: {"id":"msg_001","delta":{"content":"Here"},"usage":null}
data: {"id":"msg_001","delta":{"content":" is"},"usage":null}
data: {"id":"msg_001","delta":{"content":"..."},"usage":{"input":500,"output":128}}
data: [DONE]
POST /v1/documents/ingest
{
"project_id": "team-alpha",
"collection": "team-alpha-docs",
"documents": [
{"url": "s3://bucket/file.pdf", "metadata": {"type": "policy"}}
],
"chunking_strategy": "semantic", // semantic | fixed | sliding
"chunk_size": 512
}
GET /v1/usage/summary?project_id=team-alpha&period=2026-05
Response:
{
"total_requests": 12500,
"total_tokens": {"input": 6250000, "output": 3750000},
"total_cost_usd": 125.50,
"budget_remaining_usd": 374.50,
"by_model": {
"gpt-4o": {"requests": 3000, "cost": 85.0},
"claude-sonnet": {"requests": 5000, "cost": 30.0},
"llama-70b": {"requests": 4500, "cost": 10.5}
}
}
GET /v1/prompts/{prompt_id}/versions
POST /v1/prompts/{prompt_id}/deploy
POST /v1/prompts/{prompt_id}/ab-test
Step 6: Detailed Design 深入设计 (12 min)
6.1 Model Router — 核心组件
Model Router 决策逻辑:
输入因素:
├── 任务类型: chat / code / summary / translation
├── 复杂度: 简单问题 vs 复杂推理
├── 成本约束: 团队预算剩余
├── 延迟要求: 实时 vs 异步
├── 安全级别: 是否包含敏感数据
└── 模型可用性: 当前各Provider状态
路由策略:
Strategy 1: Rule-based (规则路由)
IF task == "code_gen" → Claude Sonnet (编码能力强)
IF task == "translation" && simple → Llama-70b (成本低)
IF task == "complex_reasoning" → GPT-4o / Claude Opus
IF data_sensitivity == "high" → Self-hosted Llama (数据不出域)
IF budget_remaining < 20% → 降级到cheaper model
Strategy 2: ML-based (智能路由)
训练一个轻量分类器:
Input: 用户Query embedding + 任务元数据
Output: 最优模型ID
训练数据: 历史请求的(query, model, quality_score)
目标: 在质量约束下最小化成本
延迟: < 5ms (不能成为瓶颈)
Strategy 3: Cascade (级联路由)
Step 1: 先用小模型(Llama-8B)尝试回答
Step 2: 用评估器判断答案质量
Step 3: 质量不达标 → 升级到大模型
优点: 80%简单问题省70%成本
缺点: 复杂问题延迟增加
Fallback 故障转移:
Primary: OpenAI GPT-4o
Secondary: Anthropic Claude Sonnet
Tertiary: Self-hosted Llama-70b
策略: Circuit Breaker(熔断器)
├── 5min内失败率 > 30% → 触发熔断
├── 自动切换到Secondary
└── 每30s探测Primary是否恢复
6.2 多租户隔离
多租户设计:
数据隔离层级:
Level 1 - 逻辑隔离 (Shared DB, Row-level Security):
├── 所有团队共享数据库
├── 每条记录有 tenant_id
├── 查询自动注入 WHERE tenant_id = ?
└── 适用: 对话历史, 用量记录
Level 2 - Collection隔离 (向量库):
├── 每团队单独Collection
├── RAG检索只在自己的Collection内
└── 适用: 知识库/文档
Level 3 - 物理隔离 (VIP租户):
├── 独立模型实例
├── 独立数据库
└── 适用: 极高安全要求的团队
资源配额管理:
per_team_config:
team_id: "team-alpha"
monthly_budget_usd: 500
rate_limit_rpm: 100 # requests per minute
max_tokens_per_request: 8192
allowed_models: ["gpt-4o", "claude-sonnet", "llama-70b"]
rag_storage_limit_gb: 5
data_retention_days: 90
预算控制:
├── Redis计数器: INCR team:{id}:cost:{month} {cost}
├── 到达80%: 发通知给团队Admin
├── 到达95%: 自动降级到cheaper model
└── 到达100%: 拒绝请求(或需审批)
6.3 安全与Guardrails
安全架构 (Defense in Depth):
Layer 1 — Input Guardrails (请求进入前):
├── PII Detection: 检测身份证/银行卡/手机号
│ ├── Regex规则(快速)
│ ├── NER模型(准确)
│ └── 动作: 脱敏替换 / 拒绝请求
├── Prompt Injection Detection: 检测注入攻击
│ ├── 关键词过滤
│ ├── LLM-as-Judge检测
│ └── 动作: 拒绝 + 告警
├── Toxicity Filter: 有害内容过滤
└── Topic Restriction: 只允许工作相关话题
Layer 2 — System Prompt Protection:
├── System Prompt不随对话发送给用户
├── 防御提取攻击(Do not reveal instructions)
└── 每个团队独立System Prompt
Layer 3 — Output Guardrails (响应返回前):
├── Hallucination Check: RAG场景下验证引用存在
├── Compliance Filter: 不允许生成投资建议等
├── PII Re-check: 确保输出不包含PII
└── 格式验证: JSON/代码格式验证
Layer 4 — Audit & Monitoring:
├── 所有请求/响应记录(加密存储)
├── 异常检测: 批量请求/敏感查询频率
├── 合规报告: 月度使用报告
└── 数据保留策略: 90天后自动清理
6.4 可观测性
LLM平台关键监控指标:
Performance Metrics:
├── TTFT (Time to First Token): P50/P95/P99
├── TPS (Tokens per Second): 流式生成速率
├── E2E Latency: 端到端延迟(含RAG检索)
└── Error Rate: 按模型/团队/错误类型
Quality Metrics:
├── User Satisfaction: 👍/👎 反馈率
├── RAG Relevance: 检索结果相关性
├── Hallucination Rate: 幻觉检测率
└── Guardrail Trigger Rate: 安全过滤触发率
Cost Metrics:
├── Cost per Request: 每次请求平均成本
├── Cost per Team: 各团队支出追踪
├── Token Efficiency: 缓存命中率
└── Budget Burn Rate: 预算消耗速率
Business Metrics:
├── DAU / MAU: 活跃用户数
├── Adoption Rate: 各团队采用率
├── Use Case Distribution: 用例分布
└── Productivity Impact: 效率提升估算
Dashboard 设计:
实时面板: TTFT / QPS / Error Rate / Cost Rate
日报面板: DAU / Token用量 / 质量分数 / 预算消耗
月报面板: 团队排名 / 趋势分析 / ROI估算
Step 7: Evaluation 评估与权衡 (5 min)
关键Trade-off分析:
Trade-off 1: 质量 vs 成本
高质量方案: 全部用GPT-4o/Claude Opus → $15K/month
低成本方案: 全部用Llama-70b自部署 → $3K/month
我们的方案: 智能路由, 简单用小模型, 复杂用大模型 → $6-8K/month
→ 成本降50%的同时质量损失<5%
Trade-off 2: 延迟 vs 安全
低延迟: 跳过Guardrails → TTFT ~200ms
高安全: Input+Output双重过滤 → TTFT ~500ms
我们的方案: Input过滤同步(必须), Output过滤异步(不阻塞流式)
→ 对于流式输出, 先返回给用户, 异步检查并在必要时截断
Trade-off 3: 数据隔离 vs 运维复杂度
完全隔离: 每团队独立实例 → 运维N个实例
完全共享: 单实例多租户 → 可能数据泄露
我们的方案: 逻辑隔离 + 敏感团队物理隔离
→ 大部分团队共享, 5%高敏感团队独立部署
Trade-off 4: 自研 vs 买服务
自研: 完全控制, 但需6-12月开发
买SaaS: 快速上线, 但被锁定+数据风险
我们的方案: 核心层自研(Router/Guardrails), 基础层用云服务(向量库/模型API)
→ 控制关键路径, 非核心外包
Step 8: Deployment 部署与运维 (4 min)
部署架构:
Kubernetes (推荐):
├── Gateway: 2-3 replicas, HPA
├── Chat Service: 3-5 replicas, HPA (按QPS)
├── RAG Service: 2-3 replicas, HPA
├── Batch Service: 1-3 replicas (按队列长度)
├── Model Router: 2 replicas (轻量级)
└── Self-hosted LLM: GPU节点, 独立NodePool
CI/CD Pipeline:
├── Prompt变更: Prompt Registry → A/B Test → Gradual Rollout
├── 代码变更: PR → Test → Staging → Canary → Production
└── 模型变更: Shadow Mode → Eval → Gradual Migration
灾备策略:
├── Multi-region部署 (Primary + DR)
├── 模型Provider故障 → 自动Fallback
├── 数据库: 主从复制 + 定时备份
└── RTO: 5min (切换模型), RPO: 0 (无数据丢失)
扩展路径:
Phase 1 (当前): 50 teams, API-based
Phase 2 (6个月后): 100 teams, 加入Fine-tuned models
Phase 3 (1年后): 500 teams, 加入Agent/Workflow平台
三、参考架构深入
3.1 Prompt管理系统
为什么Prompt管理很重要:
企业LLM平台中, Prompt是核心业务资产
├── 一个好的Prompt值几万美元(节约的人力)
├── Prompt变更可能导致输出质量剧变
├── 需要版本控制、回滚、A/B测试
└── 需要团队间共享和权限管理
Prompt Registry设计:
prompts:
id: "prompt_001"
name: "customer-support-v2"
template: |
You are a {role} assistant for {company}.
Guidelines:
- Be professional and helpful
- Do not provide financial advice
- Always cite sources from the knowledge base
Context: {rag_context}
User: {user_message}
variables: ["role", "company", "rag_context", "user_message"]
versions:
- v1: {template: "...", created: "2026-01-01", status: "deprecated"}
- v2: {template: "...", created: "2026-03-01", status: "active", traffic: 90%}
- v3: {template: "...", created: "2026-05-01", status: "canary", traffic: 10%}
metrics:
v2: {satisfaction: 4.2, hallucination: 2.1%, avg_latency: 1.2s}
v3: {satisfaction: 4.5, hallucination: 1.5%, avg_latency: 1.1s}
A/B测试流程:
1. 创建新版本Prompt (v3)
2. 设置流量分配: v2=90%, v3=10%
3. 收集7天指标数据
4. 统计显著性检验
5. 胜出 → 逐步升级到100%
6. 失败 → 回滚并分析原因
3.2 语义缓存 (Semantic Cache)
为什么需要语义缓存:
传统缓存: key完全匹配 → 命中率低
语义缓存: 语义相似的问题复用答案 → 命中率高30-50%
实现方案:
方案A: Embedding + 相似度搜索
1. 计算Query的Embedding
2. 在缓存向量库中搜索Top-1
3. 相似度 > 0.95 → Cache Hit
4. 相似度 < 0.95 → Cache Miss → 调LLM → 存入缓存
方案B: GPTCache (开源方案)
├── Adapter: 接入各种LLM
├── Pre-processing: Query规范化
├── Embedding: 语义表示
├── Cache Storage: 向量+KV存储
└── Post-processing: 结果适配
缓存策略:
├── TTL: 按内容类型设置过期时间
│ ├── 事实性内容: 24h
│ ├── 代码生成: 7d (相对稳定)
│ └── 实时数据相关: 不缓存
├── 容量: LRU淘汰 + 重要性加权
└── 失效: 当底层知识库更新时清除相关缓存
效果估算:
缓存命中率: 30-40% (企业场景, 很多重复问题)
成本节省: 30% token费用
延迟改善: 命中时 < 50ms (vs 1-3s)
3.3 成本控制体系
企业LLM成本控制 — 五层防线:
Layer 1: 智能路由 (节省30-50%)
├── 简单问题 → 小模型 (Llama-8B, $0.05/1M tokens)
├── 中等问题 → 中模型 (GPT-4o-mini, $0.15/1M tokens)
└── 复杂问题 → 大模型 (GPT-4o, $2.5-10/1M tokens)
Layer 2: 语义缓存 (节省20-30%)
├── 相同/相似问题直接返回缓存结果
└── 每月节省数千美元API调用
Layer 3: Prompt优化 (节省15-25%)
├── Prompt压缩: 去除冗余指令
├── Context窗口管理: 只保留最相关的对话历史
└── 结构化输出: 减少不必要的verbose输出
Layer 4: 批量处理 (节省50%+)
├── 利用Batch API (OpenAI批量接口半价)
├── 非实时任务延迟处理
└── 合并多个小请求为一个大请求
Layer 5: 预算管理 (防止失控)
├── 团队月度预算上限
├── 80%/95%/100%告警阈值
├── 自动降级策略
└── 月度成本复盘会议
成本报表示例:
┌─────────────┬──────────┬──────────┬──────────┐
│ Team │ Budget │ Spent │ Savings │
├─────────────┼──────────┼──────────┼──────────┤
│ Engineering │ $2,000 │ $1,450 │ $780* │
│ Support │ $1,500 │ $1,200 │ $520* │
│ Legal │ $800 │ $650 │ $290* │
│ Marketing │ $500 │ $380 │ $160* │
└─────────────┴──────────┴──────────┴──────────┘
* Savings = 如果不用路由和缓存的估算成本 - 实际成本
四、常见追问及应答
追问 1: "如何处理模型幻觉?"
回答框架:
1. 预防(减少幻觉发生):
├── RAG: 提供事实来源, 要求基于检索结果回答
├── Prompt Engineering: 明确指示"如果不确定请说不知道"
├── Temperature: 降低temperature (0.1-0.3)
└── System Prompt: 限定回答范围
2. 检测(发现幻觉):
├── Source Verification: 检查回答是否有文档支撑
├── Self-Consistency: 同一问题问多次, 答案不一致=可能幻觉
├── NLI (Natural Language Inference): 检查回答与源文档是否矛盾
└── LLM-as-Judge: 用另一个LLM评估回答的事实性
3. 缓解(降低影响):
├── Confidence Score: 给每个回答标注置信度
├── Citation: 要求回答附带引用来源
├── Human-in-the-Loop: 低置信度答案需人工审核
└── Disclaimer: UI上标注"AI生成, 可能有误"
追问 2: "如何评估平台的整体质量?"
LLM平台质量评估体系:
自动评估 (Automated):
├── 功能性: 是否正确完成任务 (Pass/Fail on test cases)
├── 相关性: 回答是否相关 (Embedding similarity)
├── 忠实度: 是否基于提供的上下文 (NLI Score)
├── 安全性: 是否触发Guardrails (Trigger Rate)
└── 延迟: TTFT / 总延迟 / Token生成速率
人工评估 (Human):
├── 用户反馈: 👍/👎 + 可选文字反馈
├── 专家评审: 随机抽样人工评分 (1-5分)
└── 对比评估: A/B测试中Side-by-side比较
综合评分:
Platform Quality Score =
0.3 × Task_Completion_Rate +
0.2 × User_Satisfaction +
0.2 × Faithfulness +
0.15 × Safety_Score +
0.15 × Latency_Score
追问 3: "如何支持Fine-tuned模型?"
Fine-tuning Pipeline集成:
流程:
1. 团队提交训练数据 (JSONL格式)
2. 数据质量检查 (格式/去重/PII过滤)
3. 提交训练任务 (OpenAI FT API / 自部署训练)
4. 训练完成 → 自动评估 (benchmark suite)
5. 评估通过 → 注册到Model Registry
6. 通过Model Router配置为该团队可用
Model Registry:
models:
- id: "ft:gpt-4o:team-alpha:customer-support:abc123"
type: "fine-tuned"
base_model: "gpt-4o"
owner: "team-alpha"
metrics: {accuracy: 0.92, latency_p50: 0.8s}
status: "active"
cost_multiplier: 1.5 # fine-tuned模型通常更贵
权限控制:
├── Fine-tuned模型只对owner团队可见
├── 可选择共享给其他团队
└── 训练数据不可被其他团队访问
追问 4: "如何处理长文档?"
长文档处理策略:
方案1: Chunking + RAG (推荐):
├── 将长文档切分为chunks
├── 检索最相关的Top-K chunks
├── 只把相关chunks放入Context
└── 适用: 大部分场景
方案2: Map-Reduce:
├── Map: 对每个chunk独立处理
├── Reduce: 合并所有chunk的结果
└── 适用: 全文摘要/信息提取
方案3: 长上下文模型:
├── 使用128K/1M context的模型
├── 直接放入完整文档
└── 适用: 需要全局理解的场景(但成本高)
混合策略 (我们的方案):
IF doc_length < 32K tokens → 直接放入context
IF doc_length < 200K tokens → 长上下文模型
IF doc_length > 200K tokens → Chunking + RAG
追问 5: "如果要支持Agent/Workflow怎么扩展?"
扩展到Agent平台:
在现有架构上扩展:
┌─────────────────────────────┐
│ Workflow Engine │ ← 新增
│ (DAG/State Machine) │
└─────────────┬───────────────┘
│
┌─────────────▼───────────────┐
│ Agent Runtime │ ← 新增
│ (Tool Calling / Memory) │
└─────────────┬───────────────┘
│
┌─────────────▼───────────────┐
│ Tool Registry + Execution │ ← 新增
│ (API/DB/Search/Code) │
└─────────────┬───────────────┘
│
┌─────────────▼───────────────┐
│ 现有LLM Orchestration │ ← 复用
└─────────────────────────────┘
关键新增组件:
1. Tool Registry: 注册可调用的工具(API/数据库/搜索)
2. Agent Runtime: 管理Agent循环(Think → Act → Observe)
3. Workflow Engine: DAG编排多步骤流程
4. Memory Store: Agent长期记忆和工作记忆
5. Safety Sandbox: 工具执行的安全沙箱
五、面试评分标准
评分维度 (满分各10分):
1. 需求理解 (10分):
├── 能否识别核心需求 vs 非核心需求
├── 是否主动问澄清问题
└── 是否考虑了企业级特有需求(安全/合规/多租户)
2. 架构设计 (10分):
├── 分层是否清晰合理
├── 组件职责是否单一
└── 是否考虑了可扩展性
3. 深入设计 (10分):
├── 是否深入了关键组件(Router/Guardrails/Cache)
├── 是否有具体的技术方案(不只是画框)
└── 是否考虑了边界情况
4. Trade-off分析 (10分):
├── 是否识别了关键权衡
├── 是否给出了合理的选择理由
└── 是否承认了方案的局限性
5. AI特殊性 (10分):
├── 模型选择和路由策略
├── 成本控制和优化
├── 输出质量保障
└── 安全和Guardrails
优秀候选人的表现:
├── 5min内快速明确范围, 不纠结于细节
├── 先画高层架构, 再深入1-2个核心组件
├── 主动讲Trade-off而不是等面试官问
├── 结合实际经验举例说明设计决策
└── 对AI系统的特殊性有深刻理解(不只是套传统架构)
常见扣分项:
├── 不问需求直接画架构
├── 画完架构不深入任何组件
├── 只考虑Happy Path, 不考虑异常
├── 不提成本(企业最关心的)
└── 安全只是一笔带过
六、面试Tips与模板句
开场模板:
"Before diving into the design, let me clarify a few requirements..."
"I'll use the RESHADED framework to structure my approach."
画架构时:
"Let me start with a high-level architecture, then we can deep dive
into the components you're most interested in."
讲Trade-off时:
"There's a trade-off here between X and Y. I'd choose X because..."
"An alternative approach is... but I prefer the first because..."
被追问不会的:
"That's a great question. I haven't implemented this before,
but here's how I'd approach it..."
结尾:
"To summarize, the key design decisions are:
1. Smart routing for cost optimization
2. Multi-layer guardrails for safety
3. Semantic cache for latency and cost
And the main trade-off is quality vs cost, which we address
through the cascading model approach."
七、今日总结
Day 43 核心收获:
1. RESHADED框架:
系统设计面试的黄金8步, AI系统设计的额外关注点
2. 企业LLM平台设计:
核心是 Model Router + Multi-tenant + Guardrails + Cost Control
3. 关键Trade-off:
质量vs成本 / 延迟vs安全 / 隔离vs复杂度 / 自研vs买服务
4. AI系统设计的特殊性:
传统系统关注Scale+Consistency
AI系统关注Quality+Cost+Latency
Phase 4 面试冲刺正式开始！
明天: Day 44 — 设计一个生产级RAG系统
参考资源:
- System Design Interview: An Insider's Guide Vol.2 — Alex Xu
- Designing Machine Learning Systems — Chip Huyen
- MLOps: Continuous Delivery for Machine Learning — Hugging Face
- LLM in Production — Anyscale / LangChain / LlamaIndex Blogs
- Enterprise LLM Platforms — Microsoft Azure OpenAI / AWS Bedrock Architecture Docs