RAG 系列（十三）：查询优化——让问题问得更好

问法不同，结果截然不同

向量检索有一个容易被忽视的脆弱性：同一个问题换个说法，检索结果可能完全不同。

“BGE 模型在中文上效果怎么样” 和 “中文 Embedding 推荐哪个” 语义高度相似，但它们的 embedding 向量在高维空间中的位置可能相差不少，导致检索到的文档集合差异很大。

这是 Bi-Encoder 的结构性问题：embedding 是在 query 和 doc互不知情的情况下各自计算的，对措辞的微妙变化非常敏感。

上一篇我们优化了文档侧——更好的分块策略让文档更容易被找到。本篇从问题侧入手：在把问题送进向量库之前，先对问题本身做一些处理，让它的召回效果更稳定、更全面。

三种策略：

1. Multi-Query：生成多个问法，多角度检索后合并
2. HyDE：先生成假设答案，用答案去检索
3. Query Decomposition：把复杂问题拆成多个子问题

Multi-Query：多角度问法扩大召回面

核心思路

一个问题对应向量空间中的一个点，这个点可能恰好和某些相关文档距离较远。如果能从多个方向逼近，就能覆盖更大的区域。

原始问题 → LLM 改写 → [问法1, 问法2, 问法3] ↓ 分别检索，合并去重 ↓ 取前 TOP-K 返回

代码实现

fromlangchain_classic.retrieversimportMultiQueryRetriever MULTI_QUERY_PROMPT=ChatPromptTemplate.from_messages([("system","你是一个专业的问题改写助手。"),("human","请将以下问题改写为 3 个不同的表达方式，从不同角度提问，""以便在向量数据库中检索到更多相关内容。\n""每行输出一个问题，不要编号，不要解释。\n\n""原始问题：{question}"),])# 方式一：使用 LangChain 内置封装retriever=MultiQueryRetriever.from_llm(retriever=vectorstore.as_retriever(search_kwargs={"k":4}),llm=llm,)# 方式二：手动实现，可以控制 Prompt 和合并逻辑multi_query_chain=MULTI_QUERY_PROMPT|llm|StrOutputParser()variants_text=multi_query_chain.invoke({"question":question}