LoHoSearch 这类搜索诊断框架，核心用途不是给搜索智能体打分，而是把一条完整的搜索链路拆成“用户需求表达、查询改写、检索召回、答案生成与引用”几个环节，分别观察哪一步先断。你真正要做的，不是跑一遍它自带的样例，而是拿着它提供的任务格式，去构造贴近业务场景的测试集，再对比中间结果。
用 LoHoSearch 识别短板，重点是看三类断层：用户意图与改写后查询是否一致、检索结果是否覆盖答案要素、生成内容是否忠实于检索证据。建议把 LoHoSearch 的测试任务当作“可控探针”，每次只改一个变量，记录检索中间结果与最终回答，再结合业务环境确认短板来自哪一层。
LoHoSearch 能暴露哪几类短板
LoHoSearch 的任务设计通常带有明确的信息需求，比直接给一句大模型提示词更难。它能有效暴露搜索智能体在以下三类场景中的问题：
- 意图识别偏差：用户原始需求是“给我推荐适合代码审查的 IDE 插件”，改写后的查询却是“IDE 插件代码审查”，导致召回结果偏向通用技术文章，而缺少按使用场景筛选的内容。
- 多跳检索断裂：问题包含多个约束条件，比如“2025 年之后发布的、支持 arm64 的本地翻译模型”。如果查询改写只保留“本地翻译模型”，第二个约束就会被丢弃，最终答案引用缺失。
- 引用与生成脱节：检索结果已经给出了明确答案，但生成阶段仍补充了检索结果之外的细节，或者把多篇来源的内容混在一起却不标出具体对应关系。
大多数搜索智能体的问题集中在这三层。你先按照这三类去记录，比单纯看最终答案有没有答对要有效得多。
构造测试用例的三种提示词版本
不要直接用 LoHoSearch 自带的原始问题清单。你需要复制其任务格式，额外加一层“用户需求背景”，让搜索智能体在不明确的情况下也能理解上下文。下面给出三个可复制的提示词版本，分别用于检测不同短板。
版本 A：多跳事实型问题，适合检测检索召回是否覆盖多个实体关系。
你是一位搜索需求分析师。请基于以下用户描述，生成一个必须经过多跳检索才能回答的问题。要求：需要综合两篇以上来源，并且答案中包含一个具体的属性值，例如时间、地点或数量。
用户描述：我正在选一台用于本地运行的代码补全模型，要求支持 ARM 架构，并且能在 8GB 内存下通过量化方式运行。
生成问题：版本 B：对比倾向型问题，适合检测意图识别是否保留比较方向。
请生成一个需要对比两个实体优缺点的搜索任务。用户没有明确说要对比，但最终答案必须体现二者取舍。生成问题时，强调“哪个更值得用”而不是“列出资料”。
用户描述：我想把团队内部的搜索 docs 工具迁到新方案，不想用 Elasticsearch，但同事说新方案不成熟。
生成问题：版本 C：时间敏感型问题，适合检测搜索智能体是否区分事实时效性。
请生成一个答案随发布时间变化很大的搜索任务。要求搜索智能体必须识别时间状语，并在回答中主动标注信息截至日期。
用户描述：今年想部署一套开源日志系统，需要支持多租户，不要那种两年前还主流的方案。
生成问题：每个版本生成 5-10 个变体，替换实体词和约束条件，再输入到你的搜索智能体中运行。这样能得到能定位短板差异的对照结果。
运行后要记录的验证清单
运行 LoHoSearch 任务时，不能只记录最终回答。你至少要为每个测试用例留出下面这些字段，否则无法判断短板到底在哪一层。
- 原始用户问题：保留用户完整描述，不要只写改写后的查询。
- 改写后的查询词：如果智能体支持查看中间查询，记录它实际发出去的检索请求。
- 检索结果数量与来源类型：记录返回了 5 条还是 20 条，其中官方文档、技术博客、论坛分别有多少。
- 答案要素覆盖度：用列表确认预期答案中的必要要素是否都出现在最终回答里。
- 引用可回查性：点击引用序号能否回到对应来源段落，是否出现张冠李戴。
- 时间一致性：如果问题有时间要求，回答是否明确说明“截至某时间”。
这里有一个可用的记录表头，可以直接复制到表格里维护。
| 用例ID | 原始问题 | 改写查询 | 结果数量 | 关键要素是否缺失 | 引用是否可回查 | 短板初步判断 |建议每个用例跑两遍：一遍直接输入原始问题，一遍先手动改写为更精确的查询。两次结果差异大，说明查询改写环节不稳定；差异不大但答案仍不对，说明问题可能在召回或生成阶段。
区分短板来自检索还是生成
LoHoSearch 的价值在于能让你把中间结果单独拿出来做对比。当最终答案不理想时，做下面这个简单的对照实验：把 LoHoSearch 返回的检索结果直接喂给一个不在线搜索的大模型，让它只依据给定片段回答。如果这个离线模型能答对，说明你的搜索智能体问题在生成侧，可能是提示词或上下文拼接方式不对。如果离线模型也答不对，那就是检索结果本身缺信息，问题在查询改写或召回。
还有一种做法是把人工精选的几段高质量内容替换掉检索结果，再走一遍完整生成流程。如果这样能答对，那基本可以认定短板在检索环节，而不是生成模型的能力问题。这个实验不需要改代码，只需要找到你的智能体配置中控制“检索结果注入”的部分。
注意边界，避免误判
LoHoSearch 的任务集通常覆盖的是通用型信息需求，它不能代表你的真实用户提问习惯。所以识别出来的短板，只能说明“在该类任务上容易失效”，不能直接推广为“生产环境性能差”。需要结合你的业务样例做二次验证。
另一个常见误区是只看最终答案的文本相似度。LoHoSearch 的任务里，即使答案字面上接近，如果引用的来源无法支撑，仍然说明数字或事实存在风险。你应该把“引用可回查”作为一票否决项，而不是只计算答案匹配度。
最后，不要试图通过调整 LoHoSearch 的评分阈值来掩盖短板。它作为一个诊断工具，能够给出的只是行为快照；你真正要利用的是那些不稳定的、边缘化的用例，这些才是搜索智能体后续改进的起点。