WorkspaceBench:如何评估大模型全局工作空间的可解释性方法

WorkspaceBench 用 27 族 3356 题评估激活读取工具能否读对模型工作空间中的中间变量。
WorkspaceBench 是一套评估「激活到文本」工具能否正确读取模型全局工作空间中间变量的基准,包含 27 个评估族、3356 道题,覆盖基础读出、计算、安全、联想与反词袋等主题,并配备幻觉专项评估与相对 J-lens 的精度/召回指标。研究把工具分为单 token 读取器(Logit lens、J-lens、R-lens、Tuned lens)与多 token 读取器(NLAs、SAE、Patchscopes、Template lens、Oracle Lens)。核心结论有两点:单 token 读取器本质是词袋,无法编码顺序,在合取联想、buggy code 等复合任务上受限,说明多 token 读取器必要;NLAs 表达力强却能浮现大量内容的同时极易幻觉,几乎每条读取都含与模型输出矛盾的声明。基准为 Qwen-3.6-27B 定制并已开源,迁移到更弱模型需重新生成题目并重推读取位置。
为什么需要 WorkspaceBench?
模型的中间表征(工作空间)里往往藏着答案、意图和计划,但我们一直缺乏衡量「激活到文本」工具是否读对了这些变量的标准。据 LessWrong 与 Alignment Forum 同步发布的研究,作者提出 WorkspaceBench——一套专门评估「全局工作空间」读取能力的基准,用来判断一个工具能否真正把前向传播中的中间变量还原成可读文本。
评估的意义在于:Astra 之类的模型在无思维链时仍能完成大量任务,这让思维链监控变得不可靠,也让可解释性成为理解模型行为的关键路径。WorkspaceBench 试图给出一个可以横向比较不同工具的标尺。

WorkspaceBench 的规模与设计目标
基准包含 27 个评估族、共 3356 道题目,覆盖安全、逻辑推理和多跳计算等主题,其中一部分专门为「单 token 输出」工具保留了子集。
作者列出衡量工作空间读取器(workspace reader)是否理想的几项期望:能覆盖 J-lens 捕获到的全部内容且不幻觉、能表达 J-lens 只能「指代」却无法单 token 说清的多 token 概念、能捕获与计算相关的其他中间量、对安全审计有实际帮助,以及输出可信、不过度编造。
正因如此,基准同时提供幻觉专项评估,并把「精度/召回相对 J-lens」作为辅助指标:低精度不一定等于幻觉,也可能是 J-lens 表达不出的多 token 内容。
被评估的两类激活读取方法
据研究,工具被分为单 token 读取器和多 token 读取器。单 token 侧包含 Logit lens、J-lens、R-lens、Tuned lens;多 token 侧包含 Natural Language Autoencoders(NLAs)、Sparse Autoencoders、Patchscopes、Template lens、Oracle Lens。对 NLAs 和 Oracle Lens,还评估了 RL 之前的微调变体。
读取方式上,J/R/Logit-lens 在 64 层的 Qwen-3.6-27B 的第 20 至 60 层、每 4 层取一次 top-10 token;Template Lens 取同一批层级的 top-10 词/短语;Oracle Lens 取 1 个样本 4 条要点(约 90 token),NLAs 在第 42 层取 1 个样本(约 250 token)。
Logit lens 是最早、最简单的激活读取方法:它把某一中间层的残差流表示直接乘以模型最后的 unembedding 矩阵,投影回词表空间,从而读出该层「此刻最想说的下一个词」。它的优点是无需训练、几乎零成本,缺点是随层数加深语义逐渐漂移,中间层的 top token 往往只是碎片化的词而非完整概念。
Tuned lens 是对 Logit lens 的改进:为每一层单独训练一个仿射变换(翻译器),把该层表示映射到一个「靠近最终层」的共享空间再解码,从而缓解中间层分布与输出层不匹配的问题。相比 Logit lens,它在各层的读出都更稳定、更接近真实续写。
J-lens 是对 Jacobian(雅可比矩阵)的缩写——它利用输出对某一层激活的雅可比矩阵来构造读出方向,捕捉「改变这一层激活会如何影响输出分布」。R-lens 可理解为一种基于类似线性探测思路的读出变体。三者共同点是最终都压缩到单个 token 上表达,因此天然无法表示需要多个词才能说清的概念,这也是后文「词袋」批评的根源。
Sparse Autoencoders(SAE) 通过在激活上训练一个过完备且稀疏的字典:编码器把高维残差流映射到大量稀疏激活的特征上,解码器再重建原激活。每个特征通常被解释为某个可命名的概念(如「法律术语」「代码缩进」),因而能输出多 token 的自然语言描述。
Patchscopes 的做法是把某一层的激活「补丁」注入到另一个提示(通常由一个能力较强的模型或同一模型的其他前向传播)中,让模型自己把这段激活翻译成文本,本质是借模型的生成能力做解码器。
Natural Language Autoencoders(NLAs) 用编码器把激活压缩成一个隐向量,再由解码器(通常是语言模型)生成一段自然语言描述,训练目标包含重建激活。它的表达力最强、读取长度最长,但由于训练信号并不强制描述与事实一致,容易生成看似合理却与模型实际输出矛盾的内容。Oracle Lens 则通过自回归重建加 RL 优化,追求更忠实、更简洁的读出。
三大难题:为什么此前没人做过这类基准
第一个难题是没有真值——没人确切知道模型工作空间里到底有什么。作者的应对是:设计任务时设法确信模型必须使用某个中间量才能得到答案,并按模型能力调整题目难度。对于联想、定向调制等无法绝对确认的评估,他们不要求一定可以饱和,但更高分仍代表工具能力更强。
第二个难题是模型本身未必有足够强的中间表征。研究指出近期开源模型的工作空间表征越来越强,因此选用 Qwen-3.6-27B 进行测试。
第三个难题是不同方法的取舍难以权衡:J-lens 单 token 但可靠,NLAs 表达力强却容易虚构。基准通过「准确率 vs 幻觉率」来刻画这种权衡。
题目质量控制与评分方式
为了保证中间量确实合理,题目需通过几项检查:模型在 n=10、temperature=0.8、无思维链下正确率高于 80%;中间量绝不出现在提示词中(无论数字还是词);模型自身的续写中也不陈述该中间量;对诗歌这类多解题目,通过重复采样确认只有一条有效路径。
评分方面,多数评估使用 Gemini-3.8-Flash 作为裁判,安全相关评估使用 Sonnet-5;仅「基线评估」(改编自 J-lens 论文)沿用原论文的正则匹配方法。作者强烈建议对原创评估使用同等或更强能力的裁判,因为更简单或更弱的裁判会放进大量误判。
Baseline 包括「Lucky guess」(不给问题直接选项)和「Prompt-only」(只给前缀让模型推断此刻在想什么)。作者特别说明:由于许多任务本身就是从提示词逻辑推断出工作空间内容的,因此 prompt-only 表现好并不意味着工具差。
LLM-as-a-judge 指用一个能力足够强的语言模型代替人工,对被测工具的输出与参考答案进行语义比对打分。相比正则匹配,它能容忍同义改写、语序差异,但代价是引入了裁判自身的偏差与不稳定。研究用 Gemini-3.8-Flash 做通用裁判、Sonnet-5 做安全裁判,即因为安全场景对措辞与语义细节更敏感。
需要强调的是,裁判能力与被测任务难度必须匹配:若用弱模型当裁判,它会把「明显错误但表面通顺」的读取误判为正确,从而系统性高估工具性能。这也是作者建议对原创评估使用同等或更强裁判的原因。temperature=0.8、n=10 则指采样温度与采样次数,用于在无思维链条件下估计模型对某题是否真的「会做」,避免把偶然碰对的题当成有效题。
评估族一览:从基础读到安全
基础类 覆盖 Basic readout(在模型回答前一个 token 是否浮现真实续写)、Multihop(是否浮现静默推断的中间概念)、Multilingual、Poetry(换行处是否浮现计划中的韵脚)、Typo、Directed Modulation(模型一边抄写句子一边想某概念,是否在书写位置浮现该概念),以及多语言版本的 typo 与 multihop。
计算类 要求模型无思维链地算出中间值且从不写出来,包括 Chained intermediates(两步或三步算术链,起始数最后给出)、Brew intermediates(十规则颜色重写表应用两次)、Buggy code(含单个已核实 bug 的程序与其无 bug 孪生版本对比)、Arithmetic intermediates(十四种形态的裸算式)。
安全类 面向生产审计场景,包括 Agentic misalignment(Qwen 实际做出错位行为时,能否在它写出来之前就显示计划,如黑mail、数据泄露、自我外泄)与 Jailbreak recognition(是否识别出最后一轮是越狱或人格覆写)。
联想类 考察子文本识别:Basic association、Conjunctive association(复合情绪状态,如对挚友升职的嫉妒而非骄傲)、User modeling(从聊天推断用户的国家、性别、职业)、Role-bound association(如分辨「小偷追警察」还是反过来)。
反词袋类 以 Relational multihop 为代表,要求同时保持两种关系的正确顺序,顺序颠倒即失败。此外还有 Hallucination eval 和 J-lens 概念精度/召回,后者在「Chinese, English, French」逗号处比对读取内容与 J-lens top-10 的覆盖情况。
结果与讨论
作者给出两点主要结论。其一,单 token 读取器无法覆盖重要的工作空间内容:它们是词袋,即便 LLM 摘要器能把 top-k token 排成看似合理的顺序,在缺乏常识排序时(如多位数、意图方向性的概念)也无法编码顺序,在合取联想、buggy code 等复合任务上表现不佳,说明多 token 读取器的必要性。
其二,NLAs 能浮现大量工作空间内容,但极易幻觉。研究称几乎所有 NLA 读取都包含与模型输出上下文直接矛盾的声明;其平均读取长度约为 Oracle Lens 的两倍。作者认为理想的工作空间读取器应当可信,尤其当声明无法由模型输出直接验证时;若可验证声明大量为假,则不可验证声明也应被低置信对待。
训练细节上,Oracle Lens 通过自回归重建激活、Inverter 微调与 RL 优化(奖励为重建解释的方差占比,且 AR 冻结)实现。作者还提到受 CHIVE 启发,正在初步探索为智能体配备激活读取器工具后在真实评估中的表现。
幻觉在此处的定义是:读取器生成的声明与「模型输出上下文」(即该题实际提示与模型真实续写)直接矛盾。它与「低精度」不同:低精度可能只是读取器没能命中 J-lens 的 top token,而这可能是 J-lens 本身无法用单 token 表达多 token 概念所致;幻觉则是编造了可被外部证据证伪的内容。
正因如此,评估把「准确率 vs 幻觉率」作为核心二维指标:一个理想读取器应同时具备高召回(不漏掉真实存在的中间变量)与低幻觉(不虚构不存在的内容)。作者特别指出,NLA 的读取长度约为 Oracle Lens 的两倍,长文本给了它更多「编造空间」;当可验证的声明大量为假时,对不可验证声明也应降低置信度——这是安全审计场景中尤其重要的原则。
使用建议
WorkspaceBench 是为 Qwen-3.6-27B 开发的,作者期望其适用于更大模型,但面对更小或更弱的模型可能需要调整。适配建议是:让能力足够的 LLM 生成定制变体题目、运行同样的有效性检查、并重新推导读取位置,因为读取位置不会跨模型与分词器迁移。基准已在 GitHub 开源。
相关推荐

Gemini 4 Argon API实战:思考等级、后台模式一次讲透
Free Code Camp 出品的 Gemini 4 Argon API 速成教程:从申请密钥、发送首次请求,到用思考等级控制推理成本、用 previous_interaction_id 实现多轮对话,再到后台模式一句话生成打砖块游戏,附 Google 工程师对模型能力的解读。

强化学习通关《抡大锤》:63%进度背后的分布式训练策略
开发者用深度强化学习挑战《抡大锤》,智能体从底部攀爬至63%进度,卡在铁砧部分。项目开源,采用分治训练和CPU训练策略,寻求社区协作突破瓶颈。

AAAI 2027二审放榜在即:社区热议评审公平与投稿生态
AAAI 2027第二阶段评审结果即将公布,Reddit社区热议评审一致性与流程透明度。本文梳理放榜前的社区情绪、顶会评审的结构性矛盾,以及作者应对二审结果的务实策略。