做招聘匹配，我们踩过最深的坑，是把“字面”当成“意思”。求职者不会写关键词，JD 描述也常常失真。靠字面比对做匹配，两头都对不上。我们的结论是：招聘匹配要理解“经历”，不能只比“字面”。
先看三个真实会发生的场景，都是示意例子。
场景一：求职者不会表达。一个做客服、想转运营的候选人，简历写“维护客户关系，处理客户投诉”。岗位 JD 写“负责客户运营，提升复购率”。字面上两组词完全对不上，关键词匹配直接把他漏掉。可经历是同一件事：客户服务、复购、运营本就是一条线。拖累匹配的不是能力，是表达。
场景二：JD 失真。JD 写着“3-5 年 Java 开发”。候选人简历写“独立重构支付系统，扛住 5 万 QPS”。关键词匹配拿“Java”“3年”去比对，年限不够就过滤。可这个人做的事，比“3年 Java”难得多。字面匹配衡量不了经历的分量。
场景三：关键词灌水。有人把简历写成词频统计表，“分布式、Spring Cloud、大数据”堆满全篇。关键词匹配给他高分，HR 约来一聊，项目经历对不上。词频高、能力虚，这是字面匹配的天然漏洞。
三个场景，三个病灶：不会表达、描述失真、刻意堆词。根子一样——只比字面，不比经历。这也是我们转向语义匹配的起点。
招聘匹配为什么比其他搜索场景更难
关键词匹配在一般搜索里够用，在招聘里却系统性失灵。原因有三层。
第一，它是双边市场。一边是求职者，一边是 HR，两头都在决策。匹配好不好，要看两边的转化，不是看某一端。
第二，语料极度长尾。岗位千差万别，同一个意思有几十种写法。词表永远追不上真实表达。
第三，代价不对称。漏掉一个合适的求职者，和推给 HR 一个不合适的候选人，都不是简单的“少一次点击”。匹配错了，两边都在流失信任。
这几层叠加，逼得我们放弃字面匹配，去做语义匹配。
语义匹配的理解单位是“经历”，不是字面
语义匹配（semantic matching）不比较字面词，而比较含义。我们把简历和 JD 各自变成“含义的表示”，再判断它们像不像。
核心是一套向量召回链路。这里的“向量”（vector / embedding），可以理解成一段文本被编码成一串数字，这串数字代表这段文本在“语义空间”里的位置。含义越接近的文本，位置越靠近。
模型选型、向量库、召回链路，各家实现差异不小，我们不在这里下结论：〔待确认：模型选型/向量库/召回链路，按真实情况填〕。下文讲的是不依赖具体选型的一套通用思路，以及我们踩过、绕开的坑。
双塔结构：简历塔和 JD 塔各编码一端
召回链路的第一步，是给简历和 JD 各配一个编码器。这就是双塔（two-tower）结构。
● 简历塔（简历编码器）：输入简历文本，输出一个向量。
● JD 塔（JD 编码器）：输入岗位 JD，输出一个向量。
● 两塔共享同一套语义空间，简历向量和 JD 向量可以直接比距离。
为什么拆成两塔，而不是一个编码器吃两边？我们的经验是，简历和 JD 是两种语体。简历叙事，JD 列要求，同一个词在两边的含义重心不一样。拆开各自优化，匹配更稳。
训练阶段，两塔用配对样本一起调：一份简历和一个 JD 确实匹配，就让它们的向量靠近；不匹配的，推远。
这里其实踩过坑，后来才改成。早期我们用随机负采样造“不匹配样本”，模型学出来全是往中间挤，区分度很差。后来加了难负样本——表面很像、实际不匹配的简历-JD 对，才把边界磨出来。负样本质量决定双塔能学到多细，别省这一步。
向量召回链路：从离线编码到在线最近邻
完整链路分四段：离线编码、入库、在线召回、粗排精排。
- 离线：把全量简历和 JD 编码成向量，写进向量库。
- 入库：向量库建索引，方便快速查找。
- 在线召回：来一条新文本（简历或 JD），编码成一个向量，在库里找离它近的一批。这步叫近似最近邻（ANN），是快速近似，不保证全局最优，但足够快。
- 粗排精排：召回只保证“大概对”，量太大，得逐级筛。
这里也踩过坑。早期我们召回拉得很宽，Top-K 取很大，想让“全都捞上来”。结果粗排扛不住，延迟飙上去。后来改成召回窄一点，把“更准”的活儿交给粗排。
还有一个坑在距离度量。向量距离有两种算法，余弦相似度和欧氏距离。早期一边塔做了 L2 归一化，另一边没做，余弦和欧氏混着用，线上分数不稳。后来统一 L2 归一化，两种度量才等价，问题消失。
粗排和精排的分工要分清。粗排便宜、快，用轻量特征把候选砍到几百条；精排准、贵，用更重的模型和更多特征，对最后的几十条细排。每一级的定位不一样，别混。
只优化求职者侧会出事——HR 侧回复率也是指标
这是容易被忽视的一环。一开始我们盯着求职者侧优化：召回覆盖、推荐点击、匹配分数。求职者侧确实上去了，可 HR 侧出问题了——推给 HR 的简历太多太杂，HR 不回。
这里其实踩过坑，后来才改成。匹配是双边市场，求职者要“被看到”，HR 要“值得回复”，两边是一根绳子。只优化求职者侧，等于把大量候选往 HR 面前堆。堆多了 HR 就懒得看，回复率掉，整个链路的转化就断。
求职者侧指标和 HR 侧指标还经常打架。推得多，求职者爽了，HR 烦；推得少，HR 清净，求职者没人理。单看任何一端都会跑偏。
所以我们后来把指标成对看。求职者侧看匹配精准度、推荐质量；HR 侧看回复率、筛选效率。评估时用整条转化漏斗，而不是某一端的分值。把 HR 回复率纳进线上和离线的共同口径之后，两边的体验才拉平衡。
匹配分数不能直接甩给用户——可解释性
双塔给的是一个相似度分数，可能从 0.62 到 0.91，看着精确。可你把它直接甩给用户，用户只会问一句：凭什么？
我们的做法，是把分数拆成解释项。
● 技能命中：JD 要的技能，简历里出现几条。
● 年限 / 层级命中：工作年限、职级是否对上。
● 行业 / 项目经历命中：有没有相关行业的项目经验。
然后给用户一句话，比如“匹配度较高，因为你有支付类项目经验，且年限符合”。分数是结果，解释项才是用户能信的东西。
这里其实踩过坑。早期我们把原始相似度分当分数展示，用户看不懂 0.78 是什么意思，投诉“算法乱推荐”。后来改成解释项加档位（高 / 中 / 低），原始分藏在内部，用户看到的是能理解的理由。
可解释性不能靠模型自己生成。早期我们试过让模型生成解释，输出不可控，会给用户编理由。后来改成“模板加槽位”：命中哪些技能、年限差几年，填进固定句式。这样可控、可审计。可解释性不是附加功能，是匹配产品的一部分。
代码示例：相似度计算与召回粗排
下面给一段框架级代码，示意向量相似度怎么算、召回和粗排怎么搭。不涉及内部实现，换成你自己的模型和向量库就能对上。1. 向量相似度：余弦相似度
余弦相似度衡量两个向量方向有多接近，取值 -1 ~ 1，1 表示方向一致。
import numpy as np
def cosine_sim(vec_a, vec_b):
a = np.asarray(vec_a, dtype=float)
b = np.asarray(vec_b, dtype=float)
if not (np.any(a) and np.any(b)):
return 0.0 # 有一端是零向量，判不了相似，给 0
return float(a @ b / (np.linalg.norm(a) * np.linalg.norm(b)))
2. 召回：向量库做近似最近邻检索
faiss 是通用向量检索库，这里只示意接口，不涉及内部模型。
import faiss # 示意
class RecallEngine:
def init(self, index):
self.index = index # 已建好的向量索引
def recall(self, query_vec, top_k=200):
# query_vec: 简历或 JD 编码出的向量，shape=(dim,)
scores, ids = self.index.search(query_vec[None, :], top_k)
return ids[0].tolist(), scores[0].tolist()
3. 粗排：对召回候选按轻量信号线性打分，砍到几百条
class CoarseRerank:
def init(self, weights):
self.weights = weights # 各信号的权重
def score_one(self, cand):
# cand 是一组轻量特征，如：向量相似度、技能命中数、年限匹配
return sum(self.weights[k] * cand.get(k, 0.0) for k in self.weights)
def rerank(self, candidates, keep=500):
scored = [(c, self.score_one(c)) for c in candidates]
scored.sort(key=lambda x: x[1], reverse=True)
return [c for c, _ in scored[:keep]]
链路跑起来大致是：recall(query_vec, top_k) 拉回候选，CoarseRerank.rerank 砍到几百条，再进精排。粗排特征选轻量的，别把重模型搬进来，否则延迟会回来。
技术背景卡
● 目标：理解“经历”而非“字面”，服务招聘双边市场。
● 核心结构：双塔（简历塔 + JD 塔），共享语义空间。
● 链路：离线编码 → 向量库入库 → 在线 ANN 召回 → 粗排 → 精排。
● 双边指标：求职者侧（匹配精准度、推荐质量）+ HR 侧（回复率、筛选效率）。
● 可解释性：相似度分数拆成技能 / 年限 / 行业 / 项目解释项，按档位展示。
● 匹配精准度数据：〔占位：口径与来源未补齐前不写数字〕
● 模型选型 / 向量库 / 召回链路：〔待确认：模型选型/向量库/召回链路，按真实情况填〕
开放讨论
- 双塔的相似度分数要不要直接给 HR 看？还是永远拆成解释项？
- HR 回复率纳进匹配目标后，会不会反过来压低估分候选的曝光？怎么权衡？
- 冷启动：新岗位、新技能样本少，向量召回容易哑火，你用什么办法补？
- 可解释项怎么做成线上可审计的？解释错了，比不解释更伤信任。
