它们俩都是用来"**干涉评分**"的，但**工作阶段不同、性能开销不同、能做的事也不同**。一句话总结：
> **function_score** 在 **第一次算分** 时就动手脚；
> **rescore** 在 **拿到 Top-N 结果后** 再"重新打分"。
下面把"能干嘛"拆开讲。
──────────────────
- function_score（查询阶段就改分）
• 时机：每个分片在 **收集命中文档时** 直接算完最终得分；属于 **query 阶段**。
• 性能：对 **全部命中文档** 都生效，数据量大时成本最高。
• 典型用途
-
按业务权重提升/降低：新品×1.5、广告×0.8
-
把"销量""点击率"等数值字段线性/对数地融进分数
-
地理位置衰减：离用户越近分数越高
-
随机打散：给每个用户返回略有不同的排序
-
脚本写复杂规则：if-else、正则、调用外部服务（不推荐高并发）
──────────────────
- rescore（先粗排，再精排）
• 时机：各分片先用原始查询拿到 **window 内的 Top-K**（默认 10×page_size），然后只在 **这 K 个文档** 上重新算分；属于 **fetch 阶段**。
• 性能：只动少量文档，**比 function_score 轻量**。
• 典型用途
-
用 **昂贵脚本** 或 **复杂机器学习模型** 给 Top-K 做二次精排
-
把 **phrase proximity**、**sloppy 查询** 放在 rescore 里，避免对全量文档计算
-
多轮 rescore：第一轮粗排，第二轮用更复杂的模型微调
-
A/B 测试：只对小窗口做实验，不影响全量
──────────────────
- 简单对比
| 维度 | function_score | rescore |
|---------------|--------------------------------|---------------------------------|
| 生效阶段 | query | fetch（先粗排再精排） |
| 处理文档量 | 所有命中文档 | 窗口内的 Top-K（可配置） |
| 性能 | 重 | 轻（窗口小就便宜） |
| 能否用脚本 | 能 | 能 |
| 能否链式 | 只能一个 function_score | 可配多个 rescore 按顺序执行 |
| 典型场景 | 业务加权、数值衰减、随机打散 | 昂贵模型精排、phrase proximity |
──────────────────
- 一句话选型
• **想对所有文档一视同仁地改分** → 用 `function_score`
• **只想在"头部结果"上精雕细琢** → 用 `rescore`