HackerRank 开源了它的 ATS。我的简历得分 90/100。哦等等 74。不是——88

工具的范围与用途

• 这个开源系统并不是生产环境中使用的完整 ATS；它是为了给数以万计的实习生简历排序，让人类知道先读哪些。
• 演示配置使用的是一个很小的本地模型（gemma3 4B，temp 0.1）；据称实际内部使用的是更大的 Gemini 模型和非常低的截断阈值，只有最底部那一小部分会被自动丢弃。

LLM 的非确定性与评分波动

• 多个人在同一份简历上、跨不同运行和模型时，复现出巨大的分数波动（例如 48–99/100）。
• 一个很长的子线程讨论了温度 0 或 0.1 是否应当是确定性的，涉及 softmax、浮点非确定性、批处理、PRNG 种子、GPU 与 CPU 以及 TPU。
• 共识是：你可以把推理工程到接近确定性，但大多数云环境并没有这样做，而确定性也无法修复根本上薄弱的评估标准。

评分细则设计与内嵌偏见

• 评分非常偏向开源（35 分）和个人项目（30 分），而工作经验只有 25 分。
• 许多人认为这会系统性地惩罚：有家庭或非编程爱好的人、在初创公司工作且“额外工作”不公开的人、年纪更大或自学成才的工程师，以及那些不活跃于 GitHub 的人。
• 有些人认为这是在筛选“内在动机强”或带有强迫倾向的编码者；另一些人则认为这是在筛选过度工作和特权。

AI 筛选的有效性、合法性与公平性

• 招聘经理描述了压倒性的申请量，并认为任何能把大约 30–35% 的人推进下一步的自动过滤器，都比只靠人工初筛更好。
• 批评者则反驳说，一个并不比随机更好的过滤器，只是在更早阶段丢掉了合格候选人，而随机化本可以用更便宜、更透明的方式实现。
• 还有人担心，黑箱式 LLM 评分可能带来违法歧视（欧盟 GDPR 第 22 条、美国平等就业法律），尤其因为姓名、学校和地理位置等输入即使在提示词里说“不要使用”，也会与受保护群体相关联。

对提示词 / 系统设计的批评

• 主要提示词把许多子任务（OSS、项目复杂度、技能）捆绑成一步，使用模糊的 0–35 分区间和大量形容词（“significant”“substantial”），把艰难的判断压给模型。
• 建议包括：把任务拆得更小、使用加法式或分类式评分细则、把分数与明确证据关联、在提示前去除敏感字段，以及依赖结构化输出。
• 有人指出幻觉问题（例如给 CV 中并不存在的 Google Summer of Code 分数）。

对招聘的更广泛反思

• 许多人认为，基于简历和 ATS 的招聘本来就已经很武断；LLM 只是放大了不透明性，并奖励关键词堆砌和 AI 生成的简历。
• 讨论中的替代方案包括：工作样本测试、限制数量或限制时长的申请、在最低合格候选人中随机抽签，或者基于书面问卷而不是简历来筛选。