专业服务 / 招聘平台
LinkedIn：基于语义的职位与简历匹配推荐
- 企业
- 国家
- 美国
- 实施阶段
- 运营中
- 资料发布
- 日期依据
- 资料发布的时间，可能与启用日期不同。
- 依据核验方式
- 阅读原文正文
业务问题
在把超过十亿会员与数千万条职位信息连接起来的推荐中，LinkedIn遇到了原有嵌入体系Pensieve的瓶颈。该公司说明，Pensieve依赖体量更小、精度更低的模型，并且被难以人工维护的分类体系和不易改动的上游处理流程所束缚。但若把大语言模型直接放进线上服务链路，又会带来高昂的计算成本、更复杂的部署流程，以及持续适配业务数据的负担。
使用的技术与数据
该公司构建了JUDE并将其投入实际服务。这是一个内部平台，把职位信息、会员档案和简历转换为同一空间中的嵌入向量。团队在一个共享基座模型上为每种输入类型配置prompt模板，并以two tower方式做微调。训练先使用相关性标签，随后在真实的投递记录上继续训练。团队使用LoRA、Flash Attention 2、bfloat16和DeepSpeed ZeRO，在多台H100上运行。服务侧则从Lambda架构迁移到Kappa架构。通过Kafka变更流只挑出发生变化的条目重新计算，并把结果写入Venice键值存储供线上读取。模型本身以gRPC服务的形式部署在Kubernetes的GPU pod上。
成果
LinkedIn表示，公司把这套嵌入同时接入职位推荐和职位搜索的二次排序模型，替换了原本重叠的标准化特征，并逐步放量。在线A/B测试中，合格投递提升2.07%，忽略职位次数与投递次数之比下降5.13%，投递总量提升1.91%。该公司补充说，这是那半年里单次模型变更所带来的最大幅度提升。在成本方面，只对变化条目重算的做法把推理成本最多降低到原来的三分之一，哈希与去重则把初次回填时的推理量减少到约六分之一。在70亿参数规模下，响应时间在第95百分位仍保持在300毫秒以内。
局限与待解问题
原文是该公司自己撰写的工程博客，没有准确说明所用基座模型的名称与规模。原文也未说明A/B测试在何时进行、持续多久、覆盖多大流量。各项指标只有相对变化率，没有绝对数值。由于未给出开始采用的月份，本条记录按文章发布日期排序。在此前的记录中，这是一条尚未读到原文的待核验候选，本轮调查读完原文后将其移入已核验依据。
来源
本案例根据公开资料整理，并非 ATF Works 客户的成果。