LLM招聘筛选大测评：谁在左右你的简历命运？

当企业用大语言模型（LLM）筛选求职简历时，决定你能否通过的，可能是一些你永远看不到的选择：用了哪个模型、给了什么指令、如何配置参数。开发者Maksim Silchenko为Kaggle基准测试挑战赛打造的FairScreen项目，用十个LLM在已知答案的虚构简历上做了系统测试，揭示了一个令人不安的现实——模型的名气、所谓的公平性指令、看似合理的解释，都无法告诉你它是否真的正确执行了招聘规则。

一个典型的例子说明了问题的严重性：某职位要求三年相关经验，申请人实际不足两年。模型准确地提取出了申请人的经验年限，却依然判定其“符合要求”。人类审核员一眼就能发现的矛盾，模型却视而不见。

测的到底是什么

一个合格的筛选模型，应该在申请人跨越某项明确门槛时改变判断，而在仅仅是姓名或排版变化时保持判断不变。FairScreen敏锐地指出：只测试后者（一致性）会漏掉一个显而易见的失败模式——一个把所有人都拒掉的模型，在不同姓名之间也是“完全一致”的。

为此，项目采用了“成对申请家族”的设计。以一个后端开发岗位为例，要求至少三年Python经验并通过SQL测评。每个核心家族包含两种资质状态（符合/不符合）、两种身份变体（不同姓名）、两种排版形式（重排、改写、无关细节等），共产生八个决策。只有当这八个决策全部正确，这个家族才算通过。作者将这一指标称为“稳健策略保真度”（robust policy fidelity）——50%的分数意味着一半的家族通过了全部检查，而非一半的单项回答正确。

测试对比了四种决策方式：直接判断、加入公平性指令、先提取事实再判断、以及用代码对同一份提取结果执行可运行策略。最后一种对比尤为巧妙——它固定了提取环节，只问模型的最终决策是否与它自己提取的数值在策略下应得的结论一致。所有申请人和策略均为虚构，身份变化基于新加坡本地背景设定。

值得强调的是，正确答案由隐藏的结构化记录在渲染申请前计算得出，LLM并不参与标注。两套策略实现与一个纯文本解析器在全部2528个最终变体上达成一致，保证了基准的可信度。

"稳健策略保真度"（robust policy fidelity）这一指标的设计逻辑值得进一步说明。传统AI评测常用"准确率"衡量单个回答的正确性，但在招聘筛选场景下，这会掩盖系统性偏差。举例而言，一个模型如果对所有申请人都输出"通过"，在资质参半的测试集上仍能获得50%的单项准确率，却完全没有执行任何招聘规则。成对家族设计的核心价值在于：它要求模型同时做到两件事——对资质差异敏感（符合/不符合者得到不同判断），以及对无关变化稳健（相同资质在不同姓名和排版下得到相同判断）。只有一个家族内全部八个决策均正确，才计为通过，这使得"蒙对一半"的策略无法获得虚高分数。这种"家族级别通过率"比条目级准确率更接近真实部署中用人单位关心的问题：这套系统在遇到类似申请时，是否始终按规则办事？

参测的十个模型

作者使用了两组不同范围的测试面板。在Kaggle上，运行了五个模型（Gemini 3.7 Flash、Gemini 3.1 Flash-Lite、GPT-5.4 nano、gpt-oss-120b、Gemma 4 31B），覆盖48个核心家族和证据充分性任务。

在新加坡国立大学（NUS）计算机学院的GPU集群上，运行了六个开源权重模型（gpt-oss-120b、gpt-oss-20b、Qwen3-32B关闭思考模式、Gemma 3 27B、Mistral Small 3.2 24B、Llama 3.1 8B），在192个核心家族上做了更全面的诊断测试。两组面板中重叠的gpt-oss-120b充当了跨平台校验，合计覆盖10个不同模型。

三个关键发现

配置可能比模型本身更重要

在开场的技术写作岗位家族中，关闭思考模式的Qwen3-32B批准了全部八份申请——包括四份不满足经验要求的。它在不同姓名间“完全一致”，却在一半决策上出错。

当作者在探索性重跑中为Qwen3-32B开启思考模式后，结果发生了戏剧性变化：

Qwen3-32B	关闭思考	开启思考重跑
八项全部正确的家族占比	39%	98%
不合格申请人被错误批准	41%	1%
单次直接决策的中位输出token	12	476

家族分数的差异高达**+59.4个百分点**（95%自助区间+53.1至+65.6）。不过作者审慎地指出，这是一个“配置结果”——重跑同时改变了采样设置和输出预算，无法单独归因于思考模式。但它传达的教训极具实践价值：一个基准结果必须附带模型配置，而不仅仅是模型名字。

相比之下，公平性指令的效果则不尽如人意。在集群六模型面板上，它仅使家族准确率变化−0.3个百分点；在Kaggle上为+2.5个百分点，区间均跨越零点。姓名实验同样未得出结论——身份互换改变了2.6%的直接决策，而同组另一姓名改变了2.2%，差异微乎其微。作者坦承这些控制组仅覆盖客服与实验室支持岗位，不能据此对所有职业做出普适的偏见判断。

代码能修复模型自相矛盾的决策

开场例子的决定性对比异常清晰：提取经验1.8年，要求至少3年，模型判定“符合”，而对同一份提取执行可运行策略得出“不符合”。

在集群面板上，用代码替代模型的结构化决策（基于相同的提取事实）平均提升了20.5个百分点的家族准确率。表现最悬殊的是Llama 3.1 8B，模型自判仅1%通过，代码判决则达56%：

集群模型	模型提取后决策	代码基于同一提取决策
Llama 3.1 8B	1%	56%
Qwen3-32B（关思考）	45%	73%
Gemma 3 27B	42%	65%
Mistral Small 3.2 24B	79%	91%
gpt-oss-20b	95%	99%
gpt-oss-120b	100%	100%

但代码重放有明确局限：它会继承提取环节的错误。当某段工作经历缺少结束日期时，提取器有时会返回已标注日期岗位的总和，而非记录“总年限未知”。代码随后把这个不完整的总和当作完整数据，错误地拒绝了申请人。在集群充分性测试中，gpt-oss-120b的通过率反而从56%跌到40%。因此作者给出的建议非常具体：可运行策略能修复决策的不一致，但前提是提取必须保留“缺失、冲突与不确定性”。

这里的"可运行策略"（executable policy）指的是一段结构化代码，它接收模型提取出的事实（如经验年限、测评成绩等结构化字段），按照预先定义的规则逻辑输出通过/拒绝决定，完全绕过模型的自然语言推理。这种"提取-判断分离"的架构在工业界有时被称为"LLM作为解析器、规则引擎作为决策者"的模式。其优势在于决策逻辑透明、可审计、可回溯——如果某位申请人被拒，可以精确定位是哪条规则触发、依据哪个提取字段，而不是追溯一段不可解释的模型输出。代码策略显著提升准确率这一结果，实际上印证了一个反直觉的观点：LLM在从非结构化文本中抽取关键事实时表现尚可，但在把这些事实映射为明确结论时，却容易引入与自身提取结果相矛盾的判断。将这两个步骤拆开，可以让各自的失败模式独立暴露，而不是混在最终答案里无从区分。

排行榜测的可能是“输出处理”而非模型能力

最具启发性的平台对比来自gpt-oss-120b：同样48个核心家族，它在Kaggle上约63%，在集群上却高达98%。检查保存的输出发现，托管答案在词语中途被截断。在31个托管答案完整的家族上，两个平台都通过了30个。

结构化任务还暴露了更微妙的问题：14个托管响应缺少JSON结尾的大括号，备用解析器虽能读出最终决策，却无法恢复代码所需的结构化事实。这使得严格要求JSON有效性时，代码与模型对比的符号发生了翻转。此外，Gemini 3.7 Flash在充分性任务中对169个返回项全部回答正确，但23次调用在三次尝试后仍无结果——若将其计为失败，通过家族数就从满分降至48中的28个。

作者由此得出一个关键的方法论洞见：下一个基准应从一开始就把“成功交付、有效输出格式、正确决策”三者分开报告。

对AI招聘的现实启示

FairScreen最有价值的地方，不在于给出哪个模型最好的排名，而在于揭示了稳定的答案背后可能隐藏着多少种不同的失败：被误用的要求、不完整的提取、一个配置选择、或者解析器无法读取的输出。作者原本以为身份偏见会是主线，结果发现这些“看不见的工程细节”才是真正左右决策的因素。

作者也诚实地列出了研究的边界：申请为合成的英文文本，来自单一地区和少量策略；多个强模型已逼近核心天花板（Gemini 3.7 Flash和Gemma 4通过全部48个托管核心家族）；一个词袋基线能通过约41%的核心集，说明部分案例存在词汇层面的捷径。这些结果针对的是明确的资格规则，而非真实招聘中的稀缺排序。

对于任何考虑用LLM做简历筛选的企业而言，这项研究的结论直截了当：不要相信模型的名气或一句公平性指令，去评估你实际部署的那套筛选配置。可运行的代码策略配合可靠的事实提取，可能比让模型“自由发挥”更值得信赖。项目代码采用MIT许可、数据采用CC BY 4.0，可在Kaggle、GitHub及交互式浏览器中查看全部2528个变体的保存结果。

背景补充

输出截断问题在使用托管API时尤为常见。大多数LLM服务提供商对单次响应设有最大token限制，当生成内容超出限制时，输出会在中途被硬性截断，而非优雅地给出一个完整但较短的回答。对于需要解析JSON或提取特定字段的下游任务，一个缺少结尾括号的响应可能使整条记录变得不可用。这在基准测试中会产生系统性偏差：能力强的模型倾向于生成更详尽的推理过程，反而更容易触达token上限并被截断，导致其在需要完整输出的任务上得分虚低；而输出简短的模型则更容易保全格式完整性。这也是为什么FairScreen作者建议将"成功交付""有效格式""正确决策"三者分开报告——许多基准测试混淆了这三种失败，使得外部读者无法判断低分究竟源于模型推理能力不足，还是部署环境的工程问题。