RAG用户查询太模糊？

RAG用户查询太模糊？三种查询扩展方法让检索更精准

在使用RAG（检索增强生成）系统时，你是否遇到过这样的情况：用户问"今天去哪里好玩"，结果系统返回一堆游乐园、公园、博物馆的泛泛介绍，完全不符合用户的实际需求？这是因为用户查询往往口语化、缺乏上下文，导致大模型难以准确理解意图，检索到的内容自然也就"答非所问"。

要解决这个问题，我们需要对用户查询进行扩展，让模糊的问题变得清晰、具体。本文将介绍三种实用的查询扩展方法，并通过旅游场景的例子，让你直观感受它们如何提升RAG的检索效果。

用户输入查询时，通常不会像搜索引擎那样精心构造关键词，而是用日常语言随口一问。比如：

这类问题缺少关键信息：是和谁去？预算多少？喜欢什么类型？大模型在没有上下文的情况下，只能从知识库中召回所有可能相关的内容，结果就是答案宽泛、不贴心。

因此，我们需要在检索之前，先对查询进行"加工"，补充背景、明确意图。

最直接的方法就是让大模型自己把问题改得更具体。比如，用户问"我想去好玩的地方"，我们可以利用历史对话或默认场景（如家庭出游）将问题改写为：

"推荐一些适合亲子游的景点，最好有儿童设施和互动项目。"

改写后的问题包含了明确的受众（亲子）和需求（儿童设施），检索时就能更精准地命中相关文档。

优点：简单有效，能快速提升检索相关性。
缺点：改写依赖大模型的猜测，如果猜错场景，可能反而引入偏差。

HyDE（Hypothetical Document Embeddings）是一种更聪明的扩展方式。它先让大模型根据用户查询生成一个假设的理想答案（即虚构的文档），然后用这个虚构答案的向量去检索真实文档。

例如，用户问"哪里适合带小朋友玩？"大模型可能会生成：

"某某主题公园拥有丰富的亲子游乐设施，包括旋转木马、水上乐园和卡通人物巡游，附近还有多家亲子餐厅......"

然后，系统用这段文字的向量去向量库中搜索，找到与它语义最接近的真实文档。因为虚构答案包含了丰富的细节，更容易匹配到真正相关的内容。

优点：能捕捉深层语义，尤其适合用户查询过于简短的情况。
缺点：生成假设答案需要额外的大模型调用，增加开销。

当查询非常复杂或宽泛时，可以将其拆解成多个子问题，分别检索后再合并结果。这就像我们出门旅游前，会先查景点，再查美食，最后综合决策。

例如，用户想找"适合带孩子玩的地方，附近还要有好吃的"。系统可以分两步走：

这种"拆解-检索-合并"的思路，其实就是让RAG系统具备类似Agent的规划能力，能处理需要多步推理的复杂问题。

优点：能处理复杂、多条件的查询，答案更全面。
缺点：实现相对复杂，需要设计子任务和执行流程。

假设我们有一个知识库，包含了大量旅游攻略、景点介绍和餐厅评价。用户输入：

"我想去好玩的地方。"

传统检索：系统直接搜索"好玩的地方"，返回一堆泛泛的景点列表，用户可能看得眼花缭乱。

方法一（问题改写）：大模型根据默认场景（比如家庭出游）将问题改写为"推荐适合亲子游的景点，要有儿童设施"。检索结果立刻聚焦到迪士尼、欢乐谷、儿童博物馆等，相关性大增。

方法二（HyDE）：系统先生成一个假设答案："某某亲子乐园有大型滑梯、水上乐园和卡通人物互动，乐园内设亲子餐厅，提供儿童套餐......"然后用它去检索，不仅找到了类似景点，还可能发现一些不太知名但同样适合亲子的"宝藏公园"。

方法三（多步检索）：系统先拆解问题：第一步找亲子景点，第二步找景点附近餐厅。执行完两步后，它会给出类似这样的推荐：

可见，三种方法层层递进，让答案从泛泛而谈变成精准贴切。

优化方法好不好，不能凭感觉，得有数据说话。我们可以构建一个小型的Ground Truth数据集，包含：

然后，用余弦相似度等指标，对比原始查询和改写查询召回的文档与期望答案的匹配度。如果改写后召回的结果更接近人工标注，就说明优化有效。

当然，评估也要结合实际业务场景，比如用户满意度、任务完成率等。

用户查询模糊是RAG系统的常见痛点，但通过问题改写、假设性答案检索、多步检索等方法，我们可以让模糊的问题变得清晰，从而大幅提升检索的精准度。这些方法各有千秋，可以根据业务场景灵活组合。