大模型玩家七七

很多 RAG 系统的问题，早在 TopK 之前就注定了 在 RAG 系统里，TopK 往往被当成一个“显眼参数”： K 设小了 → 召回不够 K 设大了 → 模型胡说   于是大家花大量时间在调： T

梯度累积，几乎是所有 OOM 的“第一反应” 在大模型训练里，只要显存一炸，几乎一定会有人说一句话：     这句话出现的频率，可能仅次于：     而且很多时候，梯度累积确实能救命： batch s

几乎所有多任务项目，都会经历“该不该拆”的阶段 如果你做过共享 backbone 的多任务微调，一定会经历这样一个阶段： 一开始：     中期：     后期：     于是会议上开始出现一句话：

多任务微调里，最危险的不是任务多，而是比例随意 在很多多任务微调项目中，任务比例往往是这样定下来的： 这个任务数据多，就多一点 这个任务重要，就多一点 实在不知道，就先平均   当时大家心里想的是：

很多系统“看起来懂了”，但只是凑巧对了 如果你做过 RAG 或向量检索系统，一定有过这样的时刻： demo 很顺 常见问题命中率不错 向量召回结果“看起来挺相关”   但一到真实使用，你会发现一些非常

几乎所有 OOM，都是“我以为还能再加一点” 如果你做过大模型微调，你一定经历过这种时刻： batch size 调小一点 → 能跑 sequence length 加一点 → 还能跑 两个一起微调

隐私问题，往往不是在预训练阶段爆出来的 在很多团队的认知里，模型隐私风险通常被认为是： 预训练阶段的问题 大模型“吃了太多脏数据”的后果 离业务微调很远的事   但现实中，一个非常反直觉的现象是：  

评估会议上，真正被消耗的不是时间 如果你回忆一下那些持续时间最长、气氛最微妙的会议， 大概率不是在讨论模型训练方案，而是：   评估会议。   那种会议通常有几个共同特征：   PPT 越做越厚 指标

你以为是在“用框架”，其实是在“被框架塑形” 几乎所有微调项目，在最开始选框架的时候，心态都是一样的：   “先把模型跑起来最重要。”   于是大家会选择一个： 文档齐全 Demo 好跑 社区活跃 看