FDE进化36记-第8记-树模型与排序模型到底该用在哪些客服场景简单模型不够用复杂模型养不起[读者] 客服平台算法与FDE工程师 [痛点] 该不该上GBDT与排序模型 收益说不清 成本说不明 [现在读] 第7记小模型路由已上线 风险评分与优先级成瓶颈 [读完] 用一张决策表把五类场景 分给对的模型 并说清代价[旧方案] 单棵决策树加人工阈值 | v [新需求] 流失 升级 知识 坐席 服务优先级 都要打分排序 | v [冲突] 复杂模型离线好看 线上解释与维护成本同涨 | v [后果] 模型越堆越多 没人敢改 排序结果说不清 业务不信我是老李在这条全球智能客服平台上做算法侧的系统落地。平台同时服务多家企业、跑多个项目、覆盖多语言和多渠道背后连着CRM、订单、支付、物流、工单和知识库。第7记我们把意图分类、路由和评分收敛回传统小模型路由稳住了下一个坑立刻露头路由只回答“这句话该分给谁”没回答“这件事该排在谁前面”。现在平台上有五类打分需求客户流失风险、投诉升级预测、知识推荐、坐席推荐、服务优先级排序。前两类是预测后三类是推荐或排序。它们看起来都是“给个分数”但用的模型、评估口径和维护方式完全不是一回事。最早我们全部用一棵决策树加人工阈值理由是简单、能解释、能改。后来业务说效果不够于是有人主张全量换XGBoost有人主张只把排序换成Learning-to-Rank。两拨人各有各的离线指标谁也说服不了谁。到底哪些客服场景真的需要GBDT哪些一棵决策树加规则就够复杂模型相对简单模型业务收益能验证到什么程度而不是靠离线指标自嗨排序模型上线后维护成本涨在哪里怎么把它压回可控01、故事先回到那个周三晚上的现场。某企业客户的客服经理在群里发了一张截图工单优先级列表的前十条里有六条是“查询发票抬头”这类咨询而一个已经连续三次进线、订单卡在物流异常、语气明显升级的客户排在第三十七位。我们的任务是为每一条进线会话产出一个可解释的分数并据此决定处置顺序在会话真正变危险之前把人拉进来。当时的实现非常朴素。特征只有七列客户等级、订单金额区间、历史投诉次数、近7天会话轮次、情绪词命中数、渠道、是否VIP。模型是一棵max_depth3的决策树导出成规则给运营看阈值由运营手动定档0.8是P00.5~0.8是P1往下依次P2、P3。变化来得很快。平台从单企业扩到多企业从单一在线渠道扩到邮件、在线、社媒、呼叫中心四条渠道会话从“每天几百条”变成“每小时上千条跨语言会话”。同一条规则在A企业表现正常到了B企业把一大批只是问价的正常客户打成了高风险坐席推荐更麻烦同一个坐席在中文会话里被推荐得很准在西班牙语会话里几乎无人点击。冲突不在“模型够不够聪明”而在分数和顺序是两件事。树输出的是概率运营要的是顺序。概率0.50和0.52落在同一个人工阈值下就是同一档但它们的危险程度并不相同。更麻烦的是这个阈值是对全体样本定的而多企业、多语言、多渠道下每组的危险基线根本不一样。于是我们需要重新回答一个问题这五类需求里哪些本质上在解预测哪些本质上在解排序分数不是顺序阈值不分企业列表漂在半空人只能去追02、问题旧方案失效的第一个表现是档位把顺序吃掉了。单棵决策树的叶子数有限同一片叶子里的样本拿到的是同一个概率常数落到同一个档位里之后谁先谁后完全靠工单时间。也就是说我们花了力气训练模型最后决定顺序的其实是“谁先提交”。第二个表现是评估口径和线上用法错位。我们离线看的是AUC这是一个pointwise指标衡量的是所有样本混在一起时正样本是否排在负样本前面。但线上用的是“取topN给坐席”和“取前十条给客户经理”这是一个listwise动作。指标和使用方式对不上指标再好看也预测不了线上。业务影响分三条高风险会话掉队投诉升级的处理窗口被浪费在排队上坐席推荐被人工大量覆盖推荐位形同虚设反而增加坐席的认知负担知识推荐的候选文档排不进前三机器被判定为“没用”人工写FAQ的动作又回来了。技术表现也分三条预测类模型输出概率高度集中大量样本挤在一两个区间里组内区分度低排序类需求被当成分类问题做评估用pointwise指标切分用随机切分全局指标所有企业混在一起看着还行按企业×语言×渠道拆开看就崩但没人拆。我们给这一轮定的可验证完成标准是五类场景各自明确归属“预测”还是“排序”并写进模型卡片分组键固定下来企业×语言×渠道×时间窗每组有独立基线与定档策略排序场景以NDCGk、Recallk为主指标pointwise指标只作辅助每次迭代能在固定测试集上按组复现指标可追溯每个模型有明确的复杂度上限和退出条件写在上线前而不是出事之后。旧树切成几档档内再无高低指标看着还行线上顺序全乱03、原理只讲本篇需要的部分。决策树递归划分特征空间做的是轴平行切分对单调变换不敏感能输出特征重要度规则可以直接讲给业务听。它的代价是方差大训练数据微小变动可能换一棵结构不同的树而且单树表达力有限。Random Forest用Bagging的思路并行训练多棵树样本和特征都做子采样再平均。它主要降方差对超参不敏感是很好的基线但不容易把偏差压得很低。GBDT走的是另一条路串行加树每棵新树拟合前面模型的残差或梯度主要降偏差。XGBoost在这条路上加了三样关键设计——带正则的目标函数、二阶泰勒近似、以及稀疏感知的分裂与加权分位草图把工程实现从“能跑”推到“能并行、能稀疏、能控复杂度”见XGBoost论文具体实现细节需按当前官方文档核验。LightGBM则用直方图分裂、GOSS、EFB和leaf-wise生长换取更快的训练与更低的内存代价是leaf-wise在小数据上更容易过拟合需要认真限制num_leaves和min_data_in_leaf具体参数名与默认值需按当前官方文档核验。Learning-to-Rank不是“更强的分类器”而是换了一个优化单位。pointwise把每个样本当独立问题pairwise比较组内样本对listwise直接面向NDCG这类不可微指标用Lambda梯度之类的代理损失去逼近。它的输入天然是“一个query 一组候选 组内相关度”。反直觉判断在客服这类以表格特征为主的数据上GBDT相比调好的单棵决策树带来的收益通常小于“把评估口径和切分方式改对”带来的收益。很多“复杂模型更准”的结论其实是切分泄漏或指标口径错造成的假象。反直觉判断排序模型用错场景收益接近零而成本明显上升。流失风险预测本质是“这个客户会不会走”不需要组内比较硬套LTR只是把一个独立预测问题拆成了伪query白白引入分组维护成本。反过来服务优先级本质是“同一批待处理工单里谁先谁后”用pointwise分类再切档就是拿锤子拧螺丝。把这套判断落到五类场景上客户流失风险 - 二分类 概率校准 - GBDT够用 投诉升级预测 - 不平衡二分类 成本敏感阈值 - GBDT 知识推荐 - query-文档排序 - LTRpairwise/listwise 坐席推荐 - query-坐席排序 曝光偏差 - LTR 服务优先级 - 组内排序队列/企业/时间窗 - listwise LTR注意最后一列的措辞是“够用”不是“最强”。这五个格子后面会决定维护成本的高低。单树切空间森林降方差提升压偏差排序换单位04、架构[输入] 会话/工单/客户事件 | v [模块] 特征层企业×语言×渠道×时间窗 | 场景路由预测 or 排序 | 模型层Tree / RF / GBDT / LTR v [数据/状态] group_key 分数 档位 模型版本 | v [处理] 分组切分 - 训练 - 校准 - 组内排序 - 阈值/配额 | v [输出] 风险分 / 升级概率 / 推荐列表 / 优先级队列三个边界必须写清楚。第一模型层只负责打分不负责动作。分数出来之后是自动回复、转人工、还是生成工单属于Workflow和Human-in-the-loop的职责第14记会展开。把动作决策塞进模型会让模型既难评估又难回滚。第二分组键不是越细越好。按企业×语言×渠道×时间窗分组可以让每组有自己的基线和定档但切得太细单组样本量会小到无法训练GBDT此时应该退回到RF或单树。第三预测和排序不能共用一套评估流水线。预测看AUC与校准曲线排序看NDCGk与Recallk两条线各自有基线、各自有发布门禁。这套架构的收益是口径统一任何一个分数都能回答“它属于哪个场景、用哪类模型、在哪个组里评估、对应哪个版本”。代价是特征血缘和分组维护的工作量上来了这也是后面维护成本的主要来源。适用条件是有稳定的分组维度、每组有足够样本、并且业务真的按顺序消费结果。输入先分组分组再定档定档才排序排序回业务05、实战一次先把V1跑通再谈复杂模型。以下为合成数据的最小可运行示例用于打通“分组切分 → 训练 → 分档 → 读规则”这条链路。未在当前环境实测以下为预期结果示例输出中的数值仅代表量级不可当业务结论。环境与依赖# 示例环境具体版本需按当前官方文档核验python-mvenv .venvsource.venv/bin/activate pipinstallnumpy pandas scikit-learn lightgbm xgboostV1单棵决策树做投诉升级预测 全局阈值分档。importnumpyasnpimportpandasaspdfromsklearn.treeimportDecisionTreeClassifier,export_textfromsklearn.model_selectionimportGroupShuffleSplitfromsklearn.metricsimportroc_auc_score rngnp.random.default_rng(7)defmake_sessions(n4000,n_tenants4):tenantrng.integers(0,n_tenants,n)langrng.integers(0,3,n)channelrng.integers(0,4,n)ordersrng.integers(0,6,n).astype(float)complaintsrng.integers(0,5,n).astype(float)turnsrng.integers(1,30,n).astype(float)sentimentrng.random(n)base-3.00.35*complaints0.06*turns1.2*sentiment0.1*orders p1.0/(1.0np.exp(-base))y(rng.random(n)p).astype(int)Xpd.DataFrame({tenant:tenant,lang:lang,channel:channel,orders:orders,complaints:complaints,turns:turns,sentiment:sentiment,})returnX.drop(columns[tenant]),y,tenant X,y,tenantmake_sessions()# 分组切分同一个企业不能同时出现在训练集和测试集splitterGroupShuffleSplit(n_splits1,test_size0.3,random_state7)tr,tenext(splitter.split(X,y,groupstenant))clfDecisionTreeClassifier(max_depth3,min_samples_leaf50,random_state7)clf.fit(X.iloc[tr],y[tr])probaclf.predict_proba(X.iloc[te])[:,1]print(AUC(示例输出):,round(roc_auc_score(y[te],proba),4))print(export_text(clf,feature_nameslist(X.columns),max_depth2))# 全局人工阈值分档bucketspd.cut(proba,bins[-0.001,0.2,0.5,0.8,1.0],labels[P3,P2,P1,P0])print(buckets.value_counts().sort_index())预期你会看到两件事。一是概率分布高度集中——树深只有3叶子数是个位数大量测试样本落到同一片叶子上拿到的概率是同一个常数。二是档位分布同样倾斜某一档吃掉大部分样本档内顺序只能靠提交时间决定。示例输出量级示意非业务结论 AUC: 0.7x P3 极多 P2 较多 P1 少量 P0 极少启动与验证方式python v1_upgrade_risk.pyV1 跑通了也把问题留下了它只能回答“这单危不危险”不能回答“这批单里谁更危险”。而这个差别恰恰是服务优先级、知识推荐、坐席推荐三个场景的全部意义。先跑最小树再看档位散留一个疑问换模型不急06、排查诊断一优先级列表里前几名是低风险会话。现象高分段工单的人工复核通过率低真正升级的会话排在列表中段。怀疑GBDT没上模型区分度不够。检查先分组统计概率分位再用export_text打印规则看有多少测试样本落到同一片叶子再看同一片叶子内部的标签混合比例。证据树深小、叶子少不同企业的样本被同一批切分条件覆盖同一叶子内正负样本混在一起。根因单树把连续风险压成少数几个常数叠加全局阈值导致跨企业、跨语言的组内顺序失效。问题不在模型容量而在“用全局标尺量不同组”。修复预测类换GBDT输出连续分同时把阈值改成组内分位数定档每企业、每语言各自定P0~P3的切点。诊断二离线指标不错坐席推荐top3被人工大量覆盖。现象离线NDCG看着可以线上坐席经常手动切到别的坐席。怀疑模型不行需要上更复杂的排序模型。检查把评估切分从随机切分换成按会话/客户分组切分再按时间切分重跑一遍同时检查训练集和测试集里是否出现同一个会话的多个候选。证据随机切分下同一会话的多个候选同时落到训练集和测试集候选集泄漏改成按组切分后指标明显回落回落幅度大于任何模型替换带来的提升。根因评估口径与线上口径不一致。离线是pointwise随机切分线上是listwise按会话消费加上候选泄漏指标虚高。修复改为分组切分与时间切分排序场景换LTR目标组内比较主指标从AUC改为NDCGk与Recallk。错误尝试我们第一反应是把决策树的max_depth从3调到15理由是“树太浅”。调完之后离线AUC确实涨了我们就以为问题解决了。错在哪加深单棵树提高的是训练集拟合能力而我们的故障是“组内顺序不可用”这两个问题不在一个维度上深度一上来跨企业泛化变差、导出的规则长到业务读不动线上顺序却没变化。判据看错了改模型容量就是白改。这两条诊断给出一条共同结论在动手换模型之前先把“评估单位”和“分组口径”这两个变量固定下来否则你无法分辨指标变化来自模型还是来自口径。现象先看清怀疑留给数据证据指向口径根因才动手07、优化严格基于第06章的两条证据做V2。根因一全局阈值 单树常数概率导致组内无序。修改预测类模型换成GBDTLightGBM或XGBoost的二分类目标并对输出做概率校准阈值改为组内分位数定档。原因GBDT把偏差压得更低输出连续组内分位数把“绝对概率”换成“在它所属组里的相对位置”直接对齐业务用法。新行为同一个概率0.52在不同企业里可能落进不同档位但同一组内的顺序始终有区分度。验证按组输出分位分布与校准曲线确认每组各档位样本占比符合预期。根因二排序场景被当成分类做且切分泄漏。修改知识推荐、坐席推荐、服务优先级改用LTR切分改为按query分组切分与时间切分。原因LTR的优化单位是组内顺序与线上listwise消费一致分组切分消除候选泄漏。新行为模型直接优化组内排序评估指标与线上动作同构。验证在固定测试集上比较同一份数据下“分类切档”与“LTR”的NDCGk全部按组统计不报全局均值。V2 的关键代码结构同样是合成数据用于打通用group的排序流程未在当前环境实测以下为预期结果具体参数名需按当前官方文档核验importnumpyasnpimportpandasaspdfromlightgbmimportLGBMRankerfromsklearn.model_selectionimportGroupShuffleSplitdefmake_ranking(n_queries400,cand_per_query5):rows,labels,groups[],[],[]forqinrange(n_queries):tenantq%4forcinrange(cand_per_query):matchfloat(np.random.random()*(1.0ifc0else0.5))rows.append({tenant_id:tenant,cand_score:match,cand_ctr:float(np.random.random()),is_vip:int(tenant0andc%20),})labels.append(1ifmatch0.6else0)groups.append(cand_per_query)returnpd.DataFrame(rows),np.array(labels),groups X,y,groupmake_ranking()qidnp.repeat(np.arange(len(group)),group)splitterGroupShuffleSplit(n_splits1,test_size0.3,random_state7)tr,tenext(splitter.split(X,y,groupsqid))group_tr[group[g]forginrange(len(group))ifginset(qid[tr])]rankerLGBMRanker(objectivelambdarank,n_estimators200,learning_rate0.05,num_leaves15,min_child_samples20,random_state7,)ranker.fit(X.iloc[tr],y[tr],groupgroup_tr)scoresranker.predict(X.iloc[te])defndcg_at_k(y_true,y_score,k3):ordernp.argsort(-y_score)[:k]gainsnp.asarray(y_true)[order]discounts1.0/np.log2(np.arange(2,k2))dcgfloat(np.sum(gains*discounts))idealnp.sort(y_true)[::-1][:k]idcgfloat(np.sum(ideal*discounts))returndcg/idcgifidcg0else0.0# 示例逐组计算后取均值而不是把全体样本混在一起算print(NDCG3(示例输出):,round(ndcg_at_k(y[te],scores,3),4))V2 上线后我们在模型卡片上补了一行硬约束排序场景不允许用全局AUC作为发布门禁。这一行比任何模型替换都更省事。至于收益这里不给百分比。收益必须用你自己的数据、自己的分组、自己的线上口径去验证任何在文章里写出的提升幅度都不该被你直接搬进生产。证据先落纸改动留最小口径先对齐模型再升级08、演进[同一输入] 一条会话 一组候选 | --[V1] 单树 全局阈值 | 简单 可解释 单文件可跑 | 代价档内无序 跨组失效 排序场景表达不了 | --[V2] GBDT LTR 组内定档 | 收益组内顺序可控 评估与线上同构 | 代价分组口径要维护 特征血缘要维护 模型数量增加 | [Trade-off] 得到什么可复现的排序能力与可解释的定档规则 失去什么单脚本的极简与部分跨组可迁移性 适用边界每组样本充足、业务确实按顺序消费结果逐项比较正确性V1在“识别高风险个体”这件事上大致成立但无法回答“谁先谁后”V2把顺序变成一等公民正确性定义本身更贴近业务。稳定性单树方差大换一批数据可能换一棵树RF更稳GBDT需要认真控容量leaf-wise尤其要限num_leaves。复杂度V1是一个脚本V2是一套流程包含分组切分、校准、LTR分组、按组评估四条流水线。成本V1成本几乎为零V2的成本主要在分组维护、特征血缘、指标看板和退出条件上而不是训练算力。适用范围样本量小、候选数小于2、特征只有个位数时单树或RF仍然更划算跨组迁移要求高时RF比深度GBDT更稳。遗留问题曝光偏差被推荐过的坐席才有反馈、时间漂移政策与话术变化、以及多语言特征在不同语言间的可比性V2都没有彻底解决。单树保简单排序补顺序取舍写清楚边界别含糊09、洞见9.1 先定评估单位再定模型反直觉判断大多数“树模型不够用”的结论来自评估口径错而不是模型容量不够。我们的两条诊断都指向同一个事实随机切分加上pointwise指标可以让任何模型看起来都还行也可以让任何模型看起来都不行。评估单位是“样本”还是“会话”是“全局”还是“分组”决定了你能看到什么问题。先把单位定下来模型选型才有意义。9.2 复杂模型买到的是偏差不是全部Tree → RF 主要降方差RF → GBDT 主要降偏差GBDT → XGBoost/LightGBM 主要是工程效率正则、稀疏感知、直方图、并行而不是全新的建模思想。这条链条上越往后越贵的其实是口径与维护而不是模型本身。所以当你发现指标不动时先问一句我是容量不够还是尺子不对9.3 Learning-to-Rank是换问题不是换模型把流失预测硬套LTR得到的是一堆组内比较收益接近零把服务优先级做成pointwise分类再切档得到的是档内无序。判断标准很朴素**这个场景的答案依赖同一批候选之间的相对比较吗**依赖就用LTR不依赖就用分类加校准。9.4 维护成本随模型数量增长不随模型复杂度线性增长这是我们在系统落地时最直观的感受。三个场景、五个模型、四类分组组合出来的评估与监控矩阵是指数级的。真正的成本不在“GBDT比决策树难训”而在“每多一个模型、每多一个分组就要多一套基线、多一套门禁、多一条回滚路径”。所以控制成本的正确动作是收敛模型数量而不是回避复杂模型。9.5 退出条件必须写在上线之前每个模型卡片都应该有一行当分组样本量低于多少、当组内NDCG连续多久不达标、当某个特征的血缘断掉时退回到什么。写不出来说明这个模型还不具备上生产的资格。口径大于模型单位大于容量成本随数涨退出写在前10、系统落地放进这条全球智能客服平台看原来有什么——第7记之后平台有了一套稳定的路由与评分基线意图分类、路由决策、置信度评分都由传统小模型承担模型、特征、版本都有登记。本篇新增了什么——在模型层里加了一级“场景路由”预测类流失风险、投诉升级走GBDT加校准排序类知识推荐、坐席推荐、服务优先级走LTR同时引入固定分组键企业×语言×渠道×时间窗和按组评估流水线把NDCGk、Recallk纳入发布门禁。现在能做什么——给任意一条进线会话可以同时得到“风险分”和“在这批候选中的顺序”并且两者都能按企业、语言、渠道拆开看指标、看分布、看校准任何一个排序结果都能追溯到模型版本、特征版本与分组口径。还缺什么——曝光偏差没有处理坐席推荐里被推荐过的坐席才有反馈未被推荐的坐席永远是未知的跨语言特征的可比性还在用近似方案模型退出的自动化动作自动回退、自动降级到单树基线还没有落地这些是后面几记要处理的问题。下一步如何演进——把场景路由从“人工写死的映射表”变成配置化的模型注册中心让新增一个客服场景时可以只声明四件事场景类型预测/排序、分组键、主指标、退出条件。这一步做完模型数量增长才不会直接变成运维负担。从分数到列表从全局到分组从模型到契约从上线到可退11、小结Q1 → 预测类用GBDT加校准排序类用LTR 小样本或候选数少的场景用单树或RF Q2 → 收益必须按组、按线上口径验证 全局离线指标不能替代业务验证 Q3 → 成本涨在分组维护、特征血缘、按组评估 与退出条件上收敛模型数量比回避复杂模型更有效 状态 → 五类客服场景各自有一个可复现、可解释、 可退出的模型基线并接入统一发布门禁问题有答案能力可交付边界写清楚下一步已知12、作业12.1 理解题为什么服务优先级排序不适合用pointwise二分类直接切档因为pointwise把每条工单当独立问题输出的是绝对风险一旦用全局阈值切档同一档内就没有顺序而业务消费的恰恰是档内顺序。正确做法是把同一批待处理工单构造为一个query用listwise或pairwise目标优化组内相对顺序评估换成NDCGk或Recallk。12.2 实战题有一批跨企业、跨语言的工单要训练升级预测模型如何设计切分与评估切分按企业×语言分组杜绝同一个企业同时出现在训练集与测试集如数据带时间改用时间切分模拟线上“用过去预测未来”。评估先按组统计AUC与校准曲线再看各档位样本占比最后才看全局均值。如果业务真正消费的是顺序则在此基础上补一个LTR版本用NDCGk对比。12.3 排障题离线NDCG很好上线后人工覆盖率很高先查什么先查切分与评估口径不查模型。检查点是否随机切分导致同会话候选泄漏测试集是否包含训练期之后才出现的分布NDCG是按组算均值还是全体混算线上候选集与离线候选集是否同构候选数量、过滤规则。多数情况下修好口径后指标会落回真实水平之后再谈模型是否要换。12.4 架构判断题平台已有15个树模型业务要求再加3个场景是再加3个GBDT还是先做模型注册中心先做注册中心。15个模型的评估、监控、回滚路径已经是指数级维护成本再叠加3个场景边际收益会被运维成本吃掉。注册中心要能声明四件事场景类型预测/排序、分组键、主指标、退出条件做不到这四点的新场景宁可用单树或RF基线先跑也不要直接上复杂模型。想清再动手动手留证据排障看口径判断看收益13、思考回到开篇那个冲突复杂模型相对简单模型真实业务收益到底是什么这一轮走下来答案不是“GBDT比决策树准多少”而是三句话模型复杂度买到的是偏差和工程效率评估口径买到的是你能否看见问题分组与退出条件买到的是这套东西能不能长期活下去。在客服这类多企业、多项目、多语言、多渠道的场景里最大的风险从来不是模型不够强而是尺子不对、口径不齐、退出无门。所以选型顺序应该是先确定这个场景解的是预测还是排序再确定评估单位和分组键再确定主指标与门禁最后才在Tree、Random Forest、GBDT、XGBoost、LightGBM和LTR之间挑一个够用的。一念辨单位一证定口径一改知代价一役见真章
