这道题问的是Query改写,但我觉得本质不是在问技术实现,而是问怎么让多个[[Agent]]更好地理解用户意图、减少协作中的歧义。说白了,改写只是手段,提升整个系统的任务理解效率和协作流畅度才是目的。
实现方式上,比较常见的就三种:规则模板、生成式模型、还有混合架构。规则模板适合那种高频、意图非常明确的Query,比如用户说“查一下我的订单”,你直接映射成“查询订单”就行,简单高效。但遇到长尾的、口语化的,比如“那个上周买的鞋还没到,帮我看看咋回事”,规则就抓瞎了,这时候得用生成式模型,像Seq2Seq或者微调一个LLM来改写。不过真正落地的时候,我一般不会只用一种,而是混合架构,规则兜底处理高频,模型处理复杂情况,这样效率和覆盖都能兼顾。
接下来说数据采样,如果让我来设计,我会分层来搞。第一层是高频意图层,大概占60%的数据,直接从线上日志按PV采样,保证头部场景学得足够好。第二层是长尾增强层,占25%,主动去挖掘那些PV低但高价值的Query,比如历史上失败的会话、多轮交互里用户反复改口的情况。这些用聚类或者不确定性采样挑出来,能提升模型的泛化能力。第三层是边界和负样本层,大概15%,专门构造一些容易让模型翻车的场景,比如“取消订单”和“退款”这种易混淆的意图对,或者改写后语义漂移的bad case。这里有个前提,就是要做质量过滤,人工标注改写对的一致性,剔除那些表面相似但意图不同的伪等价样本,否则模型会学到错误关联。
模型上线后怎么评估?我分两块。离线的话,核心是改写的准确率,就是人工抽检改写前后意图是否一致。另外我会看下游任务增益,比如改写后Agent的任务成功率有没有提升,这个比BLEU那些n-gram指标更实在。在线的话,我重点盯两个指标:一个是任务成功率,就是用户的问题有没有被完整解决,这是北极星指标;另一个是Agent协作轮数,改写后平均交互轮数应该下降,说明沟通更高效了。还会看用户满意度,比如会话结束后的显式反馈或者是否转人工。A/B实验设计上,我会按Query类型分层,比如高频和长尾分开看,避免平均效应掩盖了细分场景的问题。
这里我想提一个延伸点,就是改写和下游意图模型之间的协同。如果改写模块改了但意图模型识别不出来,那改写就没用。反过来,如果意图模型足够强,是不是可以简化甚至去掉改写?这个边界怎么划,我觉得值得深入讨论。
所以总结一下,我更倾向于把Query改写看成整个Agent系统的一个适配层,它的价值取决于上下游的配合。数据采样要兼顾效率和覆盖,评估要落到业务指标上,不能只看改写本身好不好。