ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

MathorCup竞赛实战:基于特征工程与GBDT的用户体验影响因素分析

MathorCup竞赛实战:基于特征工程与GBDT的用户体验影响因素分析 1. 项目概述与核心问题拆解去年带队参加MathorCup大数据竞赛的经历至今记忆犹新。当时我们选的是B题关于北京移动用户体验影响因素的研究。这个题目听起来很宏大但核心其实非常具体给你一堆用户的上网行为、网络信令和业务使用数据让你找出到底是什么在影响用户的“爽”或“不爽”。问题一通常是个敲门砖要求你从海量数据里把那些真正能“说话”的特征给挑出来并给出一个初步的分析框架。这活儿干得好不好直接决定了后续建模的成败。很多新手团队一上来就急着跑模型、调参数结果往往事倍功半因为喂给模型的是一堆“垃圾”特征。今天我就把我们在解决这个问题一时关于特征工程和初步分析的核心思路、实操细节以及踩过的坑系统地梳理一遍。无论你是正在备战类似竞赛的学生还是刚接触业务数据分析的从业者这套从数据到洞见的实战流程应该都能给你带来直接的启发。简单来说问题一的核心任务可以归结为特征提取与重要性初筛。我们手头的数据通常包括用户的基本属性如套餐、入网时长、网络侧指标如RSRP信号强度、SINR信噪比、上下行速率、业务体验指标如视频卡顿率、网页打开时延以及用户主观反馈如投诉工单、满意度打分。目标是从这些维度中识别出对最终用户体验常以MOS分或投诉率为量化目标影响最显著的因素。这本质上是一个高维、异构、带噪声的数据分析问题。我们的策略是分三步走首先是数据理解与清洗奠定分析基础接着是特征构造与变换把原始数据变成模型“爱吃”的格式最后是运用GBDT结合互信息等方法进行特征重要性评估与筛选锁定关键影响因素。下面我就按照这个逻辑把每个环节的“为什么”和“怎么做”掰开揉碎了讲。2. 数据理解、清洗与预处理实战拿到竞赛数据包第一件事绝不是打开代码编辑器。我们团队花了整整半天时间所有人坐在一起像侦探勘察现场一样逐字段研读数据字典Data Dictionary并抽样查看数据。北京移动这类数据集通常有几个特点一是体积大动辄几十G内存加载需技巧二是字段多网络KPI就有上百个三是存在大量缺失、异常和业务逻辑上的“脏数据”。盲目分析只会被噪音带偏。2.1 数据探查与业务逻辑对齐我们首先用pandas的info()和describe()函数对每个数据表进行快速扫描了解字段类型、缺失值比例和基本统计分布。例如用户基本信息表中“用户年龄”字段的缺失率可能很低但“ARPU值”每用户平均收入可能存在大量为0或负数的异常记录这需要结合业务判断是沉默用户还是数据采集错误注意对于通信领域数据必须理解关键指标的业务含义。比如“RSRP”参考信号接收功率正常范围大致在-85dBm到-70dBm之间如果出现大量大于-50dBm或小于-120dBm的值很可能是测试数据或采集故障需要剔除。我们当时就发现某个小区在凌晨3点持续上报RSRP为-40dBm的“极品”信号这显然不符合物理规律经查是模拟测试数据未做标记直接将其从分析集中排除。另一个重点是关联关系梳理。数据集通常包含用户维度表、网络测量事实表和业务事件表。需要通过用户ID、时间戳、小区ID等关键键进行关联。这里有个坑时间戳的格式可能不统一有的精确到毫秒有的只是日期。我们使用pandas.to_datetime()进行统一转换并特别注意了时区问题原始数据可能是UTC时间需转换为北京时区。2.2 缺失值与异常值处理策略面对缺失值我们采用分层策略高缺失率特征50%直接剔除。例如某个高级视频业务的质量指标只有极少数5G套餐用户才有数据对于整体建模贡献有限且引入大量NaN果断放弃。关键特征缺失采用基于业务逻辑的填充。例如“套餐类型”缺失我们根据用户近三个月的平均流量和通话时长通过简单的规则如月流量30GB划为“大流量套餐”进行推断填充。数值型KPI指标缺失采用同一用户在同一时间段、同一类小区下的历史均值或中位数进行填充。我们使用了pandas的groupby功能按user_id,hour_bin,cell_type分组后计算填充值。对于异常值我们结合箱线图Boxplot和业务阈值进行识别和处理。例如对于“单次TCP连接时延”我们设定业务合理上限为10秒超过此值的记录并非简单删除而是标记为“异常事件”并衍生出一个新的布尔型特征is_tcp_timeout。这样既处理了极端值对整体分布的影响又保留了“发生过异常”这一有价值的信息。2.3 特征基础构造与类型转换在正式进行复杂特征工程前需要先打好基础。这包括类型转换将分类变量如“手机品牌”、“常驻区域”进行编码。对于有序分类如套餐等级“青铜、白银、黄金”我们使用LabelEncoder对于无序分类如“手机品牌”我们使用TargetEncoder以目标变量——用户体验得分的均值进行编码以避免One-Hot编码带来的维度爆炸和树模型效率下降问题。时间特征衍生从“时间戳”字段中提取出“小时”、“是否工作日”、“是否节假日”、“时段早高峰、晚高峰、凌晨等”等特征。我们发现“晚高峰18:00-20:00”时段的网络拥塞特征对用户体验的影响权重明显高于其他时段。聚合特征初探对用户粒度的数据初步计算一些统计量如“用户近7天平均日流量”、“用户历史投诉次数”等。这些将成为后续更精细特征工程的基础。经过这一轮预处理我们得到了一份相对“干净”且包含初步衍生特征的数据集为下一步深度特征工程做好了准备。这个过程虽然繁琐但至关重要它决定了后续所有分析的“地基”是否牢固。3. 深度特征工程从原始数据到模型燃料数据清洗完后手里的数据更像是一堆“原材料”。特征工程就是把这些原材料加工成美味“菜肴”的过程其质量直接决定模型的上限。我们的思路是分层构建特征从基础统计特征到业务逻辑特征再到交叉组合特征。3.1 基于业务理解的特征构造这是最具价值也最考验功底的一环。我们小组的通信专业同学发挥了关键作用将网络KPI指标转化为更具解释性的业务特征。例如从“RSRP”和“SINR”到“信号质量等级”单纯看RSRP绝对值不够我们根据3GPP标准和实际经验定义了一个复合指标信号质量等级 0.6 * 归一化(RSRP) 0.4 * 归一化(SINR)。然后将其离散化为“优、良、中、差”四档。这个新特征比原始两个特征单独使用与用户体验的相关性更高。从“上下行速率”到“速率满意度”我们不是直接使用速率值而是根据用户当前使用的业务类型来判断速率是否达标。例如对于正在观看1080P视频的用户我们参考业界标准如YouTube的推荐码率定义了一个特征is_video_rate_satisfied如果下行速率持续高于5Mbps则为1满意否则为0。这样就把绝对的速率值转换成了与具体业务场景挂钩的“满意度”信号。序列行为特征用户的行为在时间上有连续性。我们使用滑动窗口例如过去1小时为每个用户计算了一系列序列特征如“流量使用波动率”、“频繁切换小区次数”、“高时延事件聚集度”等。计算这些特征时我们使用了pandas的rolling和expanding函数。例如计算时延波动率# 假设df是单个用户按时序排列的数据 df[rtt_rolling_std] df[round_trip_time].rolling(window6, min_periods1).std() # 过去6个采样点的时延标准差 df[rtt_volatility] df[rtt_rolling_std] / (df[round_trip_time].rolling(window6, min_periods1).mean() 1e-5) # 波动率3.2 自动化特征提取与交互特征生成在构造了大量业务特征后我们还需要一些自动化方法来发现可能被忽略的关联。这里主要用了两种方法多项式特征Polynomial Features对于我们认为可能存在非线性交互的连续型特征如“用户密度”和“平均RSRP”我们使用sklearn.preprocessing.PolynomialFeatures限定degree2仅生成交互项来生成它们的乘积项。这有助于后续的线性模型或帮助树模型更快捕捉交互效应。基于聚类构造特征我们对用户进行无监督聚类如K-Means使用的特征包括用户行为画像流量、通话、时段偏好和基础网络体验指标。然后将聚类标签作为一个新的分类特征加入数据集。这相当于让模型先“看到”用户分群的信息效果显著。例如我们聚类出了“夜间高清视频党”、“日间商务漫游族”、“低流量基础通信用户”等群体不同群体的体验敏感点差异很大。3.3 特征缩放与分布调整由于后续我们会使用基于距离的互信息计算也需要考虑模型如逻辑回归的需求对特征进行缩放是必要的。对于接近高斯分布的特征我们使用StandardScaler对于存在严重偏态如用户流量的特征我们优先尝试PowerTransformer (Yeo-Johnson)或对数变换使其分布更接近正态这对许多模型的性能有稳定提升。实操心得特征工程不是一蹴而就的。我们采用“构造-评估-筛选”的迭代循环。每构造一批新特征就快速跑一个简单的模型如LightGBM看一下特征重要性初步排名和模型性能如AUC的变化。如果重要性排名靠前的新特征很少或者模型性能没有提升说明这批特征构造的方向可能需要调整。这个快速验证闭环能节省大量时间。4. 特征重要性评估GBDT与互信息的双重视角特征准备好了接下来就要回答核心问题哪些特征最重要我们采用了“模型驱动”和“统计驱动”相结合的策略即用GBDT梯度提升决策树看特征在复杂模型中的分裂贡献同时用互信息看特征与目标变量之间线性和非线性的关联强度。两者互补结论更可靠。4.1 基于LightGBM的特征重要性分析我们选择LightGBM作为GBDT的实现因为它效率高能直接输出多种特征重要性。关键步骤如下数据准备将处理好的特征集和标签如“是否投诉”二分类划分为训练集和验证集7:3。注意保持时间序列问题中的时序关系避免用未来数据预测过去。基线模型训练使用一个相对简单的LightGBM参数进行训练主要目的是评估特征而非追求极致精度。import lightgbm as lgb params { objective: binary, metric: auc, boosting_type: gbdt, num_leaves: 31, learning_rate: 0.05, feature_fraction: 0.9, verbose: -1 } lgb_train lgb.Dataset(X_train, y_train) gbm lgb.train(params, lgb_train, num_boost_round100)解读重要性指标LightGBM主要提供两种重要性gain增益重要性特征在所有树中用于分裂时带来的平均损失减少基尼系数或信息增益。这是我们最看重的指标它直接衡量一个特征对模型预测准确度的贡献。split分裂次数特征被用作分裂点的总次数。次数多不一定代表贡献大可能只是该特征适合多次分裂。 我们通过lgb.plot_importance(gbm, importance_typegain, max_num_features20)可视化增益重要性Top 20的特征。我们的发现在本次分析中增益重要性排名前列的特征并非某个单一的原始KPI而是我们构造的复合业务特征例如“视频业务速率达标率”、“信号质量等级差的时间占比”、“忙时小区无线利用率”等。这验证了前期业务导向的特征构造工作的价值。原始KPI如“RSRP均值”虽然也上榜但排名相对靠后。4.2 基于互信息的特征筛选互信息Mutual Information, MI能够衡量两个变量之间的任意统计依赖关系包括非线性的。这对于发现那些与目标变量有复杂关联的特征特别有用。我们使用sklearn.feature_selection中的mutual_info_classif用于分类目标进行计算。from sklearn.feature_selection import mutual_info_classif # 注意互信息计算对连续特征敏感确保已处理异常值。对于分类特征需先编码。 mi_scores mutual_info_classif(X_train, y_train, discrete_featuresauto, random_state42) mi_series pd.Series(mi_scores, indexX_train.columns).sort_values(ascendingFalse)关键操作由于互信息计算量较大我们首先对高维特征进行了初步过滤例如先剔除方差几乎为0的特征。计算完成后我们将MI得分与LightGBM的增益重要性进行对比。4.3 结果对比与核心特征集确定我们将GBDT的增益重要性和互信息得分进行归一化后绘制了散点图横轴为归一化互信息纵轴为归一化增益重要性。特征落在四个象限的不同位置揭示了其不同属性象限特征特点处理建议第一象限高MI高Gain核心驱动特征。与目标强相关且对模型预测贡献大。必须保留是后续分析和建模的基石。第二象限低MI高Gain模型依赖特征。可能与目标有复杂、非线性的交互关系或通过与其他特征组合发挥作用MI未能直接捕获。保留树模型能利用其价值。需关注其稳定性。第三象限低MI低Gain冗余或弱相关特征。候选剔除以减少噪声和过拟合风险。第四象限高MI低Gain潜在干扰或泄露特征。与目标统计相关但模型认为其分裂价值不高。需警惕是否存在数据泄露如包含未来信息或与目标有虚假关联。重点审查检查业务逻辑严防数据泄露。根据这个分析框架我们筛选出了位于第一、二象限的约30个特征构成了“核心特征集”。例如我们构造的“用户近一周晚高峰平均感知速率”就稳稳落在第一象限。而一个“用户本月账单金额”特征出现在第四象限高MI低Gain经查是因为高投诉用户往往因套餐外费用高而产生高账单这属于一种结果关联而非原因在分析因果关系时需要谨慎对待。5. 问题一的结果呈现与业务解读特征筛选出来工作只完成了一半。如何将技术结果转化为业务语言并清晰呈现是竞赛拿高分和实际工作中产生价值的关键。5.1 可视化分析与故事线构建我们使用了多种可视化手段来展示结果特征重要性组合图将LightGBM的Gain重要性和互信息得分做成并列柱状图直观展示Top 15特征的双重排名。关键特征与目标变量的关系分析对于最重要的几个连续特征如“信号质量差占比”我们绘制其与用户投诉率的散点图或分段箱线图。对于分类特征如“套餐类型”我们绘制了不同类别下的投诉率对比柱状图。地理热力图我们将用户投诉数据按网格或小区进行聚合并与“平均信号质量等级”图层叠加生成地理热力图。这能直观显示网络质量与用户体验问题的空间相关性我们发现城市核心商务区的某些“热点”区域虽然RSRP信号强但因用户过度密集导致SINR差、速率低是投诉高发区。基于这些图表我们构建了一个简单的分析故事线“网络覆盖不是万能的——忙时容量与业务适配才是关键”。我们的分析显示传统上最受关注的“平均信号强度RSRP”在重要性排名中仅位列中游。而“忙时小区用户数”、“视频业务码率适配成功率”、“TCP重传率”等与网络容量和业务感知直接相关的特征占据了重要性榜首。这指向一个结论在4G/5G网络已实现广覆盖的背景下影响北京移动用户体验的主要矛盾已从“有无信号”转向了“信号好时体验是否依旧流畅”。5.2 初步归因与建议方向在问题一的框架下我们给出了初步的归因分析和发展建议主要影响因素忙时网络容量瓶颈高重要性特征集中反映了忙时晚高峰网络负载与用户体验的强负相关。视频业务体验不佳视频卡顿、缓冲相关特征重要性高说明视频业务是当前用户满意度的主要痛点。终端与网络协同问题部分“信号质量好但速率低”的案例可能与终端能力是否支持高阶调制、TCP参数配置有关。后续分析建议深入容量分析建议对Top 100高负荷小区进行重点拆解分析流量构成、用户行为。业务分层保障探讨对视频、游戏等实时业务进行网络资源调度的可行性。用户分群施策基于聚类特征对“高端视频用户”、“商务漫游用户”等制定差异化保障策略。5.3 文档撰写与答辩准备要点最后将这一切整理成文档。在竞赛中问题一的答案通常作为后续建模的基础。我们撰写时特别注意了以下几点逻辑清晰按照“数据预处理-特征工程-重要性评估-结果解读”的逻辑链来组织内容。图表专业所有图表都有清晰的标题、坐标轴标签、图例。避免使用过于花哨但难以阅读的图表。量化表达不说“A特征很重要”而是说“A特征信号质量差占比在LightGBM模型中的增益重要性为0.15排名第一其与用户投诉率的皮尔逊相关系数为0.42”。附录支撑将核心的特征重要性排名表、关键特征的定义与计算公式、数据清洗的主要规则等以附录形式提供体现工作的严谨性和可复现性。通过这一整套流程我们不仅完成了问题一的技术要求更为整个竞赛项目奠定了一个扎实、可信、具有业务洞察力的起点。这套方法论的核心——业务理解驱动的特征工程与多维度特征重要性交叉验证——在之后的许多工业界数据分析项目中也被反复证明是行之有效的。
返回列表