🟦 大厂搜索引擎的数据流总图
┌──────────┐ │ 用户Query │ └─────┬────┘ ↓ ┌────────────────────┐ │ Query Processing │← 分词/拼写纠错/Query Rewrite/同义词扩展 └───────┬────────────┘ ↓ ┌──────────────────────────────┐ │ Multi-Retriever │ │(倒排召回+向量召回+规则召回)│ └──────────┬───────────┬────────┘ ↓ ↓ Inverted Index ANN Vector Index 倒排索引 向量索引 ↓ ↓ 文本候选集 图搜候选集 └──────┬───────┘ ↓ ┌────────────────────┐ │ Rank1│ ← 粗排：经典排序+轻量模型 └──────────┬─────────┘ ↓ ┌────────────────────┐ │ Rank2│ ← 精排：深度模型（DNN） └──────────┬─────────┘ ↓ ┌────────────────────┐ │ Rerank/LLM │ ← 语义增强/结果重排序 └──────────┬─────────┘ ↓ ┌────────────────────┐ │ Final Results │ └────────────────────┘🟦 第 1 步：用户 Query（User Query）
🟩 一、主流输入类型（当前主流）
- 关键词文本 Query（Search Text）——传统主流
- 图像 Query（Image Query / 图搜）
- 图片 → 图像 embedding[[搜广推术语#embedding]] → 向量检索[[搜广推术语#检索 Retrieval]]
- 多模态 Query（Text + Image / Text + Video）— 快速发展中
🟦 二、主流技术栈（整个互联网大厂都在用）
| ① Query Parsing（查询解析）✔ 当前主流 | - 分词（Tokenizer） - 语言检测（LangID） - 拼写纠错（Spell Correction） - Query Classification（理解用户想搜什么） - Query Segmentation（拆句） 典型算法： -Trie / Double Array Trie（词典分词） -BERT / RoBERTa（意图分类） -编辑距离、BK-tree（纠错） |
|---|---|
| ② Query Understanding（Query 理解）✔ 当前大厂标配 | 核心目标： - 判定 Query 的语义意图 - 识别实体（NER） - 分类场景（比如“新闻、百科、商品、公众号”） 主流技术： - BERT / RoBERTa / NEZHA - Prompt-based LLM 意图理解模型 - 多模态理解模型（图搜） |
| ③ Query Rewrite（召回增强）✔ 当前主流 + 大厂重点 | Rewrite 让搜索能“多抓一些内容”。 例如 query：“苹果手机” → [“iPhone”, “苹果 手机”, “apple 手机”, “iphone 14”] 主流技术： - ML-based rewrite（GNN / Transformer） - Query Expansion（基于词典、Click Graph） - Embedding-based rewrite（向量相似度） - LLM-based rewrite（趋势） 大厂特色： - Google：Query Rewrite + RankBrain - 百度：基于 ERNIE 的 query 改写 - 腾讯搜一搜：多模态改写（图搜场景） |
| ④ Query Normalization（归一化）✔ 工程必做 | 把用户输入的乱七八糟文本“标准化”，转成搜索引擎能理解和处理的规范形式。 例如： - “iphne13” → “iphone 13” - “300￥鞋子” → “300元 鞋子” - 全角 → 半角，繁体 → 简体 这是 C++ 工程侧会实现的模块。 |
🟦 四、未来发展方向（2025–2030 主流趋势）
| 🟨 趋势 1：LLM 深度参与 Query 理解 | - 用户Query → LLM生成多个意图 → 多路召回 - Google 已经在做（Search Generative Experience, SGE）。 |
|---|---|
| 🟨趋势 2：多模态 Query 成为标配 | - 图像（高频） - 视频（极高增长） - 音频 - App 内上下文（微信生态特强） |
| 🟨趋势 3：个性化 Query 解释 | - A 搜 “游戏” → 想玩游戏 - B 搜 “游戏” → 想看攻略 - C 搜 “游戏” → 想下载小程序 这需要大模型和用户行为深度结合。 |
| 🟨趋势 4：Query → Agent 任务执行 | 未来 Query 不只是搜索，还会变成任务："帮我订机票" "帮我做 PPT" "帮我写个表格"LLM 直接执行，而不是只是返回文档。 |
| 🟨趋势 5：语音 + 图 + 文多模态合一 | 语音：这个东西多少钱？ 图：用户正在拍摄商品 |
🟦第 3 步：Multi-Retriever（多路召回）
🟩 1. Multi-Retriever 为什么是“多路”？
因为一种召回无法覆盖所有用户意图。 所以大厂全部采用多路召回系统，常见结构：
Multi-Retriever ┌─────────────┼────────────┬────────────────┐ 倒排召回（Lexical） 向量召回（Semantic） 规则召回（Rule-based） 图文召回（Multimodal） 点击图召回（Click Graph） 实体召回（KG）所有召回结果会合并 → Rank1 → Rank2。
| ① 倒排召回（Inverted Index Retrieval）——传统搜索主力 | query term → posting list → docIDs 核心特征： - 精确匹配（lexical matching）、特别快，延迟低、对拼写敏感、对语义不敏感（弱点） 主流技术： - BM25、TF-IDF、SkipList + 压缩 posting、多索引融合（title/abstract/content） |
|---|---|
| ② 向量召回（Vector Retrieval / ANN）——图搜、多模态、语义召回核心 | 用 embedding（句向量、图像向量）匹配语义：query_emb → ANN index → nearest neighbors 主流 ANN 技术： - HNSW：准确、快速、工业界最常用 - IVF + PQ（Faiss）：分桶 + 压缩，适合大规模索引 - ScaNN（Google）：高速 ANN 图搜链路： - Image → CLIP embedding → HNSW → Top-K 图文内容 |
| ③ 多模态召回（Multimodal Retrieval）——图搜特有的融合召回 | 当 query 不只是文本，还包含图片、视频时： - text_emb + image_emb → Joint Embedding → ANN 主流模型： -CLIP（图像 + 文本对齐） -BLIP2 -Q-Former -Florence（微软） |
| 🟩 ④ 规则召回（Rule-based Retrieval）——非常重要的兜底机制 | 这些场景不需要 ANN，也不需要倒排。 - 直接返回 card（卡片） - 匹配知识库 KB - 精准回答（例如“北京天气” → 直接给天气 widget） |
🟦Rank1（粗排）是什么？
Rank1 = 召回后对上千条候选文档做一次高速过滤与排序，用于“削减规模”，把 1000→几十条，为 Rank2 准备干净的候选池。
| 项目 | Rank1（粗排） |
|---|---|
| 主要目标 | 快速过滤、减少候选规模（1000 → 100） |
| 定位 | “粗筛选”，不追求极致准确，只求快和稳定 |
| 输入 | 多路召回的结果（倒排、向量、规则、点击图） |
| 输出 | Top 80–200（候选池） |
| 模型类型 | 轻量模型：・LR（线性模型）・GBDT（LightGBM）・轻量 MLP（1–2 层）・规则排序（BM25 等） |
| 特征数量 | 少量（10–50 维） |
| 典型特征 | BM25 / TF-IDF、embedding 粗相似度、Doc 质量分、点击率先验、内容长度、时间衰减 |
| 延迟要求 | 极低：1~3 ms |
| 资源开销 | 很小（CPU 友好） |
| 作用 | 去掉明显无关/低质量的内容；保证 Rank2 输入干净 |
| 工程重点 | 并发、内存、特征快速计算、召回合并与裁剪 |
| 大厂实践 | 大规模倒排场景、图搜粗排、多模态初筛必用 |
| 一句话总结 | Rank1 做“快 + 粗”，确保不犯大错 |
🟦Rank2（精排）是什么？
Rank2 = 搜索链路中最核心的排序模型层，用大型深度模型对 Rank1 输出的几十~百条候选进行精确排序，决定最终呈现给用户的搜索结果。
| 项目 | Rank2（精排） |
|---|---|
| 主要目标 | 对少量候选文档（100→50→20）做高精度排序 |
| 定位 | “精选择”，搜索的核心智能层 |
| 输入 | Rank1 输出（通常为 Top 80–200） |
| 输出 | Top 20–50（送给 Rerank / LLM） |
| 模型类型 | 中等规模深度模型：・MLP（多层）・Transformer Ranker（轻量注意力）・多模态 Ranker（图搜场景） |
| 特征数量 | 多（200–1000+ 维） |
| 典型特征 | Query–Doc 语义交互、embedding 相似度、内容质量、行为特征（CTR/停留）、实体/分类特征、多模态特征（图文/视频） |
| 延迟要求 | 中等：10–20 ms |
| 资源开销 | 较大（需要高效推理框架） |
| 作用 | 精准决定结果顺序，搜索结果质量主要由 Rank2 决定 |
| 工程重点 | 特征计算、批量推理、模型服务、性能优化、稳定性 |
| 大厂实践 | 搜索、视频推荐、图搜、AI 搜索核心模块 |
| 一句话总结 | Rank2 做“准 + 强”，真正决定排序质量 |
🟦📌 Rerank（重排）
| 项目 | Rerank（重排） |
|---|---|
| 主要目标 | 在 Rank2 输出的 Top 20–50 里做最后的高精度排序，解决精排难以捕捉的复杂语义问题 |
| 定位 | “最后的质量把关” + “语义纠偏层” |
| 输入规模 | 少量（Top 20–50） |
| 输出规模 | 最终展示的 Top 10–20 |
| 模型类型 | 更强、更重的模型：・Cross-Encoder（BERT 类）・大模型 LLM（问答/重写/排序）・多模态 Cross Attention（图搜） |
| 特征数量 | 特征依赖少，模型直接学习 Query–Doc 交互；更多 end-to-end 表达 |
| 典型特征 / 输入 | Query 与 Doc 全文拼接输入模型（Cross-Encoder）图像 + 文本全量特征（多模态拼接） |
| 延迟要求 | 高但可控：30ms–200ms（分平台）高端系统会异步或批推理 |
| 资源开销 | 大（GPU/高性能 CPU + 并行批推） |
| 作用 | 最终结果质量提升显著；修正 Rank2 的语义错误 |
| 工程重点 | 大模型推理优化、批处理、缓存、降级策略、限流、稳定性 |
| 何时触发 | 仅对少量候选触发；部分场景只对问题类 Query 启动 |
| 大厂实践 | Google SGE；百度“文心重排”模型；腾讯搜一搜 LLM + 多模态重排 |
| 一句话总结 | Rerank 用“最强的模型”做“最后的判断”，让最终结果更像人类理解。 |
