微信客服的 RAG，怎么在 BM25、向量检索和混合检索之间选型？

先这样答

微信客服的 RAG 默认选混合检索。BM25 和向量检索分别召回，再用 RRF 融合，最后做重排精排。选型先看查询形态。客服既会遇到带明确编号的问题，也会遇到口语描述的问题。两类查询都高频，所以我不会只凭其中一类问题决定整个客服场景的检索方式。

订单号、政策编号、产品型号这类查询属于精确类，BM25 更稳。用户用口语描述问题时，向量检索更强。这里的判断依据是用户怎么提问。用户给出明确对象，我要保留 BM25 对精确类查询的优势；用户用自然语言描述，我要用向量检索应对口语表达。只选 BM25 或只选向量，都会放弃另一类查询需要的优势。

生产方案是两路召回、RRF 融合、重排精排。RRF 融合两路结果，重排再做精排。资源不足时，我先砍重排，保留混合召回。如果还要退化，就退到纯向量；精确类查询为主的场景则退到 BM25。这是资源受限时的取舍，不改变常规方案的判断：客服场景混合是必选项。面试里我会把默认方案和退化顺序一起说清楚。

面试官会怎么追问

• 「为什么客服不能直接只用向量检索？」 口语描述类查询适合向量检索，但客服也常见订单号、政策编号和产品型号。面对这些精确类查询，BM25 更稳。只用向量，就没有用上 BM25 在这类问题上的优势。
• 「RRF 融合之后，为什么还要重排？」 两路召回先分别给出结果，RRF 负责融合。重排负责后续精排。资源够时我保留这一步；资源不够时，我先砍重排，而不是先砍掉一路召回。
• 「如果资源只够跑一路，你选哪一路？」 默认退到纯向量。若问题以订单号、政策编号、产品型号等精确类查询为主，我退到 BM25。这个选择仍然取决于查询形态，不能脱离客服实际收到的问题回答。

回答的坑

• 只说向量检索更适合口语问题，却漏掉订单号、政策编号和产品型号这类精确查询。
• 把资源不足说成直接放弃混合召回，跳过了先砍重排的退化顺序。