一文解读端到端生成式推广搜系统

端到端 成式推广搜 系统

https://zhuanlan.zhihu.com/p/1919483420859410276

https://zhuanlan.zhihu.com/p/1953081990136993470

https://docs.qq.com/doc/DSmZUQm96aWxhVVJn?no_promotion=1&is_blank_or_template=blank

端到端生成式广告或推荐系统是怎么做的?

简单来说,端到端生成式(End-to-End Generative)广告或推荐系统 是人工智能领域的一种范式转变。

在传统架构中,广告或推荐通常被看作是一个**"过滤和排序"的问题;而在生成式架构中,它被重新定义为一个 "序列生成"**的问题。

1. 核心架构对比:从"漏斗"到"翻译机"

  • 传统系统(多阶段级联架构):

像一个层层筛选的漏斗。系统先从几亿个商品中召回(Retrieval)出几千个,再进行粗排(Pre-ranking),最后进行精排(Ranking)和重排。每一层都是独立的模型,信息在层与层之间会有丢失,且维护极其复杂。

  • 端到端生成式系统:

像一个大型的翻译机(Transformer)。它将"用户的历史行为"看作输入序列,直接"翻译"(生成)出目标物品的 ID 或内容。它不再需要显式的召回和排序阶段,而是在一个统一的模型中完成从理解用户到决策输出的全过程。

2. 它具体在做些什么?

这类系统目前在工业界(如美团的 EGA、快手的 OneRec、京东的生成式召回)主要做以下三件事:

A. 语义索引(Semantic Indexing / Tokenization)

这是最关键的一步。系统不再把商品看作一个冰冷的数字 ID(如 ID: 12345),而是通过多模态模型将商品编码为语义 ID (Semantic ID)。

例子: 一双"耐克红色跑步鞋"可能被编码为一串代表属性的 Token。这样,模型在生成推荐时,本质上是在构建符合逻辑的"语义序列"。

B. 统一决策(Joint Optimization)

在广告场景中,传统方式是分别算点击率、定出价、选创意。端到端生成式模型(如美团提出的 EGA)尝试在一次生成过程中同时决定:

  1. 推什么 (商品/POI)
  2. 用什么图文 (创意生成)
  3. 出多少钱 (出价策略)
C. 超个性化内容生成(Hyper-personalized Content)

除了推荐已有的商品,生成式系统还可以实时生成最能吸引该用户的广告文案或视觉素材。

  • 以前: 从 10 张现成的海报里选 1 张最合适的。
  • 现在: 根据你的喜好,实时合成一张构图、配色、文案都精准戳中你的新海报。

3. 为什么大家都在往这个方向转?

  1. 打破信息瓶颈: 传统系统各阶段目标不一致(召回只管多,精排只管准),端到端训练让全局目标(如最终转化率)更一致。
  2. 更好地处理冷启动: 因为模型理解语义,即便是一个全新的商品,只要有描述,模型就能通过生成语义 ID 把它推荐给对的人。
  3. 多模态融合: 能够直接理解视频、图片和文本,而不是只靠简单的点击标签。

4. 目前的挑战

虽然效果惊人,但这类系统也面临巨大的挑战:

  • 算力成本: 用大模型(LLM)做实时推荐,每秒处理几十万次请求(QPS),对推理优化要求极高。
  • 实时性: 生成式模型的自回归特性(一个 Token 一个 Token 蹦)天然比简单的向量检索慢。

你想深入了解其中的某项技术实现吗? 例如:

  • 如何将商品 ID 变成可生成的 语义 Token
  • 如何在大规模流量下实现 生成式模型的低延迟推理
  • 或者是具体的工业界案例(如美团的 EGA快手的 OneRec )?

Semantic ID是怎么做的

在生成式广告和推荐系统中,Semantic ID(语义 ID) 是连接"非结构化内容(图文/视频)"与"结构化决策(生成/检索)"的核心桥梁。

简单来说,传统的 ID(如 item_8848)是随机分配的数字,没有任何含义;而 Semantic ID 是一串能够代表商品特征的短代码 (例如 [12, 45, 7]),它反映了商品在语义空间中的位置。

以下是构建 Semantic ID 的主流方法及详细步骤:

1. 核心流程:从"内容"到"离散编码"

目前工业界(如 Google 的 TIGER、快手的 OneRec)最常用的路径是:内容提取 -> 向量化 -> 离散量化。

第一步:内容特征提取 (Item Embedding)

利用预训练模型(如 BERT, Sentence-T5, 或 CLIP)将商品的标题、描述、类目甚至图片转化为一个高维的稠密向量(Embedding) 。这个向量捕捉了商品的深层语义,但它是连续的、无限空间的,不适合 LLM 直接生成。

第二步:分层离散量化 (Hierarchical Quantization)

这是生成 Semantic ID 的关键。最常用的技术是 RQ-VAE (Residual Quantized Variational AutoEncoder)

  • 层级化处理: 将一个 Embedding 分解为多个层级的索引。
    • Level 1 (大类): 找到最接近的中心点(如"鞋类")。
    • Level 2 (细分): 计算残差(Residual),在误差中再找中心点(如"运动鞋")。
    • Level 3 (细节): 继续在剩下的误差里找中心点(如"耐克/红色")。
  • 结果: 最终一个商品被表示为一串数字序列,如 [21, 104, 5]。

2. 为什么用 RQ-VAE?(技术细节)

普通的 K-Means 聚类只能给一个 ID,但 RQ-VAE 的优势在于:

  1. 解决 ID 碰撞: 推荐系统有数亿商品,如果只用一维 ID,码本(Codebook)会巨大到模型存不下。RQ-VAE 通过多级组合(如 256 * 256*256),可以用极小的码本表示数千万个唯一的 ID。
  2. 前缀共享 (Prefix Sharing): 相似的商品在语义空间距离近,它们的 Semantic ID 前几位通常是相同的。这让生成式模型(如 Transformer)只需要生成前两个 Token,就能锁定一大类相关商品,极大提高了检索效率。

3. 三种主流的构建方案对比

|------------------------------------|-----------------------------|------------------------|--------------------|
| 方法 | 实现逻辑 | 优点 | 缺点 |
| 层级聚类 (Hierarchical Clustering) | 对 Embedding 进行树状聚类,路径即为 ID。 | 简单直观,天然具有树状检索结构。 | 聚类中心固定后很难动态更新。 |
| RQ-VAE (基于学习的量化) | 训练一个自动编码器,通过残差量化生成 ID。 | 目前主流 ,信息损失小,压缩率极高。 | 需要额外的模型训练和对齐。 |
| 文本化 ID (Textual ID) | 直接用商品的"品牌-类目-关键词"作为 ID。 | 可读性最强,LLM 无需额外对齐。 | 文本过长导致推理慢,且存在同名歧义。 |

4. Semantic ID 的实战价值

  • 冷启动预测: 新商品上线没有点击数据?没关系,只要把它的文案输入 RQ-VAE,生成一个 Semantic ID,模型就能根据这个 ID 的语义(前缀相似性)把它分发给喜欢同类商品的客群。
  • 生成式检索: 模型不再需要计算几百万次向量余弦相似度,而是像预测单词一样,预测出 [21, 104, 5] 这三个 Token,直接从 KV 数据库取回商品。

你想针对某个具体场景深入探讨吗? 例如:

  • 如何训练一个 RQ-VAE 模型 来适配你的商品库?
  • 如何在 LLM 推荐模型 中使用这些生成的 Semantic ID?

假如有大批新商品加入了呢

在大规模推荐系统中,"新商品加入" (即冷启动问题)是检验 Semantic ID 方案优劣的试金石。

端到端生成式系统处理大规模新商品,主要依靠的是其**"语义外推"能力**,而不是像传统 ID 类模型那样需要重新训练 Embedding 层。以下是具体的处理逻辑:

1. 实时生成语义指纹 (On-the-fly Inference)

对于新加入的一批商品,系统不需要等待模型重新训练,而是利用已经训练好的 Encoder(编码器)Quantizer(量化器) 实时"生产" ID。

  1. 特征提取: 将新商品的标题、主图、属性(如:耐克、新款、夏季、透气)输入预训练的多模态模型(如 CLIP)。
  2. 残差量化: 将得到的 Embedding 放入之前训练好的 RQ-VAE 码本中。
  • 即使这个特定商品没见过,但"耐克"和"跑步鞋"的特征向量在空间中是存在的。
  • 量化器会将其分配到最接近的语义簇中,生成如 [12, 45, 109] 这样的 Semantic ID。

核心优势: 新商品从进入系统的那一刻起,就拥有了和老商品同一套话术(ID 体系) ,可以直接被生成式模型识别。

2. 生成式模型的"前缀感知"分发

由于 Semantic ID 是分层的(从大类到细节),生成式模型(Transformer)对新商品具有天然的泛化能力

  • 前缀匹配: 如果新商品的 Semantic ID 前两位是 [12, 45],代表"夏季运动鞋"。
  • 模型决策: 虽然模型没见过这个完整 ID [12, 45, 109],但它在训练中已经学会了:"当用户近期搜索过透气运动袜时,生成 [12, 45, *] 序列的概率会增加。"
  • 结果: 新商品通过共享前缀,直接挂载到了成熟的推荐路径上,实现了"零样本"或"极少样本"的推荐。

3. 如何应对"语义漂移"与"码本饱和"?

当新商品不仅是数量多,而且出现了全新类别 (例如:系统以前只有服装,现在增加了数码产品)时,会有两种应对策略:

A. 虚索引与占位符 (Virtual Tokens)

在设计 Semantic ID 的码本(Codebook)时,通常会预留一定的冗余度

  • 例如每个层级有 256 个中心点,但目前只用了 200 个。
  • 新出现的细分语义会被分配到剩下的 56 个空闲中心点上,而不需要改变整体模型结构。
B. 增量微调 (Incremental Fine-tuning)

如果新商品导致语义空间发生了剧烈变化,工业界通常采用 Lightweight Tuning

  • 冻结 Transformer 主模型。
  • 只更新 RQ-VAE 的码本(Codebook)或映射层。
  • 这样既能让新商品获得准确的 ID 编码,又不会破坏大模型已经学到的推荐逻辑。

4. 流程总结:新商品入库链路

|--------|-------------------|----------------------------|
| 阶段 | 动作 | 结果 |
| 入库 | 提取图文特征向量 | 得到稠密向量 |
| 量化 | 映射到现有 RQ-VAE 码本 | 得到 Semantic ID:[A, B, C] |
| 对齐 | 更新向量索引(Vector DB) | 新 ID 即可被检索生成 |
| 分发 | 生成式模型根据 A, B 前缀预测 | 流量自动导入新商品 |

5. 潜在问题:碰撞与精度

当商品量级从千万级跃升到十亿级时,可能会出现两个完全不同的商品分到了同一个 Semantic ID。

  • 对策: 增加 Semantic ID 的序列长度 (从 3 位增加到 4-6 位)或增加每一层的码本容量 。这就像从 3 位电话区号升级到 4 位,可以容纳更多的用户。

你想了解如何设计一个能容纳亿级商品的 RQ-VAE 码本参数吗? 或者我们可以聊聊美团或快手是如何在生产环境中处理这种大规模更新的?

设计亿级商品规模的 Semantic ID 系统

设计一个能支撑亿级(10^8) 商品规模的 Semantic ID 系统,核心挑战在于平衡 "唯一性" (不碰撞)、"语义化" (好理解)和**"计算效率"**(推理快)。

以下是工业界(如 Google TIGER 论文和美团实践)设计这类系统时的关键参数和策略:

1. 码本参数设计:如何计算容量?

Semantic ID 的总容量遵循乘法原理:Capacity=KL

  • K:每一层码本的大小(Codebook Size,即每层有多少个聚类中心)。
  • L:序列的层数(层级深度)。

推荐配置方案:

对于 1 亿商品,我们需要 Capacity > 108。

|----------|--------------|------------|---------|--------------------------------------------------------|
| 配置方案 | 每层大小 (K) | 层数 (L) | 总容量 | 评价 |
| 浅而宽 | 10,000 | 2 | | 推理快,但语义区分度不够精细。 |
| 深而窄 | 256 | 4 | | 最常用 。256 符合计算机 8-bit 对齐,计算效率极高,且 4 层深度能提供极细的语义颗粒度。 |

2. 核心架构:分层残差量化 (RQ-VAE)

为了让这 4 层数字真正代表语义,我们需要通过 RQ-VAE 进行训练。

训练逻辑:

  1. 第一层(粗粒度): 将商品 Embedding 映射到第一个码本,得到 。
  2. 残差计算: 用原始向量减去 对应的向量,得到"剩下的信息"。
  3. 第二层(中粒度): 对残差进行量化,得到 。
  4. 循环往复: 最终得到一个序列 [ID_1, ID_2, ID_3, ID_4]。

效果: ID_1 可能代表"家电",ID_2 代表"厨房电器",ID_3 代表"破壁机",ID_4 代表"特定功率和品牌"。

3. 解决亿级规模下的三大难题

A. 索引冲突(Collision)

即便容量足够,聚类不均也会导致成千上万个商品挤在同一个 ID 上。

  • 策略: 在训练 RQ-VAE 时加入 Commitment Loss (防止向量漂移)和 Codebook Refresh (重新激活那些很少被用到的聚类中心),确保码本被均匀利用。
B. 语义漂移(Semantic Drift)

新商品如果带有全新的特征,老码本可能表示不准。

  • 策略: 采用 多模态对齐 。不要只用文本或只用图片,而是将 CLIP 提取的图文融合向量作为 RQ-VAE 的输入。这样即使标题写得烂,通过图片也能准确分类。
C. 训练与在线不一致

如果码本变了,以前生成的 ID 就全废了。

  • 策略: 固定基座,增量映射。 核心码本一旦在亿级数据上练好,就不轻易大改。对于新奇特商品,通过一个小的线性层(Projector)将其投影到现有的语义空间。

4. 工业界落地案例参考

  • Google TIGER (2023): 采用了这种分层语义 ID,配合 Transformer。实验证明,它在检索长尾(冷启动)商品上的表现远超传统的双塔向量模型。
  • 快手 OneRec: 强调了 Semantic ID 的"前缀一致性"。当系统预测出前两个 ID 时,就可以直接触发底层的高效算子进行并行检索,极大降低了生成式推荐的延迟。

5. 总结:下一步怎么做?

如果你要从零开始搭建:

  1. 收集数据: 拿到全量商品的 Embedding(用 CLIP 或 BERT)。
  2. 训练 RQ-VAE: 设定 K=256, L=4。
  3. 构建 ID 库: 将 1 亿商品全部跑一遍模型,得到一串 (item_id, semantic_tokens) 的映射表。
  4. 喂给大模型: 让你的生成式模型开始学习:"给定的用户序列 -> 下一个 Semantic ID"

你想深入了解具体的 RQ-VAE 模型代码实现吗?或者是这类系统在检索时如何处理"重排"逻辑?

检索时如何处理"重排"逻辑?

在传统的推荐架构中,"重排"(Re-ranking)位于漏斗的最底端,负责处理多样性、打散、商业策略(如置顶广告)以及上下文感知。

端到端生成式广告/推荐系统 中,重排逻辑的处理方式发生了根本性的变化,主要分为两种路径:"由模型生成" "在生成后干预"

1. 路径一:列表级生成(List-wise Generation)

这是最硬核的端到端方案。模型不再是一个一个生成商品,而是直接生成一个有序列表

  • 逻辑: 模型的输出序列不再是 [ID_1],而是 [ID_1, ID_2, ID_3... ID_N]。
  • 重排的内生化: 在训练时,模型学习的是整个序列的奖励(Reward)。如果 ID_1 和 ID_2 过于相似(比如都是红色运动鞋),模型在序列生成的下一步会因为"多样性惩罚"而降低生成相似 ID 的概率。
  • 优势: 模型天然考虑了商品之间的相互影响(Contextual Relation) ,解决了传统系统里"每个商品独立打分,结果堆在一起很重复"的问题。

这是目前工业界更具落地性的方案。在模型生成 Semantic ID 的解码过程中,通过修改**束搜索(Beam Search)**的逻辑来实时插入重排策略。

  • 多样性打散(Diversity): 当模型准备生成下一个商品的第一个 Semantic Token 时,如果发现这个 Token 代表的类目(如"数码")在已生成的序列中占比过高,就人为降低该 Token 的概率分数(Logits)。
  • 商业策略注入: 如果有"强插广告"或"必须置顶"的需求,可以直接在解码的第一步强行指定某个 Semantic ID 的前缀。
  • 硬约束过滤: 例如用户设置了"不看某些类目",在生成概率分布(Softmax)时,直接将对应类目 ID 的概率设为 -∞。

3. 路径三:生成后的轻量级重排(Post-Generation Re-ranking)

虽然目标是端到端,但为了性能和灵活性,许多系统仍然保留了一个微型的重排层。

  1. 生成候选池: 生成式模型利用 Beam Search 产出 Top-K 个高质量序列(例如 5 组不同的推荐列表)。
  2. 重排器打分: 使用一个极简单的线性模型或规则引擎,对这 5 组序列进行整体评估。
  3. 评价维度:
    1. 多样性得分: 1 - \\text{similarity}(items)
    2. 业务价值: 预估 GMV、广告收入。
    3. 实时反馈: 考虑用户刚刚 1 秒前的点击行为。

4. 挑战:生成式重排的"窗口"难题

传统重排可以处理几百个候选集,但生成式模型由于计算量大,通常只能生成较短的序列。

  • 滑动窗口策略: 先生成前 10 个商品,展示给用户;同时异步生成接下来的 10 个。
  • 分层解耦: * 第一阶段: 生成式模型生成"语义路径"(即 Semantic ID 的前缀,代表兴趣点)。
    • 第二阶段: 在每个路径下快速填充具体的商品,进行精细化重排。

5. 总结:重排逻辑的演进

|----------|----------------------------------------|----------------------------|
| 维度 | 传统重排 | 生成式重排 |
| 处理对象 | 独立的候选商品集合 | 连续的 ID 序列 |
| 核心算法 | MMR (Maximal Marginal Relevance) / DPP | 序列建模 (Transformer) / 带约束解码 |
| 实时性 | 极高(计算简单的相似度矩阵) | 较低(受限于自回归生成速度) |
| 效果 | 局部最优(解决打散问题) | 全局最优(解决序列组合问题) |

你想看看如何在代码层面实现"带约束的 Beam Search"(即在生成时强行打散类目)吗? 或者我们可以聊聊生成式重排如何与广告的出价(Bidding)逻辑结合?

生成式重排如何与广告的出价(Bidding)逻辑结合

在生成式广告系统中,出价(Bidding) 不再是排序后的一个简单乘法因子,而是被嵌入到了 序列生成 的过程中。

传统的公式是 RankScore = pCTR \\times pCVR \\times Bid。而在生成式重排中,出价逻辑通过以下三种方式与模型深度耦合:

1. 约束解码:将出价作为"概率修正器"

在生成 Semantic ID 的每一步(Beam Search)中,模型会输出一个原始的概率分布(Logits)。此时,我们可以将广告的出价转化为一个偏置项(Bias)

  • 逻辑: Adjusted\\_Logits = \\text{Model\\_Logits} + w \\cdot \\log(\\text{Bid})
  • 操作: 1. 当模型预测下一个 Token 时,系统实时查询该 Semantic ID 对应的广告主出价。
  1. 高出价的广告会获得更高的 Logits 增量,从而在束搜索(Beam Search)中更容易"存活"并出现在序列的前端。
  • 优点: 这种方式在生成的瞬间就考虑了商业价值,而不是等列表生成完了再强行插入。

2. 奖励引导:基于强化学习(RL)的重排

如果把生成一个推荐列表看作是一个任务,那么**广告收入(Ad Revenue)**就是最直接的 Reward。

  • 训练阶段: 使用强化学习(如 PPO 算法)。模型生成一个序列,环境返回两个信号:
    • 用户体验反馈: 点击率、停留时间(确保用户不反感)。
    • 商业收益反馈: 广告的 eCPM(出价 \\times 点击率)。
  • 重排效果: 模型会学习到一种平衡------在不牺牲太多用户体验的前提下,将高出价且有点击潜力的广告生成的顺序往前排。

3. 生成出价(Generative Bidding / Auto-Bidding)

这是最前沿的方向:模型不仅生成推荐什么,还同时生成该出价多少。

在一些复杂的端到端系统中(如美团的 EGA),模型输出的序列可能包含特殊的 Action Tokens

输出示例: [Item_ID_A, Bid_Token_High, Item_ID_B, Bid_Token_Low]

  • 统一优化: 模型根据当前的上下文(用户很想买、竞争对手少),自动生成一个最优的出价策略 Token。
  • 闭环决策: 这意味着出价不再是广告主手动设置的死数字,而是系统根据生成序列的整体点击概率,自动计算出的能让总收入最大化的动态值。

4. "广告-自然"混合生成的重排策略

生成式系统最大的优势是能够处理广告与自然结果的交互(Cannibalization)

|----------|---------------------|--------------------------------------|
| 策略 | 传统做法 | 生成式做法 |
| 位置分配 | 固定槽位(如第 3, 5 位是广告)。 | 动态生成(根据语义流,决定在哪里插广告最不违和)。 |
| 出价影响 | 简单提升排名。 | 改变整个序列的路径(高出价可能引导模型生成一套完全不同的周边配套推荐)。 |
| 预算控制 | 外部平滑扣费。 | 将剩余预算作为模型的输入特征(Prompt),影响生成概率。 |

5. 总结:一个典型的生成式广告重排流程

  1. 输入: 用户历史行为 + 当前上下文 + 广告主实时出价。
  2. 第一步生成: 模型给出几个潜在的语义兴趣点(Token 序列前缀)。
  3. 动态调优: 结合出价因子,对高价值路径进行概率加权。
  4. 序列产出: 最终生成的 [ID_1, ID_2, ID_3] 是一个在"用户喜欢"和"广告主给钱多"之间达到 Nash 均衡 的有序列表。

你想深入了解如何通过强化学习(RL)来训练这个平衡点击率和出价权重的模型吗? 或者是对其中的 "动态插槽"(Slot Allocation) 技术感兴趣?

生成式搜索系统的做法和广告推荐有何不同

这是一个非常敏锐的问题。虽然它们都开始转向**端到端生成式(Generative)架构,但由于三者的 "底层驱动力"**不同,导致它们在生成逻辑上有显著差异。

简单来说:搜索求"准",推荐求"爽",广告求"效"。

1. 核心任务目标的差异

|----------|-------------------------------------|----------------------------|---------------------------|
| 维度 | 生成式搜索 (Generative Search / RAG) | 生成式推荐 (Generative Rec) | 生成式广告 (Generative Ad) |
| 驱动力 | 意图驱动 (Query-based) | 兴趣驱动 (Behavior-based) | 利益驱动 (Revenue-based) |
| 生成内容 | 答案/摘要 + 引用来源 | 物品序列 (Item IDs) | 创意内容 + 出价策略 |
| 评价指标 | 准确性 (Factuality)、相关性 | 点击率 (CTR)、多样性、时长 | 转化率 (CVR)、ROI、eCPM |

2. 生成逻辑的具体不同

A. 搜索系统:从"检索"转向"合成"

搜索系统目前的主流是 RAG (检索增强生成)生成式索引 (DSI)

  • 搜索在生成什么: 它生成的是逻辑连贯的文本答案
  • 关键区别: 搜索非常强调**"确定性"**。模型生成的每一句话都必须有据可查(Attribution)。
  • 技术点: 搜索系统会先生成"查询计划"(Query Plan),然后生成多个检索词,最后将检索到的碎片信息"缝合"成一个答案。
B. 推荐系统:从"过滤"转向"联想"

推荐系统(如前面讨论的 Semantic ID 方案)更像是一个序列补全 任务。

  • 推荐在生成什么: 它生成的是概率分布 。它在问:"看了 A 和 B 的用户,下一个最可能点击的 Token 是什么?"
  • 关键区别: 推荐允许**"发散"**。它不需要像搜索那样必须严格匹配用户输入的字面意思,而是生成符合用户潜在心理预期的语义序列。
C. 广告系统:从"匹配"转向"博弈"

广告系统在生成的过程中,加入了一个外部变量------第三方利益(广告主)

  • 广告在生成什么: 它生成的是**"最优成交路径"**。
  • 关键区别: 广告生成必须考虑**"反向约束"**。
    • 推荐只考虑用户。
    • 广告生成时,模型必须在"生成用户喜欢的 Token"和"生成出价高的 Token"之间做权衡(Trade-off)
    • 甚至会生成**"动态创意"**:针对同一个 Semantic ID,为用户 A 生成清新的文案,为用户 B 生成促销类的文案。

3. 架构上的微妙区别

1. 索引结构的差异
  • 搜索: 倾向于保留倒排索引 或稠密向量索引,生成模型主要用于对检索结果进行重写或总结。
  • 推荐: 正在尝试完全抛弃索引,将商品信息压缩进模型参数中(即 Model-as-Index ),通过生成 Semantic ID 直接出结果。
2. 对"冷启动"的处理
  • 搜索: 新内容通过爬虫抓取并实时向量化,生成模型通过 RAG 立即就能"看到"并引用。
  • 广告/推荐: 新商品需要经过 Semantic ID 编码器 转化,将其映射到已有的语义空间中,生成模型才能"梦到"它。
3. 实时性与交互
  • 搜索: 强调单次交互 的质量。生成过程可以稍慢(如 1-2 秒),只要答案好。
  • 推荐/广告: 强调高频交互 。必须在几百毫秒内生成整个列表,因此对生成算法的并行度(如使用非自回归生成)要求极高。

4. 总结对比图

  • 生成式搜索: 像一个严谨的学者 ,在翻阅资料后给你写一份准确的报告。
  • 生成式推荐: 像一个懂你的朋友 ,根据你的习惯猜你下一步想干什么。
  • 生成式广告: 像一个精明的导购 ,既要让你开心,又要帮商店把利润最高的东西卖出去。

你想针对这三者中的哪一个深入了解其底层算法结构? 比如:

  • 生成式搜索中的 RAG 架构 如何保证不产生幻觉?
  • 生成式广告中如何实现 文案-图片-商品 的全栈生成?

生成式搜索是怎么做的?

在生成式搜索(Generative Search)领域,目前存在两条截然不同的技术路径:一种是目前主流的 RAG(检索增强生成) ,另一种是更激进、更符合"端到端"定义的 DSI(可微分搜索索引)

1. 路径一:RAG(检索增强生成)------ 工业界的主流

这是目前 Perplexity、Google Search Generative Experience (SGE) 采用的方案。它并不是完全抛弃索引,而是将"找信息"和"写答案"解耦。

核心流程:

  1. 意图理解(Query Rewriting): 将用户破碎的提问改写为适合搜索引擎检索的关键词。
  2. 检索(Retrieval): 在向量数据库或网页索引中找到 Top-K 个相关的片段(Chunks)。
  3. 重排与精炼(Rerank & Selection): 过滤掉不相关的噪声,只保留最核心的证据。
  4. 生成(Generation):用户问题 + 检索到的事实 一起喂给大模型,让它生成带引用(Citations)的回答。

2. 路径二:DSI(可微分搜索索引)------ 真正的"端到端"

这是由 Google Research 提出的概念,它试图让模型直接"记住"整个互联网。在 DSI 中,模型即索引(Model-as-Index)

它是如何工作的?

  • 文档 ID 化: 给每个网页或文档分配一个 Semantic ID (类似于我们之前讨论的推荐系统方案)。
  • 模型训练: 让 Transformer 模型学习从"查询文本"直接映射到"文档 ID 序列"。
    • 训练目标: 输入 "如何制作披萨" -> 输出 [ID_77, ID_21, ID_5]。
  • 端到端检索: 当你搜索时,模型不再去查外部数据库,而是直接在神经元里进行"联想",输出对应的文档 ID。

3. 生成式搜索的关键技术点

A. 幻觉控制(Hallucination Control)

生成式搜索最怕模型"胡说八道"。

  • 归约化(Attribution): 模型在生成每一句话时,必须标注出处(如 [1], [2])。
  • 一致性校验: 系统会反向检查生成的内容是否与检索到的原始文档逻辑一致。
B. 检索触发判断(Retrieval Trigger)

并不是所有问题都需要生成式处理。

  • 如果用户搜 "123+456",系统直接生成计算结果。
  • 如果用户搜 "最新的地震新闻",系统必须触发 RAG 检索最新的网页,而不是靠模型旧的记忆。
C. 长上下文处理(Long Context Window)

端到端搜索往往涉及阅读几十篇文档。现在的系统通过 Flash Attention 等技术,将上下文窗口扩大到 128k 甚至更高,以便一次性处理更多背景资料。

4. 搜索 vs 推荐/广告在"端到端"上的区别

虽然都叫端到端,但搜索的实现难度通常更高:

|----------|-------------------------|---------------------|
| 挑战维度 | 搜索 (Search) | 推荐/广告 (Rec/Ad) |
| 时效性 | 极高 (分钟级更新,如突发新闻)。 | 中等(天/小时级,商品库存变化)。 |
| 真实性 | 红线 (绝对不能出错,否则失去信任)。 | 较低(推错了用户最多不点,不算错误)。 |
| 输入长度 | 用户可能输入很长的描述或复杂问题。 | 输入主要是用户的历史行为 ID 序列。 |
| 输出形式 | 结构化的自然语言 + 文档链接。 | 纯粹的 ID 列表或简单的图文卡片。 |

未来的生成式搜索将从"一次性生成"转向"多步推理(Reasoning)":

  1. 拆解: 将复杂问题拆成 3 个子问题。
  2. 搜索: 分别搜索,发现第 2 个子问题的信息不够。
  3. 反思: 调整关键词重新搜索,最后汇总生成。

你想深入了解 DSI 这种"模型即索引"的具体训练算法(如参数化索引)? 还是想看看 RAG 架构中如何解决"引用来源对齐"的问题?

九、 DSI 这种"模型即索引"的具体训练算法

在端到端生成式搜索中,DSI(Differentiable Search Index,可微分搜索索引) 的核心思想是:抛弃外部的向量数据库或倒排索引,直接将整个文档库的索引信息"压缩"进 Transformer 模型的权重(Weights)中。

要实现这一点,其训练算法主要分为 "索引任务(Indexing)""检索任务(Retrieval)" 两个阶段。以下是具体的算法实现逻辑:

1. 文档标识符(DocID)的设计:训练的"标签"

在 DSI 中,文档不再以文本形式存储,而是映射为模型可以生成的 DocID

  • Atomic IDs(原子 ID): 每个文档分配一个唯一的数字 Token。
    • 缺点: 无法扩展到亿级文档(词表会爆炸)。
  • Hierarchical Semantic IDs(分层语义 ID): (主流方案)
    • 做法: 对文档进行聚类(如层级 K-Means)。
    • 结果: 文档 A 可能变成序列 [12, 45, 7]。这样模型只需要生成 3 个 Token 就能锁定一个文档。
    • 优点: 语义相近的文档 ID 前缀相同,模型更好学。

2. 核心训练算法:两个关键任务

DSI 采用的是一种 Multi-task Sequence-to-Sequence (Seq2Seq) 的训练模式,通常基于 T5 架构。

任务 A:索引任务(Indexing / Memorization)

这是为了让模型"记住"文档内容。

  • 输入: 文档的正文片段(如前 512 个词)。

  • 目标: 生成该文档对应的 DocID

  • 损失函数: 标准的交叉熵损失(Cross-Entropy Loss),即:

  • 关键策略: * Span Corrupt: 随机掩盖文档中的部分段落,让模型预测 DocID,增强鲁棒性。

    • Doc2Query(预测增强): 先用另一个模型根据文档生成几个"假问题",然后训练 DSI 模型根据这些假问题生成 DocID。这能极大地缩小"索引"和"检索"之间的 Gap。
任务 B:检索任务(Retrieval)

这是为了让模型学会根据真实用户问题找到文档。

  • 输入: 用户的搜索 Query。
  • 目标: 生成相关文档的 DocID
  • 损失函数:

3. 在线推理:如何"检索"?

当用户输入一个新 Query 时,DSI 不再计算向量相似度,而是进行 生成推理

  1. 约束束搜索(Constrained Beam Search):
    1. 模型开始一个 Token 一个 Token 地生成 DocID。
    2. 约束: 模型每一步生成的 Token 必须存在于已有的"DocID 树"中(防止生成不存在的 ID)。
  2. 获取排名:
    1. 束搜索会返回 Top-K 条路径。
    2. 每条路径的累计概率分值,就是该文档的相关性得分

4. DSI 算法面临的挑战与解决方案

|------------------------|------------------------------------------------------------------------------------|
| 挑战 | 工业界解决方案 |
| 灾难性遗忘 (Forgetting) | 当学习新文档时,模型会忘了旧文档。解决:使用 增量学习(Continual Learning) 或在训练新文档时带入一部分旧文档数据(Rehearsal)。 |
| 扩展性 (Scalability) | 模型参数有限,存不下数亿个文档。解决:混合架构 。将 DSI 用于高频、核心的库,将 RAG 用于长尾网页。 |
| 更新困难 | 新文档加入需要微调模型。解决:DSI++ 算法,通过参数高效微调(PEFT/LoRA)快速插入新节点。 |

5. 总结:DSI 的训练精髓

DSI 的本质是将搜索问题转化为一个 "翻译问题" :将 "模糊的语言空间" 翻译到 "结构化的 ID 空间" 。它通过在大规模文档-ID 对上进行"死记硬背"(索引)和在查询-ID 对上进行"理解泛化"(检索),实现了完全去索引化的端到端搜索。

你想深入了解如何用代码(例如基于 HuggingFace T5)来实现一个微型的 DSI 索引任务吗? 或者我们可以讨论 DSI 在处理突发新闻(时效性要求极高)时有哪些优化手段?

相关推荐
筑梦悠然2 小时前
AI的攻坚克难
人工智能
白日做梦Q2 小时前
实时语义分割:BiSeNet与Fast-SCNN深度对比与实践启示
人工智能·深度学习·计算机视觉
云和数据.ChenGuang2 小时前
Uvicorn 是 **Python 生态中用于运行异步 Web 应用的 ASGI 服务器**
服务器·前端·人工智能·python·机器学习
IT_陈寒2 小时前
SpringBoot 3.0实战:这5个新特性让你的开发效率提升50%
前端·人工智能·后端
mr_orange_klj2 小时前
k8s StorageClass和Provisoner的AI问答(豆包)
人工智能·容器·kubernetes
向量引擎2 小时前
复刻“疯狂的鸽子”?用Python调用Sora2与Gemini-3-Pro实现全自动热点视频流水线(附源码解析)
开发语言·人工智能·python·gpt·ai·ai编程·api调用
延凡科技2 小时前
延凡智慧工厂:制造业数智化转型的 “超级引擎“
人工智能
in12345lllp2 小时前
待业人群做AI兼职缓解经济压力?
人工智能
云和数据.ChenGuang2 小时前
fastapi flask django区别
人工智能·python·django·flask·fastapi