大模型玩家七七

切分方式，是 RAG 系统里最早、也最难回头的选择 在 RAG 项目里，切分方式通常是最早被确定的部分之一： 文档进来 切一切 建向量 后面再慢慢调   而且在当时，这个选...

最危险的 RAG 错误，往往发生在“看起来很对”的时候 在很多 RAG 项目里，都会经历一个非常相似的阶段： 初期：   chunk 切得比较细，模型经常说“信息不足”  ...

为什么大家都在“省显存”，却越来越说不清显存去哪了 在大模型微调项目里，几乎所有团队都会走到同一个阶段： 显存开始吃紧 batch size 一减再减 sequence l...

模型“记住用户”，从来不是一个瞬间发生的事 在很多隐私事故复盘里，经常能听到一句话：     但如果你真正把训练过程、数据演化、评估日志一段段翻回去看， 你几乎一定会发现：...

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

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

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

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

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

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

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

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

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

LoRA 最容易被误用的，不是原理，而是直觉 在几乎所有 LoRA 微调项目里，都会出现一个非常熟悉的场景。   一开始： rank = 4 效果有点，但不明显   于是你...

这个问题之所以反复被问，是因为大家都在“补同一个洞” 在真实项目里，提出这个问题的场景，往往非常相似。 SFT 已经做过 模型能力基本够用 行为有点不稳 安全、风格、边界总...

很多 PPO 项目，死在“上线前的犹豫” 如果你真的做过 PPO 项目，大概率会有这样一段经历：   第一轮 PPO：     第二轮 PPO：     第三轮 PPO： ...

PPO 在业务里，几乎从来不是“第一选择” 如果你回看真实业务里的模型演进路径，会发现一个很有意思的现象。   PPO 几乎从来不是项目的起点。   项目通常是这样开始的：...

显存是最先“抗议”的那一层 在所有大模型工程问题里， 显存问题出现得最早，也最频繁。   batch 一调大，炸 序列一拉长，炸 多卡一并行，炸 微调一开始，炸   于是很...