一份 JD 里同时混着公司介绍、岗位职责、必要条件、优先条件和福利。系统若只把出现过的技术名词全部标成“要求技能”，就会把“团队正在迁移到云平台”误成候选人必须会云计算，也会把“有金融经验优先”抬高为硬性淘汰条件。
职位解析的目标不是收集关键词，而是恢复招聘方表达的约束结构：做什么、必须具备什么、什么可以加分、证据强度如何、每项要求来自哪一句。
先识别条款角色，再抽取技能
同一个技能出现在不同段落，含义不同。“负责 Python 服务开发”描述职责；“熟悉 Python”是能力要求；“Python 经验优先”是偏好；“团队提供 Python 培训”则不是候选人条件。
因此第一步应识别章节与句子功能，再在要求条款中抽取技能、年限、程度、资质和关系。模块标题能提供强线索，但不同企业标题不统一，列表也可能混排职责与要求，仍需结合句子语义。
技能边界比想象中复杂
SkillSpan 发布了来自三种职位来源的技能抽取数据集，包含约 1.45 万句子和 1.25 万个专家标注的硬技能与软技能 span，并公开标注指南。研究发现，针对职位文本继续预训练的领域模型优于未适配模型，说明通用语言能力不足以覆盖招聘表达。
技能不总是单个名词。“设计并维护高可用数据管道”可能整体表达能力，若只标“数据”会失去任务含义；“良好的沟通能力”边界较清楚，却难以仅凭 JD 定义可测标准。抽取系统应保留完整原文 span，而不是急于压成短标签。
标准化不是把词替换掉
原文中“PyTorch”“深度学习框架”和“模型训练工具”粒度不同。标准化需要先生成候选概念，再结合上下文、岗位和词表关系消歧。原文值、标准概念、映射方法和词表版本应分别保存。
ESCO 由欧盟委员会维护，为职业、技能和资格提供多语言共同语言，并发布职业—技能关系。它适合充当检索、统计和匹配的参考词表，但不能直接成为所有公司的岗位定义。企业内部技术、产品和岗位层级仍需要本地扩展。
词表映射还需区分“精确等同、上下位、相关和未决”。把相关技能当作完全等同，会让搜索和匹配不断扩大条件。词表升级时，也要能重算映射而不丢失原文。
数据不足时可以使用弱监督
逐句专家标注成本高。Skill Extraction from Job Postings using Weak Supervision 使用 ESCO 和语义表示生成职位技能弱标签，展示了词表与表示模型结合的可行性。
工程上可组合章节标题、句式、技能词表、旧模型和 ATS 结构生成候选标签，再由少量金标准集评估。弱监督适合扩大训练数据，不应让规则生成的标签同时充当测试答案。新兴技能与内部术语也需要人工发现机制，否则系统只会识别词表已经知道的世界。
必须与优先需要单独建模
要求等级通常由“必须、至少、优先、加分”等语言表达，也会受到列表标题和句法范围影响。“具备 A，B 优先”不能把 A、B 都标为优先。年限、学历和技能之间也有组合关系，如“本科且三年经验，或硕士且一年经验”。
数据模型应支持 AND、OR、条件与例外，而不是把所有实体塞进一个技能数组。无法可靠恢复复杂逻辑时，应保留原句并标记人工确认，避免生成比原文更确定的结构。
评估要测结构，而不只是实体 F1
技能 span 的 Precision、Recall、F1 只是第一层。还需测条款角色、必须/优先等级、标准化准确率、实体与年限的关系，以及整条要求能否被正确重建。不同岗位族、公司模板和语言要分别统计。
业务测试则看解析结果是否帮助生成更准确的搜索条件和面试问题，招聘人员修改了哪些要求，以及系统是否错误扩大硬性门槛。职位解析不是为了让 JD 看起来更结构化，而是让下游匹配忠实于真实招聘意图。