AI Day 15
AI Day 15: 第一阶段复习与架构总结 — 从概念到全景的知识地图
第一阶段不是14个孤立知识点的堆砌，而是一个完整技术栈的分层构建过程——从硬件和模型基底(Day 1-3)，到知识注入和行为控制(Day 4-7)，到性能工程(Day 8-9)，到能力扩展(Day 10-11)，到系统协作(Day 12-13)，最后到质量保障(Day 14)。今天的任务是把这些碎片拼成一张可在面试中1分钟讲清的全景图。
2026-04-16
PhaseKnowledge技术栈全景Decision面试汇总Phase
日期：2026-04-16
阶段：第一阶段 — AI/LLM技术深潜 (Day 1-15)
标签：Phase Review Knowledge Map 技术栈全景 Decision Framework 面试汇总 Phase 2 Preview
学习路径树
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-20: LLM应用架构设计（微服务/网关/缓存/监控）
│ ├── Day 21-25: 生产级RAG系统（Chunking/Rerank/评估/迭代）
│ └── Day 26-30: Agent系统工程化（状态管理/错误恢复/成本控制）
│
├── 第三阶段：金融零售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: 总结与作品集
核心概念
一句话定义
第一阶段不是14个孤立知识点的堆砌，而是一个完整技术栈的分层构建过程——从硬件和模型基底(Day 1-3)，到知识注入和行为控制(Day 4-7)，到性能工程(Day 8-9)，到能力扩展(Day 10-11)，到系统协作(Day 12-13)，最后到质量保障(Day 14)。今天的任务是把这些碎片拼成一张可在面试中1分钟讲清的全景图。
回顾方法论
这次复习不是简单"重读笔记"，而是三层递进：
Layer 1 — 垂直贯通：把14天的知识排成完整技术栈
→ 每一层解决什么问题？上下层怎么衔接？
Layer 2 — 水平关联：找出跨天的概念连接
→ RAG和Long Context在竞争什么？
→ Agent和Reasoning各自需要什么底层能力？
Layer 3 — 决策框架：从"理解概念"升级到"技术选型"
→ 面对真实需求，我能做出有理有据的架构决策吗？
为什么PM/架构师需要这个全景图
| 场景 | 需要全景图的原因 |
|---|---|
| 面试系统设计 | 需要在白板上从底到顶勾勒LLM应用架构 |
| 技术评审 | 判断团队提案是否在正确的层次解决问题 |
| 产品规划 | 根据技术成熟度设定产品路线图 |
| 成本估算 | 训练/推理/存储各层的成本模型完全不同 |
| 供应商选型 | OpenAI/Anthropic/开源的真正差异在哪一层 |
| 风险评估 | Hallucination/安全/延迟风险分别在哪一层处理 |
知识点1: LLM技术栈全景图
14天知识组装成一张从底到顶的完整地图
1.1 LLM技术栈分层架构
╔══════════════════════════════════════════════════════════════════════════╗
║ LLM 技术栈全景图 (Day 1-14 知识地图) ║
╠══════════════════════════════════════════════════════════════════════════╣
║ ║
║ ┌─────────────────────────────────────────────────────────────────┐ ║
║ │ Layer 7: 质量保障层 (Day 14) │ ║
║ │ ┌──────────┐ ┌───────────┐ ┌──────────┐ ┌───────────────────┐│ ║
║ │ │Benchmark │ │LLM Arena │ │Red Team │ │Safety Evaluation ││ ║
║ │ │MMLU/GPQA │ │Elo Rating │ │对抗测试 │ │合规/偏见/幻觉检测 ││ ║
║ │ └──────────┘ └───────────┘ └──────────┘ └───────────────────┘│ ║
║ └─────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌─────────────────────────────────────────────────────────────────┐ ║
║ │ Layer 6: 系统协作层 (Day 12-13) │ ║
║ │ ┌────────────┐ ┌──────────┐ ┌─────────┐ ┌──────────────────┐│ ║
║ │ │Agent框架 │ │Tool Use │ │MCP协议 │ │Multi-Agent系统 ││ ║
║ │ │ReAct/Plan │ │Function │ │JSON-RPC │ │A2A/Orchestrator ││ ║
║ │ │LangGraph │ │Calling │ │标准化接口│ │CrewAI/AutoGen ││ ║
║ │ └────────────┘ └──────────┘ └─────────┘ └──────────────────┘│ ║
║ └─────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌─────────────────────────────────────────────────────────────────┐ ║
║ │ Layer 5: 能力扩展层 (Day 10-11) │ ║
║ │ ┌────────────────────┐ ┌──────────────────────────────────┐ │ ║
║ │ │多模态 VLM │ │Reasoning 推理增强 │ │ ║
║ │ │Vision Encoder+LLM │ │CoT / o1 / R1 / Extended Thinking│ │ ║
║ │ │图像/视频/音频理解 │ │Test-Time Compute / PRM / ORM │ │ ║
║ │ └────────────────────┘ └──────────────────────────────────┘ │ ║
║ └─────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌─────────────────────────────────────────────────────────────────┐ ║
║ │ Layer 4: 性能工程层 (Day 2, 8-9) │ ║
║ │ ┌────────────┐ ┌──────────────┐ ┌──────────────────────────┐│ ║
║ │ │模型量化 │ │推理优化 │ │长上下文 ││ ║
║ │ │GPTQ/AWQ │ │vLLM/TRT-LLM │ │RoPE Scaling ││ ║
║ │ │GGUF/EXL2 │ │PagedAttention │ │Ring/Flash Attention ││ ║
║ │ │INT4→8GB跑 │ │Continuous │ │KV Cache压缩 ││ ║
║ │ │7B/14B模型 │ │Batching │ │1M+ Token窗口 ││ ║
║ │ └────────────┘ └──────────────┘ └──────────────────────────┘│ ║
║ └─────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌─────────────────────────────────────────────────────────────────┐ ║
║ │ Layer 3: 知识注入与行为控制层 (Day 4-7) │ ║
║ │ ┌──────────┐ ┌──────────┐ ┌───────────┐ ┌──────────────────┐│ ║
║ │ │Prompt │ │RAG │ │VectorDB & │ │Fine-tuning ││ ║
║ │ │Engineer- │ │检索增强 │ │Embedding │ │LoRA/QLoRA ││ ║
║ │ │ing / ICL │ │生成 │ │HNSW/IVF │ │Adapter方法 ││ ║
║ │ │Zero/Few │ │Query→ │ │Pinecone/ │ │领域适配 ││ ║
║ │ │Shot/CoT │ │Retrieve→ │ │Weaviate/ │ │<1%参数更新 ││ ║
║ │ │ │ │Generate │ │Qdrant │ │ ││ ║
║ │ └──────────┘ └──────────┘ └───────────┘ └──────────────────┘│ ║
║ └─────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌─────────────────────────────────────────────────────────────────┐ ║
║ │ Layer 2: 模型训练层 (Day 3) │ ║
║ │ ┌────────────┐ ┌──────────────┐ ┌────────────────────────┐│ ║
║ │ │Pre-training│ │SFT │ │Alignment ││ ║
║ │ │万亿Token │ │指令微调 │ │RLHF / DPO / GRPO ││ ║
║ │ │Next Token │ │对话格式 │ │人类偏好对齐 ││ ║
║ │ │Prediction │ │几万条高质数据 │ │Constitutional AI ││ ║
║ │ │Scaling Laws│ │ │ │ ││ ║
║ │ └────────────┘ └──────────────┘ └────────────────────────┘│ ║
║ └─────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌─────────────────────────────────────────────────────────────────┐ ║
║ │ Layer 1: 模型架构层 (Day 1) │ ║
║ │ ┌────────────────────────────────────────────────────────────┐│ ║
║ │ │ Transformer (Decoder-Only) ││ ║
║ │ │ Self-Attention → Multi-Head → FFN → 残差连接 → LayerNorm ││ ║
║ │ │ 位置编码: RoPE 注意力优化: GQA/MLA 架构: Dense/MoE ││ ║
║ │ │ Tokenizer: BPE/SentencePiece KV Cache: 推理核心瓶颈 ││ ║
║ │ └────────────────────────────────────────────────────────────┘│ ║
║ └─────────────────────────────────────────────────────────────────┘ ║
║ ▲ ║
║ ┌─────────────────────────────────────────────────────────────────┐ ║
║ │ Layer 0: 硬件基础层 │ ║
║ │ GPU (NVIDIA A100/H100/H200) | TPU | 推理芯片 (Groq) │ ║
║ │ HBM显存 (决定模型大小上限) | NVLink (多卡通信) │ ║
║ └─────────────────────────────────────────────────────────────────┘ ║
╚══════════════════════════════════════════════════════════════════════════╝
1.2 各层的核心问题与PM决策点
| 层级 | 核心问题 | PM/架构师决策 |
|---|---|---|
| L0 硬件 | 多少GPU、什么型号 | 预算和部署方式（云API vs 自建GPU集群） |
| L1 架构 | Dense还是MoE、多大模型 | 模型选型的基础：参数量→能力→成本 |
| L2 训练 | 怎么炼出好模型 | 评估开源模型的训练质量，判断是否需要SFT |
| L3 知识注入 | 怎么让模型用上我的数据 | RAG vs Fine-tuning vs Long Context的选择 |
| L4 性能 | 怎么又快又便宜 | 延迟SLA、并发量、成本预算三角平衡 |
| L5 能力扩展 | 怎么处理图片/复杂推理 | 是否需要多模态？推理问题是否值得额外Token开销？ |
| L6 系统协作 | 怎么让AI完成复杂任务 | Agent的自主性边界、工具权限、失败回退策略 |
| L7 质量保障 | 怎么知道效果好不好 | 评估指标选择、上线标准、持续监控方案 |
1.3 数据流视角：一次用户请求如何穿透技术栈
用户提问: "分析这份PDF年报中的风险因素"
│
▼
┌─ Layer 6 ─ Agent判断需要多步操作 ─────────────────────────┐
│ Planning: 1.解析PDF 2.提取风险章节 3.分析总结 │
│ Tool Selection: PDF解析工具 + 检索工具 │
└────────────┬──────────────────────────────────────────────┘
▼
┌─ Layer 5 ─ 多模态处理 ──────────────────────────────────┐
│ Vision Encoder处理PDF中的图表 │
│ OCR提取表格数据 │
└────────────┬────────────────────────────────────────────┘
▼
┌─ Layer 3 ─ RAG检索 + Prompt构造 ────────────────────────┐
│ Embedding模型将PDF切片向量化 │
│ VectorDB检索最相关的风险段落 │
│ Prompt模板注入检索结果 + 用户问题 │
└────────────┬────────────────────────────────────────────┘
▼
┌─ Layer 4 ─ 推理执行 ────────────────────────────────────┐
│ vLLM / TRT-LLM 高效推理 │
│ KV Cache管理长上下文 │
│ Continuous Batching并发处理 │
└────────────┬────────────────────────────────────────────┘
▼
┌─ Layer 1+2 ─ 模型推理（前向传播） ──────────────────────┐
│ Transformer Decoder逐Token生成 │
│ Self-Attention计算 → FFN → Softmax → 采样 │
│ 训练阶段学到的知识在权重中被激活 │
└────────────┬────────────────────────────────────────────┘
▼
┌─ Layer 7 ─ 质量检查 ────────────────────────────────────┐
│ Hallucination Detection: 检查引用是否准确 │
│ Safety Filter: 确保输出合规 │
│ Evaluation Metrics: 记录本次请求的质量分数 │
└────────────┬────────────────────────────────────────────┘
▼
返回给用户结构化的风险分析报告
知识点2: 14天知识回顾
2.1 每日一句话总结 + 核心收获
| Day | 主题 | 一句话总结 | 核心收获 |
|---|---|---|---|
| 1 | Transformer架构 | Transformer是LLM的引擎，Self-Attention让每个Token关注全局 | QKV计算、MoE vs Dense、Scaling Laws、KV Cache是性能瓶颈 |
| 2 | 量化与本地部署 | 量化让7B模型跑在8GB显卡上，精度损失可控 | GPTQ/AWQ/GGUF选择、Ollama实操、INT4是成本效率甜点 |
| 3 | 训练全流程 | Pre-training建知识，SFT教格式，RLHF/DPO对齐人类偏好 | 三阶段成本差3个数量级、DPO/GRPO替代复杂RL、数据质量>数量 |
| 4 | Prompt Engineering | 不改权重，只改输入，就能极大提升输出质量 | Zero/Few-Shot/CoT技术、System Prompt设计、ICL的本质 |
| 5 | RAG架构 | 先查资料再回答，解决幻觉和知识时效性问题 | 全链路: Index→Retrieve→Generate、Naive→Advanced→Agentic RAG |
| 6 | VectorDB & Embedding | 语义搜索的底层基础设施 | HNSW/IVF算法、Embedding模型选型、MTEB排行榜 |
| 7 | Fine-tuning / LoRA | 用不到1%的参数更新实现领域适配 | LoRA/QLoRA原理、何时Fine-tune vs RAG、灾难性遗忘风险 |
| 8 | 推理优化 | 同样GPU服务更多用户，每个用户等更短时间 | PagedAttention、Continuous Batching、Speculative Decoding |
| 9 | 长上下文技术 | 让Transformer处理百万Token级别的输入 | RoPE扩展、Ring Attention、KV Cache压缩、Long Context vs RAG |
| 10 | 多模态VLM | AI同时理解文本、图像和视频 | VLM = Vision Encoder + Projection + LLM、跨模态对齐 |
| 11 | Reasoning模型 | AI学会"深度思考"，用更多推理时间换更高准确度 | CoT/o1/R1/Extended Thinking、Test-Time Compute、PRM/ORM |
| 12 | Agent框架 | 让AI不只聊天，而是自主执行多步任务 | ReAct循环、Tool Use、Planning策略、Multi-Agent架构 |
| 13 | MCP协议 | AI的"USB标准"，标准化工具连接 | JSON-RPC协议、Server/Client架构、A2A互操作、OAuth 2.1 |
| 14 | 模型评估 | 衡量模型好不好的科学方法 | Benchmark体系、LLM Arena、Red Teaming、安全评估框架 |
2.2 掌握度自评
掌握度评级标准：
★☆☆☆☆ = 知道概念名词，但说不清原理
★★☆☆☆ = 能解释原理，但无法做技术决策
★★★☆☆ = 能解释 + 能做选型决策 + 能画架构图
★★★★☆ = 能讲清trade-off + 能在面试中深入讨论
★★★★★ = 能设计方案 + 能挑战他人方案 + 有实操经验
| Day | 主题 | 掌握度 | 自评说明 |
|---|---|---|---|
| 1 | Transformer架构 | ★★★★☆ | QKV/MHA/FFN能清晰解释，MoE细节还需加深 |
| 2 | 量化与本地部署 | ★★★★★ | 有Ollama实操经验，量化选型决策清晰 |
| 3 | 训练全流程 | ★★★☆☆ | 三阶段逻辑清楚，GRPO数学细节待加深 |
| 4 | Prompt Engineering | ★★★★☆ | 日常大量使用，系统方法论已建立 |
| 5 | RAG架构 | ★★★★☆ | 全链路理解透彻，Advanced RAG策略掌握好 |
| 6 | VectorDB & Embedding | ★★★☆☆ | 选型框架清晰，ANN算法数学细节偏弱 |
| 7 | Fine-tuning / LoRA | ★★★☆☆ | 原理和选型清楚，缺少真实LoRA训练经验 |
| 8 | 推理优化 | ★★★★☆ | PagedAttention原理深入，Speculative Decoding理解到位 |
| 9 | 长上下文 | ★★★☆☆ | RoPE扩展理解好，Ring Attention工程细节偏弱 |
| 10 | 多模态VLM | ★★★☆☆ | 架构理解清楚，缺少多模态应用实操 |
| 11 | Reasoning模型 | ★★★★☆ | o1/R1/Extended Thinking差异能讲清，PRM深度足够 |
| 12 | Agent框架 | ★★★★☆ | ReAct/Planning/Multi-Agent框架对比熟练 |
| 13 | MCP协议 | ★★★★☆ | 协议细节掌握好，有Claude Code实操经验 |
| 14 | 模型评估 | ★★★☆☆ | Benchmark体系了解，实际评估经验不足 |
2.3 知识密度分布
按知识密度和难度，14天可分为四个梯队：
梯队1 — 基石层（必须烂熟于心）:
Day 1 Transformer ████████████████████ 高密度高频考点
Day 3 训练流程 ████████████████████ 面试必问
Day 5 RAG ████████████████████ 最常见应用架构
梯队2 — 核心技能（面试中等频率）:
Day 4 Prompt Eng ████████████████ 日常工作核心
Day 7 Fine-tuning ████████████████ RAG vs FT是经典面试题
Day 8 推理优化 ████████████████ 生产部署必知
Day 12 Agent ████████████████ 2025-2026热门方向
梯队3 — 进阶知识（体现深度）:
Day 6 VectorDB ████████████ 支撑RAG的基础设施
Day 9 长上下文 ████████████ 正在改变RAG的必要性
Day 11 Reasoning ████████████ 前沿方向，快速演进中
梯队4 — 广度知识（加分项）:
Day 2 量化部署 ████████ 本地/边缘场景
Day 10 多模态 ████████ 特定应用场景
Day 13 MCP ████████ 新兴标准，快速普及
Day 14 评估 ████████ 上线前最后一关
知识点3: 关键概念关联图
14天的知识不是14个独立模块，而是一张彼此交织的网络
3.1 概念关联全景
┌─────────────────────────────────────────────────────────────────────┐
│ LLM 概念关联图 │
│ │
│ ┌──────────┐ 训练出 ┌──────────┐ │
│ │Pre-train │ ─────────────────────→ │Base Model│ │
│ │RLHF/DPO │ Scaling Laws指导 │Transformer│ │
│ └────┬─────┘ └─────┬────┘ │
│ │ │ │
│ SFT数据质量 模型推理时 │
│ 决定对话能力 │ │
│ │ ┌───────────────────────────┼──────────┐ │
│ ▼ ▼ ▼ ▼ │
│ ┌─────────┐ ┌────────┐ ┌─────────┐ ┌──────┐ ┌────────┐ │
│ │Prompt │ │RAG │ │Fine-tune│ │量化 │ │推理优化│ │
│ │Engineer │ │检索增强 │ │LoRA │ │GPTQ │ │vLLM │ │
│ └────┬────┘ └───┬────┘ └────┬────┘ │AWQ │ │Paged │ │
│ │ │ │ │GGUF │ │Attn │ │
│ ICL利用 │ 权重更新 └──┬───┘ └───┬────┘ │
│ 上下文窗口 ┌───┴───┐ 改变行为 │ │ │
│ │ │ │ │ 降低显存 提高吞吐 │
│ │ ┌────┴──┐ ┌──┴────┐ │ 需求 量 │
│ │ │Vector │ │Embed- │ │ │ │ │
│ │ │DB │ │ding │ │ ▼ ▼ │
│ │ │HNSW │ │Model │ │ ┌──────────────────┐ │
│ │ └───────┘ └───────┘ │ │ 部署环境 │ │
│ │ │ │ 云API / 本地 │ │
│ ▼ ▼ │ / 边缘 │ │
│ ┌──────────────────────────────┐ └──────────────────┘ │
│ │ 长上下文 (Day 9) │ │
│ │ RoPE Scaling让窗口扩大 │ │
│ │ 正在"侵蚀"RAG的部分场景 │ │
│ └──────────┬───────────────────┘ │
│ │ │
│ 支撑更复杂的 │
│ Agent任务 │
│ │ │
│ ┌──────────▼─────────────┐ ┌────────────────────┐ │
│ │ Agent (Day 12) │ │ Reasoning (Day 11) │ │
│ │ ReAct / Planning │◄────►│ CoT / o1 / R1 │ │
│ │ Tool Use │ 推理 │ Extended Thinking │ │
│ │ Multi-Agent │ 增强 │ Test-Time Compute │ │
│ └──────────┬─────────────┘ └────────────────────┘ │
│ │ │
│ 标准化连接 │
│ │ │
│ ┌──────────▼─────────────┐ ┌────────────────────┐ │
│ │ MCP (Day 13) │ │ 多模态 (Day 10) │ │
│ │ JSON-RPC标准 │ │ Vision-Language │ │
│ │ Tool Server/Client │◄────►│ 图像/视频理解 │ │
│ │ A2A互操作 │ 多模态│ 扩展Agent感知能力 │ │
│ └────────────────────────┘ Tool └────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────┐ │
│ │ 评估 (Day 14) │ │
│ │ 贯穿所有层的质量保障 │ │
│ │ Benchmark/Arena/ │ │
│ │ Red Team/Safety │ │
│ └────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
3.2 四条核心关联链
关联链1: Transformer → Training → Inference (模型生命周期)
Transformer架构(Day 1)
→ 定义了模型的"硬件规格"：参数量、层数、注意力头数
→ Pre-training在这个架构上灌入知识(Day 3)
→ SFT/RLHF/DPO在同一架构上调整行为(Day 3)
→ 量化把训练好的权重压缩(Day 2)
→ 推理优化让压缩后的模型高效运行(Day 8)
→ 长上下文技术扩展架构的处理能力(Day 9)
PM决策要点：
模型选型时，要同时考虑训练质量(L2)和推理成本(L4)
一个70B Dense模型可能比8x22B MoE效果好但推理贵3倍
关联链2: RAG ←→ Embedding ←→ VectorDB (知识管理三角)
RAG(Day 5) 是"方法论"——先检索再生成
│
├── 依赖 Embedding(Day 6) 做语义表示
│ → Embedding质量直接决定检索质量
│ → 中文金融领域需要领域Embedding(BGE-M3/Jina)
│
└── 依赖 VectorDB(Day 6) 做高效存储检索
→ HNSW适合低延迟场景
→ IVF-PQ适合超大规模数据
→ 选型影响RAG的延迟和成本
三者的关系像"厨师(RAG) + 食材(Embedding) + 冰箱(VectorDB)"
→ 食材不新鲜(Embedding差) → 做不出好菜
→ 冰箱太小(VectorDB不行) → 存不了足够食材
→ 厨师手艺差(RAG链路差) → 浪费好食材
关联链3: Agent ←→ Tools ←→ MCP (自主执行三角)
Agent(Day 12) 是"大脑"——决定做什么、怎么做
│
├── 通过 Tool Use / Function Calling 执行动作
│ → Tool的质量决定Agent的能力上限
│ → Tool的数量越多，Planning越复杂
│
└── 通过 MCP(Day 13) 标准化连接工具生态
→ MCP Server暴露能力，Client消费能力
→ A2A协议让Agent之间协作
→ OAuth 2.1保障安全
Agent的能力 = min(LLM推理能力, 可用工具集, 规划策略)
→ 推理能力来自Reasoning(Day 11)的提升
→ 长上下文(Day 9)让Agent记住更多历史
→ 多模态(Day 10)扩展Agent的感知维度
关联链4: Reasoning ←→ CoT ←→ RL (推理增强链)
Prompt Engineering的CoT(Day 4)
→ 是最早的推理增强方法，无需改模型
→ "让我一步步思考" 就能提升推理能力
o1/R1/Extended Thinking(Day 11)
→ 把CoT从Prompt技巧升级为模型能力
→ 通过RL训练(Day 3的GRPO)让模型自发产生推理链
→ Test-Time Compute: 推理时投入更多算力换更好结果
PRM/ORM(Day 11)
→ Process Reward Model评估每一步推理
→ 类似训练阶段的Reward Model(Day 3 RLHF)
→ 但在推理时使用，指导搜索最优推理路径
这条链揭示了一个趋势：
训练阶段的技术(RL/Reward Model)正在"迁移"到推理阶段
→ 推理时间从固定成本变成可变成本
→ PM需要设计"推理预算"机制
知识点4: 技术选型决策树汇总
从"理解概念"升级到"在真实场景中做决策"
4.1 RAG vs Fine-tuning vs Long Context
需要让LLM使用特定知识？
│
┌──────┴──────┐
│ │
知识是否经常更新？ 否 → 知识是否在训练数据中？
│ │
┌─────┴─────┐ ┌─────┴─────┐
│ │ │ │
是 否 是 否
│ │ │ │
▼ ▼ ▼ ▼
┌──────┐ 数据量多大？ Prompt 需要改变
│ RAG │ │ Engineering 输出风格？
│ │ ┌────┴────┐ (Day 4) │
└──────┘ │ │ ┌────┴────┐
<1000条 >1000条 是 否
│ │ │ │
▼ ▼ ▼ ▼
Few-Shot Fine-tune Fine-tune RAG
ICL(Day 4) LoRA(Day 7) LoRA(Day 7) (Day 5)
决策矩阵:
| 维度 | RAG | Fine-tuning | Long Context | Prompt Engineering |
|---|---|---|---|---|
| 知识更新频率 | 高（实时更新） | 低（需重训） | 高（每次注入） | 低（硬编码） |
| 数据量要求 | 无限（向量库扩展） | 几百到几万条 | 受窗口限制 | 几条示例 |
| 成本 | 中（向量库+检索） | 高（训练GPU） | 高（长序列推理） | 低（仅Prompt） |
| 延迟 | 中（检索+生成） | 低（直接生成） | 高（长序列） | 低（直接生成） |
| 适用场景 | 知识库问答、文档搜索 | 领域适配、风格迁移 | 整本书分析 | 简单任务、格式控制 |
| 金融案例 | 合规文档查询 | 金融报告生成风格 | 年报全文分析 | 交易分类 |
4.2 何时使用Reasoning模型
任务复杂度评估
│
┌──────┴──────┐
│ │
需要多步推理？ 简单问答/生成
│ │
┌─────┴─────┐ ▼
│ │ 标准LLM
推理深度？ 对延迟敏感？ (GPT-4o / Claude Sonnet)
│ │
┌─────┴───┐ ┌───┴────┐
│ │ │ │
深度推理 中等 敏感 不敏感
(数学/代码) 推理 │ │
│ │ ▼ ▼
▼ ▼ 标准LLM Reasoning模型
Reasoning CoT + CoT (o3 / R1 /
模型(o3/R1) Prompt Extended
(Day 4) Thinking)
Reasoning模型决策指南:
适合用Reasoning模型的场景：
✅ 多步数学计算（金融建模、风险计算）
✅ 复杂代码生成和调试
✅ 逻辑推理和策略规划
✅ 对准确性要求极高、可容忍高延迟
不适合Reasoning模型的场景：
❌ 简单问答和翻译（杀鸡用牛刀）
❌ 实时聊天（延迟5-30秒不可接受）
❌ 创意写作（不需要逻辑严密性）
❌ 高并发低成本场景（Token消耗大3-10倍）
4.3 本地部署 vs 云API
部署方式选择
│
┌──────┴──────┐
│ │
数据敏感性？ │
│ │
┌─────┴─────┐ │
│ │ │
极度敏感 一般 │
(金融/医疗) 敏感度 │
│ │ │
▼ │ │
本地部署 ┌──┴───┐ │
(Day 2) │ │ │
Ollama/ │ 调用量多大？
vLLM本地 ┌──┴──┐ │
│ │ │
高并发 低量 │
│ │ │
▼ ▼ ▼
自建GPU 云API 云API
集群 按量计费 (OpenAI/
(Day 8) Anthropic/
Bedrock)
成本速算公式:
云API月成本 = 日均请求数 × 平均Token数 × Token单价 × 30
自建GPU月成本 = GPU租金 + 运维人力 + 带宽 + 冗余
经验阈值（2026年参考）：
< 100万Token/天 → 云API更划算
100万-1亿Token/天 → 需要仔细算
> 1亿Token/天 → 自建大概率划算
4.4 何时使用Agent
任务类型判断
│
┌──────┴──────┐
│ │
单次交互能完成？ 需要多步操作？
│ │
▼ │
标准LLM调用 ┌──────┴──────┐
│ │
步骤确定？ 步骤不确定？
│ │
▼ ▼
Pipeline Agent
(固定流程) (动态规划)
(Day 12)
│
┌─────┴─────┐
│ │
需要外部工具？ 纯推理
│ │
▼ ▼
Agent+MCP Reasoning
(Day 12+13) 模型(Day 11)
Agent自主性光谱:
完全受控 ◄────────────────────────────────────────► 完全自主
│ │
固定Prompt Prompt+Tools ReAct Planning 全自主Agent
单次调用 函数调用 观察-行动 多步规划 自己定目标
│ │ │ │ │
金融报告 查询API 客服Agent 研究Agent 通用助手
生成 返回结果 多轮对话 搜索+分析 (风险最高)
4.5 综合决策框架
┌──────────────────────────────────────────────────────────────┐
│ LLM应用技术选型决策框架 │
├──────────────────────────────────────────────────────────────┤
│ │
│ Step 1: 明确需求 │
│ ├── 任务类型：生成/分类/提取/推理/对话/自主执行？ │
│ ├── 质量要求：容错率多少？幻觉后果有多严重？ │
│ ├── 延迟要求：实时(<1s) / 准实时(<5s) / 离线(>5s)？ │
│ └── 预算约束：月预算多少？是否有GPU资源？ │
│ │
│ Step 2: 选模型 │
│ ├── 需要最强推理 → o3/Claude Opus │
│ ├── 需要高性价比 → Claude Sonnet/GPT-4o/Qwen-72B │
│ ├── 需要本地部署 → Qwen-7B/Llama-8B GGUF量化(Day 2) │
│ ├── 需要多模态 → GPT-4o/Claude Sonnet(Day 10) │
│ └── 需要中文特化 → Qwen系列/DeepSeek(Day 1) │
│ │
│ Step 3: 选知识注入方式 │
│ ├── 知识频繁更新 + 大量文档 → RAG(Day 5+6) │
│ ├── 需要改变输出风格/格式 → Fine-tuning(Day 7) │
│ ├── 少量上下文就够 → Prompt Engineering(Day 4) │
│ └── 需要分析整本书/长文档 → Long Context(Day 9) │
│ │
│ Step 4: 选交互模式 │
│ ├── 单次问答 → 直接API调用 │
│ ├── 需要工具 → Function Calling + MCP(Day 13) │
│ ├── 多步任务 → Agent框架(Day 12) │
│ └── 复杂推理 → Reasoning模型(Day 11) │
│ │
│ Step 5: 性能和质量保障 │
│ ├── 高并发需求 → 推理优化: vLLM + Continuous Batch(Day 8) │
│ ├── 成本压缩 → 量化(Day 2) + 模型蒸馏 + 缓存 │
│ └── 质量监控 → Benchmark + 人工评估 + Red Team(Day 14) │
│ │
└──────────────────────────────────────────────────────────────┘
知识点5: 面试高频题汇总
14天积累的所有核心面试题，按类别整理
5.1 基础架构类
| # | 面试题 | 来源 | 核心答案要点 |
|---|---|---|---|
| 1 | 解释Transformer的Self-Attention机制 | Day 1 | QKV三元组、softmax归一化、Multi-Head并行 |
| 2 | 为什么现代LLM都用Decoder-only？ | Day 1 | Next Token Prediction统一了所有NLP任务 |
| 3 | MoE和Dense模型的trade-off | Day 1 | 激活参数少→推理快，但总参数大→显存多 |
| 4 | 什么是Scaling Laws？ | Day 1 | 参数/数据/算力的幂律关系，指导训练预算分配 |
| 5 | KV Cache是什么，为什么重要？ | Day 1 | 避免重复计算，但占显存大，是推理瓶颈 |
5.2 训练与对齐类
| # | 面试题 | 来源 | 核心答案要点 |
|---|---|---|---|
| 6 | Pre-training/SFT/RLHF三阶段各做什么？ | Day 3 | 知识灌入→格式教学→偏好对齐，成本差3个数量级 |
| 7 | DPO相比RLHF的优势？ | Day 3 | 不需要单独训练Reward Model，训练更稳定 |
| 8 | GRPO是什么？DeepSeek R1怎么训练的？ | Day 3 | Group Relative Policy Optimization，纯RL涌现推理 |
| 9 | 数据质量vs数据量，哪个更重要？ | Day 3 | 质量远大于数量，Phi系列用教科书级数据证明 |
| 10 | Constitutional AI是什么？ | Day 3 | Anthropic方法：用AI自己评判自己，减少人工标注 |
5.3 推理与部署类
| # | 面试题 | 来源 | 核心答案要点 |
|---|---|---|---|
| 11 | INT4/INT8/FP16量化的trade-off | Day 2 | 精度损失vs显存节省vs推理速度，INT4是性价比甜点 |
| 12 | GPTQ vs AWQ vs GGUF选哪个？ | Day 2 | GPTQ GPU推理、AWQ激活感知更准、GGUF CPU兼容 |
| 13 | PagedAttention解决了什么问题？ | Day 8 | KV Cache内存碎片化，用虚拟内存分页管理 |
| 14 | Continuous Batching vs Static Batching | Day 8 | 动态插入新请求、已完成的立即释放，吞吐量提升2-4x |
| 15 | Speculative Decoding原理 | Day 8 | 小模型草稿→大模型验证，降低延迟不损质量 |
5.4 RAG与知识管理类
| # | 面试题 | 来源 | 核心答案要点 |
|---|---|---|---|
| 16 | RAG的完整链路是什么？ | Day 5 | 文档切片→Embedding→向量存储→检索→Rerank→生成 |
| 17 | RAG vs Fine-tuning什么时候用哪个？ | Day 5+7 | 知识更新频繁用RAG，改风格/格式用FT，可组合使用 |
| 18 | Embedding模型怎么选？ | Day 6 | MTEB排行榜、考虑语言/维度/推理速度、领域适配 |
| 19 | HNSW vs IVF索引的区别 | Day 6 | HNSW图搜索延迟低、IVF倒排适合大规模+过滤 |
| 20 | Long Context会替代RAG吗？ | Day 9 | 不会完全替代：RAG在成本、更新频率、数据规模上仍有优势 |
| 21 | Naive RAG的常见失败原因？ | Day 5 | 切片粒度不当、检索召回低、缺少Rerank、Prompt差 |
5.5 Agent与工具类
| # | 面试题 | 来源 | 核心答案要点 |
|---|---|---|---|
| 22 | ReAct模式是什么？ | Day 12 | Reasoning+Acting循环：思考→行动→观察→再思考 |
| 23 | Single-Agent vs Multi-Agent的选择 | Day 12 | 复杂度vs可控性的trade-off，大多数场景Single足够 |
| 24 | Agent的Planning策略有哪些？ | Day 12 | Task Decomposition、ReWOO、Plan-and-Execute |
| 25 | MCP协议解决了什么问题？ | Day 13 | 工具连接标准化，避免每个LLM为每个工具写适配器 |
| 26 | Agent安全性如何保障？ | Day 12+13 | 权限最小化、人工审批门、操作沙箱、OAuth 2.1 |
5.6 评估与安全类
| # | 面试题 | 来源 | 核心答案要点 |
|---|---|---|---|
| 27 | 怎么评估LLM的好坏？ | Day 14 | Benchmark(MMLU/HumanEval) + Arena(人类投票) + 领域评估 |
| 28 | 如何检测和减少Hallucination？ | Day 5+14 | RAG提供引用、自我一致性检查、Fact-checking pipeline |
| 29 | Red Teaming是什么？ | Day 14 | 对抗性测试：故意找模型的安全漏洞和失败模式 |
| 30 | LLM上线前需要哪些评估？ | Day 14 | 功能评估+安全评估+偏见检测+合规检查+成本压测 |
5.7 综合架构类（面试高频压轴题）
| # | 面试题 | 涉及Day | 核心答案要点 |
|---|---|---|---|
| 31 | 设计一个企业级RAG系统 | 5+6+8+14 | 文档处理→Embedding→VectorDB→检索→Rerank→生成→评估 |
| 32 | 设计一个智能客服Agent | 12+13+5+11 | ReAct架构+知识库RAG+工具MCP+Fallback人工 |
| 33 | 如何控制LLM应用成本？ | 2+4+8+9 | 分层路由+缓存+量化+Prompt压缩+批处理 |
| 34 | Reasoning模型如何影响产品设计？ | 11 | 异步架构+推理预算+Streaming+用户预期管理 |
| 35 | 从0到1搭建LLM平台的架构？ | 全部 | API Gateway→模型路由→推理引擎→RAG→Agent→监控→评估 |
知识点6: 第一阶段遗留问题和盲区
6.1 概念层面的盲区
| 盲区 | 现状 | 原因 | 第二阶段补救计划 |
|---|---|---|---|
| MoE路由机制细节 | 知道Expert/Router概念，不清楚Load Balancing Loss | Day 1篇幅有限 | Day 16-20 LLM架构设计时补 |
| GRPO数学推导 | 知道GRPO是Group Relative PO，不清楚数学细节 | Day 3侧重宏观理解 | 阅读DeepSeek R1论文Section 2 |
| ANN算法数学 | HNSW/IVF知道概念，不清楚图构建算法 | Day 6时间不够 | Day 21-25 生产RAG系统时深入 |
| Ring Attention工程实现 | 理解分布式注意力概念，不清楚通信开销 | Day 9偏理论 | 结合实际部署时理解 |
| VLM训练细节 | 知道Vision Encoder+Projection+LLM架构，不清楚对齐训练 | Day 10广度优先 | Day 31-42 金融AI应用时深入 |
6.2 实操层面的不足
还缺少的实操经验（第二阶段必须补上）：
1. 真实LoRA Fine-tuning
现状: 理解原理和选型，但没跑过完整训练流程
计划: Day 21-25 用金融领域数据做一次完整LoRA
2. 生产级RAG系统搭建
现状: 理解全链路，但没搭过端到端系统
计划: Day 21-25 搭建包含Chunking/Rerank/评估的完整RAG
3. Agent系统的错误处理和状态管理
现状: 理解框架和模式，缺少生产环境经验
计划: Day 26-30 Agent工程化专题
4. 模型评估Pipeline
现状: 知道Benchmark和方法，没建过自动化评估流程
计划: Day 21-25 RAG评估部分实操
5. 多模型路由和成本控制
现状: 知道分层路由策略，没实现过
计划: Day 16-20 LLM应用架构设计时实现
6.3 知识深度 vs 广度的自我诊断
用"能否应对连续3个追问"来检验深度：
✅ 深度足够（能扛住追问）:
→ Transformer架构: QKV → Multi-Head → 为什么GQA更好 → MLA原理
→ RAG链路: 基本链路 → Advanced RAG策略 → Agentic RAG设计
→ Agent: ReAct → Planning策略对比 → Multi-Agent编排
→ Prompt: 基本技巧 → ICL原理 → In-Context Learning的局限性
⚠️ 深度一般（第二个追问可能卡壳）:
→ 训练: 三阶段流程 → DPO vs RLHF → GRPO的具体算法？（卡）
→ VectorDB: HNSW概念 → 图构建过程 → 调参经验？（卡）
→ 评估: Benchmark知识 → 自定义评估设计 → 实际案例？（卡）
❌ 深度不够（第一个追问就薄弱）:
→ Ring Attention的具体通信协议
→ VLM对齐训练(Contrastive Learning)的数学
→ Speculative Decoding的接受率计算
知识点7: 第二阶段预告
7.1 第二阶段总览: 从概念到工程
第一阶段: "我知道LLM技术栈的每一层是什么"
第二阶段: "我能用这些技术搭建生产级系统"
核心转变：
概念理解 → 工程实现
技术选型 → 架构设计
单点知识 → 系统集成
理论分析 → 动手实操
7.2 Day 16-30 路线图
┌─────────────────────────────────────────────────────────┐
│ 第二阶段：工程实践 (Day 16-30) │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─ Day 16-20: LLM应用架构设计 ──────────────────────┐ │
│ │ │ │
│ │ Day 16: API Gateway + 模型路由 │ │
│ │ → 多模型统一接口、负载均衡、限流降级 │ │
│ │ → 补第一阶段盲区: 分层路由实现 │ │
│ │ │ │
│ │ Day 17: Prompt管理与版本控制 │ │
│ │ → Prompt模板引擎、A/B测试框架 │ │
│ │ → 衔接Day 4 Prompt Engineering │ │
│ │ │ │
│ │ Day 18: 缓存与成本控制 │ │
│ │ → Semantic Cache、Token预算管理 │ │
│ │ → 补第一阶段盲区: 成本优化实操 │ │
│ │ │ │
│ │ Day 19: 可观测性与监控 │ │
│ │ → 延迟/成本/质量三维监控 │ │
│ │ → 衔接Day 14评估，延伸到生产监控 │ │
│ │ │ │
│ │ Day 20: 安全与合规 │ │
│ │ → 输入过滤/输出审核/PII脱敏 │ │
│ │ → 金融场景的特殊合规要求 │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ ┌─ Day 21-25: 生产级RAG系统 ─────────────────────────┐ │
│ │ │ │
│ │ Day 21: 文档处理Pipeline（PDF/表格/多语言） │ │
│ │ Day 22: Chunking策略与Embedding优化 │ │
│ │ Day 23: 高级检索(HyDE/Multi-Query/Rerank) │ │
│ │ Day 24: RAG评估与迭代(RAGAS/自定义指标) │ │
│ │ Day 25: 端到端RAG系统搭建实操 │ │
│ │ → 补第一阶段盲区: LoRA + RAG组合实操 │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ ┌─ Day 26-30: Agent系统工程化 ───────────────────────┐ │
│ │ │ │
│ │ Day 26: Agent状态管理与持久化 │ │
│ │ Day 27: 错误恢复与重试策略 │ │
│ │ Day 28: 成本控制与Token预算 │ │
│ │ Day 29: Multi-Agent编排实战 │ │
│ │ Day 30: Agent安全沙箱与权限控制 │ │
│ │ → 补第一阶段盲区: Agent生产环境经验 │ │
│ └────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
7.3 第二阶段的检验标准
Day 30结束时，必须能做到：
1. 画出完整的LLM应用架构图（15分钟白板题）
→ API Gateway → 路由 → 缓存 → 推理 → RAG → Agent → 监控
2. 搭建一个端到端RAG系统（有代码可运行）
→ 文档处理 → Embedding → VectorDB → 检索 → Rerank → 生成 → 评估
3. 实现一个可靠的Agent系统（有错误处理）
→ ReAct循环 → MCP工具连接 → 状态管理 → 失败回退
4. 解答"设计一个企业级LLM平台"面试题（完整45分钟）
→ 需求分析 → 架构设计 → 技术选型 → 成本估算 → 风险评估
5. 对金融零售场景有针对性的技术方案
→ 知道金融合规对LLM的特殊要求
→ 知道零售推荐和客服的具体架构
今日思考
思考1: 14天最大的认知转变是什么？
入门前的认知:
"LLM就是ChatGPT，输入问题输出答案，技术上就是一个大模型"
14天后的认知:
LLM是一个至少7层的技术栈，每一层都有独立的技术选型和trade-off。
一个看似简单的"智能客服"背后涉及:
→ 模型选型(L1) → 是否Fine-tune(L3) → RAG知识库(L3)
→ 推理优化(L4) → Agent编排(L6) → MCP工具连接(L6) → 质量监控(L7)
PM/架构师的价值不在于懂每一层的数学，
而在于知道每一层的trade-off，能在约束条件下做出最优决策。
思考2: 10年金融零售经验和LLM技术的连接点
金融零售背景在LLM领域的独特价值：
1. 风控思维 → Agent安全设计
传统风控: 交易限额/黑名单/异常检测
Agent风控: 权限最小化/操作沙箱/人工审批门/Token预算
2. 合规经验 → LLM合规架构
传统合规: KYC/AML/数据隐私/审计追溯
LLM合规: PII脱敏/输出过滤/Hallucination检测/决策可解释性
3. 产品迭代方法论 → RAG/Agent的迭代优化
传统PM: 数据驱动/A-B测试/漏斗分析/留存曲线
LLM PM: 评估指标/Prompt A-B测试/RAG召回率优化/Agent成功率
4. 系统架构经验 → LLM应用架构
传统架构: 微服务/消息队列/缓存/限流
LLM架构: API Gateway/模型路由/Semantic Cache/Token限流
结论: 不是"转行学AI"，而是"用AI增强10年积累的领域能力"
思考3: 第一阶段学习方法的反思
做得好的：
✅ 每天用金融类比解释技术概念，降低了认知负荷
✅ 每天整理面试题，积累了35道高质量问答
✅ 按技术栈分层学习，知识结构清晰
✅ 前沿技术(Reasoning/MCP/Agent)没落下
需要改进的：
⚠️ 实操太少，Day 2之后缺少动手环节
⚠️ 有些天的笔记深度不一致（Day 2/9偏简略）
⚠️ 概念间的关联在学习过程中发现得太晚
⚠️ 没有建立Spaced Repetition机制，早期知识可能遗忘
第二阶段改进：
→ 每天至少1小时实操（写代码/搭系统/跑实验）
→ 每5天做一次概念串联复习
→ 用"教别人"的方式检验理解深度
→ 建立面试题的间隔重复复习计划
面试表达: 1分钟讲清LLM技术栈
30秒版本
LLM技术栈可以分为7层：底层是Transformer架构和训练流程，这决定了模型的基础能力；中间层是知识注入（RAG/Fine-tuning）和性能工程（量化/推理优化），解决"怎么让模型用上我的数据"和"怎么又快又便宜"的问题；上层是能力扩展（多模态/Reasoning）和系统协作（Agent/MCP），让AI能看图、深度思考、自主执行任务；最顶层是评估和安全保障，确保上线质量。作为架构师，核心价值是在每一层的trade-off中做出最优决策。
2分钟深入版本
我把LLM技术栈分为7层来理解：
第一层是模型架构——Transformer的Self-Attention让模型能理解Token间的关系，2025年的趋势是MoE架构用更少激活参数达到更强效果，比如DeepSeek V3只激活37B但总参数671B。
第二层是训练——Pre-training用万亿Token建知识基座，SFT用几万条高质数据教对话格式，RLHF/DPO对齐人类偏好。关键洞察是数据质量远比数量重要。
第三层是知识注入——这是PM最常做决策的层。RAG适合知识频繁更新的场景，Fine-tuning适合改变输出风格，Long Context适合分析长文档，三者可以组合使用。
第四层是性能工程——量化让模型跑在更便宜的硬件上，vLLM的PagedAttention让吞吐量翻倍，长上下文技术在扩展模型的处理能力。
第五六层是能力扩展和系统协作——多模态让AI能看图，Reasoning模型用更多推理时间换更高准确度，Agent让AI自主执行多步任务，MCP标准化了工具连接。
第七层是质量保障——Benchmark评基础能力，Arena评人类偏好，Red Teaming找安全漏洞。
结合我的金融零售背景，我特别关注三个点：一是成本控制（分层路由可降低80%成本），二是合规要求（PII脱敏、Hallucination检测），三是Agent安全（权限最小化、操作沙箱）。这些恰好是金融行业最看重的。
明日预告
Day 16: LLM应用架构设计 — API Gateway与模型路由
从今天开始进入第二阶段: 工程实践
Day 16 核心内容预览：
1. LLM应用的整体架构设计（微服务视角）
2. API Gateway设计：统一入口、鉴权、限流、日志
3. 模型路由策略：根据任务复杂度选择不同模型
4. 负载均衡：多模型实例的流量分配
5. 降级策略：主模型不可用时的Fallback方案
6. 金融场景特殊需求：审计追溯、合规过滤
准备：
→ 回顾Day 8推理优化的部署层知识
→ 回顾Day 14评估的质量监控思路
→ 思考：如果要为一个银行设计LLM平台，架构怎么画？
今日总结
┌────────────────────────────────────────────────────────────────┐
│ Day 15 核心收获 │
├────────────────────────────────────────────────────────────────┤
│ │
│ 1. LLM技术栈全景图: 7层架构 │
│ L0 硬件 → L1 Transformer → L2 训练 → L3 知识注入 │
│ → L4 性能 → L5 能力扩展 → L6 系统协作 → L7 质量保障 │
│ │
│ 2. 14天知识回顾: 不是孤立知识点，而是相互关联的网络 │
│ → 4条核心关联链把碎片知识串成体系 │
│ → 掌握度自评发现3个需要深入的盲区 │
│ │
│ 3. 技术选型决策框架: 5个核心决策树 │
│ → RAG vs FT vs Long Context vs Prompt Eng │
│ → Reasoning模型使用场景 │
│ → 本地 vs 云API部署 │
│ → 是否使用Agent │
│ → 综合5步选型框架 │
│ │
│ 4. 面试准备: 35道核心面试题 + 1分钟技术栈讲解 │
│ → 按6类整理，覆盖基础/训练/推理/RAG/Agent/评估 │
│ → 30秒版和2分钟版面试表达已准备 │
│ │
│ 5. 第二阶段方向: 从概念理解 → 工程实现 │
│ → 5个实操盲区已识别，有明确补救计划 │
│ → Day 16开始搭建真实系统 │
│ │
│ 学习耗时：约 5 小时（复习+整理+反思） │
│ 下一步：Day 16 LLM应用架构设计 — API Gateway与模型路由 │
│ │
└────────────────────────────────────────────────────────────────┘