AdNanny：广告里的 LLM-RL，不一定上线上，它也可以先统一离线任务底座

背景

补完 GR4AD、GPR 和 OneSearch 之后，站里对工业广告/搜索主线已经形成了一个比较顺手的直觉：

  1. 先把级联系统压成生成式主栈。
  2. 再用 RL、value model、beam controller 或 request rehearsal 去修线上效果。
  3. 最后继续把 serving stack 往 LLM 基础设施上靠。

但这一轮用本地 search-layer 粗扫候选、再直接回到 arXiv API、arXiv HTML/PDF 和 GitHub API 做核验后，我补到一个更适合单独成 story 的入口：

  1. AdNanny: One Reasoning LLM for All Offline Ads Recommendation Tasks
  2. AdNanny arXiv HTML
  3. AdNanny PDF
  4. 一个模型统一所有离线任务！微软用671B大模型重构广告推荐「推理大脑」

核完之后，我更倾向于把它记成：

广告里的 LLM-RL，不一定上线上，它也可以先统一离线任务底座

这条线和 GR4AD / GPR 并不是同一个系统位置。

前两者更接近：

online generator / serving-time controller / future-request adaptation

而 AdNanny 更接近：

offline reasoning backbone / supervision service / downstream model aligner

核心判断

AdNanny 的关键不是“广告里又用了一个大模型”，而是把离线任务林统一成一个 reasoning backbone

论文摘要和正文都写得很直接：AdNanny 要解决的不是单个任务的精度瓶颈，而是广告系统里长期存在的一组离线任务碎片化问题。

它统一覆盖的任务至少包括：

  1. query-ad relevance labeling
  2. ad-user relevance labeling
  3. keyword-based query generation
  4. user profile generation
  5. ad optimization / keyword extension

这里最值得记的不是“任务多”，而是这些任务原本分散在不同离线模块里：

  1. 有的负责给 retrieval / ranking 打标签。
  2. 有的负责产生 keyword、query 或 creative 候选。
  3. 有的负责把用户日志压成 profile feature。
  4. 有的只服务分析、诊断或实验筛选。

AdNanny 的做法，是把它们全部改写成统一的 label / generation + reasoning 格式，再由同一个 reasoning-centric LLM 去承接。

所以这条线真正新增的系统位置，不是“又一个广告推荐器”，而是：

offline ads task backbone

这也解释了为什么这篇 paper 很适合和 GR4AD / GPR 并列看，而不是被随手塞进“广告里也能用 LLM”这一类泛结论里。

这条线真正把 RL 压到的是“下游广告模型对离线输出的消费层”，而不是线上 request-time policy

AdNanny 的训练不是只做多任务 SFT。

论文 4.2-4.3 节把两阶段写得很清楚：

  1. 先用 reasoning-augmented corpora 做 multi-task SFT
  2. 再加一层 RL，把 AdNanny 当成 policy，对齐 downstream ads models 的真实消费方式

这里的关键不是“又用了 RL”，而是 reward 的提供者。

论文明确写出：

  1. 对每个离线任务，先让 AdNanny 生成标签、query、profile 或 creatives
  2. 再把这些输出注入现有 retrieval / ranking pipeline
  3. 保持下游 ads models 固定不动
  4. 用 recall@K、NDCG@K、predicted CTR uplift 等离线指标去计算 batch reward

也就是说，这条线里的 RL consumer 不是用户当下的点击，也不是 generator 自己的解码路径，而是：

downstream frozen ads models

这会直接逼出一个站里还没显式记开的新观察维度：

offline task substrate / downstream consumer

否则下面这些方法会继续被写成一种“广告里的 LLM-RL”：

  1. GR4AD 这种 online generator + list-wise business-value RL
  2. GPR 这种 one-model + hierarchical process rewards
  3. AdNanny 这种 offline reasoning backbone + downstream-model rewards

它们都碰了推荐、广告和 RL，但系统位置完全不同。

它不是普通“离线打标器”，而是一个可被直接消费、也可被蒸馏的 reasoning service

论文 5.5 和 6 节有一个很值得单独记下来的判断：

AdNanny 并不走 latency-critical serving path，而是作为 batch / near-line 服务，给 Bing Ads 的其余模块持续产出高质量 supervision 和 diagnostics。

这会带来两层价值：

  1. 它的输出可以被人直接消费，用来做 diagnostics、人工审核、A/B 候选筛选和问题定位。
  2. 它的输出也可以继续被 retrieval / ranking student 消费，蒸馏成更轻的线上模型。

这意味着它的身份不是单一 judge，也不是单一 generator，而更像：

shared offline reasoning service

论文在任务描述里把这点写得很细。

比如：

  1. user profile generation 会把 query、impression、click、conversion 日志压成可读偏好描述，再被编码成 embedding 或离散特征
  2. keyword-based query generation 会为 advertiser keyword 生成更具体、更可匹配的 query 候选，再交给后续系统过滤和消费
  3. query-ad / ad-user 相关任务会直接为线上模块提供更细粒度的负样本判断和诊断理由

因此 AdNanny 真正逼出来的新观察列，不只是 another reward type，而是：

  1. offline task substrate
  2. downstream consumer
  3. supervision handoff

否则“给系统打标签”“给系统产 query”“给系统产 profile”“给系统做评估”这几种不同 owner，又会被重新抹平成一种“离线 LLM 工具”。

这条线的工业证据很硬，而且收益不只落在一个任务上

AdNanny 的实验不是只给一组抽象平均值。

它在几个关键位置都给了比较硬的证据。

先看 ad-user relevance labeling。

PDF Table 5 给出的结果很清楚：

  1. Dataset G 上，BACC 从 4o-1120 的 84.63 提到 88.26
  2. Dataset H 上，BACC 从 85.70 提到 88.81
  3. 更关键的是 NegAcc 分别增加 +16.69 和 +8.09

这说明它最主要修到的，不是泛泛的平均分，而是：

更稳地识别 truly bad ad-user matches

再看 keyword-based query generation。

PDF Table 6 里，AdNanny-671B 相比 public DeepSeek-R1：

  1. Relevance 从 39.33 提到 53.65
  2. Diversity 从 57.32 提到 66.49
  3. Difficulty 从 69.31 提到 82.85

而且 reasoning-guided data cooking 后蒸馏出的 AdNanny-7B (with DQC) 甚至还能把 Relevance 再拉到 55.08。

这说明它不是“只能靠 671B teacher 撑效果”，而是确实把更可迁移的 supervision 先做出来了。

再看 general capability。

PDF Table 8 给出的平均分很值得记：

  1. DeepSeek-R1 baseline 平均 0.867
  2. ads-only multi-task finetuning 后降到 0.819
  3. 加一小份 public instruction data 后又回到 0.867

这和站里前面已经记过的 OpenOneRec/verl_distillation 有一个很自然的呼应：

domain specialization 和 general capability recovery，在工业系统里已经越来越像显式 stage，而不是默认自动兼得。

最后看 serving 成本。

PDF Table 9/10 把这条线为什么能在工业里跑起来写得很直白：

  1. FP8 推理的 BACC 甚至比 BF16 略高，83.38 对 83.01
  2. label-only 配置相对 GPT-4o 的 cost ratio 是 0.23
  3. label+reasoning 配置的 cost ratio 也只有 0.52
  4. throughput 分别达到 20.22 和 8.79 samples/s
  5. 论文直接写一台 production node 每天可处理约 900K label-only samples 或 400K label+reasoning samples

这意味着 AdNanny 并不是“论文里想象一下如何离线使用 LLM”，而是真的把离线 supervision service 做到了可运行的工业成本区间。

当前公开边界仍偏 paper-first，中文传播层刚出现入口，但 xhslink 仍然缺位

这条线的工业信号很强，但公开边界并不强。

我用 GitHub API 按论文全标题、缩写 AdNanny 和 arXiv id 2602.01563 做了检索，截至 2026-03-22 仍未看到稳定官方 repo。

因此当前更准确的写法仍然是：

industrial paper-first offline ads task backbone route

中文传播层本轮补到一个可稳定访问的入口：

  1. 凤凰网转载的量子位稿件，标题直接概括成“一个模型统一所有离线任务”

它适合用来记录中文世界最先抓住了哪一层叙事，但不能拿它替代论文做事实裁定。

至于 site:xiaohongshu.com AdNanny 广告 推荐 和 xhslink AdNanny 广告 推荐 这类检索，本轮继续补做后仍没拿到稳定高价值线索。

证据与来源

  • AdNanny: One Reasoning LLM for All Offline Ads Recommendation Tasks：arXiv 摘要主入口。可直接核到 2026-02-02 的提交时间、671B DeepSeek-R1、统一离线广告任务和 Bing Ads 部署定位。
  • AdNanny arXiv HTML：正文关键入口。4.2-4.3 节明确写出 adaptive multi-task SFT、下游 frozen ads models 提供 RL 奖励，以及 recall@K / NDCG@K / predicted CTR uplift 的 reward consumer。
  • AdNanny PDF：补出 Table 5/6/8/9/10 的具体数值，包括 ad-user relevance、keyword generation、general benchmark、FP8 和成本数据。
  • 一个模型统一所有离线任务！微软用671B大模型重构广告推荐「推理大脑」：当前可稳定访问的中文传播层入口，用来看中文社区如何转述 one model for offline ads tasks 这条主线，但不能替代论文原文。
  • GitHub API 检索论文全标题、AdNanny 与 arXiv id 2602.01563：截至 2026-03-22，仍未看到稳定官方 repo，因此当前公开边界更适合记成 paper-first。
  • 公开网页检索 site:xiaohongshu.com AdNanny 广告 推荐 与 xhslink AdNanny 广告 推荐：截至 2026-03-22，仍未找到稳定高价值 xhslink。

下一步

  • 把 AdNanny / GR4AD / GPR / OneSearch / OneRec-V2 横向压成一张广告工业路线观察表，除了 training-serving co-design、serving-time controller 与 request-state adaptation regime，再新增 offline task substrate / downstream consumer。
  • 如果后续出现官方 repo，优先核三件事：RL 奖励到底如何接到下游 ads models、reasoning 输出怎样回流成轻量 student，以及 profile/query/label 三类任务是不是共用同一套 data cooking 逻辑。