GRAM

GRAM 是京东提出的电商生成式检索新范式，核心思路是用 LLM 基于 16 种结构化属性为 Query 和 Product 生成共享文本 Code，通过 Co-training + DPO Co-Alignment + JS 散度评分三层对齐，将传统「意图识别→召回→粗排」三阶段流水线整合为一个端到端的生成式检索+预排序一体化过程，在京东搜索广告线上 A/B 测试中实现广告收入 +2.46%、CTR +1.27%。

问题背景

电商搜索的检索（Recall）环节是用户体验和商业收入的关键入口。在京东这种亿级商品规模的平台上，如何在几百毫秒内从海量商品中精准找出与用户 Query 相关的商品，是一个核心挑战。

现有方法的局限

传统方法大致分为三派：

近年来生成式检索（Generative Retrieval）兴起，用模型直接生成文档标识符。但现有方法分两派且各有致命缺陷：

2.1 Code 定义与构建

GRAM 的第一步是定义一套Query 和 Product 共享的文本 Code 体系。作者从电商场景中抽象出 16 种结构化属性作为 Code 的「原子词汇」：

Code 由 1 个或多个属性通过分隔符拼接而成，按粒度分为三档：

• 粗粒度 Code：1-2 个属性（如「华为|手机壳」），覆盖面广但精度低
• 中粒度 Code：3 个属性（如「华为|手机壳|硅胶」），平衡覆盖与精度
• 细粒度 Code：超过 3 个属性（如「华为|Mate60|手机壳|硅胶|防摔」），精度高但覆盖面窄

初始 Code 构建（冷启动）

由于没有现成的 Query-Code 和 Product-Code 标注数据，GRAM 通过以下流程构建初始训练集：

1. 1
   NER 模型训练：专家标注约 300 万条 Query 的 16 种属性 → 训练 BERT-based NER 模型
2. 2
   属性提取：用 NER 模型从 Query 中提取关键属性集合 $Q$，从商品标题中提取对应属性
3. 3
   点击对挖掘：基于点击日志挖掘高频 Query-Product 对，Query 的初始 Code = 自身 NER 属性 + 关联 Product 的 NER 属性；Product 的初始 Code = 自身 NER 属性 + 反向关联 Query 的 NER 属性
4. 4
   双向扩充：最终得到 ~600 万唯一 Query、~800 万唯一 Product、~740 万唯一 Code

2.2 监督微调 (SFT)

2.2.1 Query-Code 生成器 SFT

基于 0.5B 开源 LLM，以 Query 文本为输入、Code 文本为目标做 SFT。训练目标为负对数似然最小化：

2.2.2 Product-Code 生成器 SFT

对称地，以商品标题为输入、Code 为目标训练 Product-Code 生成器：

2.2.3 Co-training（协同训练）

为什么需要 Co-training

2.2.1 和 2.2.2 各自 SFT 后，模型学会了从 Query 出 Code、从 Product 出 Code。但一个致命问题：模型几乎只生成细粒度 Code（4-5 个属性），因为训练数据里高频 Query-Product 对本身就属性多。细粒度 Code 精度高但覆盖面窄——中长尾 Query/Product 可能 Code 交集为空，完全无法召回。

第一步：数据增强（论文明确描述）

1. 用训练好的 Product-Code 生成器为全量活跃商品生成 Code
2. 基于点击关系，找到每个 Query 关联的 Product，把这些 Product 的 Code 作为 Query 候选
3. 用 Query-Code 生成器为每个 Query 额外生成 10 个新 Code
4. 去重后用相关性模型过滤，通过的 Code 合并到训练集

效果：每条训练样本的 Code 从「只有 NER 标注的细粒度 Code」扩充为「粗/中/细粒度混合 Code」。如果不做这一步直接 Co-training，模型根本没见过粗 Code，训了也没用。

第二步：同时训练（论文明确描述）

论文原话：「Unlike the separate training conducted in the previous stages, this phase needs to strengthen the connection between the two models, thus training the two generators simultaneously.」

一个 training step 里具体发生了什么（论文明确描述 loss 公式，以下 batch 细节为合理推断）：

1. 1
   拼 prompt：每条样本根据类型拼不同 prompt 前缀——Query 样本拼「请为以下搜索词生成 Code：」，Product 样本拼「请为以下商品标题生成 Code：」。文本 + prompt 拼完就是模型的标准输入。
2. 2
   forward：所有样本（Query-Code 对 + Product-Code 对）一起送进同一个 LLM，做一次前向传播。每个 token 输出词表上的概率分布。
3. 3
   算 loss：对所有样本分别算负对数似然 loss（跟 2.2.1/2.2.2 公式一样），然后全部加在一起：batch_total_loss = Σ L_q_samples + λ · Σ L_t_samples（论文 λ=1，即等权重）。
4. 4
   backward + 更新：batch_total_loss.backward()，梯度同时流回 LLM 的同一套参数，更新。

跟「各自训」的核心区别

2.3 Code 协同对齐 (Code Co-Alignment)

SFT 阶段主要关注「能不能生成 Code」，而 Co-Alignment 阶段关注「生成的 Code 能不能高效召回」。核心思路：用点击行为做监督信号，通过 DPO（Direct Preference Optimization）让模型偏好那些能召回更多相关商品的 Code。

正负样本构造

对于每个 Query-Product 点击对：

• 正例 Code ($c_w$)：Query 的 Code 集合 ∩ Product 的 Code 集合 = 共享 Code
• 负例 Code ($c_l$)：Query 的 Code 集合 − Product 的 Code 集合 = Query 独有但 Product 没有的 Code（或反过来）

一条 DPO 训练样本 = (Query 文本, Product 标题, 正例 Code 文本, 负例 Code 文本) 的四元组。

DPO 训练：一个样本到底发生了什么

第一步：参考模型打分（参数冻结，可以预先算好）

1. 1
   Forward（Query 端）：输入 = [Query Prompt] + Query 文本 → 模型输出对 $c_w$ 和 $c_l$ 的生成概率 $\pi_{SFT}(c_w \mid q)$ 和 $\pi_{SFT}(c_l \mid q)$
2. 2
   Forward（Product 端）：输入 = [Product Prompt] + Product 标题 → 得 $\pi_{SFT}(c_w \mid t)$ 和 $\pi_{SFT}(c_l \mid t)$
3. 3
   取平均：$\pi_{SFT}(c_w \mid q, t) = (\pi_{SFT}(c_w \mid q) + \pi_{SFT}(c_w \mid t))/2$，$c_l$ 同理

第二步：当前模型打分（参数在训练，需要梯度）

1. 4
   Forward（Query 端）：同样输入 Query，得 $\pi_\theta(c_w \mid q)$ 和 $\pi_\theta(c_l \mid q)$
2. 5
   Forward（Product 端）：同样输入 Product，得 $\pi_\theta(c_w \mid t)$ 和 $\pi_\theta(c_l \mid t)$
3. 6
   取平均：$\pi_\theta(c_w \mid q, t) = (\pi_\theta(c_w \mid q) + \pi_\theta(c_w \mid t))/2$

第三步：算 DPO loss → backward → 更新参数

2.4 Query-Product 对齐评分

Code Co-Alignment 解决了「Code 本身好不好」的问题，但还需要解决「同一个 Query 召回的不同商品如何排序」。为此 GRAM 引入了基于 JS 散度的 Query-Product 评分机制。

JS 散度评分

对于每个 (Query, Code, Product) 三元组，逐 token 计算 Query 端和 Product 端对该 Code 的生成概率分布的差异。差异越小（即 Query 和 Product 对同一 Code 的生成概率越接近），该 Code 对该 Query-Product 对的相关性越高：

Pairwise Ranking Loss

每个 Query 通过 Code 召回一批商品后，取 Top-K 最高分的商品作为正样本 $t_{pos}$，其余为负样本 $t_{neg}$，用 pairwise loss 训练排序：

2.5 推理与部署架构

GRAM 的在线推理流程与部署方式非常有工程价值，它做到了召回+粗排一体化：

1. 1
   Code 生成（一次 forward）：用户发起搜索 → Query-Code Generator 做一次 LLM forward，生成 N 个 Code（beam size=10）。同时免费拿到每个 token 的生成概率 $P_q$——这是 forward 的副产物，不额外消耗算力。
2. 2
   Code 匹配召回（查索引）：每个 Code 查倒排索引（Code → Product 列表），召回约 300 个广告商品。索引里除了 Code 字符串，还预存了每个商品对该 Code 的 token 级生成概率 $P_t$（近线系统提前算好写入）。
3. 3
   Query-Product 评分（纯计算，无模型调用）：对每个召回商品，用 JS 散度计算 $S_{rele} = f(P_q, P_t)$。$P_q$ 从 step 1 免费获得，$P_t$ 从 step 2 索引查表获得——全程不需要再做任何模型 forward。同一商品若被多个 Code 召回，分数累加。
4. 4
   排序输出：按 $S_{rele}$ 降序排列，直接输出——不需要额外的粗排模型。整个流程只有 step 1 涉及一次 LLM 推理。

数据规模

GRAM 的实验数据来自京东真实搜索日志，规模巨大：

离线评测

评测指标：Recall@k（k=10, 100, 300，衡量点击商品被召回的比例）和 RelR（Relevance Ratio，不依赖点击的 relevance 角度评估）。

消融实验

在线 A/B 测试

GRAM 在京东搜索广告线上随机服务 5% 流量 vs 基线模型 5% 流量，持续至少一周。结果以在线模型为 baseline：

亮点

1. 共享 Code 空间的设计非常巧妙：不是让 Query 和 Product 各自有独立的 ID 体系，而是以 16 种结构化属性为「通用语言」，让 LLM 在同一个词汇空间里为两端生成 Code。这从根本上解决了 String-based 生成式检索中 Query-Product 词汇不对齐的核心痛点，比 TIGER/LC-Rec 的 Semantic ID 方案更充分利用了 LLM 的世界知识。
2. 工程落地思维贯穿全文：从初始 Code 冷启动（NER + 点击对挖掘），到粗中细粒度 Code 的分层设计，到长度惩罚下采样平衡粗细粒度分布，再到在线缓存的延迟优化——这不是一篇纯学术 paper，而是一个真正在亿级商品规模上跑通并持续创造收入的工业系统。
3. 召回+粗排一体化的工程价值：传统「意图识别→多路召回→粗排」的漏斗架构每层都有信息损失，GRAM 用一个模型同时完成这三步，减少信息损失、降低系统复杂度。在线 A/B 结果（收入 +2.46%）证明这个方向是对的。
4. DPO 在检索对齐中的创新应用：将 DPO 从 LLM 对齐迁移到检索场景，用点击行为构造偏序关系来优化 Code 生成偏好——这个思路可以推广到其他生成式检索场景。

可能的不足

1. 对 NER 模型的强依赖：GRAM 的 Code 体系建立在 NER 提取的 16 种属性之上。NER 模型的准确率会直接影响 Code 质量，如果 NER 出错（如将「苹果」误标为水果而非品牌），会导致系统性召回偏差。论文没有分析 NER 错误对最终效果的影响。
2. Recall@10 不如稀疏/稠密方法：离线实验中 GRAM 的 Recall@10 只有 2.85%，低于 BM25 的 3.01% 和 DPR 的 3.89%。虽然在高 K 值下 GRAM 反超，但在一些对首屏结果质量要求极高的场景（如移动端搜索），Top-10 的召回质量可能比 Top-300 更重要。
3. 新商品冷启动：虽然论文提到近线系统会为新商品生成 Code，但如果新商品的属性在训练数据中从未出现过（如全新品类），NER 模型和 Code 生成器可能都表现不佳。论文没有给出新商品的专项实验。
4. 缺乏与最新稠密检索方法的对比：Baseline 中的 DPR 是 2020 年的方法，未与更强的稠密检索方法如 SimLM、ColBERT v2 等对比。

对我们的启发

一句话启发：GRAD 的核心洞见是——与其让模型从头学一套 ID，不如让 LLM 用已有的「人类语言」（结构化属性）做检索的中间表征。这种「借力 LLM 世界知识」的思路，可能是生成式检索在工业界落地的最短路径。