员工离职预测与归因分析去年年初我接手了一个挺有意思的数据分析项目用公司HR系统沉淀下来的员工信息提前预测哪些人会在未来半年内有离职倾向。当时团队正面临一个很现实的问题——核心岗位人才流失率连续两个季度攀升招聘成本居高不下HRBP人力资源业务伙伴疲于奔命地做离职访谈但往往是等人提了离职才反应过来为时已晚。如果能提前锁定高风险人群管理层就能在窗口期内做干预。这个项目就这么立项了。整个分析过程用了大概三周时间从数据清洗、特征工程、模型选型到最终的业务落地方案踩了不少坑也沉淀了一些值得分享的经验。这篇文章就把整个项目从0到1的过程完整梳理一遍包括我当时的技术选型逻辑、关键代码实现、调参心得以及最后怎么把模型预测结果转化成HR能直接用的行动清单。无论你是刚入门数据分析想找一个完整的实战案例还是已经在做用户流失、员工流失相关分析的老手这篇都应该能给你一些参考。1. 项目整体设计与业务理解1.1 离职预测到底是一个什么问题从技术角度来说员工离职预测是一个典型的二分类监督学习问题。我们要做的事情是基于员工过去和当前的状态数据包括年龄、司龄、薪资、绩效、考勤、加班时长等训练一个模型让它输出未来某个时间段内离职/不离职的概率。但这里有一个关键点必须想清楚离职预测不是算命模型给的也不是一个绝对的判决书。它的本质是一个风险评分机制帮你在海量员工中筛出值得关注的那批人把有限的管理资源用在刀刃上。所以这个项目从一开始我就没有把模型精度当成唯一KPI而是更关注预测结果能不能落到业务动作上。比如模型告诉你张三有87%的离职概率但如果你不知道他为什么可能离职那这个数字对HRBP没有任何意义。所以这个项目实际包含了两条主线一是预测谁要走二是归因他为什么想走。两条线配在一起才能形成完整的决策闭环。1.2 框架选型与工具链选择工具链方面我最后定了Python Pandas Scikit-learn XGBoost这套组合没有上Spark。原因很简单数据量在十万级以内单机处理完全没有压力Spark在这个量级反而会增加不必要的分布式调度开销。这里想多说一句很多初学者容易陷入什么火用什么的误区但实际工作中工具的选取从来都是根据数据量和业务场景来定的。具体分工是这样Pandas负责数据清洗和特征工程这个环节大概占了整个项目60%的工作量Matplotlib Seaborn做探索性可视化用来发现特征与离职之间的初步关系Scikit-learn提供基础的机器学习算法和模型评估工具XGBoost作为最终的生产模型因为它在表格数据上的表现通常优于传统模型并且自带特征重要性输出方便我后面做归因分析。建模环境用的是本地的 Jupyter Notebook后期为了调参方便也写了一部分脚本化代码。整个过程没有用任何付费工具全部是开源组件。1.3 模型指标的选取为什么我用召回率而非准确率分类模型的评估指标有很多准确率、精确率、召回率、F1、AUC等等。在离职预测这个场景里我需要特别强调一下指标选择的问题因为这会直接影响你对模型好坏的判断。我们的业务诉求是尽可能找出会离职的人而不是对所有员工的判断都要均衡正确。如果模型把10个真正会离职的人漏判了8个即使它对另外900个留任员工的判断全部正确准确率也有98.2%但这个模型对于业务来说是废的——因为HR真正关心的那几个人一个都没找出来。所以我当时把核心指标定在了召回率Recall上同时在调参时兼顾精确率Precision用F1分数做一个平衡。如果只追求召回率模型会把所有人都预测成会离职那也没有任何区分度。实际操作中我要求模型在保持召回率不低于70%的前提下尽量把精确率做高。后面会展示这一块的具体实现。2. 数据探索与特征工程的完整拆解2.1 数据结构说明与初步观察我们拿到的原始数据是HR系统导出的一个宽表一共10000条记录每条记录代表一个员工在某个时间截面的状态快照。核心字段大概有这么几类基本信息年龄、性别、婚姻状况、教育程度、籍贯是否本地、部门、岗位组织信息司龄、当前职级、汇报层级深度、最近一次晋升距今月份、是否有过转岗薪酬信息月薪、最近一次调薪幅度百分比、薪资与同岗位中位数的比值考勤与绩效过去12个月平均绩效评分、过去12个月加班时长总和、近3个月请假天数、是否有过违规记录目标标签未来6个月内是否离职1/0这里有一个很重要的事情就是标签的定义。离职预测的标签不能简单地用是否离职一个布尔值因为离职分为主动离职和被动离职公司辞退、合同到期不续签等。我们做离职预测业务方真正关心的是主动离职因为被动离职是公司可控的不需要预防。所以我在清洗数据时把被动离职的样本直接剔除了凡是离职原因在合同到期、辞退、退休这几类的都不进入建模。清洗之后正样本主动离职占比大概是16%负样本在职/被动离职剔除后留下占比84%。这个比例属于中等不平衡状态不需要特别复杂的采样策略但会在模型训练时留意类别权重。2.2 单变量分析哪些因素和离职强相关拿到数据之后我习惯先不看模型而是用最朴素的方式感受一下数据每个特征单独拎出来看它在离职组和留任组的分布差异。这一步虽然简单但能让你对数据建立直觉避免后面被模型的复杂逻辑带偏。几个比较明显的发现司龄与离职率呈现明显的U型关系。入职不到1年的新员工离职率最高达到22%左右1到3年是相对稳定期但司龄超过5年的老员工离职率又开始回升。这个现象其实很符合职业心理规律新员工处于磨合期容易因为预期落差、融入困难等原因离开而老员工往往面临职业天花板、薪酬固化的瓶颈一旦外部有机会很容易被挖走。调薪幅度是个非常关键的分水岭。过去12个月内没有调薪记录或调薪幅度低于5%的员工离职率接近28%而调薪幅度超过15%的员工离职率只有约7%。这个差距在单变量分析里是最显著的也直接印证了薪酬激励与留任之间的强关联。加班时长与离职率不是简单的线性正相关。乍看之下加班多的人离职率高一些但细分后发现中等加班时长每月20-40小时的员工离职率反而低于完全不加班的人。合理的解释是完全不加班可能说明这个人已经被边缘化或者工作量不饱和缺乏成长感而适度加班往往伴随高强度项目参与感反而能增强组织黏性。但这个规律在加班超过60小时的组里被完全打破离职率直线上升——这说明过载加班是个危险信号。2.3 特征工程从原始字段到有效特征的转换原始数据有30多个字段但直接丢给模型是不行的。特征工程要做的就是把这些原始信息转换成模型真正能利用的形态。我当时做了四类处理第一类缺失值处理。数据里最头疼的是调薪幅度这个字段有接近15%的缺失。后来和HR确认缺失代表该员工在统计周期内没有经历过调薪。所以我用0来填充而不是用均值或中位数——因为没有调薪本身就是一个非常有价值的业务信号它就意味着激励缺位。第二类连续变量分箱。年龄、司龄、薪资这些字段直接作为连续值输入也可以但分箱之后对模型更友好也便于后续解读。我用了Pandas的cut函数年龄分成了25以下、25-30、30-35、35-40、40以上五档司龄按照0-1年、1-3年、3-5年、5年以上分档薪资则按分位数切成五档。第三类衍生特征。这是我觉得最有价值的一部分。比如薪资竞争力指数定义是员工当前薪资与他所在岗位、职级的中位数薪资的比值。这个指数比绝对值更有意义因为月薪2万在高级工程师里可能是低薪但在专员里已经是高薪了。类似的衍生特征还有晋升速度当前职级所需标准年限与实际司龄的比值、薪酬-绩效匹配度高绩效低涨幅就是危险信号。第四类时间窗口类特征。离职倾向往往不是突然出现的而是有一个酝酿期。所以我在特征里加入了近3个月请假天数、近3个月登录HR系统的频次这类时间窗口特征。这些数据看起来和离职没有直接关系但实际操作中发现准备离职的人在请假频率和系统活跃度上会有明显变化这类特征对模型的贡献不容小觑。2.4 相关性检验与多重共线性控制做特征工程的同时我顺手做了一下特征间的相关性检验。为什么要做这个因为如果两个特征高度相关比如月薪和薪资竞争力指数模型可能会给它们分配不稳定的权重导致泛化能力下降。相关性热力图看下来有几个明显的抱团现象加班时长和绩效评分正相关0.42司龄和职级正相关0.55这是符合直觉的。我的处理方法是对于相关系数超过0.7的特征对只保留与目标变量相关性更高的那个。经过一轮筛选最终进入模型的特征数量是24个这24个特征之间的两两相关系数都控制在0.6以内。最后还要提一点特征工程做完之后一定要把所有特征的量纲统一一下尤其是树模型虽然对特征尺度不敏感但后续如果要做特征重要性对比还是需要数值在同一量级上。我用的是Scikit-learn的StandardScaler做了标准化但这个操作对决策树类模型不是必须的只是统一习惯。3. 建模过程中的关键决策与代码实现3.1 数据集切分必须按时间切不能随机切这是建模环节最容易被忽视但最重要的一步数据集切分方式。在员工离职预测这个场景里我们是用过去某段时间的数据预测未来某段时间的结果天然带有时间先后关系。如果你用随机抽样的方式把数据集分成训练集和测试集那么训练集里可能包含未来时间点的样本测试集里也可能包含过去时间点的样本这会导致模型严重过拟合——因为模型偷看了未来的信息测试集的评估结果会虚高上线之后效果断崖式下跌。我当时的做法是以某个时间节点为界比如用2019年1月到2020年6月的数据做训练集用2020年7月到2020年12月的数据做测试集完全模拟真实的预测场景。# 按时间顺序切分数据而不是随机切分 train df[df[统计月份] 2020-06-01] test df[df[统计月份] 2020-06-01] X_train train.drop([target, 员工ID, 姓名], axis1) y_train train[target] X_test test.drop([target, 员工ID, 姓名], axis1) y_test test[target] print(f训练集样本量: {X_train.shape[0]}, 正样本占比: {y_train.mean():.2%}) print(f测试集样本量: {X_test.shape[0]}, 正样本占比: {y_test.mean():.2%})切完之后训练集和测试集的时间分布完全不同模型无法从测试集偷师评估结果才真实可信。3.2 三类模型对比逻辑回归、随机森林、XGBoost建模我习惯先跑几个基线模型做对比而不是一上来就调XGBoost。原因很简单基线模型能帮你估算一个合理的性能地板如果XGBoost在基线基础上没有明显提升那说明问题可能出在特征工程而不是算法上。第一版基线用的是逻辑回归。逻辑回归的优点是可解释性强每个特征对应一个权重可以直接说调薪幅度每增加一个百分点离职概率下降多少。逻辑回归的缺点也很明显它假设特征与目标之间是线性关系而员工离职这个问题里很多关系是非线性的比如司龄的U型效应所以逻辑回归的初始AUC大概在0.73左右F1只有0.41效果一般。第二版用的是随机森林。随机森林通过集成多棵决策树能捕捉非线性关系而且对异常值和缺失值都比较鲁棒。我把n_estimators设为300max_depth设为8跑出来的AUC提升到了0.85F1也到了0.55。作为基线来说这个成绩已经可以接受。第三版是XGBoost也是我最终采用的生产模型。同样的特征输入下XGBoost的AUC达到了0.89F1提升了到0.62。提升主要来自两点XGBoost的正则化机制减少了过拟合而且它对特征的单调性约束处理得更好。XGBoost的核心代码大致是这样import xgboost as xgb from sklearn.metrics import roc_auc_score, classification_report model xgb.XGBClassifier( n_estimators500, max_depth5, learning_rate0.05, subsample0.8, colsample_bytree0.8, scale_pos_weight3, random_state42 ) model.fit( X_train, y_train, eval_set[(X_test, y_test)], early_stopping_rounds30, verboseFalse ) y_prob model.predict_proba(X_test)[:, 1] y_pred (y_prob 0.3).astype(int) print(fAUC: {roc_auc_score(y_test, y_prob):.3f}) print(classification_report(y_test, y_pred))这里有几个参数值得单独说scale_pos_weight因为正负样本不平衡约16% vs 84%我设置了这个参数为负样本数除以正样本数的比值约5但实际试下来3效果更好因为过高的正样本权重会导致大量误报HR那边看不过来max_depth5层对于这个数据量够了太深会过拟合learning_rate用0.05配合500棵树比直接用0.1配200棵树效果更稳定early_stopping_rounds设置30轮早停避免无效训练浪费时间。3.3 阈值选择让模型为业务服务默认情况下模型输出的概率大于0.5就预测为正类。但在我们的场景里正类占比只有16%直接套0.5阈值会导致召回率极低大量真正的离职人员被漏掉。阈值的选择本质上是在精确率和召回率之间做权衡。我把阈值从0.1到0.5每隔0.05跑了一遍观察不同阈值下的精确率、召回率和F1值。最终选择0.3作为判定阈值这时候召回率是0.74精确率是0.48。可能有人会问精确率只有48%意味着什么意思是模型预测为高风险离职的员工里大约有一半的人最终没有离职。这在业务上是可以接受的因为对HR来说对48%的假阳性做一次离职访谈的成本很低但换来的是74%的真阳性被及时发现。宁可错杀不可漏网这就是离职预测和很多其他预测场景的区别。from sklearn.metrics import precision_recall_curve precisions, recalls, thresholds precision_recall_curve(y_test, y_prob) for thr in [0.2, 0.25, 0.3, 0.35, 0.4, 0.45, 0.5]: idx np.argmin(np.abs(thresholds - thr)) print(f阈值: {thr:.2f} | 精确率: {precisions[idx]:.2f} | 召回率: {recalls[idx]:.2f})跑完这个循环阈值和指标的关系会非常直观。这比空谈阈值应该怎么选更实际。4. 模型评估、特征重要性与落地应用4.1 模型效果评估与可解释性分析模型训练完成之后除了看AUC、精确率、召回率这些指标我还做了一步非常重要的分析特征重要性排序。XGBoost自带的feature_importances_可以输出每个特征的贡献度但我要提醒一句这个数值是相对的不是绝对的只能用来做优先级排序不能直接解读成特征A比特征B重要3倍。我们跑出来的重要性Top 5是按贡献度排序调薪幅度最近12个月薪资竞争力指数司龄分箱后近3个月请假天数最近一次晋升距今月份这个排序和最初的单变量分析结果高度一致这说明模型学到的东西和业务直觉是吻合的可以放心交付。反过来如果特征重要性和业务直觉完全冲突那就要回头检查数据质量或者特征工程是不是有bug。为了更直观地展示特征与离职概率的关系我还用SHAPSHapley Additive exPlanations库做了进一步的可解释性分析。SHAP比feature_importances更强大的一点是它能告诉你每个特征对预测结果的方向性影响。比如司龄这个特征SHAP值显示司龄在1-3年的区间时SHAP值为负降低离职概率而司龄5年以上时SHAP值为正增加离职概率。这个U型关系通过SHAP依赖图可以一眼看清。4.2 风险分层把预测结果变成一个可操作的名单模型输出的是0到1的连续概率值但业务方不可能对着一个概率值做决策尤其是几千人的大团队逐个看概率根本不现实。所以我把预测结果做成了风险分层高风险概率≥0.7立即干预名单占全体员工的约5%中高风险0.3-0.7重点关注名单占约12%中低风险0.15-0.3常规关注名单占约20%低风险0.15暂不干预占约63%这里的分层阈值不是拍脑袋定的而是和HRBP团队开了两次会结合他们的实际承载能力确定的。如果每位HRBP每个月需要完成10-15次员工沟通那么高风险名单的人数就是他们的工作上限。关键的一点是风险分层名单必须附带每个员工的Top 3风险因素。比如张三的风险标签可能包括调薪幅度不足5%司龄超过5年近3个月请假天数增加300%。这样HRBP在约谈员工之前就已经有了谈话的切入点和假设沟通效率会高很多。4.3 落地效果与业务反馈项目上线之后我们做了一次为期6个月的跟踪验证。重点看两个指标一是模型预测的准确度二是干预效率。反馈出来的结果让我挺欣慰的在模型标记为高风险的员工中实际离职率是43.6%而全公司平均离职率只有16%左右说明模型确实筛出了超高危人群。与此同时高风险人群中一个比较有意思的现象是离职概率高于0.85的员工即使HR做了干预最终离职的比例仍然很高。这批人大概率是已经拿到了外部offer属于板上钉钉的流失干预的意义不大。真正能被干预挽回的是概率在0.3到0.7这个区间的人他们有离职倾向但还没有走到不可挽回的地步。这个发现直接改变了HR的资源分配策略高风险人群做离职原因确认中高风险人群做留任影响。前者是止损后者才是投资。前者靠沟通确认事实后者靠激励方案施加影响。5. 踩坑记录与经验总结5.1 数据层面的坑这个项目最大的坑我甚至愿意单独拎出来说离职原因字段非常不可靠。我从HR系统里拿到的离职原因五花八门个人原因家庭原因寻求更好发展占了大多数。但做离职访谈的人都知道员工填写的离职原因和真实的离职原因之间有巨大的鸿沟。如果真的有人因为家庭原因离职他大概率不会在离职原因栏里写因为钱给少了。如果直接用这个字段做归因分析结论会很荒谬。我的应对办法是不用离职原因字段做特征只用它做标签是否离职归因分析完全依赖模型输出的特征重要性。也就是说我让模型自己去发现调薪幅度低和离职概率高之间的关系而不是人工告诉模型员工说自己因为钱少离职。这个方法规避了主观填报信息的偏差。第二个坑是时间窗口不一致。HR系统的数据是月快照更新的但不同模块的更新时间不完全同步。比如考勤数据可能是月初录入的但薪资数据可能是月中更新的。如果不做时间对齐模型会把未来的薪资数据和过去的离职结果混在一起造成数据泄漏。我的处理方法是统一以工资发放月份作为时间基准其他所有特征都取这个时间点之前的数据坚决不用未来的数据。5.2 模型层面的坑关于不平衡数据的处理我也要多说几句。最开始我用SMOTE过采样把正负样本变成1:1效果反而变差了。原因可能是SMOTE合成的样本并不符合真实的业务逻辑——员工离职不是一个线性插值的过程两个高离职倾向员工的特征取平均值不一定代表一个真实的潜在离职者。后来改用scale_pos_weight处理类别不平衡效果明显更好。XGBoost的scale_pos_weight本质上是给少数类样本的梯度加了权重并不创造新样本保留的真实模式更可靠。这也算是我做这类预测问题的一个经验先尝试代价敏感学习再做采样。5.3 业务落地层面的坑最后是业务落地层面的教训。刚开始我交了一版技术报告里面写满了AUC、F1、SHAP这些术语业务方看得一头雾水。后来我意识到数据分析的价值不在于模型多精确而在于业务方能不能用起来。现在做这个类型的项目我会把交付物分成三层管理层一页纸核心结论和趋势用可视化和人话写清楚让决策者30秒抓住要点HRBP操作手册风险分层名单、谈话话术建议、干预措施清单技术附录模型参数、评估指标、特征重要性方便后续数据分析团队迭代三层各取所需不再用一份报告打所有人。写在最后的两个小建议结合这个项目我想分享两个自己的体会希望对正在做或者准备做离职预测的人有帮助。第一没有放之四海而皆准的模型。我们这个项目里XGBoost表现最好换了另一个公司、另一种组织文化的数据可能随机森林甚至逻辑回归更好。关键是建立一套完整的评估、对比、迭代框架而不是执着于某一个算法。模型的本质是对业务理解的代码化表达业务理解到位了用什么模型都能出效果。第二离职预测只是起点不是终点。真正让老板掏钱的是一个完整的闭环预测出高风险人群定位出风险因素制定出干预措施然后在下一次预测里去验证干预的效果。沿着这条路继续做你甚至可以建立一个留任实验框架——对不同的人用不同的激励策略用AB测试的思路验证哪种方式真正能留住人。这才是一个成熟的数据分析项目的价值所在。 
长河君 · 2026/9/16 1:56:06 · 阅读 1.2k 员工离职预测实战：基于XGBoost的风险分层与归因分析
员工离职预测与归因分析去年年初我接手了一个挺有意思的数据分析项目用公司HR系统沉淀下来的员工信息提前预测哪些人会在未来半年内有离职倾向。当时团队正面临一个很现实的问题——核心岗位人才流失率连续两个季度攀升招聘成本居高不下HRBP人力资源业务伙伴疲于奔命地做离职访谈但往往是等人提了离职才反应过来为时已晚。如果能提前锁定高风险人群管理层就能在窗口期内做干预。这个项目就这么立项了。整个分析过程用了大概三周时间从数据清洗、特征工程、模型选型到最终的业务落地方案踩了不少坑也沉淀了一些值得分享的经验。这篇文章就把整个项目从0到1的过程完整梳理一遍包括我当时的技术选型逻辑、关键代码实现、调参心得以及最后怎么把模型预测结果转化成HR能直接用的行动清单。无论你是刚入门数据分析想找一个完整的实战案例还是已经在做用户流失、员工流失相关分析的老手这篇都应该能给你一些参考。1. 项目整体设计与业务理解1.1 离职预测到底是一个什么问题从技术角度来说员工离职预测是一个典型的二分类监督学习问题。我们要做的事情是基于员工过去和当前的状态数据包括年龄、司龄、薪资、绩效、考勤、加班时长等训练一个模型让它输出未来某个时间段内离职/不离职的概率。但这里有一个关键点必须想清楚离职预测不是算命模型给的也不是一个绝对的判决书。它的本质是一个风险评分机制帮你在海量员工中筛出值得关注的那批人把有限的管理资源用在刀刃上。所以这个项目从一开始我就没有把模型精度当成唯一KPI而是更关注预测结果能不能落到业务动作上。比如模型告诉你张三有87%的离职概率但如果你不知道他为什么可能离职那这个数字对HRBP没有任何意义。所以这个项目实际包含了两条主线一是预测谁要走二是归因他为什么想走。两条线配在一起才能形成完整的决策闭环。1.2 框架选型与工具链选择工具链方面我最后定了Python Pandas Scikit-learn XGBoost这套组合没有上Spark。原因很简单数据量在十万级以内单机处理完全没有压力Spark在这个量级反而会增加不必要的分布式调度开销。这里想多说一句很多初学者容易陷入什么火用什么的误区但实际工作中工具的选取从来都是根据数据量和业务场景来定的。具体分工是这样Pandas负责数据清洗和特征工程这个环节大概占了整个项目60%的工作量Matplotlib Seaborn做探索性可视化用来发现特征与离职之间的初步关系Scikit-learn提供基础的机器学习算法和模型评估工具XGBoost作为最终的生产模型因为它在表格数据上的表现通常优于传统模型并且自带特征重要性输出方便我后面做归因分析。建模环境用的是本地的 Jupyter Notebook后期为了调参方便也写了一部分脚本化代码。整个过程没有用任何付费工具全部是开源组件。1.3 模型指标的选取为什么我用召回率而非准确率分类模型的评估指标有很多准确率、精确率、召回率、F1、AUC等等。在离职预测这个场景里我需要特别强调一下指标选择的问题因为这会直接影响你对模型好坏的判断。我们的业务诉求是尽可能找出会离职的人而不是对所有员工的判断都要均衡正确。如果模型把10个真正会离职的人漏判了8个即使它对另外900个留任员工的判断全部正确准确率也有98.2%但这个模型对于业务来说是废的——因为HR真正关心的那几个人一个都没找出来。所以我当时把核心指标定在了召回率Recall上同时在调参时兼顾精确率Precision用F1分数做一个平衡。如果只追求召回率模型会把所有人都预测成会离职那也没有任何区分度。实际操作中我要求模型在保持召回率不低于70%的前提下尽量把精确率做高。后面会展示这一块的具体实现。2. 数据探索与特征工程的完整拆解2.1 数据结构说明与初步观察我们拿到的原始数据是HR系统导出的一个宽表一共10000条记录每条记录代表一个员工在某个时间截面的状态快照。核心字段大概有这么几类基本信息年龄、性别、婚姻状况、教育程度、籍贯是否本地、部门、岗位组织信息司龄、当前职级、汇报层级深度、最近一次晋升距今月份、是否有过转岗薪酬信息月薪、最近一次调薪幅度百分比、薪资与同岗位中位数的比值考勤与绩效过去12个月平均绩效评分、过去12个月加班时长总和、近3个月请假天数、是否有过违规记录目标标签未来6个月内是否离职1/0这里有一个很重要的事情就是标签的定义。离职预测的标签不能简单地用是否离职一个布尔值因为离职分为主动离职和被动离职公司辞退、合同到期不续签等。我们做离职预测业务方真正关心的是主动离职因为被动离职是公司可控的不需要预防。所以我在清洗数据时把被动离职的样本直接剔除了凡是离职原因在合同到期、辞退、退休这几类的都不进入建模。清洗之后正样本主动离职占比大概是16%负样本在职/被动离职剔除后留下占比84%。这个比例属于中等不平衡状态不需要特别复杂的采样策略但会在模型训练时留意类别权重。2.2 单变量分析哪些因素和离职强相关拿到数据之后我习惯先不看模型而是用最朴素的方式感受一下数据每个特征单独拎出来看它在离职组和留任组的分布差异。这一步虽然简单但能让你对数据建立直觉避免后面被模型的复杂逻辑带偏。几个比较明显的发现司龄与离职率呈现明显的U型关系。入职不到1年的新员工离职率最高达到22%左右1到3年是相对稳定期但司龄超过5年的老员工离职率又开始回升。这个现象其实很符合职业心理规律新员工处于磨合期容易因为预期落差、融入困难等原因离开而老员工往往面临职业天花板、薪酬固化的瓶颈一旦外部有机会很容易被挖走。调薪幅度是个非常关键的分水岭。过去12个月内没有调薪记录或调薪幅度低于5%的员工离职率接近28%而调薪幅度超过15%的员工离职率只有约7%。这个差距在单变量分析里是最显著的也直接印证了薪酬激励与留任之间的强关联。加班时长与离职率不是简单的线性正相关。乍看之下加班多的人离职率高一些但细分后发现中等加班时长每月20-40小时的员工离职率反而低于完全不加班的人。合理的解释是完全不加班可能说明这个人已经被边缘化或者工作量不饱和缺乏成长感而适度加班往往伴随高强度项目参与感反而能增强组织黏性。但这个规律在加班超过60小时的组里被完全打破离职率直线上升——这说明过载加班是个危险信号。2.3 特征工程从原始字段到有效特征的转换原始数据有30多个字段但直接丢给模型是不行的。特征工程要做的就是把这些原始信息转换成模型真正能利用的形态。我当时做了四类处理第一类缺失值处理。数据里最头疼的是调薪幅度这个字段有接近15%的缺失。后来和HR确认缺失代表该员工在统计周期内没有经历过调薪。所以我用0来填充而不是用均值或中位数——因为没有调薪本身就是一个非常有价值的业务信号它就意味着激励缺位。第二类连续变量分箱。年龄、司龄、薪资这些字段直接作为连续值输入也可以但分箱之后对模型更友好也便于后续解读。我用了Pandas的cut函数年龄分成了25以下、25-30、30-35、35-40、40以上五档司龄按照0-1年、1-3年、3-5年、5年以上分档薪资则按分位数切成五档。第三类衍生特征。这是我觉得最有价值的一部分。比如薪资竞争力指数定义是员工当前薪资与他所在岗位、职级的中位数薪资的比值。这个指数比绝对值更有意义因为月薪2万在高级工程师里可能是低薪但在专员里已经是高薪了。类似的衍生特征还有晋升速度当前职级所需标准年限与实际司龄的比值、薪酬-绩效匹配度高绩效低涨幅就是危险信号。第四类时间窗口类特征。离职倾向往往不是突然出现的而是有一个酝酿期。所以我在特征里加入了近3个月请假天数、近3个月登录HR系统的频次这类时间窗口特征。这些数据看起来和离职没有直接关系但实际操作中发现准备离职的人在请假频率和系统活跃度上会有明显变化这类特征对模型的贡献不容小觑。2.4 相关性检验与多重共线性控制做特征工程的同时我顺手做了一下特征间的相关性检验。为什么要做这个因为如果两个特征高度相关比如月薪和薪资竞争力指数模型可能会给它们分配不稳定的权重导致泛化能力下降。相关性热力图看下来有几个明显的抱团现象加班时长和绩效评分正相关0.42司龄和职级正相关0.55这是符合直觉的。我的处理方法是对于相关系数超过0.7的特征对只保留与目标变量相关性更高的那个。经过一轮筛选最终进入模型的特征数量是24个这24个特征之间的两两相关系数都控制在0.6以内。最后还要提一点特征工程做完之后一定要把所有特征的量纲统一一下尤其是树模型虽然对特征尺度不敏感但后续如果要做特征重要性对比还是需要数值在同一量级上。我用的是Scikit-learn的StandardScaler做了标准化但这个操作对决策树类模型不是必须的只是统一习惯。3. 建模过程中的关键决策与代码实现3.1 数据集切分必须按时间切不能随机切这是建模环节最容易被忽视但最重要的一步数据集切分方式。在员工离职预测这个场景里我们是用过去某段时间的数据预测未来某段时间的结果天然带有时间先后关系。如果你用随机抽样的方式把数据集分成训练集和测试集那么训练集里可能包含未来时间点的样本测试集里也可能包含过去时间点的样本这会导致模型严重过拟合——因为模型偷看了未来的信息测试集的评估结果会虚高上线之后效果断崖式下跌。我当时的做法是以某个时间节点为界比如用2019年1月到2020年6月的数据做训练集用2020年7月到2020年12月的数据做测试集完全模拟真实的预测场景。# 按时间顺序切分数据而不是随机切分 train df[df[统计月份] 2020-06-01] test df[df[统计月份] 2020-06-01] X_train train.drop([target, 员工ID, 姓名], axis1) y_train train[target] X_test test.drop([target, 员工ID, 姓名], axis1) y_test test[target] print(f训练集样本量: {X_train.shape[0]}, 正样本占比: {y_train.mean():.2%}) print(f测试集样本量: {X_test.shape[0]}, 正样本占比: {y_test.mean():.2%})切完之后训练集和测试集的时间分布完全不同模型无法从测试集偷师评估结果才真实可信。3.2 三类模型对比逻辑回归、随机森林、XGBoost建模我习惯先跑几个基线模型做对比而不是一上来就调XGBoost。原因很简单基线模型能帮你估算一个合理的性能地板如果XGBoost在基线基础上没有明显提升那说明问题可能出在特征工程而不是算法上。第一版基线用的是逻辑回归。逻辑回归的优点是可解释性强每个特征对应一个权重可以直接说调薪幅度每增加一个百分点离职概率下降多少。逻辑回归的缺点也很明显它假设特征与目标之间是线性关系而员工离职这个问题里很多关系是非线性的比如司龄的U型效应所以逻辑回归的初始AUC大概在0.73左右F1只有0.41效果一般。第二版用的是随机森林。随机森林通过集成多棵决策树能捕捉非线性关系而且对异常值和缺失值都比较鲁棒。我把n_estimators设为300max_depth设为8跑出来的AUC提升到了0.85F1也到了0.55。作为基线来说这个成绩已经可以接受。第三版是XGBoost也是我最终采用的生产模型。同样的特征输入下XGBoost的AUC达到了0.89F1提升了到0.62。提升主要来自两点XGBoost的正则化机制减少了过拟合而且它对特征的单调性约束处理得更好。XGBoost的核心代码大致是这样import xgboost as xgb from sklearn.metrics import roc_auc_score, classification_report model xgb.XGBClassifier( n_estimators500, max_depth5, learning_rate0.05, subsample0.8, colsample_bytree0.8, scale_pos_weight3, random_state42 ) model.fit( X_train, y_train, eval_set[(X_test, y_test)], early_stopping_rounds30, verboseFalse ) y_prob model.predict_proba(X_test)[:, 1] y_pred (y_prob 0.3).astype(int) print(fAUC: {roc_auc_score(y_test, y_prob):.3f}) print(classification_report(y_test, y_pred))这里有几个参数值得单独说scale_pos_weight因为正负样本不平衡约16% vs 84%我设置了这个参数为负样本数除以正样本数的比值约5但实际试下来3效果更好因为过高的正样本权重会导致大量误报HR那边看不过来max_depth5层对于这个数据量够了太深会过拟合learning_rate用0.05配合500棵树比直接用0.1配200棵树效果更稳定early_stopping_rounds设置30轮早停避免无效训练浪费时间。3.3 阈值选择让模型为业务服务默认情况下模型输出的概率大于0.5就预测为正类。但在我们的场景里正类占比只有16%直接套0.5阈值会导致召回率极低大量真正的离职人员被漏掉。阈值的选择本质上是在精确率和召回率之间做权衡。我把阈值从0.1到0.5每隔0.05跑了一遍观察不同阈值下的精确率、召回率和F1值。最终选择0.3作为判定阈值这时候召回率是0.74精确率是0.48。可能有人会问精确率只有48%意味着什么意思是模型预测为高风险离职的员工里大约有一半的人最终没有离职。这在业务上是可以接受的因为对HR来说对48%的假阳性做一次离职访谈的成本很低但换来的是74%的真阳性被及时发现。宁可错杀不可漏网这就是离职预测和很多其他预测场景的区别。from sklearn.metrics import precision_recall_curve precisions, recalls, thresholds precision_recall_curve(y_test, y_prob) for thr in [0.2, 0.25, 0.3, 0.35, 0.4, 0.45, 0.5]: idx np.argmin(np.abs(thresholds - thr)) print(f阈值: {thr:.2f} | 精确率: {precisions[idx]:.2f} | 召回率: {recalls[idx]:.2f})跑完这个循环阈值和指标的关系会非常直观。这比空谈阈值应该怎么选更实际。4. 模型评估、特征重要性与落地应用4.1 模型效果评估与可解释性分析模型训练完成之后除了看AUC、精确率、召回率这些指标我还做了一步非常重要的分析特征重要性排序。XGBoost自带的feature_importances_可以输出每个特征的贡献度但我要提醒一句这个数值是相对的不是绝对的只能用来做优先级排序不能直接解读成特征A比特征B重要3倍。我们跑出来的重要性Top 5是按贡献度排序调薪幅度最近12个月薪资竞争力指数司龄分箱后近3个月请假天数最近一次晋升距今月份这个排序和最初的单变量分析结果高度一致这说明模型学到的东西和业务直觉是吻合的可以放心交付。反过来如果特征重要性和业务直觉完全冲突那就要回头检查数据质量或者特征工程是不是有bug。为了更直观地展示特征与离职概率的关系我还用SHAPSHapley Additive exPlanations库做了进一步的可解释性分析。SHAP比feature_importances更强大的一点是它能告诉你每个特征对预测结果的方向性影响。比如司龄这个特征SHAP值显示司龄在1-3年的区间时SHAP值为负降低离职概率而司龄5年以上时SHAP值为正增加离职概率。这个U型关系通过SHAP依赖图可以一眼看清。4.2 风险分层把预测结果变成一个可操作的名单模型输出的是0到1的连续概率值但业务方不可能对着一个概率值做决策尤其是几千人的大团队逐个看概率根本不现实。所以我把预测结果做成了风险分层高风险概率≥0.7立即干预名单占全体员工的约5%中高风险0.3-0.7重点关注名单占约12%中低风险0.15-0.3常规关注名单占约20%低风险0.15暂不干预占约63%这里的分层阈值不是拍脑袋定的而是和HRBP团队开了两次会结合他们的实际承载能力确定的。如果每位HRBP每个月需要完成10-15次员工沟通那么高风险名单的人数就是他们的工作上限。关键的一点是风险分层名单必须附带每个员工的Top 3风险因素。比如张三的风险标签可能包括调薪幅度不足5%司龄超过5年近3个月请假天数增加300%。这样HRBP在约谈员工之前就已经有了谈话的切入点和假设沟通效率会高很多。4.3 落地效果与业务反馈项目上线之后我们做了一次为期6个月的跟踪验证。重点看两个指标一是模型预测的准确度二是干预效率。反馈出来的结果让我挺欣慰的在模型标记为高风险的员工中实际离职率是43.6%而全公司平均离职率只有16%左右说明模型确实筛出了超高危人群。与此同时高风险人群中一个比较有意思的现象是离职概率高于0.85的员工即使HR做了干预最终离职的比例仍然很高。这批人大概率是已经拿到了外部offer属于板上钉钉的流失干预的意义不大。真正能被干预挽回的是概率在0.3到0.7这个区间的人他们有离职倾向但还没有走到不可挽回的地步。这个发现直接改变了HR的资源分配策略高风险人群做离职原因确认中高风险人群做留任影响。前者是止损后者才是投资。前者靠沟通确认事实后者靠激励方案施加影响。5. 踩坑记录与经验总结5.1 数据层面的坑这个项目最大的坑我甚至愿意单独拎出来说离职原因字段非常不可靠。我从HR系统里拿到的离职原因五花八门个人原因家庭原因寻求更好发展占了大多数。但做离职访谈的人都知道员工填写的离职原因和真实的离职原因之间有巨大的鸿沟。如果真的有人因为家庭原因离职他大概率不会在离职原因栏里写因为钱给少了。如果直接用这个字段做归因分析结论会很荒谬。我的应对办法是不用离职原因字段做特征只用它做标签是否离职归因分析完全依赖模型输出的特征重要性。也就是说我让模型自己去发现调薪幅度低和离职概率高之间的关系而不是人工告诉模型员工说自己因为钱少离职。这个方法规避了主观填报信息的偏差。第二个坑是时间窗口不一致。HR系统的数据是月快照更新的但不同模块的更新时间不完全同步。比如考勤数据可能是月初录入的但薪资数据可能是月中更新的。如果不做时间对齐模型会把未来的薪资数据和过去的离职结果混在一起造成数据泄漏。我的处理方法是统一以工资发放月份作为时间基准其他所有特征都取这个时间点之前的数据坚决不用未来的数据。5.2 模型层面的坑关于不平衡数据的处理我也要多说几句。最开始我用SMOTE过采样把正负样本变成1:1效果反而变差了。原因可能是SMOTE合成的样本并不符合真实的业务逻辑——员工离职不是一个线性插值的过程两个高离职倾向员工的特征取平均值不一定代表一个真实的潜在离职者。后来改用scale_pos_weight处理类别不平衡效果明显更好。XGBoost的scale_pos_weight本质上是给少数类样本的梯度加了权重并不创造新样本保留的真实模式更可靠。这也算是我做这类预测问题的一个经验先尝试代价敏感学习再做采样。5.3 业务落地层面的坑最后是业务落地层面的教训。刚开始我交了一版技术报告里面写满了AUC、F1、SHAP这些术语业务方看得一头雾水。后来我意识到数据分析的价值不在于模型多精确而在于业务方能不能用起来。现在做这个类型的项目我会把交付物分成三层管理层一页纸核心结论和趋势用可视化和人话写清楚让决策者30秒抓住要点HRBP操作手册风险分层名单、谈话话术建议、干预措施清单技术附录模型参数、评估指标、特征重要性方便后续数据分析团队迭代三层各取所需不再用一份报告打所有人。写在最后的两个小建议结合这个项目我想分享两个自己的体会希望对正在做或者准备做离职预测的人有帮助。第一没有放之四海而皆准的模型。我们这个项目里XGBoost表现最好换了另一个公司、另一种组织文化的数据可能随机森林甚至逻辑回归更好。关键是建立一套完整的评估、对比、迭代框架而不是执着于某一个算法。模型的本质是对业务理解的代码化表达业务理解到位了用什么模型都能出效果。第二离职预测只是起点不是终点。真正让老板掏钱的是一个完整的闭环预测出高风险人群定位出风险因素制定出干预措施然后在下一次预测里去验证干预的效果。沿着这条路继续做你甚至可以建立一个留任实验框架——对不同的人用不同的激励策略用AB测试的思路验证哪种方式真正能留住人。这才是一个成熟的数据分析项目的价值所在。