2. 招聘岗位数据基础
招聘岗位数据是企业景气因子构建中最贴近“实时需求”的一类高频数据。它不像财报那样滞后一个季度，也不像宏观指标那样月度发布，而是每天、甚至每小时都在变化。理解这类数据的来源、结构与质量问题，是后续做因子提取和景气判断的前提。本节围绕四个核心问题展开：数据从哪里来、一条岗位记录长什么样、怎么采、采到后怎么洗。
一、招聘数据来源：三类渠道的差异
招聘数据并非单一来源，不同渠道的字段完整度、更新频率和代表性差异很大。常见来源可归为三类：
- 综合招聘平台：如主流招聘网站，岗位量大、覆盖行业广，字段相对规范，但存在重复发布、职位挂靠和“僵尸岗位”。
- 垂直/行业平台：聚焦互联网、制造、医疗等特定领域，岗位描述更专业，技能字段更细，但样本量有限。
- 企业官网与官方招聘公众号：一手信息、可信度高，适合跟踪头部企业扩张信号，但采集成本高、格式不统一。
选择来源时，核心权衡是“覆盖广度”与“字段深度”。做宏观景气因子，通常优先综合平台保证样本量；做行业或岗位级因子，则需要垂直平台补充技能与薪资细节。
二、岗位字段结构：一条记录的标准骨架
无论来源如何，一条招聘岗位记录通常包含以下字段族。理解字段结构，才能判断哪些字段可用于因子计算。
| 字段族 | 典型字段 | 因子用途 |
|---|---|---|
| 标识字段 | 岗位ID、来源、抓取时间 | 去重、增量更新 |
| 岗位属性 | 岗位名称、职能类别、职级 | 岗位结构变化 |
| 企业属性 | 公司名称、行业、规模、融资阶段 | 行业景气度 |
| 地点与薪资 | 城市、区域、薪资区间、薪资单位 | 薪酬水平与区域热度 |
| 描述与要求 | 岗位描述、技能标签、经验学历要求 | 技能需求强度 |
| 时间字段 | 发布时间、更新时间、有效期 | 活跃度与时效性 |
其中，发布时间和薪资区间是因子计算中最敏感的两个字段：前者决定数据是否“新鲜”，后者常被用来构造薪酬指数。岗位描述文本则是技能因子的原料。
三、数据采集方式：从接口到页面的取舍
采集方式直接影响数据质量与合规风险。常见方式有三种：
- 官方API或开放接口：字段规范、稳定性高，但通常有权限和频率限制。
- 页面结构化抓取：通过解析HTML获取字段，灵活但易受页面改版影响。
- 批量数据采购或合作：质量较高，成本也高，适合长期因子生产。
无论哪种方式，采集层都要保留原始快照。下面是一个采集配置的简化示例，用于控制频率与增量：
source: job_platform_a
mode: incremental
schedule: "0 */2 * * *"
request:
page_size: 50
max_pages: 200
delay_ms: 800
fields:
- job_id
- title
- company
- city
- salary_min
- salary_max
- publish_time
- description
storage:
raw_path: /data/raw/job_platform_a/
format: jsonl四、常见数据质量问题与清洗入门
招聘数据“脏”是常态。典型问题包括：薪资写成“面议”或“15-25K·13薪”、城市写成“北京-朝阳区”、岗位名称同一职能多种写法、同一岗位多平台重复发布、发布时间缺失或异常。清洗的目标不是追求完美，而是让字段可计算、可比较。
清洗流程可概括为四步：
- 去重：按公司+岗位名称+城市+薪资区间做近似去重，保留最新发布时间。
- 字段标准化：薪资统一为月薪数值区间，城市统一为城市编码，岗位名称映射到标准职能。
- 缺失与异常处理：薪资缺失标记为NULL而非0；发布时间超出合理范围的记录剔除。
- 文本清洗：岗位描述去除HTML标签、广告语和重复模板，再提取技能关键词。
下面是一个薪资字段清洗的简化逻辑，展示从原始字符串到可计算区间的过程：
输入: "15-25K·13薪"
步骤1 提取数字区间: [15, 25]
步骤2 识别单位: K -> 千元
步骤3 识别薪资月数: 13薪 -> 年薪 = 月薪 * 13 / 12
输出: salary_min=15000, salary_max=25000, salary_month=13完成清洗后，建议对关键字段做一次质量抽检，例如统计薪资缺失率、城市标准化覆盖率、重复率。这些指标应作为数据管道的常规监控项，而不是一次性检查。
复盘来看，招聘数据基础工作的关键不在于“采得多”，而在于“字段可算、口径一致、质量可监控”。来源决定代表性，字段决定可计算性，采集决定稳定性，清洗决定可信度。把这四件事做扎实，后续的景气因子才有可靠的数据底座。