模型上线前我通常会把一批“高风险样本”拿出来单独过一遍看看模型到底在看什么。早期大家比较熟悉的是热力图比如 Grad-CAM 之类能告诉 model 的注意力落在哪里。但如果只做这一步你会发现很多问题说不清楚模型确实看了病灶区域但这不代表它没有同时依赖图像角落里的医院水印、拍摄设备的 EXIF 痕迹或者某类背景纹理。热力图只能告诉你“模型看了哪里”不能告诉你“模型到底把哪些概念组合当成了证据”。而现实中深度模型的错误决策往往不是单个特征造成的而是多个概念同时出现、共同推动的结果。这时候“ICON Decomposition”这个方向就显得很有意思。只看标题它是在做“多变量概念级解释”不是解释单个神经元不是解释单个像素而是把深度表示分解成一组概念的组合并且是多元的、多维度的最终服务于模型审计。这和我们平时理解的可解释性不完全一样——它更像是在回答一个问题模型形成某个预测时究竟是哪个概念组合在起决定作用这个组合里有没有不该出现的概念。这篇文章我想围绕这个话题谈三个层面的内容为什么模型审计需要概念级、特别是多变量概念级的解释ICON Decomposition 这类方法试图解决什么以及如果把这类方法放进真实的审计流程我们应该怎么用、有什么坑。顺便说一句阅读这篇内容不需要你已经读过 ICON 的原始论文但如果你做过可解释性或模型安全相关的实践会更容易判断它在什么场景下有真实价值。1. 模型审计为什么需要“概念级解释”而不只是“特征归因”1.1 从像素归因到概念解释是一道跨不过去的坎传统可解释性里我们最常用的是特征归因类方法给出一张输入图片计算每个像素或每个特征对输出结果的贡献。这类方法的好处是直观哪里有响应哪里就是模型关注的位置。但它的上限也很明显。一个基于像素的归因结果本质上仍然是“低层信号”的展示。模型在倒数第二层形成的抽象表示往往已经和具体像素没有直接对应关系。比如对于一张猫的照片模型最终表示里可能有一个维度对应“耳朵尖”另一个维度对应“胡须”还有一个维度组合起来表示“猫科动物”。像素归因很难回答“模型是不是因为同时看到了胡须和耳朵才判断为猫”它只能告诉你输出对哪些像素敏感而这些像素可能分布在完全不同的语义区域。概念级解释就是为了解决这个问题。它不解释像素而是解释“概念”。所谓概念可以是“毛耳朵”“条纹”“墨水痕迹”“金属边框”这样的语义单位。概念可以用图片集来定义也可以用激活模式来定义。常见做法是准备一组概念样本比如 50 张“带条纹”的图片然后在模型的某一层表示上找到能够代表“条纹”的方向或子空间。这就相当于把模型的内部表示从“连续数值向量”翻译成“人可以理解的语义标签”。对于模型审计来说这个翻译非常关键。审计者需要知道模型有没有依赖某些不该依赖的概念比如身份、版权水印、背景场景。如果只给审计者一张热力图他很难凭直觉判断模型是不是因为“水印”这种语义信息做出的决策。所以概念级解释是模型审计里更接近“证据链”的一层表达它把模型的决策依据从数学空间映射到人类可以审查的语义空间。这一步做好了审计才能从“看响应位置”升级到“看决策依据”。1.2 单变量概念解释的局限性恰恰是 ICON Decomposition 的切入点很多已有方法比如 TCAVTesting with Concept Activation Vectors会针对单个概念给出一个方向然后计算模型的预测对这个方向的敏感度。换句话说这类方法回答的是“这个模型是不是用了‘条纹’这个概念”。这确实比像素归因进了一步但仍然存在一个容易被忽略的问题它默认概念之间是相互独立的可以单独评估。但深度模型在形成高层表示时通常不会让每个概念都落在正交方向上。概念之间的关系往往比我们想象的更复杂。有些概念只有在一个特定组合里才有预测意义单独出现时模型的表示并不会特别响应。比如一个医疗模型可能只有在“阴影”和“不规则边缘”同时出现时才会触发“恶性”的判断。如果单独测“阴影”敏感度可能不高单独测“不规则边缘”也不高。但两者一起出现时预测输出会迅速上升。这就是单变量解释的短板它看不到组合效应。你测出来每个概念都没有显著贡献但组合在一起却是决定性因素。真实的模型行为里这种组合效应非常常见不是少数场景。还有一类问题更麻烦模型可能依赖“表面相关”的概念组合而不是“因果相关”的概念组合。比如一个模型区分阿拉斯加雪橇犬和哈士奇如果训练数据里阿拉斯加雪橇犬的照片经常出现雪地背景哈士奇的照片经常出现室内背景那模型可能最终把“雪地”和“室内”当成了判断依据而不是狗的毛发和体型特征。这种情况如果是单个概念单独起作用你可能能看到“雪地”贡献很高从而发现异常。但如果模型依赖的是“雪地 绳索 拉雪橇”这样的组合单变量解释就很难发现问题。ICON Decomposition 这个标题里有一个关键限定词Multivariate。这意味着它的目标不是找到单个概念和模型输出的关系而是去解释多个概念之间的联合作用以及这些概念共同如何构成深度表示的一部分。这正好切中了单变量方法诊断能力不足的痛点。1.3 审计要回答的问题不是“模型喜欢什么”而是“模型为什么做这个选择”把可解释性用在审计场景和在研究场景里不同。研究场景里我们可能满足于“模型学到的概念分布是合理的”但审计场景必须回答更严格的问题某个预测结果的形成原因是什么这个原因里有没有不符合业务规则的概念。比如在信贷风控模型里我们审计一个“拒绝贷款”的决策。如果要解释这个决策不能只说“模型认为收入太低”。审计者更关心的是模型是不是同时把“低收入”和“职业类型”组合起来形成了判断而“职业类型”恰恰是业务规则里不允许使用的敏感变量。单变量解释可以告诉你“模型是否用了职业类型”但很难告诉你“模型在什么条件下会启用职业类型这个概念”。而现实往往是条件性的模型不会在所有样本里都用某个敏感概念它可能只在某些样本组合中用它比如当收入低于某个阈值时职业类型的影响被放大。这就是模型审计真正的难点。你需要检测的不是全局的“用了还是没用”而是局部的、组合性的“在什么情况下哪些概念的组合推动了输出”。如果只是查全局相关性很多有偏依赖关系会被平均掩盖掉。所以概念级解释的下一步必然是多变量、组合式的。ICON Decomposition 这类方法的核心贡献可能不在于“多变量”这个概念本身而在于它把“深度表示”分解成一组概念组合并且让这个分解结果可以直接用于审计判断。这种分解不是简单的线性拆分它需要能够捕捉概念之间的交互作用而不是假设概念彼此独立。2. ICON Decomposition 想解决的核心问题多变量概念之间的组合作用2.1 多变量概念不是多个概念的简单叠加我们平时说“模型用了多个特征”这并不等于多变量概念解释。比如线性模型里每个特征有一个权重这算是多变量归因但不是概念级的多变量解释。多变量概念解释要处理的对象是概念在深度表示中的联合结构。举个例子假设在图像模型中有三个概念A 表示“圆形物体”B 表示“红色”C 表示“交通信号灯”。如果在某张图片里圆形和红色同时出现模型预测“交通信号灯”的概率很高。实际上B 和 A 的组合决定了“交通信号灯”这个概念是否出现。但如果我们单独去掉“红色”或单独去掉“圆形”模型可能仍然能通过其他线索判断。这说明概念组合的行为不能通过单独评估每个概念来还原。在深度模型里概念之间的组合作用往往体现在表示空间的非线性子空间中。也许可以这样理解单个概念是一条线或一个方向而多个概念组合起来占据的可能是一个平面或一个区域。ICON Decomposition 要做的可能就是把这种高维表示分解成若干个“有语义意义的组合成分”每个成分可以对应一个或一组概念甚至可以对应概念之间的交互项。从工程经验看这类分解方法通常有两个关键设计选择。第一是概念集的定义方式是从外部提供一组概念图片集还是从表示空间里自动发现概念。第二是分解的变形形式是线性分解、非负分解、还是基于层次化的聚类分解。不同选择会极大影响分解结果的可解释性。但标题里没有给出具体实现细节所以不能假定它一定用了哪种方式。更稳妥的理解是ICON Decomposition 的目标是建立一个“从深度表示到多变量概念”的解码器它输出的不是单一概念激活值而是多个概念以及它们之间的组合权重。这些组合权重可以直接用来做审计判断哪些概念组合在某个样本或某类样本上被高权重激活并且这些激活和模型的预测一致。2.2 这种分解如何对应真实模型行为要理解这种分解的价值可以把它类比成“拆解一段文字的含义”。如果我们说“这篇文本让模型判为正面”那只是一个结果。如果我们说“这篇文本因为同时出现了‘续航不错’和‘价格实惠’这两个概念并且二者组合在一起才被模型判为正面”这就是更精细的解释。审计者看到这种解释就能判断模型是不是把“便宜”和“好评”错误绑定或者是不是把“续航不错”这个原本正面的概念在某个组合里变成了负面信号。但在深度表示层面概念并不是直接写在神经元的输出上的。同一个神经元可能参与多个概念的表示一个概念也可能分散在许多神经元上。所以分解方法必须能找到一种编码方式把这种分布式表示映射到人类概念空间。这个过程本身不完美但它能够让审计者检查模型的“理由”。ICON Decomposition 在模型审计里的角色可以理解为“把模型的内部理由抽取出来”。它不是直接修改模型也不是给模型输出一个可解释的替代模型而是对已经训练好的深度模型进行审计式的分解。用这种方式你可以定位以下现象模型对某个预测结果的解释中出现了业务禁止使用的概念组合。模型在不同子群体上依赖的概念组合不同且差异没有在全局指标中显露出风险。某个看似无伤大雅的后台概念如图片压缩痕迹与某个重要概念如病灶区域形成了高权重组合导致模型在特定情况下下错结论。这些现象如果是单纯看热力图几乎不可能发现。热力图最多告诉你模型看了哪些区域而 ICON 这类分解能告诉你模型“在语义上把哪些概念联系在了一起”。2.3 和“消除偏置”不同审计是发现风险而不是修复风险有时候我们会混为一谈既然模型依赖了不该依赖的概念组合那就去消除它呗。但审计的第一步不是消除而是发现。尤其是在模型已经上线、或者模型已经经过多轮迭代之后贸然修改模型可能会引入新的问题。ICON Decomposition 的价值首先在“审计”这个词上它帮助审计者建立一份“模型行为说明书”。这份说明书至少要包括模型在哪些常见类别上使用了哪些概念组合作为决策依据。这些概念组合中有没有与领域知识冲突的意外组合。在误差样本或敏感样本中模型依赖的概念组合是否发生了变化。不同概念组合之间的边界是否清晰模型会不会在模糊边界上产生不稳定预测。所以不要一上来就问“ICON 能不能帮我去除偏见”。它更像是一个诊断仪器。真正去除偏见是后续要去做的矫正工作而 ICON 的作用是把病灶照出来。3. 把 ICON 放进模型审计流程怎么用、需要做什么准备3.1 审计前需要准备什么无论是用 ICON Decomposition 还是其他概念级解释方法进入正式分析前我们都需要先完成几个基础铺垫。如果序列颠倒后面得到的解释结果往往不可信。先要有明确的审计目标。比如“检查模型在贷款审批上是否依赖了性别相关概念组合”或者“检查医学影像模型是否因为照片背景中的品牌水印而做出诊断”。目标不同需要定义的概念集不同分解结果的解释方式也不同。其次是要有概念集定义。ICON Decomposition 这类方法通常至少需要一个“目标概念集”。这个集合可以是你关注的敏感概念性别、年龄、背景物体、水印、后期处理痕迹也可以是模型行为相关的领域概念病灶、正常组织、阴影、边缘。如果概念集定义得不准后面再怎么分解也无法覆盖你真正关心的问题。然后是要有“分层抽样”的样本。你不能只拿全部测试集跑一遍分解。审计时通常会分层构造样本集比如按预测类别分层、按预测置信度分层、按敏感属性分层、按误差与否分层。这样你才能比较不同子群上概念组合的差异。最后是确定分解的层。深度模型有很多层不同层表示的抽象程度不同。概念级解释通常取倒数第二层或倒数第三层因为这些层已经融合了足够多的抽象语义同时还没到最终输出层那样高度压缩。但具体选哪一层还是要看模型结构。如果之前有人做过该模型的可解释性研究可以直接参考已有结果如果没有我一般会先比较中间层和最后一层隐藏层的分解语义稳定性选一个多次分解结果更一致的层。3.2 一个可参考的审计流程框架下面这个框架是我在实际项目中常用的“概念组合审计”路径。它不是 ICON Decomposition 的官方流程但适合把它承接进去让分解结果真正发挥作用。第一步预筛样本。从测试集或生产日志中抽取一个审计样本池建议包含正常样本、错误样本、边界样本。边界样本指预测概率接近阈值或接近 0.5 的样本。把这些样本分成 3 到 5 个子集。第二步定义概念集并生成概念激活方向。为每个概念准备一组正样本和负样本在选定的模型层上计算概念方向。这一步的目标是让“概念”成为可计算的对象。第三步运行分解。对审计样本池中每个样本的深度表示运行 ICON Decomposition得到每个样本上的概念组合权重。这里要留意分解结果可能是一组权重向量也可能是一组组合模式需要你根据具体实现格式来解析。第四步跨子群比较。把分解结果按样本子集聚合比较不同子群上概念组合的分布差异。重点关注错误样本比正确样本更依赖哪些概念组合边界样本比置信样本更依赖哪些组合敏感属性子群之间是否出现不同组合。第五步归因验证。对发现的高风险组合不能只看分解结果要回过去用因果干预验证。比如把图片中的“水印”区域去掉观察预测变化或者用生成模型把“背景”替换掉看模型是否改变判断。这一步很关键因为很多分解方法只能反映相关性不能确认因果性。第六步形成审计结论和持续监控项。如果发现某个高风险组合把它加入评估集在后续模型版本迭代里持续观察。这个流程里ICON Decomposition 的位置出现在第三步到第四步之间。它负责把深度表示翻译成“概念组合证据”后面的验证和决策仍然需要人来完成。3.3 审计报告里应该有什么一份概念分解审计报告不能只写“模型使用了概念 A、B、C”。那太粗糙。对技术人员和业务决策者来说报告至少要有四个部分。第一部分是“高风险概念组合清单”。列出高风险组合每个组合标明它出现的频率、涉及的数据子群、对预测的影响方向。比如“在假阳性样本中背景纹理 边框形状组合出现频率是正常样本的 3 倍且该组合与模型错误率相关性显著”。第二部分是“子群差异分析”。如果模型在不同性别、不同地区、不同设备来源上依赖的概念组合不一样需要明确呈现。这部分经常能发现全局指标看不出的公平性风险。第三部分是“归因验证结果”。不是所有概念组合都需要做因果验证对于风险最高的 5 到 10 个组合要输入扰动、替换、遮挡后的预测变化数据。这一步能防止“分解发现了组合但实际是伪相关”的误报。第四部分是“持续监控建议”。把关注概念组合固化为一组探针数据每次模型训练或更新后都跑一遍分解看权重是否偏移。这可以让审计工作从一次性的检查变成长期的过程。4. 适用边界与最容易误判的地方4.1 适合谁、不适合谁先说不适合的场景。如果你的模型是一个简单的线性模型或者浅层树模型那完全不需要概念级分解。传统特征重要性已经足够直接也比 ICON 更容易审计。即便你用 ICON 做了分解效果也不会比朴素方法有明显优势因为模型本身没有复杂的分布式表示。如果模型是一个已经高度压缩的端侧小模型最后一层表示中可能很难分离出丰富的概念组合因为模型的表达能力不够概念纠缠会很严重。此时分解结果可能不稳定需要更谨慎地解读。如果你的团队里没有人熟悉深度模型的表示空间也没有人能判断“概念方向”的好坏那么贸然引入 ICON 这类方法容易把一次审计变成一场“数字游戏”。概念级解释和热力图一样都需要观察者具备一定的模型能力判断力否则很容易误解结果。更适合的场景是模型基于大规模深度神经网络并且已经上线或准备上线。审计者有明确想检查的概念集比如敏感属性、环境噪声、特定背景物体。模型之前的单变量解释已经发现了部分问题但问题集中在多个概念联合发生作用时。团队有耐心做“分解 验证”的闭环而不是只想要一张漂亮的解释图。4.2 常见的三个坑第一个坑是把概念级分解的结果当成绝对事实。ICON 或者任何解释方法给出的都是对深度表示的一种“近似解读”。概念方向本身受概念集样本选择影响分解模式也受超参数影响。同一个模型用不同的概念集跑分解结果可能差异很大。所以分解决策时一定要先固定概念集定义和层选择再做跨样本比较不能随便调整。第二个坑是只看分解权重的大小完全忽略样本上下文。同一个概念组合。在不同样本的上下文中对预测的作用方向可能不同。比如“背景模糊”和“皮肤病灶”组合在一起在某个样本上可能是良性预测的证据但在另一个样本上可能指向恶性。审计必须结合样本类别和预测结果不能只看权重绝对值。第三个坑是跳过因果验证直接给模型下结论。分解方法能发现“模型表示里这些概念组合确实和某些预测模式共现”。但共现不等于因果。模型可能不是因为“背景纹理”做出判断而是因为“背景纹理”恰好和某个真正的疾病特征相关在表示里耦合在一起。如果不去做删改或扰动实验就可能误伤一个原本无害的概念组合。我一般会坚持“先分解后干预”的顺序先通过分解锁定少量候选组合再针对这些组合做干预实验。这样既不会浪费时间验证所有组合也不会因为解释不充分而漏过重要风险。4.3 长期工程化还需要补什么要把 ICON Decomposition 这类方法真正用于生产环境的模型审计单靠论文代码通常不够。还需要补三块工程能力。第一块是概念集管理。概念集不是一次定义就一劳永逸。随着业务变化需要持续维护正负样本库并评估概念方向是否仍然稳定。如果训练数据分布变了旧的概念方向可能失效需要重新校准。第二块是审计流程自动化。不能每次审计都手动跑脚本、手动汇总结果。要设计一套可配置的流水线输入模型版本和审计样本集输出标准格式的审计报告。ICON 分解模块可以作为一个中间服务输入表示向量输出组合权重。第三块是结果解释的可追溯性。当审计发现一个高风险概念组合后我们需要能溯源到具体样本、具体层表示、具体概念定义以便后续决策。如果分解结果不能完全复现审计结论就很难站住脚所以要固定随机种子、固定模型权重、固定特征提取层确保每次运行的结果可复现。这些东西看着琐碎但决定了这个方法能不能从“论文里很漂亮”变成“生产环境里可靠”。我见过不少团队在 Demo 里跑出了很漂亮的分解图但真正上线时因为没有做概念集管理三个月后模型迭代了一版旧分解结果完全对不上审计只能从头再来。5. 回到主判断ICON Decomposition 的价值不是“更精细的可视化”如果你回头再看 ICON Decomposition 这个标题会注意到它把两个词放在了一起Multivariate 和 Model Auditing。这不是偶然的。它的价值不在于把模型的内部表示画得更清楚而在于为审计提供了一条可操作的路径把深度模型的行为拆解成一组可理解的、具有组合结构的证据链。如果只关心“模型学到了什么”单变量概念解释也已经能给出大致轮廓。但如果要回答“模型在什么条件下因为什么概念的组合而做出判断”就必须进入多变量概念分解的层面。审计这件事的特点就是要找最极端、最有风险的那些行为而不是看整体平均表现。而极端行为往往出现在概念组合的异常交集中单看每个概念是看不出问题的。我希望你在使用这类方法时保持两件心态。第一把它当作一个风险探测器而不是真相生成器。它帮你缩小范围、锁定方向真正的结论要靠干预实验去坐实。第二先从小范围开始。不要第一轮审计就跑全部测试集也不要一下子丢进去几百个概念。先选 10 到 20 个最关注的概念在几百个样本上跑通流程确认分解结果稳定可解释然后再扩大规模。这样至少可以避免一开始就被大量未知的组合冲刷掉判断力。模型审计从来没有“一图流”的捷径但 ICON Decomposition 这类方法的出现让审计者终于可以对着模型的内部表示问一个问题你到底在把哪几个概念绑在一起作为依据这个问题比“你看哪里”要重要得多。