LoHoSearch 的人工评估与自动评估衔接，通常按“自动评估筛选，人工评估仲裁”的方式组织，而不是把两套评分做加权合并。自动评估先对查询和候选文档输出可审计的分数与命中原因；只有分数落在不明确区间或评估输出异常时，才进入人工复核流程。人工复核的结论不直接改自动评分，而是用于判断自动评估的规则、阈值和标注是否仍然可信。
为什么不是两套评分互相平均
自动评估可以反复执行，分数一致，适合覆盖全量查询；缺点是只能判断可以被明确编码的关系，比如文档是否包含某个实体、是否命中查询里的限定词。人工评估能识别用户的真实意图与结果是否解决了查询背后的任务，但人工评估成本高，不同人对相关性的感受也不同。LoHoSearch 的做法是把可编码部分交给自动评估，把“是否真的对用户有用”这类问题留给人工复核，并且要求两套评估先独立完成再对比分歧，这样才能互相校准。
什么时候切入人工复核
需要人工介入的条件不一定是自动分数低，而是“自动评估结果不能被确证”的状态。下面这张表可以用于定位自己项目的衔接触发条件：
| 自动评估状态 | 衔接动作 | 验证方式 | 风险边界 |
|---|---|---|---|
| 输出正常且命中明确的验证规则 | 直接通过，不需要即时人工复核 | 定期抽取少量通过样本，确认命中理由与实际内容一致 | 长期不抽查会让“通过”变成默认值，掩盖标签失效 |
| 输出正常但分数落在中段区间 | 进入人工复核队列，人工先独立评分再对比自动评分 | 核对人工分与自动分是否一致，不一致时要能落到原因字段 | 中段区间划分过宽会让人工队列积压，过窄会漏掉值得复核的样本 |
| 输出异常：无评分、超时、字段缺失 | 强制人工复核，并同步排查评估任务本身 | 用相同输入重放，确认是数据问题还是规则配置问题 | 不能只补一条人工分后忽略原异常，异常说明评估链路的输入或规则存在缺口 |
表中状态需要结合你的数据准备情况做调整；特别是“中段区间”的上下界，应先根据历史复核分歧分布确定，而不是直接采用某套固定数值。
可落地的衔接样例
下面是一个通用接入骨架，用于把自动评估分流到人工复核，放在评估调度模块里执行：
def route_evaluation(result):
if result is None or "score" not in result:
return "force_human", "missing score"
if result["score"] >= 0.8:
return "pass", "clear pass"
if 0.4 <= result["score"] < 0.8:
return "sample", "needs human review"
return "human_review", "low score"0.8 和 0.4 只是示例阈值，不是推荐参数；需要先收集一批历史评估结果，观察分数分布与人工复核结论的关系，再确定适合你场景的分流区间。
人工复核阶段建议使用固定提示词，让复核人员先独立判断，再查看自动评估原因。提示词放在复核工作台的指令区：
请先阅读查询和当前文档，独立给出相关度分数（0 到 5 分），然后查看自动评估的输出，回答以下问题：
1. 自动评估命中的标签是否确实是用户关心的信息？
2. 自动评估没有识别到但影响你判断的语义点是什么？
3. 如果自动评估与实际判断不一致，最适合调整的是标注规则、阈值，还是查询改写？复核完成后，建议保留下面这类记录结构，才方便后续把人工判断与自动输出对齐：
{
"query_id": "query-001",
"doc_id": "doc-001",
"auto_score": 0.62,
"matched_tags": ["brand", "category"],
"route": "sample",
"human_score": null,
"reviewer": null,
"note": ""
}常见的衔接误区与边界
第一，不要直接把人工评估结果当成新标签放回自动评估。人工复核反映的是当前人的判断，不一定代表规则修改方向；建议把复核记录作为分歧分析数据。第二，不要只复核分数偏低的样本。低分样本容易暴露问题，但从不检查直接通过的样本，会让评估规则困在单一口径里。建议定期抽检通过样本，确认通过原因仍然成立。第三，不要把人工作用理解为“校正自动评分”。复核的意义在于发现需要调整的规则和阈值，而不是逐条修正分数。
LoHoSearch 这类衔接流程是否适合你的场景，取决于查询是否已经有可验证的标注基础。如果查询本身没有可编码的 ground truth，不建议一开始就搭建复杂自动评估，可以先建立一小批人工评估基线，从基线中总结可描述的模式，再逐步接入自动评估。