返回博客

技能词表一升级,为什么历史匹配结果全变了?

技能词表一升级,为什么历史匹配结果全变了?

招聘团队常把技能词表理解成一张不断追加同义词的表:发现新技术就加一行,发现别名就改名称。直到某次升级后,历史候选人的技能数量突然变化、同一搜索返回不同结果、旧报表无法复算,团队才意识到词表不是静态配置,而是生产数据依赖。

技能标准化把原文表达映射到概念。如果概念被拆分、合并、改名或调整上下位关系,所有引用它的简历、职位、搜索索引、匹配特征和统计口径都会受到影响。真正需要管理的不是一份最新 CSV,而是一条可追溯的概念演化历史。

稳定标识和显示名称必须分离

一个技能概念至少有三种东西:稳定 ID、首选显示名称和多语言或行业别名。名称会变化,ID 应尽量稳定。

例如“生成式人工智能”可能新增简称和英文别名,但仍是同一概念;“数据分析”也可能因为业务需要拆成探索性分析、商业分析和产品分析,这时不能只改名字,而要创建新概念并记录旧概念与新概念的关系。

ESCO 为职业与技能概念提供唯一 URI、多语言首选词和非首选词,并通过版本机制持续更新。O*NET 也将职业分类、内容模型、技能评分及其更新时间组织为可下载数据。它们说明公共职业知识并不是永不变化的字典,而是带版本、来源和统计元数据的数据产品。

技能概念要把稳定标识、名称、关系和版本历史分层保存
技能概念要把稳定标识、名称、关系和版本历史分层保存

企业内部词表可以借鉴这种设计:业务界面展示易懂名称,数据记录保存稳定 ID,所有映射同时带上词表版本。不要把中文名称当主键,也不要因为修正一个错别字就让下游认为出现了新技能。

更新不只有“新增”和“删除”

技能知识库常见变更包括:

  • 新增:出现新工具、法规、方法或岗位实践;
  • 别名调整:增加缩写、旧称、拼写和多语言表达;
  • 拆分:一个过宽概念分成多个更具体概念;
  • 合并:重复或难以区分的概念归一;
  • 关系变化:上下位、相关技能或职业关联被修正;
  • 停用:概念不再推荐使用,但历史记录仍要可解释;
  • 作用域变化:同一词在行业或地区中的含义被重新限定。

每类变更的迁移方式不同。新增别名通常可以安全重建索引;拆分却无法自动判断历史文本应该落到哪个新概念,必须回看原始证据;合并可能提高召回,却也会丢失原有细粒度;关系变化会直接改变技能扩展和匹配分数。

因此,变更单至少记录:旧版本、新版本、变更类型、原因、来源、影响范围、迁移规则和审核人。

永远保留原文和映射事件

最脆弱的数据模型只保存标准技能 ID。一旦词表变化,团队不知道当初候选人写了什么,也无法判断旧映射是否合理。

更可靠的记录包含:原文片段、页码或字符位置、语言、标准概念 ID、映射类型、置信度、词表版本、映射器版本和时间。映射类型可以区分精确别名、规则归一、模型候选、人工确认和上位概念回退。

这样,词表升级时不必修改原始事实,只需生成一批新的映射事件。旧结果仍可按旧版本复现,新结果也能解释变化原因。

用双轨迁移,不要原地覆盖

词表升级应让旧版和新版并行计算、比较差异后再切换
词表升级应让旧版和新版并行计算、比较差异后再切换

一次安全升级可以分为六步:

  1. 冻结旧词表和使用它的模型、索引版本;
  2. 生成旧到新的概念变更表;
  3. 用原始证据在旁路重算新映射;
  4. 比较候选人技能、职位要求、搜索和匹配结果;
  5. 对高影响差异人工抽样并修改迁移规则;
  6. 切换读取版本,同时保留回滚能力。

不要直接在数据库里把旧 ID 批量替换成新 ID。拆分关系不是一对一替换,自动迁移应允许 unresolved 状态。宁可把少量不确定样本交给复核,也不要用一个看似完整的迁移掩盖错误。

回归评测要覆盖关系,而不仅是词面

词表测试至少分三层。

概念层检查 ID 唯一、名称和别名冲突、循环上下位关系、孤立节点、多语言缺失和停用引用。

映射层用固定原文样本评价 Precision、Recall、歧义率和人工复核率。要特别覆盖短词、大小写、版本号、同名工具和行业多义词。

业务层比较升级前后的搜索召回、匹配排序和报表口径。差异本身不一定是错误,但每个大幅变化都应能归因到某项词表变更。

例如新增一个“生成式 AI”上位概念后,相关岗位召回可能提高;如果它通过过宽的关系扩展让只提到普通文本生成的候选人进入所有机器学习岗位,则需要限制扩展层级或降低关系权重。

公共分类不能直接替代企业语境

ESCO 和 O*NET 提供了结构、定义、关系和多语言资源,但企业仍有内部产品、技术栈、岗位族和能力等级。比较稳妥的方式是建立三层:公共概念层、企业扩展层和原文证据层。

企业概念可以映射到一个或多个公共概念,同时保留自己的适用范围。不要修改公共 ID 的含义来迎合内部用法,否则升级公共版本时会失去可比性。

公共分类中的职业—技能关系也不能直接当作候选人评分权重。它提供知识先验,具体岗位仍应由 JD、招聘负责人和实际证据决定。

版本应该进入所有下游结果

词表版本不能只存在知识库后台。以下对象都应带版本:

  • 简历与 JD 的标准化映射;
  • 搜索索引和查询扩展;
  • 匹配特征与解释;
  • 离线评测集和报表;
  • 人工修改记录;
  • API 返回和审计日志。

当招聘者问“为什么上周能搜到,这周搜不到”时,系统应能回答是原始简历变化、词表升级、索引重建、模型更新还是过滤条件改变,而不是只给一个最新结果。

词表发布前的检查清单

  1. 每个概念是否有稳定 ID,而不是以名称作主键?
  2. 拆分、合并、停用和关系变化是否分别建模?
  3. 原始证据和旧映射是否仍能读取?
  4. 新旧版本是否在相同数据上并行比较?
  5. 不确定迁移是否允许进入复核,而非强制映射?
  6. 搜索、匹配、报表和 API 是否记录词表版本?
  7. 是否能按旧版本复算关键历史结果?
  8. 是否准备了回滚和重新索引方案?

技能知识库的价值来自持续更新,但更新速度不能以失去历史解释为代价。把稳定标识、变更关系、原始证据、双轨迁移和业务回归做完整,词表升级才会从一次危险的全库覆盖,变成可观察、可审计的数据发布。

资料来源

返回博客申请试用