跳到主要内容

43 篇博文 含有标签「mlops」

查看所有标签

中心化 AI 平台陷阱:为什么共享 ML 团队会扼杀产品速度

· 阅读需 9 分钟
Tian Pan
Software Engineer

大多数工程组织发现问题的方式都差不多:AI Demo 效果不错,领导层推动更广泛的落地,于是有人决定正确的做法是建立一个专职团队来负责"AI 基础设施"。该团队获得了人员编制、路线图和加速全组织 AI 落地的使命。

十八个月后,产品团队开始提工单来部署他们的提示词。平台团队疲于奔命。那些 Demo 阶段只需几天的功能,现在要花上好几个季度才能上线。而那个最初为了加速 AI 落地而创建的团队,却成了最大的瓶颈。

这就是中心化 AI 平台陷阱——而且出奇地容易跌入其中。

反馈飞轮停滞:为什么大多数 AI 产品在三个月后停止进步

· 阅读需 10 分钟
Tian Pan
Software Engineer

每个 AI 产品的融资演示文稿(Pitch Deck)里都有同一张幻灯片:更多用户产生更多数据,数据训练出更好的模型,进而吸引更多用户。这就是数据飞轮。它听起来像是一台关于产品质量的永动机。在最初的几个月里,它确实奏效了——准确率攀升,用户很满意,各项指标都在持续向好。

然而,在大约第三个月的时候,曲线趋于平缓。模型不再有实质性的提升。标注队列在增长,但准确率几乎没有波动。你的团队仍在收集数据、仍在重新训练、仍在发布新版本——但飞轮已经悄然停滞。

这并非罕见的失败模式。研究显示,40% 部署 AI 模型的公司在第一年内会经历明显的性能衰减,高达 32% 的生产评分流水线在六个月内会遇到分布偏移(Distributional Shifts)。飞轮的崩溃并非伴随着巨响,而是在低语中腐朽。

模型迁移指南:如何在不破坏生产环境的情况下更换基座模型

· 阅读需 15 分钟
Tian Pan
Software Engineer

每一个交付过由大模型驱动的产品的团队都经历过同样的时刻:一个新的基础模型发布了,它拥有更好的基准测试结果、更低的成本,或者两者兼而有之——这时有人会问:“我们能直接把它换掉吗?”答案在预发布环境中总是肯定的,但在生产环境中往往是灾难性的。

“在新模型上能运行”与“在新模型上表现正确”之间的差距就是生产事故多发地。模型迁移之所以失败,不是因为新模型更差,而是因为迁移过程假设了本不存在的行为等效性。不同供应商的提示词格式规范各不相同。不同系列模型对系统提示词(System prompt)的解读也存在差异。旧模型能够优雅处理的边缘情况——通过你从未记录过的习得性怪癖——会变成回归问题暴露出来,而你的评估套件(eval suite)在设计之初并未考虑到这些。

生产环境中的嵌入模型:选择、版本管理与索引漂移问题

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的 RAG 昨天回答得还很正确。今天它却自相矛盾了。看起来什么都没变 —— 除非你的嵌入模型(Embedding)提供商悄悄更新了模型,导致你的索引现在成了一个混合了不同向量空间的“科学怪人”(Frankenstein)。

嵌入模型是每个检索增强系统(RAG)中不起眼的基石,而且它们的失效方式通常极其难以诊断。与提示词(Prompt)更改或模型参数微调不同,嵌入模型的问题往往出现得非常缓慢,表现为一种无声的质量下降,在用户开始投诉之前,你的评估系统(Evals)甚至都察觉不到。本文涵盖三个方面:如何为你的领域选择合适的嵌入模型(MTEB 评分的误导性往往大于帮助)、升级模型时究竟会发生什么,以及无需从头重建即可更换模型的版本控制模式。

在不破坏生产环境的情况下发布 AI 功能:LLM 的阴影模式、灰度发布和 A/B 测试

· 阅读需 13 分钟
Tian Pan
Software Engineer

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

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

生产环境中的提示词版本管理:工程团队历经磨难才学会的纪律

· 阅读需 12 分钟
Tian Pan
Software Engineer

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

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

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

微调 vs. 提示工程:生产级 LLM 的决策框架

· 阅读需 9 分钟
Tian Pan
Software Engineer

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

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