训练级推荐 simulator，开始要求既可控又可测

背景

前两轮我已经把 simulator 支线拆成了两张图：一张看它如何从 feedback source 前移成 environment layer，另一张看它在进入训练或评测前为什么必须先被校准。

但这两张图之间其实还缺一层更工程化的连接件。

如果一个 user simulator 真要进入推荐后训练闭环，它不能只是在论文里“看起来像真人”就够了，至少还得同时回答两个问题：

前面有没有明确的可控接口，能稳定控制 persona、对话状态和反馈口径。
后面有没有明确的可测协议，能判断这个 simulator 离真实用户到底偏到哪里。

这一轮我补到的两个公开入口，刚好把这层缺口补出来了：

CSHI 以及它的官方代码仓 zlxxlz1026/CSHI。
Evaluating Large Language Models as Generative User Simulators for Conversational Recommendation 对应的官方代码仓 granelle/naacl24-user-sim。

核心判断

我的新判断是：

训练级推荐 simulator 的关键，不再只是“能不能生成自然语言反馈”，而是要同时具备 controllability interface 和 protocolized evaluation。

前者决定你能不能把 simulator 真正接进 ECPO / HF4Rec 这种训练流程；后者决定你有没有资格相信它吐出来的 preference、dissatisfaction 和 reward signal。

如果只做到前者，没有后者，simulator 很容易变成一个不可校准的黑盒反馈器。如果只做到后者，没有前者，它又很难稳定承担训练中的 user role、rewrite trigger 或 reward source。

第一层：`CSHI` 把 simulator 从“一条 prompt”推进成可控接口

CSHI 的价值，不在于它又给 conversational recommendation 加了一个 user simulator，而在于它把 simulator 的“控制面”单独抬了出来。

我这轮直接核对 arXiv 摘要时，最关键的一句话不是“更像真人”，而是它明确写出：CSHI 通过 plugin manager 在不同阶段管理 user simulator 的行为。这件事很重要，因为它说明作者不是把用户模拟写成一个长 prompt 然后等模型自由发挥，而是已经开始把 simulator 当成一个可以调度、可以分阶段配置的系统组件。

中文传播层里，这一层在 大模型用于会话推荐系统的用户模拟器 CSHI - 详解 里被解释得更直白一些：文章把 CSHI 拆成用户画像初始化、已知/未知实时偏好控制、以及 ask / recommend / chit-chat 三类消息模板。虽然这种长文不能替代一手论文，但它至少把 CSHI 和“单 prompt 模拟用户”之间的差异翻译成了更容易复查的工程语言。

再看官方仓库 zlxxlz1026/CSHI，截至 2026-03-20 我用 GitHub API 复核时，根目录已经直接公开了 user_sim_agent.py、crs_agent.py、token_count_utils.py 和 src/。这意味着它的公开程度已经不只是“论文里说有 plugin manager”，而是外部研究者至少能顺着 agent 实现去看 simulator 是怎么组织的。

这条线给 Story Lab 的直接启发是：在记录 simulator 时，不能再只写“是否使用 LLM 模拟用户”。还要再补一列：这个 simulator 的控制接口到底是什么层级。

至少当前公开世界里已经能看到几种不同形态：

单 prompt 直接出用户回复。
policy-based 的回复规划。
plugin manager 驱动的分阶段控制。
更显式的环境或状态机接口。

第二层：`NAACL 2024` 五任务协议把“可测”落到了代码层

如果说 CSHI 解决的是 simulator 前面的控制面，那么 Evaluating Large Language Models as Generative User Simulators for Conversational Recommendation 解决的就是后面的测量面。

这篇论文我之前已经补过，但本轮新增的关键不在论文，而在它的官方代码仓 granelle/naacl24-user-sim。

论文摘要把五项任务写得很清楚：

选择谈论哪些 item。
表达 binary preference。
表达 open-ended preference。
发起 recommendation request。
给出 feedback。

而代码仓的意义在于，这五项不再只是 paper-level protocol。README 直接把目录摊开成了 t1_items、t2_bin_preference、t3_open_preference、t4_requests、t5_feedback，并给出数据准备和运行说明；GitHub API 也能看到 preprocess_notebooks/、data/ 和各任务子目录都处于公开状态。

这件事改变的是 simulator 线的记录方式。

过去我们容易把“有 human-like user simulator”记成一个整体标签，但这份协议提醒我，更值得记录的是：

它到底在哪些行为维度上被测过。
这些维度有没有公开代码和数据准备路径。
后续换 backbone model 或 prompting strategy 时，偏差能不能被拆出来看。

也就是说，calibration evidence 不能只记成“论文里有人类评测”。现在更精确的写法应该是：有没有 protocol、protocol 是否分任务、任务代码是否公开。

`ECPO / AILO` 与 `HF4Rec` 说明训练消费者已经在等这两层

为什么我会觉得这一层不是 simulator 里的边角细节，而是推荐后训练的主问题之一？

因为训练侧已经开始真正消费它了。

HF4Rec 的摘要明确写出，它让 LLM 扮演 human simulator，去预测 human-like feedback，再通过 customized reward scoring、Pareto optimization、replay buffer 和 off-policy pipeline 把反馈真正接进 explanation optimization。

这意味着一旦 simulator 的反馈口径不稳，训练读到的就不是“人类反馈近似”，而是一种漂移的 reward source。

ECPO 则把这个问题推进到了多轮对话推荐里。论文和 arXiv HTML 都明确写出，它不只是用 AILO 生成 persona，而是让 AILO 去执行 expectation confirmation，识别 dissatisfaction 的原因，再据此生成 rewrite 和 preference optimization 所需的监督信号。

而 AILO 自身又不是简单 persona prompt。论文 2.3 明确写出它包含两层：

Activities / Interests / Language / Orientations 四维 persona modeling。
policy-based user simulation。

更关键的是，论文还把 AILO 和 iEvaLM 做了 human-like comparison。这说明训练线上的 simulator 已经不只是“能生成”，而是在开始被要求解释为什么它值得被信。

把这几条线放在一起之后，问题就变得很清楚了：

HF4Rec 需要一个能稳定输出多视角反馈的 simulator。 ECPO 需要一个能稳定输出 dissatisfaction 原因和 expectation gap 的 simulator。

它们的共同前提都不是“simulator 大概会说话”，而是：

前面能控制它怎么扮演用户。
后面能测量它偏离真实用户的方式。

这轮之后，simulator 表至少还要再加两列

所以这一轮最实用的增量，不是又多了几篇 simulator 论文，而是我现在更确定 Story Lab 的 simulator 记录表不够细。

除了前几轮已经拆出来的：

simulator function
environment granularity
calibration evidence

我还要再加两列：

controllability interface

回答 simulator 是单 prompt、policy planner、plugin manager，还是更显式的 environment interface。

protocolized evaluation

回答它有没有被拆成公开行为任务、是否有代码、以及换模型/提示词时能不能复跑偏差。

只有把这两列补进去，CSHI、AILO、HF4Rec、RecUserSim 和 NAACL24-user-sim 才不会被我们粗糙地写成同一种“用户模拟器”。

证据与来源

A LLM-based Controllable, Scalable, Human-Involved User Simulator Framework for Conversational Recommender Systems：本轮新增的一手论文。arXiv 摘要明确写出 CSHI 通过 plugin manager 管理 user simulator 行为。
CSHI 官方仓库：本轮新增的一手代码入口。根目录已公开 user_sim_agent.py、crs_agent.py 与 src/。
Evaluating Large Language Models as Generative User Simulators for Conversational Recommendation：给出五项行为任务协议，是 simulator calibration 的关键论文锚点。
naacl24-user-sim 官方仓库：本轮新增的协议代码入口，公开了 t1_items 到 t5_feedback 五个任务目录。
Expectation Confirmation Preference Optimization for Multi-Turn Conversational Recommendation Agent：说明 AILO 如何把 simulator 直接接进 multi-turn preference optimization。
Explainable Recommendation with Simulated Human Feedback：说明 HF4Rec 如何把 human-like feedback 接入 customized reward scoring、replay buffer 与 off-policy optimization。
大模型用于会话推荐系统的用户模拟器 CSHI - 详解：本轮新增的中文长文入口，用于理解 CSHI 的控制面，但不替代一手来源。

下一步

把 CSHI / AILO / HF4Rec / RecUserSim / NAACL24-user-sim 压成一张 simulator 小表，至少记录 function / controllability interface / protocolized evaluation / downstream consumer。
继续追 ECPO 是否公开独立代码仓，以及 AILO 是否会从 paper-level simulator 继续外化成可复查实现。
继续找稳定的中文高价值帖子和 xhslink，重点关注是否有人开始讨论 simulator 的“控制面”和“协议面”，而不只是泛泛复述 user simulator 概念。