LLMGR: Large Language Model-based Generative Retrieval in Alipay Search
支付宝搜索部署 LLM 生成式检索系统 LLMGR，将小程序信息编码进大模型后直接生成候选标题进行检索。
INSIGHT对于复杂 query 传统检索难以召回的场景，LLM 生成式检索可作为补充召回源，通过将 item 信息编码进模型参数实现端到端检索，显著提升长尾 query 覆盖率。
业务关联社区搜索中常见复杂 query 无法匹配到相关内容的情况，LLMGR 的思路——用 LLM 作为补充召回源——可直接应用于 UGC 短文本搜索，尤其改善长尾 query 的搜索体验和 CTR。
证据在支付宝搜索在线 A/B 测试中，LLMGR 作为补充召回源相比传统方法在 CTR 上取得了统计显著的提升。
基于多轮检索，我已获取了 LLMGR 系统及其后续工作的详细信息。以下是深度解读：
注意：原始 LLMGR 论文发表于 SIGIR 2024（工业短文，4页），无 arXiv 预印本，全文在 ACM 付费墙后。以下解读结合了同团队的 SIGIR 2025 后续论文 arXiv:2503.21098（详细描述了 LLMGR 系统）以及相关文献的信息。
问题与动机
支付宝搜索的核心场景是帮助用户找到合适的小程序（mini-program）——这些是第三方开发的轻量级应用，运行在支付宝主 App 内。传统检索系统采用多阶段管线架构（索引构建 → 稀疏检索 → 稠密检索 → 排序），存在以下问题：
- 端到端优化困难：各阶段独立训练，无法联合优化，语义理解碎片化
- 长尾 query 覆盖不足：对于复杂、模糊或低频的用户查询，传统的稀疏检索（BM25）和稠密检索（双塔模型）都难以召回相关结果，导致空结果率（Zero-Result Rate）居高不下
- 语义鸿沟：用户表达的 query 与小程序标题/描述之间存在显著的语义差距，例如用户搜"怎么交水费"，但对应小程序名为"生活缴费"
这个问题的重要性在于：支付宝作为超级 App，其搜索质量直接影响用户体验和商业转化。长尾 query 虽然单条流量低，但聚合起来占总搜索量的很大比例，提升长尾召回率具有显著的商业价值。
方法概述
LLMGR 提出了一种基于大语言模型的生成式检索（Generative Retrieval）方法，核心思路是：
将小程序信息"记忆"进 LLM 的参数中，推理时直接根据 query 生成候选小程序标题，实现端到端检索。
具体流程分为三个阶段：
训练阶段
- 骨干模型：采用 Qwen2.5-14B 作为 GR 基座模型
- 文档标识：使用小程序/产品标题（Title）作为 Document ID，而非数字 ID 或语义哈希
- SFT 微调：构建
{query, 相关标题}的正例对，通过监督微调（Supervised Fine-Tuning）让 LLM 学习 query → title 的映射关系。训练的本质是让模型记忆整个小程序语料库的标题
推理阶段
- 用户输入 query 后，LLM 以自回归方式逐 token 生成候选标题
- 使用 Trie 约束解码（Trie-Constrained Decoding）：将全部合法标题构建前缀树（Trie），在每一步解码时只允许生成合法前缀路径上的 token，确保最终输出的标题一定是语料库中真实存在的文档
- 通过 Beam Search 生成 Top-K 个候选标题
系统集成
- LLMGR 作为补充召回源，与现有的稀疏检索（SR）和稠密检索（DR）并行工作，其输出并入统一的排序模块
核心技术贡献
1. 端到端生成式检索取代多阶段管线
与传统的"索引-检索-重排"管线不同，LLMGR 将检索问题转化为序列生成问题，模型参数即索引。这消除了中间表示的信息损失，实现了从 query 到文档的端到端映射。
2. Title 作为自然语言 DocID
相比 DSI（Differentiable Search Index）等工作使用数字 ID 或语义哈希作为文档标识符，LLMGR 直接使用自然语言标题作为 DocID。优势在于：
- 天然具有语义信息，LLM 可以利用预训练知识理解标题含义
- 不需要额外的 ID 分配和学习过程
- 对于小程序场景，标题数量有限（通常在万级到十万级），Trie 树规模可控
3. 大模型 + 约束解码的工业落地
这是最早将 LLM 级别的生成式检索真正部署到工业搜索系统中的工作之一。之前的 GR 研究多基于 T5 等中小模型，LLMGR 直接使用 14B 参数量的 Qwen 模型，充分利用大模型的语义理解和推理能力。
4. 与现有方法的关键区别
| 维度 | 传统稀疏/稠密检索 | LLMGR |
|---|---|---|
| 索引 | 倒排索引/向量索引 | 模型参数即索引 |
| 匹配 | 词匹配/向量相似度 | 序列生成 |
| 语义理解 | 受限于 encoder 能力 | 利用 LLM 预训练知识 |
| 优化 | 分阶段独立优化 | 端到端联合优化 |
| 长尾 query | 覆盖不足 | 借助 LLM 推理能力提升 |
实验结果分析
离线评估
- 从搜索日志中采样高频、中频、低频三类 query 构建测试集
- 由经验丰富的标注员对检索结果进行相关性标注（相关/不相关）
- 使用 Accuracy（ACC） 作为离线评估指标
- LLMGR 在特别是中低频 query 上表现出明显的召回优势
在线 A/B 测试
后续论文（SIGIR 2025）在基金搜索（Fund Search）和保险搜索（Insurance Search）场景进行了在线 A/B 测试：
- 对照组 A：现有的稀疏检索 + 稠密检索的基线召回系统
- 实验组 B：在基线上加入优化后的 GR 框架
- 保险搜索检索准确率提升 3.88%
- 搜索质量和转化率（Conversion Rate）均有显著提升
幻觉问题的发现
部署后发现 LLM 生成式检索存在幻觉问题——虽然 Trie 约束保证了生成的标题一定存在于语料库中，但模型仍会生成与 query 语义不相关的标题。这导致后续团队专门发表了 SIGIR 2025 论文来解决此问题。
局限与未来方向
现有局限
- 幻觉问题：这是最大的挑战。即使使用 Trie 约束解码，LLM 仍可能生成语义不相关但字面合法的标题。后续工作通过知识蒸馏推理（用 Qwen2.5-72B 和 GPT-4o 评估 query-doc 相关性，再蒸馏回 GR 模型）和决策代理（Decision Agent）进行后处理来缓解
- 推理延迟：14B 模型的自回归生成 + Beam Search + Trie 约束解码，延迟远高于传统的稀疏/稠密检索。Google 近期提出的 STATIC 框架（2026年2月）通过稀疏矩阵加速 Trie 约束解码，实现了 948x 的加速，说明这仍是活跃的研究方向
- 语料库更新：新小程序上线时需要重新训练模型或至少更新 Trie 树，无法像倒排索引那样实时增量更新
- 适用场景有限：当前主要适用于候选集规模可控的场景（小程序、基金、保险产品），对于海量网页级别的检索，Trie 树和模型记忆的规模都面临挑战
未来方向
- 增量学习：支持语料库动态更新而不需全量重训
- 更高效的约束解码：如 Google STATIC 和 Trie 向量化方案
- 多模态生成式检索：结合小程序的图标、截图等视觉信息
- 更好的幻觉控制：在训练阶段引入负例对比学习，或更精细的推理时 verification
工业实践意义
1. 作为补充召回源的定位非常务实
LLMGR 没有试图替代传统检索，而是作为补充召回路与 SR/DR 并行。这是工业落地的关键——降低风险的同时获取增量收益。对于长尾 query、复杂意图等传统检索薄弱的场景，GR 可以贡献增量召回。
2. 对"封闭语料库"搜索场景的启示
支付宝小程序、电商 SKU、金融产品等场景的候选集规模有限（万到百万级），非常适合生成式检索。搜索/推荐系统中的"封闭域检索"都可以借鉴这一思路。
3. LLM 作为检索系统组件的工程化范式
LLMGR 展示了如何将 LLM 嵌入到工业搜索系统中：SFT 微调记忆语料库 → Trie 约束解码保证合法性 → 与传统召回融合。这为搜广推团队提供了一条可复制的技术路线。
4. 幻觉控制是工业化的核心挑战
论文团队连续两年（SIGIR 2024 + SIGIR 2025）聚焦这一问题，说明GR 的准确性和可信度是工业部署的最大瓶颈。工业实践中可以借鉴他们的思路：训练时通过大模型蒸馏提升质量，推理时通过 Decision Agent 做后验筛选。
5. 对搜索/推荐系统演进的前瞻性意义
LLMGR 代表了搜索系统从"检索范式"到"生成范式"演进的重要一步。同团队还发表了 MAAQR（LLM 多代理查询改写），形成了 GR 召回 + LLM 改写 + 传统召回 的完整 LLM-native 搜索体系，这可能是未来搜索系统架构的趋势。
Sources: