我们团队的3个Agent上线后只活下来1个：补完监督学习的基础我才敢重新上线

我们团队的3个Agent上线后只活下来1个:补完监督学习的基础我才敢重新上线灰度第三天的周会上,总监把三台智能体的运行报告往桌上一甩:“售前Agent的幻觉率41%,内部知识库Agent随机把客户邮件当成了产品手册--你们到底测了什么?”我张了张嘴,想说“大模型本来就有不确定性”,但话到嘴边变成了沉默。因为我知道,问题出在根上:我们从没按监督学习的标准流程做过评估,连最基本的混淆矩阵都没画过。那天下午我直接登录AWS管理控制台,翻出当初潦草地跑过一遍的机器学习入门课程目录--那门课第三章清清楚楚写着监督学习的评估方法论,可我跳过去了,只看了模型部署部分。如果当时能把AWS机器学习课程里那几个实验做完,至少不会在售前Agent的对话分类训练集上,拿准确率当唯一指标,最后得到一个把所有模糊咨询都归为已解决的分类器。三个Agent是怎么一步步失控的我们当时的目标很明确:用大模型驱动三个智能体,一个做在线咨询分流与意图识别,一个做售后工单自动归类和话术生成,一个做内部知识库的文档问答。三个Agent共用一套微调过的7B模型底座,区别只在于提示词和少量领域数据的监督微调。立项时我判断这不过是套壳Prompt Engineering,两周搞定。于是数据标注的工作,我让两个实习生花三天标了600条对话--没有制定标注规范,没有打乱分布,更没有留出独立的验证集。现在回头看,这600条里,售后场景样本占了380条,咨询场景只有120条,知识库场景100条,而且知识库样本中超过一半的问题都是如何创建工单,一个典型的类不平衡问题。机器学习基础课里专门有一段讲类不平衡对监督学习模型的影响,我当时觉得那是kaggle比赛才需要关心的事,企业内部数据哪有那么讲究。售前Agent上线第一天,F1掉到0.61,但我根本没发现--因为我监控面板上只挂了平均置信度。咨询分类用的是一个简单的线性分类头,做多分类。训练时我看loss下降得挺稳,第五个epoch就停了。实际上模型在少数类上极度欠拟合,却因为多数类样本撑起了准确率,整个训练过程没有一点告警。后来我才在机器学习入门的评估章节里看到一个几乎一模一样的案例:当你面对不平衡数据却只用准确率时,监督学习模型会选择性放弃少数类,而业务上放弃掉的那些,恰恰是最致命的--比如把退款投诉分到一般咨询。我试着用Prompt工程救,反而把幻觉率推到了41%第二周我决定不再碰训练代码,转而优化提示词。我给售前Agent写了一个长长的System Prompt,包含20条规则:不要确认未付款订单、涉及金融数据必须导向人工、不要透露内部系统命名......每条规则看起来都很合理,但合在一起,模型开始频繁冲突。python我在后端日志里抓到的典型冲突示例system_prompt_rule_1 不要生成超出知识库范围的信息 system_prompt_rule_2 即使信息不完整也要给出建设性回复当用户问这个退款政策的最新版本是什么且知识库里没有时,模型在规则1和规则2之间反复横跳,最终编造了一个版本号更糟糕的是,内部知识库Agent因为检索到的文档片段里混杂了内部Wiki和客户邮件,开始把张三的投诉邮件作为产品FAQ输出。这是一个典型的数据泄露加噪声问题。我在亚马逊云科技机器学习的课程里看到过用特征存储做数据血缘追溯的例子,但当时我们根本没有区分训练数据和候选文档的界限,监督学习里的训练集与部署集分布一致假设被彻底打破。知识库Agent上线第三天,把一封包含客户身份证号的邮件摘要生成到公共回答里,合规部门直接要求下线。关停两个Agent后,我花了一周跑完机器学习入门全部实验三个Agent只活了售后那一个--因为它任务最单纯,只需要做单标签分类,而且样本量相对充足。但即便是这个活下来的,AUC也只有0.72。我把咨询和知识库Agent的容器停掉,跟老板申请了一周时间补课,他狐疑地看着我,最后说了一句:如果再上线还是这样,我们就切回规则引擎。那一周我每天早上9点到晚上11点都在电脑前,跟完机器学习入门的每一个动手实验。我用课程提供的SageMaker笔记本环境,把之前那600条脏数据重新加载,按照课程里监督学习数据预处理的checklist逐一检查:类别分布:使用SMOTE对少数类做过采样标注一致性:找三个标注人员重标了100条,计算Fleiss Kappa训练/验证/测试划分:按8:1:1分层抽样基线模型:先用逻辑回归跑一个baseline,再上BERTpython我从课程实验里改出来的数据漂移监测代码def detect_distribution_shift(reference_data, new_data, threshold0.1): from scipy.stats import ks_2samp shift_features [] for col in reference_data.select_dtypes(include[np.number]).columns: stat, p ks_2samp(reference_data[col], new_data[col]) if p threshold: shift_features.append((col, p)) return shift_features这个函数后来成了我们模型监控的标准组件最关键的改变是评估体系。监督学习的评估不是用一个数字交差,它必须覆盖业务指标和技术指标的双向映射。我把售前Agent的评估从单一的准确率,扩展为:指标修改前修改后说明宏平均F10.610.89每一个类别都被公平对待混淆矩阵关注类别无退款投诉召回率0.93业务关键类单独监控置信度分布平均0.91标准差从0.04降到0.12不再所有预测都打高分这些指标没有一个是我自己发明的,全部来自机器学习基础课程里模型评估与选择那一章的评估矩阵模板。那门课甚至还给了监督学习在线模型持续监控的架构图,我直接复用到我们自建的ML管道里。学了深度学习入门后,我把微调从炼丹变成了工程化流程售前Agent分类任务升级为多标签之后,BERT-base的容量开始不够用。我又回去看了深度学习入门的课程,里边用PyTorch从头搭了一个文本分类器,并且详细解释了学习率调度、梯度裁剪和早停法在监督学习框架下的配合策略。我之前微调大模型一直凭感觉:学习率设1e-5,epoch跑3轮,batch size能塞多大塞多大。实际上对于多标签任务,损失函数选BCEWithLogitsLoss,正负样本要按标签维度分别计算权重。这个细节如果不看AWS深度学习课程的代码拆解,我自己可能一个月都调不出来。python从深度学习入门实验迁移过来的多标签训练代码片段pos_weight torch.tensor([neg_count/pos_count for pos_count, neg_count in zip(pos_counts, neg_counts)]) criterion torch.nn.BCEWithLogitsLoss(pos_weightpos_weight)加上早停法,验证F1连续2个epoch不变就停early_stop EarlyStopping(patience2, monitorval_f1) 模型重新训练后,售前Agent的意图识别在多标签场景下子类准确率稳定在0.92以上,幻觉率从41%降到了4.7%。知识库Agent我们改用了RAG监督微调的组合,文档检索部分加了一个监督学习重排序器,把所有召回片段做是否可对外回答的二分类,合规问题终于被拦截住了。给正在落地Agent的同行的建议三个Agent只活一个的教训,归根结底是监督学习基本功在团队里的断层。大模型让很多团队误以为可以跳过特征工程、跳过数据标注规范、跳过模型评估--事实上,当你把LLM当成一个需要微调的基座时,它就是一个巨大的监督学习模型,所有老规矩都还管用。先学机器学习入门打好底盘。那门课从零讲监督学习、无监督学习、强化学习的区别,带着你在SageMaker上跑完整实验,比看十篇博客管用。如果你负责带团队,可以要求新同事入职第一周先把它跟完。评估体系必须用机器学习基础里的标准矩阵。混淆矩阵、ROC、PR曲线、宏平均/微平均F1,一个都不能少;并且让业务方确认哪几个类别绝对不能出错--这是监督学习和业务对齐的唯一接口。数据标注不是实习生三天的活。参考AWS机器学习课程里的数据标注流程,做双盲标注加一致性检验,留出固定的验证集和测试集,这些在监督学习项目里都是非可选的。上线后监控数据漂移。用机器学习管道里的概念,把训练时的特征分布存到特征存储,线上实时比较。我们后来在SageMaker Model Monitor里直接配了这条规则,任何一个特征偏离超过0.1就发告警。不要只迷信大模型,该上传统监督学习的地方别含糊。知识库Agent里那个重排序器,我们用了一个130MB的LightGBM二分类模型,延迟只有18ms,比用大模型做判断快7倍,成本低一个数量级。生成式AI的课程也值得过一遍,尤其里面讲大模型的能力边界那部分,能帮团队避开把所有任务都丢给LLM的误区。把CodeWhisperer装进IDE。评估脚本、数据漂移监控、模型注册这些代码,我有一半是描述功能需求后由Amazon CodeWhisperer自动补全的,省了大量查API文档的时间。现在三个Agent全部重新上线并稳定运行超过两个月。上周总监又在周会上打开监控面板,指着三个绿色的AUC曲线说了一句:这次稳了。我知道这不是终点--监督学习的模型会退化、数据会漂移、业务需求会变,但只要评估体系和数据管道的底子在,我们就不会回到那个灰度的下午。