混合专家 MOE：不再追求大而全，转而追求多而专精
《DeepSeek 原理与实践》第 3 篇：deepseek 极限潜能 – MOE。
最近几周自学 deepseek 原理+应用+实践，一些成果，和大家分享：
- 小众关心的，deepseek 核心技术原理；
- 大众关心的，提示词要怎么写；
今天和大家聊聊，deepseek 的核心机制之一的混合专家 MOE。
什么是混合专家 MOE？
混合专家，Mixture of Experts，该模型思路不再追求大而全，转而追求多而专精。它会将任务动态路由给各个领域专家，并将各个领域专家的输出进行组合。
比较抽象，举个容易理解的例子。
大而全模型：全栈工程师。
混合专家模型：Java，FE，QA，DBA，OP 工程师…
大而全的模型有什么不足？
- 训练时间长：培养一个”全栈”工程师太久了；
- 计算性能差：面对一个产品需求，做设计编码上线周期长；
- 回复不深入：什么都懂，但都不精，浅尝辄止；
而混合专家模型则能够很好的解决上述几个问题：
- 培养一个 Java 工程师的周期更短；
- 需求评审完之后，Java，FE，QA… 多个专家可以并行设计编码上线；
- Java，FE，QA 专人专岗，专业性高；
有了 MOE 之后，对 LLM 的架构有怎么样的影响？
学习与训练阶段
之前：追求多参数
如今：训练多专家 Expert（例如：1 万个专家，每个专家单一职责 SRP）
计算与执行阶段
之前：收到提示词 input，一上来就干
如今：
- 先判断，需要几个专家（分类任务，很容易）；
- 动态路由（需要一个门控网络作为协调者，Gating Network），分发任务给专家，专家并行计算；
- 组合专家输出，协调者再统筹输出；
input[提示词] --> 专家分类{专家E1E2...En}
门控网络 --> E1E2...En
E1 --> O1[输出1]
E1 --> O2[输出2]
...
En --> On[输出n]
O1O2...On --> 统筹输出[output]MOE 对我们写提示词，获取更佳的回答质量有什么启示呢？
如果觉得 AI 回复缺乏深度，可以显性告诉它，你希望它扮演什么专家角色来回复问题。
模型分类出来的专家角色不一定100%准确。
bad case：如何设计高并发高可用系统？
这样的提示词，你会得到一个泛泛而谈的回答。
good case：假设你是由以下专家组成的团队：
- 分布式领域系统架构师
- 电商领域业务架构师
- 资深DBA
请分别从各自领域提出5项技术选型建议，并组合设计方案满足每秒10万次交易，数据满足最终一致性，故障恢复时间小于30秒的系统。
节省训练资源，缩短回复时间，提升回答质量，多个专家还能够交叉验证（大而全模型可能过拟合），deepseek 创新性使用 MOE 之后，很快就得到了业界的广泛认可与复制。
deepseek，流弊！
总结
- MOE 是 deepseek 的核心创新应用（之一）；
- 从此大模型从”大而全”转向”多而精”；
- 提示词通过显性告诉 deepseek 专家角色，能够最大化发挥 MOE 的潜力；
一切的一切，提示词只有适配了 AI 的认知模式，才能最高效的发挥最大的作用。
检验一下
想深挖一层，读这篇：《Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer》（Shazeer 等，2017），PDF，可下载。
本篇的门控网络（Gating Network）、动态路由，出处就是这篇被引 5000+ 的 MoE 原始论文。很多人叫我不要再推荐论文了，=_=
MOE 让模型内部有了一群专家，可问题来了：专家这么多，回答问题时怎么快速找到对的人？——第 4 篇，我们讲知识图谱激活。
知其然，知其所以然。思路比结论更重要。