几年前，我负责一个时间序列流水线：用LLM给产品评论打分，1到10分。评论源源不断进来，分数实时流入仪表盘，产品团队每周一早上查看。一切平稳运行了几个月。直到某个周一，图表上出现了一道台阶。
前一周评论平均分6.4，这周突然变成7.6。同一款产品，同一批用户。我回头去读那些评论，内容和全年收到的没什么区别。
模型变了。供应商悄悄更新了权重，上周打6.4分的LLM，现在给同样内容打7.6。仪表盘里所有历史对比瞬间失效。清理数据花了一周。更难的对话是：我们之前的报告，到底有多少是真实的？
这种故障，是LLM在生产环境的默认行为。想用更严格的参数或固定版本来消除它，是打不赢的仗。真正的工作是设计一套能容纳它的系统。这个道理我学了两次：一次来自评论流水线，一次来自养两个孩子。
幼儿父母早就懂的非确定性
如果你经历过 toddler 阶段，这个实验你已经默默做了几百次，只是没叫它实验。上周每天吃得精光的午餐，周二突然被坚定推下桌。连续六晚管用的睡前故事，第七晚失效。保姆发誓靠谱的午睡流程，你刚把它叫成"规矩"，它就崩了。
有经验的父母最终会停止强迫孩子确定性。模式和趋势仍然重要，但你不再期待特定输入产生特定输出，而是建造一个能吸收方差的系统。生产AI工程师通常在第一次校准回归后，也会完成同样的转变。
LLM作为评判者也会漂移
评论流水线让我明白：评判者可能是系统中最脆弱的一环。被评估的模型会漂移，做评估的模型也会漂移。没有稳定的锚定点，你无法判断是谁在动。
可行的模式是：保留一小组输入，附带经过人工验证的已知分数，养成定期重跑的习惯。叫它校准集。20到50个样本足够。你先重跑校准集。如果平均分从6.4跳到7.6，而其他什么都没变，你就知道是评判者动了，不是数据变了。没有这个锚点，同样的诊断需要花几周读单条评论、争论到底哪变了。
这就是离线评估的价值所在。你把校准集作为数据集上传，指定评判模型，按固定节奏或在任何变更前重跑。漂移能被即时捕获，而不是等周一早上才发现。
从育儿到工程：同一套底层逻辑
toddler 不会因为你制定了规则就遵守规则。LLM不会因为你冻结了版本就停止漂移。两者都需要你放弃"控制输入就能控制输出"的幻觉，转而去设计缓冲层、反馈环和快速恢复机制。
父母学会在包里多备一套衣服，工程师学会在流水线里多埋几个检查点。父母学会不追问"为什么今天不一样"，而是快速进入"现在怎么办"；工程师学会不纠结"哪个权重变了"，而是第一时间隔离影响范围。
非确定性不是bug，是这两种系统的固有属性。对抗它消耗巨大，设计容纳它反而更便宜、更可靠。这是育儿和部署LLM共享的残酷一课：你能管理的不是结果，是系统对意外结果的响应速度。
热门跟贴