
故事的开始是使用了谷歌的Gemini就广西水患进行原因分析。
我好奇it为什么会知道最近发生的事,还知道是七月的,我以为他使用了RAG技术。
意外得出动态参数微调的方案。
我好奇这种动态参数微调会不会影响原有的模型在某些任务上的表现;
it提出了混合的动态参数微调方法,其中注意到用5%的新数据搭配95%的旧的经典数据(筛选过的)来使得微调后的模型在擅长的任务上维持表现,同时又能获得新的知识,而不依赖于外部的RAG及技术。
得出RAG的优势:量大管饱、更新快、不用对LLM进行增量式预训练+微调
专家模型的增量式微调
通过门控网络来判断哪些专家参与接收这些数据,这样只有涉及到该此增量训练的专家的神经网络参与前项传播与反向传播,由此带来算力开销。下面表格举例,着重看最后一列动态切换,“洪水数据”时代码专家在歇着,Python代码”时,代码专家立刻被激活。
| 维度 | 传统冻结参数(如 PEFT / 局部 Frozen) | MoE 的稀疏激活(Sparse Activation) |
|---|---|---|
| 决定谁不参与的人 | 人类工程师。在训练前写死代码,指定哪些层不参与训练。 | AI 路由网络自己。在训练过程中根据输入数据动态决定。 |
| 状态是固定的吗 | 绝对固定。整个训练周期内,被冻结的参数雷打不动。 | 动态切换。上一秒处理“洪水数据”时代码专家在歇着;下一秒混入的旧数据是“Python代码”时,代码专家立刻被激活开始打工。 |
| 参数会发生微弱变化吗 | 绝对不会,梯度直接为 0。 | 路由网络自身在变。虽然闲置专家的参数没动,但负责分发数据的“路由网络”参数一直在调整,它在学习未来如何更精准地分发新旧知识。 |
在解答“什么是专家模型,与激活参数的实际关系是什么”的问题中,我了解到**总参数量(Total Parameters)和激活参数量(Active Parameters)**的关系,前者是模型运行所需占用的显存的容量,决定了模型本身的知识储备量,后者的则是单次计算时的计算量,决定了推理的速度(计算量越小,推理速度越快)。
另外,解答了一点,专家模型的任务划分并不是按具体的代码任务或者知识任务来划分的是按照token级别的纬度来划分的,因此激活专家的组合是在不断切换的。
最后,回答了端侧蒸馏模型的应用,失去了大量的知识储备,保留了原有的推理思维链就,部署于手机车载设备等相对低性能终端。也就是说,蒸馏后的小模型并不是没有脑子,而是没有知识。
提出新问题:针对蒸馏后的小模型,用于部署端侧,比如手机或者车机等设备,这种小模型呢,它保留了原有的思维链,也就是思维,但是它缺少了知识储备,那么我们想法来了,这里我们加RAG技术,通过联网或者自建局与知识库,来增加知识储备和更新知识,这样的话那他岂不是和大模型相差无几了?
回答依旧提出了 致命的“长文本上下文窗口(Context Window)”,就是说RAG 的本质是把知识库里检索出来的几千甚至上万字,一股脑塞进模型的 Prompt(提示词)里,小模型上下文很短,外加上本地算力限,很容易导致推理时间过长,然后缺失这种端侧模型的优势;
另外还提到小模型,语义理解能力差,若使用RAG塞入到提示词中的大量信息,则会造成干扰,面对这种干扰时,小模型的语义理解能力展现出明显的劣势。
因此,可以通过对信息进行预先处理,如通过替换一些晦涩难懂的词等等,将要处理的信息范围限制在小模型能够理解的范围之内,这样处理后再交给小模型。
意外收获:在面对RAG给出的信息时由于小模型会受到干扰,因此小模型的 RAG 知识库投毒 / 提示词注入方向 可以做做文章。
题外话:详细了解什么是RAG?与向量数据库检索有什么关系?
RAG并不等于向量数据库检索,涉及检索(Retrieval)+ 增强(Augmentation)+ 生成(Generation)的有机结合都叫RAG,这包含搜索引擎的信息检索、知识图谱的信息检索等。下面有个具体的RAG实例:演示了RAG检索信息->组装prompt->生成回答的全过程

详细了解什么是专家模型,与激活参数的实际关系是什么?
