#### 为什么 AI 听不懂你的提问？

你有没有遇到过这样的情况：

明明自己已经把问题说得很清楚了，AI 给出的回答却总是不尽人意。你让它帮你找资料，它却找不到重点；你问它一个复杂的问题，它给出的答案看似全面，却偏偏没有回答到你真正关心的地方。

于是，你可能会想：是不是我的提示词写得不够好？是不是应该换一种问法？

其实，问题可能不只是出在提示词上。

**一个好的 AI，不仅要理解你问了什么，还要知道你真正想解决什么问题，以及应该通过什么方式找到答案。**

举个简单的例子。

当你问豆包：“帮我找出时间最短的视频。”

这句话看起来很明确，但如果让 AI 直接去检索相关文档，它真的知道应该怎么做吗？

什么叫“时间最短”？应该比较视频的播放时长，还是发布时间？如果数据库中存储了大量视频信息，究竟应该依据哪个字段进行排序？

要让 AI 准确地完成这个任务，仅仅理解自然语言还不够。它还需要将你的问题转换成明确的检索条件，甚至判断应该调用哪一种工具、查询哪一个数据源。

这就引出了 RAG（检索增强生成）中的两个重要技术：**查询重构（Query Rewriting）与查询路由（Query Routing）**。

前者解决的是“用户的问题应该如何表达，才能更好地检索”；后者解决的是“这个问题应该交给谁处理，才能得到正确的结果”。

接下来，我们就从实际案例出发，看看这两项技术是如何让 AI 更准确地理解问题、检索信息并生成答案的。

### 1.为什么需要查询重构与分发这个技术？

**传统查询流程**：  
用户问题 ---> 检索相关文档 ---> LLM根据相关文档回答

**假如** query: 找出时间最短的视频  
此时，没有一个值去衡量检索标准（什么才叫时间短？怎么比较时间长短？用什么作为依据？）

这个时候就需要查询重构。以**提示词工程方法**为例，构建提示词

```python
# 使用大模型将自然语言转换为排序指令

prompt = f"""你是一个智能助手，请将用户的问题转换成一个用于排序视频的JSON指令。
你需要识别用户想要排序的字段和排序方向。
- 排序字段必须是 'view_count' (观看次数) 或 'length' (时长) 之一。
- 排序方向必须是 'asc' (升序) 或 'desc' (降序) 之一。
  
例如:
- '时间最短的视频' 或 '哪个视频时间最短' 应转换为 {{"sort_by": "length", "order": "asc"}}
- '播放量最高的视频' 或 '哪个视频最火' 应转换为 {{"sort_by": "view_count", "order": "desc"}}
请根据以下问题生成JSON指令:
原始问题: "{query}"

JSON指令:"""
```

明确要求LLM，如果遇到“时间最短”这类关键词，就转换为 用length 排序，按照升序排列。就能很好解决用户问题**模糊不清**的情况。

于是，查询流程进阶为：  
用户问题 ---> **查询处理（重构，路由）**\---> 检索相关文档 ---> LLM根据相关文档回答

### 2.查询翻译（查询重构）

实现方式主要有四种：

-   提示工程
-   多分解查询（multi-query)
-   退步提示（Step-Back prompting）
-   假设性文档嵌入（HyDE）

**2.1提示工程**：  
提示工程是最直接的查询重构方法。通过精心设计的提示词（Prompt），可以引导 LLM 将用户的原始查询改写得更清晰、更具体，或者转换成一种更利于检索的叙述风格。

还是用上面的例子：找出时间最短的视频  
（1）：**设计一个新的提示词（Prompt），要求 LLM 输出 JSON 格式的排序指令。**  
通过 Few-Shot prompting（少样本提示）方式，在提示词中构建几个 **“输入 -> 输出”** 示例，当LLM遇到同类问题时，就会学习这样的模式。

```python
# 使用大模型将自然语言转换为排序指令

prompt = f"""你是一个智能助手，请将用户的问题转换成一个用于排序视频的JSON指令。
你需要识别用户想要排序的字段和排序方向。
- 排序字段必须是 'view_count' (观看次数) 或 'length' (时长) 之一。
- 排序方向必须是 'asc' (升序) 或 'desc' (降序) 之一。
  
例如:
- '时间最短的视频' 或 '哪个视频时间最短' 应转换为 {{"sort_by": "length", "order": "asc"}}
- '播放量最高的视频' 或 '哪个视频最火' 应转换为 {{"sort_by": "view_count", "order": "desc"}}
请根据以下问题生成JSON指令:
原始问题: "{query}"

JSON指令:"""
```

(2):**在代码中调用 LLM，解析其返回的 JSON 指令，并执行相应的排序操作。**

```python
# ... (前略，初始化LLM客户端)
# 请求LLM生成指令，并指定返回JSON格式
response = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "user", "content": prompt}
    ],
    temperature=0,
    response_format={"type": "json_object"}
)

# 解析指令并执行排序

try:
    import json
    instruction_str = response.choices[0].message.content
    instruction = json.loads(instruction_str)
    print(f"--- 生成的排序指令: {instruction} ---")
  
    sort_by = instruction.get('sort_by')
    order = instruction.get('order')

    if sort_by in ['length', 'view_count'] and order in ['asc', 'desc']:
        # 在代码中执行排序
        reverse_order = (order == 'desc')
        sorted_docs = sorted(all_documents, key=lambda doc: doc.metadata.get(sort_by, 0), reverse=reverse_order)
        # 获取排序后的第一个结果并打印
        if sorted_docs:
            doc = sorted_docs[0]
            # ... (打印结果的代码)

except (json.JSONDecodeError, KeyError) as e:
    print(f"解析或执行指令失败: {e}")
```

**2.2多分解查询：**  
当用户提出一个复杂的问题时，直接用整个问题去检索可能效果不佳，因为它可能包含多个子主题或意图。分解技术的核心思想是将这个复杂问题拆分成多个更简单、更具体的子问题。然后，系统分别对每个子问题进行检索，最后将所有检索到的结果合并、去重，形成一个更全面的上下文，再交给 LLM 生成最终答案。

**简单来说：** 对原始问题分解为不同角度的多个子问题，并行回答，将检索答案去重合并，传送给LLM。

**示例**：

-   **原始问题**：“在《流浪地球》中，刘慈欣对人工智能和未来社会结构有何看法？”
-   **分解后的子问题**：
    -   “《流浪地球》中描述的人工智能技术有哪些？”
    -   “《流浪地球》中描绘的未来社会是怎样的？”
    -   “刘慈欣关于人工智能的观点是什么？”

LangChain 提供了 `MultiQueryRetriever` 来完成这一过程[1](https://datawhalechina.github.io/all-in-rag/#fn-1 "1")。它在内部利用 LLM 将原始问题从不同角度分解成多个子问题，然后并行为每个子问题检索相关文档。最后，它将所有检索到的文档合并并去重，形成一个更全面的上下文，再传递给语言模型生成最终答案。通过这种策略，极大地丰富了检索结果，在有些应用中可以有效提升后续生成环节的质量。

**2.3退步提示：**  
**简单解释：** 先回答抽象问题背后的原理，再进行推理。

其核心流程分为两步：

（1）**抽象化**：首先，引导 LLM 从用户的原始具体问题中，生成一个更高层次、更概括的“退步问题”（Step-back Question）。这个退步问题旨在探寻原始问题背后的通用原理或核心概念。  
（2）**推理**：接着，系统会先获取“退步问题”的答案（例如，一个物理定律、一段历史背景等），然后将这个通用原理作为上下文，再结合原始的具体问题，进行推理并生成最终答案。

**示例**：

-   **原始问题**：“如果理想气体的温度增加2倍，体积增加8倍，其压力会如何变化？”
-   **退步问题**：“这个问题背后的物理原理是什么？”
-   **推理过程**：首先回答退步问题，得到“理想气体定律 PV=nRT”。然后基于这个定律，代入具体数值进行计算，最终得出压力变为原来的1/4。

通过先检索或生成高层知识，再进行具体推理，退步提示能够帮助模型构建一个更坚实的逻辑基础，从而提高在复杂问答场景下的准确性。

**2.4假设性文档嵌入：**  
**简单解释：** query（我上个月工资交了多少税？）---(使用LLM生成有关税收的文档A)--> 用生成的文档A在真实知识库中检索最相近的文档B（C D E...) ---> 这些检索出来的B（C D E...)就是最终的上下文。

**实现流程：**  
（1）**生成**：当接收到用户查询时，首先调用一个生成式 LLM（例如，GPT-3.5）。提示该模型根据查询生成一个详细的、可能是理想答案的文档。这个文档不必完全符合事实，但它必须在语义上与一个好的答案高度相关。

（2）**编码**：将上一步生成的假设性文档输入到一个对比编码器（如 Contriever）中，将其转换为一个高维向量嵌入。这个向量在语义上代表了一个“理想答案”的位置。

（3）**检索**：使用这个假设性文档的向量，在向量数据库中执行相似性搜索，找出与这个“理想答案”最接近的真实文档。这些被检索出的文档将作为最终的上下文信息。

### 3.查询路由（分发）

**应用场景：**

1.  **数据源路由**：这是最常见的场景。根据查询意图，将其路由到不同的知识库。例如：
    -   查询“最新的 iPhone 有什么功能？” -> 路由到**产品文档向量数据库**。
    -   查询“我上次订购了什么？” -> 路由到**用户历史SQL数据库**（执行Text-to-SQL）。
    -   查询“A公司和B公司的投资关系是怎样的？” -> 路由到**企业知识图谱数据库**。
2.  **组件路由**：根据问题的复杂性，将其分配给不同的处理组件，以平衡成本和效果。
    -   简单FAQ → 直接进行向量检索，速度快、成本低。
    -   复杂操作或需要与外部API交互 → 调用 Agent 来执行任务。
3.  **提示模板路由**：为不同类型的任务动态选择最优的提示词模板，以优化生成效果。
    -   数学问题 → 选用包含分步思考（Step-by-Step）逻辑的提示模板。
    -   代码生成 → 选用专门为代码优化过的提示模板。

**实现方法：**

（1）：基于LLM的意图识别

通过设计一个包含路由选项的提示词，让大语言模型（LLM）直接对用户的查询进行分类，并输出一个代表路由选择的标签。

**第一步：定义分类器**

首先创建一个 `classifier_chain`，它的任务是读取用户问题，并利用 LLM 的理解能力给问题打上分类标签（例如 '川菜', '粤菜', '其他'）。

```python
# 假设 llm 已经定义
classifier_prompt = ChatPromptTemplate.from_template(
    """根据用户问题中提到的菜品，将其分类为：['川菜', '粤菜', 或 '其他']。
    不要解释你的理由，只返回一个单词的分类结果。
    问题: {question}"""
)
classifier_chain = classifier_prompt | llm | StrOutputParser()
```

**第二步：定义路由分支**

接着，使用 `RunnableBranch` 来定义路由规则。它就像一个 `if-elif-else` 语句，根据输入的 `topic` 字段来选择执行哪一个处理链（`sichuan_chain`, `cantonese_chain` 或 `general_chain`）。

```python
# 假设 sichuan_chain, cantonese_chain, general_chain 已定义
router_branch = RunnableBranch(
    (lambda x: "川菜" in x["topic"], sichuan_chain),
    (lambda x: "粤菜" in x["topic"], cantonese_chain),
    general_chain  # 默认选项
)
```

**第三步：组合完整路由链**

最后，将分类器和路由分支组合起来。这个 `full_router_chain` 首先会并行执行两个操作：用 `classifier_chain` 为问题生成 `topic`，同时保留原始的 `question`。然后，它将这个包含 `topic` 和 `question` 的字典传递给 `router_branch`，由后者根据 `topic` 做出最终的路由决策。

```python
full_router_chain = {"topic": classifier_chain, "question": lambda x: x["question"]} | router_branch

# 调用示例
result = full_router_chain.invoke({"question": "麻婆豆腐怎么做？"})
```

（2）嵌入相似性路由

这种方法不依赖 LLM 进行分类，延迟更低。它通过计算用户查询与预设的“路由示例语句”之间的向量嵌入相似度来做出决策。

**第一步：定义路由描述并向量化**

为每个路由创建一个详细的文本描述，并使用嵌入模型将其转换为向量，供后续相似度计算使用。

```python
# 假设 embeddings 模型已经初始化
sichuan_route_prompt = "你是一位处理川菜的专家。用户的问题是关于麻辣、辛香、重口味的菜肴，例如水煮鱼、麻婆豆腐、鱼香肉丝、宫保鸡丁、花椒、海椒等。"
cantonese_route_prompt = "你是一位处理粤菜的专家。用户的问题是关于清淡、鲜美、原汁原味的菜肴，例如白切鸡、老火靓汤、虾饺、云吞面等。"

route_prompts = [sichuan_route_prompt, cantonese_route_prompt]
route_names = ["川菜", "粤菜"]
route_prompt_embeddings = embeddings.embed_documents(route_prompts)
```

**第二步：定义目标链**

创建路由最终要分发到的目标处理链，并用一个字典 `route_map` 将路由名称和链对应起来。

```python
# 假设 llm 已经定义
sichuan_chain = (
    PromptTemplate.from_template("你是一位川菜大厨。请用正宗的川菜做法，回答关于「{query}」的问题。")
    | llm
    | StrOutputParser()
)
cantonese_chain = (
    PromptTemplate.from_template("你是一位粤菜大厨。请用经典的粤菜做法，回答关于「{query}」的问题。")
    | llm
    | StrOutputParser()
)

route_map = { "川菜": sichuan_chain, "粤菜": cantonese_chain }
```

**第三步：定义路由函数**

定义一个 `route` 函数，接收用户问题，计算与各路由描述的相似度，选择最相似的路由并调用相应的处理链。

```python
def route(info):
    # 1. 对用户查询进行嵌入
    query_embedding = embeddings.embed_query(info["query"])
    
    # 2. 计算与各路由提示的余弦相似度
    similarity_scores = cosine_similarity([query_embedding], route_prompt_embeddings)[0]
    
    # 3. 找到最相似的路由名称
    chosen_route_index = np.argmax(similarity_scores)
    chosen_route_name = route_names[chosen_route_index]
    
    # 4. 获取并调用对应的处理链，返回结果
    chosen_chain = route_map[chosen_route_name]
    return chosen_chain.invoke(info)
```

**第四步：组合并调用**

最后，将 `route` 函数包装成一个 `RunnableLambda`，形成一个完整的、可执行的路由链。

```python
full_chain = RunnableLambda(route)

# 调用示例
result = full_chain.invoke({"question": "如何做一碗清淡的云吞面？"})
```

明明自己已经把问题说得很清楚了，AI 给出的回答却总是不尽人意。你让它帮你找资料，它却找不到重点；你问它一个复杂的问题，它给出的答案看似全面，却偏偏没有回答到你真正关心的地方。

一文搞懂为什么 AI 听不懂你的提问？

人工智能

架构设计

算法

AI问答效果不佳，根源在于模糊查询。RAG技术中的查询重构与路由是关键解法：前者通过提示工程、多分解查询、退步提示等方法，将模糊问题转译为精确检索指令；后者则智能分发问题至正确数据源或组件，从而显著提升回答精准度与相关性。

向量数据库

提示词工程

知识图谱

SQL数据库

代码解释

LangChain

数据库

DeepSeek

路由

Agent

JSON

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

一文搞懂为什么 AI 听不懂你的提问？-腾讯云开发者社区-腾讯云

一文搞懂为什么 AI 听不懂你的提问？

一文搞懂为什么 AI 听不懂你的提问？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐