简介这是基于机器学习实现微博恶意用户识别的高分项目完整资源包覆盖数据采集、特征工程、模型训练到系统展示全流程面向人工智能、通信、自动化、电子信息、物联网等计算机相关专业的学生和教师可快速用于毕业设计、课程设计或创新项目立项。压缩包共包含56个文件整体约8.8MB其中13个Python脚本负责爬虫采集、用户关系分析、新用户识别与Web接口20个npy文件保存了处理好的特征与模型数据6个dat文件为样本语料另有SQL数据库脚本、HTML页面、YAML配置、Markdown文档和Shell部署脚本完整支撑从数据库搭建到前端演示的每个环节。目前已有65人学习下载。除了可直接运行的代码外资源还附带微博爬虫脚本、Flask演示站点、项目授权码、README说明以及关键Cookie配置能帮助读者理解恶意用户识别中数据获取、样本标注、特征构建和模型评估的完整思路由于项目已通过高分评审代码规范和注释质量也有参考价值适合有一定Python基础并希望快速搭建同类系统的开发者。1. 微博恶意用户识别系统到底在解决什么问题先看三类让运营头疼的账号做机器学习项目最怕的不是模型效果差而是业务方把“恶意用户”四个字当成一个黑匣子。微博场景里的恶意用户拆开看至少有三类批量注册的营销号、抱团刷转评赞的水军、专门引战和传播虚假信息的反串账号。这三类账号在行为模式上差异很大放在同一个模型里训经常会出现“照顾了营销号、漏掉水军”的尴尬局面。这篇笔记要讲的就是怎么把这套识别系统从数据标注、特征工程、模型训练到上线评估完整落地适合正在做内容安全、风控方向或者拿社交媒体数据练手的从业者参考。你不需要有深度学习基础机器学习里的常规分类算法就够用关键是特征口径和采样方式别踩坑。2. 从业务定义到训练数据判别口径、标注方案与样本配比2.1 恶意用户的判别口径先把“什么是坏人”写成可标注的规则项目里最容易翻车的地方是把“恶意”这种主观词直接丢给标注员。标注员理解的恶意和产品经理理解的恶意往往不是一回事最后产出的标签噪声会让模型学出一堆莫名其妙的规律。我习惯的做法是先把恶意用户拆成三层判别口径行为层短时间内高频发布、批量转发、大量不相关用户、频繁修改昵称。内容层文本里包含推广关键词、诈骗话术、引战用语或者图片二维码。关系层关注列表中僵尸号占比高、互动用户集中在同一批账号、被其他用户多次举报。每一层都要写成“可勾选”的清单例如“1小时内发布超过20条原创微博”算高频发布“被举报次数超过5次”算异常互动。只有把这些标准提前固化下来标注员才能稳定执行。你可能会问规则定得这么细是不是直接用规则就行不是的。规则的覆盖面和组合能力远不如模型规则的价值在于给模型提供高质量的训练标签。2.2 公开微博数据采集用受限但合规的方式拿到训练样本拿到训练数据是这个项目的第一个硬门槛。微博开放平台提供的API权限现在收得很紧常规做法是维护一批自己可控的账号登录后采集公开页面的数据。这里必须强调只采集公开信息、控制请求频率、不碰私信和隐私数据这是底线。下面是一段简化版的采集脚本思路是从搜索结果页或者用户主页拿到公开微博数据import requests import time import pandas as pd # 模拟浏览器UA不带伪造参数只做最基本的标识 HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://weibo.com/ } def fetch_user_timeline(user_id, cookie, max_page5): 采集指定用户的公开微博列表。 user_id: 用户ID cookie: 自己账号登录后的cookie注意不要泄露 max_page: 最大翻页数 all_statuses [] for page in range(1, max_page 1): url https://weibo.com/ajax/statuses/mymblog params { uid: user_id, page: page, feature: 0 } try: resp requests.get(url, headersHEADERS, paramsparams, cookies{Cookie: cookie}, timeout10) data resp.json() for item in data.get(data, {}).get(list, []): all_statuses.append({ user_id: user_id, created_at: item.get(created_at), text: item.get(text_raw, ), reposts_count: item.get(reposts_count, 0), comments_count: item.get(comments_count, 0), attitudes_count: item.get(attitudes_count, 0) }) except Exception as e: print(fpage {page} error: {e}) time.sleep(2) # 低频访问避免给平台造成压力 return pd.DataFrame(all_statuses)这段逻辑本身不复杂但有几个参数值得注意。max_page控制采集深度恶意账号通常在5页以内就能看到明显的批量转发痕迹超过5页边际收益很低。time.sleep(2)是必写的如果去掉连续请求会在几分钟内触发平台的风控限制导致后面的账号全部失效。cookie建议单独写在配置文件里不要硬编码到代码中。采集到的数据要存成统一格式的DataFrame字段里必须保留created_at时间戳。后面做特征工程时时间戳是判断“批量行为”的关键一旦丢失就得重新采集这是没有后悔药吃的。2.3 类别不平衡下的样本配比欠采样比过采样更稳微博里恶意账号的比例通常只有百分之几如果直接拿全量数据训练模型会学成“全部预测为正常用户”准确率照样很高却毫无用处。处理不平衡我常用的方案是两层。第一层是欠采样从正常用户里随机抽出一部分把正负比控制在1比5到1比10之间。第二层是给少数类适当加权在损失函数里把恶意样本的惩罚系数调高。为什么不用SMOTE这类过采样因为微博用户特征是高维稀疏的SMOTE生成的是特征空间里的插值样本这些插值很可能落在真实数据不存在的区域模型上线后遇到真实恶意账号反而会误判。欠采样还有一个隐性问题随机抽样的正常用户可能“不干净”。有些账号表面上正常但偶尔也发广告。我的处理办法是先用规则筛掉这部分“灰色样本”只保留没有触发任何恶意规则的账号进入负样本池。这样模型学到的是“干净正常用户”和“明确恶意用户”之间的分界虽然有些理想化但在工程上比带噪训练更可控。3. 特征工程决定模型上限把用户行为翻译成特征矩阵3.1 四类特征属性、内容、行为、社交一个都不能少机器学习项目里经常听到一句话特征决定上限模型只是逼近这个上限。微博恶意用户识别系统里特征工程的空间比模型调参大得多。我常用的特征体系分四块属性特征账号注册时长、昵称长度、是否包含数字、头像是否默认、个人简介长度。批量注册的营销号通常昵称是随机字符串头像默认简介为空白。内容特征微博文本的重复度、含链接比例、含二维码图片比例、高频词集中度。水军账号发帖文本经常是一个模板批量替换关键词。行为特征单位时间内的发博频率、转发比例、评论比例、活跃时段分布。正常用户一天发2到3条水军可能一小时发20条而且集中在凌晨。社交特征粉丝数与关注数比值、互粉比例、互动用户重合度、被举报次数。恶意账号的粉丝数往往异常高但互动质量很差。这四类特征不是并列关系行为特征和内容特征对营销号和水军的区分度最高属性特征和社交特征则更擅长识别僵尸粉和反串账号。完整项目里大概会构造50到80维特征但新手不必一上来就堆特征先把每类里的核心特征算清楚再逐步扩展。3.2 特征计算落地24维特征矩阵的完整代码下面是一段计算用户级特征的核心代码涵盖了属性、内容、行为三类特征社交特征需要额外拉取关注列表数据import numpy as np import pandas as pd from datetime import datetime def build_user_features(df_status, user_profile): df_status: 该用户的历史微博数据包含created_at, text, reposts_count等 user_profile: 用户属性截图包含注册时间、粉丝数、关注数、简介等 返回一个包含24维特征的字典 features {} # 属性特征 reg_days (datetime.now() - datetime.strptime(user_profile[reg_time], %Y-%m-%d)).days features[reg_days] reg_days features[nickname_len] len(user_profile[nickname]) features[nickname_has_digit] int(any(ch.isdigit() for ch in user_profile[nickname])) features[is_default_avatar] int(user_profile[avatar] default) features[profile_len] len(user_profile[description]) # 内容特征 text_count len(df_status) features[text_count] text_count # 重复度去除完全相同的文本后的比例 unique_ratio df_status[text].nunique() / max(text_count, 1) features[unique_ratio] unique_ratio # 链接比例 link_ratio df_status[text].str.contains(http).mean() features[link_ratio] link_ratio # 平均原创度转发微博的比例 repost_ratio df_status[text].str.startswith(转发微博).mean() features[repost_ratio] repost_ratio # 行为特征 if text_count 0: time_list pd.to_datetime(df_status[created_at]) # 单位时间发博频率按天聚合 daily_count time_list.dt.date.value_counts() features[max_daily_count] daily_count.max() features[avg_daily_count] daily_count.mean() # 夜间(0-6点)活跃占比 night_ratio time_list.dt.hour.isin([0,1,2,3,4,5]).mean() features[night_ratio] night_ratio # 转发/评论/赞的均值 features[avg_reposts] df_status[reposts_count].mean() features[avg_comments] df_status[comments_count].mean() features[avg_attitudes] df_status[attitudes_count].mean() # 互动率被互动数 / 发博数 total_interact (df_status[reposts_count] df_status[comments_count] df_status[attitudes_count]).sum() features[interact_per_status] total_interact / text_count else: features[max_daily_count] 0 features[avg_daily_count] 0 features[night_ratio] 0 features[avg_reposts] 0 features[avg_comments] 0 features[avg_attitudes] 0 features[interact_per_status] 0 # 社交特征部分字段从profile补充 fans max(user_profile[followers_count], 1) follow max(user_profile[following_count], 1) features[fans_follow_ratio] fans / follow features[fans_per_reg_day] fans / max(reg_days, 1) # 补齐到24维加上账号是否认证、是否会员等标记 features[is_verified] int(user_profile[verified]) features[is_vip] int(user_profile[vip]) features[gender_unknown] int(user_profile[gender] 未知) features[city_level] user_profile.get(city_level, 0) return features这段代码里有几个容易忽略的细节。unique_ratio计算的是去重后的文本数与总文本数的比值恶意账号这个值通常非常低因为大量转发内容都是重复的。interact_per_status是平均每条微博获得的互动量水军账号互动主要来自同伙数量和正常账号有明显差异。fans_follow_ratio对识别互粉群很重要正常用户这个值在1左右机器养的粉头账号可能高达几十。注意repost_ratio用startswith(转发微博)判断并不完美因为微博的转发文本格式历史上改过多次。更稳妥的做法是判断text里是否包含“转发”字样或者原文链接结构但这会引入噪声。工程上你只需要保证训练集和线上预测时用的判断逻辑保持一致相对大小就有意义绝对准确性反而不是首要考虑。3.3 特征筛选相关性分析与稳定性检验特征算完之后不要一股脑丢给模型。我先做三件事第一计算特征间的皮尔逊相关系数把相关系数超过0.9的特征对挑出来只保留其中一个。比如fans_per_reg_day和reg_days高度相关两个都用会让模型重复学习同一信息还增加过拟合风险。第二看每个特征的分布是否在训练集和验证集上有明显偏移。比如“平均每条微博互动量”这个特征如果训练数据是某个时间段采集的而验证数据来自另一个时间段分布可能差异很大。简单画一下分位数对比就能发现。第三用RandomForest跑一次特征重要性把重要性为0的特征剔除。常见做法是保留前30维左右的特征再进入训练环节。from sklearn.ensemble import RandomForestClassifier def select_features(X_train, y_train, feature_names, top_k30): 用随机森林粗筛特征返回保留的特征名列表 model RandomForestClassifier(n_estimators200, random_state42, n_jobs-1) model.fit(X_train, y_train) importance pd.Series(model.feature_importances_, indexfeature_names) importance importance.sort_values(ascendingFalse) return importance.head(top_k).index.tolist()n_estimators设成200random_state固定保证结果可复现。特征筛选用的随机森林不需要调参它的作用只是给特征重要性排序不是最终分类器。这一步做完特征维度从五六十降到二三十训练速度和模型稳定性都会明显提升。4. 模型选型与训练从逻辑回归到集成学习的完整流程4.1 基线模型选逻辑回归上线快、好解释、能兜底第一次做这个系统千万别直接上XGBoost。先用逻辑回归跑通全链路理由有三个一是逻辑回归对特征尺度不敏感特征工程做完后可以直接丢进去二是它的输出是概率方便后面调阈值三是出了问题好排查。逻辑回归的L2正则系数C需要调默认值1.0在特征维度不高时通常够用。训练前对数值型特征做标准化避免量纲差异影响收敛。from sklearn.linear_model import LogisticRegression from sklearn.preprocessing import StandardScaler from sklearn.pipeline import Pipeline def train_baseline(X_train, y_train): 训练逻辑回归基线模型输出模型和标准化器 pipeline Pipeline([ (scaler, StandardScaler()), (lr, LogisticRegression(C1.0, class_weightbalanced, solverliblinear, random_state42)) ]) pipeline.fit(X_train, y_train) return pipelineclass_weightbalanced让少数类自动加权相当于2.3节提到的损失函数加权。solver选liblinear它适合中小规模数据和二分类问题收敛稳定。如果数据集超过10万条换成saga会更快。逻辑回归训练完我习惯先把系数打印出来看一遍。某些特征的系数符号和业务直觉相反多半是数据有泄漏或者特征构造错误趁早修正不要等到后面模型上线了才发现。4.2 集成模型闪亮登场随机森林与XGBoost的调参重点逻辑回归跑通之后再上集成模型。实践中随机森林和XGBoost在这个任务上的表现通常会明显超过逻辑回归原因仍然是特征里有大量非线性关系。比如unique_ratio低和night_ratio高同时出现才是恶意特征单看任何一个都不够。随机森林重点调三个参数n_estimators300到500之间足够再大收益很小且训练变慢。max_depth限制在10到20防止对训练集中的噪声拟合过深。min_samples_leaf设为50左右恶意用户识别场景里叶子节点太小会导致线上误判率升高。XGBoost的调参可以套用一套相对固定的组合import xgboost as xgb def train_xgb(X_train, y_train, X_val, y_val): 训练XGBoost模型用早停防止过拟合 dtrain xgb.DMatrix(X_train, labely_train) dval xgb.DMatrix(X_val, labely_val) params { objective: binary:logistic, eval_metric: auc, eta: 0.05, max_depth: 6, min_child_weight: 5, subsample: 0.8, colsample_bytree: 0.8, scale_pos_weight: 5, # 正负样本比例失衡时的加权 random_state: 42 } model xgb.train( params, dtrain, num_boost_round1000, evals[(dval, val)], early_stopping_rounds50, verbose_eval50 ) return modeleta设0.05是让每棵树学得慢一点留出早停空间。scale_pos_weight的经验值是负样本数除以正样本数我这里是按5倍的失衡比例设置的实际项目中量一下训练集的真实比例再填。early_stopping_rounds50意味着验证集AUC连续50轮不提升就停这比固定迭代次数省心得多。XGBoost训练完还有一个额外动作把特征重要性导出来对比一下随机森林的结果。两个模型给出的Top特征如果高度一致说明特征工程做扎实了如果差异很大需要检查是否存在特征泄漏或者特定特征被某个模型过度利用。4.3 模型融合与阈值调整F1优先还是召回优先实际使用中单独一个模型总会有漏网之鱼。常见做法是把逻辑回归、随机森林、XGBoost三个模型的预测概率做加权平均权重通过验证集上的网格搜索确定。我习惯给XGBoost权重0.5随机森林0.3逻辑回归0.2因为XGBoost在这个任务上的整体表现通常最好。但比融合更关键的是阈值调整。默认0.5的阈值对恶意用户识别不一定合适。这里取决于业务目标如果人力审核资源充足希望多抓、冤枉了也没关系那就把阈值调低到0.3提高召回率如果误删正常账号会影响用户体验那就把阈值调到0.7优先保证精度。from sklearn.metrics import precision_recall_curve def find_best_threshold(y_true, y_prob): 遍历阈值找到F1最高的概率截断点 precision, recall, thresholds precision_recall_curve(y_true, y_prob) f1_scores 2 * precision * recall / (precision recall 1e-6) best_idx f1_scores.argmax() best_threshold thresholds[best_idx] print(fbest threshold: {best_threshold:.3f}, f1: {f1_scores[best_idx]:.3f}) return best_threshold这段代码的核心是precision_recall_curve它返回在不同阈值下的精确率和召回率。恶意用户识别看PR曲线比看ROC曲线更合适因为正样本占比太低ROC曲线会给人“模型很好”的错觉PR曲线才对少数类的表现更敏感。阈值定下来后我还会额外检查一下“高概率正常用户”中是否混有恶意账号。方法是对预测概率在0.1以下的样本做人工抽样复核如果抽样结果里发现恶意账号占比超过预期说明特征或者训练数据里还有问题不要急着上线。5. 恶意用户识别系统避坑三个月踩过的五个真实大坑5.1 特征穿越用“未来信息”预测过去线上直接翻车现象离线验证时AUC高达0.98一上小流量灰度误报率暴涨。原因特征计算时混入了用户“被识别后”的数据。比如用is_verified是否被平台认证这个特征判断历史恶意行为但恶意账号往往是先被封禁、后来才被认证或者被清粉特征里包含了未来信息。更隐蔽的是用户的历史微博互动量是从采集时刻的快照里算出来的采集时刻离行为发生时刻可能已经过了几个月。解决时间对齐。训练样本只使用“在预测时间点之前已产生”的数据上线时也要保证线上特征的计算窗口与训练时一致。最稳妥的做法是把特征计算函数封装成同一个接口训练和预测共用一套代码。5.2 采集数据分布漂移模型上线三个月后效果下滑现象模型上线初期效果好后来每天抓到的新恶意账号越来越少误报却越来越多。原因微博的平台策略和用户行为都随时间变化。早期恶意账号的特征明显批量转发、链接轰炸模型容易学后来恶意账号开始模拟正常用户发帖频率降低互动变自然旧模型的判定标准失效了。解决建立周期性重训机制。我的习惯是每周跑一次数据分布对比监控核心特征的均值和分位数变化。当超过20%的核心特征出现显著偏移时就要补充新样本重训。实际操作中最好每月固定重训一次中间穿插新特征实验。5.3 标签噪声标注员的“顺手举报”把模型带进沟里现象模型预测的恶意用户里有一批账号反复被系统误杀查来查去发现训练集里它们的标签被标错了。原因初版标注标准执行不到位。有些标注员看到账号发广告就标为恶意但没注意到这个账号是正常用户偶尔转发了广告内容还有一些标注员在拿不准时倾向于“宁可错杀”大量灰色样本被标成正样本。解决给标注任务加校验环节。每个样本至少两人的标注结果一致才采用不一致的进入仲裁。成本会上升但训练数据的质量决定模型上限这笔投入不能省。另外训练时要把标注置信度低的样本过滤掉或者折价计算它们的损失贡献。5.4 评测方式错误随机切分验证集低估了“跨用户泛化”难度现象验证集上F1达到0.85线下测试满意到了线上效果只有0.6。原因随机切分验证集时同一个用户的样本可能同时出现在训练集和验证集里。模型记住了这个用户的特征验证时碰上“见过”的用户效果虚高。真实场景里系统面对的是完全没见过的账号。解决按用户切分。把所有训练样本按用户ID分组确保同一个用户的所有样本只出现在训练集或只出现在验证集中。这是风控类项目最基本的数据划分纪律踩过这一次之后我再也不做随机切分了。5.5 规则与模型打架模型概率高但规则库不联动运营不信任模型现象模型判定某个账号恶意概率0.9但规则库的命中条数只有一条。运营同事来质问为什么这个账号要封。原因规则库和模型是两套独立系统没有形成互相补充的关系。规则库擅长处理确定性场景模型擅长处理复杂场景中间有大量灰色地带没人解释。解决上线模型时输出判别理由把命中的核心特征与规则库条目做映射。比如模型因“夜间活跃占比高”和“互动用户重合度大”给出高分就把这两条关联到规则库的“疑似水军”条目下形成可解释的告警文案。这样运营同事复核时看到的不是黑匣子分数而是一组可核对的线索。6. 上线前最后一道检查时空泛化验证与小流量灰度模型即使离线验证通过也不代表线上能直接用。我每次上线前都会多走两步成本不高但能挡掉大部分雷。第一步是时间泛化验证拿上个月采集的数据做训练集用这个月新采集的数据做验证集确保训练和验证之间没有时间重叠。如果两个月的效果差异超过15%说明特征或者样本存在明显的时间偏移直接上线风险很大。第二步是空间泛化验证把数据按用户来源分成两组比如按注册地区或者客户端类型切分交叉验证模型在不同群体上的表现。这一步在微博恶意用户识别里很有必要因为不同渠道注册的账号行为差异极大只在一个群体上表现好不算真本事。小流量灰度不能只看整体准确率要分人群看收益。我习惯把预测结果按“高概率恶意”和“中概率疑似”分成两档高概率的直接进处置队列中概率的先进人工审核池。灰度期观察两个指标高概率档的复核准确率是不是达到95%以上中概率档里误伤正常用户的比例是不是低于1%。这两个口径都通过才逐步扩大流量。如果发现某个特定人群比如新注册用户的误伤比例偏高不要直接调阈值要先回看特征工程是不是遗漏了该人群的区分特征。整个项目走完最大的体会是恶意用户识别的难点不在模型结构而在数据质量和评测口径。模型换一换F1可能涨两三个点特征穿越和标签噪声一旦出现掉的可就是十几个点。希望这份踩坑记录能帮你少走一段弯路。本文还有配套的精品资源点击获取
微博恶意用户识别系统：特征工程与模型落地的完整实践
简介这是基于机器学习实现微博恶意用户识别的高分项目完整资源包覆盖数据采集、特征工程、模型训练到系统展示全流程面向人工智能、通信、自动化、电子信息、物联网等计算机相关专业的学生和教师可快速用于毕业设计、课程设计或创新项目立项。压缩包共包含56个文件整体约8.8MB其中13个Python脚本负责爬虫采集、用户关系分析、新用户识别与Web接口20个npy文件保存了处理好的特征与模型数据6个dat文件为样本语料另有SQL数据库脚本、HTML页面、YAML配置、Markdown文档和Shell部署脚本完整支撑从数据库搭建到前端演示的每个环节。目前已有65人学习下载。除了可直接运行的代码外资源还附带微博爬虫脚本、Flask演示站点、项目授权码、README说明以及关键Cookie配置能帮助读者理解恶意用户识别中数据获取、样本标注、特征构建和模型评估的完整思路由于项目已通过高分评审代码规范和注释质量也有参考价值适合有一定Python基础并希望快速搭建同类系统的开发者。1. 微博恶意用户识别系统到底在解决什么问题先看三类让运营头疼的账号做机器学习项目最怕的不是模型效果差而是业务方把“恶意用户”四个字当成一个黑匣子。微博场景里的恶意用户拆开看至少有三类批量注册的营销号、抱团刷转评赞的水军、专门引战和传播虚假信息的反串账号。这三类账号在行为模式上差异很大放在同一个模型里训经常会出现“照顾了营销号、漏掉水军”的尴尬局面。这篇笔记要讲的就是怎么把这套识别系统从数据标注、特征工程、模型训练到上线评估完整落地适合正在做内容安全、风控方向或者拿社交媒体数据练手的从业者参考。你不需要有深度学习基础机器学习里的常规分类算法就够用关键是特征口径和采样方式别踩坑。2. 从业务定义到训练数据判别口径、标注方案与样本配比2.1 恶意用户的判别口径先把“什么是坏人”写成可标注的规则项目里最容易翻车的地方是把“恶意”这种主观词直接丢给标注员。标注员理解的恶意和产品经理理解的恶意往往不是一回事最后产出的标签噪声会让模型学出一堆莫名其妙的规律。我习惯的做法是先把恶意用户拆成三层判别口径行为层短时间内高频发布、批量转发、大量不相关用户、频繁修改昵称。内容层文本里包含推广关键词、诈骗话术、引战用语或者图片二维码。关系层关注列表中僵尸号占比高、互动用户集中在同一批账号、被其他用户多次举报。每一层都要写成“可勾选”的清单例如“1小时内发布超过20条原创微博”算高频发布“被举报次数超过5次”算异常互动。只有把这些标准提前固化下来标注员才能稳定执行。你可能会问规则定得这么细是不是直接用规则就行不是的。规则的覆盖面和组合能力远不如模型规则的价值在于给模型提供高质量的训练标签。2.2 公开微博数据采集用受限但合规的方式拿到训练样本拿到训练数据是这个项目的第一个硬门槛。微博开放平台提供的API权限现在收得很紧常规做法是维护一批自己可控的账号登录后采集公开页面的数据。这里必须强调只采集公开信息、控制请求频率、不碰私信和隐私数据这是底线。下面是一段简化版的采集脚本思路是从搜索结果页或者用户主页拿到公开微博数据import requests import time import pandas as pd # 模拟浏览器UA不带伪造参数只做最基本的标识 HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://weibo.com/ } def fetch_user_timeline(user_id, cookie, max_page5): 采集指定用户的公开微博列表。 user_id: 用户ID cookie: 自己账号登录后的cookie注意不要泄露 max_page: 最大翻页数 all_statuses [] for page in range(1, max_page 1): url https://weibo.com/ajax/statuses/mymblog params { uid: user_id, page: page, feature: 0 } try: resp requests.get(url, headersHEADERS, paramsparams, cookies{Cookie: cookie}, timeout10) data resp.json() for item in data.get(data, {}).get(list, []): all_statuses.append({ user_id: user_id, created_at: item.get(created_at), text: item.get(text_raw, ), reposts_count: item.get(reposts_count, 0), comments_count: item.get(comments_count, 0), attitudes_count: item.get(attitudes_count, 0) }) except Exception as e: print(fpage {page} error: {e}) time.sleep(2) # 低频访问避免给平台造成压力 return pd.DataFrame(all_statuses)这段逻辑本身不复杂但有几个参数值得注意。max_page控制采集深度恶意账号通常在5页以内就能看到明显的批量转发痕迹超过5页边际收益很低。time.sleep(2)是必写的如果去掉连续请求会在几分钟内触发平台的风控限制导致后面的账号全部失效。cookie建议单独写在配置文件里不要硬编码到代码中。采集到的数据要存成统一格式的DataFrame字段里必须保留created_at时间戳。后面做特征工程时时间戳是判断“批量行为”的关键一旦丢失就得重新采集这是没有后悔药吃的。2.3 类别不平衡下的样本配比欠采样比过采样更稳微博里恶意账号的比例通常只有百分之几如果直接拿全量数据训练模型会学成“全部预测为正常用户”准确率照样很高却毫无用处。处理不平衡我常用的方案是两层。第一层是欠采样从正常用户里随机抽出一部分把正负比控制在1比5到1比10之间。第二层是给少数类适当加权在损失函数里把恶意样本的惩罚系数调高。为什么不用SMOTE这类过采样因为微博用户特征是高维稀疏的SMOTE生成的是特征空间里的插值样本这些插值很可能落在真实数据不存在的区域模型上线后遇到真实恶意账号反而会误判。欠采样还有一个隐性问题随机抽样的正常用户可能“不干净”。有些账号表面上正常但偶尔也发广告。我的处理办法是先用规则筛掉这部分“灰色样本”只保留没有触发任何恶意规则的账号进入负样本池。这样模型学到的是“干净正常用户”和“明确恶意用户”之间的分界虽然有些理想化但在工程上比带噪训练更可控。3. 特征工程决定模型上限把用户行为翻译成特征矩阵3.1 四类特征属性、内容、行为、社交一个都不能少机器学习项目里经常听到一句话特征决定上限模型只是逼近这个上限。微博恶意用户识别系统里特征工程的空间比模型调参大得多。我常用的特征体系分四块属性特征账号注册时长、昵称长度、是否包含数字、头像是否默认、个人简介长度。批量注册的营销号通常昵称是随机字符串头像默认简介为空白。内容特征微博文本的重复度、含链接比例、含二维码图片比例、高频词集中度。水军账号发帖文本经常是一个模板批量替换关键词。行为特征单位时间内的发博频率、转发比例、评论比例、活跃时段分布。正常用户一天发2到3条水军可能一小时发20条而且集中在凌晨。社交特征粉丝数与关注数比值、互粉比例、互动用户重合度、被举报次数。恶意账号的粉丝数往往异常高但互动质量很差。这四类特征不是并列关系行为特征和内容特征对营销号和水军的区分度最高属性特征和社交特征则更擅长识别僵尸粉和反串账号。完整项目里大概会构造50到80维特征但新手不必一上来就堆特征先把每类里的核心特征算清楚再逐步扩展。3.2 特征计算落地24维特征矩阵的完整代码下面是一段计算用户级特征的核心代码涵盖了属性、内容、行为三类特征社交特征需要额外拉取关注列表数据import numpy as np import pandas as pd from datetime import datetime def build_user_features(df_status, user_profile): df_status: 该用户的历史微博数据包含created_at, text, reposts_count等 user_profile: 用户属性截图包含注册时间、粉丝数、关注数、简介等 返回一个包含24维特征的字典 features {} # 属性特征 reg_days (datetime.now() - datetime.strptime(user_profile[reg_time], %Y-%m-%d)).days features[reg_days] reg_days features[nickname_len] len(user_profile[nickname]) features[nickname_has_digit] int(any(ch.isdigit() for ch in user_profile[nickname])) features[is_default_avatar] int(user_profile[avatar] default) features[profile_len] len(user_profile[description]) # 内容特征 text_count len(df_status) features[text_count] text_count # 重复度去除完全相同的文本后的比例 unique_ratio df_status[text].nunique() / max(text_count, 1) features[unique_ratio] unique_ratio # 链接比例 link_ratio df_status[text].str.contains(http).mean() features[link_ratio] link_ratio # 平均原创度转发微博的比例 repost_ratio df_status[text].str.startswith(转发微博).mean() features[repost_ratio] repost_ratio # 行为特征 if text_count 0: time_list pd.to_datetime(df_status[created_at]) # 单位时间发博频率按天聚合 daily_count time_list.dt.date.value_counts() features[max_daily_count] daily_count.max() features[avg_daily_count] daily_count.mean() # 夜间(0-6点)活跃占比 night_ratio time_list.dt.hour.isin([0,1,2,3,4,5]).mean() features[night_ratio] night_ratio # 转发/评论/赞的均值 features[avg_reposts] df_status[reposts_count].mean() features[avg_comments] df_status[comments_count].mean() features[avg_attitudes] df_status[attitudes_count].mean() # 互动率被互动数 / 发博数 total_interact (df_status[reposts_count] df_status[comments_count] df_status[attitudes_count]).sum() features[interact_per_status] total_interact / text_count else: features[max_daily_count] 0 features[avg_daily_count] 0 features[night_ratio] 0 features[avg_reposts] 0 features[avg_comments] 0 features[avg_attitudes] 0 features[interact_per_status] 0 # 社交特征部分字段从profile补充 fans max(user_profile[followers_count], 1) follow max(user_profile[following_count], 1) features[fans_follow_ratio] fans / follow features[fans_per_reg_day] fans / max(reg_days, 1) # 补齐到24维加上账号是否认证、是否会员等标记 features[is_verified] int(user_profile[verified]) features[is_vip] int(user_profile[vip]) features[gender_unknown] int(user_profile[gender] 未知) features[city_level] user_profile.get(city_level, 0) return features这段代码里有几个容易忽略的细节。unique_ratio计算的是去重后的文本数与总文本数的比值恶意账号这个值通常非常低因为大量转发内容都是重复的。interact_per_status是平均每条微博获得的互动量水军账号互动主要来自同伙数量和正常账号有明显差异。fans_follow_ratio对识别互粉群很重要正常用户这个值在1左右机器养的粉头账号可能高达几十。注意repost_ratio用startswith(转发微博)判断并不完美因为微博的转发文本格式历史上改过多次。更稳妥的做法是判断text里是否包含“转发”字样或者原文链接结构但这会引入噪声。工程上你只需要保证训练集和线上预测时用的判断逻辑保持一致相对大小就有意义绝对准确性反而不是首要考虑。3.3 特征筛选相关性分析与稳定性检验特征算完之后不要一股脑丢给模型。我先做三件事第一计算特征间的皮尔逊相关系数把相关系数超过0.9的特征对挑出来只保留其中一个。比如fans_per_reg_day和reg_days高度相关两个都用会让模型重复学习同一信息还增加过拟合风险。第二看每个特征的分布是否在训练集和验证集上有明显偏移。比如“平均每条微博互动量”这个特征如果训练数据是某个时间段采集的而验证数据来自另一个时间段分布可能差异很大。简单画一下分位数对比就能发现。第三用RandomForest跑一次特征重要性把重要性为0的特征剔除。常见做法是保留前30维左右的特征再进入训练环节。from sklearn.ensemble import RandomForestClassifier def select_features(X_train, y_train, feature_names, top_k30): 用随机森林粗筛特征返回保留的特征名列表 model RandomForestClassifier(n_estimators200, random_state42, n_jobs-1) model.fit(X_train, y_train) importance pd.Series(model.feature_importances_, indexfeature_names) importance importance.sort_values(ascendingFalse) return importance.head(top_k).index.tolist()n_estimators设成200random_state固定保证结果可复现。特征筛选用的随机森林不需要调参它的作用只是给特征重要性排序不是最终分类器。这一步做完特征维度从五六十降到二三十训练速度和模型稳定性都会明显提升。4. 模型选型与训练从逻辑回归到集成学习的完整流程4.1 基线模型选逻辑回归上线快、好解释、能兜底第一次做这个系统千万别直接上XGBoost。先用逻辑回归跑通全链路理由有三个一是逻辑回归对特征尺度不敏感特征工程做完后可以直接丢进去二是它的输出是概率方便后面调阈值三是出了问题好排查。逻辑回归的L2正则系数C需要调默认值1.0在特征维度不高时通常够用。训练前对数值型特征做标准化避免量纲差异影响收敛。from sklearn.linear_model import LogisticRegression from sklearn.preprocessing import StandardScaler from sklearn.pipeline import Pipeline def train_baseline(X_train, y_train): 训练逻辑回归基线模型输出模型和标准化器 pipeline Pipeline([ (scaler, StandardScaler()), (lr, LogisticRegression(C1.0, class_weightbalanced, solverliblinear, random_state42)) ]) pipeline.fit(X_train, y_train) return pipelineclass_weightbalanced让少数类自动加权相当于2.3节提到的损失函数加权。solver选liblinear它适合中小规模数据和二分类问题收敛稳定。如果数据集超过10万条换成saga会更快。逻辑回归训练完我习惯先把系数打印出来看一遍。某些特征的系数符号和业务直觉相反多半是数据有泄漏或者特征构造错误趁早修正不要等到后面模型上线了才发现。4.2 集成模型闪亮登场随机森林与XGBoost的调参重点逻辑回归跑通之后再上集成模型。实践中随机森林和XGBoost在这个任务上的表现通常会明显超过逻辑回归原因仍然是特征里有大量非线性关系。比如unique_ratio低和night_ratio高同时出现才是恶意特征单看任何一个都不够。随机森林重点调三个参数n_estimators300到500之间足够再大收益很小且训练变慢。max_depth限制在10到20防止对训练集中的噪声拟合过深。min_samples_leaf设为50左右恶意用户识别场景里叶子节点太小会导致线上误判率升高。XGBoost的调参可以套用一套相对固定的组合import xgboost as xgb def train_xgb(X_train, y_train, X_val, y_val): 训练XGBoost模型用早停防止过拟合 dtrain xgb.DMatrix(X_train, labely_train) dval xgb.DMatrix(X_val, labely_val) params { objective: binary:logistic, eval_metric: auc, eta: 0.05, max_depth: 6, min_child_weight: 5, subsample: 0.8, colsample_bytree: 0.8, scale_pos_weight: 5, # 正负样本比例失衡时的加权 random_state: 42 } model xgb.train( params, dtrain, num_boost_round1000, evals[(dval, val)], early_stopping_rounds50, verbose_eval50 ) return modeleta设0.05是让每棵树学得慢一点留出早停空间。scale_pos_weight的经验值是负样本数除以正样本数我这里是按5倍的失衡比例设置的实际项目中量一下训练集的真实比例再填。early_stopping_rounds50意味着验证集AUC连续50轮不提升就停这比固定迭代次数省心得多。XGBoost训练完还有一个额外动作把特征重要性导出来对比一下随机森林的结果。两个模型给出的Top特征如果高度一致说明特征工程做扎实了如果差异很大需要检查是否存在特征泄漏或者特定特征被某个模型过度利用。4.3 模型融合与阈值调整F1优先还是召回优先实际使用中单独一个模型总会有漏网之鱼。常见做法是把逻辑回归、随机森林、XGBoost三个模型的预测概率做加权平均权重通过验证集上的网格搜索确定。我习惯给XGBoost权重0.5随机森林0.3逻辑回归0.2因为XGBoost在这个任务上的整体表现通常最好。但比融合更关键的是阈值调整。默认0.5的阈值对恶意用户识别不一定合适。这里取决于业务目标如果人力审核资源充足希望多抓、冤枉了也没关系那就把阈值调低到0.3提高召回率如果误删正常账号会影响用户体验那就把阈值调到0.7优先保证精度。from sklearn.metrics import precision_recall_curve def find_best_threshold(y_true, y_prob): 遍历阈值找到F1最高的概率截断点 precision, recall, thresholds precision_recall_curve(y_true, y_prob) f1_scores 2 * precision * recall / (precision recall 1e-6) best_idx f1_scores.argmax() best_threshold thresholds[best_idx] print(fbest threshold: {best_threshold:.3f}, f1: {f1_scores[best_idx]:.3f}) return best_threshold这段代码的核心是precision_recall_curve它返回在不同阈值下的精确率和召回率。恶意用户识别看PR曲线比看ROC曲线更合适因为正样本占比太低ROC曲线会给人“模型很好”的错觉PR曲线才对少数类的表现更敏感。阈值定下来后我还会额外检查一下“高概率正常用户”中是否混有恶意账号。方法是对预测概率在0.1以下的样本做人工抽样复核如果抽样结果里发现恶意账号占比超过预期说明特征或者训练数据里还有问题不要急着上线。5. 恶意用户识别系统避坑三个月踩过的五个真实大坑5.1 特征穿越用“未来信息”预测过去线上直接翻车现象离线验证时AUC高达0.98一上小流量灰度误报率暴涨。原因特征计算时混入了用户“被识别后”的数据。比如用is_verified是否被平台认证这个特征判断历史恶意行为但恶意账号往往是先被封禁、后来才被认证或者被清粉特征里包含了未来信息。更隐蔽的是用户的历史微博互动量是从采集时刻的快照里算出来的采集时刻离行为发生时刻可能已经过了几个月。解决时间对齐。训练样本只使用“在预测时间点之前已产生”的数据上线时也要保证线上特征的计算窗口与训练时一致。最稳妥的做法是把特征计算函数封装成同一个接口训练和预测共用一套代码。5.2 采集数据分布漂移模型上线三个月后效果下滑现象模型上线初期效果好后来每天抓到的新恶意账号越来越少误报却越来越多。原因微博的平台策略和用户行为都随时间变化。早期恶意账号的特征明显批量转发、链接轰炸模型容易学后来恶意账号开始模拟正常用户发帖频率降低互动变自然旧模型的判定标准失效了。解决建立周期性重训机制。我的习惯是每周跑一次数据分布对比监控核心特征的均值和分位数变化。当超过20%的核心特征出现显著偏移时就要补充新样本重训。实际操作中最好每月固定重训一次中间穿插新特征实验。5.3 标签噪声标注员的“顺手举报”把模型带进沟里现象模型预测的恶意用户里有一批账号反复被系统误杀查来查去发现训练集里它们的标签被标错了。原因初版标注标准执行不到位。有些标注员看到账号发广告就标为恶意但没注意到这个账号是正常用户偶尔转发了广告内容还有一些标注员在拿不准时倾向于“宁可错杀”大量灰色样本被标成正样本。解决给标注任务加校验环节。每个样本至少两人的标注结果一致才采用不一致的进入仲裁。成本会上升但训练数据的质量决定模型上限这笔投入不能省。另外训练时要把标注置信度低的样本过滤掉或者折价计算它们的损失贡献。5.4 评测方式错误随机切分验证集低估了“跨用户泛化”难度现象验证集上F1达到0.85线下测试满意到了线上效果只有0.6。原因随机切分验证集时同一个用户的样本可能同时出现在训练集和验证集里。模型记住了这个用户的特征验证时碰上“见过”的用户效果虚高。真实场景里系统面对的是完全没见过的账号。解决按用户切分。把所有训练样本按用户ID分组确保同一个用户的所有样本只出现在训练集或只出现在验证集中。这是风控类项目最基本的数据划分纪律踩过这一次之后我再也不做随机切分了。5.5 规则与模型打架模型概率高但规则库不联动运营不信任模型现象模型判定某个账号恶意概率0.9但规则库的命中条数只有一条。运营同事来质问为什么这个账号要封。原因规则库和模型是两套独立系统没有形成互相补充的关系。规则库擅长处理确定性场景模型擅长处理复杂场景中间有大量灰色地带没人解释。解决上线模型时输出判别理由把命中的核心特征与规则库条目做映射。比如模型因“夜间活跃占比高”和“互动用户重合度大”给出高分就把这两条关联到规则库的“疑似水军”条目下形成可解释的告警文案。这样运营同事复核时看到的不是黑匣子分数而是一组可核对的线索。6. 上线前最后一道检查时空泛化验证与小流量灰度模型即使离线验证通过也不代表线上能直接用。我每次上线前都会多走两步成本不高但能挡掉大部分雷。第一步是时间泛化验证拿上个月采集的数据做训练集用这个月新采集的数据做验证集确保训练和验证之间没有时间重叠。如果两个月的效果差异超过15%说明特征或者样本存在明显的时间偏移直接上线风险很大。第二步是空间泛化验证把数据按用户来源分成两组比如按注册地区或者客户端类型切分交叉验证模型在不同群体上的表现。这一步在微博恶意用户识别里很有必要因为不同渠道注册的账号行为差异极大只在一个群体上表现好不算真本事。小流量灰度不能只看整体准确率要分人群看收益。我习惯把预测结果按“高概率恶意”和“中概率疑似”分成两档高概率的直接进处置队列中概率的先进人工审核池。灰度期观察两个指标高概率档的复核准确率是不是达到95%以上中概率档里误伤正常用户的比例是不是低于1%。这两个口径都通过才逐步扩大流量。如果发现某个特定人群比如新注册用户的误伤比例偏高不要直接调阈值要先回看特征工程是不是遗漏了该人群的区分特征。整个项目走完最大的体会是恶意用户识别的难点不在模型结构而在数据质量和评测口径。模型换一换F1可能涨两三个点特征穿越和标签噪声一旦出现掉的可就是十几个点。希望这份踩坑记录能帮你少走一段弯路。本文还有配套的精品资源点击获取
