从对话到搜索：基于LLM的上下文感知Query重写实战解析

1. 会话搜索的挑战与LLM的机遇

多轮对话中的搜索意图理解一直是个技术难题。想象一下这样的场景：用户先问"iPhone 15有什么新功能"，接着问"续航怎么样"，最后突然来一句"值得买吗"。传统搜索引擎面对这种碎片化的对话时，往往只能孤立处理每个query，完全丢失了上下文关联。这正是我们团队去年做电商客服系统时踩过的坑——当用户连续询问"这件衣服材质"、"适合什么季节穿"、"机洗会缩水吗"时，系统给出的答案总是不尽如人意。

人大的LLM4CS框架给了我们新思路。他们发现大模型就像个"对话侦探"，能通过三种独特方式还原用户真实意图：

• 场景还原：自动补全省略的上下文（把"续航怎么样"还原成"iPhone 15的续航表现如何"）
• 意图串联：关联分散的多轮提问（将"材质"-"季节"-"机洗"识别为完整的购买决策链）
• 假设推演：生成可能的回答来反推需求（通过预测"这款衣服机洗会轻微缩水"来强化搜索条件）

在实际测试中，我们先用BERT模型处理了10万条电商对话数据，发现仅使用当前query的搜索准确率只有43%。而加入LLM生成的上下文重写后，这个数字直接飙到67%。最让我意外的是，模型甚至能自动纠正用户的口语化表达——把"这玩意儿耐造不"改写成"该产品的抗摔性能如何"。

2. 三大核心重写策略详解

2.1 REW基础重写法

这是最直接的实现方式，适合刚开始尝试的团队。我们给GPT-3.5的prompt是这样的：

prompt = f""" 你是一个专业的搜索优化助手。请根据以下对话历史重构当前问题： 历史对话：{context} 当前问题：{query} 重构要求： 1. 保留原始问题的核心意图 2. 补充对话中隐含的上下文信息 3. 输出标准化的搜索语句 示例： 输入：历史对话=[用户：Python怎么安装包？ 客服：可以用pip install] 当前问题：更新呢？ 输出：如何用pip更新已安装的Python包？ """

实测发现三个优化点：

1. 温度系数：temperature=0.3时生成最稳定（我们试过0.1-0.7的范围）
2. 历史截断：当对话超过5轮时，只保留最近3轮效果更好
3. 领域限定：加入"你专注电商领域"等限定词可减少无关扩展

2.2 RTR应答增强法

这个方法在微软的Bing Chat里早有应用。关键点在于：

1. 让模型先生成假设回答
2. 把回答中的关键信息反哺给搜索query
3. 采用"5倍query+回答"的拼接策略

我们优化后的prompt结构：

[系统指令] 你正在处理一个关于{领域}的客户咨询。请执行： 1. 基于对话历史重写当前问题 2. 生成一个假设性专业回答 3. 按格式输出： 改写原因：<解释补充了哪些上下文> 重写问题：<标准化的问题> 假设回答：<2-3句话的简要回答> [示例] ... [当前任务] 对话历史：{context} 当前问题：{query}

在智能硬件客服系统中，这个方法让搜索准确率又提升了11%。比如用户问"这个路由器穿墙怎么样"，模型会自动补充"该款AX6000规格路由器的5GHz频段穿墙性能测试结果"这样的专业表述。

2.3 RAR多维拆解法

面对复杂问题时，我们会启动这个"分而治之"模式。最近处理的一个典型案例：

原始问题："我想组个能玩3A大作还能直播的电脑，预算1万左右"

模型自动拆解为：

1. "1万元预算下适合直播的游戏主机配置推荐"
2. "当前主流3A游戏对显卡的具体需求"
3. "游戏直播对CPU和内存的特殊要求"

实现关键是这个prompt设计技巧：

def build_prompt(context, query): return f""" 请将以下复杂问题拆解为3-5个子问题： 1. 每个子问题应聚焦单一维度 2. 保持原始问题的约束条件（如预算） 3. 输出格式： - 原始问题：{query} - 拆解逻辑：<解释拆分依据> - 子问题列表： 1. <问题1> 2. <问题2> ... """

3. 意图聚合的工程实践

3.1 向量化处理流水线

我们建立的完整处理流程：

1. 编码层：

   • 用all-MiniLM-L6-v2模型生成512维向量
   • 对长文本采用滑动窗口均值池化

2. 聚合层：

   def aggregate_queries(rewrites, method='SC'): if method == 'Mean': return np.mean(rewrites, axis=0) elif method == 'SC': centroid = np.mean(rewrites, axis=0) similarities = [cosine_similarity([vec], [centroid]) for vec in rewrites] return rewrites[np.argmax(similarities)] else: # MaxProb return rewrites[0] # 默认取第一个

3. 搜索层：

   • 聚合向量与文档向量的余弦相似度
   • 加入BM25作为混合排序信号

3.2 性能优化技巧

在压力测试中发现的几个关键经验：

1. 缓存机制：

   • 对相同会话hash值缓存聚合结果
   • TTL设置为30分钟（典型会话时长）

2. 降级策略：

   • 当延迟>300ms时自动切换为REW模式
   • 错误率超过5%时禁用RAR拆解

3. 监控指标：

   # Prometheus监控关键指标 llm_rewrite_latency_seconds_bucket{method="REW"} 0.2 llm_rewrite_success_rate{method="RTR"} 0.98 search_conversion_after_rewrite 0.67

4. 效果验证与调优心得

在电商知识库上做的AB测试显示：

指标	原始query	REW	RTR	RAR
首条准确率	38%	62%	71%	75%
点击率	12%	23%	28%	31%
平均响应时间	120ms	210ms	280ms	350ms

几个出乎意料的发现：

1. 思维链的魔力：在prompt中加入"请逐步思考"指令，能让RAR的拆解质量提升19%
2. 负样本注入：在示例里故意包含错误改写案例，反而使模型抗干扰能力更强
3. 长度惩罚：对生成query超过50个字符的结果进行惩罚，避免过度扩展

最近我们正在尝试将这套方案移植到智能音箱场景。遇到的最大挑战是语音query的模糊性处理——当用户说"刚才那个"时，模型需要结合声纹识别、设备交互历史等多模态信息来重写query。这可能是下一个技术突破点。