如果你真的做过 PPO 项目，大概率会有这样一段经历： 第一轮 PPO： “哇，这个方向有点东西。” 第二轮 PPO： “效果更明显了。” 第三轮 PPO： “好像是更对齐了……但我有点不踏实。” 第四轮 PPO： “这个版本，我们真的敢上线吗？” 奇怪的是：loss 没炸reward 曲线也挺好看一些坏 case 明显少了 但你就是不敢按下上线按钮。 这不是心理问题，而是一个非常理性的工程信号。

如果你回看真实业务里的模型演进路径，会发现一个很有意思的现象。 PPO 几乎从来不是项目的起点。 项目通常是这样开始的：先用 base model 跑通再 SFT 一轮再接 RAG、规则、策略直到某一天发现： “模型行为好像总差一口气。” 这时候，PPO 才会被拿出来讨论。 这本身就说明了一件事： **PPO 不是用来“让模型变聪明”的，而是用来“修正模型行为”的。** 如果你一开始就指望 PPO

在所有大模型工程问题里，显存问题出现得最早，也最频繁。 batch 一调大，炸序列一拉长，炸多卡一并行，炸微调一开始，炸 于是很多人会下意识得出一个结论： “模型太大了。” 但如果你认真看过一些长期稳定运行的系统，会发现一个很反直觉的事实： **它们用的模型不一定更小，但显存问题却很少成为“持续性困扰”。** 这说明一件事：显存不够，很少是模型尺寸本身的问题。 显存报错频率 vs 项目阶段示意图 

几乎每一个 AI 项目，在立项时都会有一个隐含共识： 只要模型足够强，项目就能跑下去。 这在项目早期看起来是完全正确的。模型效果一出来demo 能打领导能理解投资人也买账 但如果你回头看那些真正活过两年、三年、甚至更久的项目，会发现一个很残酷的事实： 它们活下来的原因，几乎从来不是“模型做得最好”。 相反，很多模型非常强、技术非常先进的项目，反而死得很快。 不是因为模型不行，而是因为项目把“活下去

如果你回看绝大多数客服系统的第一版架构，都会发现一个非常一致的特征： 模型在最中心。 用户进来，模型理解；模型判断，模型回答；模型错了，再调模型。 这在项目早期是完全合理的，甚至是唯一可行的方式。规则不全场景不清楚数据也不够 这时候不靠模型，系统根本跑不起来。 但问题在于：几乎所有最终能长期稳定运行的客服系统，都会离开这个状态。 而这条从「模型驱动」走向「策略驱动」的路，不是架构升级，而是一种责任

很多项目在复盘时，都会给自己一个“看起来合理”的结论：架构选错了代码写得不够优雅技术方案不够先进 这些结论并不是完全错误，但它们有一个共同的问题： 它们几乎都发生在项目已经失控之后。 在真实工程里，代码层面的异常，往往是最晚显现的症状，而不是病因。 项目真正开始失控的地方，通常要早得多，也隐蔽得多。  项目失控时间轴——早期决策 vs 晚期代码问题 我们先把一件事讲清楚。 在一个真实项目中，代码承

如果你认真回想一下，会发现一个很有意思的现象。 第一次用到这些词的时候——第一次上 LoRA第一次跑 PPO第一次把 RAG 接进来第一次听说 DPO 它们几乎都真的帮过你。LoRA 让你显存不炸RAG 让模型突然“知道很多事”PPO / DPO 让模型行为“看起来更对齐” 但问题在于：这些词第二次、第三次、第四次出现时，往往已经不是在帮你了。 它们开始被用在一种非常危险的语境里： “是不是该上一

在微调项目里，有一个非常反直觉的事实： **失败的项目，很少是“明显跑不动”的；更多是“看起来还能继续优化”的。** loss 还能降一点，参数还能再试一组，模型似乎也没完全崩。 于是你会不断告诉自己： “再调一版看看吧。” 而真正危险的地方就在这里——你第一次该停下的时候，通常并不会有一个明确的报警信号。 在展开之前，我先把这篇文章最重要的一句话写出来： **当你继续调参数，主要改变的已经不是“

几乎所有第一次真正用上向量数据库的人，都会经历一个相似的瞬间。 你把文档丢进去，算 embedding，建索引，然后一搜：关键词没匹配但语义“对上了”返回的内容看起来很像人类会想到的结果 那一刻你很容易产生一个判断： “这东西，比关键词检索高级多了。” 而这，恰恰是向量数据库最容易被误用的起点。 因为你很快就会把它从：“一种能力工具” 变成：“一种默认决策机制” 然后，问题开始慢慢出现。 在正式展

如果你问一个已经稳定运行了一年以上的客服系统团队： “你们一开始的设计，就是现在这个样子吗？” 几乎所有人都会笑一下，然后说： “不是，差得挺远的。” 这是一个被严重低估的事实。 客服系统不是一个“设计完就上线”的系统，而是一个会在真实用户、真实纠纷、真实事故中，被不断“修正”的系统。 从 0 到稳定，它真正经历的不是技术升级，而是一轮又一轮认知的被打碎和重建。 所有客服系统的起点，几乎都是一样的

如果你参与过真实的客服系统项目，你一定对下面这个场景不陌生。 模型上线后，陆陆续续出现一些问题：话说得太满不该答的问题也答了某些边界情况回答很危险用户开始“钻空子” 于是会议室里自然会出现这些讨论：“模型理解还是不够准。”“要不要再微调一版？”“是不是参数还能再调一下？” 在项目早期，这种反应是正常的。但如果一个客服系统已经跑了一段时间，问题仍然被不断归因到模型，那通常说明一件事： 系统走错方向了

在很多大模型项目里，都会出现一种非常熟悉的场景。 模型上线后，偶尔会出现一些“让人皱眉”的回答，于是会议室里开始出现这些声音：“模型这里理解错了。”“这个场景模型还是不够聪明。”“要不要再微调一版？” 一开始，这些讨论是合理的。但如果你发现：同一类问题反复出现每次都在讨论“要不要再调模型”却很少有人问“这个判断本来该不该交给模型” 那这通常意味着一件事： 你已经开始让模型背它不该背的锅了。 而这，

如果你认真回顾一下身边的大模型项目，会发现一个非常普遍、却很少被明说的状态：微调流程是通的loss 是正常的demo 看起来也不错但模型始终停留在「内部试用」「小范围验证」 真正要上线的时候，大家会变得异常谨慎，甚至开始拖延。 会议里常出现的话包括： “再多测一轮吧。”“感觉还有点不放心。”“先别放给真实用户。” 但如果你追问一句： “具体不放心什么？” 很多时候，答案是模糊的。 这不是因为你不专

几乎每一个微调项目，都会经历同一个阶段：一开始，参数真的很有用learning rate、batch size、epoch 调一调模型明显“变了”，效果也肉眼可见 但只要项目继续往前走，你迟早会遇到这样一个时刻：参数还在loss 还能降但你隐约感觉到——再调下去，好像也只是“换一种不对”。 很多团队就是在这个阶段，把项目调死的。 因为他们做了一个非常自然、但非常致命的判断： “既然是模型问题，那就

如果你问一个真正跑过多个微调项目的人，最让人后悔的决定是什么，答案往往不是：learning rate 设错了batch size 选小了LoRA rank 不合适 而是： “当时其实已经该停了，但我们还在继续调。” 这是一个非常真实、也非常普遍的工程问题。 因为在微调项目里，“继续调参数”看起来永远是一个积极、努力、负责的选择；而“停下来”看起来却像是：放弃妥协或承认前面哪里不对 但工程经验恰恰

很多工程师第一次被微调“背刺”，都是同一种体验。 你把训练跑起来，loss 稳稳往下走，甚至还挺漂亮：没有发散没有震荡learning rate、batch size 看起来都合理validation loss 也不高 你心里会有一种踏实感： “这次应该稳了吧。” 然后把模型拿去做一轮业务评测，或者小流量灰度，结果出问题：回答变得更笃定该拒答的问题反而更敢答同一类边界问题更容易越界输出风格更统一，

如果你刚开始做大模型微调，参数往往不是你最关心的东西。 那个阶段，你更在意的是：能不能跑起来loss 会不会降模型是不是“有点变化” 但当你走到一定阶段，会突然发现：同样的数据同样的代码只是改了几个参数 模型的行为却发生了明显、而且难以预测的变化。 这时候你会开始意识到： **参数不是“细节”，而是系统稳定性的一部分。** 这篇文章要讲的不是：learning rate 怎么设batch size

在技术社区里，如果你说： “我们最后没用向量数据库，退回关键词检索了。” 很多人会下意识觉得这是：技术倒退能力不足或者项目失败 但如果你去看真实工程项目，会发现一个很有意思的现象： **真正成熟、长期运行的系统里，“退回关键词检索”并不少见，而且往往发生在系统已经经历过一轮复杂化之后。** 也就是说，这不是“从没见过世面”，而是见过之后，重新做的选择。 很多讨论之所以跑偏，是因为默认了一个错误前提

在几乎所有 RAG 项目里，TopK 都是一个被频繁动手、但极少被认真反思的参数。 一开始大家都很谨慎：TopK = 3TopK = 5 效果不错，系统也算稳定。直到有一天，某个问题答错了。 排查下来发现：检索里“好像没捞到关键那一段” 于是有人说了一句非常符合直觉的话：“那就把 TopK 调大一点吧，多给模型点上下文。” 于是：TopK = 8TopK = 10TopK = 20 短期内，系统似

如果你做过一段时间 RAG，你大概率会经历这样一个过程：一开始效果不错后来偶尔答歪再后来开始靠感觉调参数最后系统“还能用，但谁也不敢保证稳定” 而在这些系统里，几乎一定会出现同一组操作：切分感觉不太对 → 切小一点命中不稳定 → TopK 调大一点再不稳 → 再切碎一点 + 再加 TopK 表面上看，这是在“补救”；实际上，你正在同时拧动两个最危险的旋钮。 切分和 TopK，从来就不是两个可以独立