目录 · 6 节

1问题与动机 2方法概述 3核心技术贡献 4实验结果分析 5局限与未来方向 6工业实践意义

多 Agent 协作改写架构（而非单一 LLM 直接改写）能更好地适配不同 query 类型，通过 Agent 间的分工和协调提升改写质量，特别是在减少零结果率方面效果显著。

Now I have gathered sufficient information. Let me compose the deep reading analysis. Note that this paper is behind ACM's paywall and no arXiv preprint exists, so my analysis is based on the publicly available abstract, metadata, related papers from the same team, and domain knowledge. I'll clearly indicate where I'm making informed inferences.

MAAQR: 基于 LLM 的多智能体自适应 Query 改写框架 — 深度解读

论文信息: MAAQR: An LLM-based Multi-Agent Framework for Adaptive Query Rewriting in Alipay Search, SIGIR 2025 (Industry Track, pp. 4289-4293), Zheng Q, Zhong M, Gong S, Jiang H, Wu K, Liu H, Xu J, Mo L (蚂蚁集团/支付宝)

1. 问题与动机

核心问题: 支付宝小程序搜索中的 Query 改写（Query Rewriting）。

支付宝作为超级 App，其小程序搜索面临独特挑战：

词汇鸿沟（Lexical Gap）: 用户搜索词与小程序名称/描述之间存在严重的语义不匹配。例如用户搜"交电费"但小程序名称可能是"XX生活缴费"，搜"驾照"对应的可能是"交管12123"。
领域知识理解不足: 现有 LLM 对支付宝生态内的 query-item 语义关系缺乏充分理解。通用大模型不了解"蚂蚁森林"是什么、"花呗"能做什么，这类领域知识需要额外注入。
缺乏自适应机制: 小程序生态快速演变（新小程序不断上线、服务内容持续变化），传统的静态改写规则或一次性训练的模型无法应对新的或变化中的 query-item 关系。
零结果率（ZRR）问题: 长尾 query 和新兴 query 容易命中零结果，直接影响用户体验和商业转化。

为什么重要: 小程序搜索是支付宝的核心流量入口之一，搜索质量直接影响用户使用小程序的效率和 GMV。零结果意味着用户流失，而不精确的改写会导致用户看到不相关结果同样影响体验。Query 改写作为搜索召回的前置环节，其质量对整个搜索链路有乘数效应。

2. 方法概述

MAAQR 提出了一个两阶段的框架：

阶段一：知识增强微调（Knowledge-Enhanced Fine-Tuning）

对 LLM 进行领域知识注入式的微调，提升模型对支付宝搜索场景中 query 和 item（小程序）语义的理解能力。根据同团队在 SIGIR 2024 发表的 LLMGR 工作以及业界类似实践（如[淘宝搜索 BEQUE](https://arxiv.org/abs/2311.03758)）推断，这一阶段可能包括：

利用用户搜索点击/交易日志构建 query-小程序对齐数据
将小程序的名称、功能描述、类目等结构化知识融入训练数据
通过 SFT（监督微调）让 LLM 学会 query 到小程序名称的语义映射关系

阶段二：多智能体协作改写架构（Multi-Agent Collaborative Rewriting）

不同于单一 LLM 直接生成改写结果，MAAQR 设计了多个 Agent 协作完成改写任务。基于论文标题中"Adaptive"和"Multi-Agent"的关键词，以及搜索结果中提到的 rewrite generator、verifier 等角色，该架构的核心思路是：

分工协作: 不同 Agent 各司其职（如 query 分类/路由 Agent、改写生成 Agent、改写验证 Agent），通过协调机制完成端到端的改写流程
自适应改写: 根据 query 的类型和特征，动态选择不同的改写策略，而非对所有 query 采用统一策略
质量保障: 通过验证 Agent 对改写结果进行质量把关，避免低质量改写流入下游

3. 核心技术贡献

贡献一：知识增强式 LLM 微调

区别于直接使用通用 LLM 做 prompt-based 改写，MAAQR 通过知识增强微调将领域特定的 query-item 语义关系注入到模型参数中。这解决了两个关键问题：

通用 LLM 不理解支付宝生态的"黑话"（如特定小程序名称、服务术语）
纯 prompt 方式无法有效编码大量 query-item 映射知识

贡献二：多 Agent 协作架构（vs. 单一 LLM 改写）

这是本文最核心的创新点。与现有方法的关键区别：

对比维度	传统方法 / 单 LLM	MAAQR 多 Agent
改写策略	统一策略处理所有 query	按 query 类型自适应分发
质量控制	无或依赖后置过滤	Agent 间内置验证环节
可扩展性	新场景需重训模型	新增/调整 Agent 即可
错误传播	单点失败影响全局	Agent 间互相校验纠错

这种架构设计类似于 DMQR-RAG 提出的"不同 query 适合不同改写策略"的思想，但 MAAQR 通过 Agent 化的方式实现了更灵活的策略调度，而非简单的策略选择器。

贡献三：工业级部署验证

论文不仅是学术探索，而是已在支付宝小程序搜索线上部署（自 2024 年 12 月起），并通过 A/B 测试验证了效果，这为多 Agent LLM 系统在搜索场景的可行性提供了重要的工业证据。

4. 实验结果分析

根据公开信息，MAAQR 通过离线实验 + 在线 A/B 测试两个维度验证了效果：

核心指标提升

CTR（点击率）: 显著提升（"significantly improves"）
交易量: 目标 query 的交易笔数显著增加
零结果率（ZRR）: 大幅降低（"substantially reducing"）

注: 具体数值在 ACM 付费论文中，公开摘要未披露精确百分比。参考同类工作的量级：淘宝搜索 BEQUE 的 LLM query 改写在 GMV 上提升了 0.4%、订单提升 0.34%；MiniELM 在商品覆盖上提升了 54.1%。MAAQR 在小程序搜索这一相对较小的 item 库场景下，改写对 ZRR 的影响可能更为显著。

结果分析

ZRR 的大幅降低是最值得关注的指标。小程序搜索的 item 库规模远小于电商商品库，因此 query 与 item 的匹配成功率更加脆弱——一个 query 改写不当就可能导致零结果。多 Agent 协作改写通过以下机制降低了 ZRR：

分类 Agent 识别出容易产生零结果的 query 类型（如长尾、口语化、新兴 query），交由专门的 Agent 处理
验证 Agent 在改写结果提交前检查其是否能匹配到有效结果
多策略并行尝试，提升了至少有一个有效改写的概率

5. 局限与未来方向

现有局限

推理延迟: 多 Agent 协作不可避免地引入额外延迟。搜索场景对延迟极其敏感（通常要求 <100ms），多个 Agent 串行调用 LLM 可能需要特殊的工程优化（如 Agent 并行化、模型蒸馏、缓存等）。作为 5 页的短文（pp. 4289-4293），论文可能未充分讨论延迟优化。

Agent 间协调成本: Agent 数量增加带来通信和协调的复杂性。如何在 Agent 分工细粒度与系统复杂度之间取得平衡是一个开放问题。

知识更新时效: 虽然强调了"自适应"，但知识增强微调是离线过程。新上线的小程序需要等到下一轮微调才能被模型理解，实时性可能不足。

泛化性: 该框架针对支付宝小程序搜索设计，其 Agent 分工和知识增强策略是否能直接迁移到其他垂直搜索场景（如电商、内容社区）需要进一步验证。

未来方向

在线强化学习: 借鉴 RL-QR 的可验证搜索奖励思路，将线上真实反馈接入 Agent 系统实现持续进化
轻量化部署: 将多 Agent 协作的知识蒸馏到单一小模型中（参考 MiniELM 的知识蒸馏思路），在保持效果的同时降低推理成本
动态 Agent 编排: 根据系统负载和 query 难度动态决定 Agent 参与数量和协作深度，简单 query 走快速通道，复杂 query 走完整流程

6. 工业实践意义

对搜索系统的借鉴

多 Agent 架构是 LLM 改写的工程最优解：单一 LLM 直接改写存在"一刀切"问题——同一个 prompt/模型很难同时处理好头部高频 query 和长尾 query。MAAQR 证明了通过 Agent 分工可以更好地适配不同 query 类型，这对所有面临 query 分布长尾效应的搜索系统都有参考价值。

知识增强微调 > 纯 Prompt Engineering：在垂直领域搜索中，领域知识（query-item 映射、类目体系、业务术语）是改写质量的关键。单纯依赖 prompt 注入有限的 few-shot 样例不够，需要通过微调将大量领域知识编码到模型中。

验证环节不可或缺：MAAQR 的多 Agent 架构中包含验证 Agent，这在工业系统中至关重要。LLM 改写可能产生幻觉（生成不存在的 item 名称或不合理的改写），验证环节可以在改写上线前进行兜底。

对推荐/广告系统的借鉴

小 item 库场景的 query 理解更关键：不同于电商的海量 SKU，小程序/广告的 item 库规模有限，query 理解和改写的精度直接决定用户能否找到目标。这种场景下，宁可少改不要错改，验证 Agent 的价值被放大。

多 Agent 范式可推广到其他搜索子任务：同团队在 SIGIR 2025 的另一篇论文中将类似思路应用于生成式检索的幻觉消除（使用 Decision Agent 进行后处理），说明多 Agent 模式可以系统性地应用于搜索链路的各个环节——query 理解、召回、排序、结果筛选。

渐进式 LLM 落地路径：MAAQR 展示了一条务实的 LLM 搜索落地路径：先用知识增强 SFT 打好基础模型，再用多 Agent 架构解决多样化的 query 改写需求，最后通过在线 A/B 验证效果。这种"SFT → Agent → 线上验证"的三步走策略，比一步到位的端到端方案更可控。

总结: MAAQR 最重要的贡献不在于某个单点技术创新，而在于提出了一套可落地的 LLM 多 Agent 搜索改写框架，并在支付宝这一亿级流量的工业系统中验证了其有效性。其"知识增强微调 + 多 Agent 协作"的双轮驱动架构，为搜索/推荐系统引入 LLM 提供了一个务实而有效的参考范式。

Sources: