简介：面向机器学习初学者与数据分析人员的员工绩效数据集分析预测实例，围绕员工绩效与薪资数据展开完整建模流程，可帮助读者快速上手回归预测、特征处理与模型评估，解决实际工作中绩效与薪酬分析问题。压缩包共23个文件，含20个Python脚本、1个CSV数据集、1份PDF任务说明及readme文本，整体约266KB，代码按编号拆分便于逐步学习。目前已有68人学习下载。脚本覆盖数据读取、预处理、EDA可视化、训练集划分、随机森林回归及均方误差评估等环节，并整合MinMaxScaler、train_test_split等常用模块；附带的PDF任务说明列出50项数据集操作任务，配合CSV数据便于对照练习，适合希望掌握完整数据分析项目套路、积累可运行代码模板的入门与进阶学习者。

1. 员工绩效数据集分析预测：ZIP 里装着完整链路，但坑比代码多

AI实战-员工绩效数据集分析预测实例（含20个源代码+273.98 KB完整的数据集）.zip这类资料包，解压后往往是一份几百 KB 的 CSV 和一堆按编号排好的.py脚本。很多人跑完一遍觉得“不过如此”，但真实的员工绩效预测项目里，代码能跑通只是起点：数据脏不脏、目标列该当分类还是回归、训练集和测试集有没有泄漏，每一步都可能让结果报废。这个方向适合两类人——想找完整练手链路的数据分析初学者，以及在企业做 HR BI、想把绩效打分从“拍脑袋”变成可解释预测的从业者。下面按我自己的动手顺序拆开讲，重点放在那些新手必踩、老手也容易翻车的细节上。

2. 解压到建模前的三件事：读文件、洗数据、造特征

2.1 先看压缩包内部结构：哪个是入口脚本、哪个是数据文件

20 个源代码通常不是乱序堆放的，常见做法是按01_load_data.py、02_eda.py、03_feature_engineering.py、04_train_model.py、05_evaluate.py这样的编号拆分，脚本之间靠中间产物（处理好的 CSV 或 pickle 文件）串起来。所以第一步不是双击第一个脚本，而是把 ZIP 解压后先看文件树，确认数据文件在哪个子目录、入口脚本是哪一份，再决定从哪里开始跑。

mkdir -p employee_perf && cd employee_perf unzip -o "AI实战-员工绩效数据集分析预测实例（含20个源代码+273.98 KB完整的数据集）.zip" find . -maxdepth 2 -type f | sort

-o参数用于覆盖已存在的同名文件，避免重复解压时报错。find -maxdepth 2只列两层目录，既能看清楚结构，又不会被深层缓存文件刷屏。如果解压后看到.csv或.xlsx结尾的文件，那就是数据本体；看到.py就是源码。如果你的机器没有 unzip，用 Python 的 zipfile 也能完成同样的事：

import zipfile from pathlib import Path zip_path = Path("AI实战-员工绩效数据集分析预测实例（含20个源代码+273.98 KB完整的数据集）.zip") with zipfile.ZipFile(zip_path, "r") as zf: zf.extractall("employee_perf") print("\n".join(zf.namelist()))

这段代码会把压缩包释放到employee_perf目录，并把内部文件名全部打印出来。比起命令行，Python 方式的好处是不依赖系统环境，Windows 和 Linux 行为一致；坏处是如果有隐藏文件也会一并解压，后续做数据校验时注意排除。

提示：ZIP 文件名里的中文和括号在 bash 里容易引发分词问题，最稳妥的做法是解压前先给文件名加引号，或者直接用 Python 脚本处理。

2.2 数据质量体检：缺失、重复、越界一个都不能放过

员工绩效数据集的脏数据模式其实很固定：员工 ID 重复、部门名大小写不统一、绩效记录缺失、培训时长出现负值或几百小时这种越界值。数据集只有 273.98 KB，行数大概率在几千行，直接删行会损失太多信息，正确策略是“先体检，再按情况处理”。把质量报告写出来：

import pandas as pd df = pd.read_csv("employee_perf/data/employee_performance.csv", encoding="utf-8-sig") report = pd.DataFrame({ "dtype": df.dtypes.astype(str), "missing": df.isnull().sum(), "missing_pct": (df.isnull().sum() / len(df)).round(4), "n_unique": df.nunique(), }) print(report) print("重复行数:", df.duplicated().sum())

encoding="utf-8-sig"是为了兼容带 BOM 头的 CSV，如果你第一列名读出来带着\ufeff前缀，改成encoding="gbk"基本能解决。报告里重点看三列：missing超过 10% 的字段要单独处理；n_unique只有 1 的列直接删除，因为它不提供任何区分信息；dtype是 object 的列通常是部门、学历、招聘渠道这类类别字段，为后续编码做准备。

处理策略我一般分两类：数值列用中位数填充，不用均值——绩效数据常见长尾分布，均值容易被极端值带偏；类别列用众数填充，填充后检查样本量，占比不足 1% 的类别合并成“其他”。重复行的处理也要注意：如果出现同一员工 ID 两行、指标略有不同的情况，要用df.drop_duplicates(subset=["employee_id"], keep="last")按 ID 去重。选 last 是因为数据按时间排列时，靠后的记录更接近当前状态；如果数据集没有时间顺序，就按 first 保留第一行。

2.3 特征工程：把部门、学历、招聘渠道变成模型能读的数值

绩效预测的特征工程很少需要构造复杂交叉特征，更多是把字段转换成模型能消化的格式。类别字段有三个常见方案：LabelEncoder适合目标变量；OrdinalEncoder适合学历这种有内在等级顺序的特征；OneHotEncoder适合部门这种没有顺序的类别。一次性做完：

from sklearn.preprocessing import OneHotEncoder, OrdinalEncoder, LabelEncoder from sklearn.compose import ColumnTransformer cat_no_order = ["department", "recruitment_channel"] cat_ordered = ["education_level"] target_col = "performance_level" le = LabelEncoder() df["performance_label"] = le.fit_transform(df[target_col]) ct = ColumnTransformer([ ("ohe", OneHotEncoder(handle_unknown="ignore"), cat_no_order), ("ord", OrdinalEncoder(categories=[["高中", "大专", "本科", "硕士", "博士"]]), cat_ordered), ]) feature_matrix = ct.fit_transform(df[cat_no_order + cat_ordered]) print(feature_matrix.shape)

handle_unknown="ignore"必须写：测试集里如果出现训练集没见过的部门，OneHotEncoder 会把它们全部编码为 0，而不是抛异常——这对小数据集上稳定出数很重要。OrdinalEncoder的categories参数要手动传入顺序，否则 sklearn 按字母排序，“博士”会被排到“大专”前面，语义完全反了。类别列处理完后，把数值列直接拼到特征矩阵上，得到完整建模输入。这一步最容易被低估的是列名对齐，后面看特征重要性时，列名对不上等于白忙。

3. 建模选型与基线实验：绩效预测先定任务，再谈模型

3.1 目标列决定了模型形态：先分清“等级”和“分数”

这是建模前的第一道分岔路。员工绩效数据里目标列的价值直接决定模型形态：

• 目标是“优秀 / 良好 / 合格 / 待改进”这类等级，分类模型是正解，输出的是每个类别的概率；
• 目标是“3.5 / 4.8 / 7.2”这类连续分，回归模型更合适，输出的是连续值。

真实业务里 HR 更常给“等级”而不是“分数”，因为绩效评级本身就是分档制度。如果数据里恰好分数和等级都有，我会两个都跑：先做分类基线，再做回归基线，对比误差和业务解释成本再决定。切记不要看到数值列就默认回归——有些“评分”其实只有 1 到 5 五个整数，本质上是有序分类，硬用回归会拟合出 3.7 这种业务上不存在的中间分，解释起来很尴尬。

3.2 逻辑回归与随机森林基线：最小跑通的两段代码

第一轮建模固定用两个模型对照：逻辑回归作为线性基线，随机森林作为非线性模型和特征筛选工具。全部用classification_report输出，训练集和测试集对比一眼就能看出问题。

from sklearn.linear_model import LogisticRegression from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report X = feature_matrix y = df["performance_label"] X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.2, random_state=42, stratify=y ) models = { "LogisticRegression": LogisticRegression(max_iter=2000, random_state=42), "RandomForest": RandomForestClassifier(n_estimators=300, random_state=42), } for name, clf in models.items(): clf.fit(X_train, y_train) pred = clf.predict(X_test) print(f"[{name}]") print(classification_report(y_test, pred, zero_division=0))

stratify=y很关键，它保证训练集和测试集里各绩效档位的比例与原始数据一致，避免样本量少的档位恰好全部分到训练集、测试集里某个类别一个样本都没有。zero_division=0用于测试集中某个类别完全没有出现时，报告不报警告、直接输出 0。max_iter=2000是防止逻辑回归在特征维度偏高时还没收敛就提前停止。第一轮跑完主要看两个数：macro-F1 以及训练集与测试集准确率的差距。如果随机森林训练集接近 100%、测试集只有八成上下，说明特征维度够但区分度不足，下一步进入调参和特征筛选。

3.3 特征重要性：用业务常识反向验证模型有没有在瞎学

随机森林天然能输出特征重要性，但要用对姿势：

importance = pd.DataFrame({ "feature": X_train.columns, "importance": models["RandomForest"].feature_importances_, }).sort_values("importance", ascending=False) print(importance.head(10))

拿到结果后，先别急着调参，拿业务常识去校验一遍。如果“员工 ID”排进前三，基本说明模型在记训练集的顺序信息，这种特征要么删除，要么做 shuffle 测试后处理；如果“上次绩效评估分数”重要性异常高，警惕它是不是以滞后变量的方式泄露了当前结果。行业项目里，入职年限、参与项目数、培训时长、月平均工作时长这几个特征通常会排进前十。把特征列表跟业务对照，能直接筛掉八成隐性泄漏问题——这一步比调参重要得多。另外要注意，某个部门的 OneHot 列排名高，只代表该部门在数据里的样本量大，不代表模型认为该部门的人就该得高分。绩效预测场景里这种偏差如果不管，容易演变成指标上的隐形偏见，业务上需要单独拉出来分析。

4. 交叉验证与调参：小数据集上如何让评估结果可信

4.1 分层 K 折交叉验证：单次划分的 F1 是抽样噪声

273.98 KB 的数据集本身不大，单次train_test_split的结果受随机性影响很大——同一份数据换个种子，F1 可能从 0.73 跳到 0.81。所以我固定用 StratifiedKFold 做 5 折交叉验证，把稳定性测出来：

from sklearn.model_selection import StratifiedKFold, cross_val_score cv = StratifiedKFold(n_splits=5, shuffle=True, random_state=42) scores = cross_val_score( models["RandomForest"], X, y, cv=cv, scoring="f1_macro" ) print("每折 F1:", scores) print("均值:", scores.mean().round(4), "标准差:", scores.std().round(4))

shuffle=True让每个折内的样本被重新打乱，避免原始数据按部门聚堆导致某些折全是同一个部门的人。random_state=42保证每次跑的折划分完全一致，调参前后才有可比性。n_splits=5而不是 10 是有原因的：数据量小，折数越多每个训练折的样本越少，模型学不充分，5 折是稳定性和训练量之间的合理折中。

为什么不直接把全部数据训练后留 20% 做验证？因为单次划分得到的 F1 是一次抽样结果，跳动太大。交叉验证给出 5 次均值和方差：均值代表模型真实水平，方差代表“不同数据切法下模型的稳定性”。方差大于 0.05 时，先怀疑过拟合，再排查特征里有没有员工 ID 这类高方差列，而不是急着换模型。

提示：交叉验证跑出来的均值，才是你对外汇报“模型能达到什么水平”的可靠口径。单次划分的数字不要写在报告里，容易被复现时打脸。

4.2 网格搜索调参：随机森林在绩效数据上的四个旋钮

绩效预测特征数量不多（常见在 20 到 40 个列以内），用 GridSearchCV 完全够，不需要上贝叶斯优化。我常用的参数网格是这四个：

from sklearn.model_selection import GridSearchCV param_grid = { "n_estimators": [100, 300], "max_depth": [None, 10, 20], "min_samples_split": [2, 5], "min_samples_leaf": [1, 3], } gs = GridSearchCV( RandomForestClassifier(random_state=42), param_grid, cv=StratifiedKFold(5, shuffle=True, random_state=42), scoring="f1_macro", n_jobs=-1, ) gs.fit(X_train, y_train) print("最佳参数:", gs.best_params_) print("最佳得分:", gs.best_score_)

几个参数的实际含义：max_depth=None表示不限制树深，随机森林特征少时一般不会长太深，但如果发现单棵树深度超过 30，就要限制到 10 或 20，否则训练慢还过拟合；min_samples_leaf限制叶节点最少样本数，设置越大模型越保守，适合类别不平衡的绩效数据；n_jobs=-1让所有 CPU 核并行跑，内存紧张就改成 2。scoring="f1_macro"必须和上一步交叉验证的口径一致，不然 best_params_ 可能是“精度高但少数类全错”的配置。

4.3 评估指标怎么选：准确率在绩效预测里是个陷阱

绩效数据几乎恒常存在档位不平衡：“合格”往往占 60% 以上，“待改进”可能只有 5%。用准确率评估时，模型只要不停输出“合格”就能拿到一个好看的分数，等于没做预测。这是我在这类项目里最头疼的地方——业务方习惯看准确率，但准确率在不均衡样本下会掩盖模型失效。

选指标前先回答一个问题：这个预测结果被谁用、用错了会发生什么。如果只做人效分析和趋势参考，f1_macro 就够；如果结果直接进薪酬或晋升流程，就要细分精度和召回的代价差，甚至引入自定义代价矩阵，把“把差绩效误判成优秀”的成本设成“把优秀误判成差”的三到五倍，让阈值偏移反映业务偏好。

5. 避坑与排查：员工绩效预测五个典型的翻车现场

5.1 现象：训练集精度接近 100%，测试集 F1 却只有七成

原因：特征里藏了数据泄漏。最常见的是“上次绩效评分”“是否获得过优秀奖”这类字段——它们与目标变量存在强先后关联或语义重叠，相当于把答案提早写进了输入。

解决：把直接指代结果的字段从特征矩阵中删除。如果业务上确实需要，退一步的做法是把“上次绩效等级”单独处理成滞后特征（例如做概率编码后作为先验变量）。大原则是：预测目标是“未来绩效”，输入特征必须全部来自预测时刻之前已经存在的信息。

5.2 现象：全部样本被预测成“合格”

原因：绩效等级严重不平衡，模型学到的最优策略就是永远输出多数类。准确率挺好看，但少数类全被吞了。

解决：先给模型加class_weight="balanced"，让少数类在损失函数里获得更高权重；还不行就用阈值修正——在验证集上搜索能让 f1_macro 最高的判定阈值，不要用默认的 0.5。逻辑回归在这个问题上尤其适用，因为它输出的概率值偏差大，靠阈值拉回是性价比最高的方案。

5.3 现象：pandas 读 CSV 第一列出现乱码

原因：文件实际是gbk编码保存的，pandas 默认按utf-8读取，中文列名和部门名直接乱掉。Windows 下 Excel 另存的 CSV 最常见就是这个编码。

解决：读取时直接指定encoding="gbk"重试，或者先用chardet探测编码。不要在读取后再做全局转码，那会改变中文字段的字节表示，影响后续和名称相关的合并匹配。正确的做法是读取阶段就明确编码，保证数据一进 DataFrame 就是干净的。

5.4 现象：同一份代码换台机器，F1 从 0.80 掉到 0.75

原因：模型、数据划分、抽样流程里有一处随机种子没固定。train_test_split每跑一次划分不同，模型的random_state没传值时初始化权重不同，结果自然漂移。

解决：统一定义一个常量RANDOM_STATE = 42，所有涉及随机的函数，包括 train_test_split、StratifiedKFold、RandomForest、LogisticRegression，都显式传入。这样同一份数据在任何人的电脑上跑结果一致，团队协作时省去“我的环境跟你不一致”的扯皮。还要注意 sklearn 版本差异，不同版本同一参数跑出的结果可能不同，复现时把依赖版本也记下来。

5.5 现象：按部门拆分验证时模型效果骤降

原因：绩效分布在不同部门之间差异很大，例如销售部门的月均工时和研发部门完全不同，随机划分的交叉验证掩盖了这种分布差异。真实上线场景中，预测脚本可能遇到一个训练时没见过的部门，模型在这些“域外样本”上会明显退化。

解决：用GroupKFold按部门分组划分训练和验证折，保证每组要么全部在训练集中、要么全部在验证集中。这个评估条件更苛刻，但也更贴近真实业务——上线后遇到新部门的可能性是存在的。如果模型在 GroupKFold 下表现稳定，再去跑随机划分的交叉验证，得到的结果就有说服力得多。

6. 模型落地：把 20 个零散脚本收敛成一条可复用的预测管线

前面所有分析和调参，最终都要回答“这套代码能不能用于下一次绩效评估”。零散的 20 个源代码通常按数据处理、训练、评估拆分，真实业务中不可能每次来新数据都手动跑一遍 01 到 20 号脚本，把整个流程封装成一条 Pipeline 才是正解。

常见做法是用 sklearn 的 Pipeline + ColumnTransformer 把预处理和模型打包成一条链，训练完成后用 joblib 持久化模型对象，之后的新数据只需加载模型做批量预测：

import joblib from sklearn.pipeline import Pipeline from sklearn.compose import ColumnTransformer from sklearn.preprocessing import OneHotEncoder, StandardScaler from sklearn.ensemble import RandomForestClassifier cat_cols = ["department", "recruitment_channel"] num_cols = ["years_at_company", "training_hours", "number_of_projects"] target_col = "performance_label" prep = ColumnTransformer([ ("ohe", OneHotEncoder(handle_unknown="ignore"), cat_cols), ("num", StandardScaler(), num_cols), ]) pipe = Pipeline([ ("prep", prep), ("clf", RandomForestClassifier( n_estimators=300, max_depth=10, min_samples_leaf=3, random_state=42 )), ]) pipe.fit(X_train, y_train) joblib.dump(pipe, "employee_performance_model.joblib") print("模型已保存，输入列:", cat_cols + num_cols)

这里三个要点：handle_unknown="ignore"保证未来出现新部门时预处理不报错，这是测试集和真实业务数据之间最大的差异，也是最常见的报错点；StandardScaler 放在数值列上让量纲统一，随机森林虽然不敏感，但以后替换成逻辑回归或 SVM 时预处理已经就位；joblib 保存的是完整 pipeline，预测时不需要再手动做 OneHot、填充缺失值或标准化，这些全部在 fit 阶段固化进模型对象。

下次拿到新数据，预测脚本只剩十行：

def predict_performance(df_new): model = joblib.load("employee_performance_model.joblib") proba = model.predict_proba(df_new[cat_cols + num_cols]) return model.classes_.take(proba.argmax(axis=1)), proba

这里用predict_proba而不是predict，因为 HR 业务方一般不仅想知道等级，还想知道各档位概率——“员工 A 属于优秀的概率是 0.72”这个值在人工复核时的参考意义远大于一个硬标签。后续如果要对阈值做调整，直接从 proba 上重新分配即可，不需要重新训练模型。

我最后的习惯是：这套流程在真实项目里不建议第一次就全自动上线。先跑一个季度的人工平行对照——模型输出和绩效委员会打分并排对比，重点复核差异大的样本，确认是数据问题还是模型误判。连续两个季度偏差率稳定后，再逐步让模型输出成为辅助参考。就像调参时留一手验证集那样，给业务方留一条后退的路，模型才有机会真正落地。希望这段复现和踩坑记录能帮你在绩效预测这个方向上少走一些弯路。

本文还有配套的精品资源，点击获取