企业官网建设流程全解析

简介：智联招聘人岗智能匹配参赛方案，来自第二届阿里巴巴大数据智能云上编程大赛，由OTTO团队获得初赛/复赛/决赛均第四名。面向大数据竞赛学习者、算法工程师及招聘场景智能化从业者，重点解决人岗匹配中的特征工程与建模流程问题。包体共23个文件，以12个SQL特征工程脚本为核心，覆盖用户与岗位基础特征、交叉特征及CTR特征生成等环节；另含4张流程示意图、Python基线脚本、决赛答辩PDF和说明文档，完整呈现pai平台上的文本TF-IDF、数据合并、GBDT训练等处理流程，整体仅1.86MB，轻量且体系清晰。目前已有78人学习。通过这份资料，可还原排名前四的完整技术方案，学习用SQL做大规模特征构造，并参考团队的数据处理顺序、去重策略和评估指标实现，适合备赛或项目复用。

1. 智联招聘人岗匹配竞赛的 Rank 4 方案：OTTO 团队在云上的完整特征流水线

这个资源包来自第二届阿里巴巴大数据智能云上编程大赛的智联招聘赛道，文件名里的“智联招聘人岗智能匹配.zip”直接点明了比赛方向：给定智联招聘脱敏后的简历数据和职位数据，预测用户是否会申请某个职位，评估的是真实业务场景下的排序质量。OTTO 团队以初赛、复赛、决赛均 Rank 4 的成绩完赛，包内保留了 Round1 的 Python 基线 otto_base.py、答辩 PPT，以及 Round2 在 MaxCompute 上运行的整套 SQL 特征工程脚本和 PAI 平台的 TF-IDF 文本相似度、GBDT 训练流程。对正在做招聘匹配、推荐系统或者通用 CTR 特征工程的工程师来说，这套方案的参考价值不在某个单点模型，而在于完整演示了从原始行为日志到训练特征表的加工链路。摘下竞赛外壳，这条链路就是生产环境里特征仓库的雏形。

2. MaxCompute 上的数据准备：从 copy table 到基础特征表

2.1 流水线的起点：step_0_copy_table.sql 与脚本编排方式

打开资源包的 Round2 目录，能看到 step_0 到 step_3_6 十几个 SQL 文件，命名带序号，这种脚本组织方式本身就值得借鉴。用 MaxCompute 做数据加工，最忌讳的是把所有逻辑塞进一个大 SQL，执行失败后排查成本极高。OTTO 团队把流程拆成 step_0 复制表、step_1 基础特征、step_3 CTR 特征三个阶段，阶段内部按特征主题继续拆分。这样做的好处是单个脚本失败时只需要重跑对应步骤，特征加工过程中的中间表也能直接用于数据质量排查。

step_0_copy_table.sql 承担的是把比赛原始表复制到项目空间。比赛数据集存放在共享的 MaxCompute 项目里，默认是只读权限，多支队伍共用同一份表，直接修改原表不被允许也会互相干扰。常见做法是先复制一份完整数据，后续所有步骤都在副本上操作：

-- 把原始用户行为表复制到工作空间，避免影响其他队伍 CREATE TABLE IF NOT EXISTS ws_user_behavior AS SELECT * FROM ods_user_behavior;

CREATE TABLE AS在 MaxCompute 里默认复制数据，不保留原表的生命周期配置。如果是超大数据集，建议顺手给中间表加LIFECYCLE 7，测试期间省存储费。Round2 的脚本分工可以按下面这张表理解：

2.2 用户基础特征和职位基础特征：step_1_1 与 step_1_2 的口径选择

step_1_1_gen_user_base_feat.sql 生成用户侧基础特征，典型内容是从用户行为表里统计申请次数、浏览职位数、活跃天数、偏好的城市和学历段。这类特征属于“人人都会做”的部分，真正拉开差距的是统计口径。以申请次数为例，直接COUNT(*)得到的是行为条数，不是职位数——同一个用户可能对一个职位反复提交多次申请。比赛数据里这种行为不少见，所以一般同时生成两个字段：COUNT(DISTINCT jd_no)表示用户申请过的职位数，COUNT(*)表示行为总量。前者度量广度，后者度量活跃度，两者语义不同，都进入模型。

step_1_2_gen_jd_base_feat.sql 生成职位侧基础特征，通常包括职位标题、学历要求、工作年限、薪资区间、职位子类型、城市和发布日期。职位特征是后续所有交叉 CTR 特征的底座。有一个值得注意的细节：职位表里的离散字段在原始数据中可能是编号，比如学历用 1 到 8 表示，如果直接拿编号做交叉特征，模型会误认为编号之间的距离有语义。稳妥的做法是在基础特征阶段同时保留原始编号和可读类别标签，方便后面调试时对照检查。

2.3 重复数据处理与标签语义：step_1_3_drop_repeat_data.sql

step_1_3_drop_repeat_data.sql 是数据准备阶段最重要的脚本。原始行为数据里同一个(user_id, jd_no)可能出现多次，原因可能是用户重复投递、系统重试、测试流量混入。这里不能简单地把重复行全删掉，因为重复次数本身携带信息：一个用户连续申请同一个职位三次，意图强度明显高于只申请一次的用户。

常见做法是两层处理。第一层，用ROW_NUMBER()按用户和职位分组，按行为时间倒序保留最新一条，作为“是否匹配”的标签来源；第二层，对同一分组的记录数做COUNT(*)，生成 apply_times 特征，与标签并列进入特征表。这样既去掉了重复样本对训练目标的影响，又保留了行为强度的信号。

-- 按 user_id + jd_no 分组，保留最近一次行为，同时统计重复次数 CREATE TABLE user_behavior_unique AS SELECT user_id, jd_no, apply_date, degree_id, work_years, apply_times FROM ( SELECT user_id, jd_no, apply_date, degree_id, work_years, COUNT(*) OVER (PARTITION BY user_id, jd_no) AS apply_times, ROW_NUMBER() OVER (PARTITION BY user_id, jd_no ORDER BY apply_date DESC) AS rn FROM ws_user_behavior ) t WHERE rn = 1;

这段 SQL 里COUNT(*) OVER (PARTITION BY ...)是窗口函数，在不改变行数的情况下给每一行附加分组内的总数；ROW_NUMBER()按行为时间倒序编号，WHERE rn = 1取出每个分组里最新的一条记录。执行完后，表里每一行代表一个唯一的“用户-职位”对，apply_times 是这对组合在原始数据里的出现次数。这个字段后续既可以作为特征进模型，也可以当作样本权重，让重复申请的正样本在训练时被加权。

3. 多层交叉 CTR 特征：从 step_3_1 到 step_3_6 的 SQL 流水线

3.1 为什么招聘匹配可以套用 CTR 特征框架

人岗匹配问题，本质上是一个“用户-职位”二分类或排序问题：给定用户特征和职位特征，预测用户申请该职位的概率。这与广告系统里的 CTR 预估、推荐系统里的 CVR 预估共享同一套数学框架。OTTO 团队把 CTR 特征工程大规模引入招聘匹配，核心思路是把用户对职位的每次操作视为一次“曝光-点击-转化”行为：看到推荐是曝光，打开详情是点击，提交申请是转化。

这个视角下，CTR 特征不再只是点击率本身，而是泛指“某个群体对某个属性组合的历史偏好程度”。例如“职位+工作年限”的 CTR，统计的是特定职位下不同工作年限候选人的申请率。它直接度量了职位要求与候选人资历之间的匹配程度，比单独的职位特征和用户年限特征更有判别力，因为它是两者交互后的结果。GBDT 这类树模型虽然理论上能学习到特征交叉，但显式构造的交叉特征可以让模型在浅层就捕获强信号，尤其当原始特征维度高且稀疏时效果更明显。

3.2 职位维度 CTR：step_3_1_gen_jd_ctr_feat.sql 的分子分母设计

step_3_1 生成最基础的单维度 CTR 特征。职位维度的“点击率”在招聘场景里定义为：该职位收到的申请数除以该职位被展示的次数。由于比赛数据里通常没有显式的展示日志，分母一般用行为表里该职位相关的行为总数代替，比如浏览、收藏、申请加在一起。这样定义的好处是不依赖额外日志就能近似“曝光”分母。

-- 职位维度 CTR 特征：申请率与行为率，加贝叶斯平滑 SELECT jd_no, apply_cnt, view_cnt, apply_cnt / (view_cnt + 5.0) AS apply_rate FROM ( SELECT jd_no, SUM(CASE WHEN action_type = 'apply' THEN 1 ELSE 0 END) AS apply_cnt, SUM(CASE WHEN action_type IN ('view', 'collect', 'apply') THEN 1 ELSE 0 END) AS view_cnt FROM user_behavior_unique GROUP BY jd_no ) t;

这里分子是申请次数，分母是行为总数加平滑常数 5。为什么要加 5：冷门职位行为样本极少，直接相除得到的比值方差极大，比如只有一条行为且恰好是申请的职位，申请率是 100%，它显然不代表真实概率。平滑常数相当于先验强度，取值一般在 3 到 10 之间，根据数据规模调节。这段 SQL 另一个细节是除法：MaxCompute 里两个 INT 相除不会自动转浮点，代码里view_cnt + 5.0会把分母升成浮点，避免结果被截断成 0。

3.3 三种交叉视角：年限、标题、子类型

step_3_2_gen_cross_feat.sql 做的是通用交叉特征，常见的做法是把用户基础特征和职位基础特征两两组合，比如(degree_id, jd_no)、(city_id, jd_no)，再统计组合下的申请率。step_3_3 到 step_3_5 则是三个特定方向的交叉，各有侧重：

step_3_3 回答的问题是：某个职位在不同工作年限候选人中的吸引力如何分布。实现上拿用户行为表与职位表 join，按jd_no + work_years分组统计申请率。这里要注意用户侧和职位侧的年限字段都可能缺失，分组时把缺失单独放一组，不要直接过滤掉，否则会丢掉大量样本。

step_3_4 处理职位标题文本，先做分词提取关键词，再统计每个(jd_no, title_keyword)的申请概率。分词后一般要做停用词过滤，过滤掉“的”“了”“岗位”这类高频无意义词。关键词的存储可以用字典映射保留原始字符串，也可以用哈希编码压缩维度，哈希的缺点是不同词可能碰撞到同一编码，物化最终特征时要确认碰撞率在可接受范围。

step_3_5 用到智联招聘职位数据的类目结构。每个职位有主类型和子类型两层分类，比如“技术”主类下面有“后端开发”“前端开发”“算法”等子类型。当职位主类型相同时，子类型能捕获更细粒度的行业偏好信号。这个特征与 step_3_3、step_3_4 构成互补，分别覆盖资历、文本语义、类目三个维度，三项交叉之后再做合并，特征空间的信息量会比单维度统计丰富很多。

3.4 特征合并的时序问题：step_3_6_ctr_feat_merge.sql

step_3_6 把前面几步生成的 CTR 特征合并成一张宽表。这一步最容易出错。合并时要先想清楚 join 的 key：用户侧特征用 user_id，职位侧特征用 jd_no，交叉特征用复合键，比如(jd_no, work_years)。如果 key 对不上， join 后会出现 NULL，LightGBM 默认把 NULL 归到左孩子，可能造成偏差。

推荐的合并策略是主表用 LEFT JOIN：

-- 合并 CTR 特征：优先 LEFT JOIN，保证主表样本不丢失 CREATE TABLE merged_feature AS SELECT u.user_id, u.jd_no, u.apply_times, j.apply_rate AS jd_apply_rate, c.ctr_work_years, c.ctr_title, c2.ctr_sub_type FROM user_behavior_unique u LEFT JOIN jd_ctr_feat j ON u.jd_no = j.jd_no LEFT JOIN cross_feat_work_years c ON u.jd_no = c.jd_no AND u.work_years = c.work_years LEFT JOIN cross_feat_sub_type c2 ON u.jd_no = c2.jd_no AND u.sub_type = c2.sub_type;

用 LEFT JOIN 而不是 INNER JOIN 的原因：主表每一行都对应一个训练样本，如果因交叉特征缺失被 INNER JOIN 淘汰，样本集就隐式过滤了，训练和评估都会出现偏差。LEFT JOIN 后对 NULL 特征统一填充默认值，填充动作放在建模脚本里做，不要在 SQL 里用COALESCE硬填，因为验证集和测试集的统计口径可能不同，提前填掉会影响模型在分布变化时的表现。

4. TF-IDF 文本相似度与 GBDT 训练：PAI 流程背后的建模链路

4.1 文本特征进模型的两种形态

Round2 的 SQL 跑完后，特征已经合并成宽表，但还缺文本信号：简历和职位描述之间的语义匹配程度。OTTO 团队在 PAI 平台上用 TF-IDF 文本相似度补齐这一块。PAI 项目目录下有四张流程图，分别是 step1_base_text_tfidf.png、step2_data_merge_gen_feats.png、step3_get_sim_text.png、setp4_train_gbdt.png，对应文本向量化、特征合并、相似度计算、GBDT 训练四个环节。

这里要区分“文本直接入模”和“文本相似度入模”两条路：

OTTO 用的是第二种。原因很直接：GBDT 对稀疏高维向量的支持不如线性模型，几千维甚至上万维的 TF-IDF 向量直接喂给树模型，训练慢还容易过拟合。先算成简历-职位的相似度分数，维度和计算成本都大幅下降，特征语义也清晰。

4.2 相似度计算的细节和中文分词问题

step1_base_text_tfidf.png 展示的是把简历文本和职位描述文本分别转成 TF-IDF 向量，step3_get_sim_text.png 展示的是两两计算余弦相似度。TE-IDF 在这种场景下度量的本质是词表重叠程度，它理解不了同义词，比如“Java”和“JAVA”会被当成不同词，但它的可解释性和计算成本远优于当时可用的深度学习方案，作为 GBDT 的一个输入特征已经够用。

TE-IDF 处理中文必须跨过分词这道坎。PAI 的文本组件默认按空格分词，中文简历没有空格，不挂分词组件的话，出来的向量全是整句级别的大词，相似度计算直接失效。实际操作时，我一般会在进入 TF-IDF 组件前先做两件事：一是中文分词，用 jieba 或者 PAI 自带的分词组件都行；二是停用词过滤，把“我们”“公司”“岗位”这类高频词从词表里去掉，否则它们会占据大量 TF-IDF 权重。

-- PAI SQL 节点中常见的中文文本预处理 SELECT jd_no, concat_ws(' ', split_and_filter(jd_title_text, '-', 'stopword_list')) AS title_seg FROM jd_base_feat;

split_and_filter是示意写法，实际在不同版本组件里叫法不一。它的作用是分词后按停用词表过滤，再拼成一个空格分隔的字符串。这样输出的文本已经可以直接进入 PAI 的 TF-IDF 组件。step2_data_merge_gen_feats.png 这一步就是把相似度分数和前面 SQL 产出的 CTR 宽表按(user_id, jd_no)合并，合并后同样检查行数是否与主表一致——文本连接阶段丢行会导致训练样本和评估样本的分布不一致。

4.3 otto_base.py 与 GBDT 参数：树模型在宽表上的表现

otto_base.py 是 Round1 的 Python 基线脚本，结构上就是标准的结构化数据竞赛模板：读入特征表，划分训练验证集，训练 GBDT 类模型，输出 AUC 或其他排序指标。PAI 里的 setp4_train_gbdt.png 对应同一套流程的可视化版本。GBDT 的选择在当时是合理的：特征表里有大量类别型 CTR 特征、数值型统计特征和文本相似度特征，维度不高但噪音不小，树模型对这类数据的鲁棒性优于线性模型。

# 模型训练部分的常见结构 import lightgbm as lgb from sklearn.model_selection import train_test_split features = [c for c in df.columns if c not in ('label', 'user_id', 'jd_no')] X_train, X_val, y_train, y_val = train_test_split( df[features], df['label'], test_size=0.2, random_state=42, stratify=df['label'] )

gestión参数上，竞赛常见配置是学习率 0.05、叶子节点数 31 到 63、特征采样 0.8、样本采样 0.8，这个配置在多数结构化竞赛里都能兼顾 AUC 和训练速度。需要注意的一个点是类别特征的处理：如果交叉 CTR 特征表里有大量类别 ID 列，LightGBM 可以直接通过categorical_feature参数指定列名，前提是这些列进入模型前没有被 pandas 转成丢失映射关系的数值编码。稳妥的做法是把类别列统一转成字符串类型，LightGBM 内部会自行处理，不必手动 label encoding。

5. 复现 OTTO 方案的检查清单：三个影响结果的细节坑

5.1 动手前先核对环境差异

这套资源直接基于阿里云 MaxCompute 和 PAI 平台组织，用在自己的业务环境里，先核对四件事。一是表名和字段名，比赛原始表和业务表命名不同，所有 SQL 里的表名都要替换，字段名也要对照业务口径映射。二是数据时间范围，比赛数据集是静态的，业务场景通常是增量数据，需要给每个 step 加上分区字段，避免全量重算。三是评估指标，比赛用的是排序类指标，业务里如果关注 Top 100 的准确率，特征重要性的排序和调参方向都可能不同。四是存储配额，十几个中间表都保存全量数据时存储成本上升很快，中途表设置生命周期或定期清理是必要的。

5.2 坑一：去重时丢掉 apply_times，行为强度消失

第一个坑来自 step_1_3。如果把重复行为直接去重，不保留 apply_times，到特征工程阶段会发现用户对不同职位的申请强度信息全部丢失。OTTO 的脚本用窗口函数在去重的同时保留了这个字段，后面模型提升有明显贡献。复制到自己项目时，不要简化掉这一步。一个用户可以申请同一个职位五次，这在招聘平台上是强烈的意图信号，简单去重等于主动丢弃这份信息。

5.3 坑二：把文本相似度直接当最终打分

第二个坑是放大 TF-IDF 相似度的作用。文本相似度在这个方案里的定位是 GBDT 的一个数值输入特征，不是独立打分。如果把相似度分数直接当作最终匹配结果，会发现大量简历和职位描述用词差异大但实际匹配的样本被误判。正确用法是把它和 CTR 特征、统计特征一起喂给树模型，让模型自己学习文本信号和统计信号的组合权重。TF-IDF 的边界在于词法而不是语义，这一点要清楚。

5.4 坑三：合并宽表时用了 INNER JOIN 导致样本偏移

第三个坑出现在 step_3_6 的合并环节，前面章节已经强调过用 LEFT JOIN 保证样本不丢失。这里补充一个验证方法：合并完成后对比主表和结果表的行数，行数变少说明 join 过滤了样本。这个检查可以写成一条简单的SELECT COUNT(*) FROM merged_feature，放在每个特征合并脚本的末尾做断言，几秒钟就能发现问题。样本量如果因此损失超过 5%，要回查 key 的关联关系，通常是交叉特征的复合键某一侧字段存在脏数据。

这三个坑对应特征工程里最容易影响结果的三个环节：样本标签的构造、特征尺度的定位、特征合并的完整性。把这三点控制住，这套 SQL 特征工程和 GBDT 训练的流程就能在类似任务上稳定复现。

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