恭喜学员拿下大模型独角兽月之暗面offer，总包60w+。从最开始面试被卡，回来做面试复盘，每场面试都录音回听，补齐短板。训练营这边，我布置的实战作业一个都没有落下，项目手动复现吃透。
上岸靠的不是运气，而是方法+强度，逼你在实战中，一步步把能力练出来！！
做大模型应用已有三年，我也经历了最开始欣赏 LLM 暴力美学到慢慢冷静祛魅的过程。
23 年 chatgpt 问世开始，大模型技术和应用日新月异。但每天看了很多论文，最后还是洗数据调 prompt 到天亮。
而用户一方面被嚷嚷着 AGI 要来了，一方面被手上的各种助手蠢到气死。
诚然，基座模型，SFT，RL，每个技术栈每天都有很多创新，但这些创新几乎都是通用的普世的，这些奇技淫巧仍然解决不了很痛苦的落地过程。
仔细想想如何使用大模型，针对性优化这些琐碎的工作是少有人说的，但它们依然重要。
今天想从我的经历中总结一下在业务落地上痛在何处，教训是什么。
这里只吐槽业务落地，纯粹技术上的难点和解决方式都不列了，很多技术文章可以看～
首先破除模型拟人化迷信
【目前】大模型的上限是人类，而且也不总是能达到人类的水平，至少不能指望它像人类一样被“教育”和理解现实世界。
而很多人，尤其非一线开发人员提需求时，下意识会把大模型“拟人化”，比如：“模型很喜欢输出 xxx，怎么纠正它一下“ ”明明 query A 和 query B 一个意思，A 都能做对，为什么 B 不对了？“它是不是不能理解 xxx”。
这背后总假设着：大模型能真正像人类一样，理解世界，鲁棒输出，甚至做错的时候能被“教会”。
但实际上它只是看似像人一样会说话，其原理不过是概率上对人类语言的近似，归根结底是 Transformer 里面一系列矩阵相乘算出来的数值。
时至今日，大模型的可解释性还是很多学者正在研究的课题，因为模型的输出并不像人类的逻辑一样存在一个简单且稳定的变化规律。
所以，模型输出仍然还是一个实验性的事情，要想知道输出会怎么变化，做实验用数据说话而不是理论（甚至想象猜测）是最好方式。
我们需要清醒地认识到，模型只是一个概率模拟器，它并不“意识”到自己正在说什么。
如何正确优化大模型的表现？基本路线不用多说：调 prompt ->积累原始数据->sft->RL。但每一步也都有一些坑点和教训。
调Prompt：一看就会，一上手就废
为什么说调Prompt是个坑？原因如下。
其一，容易忽略隐形上下文。 很多人误认为调 prompt 就是模型不会什么就直接prompt里面说清楚就好，就跟教人做事一样。
但人是有默认上下文的，我们天然生活在整个社会环境创造的上下文里，对话者的身份/教育背景/利益相关等可以创造出不言明自有的“默契”，而 prompt 这种方式很难表达准确这些信息。
比如社会生活告诉我们，找客服投诉的大概率是没遇到什么好事的用户，这些用户可能都不是为了解决问题来的而就是发泄情绪。
那在处理手法上，人类客服就会结合这些信息灵活判断是真的有问题需要解决还是只需要承接情绪（注意这种判断不是可言明的逻辑，它甚至是某种直觉或者经验）。
我们当然可以尽量用一些 few-shot 表达出这种隐形的东西，但更多时候这种直接来源于社会生活的“默契”并不是语言可以说清楚的，更不用说模型能注意到的语言窗口本身也有上限。
其二，忽略了表达之前需要拉齐业务定义。 通用大模型只具备最普世的认知，但很多业务场景下有一些精细化的控制需要垂类场景下的定义，基座模型再强也无法预先把这些业务概念都训进去，如果想表达准确就需要在 prompt 中定义好业务概念。
但有时候定义一件事并不是很简单，比如说“订机票去好玩的地方”，希望模型在遇到模糊的地名的时候不要调某机票的工具而去反问。
但这件事在 prompt 里面怎么写呢？比如先有一段文字定义“什么是模糊的地名”，然后再写遇到模糊地名就 blabla…
那问题来了，“什么是模糊的地名”这个边界并不是基于普世定义，是基于对下游业务工具的认知，工具能检索就是精确地址，不能检索就是模糊地址。
而这些认知靠的是经验而不是文字描述（这也就是某些场景不得不需要数据驱动的原因）。
其三，高估了模型的遵循能力，或低估了我们对遵循准确率的要求。 就算一个说得清道得明的 SOP 放在 prompt 里，也有输出不稳定的风险。
原因同上，模型输出本质是一个概率，遵循能力本身来源于预训练/后训练见过大量指令，模型学到了后面 token 的统计规律。
但我们仍然希望这种业务规则能每次执行都不出错（毕竟都能写成 SOP 了，人不遵循 SOP 是要扣钱的），但概率这个事，就算很大也不太可能是 100%。
只要不是 100% 准确终归有些 bad case 会出现。而且这类 case 大概率都会非常傻，因为能用 SOP 表达的逻辑已经是最简单的逻辑，简单 case 出错会极大降低用户的信任度。
当然，follow 能力会随着基座模型迭代逐步增强的，某些情况下也可以通过定制工具配合模型来降低模型需要达到的能力门槛（这也是业务同学每天要忙活着给模型兜底的所在）。
转向数据驱动？迎接精细化样本维护的挑战
基于以上坑点，某些时刻我们就会寄希望于数据驱动，比如 sft 或者 RL。
当然这里会有另一个活儿等着我们，比如需要做精细化样本维护。
无论 sft 还是RL，都绕不开数据。数据的构建流程大致可以分为：数据构造→评测集构造→badcase 收集→为解决 badcase 构造数据→评测…循环往复。
数据构造的奇技淫巧有很多，比如反向构造，用多次推理出的更优输出作为 label，比如大模型辅助改写以一换多，每个业务可能都有每个业务的秘密武器，就不用说了。
无论如何，某一版数据训出来的模型在线上或者评测集都有或多或少的 bad case，我们希望怎么改造训练集解决 bad case？
换句话说就是希望通过增加/删除/改造其中的某部分样本让模型做对这些 badcase（同时保证其他 good case 不变）。
但这不是那么丝滑的过程。比如判断这个 case 是模型训练时见过没做对（需要改）还是没见过（需要增）。
这里的“见过”不应该根据字符串匹配或者某种文本距离判断的，而可能是某种更细粒度的句式模式决定的。
比如 3 个 query：
1. 飞机去南京
2. 定飞机去南京
3. 飞机去寒冷的西伯利亚我要九点到
从文本相似性来说 1 和 2 是更相似的，但如果模型实际只是对“飞机去 xx”这种句式不理解是“定飞机去 xx”的意思，那 3 才是我们应该多多加入的样本。
因此需要做训练样本维护，每次增加/更改样本的时候都需要给一些样本标记，标志这个样本跟什么特征相关，为了解决什么 badcase 而更改。
比如“飞机去南京”被标记了“飞机去 xx”这个标签，下次再有“飞机去北京”做错就统一把“飞机去 xx”下的所有样本拉出来看看有没有问题。
除此之外业务逻辑也经常需要为了适配工具（或者需求调整）变更输出的形式，这涉及到训练集的每个 label（或者 RL 里的 Reward 标准）都需要频繁调整，此时样本标记也能辅助筛选需要变更的样本，但更多的手工活儿也不可避免。
而且由于这些特征标记是随着训练评测迭代才逐步发现的，所以还需要定期回归给旧样本丰富更新的标签。这里有很多人为的工作，也是一个比较痛苦的过程。
（暂时想到这些，想到新的就补充，没有后续就是没想到）
总而言之，有很多本以为很简单的事情做上来并不如我们的预期一样顺利，这些工作其实也应该被讨论和设计。
长远来看，减少应用迭代的难度，就是在减少【交互信号-开发-新的交互】整个迭代链条的时间。毕竟人类是迭代链条最短的，可以在几秒内学习+思考+作出改变。
如果某天模型能像人类一样能将用户交互的数据直接用于迭代，那能力的增速将是不可想象的。如果你也在大模型落地过程中遇到过类似的纠结或有不同的见解，欢迎在云栈社区分享你的实战心得。
作者：fjy7231，已获作者授权发布
来源：https://zhuanlan.zhihu.com/p/2004613266626872875
发表于 2026-2-12 20:25:42
|
查看: 37|
回复: 0
