BGE GES EGES
三个模型的核心概念与详细举例
Embedding（嵌入）本质上是将高维稀疏的ID映射为一个低维稠密向量（如128维或160维）。
向量之间的“距离”（点积）代表商品的相似度。
BGE（Base Graph Embedding）—— 行为序列建模器
核心概念：仅利用用户点击/购买的时序行为构建有向带权图，通过随机游走生成“商品序列”，再用Word2Vec的Skip-Gram思想训练向量。
它捕获的是行为上的共现关系（高阶相似性）。
详细举例：
假设用户行为序列为：[iPhone14, 钢化膜, 手机壳]，另一个用户：[iPhone14, 快充头]。
BGE构建的图中，iPhone14 -> 钢化膜的边权重+1，iPhone14 -> 手机壳+1。
随机游走可能生成序列iPhone14 -> 钢化膜 -> 手机壳。
训练后，钢化膜和手机壳的向量会非常接近（因为都在iPhone14后出现）。
但如果一个新上架的“MagSafe充电宝”零销量，图中没有它的节点，BGE彻底失效。
GES（Graph Embedding with Side Information）—— 属性均值融合器
核心概念：在BGE基础上，将商品的侧信息（Side Information）向量与商品自身向量做算术平均。
它强制让“属性相似”的商品在空间中也相似，解决冷启动。
详细举例：
针对那个零销量的“MagSafe充电宝”（冷启动商品），它带有属性：类目=充电宝，品牌=Apple，适用机型=iPhone。
系统已经训练好了这些属性的向量。
GES在生成该充电宝的最终向量H_v时，直接计算：H_v = (Vec(商品ID默认零向量) + Vec(充电宝类目) + Vec(Apple品牌) + Vec(iPhone适配)) / 4。
因为这个平均向量靠近“Apple配件”区域，所以当用户浏览iPhone时，这个冷启充电宝会被召回。
缺点：它默认“类目”、“品牌”、“适配机型”的重要性完全一样。
EGES（Enhanced GES）—— 自适应加权融合器
核心概念：在GES基础上，为每个商品的每种侧信息单独学习一个权重系数（公式7中的 a_v^j），通过Softmax归一化后进行加权求和。
让模型自己判断，对于“当前这个具体商品”，哪种属性最值得参考。
**详细举例：**还是那个“MagSafe充电宝”。
由于带有“Apple”品牌，训练器发现用户买充电宝极度看重品牌，于是给品牌对应的权重a打了 9.0，给类目打了 5.0，给价格打了 2.0。
另一个冷启动商品是“无品牌、纯棉白T恤”，训练器发现用户买T恤更看重店铺（是否常买的那家）和面料，品牌几乎没有区分度，于是给店铺权重打 8.0，给品牌权重打 0.5。
EGES通过反向传播，动态调整这些权重，效果显著优于GES的硬平均。
DeepWalk 与 转移概率 在其中的核心作用
这三个模型的“骨架”都是基于随机游走的图嵌入，DeepWalk和转移概率是BGE得以成立的根基，GES和EGES只是修改了节点的表示方式，但训练流程完全依赖它们。
DeepWalk的作用（宏观框架）：它是将“图结构”转化为“文本序列”的桥梁。类比Word2Vec处理句子，DeepWalk把商品图上的随机游走路径当作“句子”，路径上的节点当作“单词”。只有生成了海量序列，才能调用Skip-Gram进行训练。
转移概率（公式2）的作用（微观导航）：它决定了随机游走具体往哪个邻居节点跳转。
公式：$ P(v_j|v_i) = \frac{M_{ij}}{\sum_k M_{ik}} $，即从当前节点i跳转到邻居j的概率 = 边(i,j)的权重 / 节点i所有出边权重之和。
例子：假设节点iPhone14有两条出边：去钢化膜的权重为100（超级多人买），去MagSafe充电宝的权重为1（极少人买）。那么转移概率去钢化膜是99%，去充电宝是1%。
在训练中的作用：高转移概率的路径会频繁出现在训练序列中，使得iPhone14和钢化膜的向量内积越来越大.
低转移概率的边会被负采样压制。冷启商品（如MagSafe）若没有边，就靠GES/EGES注入的侧信息向量来“碰瓷”近似邻居。
EGES模型底层的“Sparse Feature”是什么？
看图3最底层，Sparse Feature（稀疏特征）是指输入数据的One-hot（独热）编码形式。
具体形态：假设淘宝有20亿个商品ID，对于当前商品“iPhone14”，它的Sparse Feature是一个20亿维的向量，其中只有iPhone14对应索引的位置是 1，其余全是 0。
同样，对于“品牌=Apple”，也是一个几百万维的独热向量，只有Apple那个位置是1。
为什么叫“稀疏”：因为绝大多数维度是0，极度稀疏。物理上不可能真的存储这个20亿维的全零大向量，而是只存储非零索引的整数ID（如存储一个数字“882345”代表商品ID）。
Item数据量巨大（20亿），业界真的都用One-hot吗？会不会太恐怖？
**结论：**业界（尤其是阿里、Google、Meta）确实都是这么做的，但并非进行恐怖的“20亿维稠密矩阵乘法”，而是通过Embedding Lookup（嵌入查表）来化解。
具体技术细节如下：
查表代替乘法：
在神经网络中，One-hot向量 [0,0,…,1,…,0 乘以权重矩阵 W（维度 20亿×128），其结果恰好等于取出 WW 中对应索引的那一行（128维向量）。
因此，工程上压根不构建One-hot向量，也不做矩阵乘法，而是直接维护一个巨大的Embedding字典（Hash表），输入ID直接map出那一行的稠密向量。这种操作的时空复杂度是 O(1。
海量ID带来的存储挑战：
20亿商品 × 160维 × 4字节（Float32）= 128 GB。这仅是一个嵌入矩阵的大小。
业界通常采用以下方案应对：
- 分布式PS（Parameter Server）架构：将128GB的嵌入矩阵切分打散到数百台CPU机器上存储（如论文提到的ODPS平台）。
- 动态哈希与频率截断：只保留点击量大于某个阈值（如10次）的商品ID进行Embedding训练。长尾冷启商品，直接退化为纯侧信息平均（GES），不占用宝贵的ID嵌入存储。
- 混合精度训练：使用FP16存储，将内存砍半。
侧信息（Side Information）的规模：
虽然商品有20亿，但类目（几万个）、品牌（几十万个）、店铺（几百万个）的数量级远小于商品数。
将这些小规模词表做One-hot映射到Embedding，内存开销完全可控（通常只有几GB）。
结论：业界不仅这么干，而且这是推荐系统领域的绝对标准范式（被称为“大规模稀疏特征嵌入”）。
论文中特意写“Sparse features tend to be one-hot-encoder vectors”，正是为了告诉学术界的读者，虽然理论上维度极高，但在工业级XTF平台上，我们是通过稀疏索引 + 分布式查表来实现的，效率和内存都是精心优化过的，绝不会真的去算20亿维的向量乘法。
