前几天让一个大语言模型帮我把产品说明改写成给客户看的邮件。改到第三遍，语法没问题，信息也都在，可读起来就是有点硬。说不上错，是不合适。这种“不算错但不对”的瞬间，比它干脆答错更值得琢磨。
用久了会发现，它出错的方式是有规律的。理解这一点，比记住它能做什么更有用。
它擅长的是“接下来大概会说什么”
大语言模型的训练目标很朴素：给定前面的文字，预测下一个词最可能是什么。这个目标被重复无数次之后，模型学到的是语言里那些常见的搭配、句式和展开顺序。所以它写通知、写摘要、把一段话换个说法，往往顺手，因为这些文本在语料里出现过太多次，模式很稳。
反过来，越是非常规的表达、越是只有你所在的小圈子才用的说法，它越容易滑向“通用版本”。并非它偷懒，它的目标函数本来就在往平均靠。
答不上来时，它通常不会说“我不知道”
更麻烦的是另一类情况。你问一个只在内部文档里出现的术语，或者让它按一份它没见过的模板整理内容，它很少停下来，而是给出一个看起来合理的答案。格式对，语气对，内容似是而非。
这背后是它没有把“我不确定”当成默认动作，并非知识多少的问题。语言的连续性太强，一段通顺的话会自动往下走，中途停下反而需要额外的机制。于是人得自己承担校验那一步：读一遍原始材料，对一下关键数字，看看引用的说法有没有出处。
检索、改写要求、微调，解决的不是同一件事
常见的几种补救手段，作用点其实各不相同。
- 把外部资料放进上下文，是让它“看着材料说话”，能缓解凭空编造，但材料本身对不对，它不判断。
- 把要求写清楚，是在缩小它的猜测空间。说清读者是谁、要多长、要什么语气，输出会稳定很多。
- 微调改变的是它的表达习惯，让它更贴合某类业务的口吻，但它不会因此多出事实依据。
三者都往“更贴合”的方向走，没有一项能替你判断“这段话该不该发出去”。
说清楚“好”的标准，比训练更难
评估是个容易被低估的环节。同一个回答，写文案的人觉得啰嗦，做客服的人觉得刚好；今天的标准明天可能就变。很多团队在把大语言模型接进业务流程时卡住，症结往往不在模型够不够用，没人能一句话讲清“我们要的输出长什么样”，这才是关键；这件事没法外包给模型自己。
我的判断是，把它当成一个读过很多材料、但没有具体处境的合作者比较合适。它适合起草、改写、把模糊的想法铺开成几个方向；不适合替你做取舍。留一道人工确认的工序，是分工本来就该这样，并非不信任它。
回到那封邮件。最后是我自己改的两句话，把语气放松下来。它给的骨架其实好用，只是收尾那点分寸，还得人来。