LoHoSearch的评测标准是什么？

LoHoSearch的评测标准，核心不是看它是否有搜索框或响应速度快，而是看“结果是否准、排序是否合理、用户能否控制与验证”。如果直接按单一评分下结论，容易忽略业务场景差异。建议先圈定使用场景，例如检索对象是文档、网页、还是内部知识库，再按相关性、排序质量、覆盖度、可解释性和权限边界五个维度分别验证。

先从使用场景圈定评测边界

不同的使用场景，评测侧重完全不同。文档检索重点看召回和语义改写能力；网页搜索重点看时效性与去重；知识库问答重点看答案是否能溯源到原文。操作动作：先确定一个核心查询类型，比如“技术文档中的故障排查”，再准备30-50条与LoHoSearch返回结果可人工判断的查询样本。验证方式：每条查询记录返回前5条结果，标注“有用/部分有用/无关”三档。不要把评测范围拉得过大，否则后续定位问题会很困难。

五个可直接执行的核心维度

相关性：结果是否回答查询意图。测试时使用同义替换，例如“如何重置密码”写成“忘记密码怎么办”，观察排名是否明显漂移。
排序质量：前三位是否明显优于第七八位。建议记录每条查询的top3命中率，而不是只看总命中数。
覆盖度：不同语料来源是否都能被检索到。建议在测试集中加入文件名、正文、图片OCR文本三类资源，验证LoHoSearch是否均匀覆盖。
可解释性：结果中是否给出匹配片段或来源链接。若只返回标题，用户难以确认结果可信度。
权限边界：普通用户是否能通过查询访问未授权内容。建议用两组权限不同的账号执行同一查询，比较结果差异。

每个维度都必须有验证动作，不能只看演示屏录。例如相关性测试，可以先在LoHoSearch后台导入一份包含旧文档和新文档的测试语料，再查询一个在新文档中被修改过的功能名，看结果是否优先展示新文档。如果旧文档排在前面，说明时效性权重需要调整。

一张可直接复制的评测判断表

下表适合作为评审时的记录底稿。左侧为维度，中间为测试动作，右侧为通过的保守标准，不设具体分数。

相关性：动作：10条同义改写查询，观察top5变化；标准：至少8条结果与原查询不矛盾。
排序：动作：记录每个查询第一页结果；标准：人工标为“无关”的结果不连续出现两次以上。
覆盖度：动作：查询分别命中标题、正文、OCR文本样本；标准：三类样本都能被检索到。
可解释性：动作：查看结果页是否展示匹配关键词；标准：每条结果至少有一个可点击的来源或片段。
权限：动作：用低权限账号查询高权限文档关键词；标准：结果中不出现受保护内容。

这里的“保守标准”不是标准答案，执行时应结合业务对准确率和召回率的实际容忍度调整。如果某些维度当前无法验证，应记录为“待基础设施补齐后再评”，而不是用主观感觉代替。

用小型测试集生成评测样本

如果手头没有现成查询，可以先构造一个包含三列的JSON测试集：查询、预期行为、参考语料路径。LoHoSearch如果支持API，可以直接调用接口批量获取结果；如果不支持，则人工执行查询并填写结果。

{
  "queries": [
    {
      "id": "q_001",
      "query": "如何排查服务启动失败",
      "expected_behavior": "返回日志分析、依赖检查、端口冲突相关文档",
      "corpus_path": "docs/ops/troubleshooting/startup_failure.md"
    },
    {
      "id": "q_002",
      "query": "重置密码",
      "expected_behavior": "返回账户管理、安全设置、忘记密码流程",
      "corpus_path": "docs/user/account/password_reset.md"
    }
  ]
}

如果LoHoSearch提供了搜索API，可以使用类似这样的请求骨架获取结果，并将每条查询的返回内容与expected_behavior对比。注意请求地址和参数名应替换为环境中实际存在的配置，这里的骨架只用于梳理调用流程。

curl -X POST https://your-loohosearch-endpoint/api/query \
  -H "Content-Type: application/json" \
  -d '{
    "query": "如何排查服务启动失败",
    "top_k": 5
  }'

执行后记录返回的documents列表，检查是否包含corpus_path对应的文件。如果结果中完全没有预期文档，需要确认是LoHoSearch没有索引对应语料，还是查询词与文档语义距离过大。

边界与常见误区

评测LoHoSearch时，最容易出现三种误判。第一种，用A/B测试掩盖样本量不足；建议每条查询先人工打完标签，再谈排序算法优劣。第二种，把“没有返回结果”全部归因于搜索引擎；应先用一个明确存在的文件名搜索，确认索引是否完整。第三种，只看总准确率，忽略权限与合规要求；搜索工具的比对结论不能脱离安全边界。最后需要提醒：任何评测标准都应先在一个封闭测试集上跑通，再扩展到真实流量。如果业务上线后发现查询模式与测试集差异很大，应回归到评测维度表，而不是直接调大某个权重。

下一步判断顺序

确定LoHoSearch的接入类型：自建索引、API调用、还是插件。
建立30条真实业务查询，人工标注预期结果。
按上表的五个维度逐项执行，记录无法验证的项目。
对“可解释性”或“权限”等不满足的项，优先联系实施方确认配置调整方向。

这样完成一轮评测后，得到的不是“LoHoSearch好不好”的结论，而是一张可追溯的检查记录，便于后续对比调整。