记得当时刷贝壳这套“数据挖掘/机器学习工程师笔试卷2”的时候最大的感受就是题目不算偏但覆盖面特别广从机器学习基础理论到数据挖掘实战再到 SQL、编程题全都有。尤其它会把房产交易场景揉进算法题里让你用模型去解决“房源估价”“用户找房偏好”这类真问题。这一点和其他纯考算法套路的互联网公司不太一样贝壳的题更希望你具备“业务理解 算法落地”的综合能力。这篇就把这套卷子的考察逻辑、高频考点、实战解题思路全部拆开讲。不论你是准备春招秋招还是单纯想看看数据挖掘/机器学习工程师笔试都在考什么都可以参考。我会把每类题背后的考点、为什么这么考、怎么答得分高一次说清楚。1. 笔试卷整体画像与考察逻辑拆解1.1 从岗位定位反推考点范围贝壳找房的数据挖掘/机器学习工程师日常工作基本围绕三类问题展开第一类是房产交易预测比如房源成交概率、房价估值、供需趋势第二类是推荐与搜索比如给用户推荐合适的房源、给经纪人推荐潜客第三类是风控与运营策略比如识别虚假房源、评估经纪人服务质量。这套笔试卷的出题范围基本就是绕着这几块业务能力需求来的。所以你会发现卷子里不会只考“SVM 的核函数有哪些”这种孤立概念而是会把“逻辑回归做 CTR 预测时特征怎么处理”“A/B 实验怎么评估一个推荐策略是否有效”这些贴近业务的问题放进选项。它要筛选的不是只会背模型的应届生而是能理解“算法最终要服务于业务指标”的人。1.2 试卷结构选择题、问答题、编程题三维验证从往年多套题目的反馈来看贝壳春招笔试卷一般由三大部分组成题型题量参考考察重点单选/多选题约20-30道机器学习基础、概率论与数理统计、数据结构基础问答题/场景设计题约2-4道特征工程、模型选型、业务场景建模思路编程题/SQL题约2-3道算法实现、SQL 窗口函数、模型评估指标手写这套“笔试卷2”的典型特点就是问答题占比不低而且场景和贝壳业务高度相关。比如“如何构建一个二手房估价模型”“如何评估一个排序模型在推荐场景中的效果”。这类题没有唯一标准答案但答题时如果你能体现出对数据清洗、特征工程、模型评估、业务落地的完整思考链路得分会明显更高。提示不要只刷 LeetCode一定要准备“场景设计题”的答题框架。这部分才是和普通互联网公司拉开差距的地方。2. 机器学习核心考点实战解析2.1 高频考点过拟合、正则化与损失函数选择题里几乎必考过拟合的解决手段。你要能从“数据层面、模型层面、算法层面”三个方向快速列举增加训练数据、数据增强、降低模型复杂度、正则化、早停Early Stopping、Dropout、交叉验证。这里有个容易被忽略的选项是“增加迭代次数”它不是解决过拟合的方法反而可能加剧过拟合出题人经常拿它当干扰项。正则化部分L1 和 L2 的区别也是高频考点。L1 正则化容易产生稀疏权重原因在于 L1 的惩罚项在零点不可导优化过程中更容易把参数推向 0L2 正则化则是让参数整体缩小但不会精确为 0。从贝叶斯视角看L1 等价于给参数加上拉普拉斯先验L2 等价于高斯先验。答题时能把这三层几何意义、优化行为、贝叶斯解释写出来基本就是满分答案。损失函数这块常考的有均方误差MSE与交叉熵的选择。回归问题用 MSE但要注意异常值影响大的问题有时会用 Huber Loss 替代分类问题用交叉熵因为它对概率分布的差异敏感配合 Softmax 梯度形式简洁。还有一道高频变体题为什么分类问题不用 MSE核心原因是 MSE 对概率输出求梯度时在预测概率接近真实值或者接近错误极值时梯度会变得很小导致收敛缓慢而交叉熵的梯度与预测误差线性相关优化效率更高。2.2 树模型与集成学习从分裂原理到 GBDT/XGBoost树模型在贝壳这类业务场景里地位极高因为房源数据、用户行为数据大多是表格型数据树模型对特征尺度不敏感、能处理缺失值、可解释性还强。所以卷子里关于决策树和集成学习的题目通常不止一两道。决策树的核心考点是分裂依据。ID3 用信息增益C4.5 用信息增益比CART 用基尼指数。要会手算信息增益。比如一个简单的例子总样本 10 个其中正例 6 个、负例 4 个某个特征将样本分成两个子集子集1有 4 正 1 负子集2有 2 正 3 负。先算父节点熵H(D) -(6/10)log2(6/10) - (4/10)log2(4/10) ≈ 0.971子集1熵-(4/5)log2(4/5) - (1/5)log2(1/5) ≈ 0.722子集2熵-(2/5)log2(2/5) - (3/5)log2(3/5) ≈ 0.971条件熵 H(D|A) (5/10)×0.722 (5/10)×0.971 ≈ 0.846信息增益 0.971 - 0.846 0.125这道题考察的不仅是公式记忆更是你能不能在实际中应用。建议备考时把信息增益、基尼指数、信息增益比的计算过程各练一遍选择题里可能会给具体数值让你算分裂后的增益。集成学习部分Bagging 和 Boosting 的区别是必问。Bagging 是并行训练多个基学习器然后投票降低方差Boosting 是串行训练每一轮聚焦上一轮的残差或错误样本降低偏差。随机森林是 Bagging 的典型代表GBDT 和 XGBoost 是 Boosting 的代表。高频问答题是“XGBoost 相比 GBDT 做了哪些优化”至少要说四点目标函数泰勒展开到二阶比 GBDT 只用一阶梯度信息更准确加入正则项控制模型复杂度防止过拟合支持列采样既能减少计算量又能增加随机性对缺失值自动学习分裂方向。2.3 评估指标AUC、PR 曲线与业务指标的关联模型评估这块笔试卷里出现频率最高的就是 AUC。你要清楚 AUC 的含义是“随机给一个正样本和一个负样本正样本预测值高于负样本预测值的概率”同时知道 AUC 对类别不平衡相对不敏感。但这里有个坑贝壳的业务场景中很多模型面对的是极端不平衡数据比如“成交概率预测”真正成交的房源占比可能不到 5%。ROC 曲线在负样本远多于正样本时会显得过于乐观这时候 PR 曲线更能反映模型性能。所以题目会问在正负样本比例严重失衡时应该优先关注哪个指标我的建议是答题时分两层模型层面关注 PR 曲线下面积AP和 F1-score业务层面还要看 KS、Lift 等指标。尤其在做成交概率、风控模型时KS 值在金融和交易场景里是领导层最看重的指标之一因为它的含义是“好坏样本累计分布的最大差距”直观反映了模型的区分度。这个细节你在面试时提出来面试官会觉得你有实战经验。排序模型比如推荐系统、搜索排序那边除了 AUC 还要懂 GAUC、NDCG。贝壳的推荐场景中每个用户的房源偏好差异很大全局 AUC 可能看不出模型差异按用户分组算 GAUC 更能反映个性化效果。如果笔试问答题涉及“如何评价推荐排序模型的线上效果”就要把离线指标AUC/GAUC/NDCG和在线指标点击率、收藏率、咨询转化率分开说再补充 A/B 实验设计。3. 数据挖掘与业务场景题从题目到方案3.1 二手房估价模型的完整设计方案贝壳体系里最经典的数据挖掘题就是“房源估价”。题目一般这么出请设计一个二手房价格评估模型说明数据来源、特征工程、模型选择、评估方式和预估误差容忍度。答题时要体现从业务问题到技术方案的完整链路。我先讲框架数据来源分成三个层级。第一层是房源自身属性面积、户型、朝向、楼层、楼龄、装修程度。第二层是小区的属性小区均价、绿化率、容积率、建造年代、周边学校/地铁/商圈配套。第三层是市场供需特征近三个月同小区成交均价、带看量、挂牌量、去化周期。注意贝壳做估价有个天然优势是“楼盘字典”这套标准化的房源数据库能把房源属性做得很规范所以笔试题里如果提到“真房源数据库”你要意识到这是贝壳业务的基础设施。特征工程方面价格类特征要做对数变换因为房价近似对数正态分布直接预测原始价格容易让模型偏向高总价房源而且误差评估用比例误差比绝对值误差更合理。时间特征不能只放“挂牌日期”要构造“挂牌天数”“最近一次调价幅度”“同小区近90天成交均价走势”。文本特征比如房源标题、房源描述可以用 TF-IDF 或者 BERT 提取关键词特征但考虑到工程成本实际业务中可以先从关键词规则特征做起。模型选型通常先做线性基准Lasso 回归再做树模型LightGBM/XGBoost最后叠一个加权融合。估价模型的评估指标建议用 MAPE平均绝对百分比误差也就是预测值和真实值的绝对误差除以真实值然后取平均。二手房估价如果能做到 5%-8% 的 MAPE已经算不错的水准。答题时你可以直接说“目标控制 MAPE 在 6% 左右低总价房源允许误差更小高总价房源比例误差容忍度可以放宽”这会让面试官觉得你有工程判断力。3.2 推荐与排序用户找房偏好 经纪人匹配另一类常见场景题是“如何给用户推荐房源”。这道题最怕你直接答“用协同过滤”。在贝壳的场景里用户找房决策周期长、频次低、行为稀疏单纯协同过滤效果很差。更合理的思路是“召回 排序”两层架构召回阶段多路召回并行。第一路是规则召回基于用户筛选条件区域、价格、户型做硬性过滤。第二路是协同召回基于相似用户的看房/收藏行为做 ItemCF。第三路是向量召回把房源和用户的 embeddings 训练出来做近邻检索。排序阶段用树模型或者深度模型对候选房源打分。特征分为用户侧特征、房源侧特征、交叉特征和上下文特征比如“用户近7天在该商圈看房次数”“房源近7天热度上升趋势”“当前时间是否是周末看房高峰”。这里要补充一个实操细节贝壳的用户行为有很强的“任务型”特征一个用户可能一周只看某个小区的房子所以推荐时不能只看长期偏好还要捕捉短期意图也就是“session 内行为”。如果在问答题里提到“最后收藏、IM咨询、电话咨询是强意图行为要给更高权重”这道题基本能拿高分。经纪人匹配题也经常出现核心是“如何评估经纪人服务质量并实现人房匹配”。注意不要只做规则打分应该拆成一个“归因 预测”的问题先定义好服务指标响应时长、带看转化率、历史成交率、客户好评率再用分层模型消除经纪人所在商圈差异。比如一个热门商圈的经纪人天然成交量高你不能拿绝对成交量去对比不同商圈的经纪人而要做“商圈内归一化”。这种细节在答题时写出来就会明显区别于套模板的回答。3.3 A/B 实验设计从假设检验到业务落地场景题里也可能穿插 A/B 实验的设计题。比如“某推荐策略上线后实验组点击率提升 0.5%但是成交量没有显著提升怎么分析原因、如何决策”。答题节奏建议按这样的步骤展开第一确认指标是否可靠。点击率提升 0.5% 是否有统计显著性样本量够不够置信区间是多少如果 p 值很大那 0.5% 可能只是随机波动。第二分析漏斗。点击率提升了但成交量没变说明用户点击之后到咨询/带看环节出了问题可能是推荐房源虽然点击高但价格或位置与用户真实需求不符属于“标题党”。第三做分层分析。把用户按新客/老客、高/低活跃度、刚需/改善拆开看找出效应集中在哪个细分人群。比如高活跃用户点击率提升明显但刚需用户转化没有变化那策略可能只对“随便看看”的用户有效对真实购房者影响不大。第四决定是否全量。如果业务目标是成交量点击率提升但成交量不变策略价值有限建议继续优化或放弃。A/B 实验还有一个容易被忽略的点实验的“单位”和“分析单位”要一致。如果实验按用户分组但策略影响的是经纪人行为而同一经纪人服务多个实验组用户就会造成指标相关性影响显著性检验。这在贝壳这种“平台 经纪人”双边市场里尤其重要答题时能主动提“建议将分析单位对齐到实验单位或使用聚类稳健标准误”会是一个很亮眼的加分项。4. 编程题与 SQL 实战手撕算法的套路4.1 编程题LeetCode 中等难度为主重点准备四类贝壳笔试卷的编程题一般不会特别难考的是基本功常见题型集中在数组/哈希表、字符串/滑动窗口、二叉树、动态规划入门。建议把 LeetCode 热门 100 题中难度为“简单”和“中等”的部分刷透特别是哈希表、双指针、滑动窗口、单调栈这几类。举一个典型的例子“求一个字符串中最长无重复字符子串的长度”。这道题是滑动窗口的经典题复杂度要求 O(n)。核心思路是用一个哈希表记录每个字符最近出现的位置右指针不断扩张如果遇到重复字符就把左指针跳到重复字符上一次出现位置的右边一个。写代码时容易出错的地方是“跳转左指针要取 max不能直接赋值”因为左指针可能已经越过之前的位置了。这类题在笔试中出现概率高的原因是它考察了最基本的“用空间换时间”思想。准备时不要只背题解要把“哈希表优化查找”“双指针维护窗口”这类套路形成肌肉记忆。考场上编程题通常允许 Python优先用 Python 写代码量少调 bug 也快。4.2 SQL 高频考点窗口函数、留存率与转化漏斗贝壳的数据挖掘工程师笔试中SQL 题考得比其他互联网公司更贴合业务。房源表、用户行为表、经纪人表之间做关联查询考察点集中在聚合函数、窗口函数、行转列、多表关联和留存计算。窗口函数是必考。比如“统计每个经纪人近30天每天的带看量并计算最近3天带看量的移动平均值”这道题要用 SUM() OVER (PARTITION BY broker_id ORDER BY date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)。写 SQL 时注意窗口函数的执行顺序它是先 WHERE 过滤再分组最后做窗口计算所以如果你要过滤掉异常日期必须在 WHERE 里先做不能在窗口函数里做。留存率也是一个高频题。比如“计算某批次新增用户的第1日、第7日留存率”。核心是找出每个用户的首访日期作为基准日然后统计后续第 N 天仍有行为的用户数除以基准日新增用户数。这里有三个坑首访日期要用 MIN(event_date) 从行为表里取而不是从用户表里的注册时间取因为“新增”的定义在业务里可能是指“首次产生行为”第7日留存的时间窗口要严格按日期差算不能自然周对齐分母不能去重后漏掉当天有行为但第二天就流失的用户。建议平时练习时把“用户留存、转化漏斗、GMV 贡献分布”这三类 SQL 题型都手写一遍。笔试卷时间有限能在一道 SQL 题上 10 分钟内写对后面编程题才从容。4.3 手写评估指标代码AUC 和 F1 的边界情况有些批卷人会出“手写 AUC 计算”的题。AUC 的计算逻辑不复杂把所有样本预测概率从高到低排序然后遍历遇到正样本 rank 加当前索引遇到负样本不加最后除以正负样本对总数。公式为AUC (sum_positive_rank - n_pos × (n_pos 1) / 2) / (n_pos × n_neg)很多人在代码里容易忘记处理“预测概率相同”的情况理论上有并列时要给相同分数样本赋予平均秩次。不过笔试代码题一般不会严格纠结这一点但要写清楚注释。更实际的做法是直接用 sklearn 的 roc_auc_score 验证自己的实现是否一致。这种题的核心目的不是让你重新发明轮子而是确认你真的理解 AUC 的排序本质而不是只会调包。另一个容易踩坑的是 F1 分数在多分类下的用法。如果问题没有特殊说明默认是针对二分类的正类计算。如果遇到多分类要问清楚是 macro 还是 micro但笔试没有交互机会建议在答案里注明“如果类别不均衡建议使用 macro-F1 或加权 F1”。体现你的严谨度。5. 备考清单与避坑经验5.1 按模块分配备考时间别在深度学习上耗太多不少同学准备数据挖掘岗位时容易被“深度学习、Transformer、BERT”这些热门词带偏把大量时间花在啃论文上。但从这套笔试卷来看深度学习的比例并不高最多出几道选择题考察基础概念比如 CNN 的感受野、RNN 的梯度消失、Attention 机制的基本思想。真正拉开分数差距的是机器学习基础、数据挖掘场景题和 SQL/编程基本功。我建议时间分配大概是机器学习基础理论 40%数据挖掘场景设计 25%SQL 和编程题 25%深度学习和 NLP/CV 基础 10%。你如果准备时间有限优先保证前两项。因为选择题占比高基础理论题是最容易拿分的博弈而场景题往往是大题答好一道就能拉开很多分。5.2 经典资料复习路线以题带点最有效理论部分重点复习李航的《统计学习方法》前八章覆盖感知机、KNN、朴素贝叶斯、决策树、逻辑回归、SVM再补上集成学习和聚类。周志华的《机器学习》西瓜书偏重原理推导建议搭配着看。如果时间紧张直接刷题遇到不会的知识点再回头翻书效率更高。刷题平台方面牛客网上有大量互联网公司数据挖掘/机器学习真题可以先按“公司真题”板块刷再刷“SQL 题库”。LeetCode 保持每天 2-3 道中等题的手感即可重点是不要停。有的同学考前一周就不碰代码题了结果上考场后连 HashMap 的 API 都要现想很吃亏。5.3 笔试时的答题策略场景题按链路回答编程题先暴力后优化场景设计题最容易出现的问题是“答案太散”东一句特征、西一句模型没有主线。我建议所有场景题都按下面的链路回答明确业务目标 → 定义指标 → 数据获取与清洗 → 特征工程 → 模型选型 → 评估与迭代。不管题目问的是估价还是推荐这个框架都能用。而且这本身就是工业界做机器学习项目的标准流程按这个结构答即使个别细节不到位整体逻辑也站得住。编程题部分如果一眼没有最优思路先写出暴力解并把复杂度说清楚再逐步优化。笔试平台通常按测试用例跑分暴力解至少能过一部分用例。我见过不少同学因为执着于一次写对最优解闷头纠结 20 分钟最后连一道题都没提交。考场上先保底、再冲刺永远是第一策略。5.4 容易被忽略的细节从文档能力到开源项目复盘最后提醒一点容易被忽略的东西笔试之后通常紧接着面试而面试官很喜欢围绕你写在简历上的项目深挖。所以备考笔试时最好顺便把自己的项目复盘一遍重点想清楚这几件事项目解决了什么业务问题数据怎么来的特征怎么做的为什么选这个模型而不选另一个最后效果怎么评估这套卷子还有一个隐性考察目的就是筛选“有业务 sense”的候选人。贝壳的数据挖掘岗位面对的是真实复杂交易场景模型效果好不等于业务效果好候选人如果有“从数据洞察到策略落地”的完整认知会比单纯刷题更受青睐。所以备考别只盯着公式和代码多花点时间想想业务指标和数据之间的关联这对笔试中的场景题、后面的面试都会派上用场。