基于本文回答

播面 播面

文图音视，全方位拆解八股文
0
评论
请从左侧选择一个分类

在 RAG 中，如何解决用户的 Query 非常简短或指代不明的问题（Query Understanding）？

知识点图片

在 RAG（检索增强生成）系统中，用户的 Query 往往是非结构化的、口语化的，甚至是非常简短或充满指代词（如“它”、“那个”）的。这种 Query 与知识库中高质量、详细的文档之间存在巨大的语义鸿沟（Semantic Gap），直接检索往往效果很差。

解决这一问题通常需要引入 Query Understanding (QU) 模块，主要通过以下几个维度的策略来优化：

1. 基于 LLM 的 Query 改写（Query Rewriting）

这是目前最主流且有效的方法。利用 LLM 强大的语义理解能力，将原始的“烂”Query 转化为适合检索的“好”Query。

  • 指代消解（Coreference Resolution）：

    • 场景： 用户在多轮对话中说“它多少钱？”。
    • 方法： 将当前 Query 结合历史对话上下文（Chat History）输入 LLM，要求 LLM 生成一个独立的问题（Standalone Question）。
    • 示例：
      • History: "iPhone 15 Pro Max 有哪些颜色？" -> "有钛金属原色。"
      • User: "它多少钱？"
      • Rewritten: "iPhone 15 Pro Max 的价格是多少？"

  • 查询扩展（Query Expansion）：

    • 场景： 用户搜索词太短，如“发票”。
    • 方法： 让 LLM 基于原始词生成多个相关的子问题或同义词，扩大检索范围。
    • 示例： User: "发票" -> Expanded: "如何开具发票？"、"发票丢了怎么办？"、"发票报销流程"。

  • 意图补全（Intent Completion）：

    • 场景： 用户输入模糊，如“连不上”。
    • 方法： 结合用户画像或当前所在的页面上下文（如果是嵌入式助手），补全缺失的主语或宾语。
    • 示例： User: "连不上" (用户当前在 WiFi 设置页面) -> Rewritten: "WiFi 连接失败如何解决？"

2. HyDE (Hypothetical Document Embeddings)

对于非常简短的 Query，直接去匹配长文档很难。HyDE 的思路是“以生成的答案去检索”。

  • 原理：
    1. 接收用户简短 Query（如“退款政策”）。
    2. 让 LLM 虚构一个假设性的答案（Hallucinated Answer）。这个答案事实可能不对，但包含的相关关键词和语义结构与真实文档非常接近。
    3. 将这个虚构答案转化为向量（Embedding）。
    4. 用虚构答案的向量去知识库检索真实文档。
  • 优势： 解决了 Query 很短、文档很长导致的向量空间不匹配问题。

3. 多路查询与融合（Multi-Query & Fusion）

针对指代不明或有歧义的 Query，不要只生成一种搜索向量。

  • 多角度改写： 让 LLM 从不同角度生成 3-5 个版本的 Query。
    • User: "那个功能怎么用？"
    • LLM 生成: "数据导出功能怎么用？", "报表生成功能怎么用？", "API 接口怎么调用？"
  • RRF (Reciprocal Rank Fusion)： 将这几个 Query 分别去检索，然后用 RRF 算法对检索结果进行去重和重新排序。这样可以最大概率覆盖用户的真实意图。

4. 追问与澄清（Clarification / Ask User）

如果 Query 实在太短或歧义太大，系统不应该强行猜测（容易导致幻觉），而应该反问用户。

  • 歧义检测： 设置一个置信度阈值，或者专门训练一个轻量级分类器判断 Query 是否模糊。
  • 主动追问（Agentic Pattern）：
    • User: "我想买个苹果。"
    • RAG System (检测到歧义): "请问您是指购买水果‘苹果’，还是电子产品‘Apple’设备？"
  • 选项推荐： 结合搜索建议（Autocomplete），在用户输入简短关键词时，下拉展示可能的完整问题。

5. 结合元数据过滤（Metadata Filtering）

利用 Query 之外的显式信息来约束检索范围。

  • 场景： 用户问“价格是多少”。
  • 方法： 如果无法通过 Query 本身判断，可以利用外部 Context。
    • 用户属性： 如果用户是“企业版客户”，则自动过滤 category="enterprise" 的文档。
    • 时间范围： 如果用户问“最近的新闻”，自动过滤 date="last_month"。
    • 当前页面： 如果用户在“API 文档”页面提问，优先检索技术文档库。

6. 后处理：重排序（Reranking）

在检索回一堆可能相关的文档后，利用 Cross-Encoder 模型进行精细筛选。

  • 原理： 即使 Query 很短（如“报错”），检索阶段可能会召回 50 个包含“报错”的文档。Rerank 模型可以根据语义相关性，将真正描述“常见报错解决方案”的文档排在前面，而将“报错日志格式说明”排在后面。
  • 作用： 弥补简短 Query 在向量检索（Bi-Encoder）阶段精度不足的问题。

总结与推荐流程

针对简短或指代不明的 Query，一个成熟的 RAG 链路通常是这样的：

  1. 输入： 用户 Query ("它怎么坏了？") + 对话历史。
  2. 改写 (Rewriting): LLM 结合历史生成独立 Query ("空调遥控器为什么不显示数字了？")。
  3. 判断 (Router):
    • 如果 Query 依然模糊 -> 触发追问机制。
    • 如果 Query 包含特定意图 -> 提取元数据 (Metadata Extraction)。
  4. 扩展 (Expansion/HyDE): 生成假设性答案或同义词。
  5. 检索 (Retrieval): 混合检索 (关键词 + 向量)。
  6. 重排 (Rerank): 筛选最相关文档。
  7. 生成 (Generation): 回答用户。
00:00
00:00