SAEVerbalizer 这个方向本质上是要解决 Sparse Autoencoder 特征解释里的一个老大难问题特征激活能算出来但这一维到底代表什么很难用自然语言说清楚。它的思路是借助 Representation Verbalization把特征在表示空间里的行为直接“翻译”成可读的解释文本。如果你正在研究稀疏自编码器、大模型内部机制、可解释性或者想把手头 SAE 特征做成可调用的解释结果这篇文章值得往下看。先说明一点我没有拿到官方仓库源码也没有原论文的完整表格所以这里不会伪造复现命令或具体评测数字。我会把这个方向拆成一个可以照着思考、设计和二次开发的框架重点讲清楚它要做什么、为什么需要它、实际落地时哪几个环节最容易翻车。1. 先搞清楚 SAE 特征为什么需要“被解释”1.1 稀疏自编码器到底做了什么Sparse Autoencoder 通常不是用来直接做分类或生成的它更像一个“拆解工具”。给定语言模型某一层的激活向量SAE 会用一组过完备的字典方向去重建它同时加上稀疏约束让每个输入只激活少数几个特征。这样做的好处是你能把原本混在一起的语义成分拆到不同维度上。比如某个特征可能对应“法律条文里的责任条款”另一个特征可能对应“代码注释里的 TODO”还有特征可能对应“对话中表达怀疑态度的语气”。这些划分不是预定义的而是从大量激活里自动学出来的。问题是这些特征没有天然标签。你拿到一个特征 ID只能看到它在不同输入上的激活值不知道它概括了什么。传统做法是用最大激活样本去“猜”挑出激活最高的几十条文本人工读一遍然后总结出一个描述。这种方式费时不说还容易以偏概全因为高激活样本可能只覆盖了特征某个侧面。1.2 解释不是写一句话那么简单SAE 特征解释的难点在于特征不是一个词也不是一个主题标签它是表示空间里的一个方向。这个方向在不同上下文里会表现出一定的一致性但也会出现大量例外。举一个常见现象某特征在“法院判决书”和“合同条款”中激活都很高你可能会把它解释成“正式法律文本”。但继续看它可能还会在“论文结论”和“产品说明书”里激活。这时就不能用一句“正式法律文本”覆盖全部行为。所以真正有用的解释要有边界最好还能带上反例范围。SAEVerbalizer 这类方法想做的就是把这种“特征到底在什么情况下激活、和哪些方向相关、用自然语言如何描述”的复杂判断交给一个生成流程来处理而不是让人逐条看样例。1.3 “Representation Verbalization” 在这里起什么作用Representation Verbalization 直译是“表示语言化”意思是把模型隐藏层里的连续表示变成一个可以用语言表达的东西。它不是简单地在 decoder 后面接一个分类头而是让语言模型直接参考某些表示向量生成一段自然语言说明。放到 SAEVerbalizer 里可以理解为模型不只告诉你特征激活高不高还要根据“哪些输入导致激活”和“不激活时输入的差异”来生成解释。输入是表示层面的证据输出是一段解释文本。这个流程能不能做好的关键在于语言模型有没有正确地把表示证据当作语义线索来使用。2. 如果要做这个方向环境准备和工作流程2.1 不是所有模型都适合直接上手先考虑模型规模。完整的 SAEVerbalizer 流程至少要三段一个作为研究对象的语言模型一个训练好的 Sparse Autoencoder一个负责生成解释的模型。如果你只有单卡低显存环境就要控制模型规模否则连激活提取都会卡住。常见的做法是先在中小模型上验证。例如选择 1B 到 7B 级别的开源模型取某一层激活做字典学习。SAE 本身不用太大但 hidden state 的维数和层数会影响结果建议先从前 6 到 12 层里挑一到两层试验。如果你的目标不是研究和复现而是理解这套解释方法也可以不自己训练 SAE而是直接使用社区已经发布好的 SAE 权重和特征解释公开数据。先跑通解释环节再回过来完整复现训练流程会省很多时间。2.2 核心环境项建议按这个清单检查系统Linux 优先Windows WSL 也能用但共享内存和文件路径容易出问题。Python 版本3.10 或 3.11 比较稳妥2025 年很多训练库对 3.12 的兼容性仍有差异。深度学习框架PyTorch 是主力注意 CUDA、cuDNN 和模型权重版本的匹配。研究目标模型建议用支持transformers接口的模型方便在forward里挂 hook。SAE 库OpenAI 的 sparse_autoencoder、一些基于字典学习的开源实现都可以参考。生成解释的模型可以是同一个模型也可以是对齐较好的通用大模型取决于任务设计。数据准备一批覆盖主题、风格、语气都足够广的文本作为激活提取的来源。这里给的是通用排查顺序实际参数要以你的环境为准不要照单全收。2.3 第一次测试建议拆四步第一跑通激活提取。输入一批文本拿到指定层的 hidden state并确认张量形状和数值范围没有问题。第二训练或加载 SAE。这一步只需要确认字典维度、稀疏系数、损失曲线是否收敛不需要马上看解释。第三挑少量特征做解释。先选激活频率适中、最大激活样本看起来有共性的特征不要选激活极少的死特征。第四做解释质量评估。要把生成的解释和前几名激活样本放在一起人工判断两者是否一致。这个顺序很重要。很多人一上来直接生成解释结果解释文本写得顺溜但特征本身根本没学好最后所有验证都是自欺欺人。3. SAEVerbalizer 的典型实现思路与关键参数3.1 一个可行的实现管线虽然我没有原始稿件但基于“Representation Verbalization”的思路可以搭一条相对完整、可验证的管线用一批文本作为基线语料让模型逐条前向记录目标层激活。用训练好的 SAE 对激活做编码得到稀疏特征激活向量。对每个目标特征从基线语料里挑出激活值最高的 N 条作为正样本激活值接近 0 的 M 条作为中性样本。把正样本、中性样本或对应的模型内部表示按一定方式组合后送给语言模型。询问语言模型给定这些例子用一个简短描述概括该特征在什么条件下激活。对生成的描述做验证把描述变成分类提示或再次激活源特征看是否能够预测真实激活。内部表示怎么送进语言模型是这类方法最值得实验的部分。有的做法把分解后的特征向量拼到文本 token 后面有的做法采用特征激活值作为 attention bias还有的做法是直接写成离散标签让模型归纳。不同方式对解释质量影响很大但没有绝对最优解建议用消融实验做决定。3.2 核心参数和它们的影响这里列几个实际涉及到的参数特征维度d_sae越大表示字典越细但训练难度和死特征比例也会上升。稀疏正则系数太大会让特征大多不激活解释结果很少太小则特征没有稀疏可控性。正样本数通常 20 到 50 条比较合理。太少概括不了太多会让解释文本没有重点。中性样本数通常要比正样本多一些用于让模型知道“特征在哪些常见情况下不激活”。生成解释的最大长度不要给太长建议 20 到 40 个词否则容易绕。验证阈值比如用解释文本重新预测特征激活设定准确率达到一定标准才算通过。建议不要一上来就用 100 条正样本去生成一句解释。先跑 10 条以内的样例人工看看特征分布是否清楚。3.3 解释质量怎么量化自然语言解释很难完全量化但至少可以从四个角度打分相关性解释是否是对特征激活区间的描述而不是无关文本。完整度特征在所有正样本中表现出的主要语义是否都被覆盖。区分度把解释给一个不知道特征的人他是否能据此从混合样本里挑出正样本。简洁性是否能在保持准确的前提下用更短的话说明问题。这些分数不能只看文本本身一定要回代到信号中验证。比如把“解释说的是正式法律文本”转成“包括法条、合同、诉讼文书等”这样的关键词列表再回到文本集合里检查能不能按类似语义召回原来的高激活样本。4. 最容易翻车的几个环节4.1 特征本身是坏特征再强的解释器也没用SAE 训练不稳定时会产生两类典型问题一类是死特征几乎从不激活解释时只能靠生成模型脑补另一类是重复特征同一语义被拆到很多维度解释结果看起来都差不多没有区分度。所以做特征解释的第一步不是解释而是先做好特征筛选。统计每个特征在语料上的激活频率、激活均值、激活分布的峰度以及它和最高激活样本之间的稳定性。如果一个特征在相似文本上激活值波动极大那就不要急着为它生成解释。4.2 正负样本偏置导致解释被带偏很多解释方法会陷入一种假象只要你给模型足够的正样本它总能写出一段合理文本。但这段文本可能是对“所有输入”的泛泛描述而不是对“特征激活区间”的精确描述。避免办法是做控制对比。同一批特征把正样本换成另一组随机高激活样本或者把中性样本换成完全不同的领域看生成的解释是否跟着变。如果解释没什么变化说明模型没有真正使用特征表示来生成文本只是在编通用描述。这个检查一定要做。4.3 语言模型生成的解释不可直接当标签语言模型生成解释时常常会使用“通常”“可能”“例如”这样的表达表面通顺实际有歧义。比如“通常出现在讨论天气的句子中”你无法判断它指的是气候议题、日常闲聊还是天气预报。更稳的做法是让生成的解释落到可操作结构上例如“该特征在谈及降雨概率和温度预测时激活常见于天气预报类文本”。这样你可以后面用关键词检索或语义分类去验证。5. 怎样设计一批可控的验证实验5.1 实验模型选择在真正探索大规模模型之前我建议先找一个你能完全掌控表示的小模型比如 1B 级别。为什么要小因为你需要在验证阶段频繁读取激活、切片、求和、做扰动这些操作在小模型上能快速迭代。小模型做通后再把同样的管线迁到更大模型上。5.2 人为置入特征来检验解释器除了用模型自然学到的特征还可以做“ground truth 已知”的合成验证。方法是主动给模型构造某些语义特征看解释器能不能识别出来。常见实现方式是找一些包含特定命名实体、句法结构或情绪倾向的句子再训练一个小型 SAE 或使用监督特征探测让特征与这些语义高度相关。之后运行 SAEVerbalizer看它生成的解释是否和人工标签一致。这个实验比只看自然语言通顺程度更可靠因为你知道特征真正代表什么。5.3 解释稳定性测试同一个特征换一批文本数据解释是否还成立在一段足够大的上下文中特征激活是否具有因果作用这些都要设计成稳定性测试。变化数据分布后重跑解释流程看解释是否发生漂移。从文本中去掉某些关键词后看特征激活是否明显下降。主动往文本中加入无关于该语义的片段看激活是否保持不变。稳定性测试越多越能确认这个解释不是巧合。6. 输出可以怎么用6.1 作为人工审计的前置筛选SAE 特征数量可能达到几千甚至几百万人工无法逐条解释。SAEVerbalizer 可以作为前置筛选器先生成一批候选解释再用规则或少量人工对解释质量排序只把不确定的部分交给人工复核。这样既能减少人工成本又能在高风险场景保留解释链路的可追溯性。6.2 作为神经元或特征层的文档化工具做模型的发布说明或审计报告时需要把激活层里比较重要的成分写清楚。把 SAEVerbalizer 输出整理成“特征 ID、激活规则、代表样本、反例样本”的表格会显著提高可读性。整个过程要有日志谁在什么语料上运行、使用哪些参数、生成解释的版本是什么都要记录下来。6.3 作为进一步干预的参考如果后续要做“特征激活抑制”或者“特征增强”解释文本可以帮助你选择合适的字段和介入点。例如解释描述为“与代码中 error handling 相关”你就可以在 prompt 或 logits 层面做更有方向性的控制。注意解释只是辅助不要直接拿文本描述当作反事实验证的结论。7. 常见问题排查顺序7.1 特征没有激活先看输入再调参数。输入是否经过了目标模型的正确 tokenizer。目标层是否选错。SAE 权重是否正确加载。正样本是否太少或语义太分散。特征是否已成为死特征。确认这些后再去怀疑解释生成模型。7.2 解释文本很像模板和特征无关这种情况通常不是生成模型的“幻觉”而是输入证据不足。要检查你给生成模型的提示中是否只包含文本而没有真正带上特征表示。另一个原因是中性样本没有起到对比作用。建议把正样本、中性样本都变得更有领域差异后重试。7.3 解释虽然通顺但无法用于预测试试换一个验证标准把解释文本转成“该特征激活时通常包含什么语义”的判断题用另一批召回集做打分。如果预测准确率上不去说明解释过度泛化。解决办法是减少样本数、加入负样本而不是继续堆描述词。7.4 资源占用过高不要在第一步就开大批量采样。先固定 1 到 2 个 batch中间钩子只保留目标层激活训练 SAE 时把序列长度限到 512 或 1024。如果只是想复现解释效果可以只对一个特征做前向和解释而不是全量特征都生成。8. 最后留几个自己排查时会优先看的点如果只是学习理解用现成工具和文档就能接触核心机制如果要长期做研究或产品化就要把日志、特征版本、解释版本、语料版本都管理好。SAEVerbalizer 这类工作的关键不是生成一句话而是让“表示可以回译成可验证的自然语言”并且解释本身能经受住跨样本、跨分布的检验。我个人更建议先把单特征的完整闭环跑通再扩展到批量特征。跑的过程中遇到输出异常不要先调生成模型先看 SAE 特征字典和正负样本是不是出了问题。很多看起来像“解释能力不行”的问题最终都出在信号定义不干净上。踩过几次之后会发现这个方向真正的难点不在解释器多强而在你能不能给解释器提供足够忠实、稳定的特征证据。证据稳了生成的自然语言才有意义。 SAEVerbalizer：让稀疏自编码器特征“开口说话”
SAEVerbalizer 这个方向本质上是要解决 Sparse Autoencoder 特征解释里的一个老大难问题特征激活能算出来但这一维到底代表什么很难用自然语言说清楚。它的思路是借助 Representation Verbalization把特征在表示空间里的行为直接“翻译”成可读的解释文本。如果你正在研究稀疏自编码器、大模型内部机制、可解释性或者想把手头 SAE 特征做成可调用的解释结果这篇文章值得往下看。先说明一点我没有拿到官方仓库源码也没有原论文的完整表格所以这里不会伪造复现命令或具体评测数字。我会把这个方向拆成一个可以照着思考、设计和二次开发的框架重点讲清楚它要做什么、为什么需要它、实际落地时哪几个环节最容易翻车。1. 先搞清楚 SAE 特征为什么需要“被解释”1.1 稀疏自编码器到底做了什么Sparse Autoencoder 通常不是用来直接做分类或生成的它更像一个“拆解工具”。给定语言模型某一层的激活向量SAE 会用一组过完备的字典方向去重建它同时加上稀疏约束让每个输入只激活少数几个特征。这样做的好处是你能把原本混在一起的语义成分拆到不同维度上。比如某个特征可能对应“法律条文里的责任条款”另一个特征可能对应“代码注释里的 TODO”还有特征可能对应“对话中表达怀疑态度的语气”。这些划分不是预定义的而是从大量激活里自动学出来的。问题是这些特征没有天然标签。你拿到一个特征 ID只能看到它在不同输入上的激活值不知道它概括了什么。传统做法是用最大激活样本去“猜”挑出激活最高的几十条文本人工读一遍然后总结出一个描述。这种方式费时不说还容易以偏概全因为高激活样本可能只覆盖了特征某个侧面。1.2 解释不是写一句话那么简单SAE 特征解释的难点在于特征不是一个词也不是一个主题标签它是表示空间里的一个方向。这个方向在不同上下文里会表现出一定的一致性但也会出现大量例外。举一个常见现象某特征在“法院判决书”和“合同条款”中激活都很高你可能会把它解释成“正式法律文本”。但继续看它可能还会在“论文结论”和“产品说明书”里激活。这时就不能用一句“正式法律文本”覆盖全部行为。所以真正有用的解释要有边界最好还能带上反例范围。SAEVerbalizer 这类方法想做的就是把这种“特征到底在什么情况下激活、和哪些方向相关、用自然语言如何描述”的复杂判断交给一个生成流程来处理而不是让人逐条看样例。1.3 “Representation Verbalization” 在这里起什么作用Representation Verbalization 直译是“表示语言化”意思是把模型隐藏层里的连续表示变成一个可以用语言表达的东西。它不是简单地在 decoder 后面接一个分类头而是让语言模型直接参考某些表示向量生成一段自然语言说明。放到 SAEVerbalizer 里可以理解为模型不只告诉你特征激活高不高还要根据“哪些输入导致激活”和“不激活时输入的差异”来生成解释。输入是表示层面的证据输出是一段解释文本。这个流程能不能做好的关键在于语言模型有没有正确地把表示证据当作语义线索来使用。2. 如果要做这个方向环境准备和工作流程2.1 不是所有模型都适合直接上手先考虑模型规模。完整的 SAEVerbalizer 流程至少要三段一个作为研究对象的语言模型一个训练好的 Sparse Autoencoder一个负责生成解释的模型。如果你只有单卡低显存环境就要控制模型规模否则连激活提取都会卡住。常见的做法是先在中小模型上验证。例如选择 1B 到 7B 级别的开源模型取某一层激活做字典学习。SAE 本身不用太大但 hidden state 的维数和层数会影响结果建议先从前 6 到 12 层里挑一到两层试验。如果你的目标不是研究和复现而是理解这套解释方法也可以不自己训练 SAE而是直接使用社区已经发布好的 SAE 权重和特征解释公开数据。先跑通解释环节再回过来完整复现训练流程会省很多时间。2.2 核心环境项建议按这个清单检查系统Linux 优先Windows WSL 也能用但共享内存和文件路径容易出问题。Python 版本3.10 或 3.11 比较稳妥2025 年很多训练库对 3.12 的兼容性仍有差异。深度学习框架PyTorch 是主力注意 CUDA、cuDNN 和模型权重版本的匹配。研究目标模型建议用支持transformers接口的模型方便在forward里挂 hook。SAE 库OpenAI 的 sparse_autoencoder、一些基于字典学习的开源实现都可以参考。生成解释的模型可以是同一个模型也可以是对齐较好的通用大模型取决于任务设计。数据准备一批覆盖主题、风格、语气都足够广的文本作为激活提取的来源。这里给的是通用排查顺序实际参数要以你的环境为准不要照单全收。2.3 第一次测试建议拆四步第一跑通激活提取。输入一批文本拿到指定层的 hidden state并确认张量形状和数值范围没有问题。第二训练或加载 SAE。这一步只需要确认字典维度、稀疏系数、损失曲线是否收敛不需要马上看解释。第三挑少量特征做解释。先选激活频率适中、最大激活样本看起来有共性的特征不要选激活极少的死特征。第四做解释质量评估。要把生成的解释和前几名激活样本放在一起人工判断两者是否一致。这个顺序很重要。很多人一上来直接生成解释结果解释文本写得顺溜但特征本身根本没学好最后所有验证都是自欺欺人。3. SAEVerbalizer 的典型实现思路与关键参数3.1 一个可行的实现管线虽然我没有原始稿件但基于“Representation Verbalization”的思路可以搭一条相对完整、可验证的管线用一批文本作为基线语料让模型逐条前向记录目标层激活。用训练好的 SAE 对激活做编码得到稀疏特征激活向量。对每个目标特征从基线语料里挑出激活值最高的 N 条作为正样本激活值接近 0 的 M 条作为中性样本。把正样本、中性样本或对应的模型内部表示按一定方式组合后送给语言模型。询问语言模型给定这些例子用一个简短描述概括该特征在什么条件下激活。对生成的描述做验证把描述变成分类提示或再次激活源特征看是否能够预测真实激活。内部表示怎么送进语言模型是这类方法最值得实验的部分。有的做法把分解后的特征向量拼到文本 token 后面有的做法采用特征激活值作为 attention bias还有的做法是直接写成离散标签让模型归纳。不同方式对解释质量影响很大但没有绝对最优解建议用消融实验做决定。3.2 核心参数和它们的影响这里列几个实际涉及到的参数特征维度d_sae越大表示字典越细但训练难度和死特征比例也会上升。稀疏正则系数太大会让特征大多不激活解释结果很少太小则特征没有稀疏可控性。正样本数通常 20 到 50 条比较合理。太少概括不了太多会让解释文本没有重点。中性样本数通常要比正样本多一些用于让模型知道“特征在哪些常见情况下不激活”。生成解释的最大长度不要给太长建议 20 到 40 个词否则容易绕。验证阈值比如用解释文本重新预测特征激活设定准确率达到一定标准才算通过。建议不要一上来就用 100 条正样本去生成一句解释。先跑 10 条以内的样例人工看看特征分布是否清楚。3.3 解释质量怎么量化自然语言解释很难完全量化但至少可以从四个角度打分相关性解释是否是对特征激活区间的描述而不是无关文本。完整度特征在所有正样本中表现出的主要语义是否都被覆盖。区分度把解释给一个不知道特征的人他是否能据此从混合样本里挑出正样本。简洁性是否能在保持准确的前提下用更短的话说明问题。这些分数不能只看文本本身一定要回代到信号中验证。比如把“解释说的是正式法律文本”转成“包括法条、合同、诉讼文书等”这样的关键词列表再回到文本集合里检查能不能按类似语义召回原来的高激活样本。4. 最容易翻车的几个环节4.1 特征本身是坏特征再强的解释器也没用SAE 训练不稳定时会产生两类典型问题一类是死特征几乎从不激活解释时只能靠生成模型脑补另一类是重复特征同一语义被拆到很多维度解释结果看起来都差不多没有区分度。所以做特征解释的第一步不是解释而是先做好特征筛选。统计每个特征在语料上的激活频率、激活均值、激活分布的峰度以及它和最高激活样本之间的稳定性。如果一个特征在相似文本上激活值波动极大那就不要急着为它生成解释。4.2 正负样本偏置导致解释被带偏很多解释方法会陷入一种假象只要你给模型足够的正样本它总能写出一段合理文本。但这段文本可能是对“所有输入”的泛泛描述而不是对“特征激活区间”的精确描述。避免办法是做控制对比。同一批特征把正样本换成另一组随机高激活样本或者把中性样本换成完全不同的领域看生成的解释是否跟着变。如果解释没什么变化说明模型没有真正使用特征表示来生成文本只是在编通用描述。这个检查一定要做。4.3 语言模型生成的解释不可直接当标签语言模型生成解释时常常会使用“通常”“可能”“例如”这样的表达表面通顺实际有歧义。比如“通常出现在讨论天气的句子中”你无法判断它指的是气候议题、日常闲聊还是天气预报。更稳的做法是让生成的解释落到可操作结构上例如“该特征在谈及降雨概率和温度预测时激活常见于天气预报类文本”。这样你可以后面用关键词检索或语义分类去验证。5. 怎样设计一批可控的验证实验5.1 实验模型选择在真正探索大规模模型之前我建议先找一个你能完全掌控表示的小模型比如 1B 级别。为什么要小因为你需要在验证阶段频繁读取激活、切片、求和、做扰动这些操作在小模型上能快速迭代。小模型做通后再把同样的管线迁到更大模型上。5.2 人为置入特征来检验解释器除了用模型自然学到的特征还可以做“ground truth 已知”的合成验证。方法是主动给模型构造某些语义特征看解释器能不能识别出来。常见实现方式是找一些包含特定命名实体、句法结构或情绪倾向的句子再训练一个小型 SAE 或使用监督特征探测让特征与这些语义高度相关。之后运行 SAEVerbalizer看它生成的解释是否和人工标签一致。这个实验比只看自然语言通顺程度更可靠因为你知道特征真正代表什么。5.3 解释稳定性测试同一个特征换一批文本数据解释是否还成立在一段足够大的上下文中特征激活是否具有因果作用这些都要设计成稳定性测试。变化数据分布后重跑解释流程看解释是否发生漂移。从文本中去掉某些关键词后看特征激活是否明显下降。主动往文本中加入无关于该语义的片段看激活是否保持不变。稳定性测试越多越能确认这个解释不是巧合。6. 输出可以怎么用6.1 作为人工审计的前置筛选SAE 特征数量可能达到几千甚至几百万人工无法逐条解释。SAEVerbalizer 可以作为前置筛选器先生成一批候选解释再用规则或少量人工对解释质量排序只把不确定的部分交给人工复核。这样既能减少人工成本又能在高风险场景保留解释链路的可追溯性。6.2 作为神经元或特征层的文档化工具做模型的发布说明或审计报告时需要把激活层里比较重要的成分写清楚。把 SAEVerbalizer 输出整理成“特征 ID、激活规则、代表样本、反例样本”的表格会显著提高可读性。整个过程要有日志谁在什么语料上运行、使用哪些参数、生成解释的版本是什么都要记录下来。6.3 作为进一步干预的参考如果后续要做“特征激活抑制”或者“特征增强”解释文本可以帮助你选择合适的字段和介入点。例如解释描述为“与代码中 error handling 相关”你就可以在 prompt 或 logits 层面做更有方向性的控制。注意解释只是辅助不要直接拿文本描述当作反事实验证的结论。7. 常见问题排查顺序7.1 特征没有激活先看输入再调参数。输入是否经过了目标模型的正确 tokenizer。目标层是否选错。SAE 权重是否正确加载。正样本是否太少或语义太分散。特征是否已成为死特征。确认这些后再去怀疑解释生成模型。7.2 解释文本很像模板和特征无关这种情况通常不是生成模型的“幻觉”而是输入证据不足。要检查你给生成模型的提示中是否只包含文本而没有真正带上特征表示。另一个原因是中性样本没有起到对比作用。建议把正样本、中性样本都变得更有领域差异后重试。7.3 解释虽然通顺但无法用于预测试试换一个验证标准把解释文本转成“该特征激活时通常包含什么语义”的判断题用另一批召回集做打分。如果预测准确率上不去说明解释过度泛化。解决办法是减少样本数、加入负样本而不是继续堆描述词。7.4 资源占用过高不要在第一步就开大批量采样。先固定 1 到 2 个 batch中间钩子只保留目标层激活训练 SAE 时把序列长度限到 512 或 1024。如果只是想复现解释效果可以只对一个特征做前向和解释而不是全量特征都生成。8. 最后留几个自己排查时会优先看的点如果只是学习理解用现成工具和文档就能接触核心机制如果要长期做研究或产品化就要把日志、特征版本、解释版本、语料版本都管理好。SAEVerbalizer 这类工作的关键不是生成一句话而是让“表示可以回译成可验证的自然语言”并且解释本身能经受住跨样本、跨分布的检验。我个人更建议先把单特征的完整闭环跑通再扩展到批量特征。跑的过程中遇到输出异常不要先调生成模型先看 SAE 特征字典和正负样本是不是出了问题。很多看起来像“解释能力不行”的问题最终都出在信号定义不干净上。踩过几次之后会发现这个方向真正的难点不在解释器多强而在你能不能给解释器提供足够忠实、稳定的特征证据。证据稳了生成的自然语言才有意义。