ES打分：function_score机制

可视化演示

动态演示ES打分的核心机制，通过源头/管道/节点/终端四种模式展示关键概念与交互流程。

打分机制概览

你走进“知味轩”点了一份红烧肉，后厨不是乱端菜的。大厨扫一眼菜谱，先看它和“红烧肉”三个字有多少重合：做法步骤里反复出现“五花肉”“冰糖”“酱油”的菜谱优先；只写了一句“本店有盖浇饭”的菜谱靠后。这一轮叫“相关度初筛”。紧接着老板老王凑过来，在几份菜谱上写了批注：招牌菜加 2 分、今天的推荐加 1 分、供应商离得远的减 0.5 分。大厨的基础印象加上老板的批注，才构成最终的上菜顺序。

在 ES 里，每个文档就是一张菜谱，你的查询词就是客人的点单。ES 返回结果时会给每个文档算一个 _score 字段，数值越大排得越靠前。默认的 _score 来自 Lucene 的 BM25 算法，它只关心“查询词和文档内容的相关程度”，相当于大厨师出身的“标准口味”。但实际搜索里，我们还要照顾销量、好评率、距离、会员等级这些业务因素——这时就要用 function_score 查询，在相关度之外追加“业务调分”。

整体看，ES 的排序分数可以拆成两层。第一层是查询词带来的基础相关度分，第二层是各种业务函数产生的调分。两者合起来，得到最终排序分：

所以，默认排序只是后厨的“标准菜单”，只能回答“谁和红烧肉最像”；function_score 则是老板手里的“特权批注单”，让你把商业规则翻译成排序顺序。想设计一套好的搜索体验，必须同时理解这“基础分”和“调分”两套牌。

BM25算法

大厨的基础分是怎么打出来的？他不会只看“菜谱里有没有红烧肉”就下结论，而是会考虑三件事：这个词在这份菜谱里出现了多少次？这个词在所有菜谱里是否常见？这本菜谱是厚厚一本还是薄薄一页？要是同一道词在一本 500 页的百科全书中出现 3 次，和一页小抄里出现 3 次，后者的“专注度”显然更高。

BM25 算法就是 ES 的默认大厨。它对每个查询词，结合词频（TF，Term Frequency）、逆文档频率（IDF，Inverse Document Frequency）和文档长度做综合打分。词频高说明文档围绕该词写得多；逆文档频率高说明这个词很稀有，能有效区隔文档；文档长度归一化则避免长文档仅因篇幅大就占便宜。三个信号合起来，得到一个鲁棒的相关度分数：

其中，逆文档频率 IDF 的计算方式是：

BM25 之所以成为 ES 默认，是因为它在“简单”和“有效”之间取得平衡。回到餐厅里，大厨不会因为一份菜谱写了 100 次“红烧肉”就给它打满分——重复 100 次和重复 10 次，在 BM25 眼里差别很小。这就防止了“关键词堆砌”的作弊手段，也保证了短小精悍的菜谱不会被大厚本子欺负。

function_score基础

老王老板从不单独决定上菜顺序，他总会先看大厨的初评，再往上面叠批注。他手里有一张批注单，上面可能写了好几条规则：“招牌菜加 2 分”“新品加 1 分”“距离超过 10 公里的合作店减 0.5 分”。这些规则就是 ES 里 function_score 的 functions 数组，每个函数都可以独立计算出一个“调分值”。

但这里有个关键问题：多个调分值如何合并？是求和、取平均，还是取最大值？这个合并方式由 score_mode 决定。合并之后，调分结果怎样作用于基础查询分？是加起来、乘上去，还是直接替换？这个由 boost_mode 决定。ES 里有一条完整链路：

最常见的写法是：score_mode = sum，把多条业务调分先加总；boost_mode = multiply，再让基础分整体缩放。比如一道菜基础分 5 分，招牌加分 2 分，最终分就是 5 × 2 = 10——注意，乘法会把基础分和调分“绑得更紧”，只加不加项时，基础分高的文档被放大得更明显。相反，如果用 boost_mode = sum，就是 5 + 2 = 7，业务分只作为固定加成。

批注单上的“先合并、再叠加”的顺序，就是 score_mode 和 boost_mode 的职责划分。理解这两层，你就能随心所欲地把老板的任意规则编码进排序逻辑：想让业务分只做小幅修正，用 sum；想让业务分成倍放大，用 multiply。

脚本评分

有些业务规则不是一个常数能表达的。比如老王的批注单上写：“今天食材价格高于 100 元的菜，加 2 分；否则加 0.5 分。”这需要现场读取每个文档的价格字段，再做一次判断。更复杂的规则，比如“会员收藏过的标签命中一个加 1 分，收藏超过 3 个额外加 2 分”，就很难用固定 weight 写出来。

ES 为此提供了脚本评分：用内置的 Painless 脚本语言，在打分阶段逐文档执行一小段代码。脚本可以从文档字段取值，也可以访问查询参数，最后返回一个浮点数，作为这个文档的“调分”。这样，打分逻辑就从“静态配置”变成了“动态计算”，业务上再灵活的需求都能塞进去。它对应的核心概念是 function_score 里的 script_score 函数：

脚本评分是一把瑞士军刀，能处理任何可计算的打分规则，但也要小心：它是逐文档执行的，会带来额外性能开销。就像老板不可能在用餐高峰期对每道菜都现场做复杂的数学题——他会把最常用的规则写成固定批注（weight、field_value_factor），只在真正需要时动用脚本。合理的设计是：能用配置解决的就别写脚本，脚本只用来覆盖那些“非它不可”的动态业务逻辑。

衰减函数

老王的外卖业务最近火了，但他发现一个问题：距离太远的合作餐馆，就算菜再好吃，客人也等不起。他想在排序里加一条规则：“距离越远，加分越少；超过 5 公里直接降到很低。”衰减函数就是为这类场景设计的——它根据数值字段（如距离、时间、价格）计算一个介于 0 和 1 之间的衰减系数。字段值越接近某个“完美点”，系数越接近 1；偏离越多，系数越小。

衰减函数有三种形态：linear（线性衰减）、exp（指数衰减）、gauss（高斯衰减）。它们都要求你指定两个关键参数：origin 是最优值，scale 是衰减幅度控制的“半径”。以最常用的高斯衰减为例，当一个文档的距离值为 v(D) 时，它的调分为：

想象夜晚的一盏路灯：origin 是灯芯正下方，亮度最高；scale 是光照半径，半径越大，远处越亮。如果你的业务希望“3 公里内差异不大、5 公里外快速下降”，就把 scale 调小一些；如果希望“10 公里内都能接受”，就把 scale 调大。衰减函数特别适合地理搜索、价格敏感类推荐和“新鲜度优先”的场景（比如把发布时间当成 origin，让旧内容自动降温）。

混合检索编排

大厨的口味很稳定，可老王发现，光靠菜谱关键词匹配不够——有时候客人说不清楚菜名，只描述“想吃点家常的、管饱的”。这时让美食 App 的“潮流指数”参与判断，效果更好。这个“潮流指数”就是向量检索：把文档和查询都映射成向量，用相似度衡量语义接近程度。但问题来了：大厨的基础分和潮流指数，该怎么合在一起？

ES 的实践是：先用 BM25 跑一遍词法匹配，再用向量相似度跑一遍语义匹配，最后把两个分数融合。直接相加往往不科学，因为两种分数的量纲和分布完全不同——BM25 可能从 0 到十几，向量余弦相似度通常在 -1 到 1 之间，谁数值大谁就压制对方。所以要先分别归一化，再用一个权重系数 α 平衡：

这就像老板拍板：“这次咱们按七三开——七分听大厨的关键词，三分看潮流指数。”α 的取值要结合业务反复调：对专有名词（如“iPhone 15 评测”）适合加大 BM25 权重；对口语化、同义表达多的查询（如“适合下雨天吃的暖乎乎的东西”）则要加重向量权重。归一化之后，即使未来某一方的分数普遍变高，也不会粗暴地淹没另一方。

AI 应用场景

Python 演示

import math  def idf(n, N):    return math.log(1 + (N - n + 0.5) / (n + 0.5))  def bm25_score(query_terms, term_counts, doc_len, avgdl, df, N, k1=1.2, b=0.75):    score = 0.0    for term in query_terms:        tf = term_counts.get(term, 0)        if tf == 0:            continue        term_idf = idf(df.get(term, 0), N)        denom = tf + k1 * (1 - b + b * doc_len / avgdl)        score += term_idf * tf * (k1 + 1) / denom    return score  def gauss_decay(value, origin, scale):    return math.exp(-((value - origin) ** 2) / (2 * scale * scale))  DOCS = [    {"title": "红烧肉家常做法", "text": "五花肉 冰糖 酱油 料酒 姜片",     "price": 45.0, "distance": 1.2},    {"title": "餐厅招牌红烧肉", "text": "精选五花肉 秘制酱油 慢炖两小时",     "price": 88.0, "distance": 3.4},    {"title": "低卡鸡胸肉沙拉", "text": "鸡胸肉 生菜 沙拉酱 柠檬汁",     "price": 68.0, "distance": 2.1},]  def tokenize(text):    return text.split()  def main():    query_text = "红烧肉 做法 五花肉"    query_terms = tokenize(query_text)    corpus = [" ".join(tokenize(d["text"]) + tokenize(d["title"])) for d in DOCS]    docs_tokens = [tokenize(c) for c in corpus]    N = len(docs_tokens)    doc_lens = [len(t) for t in docs_tokens]    avgdl = sum(doc_lens) / N     df = {}    for tokens in docs_tokens:        for token in set(tokens):            df[token] = df.get(token, 0) + 1     results = []    for idx, doc in enumerate(DOCS):        term_counts = dict((t, docs_tokens[idx].count(t)) for t in set(docs_tokens[idx]))        base = bm25_score(query_terms, term_counts, doc_lens[idx], avgdl, df, N)        boost = 0.0        boost += 2.5 * gauss_decay(doc["distance"], 1.0, 3.0)        boost += 1.0 if doc["price"] < 60 else 0.2        results.append((doc["title"], base, boost, base + boost))     results.sort(key=lambda row: row[3], reverse=True)    for title, base, boost, total in results:        print("%-16s BM25=%6.3f 调分=%6.3f 总分=%6.3f" % (title, base, boost, total))  if __name__ == "__main__":    main()

1. term_idf = idf(df.get(term, 0), N)计算该词在整个文档集合里的逆文档频率，词越罕见权重越高。
2. denom = tf + k1 * (1 - b + b * doc_len / avgdl)对词频做长度归一化，长文档需要更多命中才不吃亏。
3. score += term_idf * tf * (k1 + 1) / denom累加每个查询词的 BM25 贡献，得到基础相关度分。
4. boost += 2.5 * gauss_decay(doc["distance"], 1.0, 3.0)用高斯衰减把“距离越近加分越多”的规则变成数值。
5. results.sort(key=lambda row: row[3], reverse=True)按最后的总分（基础分 + 业务调分）降序排列。

常见误区

面试题