它们俩都是用来“**干涉评分**”的，但**工作阶段不同、性能开销不同、能做的事也不同**。一句话总结：

> **function_score** 在 **第一次算分** 时就动手脚；  
> **rescore** 在 **拿到 Top-N 结果后** 再“重新打分”。

下面把“能干嘛”拆开讲。

──────────────────  
1. function_score（查询阶段就改分）

• 时机：每个分片在 **收集命中文档时** 直接算完最终得分；属于 **query 阶段**。  
• 性能：对 **全部命中文档** 都生效，数据量大时成本最高。  
• 典型用途  
- 按业务权重提升/降低：新品×1.5、广告×0.8  
- 把“销量”“点击率”等数值字段线性/对数地融进分数  
- 地理位置衰减：离用户越近分数越高  
- 随机打散：给每个用户返回略有不同的排序  
- 脚本写复杂规则：if-else、正则、调用外部服务（不推荐高并发）

──────────────────  
2. rescore（先粗排，再精排）

• 时机：各分片先用原始查询拿到 **window 内的 Top-K**（默认 10×page_size），然后只在 **这 K 个文档** 上重新算分；属于 **fetch 阶段**。  
• 性能：只动少量文档，**比 function_score 轻量**。  
• 典型用途  
- 用 **昂贵脚本** 或 **复杂机器学习模型** 给 Top-K 做二次精排  
- 把 **phrase proximity**、**sloppy 查询** 放在 rescore 里，避免对全量文档计算  
- 多轮 rescore：第一轮粗排，第二轮用更复杂的模型微调  
- A/B 测试：只对小窗口做实验，不影响全量

──────────────────  
3. 简单对比

| 维度          | function_score                 | rescore                         |
|---------------|--------------------------------|---------------------------------|
| 生效阶段      | query                          | fetch（先粗排再精排）           |
| 处理文档量    | 所有命中文档                   | 窗口内的 Top-K（可配置）        |
| 性能          | 重                             | 轻（窗口小就便宜）              |
| 能否用脚本    | 能                             | 能                              |
| 能否链式      | 只能一个 function_score        | 可配多个 rescore 按顺序执行     |
| 典型场景      | 业务加权、数值衰减、随机打散   | 昂贵模型精排、phrase proximity  |

──────────────────  
4. 一句话选型

• **想对所有文档一视同仁地改分** → 用 `function_score`  
• **只想在“头部结果”上精雕细琢** → 用 `rescore`