AI Day 30: 第二阶段总结 — LLM工程实践全景 (Phase 2 Summary: LLM Engineering in Practice)
第一阶段回答了"LLM是什么、能做什么"，第二阶段回答了"LLM怎么在生产环境中可靠、安全、经济地做"。15天工程实践的核心洞察是：模型能力只占生产系统的20%，剩下80%是围绕模型构建的工程基础设施——Gateway、安全层、监控、缓存、评估、部署——这些才是区分Demo和Production的真正分水岭。
日期: 2026-05-01
阶段: 第二阶段 — 工程实践 (Day 16-30)
标签: Phase Review Engineering Summary 架构决策 RAG工程 Agent工程 成本控制 安全 可观测性 测试 面试汇总
学习路径树
AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15) ✅
│ ├── Day 1: Transformer架构与LLM基础 ✅
│ ├── Day 2: 模型量化与本地部署 ✅
│ ├── Day 3: 训练过程深度：Pre-training / SFT / RLHF / DPO ✅
│ ├── Day 4: Prompt Engineering与上下文学习(ICL)原理 ✅
│ ├── Day 5: RAG架构：检索增强生成全链路 ✅
│ ├── Day 6: 向量数据库与Embedding模型 ✅
│ ├── Day 7: Fine-tuning实战：LoRA / QLoRA / Adapter ✅
│ ├── Day 8: 推理优化：vLLM / TensorRT-LLM / SGLang ✅
│ ├── Day 9: 长上下文技术：RoPE扩展 / Ring Attention ✅
│ ├── Day 10: 多模态模型：Vision-Language架构 ✅
│ ├── Day 11: Reasoning模型：CoT / o1 / R1 / Extended Thinking ✅
│ ├── Day 12: Agent框架：ReAct / Tool Use / Planning ✅
│ ├── Day 13: MCP协议与Tool生态 ✅
│ ├── Day 14: 模型评估：Benchmark / Arena / 安全评估 ✅
│ └── Day 15: 阶段复习与架构总结 ✅
│
├── 第二阶段：工程实践 (Day 16-30) ✅
│ ├── Day 16: LLM应用架构：API Gateway / 路由 / 缓存 ✅
│ ├── Day 17: LLM安全与Guardrails ✅
│ ├── Day 18: 可观测性与监控 ✅
│ ├── Day 19: 生产级RAG(1)：Chunking与文档解析 ✅
│ ├── Day 20: 生产级RAG(2)：检索与Reranking ✅
│ ├── Day 21: 生产级RAG(3)：评估与迭代 ✅
│ ├── Day 22: Agent工程化(1)：状态管理与错误恢复 ✅
│ ├── Day 23: Agent工程化(2)：成本与延迟优化 ✅
│ ├── Day 24: Agent工程化(3)：多Agent协作架构 ✅
│ ├── Day 25: Agent工程化(4)：测试与部署 ✅
│ ├── Day 26: LLM成本工程 ✅
│ ├── Day 27: 多模型编排与Fallback ✅
│ ├── Day 28: LLM应用测试策略 ✅
│ ├── Day 29: 案例分析：企业LLM平台架构 ✅
│ └── Day 30: 第二阶段总结 ← 你在这里
│
├── 第三阶段：金融零售AI应用 (Day 31-42)
│ ├── Day 31-35: 金融AI（风控模型/智能投顾/合规/反欺诈）
│ ├── Day 36-40: 零售AI（推荐系统/智能客服/供应链预测/营销）
│ └── Day 41-42: CeFi x DeFi x AI融合架构
│
└── 第四阶段：面试冲刺 (Day 43-50)
├── Day 43-46: 系统设计面试（LLM平台/RAG/Agent/推荐）
├── Day 47-49: 产品/架构面试模拟
└── Day 50: 总结与作品集
核心概念：从理论到工程的跨越 (From Theory to Engineering)
一句话定义
第一阶段回答了"LLM是什么、能做什么"，第二阶段回答了"LLM怎么在生产环境中可靠、安全、经济地做"。15天工程实践的核心洞察是：模型能力只占生产系统的20%，剩下80%是围绕模型构建的工程基础设施——Gateway、安全层、监控、缓存、评估、部署——这些才是区分Demo和Production的真正分水岭。
为什么这个跨越如此关键
第一阶段(Day 1-15) 第二阶段(Day 16-30)
├── 模型选哪个好? ├── 多模型怎么编排和Fallback?
├── RAG的原理是什么? ├── Chunking/Rerank/评估怎么做?
├── Agent怎么规划? ├── 状态管理/错误恢复/成本控制?
├── Prompt怎么写? ├── Prompt版本管理和A/B测试?
└── 模型怎么评? └── 非确定性系统怎么测试和部署?
核心差异
"让它工作" ──────────────→ "让它在生产中持续可靠地工作"
(Make it work) (Make it work in production, reliably)
金融类比：这15天 = 把金融产品从"内部测试"推向"正式对客运营"
PoC (Day 1-15的知识足够) Production (需要Day 16-30的完整工程体系)
├── 内部演示效果不错 ├── 合规审批 — 谁为AI输出负责?
├── Notebook跑得通 ├── 7×24运维 — 模型挂了怎么办?
├── 单人使用没问题 ├── 万人并发 — 成本/延迟可控?
└── "AI确实能做" ├── 安全防线 — 注入/泄露怎么拦?
├── 质量闭环 — 怎么知道没变差?
└── "AI能可靠、安全、经济地做"
Day 16-29 知识回顾 (One-Liner + Key Takeaway)
每天一句话定位 + 最核心的收获
Day 16: LLM应用架构 — API Gateway / 路由 / 缓存
一句话: 生产级LLM系统的骨架是六层架构：Gateway、路由、缓存、Prompt管理、模型层、可观测性。
核心收获: 智能路由是降本的最大杠杆 — 60%简单请求走小模型，成本从$100K降到$8K/月，节省91.8%。LLM架构和银行核心系统的中间件架构完全同构：适配器统一接口、断路器做Fallback、分层缓存降成本、全链路追踪保合规。
Day 17: LLM安全与Guardrails
一句话: LLM安全不是一层防线能解决的，必须纵深防御 — 输入层/处理层/输出层三层Guardrails。
核心收获: Prompt Injection无法100%防住（LLM无法可靠区分开发者指令和用户输入），因此设计不能依赖"防住输入"，而是假设每层都会被突破 — 处理层做权限控制，输出层做最后把关。OWASP LLM Top 10是安全设计的权威参考。
Day 18: 可观测性与监控
一句话: LLM应用的可观测性不是传统APM的延伸，而是一个新维度 — HTTP 200不代表回答正确。
核心收获: 四层可观测性架构：基础设施(Prometheus) → 请求链路(LangFuse Tracing) → 质量评估(LLM-as-Judge异步采样) → 业务指标(成本归因/预算告警)。可观测性从Day 1就要建，不是事后补的。
Day 19: 生产级RAG(1) — Chunking与文档解析
一句话: RAG效果60%取决于数据质量，文档解析和Chunking策略是被低估的核心环节。
核心收获: 三层解析策略(快速/高精/多模态)覆盖不同文档类型；Chunking无"万能参数"，必须在自己的数据上做AB实验；Parent-Child策略是处理混合查询的最佳方案(小Child检索 + 大Parent返回上下文)。
Day 20: 生产级RAG(2) — 检索与Reranking
一句话: 检索优化是四阶段工程：Query理解 → 多路召回(Hybrid Search) → Cross-Encoder精排 → Context组装。
核心收获: Reranker不是"更好的Embedding能替代的"——Bi-Encoder独立编码有信息损失，Cross-Encoder做Query-Document深度交叉注意力，精度差异本质性。工业标准是两阶段：Embedding快速召回Top-100(ms级) → Reranker精排Top-10(~1s)。
Day 21: 生产级RAG(3) — 评估与迭代
一句话: RAG评估的四维框架：Context Precision + Context Recall + Faithfulness + Answer Relevancy，精准定位问题在检索还是生成。
核心收获: 评估集(Golden QA Set)是RAG系统的"资产"——至少200-300条，人工标注+LLM合成，集成到CI/CD，每次变更前跑回归。幻觉分三类(事实性/忠实性/推理性)，治疗方案不同。
Day 22: Agent工程化(1) — 状态管理与错误恢复
一句话: Agent可靠性的四层设计：状态机持久化 → 错误分级处理(重试/回退/人工) → 幂等性保证 → 优雅降级。
核心收获: Agent状态管理 = 银行WAL日志思想，每个状态转换持久化到数据库，服务重启后可从Checkpoint恢复。幂等性是涉及资金操作的生命线 — Agent用idempotency key保证不重复操作，和银行用交易流水号防重扣完全同构。
Day 23: Agent工程化(2) — 成本与延迟优化
一句话: Agent成本的80%来自LLM调用（每步500ms-3s x N步），优化核心是减少调用次数+降低每次成本。
核心收获: 五层优化：Prompt Caching(减40%Token) + 模型路由(简单步用小模型) + 语义缓存(同质问题复用) + 历史压缩(长对话摘要化) + 工具裁剪(只送相关工具)。预算控制三要素：步数上限 + Token预算 + 循环检测。
Day 24: Agent工程化(3) — 多Agent协作架构
一句话: 多Agent不是银弹 — 成本N倍、延迟叠加、错误传播，只在多专业领域/对抗性检查/可并行的场景才值得。
核心收获: CrewAI快速验证idea(1天)，LangGraph做生产级实现(1周)。金融合规多Agent的关键：每个Agent决策有reasoning字段、通信全持久化、合规Agent一票否决、人工审批节点hardcoded不可跳过。
Day 25: Agent工程化(4) — 测试与部署
一句话: Agent测试的核心挑战是非确定性 — 四层金字塔：确定性assert → LLM-as-Judge → 统计分布 → Golden Set回归。
核心收获: Agent灰度发布三步走：Shadow(零风险对比) → Canary(1%→5%→25%→100%，自动回滚) → Full(24h观察)。CI/CD五大差异：构建物包含Prompt+模型版本、多了Eval阶段、发布需要质量Gate、模型版本要锁定、A/B测试需更大样本。
Day 26: LLM成本工程
一句话: LLM成本控制"四把刀"：智能路由(按复杂度分模型) + 多层缓存(50%请求免调用) + Prompt压缩 + Token预算管理。
核心收获: 典型企业LLM应用从$10K/月优化到$2-3K/月是可行的。关键洞察：成本优化和质量保障不矛盾——60%简单请求用Haiku处理，质量反而更快（延迟低）；只有10%复杂请求需要Opus/o3，集中资源保质量。
Day 27: 多模型编排与Fallback
一句话: 生产级LLM应用必须多模型编排 — 四种模式：Primary-Secondary / Capability-Based / Cascade / Load Balance。
核心收获: 熔断器防级联故障是核心安全机制。Fallback至少3层(Anthropic→OpenAI→Google/开源)。核心服务还要有非AI降级方案——回退到规则引擎或预置模板。不同模型输出不一致靠JSON Schema强约束解决90%的问题。
Day 28: LLM应用测试策略
一句话: Eval-Driven Development — 评估集先行，所有迭代围绕评估分数驱动，像TDD但适配非确定性。
核心收获: 测试成本优化：60%用例只跑免费断言(contains/schema)，30%用Embedding相似度，10%才用LLM-Judge。Promptfoo(YAML/CLI)适合快速迭代，DeepEval(Python/pytest)适合CI集成。每个线上Bug加入Golden Set，测试集持续增长。
Day 29: 企业LLM平台案例
一句话: PoC证明"AI能做"，Production证明"AI能可靠、安全、经济地做"——差距在工程化、安全合规、成本控制和组织协同。
核心收获: 企业LLM落地最容易被忽视但最重要的环节是数据治理——不性感、不可见、不紧急，但RAG效果60%取决于数据质量。启动第一件事做数据审计，预算30%投入数据治理。金融客服案例的五大决策教训字字珠玑。
工程实践能力树 (Engineering Capability Tree)
15天工程实践知识，组装成一棵完整的LLM工程能力树
╔══════════════════════════════════════════════════════════════════════════════════╗
║ LLM 工程实践能力树 (Day 16-30 Knowledge Architecture) ║
╠══════════════════════════════════════════════════════════════════════════════════╣
║ ║
║ ┌──────────────────────────────────────────────────────────────────────────┐ ║
║ │ L7: 企业落地层 (Day 29) │ ║
║ │ ┌─────────────┐ ┌─────────────┐ ┌──────────────┐ ┌─────────────────┐ │ ║
║ │ │PoC→Prod规划 │ │组织协同设计 │ │数据治理体系 │ │ROI/成本预算 │ │ ║
║ │ │三阶段演进 │ │责任归属 │ │文档Owner制度 │ │业务指标>技术 │ │ ║
║ │ │金融客服案例 │ │跨部门协作 │ │增量更新策略 │ │指标 │ │ ║
║ │ └─────────────┘ └─────────────┘ └──────────────┘ └─────────────────┘ │ ║
║ └──────────────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌──────────────────────────────────────────────────────────────────────────┐ ║
║ │ L6: 测试与部署层 (Day 25, 28) │ ║
║ │ ┌──────────────────┐ ┌───────────────────┐ ┌────────────────────────┐ │ ║
║ │ │非确定性测试金字塔 │ │Eval-Driven Dev │ │灰度发布策略 │ │ ║
║ │ │assert/Judge/统计 │ │Promptfoo/DeepEval │ │Shadow→Canary→Full │ │ ║
║ │ │Golden Set回归 │ │CI/CD三Gate │ │自动回滚/版本锁定 │ │ ║
║ │ └──────────────────┘ └───────────────────┘ └────────────────────────┘ │ ║
║ └──────────────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌──────────────────────────────────────────────────────────────────────────┐ ║
║ │ L5: 成本与编排层 (Day 23, 26, 27) │ ║
║ │ ┌──────────────────┐ ┌───────────────────┐ ┌────────────────────────┐ │ ║
║ │ │智能路由 │ │多层缓存 │ │多模型编排 │ │ ║
║ │ │规则/ML/级联 │ │精确/语义/Prompt │ │Primary-Secondary │ │ ║
║ │ │60%简单→小模型 │ │50%请求免调用 │ │Cascade/Load Balance │ │ ║
║ │ │成本降91% │ │TTL分级管理 │ │熔断器/3层Fallback │ │ ║
║ │ └──────────────────┘ └───────────────────┘ └────────────────────────┘ │ ║
║ └──────────────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌──────────────────────────────────────────────────────────────────────────┐ ║
║ │ L4: Agent工程层 (Day 22, 23, 24) │ ║
║ │ ┌──────────────────┐ ┌───────────────────┐ ┌────────────────────────┐ │ ║
║ │ │状态管理 │ │错误恢复 │ │多Agent协作 │ │ ║
║ │ │FSM + 持久化 │ │重试/回退/人工接管 │ │CrewAI原型 │ │ ║
║ │ │Checkpoint恢复 │ │幂等性(idemp key) │ │LangGraph生产 │ │ ║
║ │ │WAL日志思想 │ │优雅降级 │ │合规Agent一票否决 │ │ ║
║ │ └──────────────────┘ └───────────────────┘ └────────────────────────┘ │ ║
║ └──────────────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌──────────────────────────────────────────────────────────────────────────┐ ║
║ │ L3: RAG工程层 (Day 19, 20, 21) │ ║
║ │ ┌──────────────────┐ ┌───────────────────┐ ┌────────────────────────┐ │ ║
║ │ │文档解析与Chunking │ │检索与Reranking │ │评估与迭代 │ │ ║
║ │ │三层解析策略 │ │Query Rewriting │ │四维评估框架 │ │ ║
║ │ │Parent-Child │ │Hybrid Search │ │RAGAS / DeepEval │ │ ║
║ │ │Document-Structure│ │Cross-Encoder精排 │ │Golden QA Set 200+条 │ │ ║
║ │ │Quality Gate │ │RRF融合 │ │幻觉分类诊断 │ │ ║
║ │ └──────────────────┘ └───────────────────┘ └────────────────────────┘ │ ║
║ └──────────────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌──────────────────────────────────────────────────────────────────────────┐ ║
║ │ L2: 安全与合规层 (Day 17) │ ║
║ │ ┌──────────────────┐ ┌───────────────────┐ ┌────────────────────────┐ │ ║
║ │ │输入防护 │ │处理层控制 │ │输出过滤 │ │ ║
║ │ │Injection检测 │ │最小权限原则 │ │PII泄露检查 │ │ ║
║ │ │PII脱敏 │ │Tool白名单 │ │幻觉检测 │ │ ║
║ │ │LlamaGuard │ │上下文隔离 │ │合规审查 │ │ ║
║ │ │NeMo Guardrails │ │信息隔离墙 │ │高风险转人工 │ │ ║
║ │ └──────────────────┘ └───────────────────┘ └────────────────────────┘ │ ║
║ └──────────────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌──────────────────────────────────────────────────────────────────────────┐ ║
║ │ L1: 可观测性层 (Day 18) │ ║
║ │ ┌──────────────────┐ ┌───────────────────┐ ┌────────────────────────┐ │ ║
║ │ │基础设施监控 │ │请求链路Tracing │ │质量+业务指标 │ │ ║
║ │ │Prometheus/Grafana│ │LangFuse/LangSmith │ │LLM-as-Judge异步采样 │ │ ║
║ │ │CPU/内存/网络 │ │Span: I/O/Token/$ │ │成本归因/预算告警 │ │ ║
║ │ └──────────────────┘ └───────────────────┘ └────────────────────────┘ │ ║
║ └──────────────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌──────────────────────────────────────────────────────────────────────────┐ ║
║ │ L0: 应用架构层 (Day 16) │ ║
║ │ ┌──────────────────────────────────────────────────────────────────┐ │ ║
║ │ │ AI Gateway → 智能路由 → Prompt管理 → 模型层 → 响应处理 │ │ ║
║ │ │ (Portkey/LiteLLM) (复杂度分级) (版本控制) (多Provider) │ │ ║
║ │ └──────────────────────────────────────────────────────────────────┘ │ ║
║ └──────────────────────────────────────────────────────────────────────────┘ ║
╚══════════════════════════════════════════════════════════════════════════════════╝
能力树的阅读方式
| 层级 | 核心问题 | PM/架构师的决策点 |
|---|---|---|
| L0 应用架构 | LLM应用的骨架怎么搭 | Gateway选型、路由策略、Provider策略 |
| L1 可观测性 | 怎么知道系统在正常运行 | 监控工具选型、Trace粒度、告警阈值 |
| L2 安全合规 | 怎么防住攻击和合规风险 | Guardrails层级、权限边界、审计需求 |
| L3 RAG工程 | 怎么让检索和生成高质量 | Chunking策略、Rerank方案、评估基线 |
| L4 Agent工程 | 怎么让Agent可靠运行 | 状态管理方案、错误恢复、多Agent取舍 |
| L5 成本编排 | 怎么花最少钱保持质量 | 模型路由比例、缓存TTL、Fallback链路 |
| L6 测试部署 | 怎么验证和安全发布 | 测试金字塔比例、灰度策略、回滚机制 |
| L7 企业落地 | 怎么从PoC到Production | 数据治理优先级、组织责任、ROI模型 |
关键架构决策总结 (Key Architecture Decision Summary)
第二阶段积累的所有架构决策，汇总为决策树
决策1: 模型选型策略
需要选模型?
├── 任务类型明确且固定 → 基于规则的路由
│ ├── 翻译/格式化/提取 → Haiku/GPT-4o-mini ($0.001/请求)
│ ├── 总结/写作/分析 → Sonnet/GPT-4o ($0.01/请求)
│ └── 推理/设计/复杂分析 → Opus/o3 ($0.10/请求)
│
├── 任务类型混合 → 级联路由 (Cascade)
│ └── 先试小模型 → 置信度低再升级 → 兼顾成本和质量
│
├── 金融/医疗高风险 → 基于质量的路由
│ └── 合规类请求必须走高质量模型，宁贵勿错
│
└── 大多数生产系统 → 混合策略
└── 成本+延迟+质量加权评分，按业务优先级调权重
决策2: RAG vs Fine-tuning vs Long Context
需要让模型用上"我的数据"?
├── 数据量大且频繁更新(知识库/文档) → RAG
│ ├── 优势: 实时更新、可溯源、成本低
│ ├── 劣势: 检索质量是瓶颈、延迟+100-500ms
│ └── 适用: 客服/问答/知识检索/金融报告
│
├── 需要改变模型行为/语气/格式 → Fine-tuning
│ ├── 优势: 推理时零额外延迟、一致性高
│ ├── 劣势: 训练成本、数据标注、知识截止
│ └── 适用: 品牌调性/专业术语/特定输出格式
│
├── 数据量小(<100页)且不常变 → Long Context直接塞
│ ├── 优势: 零工程成本、实施最快
│ ├── 劣势: Token成本高、性能随长度下降
│ └── 适用: 单次分析/原型验证/数据量有限
│
└── 复杂场景 → RAG + Fine-tuning组合
└── Fine-tune模型学会"银行味"，RAG注入实时知识
决策3: Agent架构设计
需要AI完成复杂任务?
├── 单步可完成(查询/生成/转换) → 不需要Agent，直接LLM调用
│
├── 多步但流程固定 → 确定性Pipeline(DAG)
│ └── 更可靠、更便宜、更易调试
│
├── 多步且需要自主决策 → 单Agent + Tool Use
│ ├── ReAct模式: 思考→行动→观察→循环
│ └── 加上: 步数上限 + Token预算 + 循环检测
│
├── 多专业领域 + 需要对抗性检查 → 多Agent
│ ├── 成本N倍、延迟叠加、调试O(N)
│ ├── CrewAI验证idea(1天) → LangGraph生产(1周)
│ └── 金融: 合规Agent一票否决 + 人工审批hardcoded
│
└── 不确定 → 先用最简单方案，遇到瓶颈再升级
└── Pipeline → 单Agent → 多Agent (渐进式复杂化)
决策4: 缓存策略设计
需要降低重复请求成本?
├── 完全相同的请求频繁出现 → 精确匹配缓存 (Redis)
│ └── FAQ/模板化查询，命中率10-30%
│
├── 意思相同但说法不同 → 语义缓存 (GPTCache)
│ └── 相似度阈值0.95+，命中率30-60%
│ └── 注意: 阈值太低会返回错误答案
│
├── System Prompt重复 → Prompt Cache (模型原生)
│ └── Anthropic/OpenAI原生支持，减40%输入Token费
│
└── TTL分级策略
├── FAQ/静态知识: 7天
├── 半动态信息: 24小时
├── 实时数据: 1小时或不缓存
└── 金融行情/价格: 不缓存(过时即错误)
决策5: 安全层级设计
需要多严格的安全?
├── 面向公众 + 高风险(AI客服/投资建议)
│ ├── 全套三层Guardrails
│ ├── 输出必经合规审查
│ ├── 高风险自动转人工
│ └── 接受200ms+额外延迟(安全代价远低于事故代价)
│
├── 面向内部 + 中风险(运营工具/数据分析)
│ ├── 输入层PII脱敏
│ ├── 输出层基础过滤
│ └── 审计日志保留
│
├── 面向内部 + 低风险(代码辅助/文档总结)
│ ├── 轻量级输入过滤
│ └── 基础日志
│
└── 安全评估指标
├── ASR(攻击成功率) < 2% — 衡量安全性
├── FPR(误拦率) < 1% — 衡量体验
└── 两者需平衡，过度拟合攻击模式会伤害正常用户
面试高频题汇总 (Complete Interview Question Index: Day 16-29)
第二阶段积累的所有面试题，按主题分类整理
应用架构类
| # | 面试题 | 来源 | 核心答题要点 |
|---|---|---|---|
| 1 | 如何设计一个生产级LLM应用的架构？ | Day 16 | 六层架构：Gateway→路由→缓存→Prompt→模型→可观测性 |
| 2 | LLM系统如何做成本控制？ | Day 16 | "四把刀"：路由/缓存/压缩/预算，可降70%+ |
| 3 | 如何为LLM应用设计可观测性方案？ | Day 18 | 四层：基础设施/请求链路/质量评估/业务指标 |
| 4 | LLM应用的质量如何持续监控？ | Day 18 | 三层防线：实时检测/异步评估/回归测试 + Feedback Loop |
| 5 | 如何控制LLM应用的成本？ | Day 18 | 成本归因到功能和用户维度，设预算告警和异常检测 |
安全类
| # | 面试题 | 来源 | 核心答题要点 |
|---|---|---|---|
| 6 | 如何设计生产级LLM应用的安全架构？ | Day 17 | 纵深防御三层Guardrails + Red Teaming持续测试 |
| 7 | Prompt Injection能100%防住吗？ | Day 17 | 不能，假设输入层被突破，处理层权限控制+输出层把关 |
| 8 | 安全层增加延迟和成本怎么trade-off？ | Day 17 | 按场景分级：高风险全套/低风险轻量，异步Guard不阻塞 |
| 9 | 如何评估Guardrails的效果？ | Day 17 | ASR(攻击成功率)<2% + FPR(误拦率)<1%，需平衡 |
RAG工程类
| # | 面试题 | 来源 | 核心答题要点 |
|---|---|---|---|
| 10 | 如何设计生产级RAG的数据处理Pipeline？ | Day 19 | 三层解析+Chunking策略AB实验+每阶段Quality Gate |
| 11 | Chunking策略怎么选？ | Day 19 | 看文档类型+查询模式，无万能参数，必须实验验证 |
| 12 | RAG检索效果怎么优化的？ | Day 20 | 四阶段：Query理解→多路召回→Reranking→Context组装 |
| 13 | 为什么需要Reranker？更好的Embedding不行吗？ | Day 20 | Bi-Encoder有信息损失，Cross-Encoder做深度交叉注意力 |
| 14 | 如何评估RAG系统的质量？ | Day 21 | 四维框架：Precision/Recall/Faithfulness/Relevancy |
| 15 | RAG系统出现幻觉如何解决？ | Day 21 | 分类诊断(事实/忠实/推理) → 对症下药(Prompt/NLI/拒答) |
Agent工程类
| # | 面试题 | 来源 | 核心答题要点 |
|---|---|---|---|
| 16 | Agent在生产环境如何保证可靠性？ | Day 22 | 四层：状态管理→错误分级→幂等性→优雅降级 |
| 17 | 如何设计Agent的错误恢复机制？ | Day 22 | 区分瞬态/永久/未知错误，指数退避+回退+人工升级 |
| 18 | 如何设计Agent系统的成本控制方案？ | Day 23 | 成本建模→多层优化→预算控制→监控迭代 |
| 19 | Agent延迟瓶颈在哪？如何优化？ | Day 23 | 80%来自LLM调用，四板斧：减次数/加速/隐藏/减工具延迟 |
| 20 | 什么时候用多Agent？主要风险？ | Day 24 | 多专业/对抗性/可并行才用；风险：成本N倍/错误传播/调试难 |
| 21 | 金融合规多Agent如何保证审计可追溯？ | Day 24 | reasoning字段/通信持久化/合规一票否决/人工节点hardcoded |
| 22 | CrewAI vs LangGraph选型？ | Day 24 | CrewAI快速原型(1天)，LangGraph生产级(1周) |
测试与部署类
| # | 面试题 | 来源 | 核心答题要点 |
|---|---|---|---|
| 23 | 如何测试非确定性的LLM Agent？ | Day 25 | 四层金字塔：assert/Judge/统计/Golden Set |
| 24 | 如何设计Agent的灰度发布策略？ | Day 25 | Shadow→Canary(1%→100%)→Full，自动回滚 |
| 25 | Agent CI/CD和传统应用有什么不同？ | Day 25 | 5差异：构建物/Eval阶段/质量Gate/版本锁定/大样本AB |
| 26 | LLM应用测试的核心挑战？ | Day 28 | 非确定性，Eval-Driven Development替代TDD |
| 27 | Golden Set多大合适？ | Day 28 | 初期50-100条，成熟后300-500条，每月审核 |
| 28 | 如何测试幻觉？ | Day 28 | Faithfulness Metric + 事实核查 + LLM-Judge+人工 |
成本与编排类
| # | 面试题 | 来源 | 核心答题要点 |
|---|---|---|---|
| 29 | 怎么判断请求该路由到哪个模型？ | Day 26 | 三种：规则/ML分类器/级联，金融推荐级联+规则混合 |
| 30 | 缓存会不会导致回答过时？ | Day 26 | TTL分级：FAQ长(7天)/实时数据短(1h)/行情不缓存 |
| 31 | 多模型编排有哪些模式？ | Day 27 | 四种：Primary-Secondary/Capability/Cascade/LB |
| 32 | Anthropic和OpenAI同时宕机怎么办？ | Day 27 | 3层Fallback+非AI降级方案(规则引擎/预置模板) |
| 33 | 不同模型输出不一致怎么办？ | Day 27 | JSON Schema强约束+后处理标准化+独立Prompt版本 |
企业落地类
| # | 面试题 | 来源 | 核心答题要点 |
|---|---|---|---|
| 34 | 描述一个AI/LLM从PoC到Production的关键阶段？ | Day 29 | STAR-T：PoC(2周)→工程化(4周)→上线迭代(4周) |
| 35 | 企业LLM项目最容易被忽视但最重要的环节？ | Day 29 | 数据治理——预算30%投入/建Owner制度/启动先做数据审计 |
面试速查表：30秒回答公式
通用结构: "这个问题我会从[N]个层面来回答..."
架构类: "分[N]层设计..." + 金融类比 + 数字佐证
安全类: "纵深防御..." + 假设被突破 + 降级方案
RAG类: "四阶段Pipeline..." + 具体指标提升
Agent类: "四层可靠性..." + 银行WAL类比
成本类: "四把刀..." + 具体节省比例
测试类: "非确定性核心挑战..." + Eval-Driven
落地类: "PoC≠Production..." + 数据治理优先
第三阶段预告：金融零售AI应用 (Day 31-42 Preview)
为什么第三阶段至关重要
Day 1-15: 理解LLM技术原理 (What & How)
Day 16-30: 掌握工程化方法论 (How to build reliably)
Day 31-42: 在金融零售场景落地 (Where & Why — 行业价值)
↑
这才是10年金融零售经验的差异化体现
"会搭LLM系统"的工程师很多
"能在金融零售场景中设计AI产品"的PM/架构师稀缺
Day 31-42 规划
第三阶段：金融零售AI应用 (Day 31-42)
│
├── 金融AI深度 (Day 31-35)
│ ├── Day 31: 智能风控 — ML风控模型 + LLM增强(特征解释/规则生成)
│ ├── Day 32: 智能投顾 — 个性化投资建议 + 合规约束 + 幻觉零容忍
│ ├── Day 33: 智能合规 — 监管科技(RegTech) + 自动化合规检查
│ ├── Day 34: 反欺诈 — 实时交易监控 + 异常检测 + 调查辅助
│ └── Day 35: 金融AI综合 — KYC/AML/信用评估/文档处理
│
├── 零售AI深度 (Day 36-40)
│ ├── Day 36: 推荐系统 — 协同过滤 + LLM增强(解释性/冷启动)
│ ├── Day 37: 智能客服 — 全渠道客服 + 意图识别 + 个性化
│ ├── Day 38: 供应链预测 — 需求预测 + 库存优化 + LLM辅助决策
│ ├── Day 39: 智能营销 — 用户分群 + 内容生成 + ROI预测
│ └── Day 40: 零售AI综合 — 定价/搜索/视觉/直播
│
└── 融合架构 (Day 41-42)
├── Day 41: CeFi x DeFi x AI — 传统金融+区块链+AI的融合架构
└── Day 42: 第三阶段总结
预习问题
进入金融AI前，思考这些问题:
1. 金融场景对AI的核心约束是什么？
→ 合规(监管审批)/可解释性(为什么拒贷)/准确性(零容忍幻觉)/审计(可追溯)
2. 风控模型为什么还在用XGBoost而不是LLM？
→ 可解释性/延迟/稳定性/监管要求 — LLM是增强不是替代
3. 你的10年金融经验如何和AI能力结合？
→ 理解业务约束 + 判断AI能在哪里增值 + 知道哪些红线不能踩
4. Web3场景有什么特殊的AI应用机会？
→ 链上数据分析/智能合约审计/DeFi风控/DAO治理辅助
今日思考 (Today's Reflections)
思考1: 工程化的本质是"为失败做准备"
第一阶段在学"怎么让AI做对"，第二阶段核心在学"AI做错了怎么办"。Guardrails假设输入层被突破，Fallback假设主模型宕机，幂等性假设操作会重复，灰度发布假设新版本可能更差。好的工程架构不是让系统不出错，而是让系统出错时还能可靠地工作。这和银行风控的核心理念完全一致——不是消除风险，而是管理风险。
思考2: 数据治理是最大的"隐性技术债"
Day 29企业案例最深的教训：RAG效果60%取决于数据质量，但数据治理是最容易被忽略的环节——不性感、不可见、不紧急、不技术。在金融领域10年，这个感受更深刻——核心系统最大的痛点不是代码写得不好，而是数据不干净。AI时代的"GIGO"(Garbage In, Garbage Out)比传统软件更严重，因为AI会自信地把Garbage包装成看似合理的答案。
思考3: 从"技术选型"到"业务价值"的思维转变
第二阶段最大的认知升级：停止追求"技术上最先进"的方案，开始追求"业务上最合适"的方案。不是所有问题都需要Agent(Pipeline可能更好)，不是所有查询都需要Opus(Haiku处理60%请求)，不是所有RAG都需要Reranker(简单场景Embedding就够)。架构师的核心能力不是知道所有技术，而是在约束条件下做出最优取舍。
面试表达
问题: "总结第二阶段你学到的最重要的3件事"
30秒版本:
第一，Production不是PoC的放大版——从Demo到生产需要完整的工程基础设施：Gateway、安全、监控、缓存、评估、部署。模型能力只占20%。第二，每一层设计都要"假设失败"——纵深防御、多层Fallback、幂等性、灰度发布——好的架构不是不出错，是出错时还能工作。第三，最被忽略的环节决定成败——数据治理决定RAG效果的60%，但预算投入往往不到10%。
2分钟版本:
作为有10年金融零售经验的人，第二阶段最大的收获是发现LLM工程和金融核心系统建设的方法论高度同构。
首先是分层架构思想。LLM的六层架构(Gateway→路由→缓存→Prompt→模型→监控)和银行核心系统的中间件架构完全对应——适配器模式统一接口、断路器做Fallback、分层缓存降成本、全链路追踪保合规。这意味着传统架构经验可以直接迁移。
其次是为失败做设计。安全层假设每层都会被突破(纵深防御)，模型层假设Provider会宕机(3层Fallback+非AI降级)，Agent假设操作会重复(幂等性)，部署假设新版本可能更差(Shadow+Canary)。这和银行风控的核心理念一致——管理风险而非消除风险。
最后是业务价值导向。我学会了停止追求技术上最先进的方案。智能路由让60%请求用便宜模型处理，成本降91%的同时延迟反而更低——成本优化和质量保障不矛盾。Pipeline能解决的问题不用Agent，规则引擎能处理的不用LLM。架构师的价值在于约束条件下的最优取舍。
进入第三阶段，我准备把这套工程方法论和金融零售行业经验真正融合——这是我的差异化竞争力所在。
第二阶段学习成果总结
╔══════════════════════════════════════════════════════════════════════╗
║ Phase 2 成果卡 (Day 16-30) ║
╠══════════════════════════════════════════════════════════════════════╣
║ ║
║ 覆盖主题: 8大工程领域 ║
║ ├── 应用架构 (Gateway/路由/缓存/Prompt管理) ║
║ ├── 安全与合规 (三层Guardrails/OWASP LLM Top 10) ║
║ ├── 可观测性 (四层监控/LangFuse/成本归因) ║
║ ├── RAG工程 (解析/Chunking/检索/Rerank/评估三部曲) ║
║ ├── Agent工程 (状态/错误/成本/多Agent/测试部署四部曲) ║
║ ├── 成本工程 (路由/缓存/压缩/预算四把刀) ║
║ ├── 多模型编排 (Fallback/熔断器/A-B测试) ║
║ └── 企业落地 (PoC→Prod/数据治理/组织协同) ║
║ ║
║ 面试题积累: 35+道 (本阶段新增) ║
║ ├── 架构类: 5道 ║
║ ├── 安全类: 4道 ║
║ ├── RAG类: 6道 ║
║ ├── Agent类: 7道 ║
║ ├── 测试部署类: 6道 ║
║ ├── 成本编排类: 5道 ║
║ └── 企业落地类: 2道 ║
║ ║
║ 架构决策框架: 5大决策树 ║
║ ├── 模型选型策略 (规则/级联/质量/混合) ║
║ ├── RAG vs FT vs Long Context ║
║ ├── Agent架构选择 (Pipeline→单Agent→多Agent) ║
║ ├── 缓存策略设计 (精确/语义/Prompt + TTL分级) ║
║ └── 安全层级设计 (高/中/低风险分级) ║
║ ║
║ 核心工具链: ║
║ ├── Gateway: LiteLLM / Portkey / Cloudflare AI Gateway ║
║ ├── 监控: LangFuse / LangSmith / Helicone ║
║ ├── 安全: NeMo Guardrails / LlamaGuard / Garak ║
║ ├── RAG: RAGAS / DeepEval / Unstructured.io ║
║ ├── Agent: LangGraph / CrewAI / AutoGen ║
║ ├── 测试: Promptfoo / DeepEval / Braintrust ║
║ └── 缓存: GPTCache / Redis / Prompt Cache(原生) ║
║ ║
║ 与金融经验的连接点: ║
║ ├── Gateway = 银行统一接入网关 ║
║ ├── 纵深防御 = 金融风控多层防线 ║
║ ├── 幂等性 = 交易流水号防重扣 ║
║ ├── 状态持久化 = WAL日志 ║
║ ├── Fallback = 灾备切换 ║
║ ├── 灰度发布 = 金融产品试点运营 ║
║ └── 数据治理 = 核心系统数据质量管理 ║
║ ║
║ 下一阶段: Day 31-42 金融零售AI应用 ║
║ → 把工程方法论 × 行业经验 = 差异化竞争力 ║
╚══════════════════════════════════════════════════════════════════════╝
学习资源回顾 (Phase 2 Key Resources)
| 资源 | 类型 | 覆盖主题 |
|---|---|---|
| What We Learned from a Year of Building with LLMs | 博客 | 生产级LLM全面实战总结(必读) |
| LLM Patterns — Eugene Yan | 博客 | LLM系统设计模式 |
| Emerging Architectures — a16z | 报告 | LLM应用架构综述 |
| OWASP LLM Top 10 | 标准 | LLM安全威胁权威分类 |
| Hamel Husain: Evals | 博客 | Eval-Driven Development最佳实践 |
| LiteLLM | 工具 | 多模型统一接入 |
| LangFuse | 工具 | LLM可观测性 |
| Promptfoo | 工具 | LLM评估框架 |
| RAGAS | 工具 | RAG评估框架 |
第二阶段完成。15天从"理解概念"升级到"工程实战"，积累了完整的LLM生产系统方法论。进入第三阶段，真正把10年金融零售经验和AI工程能力融合为差异化竞争力。