1. 问题与动机

这篇工作来自 Apple App Store 的大规模商业搜索。作者指出，线上搜索排序同时面对两个并不等价的目标：行为相关性，即用户是否点击或下载；文本相关性，即结果在语义上是否真正符合 query。行为日志量大、更新快，但它混合了位置、曝光、品牌认知、价格和 UI 等因素，不能单独代表语义匹配。人工标注的文本相关性更接近专家判断，却昂贵、覆盖有限，尤其难覆盖低频的 tail query。结果是生产 ranker 在头部 query 上有较强行为信号，在尾部 query 上既缺语义标签，也缺稳定行为样本。

作者的核心动机不是把 LLM 放到在线重排链路中，而是把它作为离线标注器，为已有搜索日志中的 query-app pair 生成可规模化的文本相关性标签。论文把这条路线明确放在两个已有方向之间：一类工作让 LLM 直接做 pointwise、pairwise 或 listwise 重排，面临推理时延和成本；另一类工作使用 LLM-as-a-Judge 辅助评测，但通常没有把生成标签直接用于生产 ranker。本文希望验证一个更工程化的问题：一个针对本业务 rubric 微调过的小模型，是否可以把少量人工判断扩展成数百万条训练监督，并且同时改善语义相关性与点击/下载表现。

论文的重要性在于它把标注瓶颈和排序目标放到了同一条生产链路中。作者不是只在公开数据集上展示离线增益，而是使用跨 storefront、跨语言的历史搜索日志生成标签，随后用独立的文本相关性验证集和全球线上流量检验信号是否可靠。这样能够回答社区 UGC 搜索最现实的问题：当短 query、长尾实体、口语表达缺少点击统计时，能否用离线语义监督补上相关性模型的盲区。

2. 方法详解

整体流程分为两个阶段。第一阶段训练并选择 LLM relevance judge，第二阶段把它生成的 pointwise 文本标签混入多目标 ranker 的训练集。对每个历史 query-app pair，模型看到 query、若干 app metadata，以及与人工标注一致的五档 relevance rubric，输出唯一的 label。论文给出的 few-shot prompt 例子要求模型只返回标签，不生成解释，从而使输出稳定、方便批量解析。作者同时比较 zero-shot 和 few-shot、字符串标签和数字标签等 prompt 配置。

标注器的实验设置很具体：三种模型分别是预训练 3B、预训练 30B，以及在人工 judgments 训练集上微调的 3B。人工标注数据被切成训练集和验证集，用于微调 FT-3B 以及评估模型能否复现 held-out human label；随后，最优配置在大规模历史 App Store session logs 上推理。日志数据包含按 query 聚合的 query-app 候选对，规模为 millions，记作 n×m 的候选关系。这样做的关键不是让模型理解所有 App Store 业务，而是让它内化本业务专家的 relevance 定义：同一个 app metadata 在不同 query 下应得到不同的 ordinal label。

第二阶段使用一个多目标 learning-to-rank 框架。行为相关性标签来自聚合后的 click 和 download 日志，文本相关性标签有两部分：人工 judgments 和 LLM-generated judgments。相同的 query-app feature vector 可以在训练数据中出现多次，但携带不同来源的监督：一行用于行为目标，另一行用于文本目标。作者采用 scalarization，把不同标签源按可控比例混合成 ranker 训练数据，相当于在 behavioral relevance 与 textual relevance 之间寻找一条 Pareto frontier。文中举例的混合比例包括 90–10、70–30 和 50–50；改变比例可以选择新的折中点，而不是把两个目标硬编码成一个不可解释的标签。

这种数据混合方式的工程含义是保留现有生产 ranker 的结构和特征，只扩展训练监督，不要求在线调用 LLM，也不必为 LLM 设计一套新的推理服务。训练阶段严格区分 label source，避免把文本判断和行为统计的梯度混在同一条样本语义里。文本相关性的离线验证使用与 LLM 微调和验证不重叠的人工判断集合；ranker 的 NDCG 也使用独立的人工文本判断，避免模型仅仅记住生成器的偏好。

3. 核心技术贡献

第一，论文把 LLM-as-a-Judge 从通用评测工具改造成生产数据生成器。与实时 LLM reranker 不同，LLM 只在离线阶段对日志候选打标签，因此可以把成本摊到索引和模型迭代周期，不改变在线 SLA。真正起作用的机制是把专家 rubric 作为模型输出空间，让生成监督和现有人工 label 可对齐。

第二，作者用实验说明领域微调比简单扩大模型尺寸更有价值。FT-3B 的验证 F1 达到 0.800，而 PT-30B 只有 0.382；前者参数量约为后者十分之一，却更接近人工判断。这不是单纯的压缩结论，而是说明 relevance judgment 的关键在于业务定义、示例和标签边界，通用语言能力不能替代任务对齐。

第三，LLM 标签不是独立优化语义指标，而是被放入多目标 ranker 的数据混合框架。这样得到的是 Pareto 改善：加入生成标签后，文本 NDCG 和行为 NDCG 在多个 cutoff 同时提升。相比只把 LLM 分数作为一个额外 feature，数据级混合能够显式控制文本与行为监督的比例，方便在不同业务阶段选择更保守或更语义化的模型。

第四，论文把离线指标和线上转化串起来。全球 A/B 测试中，llm-augmented ranker 的 conversion rate 显著提升 0.24%，并且在 89% 的 storefronts 中优于生产模型。更重要的是增益集中在 tail query，说明生成标签确实填补了行为数据稀疏的区域，而不是只在流量最大的 query 上重复已有信号。

4. 实验结果分析

实验分两层。第一层检验 LLM 是否能复现人工文本相关性；第二层检验这些标签是否能改善生产排序器。标注器验证集结果如下。

结果显示，预训练 30B 比预训练 3B 好，但规模提升十倍仍远低于业务微调的 3B。论文还报告 few-shot、字符串标签的 prompt 配置最佳；数字输出更便于解析，却没有字符串 rubric 那样充分地承载人工判断边界。作者没有把所有 prompt 组合的完整表格放出，因此不能据此断言某个具体模板在所有语言上都最优，但方向很清楚：先固定业务标签定义，再用少量高质量 judgments 微调。

第二层 ranker 评估比较 production model 与 llm-augmented model。两者均使用行为日志，差别在于后者额外加入 millions 条 LLM 文本标签。结果如下。

提升幅度并不大，但方向在所有 k=1、3、7 上一致：文本 NDCG@1 增加 0.001，行为 NDCG@1 增加 0.006；行为 NDCG@3 增加 0.005，NDCG@7 增加 0.004。对于成熟的商业排序器，小幅而稳定的线上增益往往比单一 benchmark 的大幅变化更可信。严格不重叠的文本评估集也很关键，它避免模型通过复用微调样本或生成器偏差制造虚假的离线提升。

数据混合比例实验体现了一个实用的消融结论：增加 LLM 标签会把 Pareto frontier 向外推，但继续改变 LLM 标签占比主要是在新 frontier 上移动，而不是无限制地继续抬高 frontier。也就是说，生成标签首先解决的是监督覆盖不足，达到一定覆盖后，业务需要根据文本相关性与行为相关性的权重选择工作点。这个结论支持把比例做成可配置训练旋钮，而不是把 LLM 监督一次性全量替换行为监督。

线上 A/B 测试比较全球真实流量的 prod 与 llm-augmented。conversion rate 定义为至少发生一次 app download 的搜索 session 比例；增强模型整体显著提升 +0.24%，并在 89% 的 storefronts 中胜出。按 query frequency 分桶后，低频尾部的曲线提升最大，高频头部相对有限。原因与方法假设一致：头部 query 已经有足够 click/download 信号，尾部 query 缺少可靠行为标签，LLM 生成的文本相关性提供了较稳的先验。

一个值得注意的边界是，论文主要报告 aggregate 指标和 storefront 分布，没有展开不同语言、query 意图、应用类别和错误类型的完整分桶，也没有披露生成 millions 标签的绝对推理成本、人工校验比例或线上延迟变化。因而可以确认方法具有工业可行性，但还不能直接推导在社区短文本、强噪声 UGC 或中文口语 query 上会获得同等幅度。

5. 局限与未来方向

作者明确提出的未来工作包括尝试更多微调模型，以及从 pointwise 标签扩展到 pairwise 和 listwise prompt，使 LLM 能直接表达两个候选之间的偏序，或对一个候选列表提供排序信号。这个方向可能让生成监督更贴合 LTR 的相对排序目标，但也会显著增加 prompt 复杂度、候选组合数和标签一致性问题。作者还指出，当前工作依赖已有人工 relevance judgments 来微调和验证 judge，因此完全没有人工标签的新市场仍不能直接套用。

从论文实验可见但未充分展开的限制包括：第一，LLM judge 与 ranker 共享同一业务 metadata，生成器和排序器可能形成闭环偏差；第二，五档 pointwise label 不一定能识别多样性、覆盖性和近重复内容，UGC 搜索还需要 pairwise、listwise 或 set-level 约束；第三，跨语言生成标签的质量需要单独校准，不能由英文或高流量 storefront 的验证结果外推；第四，线上 A/B 只证明总体转化提升，并不能替代对误召回、低质内容、敏感内容和长尾新帖的安全检查。

6. 工业实践意义

对社区 UGC 搜索，推荐采用离线 LLM 标注器而不是把大模型直接放在每次请求的重排路径上。第一步应整理 query—帖子或 query—评论的人工相关性 rubric，至少区分完全匹配、部分满足、主题相关但意图不符、无关和潜在误导等等级；然后用少量高质量人工 judgments 微调一个小型 judge，并在独立验证集上检查 precision、recall、F1，而不是只看模型生成的自洽性。本文的 FT-3B 对 PT-30B 的结果说明，业务对齐样本比盲目追求更大参数量更重要。

第二步是把生成标签作为增量监督，与 CTR、停留、收藏、关注、负反馈等行为标签分开管理。UGC 的点击往往受作者、标题党、发布时间和社交传播影响，不能把 click 直接当作语义相关；可用 90–10、70–30、50–50 等混合比例训练多个 ranker，在 nDCG、CTR、长尾 query 覆盖和低质召回率之间画出自己的 Pareto frontier。训练/验证必须按时间和用户切分，并确保用于 judge 微调的人工样本不出现在最终文本 NDCG 评估中。

第三步应优先在 tail query、冷启动帖子和新实体上做分桶实验。论文线上收益集中在低频 query，这正对应社区中口语、拼写变体、简称和新热点词的监督稀疏区。上线前可以用离线生成标签训练候选重排或粗排模型，线上只保留轻量模型；对 judge 的输出设置置信度阈值，低置信度、争议度高或涉及安全的样本回流人工审核。

最后要建立数据治理和偏差防线。不能让 LLM 生成标签完全替代人工；应抽样比较不同语言、内容类别、作者规模和 query 频次，检查是否系统性偏向长文本、热门作者或规范表达。对中文短文本，还应单独覆盖错别字、谐音、方言、缩写、emoji 和多意图 query。线上评估不应只看整体 CTR，应同时监控 nDCG、长尾覆盖、bad-case rate、用户负反馈与内容安全指标。论文给出的 +0.24% conversion lift 说明成熟系统的增益可以很小但有价值，社区系统应把统计显著性、效果稳定性和可回滚的训练版本一起纳入发布门槛。