搜索场景的大模型推理优化多阶段召回的精排融合与 Query 理解延迟压缩一、搜索的全链路延迟分解从 Query 输入到结果返回的三级跳搜索系统的一个完整请求链路包含三个阶段Query 理解意图分类、实体识别、纠错、改写、多路召回倒排索引、语义向量、个性化、精排融合相关性打分、CTR 预估、多样性重排。三个阶段的总延迟预算通常在 200ms 以内。将三个阶段的延迟分解在典型搜索引擎中Query 理解15-25msBERT-base 文本分类 NER 纠错模型多路召回30-50ms倒排索引 5ms 向量检索 ANN 20ms 个性化召回 10ms精排融合80-120ms500 候选 → 精排模型 → 重排 → 结果精排阶段占据了延迟预算的 40%-60%是优化的核心。但 Query 理解阶段中的 LLM大语言模型推理也在逐渐成为新瓶颈——将 BERT-base 替换为 Llama-3-8B 做 Query 意图理解后该阶段的延迟从 20ms 跃升至 120ms直接将总延迟推至 260-300ms。搜索系统的优化与推荐系统类似但有一个关键差异Query 理解是不可批量化的——搜索 Query 是即时且有状态的用户输入的每个字符都影响后续建议不能等 16 个同类 Query 到齐后再做批处理。这意味着 Query 理解的优化必须聚焦于单请求的推理延迟而精排的优化可以充分利用批量推理。二、Query 理解的蒸馏策略用 1M 参数的小模型逼近 8B 大模型效果graph TB subgraph Teacher Model (离线) A[Llama-3-8Bbr/120ms/query] -- B[10 万条 Query 标注br/意图 实体 纠错] B -- C[软标签生成br/Logits 概率分布] end subgraph Student Model (在线) D[BERT-tiny 12Mbr/4ms/query] -- E[知识蒸馏训练br/拟合 Teacher Logits] C -- E E -- F[部署到搜索服务br/延迟 4ms] end style A fill:#7950f2,stroke:#5f3dc4,color:#fff style D fill:#51cf66,stroke:#2f9e44 style F fill:#40c057,stroke:#2f9e44知识蒸馏Knowledge Distillation是将大模型的知识迁移到小模型的核心技术。在搜索 Query 理解场景中使用 Llama-3-8BTeacher对 10 万条历史 Query 做意图分类、实体识别和纠错生成软标签Soft Labels。软标签不仅包含大模型的最终分类结果还包含了各类别的概率分布——例如 Query「苹果手机」的意图分布为 [0.72 商品, 0.18 品牌, 0.10 水果]——这个分布中包含的「不确定性」信息大模型认为有 28% 概率不是商品是硬标签 [商品1] 所丢失的。Student 模型选用 BERT-tiny12M 参数2 层 Transformer在 10 万条 Teacher 生成的软标签上做蒸馏训练。蒸馏后的 BERT-tiny 在 Query 意图分类上的准确率从 87%传统微调提升至 94%蒸馏与 Teacher 模型96%仅差 2%但推理延迟从 120ms 降至 4ms——30 倍的加速。这个性能差距在大多数搜索场景中完全可以接受——2% 的意图分类误差在精排阶段有足够的信息来修正。三、语义向量召回的延迟优化Faiss 索引的 GPU 加速与量化压缩语义向量召回是基于 ANN近似最近邻搜索的。500 万商品向量 × 768 维 × FP32 15.4GB——单 GPU 的显存边界。在不得不使用 CPU 做 Faiss 检索的情况下单次查询的检索延迟约 20-30ms基于 HNSW / IVF 索引。将 Faiss 索引迁移到 GPU 做向量检索可以将延迟降至 3-5ms——关键在于显存容量。500 万 × 768 维的 FP16 向量约 7.7GB在 24GB A10 上完全可容纳。但 Faiss 的 GPU IVF 索引需要额外的 Quantizer 结构粗聚类中心查找和倒排列表存储实际显存占用约 12-15GB。对于 1000 万 Item 的大规模搜索需要做向量压缩——通过 Product Quantization (PQ) 将 768 维向量压缩为 96 维 × 8 位 码本索引约 768 字节 → 96 字节显存压缩至 960MB检索延迟增加至 8-12ms但召回率仅下降 3%-5%。更大规模的搜索 1 亿 Item需要分片索引。将全量向量按 hash(ItemID) 分 8 片每个分片独立构建 Faiss GPU 索引。每次 Query 并行查询 8 个分片每个分片返回 Top-508×50400 候选在精排层做全局排序。8 个分片并行查询的延迟约 8ms单个分片 8ms并行查询最慢分片也约 8ms与单索引的 8ms 相同——并行查询实现了几乎线性的容量扩展。四、搜索的 A/B 测试与延迟预算分配搜索系统的迭代中每新增一个模型或策略需要确认其对全链路延迟的影响。在 A/B 实验中延迟指标需要拆分为分阶段指标如果实验组的 Query 理解阶段延迟从 20ms 降至 10ms因模型优化但精排阶段延迟从 100ms 增至 120ms新模型更复杂全链路延迟从 120ms 降至 130ms——虽然在增加但需要量化是哪个阶段的问题。在不同阶段的延迟预算中设置固定配额——Query 理解 30ms、多路召回 50ms、精排 120ms。任何阶段超预算 10% 时自动触发告警并阻塞该阶段的变更上线。这种延迟预算分配机制类似于网络中的 QoS——防止某个团队为了优化自己的模型效果如精排团队加入更多特征而侵占全局延迟预算伤害用户体验。五、总结搜索场景的 AI 推理优化与推荐系统共享许多技术批量推理、Embedding 缓存、多级漏斗但 Query 理解的实时性和单请求特性使蒸馏成为核心优化路径。用 12M 参数的 BERT-tiny 蒸馏 8B 的 Llama-3在 Query 意图理解上获得 30 倍加速精度仅下降 2%——这是搜索系统中最值得的投入产出比优化。语义向量召回的 GPU 加速通过 FP16 PQ 压缩将显存需求从 15GB 降至 1GB使 1000 万级的商品向量在一张 T4 16GB GPU 上即可完成向量检索。分片索引进一步支持亿级规模——8 个分片并行查询容量线性扩展延迟几乎不增加。全链路的延迟预算分配是搜索团队协同的必备机制。将总延迟 200ms 分解为 3 个阶段的 SLO 配额在 CI/CD 中的回归检测中自动判别每个阶段的延迟是否超预算。这样避免了跨团队的「延迟泥巴战」——每个团队都加一点延迟累积到用户层面已经不可接受。
