修改基础模型做创新
寻找创新
本文何时适合食用？
“——当我们找到好的基础模型之后，打算在它上面做一些创新的时候。”
仅供参考，并非有效方式，只是个人视角，有局限且狭隘
我看到有人直接拿到基础模型的代码之后，就直接让codex去找创新去修改，去验证。这等于直接让赛跑运动员原地转二十圈后闭着眼奔跑，你不会知道他在做什么，他也不知道，又怎么会能到达终点？
正确的打开方式肯定是：
1.我们拿到了基础模型的代码，此时我们完全看不懂。但感谢有codex和gpt。我们可以使用codex来阅读仓库代码，让他为我们生成教程.md，让我们阅读。我们进一步可以将md投喂给gpt，让它来给我们讲解项目。这样一来，我们才能对我们的基础模型有些了解。至于将md投喂给gpt还是gemini，deepseek还是豆包，都随你便。你想了解项目代码流程，反正md已经有了，这里只不过是谁解释md罢了。
2.我们需要和gpt进行对话，投喂md以及基础模型的论文。在gpt建立一个项目文件夹在此进行。
3.最漫长最关键的一步。
我们需要和gpt经过无数轮的讨论才能得到我们的创新。
（1）因为你有过第1步，你知道代码流程，如果你的小脑袋瓜灵光一闪，被你想到了一个改进办法，肯定是和gpt及时沟通，看他觉得这个方法如何，以及有没有人干过。有人干过也不会是完全一样，借鉴或者不借鉴嘛
（2）当然也可能是你喜欢读论文，搜罗了今年或去年顶刊定会一会论文。看一下他们创新点，诶，这个是不是不错，我拿来用？就把呢篇论文投给gpt在和它讨论，
（3）也可以直接问gpt，我这个咋创新，这个比直接问codex好点，但是依旧不是呢么靠谱。但是也可以试一下，只不过大部分应该都没啥用
（4）也可以是你觉得哪个模块要修改，你去搜这个模块替代品的论文看。或让gpt推荐一些替代该模块的论文，去找找灵感。
我的第一篇应该就是（1）（2）（3）(4)全都有，最后怎么得出来创新点我都忘了，反正就是要挺久，以及挺充分的讨论。之后再修改看指标了。和gpt讨论出来的，我感觉可行的方法还挺多。但是最后指标提高的可能就一两个吧。
4.如果真的讨论出来一些东西。就开始让codex改呗。让gpt给方案，让codex执行即可。
这里不得不插入一些东西：我们如果直接修改了，没啥用？咋回退？
这里就是两个习惯了：（1）一些人喜欢设置配置项，就是搞配置文件，设置bool条件启动创新1，否则就不用。你可以随时切换回去。让codex做，他会知道的。（2）一些人使用git比较顺手。就会把基础模型提交为git作为main，每一个创新改动就是一个分支，在这个分支做该创新。该创新分支不成功就再从main拉取一个就可以了
5.执行的不错，在一个数据集上一个随机种子跑的不错。就扩展到全部数据集看看呗。只要指标和之前差不多或者高一点，就可以。之后再优化参数啥的不就高得多了。我们还只是初步替换，其他适配还没做呢，就持平或高了，肯定是有效果的。如果全部数据集时间长，要放到超算，就放超算呗。用作业形式提交，提交完就不用管，等着第二天三天看结果就行了。