Qdrant 电商搜索实战：混合检索、内存量化与个性化排名的架构演进

在构建电商搜索系统时，相关性、过滤、个性化、商品展示和推荐通常被拆分为五个独立服务，最终排名由多方拼凑而成。Qdrant 团队通过搭建 Qdrant Shopping（基于 580 万真实亚马逊时尚商品数据），探索了这些模块如何收敛为单一高效架构。其核心发现是：通过 Query API 实现毫秒级响应，将检索、过滤与排序统一在向量数据库中完成。

核心架构突破：从“五步走”到“一步到位”

1. 混合检索是标配：BM25 与向量的融合

商品查询本质是双重需求：一部分是精确匹配（品牌、型号、SKU），另一部分是意图匹配（如“适合徒步的保暖衣物”）。

• 策略：同时构建 Dense Vector（基于标题和类别）和 BM25 Sparse Vector（基于标题、品牌、类别）。
• 融合：在单次 Query API 请求中，利用 Reciprocal Rank Fusion (RRF) 将两个分支的结果融合。
• 价值：避免了传统架构中先检索后过滤导致的“空结果”问题，也解决了纯向量检索无法匹配精确关键词的痛点。

2. 过滤内嵌于查询：拒绝“先搜后滤”

传统做法是先检索 Top 100 候选再应用过滤，若库存不足或规格不符，页面极易变空。

• Qdrant 方案：利用 Filterable HNSW 图结构，在检索阶段直接应用过滤条件（如价格区间、库存状态）。
• 性能提升：仅对匹配的产品进行打分，避免了无效计算。同时，侧边栏的 Facet Counts 直接来源于同一 Payload，确保数据一致性。

3. 模型选择：小模型 + 精准 Embedding > 大模型

团队曾误以为需要更大模型来解决“按品牌而非按衣物排序”的 Bug，实则是输入文本（Embedding Input）设计不当。

• 关键发现：仅使用标题作为 Embedding 输入会导致品牌词主导向量。加入 Product Category 后，所有模型均表现稳定。
• 性能对比：
  • MiniLM (384 维): 精度@10 为 90.3%，延迟 ~40ms，RAM 仅 1.9GB。
  • 大模型 (1024 维): 精度@10 仅提升 2 个百分点，但延迟飙升至 ~180ms，RAM 占用 6GB。
• 结论：对于 580 万商品库，大模型带来的精度提升（2%）无法抵消其 4.5 倍的延迟和 3 倍的内存成本。建议优先优化 Embedding 配方，而非盲目升级模型。

4. 内存量化与跳过重排序 (Rescore)

• 存储策略：向量在 RAM 中存储为 int8，原始 float32 数据保留在磁盘。
• 去重排序 (Rescore)：传统做法会在检索后读取磁盘原始向量进行重排序以消除量化误差。
• 实测结果：Rescore 最多仅提升 2 点 Recall@10，但将查询时间从 41ms 延长至 334ms（延迟增加 4.5-8 倍）。
• 结论：由于 RRF 融合机制本身能平滑量化噪声，且重排序涉及昂贵的磁盘 I/O，跳过 Rescore 是更优选择。

5. 个性化：从检索阶段移至排名阶段

• 早期尝试：将用户偏好向量作为第三分支参与检索，导致搜索“牛仔裤”时返回“法兰绒衬衫”（因用户偏好）。
• 优化方案：将个性化移至 Ranking 阶段。
  • 机制：文本查询决定“哪些商品合格”，用户偏好仅用于“重新排序”。
  • 权重：经过测试，权重 0.45 是最佳平衡点。相比 0.6 的权重，它在保持高召回率（0.82 vs 0.79）的同时，将 Top 10 中的无关推荐从 1.7 个降至 0.03 个。
• 冷启动与无意图场景：无历史用户使用纯文本排名；无文本查询（如落地页）则完全由偏好驱动。

6. 商品化即权重组合

利润率、热度、新鲜度、价格、评分和库存等商业信号不应由独立服务处理，而应通过 Formula Query 在融合后进行重排序，直接组合 Payload 字段生成最终分数。

关键技术指标 (Metrics)

总结

Qdrant 的电商搜索实践表明，高性能搜索系统的关键不在于堆砌算力，而在于架构的简洁性与数据流的优化。通过 混合检索 解决语义与精确匹配矛盾，利用 内存量化 换取极致速度，并将 个性化 与 商品化 逻辑下沉至排名阶段，开发者可以构建出既快又准的搜索体验。这套方案不仅适用于电商，对任何大规模产品目录的搜索优化都具有极高的参考价值。