完整题目
在多Agent系统中，Query改写通常用于提升任务理解与协作效率。请说明Query改写的常见实现方式，并详细阐述：如果由你负责训练一个Query改写模块，你会如何设计数据采样策略来挑选训练Query？模型上线后，你将如何评估其实际效果？请提出具体的评估指标体系（包括离线与在线指标）。
本文目录
答案要点
- Query改写的3种实现方式（规则/模型/混合）
- 数据采样的分层策略（高频意图覆盖、长尾增强、负样本构造）
- 离线评估指标（改写准确率、意图一致性、下游任务增益）
- 在线评估指标（任务成功率、Agent协作轮数、用户满意度）
- A/B实验设计要点
Query改写的常见实现方式
| 方式 | 核心思路 | 适用场景 |
|---|---|---|
| 规则模板 | 基于正则/关键词映射，如"查一下"→"查询" | 高频、意图明确的头部Query |
| 生成式模型 | 用Seq2Seq或LLM直接生成改写结果 | 复杂、长尾、需要语义理解的Query |
| 混合架构 | 规则兜底+模型增强，或检索相似改写样例后编辑 | 生产环境主流方案，兼顾效率与效果 |
训练数据采样策略
分层采样，兼顾覆盖与效率：
- 高频意图层（60%）：从线上日志按PV采样，确保头部场景充分学习
- 长尾增强层（25%）：主动挖掘低PV但高价值Query（如失败会话、多轮交互），用聚类或不确定性采样筛选
- 边界/负样本层（15%）：
- 易混淆意图对（"取消订单"vs"退款"）
- 改写后语义漂移的bad case
- 多Agent上下文依赖的复杂Query（需携带历史状态）
质量过滤：人工标注改写对的一致性，剔除"伪等价"样本（表面相似但意图不同）。
评估指标体系
离线指标
| 指标 | 计算方式 | 目的 |
|---|---|---|
| 改写准确率 | 人工抽检改写前后意图一致性 | 核心质量 |
| BLEU/ROUGE | 与参考改写的n-gram重叠 | 辅助参考 |
| 下游任务增益 | 改写后 vs 原Query的Agent任务成功率 | 端到端价值 |
| 多样性 | 同一Query多参考的覆盖度 | 避免模式坍塌 |
在线指标
| 指标 | 说明 |
|---|---|
| 任务成功率 | 完整解决用户问题的比例（核心） |
| Agent协作轮数 | 改写后平均交互轮数是否下降 |
| 意图识别准确率 | 下游意图模型的Top-1准确率 |
| 用户满意度 | 会话结束后的显式反馈或隐式信号（如是否转人工） |
| 改写触发率 | 实际调用改写的Query占比，监控模块效用 |
A/B实验设计
- 实验组：开启Query改写 → 观察全链路指标
- 关键：分层实验（按Query类型、用户群体），避免平均效应掩盖细分场景问题
换一种问法，检查是否真正理解
场景切入
假设我们的电商客服多Agent系统里，用户说‘我要退货’，但系统里可能涉及退款、换货、取消订单好几个Agent，你会怎么改写这个Query让它们协作更高效？
层层追问
多Agent系统里，Query改写一般怎么用……那如果你要训练一个改写模型，数据从哪来？怎么挑训练样本？……线上怎么知道改得好不好？
直球架构
请设计一个Query改写模块，包括常见实现方式、训练数据采样策略和完整的评估指标体系，涵盖离线和在线指标，以及实验设计要点。
练习口述回答 · 约4分钟
- 本质是提升Agent协作效率，不是单纯改写
- 规则和模型各有利弊，混合架构是主流
- 数据采样要分层，覆盖头部和长尾
- 评估要分离线在线，核心看下游任务成功率和轮数
这道题问的是Query改写，但我觉得本质不是在问技术实现，而是问怎么让多个[[Agent]]更好地理解用户意图、减少协作中的歧义。说白了，改写只是手段，提升整个系统的任务理解效率和协作流畅度才是目的。
实现方式上，比较常见的就三种：规则模板、生成式模型、还有混合架构。规则模板适合那种高频、意图非常明确的Query，比如用户说“查一下我的订单”，你直接映射成“查询订单”就行，简单高效。但遇到长尾的、口语化的，比如“那个上周买的鞋还没到，帮我看看咋回事”，规则就抓瞎了，这时候得用生成式模型，像Seq2Seq或者微调一个LLM来改写。不过真正落地的时候，我一般不会只用一种，而是混合架构，规则兜底处理高频，模型处理复杂情况，这样效率和覆盖都能兼顾。
接下来说数据采样，如果让我来设计，我会分层来搞。第一层是高频意图层，大概占60%的数据，直接从线上日志按PV采样，保证头部场景学得足够好。第二层是长尾增强层，占25%，主动去挖掘那些PV低但高价值的Query，比如历史上失败的会话、多轮交互里用户反复改口的情况。这些用聚类或者不确定性采样挑出来，能提升模型的泛化能力。第三层是边界和负样本层，大概15%，专门构造一些容易让模型翻车的场景，比如“取消订单”和“退款”这种易混淆的意图对，或者改写后语义漂移的bad case。这里有个前提，就是要做质量过滤，人工标注改写对的一致性，剔除那些表面相似但意图不同的伪等价样本，否则模型会学到错误关联。
模型上线后怎么评估？我分两块。离线的话，核心是改写的准确率，就是人工抽检改写前后意图是否一致。另外我会看下游任务增益，比如改写后Agent的任务成功率有没有提升，这个比BLEU那些n-gram指标更实在。在线的话，我重点盯两个指标：一个是任务成功率，就是用户的问题有没有被完整解决，这是北极星指标；另一个是Agent协作轮数，改写后平均交互轮数应该下降，说明沟通更高效了。还会看用户满意度，比如会话结束后的显式反馈或者是否转人工。A/B实验设计上，我会按Query类型分层，比如高频和长尾分开看，避免平均效应掩盖了细分场景的问题。
这里我想提一个延伸点，就是改写和下游意图模型之间的协同。如果改写模块改了但意图模型识别不出来，那改写就没用。反过来，如果意图模型足够强，是不是可以简化甚至去掉改写？这个边界怎么划，我觉得值得深入讨论。
所以总结一下，我更倾向于把Query改写看成整个Agent系统的一个适配层，它的价值取决于上下游的配合。数据采样要兼顾效率和覆盖，评估要落到业务指标上，不能只看改写本身好不好。