在2022年中旬，一家位于杭州的智能客服科技公司“智语科技”启动了面向金融行业的AI工单自动归因与处置系统项目。客户为某区域性城商行，核心诉求是：将每日平均1.2万条跨渠道（APP、微信、电话转录文本）的用户投诉/咨询工单，在30秒内完成精准分类（如“信用卡逾期争议”“手机银行登录失败”“理财收益疑问”等37个业务子类），并自动生成合规、可审计的处置建议，最终接入其内部OA审批流实现“工单—分析—分派—反馈”全链路闭环。

团队技术负责人有多年NLP经验，判断任务属典型的多标签文本分类+结构化生成问题。考虑到交付周期仅4个月，且预算有限，他们决定“快速落地”：直接选用Hugging Face上下载量超百万的开源模型——bert-base-chinese微调分类头，并叠加社区热门的ChatGLM-6B轻量化版本做处置建议生成。训练数据来自客户脱敏提供的2021年历史工单（约8.6万条），清洗后按8:1:1划分训练/验证/测试集。模型在验证集上F1达92.3%，测试集准确率91.7%，远超客户提出的85%基线要求。项目组信心十足，三个月即完成部署上线。

然而上线首周，系统便陷入恶性循环：

• 分类层失准：模型将大量“ETC扣费异常”工单误判为“储蓄卡盗刷”，触发高风险预警流程，导致风控部门每日收到200+无效协查单；
• 生成层失控：面对“为什么我的定期存款提前支取利息这么低？”这类需引用《储蓄管理条例》第24条及本行利率公示文件的工单，模型常虚构法条编号（如编造“银保监发〔2021〕89号文”），或建议“请客户拨打955XX核实”，而该号码实为总行客服热线，无法处理分行专属产品问题；
• 闭环断裂：因处置建议频繁触发合规审核驳回，73%的工单在OA系统中滞留超4小时，客户投诉响应时效从平均2.1小时恶化至18.7小时，最终引发银行运营部正式发函中止合作。

复盘发现，失败根源并非模型能力不足，而是系统性忽视商业场景的约束刚性：

第一，数据漂移被完全忽略。训练数据全部来自2021年，而银行在2022年Q2上线了全新“数字人民币钱包”业务，相关工单占当前总量的19%。开源BERT未见过该领域术语（如“硬钱包离线支付失败”“兑出额度冻结”），词向量空间严重坍缩，分类器仅靠字面匹配强行归类，错误率高达64%。

第二，生成可控性零设计。ChatGLM-6B虽经LoRA微调，但未引入任何约束机制：未对接银行知识图谱API校验事实，未嵌入模板引擎强制输出结构（如“依据：[法规名称][条款]；操作：[具体动作]；依据来源：[文件编号]”），更未设置幻觉检测阈值。当输入含模糊表述（如“上次那个活动怎么没到账”），模型直接编造不存在的营销活动名称与时间，导致一线人员反复向客户确认，信任崩塌。

第三，闭环依赖被错误抽象。团队假设“模型输出→OA接收→人工复核→执行”是标准路径，却未验证OA系统对输入字段的强校验逻辑：模型生成的JSON中“处置建议”字段含换行符与中文引号，触发OA接口解析失败；而“紧急等级”预测值为浮点数（如0.87），但OA只接受枚举值（“高”/“中”/“低”）。这些工程细节在纯学术评测中毫无影响，却是商业系统存活的生命线。

更深层的问题在于决策惯性：技术团队用“模型指标达标”替代“业务目标达成”，用“开源模型可用”替代“场景适配可行”。他们未做关键验证——邀请银行一线坐席用真实工单盲测模型输出；未与合规部联合制定《AI建议生成红线清单》；甚至未检查客户提供的脱敏数据中，是否隐含了需特殊处理的监管敏感字段（如“涉诈账户”“反洗钱可疑交易”等，其标注规则与普通工单完全不同）。

最终，智语科技退还全部合同款，并耗时半年重建系统：弃用通用开源底座，基于银行私有文档库构建领域专用小模型（参数量仅1.2亿），所有生成内容强制通过三重校验（法规库匹配、业务规则引擎、人工抽检白名单）；同时将工单处理流程拆解为“初筛—精标—生成—合规矩阵校验”四阶段，每个环节设熔断机制。新系统上线后，分类准确率稳定在96.5%，生成建议合规通过率达100%，客户重启合作并追加二期订单。

这个案例刺破了一个普遍幻觉：开源模型不是即插即用的工业零件，而是需要深度嫁接于商业肌理的活体组织。当技术方案脱离对业务约束、数据演进、系统耦合与合规边界的敬畏，再高的F1分数，也不过是闭环崩塌前最后的烟花。