最近我帮一个做城市短租运营的朋友整理了一套日常数据流程从房源定价、户型图归档到租客群体分层全部用 Python 做机器学习来落地。这个事做完之后我最大的感受是日常项目里真正难的不是算法而是搞清楚哪些环节值得上模型、上了之后怎么跟业务对口径。这篇文章我会沿着这趟实际项目梳理一遍完整思路包括选型判断、特征工程、模型训练、结果评估和踩过的坑希望能给正在琢磨Python 机器学习到底能用在哪儿的你一些直接可抄的参考。1 先筛一遍哪些日常环节值得做机器学习哪些别碰1.1 从三个真实业务痛点里选场景一开始朋友给我列了一堆需求什么预测下礼拜哪个区域看房的人多自动识别虚假房源照片给新上架的房源定个合理租金把租客分成几类做运营。这些东西听起来都能上 AI但真要全部铺开做时间和数据都不允许。我当时的判断标准很简单高频、重复、人工做又费时而且现有数据里能挖出规律这样的场景才值得先动。最后筛出三个租金预测内部定价专员每天要手动看几十条房源信息结合周边均价和房型特征给建议价工作量大且标准不统一。户型图归档运营上传房源时经常把一居、两居、三居的户型图传错人工审核效率低。租客群体分层运营想做精细化活动但一直没有客观分群依据都是靠经验拍脑袋。如果你也在评估自己的项目可以用这个表快速过一遍判断维度租金预测户型图归档租客分层是否高频重复高高中人工成本是否够大大大中是否有历史数据有挂牌与成交数据有图库和标签有订单和浏览记录规则是否容易穷举不容易不容易不容易投入产出比高高中1.2 算法选型为什么是少即是多很多人一上来就想着上深度学习、上大模型但日常业务项目里数据量就那么几万条算力也有限模型越复杂反而越难维护。我的原则是能用经典机器学习解决的绝不上深度模型能用一个模型跑通的绝不拆成三个微服务。这个项目里我最终选的是租金预测LightGBM 和线性回归做对比选表现更好的那套。户型图归档用预训练图像分类模型做迁移学习而不是从零训练一个卷积网络。租客分层KMeans 聚类先给运营一个可解释的轮廓。这套选型逻辑其实是够用就好。日常业务的 KPI 不是榜单上的精度而是能不能稳定跑、能不能解释、出问题能不能快速修。1.3 本次项目的整体架构与数据概况数据是朋友从平台后台导出的模拟项目 X覆盖了大约 3 万条历史挂牌房源记录以及 1.2 万张户型图、2 万多条租客订单行为数据。数据质量不算差但还是有明显脏数据问题比如部分房源的面积字段为空、户型图标签错位、租客城市字段大小写不统一。整体流程分三层第一层是数据清洗与特征工程第二层是模型训练与评估第三层是结果导出和业务反馈。每一层我都会在接下来的小节里拆开讲。2 租金预测回归任务里特征工程才是主战场2.1 拿到数据先看半个小时别急着建模我真的建议所有做日常项目的人拿到数据之后先忍住建模的冲动花半个小时做探索性分析。这一步看起来慢实则最快。我当时打开租金数据后第一件事是看缺失值分布。3 万条记录里面积字段缺了大概 1500 条楼层字段有 600 多条写成低层/中层/高层的文字还有一部分房源朝向是空值。这都不算致命但你如果直接把这些字段扔给模型很多库会在内部把缺失值当成一个特殊值处理结果解释起来非常别扭。我的处理方案很简单面积缺失用同小区同户型的中位数填充。注意是中位数而不是平均数因为面积分布有长尾个别超大户型会把均值拉高。朝向空值单独标记为未知不强行猜避免造出错误信息。楼层文字映射低层 1~4 楼映射为 0中层 5~15 映射为 1高层 16 以上映射为 2做成有序类别。另外我还删掉了那些明显偏离常识的数据比如面积小于 10 平米的整租房源、租金低于 200 元的记录。这类数据要么是测试单要么是录入错误留着只会污染模型。2.2 把原始字段拆解成可用特征经验告诉我回归模型的效果很大程度取决于你怎么把原始字段变成特征。租金预测里最有效的几个特征包括每平米租金不是直接预测总价而是把总价除以面积得到一个相对稳定的目标变量。距离市中心距离用经纬度算球面距离这个特征通常比所在区更有解释力。房龄很多挂牌信息里有建筑年代可以直接算出房龄。便利设施数量把是否有电梯是否有暖气是否有车位这类布尔字段加和得到一个 0~5 的整数特征。这里有个很重要的点不要把所有原始字段一股脑堆给模型尤其是 ID、地址描述这类高基数文本数字化之后反而会引入噪声。我当时用 Python 做了这样的特征处理以面积和户型字段为例import pandas as pd import numpy as np df pd.read_csv(rent_records.csv) df[price_per_sqm] df[total_rent] / df[area] df[age] 2025 - df[building_year] # 简单但有效的区位特征到市中心的球面距离 def haversine(lat1, lon1, lat2, lon2): R 6371.0 phi1, phi2 np.radians(lat1), np.radians(lat2) dphi np.radians(lat2 - lat1) dlambda np.radians(lon2 - lon1) a np.sin(dphi/2)**2 np.cos(phi1)*np.cos(phi2)*np.sin(dlambda/2)**2 return 2 * R * np.arcsin(np.sqrt(a)) center_lat, center_lon 30.57, 104.06 # 模拟项目所在城市中心 df[center_distance_km] df.apply( lambda row: haversine(row[lat], row[lon], center_lat, center_lon), axis1 )我故意没有用复杂的编码技巧像 one-hot 编码小区名这种操作在这个项目里没有必要。因为小区数量上千one-hot 会让特征矩阵变得稀疏又难解释LightGBM 这类树模型本身就能处理这种类别字段。2.3 线性回归与梯度提升树对比特征准备完之后我同时跑了两个模型一个线性回归作为基线一个 LightGBM 做主力。对比的结果很有意思模型MAE元/平米R²训练时长线性回归15.20.713 秒LightGBM11.80.8345 秒从绝对数字看LightGBM 更好但这个好有没有代价有的。线性回归你还能直接说距市中心每远一公里每平米租金大约降两块钱LightGBM 解释起来就费劲一些。实际落地时我做了折中把两个模型的结果都保留线性回归用来做常规区间的快速预测LightGBM 用来做高价位房源的精细预测。虽然在技术上略冗余但业务上很好用。训练代码本身不复杂关键是你得做验证集而不是直接拿全部数据训练from sklearn.model_selection import train_test_split from sklearn.linear_model import LinearRegression from sklearn.metrics import mean_absolute_error import lightgbm as lgb feature_cols [area, age, center_distance_km, rooms, floor_level, facilities_count] X df[feature_cols] y df[price_per_sqm] X_train, X_test, y_train, y_test train_test_split(X, y, test_size0.2, random_state42) lr LinearRegression() lr.fit(X_train, y_train) lr_pred lr.predict(X_test) lgb_model lgb.LGBMRegressor(n_estimators300, learning_rate0.05, max_depth6) lgb_model.fit(X_train, y_train, eval_set[(X_test, y_test)]) lgb_pred lgb_model.predict(X_test) print(LinearRegression MAE:, mean_absolute_error(y_test, lr_pred)) print(LightGBM MAE:, mean_absolute_error(y_test, lgb_pred))关于 LightGBM 的超参我没有做大规模网格搜索只是把树的数量、学习率和最大深度先固定加上早停。2.4 误差指标怎么定业务侧才认一周后朋友问我你这个模型到底准不准我意识到一个问题技术上讲 MAE 是 11.8 元/平米但业务侧听不懂。我后来改用业务口径汇报预测值落在实际成交价正负 10% 范围内的比例是 71%。这个指标对定价专员非常友好因为他们关心的不是数学误差而是你猜的这个数我能不能直接用来挂牌。另外我还做了一张残差分布图发现误差在低租金房源上非常小但在月租超过 1.5 万的房源上会明显偏保守。原因是这类房源样本太少而且价格受装修风格、家具配置等难以量化的因素影响很大。这个发现直接推翻了朋友原来的想法——他以为高价房源应该加价预测实际上模型在这些样本上已经不稳定应该单独标注需要人工复核而不是盲目调整。3 户型图自动归档图像分类用预训练模型微调就够了3.1 任务拆解一居、两居、三居识别户型图归档这个需求刚开始朋友以为很复杂说要识别出客厅、卧室、厨房分别在哪。我听完先拦了一下业务上的真实需求只是把一居、两居、三居图片归到对应类目我们根本不需要做细粒度的语义分割。这个拆解很关键。需求越具体模型越简单项目越容易上线。最后任务被定义成三分类一居室、两居室、三居室。图片是用户上传的户型平面图风格不统一但整体上信息是清晰的。3.2 迁移学习的具体做法我用了 PyTorch 生态里常用的预训练模型来做迁移学习。思路是加载在 ImageNet 上训练好的 ResNet18把最后一层全连接输出改成 3 类冻结前面的卷积层只训练新加的分类头和最后一两个残差块。为什么要冻结大部分层因为户型图虽然和 ImageNet 里的自然图像差异大但基础纹理、边缘、形状特征在底层是通用的。冻结底层可以让训练更稳定参数量也更小在小数据集上不容易过拟合。核心代码大致长这样import torch import torch.nn as nn from torchvision import models, transforms model models.resnet18(weightsmodels.ResNet18_Weights.IMAGENET1K_V1) num_features model.fc.in_features model.fc nn.Linear(num_features, 3) # 冻结前几层只训练最后的部分 for name, param in model.named_parameters(): if name not in [fc.weight, fc.bias, layer4.1.weight, layer4.1.bias]: param.requires_grad False训练时数据预处理和普通分类任务没有本质区别我主要做了 resize 到 224x224、随机水平翻转、颜色抖动。优化器用的是 Adam学习率设成 1e-4批量大小 32大概 15 个 epoch 后验证集准确率稳定在 92% 上下。3.3 数据增强与小样本问题户型图的类别分布不太均匀一居室样本最多三居室样本明显偏少。我担心模型在三居室上会欠拟合所以做了两件事。第一是有针对性的数据增强。对三居室图片做了更多的随机裁剪和旋转相当于在视觉上制造出更多样本。第二是在损失函数里给少数类加权重让模型在训练时更关注三居室的错分代价。这两步效果立竿见影三居室类别 Recall 从 78% 提升到 89%。这里分享一个更通用的经验日常图像分类项目里数据增强不要盲目追求复杂。户型图是线性结构为主的图旋转 90 度、镜像翻转都有现实意义但你如果加高斯噪声或者随机擦除反而会破坏结构信息让模型学到错误特征。增强手段一定要和业务场景匹配。3.4 跑通之后的性能与部署模型训练完之后打包成一个接口服务输入图片返回类别和置信度。在实际运行中有一个问题要提前想好置信度低的图片怎么办。我的策略是分两条路置信度大于 0.8 的自动归档置信度低于 0.8 的进入人工审核队列。这个阈值是跟运营一起调的他们觉得 0.8 差不多误判率可接受。模型在真实线上数据里准确率大约 90%比人工审核快了很多倍而且人工只需要处理三成不到的争议图片。4 租客群体分层无监督聚类如何给运营产出决策4.1 为什么不直接拍脑袋分三档租客分层这个需求运营一开始想要的其实是高价值、中价值、低价值三档里面还参考了活跃不活跃这种主观判断。我直接建议别这么干原因很简单拍出来的档位经不起推敲回头业务复盘时会问凭什么他是高价值。机器学习在这里的价值不是替代运营思考而是提供一个客观、可复现的分群依据。运营可以基于分群结果重新定义自己的运营策略而不是靠感觉。4.2 特征标准化和维度选择的细节做租客聚类我挑了一组特征近 30 天下单次数、近 30 天浏览房源数、近 90 天消费金额、平均单笔订单金额、在平台停留天数。这里面不同特征的量纲差异非常大消费金额可能是上千浏览数可能只有几十如果直接丢进 KMeans欧氏距离会被消费金额主导。所以聚类前必须做标准化我用的方法是 Z-score 标准化让每个特征的均值为 0、标准差为 1。这一步是很多人最容易忽略的但也是最关键的一步。还有一点要提醒特征不要选太多。我开始还加了城市、注册来源等特征结果聚类轮廓系数反而下降了。原因是这些类别型特征和消费行为的相关性不强加入后稀释了主要信号。最后只保留五个数值特征聚类结果反而更干净。4.3 聚类结果验证与业务翻译KMeans 最麻烦的问题是 K 怎么定。我用肘部法则同时也看了轮廓系数K 值轮廓系数业务解释20.38过于粗只分成活跃和不活跃30.44比较清晰但其中一类区分度不够40.41分得过细难以运营最终选了 K3。我给这三类起了业务名高频浏览但低消费的观望型租客、消费金额大但频次低的长住型租客、浏览和消费都中等偏上的稳定型租客。这样运营一看就知道该做什么动作观望型适合推送短租优惠券长住型适合推送月租折扣。这里有个非常容易犯的错不要只看聚类结果还要用业务知识去验证每一类的合理性。如果分出来某一类里既有消费 100 元的也有消费 10000 元的那这个聚类基本是失败的可能因为标准化或特征选择出了问题。4.4 冷启动和新数据回滚问题聚类模型上线后有个天然问题用户行为特征每天都会变KMeans 中心要不要每天重新算我实际操作时用的是离线重训练 定期发布的模式每天凌晨用过去 90 天的数据重新训练一次模型然后保存簇中心。线上预测时只需要把当天用户特征标准化后计算离哪个簇中心最近。这个做法的好处是简单稳定坏处是用户行为突变时模型不能立刻反应。比如平台搞一次大促后很多平时不活跃的用户突然大量下单但模型的簇中心可能还是旧的导致这些用户被分到观望型。我后来加了规则兜底当天消费金额超过某个阈值的用户直接临时打大促敏感型标签不参与模型分群。这听起来不太优雅但业务上非常实用。5 全链路踩坑记录这些坑比算法本身更值得写5.1 特征泄漏最隐蔽的错误租金预测第一版模型效果奇好LightGBM 的 MAE 一度低到 6.2 元/平米我当时就觉得不对劲。后来排查发现特征列表里混进了一个挂牌时长字段——这个字段是房子挂出去之后慢慢累积的预测时根本不知道未来值。这就是典型的特征泄漏模型偷看了未来信息。你在训练集上它表现神勇一上新数据就崩。排查办法是列出特征清单逐个问业务方这个字段在预测时刻能不能拿到、是不是已知的。数据科学家一定要学会对这些字段保持警惕尤其在业务方导数据的时候他们常常把最终结果也当成普通字段导出来。5.2 训练和预测口径不一致户型图分类模型在测试集上准确率 92%上线后大概一周准确率掉到 86%。排查了很久发现原因是线上接口收到的图片和训练时的预处理不一致。训练时我用的是标准 224x224 的 RGB 图片但线上有一部分运营上传的是带水印的 PNG 图透明通道撑大了体积压缩处理时颜色值发生了变化。这个问题靠模型本身无法解决只能在接口层统一入口图片入库前先统一格式、统一大小、统一颜色空间。训练和预测的口径不一致是所有模型上线后性能下跌的头号原因。5.3 先跑基线再谈优化这个小节想说的其实不是技术而是心态。日常项目里如果一个简单模型已经能满足业务需要完全没必要为了上价值去换复杂模型。租金预测里线性回归已经能解释 70% 的变化只靠它就能把定价专员的效率提一倍后来我加 LightGBM 是为了把 70% 推到 83%但你要知道后面这 13% 的代价是更高的解释成本和维护成本。这个权衡要提前做。我现在的习惯是永远先搭一个最最简单的规则或线性模型做基线把流程跑通再考虑迭代。很多项目根本走不到迭代那一步因为基线已经够用了。5.4 可解释性输出给业务方最后聊聊模型结果落到业务侧时的表达问题。我每次交付都会附上一张特征重要性图用 LightGBM 自带的 feature importance 画出来让运营知道模型主要看面积、区位和房龄。这在沟通中很有用因为业务方不是要理解原理他们只是想确认这模型没有乱来。另外我绝不会只交付一个文件或一个接口一定会附带一份一页纸说明写上模型适用范围、已知局限、建议复核的边界条件。这才是日常项目里最容易被低估的产出物。很多做机器学习的同学喜欢把精力花在调参和刷点上但真实项目的成败往往取决于能不能和业务方把口径对齐、把预期管住。
最近我帮一个做城市短租运营的朋友整理了一套日常数据流程从房源定价、户型图归档到租客群体分层全部用 Python 做机器学习来落地。这个事做完之后我最大的感受是日常项目里真正难的不是算法而是搞清楚哪些环节值得上模型、上了之后怎么跟业务对口径。这篇文章我会沿着这趟实际项目梳理一遍完整思路包括选型判断、特征工程、模型训练、结果评估和踩过的坑希望能给正在琢磨Python 机器学习到底能用在哪儿的你一些直接可抄的参考。1 先筛一遍哪些日常环节值得做机器学习哪些别碰1.1 从三个真实业务痛点里选场景一开始朋友给我列了一堆需求什么预测下礼拜哪个区域看房的人多自动识别虚假房源照片给新上架的房源定个合理租金把租客分成几类做运营。这些东西听起来都能上 AI但真要全部铺开做时间和数据都不允许。我当时的判断标准很简单高频、重复、人工做又费时而且现有数据里能挖出规律这样的场景才值得先动。最后筛出三个租金预测内部定价专员每天要手动看几十条房源信息结合周边均价和房型特征给建议价工作量大且标准不统一。户型图归档运营上传房源时经常把一居、两居、三居的户型图传错人工审核效率低。租客群体分层运营想做精细化活动但一直没有客观分群依据都是靠经验拍脑袋。如果你也在评估自己的项目可以用这个表快速过一遍判断维度租金预测户型图归档租客分层是否高频重复高高中人工成本是否够大大大中是否有历史数据有挂牌与成交数据有图库和标签有订单和浏览记录规则是否容易穷举不容易不容易不容易投入产出比高高中1.2 算法选型为什么是少即是多很多人一上来就想着上深度学习、上大模型但日常业务项目里数据量就那么几万条算力也有限模型越复杂反而越难维护。我的原则是能用经典机器学习解决的绝不上深度模型能用一个模型跑通的绝不拆成三个微服务。这个项目里我最终选的是租金预测LightGBM 和线性回归做对比选表现更好的那套。户型图归档用预训练图像分类模型做迁移学习而不是从零训练一个卷积网络。租客分层KMeans 聚类先给运营一个可解释的轮廓。这套选型逻辑其实是够用就好。日常业务的 KPI 不是榜单上的精度而是能不能稳定跑、能不能解释、出问题能不能快速修。1.3 本次项目的整体架构与数据概况数据是朋友从平台后台导出的模拟项目 X覆盖了大约 3 万条历史挂牌房源记录以及 1.2 万张户型图、2 万多条租客订单行为数据。数据质量不算差但还是有明显脏数据问题比如部分房源的面积字段为空、户型图标签错位、租客城市字段大小写不统一。整体流程分三层第一层是数据清洗与特征工程第二层是模型训练与评估第三层是结果导出和业务反馈。每一层我都会在接下来的小节里拆开讲。2 租金预测回归任务里特征工程才是主战场2.1 拿到数据先看半个小时别急着建模我真的建议所有做日常项目的人拿到数据之后先忍住建模的冲动花半个小时做探索性分析。这一步看起来慢实则最快。我当时打开租金数据后第一件事是看缺失值分布。3 万条记录里面积字段缺了大概 1500 条楼层字段有 600 多条写成低层/中层/高层的文字还有一部分房源朝向是空值。这都不算致命但你如果直接把这些字段扔给模型很多库会在内部把缺失值当成一个特殊值处理结果解释起来非常别扭。我的处理方案很简单面积缺失用同小区同户型的中位数填充。注意是中位数而不是平均数因为面积分布有长尾个别超大户型会把均值拉高。朝向空值单独标记为未知不强行猜避免造出错误信息。楼层文字映射低层 1~4 楼映射为 0中层 5~15 映射为 1高层 16 以上映射为 2做成有序类别。另外我还删掉了那些明显偏离常识的数据比如面积小于 10 平米的整租房源、租金低于 200 元的记录。这类数据要么是测试单要么是录入错误留着只会污染模型。2.2 把原始字段拆解成可用特征经验告诉我回归模型的效果很大程度取决于你怎么把原始字段变成特征。租金预测里最有效的几个特征包括每平米租金不是直接预测总价而是把总价除以面积得到一个相对稳定的目标变量。距离市中心距离用经纬度算球面距离这个特征通常比所在区更有解释力。房龄很多挂牌信息里有建筑年代可以直接算出房龄。便利设施数量把是否有电梯是否有暖气是否有车位这类布尔字段加和得到一个 0~5 的整数特征。这里有个很重要的点不要把所有原始字段一股脑堆给模型尤其是 ID、地址描述这类高基数文本数字化之后反而会引入噪声。我当时用 Python 做了这样的特征处理以面积和户型字段为例import pandas as pd import numpy as np df pd.read_csv(rent_records.csv) df[price_per_sqm] df[total_rent] / df[area] df[age] 2025 - df[building_year] # 简单但有效的区位特征到市中心的球面距离 def haversine(lat1, lon1, lat2, lon2): R 6371.0 phi1, phi2 np.radians(lat1), np.radians(lat2) dphi np.radians(lat2 - lat1) dlambda np.radians(lon2 - lon1) a np.sin(dphi/2)**2 np.cos(phi1)*np.cos(phi2)*np.sin(dlambda/2)**2 return 2 * R * np.arcsin(np.sqrt(a)) center_lat, center_lon 30.57, 104.06 # 模拟项目所在城市中心 df[center_distance_km] df.apply( lambda row: haversine(row[lat], row[lon], center_lat, center_lon), axis1 )我故意没有用复杂的编码技巧像 one-hot 编码小区名这种操作在这个项目里没有必要。因为小区数量上千one-hot 会让特征矩阵变得稀疏又难解释LightGBM 这类树模型本身就能处理这种类别字段。2.3 线性回归与梯度提升树对比特征准备完之后我同时跑了两个模型一个线性回归作为基线一个 LightGBM 做主力。对比的结果很有意思模型MAE元/平米R²训练时长线性回归15.20.713 秒LightGBM11.80.8345 秒从绝对数字看LightGBM 更好但这个好有没有代价有的。线性回归你还能直接说距市中心每远一公里每平米租金大约降两块钱LightGBM 解释起来就费劲一些。实际落地时我做了折中把两个模型的结果都保留线性回归用来做常规区间的快速预测LightGBM 用来做高价位房源的精细预测。虽然在技术上略冗余但业务上很好用。训练代码本身不复杂关键是你得做验证集而不是直接拿全部数据训练from sklearn.model_selection import train_test_split from sklearn.linear_model import LinearRegression from sklearn.metrics import mean_absolute_error import lightgbm as lgb feature_cols [area, age, center_distance_km, rooms, floor_level, facilities_count] X df[feature_cols] y df[price_per_sqm] X_train, X_test, y_train, y_test train_test_split(X, y, test_size0.2, random_state42) lr LinearRegression() lr.fit(X_train, y_train) lr_pred lr.predict(X_test) lgb_model lgb.LGBMRegressor(n_estimators300, learning_rate0.05, max_depth6) lgb_model.fit(X_train, y_train, eval_set[(X_test, y_test)]) lgb_pred lgb_model.predict(X_test) print(LinearRegression MAE:, mean_absolute_error(y_test, lr_pred)) print(LightGBM MAE:, mean_absolute_error(y_test, lgb_pred))关于 LightGBM 的超参我没有做大规模网格搜索只是把树的数量、学习率和最大深度先固定加上早停。2.4 误差指标怎么定业务侧才认一周后朋友问我你这个模型到底准不准我意识到一个问题技术上讲 MAE 是 11.8 元/平米但业务侧听不懂。我后来改用业务口径汇报预测值落在实际成交价正负 10% 范围内的比例是 71%。这个指标对定价专员非常友好因为他们关心的不是数学误差而是你猜的这个数我能不能直接用来挂牌。另外我还做了一张残差分布图发现误差在低租金房源上非常小但在月租超过 1.5 万的房源上会明显偏保守。原因是这类房源样本太少而且价格受装修风格、家具配置等难以量化的因素影响很大。这个发现直接推翻了朋友原来的想法——他以为高价房源应该加价预测实际上模型在这些样本上已经不稳定应该单独标注需要人工复核而不是盲目调整。3 户型图自动归档图像分类用预训练模型微调就够了3.1 任务拆解一居、两居、三居识别户型图归档这个需求刚开始朋友以为很复杂说要识别出客厅、卧室、厨房分别在哪。我听完先拦了一下业务上的真实需求只是把一居、两居、三居图片归到对应类目我们根本不需要做细粒度的语义分割。这个拆解很关键。需求越具体模型越简单项目越容易上线。最后任务被定义成三分类一居室、两居室、三居室。图片是用户上传的户型平面图风格不统一但整体上信息是清晰的。3.2 迁移学习的具体做法我用了 PyTorch 生态里常用的预训练模型来做迁移学习。思路是加载在 ImageNet 上训练好的 ResNet18把最后一层全连接输出改成 3 类冻结前面的卷积层只训练新加的分类头和最后一两个残差块。为什么要冻结大部分层因为户型图虽然和 ImageNet 里的自然图像差异大但基础纹理、边缘、形状特征在底层是通用的。冻结底层可以让训练更稳定参数量也更小在小数据集上不容易过拟合。核心代码大致长这样import torch import torch.nn as nn from torchvision import models, transforms model models.resnet18(weightsmodels.ResNet18_Weights.IMAGENET1K_V1) num_features model.fc.in_features model.fc nn.Linear(num_features, 3) # 冻结前几层只训练最后的部分 for name, param in model.named_parameters(): if name not in [fc.weight, fc.bias, layer4.1.weight, layer4.1.bias]: param.requires_grad False训练时数据预处理和普通分类任务没有本质区别我主要做了 resize 到 224x224、随机水平翻转、颜色抖动。优化器用的是 Adam学习率设成 1e-4批量大小 32大概 15 个 epoch 后验证集准确率稳定在 92% 上下。3.3 数据增强与小样本问题户型图的类别分布不太均匀一居室样本最多三居室样本明显偏少。我担心模型在三居室上会欠拟合所以做了两件事。第一是有针对性的数据增强。对三居室图片做了更多的随机裁剪和旋转相当于在视觉上制造出更多样本。第二是在损失函数里给少数类加权重让模型在训练时更关注三居室的错分代价。这两步效果立竿见影三居室类别 Recall 从 78% 提升到 89%。这里分享一个更通用的经验日常图像分类项目里数据增强不要盲目追求复杂。户型图是线性结构为主的图旋转 90 度、镜像翻转都有现实意义但你如果加高斯噪声或者随机擦除反而会破坏结构信息让模型学到错误特征。增强手段一定要和业务场景匹配。3.4 跑通之后的性能与部署模型训练完之后打包成一个接口服务输入图片返回类别和置信度。在实际运行中有一个问题要提前想好置信度低的图片怎么办。我的策略是分两条路置信度大于 0.8 的自动归档置信度低于 0.8 的进入人工审核队列。这个阈值是跟运营一起调的他们觉得 0.8 差不多误判率可接受。模型在真实线上数据里准确率大约 90%比人工审核快了很多倍而且人工只需要处理三成不到的争议图片。4 租客群体分层无监督聚类如何给运营产出决策4.1 为什么不直接拍脑袋分三档租客分层这个需求运营一开始想要的其实是高价值、中价值、低价值三档里面还参考了活跃不活跃这种主观判断。我直接建议别这么干原因很简单拍出来的档位经不起推敲回头业务复盘时会问凭什么他是高价值。机器学习在这里的价值不是替代运营思考而是提供一个客观、可复现的分群依据。运营可以基于分群结果重新定义自己的运营策略而不是靠感觉。4.2 特征标准化和维度选择的细节做租客聚类我挑了一组特征近 30 天下单次数、近 30 天浏览房源数、近 90 天消费金额、平均单笔订单金额、在平台停留天数。这里面不同特征的量纲差异非常大消费金额可能是上千浏览数可能只有几十如果直接丢进 KMeans欧氏距离会被消费金额主导。所以聚类前必须做标准化我用的方法是 Z-score 标准化让每个特征的均值为 0、标准差为 1。这一步是很多人最容易忽略的但也是最关键的一步。还有一点要提醒特征不要选太多。我开始还加了城市、注册来源等特征结果聚类轮廓系数反而下降了。原因是这些类别型特征和消费行为的相关性不强加入后稀释了主要信号。最后只保留五个数值特征聚类结果反而更干净。4.3 聚类结果验证与业务翻译KMeans 最麻烦的问题是 K 怎么定。我用肘部法则同时也看了轮廓系数K 值轮廓系数业务解释20.38过于粗只分成活跃和不活跃30.44比较清晰但其中一类区分度不够40.41分得过细难以运营最终选了 K3。我给这三类起了业务名高频浏览但低消费的观望型租客、消费金额大但频次低的长住型租客、浏览和消费都中等偏上的稳定型租客。这样运营一看就知道该做什么动作观望型适合推送短租优惠券长住型适合推送月租折扣。这里有个非常容易犯的错不要只看聚类结果还要用业务知识去验证每一类的合理性。如果分出来某一类里既有消费 100 元的也有消费 10000 元的那这个聚类基本是失败的可能因为标准化或特征选择出了问题。4.4 冷启动和新数据回滚问题聚类模型上线后有个天然问题用户行为特征每天都会变KMeans 中心要不要每天重新算我实际操作时用的是离线重训练 定期发布的模式每天凌晨用过去 90 天的数据重新训练一次模型然后保存簇中心。线上预测时只需要把当天用户特征标准化后计算离哪个簇中心最近。这个做法的好处是简单稳定坏处是用户行为突变时模型不能立刻反应。比如平台搞一次大促后很多平时不活跃的用户突然大量下单但模型的簇中心可能还是旧的导致这些用户被分到观望型。我后来加了规则兜底当天消费金额超过某个阈值的用户直接临时打大促敏感型标签不参与模型分群。这听起来不太优雅但业务上非常实用。5 全链路踩坑记录这些坑比算法本身更值得写5.1 特征泄漏最隐蔽的错误租金预测第一版模型效果奇好LightGBM 的 MAE 一度低到 6.2 元/平米我当时就觉得不对劲。后来排查发现特征列表里混进了一个挂牌时长字段——这个字段是房子挂出去之后慢慢累积的预测时根本不知道未来值。这就是典型的特征泄漏模型偷看了未来信息。你在训练集上它表现神勇一上新数据就崩。排查办法是列出特征清单逐个问业务方这个字段在预测时刻能不能拿到、是不是已知的。数据科学家一定要学会对这些字段保持警惕尤其在业务方导数据的时候他们常常把最终结果也当成普通字段导出来。5.2 训练和预测口径不一致户型图分类模型在测试集上准确率 92%上线后大概一周准确率掉到 86%。排查了很久发现原因是线上接口收到的图片和训练时的预处理不一致。训练时我用的是标准 224x224 的 RGB 图片但线上有一部分运营上传的是带水印的 PNG 图透明通道撑大了体积压缩处理时颜色值发生了变化。这个问题靠模型本身无法解决只能在接口层统一入口图片入库前先统一格式、统一大小、统一颜色空间。训练和预测的口径不一致是所有模型上线后性能下跌的头号原因。5.3 先跑基线再谈优化这个小节想说的其实不是技术而是心态。日常项目里如果一个简单模型已经能满足业务需要完全没必要为了上价值去换复杂模型。租金预测里线性回归已经能解释 70% 的变化只靠它就能把定价专员的效率提一倍后来我加 LightGBM 是为了把 70% 推到 83%但你要知道后面这 13% 的代价是更高的解释成本和维护成本。这个权衡要提前做。我现在的习惯是永远先搭一个最最简单的规则或线性模型做基线把流程跑通再考虑迭代。很多项目根本走不到迭代那一步因为基线已经够用了。5.4 可解释性输出给业务方最后聊聊模型结果落到业务侧时的表达问题。我每次交付都会附上一张特征重要性图用 LightGBM 自带的 feature importance 画出来让运营知道模型主要看面积、区位和房龄。这在沟通中很有用因为业务方不是要理解原理他们只是想确认这模型没有乱来。另外我绝不会只交付一个文件或一个接口一定会附带一份一页纸说明写上模型适用范围、已知局限、建议复核的边界条件。这才是日常项目里最容易被低估的产出物。很多做机器学习的同学喜欢把精力花在调参和刷点上但真实项目的成败往往取决于能不能和业务方把口径对齐、把预期管住。
