深入搜索引擎1：搜索架构概览

1. 引言

在当今的软件开发领域，搜索功能几乎成为了所有应用的标准配置。无论是电商平台的商品检索、内容社区的笔记发现，还是企业内部的文档管理，搜索框背后承载的不仅仅是数据的查询，更是用户意图的理解与满足。

很多开发者在初次接触搜索时，往往认为这只是简单的 SELECT * FROM table WHERE content LIKE '%keyword%' 的升级版，或者认为部署一个 Elasticsearch 集群就能万事大吉。然而，当我们深入到海量数据和高并发场景时，会发现真正的挑战在于：如何从数亿文档中毫秒级地捞出用户真正想要的那几条？ 这是一个涉及自然语言处理（NLP）、分布式系统、机器学习排序（LTR）以及复杂的评估体系的系统工程。

在本文中，我们将跳出枯燥的教科书定义，以架构师的视角拆解现代搜索引擎的核心链路。我们将探讨决定搜索质量的关键因子，剖析从查询理解到最终排序的全流程，并重点聊聊那些容易被忽视但至关重要的评价指标。

2. 现代搜索链路的解构与重组

传统的搜索往往过分依赖倒排索引（Inverted Index），这解决了"找得到"的问题，但很难解决"找得好"的问题。现代搜索引擎的架构早已演变成了一个复杂的漏斗型流水线。

2.1 查询理解（QP）：不仅仅是分词

一切始于用户输入。但在我们去数据库检索之前，查询处理（Query Processing, QP） 是至关重要的第一步。如果说索引是搜索引擎的肌肉，那 QP 就是大脑。

我们不能直接拿着用户的原始 Query 去搜。在这个阶段，通常需要并行处理以下任务：

分词与权重计算（Tokenization & Term Weighting）：
不仅仅是把 "冬季卫衣推荐" 切开。我们需要识别出 "卫衣" 是核心词（权重最高），"冬季" 是修饰词，而 "推荐" 可能是停用词或低权重词。
查询改写（Query Rewriting）：
这是解决“词不达意”的关键。用户搜 "感冒药"，系统需要扩展出 "布洛芬"、"连花清瘟"。
意图识别（Intent Recognition）：
判断 Query 是否具有时效性（如 "世界杯比分"）、地域性（如 "附近的火锅"）或强导购意图。

2.2 多路召回（Retrieval）：文本与向量的博弈

召回层的目标是快和全。现代搜索架构通常采用多路召回策略，但在引入向量搜索时，有一个非常隐蔽的坑需要注意。

1. 文本召回（Lexical Retrieval）

基于倒排索引。虽然古老，但在处理精确匹配时依然不可替代。特别是对于专有名词、拼写错误（Typos），传统文本检索往往表现优于向量检索。

为什么文本召回不怕写错字？
文本检索基于字形（Morphology）。通过 N-gram 索引或编辑距离（Levenshtein Distance），iPhne 和 iPhone 在字符排列上高度重合，系统很容易判定它们是同一个东西。

2. 向量召回（Dense Retrieval）

利用双塔模型将 Query 和 Document 映射到同一向量空间。它解决了“语义匹配”的问题，比如搜“轻薄本”能召回“MacBook Air”。

为什么向量搜索会因为拼写错误而翻车？
很多开发者发现，用户输入 iPhne（漏了o），向量搜索的结果可能完全不相关。这是因为深度学习模型（如 BERT）依赖 Tokenizer（分词器）：正常情况：iPhone 在字典里，被映射为 ID 10532，对应一个语义明确的向量。拼写错误：iPhne 不在字典里，Tokenizer 会把它强行拆解成碎片，如 ['i', '##Ph', '##ne']。后果：模型将这些碎片的向量组合起来，可能指向一个未知的语义空间，甚至因为 Ph 与化学相关，导致结果漂移到化学领域。

因此，最佳实践是“混合检索（Hybrid Search）”：让文本路负责兜底拼写错误和精确词，让向量路负责语义泛化。

除了文本召回（基于倒排索引，解决“精准匹配”）和向量召回（基于 Embedding，解决“语义泛化”）这两大支柱外，工业级搜索引擎（尤其是电商、本地生活、社交媒体类）为了解决长尾问题、冷启动问题以及特定的业务约束，通常还会构建以下几种重要的召回通道。

我们可以把它们统称为**“辅助召回”或“特定场景召回”**。

1. 行为类召回（Behavior-based Retrieval） / 协同过滤（CF）

这是推荐系统中常用的技术，但在现代搜索中也极其重要，特别是电商搜索。它不看查询词的字面意思，而是看“群体的智慧”。

Item-to-Item (I2I) 召回：
- 原理：基于用户历史行为挖掘。如果大量用户在搜索了 Query A 后点击了商品 X，同时也点击了商品 Y，那么当新用户搜 Query A 并点击 X 后，我们可以把 Y 也捞出来（或者直接基于 Query 的点击历史）。
- 应用场景：用户搜“手机”，结果里除了手机，可能还会通过 I2I 召回“手机壳”或“充电器”，因为历史数据显示买手机的人也常看这些。
- 技术点：Swing 算法、ItemCF。
User-to-Item (U2I) 召回：
- 原理：直接基于用户画像或历史兴趣召回文档。
- 应用场景：个性化搜索。当查询词很宽泛（如“推荐”、“新品”）时，直接把用户最近感兴趣的类目下的商品捞出来。

2. 知识图谱召回 (Knowledge Graph Retrieval)

当查询涉及实体关系推理时，文本和向量往往搞不定。

原理：将 Query 映射到知识图谱中的实体（Entity Linking），然后通过关系边（Edge）寻找关联实体。
应用场景：
- 用户搜“刘德华的老婆”，文本搜不到匹配字符，向量可能只搜到刘德华的歌，但 KG 可以沿着 刘德华 -> [spouse] -> 朱丽倩 这条边直接召回。
- 用户搜“20万左右的德系SUV”，KG 可以先锁定 价格区间:20w、车系:德系、车型:SUV 属性，快速结构化召回。

3. 运营与规则召回 (Rule-based / Intervention)

算法不是万能的，有时候需要“人工降临”。

原理：基于运营配置的黑白名单或强插逻辑。
应用场景：
- 强插（Pinning）：大促期间，搜“手机”必须把 iPhone 15 放在前三位。
- 活动召回：搜“双11”，召回活动落地页，而不是某个包含“双11”关键词的商品。
- 屏蔽/黑名单：合规要求，某些特定词（如涉黄涉政）必须强制过滤或只展示特定内容。

4. 地理位置召回 (LBS / Geo Retrieval)

对于本地生活服务（美团、滴滴、大众点评），这是核心通路。

原理：使用 GeoHash 或 QuadTree 索引，结合距离计算。
应用场景：
- 搜“附近的火锅”。如果只用文本召回“火锅”，可能召回出几千公里外的店。
- LBS 召回会限定：GeoHash in [Current_Block, Neighbor_Blocks] AND Category = Hotpot。
逻辑：它通常是一个硬过滤（Hard Filter）条件，作为独立的召回源。

5. 热门与趋势召回 (Trending/Hot Retrieval)

解决“无结果”或“冷启动”问题。

原理：基于全局统计数据（点击量、搜索量飙升榜）。
应用场景：
- 当用户的 Query 极其冷门，文本和向量都召回不到足够数据时（少于一屏），用全局热门内容补齐。
- 或者 Query 本身就是“热搜”、“头条”这种泛词。

6. 标签/属性召回 (Tag/Attribute Retrieval)

针对结构化查询的快速通道。

原理：利用倒排索引的结构化字段。这看起来像文本召回，但逻辑不同。
应用场景：
- 用户点击了筛选卡片（Filter）。比如搜“连衣裙”后点了“红色”、“M码”。
- 这时系统会触发 Color:Red AND Size:M 的精确属性检索，这通常独立于 Query 的文本匹配流程。

7. 缓存与 KV 召回 (Cache/KV Retrieval)

正如书中 1.3 节提到的“其他补充召回”，这是一种**“以空间换时间”**的高效策略。

原理：离线挖掘好高频 Query 的最佳结果，存入 Redis 或 KV 存储中。
应用场景：
- 高频词（Top Query）：对于每天几亿人搜的“微信”、“淘宝”这种词，不需要每次都走复杂的倒排和向量计算，直接读 KV 缓存，毫秒级返回人工精选或离线算好的 Top N 列表。
- 查询改写结果：离线算好 q -> list<q'>，线上直接查 KV 拿到改写词，再发起召回。

2.3 排序（Ranking）：树模型的统治战场

召回回来的几千条数据，需要经过层层筛选。这是一个漏斗：海选 -> 粗排 -> 精排。在**精排（Fine Rank）**阶段，算力消耗最大，也是决定最终效果的关键。

以下是各个阶段的主流模型及其选型逻辑：

1. 召回海选（Selection / Pre-Ranking）

数据规模：亿级 $\rightarrow$ 万级 (Top 10,000)
核心目标：极速。只求“不漏掉好东西”，不求“排得特别准”。
计算耗时限制：忽略不计（通常集成在倒排/向量检索过程中）。

在这个阶段，通常没有复杂的模型，而是依赖规则和轻量级计算：

基础算分公式（Scoring Function）：
- TF-IDF / BM25：这是写死在 Lucene/ES 里的，计算代价极低。
- 静态分（Static Score）：PageRank、商品销量、店铺评分。这些是离线算好存进去的，线上只是查表。
简单的线性加权：
- Score = a * BM25 + b * 静态分。
硬规则（Hard Filters）：
- 必须同城、必须有货、必须评分 > 3.0。
ANN（近似最近邻）：
- 如果是向量召回，这里的“模型”其实就是 HNSW 或 IVF 的距离计算（点积或余弦相似度）。

2. 粗排（Rough Rank / Light Rank）

数据规模：万级 $\rightarrow$ 千级/百级 (Top 1,000)
核心目标：解耦。需要引入个性化，但不能进行复杂的特征交叉（Cross Feature）。
计算耗时限制：几毫秒。

粗排必须在有限时间内处理上千条文档，因此它绝不能使用那种“把用户特征和文档特征拼在一起做复杂运算”的模型。

主流模型：

双塔模型（Two-Tower / DSSM 变体） —— 绝对的主流
- 原理：
  - 用户塔（Query Tower）：输入用户特征，输出一个向量 $V_u$。
  - 文档塔（Doc Tower）：输入文档特征，输出一个向量 $V_d$。
  - 计算：$Score = V_u \cdot V_d$（内积）。
- 为什么用它？
  - 速度快：$V_d$ 可以离线算好存起来。线上只需要算一次 $V_u$，然后和几千个 $V_d$ 做简单的内积运算（向量运算极快）。
  - 解耦：用户和文档在进入最后一步之前没有交互，极大地降低了计算量。
知识蒸馏模型（Distilled Models）
- 原理：训练一个巨大的精排模型（Teacher），然后训练一个结构简单的小模型（Student，比如只有2层简单的神经网络）去模仿 Teacher 的打分。
- 用途：用小身板跑出接近大模型的效果。
简单的逻辑回归（LR）/ GBDT
- 早期方案，现在用得少了，或者仅用于处理少量统计特征。

3. 精排（Fine Rank）

数据规模：百级 $\rightarrow$ 十级 (Top 50)
核心目标：精准。不惜一切代价（算力允许范围内）搞清楚用户到底点不点。必须上特征交叉。
计算耗时限制：十几到几十毫秒。

精排是“重型武器”的战场。这里会使用**Pointwise（单点预估）或Pairwise（成对预估）**的方式。

主流模型：

A. 深度学习派（Deep Learning - 处理特征交叉的神器）

这是目前大厂（Google, 阿里, 字节）的主流。

Wide & Deep (Google)
- 祖师爷级别。左边是 LR（记忆能力，记性好），右边是 DNN（泛化能力，举一反三）。
DeepFM / xDeepFM
- 自动特征交叉。解决了 Wide&Deep 需要人工设计特征组合的问题。它能自动学习“用户性别”和“商品类目”结合在一起会发生什么化学反应。
DIN / DIEN (阿里)
- 序列模型。引入了Attention 机制。它不只是看用户画像，而是看用户“过去的行为序列”。
- 例子：用户搜“鞋子”，模型会重点关注用户历史记录里看过的“鞋子”，而忽略看过的“水杯”。
多目标学习（Multi-Task Learning, MTL）- MMOE / PLE
- 最现代的架构。精排不仅要预测“点击率（CTR）”，还要预测“转化率（CVR）”、“点赞率”、“停留时长”。MMOE 网络能同时输出这些分数，最后加权融合。

B. 树模型派（Tree Models - 处理统计特征的神器）

在中等规模公司，或者对可解释性、统计特征依赖极强的场景（如金融、传统电商），树模型依然是王者。

XGBoost / LightGBM
- 原理：GBDT 的进化版。擅长处理连续值、统计值（如过去7天点击率、转化率）。
- 结合方式：很多时候会采用 GBDT + LR 或 Deep Learning 提取 Embedding + XGBoost 排序 的混合架构。

总结对比

阶段	数据量级	核心逻辑	典型模型	关键词
海选/召回	亿级 -> 万级	规则过滤、硬匹配	BM25, HNSW(ANN), 倒排索引	快、静态分
粗排	万级 -> 千级	向量近似、无交叉	双塔模型 (DSSM), 蒸馏模型	解耦、向量内积
精排	千级 -> 十级	深度特征交叉、多目标	DeepFM, DIN, MMOE, XGBoost	准、Attention、CTR/CVR

一句话总结：
海选靠索引，粗排靠双塔，精排靠深度网络（交叉特征 & 多目标）、树模型。

虽然深度学习（Deep Learning）在图像和 NLP 领域大杀四方，但在搜索精排中，树模型（GBDT/XGBoost/LightGBM） 依然占据半壁江山。

为什么精排要用 XGBoost 而不是全上深度学习？

对表格型数据（Tabular Data）的统治力：
精排输入的是特征向量，包含大量统计特征（如：过去7天销量、CTR、文档字数、价格）。树模型处理这些稠密数值特征的非线性关系（例如：销量从0到100对权重影响巨大，但1万到2万影响很小）非常强悍，且无需复杂的归一化。
Pairwise 排序目标（Learning to Rank）：
XGBoost 支持 rank:pairwise 目标函数。它不像普通分类问题那样只关心“点没点击”（Pointwise），而是像教官一样，不断对比两个文档，学习**“文档 A 应该排在文档 B 前面”**这样的偏序关系。
可解释性：
如果搜索结果异常，树模型可以输出 Feature Importance，让你一眼看出是“时间特征”权重太高还是“热度特征”失效，方便调试。

架构建议：大厂的主流做法往往是 Deep Learning (用于提取 Embedding 特征) + XGBoost (作为最终的打分器) 的组合拳。

3. 决定用户满意度的核心因子

在设计算法时，我们需要明确优化的目标函数。除了让机器理解语义，我们还需要关注以下几个维度。

3.1 相关性 vs. 个性化

这是搜索系统中永恒的权衡（Trade-off）。

相关性（Relevance） 是底线。用户搜 "Python教程"，你不能因为他喜欢看美女就给他推美女视频。
个性化（Personalization） 是增益。当查询词宽泛时（如 "头像"），个性化能通过用户的历史行为来猜测他的具体偏好。

3.2 时效性与内容质量

时效性：对于突发新闻，系统必须有专门的实时索引链路。
内容质量：在 UGC 社区，图片的清晰度、排版的美观度、作者的信誉等级，都应作为静态特征存入索引，直接参与 XGBoost 的打分。

4. 拒绝虚荣指标：科学的评估体系

很多团队优化搜索时盲目追求 CTR（点击率），这容易导致“标题党”泛滥。

4.1 核心指标与过程指标

北极星指标：用户规模（DAU）和留存率（Retention）。这是业务的生命线。
中间过程指标：
- DCG (Discounted Cumulative Gain)：相比 CTR，它更关注排序的位置。排在第1位的相关文档比排在第10位的价值大得多。
- 主动换词率：如果用户搜完一个词，马上换了个词重搜，通常说明上一次搜索结果很差。

4.2 人工评估：Side-by-Side (SBS)

在算法全量上线前，SBS 评估是必不可少的一环。让评估人员同时看新旧算法的结果，给出 GSB（Good/Same/Bad）判定。这也是校准树模型 Pairwise 训练目标的重要依据（Ground Truth）。

5. 实践案例

案例一：混合检索（Hybrid Search）代码示例

在实际工程中，我们需要结合文本的模糊匹配（解决拼写问题）和向量匹配（解决语义问题）。

from elasticsearch import Elasticsearch

# 初始化 ES 客户端
es = Elasticsearch("http://localhost:9200")

def hybrid_search(query_text, query_vector):
    search_body = {
        "query": {
            "bool": {
                "should": [
                    # 1. 文本路：带模糊匹配 (Fuzziness)
                    # 关键点：利用 fuzziness="AUTO" 解决 "iphne" -> "iphone" 的拼写错误
                    {
                        "multi_match": {
                            "query": query_text,
                            "fields": ["title^3", "content"], 
                            "fuzziness": "AUTO" 
                        }
                    },
                    # 2. 向量路：语义匹配 (KNN)
                    # 关键点：解决 "轻薄本" -> "MacBook" 的语义泛化
                    {
                        "knn": {
                            "field": "embedding",
                            "query_vector": query_vector,
                            "k": 10,
                            "num_candidates": 100
                        }
                    }
                ]
            }
        },
        # 使用 RRF (Reciprocal Rank Fusion) 融合两路结果
        "rank": {
            "rrf": {
                "window_size": 50
            }
        }
    }
    return es.search(index="products", body=search_body)

案例二：使用 XGBoost 做 Pairwise 精排

如何利用树模型对召回的文档进行最终排序？以下是一个使用 XGBoost 进行 Learning to Rank 的简化示例。

import xgboost as xgb
import numpy as np

# 1. 准备数据 (Learning to Rank 格式)
# 特征 X: [BM25分数, 销量, CTR, 价格...]
X_train = np.array([
    [0.9, 1000, 0.05],  # Doc A (Query 1) - 用户点了
    [0.2, 50,   0.01],  # Doc B (Query 1) - 用户没点
    [0.8, 800,  0.04],  # Doc C (Query 2)
    [0.1, 10,   0.00]   # Doc D (Query 2)
])

# 标签 y: 相关性分数 (0:不相关, 1:点击, 2:购买)
y_train = np.array([1, 0, 1, 0])

# Group 信息: 告诉模型哪些文档属于同一个 Query
# 这里表示：前2个文档属于 Query1，后2个文档属于 Query2
group_train = [2, 2]

# 2. 构建 DMatrix
dtrain = xgb.DMatrix(X_train, label=y_train)
dtrain.set_group(group_train)

# 3. 设置参数 (核心)
params = {
    'objective': 'rank:pairwise',  # 关键：使用 Pairwise 目标函数优化排序顺序
    'eval_metric': 'ndcg',         # 评估指标使用 NDCG
    'eta': 0.1,
    'max_depth': 6
}

# 4. 训练模型
model = xgb.train(params, dtrain, num_boost_round=100)

# 5. 线上预测
# model.predict(dtest) 将返回每个文档的排序分