招聘搜索的排序评估，过去基本靠点击率、投递率这类线上指标，再补一部分人工标注。现在很多团队开始尝试另一种思路：让大语言模型当评审，直接对职位搜索结果打分或对比排序，这就是常说的 LLM judge。我最近在搭建一个招聘垂直场景的离线评测流程，把数据构造、prompt 设计、批量调用、指标计算和偏差排查完整跑了一遍，下面把能直接复用的经验拆出来。这篇文章适合做搜索排序、推荐系统或招聘平台算法迭代的人，尤其是需要快速回归排序质量但又缺人工标注资源的团队。
先说结论：LLM judge 不是要替代线上实验，而是补上“离线快速评估”这一环。它能稳定、低成本地给出带理由的相关性判断，但必须先用人工标注小样本校准，才能判断它到底可不可信。
1. 招聘搜索排序评估，LLM judge 最值得关注的价值是什么
1.1 传统评估的三条路，各自卡在哪
做招聘搜索排序，团队通常会从三个方向评估效果：
| 评估方式 | 能反映什么 | 主要问题 |
|---|---|---|
| 线上行为指标 | 点击率、投递率、转化率，业务结果最直接 | 有滞后，受位置、公司知名度、职位新鲜度干扰 |
| 离线指标 | NDCG、MRR、Recall 等，适合快速比较算法版本 | 依赖人工标注的相关性标签，标注成本高 |
| 人工逐条评估 | 判断质量最可靠，能给出原因 | 速度慢、成本高，人数少时一致性难以保证 |
招聘搜索还有一个特殊之处：相关性不只是文本词面匹配。两个人搜同一个“Java 后端”，一个人期望北京、三年经验、薪资 30K，另一个人期望远程、五年经验、薪资 50K，结果应该完全不同。传统离线指标很难把这个“候选人画像”完整吃进去，人工标注又扛不住大规模查询。
1.2 LLM judge 的定位是补充，不是替代
LLM judge 的做法，是把原本由人完成的评估任务交给大模型：给它一段候选人信息、一个查询条件、一组职位结果，让它按规则打分或对比，最后输出一个结构化结论。
这套方案的好处有三个：
- 快。几百条样本十分钟到半小时就能跑完，人工一整天都未必能完成。
- 便宜。相比雇佣标注团队，API 调用费用通常在可接受范围。
- 可解释。让模型输出理由，能反查它为什么给某个职位高分或低分。
但也要明确边界：LLM judge 输出的是“代理评估结果”，不是真实用户行为。它只能回答“这个排序看起来合不合理”，不能回答“用户会不会真的投递”。到了确认上线阶段，还是要回到线上实验看最终指标。
1.3 适用场景和不适合的场景
实际落地时，我建议优先把 LLM judge 用在这么几类任务上：
- 算法版本回归：每次排序模型迭代后，跑一批固定评估集，看排序质量有没有退化。
- 长尾查询：热门查询可能有人工标注，长尾查询没有，可以让 LLM judge 先粗筛一遍。
- 多方案对比：两个 ranker 在同一个查询上的表现差异，用两两对比方式让模型判胜负。
- 人工标注前的预标注：先让模型给一个初判，再让人工复核分歧大的样本。
不适合的场景也要说清楚。如果业务对职位推荐有很强的合规要求，或者判定结果会直接进入自动化决策流程，不能只靠模型输出。LLM judge 适合做辅助，不适合做最终裁决。
2. 开始跑之前，先把输入数据和评分规则定清楚
2.1 三段输入：查询、候选人画像、职位列表
LLM judge 的输入不是简单的“关键词 + 文档列表”，而是三条信息：
- 查询条件：用户搜索时填的关键词、筛选条件，比如“Java 后端 北京 三年以上”。
- 候选人画像：期望城市、期望薪资、工作年限、技能栈、目标职位类型、求职状态。这部分在招聘搜索里尤其重要，没有它，模型只能用文本相关性猜测。
- 职位结果：职位标题、公司、地点、薪资范围、经验要求、技能要求、职位描述，必要时带上发布时间。
我建议把候选人画像放在 prompt 靠前的位置，并且明确告诉模型“相关性是针对这个人，不是泛指某个职位”。否则模型很容易把它当成普通的文本检索题，甚至只凭职位标题长度做判断。
2.2 评判维度：把“相关”拆成可打分的规则
“相关”这个词太模糊，必须拆成可操作维度。招聘场景里我常用的维度如下：
| 维度 | 判定内容 | 容易踩的误区 |
|---|---|---|
| 职位相关性 | 职位职责和目标岗位是否匹配 | 只看标题，忽略职责描述 |
| 技能匹配 | 候选人的主要技能是否在 JD 里出现 | 把加分项当成硬性要求 |
| 薪资匹配 | 期望薪资和职位薪资区间是否有重叠 | 职位没写薪资就随意给高分 |
| 地点匹配 | 期望城市、通勤、远程要求是否满足 | 忽略候选人明确写的远程偏好 |
| 经验与职级 | 年限、职级是否在要求范围附近 | 过于严格的精确匹配 |
评分规则要写成模型能执行的形式。例如：0 分表示“明显不匹配”，1 分表示“部分匹配但存在明显问题”，2 分表示“基本匹配”，3 分表示“完全匹配”。不要用含糊的“好、中、差”。
2.3 人工标注一小批标准答案
这一步很多人会跳过，但恰恰是让整个方案可信的关键。在开始大量调用 LLM judge 之前，先人工标注 100 到 300 个样本，样本可以是“候选人 + 查询 + 职位对”，也可以是“候选人 + 查询 + 两版排序结果”。
这批数据有三个作用：
- 用于调 prompt，看模型输出和人的判断有没有明显冲突。
- 用于计算 LLM judge 与人工标注的一致性，确定它是否靠谱。
- 用于发现模型偏好，比如是不是总给描述长的职位高分。
标注样本时要故意放一些困难样本：候选人要求远程、职位明显在别的城市；候选人技能是 Java，职位标题写“Python 后端”但职责里要求 Java；职位薪资范围明显低于期望。困难样本才能逼出模型的真实判断能力。
2.4 模型选择与运行条件
模型选择会影响效果和成本。如果只是验证流程，先用一个市面上主流的中小模型或性价比模型就够了；如果要正式回归，再考虑换更强模型。
运行条件方面，LLM 不一定要跟搜索服务部署在同一台机器上。接受 OpenAI 兼容接口的远程服务、局域网内服务都能接入；如果本地有显卡，也可以部署开源模型做测试。本地部署时显存和内存需求取决于参数量，通常至少几十 GB 内存，显存 16 GB 以上才能跑得舒服一点。如果机器配置偏低，建议先用 API 方式跑通流程，再考虑本地化。
3. 评测流程搭建：prompt、调用和 JSON 解析
3.1 选点对点打分，还是两两对比
LLM judge 有两种常见形态：
- 点对点打分（pointwise）：给每个职位输出 1 到 5 分。
- 两两对比（pairwise）：给两个职位或两版排序，直接判断谁更好。
在排序评估里我更推荐两两对比。原因很直接：模型在绝对分数上容易漂移，这次给 4 分，下次给 3 分；但在“A 和 B 谁更靠前”这种相对比较上稳定性好很多。如果要对比两个排序算法，就给模型同一份候选人信息和查询条件，把两个算法产出的职位顺序分别标为方案 A、方案 B，让模型判断哪个排序更合理。
3.2 推荐 prompt 结构
一份能稳定工作的 judge prompt，至少包含四部分：
- 角色定义：说明它是招聘搜索排序评估专家。
- 输入信息：候选人画像、查询条件、职位列表或两个排序方案。
- 评分规则：包含维度、分值和约束条件。
- 输出格式：要求输出结构化 JSON，包含结果、理由和得分明细。
下面是一段可参考的结构，实际字段按你自己的业务调整：
系统：你是一名招聘搜索排序评估专家，负责判断职位和候选人的匹配程度。 用户： 候选人信息： {候选人的城市、薪资期望、技能、年限、目标职位} 查询条件：{用户搜索词} 职位 A： {职位 JSON} 职位 B： {职位 JSON} 请根据以下维度判断： 1. 职位职责和候选人目标岗位是否一致。 2. 候选人主要技能是否满足 JD 要求。 3. 薪资期望与职位薪资区间是否匹配。 4. 地点、远程、通勤要求是否匹配。 5. 经验年限和职级是否合适。 只依据上面提供的信息判断，不能编造职位未写明的福利或要求。 输出 JSON 格式，字段为： { "winner": "A" 或 "B" 或 "tie", "reason": "简要理由", "score_a": 0-3, "score_b": 0-3 }这里有一个关键点：必须明确要求模型“只依据输入信息判断”。否则模型很容易用训练知识脑补出某家公司的情况，或者默认“写得多就是好职位”。
3.3 Python 调用示例和 JSON 解析
接口调用没有太复杂的技术，关键是封装好输入和输出。下面是一个通用示例，客户端和参数以你实际使用的服务商为准：
import json from openai import OpenAI client = OpenAI( api_key="your_api_key", base_url="your_service_base_url" # 按服务商文档填写 ) def judge_pair(query, candidate, job_a, job_b, model="your_model_name"): system_prompt = ( "你是一名招聘搜索排序评估专家，" "负责判断职位和候选人的匹配程度。" ) user_prompt = f""" 候选人信息： {json.dumps(candidate, ensure_ascii=False)} 查询条件：{query} 职位 A： {json.dumps(job_a, ensure_ascii=False)} 职位 B： {json.dumps(job_b, ensure_ascii=False)} 请判断职位 A 和职位 B 哪个对这位候选人更合适。 只输出 JSON，不要输出其他内容。 """ resp = client.chat.completions.create( model=model, temperature=0, max_tokens=800, messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt}, ], ) return resp.choices[0].message.content # 调用示例 result_text = judge_pair( "Java 后端 北京 三年以上", {"city": "北京", "salary": "30K-40K", "skills": ["Java", "Spring Boot"], "years": 4}, {"title": "Java 开发工程师", "salary": "25K-35K", "city": "北京", "desc": "..."}, {"title": "Python 后端工程师", "salary": "20K-30K", "city": "上海", "desc": "..."}, ) try: result = json.loads(result_text) except json.JSONDecodeError: # 部分模型会输出 Markdown 代码块，需要先清理 cleaned = result_text.strip().removeprefix("```json").removesuffix("```") result = json.loads(cleaned) print(result)解析 JSON 时经常踩两个坑：模型在 JSON 前后追加解释文字，或者把 JSON 包在代码块里。稳妥做法是先把返回内容清理掉代码块标记，再解析；如果解析失败，记录原始文本，不要直接丢弃。
3.4 参数设置：温度、max_tokens、seed
LLM judge 要尽量可复现，参数要收敛。
- temperature 设 0 或接近 0。temperature 越高，判分越不稳定，同一个样本跑两次可能结论不同。
- max_tokens 给够。判断理由和 JSON 输出需要一定长度，建议 500 到 1000，太少会被截断。
- 如果服务商支持参数 seed 或 response_format 设为 json_object，可以一并开启。response_format 能减少解析失败比例。
- 每改一次 prompt，都要把 prompt 版本号记录下来。后续发现结果异常时，能回查到是哪一版 prompt、哪个模型、哪批数据产生的。
4. 结果怎么算，才不算白跑
4.1 胜率和同序率
最常用的指标是两两对比的胜率。假如要对比排序算法 A 和 B，每个样本都让 judge 从 A 结果和 B 结果中选一个更合理的排序，最后统计：
胜率 = A 获胜的样本数 / 总样本数平局样本要单独统计。如果平局率超过 20%，说明两个算法差异不明显，或者 judge 区分力不足。不要简单把平局算到某一方头上，这会掩盖问题。
除了胜率，还要看“同序率”，也就是 judge 的判断和某个基准排序一致的样本比例。这个基准可以是人工标注，也可以是线上点击数据。
4.2 与人工标注的一致性
判断 LLM judge 可不可信，不能只看它自己说的，要对齐到人工标注上。
先用前面标注好的 100 到 300 个样本，跑一遍 judge，计算“模型和人工都判断正确”的样本比例。更严谨一点，可以算 Cohen's kappa：
- 一致性超过 0.6，结果基本可用。
- 0.4 到 0.6，可以用于粗筛，但需要人工复核分歧部分。
- 低于 0.4，说明 prompt 或维度定义有问题，不要急着批量跑。
如果一致性不达标，优先检查评分规则是否含糊，而不是加更多解释。很多 prompt 问题不是模型能力不够，而是规则让模型没法稳定输出。
4.3 judge 自身稳定性检查
LLM judge 还会出现“自己和自己不一致”的情况。同一份输入，连续跑 20 次，如果结果在不同方案之间反复横跳，说明稳定性不够。
我一般这样做：取 30 条有代表性的样本，每个样本跑 3 次，取多数票作为最终结果，同时记录“三次结果不一致”的样本比例。这个比例最好不要超过 10%。超过的话，要么降低温度，要么给每个样本多投几次票，要么换更强模型。
4.4 耗时和成本估算
正式跑批量之前，先估算 token 消耗。
每条样本的 token 主要花在候选人画像和职位描述上。职位描述越长，成本越高。可以先用几条样本估算单次调用 token，再乘上总样本数。如果预算紧张，可以考虑：
- 把职位描述截断到前 500 字左右。大多数场景下，头部信息已经足够判断相关性。
- 先让便宜模型过滤掉明显不相关的职位，再让更强模型做精细对比。
- 控制每次调用只对比两个职位，不要一次塞 10 个职位，否则容易超出上下文窗口，结果也不稳定。
5. 最容易翻车的四个坑
5.1 位置偏差：换个顺序结论就变
LLM judge 非常容易受输入顺序影响。同一个职位 A 放在前面和放在后面，胜率可能差出一大截。
规避方法是随机化顺序。每次调用都随机交换 A、B 的位置，记录时再映射回真实方案。如果交换顺序后，有一批样本的结论跟着翻转，说明 judge 的位置偏好很强。位置偏差严重时，不要直接用单次结果，要多次投票。
5.2 描述长度偏差：越长越容易高分
模型倾向给描述更长的职位打高分，因为它看起来“更正规”。这在招聘场景里很常见：某些公司 JD 写得非常长，但候选人的核心技能其实只在里面出现一次。
处理办法有两个：
- 在 prompt 里明确“职位描述长度不影响分数”。
- 对职位描述做截断，让两个选项的文本长度接近。
更彻底的做法是把职位文本转成结构化字段：标题、地点、薪资、技能要求、经验要求、职责摘要，再让模型基于结构判断，而不是让它读一整段原文。
5.3 模型自偏好和多票不一致
如果你要评估的是“由某个模型生成的排序理由”或“由某个模型生成的职位摘要”，judge 很容易偏心同一家模型产出的内容。招聘场景里比较少见，但只要排序结果附带生成文本，就要提防。
规避方法：
- 评估时把生成内容的来源标成 A、B 匿名方案，不要暴露模型名。
- 用不同公司或不同系列的大模型当 judge。比如生成侧用甲模型，判断侧用乙模型。
- 对分歧样本做人工复核，不要自动采信。
5.4 prompt 改一个词，结果差一截
judge 评估里最大的不稳定因素，是 prompt 本身。可能只是把“匹配”改成“合适”，结论就会变。
所以每次调 prompt 都要在固定人工标注集上做对比，不能只靠感觉。我的做法是：先定义“这一版 prompt 相比上一版，在哪些维度上有改进”，再在同一批样本上跑完对比，看一致性和胜率变化。没有数据支撑的 prompt 改动，建议直接排除。
6. 从小样本到批量评估，建议按这个顺序推进
6.1 第一批：20 条，只看日志和格式
不要一上来就跑几百条。先取 20 条样本，目的只有一个：确认整个链路能通。
这一批要检查的内容包括：
- API 调用是否成功，鉴权是否正常。
- 返回内容能否稳定解析成 JSON。
- 输出字段是否完整，winner、reason、score 都不缺。
- 每条样本的耗时和 token 消耗是否有明显异常。
这一阶段发现问题不要急着调 prompt，先解决输入格式、路径、编码、接口参数这些基础设施问题。很多批量任务卡住，不是模型问题，而是文件路径写错、输入字段缺失、JSON 里混进了非法字符。
6.2 第二批：200 条，看指标和偏差
链路跑通后，扩大到 200 条左右。这时重点看三类结果：
- 胜率和同序率是否符合预期。
- judge 与人工标注的一致性是否达标。
- 有没有明显的位置偏差、长文本偏差、薪资缺失导致的误判。
这一批结果决定要不要继续跑到全量。如果一致性不达标，停下来先调 prompt 和输入构造。拿 200 条结果反推 prompt，成本低，结论也足够明显。
建议把每个样本的原始返回都存下来，不要只存解析后的字段。后面排查问题时，原始文本能告诉我们模型到底给了什么理由，解析失败也能看到是哪一步出的错。
6.3 批量跑：JSONL、重试、并发、命名
全量评估时，推荐使用 JSONL 作为输入输出格式。每一行是一个独立样本，便于断点续跑，也便于按行检查失败原因。
输入文件示例：
{"sample_id": "sample_001", "query": "Java 后端 北京", "candidate": {...}, "job_a": {...}, "job_b": {...}} {"sample_id": "sample_002", "query": "产品经理 远程", "candidate": {...}, "job_a": {...}, "job_b": {...}}处理时建议按 sample_id 把结果写回新文件，遇到解析失败或接口报错的样本，单独记录到一个错误列表，重跑时只补这些样本。
批量任务还要注意几点：
- 并发不要拉满。先用 4 到 8 个线程试跑，观察服务商限流情况。
- 必须有重试机制。推荐指数退避，例如失败后等 1 秒、5 秒、15 秒再试。
- 输出文件要包含 prompt_version、模型名、temperature、seed，保证可追踪。
- 控制单个样本的 token，避免因上下文过长导致输出质量下降或直接报错。
# 批量处理伪代码，实际以你的文件路径为准 import json with open("eval_samples.jsonl", "r", encoding="utf-8") as fin: lines = [json.loads(line) for line in fin if line.strip()] results = [] failed = [] for item in lines: try: text = judge_pair( item["query"], item["candidate"], item["job_a"], item["job_b"] ) results.append({"sample_id": item["sample_id"], "raw": text}) except Exception as exc: failed.append({"sample_id": item["sample_id"], "error": str(exc)}) with open("judge_results.jsonl", "w", encoding="utf-8") as fout: for res in results: fout.write(json.dumps(res, ensure_ascii=False) + "\n") with open("judge_failed.jsonl", "w", encoding="utf-8") as ferr: for item in failed: ferr.write(json.dumps(item, ensure_ascii=False) + "\n")失败样本不要直接丢弃，先看失败原因。大部分失败集中在几种情况：超时、限流、JSON 解析失败、输入字段缺失。按原因分批处理，比抓着一个样本反复重试有效。
7. 落到生产环境前，别忘了这三件事
7.1 先建立可追踪的评估集
LLM judge 方案能不能长期用，取决于评估集是否稳定。我建议把样本集、prompt 版本、模型版本、结果文件都放到同一个目录或仓库里，每次跑都生成一个记录。一个月后再跑，才能知道算法是变好了还是变差了。
如果不记录版本，第一次跑出 60% 胜率，一个月后跑出 55%，你根本不知道是算法退化了，还是 judge 变了，还是样本集被改动了。
7.2 定期和人工校准，别让误差越积越大
LLM judge 不能永远只和自己比较。每过一段时间，抽一部分新样本让真人标注，和 judge 结果做一次对齐。模型换代、业务重点变化、职位数据结构变化，都可能影响 judge 的表现。
校准频率不需要太高，半个月到一个月一次就够。校准的目的不是彻底替代模型，而是确认误差还在可控范围。
7.3 最终判断还是要看线上真实行为
离线评估做得再好，也只是“看起来靠谱”。用户是不是真的愿意点击、投递、接受推荐，只有线上实验能给出答案。
我建议把 LLM judge 当成一个快速筛选器：它负责在离线阶段过滤掉大概率退化的方案，把有潜力的方案留到线上小流量验证。这样既节省了重复上线的时间，又不会因为模型误判而错过真正有效的改进。踩过几次之后我发现，很多排序评估问题不是工具能力不够，而是前置数据、评分规则和版本记录没有处理干净。把这几点做扎实，LLM judge 能成为招聘搜索排序迭代里相当顺手的一件工具。
