深度学习工程师藏在代码里的重构三准则

　　上线那晚，我在茶水间抠咖啡渣，后端老张拎着保温杯进来，说模型服务崩了三次——不是报错，是返回结果飘了半度。我原以为是GPU温控，结果发现训练脚本里有个叫loss_warmup_v2_fix_final_better.py

文章配图，仅供参考

　　白板上还留着上会写的字：“数据漂移需动态补偿”，底下被谁用红笔圈了三遍，旁边画了个歪斜的箭头，指向“但loss不稳时先切回旧权重”。没人擦，也没人认领。

　　我火大不是因为又回滚，是那个命名——v2_fix_final_better，它根本不是v2，是v7改名成v2，又在v2上叠了三个临时分支，最后合并时把前年写的梯度裁剪逻辑给删了。你猜怎么删的？git log里写“移除冗余clip_grad”，可那玩意儿当年救过我们两次OOM。设计小林当时在会议室门口听我说这事，叼着烟笑了：“你们工程师连‘冗余’都敢随便定义？”

　　其实深度学习工程师藏在代码里的重构三准则，压根不是什么最佳实践——是优胜劣汰。活下来的函数名都带点卑微，比如apply_sanity_check_if_not_in_test_mode，长到IDE要换行；活不下来的全是core_optimize_v3这种，听着像老板拍板的PPT标题，结果第一轮AB测就跪了。上个季度我们拖了仨月，就为让一个get_features函数能同时接住新特征工程、老特征缓存、还有测试环境硬塞的mock向量——最后妥协成get_features_with_backwards_compat_fallback。我说这名字太长，后端反手扔来个PR，加了个type alias叫feats，结果第二天跑CI全挂，因为某处import feats导入的是另一层目录下的同名模块……妈的，是feats，不是FEATS，也不是Feats，就他妈是feats。

　　测试群一直在响，消息刷得比loss曲线还癫狂。有人说“label smoothing设成0.1是不是该开开关？”，我说开，十分钟后有人回“开了，acc涨0.03，F1跌0.07”，然后沉默两分钟，老板发来一句：“先关了，下周一同步策略。”我就站那儿，看着窗外天黑了，路灯一盏盏亮起来，跟显卡指示灯似的，一闪一闪，没规律。

　　我原以为重构靠共识，结果靠遗忘——谁记得三个月前某个PR里改掉的batch_norm momentum值？反正我不记得。我们重构不是因为想得清楚，是因为某个实习生在debug时顺手把_legacy_input_handler里那个while True改成了if，结果线上推理延时降了23ms，没人敢动，就让它挂着，成了新的事实标准。这算哪门子准则？这是幸存者偏差写进.gitignore里。

　　外卖到了没人拿，塑料袋在前台桌上堆成小山，纸袋边角卷着，汤渗出来，在桌面留下淡褐色的印子。去年这时候，前端阿哲离职前最后一周，把整个infer pipeline里所有predict()方法统一重命名为__infer_raw__，说是“避免和torch.nn.Module.predict冲突”——结果两周后我们升级PyTorch，他们真加了predict()。他走那天我问他图啥，他说：“就为了让后来人骂我的时候，至少得读三行注释。”

　　我真服这种蔫坏的智慧。所以现在看到v2_fix_final_better，我直接重命名为maybe_loss_stable_enough_for_qa，加了warning日志，还让测试同学手动勾选“信任此版本”。设计小林路过看一眼，说：“你这名字比我们上次改版的按钮文案还诚实。”我说是啊，按钮文案写“一键发布”，实际点下去先弹五层确认框，最后一层写着“已忽略校验，后果自负”。

　　其实最惨的不是命名混乱，是大家早默认了：只要loss下降，不管函数叫什么，都是对的。上周我看见一个同事把optimizer.step()包进try-except，except里直接return None，还写了注释：“防nan-step致训练中断”。我说你这等于告诉系统“断了也别停，接着糊弄”。他耸耸肩：“糊弄三年了，糊弄得挺准。”——结果那天晚上，他工位空着，椅子还热乎，桌上泡面桶底下压着半张纸，潦草写着：“loss曲线下方区域面积≈收敛置信度”。我没动它。反正明天清洁阿姨会收走。

　　我今天打算干件事：把所有带“fix”“final”“better”的文件夹，批量重命名为“tentative_v0”——不是真v0，是v0 with asterisk and a sticky note stuck on the monitor that says ‘don’t trust this, I’m asleep’. 但我估计改不完。下午还要去跟老板吵——不是吵技术，是吵要不要把training loop拆成两个repo，他觉得“耦合是信任”，我说“信任是等你半夜三点收到告警后，还能想起那段代码是谁写的”。

　　哦对，我抽完这支烟就回去改。不是为了交付，是刚发现maybe_loss_stable_enough_for_qa这个函数，调用了两次validate_input，中间隔了整整四百行，其中三百行是用来做feature scaling的条件判断……但第一次validate完已经把input clone了，第二次validate传进去的是clone的clone。它居然没崩。它居然work。它甚至比原来的快那么一点点。我坐在那儿，盯着pylint标出的红色下划线看了十分钟，然后删掉了第二次validate。没写comment。就删了。反正没人review，也不指望谁懂。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!