LinkedIn把检索嵌入按目标切开,上线调权增收4%

Embedding Subspace Partitioning for Dynamic Multi-Objective Retrieval

Shaobo Zhang, Alice Leung, Yunxiang Ren, Ping Liu, Yuchin Juan, Qianqi Shen, Benjamin Le, Jianqiang Shen, Chengming Jiang, Ko-Cheng Wang, Vidya Krishnamurthy, Caleb Johnson, Fedor Borisyuk, Luke Simon, Jingwei Wu, Wenjing Zhang

cs.IR

2026-09-25

ESP把bi-encoder嵌入切成互不干扰的子空间,检索分改成可在线调权的加权点积。LinkedIn职位匹配7天A/B增收4.0%、申请+3.95%、错配下降8.95%。

这篇在解决什么

工业检索几乎从不只服务一种相关性。LinkedIn的职位匹配要把语义匹配、用户互动和收入目标同时塞进第一阶段候选集。主流bi-encoder把所有信号压进一个静态向量,点积出一个分数。权重一旦写进训练损失,上线就没法拧;拆成多个检索栈,基础设施又随目标数线性膨胀。这就是论文说的no-knob问题:线上没有旋钮。

更硬的约束是几何的。两个目标的有效子空间冲突越大,共享嵌入能保住的每目标有效秩就越小。PCGrad这类梯度手术只能缓解优化冲突,切不掉表示瓶颈。

方法

ESP把d维嵌入切成k块,每块专管一个目标,检索分改成各子空间点积的加权和,权重在请求侧现调。权重全为1时退回普通点积,跟现有GPU穷尽kNN兼容。

Transformer版用模型自带的EOS当段分隔符,属性段放文本前面,再加段内注意力掩码和RoPE位置重置,一次前向就能把子空间隔开,不加参数。DNN版在共享主干上挂每目标投影头。LinkedIn线上用的是后者,k=3:互动、收入、匹配适配。

每个子空间用自己的损失。互动走InfoNCE,收入走蒸馏pClick的MSE,适配走BCE。子空间输出互不串梯度,共享主干仍吃混合梯度,但容量保证落在输出分区上。实体匹配这类低分辨率目标只需很小一块:约780个实体时,32维就饱和,占1024维的3%,把大部分维度留给语义。

结果

开源实验用MS MARCO造了带硬实体负例的基准:同一实体、不同信息需求。语义排名和实体排名的Kendall τ只有0.34,冲突代理ε=0.66。按定理,1024维共享嵌入的有效秩上限大约616,掉了四成。

方法语义NDCG@10实体Recall@10
多任务单头 αe=10.9240.887
多任务单头 αe=100.8231.000
单头+PCGrad0.8791.000
ESP we=0.8(上线调)0.9000.999

预训练设定下ESP语义NDCG 0.843、实体召回0.932,接近ColBERT,但每文档只存一份拼接向量,不是O(L)个token向量。k=3加上段落长度偏好后,权重(0.5,0.3,0.2)同时拿到语义0.843、实体0.957、长度匹配0.912。

生产侧更硬。强调收入时,单头in-batch recall掉28.24%,ESP只掉0.54%。适配子空间AUC 0.938,另外两个目标与k=2持平。7天A/B里,生产点wd1=0.3上收入+4.01%、申请+3.95%、点击+0.92%,错配率再降8.95%。同一模型还能扫出收入+0.91%到+7.36%的四个工作点。系统服务7000万+周活,已经跑了两年。

为什么重要

对做检索的人,这是把多目标从训练配方改成serving旋钮。前提是你愿意用GPU穷尽kNN,而不是IVFPQ那种假定单一几何的ANN。多头检索每个目标一套索引,ESP一份拼接索引就够。业务目标往往是低分辨率的,32维就能放下实体匹配。

这是架构改进,不是新损失。单目标BEIR上回归不超过0.3个点。没有穷尽检索硬件,这套旋钮转不起来。

局限与存疑

加权点积跟IVFPQ不兼容,没有GPU穷尽检索就很难落地。Transformer版依赖上游实体标注,没标就退回单嵌入。开源第三目标用段落长度当玩具,两个高分辨率目标对撞时还没压过理论上限。共享主干的梯度混合仍在,论文没证明trunk侧完全无干扰。A/B只报了显著性,没给置信区间和流量分配。MS MARCO硬负例里实体和语义相关,ESP在we∈[0.3,0.8]上语义NDCG几乎不动,极端we=1.0才塌到0.583,冲突被 complementarity部分掩盖。

术语

原文与代码

社区讨论

相关论文

全部论文解读