RecIF-Bench 已公开评测接口，但还不是无门槛 benchmark

背景

上一轮我已经确认，OpenOneRec 主仓不只是放了前训练资产，连 verl_rl 和 verl_distillation 这两条后训练链路也已经拆分公开了。看起来，OpenOneRec 离“完整公开复现”只差最后几步。

但还有一块边界必须单独拎出来核实：RecIF-Bench 到底开放到了什么程度。

因为官方在 OpenOneRec 根 README 和 Hugging Face 模型卡里都写了 RecIF-Bench dataset and evaluation scripts are open-sourced。如果只看这句话，很容易把它理解成“benchmark 已经完全开放，外部研究者随时都能从零跑通”。

这轮我把这个判断拆细后发现，更准确的说法不是“benchmark 还没开放”，也不是“benchmark 已经彻底无门槛”，而是：

RecIF-Bench 现在已经把任务结构、评测代码和模型入口公开出来了，但数据访问、环境配置和评测依赖仍然保留了明显门槛。

核心判断

截至 2026-03-20，OpenOneRec 在 benchmark 这一层实际上已经公开了三样东西：

  1. benchmark 的任务框架与评测脚本；
  2. benchmark 数据目录和文件命名；
  3. 可直接下载的 foundation 模型与公开成绩表。

但它仍然没有把“无门槛复现”这件事做完。

原因有三条。

第一，OpenOneRec-RecIF 在 Hugging Face API 里仍然显示为 gated: auto。这意味着外部研究者虽然能看见数据集页面、文件树和部分说明，但并不能默认直接拿到原始内容。

第二，官方公开的 benchmark README 明确要求用户自己准备本地 BENCHMARK_DATA_DIR，并把它指向 ../raw_data/onerec_data/benchmark_data 这类本地目录。也就是说，评测代码虽然公开，但它仍假设你已经拿到了 benchmark 数据。

第三，公开脚本本身还依赖不低的运行门槛：benchmarks/README.md 要求 torch、transformers、vllm、Ray 环境，并让用户配置 Gemini 的 project / location / credentials_path。这说明哪怕数据访问问题先放一边，评测流程本身也还不是“clone 之后一条命令直接跑完”的状态。

所以更准确的新结论应该是：

OpenOneRec 已经把 RecIF-Bench 的“接口层”公开了，但公开的主要是任务定义、评测代码和模型入口，而不是一个已经被彻底抹平摩擦的 benchmark 产品。

这条边界很重要，因为它直接决定 Story Lab 后面该怎样表述“公开 benchmark”：

  1. 不能再把 RecIF-Bench 说成“只有论文里提了一句，外部什么都看不到”。
  2. 也不能误写成“外部研究者已经可以零门槛复现官方 benchmark”。
  3. 更准确的说法应是：benchmark 的代码面和结构面已经公开，但数据访问、评测依赖和一键化体验还没有完全公开到底。

证据与来源

  • OpenOneRec 根 README 公开写出两件事：一是 2026-01-01 已经开放 RecIF-Bench dataset and evaluation scripts；二是 roadmap 里仍把 One-click reproduction、Docs & tutorials 和 Unified VeRL integration 列为未完成项。单看这两组信息，就已经能看出“已开放”和“易复现”不是一回事。
  • OpenOneRec/benchmarks 目录已经完整公开，里面能直接看到 README.md、eval_script.sh 和 benchmark/ 代码目录。这说明 benchmark 并不是纸面概念，而是真有可读、可跑的公开脚本栈。
  • benchmarks/README.md 把评测入口写得很细：需要安装 torch==2.5.1、transformers==4.52.0、vllm==0.7.3，可选地起 Ray 集群，还要配置 Gemini API；运行时还要求设置 BENCHMARK_DATA_DIR 指向本地 benchmark 数据目录。README 同时列出了 8 个任务：ad、product、interactive、video、label_cond、label_pred、item_understand、rec_reason。这说明 benchmark 的任务定义已经公开得很具体，但也说明运行门槛仍然显著。
  • benchmarks/eval_script.sh 进一步把这种“接口公开、门槛仍在”的状态钉得更清楚：8 个任务全部依赖本地 DATA_DIR，其中生成式任务还要带 --num_beams 32、--num_return_sequences 32 等设置，根本不是一个轻量的在线 demo 级入口。
  • Hugging Face 官方 API 在 OpenOneRec/OpenOneRec-RecIF 上返回 gated: auto，并显示该数据集创建于 2026-01-07、最近更新于 2026-01-28。更关键的是，API 已经暴露出文件树：benchmark_data/ad/ad_test.parquet、interactive/interactive_test.parquet、item_understand/item_understand_test.parquet、label_cond/label_cond_test.parquet、label_pred/label_pred_test.parquet、product/product_test.parquet、rec_reason/rec_reason_test.parquet、video/video_test.parquet，以及 sid2iid.json、sid2pid.json 和主数据文件 onerec_bench_release.parquet。这说明 benchmark 的结构确实已经对外可见，但数据读取仍受限制。
  • OneRec-1.7B 模型卡 则提供了另一层对照。它公开写出 RecIF-Bench 的四层能力结构和 8 个任务的成绩表，Hugging Face API 在 2026-03-20 也显示该模型 gated: false。也就是说，官方已经愿意把可运行模型和公开成绩表直接放出来，但 benchmark 数据层还没有完全抹平访问摩擦。
  • 还有一条旧问题在这轮 benchmark 核查里继续存在：OpenOneRec 的 README / 模型卡继续写 100M interactions / 200k users，而此前我核对的技术报告版本写的是 96M interactions / 160k users。这不改变本文核心判断，但说明 benchmark 对外叙事的数字口径仍未完全统一。

下一步

  1. 继续拆 benchmarks/api 和 benchmark/tasks/v1_0，确认 Gemini 在 item_understand、rec_reason 这类任务里扮演的是 judge、生成器还是混合角色。
  2. 继续追 OpenOneRec-RecIF 的访问边界是否变化，重点观察 gated 状态、README 可见性和 benchmark 数据是否新增公开子集。
  3. 后续把 RecIF-Bench 的“代码开放度”“数据开放度”“评测依赖门槛”拆成三张清单，避免再用一句“benchmark 已开源”把不同层次混成一件事。