垂直领域搜索评测的调整，实际上是在问一件事：LoHoSearch返回的结果中，哪一类错误最影响当前领域的可用性。搜索服务通常要经过查询解析、召回、重排、过滤几个环节，垂直场景的评测失败大多集中在三个位置：期望结果没有被召回、被召回但排序位置不理想、领域噪声和过期内容没有过滤干净。调整策略的第一步不是调参，而是把评测集和基线固定下来，让错误类型可以被归因，再决定动哪一个环节。

垂直搜索评测调整要先有固定评测集和基线。建议准备50-100条领域查询，记录期望结果和噪声结果；先跑LoHoSearch默认配置做基线，再按漏召回、排序偏差、过滤噪声三类问题归因。每个调整周期只改一个变量，调整前后用同一评测集对比；基线快照和配置回滚是调整有效的前提。

先建立垂直评测集与基线

垂直搜索评测与通用搜索评测的差别在标注设定。通用搜索关注点击和整体满意度，垂直搜索要绑定领域规则：商品库看型号与规格是否匹配，文献库看期刊范围与年份要求，法规库看版本与时效。建议按业务场景准备50-100条典型查询，为每条查询标注期望结果集合与禁止出现的噪声结果集合，再让LoHoSearch按默认配置跑一遍，记录基线输出。

评测记录可以先按一行一条的JSON保存。格式只是示例，不需要固定成LoHoSearch的接口格式：

{"query": "检索增强生成 综述 最新", "expected": ["doc-101", "doc-234"], "noise": [], "note": "期望覆盖近两年的综述"}<br/>{"query": "检索增强 综述", "expected": ["doc-101"], "noise": ["doc-345"], "note": "验证同义词扩展是否有效"}

注意expected和noise必须是文档ID，不能只填一句主观判断。这样后面跑完LoHoSearch评测集，能自动对照漏召回和误召回。评测集文件需要纳入版本管理，调整参数前先备份基线结果。

按评测维度归因，定位问题层级

评测结果出来以后，先分类，再定位到具体模块。可以按下面的维度记录观察点：

在这张表里，每类观察点都可以指出不同的调整方向。比如多组查询都出现期望结果缺失，说明问题出在召回；期望结果都在候选集里但排不在前面，说明要动排序；噪声结果较多，则需要收紧过滤规则。如果查询本身就被拆错词，例如把“NLP”拆成“N L P”，那么调排序或过滤都没有意义，需要先修正查询解析。

调整动作设计：先召回，后排序，再过滤

归因完成后，按固定顺序尝试调整。一个周期内只改动一个变量，改动后重跑同一评测集对比基线。

• 漏召回集中出现时，先放宽召回候选数或扩展同义词范围。验证方式：重新运行评测集，看期望结果是否进入候选集合；同时观察新增候选是否引入噪声。
• 召回没问题但期望结果排位靠后时，再调整排序特征权重。一次只调一个权重，例如提高垂直字段匹配权重，或者提高标题匹配权重。重跑典型查询，看目标结果的排序位置是否整体前移。
• 噪声、过期或越权结果出现在前列时，再添加过滤规则。每加一条过滤规则之前，先用当前评测集跑一遍，确认被过滤对象都是预期要过滤的样本；同时保留过滤规则的总开关，方便出现误杀时快速回滚。

适用场景边界：如果是冷启动阶段，还没有用户行为数据，排序权重建议先根据领域规则手工设定；如果已经积累了可标注的查询日志，再考虑用评测集反推权重。不要拿线上查询日志直接当评测结论，因为没有标注期望结果，无法区分排序偏差和用户偏好。

回归验证与回滚边界

每调整一个变量，需要做一次回归验证。回归时使用与基线相同的测评集、相同的运行环境，比较待测版本与基线的差异。验证清单通常包括：

• 查询集和期望结果集合是否与基线版本一致；
• 本次调整是否只改动了一个配置变量；
• 期望结果是否进入候选集，并到达目标排序位置；
• 噪声结果是否被过滤掉或压到后面；
• 原本表现良好的查询是否发生回退；
• 是否有基线配置快照可以直接回滚。

常见误区是同时放宽召回候选数、调整多个排序特征权重、并新增一批过滤词表，结果评测集确实变好，但无法确定是哪个动作起的作用。还有一类误区是：用自己的历史查询日志补充评测集，却不对日志做标注，这会让回归结果失去判断基准。

垂直搜索评测的调整是一个持续维护过程。评测集需要随着业务变化补充新查询、删除过时结果；LoHoSearch的具体配置项、评测接口和是否支持配置快照，需要结合当前部署环境确认。没有固定评测基线和回滚手段的情况下，不建议直接在生产环境反复尝试。