搜索引擎默认返回的结果并不一定是你想要的。特别是技术类查询，一个发布了五年、被大量外链堆积起来的老页面，往往排在官方最新文档前面。等你照着老版本API写完代码，才发现文档早已废弃，方法签名都变了。要解决搜索结果过时的问题，核心思路有两点：一是给查询加上时间范围的约束，二是给不同来源的内容赋予不同的权重。下面结合实际配置和代码，详细讲讲这两条路线怎么做。
一、为什么搜索结果会过时：排序机制的底层逻辑
要理解结果过时的原因，得先看排序是怎么算的。以Elasticsearch为例，默认的相关性评分（BM25算法）主要衡量查询词与文档内容的匹配程度，包括词频、逆文档频率和字段长度归一化。这个算法完全没有时间维度，一篇2019年的文章只要关键词匹配得好、外链积累足够多，评分就会压倒2024年刚发布的官方文档。
另一个因素是静态权重。很多自建搜索系统在索引文档时会写入一个固定的权重字段，比如老站点的域名权重高，或者历史点击量大的页面权重高。这种设计在资讯类搜索里是合理的，但在技术查询场景下就成了灾难——技术内容的价值随时间衰减得非常快，一个React 16的教程再经典，对使用React 18的开发者来说价值也趋近于零。
还有一个容易被忽视的原因：内容更新时间造假。有些站点每次页面有微小改动就把发布时间刷新为当前时间，导致搜索系统误判内容很新。这就要求我们在做时间过滤时，不能只看单一字段，而是要结合多个时间信号交叉验证，比如首次发布时间、最后修改时间、以及页面内容中明确出现的版本号信息。
二、时间范围过滤：从查询约束到时间衰减
最直接的做法是在查询阶段限定时间边界。Elasticsearch里可以用range查询配合filter上下文实现，filter不会参与评分计算但会影响缓存效率，性能比query上下文更好：
GET /articles/_search
{
"query": {
"bool": {
"must": [
{
"match": {
"content": "docker compose 部署"
}
}
],
"filter": [
{
"range": {
"publish_date": {
"gte": "now-730d",
"lte": "now"
}
}
}
]
}
}
}
这里的now-730d表示只返回最近两年的内容，可以根据领域特点调整。技术类内容建议一年到两年，新闻类可以是几天，百科类则可以放宽到不限制。硬性过滤的缺点也很明显：如果某个领域这两年确实没有新内容，过滤后结果会非常稀疏。所以更优雅的方式是软性时间衰减，让时间参与评分但不做硬性淘汰。
时间衰减可以用Elasticsearch内置的function_score查询实现。下面这个配置中，基础相关性评分乘以一个高斯衰减函数，以发布时间为基准，越新的文档分数越高：
GET /articles/_search
{
"query": {
"function_score": {
"query": {
"match": { "content": "springboot3 配置" }
},
"gauss": {
"publish_date": {
"origin": "now",
"scale": "180d",
"decay": 0.5,
"offset": "30d"
}
},
"boost_mode": "multiply"
}
}
}
几个参数的含义需要理解清楚：origin是衰减的起点，设为now表示以当前时间为基准；scale是衰减尺度，180天表示发布半年后文档得分衰减到一半；decay指定尺度处的衰减比例；offset给了30天的免衰减期，一个月内的新文档完全不衰减。这种软性方案保证了即使没有新内容，老内容依然能被召回，只是排名会往后靠。
自建系统不依赖Elasticsearch的话，可以自己在评分公式里加时间因子。一个常用的指数衰减公式是：最终得分 = 基础相关性得分 × exp(-λ × 天数差)，其中λ控制衰减速度。λ取0.005时，一年前的文档得分大约衰减到原来的16%，两年前只剩2.6%，衰减力度可以根据实际点击数据反推调优。
三、来源权重：给可信度分级而不是一刀切
时间过滤解决了新鲜度问题，但新内容不等于好内容。一个昨天刚发的营销软文，时间权重满分，内容却是抄来的。这时候就需要来源权重来兜底。来源权重的核心思想是：对不同发布渠道的可信度和专业度分级，在评分时作为乘法因子参与计算。
实际操作中可以把来源分成几个层级。第一级是官方来源，比如各语言的官方文档、官方仓库的README、RFC文档，权重设为1.5到2.0；第二级是高质量技术社区，比如知名的问答社区高票答案、活跃的开源项目文档站，权重1.2到1.5；第三级是个人技术博客，需要根据历史质量动态评估，一般在0.8到1.2之间浮动；第四级是内容农场和采集站，权重直接压到0.3以下甚至拉黑。分级之后，在索引阶段把权重写入文档字段：
GET /articles/_search
{
"query": {
"function_score": {
"query": {
"match": { "content": "redis 分布式锁" }
},
"functions": [
{
"filter": { "term": { "source_tier": "official" } },
"weight": 2.0
},
{
"filter": { "term": { "source_tier": "community" } },
"weight": 1.3
},
{
"filter": { "term": { "source_tier": "blog" } },
"weight": 1.0
},
{
"filter": { "term": { "source_tier": "farm" } },
"weight": 0.3
}
],
"score_mode": "multiply",
"boost_mode": "multiply"
}
}
}
来源分级不能完全靠人工维护，规模上去之后需要自动化手段。可以参考这些信号：域名是否在官方域名清单中、作者的历史内容平均质量分、站点的更新频率和原创比例、是否被权威源引用过。对于个人博客，还有一个实用技巧是检测内容中的版本号线索——一篇提到Spring Boot 3.2特性的文章，其技术时效性判断会比单纯的发布时间字段更准确，可以在内容解析阶段提取版本号作为辅助权重信号。
权重设计上有一个常见的坑要提醒：来源权重不宜设置得过于悬殊。如果官方文档权重是个人博客的五倍以上，会导致官方文档里那些写得很差、和查询关系不大的页面也霸占前排，用户体验反而下降。实践中建议最高权重和最低权重的比值控制在三倍以内，让相关性得分仍然占据主导地位，权重只做微调。
四、时间与权重的组合调优及验证方法
时间衰减和来源权重最终要组合起来工作，组合方式建议用乘法而不是加法。加法模式下，一个高权重来源的十年老文可能靠权重一项就补齐了时间衰减的损失，导致明显过时的内容依然靠前。乘法模式下两个因子互相制衡，只有既新鲜又靠谱的内容才能拿到最高综合分。组合评分的公式可以写成：最终得分 = BM25相关性 × 时间衰减因子 × 来源权重因子，三个因子各司其职，出了问题也容易定位是哪个环节的参数不合理。
参数调优不能拍脑袋，要有验证闭环。具体做法是准备一批标注好的测试查询集，人工标注每个查询下哪些结果是好结果、哪些是过时结果，然后计算NDCG或者简单的前十位命中率。调整一次时间衰减的scale参数或来源权重分布，就跑一遍测试集对比指标变化。另外要特别关注一类边界case：查询历史版本相关的问题时，比如用户明确搜的是Python 2的某个老特性，时间衰减反而会伤害结果质量。一个改进思路是识别查询中的版本限定词，检测到明确的老版本关键词时自动减弱或关闭时间衰减因子。
上线之后还要持续监控两个信号：一是结果点击率的分布，如果前三位的点击率持续走低，说明排序和用户预期出现了偏差；二是用户主动追加时间限定词的比例，比如大量用户在查询词后面手动加上“2024”，这几乎就是在明示默认排序的时间因子不够强。把这些反馈信号接回参数调优的流程里，形成一个完整的闭环，搜索结果的新鲜度和可信度才能长期保持在一个合理的水准。