我们曾把一个AI客服模型的离线准确率做到99.2％，但上线不到一周，真实用户就给它上了一课。模型能看懂标准测试题，却看不懂用户口中的“那个带轮子的破玩意儿”；能在评测集上拿高分，却在真实场景里频繁翻车。本文记录了一次完整的项目复盘：从数据清洗、模型训练，到线上事故、策略调整和系统重构。回头来看，真正决定项目成败的，或许从来都不是模型分数。
做AI训练师这两年，我参与过不少模型训练和落地项目。大多数时候，项目遇到的问题都在预期范围内：数据质量不足、标注标准不统一、模型效果达不到预期，或者需求在交付过程中不断变化。这些问题虽然麻烦，但至少方向明确，知道该往哪里解决。
真正让我印象深刻的一次经历，发生在一个消费电子行业的AI客服项目里。当时我们把模型的离线评测准确率做到了99.2％。从指标上看，这已经是一个相当漂亮的成绩。项目组内部普遍认为，模型已经具备上线条件，后续更多是运营和流程层面的工作。然而上线不到一周，我们就发现一个尴尬的事实：模型在测试集上的表现，和它在真实环境中的表现，完全不是一回事。
后来复盘整个项目时，我逐渐意识到，很多AI项目的问题并不是出在模型能力上，而是出在我们对真实场景的理解上。模型能够在实验室里拿高分，并不代表它已经准备好面对真实用户。那些看起来优秀的离线指标，有时候更像是在验证测试集本身，而不是验证系统是否具备落地能力。
这次项目最终并没有失败。相反，它后来成为客户内部使用效果最稳定的一套AI系统之一。但在达到这个结果之前，我们踩过不少坑，也推翻过很多原本深信不疑的判断。
项目客户是一家消费电子厂商，希望通过AI客服系统承接部分售后咨询、退换货申请以及投诉处理工作，以降低人工客服压力。
项目采用的是行业内比较成熟的SFT方案。为了保证训练效果，我们在数据准备阶段投入了大量精力。原始语料经过多轮清洗，统一表达方式，修正错别字，删除无效内容，同时对问答结构进行了标准化处理。
从训练角度来看，这批数据的质量非常高。用户会明确说明产品型号、故障现象和咨询目的，模型对应给出标准答案。无论是意图分类还是问答匹配，样本结构都非常清晰。训练结束后，模型在内部评测集上的准确率达到99.2％。无论是项目团队还是客户技术团队，都对这个结果比较满意。按照当时的判断，模型已经具备上线条件，后续更多是业务验证阶段。
问题出现在上线后的第三天。当时有用户提交了一段投诉内容，大意是某款产品在充电过程中发生冒烟现象，导致家中地毯受损。用户先后联系卖家、厂家和售后，但始终没有获得明确处理结果，因此希望确认赔偿责任，并表示如果问题持续得不到解决，将向监管部门投诉。
对于人工客服来说，这其实是一条比较典型的售后投诉信息。虽然表达中夹杂着情绪，但核心诉求并不复杂：产品存在安全隐患，用户希望获得赔偿方案。然而模型最终给出的回复却是：“我们暂不销售地毯，建议您前往电商平台购买相关商品。”看到这条回复时，我们第一反应甚至有些哭笑不得。但很快，事情就变得严肃起来。
进一步检查日志后发现，这并不是单一案例。模型没有理解用户关于赔偿和责任认定的诉求，而是错误地将“地毯”识别成了咨询主体。整个意图识别过程发生了偏移，最终生成了一条完全无关的回复。为了确认问题规模，我们对上线第一周的真实会话进行了抽样分析。
结果显示，在约500条随机抽取的真实对话中，模型的有效解决率仅为70％左右。约12％的会话存在明显的意图理解偏差，其中部分回复甚至进一步激化了用户情绪。这些问题在离线测试阶段几乎没有出现过。当时我们第一次意识到，一个离线准确率接近满分的模型，并不一定能够适应真实世界。
项目刚出现问题时，团队内部最自然的反应是继续优化模型。有人认为参数规模不够大，有人认为需要增加训练轮次，也有人建议扩大训练语料规模。但当我们开始系统分析失败案例时，发现事情并没有那么简单。
绝大多数问题都集中在同一个方向：真实用户说话的方式，与训练数据中的用户说话方式存在明显差异。
训练数据里的用户通常会这样表达：
“我的XX型号产品出现故障，请问如何申请售后服务？”
而真实用户更可能这样表达：
“我买的那个带轮子的东西坏了，现在到底该找谁处理？”
从业务角度看，两句话表达的是同一个需求。但对于模型来说，它们可能来自两种完全不同的数据分布。
为了追求训练质量，我们当时清洗掉了大量被认为“不规范”的内容，包括错别字、口语表达、情绪化语言以及不完整句子。从机器学习的角度看，这些处理确实能够提高训练数据的一致性。问题在于，我们同时也删除了大量真实世界的信息。
后来回头看，那些被清洗掉的内容恰恰构成了真实用户最常见的表达方式。用户会省略产品名称，会使用代词指代，会带着情绪表达不满，也会夹杂网络流行语和各种非标准语言。对于人来说，这些内容并不影响理解；但对于模型来说，这些恰恰是最难处理的部分。
更关键的是，我们的测试集与训练集采用了相似的构建逻辑。换句话说，模型是在一套高度规范化的数据体系里完成训练，又在同样规范化的数据体系里接受考试。它考出了高分，但并没有真正经历真实场景的检验。后来复盘时，我在笔记里写下过一句话：数据越接近理想状态，未必越接近真实世界。这句话现在看有些绝对，但放在当时的项目环境里，它几乎解释了后续所有问题的起点。
确认问题来源之后，我们决定调整训练策略。首先是在SFT阶段加入更多真实用户语料。这些数据不再经过过度清洗，而是尽可能保留原始表达方式，包括错别字、口语化表达、情绪化内容以及部分网络用语。与此同时，我们在模型前增加了一层轻量级文本清洗模块，希望先对用户输入进行适度规范化处理，再交给模型理解。
从结果来看，这轮优化是有效的。根据项目内部监控数据，业务拦截率从58％左右提升到了84％左右，用户满意度（CSAT）也从72％提升到了85％以上。此前大量因为口语表达导致的理解错误明显减少，模型开始能够识别更多真实场景下的用户意图。
如果只看这些指标，这次优化似乎已经取得成功。然而项目运行不到一个月，新的问题开始逐渐暴露出来。最先出现的问题来自网络热梗和情绪表达。当时市场上正好发生了一些与第三方配件质量相关的舆论事件，许多用户开始使用各种网络流行语进行投诉。对于人来说，这些表达往往带有非常明确的情绪色彩和潜在诉求。
但前置清洗模块并不具备理解这些内容的能力。当系统无法识别某些表达时，往往会将其视为噪声进行过滤，或者强行转换成标准句式。结果是用户原本带有明显不满情绪的投诉，最终变成了一条普通咨询。模型虽然理解了字面含义，却失去了对用户情绪的判断能力。
从系统视角看，它回答得没有问题；但从用户视角看，系统根本没有理解自己的处境。网络热梗带来的问题只是开始。随着真实用户语料不断进入训练体系，我们很快又遇到了第二个问题，而且这个问题比情绪识别偏差更难发现。模型确实学会了理解更多口语化表达，但与此同时，它也开始学习这些表达中的噪声。
最初几周，这种变化并不明显。直到法务团队在抽查对话记录时发现，一些涉及合同条款和售后责任的咨询中，模型开始频繁使用非标准表述。一些原本明确的专业术语被替换成更口语化的说法，个别情况下甚至改变了原有语义。例如，用户咨询某项条款是否属于“不可抗力”范畴时，模型在回复中将这一术语改写成了“不可抗拒的外部因素”。对于普通用户来说，两者似乎差异不大，但从法律和合同解释的角度来看，这种改写已经存在风险。
问题的根源并不复杂。模型在学习真实语料的过程中，不仅学会了用户如何表达诉求，也学会了用户表达中的各种不规范习惯。当训练目标过于强调“贴近用户语言”时，模型有时会把专业性让位给自然性。
这也是我们第一次意识到，真实数据并不天然等于高质量数据。它能够帮助模型理解现实世界，但也会把现实世界里的噪声一起带进来。如果说前两个问题还属于模型能力边界的问题，那么第三个问题则完全超出了我们的预期。
随着系统逐渐稳定，我们发现退款申请量开始出现异常波动。最初运营团队以为是产品质量出现了问题，但排查后发现，产品故障率与历史数据基本一致，并没有明显变化。真正发生变化的是用户与系统互动的方式。为了提升投诉处理效率，我们曾在策略中加入情绪优先机制。简单来说，当系统识别到用户处于强烈负面情绪状态时，会提高响应优先级，并尽快引导进入处理流程。
这个设计初衷没有问题。对于真正遇到问题的用户来说，更快获得响应本身就是更好的服务体验。但用户比我们想象得更善于学习系统规则。部分用户逐渐发现，只要在开场阶段使用足够强烈的情绪表达，就更容易获得快速响应。一些原本普通的咨询开始被包装成高优先级投诉，一些并不复杂的问题也会故意放大情绪。
两个月后，运营团队统计发现，通过AI渠道发起的退款申请量同比增长约18％，而同期产品故障率几乎没有变化。那次复盘会上，有同事说了一句话让我印象很深：“我们一直在研究模型，其实用户也在研究模型。”后来回头看，这句话几乎解释了所有问题。
经历几轮问题之后，我们逐渐意识到一个事实：继续追求更高的模型分数，并不能解决已经暴露出来的问题。当时团队内部也讨论过是否引入更大的模型，或者进一步增加训练数据规模。但经过成本测算和效果评估后，我们发现这些方案并不能直接解决线上问题。
真正有效的调整，最终都发生在系统层面。首先调整的是前置清洗模块。在最初的设计中，系统总是试图把用户输入转换成标准表达。现在看来，这种思路本身没有错，但它默认了一件事：系统一定比用户更懂用户想表达什么。
现实显然不是这样。后来我们增加了一条非常简单的规则：当清洗模块无法确定用户真实意图时，不再进行强制修正，而是保留原始输入直接交给模型处理。这个调整听起来很普通，却显著降低了误判率。很多时候，错误处理比不处理带来的损失更大。
第二个调整来自专业术语管理。此前我们曾尝试通过训练方式让模型学会“不乱改术语”，但效果始终不稳定。模型今天学会了，明天可能又会在新的边界案例中犯错。最终我们放弃了继续训练，而是采用更工程化的方法。
对于法律、合同、售后规则等关键领域，我们建立了一套术语白名单机制。一旦识别到相关术语，系统直接锁定，不允许模型进行改写或重组。从技术角度看，这个方案甚至有些“笨”。但事实证明，它远比继续微调模型更加稳定。
第三个调整发生在业务决策链路。此前系统将用户情绪与处理优先级直接绑定，而新的方案则将两者彻底拆分。情绪识别依然存在，但只影响响应速度、服务语气和人工介入优先级。至于退款、赔偿、责任认定等涉及资金和风险的决策，则全部进入独立审核流程。
换句话说，模型负责理解和辅助判断，但不负责最终拍板。这项改动上线后，退款申请量很快恢复正常，相关运营指标也逐步回归稳定。当时团队内部有人觉得这是一次“能力退让”，因为系统自动化程度降低了。
但后来大家逐渐接受了一件事：自动化程度高，并不等于系统成熟度高。对于涉及责任和风险的场景来说，可控性往往比自动化更重要。
整个项目过程中，最重要的一次变化其实不是模型优化，而是评估体系的变化。项目初期，我们关注最多的是准确率。每次训练完成之后，大家讨论的都是模型分数提升了多少、召回率提高了多少、意图识别准确率有没有达到目标。这些指标当然重要，但上线之后我们发现，它们并不能解释用户为什么不满意。
后来团队建立了一套新的复盘机制。每周固定从线上随机抽取200条真实会话，由运营、产品和算法团队共同进行人工复盘。相比关注模型答对了多少问题，我们开始关注模型是如何犯错的。这个指标后来被我们称为异常案例率（Bad Case率）。
项目初期，这项指标长期维持在10％以上。换句话说，每100条真实会话里，就有超过10条存在明显问题。这些问题未必会直接导致投诉，但已经足以影响用户体验。经过持续两个月迭代之后，异常案例率逐渐下降到3％以内。
有意思的是，在这个过程中，模型的离线准确率反而出现了一定下降。因为真实语料比例增加后，测试环境不再像过去那样“干净”，模型面对的问题也变得更加复杂。最终版本的离线准确率大约维持在96％左右。如果只看数字，它甚至不如最初的99.2％。但所有人都知道，后者才是真正可用的系统。
项目稳定运行三个月后，各项核心指标逐渐进入稳定区间。业务拦截率稳定在82％～85％之间，用户满意度维持在88％左右，高风险投诉升级率相比初版系统下降接近40％。与此同时，退款率和误判率也回到了业务能够接受的范围内。
从结果来看，这个项目最终是成功的。但如果让我总结最大的收获，那并不是某个模型技巧，也不是某种训练方法。而是我们逐渐接受了一件事：AI落地从来都不是一道单纯的算法题。
很多人刚接触大模型时，都会天然地把问题归结到模型身上。效果不好，就换模型；准确率不够，就继续训练；指标下降，就继续调参数。但真实业务环境远比实验室复杂得多。用户会说错别字，会使用新梗，会带着情绪表达诉求；业务规则会变化，市场环境会变化，用户行为也会变化。即便模型本身没有问题，整个系统依然可能因为某个环节设计不合理而失效。
回头看整个项目过程，真正起作用的从来不只是模型。训练数据、提示词设计、清洗模块、术语管理、审核机制、运营策略、人工兜底，这些因素共同决定了系统最终的表现。模型只是其中的一部分。
现在回头再看那个99.2％的准确率，我已经没有当初那种兴奋感了。不是因为这个数字没有价值，而是因为我知道它意味着什么，也知道它不意味着什么。它能够证明模型在测试集上表现优秀，却不能证明系统已经准备好面对真实用户。它能够说明模型学会了解题，却不能保证模型学会了应对现实世界。
很多AI项目上线失败，并不是因为模型不够聪明，而是因为真实世界比训练集复杂得多。用户会不断创造新的表达方式，也会不断适应系统规则。模型解决一个问题之后，新的问题往往很快就会出现。从这个角度来看，AI落地更像一个持续迭代的过程，而不是一次性的交付。
模型能力当然重要，但真正决定项目成败的，往往是那些看起来并不“高级”的东西：数据是否真实、流程是否合理、规则是否完善、风险是否可控，以及团队是否愿意持续面对那些永远处理不完的异常案例。
至少对我来说，这才是那次项目留下的最大价值。因为它让我明白了一件事：模型能够考高分，并不代表系统已经准备好面对真实世界。
本文由 @L.NaN 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自作者提供
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。