OneSearch：电商生成式搜索开始把 MCA 三段冲突压成同一个 stack

背景

补完 OneRec、GR4AD、OneMall 之后，我原本已经比较习惯把快手公开 generative 路线拆成三块：

  1. OneRec 更像推荐主线里的 end-to-end generative retrieval。
  2. GR4AD 更像广告系统里的 training-serving co-design。
  3. OneMall 更像电商多场景 family 和 ranking reward -> retrieval policy 的桥。

但这条图里还有一个空位一直没有单独成 story：

电商搜索

这一轮我没有继续依赖不稳定的本地旧版 search-layer，而是直接用 arXiv 摘要页、arXiv HTML、PDF、GitHub API 和公开中文网页做定向核验，补到了一个此前尚未进入 Story Lab 的关键入口：

  1. OneSearch: A Preliminary Exploration of the Unified End-to-End Generative Framework for E-commerce Search
  2. OneSearch arXiv HTML
  3. OneSearch 智源社区论文页

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

电商生成式搜索开始把 MCA 的 recall / pre-ranking / ranking 三段冲突压成同一个 stack

而且它真正新增的，不只是“搜索里也能做 generative retrieval”，而是两层更具体的系统变化：

  1. MCA 本身开始被写成需要替换的系统瓶颈，而不只是需要 patch 的多阶段底盘。
  2. 生成式主栈也没有彻底取消 ranking，而是出现了 generator first + reward-model selector 这种更轻的 handoff 形态。

核心判断

OneSearch 的关键不是“搜索版 OneRec”，而是直接把 MCA 当成主瓶颈

如果只看标题，很容易把它理解成：

电商搜索也上了一个 generative model

但这篇 paper 最值得记的地方其实更明确。

arXiv HTML 的引言直接把传统 MCA 写成一组结构性问题：

  1. recall 面向约 10^9 候选。
  2. pre-ranking 缩到约 10^4。
  3. ranking 最后只看约 10^2。

论文认为真正的问题不是单个阶段够不够强，而是：

  1. 计算被切碎了。
  2. 各阶段优化目标互相冲突。
  3. 前一层一旦把真正意图 item 漏掉，后面再强也救不回来。
  4. MCA 对 cold-start query、cold item 和 long-tail session 都不够稳。

这和 GR4AD 不一样。

GR4AD 的主问题更像：

value-aware RL 和 serving budget 怎样一起设计

OneSearch 则更像：

search stack 自己的 recall / pre-ranking / ranking 分工，已经开始成为性能上限

尤其在电商搜索里，这个矛盾更硬。

论文 1 节明确写出三类额外约束：

  1. 商品标题、关键词和详情页文本很长，且常带无关曝光词。
  2. 搜索里的 query-item relevance 约束比推荐强得多，属性错一点就可能完全不相关。
  3. 用户 query 通常只有 2-3 个短词，必须把 query 和用户行为一起用，才能猜对真实意图。

所以 OneSearch 真正修的不是“怎样让大模型吐出 item”，而是：

怎样让一个生成式系统同时接住 query relevance、用户偏好和多阶段目标冲突

这条线不是简单删掉 ranking，而是改成 generator first + reward-model selector

OneSearch 的第二个关键信号，是它没有把搜索改写成“从此完全不需要 ranking”。

论文在线实验里实际上给了两种形态：

  1. 纯生成版本 OneSearch
  2. 生成后再做 reward-model selection 的 OneSearch_RM

正文 4.3 节写得很清楚：

  1. 纯生成 OneSearch 已经可以和完整在线 MCA 打平，甚至在加入 RQ-OPQ 和长行为序列之后，把 Item CTR 提到 +1.45%、PV CTR 提到 +1.40%
  2. 再加上 reward-model selection 的 OneSearch_RM 后，指标进一步全面抬升到 Item CTR +1.67%、PV CTR +3.14%、PV CVR +1.78%、Buyer +2.40%、Order +3.22%

与此同时，论文还做了一个非常关键的反向对照：

MCA w/o ranking

也就是只保留 recall 和 pre-ranking，不再做最终 ranking。

结果非常直接：

  1. Item CTR -9.97%
  2. Buyer -28.78%
  3. Order -39.14%

这组数说明什么？

说明 OneSearch 的工业含义不是：

ranking 不重要了

而是：

ranking 可以不再以旧 MCA 的完整阶段形态存在，但排序能力本身仍然要被 handoff 给一个更轻的后置 selector

这很值得单独记。

因为如果只写“端到端生成式搜索替代了 MCA”，就会丢掉一个更真实的工业结构：

主 stack 已统一，但 ranking capability 仍可能以 reward-model selector 的形式回流

PARS 把 reward consumer 写成了比“上 RL”更工业的三段节奏

OneSearch 的第三个关键点，是它没有把 reward system 写成抽象的“再加一层 RL”。

论文方法部分把 PARS 明确拆成三段：

  1. 多阶段 SFT，先做 semantic alignment 和 personalization
  2. 用 reward model 生成样本，做 preference learning
  3. 再用接近 streaming 的用户交互做 hybrid preference alignment

更关键的是，PDF 的实现细节直接把训练节奏写出来了：

  1. 多阶段监督训练每周做一次
  2. reward system 上的 RL 每天做一次
  3. 用户交互对齐尽量贴近实时流量更新
  4. 但作者也明确说，reward-system RL 即使改成每周训练，通常也不会显著掉收益，只有 11.11 / 6.18 这类大促期例外

这意味着 OneSearch 里 reward 的消费方式，既不是 PROMISE 那种 test-time search controller，也不是 OneMall / GR4AD 那种更重的 retrieval RL 桥。

它更像：

用 reward system 持续校准生成式主栈的排序能力

也就是说，在工业搜索里，reward consumer 还有一类更细的形态：

post-generation preference calibrator

这点和 Story Lab 之前已经补过的几条线放在一起看，会非常重要：

  1. OneSearch 更像 generator + reward selector
  2. OneMall 更像 ranking model -> retrieval reward supplier
  3. GR4AD 更像 list-wise business-value RL + serving-time controller

如果后面不把这些 consumer 分开记，工业 generative 主线仍然会被写扁成同一种“用了 reward”。

最硬的信号不只是涨点，而是 cold-start + OPEX/MFU + 多场景部署

这篇 paper 还有一个很值得单独记的地方：

它给出的最强证据并不只是一组 CTR。

从 4.3-4.4 节可以直接读到三层更有价值的工业信号。

第一层是：

长尾和冷启动也在涨

论文 Table 10/11 给出：

  1. top query Item CTR +1.25%
  2. middle query +2.27%
  3. long-tail query +1.33%
  4. cold item +3.31%
  5. cold user +2.50%

而 warm item / warm user 只有：

  1. warm item +2.34%
  2. warm user +1.11%

这说明 OneSearch 的价值不只是改善热门 query。

它更像是在：

用 unified stack 去补 MCA 对 sparse / cold / long-tail 场景的系统性短板

第二层是：

计算经济性变了

Figure 7 和正文给出的数字很硬：

  1. MFU 从 3.26% 提到 27.32%
  2. OPEX 降到原在线搜索流水线的 24.60%
  3. 也就是运营成本下降 75.40%

这意味着 OneSearch 的收益不只是“排序更准”。

它在做的是：

把 MCA 里大量 communication / memory overhead 换回真正的数值计算

第三层则是：

它已经不是单点实验，而是多搜索场景真实部署

正文明确写到当前部署范围是：

  1. detail page search 全量
  2. mall search 50% 流量
  3. homepage e-commerce search 20% 流量

服务规模则是：

  1. 数百万用户
  2. 日均数千万 PV

外加 Figure 8 给出的：

  1. top 30 个行业里有 28 个行业 CTR 为正向
  2. 平均增益 2.49%

所以这条线当前更适合记成：

industrial paper-first e-commerce search stack unification route

而不是普通 academic generative retrieval paper。

这逼着 Story Lab 再补一列 cascade replacement regime

把 OneSearch 放回站里已有的工业线，会出现一个很具体的问题：

下面这些方法虽然都看上去在做“生成式统一”，但它们接管旧系统的方式并不一样：

  1. OneRec 更接近推荐里的 unified generative retrieval
  2. OneSearch 更接近电商搜索里的 MCA 三段压缩
  3. OneSearch_RM 还保留了一个后置 reward selector
  4. OneMall 则让 ranking model 继续做 reward supplier
  5. GR4AD 又把 value-aware RL 和 serving-time controller 绑进同一个广告栈

所以 Story Lab 后面至少要补一列：

cascade replacement regime

至少先区分：

  1. generator 只做 recall 补源
  2. generator 统一 recall + pre-ranking
  3. generator 直接接管 recall + pre-ranking + ranking
  4. generator 接管主 stack，再保留轻量 post-generation selector

否则 OneSearch 这种“压平三段 MCA，但又给 ranking capability 留一个后置 selector”的路线，很容易继续被写成普通的 generative retrieval。

证据与来源

  • OneSearch: A Preliminary Exploration of the Unified End-to-End Generative Framework for E-commerce Search：arXiv 摘要主入口。页面明确给出提交日期为 2025-09-03，最新版本日期为 2025-10-22；摘要已写清 KHQE / multi-view behavior sequence / PARS、线上 Item CTR +1.67% / Buyer +2.40% / Order +3.22%、OPEX -75.40% 和 MFU 3.26% -> 27.32%。
  • OneSearch arXiv HTML：正文关键入口。1 节写清 MCA 的阶段冲突与电商搜索的额外 relevance 约束，3.4 节写 PARS，4.3-4.4 节给出 OneSearch / OneSearch_RM / MCA w/o ranking 的线上对照，以及 query popularity、cold-start、industry-level gains 和部署范围。
  • OneSearch PDF：用来复核表格与实现细节。PDF 可直接核到 Table 10/11 的 top +1.25% / middle +2.27% / long-tail +1.33%、cold item +3.31% / cold user +2.50%，以及实现细节里的 weekly SFT + daily reward-system RL + near-stream preference alignment。
  • OneSearch 智源社区论文页：当前可稳定回溯到的中文导航层入口。页面把 KHQE / 多视角行为序列 / PARS、CTR +1.67%、Buyer +2.40%、Order +3.22% 与 OPEX -75.4% 压成一页中文摘要。
  • GitHub API 检索 OneSearch + Kuaishou in:name,description,readme、"2509.03236" in:readme,description：截至 2026-03-22，未见稳定官方仓，结果仍以 awesome list 和无关仓为主，因此当前公开边界更适合写成 paper-first。
  • 公开网页继续检索 site:xiaohongshu.com OneSearch 快手 电商 搜索、xhslink OneSearch 快手 电商 搜索 与相关中文组合：截至 2026-03-22，结果仍以财报摘录、聚合资讯和噪声为主，没有拿到稳定高价值 xhslink。

下一步

  • 把 OneSearch 和 OneRec / OneMall / GR4AD 放到同一张快手公开工业路线表里，正式补一列 cascade replacement regime，避免继续把推荐、广告和搜索的 generative 统一都写成一类。
  • 继续沿论文相关工作补 OneSug / EGA / OneLoc / GPR 这条搜索-广告-本地生活 generative family，看看快手公开工业路线是否已经形成比站内当前更完整的 search / recommendation / advertising / local service 四分图。