一个词突然被搜了一万次，BM25的IDF会不会立刻下降？仅凭查询次数，不能得出这个结论。
Lucene BM25Similarity文档中的IDF输入是docCount与docFreq，分别与参与统计的文档、包含该词的文档有关。查询量不是这两个变量。把热搜计数写进docFreq，会悄悄换掉算法的含义。
原理示意，非真实系统截图或性能测量。
把两个事件拆开
事件一：索引文档完全不变，用户反复查询同一个词。查询压力、缓存和排队会变，IDF的文档统计输入不因此自动改变。
事件二：商家批量给商品标题加热词并刷新索引。包含该词的文档数可能改变，IDF才有变化依据。具体何时可见，还受引擎刷新、段和分片统计方式影响。
from math import log def idf(n, df): if not (0 <= df <= n): raise ValueError("invalid document statistics") return log(1 + (n-df+0.5)/(df+0.5)) before = idf(100,10) query_counts = [1,100,10000] assert all(idf(100,10) == before for _ in query_counts) after_document_change = idf(100,20) assert after_document_change < before print("PASS query count absent from IDF; higher df lowers IDF here")这是公式级合成反例，本地Python 3.9.6运行通过。它没有模拟Lucene索引刷新，也没有给出线上相关性收益。图中的N=100、df=10只是算式输入。
热度信号可以有，名字要叫对
检索系统当然可以使用查询热度、时间衰减或流行度特征。问题在于它们属于业务打分，不是“标准BM25必须做的稀疏权重修复”。
如果引入热度衰减，要先说明目标：提高近期内容曝光，还是抑制刷词？它可能帮助新内容，也可能进一步挤压低频但精确的型号查询。建议分别标注精确词、泛意图和冷门查询，用同一判断集观察误召与排序变化。
RRF可以减少原始评分量纲不同带来的直接比较问题，但候选窗口仍决定它看得到哪些文档。把一个分数换成排名，不会自动解决词法误匹配，也不会替错误的统计口径兜底。
一条有用的排查链应该是：先确认查询改变了还是文档改变了，再看索引统计、召回候选和最终排序。别看到“热点”两个字，就让IDF背所有的锅。
本地示例使用Python 3.9.6；保存完整Python块为demo.py后可用python3 demo.py复现。示例只验证文中限定的逻辑，不代表已接入数据库或模型。
