AgentGuide
https://adongwanai.github.io/AgentGuide | AI Agent开发指南 | LangGraph实战 | 高级RAG | 转行大模型 | 大模型面试 | 算法工程师 | 面试题库 | 强化学习|数据合成
AgentGuide
💡 核心理念
📌 本项目定位:资源整合 + 系统化路径 + 实战导向 🎯 我们的原则: - ✅ 站在巨人的肩膀上 - 互联网已有的优质资源(课程、教程、论文),我们直接引用,不重复造轮子 - ✅ 只分享干货 - (坚持更新中,欢迎催更) - ✅ 提供系统化路径 - 将碎片化资源串联成完整学习路线,告诉你先学什么、再学什么 - ✅ 求职导向 - 每个知识点都标注"面试怎么考"、"简历怎么写" 💪 AgentGuide 的独特价值:不是简单的资源堆砌,而是系统化 + 求职导向 + 实战验证的完整解决方案!
🧭 按目标进入
| 🛠️ 开发岗路线 | 🔬 算法岗路线 | 🔥 科研前沿专题 |
|---|---|---|
| 面向工程落地与系统实践 | 面向原理、算法与实验能力 | 面向 Agent 前沿研究方向 |
| 进入开发岗学习路线 | 进入算法岗学习路线 | 进入科研前沿专题 |
📑 目录
🎯 核心内容:
- 💡 关于本项目 - Agent开发指南、转行大模型、高级RAG、大模型面试
- 🆕 求职新范式 - 1-2-5框架、个人品牌、投递策略
- 🧭 Agent 求职通关 Todo List - 当前优先级、8阶段学习产出、项目落地5步法
- 🚦 6步学习路径 - 从岗位选择到拿Offer
- 🔬 算法岗 vs 🛠️ 开发岗 - 岗位选择决策树
- 📚 学习路线图 - 算法岗10-15周 | 开发岗8-12周
- 💼 实战项目 - 开源优质项目合集 + Agent 项目
- 📖 技术教程 - LangGraph、RAG、上下文工程、监督微调、强化学习
- 🎯 面试题库 - 1500+题/面经、系统设计、编程题
- 🔥 2026 前沿面试专题 - 自进化 Agent、Agentic RL、AI Infra、Coding Agent、世界模型、图像/语音生成
🛠️ 快速导航:
- ⭐ 阿东作品推荐:learn-workbuddy - 从 0 搭建 WorkBuddy-style Desktop Agent Harness,clean-room 教学复现 Agent Loop、工具调用、上下文工程、长期记忆、Sidecar、权限审计和真实模型评测
- 🚀 10分钟快速开始 | 💬 加入学习社群 | ❓ 常见问题
- 🧭 新手快速开始 | 📚 完整文档导航 | 💼 项目导航
📖 关于本项目
3 分钟了解为什么你需要 AgentGuide
🧭 你可能正卡在这些地方
- 会调用模型、也接过工具,但 Agent 一跑长任务就早停、循环、丢状态,出了问题不知道怎么定位
- LangGraph、OpenAI Agents SDK、MCP、Skills、Multi-Agent 概念很多,却缺少一张完整的系统架构图
- Context、Memory、Tools、权限、Sandbox、Trace 混在一起,Demo 能跑,离可靠系统还很远
- RAG 做过基础问答,但复杂文档、多模态、引用溯源、评测集与线上观测没有形成闭环
- 项目只有功能截图,没有基线、指标、失败分析和工程取舍,简历写不实,面试经不起追问
- 想进入 Agent 方向,却不清楚开发岗、算法岗、Agentic RL 和前沿研究分别需要什么能力与作品
- 论文、框架和开源项目更新太快,不知道哪些值得学、先做什么、如何沉淀成可验证成果
AgentGuide 是什么?
AI Agent 工程、研究与求职的开源知识库
AgentGuide 围绕 “做得出、跑得稳、测得准、讲得清” 组织内容,不绑定单一框架,也不止于资源收藏:
- Agent 系统与 Harness:Agent Loop、Workflow / Agent / Multi-Agent 边界、状态、调度、权限与运行时
- Context Engineering 与 Memory:上下文分层、检索、压缩、长期记忆、Prompt Cache 与成本优化
- Tools 与协议生态:Tool Schema、MCP、Skills、A2A / ACP、Browser / Computer Use 与 Sandbox
- RAG 与知识系统:文档解析、Hybrid Retrieval、Rerank、GraphRAG、Agentic RAG、Multimodal RAG 与引用溯源
- Eval、Observability 与 Safety:评测集、Trace / Replay、LLM-as-a-Judge、红队、HITL 与生产可靠性
- Post-training 与 Agentic RL:SFT、DPO / GRPO、轨迹数据、Reward / Verifier、长程信用分配与环境构建
- 项目、研究与求职:可复现实战、开源项目、前沿论文、实验设计、简历表达、系统设计与面试题库
🗺️ AgentGuide 在 LLM 生态中的定位
我们覆盖 AI Agent 开发的完整技术栈 - 从模型微调到应用部署的全流程:
图片来源:Awesome-Awesome-LLMs
📌 AgentGuide 涵盖的核心技术栈(2026 版):
|
🤖 Agent 应用层
|
🧩 Agent Harness 层(核心)
|
📊 Data / Eval / Training 层
|
💡 AgentGuide 的完整覆盖: 🔬 算法工程师路径: - Agent 推理与规划:ReAct、Reflexion、Tree/Graph Search、Tool-use 策略 - RAG 与记忆算法:Hybrid Retrieval、Rerank、GraphRAG、Agentic RAG、Memory 压缩与召回 - Post-training:SFT、LoRA/QLoRA、DPO/GRPO、工具调用/轨迹数据合成与评测 🛠️ 开发工程师路径: - Agent Harness:状态管理、工具注册、权限确认、sandbox、trace、replay、成本控制 - 工具与协议:MCP、Skills、A2A/ACP、API adapter、Browser / Computer-use 工具封装 - 生产级 RAG:文档解析、向量库、rerank、引用、观测、CI eval 与安全红队 🔀 通吃型路径:用算法能力提升 Agent 决策质量,用工程能力把 Agent 做成可运行、可评测、可复盘、可写进简历的系统。
🎯 适合人群
求职目标:
- ✅ AI Agent 算法工程师 | AI Agent 开发工程师 | RAG 系统工程师
- ✅ LLM 应用工程师 | 大模型工程师 | 多模态算法工程师
学习需求:
- ✅ Agent Loop | LangGraph | OpenAI Agents SDK | MCP / Skills
- ✅ RAG / Multimodal RAG | 向量数据库 | Agent Memory | Eval Harness
- ✅ 大模型面试 | 算法岗面试 | 开发岗面试 | HR面试 | 谈薪技巧
🌟 AgentGuide 的 6 大核心价值
📚 系统化学习路径
|
🎯 100% 求职导向
|
💼 简历级实战项目
|
🔀 算法 × 开发双线通吃
|
🆓 完全开源,持续更新
|
🚀 快速上手,立即见效
|
🎁 学完 AgentGuide,你能获得什么?
从“会调用模型”到“能设计、实现、评测并讲清一个可靠的 Agent 系统”
✅ 【架构认知】分清 Chatbot、Workflow、Agent 与 Multi-Agent,理解 Agent Loop 和 Harness
✅ 【工程能力】掌握 LangGraph / OpenAI Agents SDK、Context Engineering、Memory、Tools、MCP 与 Skills
✅ 【RAG 能力】能设计 Hybrid Retrieval、Rerank、引用溯源、GraphRAG、Agentic RAG 与 Multimodal RAG
✅ 【可靠性】会构建 Eval Set、Trace / Replay、LLM-as-a-Judge、Sandbox、HITL、权限和成本控制
✅ 【训练认知】理解 SFT、DPO / GRPO、工具调用与轨迹数据合成、Reward / Verifier 的基本方法
✅ 【项目交付】完成 2-3 个可运行、可评测、可复现的项目,并写清架构、指标、取舍与失败分析
✅ 【面试表达】能围绕原理、系统设计、实验结果和工程权衡回答追问,而不是背“标准答案”
✅ 【求职路径】明确算法岗与开发岗能力差异,用项目、开源贡献和技术内容构建作品集
🚦 从零到Offer的完整路径(快速导航)
👋 新来的同学看这里!先看新范式,再按步骤执行,8-10周拿到Offer!
|
🆕 新范式 做出什么 > 学过什么 |
🎯 第一步 算法 vs 开发? |
💡 第二步 如何准备? |
📚 第三步 学什么? |
💼 第四步 做什么? |
🎓 第五步 技术细节 |
🎯 第六步 如何面试? |
⚡ 重要提醒: 1. 一定要先完成"第一步"和"第二步" - 确定方向再学习! 2. "第四步"实战项目最重要 - 简历的核心竞争力! 3. 学习时对照"第六步"面试题 - 知道学的东西面试怎么考!
🆕 求职新范式:做出什么 > 学过什么
⚡ 求职规则已经变了。2026年,HC:投递比约1:200,核心问题不再是"我够不够格",而是"我用什么方式让自己被看见"。
1-2-5 求职框架
| 维度 | 内容 |
|---|---|
| 1个原则 | 从"我会什么"转向"我做出了什么" |
| 2条轨道 | Agent开发(工程落地)vs Agent算法(研究创新) |
| 5步链路 | 简历 → 投递 → 模拟面试 → Vibe Coding → 成果展示 |
工具不再是壁垒,你用工具做出的东西才是。
旧方式 vs 新范式
| 环节 | 旧方式 | 新范式 |
|---|---|---|
| 简历 | 一份通用简历打天下 | AI读JD,动态生成针对性版本 |
| 投递 | 手动上传,逐一投递 | 一键全网投,AI做适配分析 |
| 模拟面试 | 背八股,刷题库 | AI扮演面试官,无限迭代实战 |
| Vibe Coding | 手写算法题 | AI协作设计Agent系统 |
| 成果展示 | PDF+截图 | 个人站+在线demo+社区影响力 |
个人品牌:让面试官主动找你
个人网站必备要素(免费部署:Vercel/GitHub Pages,5分钟上线):
- 每个项目一个页面 + 在线可访问的demo链接
- 技术Blog:至少3篇有深度的原理解析
- 社区数据:GitHub Star数 / 真实用户数
- 时间线里程碑
简历项目描述公式:
❌ 「参与开发了一个AI客服系统」 ✅ 「基于LangGraph + MCP构建多Agent客服系统,工具调用成功率94%,响应时长从3.2s降至0.8s,日处理10万+对话」
投递策略:AI筛简历时代的人工突围
招聘方也在用AI筛简历——两个AI在对话,人的主动触达反而更稀缺。
核心目标公司(5-10家)走人工路线:
- Boss/猎聘找具体的Hiring Manager或Team Lead
- 提前关注他们的开源项目/技术Blog
- 带着具体问题主动联系(不是「请问还招人吗?」)
- 目标:一个warm intro,不是冷申请
时机窗口: 3-6月提前批竞争烈度比8-9月低30-40%,往往是真正的机会窗口。
说几句实话
- 语言不是门槛,设计才是。 Python/TypeScript AI都能帮你写。但Agent状态机怎么设计、Memory何时截断、工具调用失败如何fallback——这些必须你自己想清楚、讲明白。
- AI工具人人都有,判断力才是壁垒。 会用Cursor写代码不算竞争力。当AI给你一个错误的Agent设计,你能30秒内发现并说清楚为什么错——这才是L5和L3的分水岭。
- 分享即异步面试。 一篇深度Blog、一个有Star的仓库,相当于提前通过了一轮面试。
- 拿结果说话。 不是"我学过LangChain",是"我用LangGraph做了一个有300个真实用户的工具"。
新增优质资源
| 资源 | 简介 | 链接 |
|---|---|---|
| learn-workbuddy | 从 0 搭建一个 WorkBuddy-style Desktop Agent Harness:clean-room 教学复现 Agent Loop、工具调用、上下文工程、长期记忆、Sidecar、权限审计和真实模型评测,不提取源码,只复现核心机制 | GitHub |
| Superpowers | 由可组合 Skills 构成的 AI Coding 完整开发工作流,覆盖需求梳理、计划、TDD、系统调试、代码评审和完成前验证 | GitHub |
| Learn Claude Code | 从零构建迷你Claude Code,12节渐进式,覆盖工具调用/子Agent/上下文压缩/多Agent协作 | GitHub |
| claw0 | 10章10个核心概念~7000行Python,从while循环到生产级Agent网关 | GitHub |
| hello-agents(Datawhale) | 《从零开始构建智能体》,16章,含MCP实战、DeepResearch复现、多Agent协同 | GitHub |
| OpenClaw | 生产级个人AI助手框架,支持Telegram/Discord/Slack等 | GitHub |
| Anthropic官方:Building Effective Agents | Anthropic工程团队出的Agent设计原则,面试必读 | 链接 |
| Vibe Coding 教程 | 从零掌握AI协作编程,Cursor/Claude Code实操指南,Vibe Coding面试攻略 | 链接 |
后续实践重点:在 Superpowers 的 Skills 工作流基础上,我将重点使用grill-me/grilling系列 Skills。它们会一次只追问一个问题,逐项压测计划、决策与设计中的假设、依赖、边界和取舍;达成共同理解后,再进入实现。
🧭 Agent 求职通关 Todo List(新增)
不是链接收藏夹,是可以照着执行的 todo list。 目标很简单:从“我学过什么”,推进到“我做出了什么、怎么验证、怎么写进简历、怎么讲给面试官听”。
- 完整路线:2026 Agent 求职通关路线
- 项目落地方法:如何落地一个可写进简历的 Agent 项目
- 工程核心专题:Agent Harness Engineering
How To Use
| 你的状态 | 建议入口 |
|---|---|
| 零基础 | 从 6步学习路径 开始,先建立 Agent / Workflow / RAG / Multi-Agent 的坐标系 |
| 会 LLM 应用 | 重点补 Agent Loop、Tool Use、Context Engineering、Eval,不要只停留在 API 调用 |
| 想做项目 | 直接进入 实战项目,按“Spec → Coding → Eval → 复盘”推进 |
| 准备面试 | 对照 面试题库,重点准备 Agent Loop、工具设计、记忆、评测、可靠性 |
| 只想找资料 | 看 技术教程 和 资源导航,优先读官方文档、工程博客和可运行项目 |
What To Learn Now
Agent 方向变化很快,当前更值得投入的是能落地、能验证、能讲清楚取舍的工程能力:
| 优先级 | 方向 | 为什么重要 |
|---|---|---|
| 1 | Claude Code / Codex-style Coding Agents | 真实代码库、shell、文件编辑、测试、权限、上下文压缩,是理解 Agent 工程的最佳样本 |
| 2 | Agent Harness Engineering | Agent 能力很大一部分来自 harness:工具协议、权限、状态、反馈、回放、CI、评测 |
| 3 | Context Engineering | Agent 的核心不是“写提示词”,而是控制信息在正确时间以正确格式进入模型 |
| 4 | Skills / MCP / A2A / ACP | Skills 负责能力复用,MCP 连接工具,A2A 连接 Agent,ACP 连接宿主应用 |
| 5 | Browser / Computer-Use Agents | 浏览器和桌面操作是 Agent 从 demo 走向真实任务的重要边界 |
| 6 | Evaluation / Observability / Safety | 没有 eval、trace、权限边界的 Agent,只能算 demo,不能算可交付系统 |
8 阶段学习产出
| 阶段 | 学什么 | 产出物 |
|---|---|---|
| Stage 0 | 区分 chatbot、workflow、agent、multi-agent | 一页笔记:为什么你的场景需要 Agent |
| Stage 1 | 最小 Agent Loop、结构化输出、工具调用 | 50-150 行最小 Agent |
| Stage 2 | Tool Use、RAG、Memory、引用与失败处理 | 一个资料研究助手 |
| Stage 3 | 现代 Agent Harness:工具、权限、状态、日志、子任务 | 可调试的 harness demo |
| Stage 4 | Multi-Agent 协调:planner / executor / reviewer / router | 一个 research → write → review 小系统 |
| Stage 5 | Skills、MCP、A2A、ACP 与能力封装 | 一个可复用 SKILL.md 或工具协议 demo |
| Stage 6 | Browser / Computer-Use Agent | 一个只操作公开网页的 browser agent |
| Stage 7-8 | Eval、Observability、Safety、部署 | 20 条 eval case + 一个别人能 clone 跑的 Agent 项目 |
项目落地 5 步法
- 建立全局认知:先搞清楚目标项目的 agent loop、tool registry、context 拼装、memory、channel 抽象。
- 准备 AI 编程环境:沉淀
CLAUDE.md/AGENTS.md、需求规格、实现计划和跨会话 todo。 - 建立项目理解 Skill:把项目结构、关键模块、测试方式写成可复用的项目理解文档。
- 先写 Spec,再写代码:明确目标用户、工具列表、权限策略、失败处理、成本约束、成功标准。
- 评测 + 归因 + 消融实验:记录通过率、失败原因、工具调用次数、成本、延迟,把结果写进简历。
面试深水区
面试不只问“会不会 LangChain”,更会追问你有没有真正写过能跑的 Agent:
- Agent Loop:
observe → think → act → observe,最大步数、停止条件、错误恢复、HITL 怎么设计? - Context + Cost Engineering:上下文分层、压缩、缓存友好结构、模型路由、token 成本怎么降?
- Tool Design:工具命名、description、schema、分页截断、权限分级、工具选错怎么修?
- Memory System:working / episodic / semantic memory,什么值得存、怎么召回、什么时候遗忘?
- Eval + Governance:component / trajectory / end-to-end eval,golden dataset 怎么来,trace 怎么审计?
- Reliability Engineering:idempotency、timeout、retry、cost guard、permission tier、observability 六件套。
简历三维表达法
不要只写“基于大模型实现智能问答”。一个 Agent 项目要从三维表达:
| 维度 | 怎么写 |
|---|---|
| 架构表达 | Agent loop、工具注册、会话状态、上下文裁剪、权限确认、记忆和错误恢复 |
| 业务表达 | 业务场景、关键工具、数据源、用户路径、约束条件 |
| 结果表达 | 评测集规模、成功率、失败类型、成本优化、消融实验结论 |
示例:
基于轻量 Agent Harness 构建垂直场景助手,使用 ReAct loop + dispatch 表注册 5 个业务工具,四层分级 context 管理 system / long-term / short-term / turn 信息;高风险操作接入三级权限确认,20 条评测 case 端到端通过率 82%,通过上下文压缩和模型路由将 token 成本降低 60%。
🎯 第一步:确定你的目标岗位
核心理念:选择 > 努力!选对方向,事半功倍!
🤔 AI Agent 岗位的两条主线
在大模型时代,Agent 方向的岗位主要分为两条线:
🔬 算法工程师线核心工作:算法创新、论文研究 日常任务:
产出形式:
评价标准:
岗位数量:⭐⭐⭐ 中等 竞争激烈度:⭐⭐⭐⭐⭐ 很激烈 薪资天花板:⭐⭐⭐⭐⭐ 很高(60-200万) |
🛠️ 开发工程师线核心工作:系统搭建、业务落地 日常任务:
产出形式:
评价标准:
岗位数量:⭐⭐⭐⭐⭐ 最多 竞争激烈度:⭐⭐⭐ 适中 薪资天花板:⭐⭐⭐⭐ 较高(40-80万) |
🎯 你应该选哪条线?
👉 点击查看详细的岗位选择决策树
问题1:你的核心优势是什么?
├─ 数学/理论强 + 喜欢钻研原理 + 有论文发表
│ → 【算法工程师线】
│
│ 细分方向选择:
│ ├─ 想优化 Agent 算法 → Agent 算法工程师(Memory优化、规划策略)
│ ├─ 想优化 RAG 算法 → RAG 算法工程师(检索策略、Reranker)
│ └─ 想改进模型本身 → 模型算法工程师(Reasoning、对齐)
│
└─ 工程能力强 + 喜欢做系统 + 注重落地
→ 【开发工程师线】
细分方向选择:
├─ 想做业务应用 → Agent 应用开发(RAG系统、RPA、智能客服)⭐ 推荐
├─ 想做基础设施 → AI Infra 开发(推理部署、训练平台)
└─ 想做产品化 → AI 应用开发(前端集成、产品化)
问题2:有什么背景?
- ✅ 有论文/科研经历 → 优先算法线
- ✅ 有工程/项目经验 → 优先开发线
- ✅ 两者都有 → 通吃策略(最推荐!)
⭐ 最佳策略:两手抓!
- 简历中既有算法项目(论文、算法优化)
- 又有开发项目(完整系统、业务指标)
- 可以同时投两类岗位,机会翻倍!
🎯 技术方向细分(重要!)
👉 点击查看 Agent 方向的细分岗位
🔬 算法线细分方向
1. 上下文工程算法工程师 ⭐⭐⭐⭐⭐ 最热门!
技术方向:
- RAG 算法:GraphRAG、Agentic RAG、Reranker 训练
- Agent 算法:Memory 机制、规划算法优化、Multi-Agent 协作
- 多模态算法:跨模态对齐(CLIP改进)、多模态融合
项目示例:
- GraphRAG 检索算法优化(召回率 +12%)
- Agent Memory 压缩算法(存储 -60%)
- Agentic RAG 策略设计(准确率 +20%)
岗位数量:⭐⭐⭐⭐(大厂+头部创业公司)
2. 模型算法工程师 ⭐⭐
技术方向:
- Reasoning 算法(Long COT、工具调用 RL)
- 对齐算法(RLHF、DPO、GRPO)
- 模型架构(MoE、长文本、Attention 改进)
岗位数量:⭐⭐(主要在大厂研究院)
🛠️ 开发线细分方向
1. 上下文工程开发工程师 ⭐⭐⭐⭐⭐ 岗位最多!
技术方向:
- RAG 系统:企业知识库、智能客服、文档解析
- Agent 应用:RPA 自动化、研究助手、工作流 Agent
- 多模态系统:图文检索、OCR pipeline、视觉问答
项目示例:
- 企业级 GraphRAG 知识问答系统(服务1000+员工)
- Agent 驱动的 RPA 系统(自动化率80%,节省200万/年)
岗位数量:⭐⭐⭐⭐⭐(所有 AI 公司都需要)
2. AI Infra 开发工程师 ⭐⭐⭐
技术方向:
- 推理服务部署(vLLM、TGI、Triton)
- 训练平台搭建(KubeFlow、Ray)
- 模型服务化(API 网关、负载均衡、监控)
岗位数量:⭐⭐⭐(大厂需求多)
👉 Agent 开发工程师核心能力要求(大厂真实招聘)
基于 OpenAI、DeepMind、Meta、蚂蚁等大厂真实 JD 总结
三层能力模型
Layer 1:后端与系统功底(基础能力)
- 大型分布式、高并发、高性能系统设计
- 云原生 PaaS 平台、Kubernetes 架构理解
- 价值:Agent 系统本质是复杂分布式服务
Layer 2:Agent 核心技术(重点能力)
- 混合 Agent 架构(单 Agent vs Multi-Agent)
- 上下文工程(动态打包、向量索引、信息检索)
- 工具编排(Tool 设计、Function Calling)
- 记忆与个性化(Memory 设计、Mem0、Zep)
- 任务规划(Orchestration、Workflow)
- 评估体系(如何证明 Agent 比人工更好?)
Layer 3:模型理解(加分项)
- 主流模型长短板(GPT-4/Claude/Llama 选择)
- 微调能力(Function Call 微调、垂直领域适配)
- 强化学习基础(Agent RL、DPO)
从"调包侠"到"真实项目"的关键转变
❌ 玩具项目:
- 只用 LangChain 跑个 demo
- 没有评估、没有优化、没有生产化考虑
- 面试一问就穿帮
✅ 真实项目:
- 具体业务场景(智能客服、RPA、研究助手)
- 完整技术栈(文档解析 + 高级 RAG + Agentic 逻辑)
- 量化评估(构建测试集、使用 Ragas、持续追踪优化)
- 生产化考虑(成本控制、性能优化、可观测性、异常处理)
📖 完整技术方向详解:转行大模型热门方向准备指南
💡 新手建议:优先选择上下文工程开发(RAG/Agent 系统),岗位最多、最易落地
💡 第二步:拿Offer的方法论
不同岗位,完全不同的准备策略!
🔬 算法工程师 - 如何准备?
点击查看算法岗完整准备方案
简历重点:
✅ 必须强调:
- 算法创新:"提出XX算法"、"改进XX方法"、"设计XX策略"
- 实验验证:对比实验、消融实验、baseline对比、指标提升
- 论文/专利:"论文在投XXX"、"发表于XXX"
- 开源贡献:"开源代码XX stars"
❌ 尽量少提:
- 业务指标(用户数、QPS)
- 系统架构细节
- 工程优化
项目示例(算法岗):
【Agentic RAG 策略优化】
- 问题:多跳推理场景召回率低(实验测得62%)
- 方法:提出基于RL的子图采样算法,优化路径排序策略
- 实验:在KGQA数据集上F1提升12%,对比5种baseline
消融实验:RL策略贡献8%,路径排序贡献4%
- 产出:论文在投EMNLP(一作),代码开源300+ stars
- 技能:强化学习、图神经网络、知识图谱
面试准备重点:
- 📚 理论深度(能推导算法原理)
- 🧪 实验设计(对比实验、消融实验)
- 📄 论文阅读(顶会最新进展)
- 💻 代码实现(能手撕核心算法)
🛠️ 开发工程师 - 如何准备?
点击查看开发岗完整准备方案
简历重点:
✅ 必须强调:
- 完整系统:"搭建XX系统"、"端到端实现"、"上线服务"
- 业务价值:服务用户数、处理量、业务指标提升
- 性能优化:QPS提升、延迟降低、成本节省
- 技术栈:具体框架、工具、数据库、部署方案
- 工程能力:高并发、高可用、监控告警
❌ 不要过度强调:
- 算法细节和理论推导
- 论文(开发岗更看重系统)
项目示例(开发岗):
【企业级 Agent 自动化系统】
- 背景:客服部门日均5000+重复工单,人力成本高
- 技术:LangChain + WebShaper + Mem0
多Agent协同(规划Agent、执行Agent、审核Agent)
集成20+工具(数据库、API、浏览器操作)
- 优化:异常重试机制,成功率从70%→95%
并发处理,吞吐量提升5倍
- 成果:自动化率80%,效率提升3倍
节省人力成本200万/年,获部门最佳项目奖
- 技能:Agent开发、工具集成、系统监控
面试准备重点:
- 🏗️ 系统设计(高可用、高并发)
- ⚡ 性能优化(缓存、批处理)
- 🔧 工程实践(部署、监控、异常处理)
- 💼 业务理解(为什么这样设计)
🔀 通吃策略 - 如何准备?(⭐ 最推荐)
点击查看"通吃"完整准备方案
为什么推荐通吃?
- 机会翻倍:可同时投算法和开发岗
- 展现全栈:大模型时代,算法+工程都重要
- 灵活适配:大厂偏算法,创业公司偏工程
理想简历结构(3-4个项目):
项目1:算法创新型 🔬
→ 体现算法能力:Agent Memory优化 / Agentic RAG策略
→ 关键词:论文、实验、开源
项目2:系统落地型 🛠️
→ 体现工程能力:完整RAG系统 / Multi-Agent应用
→ 关键词:业务指标、性能优化、上线
项目3:微调/训练型(加分项)
→ 体现训练能力:Function Call微调 / RLHF
→ 关键词:多少卡、参数设置、训练稳定性
AgentGuide 的学习路径:
- 先学理论(第一部分)- 建立算法认知
- 再学工具(第二部分)- 掌握工程技能
- 做实战项目(第三部分)- 同时准备算法版和开发版
- 面试准备(第四部分)- 掌握两类面试技巧
📚 第三步:基于岗位的学习路线
根据你在"第一步"的选择,选择对应的学习路线
🎯 快速导航
🚀 新手推荐:
- 📘 AgentGuide开源学习路线(简易版) - 从零到Offer完整路径,8-15周系统化学习方案,包含完整资源清单 ⭐⭐⭐
🔬 算法 / 具身方向新增:
- 🧠 前沿算法岗位完整学习指南 - 覆盖算法岗从工程基础、模型训练、RAG/Agent、多模态到推理部署的完整能力栈
- 🤖 具身智能与 VLA 完整学习指南 - 面向 VLA/机器人岗位的多模态、动作建模、仿真、Sim2Real 与数据闭环路线
📋 详细路线(按岗位分):
🗺️ 选择你的学习路线
🔬 算法岗学习路线学习时长:10-15 周 难度:⭐⭐⭐⭐⭐ 产出:论文 + 开源项目 学习重点:
项目类型:
👉 查看详细路线图 |
🛠️ 开发岗学习路线学习时长:8-12 周 难度:⭐⭐⭐ 产出:完整系统 + 业务指标 学习重点:
项目类型:
👉 查看详细路线图 |
🗺️ 通用学习流程图
graph TD
A[开始学习 AI Agent] --> B{你的背景是什么?}
B -->|算法/研究背景| C[第一部分: 核心理论<br/>深入理解 Agent 原理]
B -->|开发/工程背景| D[第二部分: 核心技术栈<br/>快速上手开发框架]
C --> E[第二部分: 核心技术栈<br/>掌握工具和框架]
D --> F[第一部分: 核心理论<br/>补充理论基础]
E --> G[第三部分: 系统设计与实战<br/>完成简历项目]
F --> G
G --> H[第四部分: 面试指南<br/>准备求职]
H --> I{目标岗位?}
I -->|算法工程师| J[强化: 论文复现 + 实验设计<br/>准备算法面试题]
I -->|开发工程师| K[强化: 系统架构 + 性能优化<br/>准备系统设计题]
I -->|全栈 Agent 工程师| L[双线并进<br/>准备两类面试]
J --> M[投递简历 + 面试]
K --> M
L --> M
⏱️ 学习时间概览
| 学习路线 | 时长 | 每日投入 | 适合人群 |
|---|---|---|---|
| 🔬 算法岗路线 | 10-15周 | 4-6小时 | 有科研背景,想做创新 |
| 🛠️ 开发岗路线 | 8-12周 | 2-4小时 | 有工程背景,想做落地 |
💡 建议:点击上面的"查看详细路线图",获取每日学习计划和详细任务清单
💼 第四步:完成实战项目(可写进简历)
这是最重要的一步!没有项目,一切都是空谈!
AgentGuide 提供 简历级实战项目,每个项目都提供:
- ✅ 完整的代码实现
- ✅ 系统架构设计
- ✅ 算法岗和开发岗两种简历写法
- ✅ 面试时如何讲解
👉 直接跳转到实战项目:点击这里查看项目
🎓 第五步:系统学习 Agent 技术(技术准备)
💡 学习目标:掌握 Agent 开发完整技术栈,从理论到实战全覆盖 🔬 算法岗重点:深入理解原理,能推导公式,关注创新点 🛠️ 开发岗重点:熟练使用框架,快速实现功能,注重工程化
📊 技术能力四层模型
我们将 Agent 技术划分为四大能力层级,每个层级对应不同的学习模块:
📑 内容导航
| 章节 | 内容介绍 | 进展 |
|---|---|---|
| 🔰 L1-基础认知层 | 理解核心概念、掌握基本原理(1-2周) | |
| 模块1:Agent核心概念解析 | 智能体定义与分类体系、5级自主性模型 | |
| 模块2:技术演进历程与趋势洞察 | 从专家系统到神经网络的发展轨迹 | |
| 模块3:大模型工作原理 | Transformer/分词/训练/推理/对齐技术 | |
| 🛠️ L2-开发实现层 | 掌握框架工具、完成系统搭建(3-4周) | |
| 模块4:经典Agent范式手撕实现 | ReAct、Plan-Execute、Reflection模式 | |
| 模块5:低代码平台快速验证 | LangChain、Dify、Coze、n8n工具使用 | |
| 模块6:主流框架深度实战 | LangGraph、AutoGen、AgentScope、CrewAI | |
| 模块7:自研Agent框架设计原理 | 消息路由、工具注册、异常处理、日志追踪 | |
| 🚀 L3-高阶优化层 | 检索优化、上下文管理、模型训练(4-5周) | |
| 模块8:检索增强生成(RAG)全栈技术 | 数据预处理、索引构建、检索优化、高级RAG | |
| 模块9:上下文工程 | Write/Select/Compress/Isolate四大策略 | |
| 模块10:智能体通信标准与协议 | MCP、A2A、ANP协议详解 | |
| 模块11:模型微调与强化学习 | SFT、LoRA、PPO、DPO、GRPO算法应用 | |
| 模块12:性能评估与效果量化 | 评估维度、测试框架、自定义评估方法、🔥Anthropic评估完全指南 | ✅ |
🔰 L1-基础认知层详解
学习时长:1-2 周 | 难度:⭐⭐⭐ | 重要性:⭐⭐⭐⭐⭐
🎯 阶段目标
- ✅ 理解 Agent 的本质定义与核心组件
- ✅ 掌握 Transformer 架构与大模型基础
- ✅ 了解 Agent 技术发展历程与未来趋势
📚 学习内容
|
模块1:Agent 核心概念解析
|
模块2:技术演进历程与趋势洞察
|
||||||||||||||||||
|
模块3:大模型工作原理(Agent的大脑) Agent 的"大脑"是 LLM,理解大脑的工作原理是构建 Agent 的前提
📖 DeepSeek 系列完整深度笔记 🆕 📖 LLaMA 系列完整深度笔记 🆕 📖 Qwen 系列深度学习笔记 🆕 |
|||||||||||||||||||
🛠️ L2-开发实现层详解
学习时长:3-4 周 | 难度:⭐⭐⭐⭐ | 重要性:⭐⭐⭐⭐⭐
🎯 阶段目标
- ✅ 手撕核心 Agent 架构(ReAct、Plan-Solve、Reflexion)
- ✅ 掌握主流开发框架(LangChain、AutoGen、AgentScope)
- ✅ 能够独立搭建完整的 Agent 系统
🔨 实操内容
|
模块4:经典 Agent 范式手撕实现 从零实现三大核心模式: 1. ReAct 模式
2. Plan-Execute 模式
3. Reflection 模式
|
模块5:低代码平台快速验证 工具选型与使用: 1. 代码优先(Code-First)
2. 低代码/无代码(Low-Code)
|
||||||||||||||||||||
|
模块6:主流框架深度实战 框架能力对比与应用:
模块7:自研 Agent 框架设计原理 理解框架底层设计,培养自主开发能力:
|
|||||||||||||||||||||
🚀 L3-高阶优化层详解
学习时长:4-5 周 | 难度:⭐⭐⭐⭐⭐ | 重要性:⭐⭐⭐⭐⭐
🎯 阶段目标
- ✅ 掌握 RAG 全栈技术(数据处理、检索优化、高级 RAG)
- ✅ 精通上下文工程(Context Engineering 2.0)
- ✅ 理解 Agent 评估体系与微调方法
💡 高级技术
|
模块8:检索增强生成(RAG)全栈技术 8.1 数据预处理
8.2 索引构建与管理
8.3 检索策略优化
8.4 高级 RAG 架构
|
模块9:上下文工程(Context Engineering)⭐⭐⭐ "将海量信息中最相关的内容,精准放入有限上下文窗口的艺术" 核心策略 - The 4 Acts:
工程实践技巧:
常见问题修复:
|
||||||||||||||||
|
模块10:智能体通信标准与协议
|
|||||||||||||||||
|
模块11:模型微调与强化学习 从监督微调到强化学习的完整路径: 11.1 监督微调(SFT)
11.2 强化学习(RLHF)
11.3 Agent RL 应用
|
模块12:性能评估与效果量化 如何科学评估 Agent 性能? 评估维度:
评估框架:
自定义评估:
🔥 新增:AI Agent 评估完全指南
📖 评估指南:科学评估 Agent 📖 🔥 AI Agent 评估完全指南 (Anthropic官方万字长文) ⭐ 必读 |
||||||||||||||||
🛡️ 生产级系统设计(工程化实践)
高可用架构设计
- 缓存策略(Semantic Cache、KV Cache)
- 异步任务队列与重试机制
- 降级与熔断
可观测性(Observability)
- LangSmith/LangFuse 链路追踪
- 成本监控与 Token 审计
- 性能分析与优化
安全性(Security)
- Prompt 注入防御
- 权限控制与沙盒隔离
- 人机协作边界(Human-in-the-loop)
📖 安全性指南
💼 简历级实战项目 🚀
💡 学习目标:掌握复杂 Multi-Agent 系统设计,完成可写进简历的高质量项目 ⏱️ 学习时长:3-4 周 | 难度:⭐⭐⭐⭐⭐ | 重要性:⭐⭐⭐⭐⭐(简历核心)
🎯 核心收获
- ✅ 掌握复杂 Multi-Agent 系统设计
- ✅ 理解生产级系统的工程化实践
- ✅ 完成可写进简历的高质量项目
🎨 简历级实战项目详解
每个项目都提供完整代码 + 算法岗/开发岗双版本简历写法
🎯 简历项目详细教程
📄 项目一:自动化论文检索与分析 Agent(⭐ 推荐新手)
项目核心:为研究人员打造智能论文分析助手,整合 ArXiv 检索、多跳推理、自主规划等核心技术
适合场景:
- ✅ 面试 RAG 相关岗位(检索增强生成)
- ✅ 展示 Agentic 思维和系统设计能力
- ✅ 零基础友好,2-3周可完成
你将获得的核心能力:
|
🔬 算法线能力
|
🛠️ 工程线能力
|
技术栈:LangChain + Milvus + ArXiv API + GPT-4 + Redis
学习路径:
- ☐ 项目需求与技术选型 _(即将推出)_
- ☐ 系统架构设计 _(即将推出)_
- ☐ 核心代码实现 _(即将推出)_
- ☐ 部署与演示 _(即将推出)_
- ☐ 📝 如何写进简历?(算法岗 vs 开发岗)_(即将推出)_
📝 简历示例
|
算法岗写法:
|
开发岗写法:
|
🌍 项目二:旅行规划 Multi-Agent 系统(⭐ 适合展示协作能力)
项目核心:打造智能旅行助手,通过多Agent协作实现从需求分析到行程规划的完整闭环
适合场景:
- ✅ 面试 Multi-Agent 协作岗位
- ✅ 展示复杂任务分解与Agent编排能力
- ✅ 中等难度,适合有一定基础的同学
你将获得的核心能力:
|
🔬 算法线能力
|
🛠️ 工程线能力
|
技术栈:AutoGen / CrewAI + 天气API + 航班API + 酒店API + GPT-4
项目亮点:
- ✅ 3 个专业 Agent 协同工作(需求分析师、预算规划师、行程执行者)
- ✅ 层级式通信:Supervisor 模式 + 消息队列
- ✅ 智能决策:预算超支自动调整、天气影响行程变更
学习路径:
- ☐ 项目需求与技术选型 _(即将推出)_
- ☐ 系统架构设计 _(即将推出)_
- ☐ 核心代码实现 _(即将推出)_
- ☐ 部署与演示 _(即将推出)_
- ☐ 📝 如何写进简历?(算法岗 vs 开发岗)_(即将推出)_
🕷️ 项目三:Web Agent - 自主浏览与任务完成(⭐ 高级,适合冲刺大厂)
项目核心:打造能自主浏览网页、理解页面内容、完成复杂任务的智能Agent(如在线购物、表单填写)
适合场景:
- ✅ 面试顶级 Agent 岗位(字节、阿里等)
- ✅ 展示视觉理解 + 决策执行的完整能力
- ✅ 高级项目,适合冲刺大厂SP/SSP
你将获得的核心能力:
|
🔬 算法线能力
|
🛠️ 工程线能力
|
技术栈:Playwright + GPT-4V + LangChain + 强化学习(PPO)
项目亮点:
- ✅ 视觉理解 + 操作执行的完整闭环
- ✅ 基于反馈的自我修正机制(识别错误 → 分析原因 → 调整策略)
- ✅ 在 WebArena 基准测试上达到 75% 成功率(超越 Baseline 10%)
学习路径:
- ☐ 项目需求与技术选型 _(即将推出)_
- ☐ 系统架构设计 _(即将推出)_
- ☐ 核心代码实现 _(即将推出)_
- ☐ 部署与演示 _(即将推出)_
- ☐ 📝 如何写进简历?(算法岗 vs 开发岗)_(即将推出)_
📂 项目四:优质 Agent 实战开源项目、Workflow 项目与 Agent 项目集合
项目核心:整理分享一些优质的 Agent 实战开源项目、Workflow 项目与 Agent 项目集合
包含内容:
🧳 项目五:智能旅行助手 - Multi-Agent 协作系统(⭐ 适合展示协作能力)
项目核心:打造智能旅行助手,通过多Agent协作实现从需求分析到行程规划的完整闭环
适合场景:
- ✅ 面试 Multi-Agent 协作岗位
- ✅ 展示复杂任务分解与Agent编排能力
- ✅ 中等难度,适合有一定基础的同学
你将获得的核心能力:
|
🔬 算法线能力
|
🛠️ 工程线能力
|
技术栈:AutoGen / CrewAI + 天气API + 航班API + 酒店API + GPT-4
项目亮点:
- ✅ 3 个专业 Agent 协同工作(需求分析师、预算规划师、行程执行者)
- ✅ 层级式通信:Supervisor 模式 + 消息队列
- ✅ 智能决策:预算超支自动调整、天气影响行程变更
- ✅ MCP 协议集成实践
学习路径:
- ☐ 项目需求与技术选型 _(即将推出)_
- ☐ 系统架构设计 _(即将推出)_
- ☐ 核心代码实现 _(即将推出)_
- ☐ 部署与演示 _(即将推出)_
- ☐ 📝 如何写进简历?(算法岗 vs 开发岗)_(即将推出)_
🔬 项目六:自动化深度研究智能体(⭐ 适合科研方向)
项目核心:复现 DeepResearch Agent,打造自动化文献检索与分析系统
适合场景:
- ✅ 面试 AI 研究助手相关岗位
- ✅ 展示复杂工作流设计与知识整合能力
- ✅ 高级项目,适合有科研背景的同学
你将获得的核心能力:
|
🔬 算法线能力
|
🛠️ 工程线能力
|
技术栈:LangGraph + ArXiv API + Semantic Scholar + GraphRAG + GPT-4/Claude
项目亮点:
- ✅ 复现 DeepResearch Agent 核心功能
- ✅ 自动化文献检索与分析(日均处理100+论文)
- ✅ 知识图谱自动构建与可视化
- ✅ 研究报告自动生成(3000+字深度报告)
学习路径:
- ☐ 项目需求与技术选型 _(即将推出)_
- ☐ 系统架构设计 _(即将推出)_
- ☐ 核心代码实现 _(即将推出)_
- ☐ 部署与演示 _(即将推出)_
- ☐ 📝 如何写进简历?(算法岗 vs 开发岗)_(即将推出)_
🎮 项目七:桌游小镇社会模拟 - 大规模Agent系统(⭐ 高级,展示系统设计能力)
项目核心:构建25个Agent角色的社会模拟系统,探索复杂社交网络与记忆机制
适合场景:
- ✅ 面试大规模Agent系统设计岗位
- ✅ 展示社交模拟与记忆系统设计能力
- ✅ 高级项目,适合冲刺大厂
你将获得的核心能力:
|
🔬 算法线能力
|
🛠️ 工程线能力
|
技术栈:自定义 Agent 框架 + SQLite + 事件驱动架构 + 可视化界面
项目亮点:
- ✅ 25 个 Agent 角色自主交互与演化
- ✅ 记忆与关系网络动态管理
- ✅ 复杂社交行为模拟(友谊、竞争、合作)
- ✅ 可视化展示社交网络演化过程
学习路径:
- ☐ 项目需求与技术选型 _(即将推出)_
- ☐ 系统架构设计 _(即将推出)_
- ☐ 核心代码实现 _(即将推出)_
- ☐ 部署与演示 _(即将推出)_
- ☐ 📝 如何写进简历?(算法岗 vs 开发岗)_(即将推出)_
🎓 项目八:毕业设计 - 综合实战项目(⭐⭐⭐ 必做)
项目核心:综合运用所学知识,构建属于你的完整 Agent 应用
适合场景:
- ✅ 所有同学必做
- ✅ 简历核心项目
- ✅ 面试必讲项目
设计要求:
- ✅ 选择真实业务场景(RAG/自动化/研究助手等)
- ✅ 端到端系统设计(需求分析 → 架构设计 → 实现 → 优化 → 部署)
- ✅ 包含量化评估(构建测试集、性能指标、成本分析)
- ✅ 生产级考虑(异常处理、监控告警、成本优化)
- ✅ 可写进简历(提供算法岗和开发岗两种描述版本)
推荐方向:
|
🔬 算法岗方向
|
🛠️ 开发岗方向
|
核心产出:
- ✅ 完整的系统设计文档
- ✅ 可运行的代码实现
- ✅ 性能评估报告
- ✅ 算法岗 + 开发岗双版本简历描述
- ✅ 面试讲解准备材料
💼 第六步:面试准备与 Offer 冲刺
💡 学习目标:系统准备面试,提升 Offer 成功率 📝 两条线不同的面试策略:算法岗讲创新,开发岗讲价值
📚 完整面试题库(1500+题/面经)🔥 全面升级
🎯 题库特色: - ✅ 完整覆盖 LLM/VLM/RLHF/RAG/Agent 全技术栈 - ✅ 包含美团、字节、阿里、DeepSeek等一线大厂真题 - ✅ 难度分级 + 公司来源标注 + 考点分析 - ✅ 区分算法岗/开发岗重点,覆盖最新技术(DeepSeek-V3/R1)
📖 核心通用题库(两个岗位都需要)
|
理论基础(必学)
RAG系统(开发岗重点)
|
Agent开发(核心)
编程实战(必备)
|
🎯 岗位专项题库(针对性强化)
🏢 真实面经与进阶
- ☑ 🧭 面试与求职总导航 - 按岗位选择题库,提供 7/21/42 天备考节奏与项目证据清单
- ☑ 🔥 2026 AI 前沿面试专题 🆕 - 自进化 Agent、Agentic RL、AI Infra、数据评测、Coding Agent、世界模型、图像/语音生成、项目深挖
- ☑ 📋 大厂真实面经 - 美团/字节/阿里等16个完整案例
- ☑ 🧭 AI Agent 面试备战手册合集 - Memory、Skills、Harness、评估、数据合成、源码分析与项目话术
- ☑ 📚 1000篇小红书AI算法岗面经:难度递增整合版 🆕 - 按编程、ML/DL、RAG/Agent、多模态、系统设计等难度递增整理
- ☑ 📊 模型评估专题 - BLEU/ROUGE、基准测试、LLM-as-Judge 10题
- ☑ 🔮 前景与趋势 - AGI、多模态、世界模型等开放讨论 9题
- ☑ 💬 开放性讨论 - 技术判断、学习建议、核心素质 8题
💡 题库使用建议
第一阶段(2-3周):系统学习
├─ 01-理论基础题(LLM/VLM/RLHF)→ 打基础
├─ 02-RAG系统题 → 掌握检索技术
└─ 03-Agent核心题(Q1-Q13)→ 理解Agent原理
第二阶段(2-3周):深入强化
├─ 03-Agent系统题(Q14-Q52)→ 工程实践
├─ 05/06-岗位专项 → 针对性准备
└─ 04-编程实战题 → 手撕代码
第三阶段(1-2周):冲刺突破
├─ 12-真实面经 → 模拟完整面试
├─ 13-模型评估 → 掌握评估方法
└─ 14/15-开放讨论 → 展示思维深度
求职软技能
📄 专业简历模板(新增⭐)
🎨 开源 LaTeX 简历模板 - 专为转行大模型设计
|
模板特色:
适合人群:
|
🔗 获取模板: 快速开始:
模板包含:
|
面试软技能(新增⭐)
- ☑ ⭐ 校招生谈薪实用指南 - 3大原则、话术模板
- ☑ ⭐ HR面试完全攻略 - 10大高频问题应对
- ☑ ⭐ 秋招心态调整指南 - 保持好心态拿Offer
4.3 核心资源精选(按方向分类)
📌 只推荐面试会考、项目会用的核心资源!
🤖 Agent 方向:
- ☑ Agent 资源总览 📂 - Agent 所有资源导航
- Agent 框架对比 - 5个核心框架
- Memory 模块 - 4个记忆系统
- Tool Use - 工具调用
- GUI Agent - AppAgent、SeeAct、WebArena 等界面操作资源
- 核心论文 - 必读论文
📊 RAG 方向:
- ☑ RAG 资源总览 📂 - RAG 所有资源导航
- 向量数据库 - 5个核心向量库
- 文档解析 - 5个解析工具
- 完整项目汇总 - 150+个RAG开源项目 🆕
- Agentic RAG 论文 - 智能体驱动的检索与研究
- 核心论文 - 必读论文
🛠️ 通用工具:
🎨 推荐可视化学习资源:
- 📊 100+ LLM/RL 算法原理图 - 《大模型算法:强化学习、微调与对齐》作者巨献
- 涵盖内容:Transformer架构、注意力机制、SFT微调、LoRA/QLoRA、DPO/PPO/GRPO、RLHF全流程、逻辑推理优化等
- 适合人群:算法岗必看!通过100+原创原理图深入理解大模型算法的数学原理和实现细节
- 配套书籍:《大模型算法:强化学习、微调与对齐》
🌟 需要更全面的 LLM 资源? 👉 查看作者的另一个项目:Awesome-Awesome-LLMs (涵盖训练、推理、多模态、Infra 等 LLM 全栈 200+ Awesome 系列资源)
🚀 快速开始
1️⃣ 如果你是算法背景(10 分钟快速入门)
# 第一步:理解 Agent 是什么
阅读:docs/01-theory/01-what-is-agent.md
# 第二步:学习核心框架 ReAct
阅读:docs/01-theory/04-react-framework.md
2️⃣ 如果你是开发背景(10 分钟快速入门)
# 第一步:理解 Agent 核心概念
阅读:docs/01-theory/01-what-is-agent.md
🤝 如何贡献
AgentGuide 是一个完全开源的项目,非常欢迎你的贡献!
贡献方式
- 内容贡献:完善文档、补充案例、纠正错误
- 代码贡献:优化示例代码、添加新的实战项目
- 翻译贡献:帮助翻译成英文版,让更多人受益
- 问题反馈:发现问题?请提 Issue
贡献流程
- Fork 本仓库
- 创建你的特性分支 (
git checkout -b feature/AmazingFeature) - 提交你的修改 (
git commit -m 'Add some AmazingFeature') - 推送到分支 (
git push origin feature/AmazingFeature) - 提交 Pull Request
详细贡献指南请参考:CONTRIBUTING.md
📬 联系作者 & 加入社群
👨💻 关于作者
我是阿东,一线大模型算法工程师
- 🎓 技术背景:专注 AI、RAG、LLM 应用方向
- 📝 内容创作:全网 5w+ 粉丝,持续分享 AI 技术与求职经验
- 🚀 开源贡献:多个 AI 相关开源项目维护者
🌐 在这些平台找到我
📱 小红书阿东玩AI短视频教程 + 技术拆解 |
📝 公众号阿东玩AI深度技术文章 + 求职经验 |
🎬 B站阿东玩AI视频教程 + 项目实战 |
💻 GitHub@adongwanai开源项目 + 代码示例 |
💬 加入 AI Agent 学习社群
为什么要加入社群?

- ✅ 每周技术分享:Agent 最新论文解读、工程实践经验
- ✅ 简历面试辅导:免费简历诊断、模拟面试、内推机会
- ✅ 问题实时答疑:技术问题、求职困惑,随时提问
- ✅ 学习小组:组队学习 AgentGuide,互相监督,共同进步
- ✅ 行业资源:大厂内推信息、技术资料、论文分享
如何加入?
- 关注公众号「阿东玩AI」,回复「AgentGuide」获取入群二维码
- 小红书@阿东玩AI,私信"加群"
GitHub Issues 仅用于可复现的仓库问题和有明确交付物的核心改进,不处理加群申请。
🎁 社群福利:Agent 学习路线图 PDF + 面试题库 + 项目代码模板 + 大厂内推机会
⭐ 如果这个项目对你有帮助
请考虑支持一下:
- ⭐ Star 本仓库,让更多人看到
- 🔀 Fork 本仓库,开始你的学习之旅
- 📣 分享 给正在找 AI 工作的朋友
- 💬 反馈 你的建议和意见(提 Issue 或 PR)
你的每一个 Star 都是我持续更新的动力!🚀
🚀 开始你的 AI Agent 学习之旅吧!
从这一刻起,距离你拿到 AI Agent Offer 只有 8-10 周
⭐⭐⭐ 如果觉得有帮助,请给个 Star!⭐⭐⭐
你的 Star 是我持续更新的最大动力
转行大模型,看阿东玩AI
📈 Star History
learning roadmap development
type: 路线图 status: 已发布 level: 通用 topic:
- 面试求职
- Agent
- 项目实战
AI Agent 开发工程师学习路线图(工程落地版)
目标岗位:AI Agent 开发工程师(应用型、工程型) 学习时长:8 周(全职投入) 最终产出:2-3 个生产级、可部署的 Agent 系统 + 完整的全栈技术能力
一、你能获得什么
用8周,打造从原型到生产的完整工程能力 ✅ 8周系统课程:从 LangChain 基础到生产级 Agent 系统架构 ✅ 每周代码实战:手撕 RAG、Agent、多智能体,将想法变为高可用服务 ✅ 2个工业级项目:完成从需求分析、技术选型、开发部署到监控优化的全流程 ✅ 生产级技术栈:掌握 FastAPI, Docker, Redis, Prometheus 等后端必备技能 ✅ 顶级面试能力:搞定系统设计、性能优化、故障排查等高频面试题
二、开发岗核心要求
你需要具备的能力
|
系统设计
|
工程实现
|
业务理解
|
开发岗简历必备
✅ 至少2个完整系统项目:端到端可运行,有线上部署经验 ✅ 量化的业务指标提升:如 QPS+100%、P99延迟-80%、成本-50% 等数据 ✅ 丰富的生产级技术栈:LangChain + FastAPI + Milvus + Redis + Docker + Prometheus ✅ 生产化经验:有部署、监控、性能优化、异常处理的实战经历
三、推荐学习资源与工具
📚 核心课程与书籍
- 课程: 吴恩达: Generative AI for Everyone
- 课程: 微软: Generative AI for Beginners
- 课程: HuggingFace NLP Course
- 教程: 《动手学大模型应用开发》 - Datawhale开源教程
- 教程: 《面向开发者的 LLM 入门教程》 - 吴恩达课程中文版
- 教程: 《开源大模型食用指南》 - 快速微调与部署教程
- 教程: 《AI-Guide-and-Demos》 - API到本地部署微调指南
- 书籍: 《Build a Large Language Model (From Scratch)》
🛠️ 开发框架与工具
- LLM框架: LangChain, LlamaIndex, Dify
- Agent框架: AutoGen, CrewAI, AgentScope
- 向量数据库: Milvus, Qdrant, Chroma
- 推理引擎: vLLM, SGLang, Ollama
- 评估工具: RAGAs, DeepEval, LangSmith
🌐 学习社区与资源
- 社区: HuggingFace, ModelScope, 魔乐社区
- 博客: Lil'Log (OpenAI), 科学空间(苏剑林), Chip Huyen
- 资源库: Awesome LLM Resources
- 可视化: 100+ LLM/RL 算法原理图 - 通过图解理解算法原理
- 可视化: Interactive Transformer Explainer - 交互式理解Transformer
四、8周详细学习计划
第 1 周:大模型应用开发基础 + 手撕 Naive RAG
学习内容: - 后端基础: FastAPI 路由、异步 I/O、Pydantic 数据校验 - LangChain 核心: LLM, Prompt Templates, Output Parsers, LCEL - Naive RAG 流程: Document Loaders, Text Splitters, Embeddings, Vector Stores - 向量数据库: FAISS/ChromaDB 本地化使用 手撕系列: - [ ] FastAPI 搭建 "Hello, World" API 服务 - [ ] LangChain LCEL 编写第一个 LLM Chain - [ ] 30分钟手撕一个完整的 Naive RAG 应用 解锁技能: - 熟练使用 FastAPI 搭建 API - 掌握 LangChain 核心组件与 LCEL 表达式语言 - 能够从零开始,快速构建一个基于文档问答的 RAG Demo
🌟 每日学习计划
| 天数 | 学习主题 | 资源链接 | 目标 |
|---|---|---|---|
| 1 | FastAPI 快速入门 | 教程: FastAPI Official Tutorial | 掌握 FastAPI 基础,能够创建路由、处理请求 |
| 2 | LangChain 核心概念 | 文档: LangChain Quickstart 课程: 吴恩达: LangChain for LLM Application Development 课程: Building Systems with the ChatGPT API | 理解 LangChain 六大核心模块,熟练使用 LCEL |
| 3 | RAG Part 1: 加载与分割 | 文档: LlamaIndex Loaders 工具: Unstructured.io, MinerU, Docling | 掌握不同格式文档 (PDF, MD) 的加载和文本分块策略 |
| 4 | RAG Part 2: 向量化与存储 | 教程: FAISS Intro 教程: Sentence Transformers | 理解 Embedding 原理,使用 FAISS/Chroma 构建本地向量索引 |
| 5-6 | 手撕 Naive RAG 系统 | 教程: RAG from Scratch 概念: LLM Powered Autonomous Agents 教程: 动手学大模型应用开发 参考: 面向开发者的LLM入门教程 | 整合 FastAPI + LangChain,完成一个端到端的文档问答 API |
| 7 | 周度总结与项目部署 | 将本周的 RAG 项目用 Docker 打包,并成功运行 |
第 2 周:Advanced RAG 与生产级向量数据库
学习内容: - Advanced RAG 技术: Query Transformation, Re-ranking, Hybrid Search - RAG 评估: 使用 RAGAs, TruLens 进行自动化评估 - 生产级向量数据库: Milvus/Zilliz Cloud 部署与使用 - 数据处理: Unstructured.io 解析复杂文档 手撕系列: - [ ] 实现 BM25 + 向量的混合检索 - [ ] 引入 Cohere Rerank 模型提升检索精度 - [ ] 使用 RAGAs 评估 RAG 系统的 Faithfulness 和 Answer Relevancy - [ ] Docker 部署 Milvus 并进行增删改查操作 解锁技能: - 掌握 10+ 种 RAG 优化策略 - 能够建立 RAG 系统的自动化评估流水线 - 熟练使用生产级的分布式向量数据库 Milvus - 具备处理复杂、非结构化文档的能力
🌟 每日学习计划
| 天数 | 学习主题 | 资源链接 | 目标 |
|---|---|---|---|
| 8 | Query Transformation | 教程: LlamaIndex Query Transformations | 实现 HyDE, Multi-Query 等查询改写策略 |
| 9 | 混合检索与重排 (Rerank) | 教程: LlamaIndex Cohere Rerank 论文: Modular RAG | 实现 BM25 + Embedding 混合检索,并集成 Reranker |
| 10-11 | RAG 评估体系 | 文档: RAGAs 评估框架 工具: FlashRAG, DeepEval, Lighteval | 学习 RAG 核心评估指标,并用 RAGAs 评估优化前后的系统性能 |
| 12 | 生产级向量数据库 (Milvus) | 文档: Milvus Quick Start 替代: Infinity, Qdrant | 使用 Docker 部署 Milvus,并掌握其 Python SDK |
| 13 | 高级数据处理 | 文档: Unstructured.io 工具: MinerU, PDF-Extract-Kit, Docling, GOT-OCR2.0 | 使用 Unstructured/MinerU 解析包含表格、图片的复杂 PDF |
| 14 | 周度总结与系统升级 | 将第一周的 RAG 系统升级,集成混合检索、Reranker 和 Milvus |
第 3 周:Agent 开发与 Tool Calling
学习内容: - Agent 核心: ReAct 框架, Planning, Tool Use, Memory - Tool Calling: OpenAI Function Calling, Tool Schema 定义 - 工具开发: 如何将 API, 数据库查询等封装为 Agent 可用的工具 - 错误处理: 工具调用失败的重试、降级策略 手撕系列: - [ ] 实现 3个 自定义工具 (天气查询, SQL数据库查询, API调用) - [ ] 基于 LangChain 构建一个可以链式调用工具的 Agent - [ ] 使用 OpenAI Function Calling 实现结构化数据提取 解锁技能: - 深刻理解 Agent 的"思考-行动"工作流 - 能够开发、测试、维护自定义工具集 - 掌握 Function Calling 的原理与应用 - 具备构建能处理真实世界任务的 Agent 的能力
🌟 每日学习计划
| 天数 | 学习主题 | 资源链接 | 目标 |
|---|---|---|---|
| 15 | Agent 核心概念 | 博客: LLM Powered Autonomous Agents 文档: LangChain Agents 论文: ReAct | 理解 ReAct 框架,并运行一个 LangChain 官方的 Agent 示例 |
| 16 | 自定义工具开发 | 教程: LangChain Custom Tools 参考: MCP协议, MCP教程 | 编写一个查询天气的自定义工具,并集成到 Agent 中 |
| 17 | SQL & 数据库工具 | 教程: LangChain SQL Agent | 构建一个能根据自然语言查询数据库的 SQL Agent |
| 18 | Function Calling 实战 | 文档: OpenAI Function Calling 指南: GPT Best Practices | 使用 OpenAI API 实现一个能根据用户问题调用函数的 Agent |
| 19 | Agent Memory | 文档: LangChain Memory 工具: Mem0, MemoryScope | 为 Agent 添加对话历史记忆 (ConversationBufferMemory) |
| 20 | Agent 错误处理 | 教程: Error Handling in Agents | 为工具调用添加重试机制 (tenacity 库) 和降级策略 |
| 21 | 周度总结与项目构建 | 构建一个集成 RAG 和 Web 搜索工具的 "研究助手" Agent |
第 4 周:系统性能优化
学习内容: - 缓存策略: Redis 缓存 LLM 响应和 Embedding 结果 - 异步处理:asyncio,aiohttp实现高并发 - 批处理优化: Embedding 和 LLM 调用的批处理 - 推理加速: vLLM, TensorRT-LLM 部署与使用 手撕系列: - [ ] 为 RAG 系统引入 Redis 缓存,对比优化前后性能 - [ ] 将 FastAPI 的同步接口改造为异步接口 - [ ] 部署 vLLM 并通过 API 进行推理 解锁技能: - 掌握 LLM 应用的核心性能优化手段 - 能够将系统的 QPS 提升 10 倍以上 - 熟练使用 Redis 进行缓存设计 - 具备部署和使用高性能推理引擎的能力
🌟 每日学习计划
| 天数 | 学习主题 | 资源链接 | 目标 |
|---|---|---|---|
| 22 | 性能瓶颈分析 | 工具: py-spy, Scalene | 学习使用 cProfile, py-spy 等工具分析现有 Agent 系统的性能瓶颈 |
| 23 | 缓存优化 (Redis) | 教程: FastAPI with Redis 工具: LiteLLM Caching | 为 Agent 系统添加 Redis 缓存,缓存 LLM 响应 |
| 24-25 | 异步处理 (Async) | 教程: FastAPI Async 示例: LangChain Async | 将系统中 I/O 密集型操作 (如 API 调用) 改造为异步 |
| 26 | 批处理优化 (Batching) | 教程: Batch Processing | 实现 Embedding 和 Reranker 的批处理,提升吞吐量 |
| 27 | 高性能推理 (vLLM) | 文档: vLLM Quickstart 替代: SGLang, TensorRT-LLM, LMDeploy 概览: Awesome Inference | 使用 vLLM 部署一个开源模型 (如 Llama 3),并测试其吞吐量 |
| 28 | 周度总结与性能压测 | 使用 locust 或 jmeter 对优化前后的系统进行压测,并记录 QPS, P99 等指标 |
第 5 周:监控、可观测性与部署
学习内容: - Agent 链路追踪: LangSmith, OpenTelemetry - 指标监控: Prometheus 监控业务和系统指标 - 可视化: Grafana 创建监控大盘 - 日志系统: ELK Stack (Elasticsearch, Logstash, Kibana) - 容器化部署: Docker, Docker Compose 手撕系列: - [ ] 为 Agent 应用集成 LangSmith,追踪每一步的调用和延迟 - [ ] 使用 Prometheus 暴露自定义指标 (如 Token 消耗, 缓存命中率) - [ ] 使用 Docker Compose 将 FastAPI + Milvus + Redis 整套系统一键部署 解锁技能: - 具备构建完整 LLM 应用可观测性体系的能力 - 能够快速定位和诊断线上问题 - 掌握基于 Docker 的容器化部署和编排 - 拥有完整的 DevOps for LLM Apps 经验
🌟 每日学习计划
| 天数 | 学习主题 | 资源链接 | 目标 |
|---|---|---|---|
| 29 | 链路追踪 (LangSmith) | 文档: LangSmith 替代: OpenTelemetry, LangFuse | 将 LangSmith 集成到现有 Agent 应用中,分析调用链路 |
| 30 | 指标监控 (Prometheus) | 教程: Prometheus Python Client 集成: FastAPI Instrumentator | 暴露 API 的 QPS, 延迟, 错误率等核心指标 |
| 31 | 可视化 (Grafana) | 教程: Grafana Dashboard | 安装 Grafana,并创建一个简单的监控大盘来展示 Prometheus 指标 |
| 32 | 容器化 (Docker) | 教程: Docker for FastAPI 最佳实践: Docker Best Practices | 为 FastAPI 应用编写 Dockerfile 并成功构建镜像 |
| 33 | 服务编排 (Docker Compose) | 教程: Docker Compose 示例: Full Stack FastAPI | 编写 docker-compose.yml 文件,一键启动整个应用栈 |
| 34 | 日志系统 | 教程: Python Logging 工具: Loguru, structlog | 配置应用将日志输出为 JSON 格式,为接入 ELK 做准备 |
| 35 | 周度总结与生产环境模拟 | 模拟一次线上故障,并使用本周学习的工具链进行问题定位 |
第 6 周:Multi-Agent 系统开发
学习内容: - Multi-Agent 框架: AutoGen vs. CrewAI - Agent 角色定义: 如何设计具有不同职责和能力的 Agent - 通信机制与工作流: GroupChat, Sequential/Hierarchical flow - 状态管理: 如何在多个 Agent 之间共享和传递状态 手撕系列: - [ ] 使用 AutoGen 构建一个“研究员-程序员-测试员”协作的软件开发团队 - [ ] 使用 CrewAI 构建一个“旅行规划师-本地向导-预订专员”的旅行 Agent 解锁技能: - 掌握至少两种主流的 Multi-Agent 开发框架 - 能够根据复杂业务需求,设计和实现多智能体协作系统 - 理解不同协作模式 (如层级式 vs. 对话式) 的优缺点
🌟 每日学习计划
| 天数 | 学习主题 | 资源链接 | 目标 |
|---|---|---|---|
| 36-37 | AutoGen 核心概念 | 文档: AutoGen Tutorial 论文: AutoGen Framework | 学习 ConversableAgent, GroupChat 等核心概念,并运行官方示例 |
| 38 | AutoGen 实战 | 示例: AutoGen Examples | 实现一个"研究员-程序员-测试员"的 Multi-Agent 系统 |
| 39-40 | CrewAI 核心概念 | 文档: CrewAI Docs 教程: CrewAI Quickstart | 学习 Agent, Task, Crew, Process 的概念,并运行官方示例 |
| 41 | CrewAI 实战 | 示例: CrewAI Examples | 实现一个"旅行规划师-本地向导-预订专员"的 Multi-Agent 系统 |
| 42 | 框架对比与总结 | 更多框架: agentUniverse, AgentScope, Qwen-Agent, Lagent, PraisonAI 概览: Awesome Agents | 对比 AutoGen 和 CrewAI 的设计哲学、优缺点和适用场景 |
第 7-8 周:工业级项目实战与面试准备
核心目标:完成 1-2 个可写进简历的完整系统,并准备面试。
项目1:企业级智能客服 RAG 系统
业务场景: 为某电商公司构建智能客服系统,自动回答 80% 的重复性用户问题 (订单状态、物流、退款等)。 技术要求: - 数据源: 对接 FAQ 文档、商品信息数据库 (PostgreSQL)。 - 核心: 实现一个混合检索 RAG,优先从数据库精确查询,无法命中再从文档模糊检索。 - 性能: 系统 QPS > 200, P99 延迟 < 500ms。 - 监控: 完整的 LangSmith + Prometheus + Grafana 监控体系。 - 部署: 使用 Docker Compose 部署。 简历亮点: 高并发、低延迟、生产级监控、节省XX人力成本。
项目2:Agent 驱动的自动化投研系统
业务场景: 为投资分析师构建自动化报告生成 Agent,输入公司名,自动完成信息搜集、分析和报告撰写。 技术要求: - Multi-Agent: 使用 CrewAI 构建,包含信息搜集Agent(调用搜索引擎、API)、财报分析Agent(解析PDF财报、计算关键指标)、报告撰写Agent。 - 工具集: 集成 Google Search, SEC API, 文件读写等至少 5 个工具。 - 稳定性: 强大的异常处理和重试机制,任务成功率 > 95%。 - 工作流: 设计一个顺序工作流,并记录每一步的中间产出。 简历亮点: Multi-Agent 协作、复杂工作流自动化、为分析师提升XX%工作效率。
🌟 学习计划 (2周)
| 天数 | 学习主题 | 目标 | |
|---|---|---|---|
| 43-47 | 项目一:智能客服 RAG | 完成需求分析、架构设计、核心功能开发 | |
| 48-51 | 项目一:优化与部署 | 完成性能优化、监控集成和 Docker 部署,撰写项目文档 | |
| 52-56 | 项目二:自动化投研 Agent | 完成需求分析、Agent 设计、工具开发和工作流实现 | |
| 57-58 | 简历撰写与项目总结 | 指南: Tech Resume Guide 参考: AI面试指南 | 按照开发岗模板,将两个项目经历量化地写入简历 |
| 59-60 | 系统设计与面试 Mock | 资源: OpenAI Cookbook, GPT Best Practices 题库: LLM系统设计面试题 课程: LLM Evaluation: A Complete Course | 准备高频系统设计题,并进行 1v1 模拟面试 |
📚 核心学习资源推荐
精选业界最优质的学习资源,助你快速提升工程能力
🤖 智能体开发
- ⭐ 推荐指数: ★★★★★
- 📖 内容: Agent 开发完整教程,从基础到进阶
- 🎯 适合: 快速上手 Agent 开发,掌握框架使用
- 💡 亮点: 中文友好、实战导向、案例丰富
📊 RAG 系统搭建
- ⭐ 推荐指数: ★★★★★
- 📖 内容: RAG 系统完整实现,涵盖文档解析、检索、生成
- 🎯 适合: 构建企业级 RAG 系统、性能优化
- 💡 亮点: 完整代码、最佳实践、生产级方案
🔧 模型微调(可选)
- ⭐ 推荐指数: ★★★★☆
- 📖 内容: 快速微调工具,降低资源消耗
- 🎯 适合: 需要快速微调、资源有限的场景
- 💡 亮点: 速度快、易上手、成本低
- ⭐ 推荐指数: ★★★★★
- 📖 内容: Web UI 微调平台,支持 SFT、LoRA、DPO
- 🎯 适合: Function Call 微调、模型定制化
- 💡 亮点: 可视化界面、功能全面、易于使用
🗃️ 数据处理
- ⭐ 推荐指数: ★★★★☆
- 📖 内容: 数据清洗、格式转换、质量评估
- 🎯 适合: RAG 数据准备、知识库构建
- 💡 亮点: 自动化工具、提升数据质量
🧠 理解大模型原理(加分项)
- ⭐ 推荐指数: ★★★★★
- 📖 内容: 从零实现 GPT,理解模型原理
- 🎯 适合: 深入理解 LLM 工作机制、面试加分
- 💡 亮点: 代码简洁、注释详细、理解本质
- ⭐ 推荐指数: ★★★★☆
- 📖 内容: 从零构建对话模型
- 🎯 适合: 理解对话系统、端到端实现
- 💡 亮点: 完整流程、实战导向
🎯 完整学习路径
- ⭐ 推荐指数: ★★★★★
- 📖 内容: Agent 开发、RAG 系统、上下文工程、面试指南
- 🎯 适合: 系统化学习、求职准备、技术路线规划
- 💡 亮点: 开发岗/算法岗双路线、实战项目、简历模板
💡 学习建议
入门阶段(第1-2周)
- 先学习 Hello-Agents 建立 Agent 开发基础
- 浏览 nanoGPT 了解模型原理(可选)
进阶阶段(第3-6周)
- 深入 All-in-RAG 学习 RAG 系统搭建
- 使用 LLaMA-Factory 进行 Function Call 微调(可选)
- 用 Easy-Dataset 处理数据
实战阶段(第7-8周)
- 参考 AgentGuide 完成项目
- 构建完整的生产级系统
- 准备面试和简历
🛠️ 推荐技术栈组合
RAG 系统项目
后端: FastAPI + LangChain + Milvus/Chroma
数据处理: Easy-Dataset
监控: LangSmith + Prometheus + Grafana
部署: Docker + Docker Compose
Multi-Agent 项目
框架: CrewAI / AutoGen / LangGraph
工具: LangChain Tools + Custom Tools
工作流: State Machine + Task Queue
监控: LangSmith + 自定义日志
👉 返回主文档:README.md
learning roadmap algorithm
type: 路线图 status: 已发布 level: 通用 topic:
- 面试求职
- Agent
- 模型训练
AI Agent 算法工程师学习路线图(研究型)
目标岗位:AI Agent 算法工程师(研究/创新型) 学习时长:9 周(全职投入) 最终产出:1-2 个算法创新型项目 + 1 篇高质量论文/高星开源项目
一、你能获得什么
时间紧迫!用9周,打造从理论到创新的完整算法能力 ✅ 9周系统学习:从经典论文到前沿算法,构建坚实的理论体系 ✅ 每周代码实战:手撕核心算法,将理论转化为代码 ✅ 2个创新项目:完成从问题定义、算法设计到实验分析、论文撰写的完整科研流程 ✅ 独享学习路径:专为算法研究岗定制,区别于应用开发岗 ✅ 顶级面试能力:掌握算法岗面试核心,从容应对深度追问 ✅ 科研产出能力:完成具备顶会投稿/高星开源水平的创新项目
二、算法岗核心要求
你需要具备的能力
|
理论深度
|
实验能力
|
产出能力
|
算法岗简历必备
✅ 至少1篇高质量论文:顶会/顶刊在投或已发表 ✅ 至少1个高星开源项目:300+ Stars 且有持续维护 ✅ 2-3个算法深度优化项目:有严谨的实验数据支撑 ✅ 扎实的理论基础:能从第一性原理层面回答深度问题
三、推荐学习资源与工具
📚 核心课程与书籍
- 课程: 《动手学深度学习》 - 深度学习基础的最佳入门
- 课程: 清华大模型公开课第二季 - 系统了解大模型历史与前沿
- 课程: Stanford CS224N: NLP with Deep Learning - NLP经典课程
- 书籍: 《大语言模型》 - 大模型最佳中文书籍
- 书籍: 《Build a Large Language Model (From Scratch)》 - 从零构建大模型
- 教程: 《动手学大模型Dive into LLMs》 - 上海交大编程实践教程(含PPT、视频)
- 教程: 《面向开发者的 LLM 入门教程》 - 吴恩达课程中文版
- 教程: 《从零开始的大语言模型原理与实践》 - Datawhale系统教程
📝 必读论文
- 基础: "Attention Is All You Need" - Transformer开山之作
- Agent: ReAct, Reflexion, Tree of Thoughts
- RAG: DPR, Self-RAG, GraphRAG
- RL: DPO, GRPO, DeepSeek-R1
🛠️ 研究工具与框架
- 训练框架: LLaMA-Factory, TRL, OpenRLHF
- 微调教程: 大模型微调系列 - 从基础到实战的完整指南
- 评估工具: lm-evaluation-harness, OpenCompass, RAGAs
- Agent框架: LangChain, AutoGen, AgentScope
🌐 学习社区与资源
- 论文库: Huggingface Daily Papers, Cool Papers, ML Papers Explained
- 博客: Lil'Log (OpenAI), 科学空间(苏剑林), Andrej Karpathy
- 综述: 大语言模型综述, Awesome LLM Reasoning
- 资源库: Awesome LLM Resources
🎨 可视化学习资源(强烈推荐!)
- 100+ LLM/RL 算法原理图 ⭐ 算法岗必看!
- 作者:《大模型算法:强化学习、微调与对齐》作者余昌叶
- 内容:100+张原创算法原理图,涵盖Transformer、注意力机制、SFT、LoRA/QLoRA、DPO/PPO/GRPO、RLHF、推理优化等
- 价值:通过可视化图解深入理解算法的数学推导和实现细节,让复杂算法一目了然
- 书籍:《大模型算法:强化学习、微调与对齐》
四、9周详细学习计划
第 1 周:大模型必备基础 + 手撕Transformer
学习内容: 基础速通: - [ ] Python 核心语法、NumPy/Pandas 基础 - [ ] 神经网络核心概念:前向传播、反向传播、损失函数 - [ ] PyTorch 框架速通:Tensor 操作、自动求导、模型搭建 Transformer架构: - [ ] Transformer 架构详解:Encoder、Decoder 结构、Self-Attention 机制、Multi-Head Attention - [ ] 核心组件剖析:Attention、Positional Encoding、Layer Normalization、残差连接、FFN - [ ] MOE架构初探:专家网络、门控网络、Top-K激活 手撕系列: - [ ] PyTorch 手撕神经网络训练 - [ ] EXCEL实现Transformer矩阵计算 - [ ] 手撕 Multi-Head Attention - [ ] 手撕 Transformer 关键模块 解锁技能: - 熟练运用 Python 和 PyTorch 进行开发 - 精通 Transformer 模型的核心架构与组件 - 具备手撕关键模块的能力 - 完全理解Bert、T5、GPT架构的工作原理
🌟 每日学习计划
| 天数 | 学习主题 | 资源链接 | 目标 |
|---|---|---|---|
| 1 | Python & PyTorch 基础 | 课程: 《动手学深度学习》 (B站视频) 数学: 3Blue1Brown - 线性代数的精髓 补充: 台湾大学李宏毅深度学习 | 掌握 Python 基础语法、PyTorch 张量操作与训练循环 |
| 2 | 手撕神经网络训练 | 教程: Neural Networks from Scratch 课程: Andrej Karpathy: Neural Networks Zero to Hero | 从零实现一个简单的前馈神经网络,理解反向传播 |
| 3 | Transformer 宏观理解 | 博客: The Illustrated Transformer 论文: "Attention Is All You Need" 可视化: Interactive Transformer 图解: Transformer算法原理图 | 掌握 Encoder/Decoder 结构、Multi-Head Attention |
| 4 | Transformer 矩阵计算 | 教程: Transformer from scratch in Excel 详解: Transformer 数学原理 图解: 算法原理图 | 逐个公式推导 Q/K/V 计算流程 |
| 5 | 手撕 Multi-Head Attention | 教程: Let's build GPT: from scratch 代码: nanoGPT, build nanoGPT | 纯 PyTorch 实现 Multi-Head Attention 和 FFN |
| 6 | 手撕 Transformer 关键模块 | 参考: pytorch-llama, LLMs-from-scratch | 组合已实现模块,完成一个完整的 Transformer Block |
| 7 | MOE 架构与模型家族 | 论文: Outrageously Large Neural Networks 指南: A Visual Guide to Mixture of Experts | 理解 MOE 架构,并梳理 Bert、T5、GPT 架构的差异 |
第 2 周:Agent 核心理论 + ReAct 框架
学习内容: Agent 核心概念: - [ ] 什么是 AI Agent? - [ ] Agent 的核心组件:Planning、Memory、Tool Use - [ ] Agent vs. LLM vs. RAG 的本质区别 ReAct 框架: - [ ] ReAct 核心思想:Reasoning + Acting 交替进行 必读论文: - ReAct (必读!): Agent 的 "Hello World" - 论文: https://arxiv.org/abs/2210.03629 手撕与学习任务: - [ ] 阅读 ReAct 论文,手绘算法流程图 - [ ] 基于 LangChain 或 LlamaIndex 复现一个基础的 ReAct Agent 面试准备: - Q: 请解释 ReAct 框架的工作原理。 - Q: ReAct 和传统的 Chain-of-Thought 有什么区别? 解锁技能: - 深刻理解 Agent 的基本工作范式 - 掌握 ReAct 框架的算法原理
🌟 每日学习计划
| 天数 | 学习主题 | 资源链接 | 目标 |
|---|---|---|---|
| 8 | Agent 核心概念 | 博客: LLM Powered Autonomous Agents 综述: 大语言模型综述 课程: 清华NLP大模型公开课 | 建立 Agent 的宏观认知,理解其与 LLM 的区别 |
| 9-10 | ReAct 论文精读与复现 | 论文: ReAct 代码: LangChain ReAct Agent 解读: ReAct解读 | 深度理解 "Thought, Action, Observation" 循环,并用框架实现 |
| 11-12 | ReAct 算法复现与思考 | 博客: 深入理解 ReAct 框架: Lagent, Qwen-Agent | 总结 ReAct 的优缺点,思考其在复杂任务中的局限性 |
| 13-14 | 预留时间 & 周度复盘 | 书籍: 《大语言模型》 技术报告: State of GPT 教程: 《动手学大模型Dive into LLMs》 | 巩固本周知识,完成所有编码任务 |
第 3 周:高级 Agent 架构:规划、反思与搜索
学习内容: 高级 Agent 架构: - [ ] Reflexion:自我反思机制 - [ ] Tree of Thoughts:树状思维搜索 - [ ] Self-Consistency:一致性采样 Multi-Agent 协作: - [ ] Multi-Agent 通信协议与协作策略(辩论、投票、层级) - [ ] 任务分解与分配算法 必读论文: - Reflexion: 核心思想是通过自我反思改进决策。 - 论文: https://arxiv.org/abs/2303.11366 - Tree of Thoughts: 核心思想是搜索算法 + LLM。 - 论文: https://arxiv.org/abs/2305.10601 - AutoGen Framework: 对话驱动的多智能体系统。 - 论文: https://arxiv.org/abs/2308.08155 学习任务: - [ ] 对比 ReAct、Reflexion、ToT 的算法差异,分析各自优缺点 - [ ] 用 Python 实现一个 ToT 节点,并结合 LLM API 设计一个简单的评估函数来解决 24点游戏 问题 - [ ] 使用 AutoGen 框架实现一个简单的 "coder" 与 "critic" 协作的 Multi-Agent 系统 面试准备: - Q: Reflexion 的自我反思机制如何实现?它和 RL 中的 "Credit Assignment" 有什么关系? - Q: Tree of Thoughts 和传统 MCTS (蒙特卡洛树搜索) 的区别是什么? - Q: 在 Multi-Agent 系统中,如何解决 "责任分散" 和 "目标冲突" 的问题? 解锁技能: - 掌握 Reflexion, ToT 等高级 Agent 架构的算法思想 - 能够分析不同 Agent 架构的优缺点和适用场景 - 理解多智能体系统的设计理念和协作模式 - 具备初步设计复杂 Agent 系统的能力
🌟 每日学习计划
| 天数 | 学习主题 | 资源链接 | 目标 |
|---|---|---|---|
| 15 | Reflexion 论文精读 | 论文: Reflexion 解读: Reflexion 论文解读 扩展: Self-Refine | 掌握其"Actor -> Evaluator -> Self-Reflection"的算法流程 |
| 16 | Reflexion 算法分析 | 伪代码: Reflexion 官方伪代码 相关: Chain of Thought | 分析反思机制如何帮助 Agent 从失败中学习,并尝试用伪代码实现 |
| 17 | Tree of Thoughts 论文精读 | 论文: Tree of Thoughts 代码: ToT 开源代码实现 相关: Self-Consistency | 理解如何将 LLM 作为搜索算法的启发式函数 |
| 18 | ToT 算法实战 | 任务: 24点游戏 博客: Prompt Engineering Guide | 实现一个简化的 ToT 搜索策略来解决 24点游戏 |
| 19 | Multi-Agent 协作模式 | 论文: MetaGPT 论文: Communicative Agents 论文: AutoGen | 学习 MetaGPT 中角色定义 (SOPs) 和协作模式 |
| 20 | AutoGen 框架实战 | 文档: AutoGen 官方教程 替代: AgentScope, CrewAI | 使用 AutoGen 搭建一个简单的 Coder 和 Critic Agent |
| 21 | 周度总结与对比分析 | 综述: Awesome Agent Reasoning | 绘制 ReAct, Reflexion, ToT 的算法流程对比图,总结优劣 |
第 4 周:RAG 核心算法:从密集检索到图检索
学习内容:
检索算法原理:
- [ ] Naive RAG 的算法流程
- [ ] 检索算法:BM25、Dense Retrieval、Hybrid Search
- [ ] Reranker 算法原理
Advanced RAG 算法:
- [ ] GraphRAG 算法创新
- [ ] Agentic RAG 与多跳推理
必读论文:
- Dense Passage Retrieval (DPR): 现代 RAG 的基础,对比密集检索与稀疏检索。
- 论文: https://arxiv.org/abs/2004.04906
- GraphRAG: 基于知识图谱的检索,关注其子图采样、路径排序等创新。
- 报告: https://www.microsoft.com/en-us/research/project/graphrag/
- Self-RAG: 让 Agent 自主规划检索策略。
- 论文: https://arxiv.org/abs/2310.11511
手撕与学习任务:
- [ ] Python 手撕 BM25 算法
- [ ] 使用 FAISS 构建一个向量索引并进行相似度搜索
- [ ] 使用 RAGAs 或 trulens-eval 对一个基础 RAG 系统进行评估
- [ ] 设计一个简单的 Agentic RAG 查询规划模块伪代码
面试准备:
- Q: GraphRAG 相比传统 RAG 的算法改进是什么?它适用于什么场景?
- Q: 如何设计一个 Agentic RAG 的规划策略?如何评估规划的好坏?
- Q: 密集检索和稀疏检索的优缺点分别是什么?为什么 Hybrid Search 通常效果更好?
解锁技能:
- 深入理解现代 RAG 系统的检索算法基石
- 掌握 GraphRAG、Agentic RAG 等前沿 RAG 算法的创新点
- 具备手撕核心检索算法和评估 RAG 系统的能力
- 能够设计和评估 RAG 系统的检索模块
🌟 每日学习计划
| 天数 | 学习主题 | 资源链接 | 目标 |
|---|---|---|---|
| 22 | 检索算法基础 (BM25) | 教程: BM25 from scratch 论文: TF-IDF | 理解 TF-IDF 和 BM25 的原理,并手动实现 |
| 23 | DPR 与密集检索 | 论文: DPR 教程: Sentence Transformers 论文: ColBERT | 掌握双编码器架构,并使用 Sentence Transformers 训练一个模型 |
| 24 | Reranker 与混合检索 | 教程: LlamaIndex Cohere Rerank 论文: Modular RAG 技术: RAG Techniques | 理解 Reranker 的作用,并实现一个 BM25 + Embedding 的混合检索流程 |
| 25 | GraphRAG 技术解读 | 报告: Microsoft GraphRAG 博客: GraphRAG 详解 实现: LightRAG, nano-GraphRAG | 理解其基于图的社群检测、摘要和问答流程 |
| 26 | RAG 评估体系 | 文档: RAGAs 评估框架 工具: FlashRAG 概览: Awesome Evaluation | 学习 Faithfulness, Answer Relevancy 等 RAG 评估指标,并用 RAGAs 进行评估 |
| 27 | Self-RAG 论文精读 | 论文: Self-RAG 相关: CRAG, Adaptive-RAG | 学习如何通过 "reflection tokens" 让 LLM 自主决定何时检索、检索什么内容 |
| 28 | Agentic RAG 算法设计 | 教程: Learn RAG From Scratch 课程: OpenRAG | 思考如何设计一个能进行多步推理的 Agentic RAG 策略,并绘制流程图 |
第 5 周:Agent Memory 与上下文工程算法
学习内容: Memory 算法设计: - [ ] 短期记忆 vs 长期记忆 - [ ] 记忆重要性评分算法 (语义相似度 + 任务相关性 + 时效性) - [ ] 记忆压缩与总结策略 (聚类 + 摘要 + 去重) - [ ] 记忆检索优化 (向量检索 + 时间衰减 + 重要性加权) 上下文工程算法: - [ ] 上下文选择策略 (语义相关性、逻辑依赖、时效性) - [ ] 上下文压缩算法 (层级笔记、QA对转换、总结算法) - [ ] 动态上下文构建 必读论文: - Generative Agents: 经典的 Agent Memory 模拟社会行为研究。 - 论文: https://arxiv.org/abs/2304.03442 - MemGPT: 通过分层记忆和函数调用管理虚拟上下文。 - 论文: https://arxiv.org/abs/2310.08560 学习任务: - [ ] 基于MemGPT开源库,修改其配置以处理一个长文档问答任务 - [ ] 实现一个自定义的NodePostprocessor(LlamaIndex) 来根据关键词或时间戳过滤上下文 - [ ] 设计一个分层记忆架构伪代码,包含评分、压缩、检索的完整 Agent Memory 算法方案 面试准备: - Q: 如何设计 Agent 的长期记忆机制?请阐述其写入、更新、读取的全流程。 - Q: 记忆压缩和检索的trade-off如何平衡?如何通过实验评估你的压缩算法没有损失关键信息? - Q: MemGPT 和传统的 RAG 在处理长上下文时有何本质区别? 解锁技能: - 掌握 Agent 记忆系统的核心算法设计 - 能够设计高效的上下文选择与压缩策略 - 理解如何平衡信息保真度与上下文长度的限制 - 具备从算法层面优化 Agent 长对话能力的视野
🌟 每日学习计划
| 天数 | 学习主题 | 资源链接 | 目标 |
|---|---|---|---|
| 29 | Agent Memory 概述 | 博客: LLM Powered Agents - Memory 工具: Mem0, MemoryScope 论文: Agent Memory 综述 | 梳理 Agent 记忆的分类和挑战 |
| 30 | Generative Agents 论文精读 | 论文: Generative Agents 博客: Generative Agents 解读 | 学习其对记忆进行评分 (Recency, Importance, Relevance) 和检索的机制 |
| 31 | MemGPT 论文精读 | 论文: MemGPT 代码: MemGPT 开源库 相关: Anthropic Context | 学习其分层记忆和函数调用管理虚拟上下文的方法 |
| 32 | MemGPT 实战 | 教程: MemGPT Tutorial 扩展: LangMem | 运行 MemGPT 官方示例,理解其工作流程 |
| 33 | 上下文压缩技术 | 教程: LlamaIndex Context Stuffing 论文: LongLLMLingua | 学习并实现不同的上下文填充和压缩策略 |
| 34 | 上下文选择与过滤 | 教程: LlamaIndex Node Postprocessors 论文: Lost in the Middle | 实现一个自定义的后处理器来优化上下文选择 |
| 35 | 周度总结与方案设计 | 设计一个包含评分、压缩、检索的完整 Agent Memory 算法方案,并绘制架构图 |
第 6 周:基于强化学习的 Agent 决策优化
学习内容: RL 基础理论: - [ ] RL 基础:MDP、Q-learning、Policy Gradient - [ ] Agent + RL 的结合点 - [ ] 奖励函数设计 (稀疏奖励 vs 密集奖励, Reward Model) - [ ] 策略优化算法 (PPO vs DPO vs GRPO) 必读论文: - DPO: 无需显式奖励模型的偏好对齐方法。 - 论文: https://arxiv.org/abs/2305.18290 - GRPO: 最新的 RLHF 算法,核心思想是 Group Relative Policy Optimization,算法创新点在于相对偏好建模。 - 论文: https://arxiv.org/pdf/2402.03300 手撕与学习任务: - [ ] 推导 DPO 的损失函数 - [ ] 使用TRL库中的DPOTrainer对一个 SFT 模型进行 DPO 微调 - [ ] 设计一个 Agent 工具调用任务的奖励函数 面试准备: - Q: 如何用强化学习优化 Agent 的决策?请举例说明 State, Action, Reward 如何定义。 - Q: DPO 和 PPO 在 Agent 场景下的选择和优劣势是什么?为什么 DPO 更稳定? - Q: 在一个稀疏奖励的 Agent 任务中(例如,只有任务最终成功才有奖励),如何设计 Reward Shaping 或辅助任务来帮助模型学习? 解锁技能: - 掌握将 Agent 决策过程建模为 RL 问题的能力 - 深刻理解 PPO/DPO/GRPO 等主流对齐算法的原理 - 能够为 Agent 任务设计合理的奖励函数 - 具备使用强化学习优化 Agent 策略的理论基础
🌟 每日学习计划
| 天数 | 学习主题 | 资源链接 | 目标 |
|---|---|---|---|
| 36 | RL 基础入门 | 教程: Hugging Face Deep RL Course 课程: 《动手学强化学习》 书籍: Reinforcement Learning: An Introduction | 掌握 MDP, Policy, Value Function 等核心概念 |
| 37 | Policy Gradient & PPO | 博客: Understanding PPO 论文: PPO 教程: RL课程 图解: PPO算法图解 | 理解 PPO 的目标函数和裁剪机制 |
| 38 | DPO 论文精读与推导 | 论文: DPO 博客: DPO 详解 教程: Preference Optimization | 掌握 DPO 如何从偏好数据中隐式学习奖励并优化策略,并推导其损失函数 |
| 39 | DPO 实战 | 教程: Hugging Face TRL DPO 框架: OpenRLHF, RL-Factory, VeRL | 使用 TRL 库完成一次 DPO 训练 |
| 40 | GRPO 理论解读 | 论文: GRPO 相关: DeepSeek-R1 综合: Open o1推理 | 理解 GRPO 如何将 DPO 扩展到组级别的偏好 |
| 41 | RL for Tool Learning | 论文: Toolformer 论文: ReAct RL 资源: Agent+RL项目汇总 | 学习如何用 RL 思想让模型学会使用工具 |
| 42 | 奖励模型设计 | 教程: TRL Reward Modeling 框架: RM-Gallery 书籍: RLHF Book | 学习如何为 Agent 任务设计奖励函数/训练奖励模型 |
第 7-8 周:算法创新项目实战
根据阿东提供的方向进行选择
核心目标:完成 1-2 个算法创新型项目,从问题定义到实验分析,产出论文初稿或开源代码。
项目方向1:Agentic RAG with Self-Correction
问题定义: 传统 RAG "一次检索定成败",无法处理需要多步推理或信息汇总的复杂问题。 算法创新点: 1. Iterative Retrieval: 构建一个 Agent,能对初步检索结果进行评估。 2. Self-Correction: 如果 Agent 认为信息不足或有矛盾,能自主生成新的、更精确的查询,进行多轮检索。 3. Adaptive Planning: (进阶) 使用 RL 训练查询生成策略,最大化最终答案的准确性。 实验设计: - 数据集: HotpotQA, QASPER (需要多跳推理的数据集) - Baseline: Naive RAG, ReAct Agent - 评估指标: F1, Recall@K, Answer Correctness, # of Queries (效率) - 消融实验: 验证 Self-Correction 模块和 Iterative Retrieval 模块的贡献。
项目方向2:Hierarchical Memory Agent for Long-Term Tasks
问题定义: 现有 Agent 的 Memory 机制通常是扁平的向量存储,难以在长期、多任务的场景中有效组织和检索记忆。 算法创新点: 1. Hierarchical Memory: 设计一个分层记忆结构,例如Event Memory(高层事件总结) 和Working Memory(底层原始信息)。 2. Autonomous Summarization: Agent 能够在对话或任务结束后,自动将Working Memory中的内容进行总结,并存入Event Memory。 3. Layered Retrieval: 检索时,Agent 首先在高层Event Memory中定位相关事件,再深入底层的Working Memory获取细节,提高效率和准确性。 实验设计: - 数据集: 构建一个长对话、多主题的数据集 (如整理多场会议纪要)。 - Baseline: Sliding Window Memory, Naive Vector Store Memory - 评估指标: Information Recall (信息保留率), Compression Ratio (压缩率), Retrieval Speed (检索速度) - 消融实验: 验证 Hierarchical 结构和 Summarization 模块的有效性。
🌟 学习计划 (2周)
| 天数 | 学习主题 | 目标 |
|---|---|---|
| 43-44 | 项目选题与文献调研 | 选定一个项目方向,精读 5-7 篇核心论文,完成 Related Work 初稿 |
| 45-46 | 算法与实验方案设计 | 完成算法流程图绘制,确定数据集、Baseline、评估指标和消融实验方案 |
| 47-51 | 编码:框架与 Baseline | 搭建实验框架 (数据处理、评估脚本),并实现 Baseline 方法 |
| 52-55 | 编码:核心算法实现 | 实现自己设计的核心创新算法模块 |
| 56-58 | 实验与结果分析 | 运行所有实验,收集数据,使用图表进行可视化,撰写初步的实验结论 |
| 59-60 | 论文撰写 (Method & Exp) | 完成论文中方法和实验部分的核心内容撰写 |
第 9 周:论文撰写/开源与面试冲刺
学习内容: 论文/开源准备: - [ ] 论文撰写: 学习 Introduction, Method, Experiments, Conclusion 的写法。 - [ ] 开源准备: 代码整理与注释,撰写 README,准备示例代码和技术博客。 面试准备: - [ ] 简历撰写: 学习如何突出算法创新、实验验证和论文/开源产出。 - [ ] 算法面试题: 刷算法设计类、实验设计类、理论深度类题目。 - [ ] 模拟面试: 准备自我介绍和项目介绍的逐字稿,进行模拟面试。 面试话术准备 (STAR - 算法版): - Situation: 问题背景,现有方法的局限性。 - Task: 你要解决的问题和优化目标。 - Action: 你设计的算法,创新点,为什么这样设计。 - Result: 实验结果,对比了哪些 baseline,提升了多少,有什么产出。 解锁技能: - 掌握学术论文的撰写规范与技巧 - 能够将自己的研究成果进行开源分享 - 拥有一份极具竞争力的算法项目经历 - 具备在面试中清晰、深入地阐述自己工作的能力
🌟 每日学习计划
| 天数 | 学习主题 | 资源链接 | 目标 |
|---|---|---|---|
| 61 | 论文撰写 (Intro & Conclusion) | 模板: Overleaf ACL Template 指南: 论文写作技巧 | 完成引言、结论和摘要部分的初稿,并进行全文校对 |
| 62 | 代码开源与博客撰写 | 指南: 如何写好 README 平台: Huggingface, GitHub | 整理代码,撰写 README,并写一篇技术博客解读你的项目 |
| 63 | 简历项目经历打磨 | 指南: Tech Resume Guide 参考: AI面试指南 | 按照 STAR-算法版 模板,将你的项目经历写入简历 |
| 64 | 准备项目介绍逐字稿 | 模板: STAR方法 | 准备一个 3-5 分钟的项目介绍,覆盖 S/T/A/R 各个环节 |
| 65 | 模拟项目深挖 | 题库: LLM系统设计面试题 | 针对 "为什么不用XX方法"、"算法的局限性" 等问题准备回答 |
| 66 | 算法理论题复习 | 题库: AI Interview Questions 笔记: LLMs Interview Note 课程: ML Papers Explained | 复习 Transformer, RL, RAG 等核心理论高频面试题 |
| 67 | 模拟面试与总结 | 资源: LLM Evaluation: A Complete Course 社区: AI研究社群 | 进行 1v1 模拟面试,复盘并改进 |
📚 核心学习资源推荐
精选业界最优质的学习资源,助你快速提升算法能力
🤖 智能体开发
- ⭐ 推荐指数: ★★★★★
- 📖 内容: Agent 开发完整教程,从基础到进阶
- 🎯 适合: 入门 Agent 算法开发,了解核心原理
- 💡 亮点: 中文友好、实战导向、Datawhale 出品
📊 RAG 算法优化
- ⭐ 推荐指数: ★★★★★
- 📖 内容: RAG 全流程算法优化,涵盖检索、重排、GraphRAG
- 🎯 适合: RAG 算法研究、检索优化、算法创新
- 💡 亮点: 系统化 RAG 教程、算法改进方向、实战案例
🔧 模型微调
- ⭐ 推荐指数: ★★★★★
- 📖 内容: 2-5倍微调加速,显存优化,支持 LoRA/QLoRA
- 🎯 适合: 高效微调、资源受限场景、快速实验
- 💡 亮点: 速度快、显存省、易上手
- ⭐ 推荐指数: ★★★★★
- 📖 内容: 支持100+ LLM微调,Web UI + CLI,SFT/DPO/PPO
- 🎯 适合: 算法实验、Function Call微调、模型对齐
- 💡 亮点: 功能全面、社区活跃、文档完善
🗃️ 数据处理
- ⭐ 推荐指数: ★★★★☆
- 📖 内容: 数据清洗、格式转换、质量评估
- 🎯 适合: 微调数据准备、数据质量提升
- 💡 亮点: 自动化数据处理、提升数据质量
🧠 从零构建大模型(理论深度)
- ⭐ 推荐指数: ★★★★★(算法岗必看)
- 📖 内容: 从零实现 GPT,代码简洁、注释详细
- 🎯 适合: 深入理解 Transformer、预训练原理
- 💡 亮点: Karpathy 亲自编写、500行核心代码、理解模型本质
- ⭐ 推荐指数: ★★★★★(算法岗必看)
- 📖 内容: 从零构建对话模型,涵盖训练、推理、部署
- 🎯 适合: 理解对话系统、端到端模型构建
- 💡 亮点: 完整的训练流程、实战导向、算法细节
🎯 完整学习路径
- ⭐ 推荐指数: ★★★★★
- 📖 内容: Agent 开发、RAG 系统、上下文工程、面试指南
- 🎯 适合: 系统化学习、求职准备、技术路线规划
- 💡 亮点: 算法岗/开发岗双路线、面试题库、简历模板
💡 学习建议
入门阶段(第1-2周)
- 先学习 Hello-Agents 建立 Agent 开发基础
- 阅读 nanoGPT 源码理解模型原理
进阶阶段(第3-6周)
- 深入 All-in-RAG 学习检索算法优化
- 使用 LLaMA-Factory 进行微调实验
- 用 Unsloth 提升训练效率
实战阶段(第7-9周)
- 参考 nanochat 构建对话系统
- 使用 Easy-Dataset 处理训练数据
- 跟随 AgentGuide 完成项目和面试准备
👉 返回主文档:README.md
FAQ
常见问题 (FAQ)
AgentGuide 使用过程中的常见问题解答
🎓 学习相关
Q1: 我没有 AI 基础,能学会吗?
A: 可以!但建议先具备:
- ✅ 基础的 Python 编程能力
- ✅ 了解基本的机器学习概念(不强制)
- ✅ 使用过 ChatGPT 等 LLM 产品
如果完全零基础,建议先学习:
- Python 基础(菜鸟教程即可,1-2周)
- 了解什么是大语言模型(看 1-2 篇科普文章)
- 试用 ChatGPT/Claude(感受 LLM 能力)
零基础学习路径:
Step 1: Python 基础(2周)
↓
Step 2: 了解 LLM(1周)
↓
Step 3: 开始 AgentGuide 学习(6-8周)
Q2: 学完大概需要多长时间?
A: 取决于你的目标和基础:
| 路线 | 时长 | 适合人群 | 产出 |
|---|---|---|---|
| 快速通道 | 2-3周 | 有AI基础 | 1个项目,能投简历 |
| 开发岗路线 | 4-6周 | 有工程背景 | 2-3个项目,充分准备 |
| 算法岗路线 | 6-8周 | 有科研背景 | 论文+项目,深入掌握 |
| 深入掌握 | 3-4个月 | 想做顶尖 | 所有项目+论文复现 |
建议:
- 不要贪多,先完成一条线
- 边学边做项目,不要只看不练
- 每周至少 10-15 小时投入
Q3: 算法岗和开发岗有什么区别?我该选哪个?
A: 核心区别总结:
|
🔬 算法工程师 核心工作:算法创新、论文研究 必备能力:
简历核心:
薪资:60-100万 竞争:⭐⭐⭐⭐⭐ 激烈 岗位数:⭐⭐⭐ 中等 |
🛠️ 开发工程师 核心工作:系统搭建、业务落地 必备能力:
简历核心:
薪资:40-80万 竞争:⭐⭐⭐ 适中 岗位数:⭐⭐⭐⭐⭐ 最多 |
如何选择:
- ✅ 有论文/科研经历 → 优先算法岗
- ✅ 有工程/项目经验 → 优先开发岗
- ✅ 两者都有 → 通吃策略(最推荐!)
详细对比:查看 岗位选择指南
Q4: AgentGuide 和其他教程有什么不同?
A: 核心差异:
| 维度 | AgentGuide | 其他教程 |
|---|---|---|
| 定位 | 求职导向 | 技术导向 |
| 结构 | 6步法(岗位→方法→路线→项目→技术→面试) | 纯技术堆砌 |
| 路线 | 算法/开发双线,差异化 | 单一路线 |
| 项目 | 双版本简历写法 | 只有代码 |
| 更新 | 持续更新(作者一线从业者) | 更新慢 |
AgentGuide 的独特价值:
- ✅ 选择优先:先确定岗位,再学习
- ✅ 求职导向:每个知识点都标注"面试怎么考"
- ✅ 实战项目:提供算法岗和开发岗两种写法
- ✅ 系统化:从零基础到拿Offer的完整路径
- ✅ 作者背书:一线大模型算法工程师
Q5: 我可以商业使用 AgentGuide 的内容吗?
A: 个人学习和求职完全免费。但请注意:
✅ 允许的用途:
- 个人学习、求职简历、面试准备
- 在自己的博客/公众号分享(需注明来源)
- 企业内部学习使用
❌ 不允许的用途:
- 未经许可的商业培训、课程销售
- 去除作者信息后的二次分发
- 直接复制内容做付费产品
灰色地带:
- 如果要基于 AgentGuide 做商业培训,请联系作者授权
- 可以引用部分内容,但需注明出处
💻 技术相关
Q6: 需要什么硬件配置?
A: 取决于你的目标:
开发岗(轻量):
- 💻 普通笔记本即可
- 🌐 稳定的网络(调用 API)
- 💰 LLM API 费用(每月 50-100 元)
算法岗(需要GPU):
- 💻 带 GPU 的电脑或云服务器
- 🎮 推荐:RTX 3090/4090 或 A100
- 💰 云 GPU 费用(AutoDL约 2-5 元/小时)
建议:
- 开发岗:本地开发 + OpenAI API
- 算法岗:AutoDL 租 GPU(按需使用)
Q7: 学完能找到什么样的工作?
A: 基于往期学员案例:
薪资范围:
- 应届生:30-50 万
- 1-3年经验:50-80 万
- 3年+经验:80-150 万
典型岗位:
- AI Agent 算法工程师
- AI Agent 开发工程师
- RAG 系统工程师
- LLM 应用工程师
- 多模态算法工程师
公司类型:
- 大厂:字节、阿里、腾讯、百度
- AI 独角兽:智谱、月之暗面、零一万物
- AI 创业公司:各垂直领域
Q8: 项目会持续更新吗?
A: 会的!承诺:
更新频率:
- 每周至少 2-3 篇新内容
- 每月至少 1 个实战项目
更新内容:
- 📚 技术教程(LangChain、RAG、Agent)
- 💼 实战项目(完整代码+教程)
- 📰 最新技术动态(论文解读)
- 🎯 面试题库(真实大厂面试题)
如何获取更新:
- ⭐ Star 本项目
- 👁️ Watch 本项目(推荐)
- 关注公众号「阿东玩AI」
🤝 社群相关
Q9: 如何加入学习社群?
A: 三种方式任选其一:
- 方式一(推荐):
- Star 本项目
- 在 Issues 评论"申请加群"
- 留下你的微信号
- 方式二:
- 关注公众号「阿东玩AI」
- 回复「AgentGuide」
- 获取入群二维码
- 方式三:
- 小红书搜索「阿东玩AI」
- 私信"加群"
社群福利:
- ✅ 每周技术分享
- ✅ 简历/面试辅导
- ✅ 问题实时答疑
- ✅ 学习小组
- ✅ 大厂内推机会
Q10: 社群是免费的吗?
A: 基础社群完全免费!
免费内容:
- Agent 学习交流
- 技术问题答疑
- 资源分享
付费服务(可选):
- 1v1 简历诊断
- 模拟面试
- 深度学习陪跑
🔧 使用问题
Q11: 代码运行不了怎么办?
A: 常见问题排查:
- 检查 Python 版本
python --version # 需要 3.8+
- 检查依赖安装
pip install -r requirements.txt
- 检查 API Key
- OpenAI API Key 是否配置
- 网络是否能访问 OpenAI
- 查看错误日志
- 复制完整错误信息
- 在 Issues 中提问
Q12: 我能贡献内容吗?
A: 非常欢迎!🎉
贡献方式:
- 纠正错误(错别字、技术错误)
- 补充内容(新的资源、工具)
- 优化代码(示例代码优化)
- 翻译内容(英文版)
贡献流程: 详见 CONTRIBUTING.md
贡献者权益:
- ✅ 名字出现在贡献者列表
- ✅ 优先获得技术支持
- ✅ 社群"核心贡献者"标识
📬 其他问题
Q13: 如何联系作者?
A: 多种方式:
- 📝 GitHub Issues:https://github.com/adongwanai/AgentGuide/issues
- 📱 小红书:阿东玩AI
- 📰 公众号:阿东玩AI
- 🎬 B站:阿东玩AI
紧急问题:GitHub Issues(24小时内回复)
Q14: 项目会一直免费吗?
A: AgentGuide 永久开源免费!
承诺:
- ✅ 所有核心内容永久免费
- ✅ 不会设置付费墙
- ✅ 不会删除已有内容
可能的商业化:
- 基于 AgentGuide 的付费课程(深度陪跑)
- 1v1 咨询服务
- 企业内训
但 AgentGuide 本身永远免费!
💡 还有其他问题?
- 📝 提 Issue:https://github.com/adongwanai/AgentGuide/issues
- 💬 加入社群:公众号回复「AgentGuide」
👉 返回主文档:README.md
agent job ready roadmap 2026
type: 路线图 status: 已发布 level: 通用 topic:
- 面试求职
- Agent
- 项目实战
2026 Agent 求职通关路线
这是一条面向求职和项目落地的 Agent 学习路线。目标不是收藏更多链接,而是一步步做出能验证、能演示、能写进简历的作品。
适合谁
| 你的状态 | 建议入口 |
|---|---|
| 零基础 | 从 Stage 0 开始,先建立 Agent / Workflow / RAG / Multi-Agent 的坐标系 |
| 做过 LLM 应用 | 从 Stage 1 或 Stage 2 开始,补 Agent Loop、工具调用、评测和上下文工程 |
| 想做简历项目 | 直接看 Stage 7-8,把项目做成可运行、可评测、可复盘的系统 |
| 准备面试 | 对照每个阶段的产出物,练习用架构、业务、结果三维表达项目 |
当前优先级
Agent 方向变化很快,当前更值得投入的是能落地、能验证、能讲清楚取舍的能力。
| 优先级 | 方向 | 为什么重要 |
|---|---|---|
| 1 | Claude Code / Codex-style Coding Agents | 真实代码库、shell、文件编辑、测试、权限、上下文压缩,是理解 Agent 工程的最佳样本 |
| 2 | Agent Harness Engineering | Agent 能力很大一部分来自 harness:工具协议、权限、状态、反馈、回放、CI、评测 |
| 3 | Context Engineering | Agent 的核心不是提示词,而是控制信息如何进入模型 |
| 4 | Skills / MCP / A2A / ACP | Skills 负责能力复用,MCP 连接工具,A2A 连接 Agent,ACP 连接宿主应用 |
| 5 | Browser / Computer-Use Agents | 浏览器和桌面操作是 Agent 从 demo 走向真实任务的重要边界 |
| 6 | Evaluation / Observability / Safety | 没有 eval、trace、权限边界的 Agent,只能算 demo |
Stage 0:理解 Agent 是什么
目标:区分 chatbot、workflow、agent、multi-agent,知道什么时候不该用 Agent。
需要掌握:
- Agent 基本循环:observe -> think -> act -> observe
- Workflow 和 Agent 的边界
- Agent 失败的常见原因:上下文污染、工具设计差、状态不可恢复、没有评测
- Harness 的意义:模型是推理核心,harness 提供工具、权限、记忆、反馈和运行环境
推荐阅读:
产出物:写一页笔记回答三个问题:
- 我的场景为什么需要 Agent,而不是普通 workflow?
- Context Engineering 和 Prompt Engineering 的区别是什么?
- Harness 的各层分别解决什么问题?
Stage 1:写出最小 Agent Loop
目标:自己写出一个能选择工具、执行工具、返回最终答案的最小 Agent。
需要掌握:
- 普通 LLM API 调用
- 结构化 JSON 输出
- 工具函数定义和 schema 设计
- tool call / function call 解析
- 最大步数、超时、错误处理
核心循环:
while True:
response = call_model(messages, tools)
if response.stop_reason == "end_turn":
break
if response.stop_reason == "tool_use":
result = run_tool(response.tool_call)
messages.append(result)
continue
推荐阅读:
产出物:一个 50-150 行的最小 Agent,可以调用 calculator、search、read_file 等工具。
Stage 2:Tool Use、RAG 和 Memory
目标:让 Agent 从“会聊天”变成“能查资料、用工具、有记忆”。
需要掌握:
- RAG 全流程:chunk -> embed -> retrieve -> answer with citations
- 工具注册:优先使用 dispatch 表,而不是 if-elif 长链
- 短期上下文、会话记忆、长期记忆的区别
- 工具失败、空结果、重复调用、幻觉引用处理
- 回答中给出来源或证据
推荐阅读:
产出物:一个资料研究助手,输入主题后自动搜索、筛选、总结并输出引用链接。
Stage 3:研究一个现代 Agent Harness
目标:从真实系统里学习 Agent 如何组织工具、上下文、权限、状态、日志、子任务和反馈。
推荐研究对象:
| 系统 | 适合学习什么 |
|---|---|
| Claude Code | CLI、工具、权限、hooks、subagents、MCP |
| learn-claude-code | 从零复刻 coding agent harness |
| OpenClaw / claw0 | 长运行、本地优先、消息入口、memory、heartbeat |
| OpenHands / SWE-agent | 代码库编辑、shell、测试、sandbox |
| nanobot | 轻量 agent base、multi-provider、memory、skills |
重点读:
- agent loop 在哪里
- tool registry 怎么设计
- permission gate 怎么拦截风险动作
- session store 怎么保存状态
- context compaction 怎么触发
- trace 怎么记录和回放
产出物:一个可调试的 harness demo,包含 README、运行步骤、示例输入输出和失败记录。
Stage 4:把 Multi-Agent 当协调问题
目标:理解多 Agent 不是“角色扮演越多越强”,而是任务分解、上下文隔离和结果汇总。
需要掌握:
- planner / executor / reviewer / critic / router 的职责边界
- supervisor 或 graph 如何管理多 Agent
- 每个 Agent 的输入输出 schema 和停止条件
- 循环、争论、任务漂移、上下文膨胀怎么处理
- 什么时候单 Agent 更好
判断标准:
如果子任务之间需要频繁交换中间状态,优先单 Agent;如果子任务可以独立完成、最后只汇总结果,才考虑 multi-agent。
推荐阅读:
产出物:一个 research -> write -> review -> revise 的小型多 Agent 系统。
Stage 5:学习 Skills、协议和能力封装
目标:理解 Tool、Skill、MCP、A2A、ACP 分别解决什么问题。
需要掌握:
- Tool:可调用接口,解决“能不能做”
- Skill:可复用流程知识,解决“怎么高质量地做”
- MCP:连接外部工具和数据源
- A2A:Agent 之间发现、通信和协作
- ACP:宿主应用与 Agent 的统一接口
一个好的 Skill 应该包含:
- name / description
- 何时使用
- 操作步骤
- 需要渐进加载的脚本或模板
- 验收标准
- smoke test
推荐阅读:
产出物:一个可复用 Skill,例如 code-review、research-report、pdf-extraction 或 release-note-writer。
Stage 6:Browser 和 Computer-Use Agents
目标:让 Agent 能操作公开网页,并具备可复盘的安全边界。
需要掌握:
- Browser Agent 和普通 API Tool 的区别
- Playwright / browser-use 的基本操作
- 页面变化、弹窗、加载失败、元素定位失败处理
- 截图、DOM、动作日志记录
- 对登录、支付、发布、删除等动作设置安全限制
推荐阅读:
产出物:一个只操作公开网页的 Browser Agent,能打开页面、提取信息、生成摘要。
Stage 7:Evaluation、Observability 和 Safety
目标:用评测和 trace 把 Agent 从“感觉变好”推进到“可以定位、可以回归、可以优化”。
需要掌握三层评测:
| 层级 | 测什么 | 怎么做 |
|---|---|---|
| Component eval | 单个 prompt / tool / retriever 是否可靠 | fixture -> 期望输出,断言关键属性 |
| Trajectory eval | 整段 agent loop 是否走对路径 | 看步数、工具选择、是否绕路,结合 rubric 打分 |
| End-to-end eval | 用户任务是否完成 | 真实任务 + 明确成功标准 |
还需要记录:
- 成功率
- 失败原因
- 工具调用次数
- 成本
- 延迟
- 权限确认记录
推荐阅读:
产出物:一个 eval 表格,至少 20 个任务、期望结果、实际结果、失败分类。
Stage 8:Ship 一个真实 Agent
目标:完成一个别人能 clone 下来跑的 Agent 项目。
最低要求:
- 有明确用户、明确任务、明确成功标准
- 有日志、trace、错误重试、超时、成本上限
- 有权限边界和人工确认机制
- 有部署方式:CLI、Web app、Slack bot、GitHub Action 或后台任务
- 有 README:怎么运行、怎么配置、怎么扩展、有哪些限制
- 有 eval:至少 20 条任务,记录通过率和失败归因
最终产出物:一个可运行 Agent 项目 + 技术博客 + 简历项目描述。
简历表达模板
不要只写“基于大模型实现智能问答”。一个 Agent 项目应该从三维表达:
| 维度 | 怎么写 |
|---|---|
| 架构表达 | agent loop、工具注册、会话状态、上下文裁剪、权限确认、记忆和错误恢复 |
| 业务表达 | 业务场景、关键工具、数据源、用户路径和约束条件 |
| 结果表达 | 评测集规模、成功率、失败类型、成本优化和消融实验结论 |
示例:
基于轻量 Agent Harness 构建垂直场景助手。ReAct loop + dispatch 表注册 5 个业务工具,四层分级 context 管理 system / long-term / short-term / turn 信息;高风险操作接入三级权限确认。20 条评测 case 端到端通过率 82%,通过上下文压缩和模型路由将 token 成本降低 60%。
ship agent project
type: 实践指南 status: 已发布 level: 进阶 topic:
- Agent
- 项目实战
- 面试求职
如何落地一个可写进简历的 Agent 项目
不是装一个框架跑 hello world,而是从理解、规划、实现、评测到复盘,做出一个能演示、能解释、能量化的 Agent 项目。
最终标准
一个简历级 Agent 项目至少应该做到:
- 有明确用户和任务,不是泛泛的“智能助手”
- 有可运行入口,别人 clone 后能按 README 跑起来
- 有清晰 agent loop、工具注册、上下文管理、权限边界
- 有日志或 trace,失败后能定位问题
- 有 eval case,能说明通过率、失败类型、成本和延迟
- 有复盘:为什么这样设计,替代方案是什么,哪些机制真的带来提升
Step 1:建立全局认知
不要一上来逐文件读源码。先回答 5 个问题:
- Agent loop 在哪里?也就是模型调用、工具调用、观察结果回写的主循环在哪里。
- 工具注册机制是什么?新增工具是加配置、加函数,还是改核心逻辑?
- Context 怎么组装?system、history、memory、retrieved context、tool result 的顺序是什么?
- Memory 怎么存?JSONL、SQLite、向量库、外部服务,分别存什么?
- 通道层怎么抽象?CLI、Web、IM、定时任务是否共用同一套 agent core?
建议做法:
- 先看 README、架构图、入口文件、测试文件
- 用
rg搜索tool,agent,loop,memory,session,trace - 把核心文件压缩到 3-5 个,逐行读这些文件
- 配角文件只扫职责,不要陷进每个实现细节
产出物:一页项目理解笔记,包含模块图和核心调用链。
Step 2:准备 AI 编程环境
核心不是装 IDE,而是建立:
Plan -> 执行 -> 验证 -> 复盘
建议在项目根目录沉淀这些文件:
项目根/
├── AGENTS.md 或 CLAUDE.md # 给 coding agent 的项目规则
└── docs/
├── spec.md # 需求规格
├── prompt_plan.md # 实现计划
└── eval_plan.md # 评测设计
AGENTS.md 或 CLAUDE.md 建议写四块:
| 模块 | 内容 |
|---|---|
| WHAT | 项目一句话定位 |
| WHY | 不可变约束,例如安全边界、数据权限、成本上限 |
| HOW | 如何安装、运行、测试、调试 |
| TEST | 改代码必须同步验证什么,外部依赖如何 mock |
产出物:能让 AI coding 工具稳定协作的项目规则文件。
Step 3:建立项目理解 Skill
当项目变大后,只靠一次性 prompt 很容易丢上下文。更好的方式是把项目理解沉淀成可复用 Skill 或项目指南。
可以写成:
custom_skills/
└── understand_project.md
内容建议:
- 项目一句话定位
- 目录结构
- 核心流程
- Agent loop 位置
- 工具注册方式
- Context / Memory / Eval 相关文件
- 常用命令
- 修改代码时的注意事项
- 验收标准
这样之后你可以让 coding agent “参考项目理解 Skill”,不需要每次重新读一遍源码。
产出物:一份项目理解 Skill 或等价的项目上下文文档。
Step 4:先写 Spec,再写代码
脑子里的需求通常不完整。先把需求写成 spec,再拆成可测试的小步骤。
Spec 至少回答:
| 问题 | 示例 |
|---|---|
| 目标用户是谁 | 研究生、客服、运营、开发者 |
| 触达渠道是什么 | CLI、Web、飞书、Slack、浏览器 |
| 核心任务是什么 | 搜索资料、生成报告、审查代码、整理会议 |
| 工具有哪些 | search、read_file、write_file、browser、database |
| 每个工具失败怎么办 | 空结果、超时、权限不足、参数错误 |
| 哪些动作需要确认 | 发邮件、删文件、付款、发布内容 |
| 成功标准是什么 | 完成率、引用正确率、延迟、成本 |
| 成本约束是什么 | 每个 trajectory 的 token / 金额上限 |
实现计划建议拆成 5-10 个小步骤,每步都能独立验证。
产出物:docs/spec.md 和 docs/prompt_plan.md。
Step 5:评测、归因和消融实验
没有 eval 的 Agent 修改就是“感觉变好了”。项目要能写进简历,必须有数据。
准备 10-20 个评测 case,覆盖:
- 正常任务
- 空输入
- 工具失败
- 检索不到结果
- prompt injection
- 高风险动作
- 长上下文
- 多轮追问
每次跑完记录:
| 字段 | 说明 |
|---|---|
| task_id | 任务编号 |
| input | 用户输入 |
| expected | 期望行为 |
| actual | 实际输出 |
| pass | 是否通过 |
| failure_type | 工具选错、上下文污染、模型能力、业务规则、权限问题 |
| steps | agent loop 步数 |
| tool_calls | 工具调用次数 |
| cost | token 或金额 |
| latency | 延迟 |
消融实验可以这样做:
- 去掉 context 压缩,看成功率和成本变化
- 去掉 reranker,看引用正确率变化
- 换小模型做 gate,看成本和误判率变化
- 合并或拆分工具,看工具选择准确率变化
- 关闭 memory,看多轮任务成功率变化
产出物:一张 eval 表格 + 一段项目复盘。
可靠性六件套
| 机制 | 做什么 | 不做的后果 |
|---|---|---|
| Idempotency | 工具调用带幂等 key | 重启后重复发邮件、重复扣款、重复写入 |
| Timeout + Circuit Breaker | 每个工具有超时,连续失败后熔断 | trajectory 被慢工具拖垮 |
| Rate Limit Aware Retry | 指数退避、jitter、多 provider fallback | 限流后整个系统挂掉 |
| Cost Guard | 每个 trajectory 设 token / 金额上限 | bug 无限循环烧成本 |
| Permission Tier | 读自动、写 dry-run + 人审、不可逆显式确认 | Agent 执行危险动作 |
| Observability | 记录 prompt、tool call、result、token、延迟 | 出问题无法回放和归因 |
简历写法
不要写:
基于大模型实现智能问答系统。
可以写:
基于轻量 Agent Harness 构建资料研究助手。ReAct loop + dispatch 表注册 search / fetch / summarize / cite 4 类工具,四层 context 管理 system、memory、retrieval、turn 信息;高风险写入动作接入 dry-run 和人工确认。构建 20 条 eval case,端到端通过率 82%,消融实验显示 context 压缩使成功率提升 12%,模型路由将 token 成本降低 60%。
常见误区
| 误区 | 更好的做法 |
|---|---|
| 先选最强模型 | 先搭好 harness,模型应该可以快速切换 |
| 先想清架构再动手 | Agent 是反馈密集型,先跑通最小闭环 |
| 框架越大越好 | 轻量基座 + 清晰边界通常更适合个人项目 |
| 只看最终输出 | 看 trajectory,失败常发生在工具选择和上下文管理 |
| 没有测试就加功能 | 先有 eval,再扩工具、加 memory、上 multi-agent |
agent harness engineering
type: 教程 status: 已发布 level: 高阶 topic:
- Agent
- 上下文工程
- MCP
Agent Harness Engineering:把裸模型变成能干活的系统
模型决定推理下限,Harness 决定产品上限。真正的 Agent 工程,不是只调用 LLM API,而是给模型配好工具、权限、状态、记忆、通道、反馈和评测。
什么是 Agent Harness
可以把 Agent 拆成两部分:
Agent = Model + Harness
- Model:负责理解、推理、生成、选择动作。
- Harness:负责把模型放进真实工作环境,提供工具、上下文、权限、状态、日志、回放、评测和人类反馈。
同一个模型,放在聊天窗口里只是问答助手;放进好的 harness 里,才可能成为能长期执行任务的 Agent。
为什么 Harness 重要
很多 Agent demo 失败,不是模型不够强,而是 harness 太弱:
- 工具描述含糊,模型经常选错工具
- 工具返回太长,污染上下文
- 没有权限分级,危险动作不可控
- 没有 session store,任务中断后无法恢复
- 没有 trace,失败后无法复盘
- 没有 eval,改动后不知道能力是否退化
- 没有成本上限,循环调用工具烧 token
Harness Engineering 的核心问题是:
如何设计一个运行环境,让模型能稳定、可控、可观测地完成真实任务?
七层模型
L7 自驱层(heartbeat / cron) 让 Agent 自己找活干
L6 通道层(CLI / Web / IM / Email)让 Agent 进入真实入口
L5 人格层(SOUL / policy) 让 Agent 跨模型不漂移
L4 记忆层(JSONL / SQLite / vector)让 Agent 记得上下文和偏好
L3 工具层(tools / skills / MCP) 让 Agent 真的能干活
L2 循环层(agent loop) 让 Agent 能持续观察和行动
L1 模型层(provider abstraction) 让 Agent 不绑死一家模型
初学者不要一开始就搭七层。第一周只需要跑通 L1 + L2 + L3:
- 模型能调用
- agent loop 能持续执行
- 工具能注册、执行、返回结果
后面的 memory、channel、heartbeat 都应该在真实需求出现后再加。
L1:模型层
目标:换模型不用改业务代码。
关键做法:
- 所有模型调用统一走
call_model(messages, tools, config) - provider 配置外置,支持 OpenAI / Anthropic / Gemini / 本地模型切换
- 输出统一成内部事件格式,例如
message,tool_call,final,error - 记录 token、延迟、模型名、请求 id
面试常问:
为什么不能直接在业务代码里到处调 SDK?
回答重点:
- provider 行为不同,必须做统一抽象
- 便于模型路由和 fallback
- 便于统计成本和排查问题
L2:循环层
目标:从一次问答变成持续工作。
最小 agent loop:
for step in range(max_steps):
response = call_model(messages, tools)
if response.type == "final":
return response.content
if response.type == "tool_call":
result = run_tool(response.tool_call)
messages.append(format_tool_result(result))
continue
raise MaxStepsExceeded()
必须有:
- 最大步数
- 超时
- 工具错误回传
- stop condition
- interrupt / resume 设计
- trace id
进阶设计:
- 一个 turn 可以包含多个 tool call
- 支持用户中途 steer
- 支持 context compaction
- 支持任务暂停和恢复
L3:工具层
目标:让 Agent 不只聊天,还能读取、搜索、计算、写入和调用外部系统。
工具设计原则:
| 原则 | 说明 |
|---|---|
| 名称语义互斥 | 不要让 search_docs 和 find_docs 同时出现 |
| description 面向模型 | 让模型知道什么时候用、什么时候不用 |
| schema 严格 | JSON Schema / enum / required 字段要清楚 |
| 返回可控 | 大结果分页、截断、摘要、附来源 |
| 最小权限 | 工具只暴露完成任务所需的最小能力 |
| 可观测 | 每次调用记录参数、结果、耗时、错误 |
推荐结构:
TOOLS = {
"search": search_tool,
"read_file": read_file_tool,
"write_file": write_file_tool,
}
新增工具应该是加一项注册,而不是改一坨 if-elif。
L4:记忆层
目标:让 Agent 在任务、会话和长期偏好之间保持连续性。
三类记忆:
| 类型 | 存什么 | 常见实现 |
|---|---|---|
| Working memory | 当前任务的短期状态 | messages / scratchpad |
| Episodic memory | 过去发生过什么 | JSONL / SQLite |
| Semantic memory | 用户偏好、事实、知识 | 向量库 / hybrid search |
不要过早上向量库。很多个人项目用 JSONL + SQLite 就能跑很久。
关键问题:
- 谁决定什么值得存?
- 写入门槛是什么?
- 什么时候合并、遗忘、压缩?
- 召回结果如何防止污染当前上下文?
L5:人格层
目标:让 Agent 的行为风格和边界跨模型保持稳定。
可以沉淀:
- 项目规则:
AGENTS.md/CLAUDE.md - 行为原则:
SOUL.md - 安全策略:policy / permission config
- 输出风格:templates
人格层不是玄学,它解决的是:
- 换模型后风格漂移
- 多入口回复不一致
- 风险场景没有统一边界
- 项目协作规则反复遗忘
L6:通道层
目标:让 Agent 不只躲在终端里,而是进入用户真实入口。
常见通道:
- CLI
- Web app
- Slack / 飞书 / Discord / Telegram
- GitHub Action
- 定时后台任务
设计原则:
- agent core 和 channel adapter 分离
- 不同通道共用 session / permission / trace
- 先把一个通道用透,再加第二个通道
L7:自驱层
目标:让 Agent 从“踹一下动一下”变成能主动检查任务。
常见方式:
- heartbeat
- cron
- queue worker
- webhook
- monitor
谨慎使用:
- 自驱层会放大成本
- 会放大错误动作
- 需要更强权限边界
- 需要更完整 trace 和告警
第一个月建议先关掉自驱层,等 eval 和权限成熟后再加。
可靠性六件套
| 机制 | 做什么 | 不做的后果 |
|---|---|---|
| Idempotency | 工具调用带幂等 key | 重启后重复发邮件、重复写入、重复扣款 |
| Timeout + Circuit Breaker | 每个工具有超时,连续失败后熔断 | trajectory 被慢工具拖垮 |
| Rate Limit Aware Retry | 指数退避、jitter、多 provider fallback | 限流后整个系统挂掉 |
| Cost Guard | 每个 trajectory 设置 token / 金额上限 | bug 无限循环烧成本 |
| Permission Tier | 读自动、写 dry-run + 人审、不可逆显式确认 | Agent 执行危险动作 |
| Observability | 记录 prompt、tool call、result、token、延迟 | 出问题无法回放和归因 |
Evaluation Harness vs Agent Harness
这两个概念容易混:
| 概念 | 解决什么 |
|---|---|
| Agent Harness | 让模型能在真实环境里工作 |
| Evaluation Harness | 评估模型或 Agent 是否完成任务 |
二者关系:
- Agent Harness 产生 trajectory
- Evaluation Harness 读取 trajectory、输出分数和失败归因
- 生产级系统里,评测和治理都依赖 trace
相关文档:
面试速查
| 问题 | 回答框架 |
|---|---|
| 怎么设计一个 Agent? | workflow vs agent -> loop -> tools -> context -> memory -> permission -> eval |
| 上下文太长怎么办? | 分层、压缩、检索、工具结果后处理、cache-friendly 结构 |
| 工具选错怎么办? | 改 description、拆/合工具、加 router、few-shot、看 trajectory |
| 什么时候用 multi-agent? | 子任务独立性强、上下文隔离有收益、最后能汇总 |
| 成本怎么控制? | 模型路由、prompt 瘦身、context 压缩、prefix cache、cost guard |
| HITL 怎么设计? | pre-turn、mid-turn、post-turn;读自动、写审查、不可逆确认 |
最小实现 checklist
- ☐
call_model()provider 抽象 - ☐ agent loop 有最大步数和超时
- ☐ tools 用注册表管理
- ☐ 工具 schema 严格,返回可控
- ☐ 每步记录 trace id、tool call、result、latency、token
- ☐ 高风险工具有 permission tier
- ☐ session 可以保存和恢复
- ☐ 至少 20 条 eval case
- ☐ README 写清运行、配置、限制和扩展方式
学习顺序
- 先手写一个最小 agent loop
- 加 3 个工具,跑通 dispatch 表
- 加 trace,能复盘每一步
- 加 context compaction 和 cost guard
- 加 permission tier
- 加 memory
- 加 eval
- 最后再考虑 multi-agent、browser、channel 和 heartbeat
career transition
type: 求职指南 status: 已发布 level: 入门 topic:
- 面试求职
0. 岗位类型选择指南⭐(必读)
核心洞察:大模型岗位的两条主线
关键问题:算法和开发如何划分?
在大模型时代,岗位划分的核心是:大模型算法工程师 vs 大模型开发工程师
┌─────────────────────────────────────────────────────────────┐
│ 大模型算法工程师 🔬 │
│ 核心:算法创新、论文发表、实验研究 │
│ 产出:论文、专利、算法库、开源贡献 │
└─────────────────────────────────────────────────────────────┘
↕️
┌─────────────────────────────────────────────────────────────┐
│ 大模型开发工程师 🛠️ │
│ 核心:系统搭建、业务落地、性能优化 │
│ 产出:生产系统、业务指标、用户满意度 │
└─────────────────────────────────────────────────────────────┘
注意: 两条线不是对立的,而是有交集的!优秀的工程师往往兼具两者能力。
一、两条主线详解
🔬 主线1:大模型算法工程师
核心定义: 专注于算法创新和技术突破,推动技术边界
判断标准(满足2条以上):
- ✅ 日常工作:读论文、做实验、写论文
- ✅ 核心产出:论文发表、算法库、专利
- ✅ 技术特点:在某个点上钻研到极致
- ✅ 评价标准:算法性能提升、创新性
典型工作场景:
早上:阅读最新论文(AAAI/NeurIPS/EMNLP)
上午:设计新算法,实现prototype
下午:跑实验、对比baseline、消融实验
晚上:分析结果、优化算法、准备论文
岗位数量: ⭐⭐⭐ 中等(大厂+头部创业公司)
🛠️ 主线2:大模型开发工程师
核心定义: 专注于系统落地和业务价值,用技术解决实际问题
判断标准(满足2条以上):
- ✅ 日常工作:写代码、优化系统、对接业务
- ✅ 核心产出:生产系统、业务指标、用户反馈
- ✅ 技术特点:多技术栈集成,端到端交付
- ✅ 评价标准:系统稳定性、性能指标、用户满意度
典型工作场景:
早上:站会、需求评审、技术方案讨论
上午:编码开发、集成第三方组件
下午:性能优化、问题排查、code review
晚上:监控告警、系统维护、文档编写
岗位数量: ⭐⭐⭐⭐⭐ 最多!(所有AI公司都需要)
二、技术方向细分
🔬 算法线:按技术方向细分
1️⃣ 模型算法工程师
技术方向:
- Reasoning算法:Long COT、工具调用RL、推理能力优化
- 对齐算法:RLHF、DPO、Constitutional AI
- 模型架构:MoE、长文本建模、注意力机制改进
- 预训练:数据配比、损失函数、训练稳定性
✅ 项目示例:
【Long COT推理算法优化】
- 问题:传统COT在复杂推理任务上准确率仅68%
- 方法:提出分层推理策略,结合强化学习优化推理路径
- 实验:在数学推理数据集上对比5种baseline,准确率提升15%
- 产出:论文在投NeurIPS,代码开源400+ stars
对应本文章节: Reasoning
岗位数量: ⭐⭐ 少(主要在大厂研究院)
2️⃣ 上下文工程算法工程师 ⭐⭐⭐ (热门!)
技术方向:
A. RAG算法方向:
- GraphRAG算法优化、Agentic RAG策略设计
- Reranker模型训练、检索召回优化
- 多模态RAG融合算法
- Agent Memory机制设计、记忆压缩算法
B. Agent算法方向:
- 规划算法优化(ReAct改进、Tree-of-Thought)
- 多Agent协同策略、通信协议设计
- Agent + RL:奖励模型设计、策略优化
C. 多模态算法方向:
- 跨模态对齐算法(CLIP改进、对比学习)
- 多模态融合策略(Attention机制设计)
- 多模态预训练(数据配比、损失函数)
核心洞察: RAG、Agent、多模态本质都是"如何给模型提供更好的上下文"
✅ 项目示例:
【GraphRAG检索算法优化】
- 问题:多跳推理场景下召回率低(62%)
- 方法:设计基于强化学习的子图采样策略,优化路径排序
- 实验:在KGQA数据集上F1提升12%,消融实验验证RL贡献8%
- 产出:论文在投EMNLP,贡献到GraphRAG开源项目
【Agent记忆机制设计】
- 问题:长对话场景下Agent记忆开销大、检索慢
- 方法:提出分层记忆压缩算法,结合语义聚类
- 实验:存储减少60%,检索速度提升3倍,信息保留率99%
- 产出:在投ICLR,集成到Mem0项目
【多模态对齐算法优化】
- 问题:CLIP在垂直领域(医疗影像)效果差
- 方法:改进负样本采样策略,引入领域知识蒸馏
- 实验:在医疗影像检索任务上mAP@10提升12%
- 产出:发表于CVPR Workshop,开源数据集
对应本文章节: RAG、Agent、多模态
岗位数量: ⭐⭐⭐⭐ 中等(技术含量高,成长空间大)
3️⃣ AI基础设施算法工程师
技术方向:
- 训练优化算法:ZeRO改进、通信算法优化、混合精度策略
- 推理加速算法:KV Cache优化、Flash Attention改进
- 模型压缩算法:量化算法、蒸馏策略、剪枝方法
✅ 项目示例:
【分布式训练通信优化】
- 问题:多机训练时通信成为瓶颈,GPU利用率仅60%
- 方法:设计梯度压缩算法,优化AllReduce调度策略
- 实验:在128卡训练中GPU利用率提升至85%,训练时间减少30%
- 产出:论文在投MLSys,贡献到DeepSpeed
对应本文章节: AI Infra
岗位数量: ⭐⭐ 少(主要在大厂基础设施团队)
🛠️ 开发线:按技术方向细分
1️⃣ 上下文工程开发工程师 ⭐⭐⭐⭐⭐ (岗位最多!推荐)
技术方向:
A. RAG系统开发:
- 企业知识库问答系统、智能客服
- 文档解析pipeline、AI搜索引擎
- 使用技术:LangChain、Milvus、GraphRAG框架
B. Agent应用开发:
- RPA自动化、研究助手、工作流Agent
- GUI Agent、Web交互Agent
- 使用技术:LangChain、AutoGen、Mem0
C. 多模态系统开发:
- 多模态文档解析、图文检索系统
- OCR pipeline、视觉问答系统
- 使用技术:CLIP、PaddleOCR、Milvus
D. Prompt工程:
- 业务Prompt优化、Few-shot构建
- COT链路设计、System Prompt调优
四种上下文工程形式对比:
| 形式 | 本质 | 技术实现 | 典型应用 |
|---|---|---|---|
| RAG | 检索增强上下文 | 向量检索、Reranker、知识图谱 | 企业知识库、智能客服 |
| Agent | 动态构建上下文 | 工具调用、Memory、任务规划 | RPA、研究助手 |
| Prompt Engineering | 指令设计上下文 | COT、Few-shot、System Prompt | 业务任务优化 |
| 多模态 | 跨模态上下文 | 图文对齐、OCR、视觉理解 | 文档解析、图文检索 |
✅ 项目示例:
【企业级GraphRAG知识问答系统】
- 背景:公司10万+内部文档需要智能检索
- 技术:GraphRAG + Neo4j + Milvus + FastAPI
- 优化:混合检索+缓存机制,响应时间从2s降至300ms
- 成果:服务1000+员工,日均2000+查询,准确率85%,满意度90%
【Agent驱动的RPA系统】
- 背景:客服部门每天5000+重复工单
- 技术:LangChain + WebShaper + Mem0记忆模块
- 优化:多Agent协同,异常处理,工具集成20+
- 成果:自动化率80%,效率提升3倍,节省人力成本200万/年
【多模态文档解析系统】
- 背景:处理合同、报表等复杂PDF文档
- 技术:PaddleOCR + LayoutParser + 结构化提取
- 优化:并行处理+GPU加速,吞吐量提升5倍
- 成果:日处理10万+页,准确率90%,错误率降低70%
对应本文章节: RAG、Agent、多模态
岗位数量: ⭐⭐⭐⭐⭐ 最多!(所有AI公司都需要)
2️⃣ AI基础设施开发工程师
技术方向:
- 推理服务:Triton、vLLM、TGI部署和优化
- 训练平台:KubeFlow、Ray搭建和维护
- 模型服务化:API网关、负载均衡、监控告警
- 资源调度:GPU资源管理、任务调度
✅ 项目示例:
【高性能推理服务平台】
- 背景:支撑公司100+模型服务,QPS峰值10000+
- 技术:vLLM + K8s + Istio + Prometheus
- 优化:动态批处理、模型并发、KV Cache复用
- 成果:P99延迟<500ms,GPU利用率85%,成本降低40%
对应本文章节: AI Infra
岗位数量: ⭐⭐⭐ 中等(大厂需求多)
3️⃣ AI应用开发工程师
技术方向:
- API封装、前端集成、用户系统
- 产品化、商业化、运营支持
岗位数量: ⭐⭐⭐⭐(技术含量较低,不在本文重点讨论)
三、两条主线对比总结
| 维度 | 大模型算法工程师 🔬 | 大模型开发工程师 🛠️ |
|---|---|---|
| 核心工作 | 算法创新、论文研究 | 系统搭建、业务落地 |
| 日常任务 | 读论文、做实验、写代码+论文 | 写代码、优化系统、对接业务 |
| 产出形式 | 论文、专利、算法库 | 生产系统、业务指标 |
| 技术特点 | 深度:一个点钻到极致 | 广度:多技术栈集成 |
| 评价标准 | 算法性能、创新性、影响力 | 系统稳定性、性能、用户满意度 |
| 技能要求 | 数学/ML理论、实验设计、论文写作 | 系统设计、工程实现、业务理解 |
| 岗位数量 | ⭐⭐⭐ 中等 | ⭐⭐⭐⭐⭐ 最多 |
| 门槛 | 高(需论文/竞赛) | 中(需项目经验) |
| 典型公司 | 大厂研究院、头部创业公司 | 所有AI公司 |
四、岗位选择决策树
Step 1: 你的核心优势是什么?
│
├─ 数学/理论强 + 喜欢钻研原理 + 有论文发表
│ → 【算法线】
│ ├─ 想改进模型本身 → 模型算法工程师(Reasoning、对齐)
│ ├─ 想优化上下文算法 → 上下文工程算法工程师(RAG/Agent/多模态算法)⭐推荐
│ └─ 想优化底层系统 → AI Infra算法工程师(训练/推理优化)
│
└─ 工程能力强 + 喜欢做系统 + 注重落地
→ 【开发线】
├─ 想做业务应用 → 上下文工程开发工程师(RAG/Agent/多模态系统)⭐⭐推荐
└─ 想做基础设施 → AI Infra开发工程师(推理部署、训练平台)
⭐ 最佳策略:两手抓!
- 简历中既有算法项目(论文、算法优化)
- 又有开发项目(完整系统、业务指标)
- 可以同时投两类岗位,灵活适配
五、简历准备策略 ⭐ 关键!
策略1:针对两条主线,差异化描述
🔬 投算法工程师岗位
简历重点:
✅ 必须强调:
- 算法创新:"提出XX算法"、"改进XX方法"、"设计XX策略"
- 实验验证:对比实验、消融实验、基线对比、指标提升
- 论文/专利:"论文在投XXX"、"发表于XXX"、"专利申请中"
- 开源贡献:"开源代码XX stars"、"贡献到XX项目"
- 技术深度:算法原理、数学推导、参数分析
❌ 尽量少提:
- 业务指标(用户数、QPS、成本节省)
- 系统架构(缓存、监控、部署)
- 工程细节(API设计、异常处理)
项目描述模板(算法线):
【GraphRAG检索算法优化】(算法创新型)
- 问题:多跳推理场景召回率低(实验测得62%)
- 方法:提出基于RL的子图采样算法,优化路径排序策略
- 实验:在KGQA数据集上F1提升12%,对比5种baseline
消融实验:RL策略贡献8%,路径排序贡献4%
- 产出:论文在投EMNLP(一作),代码开源300+ stars
- 技能:强化学习、图神经网络、知识图谱
【Agent记忆压缩算法】(算法创新型)
- 问题:长对话Agent记忆开销大(10轮后内存占用5GB)
- 方法:设计分层记忆压缩算法,语义聚类+重要性采样
- 实验:存储减少60%,检索速度3x,信息保留率99%
在3个benchmark上验证有效性
- 产出:论文在投ICLR,集成到Mem0开源项目
- 技能:序列建模、聚类算法、信息论
🛠️ 投开发工程师岗位
简历重点:
✅ 必须强调:
- 完整系统:"搭建XX系统"、"端到端实现"、"上线服务"
- 业务价值:服务用户数、处理量、业务指标提升
- 性能优化:QPS提升、延迟降低、成本节省、资源利用率
- 技术栈:具体框架、工具、数据库、部署方案
- 工程能力:高并发、高可用、监控告警、异常处理
❌ 不要过度强调:
- 算法细节和理论推导(除非特别突出)
- 论文(开发岗更看重系统)
项目描述模板(开发线):
【企业级GraphRAG知识问答系统】(系统落地型)
- 背景:公司10万+文档需智能检索,原有方案准确率仅60%
- 技术:GraphRAG + Neo4j + Milvus + FastAPI
混合检索(BM25+向量+图谱),三路召回融合
- 优化:引入Redis缓存,响应时间从2s→300ms
批处理优化,QPS从50→200
- 成果:服务1000+员工,日均2000+查询
准确率85%,用户满意度90%
- 技能:系统设计、性能优化、向量检索、分布式缓存
【Agent驱动的RPA系统】(系统落地型)
- 背景:客服部门日均5000+重复工单,人力成本高
- 技术:LangChain + WebShaper + Mem0
多Agent协同(规划Agent、执行Agent、审核Agent)
集成20+工具(数据库、API、浏览器操作)
- 优化:异常重试机制,成功率从70%→95%
并发处理,吞吐量提升5倍
- 成果:自动化率80%,效率提升3倍
节省人力成本200万/年,获部门最佳项目奖
- 技能:Agent开发、工具集成、异常处理、系统监控
策略2:两手抓!⭐⭐⭐ (最推荐)
为什么要两手抓?
- 增加面试机会:可同时投算法和开发岗,机会翻倍
- 展现全栈能力:大模型时代,算法+工程都重要
- 适应不同公司:大厂偏算法,创业公司偏工程,都能适配
理想简历结构(3-4个项目):
项目1:算法创新型 🔬
- 体现算法能力:GraphRAG算法优化 / Agent RL策略
- 关键词:论文、实验、开源
项目2:系统落地型 🛠️
- 体现工程能力:完整RAG系统 / Agent应用
- 关键词:业务指标、性能优化、上线
项目3:Training经验型(必备!)
- 体现训练能力:模型微调 / 分布式训练
- 关键词:多少卡、参数设置、训练稳定性
(可选)项目4:竞赛/开源贡献
- 体现综合实力:Kaggle Top 5% / 开源贡献500+ stars
不同岗位投递时的调整:
- 投算法岗:项目1放前面,突出算法创新
- 投开发岗:项目2放前面,突出系统落地
- 投Infra岗:项目3放前面,突出训练/推理优化
六、面试准备差异
🔬 算法工程师面试
高频问题类型:
- 算法设计类:
- "你的算法创新点是什么?为什么这样设计?"
- "有没有考虑过其他方法?为什么选择这个?"
- "算法的时间/空间复杂度是多少?"
- 实验验证类:
- "做了哪些对比实验?baseline选择的依据是什么?"
- "消融实验怎么做的?每个模块的贡献是多少?"
- "有没有失败的尝试?为什么失败?"
- 理论深度类:
- "能推导一下这个算法的数学原理吗?"
- "为什么这个loss function有效?"
- "如果数据分布变化,算法还有效吗?"
回答模板:
问题:你的GraphRAG算法改进点是什么?
回答:
1. 【问题分析】传统GraphRAG在多跳推理时召回率低,因为子图采样策略是随机的
2. 【方法设计】我提出了基于强化学习的采样策略:
- 状态:当前子图节点集合
- 动作:选择扩展哪个节点
- 奖励:根据最终答案是否正确给奖励
3. 【实验验证】在KGQA数据集上F1提升12%
- 对比了5种baseline(Random、BFS、PageRank等)
- 消融实验证明RL策略贡献8%
4. 【理论分析】本质是把离散优化问题转化为序贯决策问题
5. 【未来工作】可以引入图注意力机制进一步优化
🛠️ 开发工程师面试
高频问题类型:
- 系统设计类:
- "系统架构是怎么设计的?为什么这样设计?"
- "如果QPS增长10倍,怎么扩展?"
- "如何保证系统的高可用?"
- 性能优化类:
- "遇到过什么性能瓶颈?怎么发现和解决的?"
- "为什么响应时间能从2s降到300ms?具体做了什么?"
- "如何监控和定位性能问题?"
- 业务场景类:
- "为什么选择这个技术方案?有没有考虑其他方案?"
- "业务上遇到的最大挑战是什么?怎么解决的?"
- "用户反馈如何?根据反馈做了哪些迭代?"
- 异常处理类:
- "系统出现故障怎么办?有什么容错机制?"
- "线上出过什么问题?怎么排查和修复的?"
- "如何做监控和告警?"
回答模板:
问题:RAG系统响应时间怎么从2s优化到300ms的?
回答:
1. 【问题定位】用火焰图分析,发现瓶颈在:
- 向量检索:800ms(热点查询重复检索)
- Reranker推理:1000ms(模型太大)
- LLM生成:200ms(可接受)
2. 【优化方案】
- 引入Redis缓存:缓存热点查询的检索结果,命中率70%
- Reranker量化:INT8量化,推理速度3x,精度损失<1%
- 批处理优化:Reranker批量推理,提升吞吐
3. 【效果验证】
- P99延迟从2s→300ms
- QPS从50→200
- 缓存命中率稳定在70%
- 用户满意度从75%→90%
4. 【监控告警】
- Prometheus监控延迟、QPS、缓存命中率
- Grafana可视化
- 延迟>500ms自动告警
5. 【未来优化】可以考虑预取、预计算等策略
七、本文技术方向与岗位对应
📊 方向-岗位映射表
| 本文章节 | 算法工程师🔬 | 开发工程师🛠️ | 推荐优先级 |
|---|---|---|---|
| RAG | GraphRAG算法、Agentic RAG、Reranker训练 | RAG系统搭建、文档解析、智能客服 | ⭐⭐⭐⭐⭐ |
| Agent | Memory机制、规划算法、Agent+RL | Agent应用、RPA系统、工作流 | ⭐⭐⭐⭐⭐ |
| 多模态 | 跨模态对齐、融合算法、预训练 | 多模态系统、OCR、图文检索 | ⭐⭐⭐⭐⭐ |
| AI Infra | 通信优化、压缩算法、加速算法 | 推理部署、训练平台、监控 | ⭐⭐⭐ |
| Reasoning | Long COT、工具调用RL、推理优化 | 推理系统(较少开发岗) | ⭐⭐ |
🎯 岗位优先级建议
按岗位数量排序:
- ⭐⭐⭐⭐⭐ 上下文工程开发工程师(RAG/Agent/多模态系统)
- 岗位最多,所有AI公司都需要
- 门槛适中,容易上手
- 成长空间大,技术含量也不低
- ⭐⭐⭐⭐ 上下文工程算法工程师(RAG/Agent/多模态算法)
- 岗位适中,大厂+头部创业公司
- 技术含量高,有论文产出
- 需要算法背景和实验能力
- ⭐⭐⭐ AI基础设施开发工程师
- 大厂需求多,创业公司较少
- 需要系统工程能力
- 适合工程能力强的候选人
- ⭐⭐ AI基础设施算法工程师
- 岗位少,主要在大厂
- 门槛高,需要底层优化能力
- CUDA/系统编程
- ⭐⭐ 模型算法工程师
- 岗位少,主要在研究院
- 门槛高,需要论文和理论能力
- 适合读博或深度算法背景
按方向排序:
- 优先:RAG、Agent、多模态(上下文工程)—— 岗位多,易落地
- 次选:AI Infra —— 适合工程能力强的
- 谨慎:Reasoning —— 岗位少,门槛高,落地难
八、核心要点总结
✅ 关键结论
- 两条主线清晰划分:
- 🔬 算法工程师:做算法创新,产出论文/专利
- 🛠️ 开发工程师:做系统落地,产出业务价值
- 两者不对立,优秀工程师兼具两者能力
- 上下文工程是核心:
- RAG、Agent、Prompt、多模态本质都是"优化模型输入上下文"
- 这是当前岗位需求最旺盛的领域
- 建议重点准备!
- 简历策略:两手抓
- 既有算法项目(论文、算法优化)
- 又有开发项目(完整系统、业务指标)
- 灵活适配不同岗位,增加面试机会
- 方向选择建议:
- 首选:RAG/Agent/多模态(岗位多,技术含量适中)
- 适合工程强:AI Infra开发
- 适合算法强:上下文工程算法、模型算法
- 谨慎选择:Reasoning(岗位少,门槛高)
- 面试准备差异:
- 算法面试:重理论、重实验、重创新
- 开发面试:重系统、重性能、重业务
🎯 行动建议
对于应届生/转行者:
- 建议先从开发线入手(门槛较低,岗位多)
- 做1-2个完整的RAG/Agent系统项目
- 积累工程经验后,逐步向算法线发展
对于有算法背景者:
- 建议算法+开发两手抓
- 做算法创新项目(发论文/开源)
- 同时做系统落地项目(展现工程能力)
对于有工程背景者:
- 建议从上下文工程开发切入
- 重点掌握RAG/Agent系统搭建
- 学习基础算法原理,逐步提升技术深度
1. RAG(Retrieval-Augmented Generation)
概述
RAG结合检索与生成,广泛应用于智能客服、文档解析、搜索等场景。秋招中,RAG相关项目是简历和面试的亮点,尤其适合无实习经历的候选人。
核心技术
- 传统RAG:从知识库检索相关文档,结合LLM生成答案。
- 多模态RAG:融合文本、图像、表格等多模态数据,提升检索和生成质量。
- GraphRAG:基于知识图谱的RAG,增强复杂关系推理。
- Agentic RAG:基于Agent的自主检索,动态规划查询策略,优化复杂问题的信息获取。
- AI搜索:结合RAG的搜索系统,优化查询效率和结果相关性。
准备要点
- 项目经历:
- 实现一个RAG项目(如智能客服系统),包含数据预处理、嵌入生成、检索优化和生成微调。
- 使用**专有领域数据**(如公司内部文档、行业数据集),避免通用数据集(如GSM8K)。
- 展示**Training经验**,如对LLM进行LoRA或SFT微调以适配特定任务。
- 技术细节:
- **嵌入模型**:熟悉Sentence-BERT、CLIP等,优化文本/图像嵌入。
- **向量数据库**:掌握Milvus、Faiss、Chroma等,用于高效检索。
- **优化技巧**:如检索召回率优化(BM25+神经网络)、生成质量提升(Prompt Engineering)。
- 推荐工具:
- **MinerU**:文档解析,适合处理PDF、图像等多模态输入。
- **Milvus**:向量数据库,支持高维嵌入存储和快速检索。
- **Llama-factory**:模型微调工具,快速实现LoRA/SFT。
注意事项
- 突出项目中数据处理的独特性,如清洗特定领域数据或优化多模态检索。
- 简历中避免重复描述RAG经历,选择最能体现技术深度的项目。
- 面试中准备好回答RAG的召回率和生成质量优化方法。
2. Agent
概述
Agent方向聚焦智能体设计,强调自主决策、工具调用和任务规划,岗位需求旺盛。秋招中,Agent相关项目能显著提升竞争力。
核心技术
- DeepResearch相关技术:
- **MiroMind Agent**:多模态任务规划智能体。
- **CognitiveKernel-Pro**:认知驱动的Agent框架,强调推理和记忆。
- **WebShaper**:Web交互Agent,擅长自动化任务。
- **Owl**:跨领域任务处理智能体。
- **AgentOrchestra**:多Agent协同框架。
- GUI Agent:基于图形界面的智能体,参考论文如GUI TARs,实现界面交互自动化。
- Agent Memory:如Mem0,为Agent提供长期记忆,但需注意复现问题。
- 评估Benchmark:
- **GAIA**:通用人工智能评估,测试Agent任务完成能力。
- **Human Last Exam**:模拟人类复杂任务,评估Agent综合能力。
准备要点
- 项目经历:
- 开发一个Agent项目,如基于WebShaper的自动化爬虫或GUI Agent的界面操作工具。
- 体现**工具调用**能力,如调用API、数据库或外部工具。
- 展示**多Agent协同**或**记忆模块**(如Mem0)的应用。
- 技术细节:
- **框架**:熟悉LangChain、LlamaIndex等Agent开发框架。
- **记忆管理**:实现上下文记忆或外部记忆存储(如Mem0、Redis)。
- **评估**:使用GAIA或自定义任务评估Agent性能。
- 推荐工具:
- **LangChain**:快速构建Agent工作流。
- **Mem0**:轻量级记忆模块(谨慎使用,验证复现稳定性)。
- **Milvus**:支持Agent检索外部知识。
注意事项
- Mem0复现问题:社区反馈可能存在Bug,建议验证后再写进简历。
- 面试准备:熟悉Agent的任务规划(如ReAct、Plan-and-Execute)和评估指标(如任务成功率、响应时间)。
- 优先关注DeepResearch和GUI Agent,因其岗位需求较多。
补充:Agent开发工程师的核心能力要求⭐
基于OpenAI、DeepMind、Meta、蚂蚁等大厂的真实招聘要求总结
🎯 三层能力模型
Layer 1:后端与系统功底(基础)
- 大型分布式、高并发、高性能系统设计经验
- 云原生PaaS平台、Kubernetes架构理解
- 核心价值:Agent系统本质是复杂的分布式服务,需要稳定性、可观测性、成本控制
Layer 2:Agent核心技术(重点)
- 混合Agent架构:单Agent vs 多Agent协同(Supervisor模式、专家Agent分工)
- 上下文工程:如何为特定任务构建高质量上下文(动态打包、向量索引、信息检索)
- 工具编排:Tool设计、Function Calling、工具调用管理
- 记忆与个性化:Memory设计(何时存储、如何召回、长对话处理)memo0 zep
- 任务规划:Orchestration、Workflow、多Agent协同
- 评估体系:如何证明Agent比人工更好?如何量化优化效果?
Layer 3:模型理解(加分项)
- 了解主流模型长短板(GPT-4/Claude/Llama的选择策略)
- 微调能力(Fine-tuning工具调用能力、垂直领域适配)
- 强化学习基础(Agent RL、DPO等)
💡 从"调包侠"到"真实项目"的关键转变
❌ 玩具项目特征:
- 只用LangChain/LlamaIndex跑个demo
- 几行代码串起几个LLM调用
- 没有评估、没有优化、没有生产化考虑
✅ 真实项目特征:
1. 具体业务场景
- 例:智能投后报告分析助手(处理PDF财报,回答关键问题)
- 例:自动化RPA系统(处理工单,工具调用,异常处理)
2. 完整技术栈
- 复杂数据处理(PDF解析、表格提取、图片OCR)
- 高级RAG策略(HyDE、Multi-Query、Graph RAG)
- Agentic逻辑(ReAct循环、Tool Use、多Agent协同)
3. 量化评估体系⭐ 重要!
- 构建评估集(20份报告、100个问题、标准答案)
- 使用Ragas等框架(faithfulness、answer_relevancy)
- 持续追踪优化效果(从60%→85%的过程)
4. 生产化考虑
- 成本控制(按token计费、缓存策略、小模型替代)
- 性能优化(延迟、并发、批处理)
- 可观测性(LangSmith、W&B追踪每次调用)
- 稳定性(异常重试、容错机制、监控告警)
🔧 Agent开发中的实战问题
1. Memory设计难题:
- Supervisor规划任务后直接update,还是子Agent执行完再callback?
- 日常对话中大量无用信息,如何判断是否存入Memory?
- 长对话上下文如何处理?总结后如何存储?多少轮后不支持回溯?
2. 语义理解:
- Embedding模型选择(如何确定业务最适合的模型?)
- 多意图并发识别(用户真实意图是什么?)
- 意图识别准确性(知识库检索和意图识别都需要)
3. 任务管理:
- 中途任务强行结束怎么办?如何撤销?
- 多工具分布调用如何解决?
- 如何规划任务流程?(Orchestration策略)
4. RAG优化:
- 单/多模态RAG检索怎么做?
- 如何提高检出率?如何评价检出质量?
- 知识库文档怎么切片合适?
- 多工具多Prompt下,消融实验怎么展开?
5. 评估标准:
- 如何评价Agent解决问题的质量?
- 走完用户指定任务 vs 各个任务节点完成质量?
- 如何设计自动化评估流程?
📚 推荐学习资源
开源项目(深入理解架构):
- OpenManus:比LangChain更清晰的Agent实现
- AgentUniverse:阿里开源的Agent框架
- AutoGen:微软的多Agent框架
- LangGraph:状态机驱动的Agent编排
关键建议:
- 研究源码:理解框架如何管理状态、工具路由、输出解析
- 手写RAG:用sentence-transformers + Faiss手动实现,理解每个环节
- 建立评估:没有评估,一切优化都是玄学
- 关注成本:一个设计不好的Agent链条可能一个请求调用LLM十几次
⚠️ 避坑指南
- 框架过度依赖
- LangChain/LangGraph抽象和封装过度,遇到问题难以调试
- 建议:理解原理,必要时自己实现或魔改
- 评估集问题
- Demo效果惊艳 ≠ 线上可用
- 评估集太小、太"干净",无法覆盖真实复杂场景
- 建议:构建真实、多样、有挑战性的评估集
- 生产化意识缺失
- 只关注功能实现,忽视成本、延迟、稳定性
- 建议:从一开始就考虑缓存、监控、异常处理
- 后端优势的忽视
- 如果有后端背景,这是你最大的优势
- Agent系统需要服务治理、高可用设计、可观测性
- 建议:突出如何用后端能力解决Agent系统的工程问题
3. AI Infra(AI基础设施)
概述
AI Infra聚焦大模型训练、部署和优化,强调工程能力,适合对分布式系统、并行计算感兴趣的候选人。秋招中,AI Infra岗位对Training经验要求高。
核心技术
- 训练优化:分布式训练(DDP、FSDP)、混合精度训练、梯度累积。
- 部署优化:模型压缩(蒸馏、量化)、推理加速(Triton、ONNX)。
- 基础设施工具:KubeFlow、Ray、DeepSpeed、Megatron-LM。
- 通信优化:NCCL、Gloo,优化多卡通信效率。
准备要点
- 项目经历:
- 实现一个分布式训练项目,如用DeepSpeed训练LLaMA模型。
- 展示**模型蒸馏**(如R1蒸馏)或**量化**(如INT8)经验。
- 优化训练效率,如减少显存占用或加速通信。
- 技术细节:
- **参数设置**:熟悉学习率、批大小、Warmup等设置的原理。
- **通信优化**:如AllReduce优化、通信调度。
- **监控工具**:使用TensorBoard或W&B监控训练指标。
- 推荐工具:
- **DeepSpeed**:分布式训练框架,支持ZeRO优化。
- **Llama-factory**:快速实现LoRA/SFT。
- **Triton**:推理服务器,优化模型部署。
注意事项
- 简历中突出训练规模(如用了多少卡、训练了多少epoch)和优化成果(如显存降低XX%)。
- 面试中准备好回答通信瓶颈和训练稳定性问题。
- AI Infra岗位更看重工程实现,需展示代码能力和系统设计理解。
4. Reasoning
概述
Reasoning方向聚焦大模型的推理能力,如工具调用、长链推理(Long COT)。秋招中,Reasoning岗位需求较实习多,但因落地难度大,邀面机会可能较少。
核心技术
- Deep Research RL:强化学习驱动的工具调用,参考MiroMind Agent相关论文。
- Long COT Reasoning:长链推理,如M2-Reasoning,针对垂域复杂任务。
- 评估Benchmark:GAIA、Human Last Exam,测试推理能力。
准备要点
- 项目经历:
- 实现一个Reasoning项目,如基于Long COT的数学推理或工具调用任务。
- 结合**垂域数据**,如金融、法律领域的推理任务。
- 展示**Prompt优化**(如COT、Self-Consistency)或RLHF经验。
- 技术细节:
- **COT(Chain of Thought)**:设计结构化推理Prompt。
- **工具调用**:实现API调用或外部工具集成。
- **评估**:使用GAIA或自定义指标评估推理准确性。
- 推荐工具:
- **Llama-factory**:支持RLHF和COT微调。
- **LangChain**:快速实现工具调用。
- **HuggingFace Datasets**:获取垂域数据集。
注意事项
- Reasoning方向技术门槛高,需深入理解Prompt设计和RL原理。
- 秋招中邀面机会可能较少,建议作为次选方向,优先RAG或Agent。
- 面试中准备好回答推理失败案例和优化思路。
5. 多模态
概述
多模态方向结合文本、图像、音频等数据,广泛应用于AI搜索、文档解析等场景。秋招中,多模态RAG和多模态Agent是热门领域。
核心技术
- 多模态RAG:融合文本、图像、表格的检索与生成。
- 多模态Agent:支持多模态输入的智能体,如图像引导的任务规划。
- 多模态预训练:如CLIP、BLIP,处理跨模态嵌入。
- OCR与文档解析:处理图像中的文本提取和结构化。
准备要点
- 项目经历:
- 实现一个多模态RAG项目,如基于CLIP和Milvus的图像+文本检索系统。
- 开发文档解析项目,提取PDF中的文本、表格和图像。
- 展示多模态数据预处理,如图像增强、文本清洗。
- 技术细节:
- **嵌入模型**:熟悉CLIP、BLIP的跨模态嵌入生成。
- **数据融合**:实现文本+图像的联合表示学习。
- **评估**:使用多模态Benchmark(如MSCOCO、VisualQA)评估效果。
- 推荐工具:
- **PaddleOCR**:高效OCR工具,适合文档解析。
- **Rapid_OCR**:轻量级OCR,适合快速部署。
- **CLIP**:跨模态嵌入生成。
- **Milvus**:支持多模态向量检索。
注意事项
- 突出多模态数据处理的独特性,如处理复杂表格或低质量图像。
- 面试中准备好回答跨模态对齐和数据噪声问题。
- 多模态方向岗位需求旺盛,建议优先准备。
通用建议
- 简历优化:
- 保持**一页**,突出核心项目,删除重复或次要经历。
- 结构化展示:教育背景、实习经历、项目经历、技术技能。
- 论文仅单列一行(如“在投”),留空间给工程经历。
- 面试准备:
- 准备**项目故事**:问题点、优化措施、成果指标。
- 熟悉八股文,突出Training经验(如多少卡、参数设置)。
- 回答技术细节时,结合业务场景,展现落地能力。
- 时间规划:
- 提前1-2个月刷LeetCode(Hot 100+Interview 150)。
- 提前3-4个月积累项目,关注热门方向(如R1蒸馏、Agent)。
- 开源项目投稿:
- 投稿论文到OpenReview,记录“在投”状态,增加简历亮点。
- 参与开源项目(如Llama-factory、MinerU),提升技术影响力。
总结
- 优先方向:多模态和Agent岗位需求多,易落地,建议重点准备。
- 次选方向:RAG适合无实习经历的候选人,AI Infra适合工程能力强的候选人,Reasoning需谨慎选择。
- 核心目标:通过项目和八股展现工程能力和业务理解,突出Training经验和专有领域数据处理。
- 心态:秋招竞争激烈,多投简历,持续优化,机会总会到来。
祝大家秋招顺利,拿到心仪offer!#互联网大厂 #大模型 #算法 #秋招 #校招
AgentGuide开源学习路线(简易版本)
type: 路线图 status: 已发布 level: 通用 topic:
- 面试求职
- 基础模型
- Agent
🚀 大模型 / Agent 全栈学习路线

核心逻辑:先明确目标岗位→按岗位路线分阶学习→项目实战→简历包装→面试冲刺,全程以「拿 Offer」为导向,避免盲目学习。
阶段 1:定位与路线规划(1 周)
优先资源:🎯 AgentGuide 求职宝典🌐 GitHub:adongwanai/AgentGuide《Agent 求职通关秘籍》:

- 岗位分轨:明确「算法岗(10-15 周)」vs「开发岗(8-12 周)」核心差异(算法岗重策略优化 / RL,开发岗重工程落地 / RAG)。
- 路线拆解:
- 算法岗:基础(Python/ML)→ LLM 原理(Transformer)→ Agent 范式(ReAct/CoT)→ RAG 进阶→ RLHF / 对齐→ 论文复现。
- 开发岗:基础(Python / 数据库)→ LLM 部署(API / 本地)→ RAG 全流程→ Agent 框架(Dify/Coze)→ 系统集成→ 项目上线。
- 求职工具:简历模板(算法 / 开发岗适配)、面试高频考点(如「Agent 与传统软件的区别」「RAG 性能优化」)、谈薪 / HR 攻略,提前规避求职坑。
**产出**:确定目标岗位,制定周度学习计划,标注「面试必考点」。
阶段 2:基础能力夯实(2-4 周)
算法岗核心:
- Python 与 ML 基础:
- 推荐:《Python 编程:从入门到实践》+ LeetCode 中等题(数组 / 字符串 / 动态规划,面试基础)。
- LLM 底层原理:
- 推荐:
🧠 **nanoGPT**(karpathy/nanoGPT):300 行代码吃透 Transformer 注意力机制、词嵌入、生成逻辑,理解「大模型黑箱」。

📚 **吴恩达大模型系列课程中文版**(datawhalechina/llm-cookbook):AI 教父课程本地化,覆盖预训练 / 微调核心概念。
**开发岗核心**:
- Python 与工程基础:
- 推荐:FastAPI/Flask(API 开发)、Docker(环境封装)、Git(版本控制),掌握「代码可复用性」。
- LLM 应用入门:
- 推荐:
🎓 **AI-Guide-and-Demos-zh_CN**(Hoper-J):从 OpenAI API 调用→ 本地部署(Llama 3/Qwen3)→ 基础微调,提供 Colab 在线环境,零基础可上手。

💻 **动手学大模型**(Lordog/dive-into-llms):上交大开源教程,含 GUI Agent、数学推理等实战,适合快速练手。
**产出**:算法岗能复现简单 Transformer 模块;开发岗能独立调用 LLM API 并部署本地模型。
阶段 3:核心技术突破(算法岗 6-8 周 / 开发岗 4-6 周)
模块 A:Agent 核心(算法 / 开发岗均需)
- 优先资源:
🔫 **Hello-Agents**(datawhalechina/hello-agents)
《AI 原生 Agent 从 0 到 1 构建指南》:
- 算法岗重点:拆解 ReAct、Plan-and-Solve 等经典范式,实现单智能体决策逻辑,进阶多智能体通信(MCP 协议)与 Agentic RL 训练。
- 开发岗重点:用 Coze/Dify 低代码平台快速搭建「智能旅行助手」,再尝试自研轻量 Agent 框架(如任务调度 + 工具调用)。
- 
- 实战项目:
- 算法岗:复现「论文检索 Agent」(结合 RAG 实现学术文献自动摘要与引用)。
- 开发岗:搭建「赛博小镇」多智能体系统(模拟居民互动,涉及 Agent 协作与记忆机制)。
模块 B:RAG 技术(Agent 知识底座)
- 优先资源:
🔍 **All-in-RAG**(datawhalechina/all-in-rag)

《RAG 全栈通关手册》:
- 算法岗重点:向量索引优化(如 IVF-PQ 量化)、混合检索策略(BM25 + 向量检索)、检索评估指标设计(如 MRR、Hit@k)。
- 开发岗重点:数据加载→文本分块→Milvus 部署→检索接口开发,完成「智能美食推荐 RAG 系统」(300 + 食谱匹配)。
- 产出:算法岗能优化 RAG 检索精度;开发岗能独立搭建生产级 RAG 问答系统。
模块 C:微调技术(算法岗核心 / 开发岗可选)
- 算法岗优先:
⚡ **Unsloth**(unslothai/unsloth):2 倍训练速度 + 70% 显存节省,用 14GB GPU 训练 20B 模型,适配 GPT-OSS/Qwen3,原生支持 GRPO 强化学习(提升 Agent 工具调用精度)。
🚀 **LLaMA-Factory**(hiyouga/LLaMA-Factory):100 + 模型统一微调框架,覆盖 SFT/DPO/GRPO,可实现多模态微调(如 Qwen3-VL 图文检索)。

- 开发岗可选:用 LLaMA-Factory Web UI 完成 LoRA 微调,适配特定场景(如客服问答)。
- 数据支撑:
📊 **Easy-Dataset**(ConardLi/easy-dataset):自动处理 PDF/Markdown 文档,生成带 CoT 的问答数据,导出 Alpaca 格式直接对接微调框架,告别手动标注。
**产出**:算法岗能完成 LLM 策略微调;开发岗能基于开源数据快速适配模型。
阶段 4:项目实战与简历包装(2-3 周)
- 简历项目打磨:
- 参考 AgentGuide 的「项目杀器」:
- 算法岗:突出「论文检索 Agent」(技术点:ReAct 范式 + Graph RAG+GRPO 强化学习)、「大模型对齐实验」(DPO 训练)。
- 开发岗:突出「旅行规划 Multi-Agent」(技术点:Dify 低代码 + Milvus 向量库 + Docker 部署)、「企业知识库 RAG 系统」(技术点:混合检索 + 权限控制)。
- 每个项目标注「技术栈 + 解决问题 + 量化指标」(如「检索准确率提升 25%」「部署成本降低 40%」)。
- 实战项目落地:
- 算法岗:复现顶会 Agent 论文(如 AutoGPT、MetaGPT)核心模块,在 GitHub 开源并撰写技术博客。
- 开发岗:将 RAG+Agent 系统部署到云服务器(如阿里云 ECS),提供公开 Demo 链接。
**产出**:适配目标岗位的简历 + 2-3 个可演示的实战项目。
阶段 5:面试冲刺(1-2 周)
- 高频考点突击:
- 算法岗:Agent 范式对比(ReAct vs Plan-and-Solve)、RAG 性能调优(分块策略 / 向量量化)、RLHF 原理(DPO/PPO 区别)。
- 开发岗:LLM 部署方案(vLLM/Ollama)、向量数据库选型(Milvus vs Pinecone)、系统高可用设计(缓存 / 降级)。
- 模拟面试:
- 用 AgentGuide 的「面试题库」自测,重点准备「项目复盘」(如「你在 RAG 系统中遇到的最大问题是什么?如何解决?」)。
- 谈薪与 HR 攻略:
- 参考 AgentGuide 的「谈薪技巧」,明确行业薪资范围,突出项目价值(如「搭建的 RAG 系统为公司节省 50 万标注成本」)。
**产出**:面试通过率提升 30%+,拿到目标 Offer。
学习建议
- 按岗位聚焦:算法岗深耕原理与策略,开发岗侧重工程与落地,避免「全而不精」。
- 边学边输出:每完成一个模块,在 GitHub 提交代码、写技术笔记(如 CSDN / 知乎),形成个人品牌。
- 紧跟社区:关注项目更新(如 Unsloth 新增 TTS 支持、LLaMA-Factory 适配 Llama 4),面试时体现技术敏锐度。
总结:以 AgentGuide 为路线图,先定岗位→再夯基础→攻核心技术→做实战项目→冲面试,全程目标明确,效率拉满!按此路线执行,8-15 周即可具备大模型 / Agent 领域求职硬实力~
algorithm complete learning guide
type: 路线图 status: 已发布 level: 通用 topic:
- 面试求职
- 模型训练
- 科研
前沿算法岗位完整学习指南
基于北上杭深真实算法岗位的技术职责、硬要求和加分项生成。生成时间:2026-07-15T16:13:26+08:00。
使用方法
这份指南把岗位中的技术职责、硬要求和加分能力归并到阶段能力模块中。模块用于明确学习边界,实践任务、交付物、验收标准和技术索引按阶段统一组织。
建议维护一个贯穿全程的实验仓库,统一保存环境、数据、训练、评测、部署、失败案例和技术决策。不要把每个阶段做成互不关联的玩具项目。
完整性口径
- 6635 条技术要求均映射到一个阶段能力模块;主文档不再逐句重复。
- 357 项算法主关键词与补充技术词共同进入各阶段技术索引;每个词放在最适合学习的主阶段,避免重复堆砌。
- 基础技术词表共 535 项,并从技术要求中补充缩写、框架和工具名。
- 职责动作由能力闭环、实践任务和验收标准承接;具体技术对象由模块内容和技术索引承接。
- 教育、院校、毕业批次和数字年限已在上游筛选文档中删除,本指南不重新引入。
能力全景
| 阶段 | 能力域 | 建议节奏 | 能力模块 | 技术关键词 | 核心产出 |
|---|---|---|---|---|---|
| 0 | 工程环境、编程与实验规范 | 2-4 周 | 6 | 62 | 训练模板仓库、故障排查手册 |
| 1 | 数学、统计、机器学习与优化基础 | 4-6 周 | 6 | 86 | 数学推导笔记、传统 ML 基线仓库 |
| 2 | 深度学习、Transformer 与生成建模 | 5-8 周 | 6 | 32 | Transformer 实现、生成模型实验 |
| 3 | 数据工程、语料治理与合成数据 | 4-7 周 | 7 | 73 | 版本化数据集、数据质量报告 |
| 4 | 预训练、模型架构、MoE 与长上下文 | 6-10 周 | 7 | 102 | 预训练配方、Scaling 实验 |
| 5 | 后训练、PEFT、强化学习与模型对齐 | 7-12 周 | 7 | 137 | 后训练流水线、偏好与奖励数据 |
| 6 | RAG、Agent、工具调用、记忆与长程规划 | 6-10 周 | 7 | 95 | RAG 系统、长程 Agent |
| 7 | 多模态、视觉语言、语音、视频与具身模型 | 7-12 周 | 7 | 134 | 多模态微调项目、生成模型项目 |
| 8 | 评测、Benchmark、实验工程与因果分析 | 4-7 周并持续进行 | 7 | 50 | 评测框架、Benchmark 数据卡 |
| 9 | AI 安全、红队、鲁棒性、事实性与隐私 | 4-8 周并持续进行 | 7 | 29 | 威胁模型、红队与安全评测集 |
| 10 | 分布式训练、训练平台与 AI Infra | 5-9 周 | 7 | 58 | 多卡训练方案、Profiling 报告 |
| 11 | 推理、Serving、压缩与性能优化 | 5-8 周 | 7 | 55 | 推理服务、性能基准 |
| 12 | 垂直算法分支与业务建模 | 任选 1-2 个方向,各 6-10 周 | 8 | 75 | 领域端到端项目、业务指标树 |
| 13 | 论文复现、研究方法、产品落地与作品集 | 贯穿全程,集中整理 4-6 周 | 7 | 207 | 论文复现仓库、开源贡献 |
推荐推进方式
- 阶段 0-2 是共同基础,应先完成可复现训练模板、数学基线和 Transformer/生成模型实验。
- 阶段 3-5 打通数据、预训练和后训练,是基础模型算法岗的核心主线。
- 阶段 6-9 按 Agent、多模态、评测和安全逐步扩展,所有方向都必须建立可重复评测。
- 阶段 10-11 负责把算法变成可规模化训练和稳定服务的系统。
- 阶段 12 选择一到两个垂直方向形成深度;阶段 13 从第一天开始持续积累证据。
不要用课程数量衡量进度。每个阶段必须留下代码、数据说明、实验结果、失败分析和验收记录。
阶段 0:工程环境、编程与实验规范
建议节奏:2-4 周。能力模块:6 个。
学习目标
建立可复现、可调试、可扩展的算法研发底座,能独立完成数据处理、训练、评测和服务接口。
必学内容
能力闭环:原理研究与复现、数据构建与治理、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、安全、鲁棒与合规、原理理解与实际应用。
- 模块 0.1:Python、C/C++、SQL、Shell;补充 Go/Java/Rust 在服务和高性能模块中的使用边界。
- 模块 0.2:Linux、Git、Docker、Conda/uv、CUDA 环境、依赖锁定、配置管理和随机种子。
- 模块 0.3:NumPy、Pandas、SciPy、scikit-learn;PyTorch Dataset、DataLoader、autograd 与自定义算子。
- 模块 0.4:日志、断点续训、指标记录、实验追踪、数据校验、单元测试、回归测试和故障复现。
- 模块 0.5:数据结构、复杂度、并发、网络、数据库、RPC/REST、缓存、消息队列和微服务基础。
- 模块 0.6:Profiling、数值异常、梯度异常、OOM、I/O 瓶颈和线上问题定位。
实践任务
- 实现一个可配置的 PyTorch 训练模板,支持 AMP、断点恢复、独立评测和实验追踪。
- 为数据为空、标签越界、NaN、梯度爆炸、OOM 和训练中断分别编写复现与修复用例。
- 把模型封装为 REST/RPC 服务,加入超时、重试、幂等、批处理、监控和压测。
可交付成果
- 训练模板仓库
- 故障排查手册
- 接口与压测报告
验收标准
- 换机器后可按文档复现实验,关键依赖和随机性来源可追踪。
- 能解释训练慢、显存高、结果漂移和服务不稳定的具体原因。
- 代码具备测试、日志、配置、版本和最小可观测性。
技术关键词索引
AI-Native、c++、cuda、docker、FastAPI、FForking、Full-stack、gitGitHub、golang、go语言、GtHub、huggingface、ICPC、java、jaxJS、k8s、keras、kubernetes、linux、MATLAB、mindspore、MMDetectionModelScope、MySQL、numpy、OD、OOP、OpenCode、opencv、PaddleDetectionpaddlepaddle、pandas、PostgreSQL、PR、PyQt、python、pytorch、QNNrepo-level、RT-DETR、rust、scala、scikit-learn、scipy、shell、SIMULINKsklearn、SPSS、sql、SWE-bench、TCP、tensorflow、transformers、tritonXZ0000580、并发编程、数据库、网络编程、计算机基础、软件工程
阶段 1:数学、统计、机器学习与优化基础
建议节奏:4-6 周。能力模块:6 个。
学习目标
能从目标函数、数据分布和统计假设解释算法,而不是只会调用框架。
必学内容
能力闭环:原理研究与复现、数据构建与治理、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、安全、鲁棒与合规、原理理解与实际应用。
- 模块 1.1:线性代数:向量空间、矩阵分解、特征值、SVD、低秩近似和张量运算。
- 模块 1.2:概率统计:条件概率、贝叶斯、常见分布、最大似然、假设检验、置信区间和校准。
- 模块 1.3:优化:梯度下降、动量、AdamW、约束优化、凸优化、拉格朗日、数值稳定性。
- 模块 1.4:机器学习:线性/逻辑回归、树模型、Boosting、聚类、降维、异常检测和特征工程。
- 模块 1.5:泛化:偏差方差、正则化、交叉验证、数据泄漏、分布偏移和不确定性。
- 模块 1.6:实验统计:效应量、显著性、功效、方差缩减、因果推断和 uplift 建模基础。
实践任务
- 不用深度学习框架实现线性模型、MLP 和反向传播,并进行梯度检查。
- 完成树模型与神经网络的同数据对比,分析数据规模、特征和误差类型。
- 设计一组有置信区间的对照实验,说明结论何时成立、何时不能外推。
可交付成果
- 数学推导笔记
- 传统 ML 基线仓库
- 统计实验报告
验收标准
- 能推导常用损失和优化更新,并解释稳定性与收敛问题。
- 能识别泄漏、混杂、过拟合和指标误导。
- 能为新问题建立合理基线,而不是直接上大模型。
技术关键词索引
AI+、ARM、BLOOM、C#、CANN、CCPC、co-design、DALIDeepSpeedd、Diffusion-based、DLRover、DNN、DQN、DSA、end-to-end、ESPnetfasterTransformer、GBDT、GNN、GO、GPGPU、hands-on、HMM、IEGInference、IP、LIO-SAM、LLaMA、LLamaFactory、LM、Long-CoT、LPLSTM、MACE、MapTR、MASt3R、MCTS、MDP、MILP、MINLPMIP、MLIR、MLM、mniGuard、MXNet、NN、NPU、NVIDIAObjective-C、PhD、PHP、Python+Pytorch、QWen、RDMA、RESTful、Self-EvolvingSFTRLHF、Spec-Decoding、SwiftUI、SysML、TCN、TensorBoard、TF、TorchScriptTRT-LLM、VAD、VGGT、VideoMAE、ViT、WeNet、WFST、x86XLA、凸优化、因果推断、数值计算、数学模型、数据结构、数理统计、最优化机器学习、概率统计、概率论、特征工程、特征提取、线性代数
阶段 2:深度学习、Transformer 与生成建模
建议节奏:5-8 周。能力模块:6 个。
学习目标
掌握现代基础模型共同的表示学习、序列建模和生成建模原理。
必学内容
能力闭环:原理研究与复现、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、原理理解与实际应用。
- 模块 2.1:MLP、CNN、RNN/LSTM、残差、归一化、初始化、激活函数、正则化和损失设计。
- 模块 2.2:Attention、Transformer、位置编码、RoPE、Encoder/Decoder、KV 表示和自回归建模。
- 模块 2.3:BERT/GPT/ViT、对比学习、自监督学习、掩码建模和表征学习。
- 模块 2.4:VAE/VQ-VAE、GAN、Diffusion、Flow Matching、能量模型和自回归生成。
- 模块 2.5:优化器、学习率、warmup、梯度裁剪、混合精度、稳定性和消融实验。
- 模块 2.6:参数量、计算量、显存、吞吐、上下文长度和数据规模之间的基本关系。
实践任务
- 从头实现小型 Transformer,并在序列任务上验证 mask、位置编码和解码策略。
- 训练一个视觉或文本编码器,比较监督、对比和自监督目标。
- 实现小型 Diffusion 或 Flow Matching 项目,并完成采样速度与质量对比。
可交付成果
- Transformer 实现
- 生成模型实验
- 消融与失败分析
验收标准
- 能解释架构、目标函数和数据如何共同决定模型行为。
- 能阅读并修改主流模型代码,而不是只调用推理 API。
- 每个结论都有基线、消融和失败案例支持。
技术关键词索引
ACT、attention、BaiChuan、bert、bge-m3、ChatGPT、DLRM、gptGR、HTML、LLM-based、MindGPT、MindStudio、MindX、MiniCPM、Model-BasedPPT、PSI、Representation Engineering、SeedVL、TMT、transformer、Transformer Architecture、偏好模型基础模型、大模型、大语言模型、奖励模型、扩散模型、深度学习、生成模型、语言模型
阶段 3:数据工程、语料治理与合成数据
建议节奏:4-7 周。能力模块:7 个。
学习目标
建立从原始数据到可训练、可评测、可追溯数据资产的完整流水线。
必学内容
能力闭环:原理研究与复现、数据构建与治理、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、安全、鲁棒与合规。
- 模块 3.1:采集、解析、清洗、去重、过滤、脱敏、标注、质量评分、版本和血缘。
- 模块 3.2:Web-scale 数据处理、MinHash/LSH、近重复、污染检测、版权与隐私约束。
- 模块 3.3:Tokenizer:BPE、Byte-level、SentencePiece、Tiktoken、词表训练与压缩率。
- 模块 3.4:数据配比、Data Mixture、Curriculum、难例挖掘、主动学习和数据价值评估。
- 模块 3.5:指令、偏好、过程、轨迹、多模态和领域数据的 schema 与质量标准。
- 模块 3.6:Synthetic Data、Self-Instruct、拒绝采样、蒸馏数据、Self-Play 和数据飞轮。
- 模块 3.7:Spark/Flink/Hadoop/Ray、对象存储、流批处理、并行预处理和增量更新。
实践任务
- 构建百万级样本清洗去重管线,输出每一步保留率、质量变化和成本。
- 训练并比较两个 Tokenizer,分析领域词、长文本和多语言的编码效率。
- 生成一批指令或偏好数据,建立自动过滤与人工抽检协议。
- 做数据配比消融,把性能变化归因到来源、质量、难度和污染。
可交付成果
- 版本化数据集
- 数据质量报告
- 合成数据与配比实验
验收标准
- 任一模型结果可追溯到数据版本、规则和样本分布。
- 能量化去重、过滤、配比和合成策略的收益与副作用。
- 训练集、验证集、评测集之间不存在不可解释的污染。
技术关键词索引
/ Synthetic Environments、AB、Adaptive Curriculum Learning、AUC、CC、CDK、ClickHouse、ColossalAlCross-functional Collaboration(产品 / 设计 / 数据 / 人文训练师团队)、Data Curriculum、Data Filtering、Data Filtering / Quality Filtering / Deduplication、Data Mixture Optimization、Data Mixture Optimization / Data Curriculum、Data-Centric、DeduplicationDFL、DFT、DSP、EasyR1、ETA、Graph-LLM、HDFS、High-Quality Data CurationIMAGE、IO、IoT、IoU、KS、LaMMA-Factory、LGB、LRLTV、mAP、MapReduce、MaxCompute、MongoDB、MQTT、MVS、NebulaGraphNeo4j、NLU、NoSQL、PB、PE、Pipeline、Quality Filtering、query-docretrieval、RTOS、S3、SfM、Synthetic Data Generation、Table+、TB、UMIuser-item、Web-scale Data Filtering、Web-scale Data Filtering / Quality Filtering / Deduplication、Web-scale Data Processing Pipeline、XGB、偏好数据、合成数据、向量数据库数据分析、数据去重、数据合成、数据标注、数据治理、数据清洗、数据管线、数据质量数据配比
阶段 4:预训练、模型架构、MoE 与长上下文
建议节奏:6-10 周。能力模块:7 个。
学习目标
理解并实践基础模型从数据配方到稳定训练、扩展和架构迭代的核心方法。
必学内容
能力闭环:原理研究与复现、数据构建与治理、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、安全、鲁棒与合规、原理理解与实际应用。
- 模块 4.1:Next-token prediction、自监督预训练、Continued/Domain-Adaptive Pre-training。
- 模块 4.2:Scaling Laws、Compute-optimal、Chinchilla、数据/参数/算力预算和训练曲线外推。
- 模块 4.3:Dense Transformer、MoE、稀疏激活、路由、专家负载均衡和容量规划。
- 模块 4.4:AdamW/Lion/Muon/Sophia、学习率、warmup、cosine decay、梯度裁剪和稳定性。
- 模块 4.5:长上下文:RoPE、YaRN、NTK-aware、ALiBi、Ring Attention 和上下文扩展。
- 模块 4.6:FlashAttention、Activation/Gradient Checkpointing、BF16/FP8 和训练效率。
- 模块 4.7:数据混合、Tokenizer、checkpoint、loss spike、退化检测和预训练评测。
实践任务
- 预训练一个小型语言模型,完整记录 token、FLOPs、loss、吞吐和验证能力。
- 完成一次领域继续预训练,与直接 SFT 做公平对比。
- 实现或复现小型 MoE,分析路由分布、负载不均和通信成本。
- 扩展上下文窗口,比较位置编码外推、训练成本和长文本真实收益。
可交付成果
- 预训练配方
- Scaling 实验
- MoE/长上下文报告
验收标准
- 能从数据、优化、数值、并行和模型结构定位训练异常。
- 能用预算约束解释模型与数据规模选择。
- 能证明长上下文或 MoE 改动带来真实任务收益,而非只改善单一指标。
技术关键词索引
/ Sparse MoE、AD、AdamW、ADK、ALiBi、Autoregressive Language Modeling、Baichuan-Omni、BERT4RecCFA、Chinchilla-optimal、CLIP-type、Continued Pre-training、Continued Pre-training / Domain-Adaptive Pre-training、Cosine Decay、CosyVoice、CPCPA、Cross-Attention、Cross-lingual、DCN、DeepSpeed-MoE、DiT、Domain-Adaptive Pre-training、DPDualPipe、E2E、embedding、EP、EPLB、FlashMLA、FRM、GQAGraphRAG、Hessian-free、HSTU、K+、KV、Learning Rate Schedule / Warmup / Cosine Decay、Lion、Long-contextLong-Context Modeling、Long-Context Pre-training、LongCat、Mid-training、MindDiffusion、MindFormers、MindPet、MindSpeed-LLMMixture of Experts、Mixture of Experts(MoE)、MLA、MoE、MoE Pre-training、MoE Routing、MTP、Multi-taskMuon、MuP、Next-Token Prediction / Autoregressive Language Modeling、NTK-aware Scaling、NTP、Omni-model、Optimizer、Optimizer(AdamW / Lion / Muon / Sophia)PaddleOCR、PAI、PP、Pre-training、Pre-training / Self-Supervised Pre-training、ReAct、ResidualNet、Ring AttentionRoPE、RoPE / YaRN / NTK-aware Scaling / ALiBi、scale-up、Scaling Laws、Scaling Laws / Compute-Optimal Training / Chinchilla-optimal、self-attention、self-improve、Self-Supervised Pre-trainingSophia、SP、Sparse Activation、Sparse Activation / MoE Routing、STEM、Tokenizer、TP、Transformer Architecture / Mixture of Experts(MoE) / Sparse MoEU2++、V-LLM、VAE、VALLE、VITS、VQ、Warmup、Wav2VecWLLM、XML、YaRN、自监督预训练、长上下文、预训练
阶段 5:后训练、PEFT、强化学习与模型对齐
建议节奏:7-12 周。能力模块:7 个。
学习目标
掌握从 SFT、偏好优化、奖励模型到可验证强化学习和持续对齐的完整链路。
必学内容
能力闭环:原理研究与复现、数据构建与治理、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、安全、鲁棒与合规、原理理解与实际应用。
- 模块 5.1:SFT、Instruction Tuning、Cold Start、数据配方、模板、packing 和灾难性遗忘。
- 模块 5.2:LoRA/QLoRA/DoRA/AdaLoRA、Adapter、Prompt/Prefix/P-Tuning 与全参微调。
- 模块 5.3:Preference Modeling、Reward Model、PRM/ORM、Process/Outcome Supervision。
- 模块 5.4:RLHF、RLAIF、RLVR、PPO、GRPO、DAPO、RLOO、DPO、SimPO、KTO、ORPO。
- 模块 5.5:Verifiable Reward、Advantage、credit assignment、reward hacking 和训练稳定性。
- 模块 5.6:Scalable Oversight、Constitutional AI、Weak-to-Strong、Debate、IDA 与递归改进。
- 模块 5.7:持续后训练、在线反馈、Self-Play、Self-Improvement、模型退化和安全边界。
实践任务
- 完成 SFT 与 LoRA/QLoRA 对比,记录精度、显存、吞吐和遗忘。
- 构建偏好数据,训练奖励模型并完成 DPO/GRPO 中至少一种方法。
- 为数学、代码或工具任务设计可验证奖励,分析作弊和奖励投机。
- 比较过程监督和结果监督,做 KL、长度、格式和泛化消融。
可交付成果
- 后训练流水线
- 偏好与奖励数据
- 对齐/RL 实验报告
验收标准
- 能说明不同后训练方法的目标、数据需求、偏差和适用边界。
- 能诊断 reward collapse、长度偏好、KL 漂移、模式坍塌和验证集过拟合。
- 模型提升同时经过能力、安全、风格、事实性和回归评测。
技术关键词索引
/ OpenRLHF、/ Outcome Reward Model、/ Preference Modeling、AdaLoRA、Adapter Tuning、Adapter Tuning / Prompt Tuning / Prompt Tuning v2、AgenticSearch、alignmentAutoML、Best-of-N、CodeAgent、Context Window Extension / Long-Context Fine-tuning、Continuous Post-Training、CoT、DAPO、Debate-style OversightDecoderOnly、DeepResearch、DeepSpeed-Chat、DJI、DocVQA、DPO、DPO / SimPO / KTO / ORPO / RLOO / RiskPO、Dr. GRPODynamic Preference Modeling、End-to-End Post-Training、fine-tuning、FT、Full-parameter Fine-tuning vs PEFT 混合策略、GPT-4V、GRPO、GRPO / DAPO / Dr. GRPOGSPO、ICL、IM、IPO、ISP、Iterative Post-Training、Iterative Post-Training / Continuous Post-Training、JD-LLMKL、KTO、KV-Cache、Large-scale Preference Data Pipeline、Latent Space Alignment、Latent Space Alignment / Representation Engineering(RepE)、LLaMA-2、LLaMA-FactoryLong-Context Fine-tuning、Long-Term、Long-thought、LoRA、LoRA / QLoRA / DoRA / AdaLoRA / Prefix Tuning / P-Tuning、Meta-learning、Model、MoE Fine-tuningMoE Post-training、MoE Pre-training / MoE Post-training / MoE Fine-tuning、MS-Swift、NL2SQL、On-policy、OneTrans、OPD、OpenRLHFORPO、Parameter-Efficient Fine-Tuning、PEFT、PEFT(Parameter-Efficient Fine-Tuning)、Post-Training、Post-Training Pipeline、Post-Training Pipeline / End-to-End Post-Training、PostTrainingPPL、Preference Collection Pipeline、Preference Data Construction、Preference Data Construction / Synthetic Preference Data、Pretraining、Process Reward Model、Process Reward Model(PRM) / Outcome Reward Model(ORM)、QLoRAQwen2.5-Coder、RankMixer、Reasoning、Recursive Reward Modeling、Recursive Reward Modeling(RRM)、Recursive Self-Improvement、Recursive Self-Improvement(RSI)、Reinforcement Learning Post-TrainingReinforcement Learning with Verifiable Rewards、reward model、Reward Modeling、Reward Modeling(RM) / Preference Modeling、RL、RL Stage / Reinforcement Learning Post-Training、RLAIF、RLHFRLHF / RLAIF / RLVF、RLOO、RLVR、RLVR(Reinforcement Learning with Verifiable Rewards)、ROLL、rollout、SAM、Scalable OversightSelf-Alignment、Self-Improvement loops、Self-Play、SFT、SFT / Supervised Fine-Tuning / Instruction Tuning / Cold Start、SimPO、SL、STRSupervised Fine-Tuning、Synthetic Data Generation / Synthetic Preference Data Pipeline、Synthetic Preference Data、Synthetic Preference Data Pipeline、Tiktoken、Tokenizer(BPE / Byte-level / SentencePiece / Tiktoken)、ToSQL、TrainingUGC、Value Alignment、VeOmni、Verifiable Reward、Verifiable Reward / Verifiable Feedback、verifier-driven、verl(ByteDance RL Framework) / OpenRLHF / TRL / Axolotl、Vision-LanguageWeak-to-Strong Generalization、Weak-to-Strong Generalization / Weak-to-Strong Preference Optimization、Weak-to-Strong Preference Optimization、价值对齐、后训练、对齐、微调、指令微调模型对齐
阶段 6:RAG、Agent、工具调用、记忆与长程规划
建议节奏:6-10 周。能力模块:7 个。
学习目标
构建能检索、规划、调用工具、维护状态并在长任务中稳定恢复的智能体系统。
必学内容
能力闭环:原理研究与复现、数据构建与治理、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、安全、鲁棒与合规、原理理解与实际应用。
- 模块 6.1:RAG:切分、Embedding、召回、混合检索、重排、引用、权限和知识更新。
- 模块 6.2:Function Calling、Tool Use、MCP/API、代码执行、浏览器/数据库工具和沙箱。
- 模块 6.3:ReAct、Plan-and-Execute、反思、搜索、任务分解、状态机和工作流编排。
- 模块 6.4:短期/长期/情景/语义记忆、跨会话记忆、检索、压缩、衰减和隐私。
- 模块 6.5:Multi-Agent、角色协作、通信协议、冲突、共享状态和可观测性。
- 模块 6.6:Agentic RL、长程 rollout、异步环境、轨迹优化、Agent World Model。
- 模块 6.7:Harness Engineering、失败恢复、幂等、成本、延迟、安全和长期 Benchmark。
实践任务
- 实现带引用的混合检索 RAG,评估召回、重排、答案事实性和权限泄漏。
- 构建能调用代码、搜索和数据库的 Agent,加入超时、重试和执行审计。
- 设计跨会话记忆实验,比较摘要、向量检索、结构化记忆和遗忘策略。
- 完成一个 20 步以上任务 Benchmark,统计成功率、错误传播、成本和恢复率。
可交付成果
- RAG 系统
- 长程 Agent
- 轨迹与失败分类报告
验收标准
- 检索、推理、工具、记忆和环境错误可以被独立定位。
- Agent 输出可追踪到证据、工具调用和状态变化。
- 长任务提升基于可重复 Benchmark,而非演示案例。
技术关键词索引
Agent、Agent World Model、Agent World Model(AWM) / Synthetic Environments、Agent-RL、Agent-to-Agent、AgentBench、Agentic RL、Agentic RL / Tool-augmented RL / Long-horizon RLAgentic-RL、AgenticLLM、AgentOS、Agents、AgentScope、AI-Agent、AIagents、AIGuardAPP、arXiv、AutoGen、AutoGPT、B2B、Chain-of-Thought、chatBI、Coevolving World ModelConnector、Continual Learning、CrewAI、CRM、crop_video、Cross-session Memory、Cross-session Memory / Behavioral State Decay Mitigation、DataEngineerDE、DeepReaserch、Dynamic Preference Modeling / Personalization、Episodic-Semantic Memory、Fact-Checking、FRIDAY、FunctionCalls、GB10GUI、Hierarchical Agentic RL、Hierarchical Agentic RL / Multi-Agent RL、Hierarchical Long-Term Memory、Hierarchical Long-Term Memory / Episodic-Semantic Memory、IDE、LangChain、LangGraphLifelong Learning、Lifelong Learning / Continual Learning、LlamaIndex、LLM-as-a-Judge、long-horizon、Long-horizon Planning、Long-horizon Planning / Strategic Tool Utilization、Long-horizon RLLong-term Memory Modeling、MaaS、MCP、Memory、Multi-Agent、Multi-Agent RL、MultiAgent、o3OpenClaw、OS、Persistent Memory、Persistent Memory / Long-term Memory Modeling、Personalization、planning、Pre-trained、Proactive Memory AgentPydanticAI、QA、R1、Scalable Agentic Rollouts、Self-Evolution、Self-Evolving Agents、Self-Instruct、Self-Play / Self-Improvement loops / Self-Evolving AgentsSKILL、Stateful Agents、Stateful Agents / Proactive Memory Agent、Strategic Tool Utilization、Tool-augmented RL、Tool-use、ToT、UGC+workflow、XZ0000602、zoom-in、多智能体、工具调用、智能体、长期记忆
阶段 7:多模态、视觉语言、语音、视频与具身模型
建议节奏:7-12 周。能力模块:7 个。
学习目标
掌握图像、视频、语音、文本和动作的表示、对齐、生成及统一建模。
必学内容
能力闭环:原理研究与复现、数据构建与治理、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、安全、鲁棒与合规、原理理解与实际应用。
- 模块 7.1:视觉编码器、CLIP、ViT、投影层、Cross-Attention、Q-Former 和多模态 Token。
- 模块 7.2:图文/视频理解、OCR、检测、分割、Grounding、时空建模和开放词汇感知。
- 模块 7.3:ASR、TTS、音频编码、语音对话、说话人和音视频同步。
- 模块 7.4:VLM 指令微调、多模态预训练、数据混合、对齐、幻觉和细粒度评测。
- 模块 7.5:文生图/视频、Diffusion/Flow、可控生成、编辑、一致性和生成评测。
- 模块 7.6:VLA、World Model、行为预测、动作生成、机器人学习和自动驾驶多模态。
- 模块 7.7:多模态部署的输入管线、显存、延迟、帧率、分辨率和端侧约束。
实践任务
- 微调一个开源 VLM,建立视觉遗漏、文本误解、时序错误和幻觉分类。
- 完成图像/视频/语音至少两种模态的联合任务与单模态基线对比。
- 实现小型可控生成或编辑项目,评估质量、一致性、可控性和安全。
- 选择 VLA、自动驾驶或具身方向,完成数据到闭环评测的最小项目。
可交付成果
- 多模态微调项目
- 生成模型项目
- 模态错误分析
验收标准
- 能解释不同模态的编码、对齐、融合和解码选择。
- 评测覆盖感知、理解、推理、生成、时序和安全。
- 能把多模态失败归因到数据、编码器、对齐、语言模型或解码器。
技术关键词索引
A2A、ActionInsight、AdaRound、Agent+、AI4SE、AIGC、AIOps、APIasr、BEV、BLIP、CapCut、Claude3.5Sonnet、CLE、CLIP、CNCCo-pilot、CoTraining、CPT、DALL-E、DataLoader、DAU、DETR、DiffusionModelsDINO、DM、dots.mocr、dots.mocr-svg、dots.ocr、DVR、Few-shot、FlexRoundFLUX、FM、FP、GAN、GenAI、GenFlare、GenX、GNSSGOD、GPT-4o、GPT4V、Grounding、HDR、HyperOS、i2i、ICID、Image2Code、IMU、INT、JSON、k+star、LBS、LiDARLLaVA、LLM+Recsys、llm4rec、LLMOps、LLMs、LMM、MindSpeed、MindSpeed-MMML、MLLM、MLOps、MMBench、MR、Multimodal Pre-training、NCNN、OmniGuardOneRec、OneSearch、OpenCompass、OpenVLA、OPPO、Outcome Supervision、PDF、PGCPOC、POI、Post-Train、Pre-train、PrefixQuant、Process Supervision、Process Supervision / Outcome Supervision、PSIGQwen-Audio、Qwen-Coder、Qwen-Image、Qwen-Omni、Qwen-VL、QwenVL、RFT、RKNNROI、ROL、RPM、RQ-VAE、RTK、RTL、ScalingUp、SenseNovaSOP、SOTA、SpeechLLM、SpinQuant、SVA、TA、tts、UIUID、Video-LLaMA、VL、vla、vlm、VLMs、VP、VQ-VAEVQA、WAN、Wav2Vec2、WLM、world model、XR、YOLO、YOLOXZ-Image、ZeRO、多模态、生成式AI、视觉语言、视频剪辑
阶段 8:评测、Benchmark、实验工程与因果分析
建议节奏:4-7 周并持续进行。能力模块:7 个。
学习目标
建立可信、可复现、能驱动迭代的离线与在线评测体系。
必学内容
能力闭环:原理研究与复现、数据构建与治理、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、安全、鲁棒与合规、原理理解与实际应用。
- 模块 8.1:能力矩阵、Benchmark 设计、数据污染、难度分层、切片和黄金集。
- 模块 8.2:准确率、F1、NDCG、BLEU/ROUGE、困惑度、校准、鲁棒性和任务成功率。
- 模块 8.3:LLM-as-Judge、pairwise/rubric、位置偏差、自洽、校准和人工复核。
- 模块 8.4:Human Evaluation、偏好采集、一致性、标注规范和质量控制。
- 模块 8.5:A/B Testing、在线指标、护栏指标、方差缩减、序贯检验和 uplift。
- 模块 8.6:实验管理、消融、回归、显著性、错误分类、bad case 和根因分析。
- 模块 8.7:Agent/长程/多模态/安全评测以及性能、成本、延迟的联合评价。
实践任务
- 为已有项目建立分层评测集、自动评测、人工复核和回归门禁。
- 比较至少两种 Judge 策略,并用人工标签分析偏差和置信度。
- 设计一次 A/B 或离线反事实实验,给出效应量、区间和上线决策。
- 建立 bad case 数据库,把错误归因和修复动作接入下一轮训练。
可交付成果
- 评测框架
- Benchmark 数据卡
- 实验与回归报告
验收标准
- 指标与真实目标一致,切片结果和不确定性透明。
- 结论能够经重复实验、统计检验和人工审计。
- 每次模型迭代都有能力、安全、性能和成本回归。
技术关键词索引
a/b、A/B Testing、A/B Testing / Online Experimentation / Uplift Modeling、AED、Agentic Benchmark、Agentic Benchmark / Long-horizon Benchmark、ATH、Automated Evaluation FrameworkAutomated Judging Pipeline、BadCase、benchmark、ChatSVA、CNN、DMC、ECU、ELOFramework、GAIA、GenBen、GSB、Human Evaluation、Human Evaluation / Preference Collection Pipeline、learning-based、LLM-as-JudgeLLM-as-Judge / Automated Judging Pipeline、Long-Context Evaluation、Long-horizon Benchmark、MMLU、MOS、Online Experimentation、Online Experimentation & Iteration、PRDProcess vs Outcome Evaluation、QPS、RNN、RT、RTL-LLM、RTLCoder、Seed3D、Self-CorrectionSigLIP、TPOT、TTFT、Uplift Modeling、VeriCoder、Verifiable Rewards Evaluation、VerilogEval、VeriRL消融实验、评测
阶段 9:AI 安全、红队、鲁棒性、事实性与隐私
建议节奏:4-8 周并持续进行。能力模块:7 个。
学习目标
把安全从上线前检查变成数据、训练、评测和服务全链路能力。
必学内容
能力闭环:原理研究与复现、数据构建与治理、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、安全、鲁棒与合规。
- 模块 9.1:Safety/Value Alignment、政策约束、拒答边界、Constitutional AI 和安全数据。
- 模块 9.2:Jailbreak、Prompt Injection、越权工具调用、数据外泄和间接注入。
- 模块 9.3:自动红队、攻击生成、对抗样本、风险分类、严重度和修复验证。
- 模块 9.4:幻觉、事实性、引用、校准、不确定性、知识时效和 grounded generation。
- 模块 9.5:Reward Hacking、欺骗、后门、模型窃取、投毒、成员推断和隐私。
- 模块 9.6:Representation Engineering、Circuit Breaker、鲁棒训练和监控告警。
- 模块 9.7:内容、金融、风控、医疗、驾驶和 Agent 执行中的领域安全约束。
实践任务
- 为 RAG/Agent 系统建立威胁模型,覆盖注入、越权、泄漏和危险执行。
- 构建自动红队集,记录攻击成功率、误拒率、修复率和能力损失。
- 实现事实性与引用评测,比较检索、训练和解码层修复。
- 为工具调用加入最小权限、确认、沙箱、审计和回滚。
可交付成果
- 威胁模型
- 红队与安全评测集
- 修复及回归报告
验收标准
- 风险有明确资产、攻击面、严重度、检测和缓解措施。
- 安全提升不会用不可解释的能力损失换取。
- 上线系统具备持续监控、事件复盘和快速回滚。
技术关键词索引
AI Safety via Debate、AI Safety via Debate / Debate-style Oversight、Automated Red Teaming、Automated Red Teaming / Red-teaming Automation、CBG、Circuit Breakers、Circuit Breakers / Representation Engineering for Safety、Constitutional AIConstitutional AI / Self-Critique / Self-Alignment、Constitutional Constraints、Deceptive Behavior Mitigation、Factuality Alignment、Hallucination Mitigation、Hallucination Mitigation / Factuality Alignment、Jailbreak Defense、Jailbreak Defense / Adversarial RobustnessRepresentation Engineering for Safety、Reward Hacking Prevention、Reward Hacking Prevention / Deceptive Behavior Mitigation、Safety Alignment、Safety Alignment / Value Alignment、事实性、安全对齐、对抗鲁棒性幻觉、红队、越狱、越狱防御、鲁棒性
阶段 10:分布式训练、训练平台与 AI Infra
建议节奏:5-9 周。能力模块:7 个。
学习目标
能把模型稳定扩展到多卡、多机和大规模训练平台,并定位性能与可靠性瓶颈。
必学内容
能力闭环:原理研究与复现、数据构建与治理、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、原理理解与实际应用。
- 模块 10.1:DDP、ZeRO、FSDP、Tensor/Pipeline/Sequence/Expert Parallel 和 3D 并行。
- 模块 10.2:DeepSpeed、Megatron-LM、Colossal-AI、verl、OpenRLHF、TRL 和 Ray。
- 模块 10.3:NCCL、拓扑、通信、重叠、sharding、checkpoint、恢复和容错。
- 模块 10.4:BF16/FP16/FP8、Gradient/Activation Checkpointing、FlashAttention 和内存估算。
- 模块 10.5:数据加载、样本 packing、动态 batch、吞吐、MFU、straggler 和长尾任务。
- 模块 10.6:Kubernetes、队列、资源调度、弹性、优先级、可观测性和成本治理。
- 模块 10.7:异步 rollout、环境隔离、偏好数据管线和后训练基础设施。
实践任务
- 把单卡训练迁移到 DDP/FSDP/DeepSpeed,逐层记录吞吐、显存和通信。
- 完成一次故障注入:进程、节点、存储或网络失败后自动恢复。
- 实现训练任务调度与监控面板,统计 GPU 利用率、排队和失败原因。
- 搭建小型异步 rollout 或偏好训练链路,分析生产者消费者瓶颈。
可交付成果
- 多卡训练方案
- Profiling 报告
- 容错与调度实验
验收标准
- 能估算不同模型、序列和并行策略的显存与通信。
- 能定位计算、通信、I/O、数据、调度和 straggler 瓶颈。
- 训练可恢复、可观测、可复现,并有明确成本指标。
技术关键词索引
3D Parallelism、3D Parallelism / Activation Checkpointing、3D Parallelism / Pipeline Parallelism / Tensor Parallelism、A100、Activation Checkpointing、Activation Checkpointing / Gradient Checkpointing、ADAS、AI-infraAsynchronous Rollout Infrastructure、B+、BF16、Checkpoint、Colossal-AI、ColossalAI、CPUGPU、DDPdeepspeed、DeepSpeed ZeRO、DeepSpeed ZeRO / FSDP / Megatron-DeepSpeed、FlashAttention、FlashAttention / Ring Attention / FlashAttention-2/3、FlashAttention for Long Context、FlashAttention-2/3、FP8FSDP、GLM、GPU、GPU+CPU、Gradient Checkpointing、HPC、HugeCTR、KernelKubernetes for Distributed Training、megatron、Megatron-DeepSpeed、Megatron-LM、Mixed Precision Training(BF16 / FP8)、MPI、oneDNN、PCPipeline Parallelism、Ray、Ray / Kubernetes for Distributed Training、Ring Attention / FlashAttention for Long Context、SGLang、Tensor Parallelism、TileLang、UCXXZ0000582、ZeRO-1、Zero-Shot、分布式系统、分布式训练、异构集群、张量并行、数据并行模型并行、流水线并行
阶段 11:推理、Serving、压缩与性能优化
建议节奏:5-8 周。能力模块:7 个。
学习目标
在精度、延迟、吞吐、显存、成本和可靠性之间做可量化取舍。
必学内容
能力闭环:原理研究与复现、数据构建与治理、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、原理理解与实际应用。
- 模块 11.1:Prefill/Decode、KV Cache、PagedAttention、Continuous Batching 和调度。
- 模块 11.2:vLLM、TensorRT-LLM、TGI、Triton、ONNX Runtime、llama.cpp 和服务框架。
- 模块 11.3:INT4/INT8/FP8、GPTQ/AWQ、量化感知、蒸馏、剪枝和稀疏化。
- 模块 11.4:Speculative Decoding、并行解码、Prefix Cache、长上下文和多 LoRA Serving。
- 模块 11.5:CUDA/Triton Kernel、算子融合、内存带宽、CPU/GPU 协同和硬件感知优化。
- 模块 11.6:在线批处理、限流、熔断、降级、灰度、弹性、SLA 和多租户。
- 模块 11.7:质量回归、监控、漂移、成本、容量规划和端侧部署。
实践任务
- 用 vLLM/TensorRT-LLM 部署模型,测量 TTFT、TPOT、吞吐、显存和成本。
- 完成两种量化或蒸馏方案,比较分任务精度和硬件收益。
- 为长上下文、多并发和突发流量设计容量与降级策略。
- 优化一个 CUDA/Triton 或数据预处理热点,给出 profiler 证据。
可交付成果
- 推理服务
- 性能基准
- 压缩与容量规划报告
验收标准
- 性能结论覆盖不同 batch、序列、并发和硬件。
- 压缩后的能力、安全和长尾任务经过回归。
- 系统达到明确 SLA,并能解释瓶颈与扩容策略。
技术关键词索引
AMP、AutoResearch、AWQ、AWS、Continuous Batching、CPU、Distillation、FP16GCP、GMV、GPTQ、Hardware-aware Optimization、Inference Optimization、Inference Optimization / Serving Infrastructure、Iterated Distillation and Amplification、Iterated Distillation and Amplification(IDA)KV Cache Optimization、KV Cache Optimization / PagedAttention / Continuous Batching、LVM、MNN、Model Compression、PagedAttention、Privacy-Preserving、PTQQAT、QNX、Quantization、Quantization(INT4 / INT8 / FP8 / GPTQ / AWQ)、RTC、Serving、Serving Infrastructure、SLASpeculative Decoding、Speculative Decoding / Model Compression / Distillation、tensorrt、TensorRT-LLM、test-time、TGI、ToB、TPUTriton Inference Server、TVM、vLLM、vLLM / TensorRT-LLM / TGI / Triton Inference Server、WebSocket、X-Learner、剪枝、推理优化推理加速、推理引擎、模型压缩、模型蒸馏、模型量化、蒸馏、量化
阶段 12:垂直算法分支与业务建模
建议节奏:任选 1-2 个方向,各 6-10 周。能力模块:8 个。
学习目标
把通用模型能力转化为领域问题定义、数据、指标、约束和线上收益。
必学内容
能力闭环:原理研究与复现、数据构建与治理、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、安全、鲁棒与合规、原理理解与实际应用。
- 模块 12.1:NLP:分类、抽取、检索、问答、翻译、文本生成、知识图谱和多语言。
- 模块 12.2:CV/AIGC:检测、分割、OCR、三维、图像/视频理解、生成、编辑和质量评价。
- 模块 12.3:语音:ASR、TTS、声学/语言模型、端到端、多语种、对话和实时流式。
- 模块 12.4:搜索/推荐/广告:召回、排序、重排、CTR/CVR、序列建模、生成式推荐和因果。
- 模块 12.5:图学习、时序预测、异常检测、风控反欺诈、金融建模和数据挖掘。
- 模块 12.6:运筹优化:规划、调度、组合优化、启发式、整数规划和学习增强优化。
- 模块 12.7:自动驾驶/机器人:感知、预测、规划、控制、VLA、世界模型和闭环安全。
- 模块 12.8:业务抽象、目标函数、代理指标、约束、冷启动、反馈回路和 Research-to-Production。
实践任务
- 选择一个方向建立传统算法、深度模型和基础模型三层基线。
- 从业务目标推导训练目标和评测指标,分析代理指标与真实价值偏差。
- 打通离线数据、训练、评测、在线服务、监控和反馈闭环。
- 做跨域、冷启动、长尾、分布漂移和成本约束实验。
可交付成果
- 领域端到端项目
- 业务指标树
- 线上化与迭代方案
验收标准
- 能把模糊需求转成可验证的算法问题和约束。
- 结果同时优于简单基线,并解释线上线下差异。
- 方案包含数据、算法、系统、评测、安全和成本。
技术关键词索引
AF、AIMET、APA、AR、AUDIO、AVP、catboost、CTRcv、cvpr、CVPR2023、CVR、DGS、e.g、eccv、ECCV2022emnlp、ETL、G2O、GPT4、GroundingDINO、GTSAM、HPA、ICBUiccv、ICLR2020、ICSE、isaac、LI-SLAM、lightgbm、LTR、MPCmujoco、NeRF、nlp、o1、OMPL、OpenAI、OWL-ViT、PaLMpeer-reviewed、Perception-to-Control、re-caption、ros、ROS2、S-curve、SDK、SEslam、UniAD、VI-SLAM、VIO、VL-BERT、xgboost、反欺诈、召回广告算法、异常检测、排序算法、推荐系统、搜索算法、知识图谱、粗排、精排自动驾驶、自然语言处理、计算机视觉、语音合成、语音识别、资源调度、轨迹规划、运动规划运筹优化、重排、风控
阶段 13:论文复现、研究方法、产品落地与作品集
建议节奏:贯穿全程,集中整理 4-6 周。能力模块:7 个。
学习目标
把学习转化为第三方可验证的研究、工程和业务能力证据。
必学内容
能力闭环:原理研究与复现、数据构建与治理、算法建模与实现、训练调优与稳定性、评测、消融与误差分析、工程系统与工具链、部署、性能与运维、场景适配与产品闭环、安全、鲁棒与合规、原理理解与实际应用。
- 模块 13.1:论文检索、问题定义、假设、相关工作、复现、基线、公平比较和消融。
- 模块 13.2:ICLR、NeurIPS、ICML、ACL、EMNLP、CVPR、KDD、SIGIR 等方向性阅读。
- 模块 13.3:实验设计、统计、负结果、错误分析、可复现性、代码质量和数据卡。
- 模块 13.4:开源协作、Issue/PR、代码评审、许可证、模型卡、技术报告和演示。
- 模块 13.5:系统设计、技术路线、跨团队接口、里程碑、风险、成本和迭代优先级。
- 模块 13.6:Research-to-Production、用户反馈、在线实验、产品研究协同和技术影响力。
- 模块 13.7:面试表达:问题、选择、实现、指标、失败、修复、贡献和边界。
实践任务
- 完整复现一篇论文,补齐未报告细节并做至少三个消融。
- 向真实开源项目提交可合并贡献,留下设计、测试和评审记录。
- 把前面项目整合成一个旗舰项目,提供训练、评测、部署和演示。
- 为每个项目写一页技术决策记录和一份失败复盘。
可交付成果
- 论文复现仓库
- 开源贡献
- 旗舰项目
- 技术报告与作品集
验收标准
- 第三方能按文档复现核心结果并理解你的贡献。
- 能解释为什么选择某技术、替代方案是什么、失败在哪里。
- 作品集同时证明研究深度、工程质量和实际效果。
技术关键词索引
aaai、acl、ACLNeUrIPS、ACM、ACM-ICPC、ACMICPC、across tasks/domains、Advantage NormalizationAdvantage Normalization(across tasks/domains)、Adversarial Robustness、AGI、AI、ASE、ASI、ASi8、ASPLOSASRU、Asynchronous RL Training、Asynchronous RL Training / Isolated Environment Execution、AWM、Axolotl、Behavioral State Decay Mitigation、BPE、BUByte-level、ByteDance RL Framework、CCF、CCF-A、CCS、ChatGLM、CIKM、Cold Startcoling、Compute-Optimal Training、Context Window Extension、CORL、Cross-functional Collaboration、CT、DeepSeek、DLDoRA、DROID-SLAM、EDA、elasticsearch、Execution-Grounded Credit Assignment、Expert Specialization、Expert Specialization / Load Balancing、faissFast-LIVO、flink、FSE、Group Relative Advantage Estimation、grpc、GS-Cacl、H5、hadoopHIL、Human-AI Hybrid Feedback、Human-AI Hybrid Feedback / Real-user Feedback Loop、ICASSP、ICDE、iclr、icml、ICRAIDA、ijcai、IJCV、IJRR、iLAM、Instruction Tuning、INT4、INT8interspeech、IOI、iOS、IR、IROS、Isolated Environment Execution、JD、kddKDDCup、Learning Rate Schedule、llm、Load Balancing、LQR、LSH、MFU、MICCAImilvus、Mixed Precision Training、MLSys、MM、MRI、Multi-turn Trajectory Optimization、naacl、ncclneurips、NeurLPS、NeurPS、Next-Token、Next-Token Prediction、NFV、NIPS、NOINPC、NV、OCC、ocr、On-device、onnx、onnxruntime、OODopencl、openvino、ORB-SLAM、ORM、P-Tuning、PDAF、PID、PMPMO、ppo、Prefix Tuning、PRM、Product-Research co-design、Prompt Tuning、Prompt Tuning v2、ragRAL、Real-user Feedback Loop、RECSYS、Red-teaming Automation、redis、RepE、Research-to-Production Pipeline、RiskPORL Stage、RLVF、RM、RoboBrain、RRM、RSI、SAC、SAFeSDN、Self-Critique、SentencePiece、SIGGRAPH、sigir、SIGKDD、SIL、Slam-Formerspark、SplatFusion、TASLP、TIP、TMM、Token-level MDP、Token-level MDP / Execution-Grounded Credit Assignment、TOPTorchTitan、TPAMI、TPM、TRL、TRO、USENIX、Verifiable Feedback、verlvibe coding、VINS、WSDM、www、上下文窗口、专利、专家混合、业务建模个性化、人文训练师团队、函数调用、可解释性、可验证奖励、后期制作、基准测试、工作流开源项目、强化学习、技术方案、持续学习、操作系统、检索增强、混合精度、混音用户行为、稀疏化、稀疏激活、算法竞赛、算法落地、终身学习、编译原理、论文负载均衡、长文本、长时序、音频处理、顶会、顶刊、高性能计算
embodied ai vla learning guide
type: 路线图 status: 已发布 level: 通用 topic:
- 面试求职
- 具身智能
- 多模态
具身智能与 VLA 完整学习指南
基于已筛选的真实岗位职责、硬要求与加分项整理。生成时间:2026-07-10T12:43:12+08:00。
一、如何使用这份指南
这不是术语目录,而是一条以岗位能力为终点的实践路线。每个阶段都包含五件事:
- 学习目标:完成后应该具备的能力。
- 必学内容:岗位职责和要求中反复出现的知识。
- 实践任务:必须亲手完成的训练、评测或部署工作。
- 可交付成果:可以放进代码仓库或作品集的产物。
- 验收标准:判断自己是否真正掌握,而不是只看过资料。
建议始终维护一个实验仓库,至少包含:环境配置、数据说明、训练脚本、评测脚本、实验记录、失败案例和复现步骤。每个阶段都在同一个仓库中累积,而不是做完就丢。
二、VLA 岗位能力全景
VLA 与具身智能岗位可以拆成八层能力栈:
| 层级 | 核心问题 | 最终需要证明的能力 |
|---|---|---|
| 工程基础 | 能否稳定写出和调试训练代码 | Python、PyTorch、Linux、Git、实验管理 |
| 模型基础 | 是否理解模型为何有效或失败 | 深度学习、Transformer、Diffusion、优化方法 |
| 多模态基础 | 如何联合视觉、语言、视频与状态 | VLM、对齐、Token 化、跨模态融合 |
| 动作建模 | 如何从观察和指令生成动作 | Action Head、ACT、Diffusion Policy、自回归策略 |
| 机器人学习 | 如何让策略从数据和交互中学习 | BC、IL、RL、Offline RL、Policy Learning |
| 世界模型与决策 | 如何预测、规划并处理长时序任务 | World Model、Model-Based RL、Planning、MPC |
| 数据与闭环 | 如何持续提升真实任务成功率 | 采集、清洗、配比、评测、bad case、再训练 |
| 系统与落地 | 如何让模型在仿真和真机稳定运行 | ROS2、Sim2Real、推理优化、分布式训练、部署 |
学习时不要把这八层割裂。一个合格项目应至少打通:数据输入 → 模型训练 → 离线评测 → 仿真闭环 → 失败分析;更完整的项目还应包含真机或受控硬件验证。
三、总学习路线
| 阶段 | 建议节奏 | 核心产出 |
|---|---|---|
| 0. 工程环境与实验规范 | 1–2 周 | 可复现的 PyTorch 训练模板 |
| 1. 深度学习与 Transformer | 4–6 周 | 图像/序列模型训练与消融实验 |
| 2. LLM、VLM 与多模态对齐 | 4–6 周 | 多模态微调和评测项目 |
| 3. 机器人基础与仿真 | 4–6 周 | ROS2 + 仿真环境闭环任务 |
| 4. 模仿学习与策略模型 | 4–6 周 | ACT 或 Diffusion Policy 复现 |
| 5. VLA 训练全链路 | 6–8 周 | 数据、训练、评测、部署一体化项目 |
| 6. World Model、RL 与长时序决策 | 4–8 周 | 预测、规划或策略改进实验 |
| 7. Sim2Real、真机和数据闭环 | 持续进行 | 闭环评测与 bad case 再训练 |
| 8. 分布式训练与推理优化 | 3–5 周 | 吞吐、显存、延迟优化报告 |
| 9. 论文复现与作品集 | 持续进行 | 可复现实验、技术报告和演示 |
节奏可以压缩或拉长,但顺序不宜完全颠倒。VLA 的困难通常不在“调用一个现成模型”,而在数据质量、动作表示、评测协议、闭环稳定性和真实系统约束。
四、阶段 0:工程环境与实验规范
学习目标
- 能独立配置 Linux、Python、CUDA 与 PyTorch 环境。
- 能编写可恢复、可记录、可比较的训练程序。
- 能定位数据、梯度、显存、速度和数值稳定性问题。
- 能为训练平台、推理服务和机器人终端设计可靠的数据与接口层。
必学内容
- Python、NumPy、PyTorch、Git、Shell、基础 Docker。
- Dataset/DataLoader、自动微分、优化器、学习率调度、混合精度。
- 配置管理、随机种子、断点恢复、日志、指标和实验版本管理。
- 单元测试、数据检查、梯度检查、profiling 和异常样本定位。
- RESTful API/RPC 的接口契约、版本、超时、重试、幂等、鉴权和可观测性。
- MySQL/PostgreSQL、MongoDB/Redis 的数据模型、索引、缓存与大规模多模态元数据查询。
- Docker/Kubernetes、微服务边界、任务调度、健康检查和故障恢复。
实践任务
- 用 PyTorch 完成一个图像分类或序列预测任务。
- 支持配置文件、混合精度、断点恢复、训练日志和独立评测。
- 主动制造数据为空、标签越界、梯度爆炸和显存不足问题,并记录定位过程。
- 用 FastAPI 实现模型推理 RESTful API,并用 RPC 模拟机器人终端调用;加入超时、重试、幂等键和链路日志。
- 为轨迹元数据、实验记录和任务状态设计关系型表与 Redis/MongoDB 查询层,比较索引和缓存前后的延迟。
可交付成果
- 一个干净的训练模板仓库。
- 一份实验复现说明。
- 一份失败排查手册。
- API 契约、数据库 schema、负载测试和故障注入报告。
验收标准
- 换一台机器后可以按文档完成训练和评测。
- 同一随机种子能得到可解释的结果波动。
- 能说明训练慢、显存高或 loss 异常的具体原因。
- 能证明接口在重复请求、超时和服务重启下不产生重复动作,并能解释数据表、文档库和缓存的选型。
岗位技术扩展:编程、训练框架与开发环境
- 学习定位: 掌握级:能独立编写、调试、测试和复现训练代码。
- 最低实践: 把同一训练任务分别做成单卡、混合精度、断点恢复和容器化版本,并记录速度、显存和复现误差。
- 达标标准: 离开现成 Notebook 后仍能从数据读取开始搭出可维护的训练与评测工程。
- 本阶段需要覆盖的原文技术:
c++、CUDA、Docker、FastAPI、git、Java、JAX、Kubernetes、linuxMongoDB、MySQL、PostgreSQL、python、pytorch、Redis、RESTful API、RPC、TensorFlow代码、工程、微服务、框架、编程
五、阶段 1:深度学习、Transformer 与生成建模
学习目标
- 理解视觉、语言和动作序列的共同建模基础。
- 能读懂并修改 Transformer、Diffusion 和常见视觉编码器代码。
- 能通过消融实验解释模型设计选择。
必学内容
- 线性代数、概率、优化、交叉熵、对比学习和序列建模。
- CNN、ViT、Attention、Transformer、位置编码和归一化。
- 自回归建模、VAE/VQ-VAE、Diffusion、Flow Matching。
- Transfusion、Show-o、Janus-Pro、Cosmos、RynnVLA 等 AR + Generation 统一建模思路。
- 图学习、图信号处理与跨域迁移学习,理解其在拓扑、关系建模和域泛化中的适用边界。
- 训练稳定性、数据分布偏移、过拟合、泛化和指标设计。
实践任务
- 从头实现一个小型 Transformer,并用于序列预测。
- 训练一个视觉编码器或 ViT,比较不同增强和预训练方式。
- 完成一个小型 Diffusion 或 Flow Matching 生成任务。
- 为每个实验设计至少一个消融变量,并解释结果。
- 选择一个统一生成架构,比较自回归 token 与连续生成目标;再用一个小型图任务验证跨域迁移前后的泛化差异。
可交付成果
- Transformer 与生成模型实现。
- 消融实验表格和结论。
- 模型失败案例可视化。
- 统一生成与图迁移实验笔记,明确它们何时值得用于 VLA。
验收标准
- 能解释 Attention、Token、位置编码和 Action Chunk 的关系。
- 能区分自回归动作生成、Diffusion Policy 和 Flow Matching 的主要取舍。
- 面对训练不稳定时,能提出可验证的排查顺序。
- 能说明统一生成架构、图学习或跨域迁移给 VLA 带来的收益假设,并用基线验证而不是只复述模型名称。
岗位技术扩展:深度学习、基础模型与生成建模
- 学习定位: 掌握级:理解核心结构、损失、训练稳定性和主要架构取舍。
- 最低实践: 实现小型 Transformer 与生成模型,完成自回归、Diffusion、Flow Matching 的可控对比。
- 达标标准: 能从数据分布、架构和优化三个层面解释模型效果,不只会调用接口。
- 本阶段需要覆盖的原文技术:
AR + Generation、BERT、Cosmos、diffusion、DINO、DINOv2、DiT、Flow Matching、GeminiGPT、HuggingFace、Janus-Pro、Llama、loss、Mamba、MoE、RWKV、RynnVLASAM、Show-o、Sora、transformer、Transformers、Transfusion、ViT、VQ-GAN、VQ-VAE优化、图信号处理、图学习、数学、机器学习、概率、模型、深度学习、神经网络线性代数、跨域迁移学习
六、阶段 2:LLM、VLM 与多模态对齐
学习目标
- 理解语言、图像、视频和状态信息如何进入统一模型。
- 能完成 VLM 的数据处理、微调、评测和失败分析。
- 能解释 VLM 如何成为 VLA 的视觉语言基座。
必学内容
- LLM/VLM 基础、Tokenizer、视觉编码器、投影层和跨模态对齐。
- CLIP 式对比学习、视觉指令微调、图文/视频语言建模。
- SFT、LoRA/QLoRA、PEFT、数据配比和多模态 batch 构造。
- 幻觉、时空理解、视觉定位、开放词汇识别和评测设计。
实践任务
- 选择一个开源 VLM,完成领域数据的 SFT 或 LoRA 微调。
- 构建包含图像、指令和答案的数据管线。
- 建立自动指标与人工错误类型相结合的评测集。
- 分析视觉遗漏、语言误解、时序错误和错误推理案例。
可交付成果
- 可复现的 VLM 微调脚本。
- 数据格式与质量规则说明。
- 评测报告和 bad case 分类。
验收标准
- 能说明视觉编码器、语言模型和投影模块分别承担什么作用。
- 能解释数据配比变化为什么影响泛化。
- 能把失败案例转化为数据或训练策略改进。
岗位技术扩展:LLM、VLM 与多模态对齐
- 学习定位: 掌握级:能完成多模态数据处理、微调、对齐和评测。
- 最低实践: 微调一个 VLM,建立图像/视频、指令和答案数据管线,并对幻觉、定位和时序错误做分类。
- 达标标准: 能说明视觉编码器、语言基座和投影/融合模块各自的作用与失败模式。
- 本阶段需要覆盖的原文技术:
agent、CLIP、LLaVA、llm、QwenVL、vlm、VLM-Adapter、多模态、多视角大模型、视觉、视觉-语言、视觉语言
七、阶段 3:机器人基础、ROS2 与仿真
学习目标
- 理解 VLA 输出如何真正驱动机器人。
- 能在仿真中完成观察、决策、动作执行和评测闭环。
- 能处理坐标系、标定、控制频率和延迟问题。
- 能完成机器人本体、物理参数和仿真场景资产的建模与校验。
- 能把真实场景重建为可用于仿真、数据合成和策略评测的三维资产。
必学内容
- 机器人运动学、动力学、关节空间、笛卡尔空间和末端执行器。
- 相机内外参、手眼标定、RGB-D、力觉、触觉和状态估计。
- ROS/ROS2 Topic、Service、Action、TF、rosbag 和控制接口。
- 多模态传感器接入:RGB-D/深度相机、IMU、力/力矩、压阻、电容和视触觉;时间同步、空间标定与质量监控。
- SLAM、Topological Map、Global/Local Planner、路径规划、SMACH/BehaviorTree 与导航状态机。
- MuJoCo、Isaac Sim/Gym、Habitat、Gazebo 中至少一个环境。
- 遥操作、轨迹记录、动作归一化、控制频率与安全约束。
- URDF/SDF 的本体描述、关节限制、惯量、碰撞体和传感器配置。
- USD 的 Stage/Prim、Layer、Reference/Payload、变换、材质和资产组合;理解它与 URDF/SDF 的职责差异。
- PhysX 刚体、Articulation、碰撞检测、接触、摩擦、恢复系数和阻尼,以及参数失真如何影响策略。
- Isaac Sim/Isaac Lab 的 Python API、传感器仿真、并行环境、合成数据和 Domain Randomization。
- 多视图几何、相机位姿、深度/点云/网格、NeRF、3DGS 与大规模场景重建流水线。
实践任务
- 在仿真中搭建机械臂抓取或 pick-and-place 任务。
- 用 ROS2 串联传感器输入、策略推理和动作执行。
- 记录 observation、language、state、action 和时间戳。
- 接入至少两种异步传感器,完成硬/软件时间戳对齐、外参标定、丢帧检测和数据质量告警。
- 在 ROS2 中搭建 SLAM/拓扑地图、Global/Local Planner 与 BehaviorTree 状态流,验证重规划和异常恢复。
- 用 URDF/SDF 描述机器人,再转换或重建为 USD 资产,逐项检查坐标、关节、惯量和碰撞体。
- 使用 COLMAP 配合 NeRF 或 3DGS 重建一个真实桌面场景,将点云、网格或渲染资产导入 Isaac Sim,并补齐可碰撞几何。
- 对 PhysX 的摩擦、恢复系数、阻尼、质量和接触参数做受控扫描,记录抓取成功率和轨迹误差变化。
- 故意引入标定误差、延迟、观测噪声和重建误差,观察策略退化。
可交付成果
- 可一键启动的仿真任务。
- ROS2 节点图和数据字段说明。
- 延迟、频率、标定误差实验报告。
- 多传感器时间同步、标定、丢帧与质量监控报告,以及导航/重规划状态图。
- 一套可复用的 URDF/SDF、USD 和场景资产,以及资产校验清单。
- NeRF/3DGS 重建报告,包含相机轨迹、重建质量、碰撞近似和导入仿真的过程。
- PhysX 参数敏感性实验与仿真参数表。
验收标准
- 能解释模型动作如何转换为机器人可执行指令。
- 能定位策略失败属于感知、决策、控制还是系统时序问题。
- 能定义任务成功率、轨迹误差、响应延迟和恢复率。
- 能区分同步、外参、传感器漂移和规划状态机造成的失败,并通过日志复现问题。
- 能解释 URDF/SDF、USD、渲染资产和物理碰撞体各自解决什么问题。
- 能证明重建质量或物理参数变化会怎样影响闭环策略,而不只展示三维渲染效果。
岗位技术扩展:机器人本体、感知与传感器
- 学习定位: 实践级:能把模型输出接入真实或高保真机器人闭环。
- 最低实践: 完成传感器同步、坐标变换、动作接口、控制频率和安全限制的系统联调。
- 达标标准: 能够判断失败来自观测、标定、策略、控制、延迟还是执行机构。
- 本阶段需要覆盖的原文技术:
6DoF、AGV、ALOHA、BehaviorTree、DDS、forward kinematics、Franka、Global/Local Planner、IKIMU、Kuavo、locomotion、Mobile-ALOHA、MoveIt、MoveIt 2、PLC、proprioception、retargetingRGB-D、ROS、ROS2、SDF、SDK、SLAM、SMACH、SMPL-X、subgoal imageteleoperation、Topological Map、URDF、xArm、具身、力矩传感器、力觉、动作、动力学压阻、多模态传感器、导航、感知、手眼标定、抓取、控制、操作、机器人机械臂、灵巧手、点云、电容、规划、视触觉、触觉、触觉传感器、路径规划运动学、遥操作
岗位技术扩展:三维重建、场景建模与仿真资产
- 学习定位: 实践级:能把真实场景变成可校验、可碰撞、可用于策略实验的仿真资产。
- 最低实践: 完成相机标定与 NeRF/3DGS 重建,导入 Isaac Sim 后补齐碰撞几何,并比较重建误差对策略成功率的影响。
- 达标标准: 能分别量化视觉、几何和碰撞误差,并说明何时使用神经渲染、网格资产或人工建模。
- 本阶段需要覆盖的原文技术:
3DGS、3D建模、NeRF、三维重建、场景重建、计算机图形学
八、阶段 4:模仿学习、策略学习与动作生成
学习目标
- 能从示教轨迹训练机器人策略。
- 理解动作表示、Action Chunk、闭环误差和分布偏移。
- 能复现至少一种主流策略模型。
必学内容
- Behavior Cloning、DAgger、Offline RL、Imitation Learning。
- ACT、Diffusion Policy、自回归 Policy、Action Tokenizer。
- observation/action space、动作归一化、控制频率和 horizon。
- 遥操作数据、轨迹切分、数据不平衡和异常动作过滤。
- 离线评测与闭环评测之间的差异。
实践任务
- 在仿真数据上复现 ACT 或 Diffusion Policy。
- 比较单步动作、Action Chunk 和不同 horizon。
- 测试视觉扰动、指令变化和物体位置变化下的泛化。
- 建立失败类型:未识别、抓取偏差、动作振荡、长时序中断、恢复失败。
可交付成果
- 策略训练与评测代码。
- 不同动作表示的对比实验。
- 闭环失败分析和数据改进方案。
验收标准
- 能解释为什么训练 loss 下降但真实成功率不升。
- 能说明 BC、DAgger、Offline RL 与在线 RL 的数据假设。
- 能根据失败类型选择增加数据、修改模型还是调整控制接口。
九、阶段 5:VLA 模型训练全链路
学习目标
- 打通视觉、语言、机器人状态到动作输出的完整链路。
- 能完成数据构建、预训练/微调、评测、推理和系统集成。
- 能理解主流 VLA 路线的架构取舍。
必学内容
- RT-1/RT-2、OpenVLA、Octo、ACT、RDT、PI 系列、GR00T 等代表路线。
- 视觉编码器、语言基座、状态编码、Action Head 和动作解码。
- 离散动作 Token、连续动作、Diffusion/Flow Matching、Autoregressive Policy。
- 预训练、SFT、Post-training、LoRA/QLoRA 和策略微调。
- 多任务、多本体、跨场景泛化与 embodiment 差异。
实践任务
- 选择一个开源 VLA 或策略模型,跑通数据到评测全流程。
- 将自定义任务转换为模型所需 observation/action 格式。
- 比较冻结基座、部分微调和全量微调。
- 设计跨对象、跨背景、跨指令和跨任务测试。
- 记录成功率、动作平滑度、延迟、失败恢复和泛化差异。
可交付成果
- 完整 VLA 训练与评测仓库。
- 模型架构图和数据流图。
- 至少三组关键消融实验。
- 可重复运行的演示和技术报告。
验收标准
- 能讲清视觉、语言、状态和动作在哪些位置融合。
- 能解释 Action Head、动作 Token 和控制频率如何影响结果。
- 能把模型效果变化追溯到数据、架构、训练或部署因素。
岗位技术扩展:VLA、动作表示与策略模型
- 学习定位: 核心掌握级:这是岗位主线,至少要完整复现并改造一种策略架构。
- 最低实践: 比较 ACT、Diffusion Policy 和一个 VLA 路线,测试 Action Chunk、动作归一化与控制频率。
- 达标标准: 能讲清观察、语言、状态、Action Head 和机器人控制接口之间的完整数据流。
- 本阶段需要覆盖的原文技术:
ACT、Action Chunk、action chunking、Action Head、Diffusion Policy、FluxVLA、GR00T、GR00T N1.7、GROOTHelix、LingBot、LoRA、MT-ACT、Octo、OpenPI、OpenVLA、PI0、policyprompt-to-action、QLoRA、Qwen-VLA、RDT、RoboBrain、RT-2、RT-X、SARM、SARM2StarVLA、Vision-Language-Action、vla、VTLA、wam、World-Action Model、世界动作模型、动作分块、视觉语言动作跨本体
十、阶段 6:World Model、RL 与长时序决策
学习目标
- 理解环境动力学、动作后果和长期演化如何建模。
- 能把 World Model、Planning、RL 与 VLA Policy 联系起来。
- 能针对长时序、稀疏奖励和误差累积设计实验。
必学内容
- Latent Dynamics、Video Prediction、Action-Conditioned Model。
- Dreamer、MuZero、JEPA、TD-MPC、Model-Based RL。
- PPO、SAC、Offline RL、Reward Model、Curriculum 和 Replay Buffer。
- Planning、MPC、Skill-Level Planning、长 horizon 和 recovery policy。
- SFT、DPO、RLHF/RLAIF、GRPO 等后训练思想在策略模型中的应用。
实践任务
- 训练一个预测未来状态或视频帧的动作条件模型。
- 用预测模型辅助规划或策略选择,并与无 World Model 基线对比。
- 设计长时序任务,测量误差累积和任务中断位置。
- 研究 reward sparsity、reset distribution 和 curriculum 对训练的影响。
可交付成果
- World Model 或 Model-Based Policy 实验。
- 长时序任务评测协议。
- 模型预测误差与任务成功率关系分析。
验收标准
- 能说明 World Model 不等于 VLA,但可以如何辅助 VLA。
- 能区分预测准确率提升与实际策略提升。
- 能设计验证长期规划、恢复能力和分布外泛化的实验。
岗位技术扩展:World Model、强化学习与模仿学习
- 学习定位: 掌握级:能区分离线学习、在线交互、世界模型预测和后训练各自解决的问题。
- 最低实践: 实现 BC 基线,再加入一种 RL 或 World Model 改进,分析 reward、horizon 和分布偏移。
- 达标标准: 能用闭环成功率证明策略改进,而不是只展示预测 loss 或离线指标。
- 本阶段需要覆盖的原文技术:
BC、Cosmos Policy、Ctrl-World、DAgger、DAPO、DDPG、DPO、Dreamer、DreamerV2GRPO、HIL-SERL、human-in-the-loop learning、JEPA、long-horizon manipulation、Model-Based RL、mpc、Offline RL、offline-to-onlineplanning、PPO、real-robot RL、reward、RFT、rl、RLAIF、RLHF、RLINFRLVR、SAC、SERL、SFT、TD-MPC、TD-MPC2、TD3、V-Learning、world model世界模型、决策、序列决策、强化学习、模仿学习、策略、行为克隆、长时序
十一、阶段 7:数据工程、评测闭环与 Sim2Real
学习目标
- 能建立从采集到再训练的数据闭环。
- 能把失败案例转换成可操作的数据和模型改进。
- 能评估仿真策略迁移到真实系统的风险。
必学内容
- 遥操作、UMI、rosbag、LeRobot 格式和多源轨迹数据。
- 时间同步、空间标定、轨迹切分、异常过滤、质量评分和版本管理。
- 真机数据、仿真数据、互联网视频和合成数据的配比。
- Domain Randomization、Real-to-Sim-to-Real、校准与域适配。
- Real2Sim 场景重建、仿真参数辨识、HIL/SiL 验证与 Sim-Real 差异度量。
- Benchmark、failure case、任务成功率、恢复率、鲁棒性和数据效率。
实践任务
- 定义一套机器人轨迹数据规范和质量检查器。
- 建立训练集、验证集和真实闭环测试集,避免任务泄漏。
- 搭建“训练 → 部署 → bad case → 数据修复 → 再训练”流程。
- 测试光照、遮挡、物体变化、延迟、标定误差和执行噪声。
- 对同一真实场景构建粗网格、NeRF/3DGS 重建和人工高保真资产三个版本,比较视觉差异、接触差异与策略成功率。
- 通过 HIL/SiL 和少量真机回放校准质量、摩擦、延迟及传感器噪声,记录每次校准是否缩小 Sim-Real 指标差距。
可交付成果
- 数据规范与自动检查脚本。
- Benchmark 和评测仪表。
- bad case 数据闭环报告。
- Sim2Real 风险清单和缓解方案。
- Real2Sim 资产版本、参数辨识记录和“重建质量 → 策略表现”对照表。
验收标准
- 能说明每条数据为什么进入训练集、被删除或被降权。
- 能用稳定指标比较两版策略,而不是只看演示视频。
- 能判断失败来自仿真差异、传感器、动作接口还是模型本身。
- 能把视觉重建误差、几何/碰撞误差和物理参数误差分别量化,并据此选择重建、随机化或真实数据回流方案。
岗位技术扩展:轨迹数据、数据集与评测闭环
- 学习定位: 核心实践级:数据和评测决定策略是否真正进步。
- 最低实践: 建立轨迹格式、质量检查、版本管理、Benchmark 和 bad case 再训练流水线。
- 达标标准: 每次模型迭代都能追溯到数据变化、训练变化和闭环指标变化。
- 本阶段需要覆盖的原文技术:
AGIBot World、AGIBot-World、benchmark、Bridge、DexGraspNet、DROID、Ego4D、EgoDex、Epic-KitchenGO-1、LeRobot、Open X-Embodiment、OXE、ROBOCOIN、ROBOMIND、RoboNet、rosbag、rosbag2UMI、后训练、微调、数据、数据处理、数据标注、数据清洗、数据集、标注泛化、训练、评估、评测、预训练
岗位技术扩展:仿真、Sim2Real 与数字孪生
- 学习定位: 实践级:能在仿真中稳定训练和评测,并知道迁移到真实系统会坏在哪里。
- 最低实践: 搭建同一任务的仿真训练、扰动评测和受控真实验证,量化域差异。
- 达标标准: 能提出并验证校准、随机化、域适配和真实数据回流方案。
- 本阶段需要覆盖的原文技术:
AI2-THOR、Blender、CARLA、Domain Randomization、Gazebo、Genesis、Habitat、HIL、isaacIsaac Gym、Isaac Lab、Isaac Sim、IsaacGym、IsaacLab、ManiSkill、MuJoCo、Newton、NVIDIA IsaacOmniverse、Orbit、PhysX、PyBullet、Real-Sim-Real、Real2Sim、RLBench、RoboCasa、SAPIENSiL、sim-to-real、sim2real、Unity、Unreal Engine、USD、V-Rep、仿真、域随机化数字孪生、真机
十二、阶段 8:分布式训练、推理与部署优化
学习目标
- 能训练更大模型并解释吞吐、显存和通信瓶颈。
- 能把模型部署到满足机器人实时约束的推理链路。
- 能量化优化前后的精度与系统代价。
必学内容
- DDP、FSDP、DeepSpeed、Megatron-LM、Colossal-AI、数据/张量/流水线并行。
- 混合精度、梯度累积、Checkpoint、数据加载和通信优化。
- INT8/INT4、AWQ/GPTQ、Pruning、Distillation、ONNX/ONNX Runtime、TensorRT/TensorRT-LLM、vLLM 和推理引擎。
- KV Cache、Action Chunk、批处理、异步流水线和端到端延迟。
- Docker/K8s、服务接口、ROS2 集成、监控和故障恢复;Jetson/Orin 等边缘硬件的算力、内存和功耗约束。
实践任务
- 在多卡环境对比 DDP、FSDP 或 DeepSpeed 的显存和吞吐。
- 对一个 VLM/VLA 模型做量化或蒸馏实验。
- 分解视觉预处理、模型推理、动作后处理和通信延迟。
- 建立超时、异常输入和模型失效时的安全降级路径。
- 导出 ONNX,比较 FP16、INT8、INT4/AWQ/GPTQ 与 TensorRT 的精度、显存、吞吐和 P99 延迟,并在目标边缘硬件上复测。
- 用 profiler 找出一个 CUDA 热点,完成算子融合、内存访问或自定义 CUDA 算子优化,并验证数值一致性与端到端收益。
可交付成果
- 分布式训练配置与性能报告。
- 推理优化前后对比。
- 端到端延迟剖析和部署说明。
- 可复现的模型导出、量化、引擎构建和目标硬件基准脚本。
- CUDA profiling、算子优化前后基准和正确性测试。
验收标准
- 能解释 OOM、低 GPU 利用率和数据加载瓶颈。
- 能说明训练并行策略、量化格式、推理引擎与机器人实时预算之间的取舍。
- 能说明优化带来的精度、吞吐、显存和延迟取舍。
- 部署链路能够稳定运行,并有异常监控和恢复策略。
岗位技术扩展:分布式训练、推理优化与部署
- 学习定位: 工程掌握级:能量化显存、吞吐、精度和延迟之间的取舍。
- 最低实践: 完成一次多卡训练和一次端侧/服务化推理优化,输出 profiling 与对比报告。
- 达标标准: 能定位 OOM、通信、数据加载和推理延迟瓶颈,并给出可验证改进。
- 本阶段需要覆盖的原文技术:
AWQ、Colossal-AI、CUDA 加速、CUDA 算子、CUDA加速、DDP、DeepSpeed、FSDP、GPTQINT4、INT8、Jetson、K8s、KV cache、llama.cpp、Megatron、Megatron-LM、NanoLLMONNX、ONNX Runtime、Orin、TensorRT、TensorRT-LLM、TorchDeploy、vLLM、分布式、剪枝加速、工程化、并行、性能、推理、蒸馏、部署、量化、集群
十三、阶段 9:论文复现、研究能力与作品集
学习目标
- 能快速读懂论文、识别关键假设并独立复现核心方法。
- 能设计可信的对照实验、消融实验和失败分析。
- 能用项目证明具备数据、模型、机器人和系统的综合能力。
必学内容
- ICLR、NeurIPS、CVPR、ICRA、IROS、RSS、CoRL 等会议的相关方向。
- 论文问题定义、方法假设、实验协议、基线、公平比较和复现误差。
- 技术报告写作、图表、实验日志、代码质量和开源规范。
实践任务
- 每两周精读一篇论文,输出问题、方法、实验和局限总结。
- 至少完成一次“论文无完整代码时”的核心模块复现。
- 对自己的 VLA 项目完成基线、消融、失败分析和复现实验。
- 将项目整理成代码仓库、技术报告和短演示。
作品集最低配置
- 一个 VLM 微调与评测项目。
- 一个 ACT、Diffusion Policy 或同类策略复现。
- 一个 VLA 全链路项目。
- 一个 World Model、RL 或长时序决策实验。
- 一份数据闭环或 Sim2Real 报告。
- 一份训练/推理性能优化报告。
验收标准
- 别人可以按文档复现主要结果。
- 每个结果都有基线、指标和失败案例,而不只是成功演示。
- 能清楚说明自己完成了哪些工作、做了哪些选择、失败过什么以及如何改进。
岗位技术扩展:研究、开源与能力证明
- 学习定位: 证明级:这些词不是模型模块,但决定学习结果能否被验证和复用。
- 最低实践: 把技术工作整理成复现仓库、消融实验、失败分析、技术报告和可运行演示。
- 达标标准: 第三方可以依据文档复现核心结果,并看清你的具体贡献与技术判断。
- 本阶段需要覆盖的原文技术:
ACL、corl、cvpr、ECCV、EMNLP、ICCV、iclr、ICML、icraIJRR、iros、neurips、NIPS、RAL、rss、TPAMI、TRO、专利前沿、复现、实践经验、工作经验、工程经验、年以上、年经验、开源、研发经验研究经验、科研、竞赛、落地经验、论文、顶会、项目经验
十四、按岗位层级准备
工程师与实习生主线
优先证明“能做完整实验闭环”:
- 能处理数据并完成训练、调优和评测。
- 能复现 VLA/VLM/Policy 模型并解释主要模块。
- 能在仿真或真实机器人任务中做闭环验证。
- 能定位 failure case,提出数据或模型改进。
- 能写出可维护、可复现的训练代码。
专家、负责人和科学家进阶
在主线能力之外,需要进一步证明:
- 能制定 VLA、World Model、机器人学习和数据闭环技术路线。
- 能比较不同模型架构、训练范式和落地方案的取舍。
- 能建立统一 Benchmark、数据规范和研发流程。
- 能推动多团队完成模型、控制、硬件和系统集成。
- 能持续形成研究成果、核心技术和规模化落地能力。
自动驾驶 VLA 分支
在通用 VLA 能力上补充:
- 驾驶场景的感知、预测、规划与行为建模。
- BEV、Occupancy、Spatial Memory、World Model 和闭环仿真。
- 视觉、语言、驾驶动作和车辆状态的多模态数据。
- CARLA 等闭环环境、bad case 分析和安全评测。
- 车端芯片推理、量化、延迟和资源约束。
岗位技术扩展
- 学习定位: 分支实践级:在通用 VLA 之外补充驾驶场景的感知、预测、规划和安全评测。
- 最低实践: 在 CARLA 或闭环数据上完成 VLA/World Model 的轨迹生成、bad case 和车端延迟实验。
- 达标标准: 能区分机器人操作 VLA 与驾驶 VLA 在动作空间、数据、评测和安全约束上的差异。
- 本阶段需要覆盖的原文技术:
Apollo、Autoware、BEV、Occupancy、OpenDriveLab、Spatial Memory、UniAD、VAD、自动驾驶
十五、项目选择建议
项目 A:策略学习入门
- 任务:仿真机械臂 pick-and-place。
- 模型:ACT 或 Diffusion Policy。
- 必须包含:数据处理、训练、闭环评测、扰动测试和失败分析。
项目 B:VLA 全链路
- 任务:自然语言指令驱动多任务操作。
- 模型:OpenVLA、PI、RDT、GR00T 或其他可运行路线。
- 必须包含:多模态数据、微调、跨任务测试、延迟测量和部署说明。
项目 C:World Model 与长时序
- 任务:预测动作后果并辅助规划或策略选择。
- 模型:Dreamer、JEPA、视频预测或 Action-Conditioned Model。
- 必须包含:预测指标、任务指标、误差累积和基线比较。
项目 D:数据与 Sim2Real
- 任务:建立遥操作/仿真数据到真实策略验证的闭环。
- 必须包含:数据质量规则、域随机化、真机或受控验证、bad case 再训练。
项目 E:Real2Sim 场景重建与 Isaac 物理校准
- 任务:用 NeRF/3DGS 重建一个真实操作场景,生成可碰撞资产并导入 Isaac Sim。
- 必须包含:相机标定、重建质量评测、USD 资产组织、PhysX 参数辨识、HIL/SiL 或受控真机对照。
- 核心结论:量化视觉、几何和物理误差分别怎样影响策略成功率,并给出 Domain Randomization 或真实数据回流方案。
选择项目时,优先做“可完整闭环的小任务”,不要一开始追求庞大模型。岗位真正看重的是能否清晰处理数据、训练、评测、失败和落地。
十六、自检清单
模型
- ☐ 能解释 VLM、VLA、World Model 和 Policy 的边界与关系。
- ☐ 能解释 Action Head、Action Token、Action Chunk 和控制频率。
- ☐ 能独立完成 SFT/微调、评测和 failure case 分析。
- ☐ 能比较自回归、Diffusion Policy 和 Flow Matching。
机器人
- ☐ 能处理坐标系、标定、运动学、传感器和控制接口。
- ☐ 能在 ROS2 与仿真环境中完成闭环任务。
- ☐ 能定义任务成功、恢复、鲁棒性和延迟指标。
- ☐ 能校验 URDF/SDF 与 USD 资产,并调试 PhysX 接触、摩擦、阻尼和碰撞参数。
- ☐ 能完成 NeRF/3DGS 场景重建、仿真导入,并评估重建误差对策略的影响。
数据
- ☐ 能设计轨迹数据格式、同步、清洗、切分和质量评分。
- ☐ 能解释训练数据分布如何影响真实泛化。
- ☐ 能建立 bad case 到再训练的闭环。
系统
- ☐ 能定位训练吞吐、显存、通信和数据加载瓶颈。
- ☐ 能完成量化、推理优化和端到端延迟分析。
- ☐ 能为异常输入、超时和模型失效设计保护机制。
- ☐ 能比较 ONNX/TensorRT、INT8/INT4、AWQ/GPTQ 在目标硬件上的精度、显存和 P99 延迟。
研究与表达
- ☐ 能快速阅读并复现核心方法。
- ☐ 能设计基线、消融和公平评测。
- ☐ 能把实验结论写成可复现的技术报告。
what is agent
type: 教程 status: 已发布 level: 入门 topic:
- Agent
- 基础模型
什么是 AI Agent?
AI Agent 是一个能在给定目标和约束下,观察环境、选择动作、调用工具、接收反馈,并持续推进任务的软件系统。
一句话区分:LLM 负责“推理和生成”,Agent 系统负责“把模型放进可行动、可观察、可评测的环境里”。
Agent 不等于 Chatbot
| 类型 | 主要能力 | 是否行动 | 典型例子 |
|---|---|---|---|
| Chatbot | 对话和回答 | 否 | FAQ、知识问答 |
| Workflow | 按固定步骤处理任务 | 有,但流程固定 | 分类 -> 检索 -> 生成 -> 审核 |
| Agent | 模型根据状态选择下一步动作 | 有,路径可变 | 研究助手、Web Agent、Coding Agent |
| Multi-Agent | 多个 Agent 通过角色或协议协作 | 有 | planner + executor + reviewer |
Anthropic 在 Agent 工程实践中强调:很多任务用 workflow 更稳,只有当任务路径难以提前写死、需要模型动态决策时,才需要更自主的 Agent。
Agent 的最小闭环
Goal
-> Observe state
-> Think / plan
-> Act with tools
-> Observe result
-> Stop / continue / ask human
这就是常见的 ReAct 思路:Reasoning + Acting。真正工程化时,最好不要暴露完整 chain-of-thought,而是记录可审计的 reason_summary、工具调用、观察结果和最终判断。
Agent 的 8 个组成部分
| 模块 | 作用 | 面试追问 |
|---|---|---|
| Goal | 定义任务和成功标准 | 怎么判断任务完成? |
| Policy | 系统规则、安全边界、权限 | 哪些动作必须人工确认? |
| State | 当前进度、历史、临时产物 | 长任务如何恢复? |
| Memory | 可复用经验和用户偏好 | 什么值得存,什么时候忘? |
| Context Builder | 组装模型输入 | 如何避免上下文污染? |
| Tool Registry | 声明可调用工具 | schema、错误、权限怎么设计? |
| Loop Controller | 决定下一步和停止条件 | 如何防止无限循环? |
| Eval / Trace | 记录和评估行为 | 如何证明 Agent 有效? |
能力分级
| 级别 | 名称 | 特征 | 示例 |
|---|---|---|---|
| L0 | Prompt App | 无工具,只生成文本 | 简单总结器 |
| L1 | Tool-Using App | 单轮工具调用 | 查天气后回答 |
| L2 | Workflow Agent | 多步骤但流程固定 | RAG pipeline |
| L3 | Autonomous Agent | 模型在有限步内选动作 | 资料研究 Agent |
| L4 | Long-running Agent | 有持久状态、恢复、人工介入 | Coding Agent、Web Agent |
| L5 | Multi-Agent System | 多角色协作和协调 | 研究员 + 写作者 + 审稿人 |
求职项目做到 L3-L4 就已经有含金量。L5 很酷,但复杂度和评测成本也高,不建议新手一上来做“全自动公司”。
什么时候不该用 Agent
- 任务流程固定,用普通 workflow 更稳定。
- 成功标准无法定义,也没有人工审核。
- 工具风险高,但没有权限、日志和回滚。
- 只是一次文本生成,不需要环境反馈。
- 评测成本太高,无法证明改动有效。
面试怎么回答
一个合格回答:
Agent 是把 LLM 放进一个有状态、有工具、有反馈、有约束的执行循环中。它和普通 chatbot 的区别在于会对环境采取动作,并根据观察结果调整下一步。工程上我会重点设计 tool schema、context builder、loop controller、权限边界、trace 和 eval,而不是只写 prompt。
项目落地清单
做任何 Agent 项目前先回答:
- 用户目标是什么?
- 为什么 workflow 不够?
- 工具有哪些,哪些有风险?
- 状态和产物存哪里?
- 最大步数和停止条件是什么?
- 出错时怎么恢复?
- 用什么 eval case 证明有效?
延伸阅读
- Anthropic: Building effective agents
- OpenAI: A practical guide to building agents
- LangGraph
- OpenAI Agents SDK
deepseek series
type: 教程 status: 已发布 level: 进阶 topic:
- 基础模型
- 模型训练
DeepSeek 系列完整深度笔记
覆盖范围:DeepSeek-V1 → V2 → V3 → R1 → Prover-V2 → V3.2 → DualPath → Engram 学习方式:从基础概念到工程实践,从原理到前沿
目录
- DeepSeek-V1:开源大模型的起点
- DeepSeek-Math:数学推理的专项突破
- DeepSeek-V2:MoE架构的革命
- DeepSeek-V3:从V2到工业级MoE
- DeepSeek-R1:纯RL解锁推理能力
- DeepSeek-Prover-V2:形式化定理证明
- DeepSeek-V3.2:稀疏注意力的探索
- DualPath:榨干每一块闲置网卡的带宽
- DeepSeek Engram:让大模型学会查字典
1. DeepSeek-V1
1.1 论文信息
论文名称:DeepSeek LLM: Scaling Open-Source Language Models with Longtermism
1.2 模型结构
DeepSeek-V1 基于 LLaMA 架构,选择"站在巨人肩膀上"——不从零开始,而是在成熟基础上优化。
三大核心组件
PreRMSNorm(前置均方根归一化)
在每一层计算之前先对输入做归一化处理,防止某个特征值主导整个计算过程。
传统LayerNorm:计算均值和方差,相对开销较大
PreRMSNorm:只计算均方根,更轻量,效果相当
公式:RMSNorm(x) = x / sqrt(mean(x²) + ε) * γ
SwiGLU(门控线性单元)
FFN层的激活函数,决定哪些信息值得向后传递。相比ReLU,SwiGLU通过门控机制提供了更平滑的梯度流。
SwiGLU(x) = Swish(xW₁) ⊗ (xW₂)
Swish(x) = x * sigmoid(βx)
RoPE(旋转位置编码)
给每个词打上"位置编号",让模型感知词与词之间的相对距离。相比绝对位置编码,RoPE对长文本的泛化性更好。
GQA(分组查询注意力)——67B专属优化
核心问题:KV Cache 的显存危机
在推理时,模型需要缓存每个 token 的 K(Key)和 V(Value)向量,称为 KV Cache。上下文越长,KV Cache 越大。
标准MHA的显存占用:
KV Cache 大小 = 层数 × KV头数 × 每头维度 × 序列长度
7B模型:30层 × 32头 × 128维 = 122,880 个数值/token
67B模型(不用GQA):95层 × 64头 × 128维 = 778,240 个数值/token
67B模型(用GQA):95层 × 8头 × 128维 = 97,280 个数值/token
GQA的核心思路:多个Q头共享同一组K、V头
MHA:32个Q头 → 32个K头 + 32个V头(每人一本书)
GQA:32个Q头 → 8个K头 + 8个V头(四人共用一本书)
压缩比:4倍
为什么7B不需要GQA,67B必须用?
三个维度同时变大(层数×头数×维度),KV Cache 指数级增长。GQA 让 67B 的 KV Cache 开销控制在和 7B 同一数量级。
具体参数对比:
| 参数 | 7B | 67B |
|---|---|---|
| 层数 | 30 | 95 |
| 模型维度 | 4096 | 8192 |
| 注意力头数 | 32 | 64 |
| KV头数 | 32 | 8(GQA) |
| Context长度 | 4096 | 4096 |
| Sequence Batch Size | 2304 | 4608 |
| 学习率 | 4.2e-4 | 3.2e-4 |
| 训练Token数 | 2.0T | 2.0T |
1.3 BBPE 分词算法
DeepSeek-V1 使用 Byte-level BPE(BBPE)。
普通BPE的问题:
遇到生僻字 → [UNK](未知符号)→ 信息丢失
BBPE的改进:
在字节(byte)级别操作
任何文字 = 256个基础字节的组合
→ 永远不会出现UNK ✅
→ 对中文、代码、数学符号都友好
DeepSeek的BBPE配置:
- 训练语料:约24GB文本
- 词汇表大小:102,400个token(比GPT-2的50,257大一倍)
- 原因:中文字符、数学符号、代码关键字需要更多词表空间
1.4 SFT训练(监督微调)
目的:教模型从"续写者"变成"助手"
没有SFT时的问题:
输入:"帮我写一封道歉信"
Base模型输出:"帮我写一封道歉信的方法有很多种,古代文人常用..."
← 在续写,不是在帮忙!
训练数据:
- 规模:1.5M 条中英文指令数据
- 中文:日常对话、知识问答、写作
- 英文:学术、代码、逻辑推理
- 双语混合:让模型学会语言间灵活切换
超参数设计:
| 配置 | 7B | 67B |
|---|---|---|
| 训练轮数 | 4 epochs | 2 epochs |
| 学习率 | 1e-5 | 5e-6 |
为什么大模型用更小的学习率和更少轮数?
大模型预训练积累了大量知识,大学习率会导致灾难性遗忘(Catastrophic Forgetting)。步子太大会把预训练学到的知识"冲掉"。
1.5 DPO训练(直接偏好优化)
背景:SFT之后模型能理解指令,但输出质量参差不齐。DPO让模型学会"更好"的回答风格。
偏好数据构建流程:
第一步:对同一问题,用Chat Model采样多个候选回答
第二步:用规则+模型打分区分好坏
规则维度(客观):格式规范、长度合适、回答了问题
模型打分维度(主观):用更强模型当裁判
第三步:筛选差异明显的对(信号强)
DPO vs RLHF的优势:
RLHF流程:人类标注 → 训练RM → PPO训练
问题:需要单独训练RM,PPO不稳定,显存压力大
DPO流程:偏好对数据 → 直接优化Policy Model
优势:更简单、更稳定、不需要RM、显存更小
DPO目标函数直觉:
loss = -log(sigmoid(
β * (log_prob(好回答) - log_prob(差回答) # 当前模型
- log_prob(好回答) - log_prob(差回答)) # 参考模型
))
# β控制偏离参考模型的程度
# 让"好回答"概率相对参考模型提高
# 让"差回答"概率相对参考模型降低
DeepSeek-V1 DPO超参数:
- Batch size:512(更大batch → 梯度更稳定)
- 学习率:5e-6(和大模型SFT一样小,防止过度更新)
为什么用自己的模型生成偏好对?
- 不是让模型"评判好坏",而是生成多样性后用规则筛选
- "模型最了解自己的输出分布"
- 成本远低于大规模人工标注
2. DeepSeek-Math
2.1 主要贡献
- 可扩展的数学预训练:从Common Crawl中挖掘120B数学tokens
- 强化学习的探索:GRPO算法在数学推理上的应用
2.2 数据处理流程:fastText流水线
核心思路:粗筛 → 精筛的工业流水线
Math Seed(高质量种子)
↓ 训练fastText分类器
fastText扫描40B HTML网页(粗筛,极快)
↓ 按分数排名
去重 + 过滤(精筛)
↓ 四轮迭代
最终产出:3550万数学网页,120B tokens
为什么用fastText而不是GPT-4?
| 维度 | fastText | GPT-4 |
|---|---|---|
| 速度 | 数十万条/秒 | 几十条/秒 |
| 成本 | 极低 | 极高 |
| 精度 | 足够(粗筛不需要完美) | 更高 |
| 场景 | 40B网页的初步过滤 | 精细质量判断 |
速度差距约10,000倍,面对40B网页,大模型完全不可行。这是工程思维的核心:规模决定工具选择。
fastText训练数据:
- 正样本:从OpenWebMath随机抽50万条(已知高质量数学网页)
- 负样本:从Common Crawl随机抽50万条普通网页
- 关键:用目标域数据定义"什么是数学",而不是人工写规则
fastText配置:
- 向量维度:256
- 学习率:0.1
- 最大词n-gram长度:3
- 最小词出现次数:3
- 训练轮数:3
2.3 数据清洗四步走
第一步:去重
- URL去重:相同URL只保留一份
- 近似去重:相似内容去除
- 将Common Crawl压缩为40B个HTML网页
第二步:召回与排名
- 使用fastText对去重后的网页打分
- 按分数降序排名
- 只保留前40B tokens(通过预训练实验确定阈值)
第三步:迭代优化(4轮)
- 识别和注释未收集的数学网页来源
- 丰富种子语料库,重新训练fastText
- 每轮召回更多高质量数据
第四步:去污染(Decontamination)
防止训练数据包含测试集内容,避免评测基准被污染。
两段式去污染规则:
def is_contaminated(webpage_text, benchmark_texts):
for bench_text in benchmark_texts:
length = len(bench_text)
if length >= 10:
# 长文本:子串匹配(宽松)
# 10字符随机碰撞概率极低,误伤少
if bench_text in webpage_text:
return True
elif length >= 3:
# 短文本:精确匹配(严格)
# "∫dx"这种短公式到处都有,不能用子串匹配
if bench_text == webpage_text.strip():
return True
# < 3字符:直接放弃过滤(无法可靠识别)
return False
设计逻辑:
- 长题目(≥10字符):出现即删,误伤极少
- 短题目(3-9字符):必须完全匹配才删,保护正常内容
- 极短(<3字符):无法区分,跳过
2.4 预训练配置
基座模型:DeepSeek-Coder-Base-v1.5 7B(从Code LLM开始是好选择)
为什么从代码LLM开始?
代码和数学有深层共性:
├── 都需要严格的符号推理
├── 都需要追踪变量状态
├── 都有明确的正确/错误标准
└── 都需要结构化的步骤分解
代码训练相当于给数学能力"预热"
先做代码预训练 → 再做数学预训练
效果 > 直接做数学预训练
预训练数据分布(500B tokens):
| 数据来源 | 比例 | 说明 |
|---|---|---|
| DeepSeekMath语料库 | 56% | 核心数学网页 |
| AlgebraicStack | 4% | 代数专项 |
| arXiv论文 | 10% | 高质量数学推导 |
| GitHub代码 | 20% | 提升代码-数学协同能力 |
| Common Crawl自然语言 | 10% | 保持通用能力 |
训练框架:HAI-LLM 优化器:AdamW 预热步数:2000步 学习率:4.2e-4 Batch Size:10M tokens
2.5 指令微调
数据集构成:
- 总量:776K样本
- 语言:中英文混合
- 难度:覆盖不同数学领域和复杂程度
三种解题格式:
| 格式 | 全称 | 适用场景 | 特点 |
|---|---|---|---|
| COT | Chain of Thought | 需要语义理解的题 | 自然语言推理,人类可读 |
| POT | Program of Thought | 数值计算密集型 | 用代码写推理,精度100% |
| Tool-integrated | 工具集成推理 | 推理+精确计算混合 | 两全其美,系统较复杂 |
选择示例:"计算123456789 × 987654321" → 选POT(代码计算),因为自然语言处理进位信息容易出错
训练配置:
- 数据拼接长度:4K tokens
- Batch Size:256
- 学习率:5e-5
- 训练步数:500步
2.6 Pass@K 评估指标
为什么不用普通准确率?
模型对数学/代码题有随机性,一次采样答错不等于模型不会。
Pass@K的思路:
对同一道题采样K次
只要有1次答对 → 算通过
更公平地反映模型的真实能力上限
计算公式:
def pass_at_k(n_samples, n_correct, k):
"""
n_samples: 总采样次数(如采样16次)
n_correct: 其中答对的次数
k: Pass@K中的K值
"""
if n_correct == 0:
return 0.0
# 1 - 全部答错的概率
prob_all_wrong = (
combinations(n_samples - n_correct, k) /
combinations(n_samples, k)
)
return 1.0 - prob_all_wrong
# 例子:16次采样中答对4次
# Pass@1 = 4/16 = 25%
# Pass@64 ≈ 99%(采样越多越容易碰到对的)
2.7 强化学习:GRPO在数学上的应用
算法:GRPO(Group Relative Policy Optimization)
Group Size = 64 的含义:
对每道数学题,采样64个不同的解题过程
可能的结果:
├── 64个里有30个答对 → 这道题难度中等
├── 64个里有2个答对 → 这道题很难
└── 64个里有63个答对 → 这道题很简单
为什么数学任务需要G=64(比R1-Zero的G=16更大)?
数学推导步骤多,出错概率高
竞赛级别的题:16个样本可能全部答错!
→ 全是0的奖励 → 无法估计优势值
G=64:即使很难的题,64次里大概率有1-2次答对
→ 至少有一个正奖励信号
→ 优势值估计有意义
3. DeepSeek-V2
3.1 论文信息
论文名称:DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model
3.2 DeepSeekMoE 架构
MoE(Mixture of Experts,混合专家)的基本思想:不是所有参数都参与每次计算,而是根据输入动态选择激活哪些"专家"。
3.2.1 共享专家:解决知识冗余
没有共享专家时的问题:
刑事律师:需要懂基础法律 + 刑事专业 ← 基础法律重复!
民事律师:需要懂基础法律 + 民事专业 ← 基础法律重复!
税务律师:需要懂基础法律 + 税务专业 ← 基础法律重复!
→ 每个专家都在重复存储"基础知识"
→ 浪费参数,且每人的专业深度被基础知识占用
引入共享专家后:
共享专家(法律顾问):专门掌握基础法律,人人调用
刑事律师:只专注刑事专业
民事律师:只专注民事专业
税务律师:只专注税务专业
→ 每个路由专家可以专得更深!
论文将此称为:减少路由专家之间的知识冗余。
3.2.2 细粒度专家切分
传统MoE(粗粒度):
4个大专家,每次激活Top-2
[专家A(大)] [专家B(大)] [专家C(大)] [专家D(大)]
激活后:[A] + [C]
DeepSeekMoE(细粒度):
8个小专家,每次激活Top-4(激活参数量相同!)
[a][b][c][d][e][f][g][h]
激活后:[a] + [c] + [e] + [g]
为什么切细更好?
专家越细 → 每个专家负责的知识领域越窄 → 专业化程度越高 → 组合更灵活。类比乐高积木:大块只能拼出几种形状,小块能拼出任何形状。
3.2.3 FFN输出计算公式
h'_t = u_t # 原始输入
+ Σ FFN_i^(s)(u_t) # 共享专家:每次必激活
+ Σ g_{i,t} * FFN_i^(r)(u_t) # 路由专家:只激活Top-K个
其中门控值:
g_{i,t} = s_{i,t},如果 s_{i,t} ∈ TopK({s_{j,t}}, K_r)
g_{i,t} = 0,否则
亲和度分数:
s_{i,t} = Softmax_i(u_t^T * e_i)
3.3 设备受限路由(Device-Limited Routing)
问题背景:
在专家并行时,专家分布在多台机器上。如果不限制,每个token可能需要联系全集群的专家。
没有设备限制时的通信开销:
V2有160个路由专家,分布在多台机器
token_A的Top-6专家 → 可能散落在6台不同机器上
→ 需要6次跨机器通信
→ 每次通信 ~100μs
→ 总等待:600μs
有设备限制(M=3)时:
token_A的Top-6专家 → 只来自3台机器以内
→ 最多3次跨机器通信
→ 总等待:300μs(减半!)
关键实验结论:
M=1(只用本机专家):性能明显下降
M=2:性能接近无限制
M=3:性能几乎等于无限制 ← DeepSeek选择这里
M=∞:性能基准线,但通信爆炸
好专家的分布是局部聚集的,不需要全局搜索。
3.4 负载均衡三道防线
第一道:设备受限路由
控制每个token最多联系M个设备,解决"发送侧"流量集中问题。
第二道:Communication Balance Loss
解决"接收侧"流量集中问题。
L_CommBal = α₃ × Σᵢ f_i'' × P_i''
f_i'' = (D/MT) × Σₜ 1(Token t is sent to Device i)
P_i'' = Σⱼ∈Eᵢ P_j
含义:
f_i'':设备i实际收到的token比例
P_i'':路由器分配给设备i的概率
两者都大 → 惩罚大 → 路由器被迫分散流量
类比:高速公路收费站引导系统,主动引导车辆去队伍短的窗口。
第三道:Token-Dropping Strategy(Token丢弃)
前两道防线都是"概率性"的,极端情况下某设备仍可能过载。Token Dropping是最后的兜底。
处理流程:
def device_forward(tokens_received, avg_budget):
# 第一步:按路由分数降序排列
sorted_tokens = sort_by_routing_score(tokens_received, order='descending')
# 第二步:只处理预算以内的token
tokens_to_process = sorted_tokens[:avg_budget] # ✅ 处理
tokens_to_drop = sorted_tokens[avg_budget:] # ❌ 丢弃
# 被丢弃的token不参与该层计算,直接用残差跳过
return compute(tokens_to_process)
为什么按路由分数排序再丢弃是合理的?
- 低分token:与该专家本来匹配度低,即使计算贡献也小,丢掉影响不大
- 高分token:该专家对这些token最重要,必须保留
3.5 MLA(Multi-Head Latent Attention)
核心动机:GQA是粗暴压缩(减少头数),MLA是精细压缩(压缩每头维度)。
问题规模
V2标准配置下,KV Cache大小:
128个注意力头 × 128维 × 2(K+V) × 128K tokens × 60层
= 约 240GB(比模型权重还大!)
低秩投影的核心思想
类比:
完整KV(1000页百科全书)
GQA的方案:只带8章,其他章节丢掉
→ 轻了,但信息有损失
MLA的方案:把1000页压缩成50页精华索引
需要内容时,从索引重新展开
→ 同样轻,但信息损失更少!
压缩效果数字对比:
标准MHA每个token缓存:
K + V = 128头 × 128维 × 2 = 32,768 个数值
MLA每个token只缓存:
一个低秩向量 c_t^KV,维度 = 512
压缩比:32,768 / 512 = 64倍!(远超GQA的16倍)
MLA数据流
第一步:压缩(每个新token都要做,结果存入缓存)
h_t ──[W^{DKV}降维矩阵]──> c_t^KV(512维)← 只缓存这个!
第二步:展开(计算注意力时)
c_t^KV ──[W^{UK}升维矩阵]──> 完整K向量
c_t^KV ──[W^{UV}升维矩阵]──> 完整V向量
# MLA的KV压缩与展开
# 压缩阶段
c_t_KV = h_t @ W_DKV # 降维:[d_model] → [512]
kv_cache.store(c_t_KV) # 只缓存这512维!
# 展开阶段(计算注意力时)
c_t_KV = kv_cache.load() # 取出512维
k_t = c_t_KV @ W_UK # 升维回完整K
v_t = c_t_KV @ W_UV # 升维回完整V
# 注意力计算照常进行
scores = q_t @ k_t.T / sqrt(d_head)
output = softmax(scores) @ v_t
RoPE位置编码的处理
KV压缩状态无法直接加RoPE,MLA将K拆成两部分:
K = [K^C ; K^R]
↑ ↑
内容部分 位置部分
从c_t_KV 从h_t直接
展开得到 计算RoPE
缓存时:
c_t_KV(内容)← 低秩压缩,省空间
k_t_R(位置) ← 单独缓存RoPE结果
压缩维度的权衡
压缩维度 = 16:省了2048倍,但表达能力极有限 → 效果崩塌
压缩维度 = 4096(原始维度):退化成标准MHA,无压缩
压缩维度 = 512(MLA选择):
├── 缓存压缩64倍 ✅
├── 512维足够保留主要语义信息 ✅
└── 展开计算开销可接受 ✅
4. DeepSeek-V3
4.1 论文信息
论文名称:DeepSeek-V3 Technical Report
4.2 架构改进:从V2到V3
4.2.1 Sigmoid门控替换Softmax
问题背景:
V2到V3,路由专家从160个增加到256个。
Softmax的饱和问题:
所有专家的分数加起来 = 1
专家越多 → 每个专家平均分数 ≈ 1/256 ≈ 0.004
→ 大家的分数都挤在0.004附近
→ 梯度几乎为0
→ 路由器变得"迟钝",训练极慢
→ 不同专家之间缺乏区分度
Sigmoid的解决:
每个专家独立输出,范围始终是(0, 1)
256个专家和2个专家的分数分布完全一样
→ 区分度完全保留
类比:softmax像全班同学分100分(人越多每人越少),sigmoid像每人单独打分(不受人数影响)。
V3的FFN输出公式(注意变化):
h'_t = u_t + Σ FFN_i^(s)(u_t) + Σ g_{i,t} * FFN_i^(r)(u_t)
g_{i,t} = g'_{i,t} / Σⱼ g'_{j,t} ← 归一化
g'_{i,t} = s_{i,t},如果 s_{i,t} ∈ TopK({s_{j,t}+b_j}, K_r)
g'_{i,t} = 0,否则
s_{i,t} = Sigmoid(u_t^T * e_i) ← 改为sigmoid!
4.2.2 无辅助Loss负载均衡
V1/V2的问题:用辅助Loss来保证负载均衡,但这些Loss会与主Loss互相打架,导致模型效果下降。
V3的解法:直接把辅助Loss扔掉,换成可学习的bias项:
# V3的路由选择:
top_k_selection = gate_score + b_i # b_i 是可学习的偏置项
# 动态调节机制:
# 专家i过载 → 降低b_i → 该专家被选中概率下降
# 专家i空闲 → 提高b_i → 该专家被选中概率上升
# 关键优势:
# b_i只影响"谁被选中",不影响"选中后的计算权重"
# → 不干扰模型的预测能力!
4.2.3 Complementary Sequence-Wise Auxiliary Loss
在无辅助Loss均衡的基础上,额外加一个序列级别的辅助Loss:
L_Bal = α × Σᵢ f_i × P_i
f_i = (N_r / K_r × T) × Σₜ 1(s_{i,t} ∈ TopK({s_{j,t}}, K_r))
P_i = (1/T) × Σₜ s'_{i,t} 其中 s'_{i,t} = s_{i,t} / Σⱼ s_{j,t}
与V2辅助Loss的区别:粒度控制在单条数据(序列级别),比batch级别更细,对模型能力影响更小。
4.2.4 No Token-Dropping
有了bias动态调节 + Sequence-Wise Loss,负载均衡更彻底,Token-Dropping这个"应急措施"可以光荣退休。
V2→V3负载均衡演进:
| 机制 | V2 | V3 |
|---|---|---|
| 专家级辅助Loss | ✅ | ❌(副作用大,删掉) |
| 设备级辅助Loss | ✅ | ❌ |
| 通信平衡Loss | ✅ | ❌ |
| bias动态调节 | ❌ | ✅(无副作用) |
| Sequence-Wise Loss | ❌ | ✅(细粒度补充) |
| Token-Dropping | ✅ | ❌(不再需要) |
4.3 Multi-Token Prediction(MTP)
4.3.1 传统训练的"浪费"
传统语言模型训练:
输入:"今天 天气 很"
预测:"好" ← 每次只预测下一个词
处理完这个样本,模型只学到了一件事:
"今天天气很" 后面跟 "好"
其余信息全部丢弃 ← 浪费!
4.3.2 MTP的思路
MTP训练:
输入:"今天 天气 很"
同时预测:
主模型 → "好" (预测第+1个词)
MTP模块1 → "," (预测第+2个词)
MTP模块2 → "心情" (预测第+3个词)
一个样本,学到三件事 ← 数据利用率提升3倍!
4.3.3 顺序预测 vs 并行预测
其他工作(并行预测):
主模型 → [独立头1] → 预测第+1个词
→ [独立头2] → 预测第+2个词
→ [独立头3] → 预测第+3个词
问题:三个预测互相独立,没有因果关系
DeepSeek-V3(顺序预测):
主模型 → 预测第+1个词"好"
↓ 把"好"的信息传递下去
MTP模块1 → 知道"好"之后,预测第+2个词","
↓ 把","的信息传递下去
MTP模块2 → 知道"好,"之后,预测第+3个词"心情"
每一步预测都建立在前一步的基础上 ← 保持完整因果链
4.3.4 MTP具体实现
第k个MTP模块的输入构造:
h'_i^k = M_k[RMSNorm(h_i^{k-1}); RMSNorm(Emb(t_{i+k}))]
解释:
- RMSNorm(h_i^{k-1}):上一层传下来的隐藏状态
- RMSNorm(Emb(t_{i+k})):当前位置+k的词嵌入(告诉模块"上一步预测了什么")
- 两者拼接后,经过一个Transformer Block继续处理
每个MTP模块的训练目标:
L_MTP^k = CrossEntropy(P_{2+k:T+1}^k, t_{2+k:T+1})
= -(1/T) × Σ log P_i^k[t_i]
最终综合MTP目标:
L_MTP = (λ/D) × Σₖ L_MTP^k
其中λ是权重系数,D是预测深度
4.3.5 MTP的双重价值
价值1:训练信号密度提升
传统:1个样本 → 1个loss
MTP: 1个样本 → D个loss
→ 相同数据量,模型学到更多
价值2:迫使模型"提前规划"
要准确预测第+3个词,模型必须在表示第+1个词时
就已经"想好"后面要说什么
→ 表示质量显著提升
→ 对代码、数学这类需要"想好再说"的任务帮助最大
4.3.6 推理时的投机解码
训练时MTP学会预测多个词,推理时可以利用MTP做投机解码(Speculative Decoding),加速推理。
投机解码流程:
步骤1:MTP模块(轻量草稿器)快速猜测接下来4个词
[今天天气很好,我]
步骤2:主模型并行验证所有猜测
"好" ✅ "," ✅ "我" ❌(应该是"心情")
步骤3:接受正确前缀"好,",只重算"心情"
效率:原本需要3次完整前向传播,现在只需1次!
MTP模块为什么特别适合做猜测器?
优势1:训练时顺带训好,零额外成本 ✅
优势2:共享主模型的嵌入层和输出头,和主模型说"同一种语言",猜对率高 ✅
优势3:只有一个Transformer Block,极为轻量,猜测速度快 ✅
5. DeepSeek-R1
5.1 论文信息
论文名称:DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning
核心贡献:证明了无监督的RL就能教会LLM推理——不需要任何SFT标注数据,纯强化学习即可让大模型学会推理。
5.2 整体概览
两个主要模型:
- DeepSeek-R1-Zero:纯RL训练,无需SFT作为前置步骤
- DeepSeek-R1:RL之前结合多阶段训练和冷启动数据,解决Zero的可读性差问题
开源内容:
- DeepSeek-R1-Zero
- DeepSeek-R1
- 基于Qwen和Llama蒸馏的六个Dense模型(1.5B、7B、8B、14B、32B、70B)
5.3 GRPO算法详解
5.3.1 PPO的回顾
PPO是process-reward(token级别)的action,目标函数:
J_PPO(θ) = E[q~P(Q), o~π_θ_old(O|q)]
(1/|o|) × Σₜ [min(π_θ(oₜ|q,o<t)/π_θ_old(oₜ|q,o<t) × Aₜ,
clip(π_θ/π_θ_old, 1-ε, 1+ε) × Aₜ)
- β × D_KL(π_θ||π_ref)]
PPO需要的四个模型:
- Policy Model(策略模型):要训练的主角
- Reference Model(参考模型):防止跑偏太远
- Reward Model(奖励模型):打分
- Value Model(价值模型):估计"这个状态值多少分"← 和Policy一样大,显存翻倍!
5.3.2 GRPO的核心创新
去掉了Value Model,用"小组平均分"替代优势值估计:
对于每个问题q,GRPO从旧策略采样G个输出 {o₁, o₂, ..., o_G}
优势值计算:
A_i = (r_i - mean({r₁,...,r_G})) / std({r₁,...,r_G})
解读:
比小组平均好 → 正优势 → 加强这种输出
比小组平均差 → 负优势 → 抑制这种输出
不需要Value Model估计"绝对价值"
只需要组内相对比较!
GRPO目标函数:
J_GRPO(θ) = E[q~P(Q), {oᵢ}ᵢ₌₁^G ~ π_θ_old(O|q)]
(1/G) × Σᵢ [min(π_θ(oᵢ|q)/π_θ_old(oᵢ|q) × Aᵢ,
clip(π_θ/π_θ_old, 1-ε, 1+ε) × Aᵢ)
- β × D_KL(π_θ||π_ref)]
5.3.3 PPO vs GRPO的λ参数
λ的含义:控制未来奖励的折扣程度
λ=0:只看当前步,完全忽略未来
λ=1:把所有步的奖励都加起来,不折扣
为什么语言模型RL中λ=1比λ=0.95更好?
语言生成的特殊性:整个输出完成后才能判断好坏,奖励无法归因到某个具体token。
λ=0.95时(大多数开源实现的默认值):
token_10: 1.0
token_9: 0.95
...
token_1: 0.63 ← 第一个token只分到63%!
问题:前几个token的梯度信号被人为削弱
但"今天天气"这几个token对整个句子质量同样重要!
→ 训练信号不均衡 → 模型学得歪
λ=1.0时:
token_1到token_10:全部 = 1.0
每个token平等地学习 ✅
实验结论:
- PPO(λ=0.95):表现明显差于GRPO
- PPO(λ=1.0):性能接近GRPO水平
- GRPO:最稳定,性能最好
5.3.4 KL散度的近似估计
为什么需要近似?
原有KL计算包含期望,需要实时采样,计算复杂度高,且数值不稳定。
近似公式(来自《Approximating KL Divergence》):
D_KL[π_θ||π_ref] ≈ π_ref/π_θ - log(π_ref/π_θ) - 1
优势:
- 只需计算当前策略和参考策略的概率比值
- 不需要计算KL散度的积分或期望
- 计算复杂度显著降低
直觉:
- 当π_θ ≈ π_ref时:π_ref/π_θ ≈ 1,log(π_ref/π_θ) ≈ 0,近似值 ≈ 0 ✅
- 当π_θ ≠ π_ref时:近似值给出较大正值,反映差异 ✅
5.4 DeepSeek-R1-Zero
5.4.1 基座模型
DeepSeek-V3-Base
5.4.2 基于规则的奖励系统
为什么不用神经网络奖励模型(Reward Model)?
Reward Hacking(奖励过度利用)的危险:
训练后期,模型发现RM的"弱点":
输出超长的、听起来很有道理的废话
→ RM被"忽悠",打出0.95的高分
→ 但答案其实是错的!
现实证明(论文图6):
Reward分数:持续上升 📈
CodeForces实际表现:持续下降 📉
← 模型在"刷分"而不是"真的变强"
两种基于规则的奖励:
def accuracy_reward(response, ground_truth):
"""
数学题:提取\boxed{}里的答案,和标准答案比较
代码题:直接跑编译器,看测试用例通不通
答案对就是对,错就是错
模型无法忽悠这个评委
"""
if extract_answer(response) == ground_truth:
return 1.0
return 0.0
def format_reward(response):
"""
检查思维过程是否在<think></think>标签里
纯字符串匹配,无法被破解
"""
if "<think>" in response and "</think>" in response:
return 1.0
return 0.0
# 最终奖励:两者直接相加
total_reward = accuracy_reward + format_reward
5.4.3 训练模板
A conversation between User and Assistant.
The assistant first thinks about the reasoning process
and then provides the user with the answer.
The reasoning process and answer are enclosed within
<think></think> and <answer></answer> tags.
User: {prompt}. Assistant:
模板统一,不针对特定问题调整,避免内容偏差。
5.4.4 训练超参数(升级版报告详细版)
学习率:3e-6
KL系数:0.001
采样温度:1.0
Group size:16
最大输出长度:
前8200步:32,768 tokens
8200步后:65,536 tokens ← 长度跃升!
Batch size:32题 × 16样本 = 512
参考模型更新:每400步替换一次
总训练步数:10,400步(约1.6个epoch)
8200步的长度跃升现象:
0~8200步:性能缓慢提升,输出长度缓慢增长
8200步时:性能突然显著跳升!输出长度同时跳升!
解释:
模型突破了某个"能力阈值"
开始真正理解"想得更深=答得更好"
主动申请更长的思考空间
→ 8200步后把最大长度从32K扩展到64K
给模型更大的思考空间
每400步替换参考模型的原因:
固定参考模型的问题:
训练后期π_θ已经进化很多
KL越来越大 → KL惩罚越来越重
→ 模型被死死锁住,无法继续进步!
动态参考模型:
参考模型跟着策略模型一起进化
KL始终在可控范围内
→ 模型可以持续进步
5.4.5 R1-Zero的涌现行为
Self-Evolution自我进化:
训练初期(step 0~2000):
<think>1+1=2</think>
<answer>2</answer>
(思考过程很短,直接输出)
训练中期(step 2000~6000):
<think>
Let me compute... 1+1=2
Wait, let me verify this again... ← 自发出现验证行为!
Yes, 1+1=2, confirmed.
</think>
训练后期(step 6000~8000):
<think>
Let me try approach A... 得出结论X
Wait, wait. Wait. That's an aha moment. ← 真实出现在论文里!
Let me re-evaluate using approach B...
</think>
三个未被明确编程的涌现行为:
- 反思行为:重新审视和重新评估先前步骤
- 验证行为:主动检查答案正确性
- 替代探索:自发探索解决问题的替代方法
Aha Moment(顿悟时刻):
模型学习通过重新评估初始方法来为问题分配更多思考时间
这体现了强化学习的power and beauty:
通过简单提供正确的奖励,大模型会自己找到更优的问题解决策略
并不需要明确教模型如何解决问题
R1-Zero的缺点:
- 可读性差:思维过程混乱
- 语言混合:中文问题可能用英文思考
5.4.6 R1-Zero性能数据
| 模型 | AIME 2024 pass@1 | AIME 2024 cons@64 | MATH-500 | GPQA Diamond | CodeForces rating |
|---|---|---|---|---|---|
| OpenAI-o1-mini | 63.6 | 80.0 | 90.0 | 60.0 | 1820 |
| OpenAI-o1-0912 | 74.4 | 83.3 | 94.8 | 77.3 | 1843 |
| DeepSeek-R1-Zero | 71.0 | 86.7 | 95.9 | 73.3 | 1444 |
5.5 DeepSeek-R1
5.5.1 四阶段训练流水线
基础模型:DeepSeek-V3-Base
↓
阶段1:冷启动 SFT(几千条长CoT数据)
目标:学会格式、语言一致、训练稳定
输出:R1-ColdStart 模型
↓
阶段2:面向推理的 RL
奖励:准确率奖励 + 格式奖励 + 语言一致奖励
目标:强化推理能力,延长思考链
输出:R1-Reasoning 模型
↓
阶段3:拒绝采样 + SFT
数据:600K推理数据 + 200K通用数据
目标:补充通用能力(写作、问答、翻译)
输出:R1-SFT 模型
↓
阶段4:全场景 RL
奖励:规则奖励(推理)+ 奖励模型(通用)
目标:Helpfulness + Harmlessness
输出:DeepSeek-R1 ✅
5.5.2 阶段1:冷启动SFT
为什么要冷启动?
纯RL从零开始(没有冷启动)= 冬天冷车直接猛踩油门
症状:
├── 早期输出完全混乱,奖励信号极其稀疏
├── 语言混合:中文问题→英文思考→中文回答
└── 格式混乱:推理过程和答案混在一起
先SFT冷启动再RL = 先热车,让引擎进入工作温度
解决:
├── ✅ 格式稳定:学会<think>...</think>结构
├── ✅ 语言一致:中文问题→中文思考→中文回答
└── ✅ 训练稳定:有合理初始策略,梯度更有方向感
冷启动数据收集方法:
- Few-shot prompt(少样本提示)
- 直接prompt with reflection和verification
- 人类后处理DeepSeek-R1-Zero的输出
冷启动数据格式:
|special_token|<reasoning_process>|special_token|<summary>
每个回答末尾包含总结
过滤掉对读者不友好的回答
5.5.3 阶段2:面向推理的RL
在冷启动模型基础上进行RL训练,RL框架与R1-Zero相同(GRPO)。
引入语言一致性奖励:
Reward_language = Num(Words_target) / Num(Words)
← 计算思维链中目标语言单词的比例
代价:准确率略微下降
原因:语言一致性目标和推理准确性有时冲突
但:更符合人类偏好,提高内容可读性
综合奖励 = 准确率奖励 + 语言一致性奖励(直接相加)
阶段2超参数:
学习率:3×10⁻⁶
KL系数:0.001
GRPO clip ratio ε = 10(注意:比通常的0.2大很多!)
采样温度:1.0
每问题采样:16个输出,最大长度32768
批次大小:32个独立问题,总batch=512
每400步更新参考模型
5.5.4 阶段3:拒绝采样与SFT
拒绝采样(Rejection Sampling)的核心逻辑:
def rejection_sampling(prompt, model, n_samples=16):
"""对同一个问题,采样多个回答,只保留正确的那些"""
responses = [model.generate(prompt) for _ in range(n_samples)]
correct_responses = [
r for r in responses
if verify(r) == True # 答案正确
and no_language_mixing(r) # 没有语言混合
and not too_long(r) # 没有无意义的重复
]
return correct_responses
# 效果:
# 600K 推理数据:全部是模型能做对的题
# 训练信号极其干净
数据构成:
- 推理数据:600K(设计推理prompt + 拒绝采样 + judge model验证)
- 非推理数据:200K(写作、事实问答、翻译等,复用DeepSeek-V3 SFT数据)
- 总量:800K,训练2个epoch
5.5.5 阶段4:全场景RL
综合奖励公式:
Reward = Reward_reasoning + Reward_general + Reward_language
其中:
Reward_reasoning = Reward_rule(基于规则,数学/代码/逻辑推理)
Reward_general =
Reward_helpful (若属于有用性数据集)
Reward_safety (若属于安全性数据集)
关键工程细节:
Stage4只有1700步训练
最后400步才引入通用指令数据和偏好奖励!
原因:
前1300步:只用推理数据和规则奖励
→ 打稳推理能力基础
→ 规则奖励不会导致Reward Hacking
后400步:引入偏好奖励
→ 时间很短,偏好信号来不及被过度利用
→ 避免Reward Hacking!
阶段4超参数:
学习率:3×10⁻⁶
KL系数:0.001
采样温度:0.7(比阶段2的1.0更低,输出更稳定)
批次大小:512
每400步更新参考模型
5.6 奖励模型训练(升级版报告)
5.6.1 Helpful RM(有用性奖励模型)
数据构建:
- 规模:66,000对偏好数据
- 方法:Pairwise(成对比较)
- 生成方式:用Arena-Hard格式,DeepSeek-V3独立查询4次打平均分
- 随机交换A/B位置:防止位置偏见
- 只保留分数差异Δ>1的样本:确保差异显著
- 控制长度偏差:防止模型学到"长=好"
为什么用成对比较?
有用性是主观的,人人打分基准不同
"这个回答有多有帮助?"
标注者A:"3分,有点啰嗦"
标注者B:"5分,很详细"
换成"A和B哪个更好?"
标注者A:"B更好"
标注者B:"B更好"
相对判断消除了主观基准差异 ✅
模型架构:
基础模型:DeepSeek-R1
额外组件:顶层加奖励头(Reward Head),输出标量偏好分数
公式:Reward_helpful = RM_helpful(ResponseA, ResponseB)
超参数:
- Batch size:256
- 学习率:6e-6
- 训练轮数:1轮
- 最大序列长度:8192 tokens(训练时),推理时无限制
- 评估重点:只看最终总结,不干扰推理过程
5.6.2 Safety RM(安全性奖励模型)
数据构建:
- 规模:106,000条标注数据
- 方法:Point-wise(单独打分)
- 直接标注"安全"或"不安全",依据预定义安全准则
为什么用单独打分?
安全性是客观的,标准一致
"这个回答安全吗?"
标注者A:"不安全,包含有害信息"
标注者B:"不安全,包含有害信息"
标注者C:"不安全,包含有害信息"
大家对"是否安全"容易达成共识
直接点对点打标签更高效 ✅
模型架构:
- 基础模型:DeepSeek-R1
- 训练目标:CrossEntropy二分类
- 评估范围:整个response(包括推理过程)
5.7 蒸馏:赋予小模型推理能力
5.7.1 蒸馏方法
直接对Qwen和Llama等开源模型进行SFT
使用的是R1生成的800K条数据
基础模型:
Qwen2.5-Math-1.5B、Qwen2.5-Math-7B、Qwen2.5-14B、
Qwen2.5-32B、Llama-3.1-8B、Llama-3.3-70B-Instruct
5.7.2 为什么蒸馏比小模型直接RL更好?
小模型直接RL的困境:
奖励稀疏问题:
7B模型能力有限
面对难题:16次采样 → 全部错误 → 奖励全是0
→ 优势值 A_i = (0-0)/std(0) = 无意义
→ 梯度为零,模型无法更新!
蒸馏的优势:
大模型R1的输出包含完整推理链:
<think>
这道题需要用反证法...
假设√2是有理数,设√2 = p/q...
...(完整推理过程)
</think>
小模型直接学这个完整推理链:
→ 不需要自己探索
→ 直接学会"反证法"这种推理模式
→ 学习的不只是最终答案,而是每一步token的概率分布
→ 这就是"隐层含义信息"被传递
数字对比(AIME 2024,Pass@1):
| 模型 | 得分 |
|---|---|
| GPT-4o | 9.3 |
| Claude-3.5-Sonnet | 16.0 |
| QwQ-32B-Preview | 50.0(320亿参数) |
| DeepSeek-R1-Distill-Qwen-7B | 55.5(只有70亿参数!) |
| DeepSeek-R1-Distill-Qwen-32B | 72.6 |
蒸馏的上限:蒸馏只能复制大模型已有的能力,不能超越。突破智能边界仍需更强基础模型和更大规模RL。
5.7.3 蒸馏vs直接RL的总结
蒸馏:快速低成本复制已有能力
小学生照着教授的解题步骤学(方案B)
直接RL:探索超越已有能力的边界
小学生自己摸索(方案A)
两者不对立:
蒸馏 = 让小模型站在大模型肩膀上
RL = 让大模型突破自身边界
5.8 整体Benchmark测试结果
| 模型 | AIME 2024 | Codeforces | GPQA Diamond | MATH-500 | MMLU | SWE-bench |
|---|---|---|---|---|---|---|
| OpenAI-o1-1217 | 79.2 | 96.6 | 75.7 | 96.4 | 91.8 | 48.9 |
| DeepSeek-R1 | 79.8 | 96.3 | 71.5 | 97.3 | 90.8 | 49.2 |
| DeepSeek-V3 | 39.2 | 58.7 | 59.1 | 90.0 | 88.5 | 42.0 |
DeepSeek-R1在推理任务上实现了与OpenAI-o1-1217相当的性能。
6. DeepSeek-Prover-V2
6.1 形式化定理证明的挑战
普通数学题 vs 形式化证明的核心区别:
普通数学题(自然语言):
答案:"大概正确"就能得分
"显然可得..." ← 人类接受这种跳跃
形式化证明(Lean 4语言):
每一步都必须有严格依据
计算机自动验证:一个符号错误 = 整个证明无效!
"显然a+b=b+a"
→ 需要引用交换律定理
→ 需要指定在哪个代数结构上
→ 需要验证类型匹配
搜索空间爆炸问题:
每步有数百种可能的证明策略
一个证明可能需要数百步
总搜索空间 ≈ 100^100 ← 天文数字
6.2 核心技术:子目标分解流水线
核心思路:把一个不可能的大问题,分解成多个可能的小问题。
分工模式:
DeepSeek-V3(大模型):架构师
→ 理解定理高层结构
→ 分解成合理的子目标(含sorry占位符)
→ 生成证明骨架
DeepSeek-Prover-V2-7B(小专家模型):工程师
→ 针对简单子目标快速生成策略
→ 反复尝试不同战术组合
→ 速度快,可以大量采样
Lean 4证明骨架示例:
theorem induction_ineq (n : ℕ) (h₀ : 4 ≤ n) : n^2 ≤ n! := by
have base_case : 4^2 ≤ 4! := by
simp [Nat.factorial] -- 子目标1:直接计算验证
have inductive_step : ∀ k ≥ 4, k^2 ≤ k! → (k+1)^2 ≤ (k+1)! := by
intro k h₁ h₂
simp_all [Nat.factorial]
nlinarith -- 子目标2:数学推导
-- 子目标3:组合(等待小模型填充sorry)
sorry
效果:
原始定理搜索空间:100^100
每个子目标搜索空间:约100^10
难度指数级下降!
6.3 冷启动数据生成
完整流程:
步骤1:V3生成含sorry占位符的Lean代码(证明骨架)
步骤2:7B专家模型递归解决每个子目标
步骤3:合成完整证明(子证明组合回骨架)
步骤4:Lean编译器验证(通过=成功,失败=重试)
关键:一旦子目标被解决,合成为连贯的思维链数据,用于后续训练。
6.4 课程学习策略
朴素方案(随机顺序)的问题:
模型第一天就遇到费马大定理级别的难题
→ 奖励全是0 → 和小模型RL困境一样
→ 梯度消失,学不到东西
课程学习(由易到难):
第一阶段:喂简单引理
→ 模型频繁得到正奖励,快速建立基础策略
第二阶段:喂中等难度定理
→ 建立在简单引理之上,命中率仍然合理
第三阶段:喂复杂定理
→ 此时模型已有足够基础,能把复杂定理分解成已掌握的子目标
难度评估的天然来源:
def estimate_difficulty(theorem):
subgoals = decompose(theorem) # V3生成的骨架
difficulty = {
'breadth': len(subgoals), # 子目标数量
'depth': max_nesting(subgoals), # 嵌套深度
'leaf_complexity': avg_leaf_size() # 每个子目标的复杂度
}
return weighted_sum(difficulty)
6.5 一致性奖励
强制使用子目标结构的原因:
如果允许跳过子目标直接证明:
模型学到的是"找捷径",而不是"结构化推理"
遇到更难的定理时,无法分解
泛化能力崩塌
你说的"逻辑信息被压缩":
跳过子目标 = 把多步推理压缩成一步
→ 模型内部表示变得不透明
→ 无法处理更复杂的情况
一致性奖励:
如果最终证明漏掉了V3分解出来的have语句
→ 给予惩罚
→ 促使模型保留并使用所有子目标
6.6 no-CoT与CoT两阶段训练
两种推理模式:
| 模式 | 特点 | 适用场景 |
|---|---|---|
| no-CoT | 直接输出Lean代码,无中间推理 | 简单定理,速度优先 |
| CoT | 自然语言分析 → Lean代码 | 复杂定理,准确率优先 |
性能对比(miniF2F,Pass@8192):
| 规模 | no-CoT | CoT |
|---|---|---|
| 7B | 75.0% | 82.0%(+7%) |
| 671B | 78.3% | 88.9%(+10.6%) |
结论:越难的定理,CoT的优势越大;大模型从CoT中获益更多。
6.7 性能对比
miniF2F测试集(Pass@8192):
| 方法 | 通过率 |
|---|---|
| Hypertree Proof Search | 41.0% |
| Goedel-Prover-SFT | 64.7% |
| STP | 67.6% |
| Kimina-Prover | 80.7% |
| DeepSeek-Prover-V2 671B | 88.9% SOTA! |
PutnamBench(大学竞赛级别):
- DeepSeek-Prover-V2:解决 49/658 题
- 此前最佳:约10题
- 提升:接近5倍!
7. DeepSeek-V3.2
7.1 论文信息
论文名称:DeepSeek-V3.2-Exp: Boosting Long-Context Efficiency with DeepSeek Sparse Attention
7.2 架构创新
相比V3,V3.2新增两个组件:
V3:MLA(Multi-Head Latent Attention)
V3.2:MLA + MQA + DSA
MQA = Multi-Query Attention(多查询注意力)
DSA = DeepSeek Sparse Attention(稀疏注意力)
7.3 MQA(Multi-Query Attention)
注意力家族对比:
| 类型 | Q头 | K头 | V头 | 压缩程度 |
|---|---|---|---|---|
| MHA(标准) | 128个 | 128个 | 128个 | 无压缩 |
| GQA(V1用) | 128个 | 8个 | 8个 | 16倍压缩 |
| MQA(V3.2) | 128个 | 1个! | 1个! | 极致压缩 |
# MQA的注意力计算:
Q = input @ W_Q # [batch, seq, n_heads, head_dim](每头独立)
K = input @ W_K # [batch, seq, 1, head_dim](只有1个头!)
V = input @ W_V # [batch, seq, 1, head_dim]
# 计算时:K、V广播到所有Q头
scores = Q @ K.transpose(-2, -1) # 广播操作
output = softmax(scores) @ V
实际工程细节:
论文设计:
训练阶段用MHA(保证训练质量)
推理阶段用MQA(节省显存)
切换方式:把MHA的多个K头通过"均值池化"合并成1个
但实际发布的V3.2-Exp模型:
inference代码显示 num_key_value_heads = 128
→ 实际上还是MHA!
→ MQA只是理论设计,工程实现还在探索中
7.4 DSA(DeepSeek Sparse Attention)
核心思路:不对所有历史位置做完整注意力,只挑选最相关的Top-2000个位置。
速度对比:
序列长度:100K tokens
完整注意力:100K × 100K = 100亿次运算
DSA:
Lightning Indexer粗筛:100K × 低维 ← 便宜!
完整注意力:只算2000个位置
节省:省了98%的注意力计算!
7.4.1 Lightning Indexer:快速找到相关位置
解决"先有鸡还是先有蛋"的悖论:
悖论:
要找出最相关的2000个位置
需要先和所有位置计算相似度
但这本身就是完整注意力!
解决方案:用两个不同精度的操作分工
Lightning Indexer(粗糙但快):
低维、低精度(FP8)、ReLU激活
→ 快速给所有位置打分
完整注意力(精确但慢):
只对Top-2000个位置精确计算
→ 不需要覆盖所有位置
Lightning Indexer的核心设计:
def lightning_indexer(query_token, all_history):
# 关键1:低维向量(比完整QK便宜100倍)
q_index = query_token @ W_q_index # 降维到很小
k_index = all_history @ W_k_index
# 关键2:ReLU代替softmax
# ReLU:每个位置独立打分,不需要看其他位置(快!)
# softmax:需要看完所有位置才能归一化(慢)
scores = ReLU(q_index @ k_index.T)
# 关键3:FP8低精度运算(牺牲精度换速度)
# (实际实现中使用FP8量化)
return scores # 粗糙但够用的相关性估计
# 然后:
top_2000_positions = scores.topk(2000)
# 最后:
final_output = full_attention(query, top_2000_positions)
DSA完整流程:
输入序列:[t1, t2, ... t100K]
当前位置:t_i
Lightning Indexer(便宜)→ 给每个位置打分
↓
Top-K Selection → 选出分数最高的2000个位置
↓
完整注意力(只算2000个)→ 精确的注意力输出
7.4.2 精度损失分析
实际损失有多大?
关键观察:注意力分布本身就是稀疏的!
大多数位置的注意力权重趋近于零
丢掉它们 ≈ 丢掉0.049的信息
保留Top-2000 ≈ 保留了95%以上的有效信息
RULER基准测试(专门测长上下文能力):
完整注意力(基准线):100%
DSA(Top-2000):约98%
2%的损失对大多数任务可以接受
最危险的场景:
"大海捞针"任务:
100K token文章里藏着一句关键信息
Lightning Indexer可能打分偏低
被排在Top-2000之外 → 永远看不到!
→ 直接影响答案正确性
DeepSeek的工程兜底:
for layer_id in range(total_layers):
if layer_id in sparse_layers:
output = dsa_attention(x, top_k=2000) # 省计算,轻微损失精度
else:
output = full_attention(x) # 保证精度
# 混合使用,在速度和精度之间找平衡
7.5 Cache-Compute Ratio 指标
定义:GB/PFLOP = 每做1PFLOP计算,需要读多少GB的KV-Cache
GB/PFLOP越大 → 越I/O-bound(存储是瓶颈)
GB/PFLOP越小 → 越compute-bound(计算是瓶颈)
各模型对比(16K-64K上下文):
| 模型 | GB/PFLOP | 说明 |
|---|---|---|
| Qwen2.5-32B (FP16) | 117-267 | 传统GQA,KV-Cache最大 |
| GPT-OSS-120B | 47-95 | 无特殊KV优化 |
| Qwen3-235B-A22B | 39-60 | MoE减少计算量 |
| DeepSeek-V3.2 660B | 13-36 | MLA+DSA,计算减少更多 |
| DeepSeek-V3 660B | 4.8-5.8 | MLA最优 |
为什么V3.2比V3的比值更大?
V3.2加入DSA,计算量大幅减少:
分子(计算量)↓↓
分母(KV-Cache大小)不变
→ GB/PFLOP = 分母/分子 ↑↑
这说明:V3.2计算变少,但I/O相对更重要了
→ 更需要DualPath这样的I/O优化!
7.6 两阶段继续预训练
从DeepSeek-V3.1-Terminus 128K长上下文base ckpt冷启动。
阶段1:密集预热(Dense Warm-up Stage)
目标:初始化Lightning Indexer
方法:保持密集注意力,冻结除Indexer外的所有参数
为什么要冻结主模型?
如果全部一起训练:
主模型每天都在变化
Indexer追不上 → 目录索引永远无效
冻结主模型:
书的位置固定 → 专心建立目录 ✅
损失函数:KL散度对齐
L^I = Σₛ p_{t,s} × log(p_{t,s}/q_{t,s})
p_{t,s}:主注意力的L1归一化分布(老师)
q_{t,s}:Indexer输出的分布(学生)
超参数:
学习率:10⁻³
训练步数:1000步
数据量:2.1B tokens
阶段2:稀疏训练(Sparse Training Stage)
目标:让整个模型适应稀疏注意力
方法:解耦Indexer与主模型的梯度传播
Indexer:只通过L^I优化(继续对齐注意力分布)
主模型:通过语言建模Loss优化(学会稀疏注意力下生成好文本)
为什么要解耦?
两个目标方向可能冲突
解耦后各自优化各自目标,不互相干扰
超参数:
学习率:7.3×10⁻⁶
训练步数:15,000步(是阶段1的15倍!)
数据量:943.7B tokens(是阶段1的450倍)
7.7 后训练
专家蒸馏(Specialist Distillation)
构建5个领域专家模型:数学、编程、逻辑推理等
两种数据生成模式:
thinking mode(长链推理):复杂任务
non-thinking mode(直接响应):简单任务
优势:
专家模型数据质量 >> 通用模型数据质量
模型学会根据任务难度自动选择推理深度
混合强化学习训练(Mixed RL Training)
算法:GRPO
创新:单阶段RL
推理任务 + 代理任务 + 人类对齐 → 同时训练
避免多阶段训练中的灾难性遗忘问题
奖励设计:
代码/数学任务 → 基于规则的奖励
通用任务 → 生成式奖励模型
平衡机制:长度-准确率、语言一致性-准确率
8. DualPath
8.1 论文信息
论文名称:DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference 核心结论:离线推理加速1.87×,在线服务吞吐提升1.96×(实际测试2.25×)
8.2 背景:Prefill和Decode的本质区别
| 阶段 | 做什么 | 硬件特点 | 瓶颈 |
|---|---|---|---|
| Prefill | 一次性处理整段prompt | 计算密集:大量矩阵乘法 | GPU算力 |
| Decode | 逐个生成新token | 访存密集:大量读取KV-Cache | 显存带宽 |
PD分离的必要性:
同一块GPU上的问题:
Prefill的大计算量抢占Decode的内存带宽
Decode的频繁小读取打断Prefill的连续计算
→ 两个阶段都变慢
PD分离:
专门的PE(Prefill Engine):多核高算力GPU
专门的DE(Decode Engine):高带宽显存GPU
各司其职,互不干扰 ✅
8.3 Agent场景的I/O瓶颈
为什么Agent推理这么吃存储带宽?
传统对话 vs Agent:
传统对话:几轮,上下文几K tokens
Agent场景(coding助手):
第1轮:500 tokens
第2轮:800 tokens
...
第157轮:32,700 tokens!(滚雪球式增长)
关键数据(DeepSeek生产环境coding任务):
平均交互轮数:157轮
平均上下文长度:32.7K tokens
平均每轮新增:429 tokens
KV-Cache命中率:98.7%!
98.7%命中率的含义:
32K token的上下文中:
98.7%(32,271个):之前已经算过,存在外部存储,只需读出来
1.3%(429个):新token,需要GPU计算
→ 几乎所有时间都花在从存储读旧数据
→ 系统从compute-bound变成I/O-bound!
8.4 带宽失衡问题
PD分离架构下的不均衡:
PE节点的SNIC(存储网卡):
一直在疯狂读取KV-Cache
利用率:100% ← 打满,成为瓶颈!
DE节点的SNIC:
完全空闲
利用率:0% ← 在睡觉!
原因:传统设计里只有PE需要从存储读KV-Cache
DE的KV-Cache是PE通过RDMA传过来的
DE根本不需要碰存储
硬件趋势三重挤压:
从Ampere到Blackwell:
GPU算力(FLOPS):翻了14倍多
NIC带宽:只翻了2倍
HBM容量:缓慢增长
I/O-Compute Ratio下降了14.4倍!
问题只会越来越严重
8.5 DualPath的核心思路:带宽池化
传统只有一条路(PE Read Path):
存储 ──SNIC──→ PE DRAM ──H2D──→ PE HBM → 计算
DualPath新增第二条路(DE Read Path):
存储 ──SNIC──→ DE DRAM ──RDMA/CNIC──→ PE HBM → 计算
DE的SNIC原本在睡觉,现在被利用起来!
效果:全集群存储带宽被池化
带宽提升示例(1台PE配4台DE):
传统:1 × 400Gbps = 400Gbps
DualPath:5 × 400Gbps = 2000Gbps ← 5倍!
8.6 两条路径的详细数据流
PE Read Path(传统路径优化)
步骤1:存储 → PE DRAM
KV-Cache通过PE的SNIC读到PE的主机内存
步骤2:PE DRAM → PE HBM(逐层,与计算重叠)
每次只搬一层的KV-Cache
搬完立刻开始该层Prefill计算
GPU在算第L层的同时,CNIC在搬第L+1层
步骤3:PE HBM → DE DRAM
Prefill完成后,完整KV-Cache通过RDMA传给DE
步骤4:DE DRAM → DE HBM
DE开始自回归Decode
Layerwise Prefill的收益:
传统方案:
必须把所有60层KV-Cache全部塞进HBM才能开始
= 6GB占用(假设每层100MB)
→ batch size被迫很小 → GPU利用率低
逐层流水:
每次只持有当前层的KV-Cache(100MB)
算完立刻释放
→ HBM占用从6GB降到100MB
→ batch size可以扩大60倍!
→ GPU利用率大幅提升
DE Read Path(DualPath新增的路径)
步骤1:存储 → DE DRAM
KV-Cache通过DE节点的SNIC读到DE的内存
← 这条网卡原本完全空闲!
步骤2:DE DRAM → PE HBM(逐层,与计算重叠)
通过RDMA(计算网络CNIC)逐层传输到PE的GPU显存
步骤3:PE传回miss tokens
PE只需计算新增的429个token的KV(miss tokens)
把结果传回DE Buffer,与已有的hit tokens合并
步骤4:DE DRAM → DE HBM
Decode阶段直接从DE Buffer加载到HBM
DE Path的关键优势:
PE的DRAM完全不参与KV-Cache搬运!
→ PE DRAM压力清零
8.7 流量隔离:Virtual Lane机制
核心问题:
KV-Cache传输需要走计算网络(CNIC)
但CNIC原本是给推理通信用的(AllToAll、ReduceScatter)
两种流量混在一起,会不会互相干扰?
为什么不用PCIe直连?
PCIe没有QoS(服务质量)机制!
所有流量无差别竞争带宽,先到先得
→ KV-Cache传输可能堵住推理通信
→ 推理延迟爆炸
CNIC-Centric设计:
所有进出GPU的数据都必须经过CNIC!
即使是本机DRAM → GPU HBM,也走CNIC的RDMA Write绕一圈
为什么绕路更好?
CNIC是网卡,原生支持QoS
网卡硬件队列可以区分不同优先级的流量
PCIe做不到这一点
意外好处:
RDMA Write提交延迟:~1μs(用户态mmio)
cudaMemcpyAsync提交延迟:5-7μs(需CUDA驱动栈)
Layerwise Prefill需要提交数千次 → CNIC方案反而更快!
Virtual Lane流量隔离:
| 流量类型 | VL优先级 | 带宽分配 | 类比 |
|---|---|---|---|
| 推理通信(AllToAll等) | 高优先级 | ~99% | 应急车道,优先通行 |
| KV-Cache传输 | 低优先级 | ~1%(防饿死) | 普通车道,见缝插针 |
调度算法:加权轮转(Weighted Round Robin)
每发99个推理数据包,插入1个KV-Cache数据包
推理通信是突发性的(burst),两次burst之间网络大量空闲
KV-Cache就在这些空隙里"见缝插针"
← 把原本浪费的带宽利用起来,同时不影响推理延迟
RoCE网络:用DSCP打标 + TC流量分类实现同样效果
8.8 自适应调度器
Inter-Engine调度:PE调度三级优先策略
def schedule_pe(waiting_requests, all_pes):
for request in waiting_requests: # FIFO顺序
# 第一级:排除过载(算力保底)
available_pes = [pe for pe in all_pes if pe.token_count <= β]
# 第二级:优先选磁盘队列短的PE(存储带宽最大化)
# 磁盘队列短 = SNIC快要空闲 = 立刻塞请求保持满载
short_queue_pes = [pe for pe in available_pes if pe.disk_queue <= α]
# 第三级:同级别内选token数最少的(算力均衡)
if short_queue_pes:
chosen = min(short_queue_pes, key=lambda pe: pe.token_count)
elif available_pes:
chosen = min(available_pes, key=lambda pe: pe.token_count)
else:
break # 所有PE都过载,等下一轮
assign(request, chosen)
为什么磁盘队列优先于token数?
在Agent场景:
GPU大部分时间在等存储(98.7%的时间是I/O操作)
存储带宽是真正的瓶颈
优化算力 → 收益2%
优化存储带宽 → 收益98%
当然优先保证存储带宽满载!
路径选择:
比较PE和DE两侧的磁盘读取队列长度
选更短的一侧读取
→ 哪边空闲就让哪边来读
→ 动态负载均衡
DE调度两级:
跨组调度:将请求分配到总token数最小的DE group(平衡组间负载)
组内调度:设定高token阈值Z = 1.05×avg(比组内平均高5%)
优先选低于阈值且HBM剩余充足的DE
8.9 Compute Quota:消除GPU气泡
GPU气泡的成因:
Expert Parallel(专家并行)模式下:
多块GPU各自负责不同的请求做attention计算
但必须同步进入FFN层
GPU_A:3个短请求,50ms完成 → 等待250ms 💤
GPU_B:1个超长请求,300ms完成
GPU_C:2个中等请求,150ms完成 → 等待150ms 💤
GPU_A浪费83%,GPU_C浪费50%!
Compute Quota解法:
def build_batch_with_quota(waiting_requests, quota=300ms):
batch = []
total_estimated_time = 0
for request in waiting_requests:
estimated_time = predict_attention_time(
cached_tokens=request.hit_count,
miss_tokens=request.miss_count
) # 基于离线profiling拟合的性能模型
if total_estimated_time + estimated_time <= quota:
batch.append(request)
total_estimated_time += estimated_time
else:
# 超限!用二分搜索找合适的chunk size
chunk_size = binary_search_chunk(
request,
remaining_quota=quota - total_estimated_time
)
# Chunked Prefill:只处理前chunk_size个token
batch.append(request.chunk(chunk_size))
break
return batch
效果: 同一EP组内各GPU的attention计算时间被控制在差不多的范围内,GPU气泡从83%降到接近0%。
8.10 P/D比例安全空间
数学推导结论:
设定:
P:PE节点数,D:DE节点数
g=8(每节点GPU数),s=1(每节点SNIC数)
B:SNIC带宽,M:DRAM带宽
三个上界约束:
DE CNIC读方向:P/D ≤ (g-2s)/s = 6
DE CNIC写方向:P/D ≤ (g-s)/2s = 3.5
DE DRAM带宽: P/D ≤ (M/Bs-3)/2 = 3.5
下界约束(PE SNIC不空转):
P/D ≥ s/(g-s) = 1/7
最终安全区间:
1/7 ≤ P/D ≤ 3.5
覆盖几乎所有实际生产部署场景!
DeepSeek实际用的2P4D:P/D=0.5,在安全区间内✅
8.11 实验结果
实验环境:
- 集群:DeepSeek内部InfiniBand集群,最大1152块NVIDIA Hopper GPU
- 每台服务器:8块GPU + 8块400Gbps CNIC + 1块400Gbps SNIC
- 存储:3FS(DeepSeek自研分布式文件系统)
- 基准:真实Agent RL训练trace(生产环境coding Agent任务)
消融实验(离线推理,JCT降低):
| 组件 | 平均JCT降低 | 做了什么 |
|---|---|---|
| +Layerwise Prefill | 17.21% | GPU每次只装一层KV-Cache,batch size大增 |
| +Dual-Path Loading | 38.19% | 开辟DE→PE第二条读取路径,池化存储带宽 |
| +Scheduling Algorithm | 45.62% | 智能调度,平衡NIC和GPU负载 |
在线服务性能(DS 660B):
Basic最大吞吐:0.20 Agent/s
DualPath最大吞吐:0.45 Agent/s
提升:2.25倍
TTST和TPOT与Basic基本相当(KV-Cache搬运不影响Decode效率)
TTFT显著降低(存储带宽池化,排队时间大幅减少)
大规模扩展性(24倍扩展):
2P4D(48 GPU)→ 48P96D(1152 GPU):
Agent数从2K增加到48K
JCT几乎不变:3167s → 3201s(仅增1.1%!)
→ 近线性扩展 ✅
调度器CPU占用 < 10核,不是瓶颈
9. DeepSeek Engram
9.1 论文信息
论文名称:Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models 代码:https://github.com/deepseek-ai/Engram
9.2 核心动机:两种子任务的浪费
语言建模的两种本质子任务
| 维度 | 组合推理 | 知识检索 |
|---|---|---|
| 典型任务 | 数学推导、逻辑分析、代码生成 | 识别命名实体、回忆事实、匹配固定短语 |
| 计算特征 | 动态、深度依赖 | 局部、静态、高度模式化 |
| 理想实现 | 多层Attention + FFN | O(1)查表 |
| 当前实现 | MoE条件计算 | 被迫用计算模拟,没有专门机制 |
经典案例:识别实体需要6层网络
识别"Diana, Princess of Wales"(戴安娜王妃):
Layer 1-2:Wales = 英国的一个地方
Layer 3: Wales = 欧洲某个国家
Layer 4: Princess of Wales = 某个王妃头衔(不确定)
Layer 5: = 威尔士亲王之妻
Layer 6: = 戴安娜王妃(1961-1997)← 终于认出!
6层Attention+FFN,只为认出一个众所周知的实体
这些算力本可以用于真正的推理任务
却被浪费在"硬背书"上
Engram不是什么
- 不是RAG:Engram整个过程发生在模型内部,不需要外部文档,不返回原文片段
- 不是KV Cache:KV Cache是当前上下文的运行时状态;Engram查的是预先训练好的静态记忆表
- 不是取代MoE:MoE负责组合推理,Engram负责知识检索,两者互补
9.3 整体架构:查字典的五步流程
第一步:归一化(CompressedTokenizer)
Apple/apple/APPLE → 统一成apple
避免查字典时一个词有三个词条
第二步:提取关键词(N-gram)
把相邻2-3个token组合作为查询词
"Alexander the Great" → 3-gram = (Alexander, the, Great)
第三步:查字典(多头哈希 + 嵌入表)
用哈希函数定位到嵌入表的位置
O(1)直接取出对应的嵌入向量
第四步:判断是否采纳(上下文感知门控)
"apple"在科技文 vs 菜谱含义不同
根据当前语境决定是否采纳记忆
第五步:融合(ShortConv + 残差)
将有用的记忆信息注入Transformer主干
插入位置: 只在第2层和第15层插入Engram(不是每层都插入)
为什么是这两层?
第2层(很早):
在深层计算之前注入静态知识
让后续层不需要浪费算力重建实体
第15层(中间):
补充第2层可能遗漏的知识
覆盖更复杂的实体识别场景
9.4 CompressedTokenizer:词表压缩
为什么词表压缩对查字典很重要?
没有压缩时:
"apple" → ID: 12345
"Apple" → ID: 23456 ← 不同ID!
"APPLE" → ID: 34567 ← 又不同!
同一个实体,查出三份不同结果
浪费空间,增加冲突
压缩后:
全部 → 统一ID: 8701
无论大小写,查到同一份嵌入向量 ✅
NFKC归一化处理内容:
- 全角数字:123 → 123
- 罗马数字:Ⅷ → VIII
- 带重音字母:café → cafe
- 特殊符号变体:统一成基础字符
代码实现:
class CompressedTokenizer:
def __init__(self, tokenizer_name_or_path):
self.normalizer = normalizers.Sequence([
normalizers.NFKC(), # Unicode兼容分解
normalizers.NFD(), # 规范分解
normalizers.StripAccents(), # 去除重音符号
normalizers.Lowercase(), # 统一小写
normalizers.Replace(Regex(r"[ \t\r\n]+"), " "), # 合并空白
normalizers.Strip(),
])
效果: 128K词表经压缩后减少约23%(约98K有效词条)
9.5 NgramHashMapping:多头哈希映射
为什么不能直接建完整映射表?
3-gram组合数:词表大小^3 = 100K^3 = 10^15
→ 不可能为每种组合都建一个词条
→ 必须用哈希压缩到有限大小的嵌入表
三个关键设计:
关键1:移位构建N-gram
def shift_k(k):
"""将序列向右移动k位,前面补pad_id"""
if k == 0: return x
return np.pad(x, ((0,0),(k,0)), constant_values=pad_id)[:, :T]
# 对于位置t:
# 2-gram = (x[t-1], x[t])
# 3-gram = (x[t-2], x[t-1], x[t])
base_shifts = [shift_k(k) for k in range(max_ngram_size)]
关键2:乘法-XOR混合哈希
for n in range(2, max_ngram_size + 1):
tokens = base_shifts[:n]
# 核心哈希:每个token乘以随机奇数系数,然后XOR混合
mix = tokens[0] * multipliers[0]
for k in range(1, n):
mix = np.bitwise_xor(mix, tokens[k] * multipliers[k])
# 为什么用XOR?
# ├── 计算极快(位运算)
# ├── 每个位置的token都参与混合
# └── 顺序敏感:(A,B,C) ≠ (C,B,A) ← 正确!
关键3:素数取模 + 多头降冲突
# 每个N-gram阶数配K=8个独立哈希头
for j in range(num_heads_for_this_ngram):
mod = int(head_vocab_sizes[j]) # 质数大小的嵌入表
head_hash = mix % mod # 取模得到索引
all_hashes.append(head_hash)
# 为什么用质数?
# 增大哈希分布均匀性,减少规则性冲突
# 为什么用多头(K=8)?
# 8个独立哈希函数同时查表
# 即使某些头冲突,其他头不冲突
# 整体信息损失极小
#
# 类比:8个证人同时作证,一个记错不要紧
9.6 Context-aware Gating:上下文感知门控
为什么查到的记忆不能直接用?
哈希冲突可能带来噪声
同一个N-gram在不同语境下含义不同
("apple"在科技文 vs 菜谱里)
完整门控计算:
def context_aware_gating(hidden_state, embeddings):
"""
hidden_state:来自Attention之后(含上下文语义)
embeddings:Engram查到的静态记忆
"""
# Key:记忆向量投影
key = W_K @ embeddings
key = RMSNorm(key)
# Query:当前上下文(来自Attention之后,已整合上下文信息!)
query = hidden_state
query = RMSNorm(query)
# 相似度计算
similarity = dot(query, key) / sqrt(d)
# sqrt激活(论文特殊设计,比sigmoid更敏感)
similarity = sqrt(abs(similarity)) * sign(similarity)
# sigmoid:把相似度压缩到(0,1)
alpha = sigmoid(similarity)
# 门控调制
value = W_V @ embeddings
output = alpha * value # 相关就用,不相关就屏蔽
return output
# alpha ≈ 1:记忆与上下文高度匹配 → 全量注入
# alpha ≈ 0:记忆与上下文矛盾 → 抑制噪声
具体场景示例:"我喜欢吃apple派"
"吃"、"派"的上下文 → Query的语义方向:食物、饮食
知识A(苹果公司:科技语义):
Query × Key_A → 方向差异大 → α_A ≈ 0.08 → 几乎屏蔽 ❌
知识B(水果苹果:食物语义):
Query × Key_B → 方向接近 → α_B ≈ 0.91 → 大量注入 ✅
最终:91%水果苹果 + 8%苹果公司 ≈ 基本只有"水果"语义
为什么Query来自Attention之后?
来自Attention之后:已经看过了"我喜欢吃"和"派",上下文清晰
来自Attention之前:只有当前token"apple",无法区分语义
9.7 ShortConv:深度因果卷积
为什么需要卷积层?
N-gram最大是3-gram:覆盖当前token + 前2个token = 3个token
但有些实体比3个token更长:
"United States of America" = 4个token ← 超出了!
ShortConv:把感受野从3个token扩展到10个token
配置:
self.conv = nn.Conv1d(
kernel_size=4,
groups=total_channels, # 深度可分离:每个通道独立卷积(计算量极小)
padding=(4-1)*3, # 因果:只看过去,不看未来!
dilation=3, # 空洞卷积:跳着看,覆盖更大范围
)
# 有效感受野 = 1 + (4-1) × 3 = 10个token
# 覆盖了绝大多数命名实体的长度 ✅
因果卷积的重要性:
语言模型是自回归的:
生成第t个token时,第t+1个不存在
如果卷积看了未来 → 训练时能用,推理时崩溃!
因果填充:只在左边填充,右边不填充
→ 位置t只能看到t之前的token ✅
9.8 U型Scaling Law
核心实验:给定固定参数预算,MoE和Engram如何分配?
ρ=1.0:全部给MoE,没有Engram(纯MoE)
ρ=0.0:全部给Engram,没有MoE(纯Engram)
ρ=0.75:75%给MoE,25%给Engram(混合)
实验结果:U型曲线,最优点ρ≈75-80%
纯MoE(ρ=100%)的问题:
没有专门记忆模块
被迫用计算模拟查找
→ 算力浪费在简单检索上
→ 复杂推理的算力被稀释
纯Engram(ρ=0%)的问题:
没有条件计算能力
"2+3等于几"→查表→找不到"2+3=5"这条记录
→ 推理能力丧失
最优混合(ρ≈75%):
MoE(75%):负责组合推理
Engram(25%):负责知识检索
1+1 > 2 ✅
无限记忆扩展的Scaling Law:
验证集Loss与嵌入数量呈对数线性关系!
每增加10倍记忆容量,Loss稳定下降
关键:记忆容量 ≠ 计算量
更多嵌入 → 存储更多知识模式
但每个token的计算路径完全不变
→ 知识容量和计算成本解耦!
9.9 实验结果
实验设置(三者完全公平对比):
| 配置 | Dense-4B | MoE-27B | Engram-27B | Engram-40B |
|---|---|---|---|---|
| 总参数 | 4.1B | 26.7B | 26.7B | 39.5B |
| 激活参数 | 3.8B | 3.8B | 3.8B | 3.8B |
| 训练数据 | 262B tokens | 262B tokens | 262B tokens | 262B tokens |
| 专家数 | - | 2+72 (top-6) | 2+55 (top-6) | 2+55 (top-6) |
| Engram参数 | - | - | 5.7B | 18.5B |
核心结果(Engram-27B vs MoE-27B):
| 任务类别 | Benchmark | 提升 |
|---|---|---|
| 知识检索 | MMLU +3.0, CMMLU +4.0, CCPM +7.5 | 静态事实查询更准 |
| 通用推理 | BBH +5.0, ARC-Challenge +3.7 | 复杂逻辑推理增强 |
| 代码&数学 | HumanEval +3.0, MATH +2.4, GSM8K +2.2 | 意外提升! |
最令人意外的发现: Engram不仅提升了查资料类任务,连代码和数学也提升了!
原因:
数学题 = 知识检索(识别符号含义)+ 数值推导
没有Engram时:MoE要同时处理符号识别+数值计算
有Engram时:Engram负责符号识别,MoE专心数值推导
→ 分工明确,数学能力也提升 ✅
长上下文表现(RULER 32K):
Multi-Query NIAH(大海捞针多查询):
MoE-27B:84.2
Engram-27B:97.0 ← +12.8的巨大提升!
原因:Engram将局部依赖卸载到查表
释放了Attention带宽用于全局上下文 ✅
9.10 机理分析:三个证据
证据1:LogitLens分析
MoE-27B(没有Engram):
Layer 1:Wales = 英国某地方(模糊)
...
Layer 6:= 戴安娜王妃(终于认出!)
→ 需要6层才能收敛
Engram-27B:
Layer 1:= 戴安娜王妃(直接认出!)
→ 早期层KL散度显著更低
→ 第2层的Engram直接注入了知识 ✅
证据2:CKA相似度分析
发现:Engram模型的第5层表示 ≈ MoE模型的第12层表示!
含义:
Engram在第5层就达到了MoE第12层的表示质量
相当于"有效深度"比实际层数深得多
用更少的层数做了更多的事 ✅
证据3:破坏性实验(关闭Engram)
| 任务类型 | 性能保留率 | 结论 |
|---|---|---|
| 事实知识(TriviaQA等) | 29-44% | Engram是事实知识的主要存储库 |
| 阅读理解(C3, RACE等) | 81-93% | 上下文理解主要依赖Attention |
功能分离成功!静态事实存在Engram,动态推理留在Transformer主干。
门控可视化的发现:
强激活(α≈1)的位置:
"Alexander the Great"、"the Milky Way" 等命名实体
"By the way"、"Princess of Wales" 等固定短语
"四大发明"、"张仲景" 等中文成语和历史实体
几乎不激活(α≈0)的位置:
"the"、"is"、"of" 等普通功能词
9.11 系统效率:把内存墙变成内存优势
确定性预取
MoE vs Engram的系统效率对比:
MoE专家调度(不可预测):
哪个专家被激活?取决于路由器计算结果
必须等路由器算完才知道
→ 无法提前预取
→ GPU必须等待数据
Engram调度(完全可预测!):
哪个嵌入被查询?完全由输入token决定!
→ CPU可以在GPU计算当前层时,异步预取下一层的嵌入
→ 通信与计算完全重叠
→ 访问延迟几乎为零 ✅
推理流水线时序:
GPU计算:[Block 0-14] [Engram Layer2] [Block 2-14] [Engram Layer15]
CPU预取: [解析hash IDs(L2)] [解析hash IDs(L15)]
PCIe传输: [Engram嵌入→GPU(L2)] [Engram嵌入→GPU(L15)]
关键:CPU预取和PCIe传输与GPU计算完全重叠!
多级缓存
利用Zipfian分布:
自然语言N-gram服从Zipf分布:
少数高频模式("of the"、"in the")占大多数访问
大量低频模式(罕见实体)只占少数访问
| 缓存层级 | 存储位置 | 缓存内容 | 延迟 |
|---|---|---|---|
| L1 | GPU HBM | Top高频N-gram | 最低(纳秒) |
| L2 | 主机DRAM | 中高频N-gram | 低(微秒) |
| L3 | NVMe SSD | 长尾低频N-gram | 较高但容量极大 |
极端测试(100B参数卸载到CPU):
| 配置 | 吞吐量 | 损失 |
|---|---|---|
| Dense-4B 基线 | 9,031 tok/s | - |
| Dense-4B + 100B Engram(CPU卸载) | 8,858 tok/s | 仅1.9%! |
| Dense-8B 基线 | 6,315 tok/s | - |
| Dense-8B + 100B Engram(CPU卸载) | 6,140 tok/s | 仅2.8%! |
结论:1000亿参数放在便宜的DDR5内存条上,吞吐量损失不到3%! 极大降低了扩展记忆的成本。
总结:DeepSeek的核心设计哲学
贯穿始终的主线
从V1到Engram,DeepSeek的核心哲学可以归纳为:
"在给定硬件约束下,通过软件层面的精巧设计,把每一分计算资源、每一分带宽、每一分显存都用在刀刃上。"
具体体现:
1. 计算稀疏化(不是所有参数都参与每次计算)
V2/V3:MoE细粒度专家切分 + 共享专家
V3.2:DSA稀疏注意力
2. 存储压缩(不是所有状态都需要完整缓存)
V2:MLA低秩KV-Cache压缩(64倍压缩)
V1:GQA多头共享
3. 带宽利用(不让任何一块网卡空转)
DualPath:池化全集群存储带宽
4. 任务分工(不同任务走最适合的路径)
Engram:知识检索走查表,推理走深层计算
5. 训练效率(不浪费一个训练样本)
V3 MTP:每个样本同时学多个预测目标
R1 GRPO:去掉Value Model,降低训练成本
6. 渐进式设计(不一步到位,迭代优化)
V1→V2:引入MoE和MLA
V2→V3:消除辅助Loss副作用
V3→V3.2:探索稀疏注意力
每一步都解决了上一步的具体痛点
关键技术演进时间线
DeepSeek-V1:LLaMA基础 + GQA + BBPE + SFT/DPO
↓
DeepSeek-Math:fastText数据工程 + GRPO首次应用
↓
DeepSeek-V2:MoE革命(细粒度+共享专家)+ MLA + 设备路由
↓
DeepSeek-V3:sigmoid门控 + 无辅助Loss均衡 + MTP + 投机解码
↓
DeepSeek-R1:纯RL解锁推理 + 冷启动 + 四阶段训练
↓
DeepSeek-Prover-V2:子目标分解 + 形式化证明
↓
DeepSeek-V3.2:DSA稀疏注意力 + Lightning Indexer
↓
DualPath:存储带宽池化 + Virtual Lane隔离
↓
Engram:条件记忆 + O(1)查表 + U型Scaling Law
笔记整理完成。覆盖所有PDF文档的核心知识点,结合完整教学对话的深度解析。
llama series
type: 教程 status: 已发布 level: 进阶 topic:
- 基础模型
- 模型训练
LLaMA 系列完整深度笔记
覆盖 LLaMA1 → LLaMA2 → CodeLlama → LLaMA3 → LLaMA4 包含模型结构、训练方式、工程实践、前沿探索
目录
1. LLaMA1
论文:LLaMA: Open and Efficient Foundation Language Models 定位:开源高效基础语言模型,目前主流开源大模型(Dense)基本都是LLaMA架构
1.1 模型结构
相比 GPT,LLaMA1 做出了以下四个核心改动:
Pre-RMSNorm(层归一化)
传统 Post-LayerNorm 的问题:
输入 → 注意力/FFN → 输出 → 再做归一化
类比:先跑完100米,再量血压——数值因剧烈运动而波动。
LLaMA1 的 Pre-RMSNorm:
输入 → 先做归一化 → 再做注意力/FFN → 输出
类比:先量好血压,再让你跑步——从一开始就稳定。
RMSNorm vs LayerNorm:
| 对比项 | LayerNorm | RMSNorm |
|---|---|---|
| 计算内容 | 均值 + 方差 | 只有方差(RMS) |
| 计算量 | 较大 | 更小 |
| 隐含假设 | 无 | 激活值天然趋近零均值 |
RMSNorm 去掉均值计算的合理性:深度网络中,权重初始化(Xavier/He)+ 对称激活函数,使中间层输出天然围绕 0 波动,减去均值几乎没有额外效果,却多花了计算。
公式: $$y = \frac{x}{\sqrt{\frac{1}{d}\sum_{i=1}^{d}x_i^2 + \epsilon}}$$
SwiGLU(激活函数)
标准 FFN(ReLU):
输出 = ReLU(xW₁) · W₂
类比:只有开关的水龙头,要么全开,要么关死。
SwiGLU:
输出 = (xW₁ · SiLU(xW_gate)) · W₂
类比:水龙头 + 调节阀,门控值决定每个维度放多少信息通过。
参数量补偿: SwiGLU 多了一个 W_gate 矩阵,LLaMA 通过缩小 FFN 中间维度来补偿:
标准FFN: 2个矩阵,中间维度 4d
SwiGLU FFN:3个矩阵,中间维度 8d/3 ≈ 2.67d
→ 参数量基本持平
RoPE(旋转位置编码)
绝对位置编码的问题: 给每个位置贴固定标签,训练时见过 1~2K,推理时遇到 2001 就懵了——这个位置标签从未见过。
RoPE 的思路: 不给位置贴标签,而是把位置信息编码进向量的旋转角度里。
位置m的词向量:旋转 m·θ 度
位置n的词向量:旋转 n·θ 度
注意力点积:
Q · K = (旋转了mθ的向量) · (旋转了nθ的向量)
= 只取决于 (m-n)θ ← 相对距离!
多频率设计(类比时钟):
低维度 → 小θ → 转得快 → 像秒针 → 感知近距离细粒度差异
高维度 → 大θ → 转得慢 → 像时针 → 感知远距离粗粒度差异
多个"指针"叠加,才能唯一表示任意位置。若所有维度用同一个θ,旋转到 2π 就归零重置,位置 1 和位置 1+周期 完全一样,模型无法区分。
BPE 分词器
核心思想:合并高频字符对
第一步:统计相邻字符对出现频率
第二步:合并最高频的字符对为一个新token
第三步:重复,直到词表达到目标大小(LLaMA1是32K)
LLaMA1 的特殊处理:
- 数字强制拆分: 所有数字分解为单独数字 token
普通BPE:"123456" → ["123", "456"]
LLaMA1: "123456" → ["1","2","3","4","5","6"]
原因:训练时见过 "42",推理时遇到 "43",如果整体处理则不认识;拆开后 "4" 和 "3" 都见过。 代价:模型需要隐式维护进位状态,数学计算更难。
- UTF-8 字节回退: 对未知字符回退到字节分解
"🔥" → ["<0xF0>","<0x9F>","<0x94>","<0xA5>"]
意义:没有回退机制时,遇到生僻字只能输出 <UNK>,信息丢失;有回退则信息完整保留。
1.2 训练方式
基础的自监督学习模型,没有经过任何形式的特定任务微调。
AdamW 优化器
普通 Adam 的问题: 权重衰减被加入梯度,随后被 Adam 的自适应学习率"稀释",大权重没有被有效惩罚。
AdamW 的修复:解耦权重衰减
# 第一步:正常的Adam梯度更新
weight = weight - lr * adam_update(gradient)
# 第二步:独立的权重衰减(不经过Adam缩放)
weight = weight - lr * λ * weight
LLaMA1 具体配置:
optimizer = AdamW(
β1 = 0.9, # 梯度均值历史权重(90%历史+10%当前)
β2 = 0.95, # 梯度方差历史权重(更稳定的步长估计)
weight_decay = 0.1, # 防止权重过大
grad_clip = 1.0 # 梯度裁剪,防止梯度爆炸
)
梯度裁剪的必要性:
if gradient.norm() > 1.0:
gradient = gradient / gradient.norm()
触发场景:训练数据里出现极端样本(格式异常的代码、生僻字文章),loss 暴增,梯度随之暴增。不裁剪则参数直接飞出合理区间,后续 loss 变成 NaN,训练彻底崩溃。
余弦学习率调度
为什么选余弦而不是线性:
线性衰减:匀速下降,前期下降太快,模型还没探索清楚
余弦衰减:前期缓慢→中期快速→后期缓慢,给模型充分探索空间
完整学习率生命周期:
def get_lr(step, warmup_steps, total_steps, lr_max, lr_min):
# 第一阶段:warmup(线性上升)
if step < warmup_steps:
return lr_max * (step / warmup_steps)
# 第二阶段:余弦衰减
progress = (step - warmup_steps) / (total_steps - warmup_steps)
return lr_min + 0.5 * (lr_max - lr_min) * (1 + cos(π * progress))
# 曲线形状:
# lr ↑ /﹨
# | / ﹨_
# | / ﹨___
# |——warmup——|———余弦衰减———→ step
Warmup 的作用: 训练最开始参数随机初始化,梯度方向不可信,用极小学习率让各层输出分布趋于正常,再逐步放开学习率大步走。
不同模型大小用不同学习率:
7B/13B 模型:lr_max = 3×10⁻⁴
33B/65B 模型:lr_max = 1×10⁻⁴
原因:大模型层数更深,梯度传播时误差累积更多(多层连乘放大误差),且参数耦合更复杂,改动一个引发更长连锁反应,大 lr 容易导致整个网络震荡。
1.3 训练数据
总量 1.4T token,全部公开数据,自监督学习。
| 数据集 | 采样比例 | Epoch | 磁盘大小 |
|---|---|---|---|
| CommonCrawl | 67.0% | 1.10 | 3.3 TB |
| C4 | 15.0% | 1.06 | 783 GB |
| Github | 4.5% | 0.64 | 328 GB |
| Wikipedia | 4.5% | 2.45 | 83 GB |
| Books | 4.5% | 2.23 | 85 GB |
| ArXiv | 2.5% | 1.06 | 92 GB |
| StackExchange | 2.0% | 1.03 | 78 GB |
为什么 CommonCrawl 占 67%(而非更多高质量数据):
- 数据量天花板:Wikipedia 只有 83GB,重复训练会严重过拟合
- 多样性比纯净度更重要:CommonCrawl 覆盖人类语言真实场景,让模型"说人话"
- Epoch 数是真正的质量加权:Wikipedia 训练 2.45 轮,Github 只有 0.64 轮
Github 数据连一轮都没训练完的启示: 代码数据利用率不足,缺乏合成数据构造能力,LLaMA3 通过扩充4倍代码数据+合成代码来解决。
代码数据为何能提升逻辑推理: 代码天然携带严格因果链(if→then)、显式步骤分解(step1→2→3)、零噪声逻辑(对就是对,错就是错),训练后模型学到的是精确推理而非模糊推理。
2. LLaMA2
论文:Llama 2: Open Foundation and Fine-Tuned Chat Models 核心变化:更多训练数据、更长上下文、GQA、完整 RLHF 流程
2.1 模型结构变化
| 变化点 | LLaMA1 | LLaMA2 |
|---|---|---|
| 上下文长度 | 2K | 4K |
| 大参数模型注意力 | MHA | GQA |
| FFN 矩阵维度 | 标准 | 扩充(增强泛化) |
| 训练数据 | 1.4T | 2T |
GQA(分组查询注意力)
KV Cache 的危机:
每生成1个新token → 需要读取所有历史K和V
→ 序列越长,KV Cache占用显存越大
→ 8个头 × 序列长度 × 维度 × 精度 = 显存爆炸
三种注意力机制对比:
MHA:8个Query头 → 对应8个K头、8个V头(最贵)
GQA:8个Query头 → 共享2个K头、2个V头(分组共享)
MQA:8个Query头 → 共享1个K头、1个V头(最省但效果差)
类比:餐厅每个服务员都有完整菜单(MHA)→ 几个服务员共用一份菜单(GQA)。
GQA 的能力损失: 损失了不同头对 K、V 的差异化关注能力。
- 短上下文、语义简单任务:损失可忽略
- 长上下文、需要同时关注多处细节(如100页法律合同):损失明显
KV Cache 显存计算:
显存 = 层数 × 组数 × 序列长度 × 维度 × 精度字节数 × 2(K和V)
LLaMA4 Scout(1000万token):
= 64 × 8 × 10,000,000 × 128 × 2 × 2
= 2,621,440,000,000 字节 ≈ 2.4 TB
需要约30张H100
2.2 训练数据
预训练使用来自公开可用源的 2T 个数据 token,相当于 LLaMA1 的 1.4 倍。
核心理念:"quality is all you need"
- 开始时使用公开数据做 SFT,后来改用自有标注数据
- 不同数据源和标注供应商会显著影响下游微调结果
- 数据检查极其重要
2.3 后训练流程
Llama-2-chat 的完整流程:
预训练 → SFT → 奖励模型训练 → RLHF(BoN + PPO)→ Llama-2-chat
SFT 阶段
核心洞察:一万个样本就够了
原因:
预训练阶段:模型已经"见过"几乎所有人类知识
SFT 的真正作用:不是教知识,而是教"对话格式和态度"
SFT 数据堆太多的危害:
→ 模型被过度约束在标注员水平
→ 标注员能力 < 模型潜力上限
→ 潜力被压制
SFT vs RLHF:
SFT = 模仿人类 → 上限是人类
RLHF = 被人类评价 → 上限可超越人类
奖励模型构建
数据必须来自自己的模型:
❌ 错误:用 GPT4 的输出
→ 奖励模型只学会判断GPT4风格
→ 遇到LLaMA输出 = 分布外数据 → 打分失效
✅ 正确:用自己模型的输出
→ 奖励模型精准感知LLaMA的好坏边界
采样策略: 对不同大小模型做不同 temperature 的采样
7B 模型:temperature=0.7 → 输出偏保守
13B 模型:temperature=0.9 → 输出适中
34B 模型:temperature=1.1 → 输出偏多样
→ 覆盖不同难度样本,奖励模型见识更广
LLaMA2 奖励模型数据统计:
| 数据源 | 对比数量 |
|---|---|
| Meta (Safety & Helpfulness) | 1,418,091 |
| StackExchange | 1,038,480 |
| Anthropic Helpful | 122,387 |
| OpenAI WebGPT | 13,333 |
Meta 自收集数据最多的原因:不是资源问题,而是分布匹配。OpenAI数据训练的奖励模型只懂GPT风格的好坏,对LLaMA输出是分布外数据。
拒绝采样(Reject Sampling)
for prompt in prompts:
outputs = model.generate(prompt, n=K) # 同一prompt生成K个回答
best = reward_model.pick_best(outputs) # 奖励模型评分
sft_data.append(best) # 最优答案存入训练集
特点:模型权重没有被直接更新,奖励模型只是"筛选器",无法被针对性作弊。
RLHF 迭代(共5轮)
RLHF 的哲学:宏观层面的梯度下降
| 微观梯度下降 | 宏观 RLHF |
|---|---|
| loss 函数 | 人类偏好标注 |
| 梯度方向 | 奖励模型信号 |
| 学习率 | PPO 更新幅度 |
| 一个 batch | 一轮迭代数据 |
| 时间粒度:毫秒 | 时间粒度:天/周 |
迭代策略:
第1-4轮:BoN(Best of N)
→ 模型还弱,奖励模型也不够准
→ BoN只是筛选器,无法被作弊
→ 让模型和奖励模型共同成熟
第5轮:PPO
→ 模型和奖励模型都已足够稳定
→ 梯度信号可信
→ 做最后一步精准对齐
PPO 不能过早使用的原因:奖励作弊(Reward Hacking)
PPO 优化目标:最大化 reward_model(输出) 的分数
模型发现捷径:输出超长废话、重复讨好性语句
→ 奖励分数高,但人类觉得很烂
RLHF 迭代收益递减的根本瓶颈:人类标注员辨别能力上限
初级阶段:差距明显 → 人人能判断 → 信号强
高级阶段:差距微小 → 需领域专家 → 普通标注员随机选
→ 奖励模型学到噪声而非信号
破局方向:
- AI Feedback(RLAIF):用更强的模型做裁判
- 任务分解:把"哪个更好"拆成更简单的判断
- 宪法AI:给模型一套规则让其自我评判
重要结论: LLaMA2 前四次迭代都是简单的 BoN,只有最后一次才是 PPO,说明 RLHF 的核心是 HF(人类反馈),而不是 RL(强化学习算法)。
3. CodeLlama
论文:Code Llama: Open Foundation Models for Code 定位:基于 LLaMA2 训练的代码领域模型
3.1 核心定位:继续预训练
从头训练:随机初始化 → 从零学习所有知识(20年)
继续预训练:LLaMA2基础 → 在代码数据上继续训练(几个月)
类比:培养从小学代码的程序员 vs 让博士转行学编程
混入自然语言数据的必要性: 防止灾难性遗忘(只喂代码数据会让模型忘记怎么说人话)。
3.2 训练流程
起点:LLaMA2(所有尺寸)
↓ 500B代码数据训练(所有尺寸)
↓
├── 7B/13B → Infilling训练
│
└── 所有尺寸 → 长上下文微调(20B token,4K→100K)
↓
┌──────────────────┐
│ │
CodeLlama-Python CodeLlama-Instruct
(+100B Python数据) (+5B指令微调数据)
为什么只做 Python 专项:
| 语言 | 在AI场景使用频率 | 专项训练价值 |
|---|---|---|
| Python | 极高(训练/推理/数据全流程) | 最大 |
| C++ | 中等(CUDA底层/推理引擎) | 数据量少,有限 |
| Java | 低(与AI场景关系弱) | 接近零 |
专项训练的价值公式:
收益 = 该语言在目标场景的使用频率 × 现有模型在该语言上的能力缺口
3.3 Infilling Task(代码填空)
为什么需要 Infilling:
普通代码生成(自回归):只能从左到右,给开头续写结尾
真实编程场景:中间空了需要填入 ← 普通模型完全不会 💀
数据构造(SPM 格式):
# 从完整代码中随机选一段进行掩码
original = "完整代码..."
prefix = 掩码前的部分
middle = 被掩码的部分(训练目标)
suffix = 掩码后的部分
# 输入格式:
input = f"<PRE> {prefix} <SUF> {suffix} <MID>" # 模型预测 <MID> 部分
为什么用 SPM 而不是 BERT 的 [MASK]:
BERT [MASK]:双向注意力,只能预测单个token,不适合生成整段代码
SPM: 保持自回归生成,把后缀放到前缀前面输入
→ 模型看到完整上下文后,从左到右生成中间缺失部分
→ "把填空题转化成看着答案范围来续写"
随机掩码策略:
def create_infilling_sample(code):
start = random.randint(1, len(lines)-2) # 随机起始行
length = random.randint(1, len(lines)//2) # 随机掩码长度
# 位置和长度完全随机 → 模型必须真正理解代码逻辑
为什么只有 7B/13B 做 Infilling:
7B/13B:部署在IDE插件,实时代码补全,Infilling是刚需
34B/65B:用于复杂代码生成和架构设计,不需要实时补全
Infilling 的局限性: 防御性编程(如除零判断)生成不稳定。训练数据从正确代码构造,掩码位置随机,有时防御逻辑在前缀里,模型只需填核心逻辑,倾向于生成最简单的填充。
工业界解法:
- 数据工程:提高含防御代码的掩码样本权重
- 指令微调:显式教会"注意边界情况"
- 后处理:接静态分析工具兜底(最实用)
3.4 三个最终产物定位
| 产品 | 特点 | 适用场景 |
|---|---|---|
| CodeLlama(基础版) | 纯代码补全,无对话能力 | 嵌入IDE |
| CodeLlama-Python | Python 专项强化 | 数据科学/AI开发 |
| CodeLlama-Instruct | 自然语言描述需求 | 对话式编程助手 |
长上下文的工程价值(4K→100K): 跨文件理解整个项目结构(main.py + utils.py + models/ + tests/),需要同时看多个文件的完整内容,4K 完全不够。
4. LLaMA3
论文:The Llama 3 Herd of Models 包含 LLaMA3 和 LLaMA3.1 两个系列(差别不大,多语言/长文本/tool use)
4.1 模型结构变化
| 变化点 | LLaMA2 | LLaMA3 |
|---|---|---|
| Tokenizer | sentencepiece | tiktoken |
| 词表大小 | 32K | 128K |
| 上下文长度 | 4K | 8K(后扩展到128K) |
| GQA | 部分模型 | 全系列 |
| 代码数据 | 少量 | 扩充4倍 |
LLaMA3 主要模型规格:
| 8B | 70B | 405B | |
|---|---|---|---|
| 层数 | 32 | 80 | 126 |
| 模型维度 | 4096 | 8192 | 16384 |
| FFN 维度 | 14336 | 28672 | 53248 |
| 注意力头数 | 32 | 64 | 128 |
| KV 头数 | 8 | 8 | 8 |
| 词表大小 | 128000 | 128000 | 128000 |
| 位置编码 | RoPE (θ=500,000) | RoPE (θ=500,000) | RoPE (θ=500,000) |
4.2 Tokenizer 升级:sentencepiece → tiktoken
词表 32K → 128K 的四重影响:
- 多语言覆盖: 32K 主要覆盖英语,其他语言靠字节回退;128K 可以给中/日/阿拉伯文等分配专属 token
- 序列压缩效应(最重要):
同样文字:
32K词表 → 9个token
128K词表 → 5个token(压缩44%)
→ 不改变上下文窗口大小
→ 但实际能处理的文本量增加80%
→ 相当于免费获得了更长的上下文
- 推理成本变化:
词表扩大的代价:输出层对128K个词计算softmax(比32K多4倍)
序列压缩的收益:序列变短,省约40%计算
结论:序列压缩收益 > 词表扩大代价 → 整体速度更快
- 代码处理更好: tiktoken 保留完整编程关键词("for"/"in"/"range"各自是独立token),而 sentencepiece 会把代码切成很多碎片
4.3 三阶段预训练
阶段一:初始预训练
├── 数据:15T token 混合数据
├── 上下文:8K
└── 目标:建立扎实的通用能力
阶段二:长上下文预训练
├── 数据:长文本专项数据
├── 上下文:8K → 128K(逐步扩展)
└── 目标:让模型适应超长序列
阶段三:退火(Annealing)
├── 数据:换成高质量精选数据
├── 学习率:从当前值降到接近0
└── 目标:最终精细收敛
为什么要逐步扩展上下文(不能直接从8K跳到128K):
注意力计算量:O(序列长度²)
8K: 8000² = 6400万
128K:128000² = 163亿 (贵2500倍)
直接跳的风险:
RoPE位置编码进入从未训练过的角度区间
→ 注意力分数分布崩塌
→ 模型在8K-128K之间的位置输出乱码
退火的冶金类比:
铸铁急速冷却 → 原子来不及调整 → 结构有内应力 → 刀刃易崩裂
模型直接停训 → 参数停在将就位置 → 没充分利用最后优化空间
退火 = 缓慢降温:
→ 参数有足够时间在局部精细调整
→ 换成高质量数据做最后雕琢(铸剑最后用细磨刀石收尾)
4.4 Scaling Laws
核心发现(OpenAI 2020年):
loss = A / N^α + B / D^β + 不可消除误差
(N=参数量,D=数据量)
→ 参数量/数据量翻倍,loss 下降固定比例
LLaMA3 的工程用法:
第一步:在小模型(1B/7B)上训练,记录不同配置的benchmark性能
第二步:拟合每种能力的扩展曲线
第三步:把 405B 参数代入公式,预测最优数据配比
→ 不需要真的训练405B才知道结果
Scaling Laws 的边界:无法预测涌现能力
涌现的本质是多个子能力同时达标,类似木桶装水:
CoT 推理需要同时具备:
子能力A:理解问题语义 → 80% ✅
子能力B:分解成步骤 → 60% ✅
子能力C:每步推理不出错 → 30% ❌ ← 最短板
子能力D:整合多步结果 → 70% ✅
木桶容量 = 最短板 = 30% → CoT 完全失效
当模型增大到子能力C突破60%:
→ 四个子能力同时达标
→ CoT 突然涌现
→ Scaling Laws 看到的是平均loss线性下降
→ 无法预测这种非线性跳变
4.5 数据过滤 Pipeline
四道关卡:
第一关:启发式过滤(快速)
# 长度过滤、特殊字符比例、数字比例、重复行比例
if len(doc) < 100 or len(doc) > 100000: return False
if special_char_ratio > 0.2: return False
if digit_ratio > 0.5: return False
if unique_line_ratio < 0.5: return False
第二关:NSFW 过滤 用多维分类模型(色情/暴力/仇恨/违法/自伤)打分,针对不同领域(医学/法律/历史)设置不同阈值。
第三关:语义去重
# 不能用精确匹配,用向量相似度
vectors = [encoder(doc) for doc in documents]
similar_pairs = find_similar_pairs(vectors, threshold=0.85)
# 保留质量更高的那个,而不是随机删一个
# 用 MinHash+LSH 把复杂度从 O(n²) 降到 O(n log n)
语义重复数据的三重危害:
- 知识分布失衡,模型对重复内容过度自信
- 死记硬背而非泛化学习,换个问法就不会
- 污染验证集评估(训练/验证集都有相似内容,验证 loss 虚低)
第四关:质量分类器(用上一代 LLaMA 做裁判)
quality_model = load_model("llama2") # 上一代模型判断数据质量
飞轮效应: LLaMA2 筛选数据 → 训练更好的 LLaMA3 → LLaMA3 筛选数据 → ...
循环偏见风险与防御:
| 风险 | 表现 | 防御方案 |
|---|---|---|
| 偏见放大 | 每代偏见指数级放大(b → b² → b³) | 多元模型打分(Ensemble) |
| 错误继承 | 上代认为低质量的类别被系统过滤 | 分桶多样性采样(每领域固定配额) |
| 能力天花板 | 无法超越上代模型的判断能力 | 人工抽查返工 + 外部基准锚定 |
最优数据过滤实践:
# 不是固定比例,而是质量加权采样
def quality_score(sample):
return check_logic(sample) + check_consistency(sample) + check_format(sample)
sampler = WeightedSampler(samples, weights=[quality_score(s) for s in samples])
# 分桶保证多样性(每个领域独立筛选,不跨领域竞争)
for domain, docs in domain_buckets.items():
result.extend(sort_by_quality(docs)[:quota[domain]])
4.6 后训练流程
完整迭代循环:
for round in range(num_rounds):
outputs = current_model.generate(prompts, n=K)
best_outputs = reward_model.select_best(outputs) # 拒绝采样
preference_pairs = construct_pairs(best, worst)
sft_model = finetune(base_model, data=best_outputs) # SFT
dpo_model = dpo_train(sft_model, preference_pairs,
mask_shared_prefix=True, # LLaMA3改进
nll_regularization=0.2) # LLaMA3改进
current_model = average_models([dpo_v1, dpo_v2, dpo_v3]) # 模型平均化
DPO 改进(针对梯度打架问题)
问题根源:
chosen: "好的,我来帮你...[答案]...<EOS>"
rejected: "好的,我来帮你...[废话]...<EOS>"
共同前缀:"好的,我来帮你..."
DPO loss 同时要求:
→ 增加 chosen 中这段话的概率
→ 减少 rejected 中这段话的概率
→ 同一段话,又增又减 → 梯度互相打架 💥
两个修复方案:
# 修复1:mask 掉共享前缀的 loss
loss = dpo_loss(chosen, rejected, mask_shared_tokens=True)
# 修复2:加入 NLL 正则项(系数0.2)
# 确保 chosen 的概率不会因对抗训练而整体下滑
total_loss = dpo_loss + 0.2 × nll_loss(chosen)
模型平均化
直接平均 vs Task Arithmetic:
# 直接平均(LLaMA3 用的)
averaged_params = mean([model_A, model_B, model_C])
# 适用条件:同基础模型、超参数略有不同、参数空间距离近
# Task Arithmetic(更先进)
task_vector_A = model_A.params - base_model.params # 计算相对变化方向
task_vector_B = model_B.params - base_model.params
merged = base_model.params + mean([task_vector_A, task_vector_B])
# 在"方向空间"合并而非"绝对位置空间"
每阶段都平均 vs 只在最后平均:
只在最后:误差层层累积放大(RM误差→SFT误差→DPO误差)
每阶段: 误差在每层被截断(高质量数据→高质量下游)
学术界更先进的合并方法演进:
- 2022:直接平均
- 2023:Task Arithmetic(方向空间合并)
- 2023:TIES-Merging(解决符号冲突,保留多数同意的方向)
- 2024:DARE(随机丢弃噪声分量)
- 2024:SLERP(球面线性插值,保留特征方向)
为什么 LLaMA3 大量使用 DPO 而不是 PPO
| 对比项 | PPO | DPO |
|---|---|---|
| 需要模型数量 | 4个(Actor/Critic/Reference/Reward) | 2个 |
| 显存占用 | 单模型 × 4 | 单模型 × 2 |
| 训练稳定性 | 极难调参 | 接近 SFT |
| 工程复杂度 | 极高 | 低 |
5. LLaMA4
官网:https://ai.meta.com/blog/llama-4-multimodal-intelligence/ 核心变化:MoE 架构、多模态、超长上下文
5.1 三个模型版本
| 模型 | 激活参数 | 总参数 | 专家数 | 上下文长度 | 训练Token |
|---|---|---|---|---|---|
| Llama 4 Scout | 17B | 109B | 16 | 10M | ~40T |
| Llama 4 Maverick | 17B | 400B | 128 | 1M | ~22T |
| Llama 4 Behemoth | 288B | 2T | 16 | - | 仍在训练 |
Scout vs Maverick(推理成本相同,能力不同):
两者激活参数都是 17B → 推理FLOPs相同 → 推理速度/成本完全一致
能力差异:
Scout(16专家):候选池小,遇到罕见问题可能无精准专家
Maverick(128专家):候选池大,自发形成更细粒度专业分工
数论专家 / 复分析专家 / 代码专家 / 多语言专家...
MoE 的核心价值:把"存储成本"和"推理成本"解耦
5.2 文本模型架构
继承 LLaMA2 的特性:
- 前置 RMSNorm
- SwiGLU 激活函数
- GQA(分组查询注意力)
新增特性:
- QK Norm(Attention 内部 L2 归一化)
- iRoPE(交替 RoPE 编码)
- MoE 架构(多个 SwiGLU 专家)
5.3 QK Norm
为什么 MoE 特别需要 QK Norm:
MoE 训练不稳定性:
不同专家更新频率不同(热门专家频繁,冷门专家稀少)
→ Q/K 向量的数值范围差异巨大
→ Q@K.T 出现极大值(如2000)和极小值(如0.03)
→ softmax 退化成"只看一个位置"
→ 多头注意力能力丧失 💀
L2 Norm 的修复:
class Llama4TextL2Norm(torch.nn.Module):
def _norm(self, x):
return x * torch.rsqrt(x.pow(2).mean(-1, keepdim=True) + self.eps)
# 归一化后:Q和K向量模长均为1,注意力分数范围[-1,1](余弦相似度)
公式:$y = \frac{x}{\sqrt{\frac{1}{d}\sum_{i=1}^{d}x_i^2 + \epsilon}}$
Scout 用 QK Norm,Maverick 不用的原因:
Scout(16专家):专家粒度粗,Q/K分布不均匀,需要归一化兜底
Maverick(128专家):专家高度专精,输入分布天然均匀,无需归一化
且保留向量模长信息(模长大=该token很确定要找什么)
→ 额外的隐性表达维度
5.4 iRoPE(交替位置编码)
普通 RoPE 的超长上下文危机:
训练:最长 256K token
推理:遇到 1000万 token
→ 旋转角度进入从未见过的区域
→ 注意力分数分布崩塌,输出乱码 💀
iRoPE 的解法:
# 每4层才用一次RoPE
self.use_rope = int((layer_idx + 1) % 4 != 0)
# 不用RoPE的层:用推理时温度缩放代替
if not self.use_rope:
attn_scales = torch.log(
torch.floor((cache_position.float() + 1.0) / self.floor_scale) + 1.0
) * self.attn_scale + 1.0
query_states = query_states * attn_scales
无 RoPE 层靠什么感知顺序:
第1层 [有RoPE] → hidden_state 携带位置信息
第2层 [无RoPE] → 继承上层 hidden_state(位置"惯性")
第3层 [无RoPE] → 继续继承,做语义加工
第4层 [有RoPE] → 重新注入/校准位置信息
类比:导航不需要每秒重新定位,定期校准一次,中间靠惯性推算。
iRoPE 的额外好处:
频繁 RoPE 的问题:超长序列时旋转角度累积过大,高频维度转几百圈,数值精度损失
iRoPE:只有1/4的层做RoPE → 角度累积压力分散 → 长上下文稳定性大幅提升
5.5 MoE 架构
每个 Expert 仍是 SwiGLU 结构(与 LLaMA3 一致):
class Llama4TextMLP(nn.Module):
def forward(self, x):
down_proj = self.activation_fn(self.gate_proj(x)) * self.up_proj(x)
return self.down_proj(down_proj)
Shared Expert 设计:
普通MoE:所有expert都参与竞争路由
LLaMA4: 1个Shared Expert永远激活(处理通用知识)
+ Router选出的Expert(处理专业知识)
Expert Collapse(专家坍塌)问题与防御:
问题:训练初期某几个Expert碰巧被多选
→ 这几个Expert更新更多,变得更强
→ Router更倾向选它们
→ 其他Expert永远学不到东西 → 退化成2-3个Expert在工作
防御方案一:辅助负载均衡 Loss
balance_loss = ((expert_usage - 1/num_experts)²).sum()
total_loss = main_loss + 0.01 * balance_loss
防御方案二:Bias 动态调控(DeepSeek-V3 方案,更优雅)
if expert_i 使用率过高: expert_bias[i] -= δ
if expert_i 使用率过低: expert_bias[i] += δ
# 完全解耦,不干扰主loss的梯度方向
5.6 多模态架构
三模块标准架构:
Vision Encoder(MetaCLIP)
↓
Projector(单层MLP)← 实现简单但有效,本质是LLaVA架构
↓
LLM(LLaMA4文本模型)
class Llama4ForConditionalGeneration(Llama4PreTrainedModel):
def __init__(self, config):
self.vision_model = Llama4VisionModel(config.vision_config) # MetaCLIP
self.multi_modal_projector = Llama4MultiModalProjector(config) # 单层MLP
self.language_model = Llama4ForCausalLM(config.text_config) # LLaMA4文本模型
class Llama4MultiModalProjector(nn.Module):
def __init__(self, config):
self.linear_1 = nn.Linear(vision_output_dim, text_hidden_size, bias=False)
MetaCLIP vs CLIP: 没有模型架构调整,只改进训练数据的质量和分布来提升性能。
5.7 FP8 训练
为什么需要低精度:
Behemoth(2T参数)用FP32:
参数:8TB + 梯度:8TB + 优化器状态:16TB = 32TB
需要约400张H100 → 工程上不可行
浮点精度对比:
| 精度 | 位数 | 数值范围 | 显存占用 |
|---|---|---|---|
| FP32 | 32 | ±3.4×10³⁸ | 基准×1 |
| BF16 | 16 | ±3.4×10³⁸ | 基准×0.5 |
| FP8(E4M3) | 8 | ±448 | 基准×0.25 |
| FP8(E5M2) | 8 | ±57344 | 基准×0.25 |
FP8 使用策略:
✅ 可以用FP8:矩阵乘法输入输出、前向激活值、大部分梯度
❌ 必须高精度:优化器状态(Adam动量)、权重更新、Loss计算
核心挑战:动态缩放(防止数值溢出)
# 问题:FP8最大值只有448,某层激活值可能出现500 → 溢出 → NaN
# 解决:每个张量有自己的缩放因子
scale = MAX_FP8_VALUE / tensor.abs().max()
fp8_tensor = convert_to_fp8(tensor * scale)
# 使用时还原
original = fp8_tensor / scale
分布式训练中的梯度聚合问题:
# 问题:不同GPU的梯度在不同scale下压缩,直接相加就像人民币和美元直接加
# 解决:先还原,再聚合
def aggregate_gradients(local_grad, local_scale):
true_grad = local_grad * local_scale # 还原到真实值(BF16)
aggregated = all_reduce(true_grad) # 跨GPU聚合
new_scale = compute_scale(aggregated) # 重新压缩FP8
return aggregated / new_scale, new_scale
FP8 的实际收益(相比BF16):
- 显存节省:约60%
- 算力提升:H100的FP8算力是BF16的2倍
- 实际加速:约1.5-1.8倍
5.8 MetaP(超参数缩放规律)
传统超参数迁移的问题:
7B模型最优lr:3×10⁻⁴
直接用到70B → 可能完全不对
原因:参数量增大,梯度统计特性变化
MetaP 的思路:找规律而非找最优值
发现:lr ∝ 1/sqrt(参数量)
7B: lr = C/sqrt(7B) = 3×10⁻⁴ → 求出C
70B: lr = C/sqrt(70B) = 1×10⁻⁴ (自动推导)
405B:lr = C/sqrt(405B) = ? (公式算出)
→ 不需要在大模型上重新调参
MoE 特有超参数不能从 Dense 迁移:
Dense 假设:所有参数均匀更新(均匀梯度流)
MoE 实际: 热门Expert频繁更新,冷门Expert稀疏更新
→ 违反了Dense的均匀假设
→ Dense规律完全失效
MoE 必须重新建立的超参数规律:
├── top-k:激活专家数(k=1和k=2是质变,不是量变)
├── 负载均衡Loss系数(太大破坏专家分工,太小Expert Collapse)
├── Shared Expert的独立学习率(更新频率远高于Routed Expert)
└── 路由温度
5.9 后训练流程
总体流程:
轻量SFT → 在线RL → 轻量DPO
SFT 阶段:
用 Llama 模型筛选训练数据
→ 去掉50%被标记为"简单"的问题
→ 只保留较难的问题做 SFT
在线 RL 阶段:
精心选择 medium-to-hard 难度的问题
持续在线RL策略:
→ 交替进行模型训练和提示词筛选
→ 动态保留 medium-to-hard 难度的提示词
DPO 阶段: 针对模型响应质量相关的 corner case 进行轻量 DPO。
5.10 实验结果
预训练模型对比:
| 任务 | LLaMA 3.1 70B | LLaMA 3.1 405B | LLaMA 4 Scout | LLaMA 4 Maverick |
|---|---|---|---|---|
| MMLU | 79.3 | 85.2 | 79.6 | 85.5 |
| MMLU-Pro | 53.8 | 61.6 | 58.2 | 62.9 |
| MATH | 41.6 | 53.5 | 50.3 | 61.2 |
| MBPP | 66.4 | 74.4 | 67.8 | 77.6 |
| ChartQA | - | - | 83.4 | 85.3 |
| DocVQA | - | - | 89.4 | 91.6 |
指令微调模型对比:
| 任务 | LLaMA 3.3 70B | LLaMA 3.1 405B | LLaMA 4 Scout | LLaMA 4 Maverick |
|---|---|---|---|---|
| MMMU | - | - | 69.4 | 73.4 |
| GPQA Diamond | 50.5 | 49.0 | 57.2 | 69.8 |
| MMLU Pro | 68.9 | 73.4 | 74.3 | 80.5 |
| LiveCodeBench | 33.3 | 27.7 | 32.8 | 43.4 |
| MGSM | 91.1 | 91.6 | 90.6 | 92.3 |
6. 演进总览
架构演进
| 特性 | LLaMA1 | LLaMA2 | LLaMA3 | LLaMA4 |
|---|---|---|---|---|
| 归一化 | Pre-RMSNorm | Pre-RMSNorm | Pre-RMSNorm | Pre-RMSNorm + QK Norm |
| 激活函数 | SwiGLU | SwiGLU | SwiGLU | SwiGLU (MoE) |
| 位置编码 | RoPE | RoPE | RoPE(θ=500K) | iRoPE |
| 注意力 | MHA | GQA(大模型) | GQA(全系列) | GQA + QK Norm |
| FFN | Dense | Dense | Dense | MoE |
| 上下文 | 2K | 4K | 8K→128K | 1M/10M |
| Tokenizer | sentencepiece(32K) | sentencepiece(32K) | tiktoken(128K) | tiktoken(128K) |
| 训练数据 | 1.4T | 2T | 15T | 22T~40T |
| 多模态 | ❌ | ❌ | ❌ | ✅ |
核心技术演进脉络
稳定性:
Pre-RMSNorm(LLaMA1)→ QK Norm(LLaMA4)→ FP8动态缩放(LLaMA4)
效率:
MHA → GQA(LLaMA2)→ MoE(LLaMA4)
[显存:头数×序列长度] → [组数×序列长度] → [激活参数/总参数解耦]
长上下文:
2K → 4K → 8K/128K → 1M/10M
RoPE → iRoPE(每4层用一次)
对齐:
无(LLaMA1)→ BoN+PPO(LLaMA2)→ DPO改进(LLaMA3)→ 轻量SFT+在线RL+轻量DPO(LLaMA4)
数据工程:
公开数据(LLaMA1)→ 质量优先(LLaMA2)→ 四道过滤Pipeline(LLaMA3)→ AI辅助筛选50%(LLaMA4)
各版本最重要的一个创新
| 版本 | 最重要创新 | 理由 |
|---|---|---|
| LLaMA1 | RoPE | 奠定了后续所有版本长上下文的数学基础 |
| LLaMA2 | 迭代RLHF | 证明了"宏观梯度下降"的对齐哲学 |
| CodeLlama | SPM Infilling | 把代码填空变成自回归生成,工程上极实用 |
| LLaMA3 | 数据过滤Pipeline | 15T token质量保证,数据工程决定模型上限 |
| LLaMA4 | iRoPE + MoE | 实现存储/推理解耦,撑起1000万token上下文 |
笔记整理完成。覆盖文档全部内容,并补充了课程中深度讨论的工程原理、数学推导和工业界实践。
qwen series
type: 教程 status: 已发布 level: 进阶 topic:
- 基础模型
- 多模态
- 模型训练
Qwen 系列模型深度学习笔记
覆盖范围:Qwen1 → Qwen1.5 → Qwen2 → Qwen2.5 → Qwen3 → Qwen3.5 学习方式:螺旋上升式深度解析,从基石到前沿
目录
- Qwen 系列演进总览
- Qwen1:基石奠定
- Qwen1.5:稳步迭代
- Qwen2:全面升级
- Qwen2.5:数据与后训练的突破
- Qwen3:推理与效率的融合
- Qwen3.5:迈向原生多模态智能体
- 横向对比与关键演进主线
1. Qwen 系列演进总览
Qwen1.0 & 1.5 → 高质量数据清洗 + 基础 Transformer 架构
Qwen2 & 2.5 → 全注意力架构推向 72B,代码和数学能力突破
Qwen3 → 长上下文 + 推理能力(Thinking Mode)结合,引入 MoE
Qwen3VL → 加入视觉编码器和 MRoPE,引入 DeepStack 多层级视觉特征注入
Qwen3Next → 引入 GatedDeltaNet + Gated Attention 混合注意力 + 共享专家
Qwen3.5 → 在 Qwen3Next 基础上加入 MRoPE + Vision,拆分投影层,去掉 DeepStack
核心演进主线:
| 维度 | 演进轨迹 |
|---|---|
| 注意力机制 | MHA → GQA → Q/K Norm → Gated Attention → GatedDeltaNet 混合 |
| 长度外推 | 动态NTK → YaRN+DCA → ABF → MRoPE + Partial RoPE |
| 训练效率 | BF16 → FP8 流水线 |
| 对齐训练 | RLHF → Constitutional AI → Online Merging → 四阶段后训练 → 异步RL |
| 多模态 | 无 → 后融合(Qwen3VL) → Early Fusion(Qwen3.5) |
| MoE规模 | 60专家 → 256专家 → 512专家 |
2. Qwen1:基石奠定
论文:QWEN TECHNICAL REPORT
2.1 模型结构
词表设计(152K)
- 基础:tiktoken BPE,选择
cl100k_base作为起点 - 扩充中文词汇:让中文不再被拆得七零八落
- 数字单独拆分:
2048→2,0,4,8
数字拆分的权衡:
优点:
→ 模型能感知数字结构(1024 和 2048 都以 0,4,8 结尾)
→ 数学推理能力显著提升
代价:
→ 1000000000 → 10个token(原来1个)
→ 金融、科学类文本序列长度急剧膨胀
→ 消耗宝贵的上下文窗口
Untied Embedding(解耦嵌入)
标准 LLM 的输入嵌入矩阵 = 输出嵌入矩阵(权重共享),而 Qwen1 将两者拆分:
| 输入侧(理解词) | 输出侧(生成词) | |
|---|---|---|
| 目标 | 把 token 映射成语义向量 | 把向量还原成最可能的下一个 token |
| 关心的 | 与上下文的相似关系 | 词表中的概率分布 |
| 本质 | 做检索(我是谁?) | 做排名(谁最可能出现?) |
结论:理解是"聚合语义",生成是"竞争排名",强迫共用同一套参数是在让一个人同时用同一只手写字和打架——能做,但都做不到最好。代价是增加内存消耗,但可以显著提升模型性能。
Pre-RMSNorm
Pre-Norm vs Post-Norm:
Post-Norm(旧方式):每层操作完再归一化
→ 理论上限更高,但深层网络梯度不稳定
→ 需要精细的学习率调参
Pre-Norm(Qwen选择):每层操作前先归一化
→ 梯度回传时每层输入幅度可控
→ 训练稳定,可用更大学习率
→ 更容易 Scale 到大模型
RMSNorm vs LayerNorm:
# LayerNorm(完整版)
mean = x.mean()
var = x.var()
x_norm = (x - mean) / sqrt(var + ε)
# RMSNorm(砍掉均值计算)
rms = sqrt(mean(x²) + ε)
x_norm = x / rms
均值计算对模型效果贡献极小,砍掉后计算更快,效果几乎不变。
ε 的作用:防止分母为零或极小时的数值不稳定(数值爆炸)。
SwiGLU 激活函数
ReLU 的问题:负数区域梯度为0,神经元可能永久失活。
SwiGLU 的门控机制:
gate = Linear1(x) # 门控分支
signal = Linear2(x) # 信号分支
output = signal * Swish(gate)
# Swish(x) = x * sigmoid(x),平滑版ReLU
FFN 维度调整:SwiGLU 有3个矩阵,标准FFN有2个。为保持参数量不变:
2 × d_model × d_ff = 3 × d_model × d_ff_new
→ d_ff_new = (2/3) × d_ff
所以使用 SwiGLU 的模型 FFN 隐藏维度是原始的 2/3。
RoPE 位置编码
传统正弦编码的问题:编码的是绝对位置,超出训练长度的位置从未见过,模型完全懵掉。
RoPE 的核心洞察:Attention 机制真正需要的不是"我在第几位",而是"我和你之间差了几位"。
数学推导:
位置 m 的向量旋转角度 mθ
位置 n 的向量旋转角度 nθ
点积结果:
cos(mθ) × cos(nθ) + sin(mθ) × sin(nθ) = cos((m-n)θ)
→ 相对位置 (m-n) 自动从点积里冒出来!
→ 天然支持长度外推
实现方式:每两个维度一组进行旋转,不同维度用不同的 θ:
θ_i = 10000^(-2i/d)
# 低维度:θ大 → 旋转快 → 捕捉短距离关系(类比秒针)
# 高维度:θ小 → 旋转慢 → 捕捉长距离关系(类比时针)
QKV 层保留 Bias
大多数层移除 bias(被 RMSNorm 抵消,浪费参数),但 QKV 层保留 bias:
Q = x @ Wq + bq
K = x @ Wk + bk
bias 提供固定的"基准值"(锚点)
→ 遇到训练时没见过的位置
→ bias 提供稳定的参考
→ 外推时更稳定
类比:口袋里的纸质地图 vs 纯依赖GPS
2.2 长度外推技术(2048 → 8192)
三种技术组合,各司其职:
动态 NTK 插值
NTK 的本质:修改 RoPE 底数,让所有维度"转慢一点",防止高频混叠。
# 原始 RoPE
θ_i = 10000 ^ (-2i/d)
# 静态 NTK(固定底数)
k = 目标长度 / 训练长度 # 如 8192/2048 = 4
new_base = 10000 * (k ^ (d/(d-2)))
# 动态 NTK(按需放大)
def get_base(current_len, train_len=2048):
if current_len <= train_len:
return 10000 # 短序列:原汁原味
k = current_len / train_len
return 10000 * (k ^ (d/(d-2))) # 长序列:按需扩展
底数变大 → θ_i 变小 → 旋转变慢 → 不越界
三种外推方法对比:
| 方法 | 核心思路 | 解决了什么 | 引入了什么问题 |
|---|---|---|---|
| 线性插值 | 位置等比例压缩 | 越界问题 | 短距离感知模糊 |
| 静态 NTK | 固定放大底数 | 越界+精度 | 短序列精度白白损失 |
| 动态 NTK | 按需放大底数 | 两者兼顾 | 无明显缺陷 |
| YaRN | 低频插值+高频不动 | 更精细处理 | 实现更复杂 |
LogN-Scaling
问题:序列变长时,softmax 在更多值中分配注意力权重,导致注意力分布极度分散(聚光灯变泛光灯)。
解法:
普通 Attention:scale = 1/√d(固定)
LogN-Scaling: scale = κ·log(n)/d(随序列长度增大)
n 变长 → log(n) 变大 → scale 变大
→ logits 整体放大
→ softmax 输出更集中
→ 注意力熵保持稳定(熵不变性)
分层窗口 Self-Attention
低层(捕捉局部语法):短窗口
→ 主谓宾关系只需要4-8个词的窗口
高层(捕捉全局语义):长窗口
→ 文章主题需要看全文
效果:按需分配算力
底层:短窗口×多层 → 省算力,够用
顶层:长窗口×少层 → 花算力,值得
2.3 模型训练
| 配置项 | 值 | 说明 |
|---|---|---|
| 训练目标 | 标准自回归语言模型 | 预测下一个 token |
| 上下文长度 | 2048 | 训练时固定 |
| 注意力 | Flash Attention | 提高计算效率 |
| 精度 | BF16 混合精度 | 速度+稳定性 |
| 优化器 | AdamW | β1=0.9, β2=0.95, ε=1e-8 |
| 学习率 | 余弦衰减到峰值的10% | 保留微调空间 |
β2=0.95 的原因:
有效记忆窗口 = 1/(1-β2)
β2=0.999 → 记忆1000步(小模型,梯度噪声大)
β2=0.95 → 记忆20步(大模型,batch极大,梯度已准确)
大模型训练 batch size 极大 → 每步梯度噪声小
→ 不需要平均那么长的历史
→ 更快响应当前梯度方向
余弦衰减到10%而非0%:
降到0%:参数完全停止更新,无法微调落点
保留10%:
→ 继续以极小步长游走
→ 跳出训练末期的微小局部极小值
→ 在损失曲面的"平坦区域"(Flat Minima)落脚
→ 测试集偏移时损失变化平缓,泛化更好
Document Packing(文档打包):
问题:文档长度分布极不均匀
→ 短文档(20-100 tokens) padding 到 2048
→ 97%的计算浪费在 PAD token 上
解法:随机打乱多篇文档并拼接至 2048
→ 消灭 PAD,算力不浪费
副作用:跨文档注意力污染
解法:块对角因果 Mask
块对角因果 Mask 示意:
A1 A2 A3 B1 B2 B3
A1 [ 1 0 0 0 0 0 ]
A2 [ 1 1 0 0 0 0 ]
A3 [ 1 1 1 0 0 0 ]
B1 [ 0 0 0 1 0 0 ] ← B1只看自己文档
B2 [ 0 0 0 1 1 0 ]
B3 [ 0 0 0 1 1 1 ]
工程实现使用 FlashAttention 的变长版本(varlen):
from flash_attn import flash_attn_varlen_func
output = flash_attn_varlen_func(
q, k, v,
cu_seqlens_q, # 每个文档的累积长度 [0, 3, 6]
cu_seqlens_k,
max_seqlen_q,
max_seqlen_k,
causal=True
)
为什么要随机打乱:防止灾难性遗忘(Catastrophic Forgetting)。相同领域文档集中训练会导致梯度长期偏向同一方向,其他领域能力退化。随机打乱保证每个 batch 都是整体数据分布的无偏估计(i.i.d 采样)。
2.4 Reward Model 训练体系
奖励模型结构:
class QwenRewardModel(nn.Module):
def __init__(self):
self.qwen = QwenModel() # 同等大小的 Qwen 模型
self.pooling = nn.Linear(hidden_size, 1) # 池化层输出标量奖励
def forward(self, input_ids):
hidden_states = self.qwen(input_ids)
eos_hidden = hidden_states[:, -1, :] # EOS token 位置
reward = self.pooling(eos_hidden)
return reward
为什么用 EOS token:EOS 经过所有层的注意力计算,其隐藏状态已经"看过并总结了"整个序列的信息,是回答质量的天然压缩表示。
三重保障机制:
- 6600标签分类系统:预先设计覆盖所有领域的"地图",确保偏好数据覆盖广度
- 平衡采样算法:每个标签桶贡献相同数量的样本,防止高频领域主导训练
- 多样性回答生成:用不同规模+不同采样策略的 Qwen 模型生成回答,提高标注质量
为什么需要多样性:若 RM 只见过数学题的偏好对,它对写诗、编程等领域的判断力将完全失效(Out-of-Distribution Generalization Failure)。
3. Qwen1.5:稳步迭代
注:无正式技术报告,有两篇官方介绍博客。
3.1 模型结构
- 黄金四件套:Tokenizer BPE + PreRMSNorm + SwiGLU + RoPE
- Flash Attention:使用
torch.nn.functional.scaled_dot_product_attention(SDPA)实现 - GQA:仅 Qwen1.5-32B 使用 Grouped Query Attention
- Untied Embedding:延续 Qwen1,
tie_word_embedding=False - QKV bias:延续 Qwen1,只在 QKV 参数里加 bias
3.2 Qwen1.5-MoE-A2.7B
MoE 基本原理:
Dense 模型:每个 token 激活所有 FFN 参数(14B模型推理用全部14B参数)
MoE 模型:每个 token 只激活部分"专家"(总参数14B,每次只用2-3B)
Qwen1.5 MoE 架构细节:
- 细粒度专家:将 FFN 切分为多个小块,每小块是独立专家
- 路由机制:4个共享专家 + 60个路由专家(每次激活4个)
粗粒度8专家选2:C(8,2)=28种组合
细粒度60专家选4:C(60,4)=487635种组合
→ 细粒度表达能力指数级增大
初始化策略:
从 Qwen-1.8B 继承初始化:
→ 把1.8B的FFN权重复制并切分到各专家
→ 每个专家起点已有基础能力
→ 收敛速度大幅提升
引入随机扰动:
→ 打破所有专家完全相同的对称性
→ 专家开始分化,各司其职
专家坍缩问题与负载均衡损失:
问题:路由器发现专家A最好 → 全部token路由给A → A更强 → 恶性循环
→ 最终只有1个专家在工作,MoE退化为Dense模型
解法:负载均衡损失
loss = cross_entropy_loss + α * load_balance_loss
load_balance_loss = Σ(usage_i - 1/n_experts)²
→ 越均匀损失越小
→ 梯度惩罚路由器,迫使分散分配
α = 0.01 ~ 0.1(轻微惩罚,非强制均分)
3.3 模型训练
- 数据量未公布
- 偏好对齐:PPO 和 DPO 都用到了
- 全系列支持 32K 上下文
- 提供 AWQ 和 GPTQ 量化模型(int4/int8)
3.4 模型量化:AWQ vs GPTQ
朴素 INT4 量化的问题:
所有权重一视同仁四舍五入
→ 重要权重被破坏(激活值大的权重,四舍五入一点点就导致输出剧变)
→ 模型质量严重下降
AWQ(Activation-Weighted Quantization):
# 核心思路:不是跳过重要权重,而是先放大再量化
# 计算重要性
importance = activation.abs().mean() # 激活值越大,权重越重要
# 重要权重的处理
scale = activation ** 0.5 # 根据激活值计算缩放因子
w_scaled = w * scale # 放大重要权重
w_int4 = round(w_scaled / quant_scale) # 量化(相对误差更小)
# 推理时除回去,误差已被压缩
放大效果类比:
直接量化:精密零件1.2345米 → 四舍五入 → 1米(误差0.2345米)
AWQ:先×100=123.45厘米 → 四舍五入 → 123厘米 → ÷100 → 1.23米(误差0.0045米)
AWQ vs GPTQ 对比:
| AWQ | GPTQ | |
|---|---|---|
| 核心原理 | 激活值缩放 | 逐层误差补偿 |
| 运行环境 | CPU也能跑 | 需要GPU |
| 速度 | 快 | 慢 |
| 精度 | 接近GPTQ | 略高 |
| 工业选择 | 部署速度优先 | 精度优先 |
4. Qwen2:全面升级
论文:QWEN2 TECHNICAL REPORT
4.1 模型结构
与 Qwen1 的主要区别:
- GQA(Grouped Query Attention):全系列标配
- YaRN + DCA:替代动态 NTK,更精细的长度外推
- Tokenizer:升级为 BBPE,词表 151643
GQA(分组查询注意力)
MHA(标准):Q头数=K头数=V头数(如32:32:32)
GQA: Q头数 > K头数=V头数(如32:4:4)
→ K和V参数大幅缩减
→ KV Cache 显存大幅降低
→ 推理速度提升
YaRN(进阶长度外推)
YaRN 在 NTK 基础上做了分频段处理:
低频维度(旋转慢的维度):做插值压缩
高频维度(旋转快的维度):保持不动
对比:
NTK:整体缩放,高频维度也被压缩
YaRN:分别处理,高频维度精度不损失
优势:
→ 保住了短距离精度(高频不动)
→ 扩展了长距离范围(低频插值)
→ 两全其美
DCA(Dual Chunk Attention,双块注意力)
解决超长序列下全注意力的计算效率问题:将序列分成若干块,块内做完整注意力,块间通过特殊机制交互,在保持精度的同时降低计算复杂度。
BBPE(Byte-level BPE)
BPE 的问题:
遇到生僻字或新语言:
泰语:ไม่มีวันสิ้นสุด → BPE词表里没有 → [UNK]
→ 模型完全看不懂
BBPE 的解法:
从字节(Byte)出发,而非字符:
'A' → 0x41(1字节)
'中' → 0xE4 B8 AD(3字节)
'ไ' → 0xE0 B9 84(3字节)
→ 任何语言都能用256个基础字节表示
→ 永远不会出现 UNK
→ 新语言零成本支持
4.2 预训练
三大改进:
- 质量提升:额外的启发式方法 + 基于模型的过滤(用 Qwen 模型过滤低质量数据),合成高质量预训练数据
- 数据扩展:更大规模的高质量代码、数学和多语言数据,支持约30种语言
- 分布改进:在小规模模型上实验,优化不同来源和领域的数据混合
4.3 后训练数据合成
拒绝采样(Rejection Sampling):
针对数学等有明确答案的任务:
→ 生成100条推理链
→ 只保留答案正确的
→ 错误推理全部丢弃
→ 保证数据质量
执行反馈(Execution Feedback):
针对 coding 任务:
→ LLM 生成代码 + 相关测试用例
→ 实际编译执行评估有效性
→ 创建演示和偏好数据
对于指令跟随:
→ 对每个有约束的指令,LLM 生成 Python 验证函数
→ 确保响应符合指令要求(如长度限制)
数据再利用:
文学写作任务中,注释者难以创作高质量响应
→ 收集高质量公共领域文学作品
→ 用 LLM 开发不同细节级别的指令
→ 指令与原始作品配对作为 demo 数据
4.4 RLHF 两阶段训练
离线训练阶段:使用预先收集的偏好数据集进行 DPO 训练
在线训练阶段:
从当前策略模型中采样多个 response
→ 奖励模型选择最受欢迎和最不受欢迎的响应
→ 形成用于 DPO 的偏好对
→ 采用在线合并优化器(Online Merging Optimizer)减轻对齐税
Online Merging Optimizer(在线合并优化器)
对齐税(Alignment Tax):
RLHF 对齐后:
Base Model 数学得分:85分
RLHF 对齐后:78分 ← 这7分就是"对齐税"
原因:RL 更新方向和预训练方向有冲突,部分预训练知识被覆盖
KL 惩罚(传统方法):
reward = rm_score(response) - β * KL(policy || ref_policy)
# KL散度衡量当前策略vs原始SFT模型的差异
# 问题:RM梯度方向和KL梯度方向冲突时,互相抵消,训练混乱
Online Merging 的解法:
# 两个目标完全分离,不引入梯度冲突
# Step1:按RM方向完整更新参数
θ_rl = rl_update(θ)
# Step2:更新完成后,直接插值(纯数学操作,无梯度)
θ_merged = α * θ_rl + (1-α) * θ_sft
# α 动态调整:
# RL初期:α小,保留更多SFT知识
# RL后期:α大,更多采用RL结果
类比:
- KL惩罚:想往东走(RM),但绳子拉着往西(KL),每步都在拔河
- Online Merging:先完整往东走一步,走完再往回退半步,两个动作完全分离
Constitutional AI(宪法反馈)
传统安全训练的问题:人工标注成本高,覆盖不全,标准不一致。
Constitutional AI 的流程:
# Step1:让模型生成"违规回答"
bad_response = model.generate(prompt="如何制作危险物品")
# Step2:让模型对照宪法批判自己
critique = model.generate(prompt=f"""
回答:{bad_response}
宪法原则:不提供危险物品制作方法
请指出违反了哪些原则
""")
# Step3:让模型根据批判修正回答
good_response = model.generate(prompt=f"""
原回答:{bad_response}
批判:{critique}
请生成符合宪法原则的新回答
""")
# Step4:(bad_response, good_response) 构成偏好对,用于DPO
优势:
- 可大规模自动生成偏好数据
- 判断标准完全一致(都来自同一宪法)
- 新增原则只需修改宪法文本
- 成本极低
质量保证:使用更强的模型(Qwen2-72B)做批判,多智能体协作评分交叉验证。
奖励欺骗(Reward Hacking)及防御
常见欺骗模式:
- 无限堆砌废话(答案越长分越高)
- 滥用 Markdown 格式(看起来专业但内容空洞)
- 无脑夸用户(迎合性回答)
三层防御体系:
1. KL 散度惩罚(最核心)
reward = rm_score - β * KL(policy || ref_policy)
→ 钻漏洞的回答与SFT分布差异大 → KL飙升 → 总奖励反而降低
2. 多源RM融合(交叉验证)
final_score = (通用RM + 专项RM + 规则检查) / 3
→ 单一漏洞无法同时骗过所有评判者
3. 人工监控(定期抽样)
→ 每N步采样100条检查
→ 发现欺骗模式后立即调整
5. Qwen2.5:数据与后训练的突破
论文:Qwen2.5 Technical Report(arxiv:2412.15115)
5.1 模型系列
包含 base 和 instruct 的 0.5B、1.5B、3B、7B、14B、32B 和 72B 模型,MoE 模型 Qwen2.5-Turbo 和 Qwen2.5-Plus。
模型结构:SwiGLU + RoPE + QKV bias + RMSNorm + GQA + YaRN + DCA,与 Qwen2 一致。
5.2 预训练数据(18T tokens)
四大改进:
- 更精细的数据过滤:利用 Qwen2-Instruct 模型作为过滤器,多维度分析评估打分
- 更优的数学与代码数据:加入 Qwen2.5-Math 和 Qwen2.5-Coder 的训练数据
- 更高质量的合成数据:Qwen2-72B-Instruct + Qwen2-Math-72B-Instruct 合成,专有奖励模型严格过滤
- 更合理的数据混合:用 Qwen2-Instruct 对内容分类,对电商/社交媒体等过度代表领域下采样,对技术/科学等高价值领域上采样
5.3 长文本预训练(两阶段)
阶段一:使用 4K token 上下文长度训练,在最终预训练阶段将上下文从 4K 扩展到 32K token。
ABF 技术:将 RoPE 基础频率从 10000 提升到 1,000,000
# 原始 RoPE
θ_i = 10000 ^ (-2i/d)
# ABF
θ_i = 1000000 ^ (-2i/d)
# 底数变大 → θ_i 变小 → 旋转变慢 → 天然支持更长序列
# ABF vs NTK:
# NTK:推理时的补救措施(出门发现鞋小了,现场改)
# ABF:训练时的主动设计(出门前就买了合脚的鞋)
Qwen2.5-Turbo 的四阶段扩展:32K → 64K → 128K → 256K → 1M token
每个阶段训练数据:40%当前最大长度序列 + 60%较短序列
应用 YaRN + DCA 使得 Qwen2.5-Turbo 处理最多 1M token
其他模型处理最多 128K token
5.4 后训练(1M 示例数据)
涵盖 SFT、DPO 和 GRPO,共9大类:
能力扩展类
长序列生成:
问题:模型不会生成长文
解法:反向翻译技术
→ 从预训练语料里找优质长文
→ 让模型生成这篇长文的 query
→ (query, 长文) 配对,复用高质量长文
→ 确保输出长度符合预期
数学推理:
引入 Qwen2.5-Math 中的 CoT 数据
拒绝采样保证高质量
结合奖励建模和带注解的答案
→ 帮助模型生成逐步推理过程
编程能力:
整合 Qwen2.5-Coder 指令微调数据
多个编程语言的智能体协作
生成约40种编程语言的多样化高质量指令数据
多语言 sandbox 静态代码检查
自动化单元测试验证代码质量
精准执行类
指令跟随:
模型既生成指令也生成相应的验证代码
配合全面的单元测试交叉验证
基于执行反馈的拒绝采样精选训练数据
结构化数据理解:
包含传统任务(表格问答、事实验证、错误修正、结构理解)
和复杂结构化/半结构化数据任务
通过加入 CoT 增强从结构化数据中推理的能力
逻辑推理:
引入来自多个领域的70000个新 query
涵盖多项选择题、判断题和开放性问题
演绎推理、归纳推理、类比推理等多种方式
迭代优化剔除错误答案和有缺陷的推理过程
鲁棒性类
跨语言迁移:
翻译模型将高资源语言指令翻译为低资源语言
评估语义对齐情况
保证响应在不同语言间的逻辑结构和风格一致性
鲁棒系统指令:
构建数百条通用系统提示词
同一问题配不同 system prompt 训练
→ 模型学会忽略 prompt 风格差异,专注任务本身
响应过滤:
专门的评论模型 + 多智能体协作评分系统
只有被所有评分系统认为完美的响应才被保留
→ 保证输出的高质量标准
6. Qwen3:推理与效率的融合
6.1 模型系列
从 0.6B 到 235B 参数量的多种模型(Dense 或 MoE)。
包含 Qwen3-235B-A22B、Qwen3-32B 等前沿模型,以及通过蒸馏得到的 Qwen3-14B/8B/4B 等轻量模型。
6.2 模型结构(相较 Qwen2 的变化)
Q/K RMSNorm(防止注意力坍缩)
Attention Collapse(注意力坍缩)问题:
训练后期 Q 和 K 的向量幅度差异极大
→ 某些头的点积值爆炸到几千
→ softmax 之后变成 one-hot 分布
→ 模型只关注一个 token,其他全部忽略
→ 注意力坍缩
Qwen2 vs Qwen3 代码对比:
# Qwen2:直接使用,无归一化
query_states = self.q_proj(hidden_states).view(hidden_shape).transpose(1, 2)
# Qwen3:先投影,再归一化
self.q_norm = Qwen3RMSNorm(self.head_dim) # 注意:在 head_dim 维度!
self.k_norm = Qwen3RMSNorm(self.head_dim)
query_states = self.q_norm(self.q_proj(hidden_states).view(hidden_shape)).transpose(1, 2)
key_states = self.k_norm(self.k_proj(hidden_states).view(hidden_shape)).transpose(1, 2)
为什么在 head_dim 而非 hidden_size 归一化:
每个头负责捕捉不同类型的关系:
Head 1 → 语法关系
Head 2 → 指代关系
Head 3 → 位置关系
头间的幅度差异本身有意义!
对整体 hidden_size 归一化 → 各头互相污染 → 多头意义丧失
对每个头单独归一化 → 防止各自坍缩,同时保留头间独立性 ✅
Attention Bias 可配置
# Qwen2:QKV bias 写死为 True
self.q_proj = nn.Linear(..., bias=True)
# Qwen3:bias 变成可配置
self.q_proj = nn.Linear(..., bias=config.attention_bias)
原因:不同规模的模型对 bias 的需求不同。大模型(235B)参数极度充裕,W 矩阵本身已能处理任何位置偏移,bias 是多余的,去掉可加速训练推理。小模型(0.6B)参数稀缺,bias 是宝贵的"兜底锚点"。
Sliding Window 判断逻辑移到初始化阶段
# Qwen2:检查逻辑在 forward 中(每次推理都判断)
def forward(self, ...):
sliding_window = None
if (self.config.use_sliding_window and ...):
sliding_window = self.config.sliding_window
# Qwen3:检查逻辑在 __init__ 中(只判断一次)
def __init__(self, config, layer_idx):
self.sliding_window = config.sliding_window
if not (self.config.use_sliding_window and ...):
self.sliding_window = None # 初始化时确定,forward 直接用
6.3 预训练
三阶段预训练(训练数据从 Qwen2.5 的 18T 扩展到 36T tokens):
- 第一阶段:在超过 30T tokens 数据上预训练,上下文长度 4K tokens
- 第二阶段:增加知识密集型数据比例(STEM、代码、逻辑推理),额外训练 5T tokens,提升推理能力
- 第三阶段:使用高质量长上下文数据,扩展上下文长度至 32K tokens
6.4 后训练:四阶段流程
目标:同时具备"慢慢推理"和"快速响应"两种能力。
Stage 1:Long-CoT 冷启动
→ 使用多样化的长 CoT 数据微调
→ 涵盖数学、编码、逻辑推理、STEM
→ 赋予模型基本推理能力
Stage 2:基于推理的强化学习
→ 通过 RL 进一步提升推理能力
Stage 3:思考模式融合
→ 同时喂三种数据:
带<think>标记的长CoT数据
带/no_think标记的直接回答数据
无标记的自动判断数据(训练Auto模式)
→ 模型学会"看标记,切模式"
Stage 4:通用强化学习
→ 在超过20个领域任务上进行强化学习
→ 进一步优化两种模式的表现
轻量模型:通过 Strong-to-Weak Distillation(强到弱蒸馏)训练。
蒸馏的本质优势(Dark Knowledge):
硬标签训练:
问:苹果是什么颜色?答:红色(只有0和1)
软标签蒸馏(大模型输出概率分布):
红色: 0.70, 绿色: 0.20, 黄色: 0.09, 紫色: 0.01
→ 小模型同时学到:"红色最对,但绿色也有道理"
→ 传递的是大模型对世界的"认知不确定性结构"
→ 不是答案,是暗知识(Dark Knowledge)
思考模式的实际使用:
# 开启思考(/think 标记)
messages = [{"role": "user", "content": "证明勾股定理 /think"}]
# 输出:<think>让我逐步分析...</think>然后给出答案
# 关闭思考(/no_think 标记)
messages = [{"role": "user", "content": "今天几号 /no_think"}]
# 输出:直接回答
# Auto 模式(无标记,模型自判断)
messages = [{"role": "user", "content": "证明勾股定理"}]
# 模型内部判断复杂度,自动决定是否思考
6.5 模型效果(Base 模型对比)
| Benchmark | Qwen2.5-72B | DeepSeek-V3 | Qwen3-235B |
|---|---|---|---|
| MMLU | 86.06 | 87.19 | 87.81 |
| MATH | 62.12 | 62.62 | 71.84 |
| GSM8K | 91.50 | 87.57 | 94.39 |
| EvalPlus | 65.93 | 63.75 | 77.60 |
| MBPP | 76.00 | 74.20 | 81.40 |
核心结论:Qwen3-235B(MoE,激活22B)在数学和代码上大幅领先,体现了 MoE 架构的参数效率优势。
7. Qwen3.5:迈向原生多模态智能体
发布时间:2026年2月 首发模型:Qwen3.5-397B-A17B(397B总参数,17B激活参数)
7.1 核心创新概览
| 技术 | 说明 |
|---|---|
| 混合注意力 | GatedDeltaNet (线性) + Gated Full Attention,75:25 交替 |
| MRoPE | 多模态旋转位置编码,3D位置 (temporal, height, width) |
| Gated Attention | Q 投影输出翻倍,一半做 query,一半做 sigmoid 门控 |
| MoE | 512 路由专家 + 共享专家 + sigmoid 门控 |
| (1+w) RMSNorm | weight 初始化为 0,前向计算 x * (1 + weight) |
7.2 架构演进背景:O(n²) 问题
Full Attention 的计算瓶颈:
计算量和 KV Cache 随序列长度 L 的关系为 O(L²)
应用场景从短对话演进到 100K+ token 长文档、1M+ token 代码库
O(L²) 不再可承受:
→ 显存墙:KV Cache 迅速占满显存,batch size 受限
→ 推理延迟:生成每个 token 的延迟线性增加
数字感受:
32K² = 1,024(单位)
256K² = 65,536(单位)
→ 序列扩大8倍,计算量扩大64倍!
Qwen3.5 的吞吐量优势:
vs Qwen3-Max:
32K 上下文:吞吐量 8.6 倍
256K 上下文:吞吐量 19.0 倍
→ 序列越长,优势越大(理论预期的完美体现)
7.3 混合层设计:75% Linear + 25% Full
层分配模式:
[L, L, L, F, L, L, L, F, ...] (full_attention_interval=4)
L = GatedDeltaNet(线性注意力)
F = Gated Full Attention(全注意力)
为什么不全用线性注意力:
纯 Linear Attention 的硬伤:
大海捞针任务(100K token里找特定信息)
→ 线性注意力维护固定大小记忆矩阵 S
→ 久远的精确信息容易被覆盖
→ 精确检索能力不如 Full Attention
解法:
75% Linear → 承担粗粒度语义混合(省算力)
25% Full → 承担精确全局交互校正(保质量)
KV Cache 显存分析:
Linear 层:维护固定大小递推状态 → O(1)
Full 层: KV Cache 随序列增长 → O(n)
整体:由 O(n) 主导,但系数只有 0.25
→ 相比纯 Full Attention 的 KV Cache 缩小到 1/4
7.4 GatedDeltaNet:线性注意力的核心
从线性注意力到 Delta Rule
普通线性注意力的问题:
维护记忆矩阵 S
简单叠加写入:S_t = S_{t-1} + v_t · k_t^T
问题:变量X=1 写入S,变量X=2 再写入S
→ S里同时存着 X=1 和 X=2 → 记忆干扰
Delta Rule 的核心思想:写入前先擦除旧信息
关键问题:用 Q 还是 K 查旧值?
→ K 是"写操作的地址"(我是谁,我对应字典哪一页)
→ Q 是"读操作的查询"(我想找什么)
→ 写入前用 K 查旧值,读取时才用 Q
Delta Rule 公式:
S_t = S_{t-1} + k_t ⊗ [β_t · (v_t - S_{t-1}^T · k_t)]
分解:
S_{t-1}^T · k_t → 用K查出旧值(key查自己的存储位置)
v_t - S_{t-1}^T k_t → 计算delta(新值-旧值,只写增量)
β_t → 写入强度(学习率)
k_t ⊗ delta → 外积更新对应位置
类似数据库的 UPSERT 操作:精确覆盖,不留残影
Gated DeltaNet:加入遗忘门
问题:话题切换时(量子力学→食谱),记忆矩阵S里还残留旧话题内容,相互干扰。
解法:数据依赖的遗忘门 α_t
完整公式:
S_t = α_t · S_{t-1} · (I - β_t k_t k_t^T) + β_t v_t k_t^T
各参数含义:
α_t ∈ (0,1) 遗忘门:话题转换时→0,快速清空无关记忆
β_t ∈ (0,1) 写入强度:控制新信息写入深度
(I-β_t k_t k_t^T) Householder变换:腾出旧空间防止信息重叠
前向计算 6 步骤
Step1:输入投影(4条并行路径)
in_proj_qkv → Q/K/V
in_proj_z → 输出门控
in_proj_b → beta(写入强度)
in_proj_a → alpha(衰减系数)
Step2:因果卷积(Causal Conv1d,kernel_size=4)
QKV经过 depthwise 因果卷积 + SiLU
→ 融合前4个位置的局部上下文
→ 弥补线性注意力对局部模式感知弱的缺陷(借鉴自 Mamba)
Step3:门控参数计算
beta = sigmoid(b) 学习率 ∈ (0,1)
g = -exp(A_log) * softplus(a + dt_bias) 衰减系数 < 0
Step4:GQA 扩展(Linear Attention 也支持 GQA)
Step5:核心计算(两条路径)
prefill:chunk_gated_delta_rule(分块并行,chunk_size=64)
decode: recurrent_gated_delta_rule(逐token递推)
Step6:输出门控
output = RMSNormGated(attn_out, gate_z)
→ RMSNorm(x) * SiLU(gate_z)
prefill 用分块并行的原因:
逐token递推:严格串行,每步依赖上一步S,GPU大量核心闲置
分块并行:1024个token切成16个chunk
→ chunk内部矩阵乘法并行计算
→ 串行部分只有16步(而不是1024步)
→ GPU利用率大幅提升,速度差达数十倍
Qwen3.5 vs Qwen3Next 投影层差异
# Qwen3Next:2个合并投影(需要复杂的重排函数)
self.in_proj_qkvz = nn.Linear(hidden_size, key_dim*2 + value_dim*2)
self.in_proj_ba = nn.Linear(hidden_size, num_v_heads*2)
# Qwen3.5:4个独立投影(语义清晰,便于优化)
self.in_proj_qkv = nn.Linear(hidden_size, key_dim*2 + value_dim)
self.in_proj_z = nn.Linear(hidden_size, value_dim) # 输出门控
self.in_proj_b = nn.Linear(hidden_size, num_v_heads) # beta
self.in_proj_a = nn.Linear(hidden_size, num_v_heads) # alpha
# 删除了 fix_query_key_value_ordering 方法
7.5 Gated Full Attention
Q 维度翻倍 + sigmoid 门控:
# Q投影维度翻倍
self.q_proj = nn.Linear(hidden_size, num_heads * head_dim * 2) # ×2!
# forward 中拆分
query_states, gate = torch.chunk(q_proj_output, 2, dim=-1)
# 标准注意力计算
attn_output = attention(query_states, key_states, value_states)
# 门控
attn_output = attn_output * torch.sigmoid(gate)
参数量分析:
标准 MHA(32Q+32K+32V):96单位参数
Qwen3.5(Q翻倍+GQA 16:1):
Q: 32×2=64单位
K: 32/16=2单位
V: 32/16=2单位
总计: 68单位
→ GQA省掉的远比Q翻倍多出的多,整体参数量反而减少
QK Norm(继承自Qwen3):
self.q_norm = Qwen3_5RMSNorm(self.head_dim) # 在 head_dim 维度
self.k_norm = Qwen3_5RMSNorm(self.head_dim)
# head_dim=256 时尤为重要,防止大 head_dim 下的数值爆炸
Partial RoPE(仅 25% 维度):
partial_rotary_factor = 0.25
# head_dim=256,只有前 64 维参与 RoPE 旋转,剩下 192 维保持原始值
rotary_dim = 64 # 256 * 0.25
q_rot, q_pass = q[..., :64], q[..., 64:] # 64 / 192
q_embed = cat([rotate(q_rot), q_pass]) # 拼接回 256
位置信息 vs 内容信息分工:
参与RoPE的64维(25%):专门携带位置信息
剩余192维(75%):完全不受位置编码干扰,专门携带语义内容
→ 两者职责分离,互不干扰
→ 更大的head_dim,更纯净的内容表达空间
7.6 MRoPE:多模态旋转位置编码
从 1D 到 3D 位置编码:
文本token:1D位置(pos, 0, 0)
图像token:3D位置(frame, row, col)
视频token:3D位置(t, h, w)
position_ids 的 shape:(3, B, L)
分别对应 temporal(T)、height(H)、width(W)
文本token的特殊处理:
# 文本token设置:
t = 序列位置(0,1,2,3...) # 保留1D顺序信息
h = 0 # 固定常数
w = 0 # 固定常数
# 效果:cos((0-0)θ) = cos(0) = 1
# → 所有文本token在h/w维度"相对位置完全相同"
# → h和w对文本token静默
# → 退化回标准1D RoPE
频率分段(mrope_section):
mrope_section = [11, 11, 10] # 总和32对 = 64维旋转空间
# T占11对频率,H占11对频率,W占10对频率
# 排列方式:交错排列(非分块)
# 分块:[T,T,T...H,H,H...W,W,W](时空联合关系难学)
# 交错:[T,H,W,T,H,W,T,H,W...](每局部包含完整3D位置信息)
Qwen3 vs Qwen3VL vs Qwen3.5 RoPE对比:
| 特性 | Qwen3 | Qwen3VL | Qwen3.5 |
|---|---|---|---|
| RoPE类型 | 标准1D | MRoPE 3D | MRoPE 3D |
| mrope_section | - | [24,20,20] | [11,11,10] |
| head_dim | 128 | 128 | 256 |
| partial_rotary_factor | 1.0 | 1.0 | 0.25 |
| RoPE有效维度 | 128 | 128 | 64 |
Qwen3.5 用更大的 head_dim 但更小的 rotary factor,使 RoPE 有效维度(64)反而比 Qwen3VL(128)小,意味着更多维度留给内容表示,位置信息更加"紧凑"。
7.7 (1+w) RMSNorm
对比标准 RMSNorm:
# 标准 RMSNorm(Qwen3)
weight = torch.ones(dim) # 初始化为1
output = normalize(x) * weight
# (1+w) RMSNorm(Qwen3.5,来自Gemma3)
weight = torch.zeros(dim) # 初始化为0
output = normalize(x) * (1 + weight)
# 初始状态:两者完全一样(都输出 normalize(x))
# 但训练动态不同!
训练优势:
想"关闭"这一层:
标准:weight → 0(从1走到0,路径长)
(1+w):weight → -1(从0走到-1,梯度在0附近更稳定)
weight = -1 时:
normalize(x) * (1 + (-1)) = 0
→ 等效于残差连接跳过这层(自适应跳层)
→ 梯度直接"穿透",不在这里消失或爆炸
→ 60层网络如果20层自适应关闭,梯度只需穿越40层
GatedRMSNorm(不同场景):
# 用在 GatedDeltaNet 的输出端
weight = torch.ones(hidden_size) # 注意:这里是 ones!
output = RMSNorm(x) * SiLU(gate_z)
# 为什么用 ones:
# 这个 Norm 需要在训练初期就能正常传递梯度
# 如果初始化0:SiLU(gate_z) * 0 = 0 → 输出全0 → 梯度消失 → 训练无法启动
7.8 512 专家 MoE 架构
规格对比:
Qwen1.5-MoE: 60路由专家,每次激活4个,激活比例 6.7%
Qwen3.5-MoE: 512路由专家,每次激活10个 + 1共享专家,激活比例 2%
TopK Router(softmax → topk(10) → renormalize):
router_logits = F.linear(hidden_states, self.weight) # [L, 512]
probs = F.softmax(router_logits, dim=-1) # 归一化到所有512专家
top_values, top_indices = torch.topk(probs, k=10) # 选top-10
top_values /= top_values.sum(dim=-1, keepdim=True) # renormalize
# 为什么 renormalize:
# softmax后10个专家权重之和≈0.35(只有35%信息量)
# renormalize后权重之和=1(信息量完整保留)
细粒度专家(3D张量存储):
# 512个专家,每个是标准 SwiGLU 结构
self.gate_up_proj = nn.Parameter(
torch.empty(512, 2 * intermediate_dim, hidden_dim) # 3D张量
)
self.down_proj = nn.Parameter(
torch.empty(512, hidden_dim, intermediate_dim)
)
# 每个专家:output = down_proj(SiLU(gate_proj(x)) * up_proj(x))
共享专家 + sigmoid 门控:
def forward(self, hidden_states):
# 路由专家
routing_weights, selected_experts = self.gate(hidden_states)
expert_output = self.experts(hidden_states, selected_experts, routing_weights)
# 共享专家(带sigmoid门控)
shared_output = self.shared_expert(hidden_states)
gate_value = F.sigmoid(self.shared_expert_gate(hidden_states))
shared_output = gate_value * shared_output
# 最终输出公式:
# output = Σ(w_i · expert_i(x)) + σ(g(x)) · shared(x)
return expert_output + shared_output
sigmoid 门控的作用:不同 token 对共享知识需求不同,gate 自适应调节共享专家贡献强度。
7.9 Early Fusion 多模态
后融合 vs 早期融合:
后融合(Qwen3VL旧方式):
图像 → ViT → Projector(信息瓶颈) → 注入LLM
→ 视觉信息被压缩后才进入LLM
→ 精确空间信息(按钮坐标)容易丢失
Early Fusion(Qwen3.5):
图像 → VisionModel → 视觉token
与文本token拼接 → 统一送入TextModel所有层
→ 视觉信号直接参与LLM深层计算
→ 精确到像素级的坐标信息保留
→ GUI 操作等 Agent 任务效果显著提升
7.10 视觉编码器结构
完整处理流程:
输入:图像或视频帧
↓
PatchEmbed(Conv3d)
kernel_size = (temporal_patch_size, patch_size, patch_size)
图像(单帧):退化为2D卷积
视频(多帧):同时处理时序信息
→ 统一处理图像和视频,无需两套代码
↓
VisionBlocks × 27(标准ViT,Full Attention)
注:视觉部分用 Full Attention(图像patch需要精确全局交互)
↓
PatchMerger(4:1合并)
相邻4个patch合并成1个token
[4 × patch_dim] → MLP → [text_hidden_dim]
1024×1024图像:5000 patch → 1250 视觉token
↓
视觉token → 注入TextModel
去除 DeepStack:
Qwen3VL 的 DeepStack:
在 ViT 第8、16、24层提取中间特征 → 多级 PatchMerger → 注入LLM
→ 多层级特征,类似FPN
→ 但参数量多,训练不稳定,序列长度膨胀
Qwen3.5 删除 DeepStack:
del self.deepstack_visual_indexes
del self.deepstack_merger_list
→ 直接跑完所有 VisionBlock,只用最终输出
原因:
Early Fusion + GatedDeltaNet 本身已能从不同深度感知视觉信息
DeepStack 的多层级功能被天然替代,不再需要"打补丁"
7.11 DynamicCache 统一管理
混合架构的 Cache 挑战:
Full Attention 层:需要 key_cache + value_cache(随序列增长)
Linear Attention 层:需要 conv_states + recurrent_states(固定大小)
两套独立 Cache → 内存预分配复杂 + 与现有框架不兼容
统一设计:
class Qwen3NextDynamicCache:
def __init__(self, config):
# 每层都初始化四个槽位
self.key_cache = [None] * num_layers # Full Attention 用
self.value_cache = [None] * num_layers # Full Attention 用
self.conv_states = [None] * num_layers # Linear Attention 用
self.recurrent_states = [None] * num_layers # Linear Attention 用
class Qwen3_5DynamicCache(Qwen3NextDynamicCache):
pass # 完全继承
# 运行时:
# Full Attention 层只用 key_cache/value_cache,其余为 None
# Linear Attention 层只用 conv_states/recurrent_states,其余为 None
# None 槽位不占实际显存
工程优势:对外只有一个 Cache 对象,serving 系统无需感知两种状态的差异,无缝接入 vLLM 等现有框架。
7.12 Multi-Token Prediction (MTP)
标准 Next Token Prediction 的局限:
每次只预测下一个token
→ 每个训练步只产生1个预测信号
→ 大量计算只用来预测1个token,信息利用率偏低
MTP 的核心思想:
同时预测未来N个token
→ 每个训练步产生N个预测信号
→ 同样计算量,N倍学习信号
→ 模型被迫学习全局语言结构(而非局部统计规律)
→ 在代码和数学任务上提升最明显
工程实现(共享LM Head):
# 主干正常计算
hidden_states = transformer(input_ids)
# 预测头1(标准)
logits_1 = lm_head(hidden_states)
# 预测头2/3/4(轻量,共享lm_head)
delta_2 = small_mlp_2(hidden_states)
logits_2 = lm_head(hidden_states + delta_2) # 共享lm_head!
# 训练损失(权重递减)
loss = λ_1 * CE_1 + λ_2 * CE_2 + λ_3 * CE_3 + λ_4 * CE_4
# λ_1 > λ_2 > λ_3 > λ_4(近的预测更可靠,权重更高)
推理时的投机采样收益:
训练时的MTP头可用于推理阶段的投机采样(Speculative Decoding):
Step1:用轻量MTP头快速生成4个候选token(草稿)
Step2:用主干模型一次性验证这4个token
结果处理:
→ 全部正确:1次forward = 4个token
→ 前2个正确,第3个错:接受前2个,从第3位重新生成
→ 平均:1次forward ≈ 2-3个token
对比标准自回归(1次forward=1个token):显著提速
工程联动:
MTP → 投机采样 → 异步RL加速(Rollout生成更快,Replay Queue填充更快)
7.13 FP8 训练流水线
三层量化策略:
1. 激活量化:forward时激活值用FP8存储 → 激活显存降低约50%
2. MoE路由量化:路由矩阵计算用FP8 → 512专家路由显存大幅降低
3. GEMM量化:矩阵乘法(最耗时操作)用FP8 → H100的FP8 GEMM比BF16快约2倍
敏感层保护机制(运行时监控):
# 每N步检测各层激活值的绝对最大值(amax)
amax = max(|activation|)
if amax > FP8_MAX_VALUE(448): # FP8 E4M3格式最大值
use_bf16_for_this_layer() # 自动升级到BF16
else:
keep_fp8()
# 高风险层(容易超过448):
# QK点积前、FFN第一个线性层输出、MoE路由logits、残差连接累加处
# 低风险层:RMSNorm之后、Embedding层
整体效果:激活显存降低约50%,训练速度提升超过10%,稳定扩展至数万亿token。
7.14 异步 RL 框架
传统同步 RL 的问题:
生成样本 → 等待 → 计算奖励 → 等待 → 更新参数 → 循环
GPU 在"等待"期间完全空闲
Actor-Learner 解耦架构:
Actor GPU:不断生成 rollout → 存入 Replay Queue
Learner GPU:不断消费 rollout,计算梯度更新参数
→ 两者并行运行,互不等待
→ GPU 利用率最大化
→ 端到端加速 3x-5x
关键技术细节:
Staleness Control(新鲜度控制):
→ Actor 用的参数最多落后 Learner 2步
→ 太旧的样本直接丢弃(staleness ≤ 2)
→ 保证 off-policy 偏差可控
Rollout 路由回放:
→ 相同任务的 rollout 路由给同一GPU
→ 减少跨卡通信,提升缓存命中率
投机采样(联动MTP):
→ 用MTP头加速 Rollout 生成
→ Replay Queue 填充更快
→ Learner 等待时间更短
7.15 三种推理模式
Qwen3 的旧方式:在输入文本里加 /think、/no_think 标记(工程不够健壮)
Qwen3.5 的接口参数控制:
# thinking 模式(深度思考)
response = model.generate(messages, thinking_mode="thinking")
# 输出:<think>详细推理过程...</think>最终答案
# fast 模式(直接回答)
response = model.generate(messages, thinking_mode="fast")
# 输出:直接回答,无思考过程
# auto 模式(自适应)
response = model.generate(messages, thinking_mode="auto")
# 简单问题→fast,复杂问题→thinking,模型自判断
7.16 规格参数
| 维度 | 数值 |
|---|---|
| 总参数量 | 397B |
| 激活参数量 | 17B |
| 模态 | 文本+图像+视频输入,文本输出 |
| 词表大小 | 248320(覆盖201种语言/方言) |
| 层数 | 60(15组,每组3L+1F) |
| 隐藏维度 | 4096 |
| head_dim | 256 |
| partial_rotary_factor | 0.25(RoPE维度64) |
| 原生上下文 | 262144 tokens |
| 可扩展上下文 | 最高约1010000 tokens(YaRN RoPE scaling) |
| FFN(MoE) | 512路由专家,每token激活10+1个 |
| MoE专家中间维度 | 1024 |
| GQA(Full Attn) | Q头32,KV头2(16:1) |
7.17 RL Environment Scaling
官方核心结论:
训练环境数量从 0 → 17500:
Qwen3.5 Thinking:排名从13 → 4(超越 Claude Opus 4.5 Thinking)
Qwen3.5 Non-Thinking:排名从13 → 7(超越 DeepSeek-V3.2 Thinking)
规律:
1. 环境越多,性能越强(RL在Agent任务上的Scaling Law得到验证)
2. Thinking 模式始终优于 Non-Thinking,但差距随环境增多缩小
3. 官方策略:"更强调RL环境的难度与可泛化性,而非针对特定指标优化"
→ 防止 Benchmark Hacking,追求真实泛化能力
8. 横向对比与关键演进主线
8.1 Qwen3 vs Qwen3.5 核心差异
| 特性 | Qwen3 | Qwen3.5 |
|---|---|---|
| 注意力类型 | Full + Sliding Window | Hybrid(Linear 75% + Full 25%) |
| 推理复杂度 | O(n²) | 大部分O(n),少量O(n²) |
| 长序列友好 | 有限(靠SWA缓解) | 原生高效(Linear Attention) |
| GQA比例 | 32:32(MHA) | 16:2(MoE变体) |
| head_dim | 128 | 256 |
| RoPE类型 | 标准1D,全维度 | MRoPE 3D,仅25%维度 |
| RMSNorm | 标准(ones初始化) | (1+w)变体(zeros初始化) |
| 视觉编码器 | 无 | ViT(去掉DeepStack) |
8.2 完整继承链(Qwen3.5)
Qwen3_5TextConfig → Qwen3NextConfig
Qwen3_5GatedDeltaNet → Qwen3NextGatedDeltaNet
Qwen3_5Attention → Qwen3NextAttention → Qwen3MoeAttention → Qwen3Attention
Qwen3_5RMSNorm → Qwen3NextRMSNorm → Gemma3RMSNorm
Qwen3_5TextModel → Qwen3NextModel
Qwen3_5Model → Qwen3VLModel
Qwen3_5DynamicCache → Qwen3NextDynamicCache
Qwen3_5MoeSparseMoeBlock → Qwen3NextSparseMoeBlock → Qwen2MoeSparseMoeBlock
Qwen3_5MoeForCausalLM → Qwen3NextForCausalLM → MixtralForCausalLM
文本骨干:来自 Qwen3Next(混合注意力架构)
多模态外壳:来自 Qwen3VL(VisionModel + MRoPE)
MoE 机制:追溯到 Qwen2Moe 和 Mixtral
RMSNorm 设计:来自 Gemma3
8.3 核心技术决策总结
- 混合注意力是核心:75% O(n) + 25% O(n²),在保持表达力的同时大幅提升长序列效率
- 投影层拆分是实用性改进:4个独立投影替代2个合并投影,代码更清晰,实现更灵活
- 去 DeepStack 是简化之举:混合注意力的多尺度建模能力已足够,无需多级特征注入
- (1+w) RMSNorm 贯穿全局:从 Gemma3 借鉴,为训练稳定性做出贡献
- Early Fusion 是多模态的未来:信息不再经过瓶颈,视觉信号直接参与深层计算
笔记整理完毕,覆盖 Qwen1 至 Qwen3.5 全系列核心技术。
react framework
type: 教程 status: 已发布 level: 进阶 topic:
- Agent
- 框架工具
手撕 ReAct 框架
ReAct = Reasoning + Acting。它让模型在推理和行动之间交替:先判断下一步,再调用工具,再根据观察结果继续。
ReAct 是理解 Agent loop 的入门框架,但工程里不要迷信“让模型一直想”。你真正要设计的是工具、状态、停止条件、错误恢复和 trace。
基本模式
Question: ...
Thought: I need to search for evidence.
Action: search(query="...")
Observation: ...
Thought: The evidence is enough.
Final Answer: ...
真实系统建议不要存完整 Thought,而是存可审计摘要:
{
"step": 2,
"action": "search",
"args": {"query": "agentic rag evaluation"},
"reason_summary": "Need external evidence before comparing methods.",
"observation_summary": "Found 5 papers from 2024-2025."
}
最小实现
def react(task, model, tools, max_steps=6):
trace = []
observations = []
for step in range(max_steps):
prompt = build_prompt(task, tools, observations)
decision = model.generate_json(prompt)
if decision["type"] == "final":
return {
"answer": decision["answer"],
"trace": trace,
"status": "completed",
}
tool_name = decision["tool"]
if tool_name not in tools:
obs = {"ok": False, "error": "unknown_tool"}
else:
args = decision.get("args", {})
tool = tools[tool_name]
obs = tool(**args)
observations.append(obs)
trace.append({
"step": step + 1,
"tool": tool_name,
"args": decision.get("args", {}),
"observation": summarize(obs),
})
return {
"answer": None,
"trace": trace,
"status": "max_steps_exceeded",
}
Prompt 结构
You are an agent that solves the task by calling tools.
Rules:
- Use only the listed tools.
- Stop when enough evidence is collected.
- If evidence is missing, say what is missing.
- Never fabricate tool results.
Task:
{task}
Tools:
{tool_cards}
Previous observations:
{observations}
Return JSON:
{
"type": "tool_call | final",
"tool": "tool name or null",
"args": {},
"answer": "final answer or null",
"reason_summary": "short auditable reason"
}
Tool Card 很重要
ReAct 失败常常不是模型不会推理,而是工具描述太差。每个工具至少写清楚:
- 什么时候用。
- 什么时候不要用。
- 输入 schema。
- 输出 schema。
- 错误类型。
- 权限等级。
- 示例。
可参考:Tool Card 模板。
常见失败模式
| 失败 | 现象 | 修复 |
|---|---|---|
| 无限循环 | 一直搜索或重复点击 | 最大步数、重复动作检测 |
| 工具选择错 | 本该查数据库却搜网页 | 工具描述加 Use When / Do Not Use |
| 观察过长 | 工具返回淹没关键信息 | 工具层分页、摘要、截断 |
| 过早 final | 证据不足就回答 | evidence gate、引用检查 |
| 幻觉工具结果 | 没调用工具却声称查到了 | trace 强制引用 observation |
| 高风险动作 | 自动付款、删除、提交 | permission tier + human-in-the-loop |
ReAct vs Plan-and-Execute
| 模式 | 适合 | 风险 |
|---|---|---|
| ReAct | 短任务、信息查找、工具反馈快 | 容易局部贪心和循环 |
| Plan-and-Execute | 长任务、步骤明确但需要调整 | 初始计划可能过时 |
| Reflection | 需要复盘和修正的任务 | 反思也可能幻觉 |
| Graph workflow | 状态分支明确、需要恢复 | 设计成本更高 |
评测 ReAct Agent
至少记录:
- 任务成功率。
- 平均步数。
- 工具调用成功率。
- 重复动作次数。
- 证据引用准确率。
- 高风险动作拦截率。
- 成本和延迟。
面试表达
我会把 ReAct 看成 Agent loop 的基础模式,但不会只依赖 prompt。工程实现里会加工具注册表、结构化输出、最大步数、重复动作检测、权限确认和 trace。对需要稳定性的业务流程,我会优先用 graph/workflow 承载确定步骤,只在开放决策点使用 ReAct。
延伸阅读
- ReAct: Synergizing Reasoning and Acting in Language Models
- Anthropic: Building effective agents
- LangGraph
- OpenAI Swarm
context engineering resources
type: 教程 status: 已发布 level: 进阶 topic:
- 框架工具
✴️ 全网最全最优质的上下文工程资源合集
上下文工程(Context Engineering):一门将不断变化的信息宇宙中最相关内容,精心筛选并放入有限上下文窗口的艺术与科学。本质是"熵减"过程——将高熵的原始上下文转化为机器可理解的低熵表示。
🎯 一、核心概念入门(建立框架)
### 1. **The New Skill in AI is Not Prompting, It's Context Engineering**
- 作者:Philipp Schmid(Google DeepMind 高级AI工程师)
- 链接:https://www.philschmid.de/context-engineering
- 核心价值:★★★★★(入门必读)
- 内容要点:
- **首次系统定义**:上下文工程 ≠ 提示工程,是动态系统而非静态字符串
- **六层上下文模型**:指令/提示、短期记忆、长期记忆、RAG检索、工具定义、结构化输出
- **经典案例对比**:简单Demo vs 魔法Agent的区别在于上下文质量
- **核心公式**:正确信息 + 正确工具 + 正确时机 + 正确格式 = 有效Agent
- 适用人群:所有开发者,快速建立术语体系和框架认知
2. 上下文工程技术总结(中文叙事版)
- 包含资源:
- 论文:https://arxiv.org/pdf/2510.26493
- 仓库:https://github.com/GAIR-NLP/Context-Engineering-2.0
- 微信文章:https://mp.weixin.qq.com/s/KbviOJ6q-K4ik_wzsUs2dw
- 核心价值:★★★★★(理论深度)
- 内容要点:
- **历史视角**:上下文工程可追溯至20多年前,非LLM时代新创
- **熵减理论**:RAG(文档→片段)、CoT(模糊推理→逻辑链)、多模态(高熵数据→共享向量空间)
- **2.0核心策略**:
- 文本处理:时间戳标记、功能/语义标签、QA对压缩、层级笔记
- 选择策略:语义相关性、逻辑依赖、时效性、信息去重、用户偏好
- 适用人群:研究者,需要理论深度和演进脉络
🛠️ 二、实战方法论(可落地的流程)
3. Context Engineering for Agents(LangChain官方)
- 作者:Harrison Chase(LangChain联合创始人兼CEO)
- 链接:https://blog.langchain.com/context-engineering-for-agents/
- 配套仓库:https://github.com/langchain-ai/how_to_fix_your_context
- 核心价值:★★★★★(实践框架)
- 四大策略框架:
1. **Write Context(写入)**:Scratchpads、短期/长期记忆、LangMem
2. **Select Context(选择)**:动态检索、工具筛选(BigTool)、RAG优化
3. **Compress Context(压缩)**:总结(递归/层级)、剪枝(时间/令牌)
4. **Isolate Context(隔离)**:多Agent、沙盒环境、状态对象
- 技术栈支持:LangGraph + LangSmith 闭环测试
- 适用人群:使用LangChain生态的开发者,有完整代码示例
4. 12-Factor Agents(工程化原则)
- 作者:Dex Horthy(HumanLayer创始人)
- 链接:https://github.com/humanlayer/12-factor-agents
- 核心价值:★★★★★(生产级方法论)
- 12条核心原则(类比12-Factor App):
- Factor 1:自然语言→工具调用
- Factor 2:拥有你的提示词
- **Factor 3:拥有你的上下文窗口**(最关键)
- Factor 4:工具即结构化输出
- Factor 5-12:状态管理、暂停/恢复、人机协同、控制流、错误处理、小型聚焦、多渠道、无状态Reducer
- 核心观点:
- 80%的Agent是确定性代码 + 20% LLM调用
- 不要盲目信任框架,要拥有核心组件
- 成本呈二次增长,必须优化
- 适用人群:需要构建生产级Agent的工程师
5. phodal/build-agent-context-engineering(中文最全实战)
- 作者:phodal(ThoughtWorks资深架构师)
- 链接:https://github.com/phodal/build-agent-context-engineering
- 核心价值:★★★★★(中文最系统)
- 四大学习路径:
1. **结构化提示词工程**:输入/输出结构化、链式设计、路由分发
2. **上下文工程与RAG**:关键词+语义+图检索、查询改写、HyDE、重排序
3. **工具系统设计**:语义清晰、无状态、原子性、最小权限、MCP协议
4. **Agent规划与多Agent**:预先分解 vs 交错分解、记忆系统、自我完善
- 经典案例:GitHub Copilot上下文优先级排序、Cursor Rule设计
- 适用人群:中文开发者,从零到一构建完整Agent系统
🔬 三、问题诊断与修复(避坑指南)
6. How Contexts Fail—and How to Fix Them
- 作者:Drew Breunig(独立研究者)
- 链接:https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html
- 核心价值:★★★★★(反面教材+对策)
- 四种上下文失败模式:
1. **Context Poisoning(中毒)**:幻觉错误被反复引用
- 案例:Gemini玩Pokémon时目标被污染,陷入死循环
2. **Context Distraction(分心)**:过长上下文导致重复历史动作
- 数据:Llama 3.1 405B在32K时正确率开始下降
3. **Context Confusion(混淆)**:无关工具/信息干扰响应
- 案例:Berkeley测试显示所有模型在多工具场景下准确率下降
4. **Context Clash(冲突)**:多轮对话中信息矛盾
- 数据:分片提示导致o3性能从98.1%跌至64.1%
- 修复策略:动态工具加载、上下文隔离、总结压缩
- 适用人群:调试Agent系统的开发者
7. Practical Tips on Building LLM Agents
- 作者:Paras Chopra(Lossfunk创始人)
- 链接:https://letters.lossfunk.com/p/practical-tips-on-building-llm-agents
- 核心价值:★★★★☆(一线经验+成本考量)
- 6大实战洞察:
1. **任务切分**:每个原子任务≤10-15分钟(METR数据:成功率~90%)
2. **单一LLM+长上下文**:避免RAG碎片化,完整文件入上下文
3. **验证系统**:每步明确成功/失败标准,防止错误累积
4. **重复关键信息**:定期重复待办列表,对抗"健忘症"
5. **工具读写**:让LLM自主构建上下文,而非预填充
6. **缓存策略**:成本呈二次增长(50轮=$2.5,100轮=$100),必须命中KV缓存降至1/10
- 真实指标:Cline错误率从20%降至<5%(用LLM生成diff取代fast-diff模型)
- 适用人群:产品经理、创业者、需要成本优化的开发者
🏢 四、企业实战案例(生产环境经验)
8. Context Engineering for AI Agents: Lessons from Building Manus
- 作者:季逸超(Manus联合创始人)
- 链接:https://manus.im/zh-cn/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
- 核心价值:★★★★★(企业级坑点)
- 核心经验:
- **KV缓存优化**:只追加不修改,命中率提升10倍,成本降至1/10
- **工具遮蔽**:动态显示/隐藏工具,避免上下文混淆
- **文件系统作为上下文**:让Agent读写Memory文件,持久化信息
- **复述操控注意力**:重复关键信息到上下文末尾,提升模型关注度
- **保留错误信息**:不要急于清理错误,LLM需要错误上下文来自我纠正
- **避免少样本陷阱**:Few-shot过多会偏离当前任务
- 适用人群:长任务Agent优化、需要控制延迟和成本的团队
9. Effective Context Engineering for AI Agents(Anthropic官方)
- 链接:https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- 核心价值:★★★★★(Claude团队实践)
- 官方定义:"上下文工程是将不断变化的信息宇宙中最相关内容,精心筛选并放入有限上下文窗口的艺术与科学"
- 三大维度:
- **有效上下文**:提示词、工具定义、Few-shot示例
- **即时检索**:动态工具调用、RAG增强
- **长任务管理**:上下文压缩、笔记系统、子Agent隔离
- 最佳实践:管理有限注意力预算、避免上下文腐烂、数百轮对话管理
- 适用人群:使用Claude系列模型的开发者
10. Brainwash Your Agent: How We Keep the Memory Clean
- 作者:CAMEL-AI团队
- 链接:https://www.camel-ai.org/blogs/brainwash-your-agent-how-we-keep-the-memory-clean
- 核心价值:★★★★☆(内存管理技巧)
- 核心概念:"脑洗"Agent = 主动清理内存,丢弃噪音
- 三大技术:
1. **上下文总结**:提取关键组件、自动触发压缩
2. **工作流内存**:记录过去策略以复用
3. **工具输出缓存**:外部存储大输出,避免上下文膨胀
- 收益:长期任务保持焦点、减少令牌消耗、避免侧任务干扰
- 挑战:信息丢失风险(需要权衡)
- 适用人群:长工作流Agent开发者、开源贡献者
📚 五、学术综述与前沿研究
11. A Survey of Context Engineering for Large Language Models
- 论文:https://arxiv.org/pdf/2507.13334
- 仓库:https://github.com/Meirtz/Awesome-Context-Engineering
- 核心价值:★★★★★(最全综述)
- 研究规模:分析1400+篇论文,160+页
- 内容框架:
- **核心机制**:检索增强、上下文处理、记忆管理
- **优势分析**:性能提升、资源优化、减少幻觉
- **改进方向**:效率优化、评估标准、长上下文挑战
- 分类体系:基础概念、内存系统、RAG、长上下文、结构化数据、自生成上下文、Agent通信、评估
- 适用人群:研究者、需要全景视野的架构师
12. Context Engineering 2.0: The Context of Context Engineering
- 论文:https://arxiv.org/pdf/2510.26493
- 仓库:https://github.com/GAIR-NLP/Context-Engineering-2.0
- 核心价值:★★★★☆(概念演进)
- 核心贡献:
- 提出**上下文工程2.0**概念(Agent中心智能)
- 将CE定位为**熵减过程**的理论框架
- 策略分类:文本处理(时间戳/标签/QA/层级)+ 选择策略(语义/逻辑/时效/去重/偏好)
- 引用网络:连接众多相关工作,建立知识图谱
- 适用人群:理论研究者、需要引文脉络的学术人员
💻 六、开源工具与代码仓库
13. davidkimai/Context-Engineering
- 链接:https://github.com/davidkimai/Context-Engineering
- Stars:4.1K+(社区广泛认可)
- 核心价值:★★★★★(最佳学习路径)
- 内容模块:
- 基础学习路径:从原子概念到元递归
- 可操作模板:数学模型、RAG架构、记忆设计
- 进阶示例:工具集成、上下文修剪、认知工具
- 上下文协议:标准化规范
- Agent系统:完整架构参考
- 引用研究:ICML、NeurIPS前沿成果
- 适用人群:需要深入符号机制和优化的开发者
14. WakeUp-Jin/Practical-Guide-to-Context-Engineering
- 链接:https://github.com/WakeUp-Jin/Practical-Guide-to-Context-Engineering
- 核心价值:★★★★☆(实践指南)
- 七类上下文分解:系统提示、用户输入、短期记忆、长期记忆、RAG、工具输出、结构化输出
- 内容覆盖:基础技术、管理策略、Agent架构、评估方法
- 特色:鼓励社区贡献、项目实践案例
- 适用人群:需要结构化导航的开发者
15. ginobefun/agentic-design-patterns-cn
- 链接:https://github.com/ginobefun/agentic-design-patterns-cn/tree/main
- 核心价值:★★★★☆(设计模式)
- 内容:《Agentic Design Patterns》中英对照译本
- 模式库:提示链、反思、工具使用、多Agent、记忆管理、协议设计、异常处理、RAG集成、生产模式
- 上下文工程关联:通过模式支持连续性和上下文管理
- 适用人群:AI工程师、架构师、产品经理
🎥 七、视频与多媒体资源
16. Context Engineering: The Outer Loop
- 作者:Hammad Bashir(Chroma CTO)
- 平台:YouTube
- 时长:30分钟
- 核心价值:★★★★☆(可视化演示)
- 内容:如何用向量数据库构建外循环动态上下文
- 技术栈:Chroma + 向量检索 + 动态上下文构建
- 适用人群:视觉学习者、需要实操演示的开发者
17. AI Engineer World's Fair Talk: 12-Factor Agents
- 链接:https://www.youtube.com/watch?v=8kMaTybvDUw
- 演讲者:Dex Horthy
- 核心价值:★★★★☆(现场分享)
- 内容:12-Factor Agents方法论现场讲解
- 适用人群:参会者、需要系统理解的学习者
📖 八、电子书与完整指南
18. The Context Engineering Guide
- 出版方:Weaviate
- 链接:https://weaviate.io/ebooks/the-context-engineering-guide
- 核心价值:★★★★☆(完整eBook)
- 章节覆盖:
- Agent架构设计
- 查询增强技术
- 检索策略优化
- 内存系统构建
- 工具集成方案
- 生产级模式
- 特色:实用建筑模式、可靠性保障
- 适用人群:需要系统化学习的开发者
🎯 学习路径推荐
入门路径(1-2周)
- 阅读 Philipp Schmid 的概念文章(建立框架)
- 学习 Drew Breunig 的失败模式(避坑)
- 浏览 LangChain 的四大策略(建立方法论)
进阶路径(2-4周)
- 深入 phodal 的中文实战仓库(系统实践)
- 研读 12-Factor Agents(工程化原则)
- 学习 Manus/Anthropic 的企业案例(生产经验)
专家路径(1-3个月)
- 研读 1400+论文综述(全景视野)
- 实践 davidkimai 的完整学习路径(深度优化)
- 贡献开源项目(社区参与)
📊 核心技术要点速查
上下文工程三大支柱
- 信息检索:RAG、混合检索、Agentic检索
- 记忆管理:短期/长期记忆、反思机制
- 工具编排:MCP协议、工具路由、并行调用
生产环境最佳实践
- ✅ 任务原子化(10-15分钟粒度)
- ✅ 使用KV缓存(只追加不修改)
- ✅ 建立验证系统(每步明确成功/失败)
- ✅ 工具单一职责(原子性+语义清晰)
- ✅ 上下文压缩与隔离(总结+剪枝+沙盒)
- ❌ 避免上下文中毒和冲突
- ❌ 防止过度依赖长上下文
成本优化关键指标
- 多轮Agent成本呈二次增长(50轮=$2.5,100轮=$100)
- KV缓存命中可降低90%成本
- 上下文总结可减少60-80%令牌
🌟 资源价值矩阵
| 资源 | 理论深度 | 实践性 | 代码质量 | 适合人群 |
|---|---|---|---|---|
| Philipp Schmid文章 | ⭐⭐⭐ | ⭐⭐⭐⭐ | - | 所有人 |
| LangChain博客 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | 开发者 |
| 12-Factor Agents | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | 工程师 |
| phodal仓库 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | 中文开发者 |
| Drew Breunig文章 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | - | 调试者 |
| 1400+论文综述 | ⭐⭐⭐⭐⭐ | ⭐⭐ | - | 研究者 |
| davidkimai仓库 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | 深度学习者 |
| Manus案例 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | 企业团队 |
这份合集代表了上下文工程领域(截至2025年)的最新进展,涵盖从理论基础到生产实践的完整知识体系! 🚀
