PAI-Rec的RealTimeU2IRecall 如何使用内置的i2i 缓存功能

简介: `RealTimeU2IRecall` 内置物品级本地LRU缓存(I2ICacheSize/I2ICacheTime),对trigger item的相似商品列表进行内存缓存,命中即用、未命中批量查FeatureStore并写入负缓存,兼顾实时性与性能,显著降低下游查询压力。

概述

RealTimeU2IRecall 内置了 I2I(物品到物品)缓存功能,可以对 trigger item 的相似 item 列表进行本地内存缓存,在保留用户行为实时性的同时,减少 FeatureStore 的查询压力。


配置方式

在 RecallConfs 的 RealTimeUser2ItemDaoConf 中添加 I2ICacheSize 和 I2ICacheTime:

{
   
  "RecallConfs": [
    {
   
      "Name": "realtime_u2i",
      "RecallType": "RealTimeU2IRecall",
      "RecallCount": 200,
      "RealTimeUser2ItemDaoConf": {
   
        "UserTriggerDaoConf": {
   
          "FeatureStoreName": "fs_pairec",
          "FeatureStoreViewName": "user_behavior_seq",
          "ItemCount": 20,
          "TriggerCount": 10,
          "EventWeight": "click:1.0;buy:3.0",
          "WeightExpression": "1.0 / (1.0 + (currentTime - eventTime) / 3600.0)"
        },
        "Item2ItemFeatureViewName": "item_i2i_table",
        "I2ICacheSize": 100000,
        "I2ICacheTime": 3600
      }
    }
  ]
}

配置字段说明

字段 类型 说明
I2ICacheSize int I2I 缓存的最大条目数(LRU 本地缓存),设为 0 或不设则不启用
I2ICacheTime int 缓存过期时间(秒),默认 3600 。保证i2i数据凌晨更新,则影响不大。

缓存工作原理

执行流程

用户请求
  ↓
1. 从 FeatureStore 读取用户行为序列
   → 得到 trigger item 列表(如 [itemA, itemB, itemC])
  ↓
2. 对每个 trigger item,查 I2I 缓存:
   - cache.GetIfPresent("itemA") → 命中:直接用缓存的相似 item 列表
   - cache.GetIfPresent("itemB") → 未命中:加入待查询列表
  ↓
3. 对未命中缓存的 trigger item,批量查 FeatureStore 的 I2I 表
  ↓
4. 查到的结果写入缓存:
   cache.Put("itemB", "sim_item1:0.9,sim_item2:0.8,...")
  ↓
5. 如果某个 trigger item 在 I2I 表中无数据,写入空值(负缓存):
   cache.Put("itemX", "")

核心逻辑说明

  • Cache Key:trigger item 的 item_id
  • Cache Value:该 item 的相似 item 列表,格式为 item_id1:score1,item_id2:score2,...
  • 负缓存:如果某个 trigger item 在 I2I 表中查不到数据,会写入空字符串,避免每次都去查 FeatureStore
  • 缓存类型:本地内存 LRU 缓存(基于 cache.New),不依赖外部 Redis

与 BaseRecall 用户级缓存的对比

RealTimeU2IRecall 支持两层缓存,它们作用在不同层级:

维度 BaseRecall Cache(用户级) I2I Cache(物品级)
Cache Key CachePrefix + user_id trigger_item_id
缓存内容 该用户的最终召回结果 某个 item 的相似 item 列表
缓存位置 外部 Redis 或本地缓存 本地内存 LRU 缓存
适用层级 跳过整个召回流程 只跳过 I2I 表查询,trigger 仍实时获取
实时性影响 牺牲实时性(整体缓存) 保留实时性(trigger 实时,只有 I2I 关系缓存)
配置字段 CacheAdapter / CacheConfig / CachePrefix / CacheTime I2ICacheSize / I2ICacheTime

两层缓存配置示例

如果同时启用两层缓存:

{
   
  "RecallConfs": [
    {
   
      "Name": "realtime_u2i",
      "RecallType": "RealTimeU2IRecall",
      "RecallCount": 200,
      "CacheAdapter": "redis",
      "CacheConfig": "{\"redisName\": \"your_redis_name\"}",
      "CachePrefix": "rt_u2i_",
      "CacheTime": 60,
      "RealTimeUser2ItemDaoConf": {
   
        "UserTriggerDaoConf": {
    ... },
        "Item2ItemFeatureViewName": "item_i2i_table",
        "I2ICacheSize": 100000,
        "I2ICacheTime": 3600
      }
    }
  ]
}

执行顺序:

  1. 先查 用户级缓存(Redis),命中则直接返回
  2. 未命中 → 实时获取用户 trigger → 对每个 trigger 查 I2I 缓存(本地内存)
  3. I2I 缓存未命中的 → 查 FeatureStore → 写回 I2I 缓存
  4. 最终结果写回用户级缓存(Redis)

推荐配置

场景 I2ICacheSize I2ICacheTime 说明
I2I 数据每天更新 10000 ~ 50000 3600 ~ 7200 覆盖热门 trigger item
I2I 数据小时级更新 5000 ~ 20000 600 ~ 1800 平衡实时性和缓存效果
item 池较小 覆盖全量 item 1800 ~ 3600 几乎消除 I2I 查询
高 QPS + FeatureStore 压力大 尽量大 1800 有效保护下游

注意事项

  1. 内存占用:I2I 缓存是本地内存缓存,I2ICacheSize 设置过大会增加内存占用。每个缓存条目大约占用几百字节到几 KB(取决于相似 item 数量)
  2. 多实例不共享:本地缓存在每个引擎实例独立维护,不同实例的缓存不共享,冷启动时各实例需要独立预热
  3. 负缓存:I2I 表中查不到数据的 item 也会被缓存(空字符串),避免重复查询。如果 I2I 数据后续补充了,需等缓存过期后才能生效
  4. 与用户级缓存的关系:建议只启用 I2I 缓存,不启用用户级缓存,这样可以保留用户行为的实时性
相关文章
|
7月前
|
机器学习/深度学习 JSON 自然语言处理
PAI-Rec 特征工程全解析:统计特征、实时特征、序列特征与 FG 特征算子
PAI-Rec是阿里云智能推荐的特征工程解决方案,支持离线统计、实时及序列特征自动衍生,并通过Feature Generator(17种内置算子)保障离线/在线特征一致性,大幅降低开发与维护成本。
854 9
|
自然语言处理 算法
向量检索服务的优缺点
使用向量检索服务的好处是它可以将文本信息转化为向量表示,并进行相似度计算。这使得能够高效地搜索与查询进行语义匹配的文本
1656 3
|
机器学习/深度学习 分布式计算 DataWorks
EasyRec 使用介绍|学习笔记
快速学习 EasyRec 使用介绍。
2318 0
|
6月前
|
搜索推荐
PAI-Rec 多路召回截断实践:用 PriorityAdjustCountFilter 和 SnakeFilter 控制精排入口数量
PAI-Rec推荐开发平台提供PriorityAdjustCountFilter(按优先级截取)与SnakeFilter(按权重蛇形交错)两种多路召回截断策略,无需粗排即可将数百候选精准压缩至200个以内进入精排,兼顾保量性、多样性与业务可控性。
431 0
|
7月前
|
机器学习/深度学习 分布式计算 搜索推荐
PAI-Rec 召回引擎:构建高性能推荐系统的核心引擎
PAI-Rec是阿里云智能推荐平台的核心召回引擎,经阿里大规模场景验证。支持多路召回融合(U2I/I2I/向量/随机)、召回即过滤、毫秒级实时更新与分布式弹性架构,开箱即用,助力企业构建毫秒级、高精度、强实时的推荐系统。
669 9
|
人工智能 并行计算 算法
为什么 OpenSearch 向量检索能提速 13 倍?
本文介绍在最新的 OpenSearch 实践中,引入 GPU 并行计算能力 与 NN-Descent 索引构建算法,成功将亿级数据规模下的向量索引构建速度提升至原来的 13 倍。
1144 25
为什么 OpenSearch 向量检索能提速 13 倍?
|
5月前
|
机器学习/深度学习 人工智能 网络架构
深度解析:Transformer 的“灵魂”——QKV 变换的物理直觉
本文用图书馆检索等生活隐喻,从物理意义与认知科学角度解析Transformer中QKV设计的精妙本质:解耦查询(q)、键(k)、值(v)三重角色,实现语义分离、避免自注意力“自恋”,模拟人类动态信息路由的认知过程。(239字)
983 13
|
7月前
|
机器学习/深度学习 搜索推荐 数据处理
PAI-Rec推荐开发平台:企业级智能推荐解决方案,驱动业务全域增长
PAI-Rec是阿里云一站式推荐系统平台,集成多路召回、多目标精排(如DBMTL)、GPU加速推理与灵活迭代能力,已助力电商、直播、音视频等多行业提升点击率、转化率与ROI,实现高效、低成本、可自主演进的智能推荐。
633 16
|
7月前
|
存储 搜索推荐 PyTorch
为什么使用 TorchRec 训练和推理更快
本文结合TorchEasyRec实践,从四大维度解析推荐系统加速:1)KeyedJaggedTensor统一变长特征,实现Embedding批量融合查找;2)自动分布式分片突破单卡显存瓶颈;3)TrainPipelineSparseDist流水线并行,重叠通信与计算;4)fbgemm-gpu融合优化器,减少显存访问。端到端提升训练效率与扩展性。
644 9
|
9月前
|
数据库 C++
向量维度、距离函数,如何影响召回结果
本文揭示向量检索效果不佳的根源常被误判:问题不在embedding模型本身,而在于被忽视的底层选择——向量维度与距离函数。二者共同定义了“相似性”的本质,而非仅调节精度。维度决定语义表达自由度与错误类型,距离函数(L2/Cosine/Dot)则确立“何为相近”的世界观。二者强耦合,直接塑造召回空间。调参前,先问:你更怕漏召,还是误召?
向量维度、距离函数,如何影响召回结果