LLM招聘匹配评测翻车：28条JD跑出负相关，Spearman分析复盘

1. 一次翻车的评测28条JD跑出负相关先说结论我用LLM给28条招聘JD做Agent岗位匹配打分把模型输出的匹配分和三位资深招聘官的人工判断做Spearman相关性分析结果ρ-0.085。负相关接近零基本等于模型打分和人的判断各说各话。这个结果第一次跑出来的时候我盯着屏幕看了半分钟怀疑是代码写反了。把分数列对调、把排序方向翻转、换一个相关性库重算ρ还是负的。那一刻我意识到问题不在计算在于我一开始就把匹配这件事想简单了。这篇东西写给两类人一类是正在做Agent应用、想用LLM做简历或JD匹配的开发者另一类是做招聘产品、想评估模型打分可信度的从业者。我会把整个评测的设计、28条JD的构造逻辑、Spearman的计算细节、以及为什么会出现负相关这件事一层层拆开讲。中间会穿插我踩过的坑包括prompt设计、评分维度定义、样本量陷阱这些常规文档不会写的东西。先给一个反直觉的判断在样本量只有28、评分维度又没有对齐的情况下Spearman相关系数本身就是一个高噪声指标ρ-0.085这个数字与其说证明了模型不行不如说暴露了评测设计的问题。但这个问题非常典型值得完整复盘一遍。2. 评测设计28条JD是怎么造出来的2.1 为什么是28条而不是280条很多人第一反应是样本太少。确实28条JD做相关性分析统计功效很低。但我当时的约束是人工标注成本。三位招聘官每人要对28条JD逐条打分每条JD要对照一份候选人画像判断匹配度单条耗时约3-5分钟28条就是接近两小时。三个人就是六小时的高强度标注这已经是能压榨出来的极限。如果扩到280条人工标注要么外包质量不可控要么拉长到几周招聘官会疲劳后段标注质量断崖下跌。所以我选择了一个折中28条JD但每条JD的构造是精心设计的覆盖不同的岗位层级、技术栈、职责范围而不是随机抓取。这里有个经验小样本评测里样本的信息密度比数量更重要。28条随机JD可能20条都是Agent开发工程师熟悉LangChain3年经验这种高度同质的描述相关性分析根本区分不出来。我刻意让28条JD在以下几个维度上分散岗位层级初级、中级、高级、专家、管理技术栈纯LLM应用、Agent框架、RAG、多模态、传统后端AI职责重心偏工程、偏算法、偏产品、偏架构行业背景互联网、金融、医疗、教育、制造业这样做的目的是让匹配分有足够的方差否则所有JD得分都挤在70-80分区间Spearman排序相关性会被压缩得毫无意义。2.2 候选人画像的设定评测的另一端是候选人画像。我设定了一个具体的候选人5年后端经验近2年转向LLM应用开发熟悉Python、有过Agent项目落地经验、了解RAG但没做过GraphRAG、英语读写OK口语一般。这个画像的关键是有明确的强项和弱项。如果画像是全能型那所有JD的匹配度都会很高区分度就没了。我特意让画像在某些维度上偏科这样不同JD的匹配分才会拉开差距。提示做匹配评测时候选人画像一定要有棱角。一个各方面都80分的候选人和28条JD的匹配分可能全在75-85之间这种数据做相关性分析是浪费时间。2.3 人工判断的标注方式三位招聘官拿到的不是给这条JD打个匹配分而是对28条JD做强制排序。为什么用排序而不是打分因为人对绝对分数的锚定很不稳定今天打75分明天可能打80分但人对这两条JD哪个更匹配的相对判断要可靠得多。具体操作给每位招聘官28张卡片每条JD一张要求他们按这个候选人适合投递的优先级从高到低排序。允许并列但鼓励区分。最后把三人的排序取平均得到一个人工排序。这里有个细节三位招聘官的排序一致性如何我算了一下两两之间的Spearman相关系数在0.6-0.75之间。也就是说人工判断本身也不是完全一致的存在0.25-0.4的人际噪声。这个数字后面会用到。3. Spearman相关性分析计算本身没问题问题在别处3.1 Spearman到底在算什么Spearman相关系数衡量的是两个排序之间的单调关系。公式是ρ 1 - (6 * Σd²) / (n * (n² - 1))其中d是每条样本在两个排序中的名次差n是样本量。它的核心假设是两个变量之间是单调关系。也就是说如果模型打分高人工排序也应该靠前模型打分低人工排序靠后。只要方向一致哪怕不是线性关系Spearman也能捕捉到。我用的是scipy的spearmanr输入是模型匹配分数组和人工平均排序数组。计算过程没有任何问题我甚至手算了一遍验证。3.2 ρ-0.085意味着什么ρ-0.085p值大约0.67n28。这意味着相关性在统计上不显著方向和预期相反负相关效应量极小基本可以认为是随机噪声但这里有个陷阱n28时Spearman的置信区间非常宽。即使真实相关性是0.328个样本也很可能跑出-0.1到0.5之间的任意值。所以ρ-0.085不能直接推出模型完全无效只能说在这个样本量下没有观察到正向相关。我后来做了个模拟假设真实相关性是0.4随机生成1000组n28的数据看ρ的分布。结果有大约18%的情况会跑出负相关。也就是说即使模型真的有点用28条样本也有近两成的概率让你看到负相关。这是小样本评测的固有风险。3.3 计算之外我检查了哪些东西跑出负相关后我按顺序排查了分数数组和排序数组是否对调了——没有排序方向是否一致1代表最好还是最差——检查后一致是否有重复值导致排名计算错误——用average rank处理了是否用了错误的相关系数Pearson vs Spearman——确认是Spearman数据里是否有异常值——28条里没有极端离群点排查完这些计算层面是干净的。问题出在更上游模型打分的维度和人工判断的维度根本不是一回事。4. 负相关的根因模型和人在匹配上看的不是同一件事4.1 模型在打什么分我的prompt大概是这样的你是一个招聘匹配专家。请根据以下候选人画像和JD描述 给出0-100的匹配分。考虑技能匹配、经验年限、行业背景。模型输出的分数我观察了一下主要集中在几个维度技能关键词重合度Python、LLM、Agent这些词出现了几次经验年限是否满足JD要求学历、行业等硬性条件模型本质上在做关键词匹配硬条件过滤。它很擅长判断JD要求Python候选人会Python但很难判断这个岗位实际需要的是能扛住高并发Agent服务的工程能力而候选人的Agent经验主要在小规模demo。4.2 人在判断什么三位招聘官后来跟我复盘他们的排序逻辑是这个候选人投这个岗位简历会不会被HR筛掉硬条件如果过了HR技术面能不能过真实能力匹配这个岗位的成长空间和候选人职业规划是否契合岗位的实际工作内容和JD描述是否一致很多JD写得漂亮实际是CRUD招聘官看的是这个人来了能不能干活、能不能留下、能不能成长。这是一个多维度的、带有很多隐性知识的判断。4.3 维度错位导致的相关性崩塌当模型用关键词重合度排序人用实际适配度排序两个排序之间没有必然的单调关系。举个具体例子有一条JD写的是负责Agent平台架构设计要求熟悉多智能体协作、有大规模服务经验。模型给这条打了高分因为候选人画像里Agent架构这些词都出现了。但招聘官把这条排得很低因为候选人虽然做过Agent但都是单机demo级别没有大规模服务经验这个岗位实际要的是能扛住生产环境的人。反过来有一条JD写的是LLM应用开发负责RAG系统优化3-5年经验。模型给的分中等因为候选人RAG经验只是了解级别。但招聘官排得较高因为这个岗位实际是团队扩招对RAG深度要求不高更看重后端工程能力而候选人5年后端经验是强项。模型看的是词人看的是事。这就是负相关的根本原因。5. 重跑一遍我做了哪些调整结果如何5.1 调整一把评分维度拆开原来的prompt是一个总分。我改成让模型输出多个维度的分硬性条件匹配学历、年限、行业技能关键词匹配项目经验深度匹配岗位职责匹配然后每个维度单独和人工排序做相关性。结果发现硬性条件匹配和人工排序的ρ0.42技能关键词匹配ρ0.31但项目经验深度匹配ρ-0.12。这个拆解很有价值。它说明模型在硬条件上和人的判断是一致的但在经验深度上完全跑偏。模型无法判断demo级Agent经验和生产级Agent经验的区别因为prompt里没有给这个信息模型也没有这个常识。5.2 调整二给prompt注入判断标准我在prompt里加了一段注意候选人的Agent经验主要是小规模demo没有大规模服务经验。 在评估需要大规模服务经验的岗位时应适当降低匹配分。加了这段之后项目经验深度维度的ρ从-0.12提升到0.28。虽然还是不高但至少方向对了。这说明一个事LLM做匹配prompt里必须包含判断标准而不能只给事实描述。模型不会自己知道demo级和生产级的区别你得告诉它。5.3 调整三换用排序而非打分我让模型直接对28条JD做排序而不是先打分再排序。prompt改成请将以下28条JD按该候选人的匹配度从高到低排序 输出一个包含28个JD编号的列表。结果ρ提升到0.35。虽然还是不显著n28但至少是正相关了。为什么排序比打分好因为打分需要模型建立一个绝对尺度而模型对绝对尺度的校准很差。排序只需要模型做相对比较这更接近LLM擅长的能力。5.4 调整后的完整结果方案Spearman ρp值说明原始总分打分-0.0850.67负相关不显著拆维度后-硬条件0.420.03显著正相关拆维度后-技能0.310.11不显著拆维度后-经验深度-0.120.55负相关注入判断标准后-经验深度0.280.15方向正确直接排序0.350.07接近显著这张表是我整个评测最有价值的产出。它说明不是LLM不能做匹配而是一个总分这种用法太粗糙。把维度拆开、把判断标准写进prompt、用排序代替打分效果会明显改善。6. 实操中踩过的坑与经验6.1 prompt闪退与内容审核跑评测过程中遇到过几次prompt被拦截的情况。有一次prompt里包含了候选人年龄相关的描述触发了内容审核返回invalid prompt: your prompt was flagged as potentially violating our usage policy。后来我把年龄、性别这些敏感字段全部从画像里移除只保留技能、经验、项目这些和工作直接相关的信息。注意做招聘匹配时候选人画像里不要包含年龄、性别、婚育、籍贯这些字段。一是合规风险二是这些字段对匹配判断没有正面价值反而会引入偏见。6.2 token超限与截断28条JD加上候选人画像一次性塞进prompt很容易超token限制。我一开始的做法是分批处理每批7条JD跑4次。但这样有个问题分批之间的打分尺度不一致。第一批可能最高分85第二批最高分92直接合并排序会失真。后来改成每批内部先排序然后跨批做归并排序。或者更简单把JD描述压缩到200字以内28条一起塞进去。压缩JD描述会损失信息但保证了尺度一致。6.3 人工标注的疲劳问题三位招聘官标注到第20条左右时明显出现疲劳。表现是排序变得随意相邻名次的区分度下降。我后来在标注流程里加了强制休息每标注7条休息5分钟并且把28条分成4组每组7条组内排序后再做组间归并。这个细节看起来小但对数据质量影响很大。人工标注的疲劳噪声会直接污染相关性分析的结果。6.4 样本量的现实约束如果重做一次我会把样本量提到至少50条。28条做Spearman置信区间太宽任何结论都站不住。但50条的人工标注成本是28条的近两倍需要提前规划好资源。一个折中方案用半自动标注。先让模型排序人工只做修正把明显错误的调整过来。这样人工成本降低但会引入模型偏见。适合探索性分析不适合严谨评测。7. 这套评测方法还能怎么用7.1 扩展到简历匹配同样的方法可以反过来用给一批简历让模型对某条JD做匹配排序再和HR的人工排序对比。逻辑完全一样只是把JD换成简历。7.2 用于prompt迭代的量化反馈ρ这个指标可以当作prompt优化的目标函数。每次改prompt跑一遍评测看ρ有没有提升。这比感觉这个prompt更好要靠谱得多。7.3 注意Spearman的适用边界Spearman适合单调关系但如果模型打分和人工排序是U型关系中间分匹配最好两头都差Spearman会失效。这种情况下应该用其他方法比如分组对比或互信息。7.4 小样本评测的替代方案如果样本量实在上不去可以考虑成对比较让模型和人对同一对JD做哪个更匹配的判断统计一致率。这比排序对样本量的要求低。Top-K命中率看模型排的前5条里有多少条在人工排的前5条里。这个指标直观且对小样本友好。分维度分析不要只看总分相关性拆开看每个维度的相关性往往能发现更有价值的信息。8. 关于ρ-0.085这件事我最后的看法这个负相关数字一开始让我很沮丧。但复盘完整件事之后我反而觉得它是个好事。它逼着我去拆解匹配这件事到底由哪些维度构成逼着我去检查prompt里缺失了哪些判断标准逼着我去思考LLM到底擅长什么、不擅长什么。LLM擅长的是基于明确标准的相对比较不擅长的是基于隐性知识的绝对打分。当你把判断标准写清楚、把任务从打分改成排序、把维度拆开单独评估它的表现会好很多。28条JD的评测规模确实小ρ-0.085这个数字也确实不显著。但整个排查过程里得到的那些经验——维度要拆、标准要写、排序优于打分、样本量要够、人工标注要防疲劳——这些比一个相关系数有用得多。如果你也在做类似的匹配评测我的建议是先把维度拆开每个维度单独算相关性看看模型到底在哪个维度上跑偏了。往往问题不在模型能力而在你没告诉它该看什么。