63 篇博文 含有标签「mlops」

一个团队在周二下午将 GPT-4o 换成了一个更新的模型。到周四，支持工单增加了 30%，但没人能说清原因 —— 新模型的回答稍短，拒绝了一些旧模型能处理的边缘情况请求，并且日期格式化的方式不同，导致下游解析器崩溃。团队选择了回滚。两个迭代周期的工作付诸东流。

这种故事不断上演。问题不在于新模型更差 —— 它在大多数方面可能表现得更好。问题在于团队发布的流程与发布 bug 修复程序完全相同：合并、部署、观察。这对代码有效，但对 LLM 则行不通。

你在凌晨 2 点收到了报警。用户报告输出内容全是一堆垃圾。你通过 SSH 登录，检查日志，盯着追踪信息 —— 结构上看起来一切正常。模型有响应，延迟也正常。但答案就是不对劲。接着，事故频道里出现了一个问题：“现在到底运行的是哪个版本的 Prompt？”

如果你不能在 30 秒内回答这个问题，说明你正面临 Prompt 版本管理问题。

在大多数早期 LLM 项目中，Prompt 被当作配置来对待。产品经理修改 .env 文件中的字符串，开发者将更新后的指令粘贴到硬编码的常量中，还有人在 staging 的 Slack 频道中粘贴了一个略有不同的版本。最终，版本产生了偏差，没有人知道哪里运行的是什么。这种在实验阶段助你快速上线的随意性，在你拥有真实用户的那一刻就会变成一种负债。

大多数团队在微调的时机上不是太早就是太晚。过早进行微调的团队会花费数周时间在训练管道上，结果却发现一个更好的系统提示就能解决问题。而等待太久的团队则在数百万个重复任务上运行昂贵的 70B 推理，同时接受着一个微调后的 7B 模型能以十分之一的成本击败的准确性。

决策的关键不在于哪种技术“更好”。而在于根据你的具体限制条件——数据量、延迟预算、准确性要求以及任务定义的稳定性——选择合适的工具。下面将介绍如何进行思考。