搜索算法项目在面试里经常被问到相关性。候选人容易直接讲向量召回、排序模型、点击率提升，但面试官更关心一个具体问题：用户输入一个查询词后，系统怎么理解它，怎么找到候选结果，怎么判断排在前面的内容真的相关。
搜索和推荐不同。推荐可以根据用户画像主动分发，搜索则更依赖用户当下表达的意图。查询词短、含糊、拼写不规范、存在同义词，都会影响效果。
查询理解是第一步
搜索项目不要从模型开始讲，可以先讲查询理解。比如用户搜索“java 面试”，可能想看题目、经验、教程或岗位要求；搜索“苹果”，可能是水果也可能是公司。系统需要处理分词、同义词、纠错、意图识别和类目判断。
如果没有复杂模型，也可以讲规则和词典。真实项目里，很多有效改进来自对高频查询的分析，而不是一开始就上复杂模型。
召回要兼顾覆盖和准确
搜索召回要把可能相关的结果找出来。可以用关键词匹配、倒排索引、标签匹配、向量语义召回等方式。关键词匹配精准但可能漏掉表达不同的内容，语义召回覆盖更广但可能带来噪声。
面试里可以说多路召回后再合并去重，并记录每一路的命中情况。这样当结果不好时，能判断是召回阶段没找到，还是排序阶段排错了。
排序评估不能只看点击
搜索排序常看点击，但点击不等于满意。标题党也可能点击高，但用户很快退出。更稳的评估要结合点击、停留、转化、跳出、人工标注相关性和坏例反馈。对于核心查询，还可以维护一批人工评估集，定期看前几条结果是否满足用户意图。
如果面试官问“模型分数提升但线上一般”，可以从标注口径、训练样本偏差、点击噪声、热门内容挤压长尾、查询类型差异等角度分析。
坏例分析最能体现真实经验
搜索项目一定要准备坏例。比如同义词没覆盖导致搜不到，分词错误导致召回偏了，热门内容因为点击多长期压住新内容，短查询意图模糊导致排序不稳定。讲坏例时要补改进方向：加词典、改召回策略、分查询类型排序、引入人工标注或规则兜底。
可以这样表达：我会把搜索问题拆成查询理解、召回和排序三层排查。先看用户查询有没有被正确解析，再看候选结果是否覆盖，再看排序是否把相关结果放前面。评估时不只看点击，还会看人工相关性、停留和坏例。这样的回答比单纯说“用了语义模型”更有工程价值。
相关性问题的分层判断
搜索相关性不是一个模型就能解决。用户查询可能被理解错，召回可能漏掉结果，排序可能偏向点击诱饵，评估可能被历史位置偏差影响。面试时把链路拆开，答案会更稳。
查询理解：典型问题是同义词、错别字、意图不清，改进方向是纠错、改写、意图识别，评估方式是查询级坏例集。召回：典型问题是正确结果没进候选，改进方向是多路召回和召回融合，评估方式是召回覆盖率。
- 排序：典型问题是相关但质量差的结果排前，改进方向是增加质量、时效、业务特征，评估方式是人工评审和排序指标。
- 线上反馈：典型问题是点击高不等于满意，改进方向是结合停留、转化、负反馈，评估方式是分场景观察。
这篇文章可以提醒读者：搜索题不要只讲点击率。点击率可能被标题党影响，也可能受位置影响。相关性要和用户任务完成联系起来。