Elasticsearch 相关性调优：BM25 参数不是调出来的，是测出来的

搜索相关性差，很多人的第一反应是调 BM25 的 k1 和 b。但这两个参数控制的是词频饱和和文档长度归一化，调它们之前，先确认问题真的出在这里。

BM25 的评分由三部分构成：词频（TF）、逆文档频率（IDF）和文档长度归一化。k1 控制词频饱和速度，值越大，高频词的影响越持续；b 控制长度归一化的强度，b=1 表示完全按长度惩罚，b=0 表示不惩罚。默认 k1=1.2、b=0.75 在大多数语料上是合理起点，但“合理”不等于“适合你的数据”。

一个更常见的相关性问题是字段分析和查询结构，而不是参数。比如中文搜索没有正确分词，导致“手机壳”被切成“手机”和“壳”，召回一堆不相关文档；或者标题和正文用了相同的权重，而标题里的匹配显然应该更重要；或者查询用了 match 但没指定 operator，默认 OR 导致“红色 连衣裙”召回了所有包含“红色”或“连衣裙”的文档。这些问题不解决，调 k1 和 b 只是在错误的基础上做微调。

调优的正确顺序是：先看分词是否合理，再看查询结构是否表达了业务意图，然后看字段权重是否符合“标题 > 摘要 > 正文”的直觉，最后才考虑 BM25 参数。字段权重可以通过 boost 在查询时指定，也可以通过 multi_match 的 fields 加权重。一个实用做法是给标题 2—3 倍权重，给标签更高，给正文基准权重，然后用评估集验证。

评估集是相关性调优的前提。准备 50—100 个真实查询，为每个查询标注“哪些文档是相关的”，然后计算 NDCG 或 MRR。没有评估集，调参就是凭感觉，而且无法判断一次改动是变好还是变坏。评估集不需要很大，但要覆盖典型查询类型：精确匹配、同义改写、长尾查询、拼写错误。

一个容易被忽略的维度是查询意图分类。导航型查询（用户想找某个具体页面）、信息型查询（用户想了解某个话题）、交易型查询（用户想购买某物），对相关性的定义不同。导航型查询要求第一条结果就是目标页面，信息型查询可以容忍多样化的结果。用同一套评分标准衡量所有查询，会得出“整体相关性一般”的模糊结论，而无法指导具体优化。

BM25 参数可以作为最后一步微调，但它的收益通常小于分词、查询结构和字段权重的修正。先修结构，再调参数，顺序反了会浪费大量时间在无效调参上。