第3章：索引、查询、排序、分布式核心组件面试点
搜索引擎核心系统技术栈是面试中考察广度与深度的关键章节。面试官通常要求你从整体架构出发，逐一拆解索引构建、查询解析、排序策略、分布式协作等模块。本章提供结构化回答框架和典型追问路径，帮助你在任何技术栈问题上建立清晰表达逻辑。
📌 面试问答卡片（常规章节）
问题1：请描述搜索引擎的倒排索引结构和构建流程
| 考察点 | 基础概念理解、构建过程、增量与全量 |
|---|
| 回答框架 | ① 定义倒排索引（词 -> 文档ID列表） ② 构建流程：分词 → 归一化 → 统计频率 → 排序写入 ③ 正排索引补充 ④ 增量更新策略 |
|---|
| 示例回答 | 倒排索引由词典和倒排表组成。构建时先对文档集分词、去停用词、做归一化，再统计每个词出现的文档ID及TF。为提高查询效率，词典常使用Trie或哈希表，倒排表按docID排序存储。同时维护正排索引存放文档原始字段，用于排序和展示。 |
|---|
| 可能追问 | 如何支持实时索引？跳表在倒排合并中的作用？压缩算法（Varint、PForDelta）？ |
|---|
| 避坑提醒 | 不要只讲概念不提具体数据结构（如跳表/位图）和压缩优化；避免混淆倒排和正排 |
|---|
问题2：查询处理阶段通常包括哪些步骤？如何优化查询性能？
| 考察点 | 查询全链路理解、性能瓶颈、SDK/Proxy层面优化 |
|---|
| 回答框架 | ① 查询预处理：分词、改写、纠错 ② 查询重写：同义词、Query理解 ③ 检索：倒排拉链求交/或 ④ 过滤与打分 ⑤ 优化：剪枝、缓存、预取 |
|---|
| 示例回答 | 查询首先经分词和Query分析，识别实体和意图。之后进入检索模块，使用倒排索引求交得到候选集。重点优化在倒排合并时采用跳表加速，并对高频term的倒排表做早期终止。同时利用LRU缓存query结果，降低重复计算。 |
|---|
| 可能追问 | 如何平衡召回率与响应时间？分片查询与结果合并如何处理？实时索引对查询延迟的影响？ |
|---|
| 避坑提醒 | 避免只讲理论不讲工程实践（如分片并发查询、协调层超时策略）；忽略Query理解对排序的影响 |
|---|
问题3：排序阶段如何设计粗排和精排？分布式下的排序挑战是什么？
| 考察点 | 多阶段排序架构、LTR模型、分布式结果合并 |
|---|
| 回答框架 | ① 粗排：用轻量模型（FFM、双塔）从几万候选快速筛选top N ② 精排：用复杂模型（DeepFM、Transformer）排序 ③ 分布式：各分片独立排序后，协调层做全局重排或取topK再排序 ④ 一致性映射 |
|---|
| 示例回答 | 粗排使用向量化特征和轻量模型对候选doc打分，保留top200；精排加载更多特征（用户历史、点击率）用dense模型排序。分布式场景下，各shard返回本地topK结果，协调层合并后使用完整特征重排，确保全局排序一致性。 |
|---|
| 可能追问 | 粗排特征如何选择？精排模型线上serving延迟如何优化？样本偏差如何处理？ |
|---|
| 避坑提醒 | 不能只提模型名称不说特征工程和数据流；忽略粗排对延迟的敏感性；分布式合并时注意排序稳定性 |
|---|
🚀 项目案例章节
项目名称：电商搜索排序系统重构
| 业务背景 | 原有排序基于BM25+静态分，转化率低，需要引入LTR模型并优化分布式排序性能 |
|---|
| 规模指标 | 商品数2亿、日活3000万、QPS峰值2万、响应时间要求<50ms p99 |
|---|
| 技术栈 | Java+Elasticsearch（定制） + Spark + TensorFlow + ZooKeeper |
|---|
| 核心难点 | ① 粗排模型延迟高需剪枝 ② 多分片排序结果合并后排名漂移 ③ 实时特征更新与模型serving一致性 |
|---|
| 面试高频追问 | 你如何评估粗排剪枝对召回的影响？分片合并后如何保证排序公平性？模型版本管理与灰度策略？ |
|---|
| 可迁移话术 | “我们采用上下界剪枝+分片返回topK的改进，在合并阶段用完整特征重新打分，既保证排序质量又控制延迟。这套方案后来推广到推荐系统粗排中。” |
|---|
💡 复习提示：每个模块都要准备一个“踩坑实例”，面试官更看重你从实际项目中提炼的工程决策。例如：倒排压缩选型导致GC压力、实时索引合并时内存OOM等。