搜索算法面试怎么讲相关性：从用户查询到排序评估

搜索算法项目在面试里经常被问到相关性。候选人容易直接讲向量召回、排序模型、点击率提升，但面试官更关心一个具体问题：用户输入一个查询词后，系统怎么理解它，怎么找到候选结果，怎么判断排在前面的内容真的相关。

搜索和推荐不同。推荐可以根据用户画像主动分发，搜索则更依赖用户当下表达的意图。查询词短、含糊、拼写不规范、存在同义词，都会影响效果。

查询理解是第一步

搜索项目不要从模型开始讲，可以先讲查询理解。比如用户搜索“java 面试”，可能想看题目、经验、教程或岗位要求；搜索“苹果”，可能是水果也可能是公司。系统需要处理分词、同义词、纠错、意图识别和类目判断。

如果没有复杂模型，也可以讲规则和词典。真实项目里，很多有效改进来自对高频查询的分析，而不是一开始就上复杂模型。

召回要兼顾覆盖和准确

搜索召回要把可能相关的结果找出来。可以用关键词匹配、倒排索引、标签匹配、向量语义召回等方式。关键词匹配精准但可能漏掉表达不同的内容，语义召回覆盖更广但可能带来噪声。

面试里可以说多路召回后再合并去重，并记录每一路的命中情况。这样当结果不好时，能判断是召回阶段没找到，还是排序阶段排错了。

排序评估不能只看点击

搜索排序常看点击，但点击不等于满意。标题党也可能点击高，但用户很快退出。更稳的评估要结合点击、停留、转化、跳出、人工标注相关性和坏例反馈。对于核心查询，还可以维护一批人工评估集，定期看前几条结果是否满足用户意图。

如果面试官问“模型分数提升但线上一般”，可以从标注口径、训练样本偏差、点击噪声、热门内容挤压长尾、查询类型差异等角度分析。

坏例分析最能体现真实经验

搜索项目一定要准备坏例。比如同义词没覆盖导致搜不到，分词错误导致召回偏了，热门内容因为点击多长期压住新内容，短查询意图模糊导致排序不稳定。讲坏例时要补改进方向：加词典、改召回策略、分查询类型排序、引入人工标注或规则兜底。

可以这样表达：我会把搜索问题拆成查询理解、召回和排序三层排查。先看用户查询有没有被正确解析，再看候选结果是否覆盖，再看排序是否把相关结果放前面。评估时不只看点击，还会看人工相关性、停留和坏例。这样的回答比单纯说“用了语义模型”更有工程价值。

相关性问题的分层判断

搜索相关性不是一个模型就能解决。用户查询可能被理解错，召回可能漏掉结果，排序可能偏向点击诱饵，评估可能被历史位置偏差影响。面试时把链路拆开，答案会更稳。

这篇文章可以提醒读者：搜索题不要只讲点击率。点击率可能被标题党影响，也可能受位置影响。相关性要和用户任务完成联系起来。