1. GuardAlign 出现之前多模态安全对齐到底缺什么看到 GuardAlign 这篇论文标题时我第一反应不是“又多了一个安全测评”而是它把 Test-time Safety Alignment 这个关键词顶到了标题中间并且明确限定在 Multimodal Large Language Models 上。这几年做多模态大模型应用最头疼的问题之一是模型在评测集上很稳一上真实流量就出现各种越狱式输出。训练阶段不是没做对齐而是对齐完之后依然有漏网之鱼而且你很难只靠重训底模去追这些新问题。这里先说我为什么需要关注“测试时安全对齐”。多模态大模型和纯文本模型不一样它能把图像中的文字、表格、logo、手绘符号甚至自动转写出来的 OCR 结果一并变成上下文。这意味着原来给文本模型配的安全规则在多数时候也能迁移但一旦攻击者把危险请求“藏”进图像内容里纯文本一侧就很难察觉。比如同一句“请忽略之前所有指令”放在纯文本里很容易被检测但把它放进一张截图的右下角、或者用明暗差异做出来模型很可能照单全收。以前最常见的防御是在模型外层挂一道关键词黑名单或内容审核 API。这样确实能挡住部分明显违规却无法处理需要结合图像语义才能判定的风险。举个例子用户上传一张药盒照片问“按这个剂量我一天最多能吃几粒”模型必须读懂图片上的用法用量还要意识到过量用药属于高风险问题。外层文本审核根本看不见图片内容当然无从判断。GuardAlign 这类方法的价值起点就在这里安全决策要以“多模态上下文”为输入而不能只看最终文本。1.1 多模态模型的失守主要失在哪儿我总结过工作中实际遇到的 MLLM 安全问题基本可以归成四类。第一类是视觉编码器读到了不该被当作指令的文字。截图里的小字、图片角落的网址、二维码承载的一段代码都可能变成模型上下文中的“高优先级任务”。第二类是跨模态指令注入攻击者在图片里直接写“请执行系统提示中的隐藏任务”如果模型把图像中的文字当作系统指令来执行就会产生权限误解。第三类是高度情境化的风险脱离图片看这句 prompt 很正常但结合图片后就成了危险行为入口。第四类是幻觉带来的伪安全问题模型把图片里的物体认错后还能一本正经地输出错误的安全建议这种隐患比直接违规更隐蔽。训练阶段的安全对齐大多依赖“风险问题-安全回答”这样的成对数据。要覆盖上面四类风险数据成本会迅速上涨而且每出一种新的攻防模式就补一轮数据并不现实。多模态输入又是连续高维图像不是有限离散文本想要靠穷举样本挡住变化几乎不可能。1.2 训练时对齐为什么补不完这块短板现在比较常用的对齐手段有 RLHF、DPO、基于红队数据的 SFT 等。它们确实让底模在多数场景下变得安全但存在两个硬约束。第一训练数据是静态的而越狱方法是动态演化的。今天收集的对抗样本在模型升级或攻击者换一种编码方式之后可能就不起作用。若每次都要重新训模型上线节奏会被拖得很慢。第二对齐和能力之间天然存在拔河效应。把模型在某些主题上调得过于保守它在无关场景里也会出现多余拒答用户体感会差很多。测试时安全对齐不做参数更新这意味着风险案例出现后可以只调推理策略不动底模维护成本天然更低。我在工程里更喜欢这样的切分模型负责通用能力安全策略作为生成过程中的一个控制层独立存在。GuardAlign 选 “测试时”这个切入点正好和这类部署需求对上。下面我顺着论文标题里的 Guard、Align 两个词说说我理解的实现思路。2. GuardAlign 的做法拆解把对齐动作放到生成阶段先澄清一点下面不是逐行贴公式而是把 GuardAlign 这类“测试时安全对齐”方案在推理链路里的位置讲清楚。Transformer 结构的 MLLM 本质上是自回归模型每生成一个 token 都依赖前文和视觉特征。测试时对齐想做的就是在这个逐 token 生成的过程中加入安全干预而不是等整段文本生成完之后再开一个审核服务。2.1 名称本身透露的设计意图guard alignGuardAlign 可以拆成 guard 和 align 两部分。guard 是守卫负责判断当前解码路径是否踩到安全边界align 是对齐负责在发现边界风险后重新调整生成分布而不是粗暴地清空输出。这个区别很重要。很多内容安全方案会做硬拦截命中关键词就返回“抱歉我无法回答”但硬拦截会有两个问题容易误伤无害问题而且无法处理语义层面的风险。GuardAlign 用“对齐”而不是“拦截”这个动作说明它的目标是把模型输出拉回到一个安全可靠的概率分布上。我在理解这类论文时会把它类比成开车时的导航。底模是发动机负责提供动力安全对齐是路线约束遇到前方封路时重新规划一条可走的路而不是直接熄火。测试时安全对齐更接近这种实时规划它观察当前已经生成的前缀和图像特征判断继续往哪个方向走会出问题然后压低高风险 token 的概率。一个典型的测试时安全对齐流程至少包含两个核心模块。一个是“安全评估器”它要能基于多模态上下文给出当前候选内容的风险评分另一个是“概率修正器”它把评分转成解码时的偏置信号改变下一个 token 的分布。GuardAlign 这个名字里的 Align 意味着它做的不是非黑即白的事后过滤而是把安全约束嵌入到生成过程中。2.2 一次完整的闭环应该长什么样按照标题推断GuardAlign 的输入侧应该同时拿到图片和用户文本而不是把图片先转成一段文字描述再走文本安全通道。后者会丢失大量细节并且单次 OCR 或 caption 的误差会被放大。安全判断如果直接建立在视觉特征和 token 序列上就能捕捉到更多跨模态上下文。实际推理时闭环大致是这几步用户上传图片并输入 prompt多模态编码器提取图像特征与文本嵌入一起进入模型。模型按正常方式解码但每生成一个候选 token解码器都会把当前前缀和图像隐状态交给安全评估器打分。安全评估器判定该方向是否存在高风险输出一个介于安全与不安全之间的连续分数。分数超过阈值后概率修正器会压低对应候选 token 的 logits或者基于安全目标重新进行 beam 搜索。模型继续生成直到输出结束或安全评估确认内容已经落在可接受区间。在这里很多人容易混淆“测试时对齐”和“输出审核”。输出审核是全文生成完再跑一遍内容安全模型发现问题后要么整段丢弃要么重新生成延迟和误伤都比较高。测试时对齐则是在生成的过程中实时介入它有潜力在造成不可逆输出之前改变方向。这也是为什么需要一个模块能访问模型内部状态而不只是拿到最终文本。我在复现类似方案时还意识到一个容易被忽视的细节安全评估器不一定非要是一个独立大模型。它可以是一个很轻量的分类头、一个训练过的 reward model甚至只是一组规则加向量检索。关键在于它评价对象要包含“图像特征 当前前缀”如果只看当前前缀就退化成文本安全分类了。2.3 为什么不更新模型参数也能产生对齐效果要理解这一点得回归到自回归模型的基本公式。模型在给定输入 X 时会为整个输出序列 Y 分配一个概率。安全对齐的目标是让模型在安全问题上输出低风险内容本质上是要改变条件分布让风险高的区域概率变小让规则内回答概率变大。传统方法通过调整网络权重来实现GuardAlign 这类测试时方法则直接操作解码阶段的分布。因为输出空间的概率分布由模型每一层的隐状态决定测试时干预如果发生在 logits 层它不会反向修改任何权重但也确实会影响最终抽样结果。把一批高风险回复的概率压下去把一批合规回复的概率抬起来最终从模型里采样得到的文本就变了。这种做法的最大优势是“可回滚”。如果安全策略导致误伤太大我只需调整干预权重或阈值不用重新部署模型。在某些产品里A/B 测试新安全策略只需要半天而重训模型可能要两到三周。对做多模态产品的人来说这两种时间成本不是一个量级。不过也要想清楚测试时对齐不改变模型内部已经学到的世界知识。模型可能仍然知道某些危险做法只是在生成时被约束住了。这既是优点也是局限后面我专门写一段边界判断。3. 动手跑通一条最小链路从模型加载到安全干预只看论文不落地其实很难有体感。我按照 GuardAlign 的思路在本地搭过一条最小验证链路。这里用的不是完整复现官方代码而是把“测试时安全对齐”的核心思想落到实际推理流程里适合想快速验证效果的同学参考。3.1 选型、数据和运行环境的准备模型选型上建议优先用支持图像输入的开源模型。Qwen2-VL、LLaVA、MiniGPT-4 这一类都可以。我实验时选了参数量 7B 左右的模型因为显存占用和推理速度更容易控制。如果你的任务只是先验证安全干预逻辑没必要一上来就上 70B。数据准备要分两类。第一类是“基础能力测试集”目的是验证加了安全干预后模型仍然能回答正常问题比如图像描述、OCR 提取、普通问答。第二类是“风险测试集”我建议从公开的多模态安全基准里取一部分再自己构造一些脱敏样本。自己构造时不要直接写危险细节最好从类别层面控制比如“诱导模型给出个人信息提取结果”“让模型把图片里的敏感操作步骤解释得更具体”等方向。环境上需要一块至少 24GB 显存的 GPU配合 Transformers 库就能完成大部分实验。视觉模型加载时记得把图片输入也放到同一设备上避免编码器和语言模型在不同设备间反复拷贝速度会慢很多。3.2 解码端安全介入的最小实现代码实现上我选择写一个自定义的 LogitsProcessor。这是 Hugging Face Transformers 提供的接口可以在每次生成 token 后、softmax 之前对模型输出的 logits 做修改。这样我们不需要改模型内部结构只要在 generate 时多传一个 processor 就行。下面是一个简化的伪代码from transformers import LogitsProcessor class GuardLogitsProcessor(LogitsProcessor): def __init__(self, safety_scorer, threshold0.6, weight1.5): self.safety_scorer safety_scorer self.threshold threshold self.weight weight def __call__(self, input_ids, scores): # scores shape: (batch_size, vocab_size) # 这里只处理第一条样本方便演示 batch_topk_indices scores.topk(10, dim-1).indices[0] for token_id in batch_topk_indices: token_text decode_token(token_id) # 评估器结合当前上下文判断这个token方向上是否安全 risk_score self.safety_scorer(token_text) if risk_score self.threshold: # 降低风险token的概率 scores[0, token_id] - self.weight * risk_score return scores这段代码的核心逻辑很简单每次生成时只看 top-k 候选如果某个 token 触发安全评估就降低它的分数。但真实场景有两个问题需要处理。第一安全评估不能只看当前 token。单个 token 往往没有完整语义比如“如何”这个词本身不危险但它可能开启一整段危险回答。所以安全评估器最好接收“当前已生成前缀 当前候选 token 图像特征”的拼接结果把输入序列喂给一个轻量分类模型或规则引擎。第二不能每步都对整个词表做评估。词表大小通常在十万以上逐 token 打分会拖垮推理速度。处理方式是把候选范围缩小到 top-k 或者 beam 候选里只对当前最有可能被采样的几百个方向做安全判断。如果你的场景需要更强控制可以加入一次“安全前缀池”预先生成若干条安全方向引导语解码时让模型在这些前缀中选择。这个方法在控制生成走向上比较有效缺点是会增加显存开销。3.3 该看哪些指标才能证明干预有效我见过很多人在评估安全对齐效果时只看“是否拒绝危险问题”。这其实不够。一个模型如果对所有输入都回复“我不能帮助你”安全指标当然好看但它已经无法提供服务。评估一套测试时安全对齐方案至少要同时看三类指标。第一类是安全类指标包括危险请求的拦截率、有害内容生成率。第二类是能力保持指标包括正常问答的正确率、图像描述的一致性和信息完整度。第三类是稳定性指标包括平均回答长度、拒答率、推理延迟变化。把这几项放在同一张表里对比才能看出干预到底是在“解决问题”还是“牺牲产品体验”。我实测下来比较有效的做法是设计成对样本。同一个图片输入先跑原始模型再跑加了 Guard 逻辑的模型然后对比回答路径。如果原始模型会生成一段高风险回答Guard 版本能改成“拒绝 给出安全替代建议”并且没有影响其他正常样本的回答那说明这套机制至少在这个测试集上是有效的。如果你需要更精细的调试还可以记录每一处被压低的 token 和对应风险分数。这样能准确定位是哪一步干预让回答轨线改变而不是把生成结果当成黑盒出了偏差只能盲目调参数。4. 实测中的四个典型问题与排查记录测试时安全对齐听起来不难但真正跑起来坑很多。这里分享四个我遇到过的典型问题它们不是论文里会写的那种“理想情况”而是生产级实验里几乎都会碰到的工程细节。4.1 图像上的隐藏文本根本没有进入判断器我第一次跑实验时安全评估器只接收了文本侧的 token 序列图片特征虽然参与了模型解码但没有被评估器显式利用。结果模型看到了图片里的一行小字并且把这行小字当成指令执行安全评估器却对整段输出的风险毫无感知。原因是评估器看到的只是“已生成文本”它根本不知道这句话来自图片中可被忽略的广告字幕还是用户强烈要求的指令。解决方式是在评估器入口增加多模态信息对齐。具体做法是先把图片里的 OCR 结果和用户 prompt 拼接起来再和当前生成前缀一起送入安全评分。如果你的视觉模型本身有 OCR 能力也可以直接从内部拿到视觉 token 对应的文本映射。对图片里的文字做一次显式提取能显著降低这种“隐形注入”漏判。4.2 干预强度一高整个模型变成复读机GuardLogitsProcessor 的 weight 参数如果调得太大模型会在很多安全问题的边界上直接选择保守回复。表面上拦截率提高了但用户问一个无害的常识问题只要某个候选 token 出现在安全敏感区也会被强行压低最终导致整句回答变得别扭甚至频繁输出“抱歉我不能回答”。我把这个现象叫“过度防御”。排查时先看拒答率是不是突然抬升。如果是就降低干预权重或者把“硬惩罚”改成“软重排”。具体做法是不直接减去一个固定分数而是对 top-k 候选重新归一化让相对安全的 token 获得更高概率。另一种方案是限制干预范围只对明确触发风险类别的首轮回复做干预后续生成尽量保持模型原有分布这样能减少对正常能力的影响。4.3 安全评估器自身也可能被“提示注入”带偏如果安全评估器本身就是一个大语言模型攻击者在图片里写入一段引导评估器“忽略安全规则”的文字评估器也可能被牵着走。换句话说你用来防守的模型也可能被同一套越狱手段攻破。这个问题在真实产品里比想象中更常见。应对思路是不要把评估器设计成“直接读上下文给结论”的开放问答模式而是给它结构化的输入。我会把原始用户 prompt、OCR 结果、当前生成前缀分别放入独立字段要求评估器只输出定长的结构化标签不输出自由文本。同时不应把用户提供的原始内容直接当作系统指令而应明确标注“以下内容均属于待检测输入”。这样能大幅降低注入效果。4.4 多图和超长上下文带来的性能怪问题产品里的真实请求不总是一张图有时用户一次提交多张截图或者图片中带有大量表格文字。多图场景下安全评估器如果对每张图单独判断可能漏掉跨图的组合风险。例如第一张图看起来无害第二张图也无害但两张图拼在一起就构成了完整的高危上下文。测试时安全对齐如果只做单帧判断这类风险就会绕过。超长上下文则会影响干预时延。每次解码都要把当前前缀送入评估器token 越长评估耗时越高。我实测下来最有效的方式是分层评估只在关键风险点比如用户指令刚被理解完、模型准备输出结论时做一次高强度的安全检查其他 token 只做轻量级判断。这样能把延迟控制在可接受范围内。4.5 常见问题速查表现象可能原因定位思路处理建议图片内嵌文本触发的危险回答未被拦截评估器没有接收图像侧文本特征检查评估器输入中是否包含 OCR 结果显式提取 OCR 文本并并入评估上下文拦截率上升但正常问答变差干预权重过大或范围过宽对比干预前后正常问题准确率降低 weight使用软重排代替硬惩罚安全评估器被图片里的注入词绕过评估模型把待检测内容当成了指令拆分输入字段禁止评估器输出自由文本输出结构化标签并加字段边界标识多图请求处理时长明显增加每张图、每个 token 都做深度评估打印评估耗时分布采用分层评估只在关键节点做深度判断5. 我对 GuardAlign 这类测试时对齐的边界判断把整个链路跑通之后我对测试时安全对齐的边界也有了更清楚的认识。它适合解决“上线之后遇到新攻击面”的问题但并非万能补丁也不是用来替代训练时对齐的。5.1 测试时干预改不了“内部知识”如果模型内部已经把一种危险做法学得非常扎实测试时安全对齐只能让模型“不说不做”并不能把这段知识从模型权重里抹掉。在要求强解释性的场景里模型可能因为安全约束给出表面合规的回复但底层知识仍然会影响它回答其他相关问题时的方式。因此我认为最佳实践是把训练时对齐和测试时对齐组合起来训练阶段做基础价值观对齐测试阶段做动态防线。另一个边界是性能开销。虽然它比重新训练快得多但每一次干预都增加了推理时计算。如果产品并发很高又不能接受延迟上升那么测试时安全对齐模块需要做大量工程优化比如把评估器蒸馏成一个小模型或者只在响应时间压力较小的离线异步流程中使用。5.2 后续值得尝试的两个扩展方向我接下来会重点试两个方向。第一个方向是给测试时安全对齐增加“记忆能力”。把历史上被拦截的风险样本向量化存储当新的多模态输入进来时先与历史风险向量做一次检索命中后再启动深度安全评估。这样不需要每次都对全部上下文做大模型推理响应速度和拦截准确率可以有更好的平衡。第二个方向是把多模态防护从“判断结果”推进到“引导过程”。目前的方案大多是让模型不要输出危险内容更好的方式是在图像特征进入模型前就对可能导致风险的视觉注意力区域做引导性调整或者把图像描述“翻译”成一个更安全的内部表达让模型从一开始就不走上高风险推理路径。我个人现在的体会是多模态大模型的安全问题不会因为一次测试时对齐就彻底结束但 GuardAlign 把问题放在了一个非常适合工程迭代的位置。它让我们不必为了追一个新型攻击反复重训模型而是可以在推理侧快速建立防线、观察效果、动态调整。对产品团队来说这种“反应速度”往往比单点能力更有价值。最后再分享一个小技巧调试测试时安全对齐时不要只看最终安全率建议把每次干预的 token 路径和风险分数都打出来。那些你以为没有问题、却被干预改写的样本才是帮你调好阈值最宝贵的素材。