BP3 · 向量召回与精排管道#

定位：面试官追问召回管道设计与选型决策时的拷问预备。

---

核心口述（30 秒）#

“三阶段召回：BGE-M3 dense 编码 → Qdrant 向量搜索 + 多维 payload filter → BGE-Reranker 精排。经历三次选型修订：Faiss 纯 dense → Qdrant hybrid → 最终 dense+filter+精排。核心洞察：exact-match 是 filter 问题不是打分问题。“

---

拷问链#

Q: 为什么不用 hybrid（dense + sparse）？#

品牌/型号是结构化字段，Qdrant payload filter 直接解决。sparse 腿增加复杂度（融合查询 filter 坑），删掉更简单。

Q: 跨语言怎么做到的？#

BGE-M3 原生多语言能力，中文 query 和英文商品在同一向量空间。不需要翻译。

Q: 138 万商品 amazon 占 99.75%，搜出来全是 amazon？#

是数据分布问题不是 bug。platform filter 可以指定平台。all 搜确实全是 amazon——因为其他平台只有几千条。

Q: 精排为什么不总是开？#

本地 Jaccard 回退是 stub，跨语言零重叠空转。只在配了真 reranker（SiliconFlow API）时重排。

Q: 为什么不自训 embedding？#

无 GPU。BGE-M3 API 跨语言能力足够。自训需要大量标注数据 + GPU，投入产出比不合理。

Q: Qdrant 融合查询 filter 静默失效怎么发现的？#

测试发现 platform=“amazon” 过滤不起作用，debug 到 Qdrant Query API 融合模式下顶层 filter 不传播。必须放进每条 prefetch。

---

压力题#

Q: 这个召回管道能扛住 1000 QPS 吗？#

当前单节点 Qdrant，扛不住。升级路径：Qdrant 分布式集群 + read replica + embedding 批量预计算。瓶颈不在 Qdrant 而在 LLM——1000 QPS 的 Agent 调用意味着数千个 LLM 请求同时在飞。