Arch Day 107
Arch Day 107: AI系统架构 — MLOps/LLMOps全景
Arch Day 107: AI系统架构 — MLOps/LLMOps全景
2026-03-29
第四阶段 - 高阶融合MLOpsLLMOps特征平台模型Serving向量数据库AI网关
日期: 2026-03-29 (Day 107) 阶段: 第四阶段 - 高阶融合 标签: #MLOps #LLMOps #特征平台 #模型Serving #向量数据库 #AI网关
核心概念
一句话定义
AI系统架构不只是"训练一个模型"——它是一套完整的工程体系：从数据管理、特征工程、模型训练、注册管理、在线Serving、监控反馈到持续迭代的全生命周期管理。2026年，MLOps已经从"实验性实践"演变为"企业级基础设施"，LLMOps作为MLOps的延伸正在快速成熟。
为什么关注
AI/ML正在成为每一个系统的核心组件，而不是独立的"AI项目"：
- MLOps市场规模：2026年预计达到43.8亿美元，年复合增长率39.8%
- 从实验到生产的鸿沟：85%的AI项目无法投产——MLOps就是解决这个问题的
- LLMOps是新战场：传统MLOps围绕模型训练，LLMOps围绕Prompt管理、RAG、Guard Rails
- 10年金融经验：金融业是AI落地最活跃的行业——风控、营销、客服都需要ML平台
- 面试高频：高级架构面试必问ML系统设计、特征平台、模型部署策略
误区与反模式
| 误区 | 现实 |
|---|---|
| "MLOps就是把Jupyter Notebook上线" | MLOps是完整的工程体系，Notebook只是冰山一角 |
| "LLMOps和MLOps是两回事" | LLMOps是MLOps的扩展，核心理念相通，但工具链不同 |
| "向量数据库选最火的就行" | 选型取决于数据规模、查询模式、已有技术栈 |
| "模型越大越好" | 模型大小 vs 推理成本 vs 延迟是核心trade-off |
| "特征平台是大公司的事" | 有3个以上ML模型就应该考虑Feature Store |
知识点详解
一、ML平台架构全景
1.1 端到端架构
ML平台全景架构（2026版）：
┌─────────────────────────────────────────────────────────────┐
│ ML Platform Architecture │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Data │ │ Feature │ │ Model │ │ Online │ │
│ │ Mgmt │→│ Engg │→│ Training │→│ Serving │ │
│ │ │ │ │ │ │ │ │ │
│ │ ├─数据源 │ │ ├─离线特征│ │ ├─实验管理│ │ ├─API │ │
│ │ ├─数据质量│ │ ├─在线特征│ │ ├─分布训练│ │ ├─批推理 │ │
│ │ ├─数据版本│ │ ├─近线特征│ │ ├─超参优化│ │ ├─流推理 │ │
│ │ └─数据目录│ │ └─特征目录│ │ └─模型注册│ │ └─边缘推理│ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │ │
│ ┌────┴──────────────┴──────────────┴──────────────┴───┐ │
│ │ Monitoring & Feedback Loop │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 模型监控 │ │ 数据漂移 │ │ A/B测试 │ │ │
│ │ │ (性能/延迟)│ │ 检测 │ │ 统一实验 │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ LLMOps Extension (2025-2026新增) │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │ │
│ │ │ Prompt │ │ RAG │ │ Guard │ │ Cost │ │ │
│ │ │ Mgmt │ │ Pipeline │ │ Rails │ │ Control│ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └────────┘ │ │
│ └──────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
1.2 MLOps成熟度模型
MLOps成熟度（Google提出的3级模型）：
Level 0: 手动ML
├── Jupyter Notebook手动训练
├── 手动部署到生产
├── 无监控无回滚
└── 适用：PoC/实验阶段
Level 1: ML Pipeline自动化
├── 自动化训练Pipeline
├── 特征工程自动化
├── 持续训练(CT) → 数据到了自动重训
├── 模型验证自动化
└── 适用：中等ML成熟度
Level 2: CI/CD for ML
├── 代码变更 → 自动训练 → 自动部署
├── A/B测试自动化
├── 模型监控 + 自动回滚
├── 特征平台 + 实验平台
└── 适用：大规模ML应用
Level 3: 自治ML（2025-2026新趋势）
├── AI Agent自动选择模型架构
├── 自动特征发现和工程
├── 自动漂移检测 + 自动重训
├── 自动成本优化
└── 适用：AI-first企业
二、特征平台(Feature Store)
2.1 为什么需要特征平台
没有Feature Store的痛点：
Data Scientist A:
SELECT age, income, AVG(txn_amount) OVER (...)
FROM raw_data
WHERE ...
Data Scientist B:
SELECT age, annual_income, MEAN(transaction_amt) OVER (...)
FROM source_data
WHERE ...
→ 同一个特征，不同定义，不同计算，不同结果
→ 线上/线下特征不一致 (Training-Serving Skew)
→ 重复计算，浪费资源
→ 新模型要重新写所有特征工程代码
2.2 Feature Store架构
Feature Store架构：
┌─────────────────────────────────────────────────────┐
│ Feature Store │
├─────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────┐ │
│ │ Feature Registry (元数据层) │ │
│ │ ├── 特征定义(Schema/类型/描述) │ │
│ │ ├── 特征血缘(Lineage) → 溯源到原始数据 │ │
│ │ ├── 特征版本 → 支持回滚 │ │
│ │ ├── 特征质量 → 完整性/分布/漂移 │ │
│ │ └── 特征权限 → 谁能读/写哪些特征 │ │
│ └───────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────┐ ┌──────┴──────┐ ┌──────────────┐ │
│ │ 离线存储 │ │ 近线存储 │ │ 在线存储 │ │
│ │ (Batch) │ │ (Near-line) │ │ (Real-time) │ │
│ │ │ │ │ │ │ │
│ │ Hive/ │ │ Kafka/ │ │ Redis/ │ │
│ │ Spark/ │ │ Flink/ │ │ DynamoDB/ │ │
│ │ BigQuery│ │ Spark │ │ Cassandra │ │
│ │ │ │ Streaming │ │ │ │
│ │ 延迟: │ │ 延迟: │ │ 延迟: │ │
│ │ 分钟-小时│ │ 秒-分钟 │ │ <10ms │ │
│ │ │ │ │ │ │ │
│ │ 用途: │ │ 用途: │ │ 用途: │ │
│ │ 训练 │ │ 近实时模型 │ │ 在线推理 │ │
│ └─────────┘ └─────────────┘ └──────────────┘ │
│ │
│ ┌───────────────────────────────────────────────┐ │
│ │ Transformation Engine │ │
│ │ ├── 批处理转换(Spark/Flink Batch) │ │
│ │ ├── 流处理转换(Flink/Spark Streaming) │ │
│ │ ├── 在线转换(Python/Java实时计算) │ │
│ │ └── SQL转换(dbt/Spark SQL) │ │
│ └───────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
2.3 Feast vs Tecton对比（2025-2026）
| 维度 | Feast | Tecton |
|---|---|---|
| 部署模式 | 开源自建 | 全托管SaaS |
| 特征转换 | 需要外部处理(Spark/Flink) | 内置转换引擎(批/流/实时) |
| 在线存储 | 插件化(Redis/DynamoDB等) | 托管在线存储 |
| 延迟性能 | Java gRPC + Redis → 极低延迟 | 优秀，但受托管架构影响 |
| 流特征支持 | 基础(需自己搭Kafka/Flink) | 原生支持，秒级可用 |
| 治理能力 | 基础(需自己扩展) | 企业级(血缘/权限/审计) |
| 成本 | 免费(但运维成本高) | 付费(但运维成本低) |
| 适用场景 | 有强ML工程团队的中大型公司 | 需要快速上线+SLA保障的企业 |
| 社区/生态 | CNCF生态，活跃社区 | 商业生态，专业支持 |
| 2026更新 | v0.10: 增强流数据源/云集成 | 持续加强实时流/治理能力 |
选型建议：
选Feast如果：
├── 你有强大的ML工程团队(>5人)
├── 已有Spark/Flink/Kafka基础设施
├── 需要深度定制
├── 成本敏感
└── 已经是Kubernetes生态
选Tecton如果：
├── 需要快速上线(<3个月)
├── 需要生产级SLA(99.9%+)
├── 缺少ML工程专家
├── 需要企业级治理(审计/合规)
└── 愿意为减少运维付费
三、模型Serving架构
3.1 Serving框架对比（2025-2026）
模型Serving框架演进：
2020-2022: TFServing/TorchServe → 传统ML模型
2022-2024: vLLM/TGI → LLM专用Serving
2025-2026: vLLM/SGLang + TensorRT-LLM → 高性能LLM Serving
+ AI Gateway → 统一管理层
核心框架对比：
| 维度 | vLLM | TGI (v3) | Triton/TensorRT-LLM | SGLang |
|---|---|---|---|---|
| 核心创新 | PagedAttention | Flash Attention + 长上下文优化 | TensorRT优化内核 | RadixAttention |
| 性能 | 高吞吐基线 | 长Prompt(>200k)快13x | H100上高20-40% | 与vLLM竞争 |
| 易用性 | pip install + 1命令 | Docker + 少量配置 | 需编译TRT引擎+模型仓库 | pip install |
| API兼容 | OpenAI兼容 | OpenAI兼容 | 自有gRPC/HTTP | OpenAI兼容 |
| 硬件支持 | NVIDIA + AMD + TPU | NVIDIA为主 | 仅NVIDIA | NVIDIA + AMD |
| 社区 | 最大最活跃 | Hugging Face生态 | NVIDIA企业级 | 快速增长 |
| 适用场景 | 通用LLM Serving | HF模型快速部署 | 极致性能+企业级 | 结构化生成 |
| 2026推荐 | 默认首选 | HF生态首选 | 需要极致优化时 | 新锐挑战者 |
3.2 Serving架构设计
生产级模型Serving架构：
┌────────────────┐
│ AI Gateway │
│ (路由/限流/缓存) │
└───────┬────────┘
│
┌─────────────┼─────────────┐
│ │ │
┌─────┴─────┐ ┌────┴────┐ ┌─────┴─────┐
│ vLLM集群 │ │ TGI集群 │ │ TRT-LLM │
│ (通用) │ │ (HF模型)│ │ (高性能) │
│ │ │ │ │ │
│ ┌───────┐ │ │ ┌─────┐ │ │ ┌───────┐ │
│ │GPU Pod│ │ │ │GPU │ │ │ │H100 │ │
│ │ x N │ │ │ │Pod │ │ │ │集群 │ │
│ └───────┘ │ │ └─────┘ │ │ └───────┘ │
└───────────┘ └─────────┘ └───────────┘
│ │ │
┌─────┴─────────────┴─────────────┴────┐
│ Model Registry │
│ ┌──────────────────────────────────┐ │
│ │ MLflow / Weights & Biases │ │
│ │ ├── 模型版本管理 │ │
│ │ ├── A/B流量分配 │ │
│ │ ├── 金丝雀发布 │ │
│ │ └── 自动回滚 │ │
│ └──────────────────────────────────┘ │
└──────────────────────────────────────┘
3.3 关键性能指标
| 指标 | 定义 | 典型目标 |
|---|---|---|
| TTFT | Time to First Token | <200ms (交互式) |
| TPS | Tokens Per Second (生成速度) | >30 tokens/s/请求 |
| 吞吐量 | 并发请求数 × TPS | 取决于GPU数量 |
| P99延迟 | 99分位延迟 | <2s (对话式) |
| GPU利用率 | GPU计算利用率 | >70% |
| 内存效率 | KV Cache利用率 | >90% (PagedAttention) |
四、LLMOps特有挑战
4.1 MLOps vs LLMOps
MLOps vs LLMOps对比：
┌─────────────────┬────────────────────┬────────────────────┐
│ 维度 │ MLOps │ LLMOps │
├─────────────────┼────────────────────┼────────────────────┤
│ 核心制品 │ 模型(权重+代码) │ Prompt+模型+RAG │
│ 训练方式 │ 从头训练/微调 │ 微调/ICL/RLHF/DPO │
│ 评估方式 │ 数值指标(AUC/F1) │ 主观+自动(LLM Judge)│
│ 版本管理 │ 数据版本+模型版本 │ +Prompt版本+RAG版本 │
│ 成本模型 │ 训练GPU + 推理GPU │ 训练 + 推理 + Token │
│ 监控重点 │ 准确率/漂移 │ +幻觉/有害/成本 │
│ 安全关注 │ 模型偏见/公平性 │ +越狱/注入/数据泄露 │
│ 迭代周期 │ 数据→训练→评估 │ Prompt→测试→RAG调优 │
│ 关键工具 │ MLflow/Kubeflow │ +LangSmith/Maxim │
│ 2026新趋势 │ AutoML/自治ML │ Agent编排/MCP/A2A │
└─────────────────┴────────────────────┴────────────────────┘
4.2 Prompt Management
Prompt Management架构：
┌──────────────────────────────────────────────────┐
│ Prompt Management System │
├──────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Prompt Registry │ │
│ │ ├── Prompt模板版本管理 │ │
│ │ ├── 变量(Variables)注入 │ │
│ │ ├── A/B测试分组 │ │
│ │ ├── 使用统计(Token消耗/延迟/质量) │ │
│ │ └── 权限控制(谁能修改哪些Prompt) │ │
│ └──────────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────────────────┐ │
│ │ Prompt Testing │ │
│ │ ├── 单元测试(固定输入→期望输出) │ │
│ │ ├── 回归测试(旧Case不能退步) │ │
│ │ ├── LLM-as-Judge(用LLM评估LLM) │ │
│ │ └── Human-in-the-Loop(关键场景人工审核) │ │
│ └──────────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────────────────┐ │
│ │ Prompt Optimization │ │
│ │ ├── DSPy自动优化 │ │
│ │ ├── Few-shot示例选择 │ │
│ │ └── Chain-of-Thought模板 │ │
│ └──────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘
4.3 Guard Rails设计
LLM Guard Rails多层防御：
Layer 1: 输入过滤
├── Prompt Injection检测 → 识别恶意指令注入
├── PII检测 → 自动脱敏个人信息
├── 有害内容检测 → 拦截暴力/歧视/色情内容
└── Token预算检查 → 防止恶意超长输入
Layer 2: 模型层控制
├── System Prompt锁定 → 防止被覆盖
├── 温度/Top-P控制 → 限制随机性
├── 停止序列(Stop Sequences)
└── JSON模式 → 强制结构化输出
Layer 3: 输出验证
├── 幻觉检测 → 与知识库交叉验证
├── 格式验证 → 确保输出符合Schema
├── 有害内容二次检测
├── 引用来源验证(RAG场景)
└── 一致性检查 → 多次生成对比
Layer 4: 业务层兜底
├── 人工审核队列 → 高风险回答送人工
├── 置信度阈值 → 低置信度返回兜底回答
├── 速率限制 → 防止滥用
└── 审计日志 → 所有输入输出可追溯
五、向量数据库选型（2025-2026）
5.1 选型矩阵
| 维度 | Pinecone | Milvus | Weaviate | Qdrant | pgvector |
|---|---|---|---|---|---|
| 部署 | 全托管 | 自建/Zilliz Cloud | 自建/Cloud | 自建/Cloud | PG扩展 |
| 语言 | — | Go/C++ | Go | Rust | C |
| 最大规模 | 十亿级 | 百亿级 | 十亿级 | 十亿级 | 千万级 |
| 混合搜索 | 专有稀疏编码 | BM25(v2.5+) | BlockMax WAND | 命名向量混合 | 需扩展 |
| 元数据过滤 | 基础 | 强 | 强 | 最强(Rust优化) | SQL原生 |
| ACID | 无 | 无 | 无 | 无 | 完整ACID |
| 延迟(1M) | <50ms | <20ms | <50ms | <30ms | 50-100ms |
| 生态 | 最广API集成 | CNCF毕业 | GraphQL原生 | 极简API | PostgreSQL生态 |
| 成本 | 高(托管溢价) | 中 | 中 | 低(Rust高效) | 最低(PG已有) |
| 适合 | 快速上手 | 大规模部署 | 多模态+混合搜索 | 高性能+过滤 | 已有PG |
5.2 选型决策树
向量数据库选型决策树（2026版）：
START
│
├── 已经有PostgreSQL？
│ ├── YES → 数据量<5000万？
│ │ ├── YES → pgvector/pgvectorscale ★
│ │ └── NO → 考虑专用向量数据库
│ └── NO → 继续
│
├── 需要全托管(零运维)？
│ ├── YES → Pinecone ★
│ └── NO → 继续
│
├── 数据量>10亿？
│ ├── YES → Milvus/Zilliz Cloud ★
│ └── NO → 继续
│
├── 需要复杂元数据过滤？
│ ├── YES → Qdrant ★
│ └── NO → 继续
│
├── 需要多模态+混合搜索？
│ ├── YES → Weaviate ★
│ └── NO → 继续
│
└── 默认推荐 → Qdrant（性能/灵活性最佳平衡）
5.3 pgvectorscale的崛起
2025-2026年的一个重要趋势是pgvectorscale的崛起——它让PostgreSQL在5000万向量规模下具备了专用向量数据库的竞争力：
pgvectorscale关键优势：
├── 5000万向量 → 471 QPS @ 99%召回率
├── 完整ACID事务（向量数据库做不到）
├── 无需引入新数据库（降低运维复杂度）
├── SQL原生查询（团队学习成本为零）
└── 成本远低于专用向量数据库
局限：
├── 超大规模(>1亿)性能不如Milvus/Qdrant
├── 分布式扩展能力有限
└── 高级向量操作（如量化策略）不如专用DB灵活
六、AI网关(AI Gateway)设计
6.1 AI网关 vs API网关
API网关 vs AI网关：
API Gateway: AI Gateway:
├── HTTP路由 ├── 多模型路由
├── 速率限制 ├── Token级限流
├── 认证/鉴权 ├── Prompt安全控制
├── 负载均衡 ├── 语义缓存(Semantic Cache)
├── 请求/响应转换 ├── 成本控制/Token计量
└── 日志/监控 ├── Guard Rails
├── 多Provider容灾
├── Agent工作流支持
└── 可观测性(延迟+成本+质量)
6.2 AI网关架构
AI Gateway架构（2026版）：
┌──────────────────────────────────────────────────────────┐
│ AI Gateway │
├──────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Ingress Layer │ │
│ │ ├── OpenAI兼容API → 统一接口 │ │
│ │ ├── 认证/鉴权 → API Key / OAuth / JWT │ │
│ │ ├── 速率限制 → 按用户/团队/模型 │ │
│ │ └── 请求验证 → Schema检查 + Guard Rails │ │
│ └────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Routing & Optimization Layer │ │
│ │ ├── 智能路由 → 按成本/延迟/质量选择模型 │ │
│ │ ├── 语义缓存 → 相似问题返回缓存（节省30-60%成本） │ │
│ │ ├── Fallback → Provider故障自动切换 │ │
│ │ ├── 负载均衡 → 加权轮询 + 自适应 │ │
│ │ └── Prompt增强 → 注入System Prompt/RAG上下文 │ │
│ └────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Provider Layer │ │
│ │ ├── OpenAI (GPT-4o/o3) │ │
│ │ ├── Anthropic (Claude) │ │
│ │ ├── Google (Gemini) │ │
│ │ ├── Self-hosted (vLLM/TGI) │ │
│ │ └── 其他 (Mistral/Cohere/...) │ │
│ └────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Observability Layer │ │
│ │ ├── Token消耗追踪 → 按团队/项目/模型 │ │
│ │ ├── 延迟监控 → TTFT/TPS/P99 │ │
│ │ ├── 质量监控 → 幻觉率/满意度 │ │
│ │ ├── 成本仪表板 → 实时/预算/预测 │ │
│ │ └── 审计日志 → 完整请求/响应（合规需要） │ │
│ └────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
6.3 主流AI网关方案对比（2026）
| 方案 | 类型 | 核心优势 | 延迟开销 | 适用 |
|---|---|---|---|---|
| Portkey | SaaS | 最全功能集(30+Provider) | 中等 | 企业级多Provider |
| LiteLLM | 开源/Python | OpenAI统一接口 | 高(Python GIL) | 开发/测试 |
| Bifrost | 开源/Go | 极低延迟(11μs) | 极低 | 高性能生产 |
| Kong AI Gateway | 商业 | 已有Kong用户无缝升级 | 低 | 已有Kong的企业 |
| AWS Bedrock | 云服务 | AWS生态集成 | 中等 | AWS全家桶用户 |
七、统一实验平台
7.1 A/B测试+特征实验+模型实验
统一实验平台：
┌──────────────────────────────────────────────────────────┐
│ Unified Experiment Platform │
├──────────────────────────────────────────────────────────┤
│ │
│ 实验类型: │
│ ├── A/B测试: UI变更/文案/功能开关 │
│ ├── 特征实验: 不同特征组合 → 模型效果 │
│ ├── 模型实验: 不同模型/超参 → 业务指标 │
│ └── Prompt实验: 不同Prompt → 生成质量(2025+新增) │
│ │
│ 关键能力: │
│ ├── 流量分配: 用户→实验组的确定性分配(哈希) │
│ ├── 互斥/分层: 多个实验不冲突 │
│ ├── 指标计算: 自动计算统计显著性 │
│ ├── 早停规则: 负面效果自动停止 │
│ └── 毕业流程: 胜出方案自动全量 │
│ │
│ 架构: │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │实验配置│→│流量分配│→│指标收集│→│分析报告│ │
│ │管理 │ │引擎 │ │Pipeline│ │引擎 │ │
│ └──────┘ └──────┘ └──────┘ └──────┘ │
└──────────────────────────────────────────────────────────┘
八、实操：设计"金融AI平台"
金融AI平台完整架构：
┌──────────────────────────────────────────────────────────────┐
│ Financial AI Platform │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌─── 数据层 ──────────────────────────────────────────────┐│
│ │ 数据源: 交易流水 | 用户行为 | 征信数据 | 市场数据 ││
│ │ 数据湖: Delta Lake / Iceberg ││
│ │ 数据质量: Great Expectations + 自动化监控 ││
│ └──────────────────────────────────────────────────────────┘│
│ │ │
│ ┌─── 特征层(Feast) ──────┴──────────────────────────────┐ │
│ │ 离线特征: 用户画像/信用评分历史/交易统计(Spark Batch) │ │
│ │ 近线特征: 近7天交易频率/近1小时交易金额(Flink Streaming) │ │
│ │ 在线特征: 当前余额/实时风险分(Redis, <5ms) │ │
│ └──────────────────────────────────────────────────────────┘│
│ │ │
│ ┌─── 模型层 ──────────────┴───────────────────────────────┐│
│ │ 训练: 分布式训练(Horovod/DeepSpeed) + W&B实验追踪 ││
│ │ 注册: MLflow Model Registry + 审批流程(合规要求) ││
│ │ 评估: 自动化回测 + 公平性检测(金融监管) ││
│ └──────────────────────────────────────────────────────────┘│
│ │ │
│ ┌─── Serving层 ──────────┴────────────────────────────────┐│
│ │ ML模型: TorchServe(风控模型/信用评分, <50ms) ││
│ │ LLM: vLLM(智能客服/文档理解, <2s TTFT) ││
│ │ AI Gateway: Portkey(多模型路由/成本控制/审计日志) ││
│ └──────────────────────────────────────────────────────────┘│
│ │ │
│ ┌─── 监控层 ──────────────┴────────────────────────────────┐│
│ │ 模型监控: Evidently(数据漂移/模型性能衰减) ││
│ │ LLM监控: LangSmith(Prompt质量/幻觉率/Token成本) ││
│ │ 业务监控: 风控准确率/误报率/客户满意度 ││
│ │ 合规审计: 所有模型决策可追溯(金融监管要求) ││
│ └──────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────────┘
面试题精选
面试题1：MLOps和LLMOps有什么区别？
30秒版本： MLOps关注模型训练全生命周期管理，核心制品是模型权重。LLMOps在此基础上新增了Prompt管理、RAG Pipeline、Guard Rails和Token成本控制。两者理念相通但工具链不同——MLOps用MLflow/Kubeflow，LLMOps用LangSmith/Maxim。
2分钟版本： 我把它分三个维度来讲：
-
核心差异：MLOps的迭代单位是"数据+模型"，每次改进是收集更多数据、调整特征、重新训练。LLMOps的迭代单位是"Prompt+RAG+模型"，很多时候改一个Prompt就能显著改善效果，不需要重训模型。
-
工具链差异：MLOps用Feature Store管理特征、MLflow追踪实验、Kubeflow编排Pipeline。LLMOps新增了Prompt版本管理、向量数据库(RAG)、Guard Rails(安全护栏)、LLM Evaluation框架(LLM-as-Judge)。
-
成本模型差异：MLOps的成本主要是训练时的GPU。LLMOps的成本分三块——训练(微调)、推理(Token计费)、RAG(向量存储+检索)。Token成本是LLMOps的核心关注点，所以AI Gateway的语义缓存和路由优化变得很重要。
在我设计金融AI平台时，实际上MLOps和LLMOps是统一在一个平台上的——共享数据层和监控层，但模型训练和Serving走不同的路径。
面试题2：向量数据库如何选型？
30秒版本： 如果已有PostgreSQL且数据量<5000万，首选pgvectorscale。需要零运维选Pinecone。10亿级以上选Milvus。需要复杂过滤选Qdrant。多模态+混合搜索选Weaviate。
2分钟版本： 选型要考虑五个维度：
-
现有技术栈：如果已经有PostgreSQL，pgvectorscale在5000万向量以内性能出色，而且不用引入新数据库——这在企业环境中运维成本的节省是巨大的，还有完整ACID事务。
-
数据规模：千万级以下pgvector够用；亿级首选Milvus（Go/C++，分布式扩展性最强）或Qdrant（Rust，单机性能极好）；十亿级以上必须Milvus。
-
查询模式：如果大量需要元数据过滤（比如"找与这个问题相似的、且属于金融领域、且时间在最近30天的文档"），Qdrant的Rust实现过滤性能最优。
-
运维能力：没有专职DBA/运维团队就选托管方案——Pinecone(最简单)或Zilliz Cloud(Milvus托管版)。
-
成本：Pinecone最贵但最省心，pgvector最便宜但功能最简单。要根据预算和团队能力权衡。
今日总结
核心要点
- ML平台是端到端工程体系，不是"训练一个模型"
- Feature Store解决训练-推理特征不一致(Training-Serving Skew)问题
- vLLM是2026年LLM Serving的默认选择，PagedAttention是核心创新
- LLMOps在MLOps基础上新增Prompt管理、RAG、Guard Rails、成本控制
- 向量数据库选型取决于规模、技术栈、查询模式——pgvectorscale是PostgreSQL用户的杀手级方案
- AI网关正从可选组件变为关键基础设施，语义缓存可节省30-60%成本
明日预告
Day 108将深入AI Agent系统架构——从Agent架构模式到多Agent编排，从RAG演进到安全权限设计。