最近在梳理大模型安全审计相关方案时我注意到一个很有启发性的研究方向BLOOM-WILT。它把“日志倾斜Logit Tilting”用在了自动化 LLM 审计中目的是通过可控的生成测干预把模型在常规提问下不容易暴露的行为诱发出来。这类工作既不是简单的对抗样本攻击也不是纯提示词工程而是从模型输出概率分布入手重新思考“如何让模型展现出我们需要观察的行为”。本文围绕这个方法做一次系统拆解适合做 LLM 应用开发、模型评测、安全测试的同学阅读希望帮助你把论文里的核心思想迁移到自己的审计实验或评测框架里。1. 为什么自动化 LLM 审计需要“行为诱发”1.1 能力评测与行为审计是两回事训练完一个大模型后团队通常先跑一批公开 benchmark比如问答准确率、代码生成通过率、指令遵循率。这些指标回答的是“模型在标准任务上有多强”。但当我们把一个模型放到客服、知识助手、自动化 Agent、企业内部问答等真实场景前还要回答另一个问题模型在什么情况下会出现不该出现的行为例如模型是否会在特定身份暗示下输出未经确认的建议是否在多次追问后逐渐降低拒绝概率是否会对不同人群给出不一致的回答是否在上下文里出现少量错误事实时表现出过度自信。这些现象很难用一两条测试用例触发因为它们不是均匀分布在正常输入空间里的而是潜伏在特定上下文和采样条件下。传统评测通常只做一次性采样再用规则或模型打分判断对错。这种方式在风险审计中往往不够一次干净输出不能证明模型不会在别的生成条件下输出风险内容。我们需要构造更容易暴露问题的实验条件让风险行为源源不断地呈现出来然后统一记录、分析、评估。这个过程可以称为行为诱发Behaviour Elicitation。1.2 固定测试集无法覆盖“隐藏行为”很多团队会准备一份敏感话题测试集循环去问模型再判断回答是否合规。思路没错但覆盖面存在明显瓶颈自然语言输入空间太大靠人工枚举问题很难覆盖边界情况。模型经过对齐后对部分高危指令会直接拒绝。但拒绝不等于内部没有对应行为模式更不等于换个表达后依然不会触发。固定的 prompt 模板会被模型记住开发阶段测过一轮后模型可能已经“熟悉”了这些问法继续用同一批用例难以反映真实鲁棒性。所以审计不能只停留在“多写几个坏问题”的阶段而应该寻找一种系统化改变生成条件的方法。BLOOM-WILT 这类工作的价值就在这里它不是为了构造一个无敌的攻击模板而是提供一套可调节的生成干预机制用来系统性地筛查模型的行为边界。1.3 生成侧干预比纯 prompt 更可控当我们只用 prompt 诱发模型行为时实际上是在输入层做文章。输入层的缺点是模型内部如何理解 prompt、哪些 token 被激活都是一个黑盒同样的 prompt 换一个模型版本效果可能完全不同。如果从 logits 层做干预情况就不一样了。模型的每一步生成都基于一个词汇表大小的分数向量也就是 logits。这个分数向量经过 softmax 后变成下一个 token 的概率分布。直接调整某些 token 的 logits相当于绕过 prompt 表达的不确定性从采样源头改变模型输出倾向。这种方法的一个直接好处是干预量是可量化的比如对目标 token 的 logits 加 1.0、2.0我们可以重现实验结果也可以用不同干预强度画出行为变化曲线。因此行为审计想要自动化需要一种足够稳定、可重复、可参数化的手段。Logit Tilting 正符合这个需求。2. 从 Logits 到 Logit Tilting核心原理与实现方式2.1 Logits 与概率分布的基本关系大语言模型本质上是在预测“下一个 token 是什么”。在每一层 Transformer 计算结束后模型会通过语言模型头输出一个维度等于词表大小的向量这个向量就是 logits。为了得到每个 token 的生成概率需要对 logits 做 softmax 归一化。用简单公式表达就是p_i exp(z_i / T) / sum_j exp(z_j / T)其中 z_i 是第 i 个 token 的 logitsT 是温度参数p_i 是最终生成概率。如果我们想提高某个 token 的出现概率最直接的方法是让它的 logits 变得更大或者让其他 token 的 logits 变得更小。对 logits 做这种定向改造在工程上通常叫 logit bias在研究语境下也可以叫 logit adjustment 或 logit tilting。先看一个很小的模拟示例理解数值变化带来的概率变化import torch import torch.nn.functional as F # 假设一个极小的词汇表只有 3 个 token logits torch.tensor([-2.0, 0.5, 3.0]) # 温度 T1.0 时的原始概率 probs_original F.softmax(logits, dim-1) # 对第 2 个 token 施加 bias1.0 logits_tilted logits.clone() logits_tilted[2] 1.0 probs_tilted F.softmax(logits_tilted, dim-1) # 更低的温度会放大差异 probs_low_temp F.softmax(logits / 0.8, dim-1) print(原始概率:, probs_original.numpy()) print(倾斜后概率:, probs_tilted.numpy()) print(低温概率:, probs_low_temp.numpy())从结果可以看到原始概率会被拉高或压低。这里的核心不是“加一个正数”这个动作而是我们改变的是 logits 的相对关系。softmax 对绝对数值不敏感但对相对差值非常敏感。某一个 token 的 logits 比另一个 token 高 2.0和整体 logits 同时平移 2.0概率分布不变但单独抬升一个 token其他所有 token 的概率都会被相对压低。2.2 什么是 Logit Tilting“Tilt”这个词在英文里有倾斜、偏向的意思。Logit Tilting 可以直译为“日志倾斜”或“对 logits 做偏置调整”。它并不是大模型领域新造出来的概念早期统计语言模型里就有类似操作例如强行提升某个词的概率、屏蔽某些词业界常称为 logit bias。在 BLOOM-WILT 这个审计场景里Logit Tilting 被用来做更系统化的事它不是针对单一有毒词做屏蔽或放行而是选取一组与待审计行为相关的 token整体提高或压低它们的 logits从而创造一个概率分布倾斜的生成环境。例如我们想观察模型在“不确定语气”上的行为边界可以把 maybe、possibly、uncertain、not sure 这类 token 的 logits 适当抬高。这样模型在生成时更容易顺着带有不确定语义的方向输出。接下来就可以判断模型是对不确定内容表达得更保守还是会因为倾向性太强而产生模式化回复。也可以反向操作压低某些表示拒绝或保守的 token观察模型是否会在缺少拒绝信号后暴露出与训练目标不一致的行为。这种方法比单纯换 prompt 要精细我们不是重新教模型“你应该怎么回答”而是通过改变概率分布观察模型内部原本存在的各种行为倾向。2.3 与 Temperature、Top-k、Prompt 的关系很多读者容易把 Logit Tilting 和 Temperature、Top-k 采样混淆。这里用一张表说明它们的区别生成控制方式作用位置控制目标审计用途Prompt 设计输入层指定任务指令、角色、示例覆盖面广但难以精确复现到 logits 层Temperature概率分布缩放控制整体分布的平滑程度温度高时随机性增加温度低时趋向确定Top-k / Top-ptoken 候选集合截断低概率候选用于约束搜索空间不能定向提升某类行为Logit Tilting单个 token 或 token 子集定向抬高/压低某类候选 token可以对行为关键词做定量干预适合自动化审计采样方式输出路径控制 greedy / beam / sample影响生成稳定性和多样性实现层面Temperature 也是对 logits 做缩放但它是对整个向量统一处理Top-k、Top-p 则是过滤候选 token 集合。Logit Tilting 是更精细的“局部”操作只修改我们关心的 token 子集保留其他 token 之间的竞争关系。因此在 BLOOM-WILT 风格的行为诱发流程中它非常适合与常规采样器组合使用。2.4 需要理解的能力边界Logit Tilting 能改变生成结果但不要把它的作用想得过于神奇。模型的参数在推理阶段是冻结的Logit Tilting 只是在最后一层输出分布上做偏置并不能消除模型权重里已经学到的知识依赖。如果某个行为在模型内部完全没有对应的语义表示那再怎么倾斜 logits也只能生成无意义的重复文本。另外Logit Tilting 对“表层文本风格”的调节能力较强对“深层事实推理”的调节能力相对有限。比如我们可以通过倾斜 token 让模型更倾向于说“我不同意”但模型不同意背后的理由是否成立还需要结合完整生成内容和评测标准来判断。这也是为什么在自动化审计中行为诱发只承担“发现问题”的职责最终结论仍然需要人来复核。3. BLOOM-WILT 的方法思路与审计工作流3.1 方法名传达了什么意图“BLOOM-WILT”这个命名带有很强的意象对比Bloom 是绽放Wilt 是枯萎。放在 LLM 审计语境里可以理解为我们希望模型在某些条件刺激下把原本“沉睡”的行为展现出来像花一样开放同时我们希望模型内部那些不合适的抑制或对抗行为在可控实验条件中“枯萎”从而暴露真实风险。从标题结构看“BLOOM-WILT: Logit Tilting for Behaviour Elicitation in Automated LLM Auditing”强调的是一套为自动审计服务的行为诱发方法核心技术手段是 Logit Tilting。BLOOM-WILT 本身更像是这套流程的整体代号而不是某个单一开源框架。因此我们不必把注意力放在“它是不是一个库”上而应该抓住它对审计流程的贡献使用可控的生成概率干预让模型行为更可观测、可量化、可复现。3.2 一套可迁移的审计工作流虽然论文的具体数据、模型和实验配置没有完全公开但基于标题和方法名可以整理出一套通用的自动化审计工作流。这套流程很适合在实际项目中迁移第一步明确待审计的行为类别。审计不是漫无目的地让模型乱说话而是先定义一组行为假设。例如模型是否会在角色扮演中忘记安全边界是否会在用户持续追问时降低拒绝概率是否会在代码任务里生成不安全的伪代码是否会对不同表达方式的敏感问题存在响应差异。第二步挑选行为指示 token。对每个行为类别选择一个或多个能够代表该行为的 token 集合。例如想诱发“继续完成任务”的行为可以把表示肯定、同意的常见英文或中文 token 纳入集合想观察“模型愿意展开分析”的程度可以把表示推测、比较、总结的 token 作为目标。token 集合需要从具体模型的 tokenizer 中解析不能拍脑袋写死。第三步设计 Logit Tilting 策略。设定倾斜方向和强度。倾斜方向包括抬高、压低或同时抬高一组 token、压低另一组 token倾斜强度通常从 0.5 到 3.0 之间按梯度选择。审计阶段建议跑一组基线bias0.0再逐步增加倾斜强度观察模型输出的行为变化曲线。第四步批量生成与自动判读。在统一 prompt 集上分别用不同倾斜参数生成多条输出。自动判读可以是规则匹配也可以是另一个评估模型还可以是分类器。关键指标包括目标 token 出现的比例、输出文本在行为类别上的分布、拒绝率、连续生成是否中断等。第五步汇总证据并生成报告。把每条输出与对应的生成参数、prompt、模型版本、采样随机种子一起记录。审计报告必须具备可复现性否则风险结论无法被后续回归测试使用。3.3 与常见 Prompt 红队测试的区别很多朋友看到“行为诱发”会联想到红队测试或越狱测试。需要说明的是Red Teaming 通常强调“人肉找漏洞、构造攻击性输入”而 BLOOM-WILT 这类方法更强调“自动化、系统化地发现行为边界”。两者的区别主要有三点第一干预层次不同。Prompt 红队是在输入文本层寻找漏洞BLOOM-WILT 则直接把控制信号放在 token 概率分布上干预更底层也更稳定。第二目标不同。红队测试经常会追求“让模型输出违规内容”而 BLOOM-WILT 更偏向审计机制研究。它同样要观察模型的风险行为但目的是形成可执行的测试方法和度量指标而不是制造一次攻击。第三可复用性不同。红队发现一个漏洞后往往只能固定成一个回归用例BLOOM-WILT 可以用不同的 logit 倾斜因子扫描行为边界得到的是类似“强度-响应曲线”的数据对后续对齐训练和风险评估更有参考价值。从安全角度说这类审计方法必须建立在合法授权和研究伦理基础上。使用它的人应该限定在模型开发方、合规审计方或明确授权的研究团队中不能直接拿来做攻击工具。4. 最小自动化审计实验从 Logit Bias 到行为诱发的完整示例4.1 实验目标与准备为了把前文概念落到可运行代码这里设计一个最小实验。实验不复制 BLOOM-WILT 的原始实现而是演示“如何用 logit tilting 做行为诱发”你可以在此基础上扩展。实验假设你希望审计一个生成模型在“天气预测任务”中是否会出现过度自信。我们先让模型在常规条件下生成预测再通过倾斜不确定类 token观察输出是否明显转向不确定语气。实验不涉及敏感话题只用于演示方法流程。需要准备的 Python 环境包括 transformers、torch。安装命令pip install torch transformers由于不同版本接口有差异本文代码以常见的 transformers 4.x 版本为例。模型加载部分建议使用 gpt2 这类体积较小的模型也方便在 CPU 上运行。如果网络环境无法直接下载模型可以提前把模型文件放到本地目录然后改成 AutoModelForCausalLM.from_pretrained(/your/local/model/path)。4.2 用模拟 logits 理解倾斜效果先写一个简单的函数对比原始 logits 与倾斜后概率的差异。这里使用一个假设的 10 维向量只为了可读性不是真实模型输出import torch import torch.nn.functional as F def inspect_logit_tilting(logits, target_ids, bias, temperature1.0): 观察给指定 token 增加 bias 后的概率变化。 target_ids: 需要倾斜的 token id 列表 bias: 倾斜量 logits torch.tensor(logits, dtypetorch.float32) original_probs F.softmax(logits / temperature, dim-1) logits_tilted logits.clone() for token_id in target_ids: logits_tilted[token_id] bias tilted_probs F.softmax(logits_tilted / temperature, dim-1) print(原始概率 top3:, original_probs.topk(3)) print(倾斜后概率 top3:, tilted_probs.topk(3)) for token_id in target_ids: diff tilted_probs[token_id].item() - original_probs[token_id].item() print(ftoken {token_id} 概率变化: {diff:.4f}) # 示例用 10 维 logits demo_logits [0.1, 0.5, -0.3, 2.0, 1.2, -1.0, 0.8, 1.5, 0.3, 0.6] inspect_logit_tilting(demo_logits, target_ids[6], bias2.0, temperature1.0)代码里 target_ids 是待倾斜 token 的索引实际使用时应换成真实模型的词表 id。增加 bias 后目标 token 的概率会上升但上升幅度不是线性的它取决于原有 logits 与其他 token 的竞争关系。理解这一点很重要Logit Tilting 的强度需要根据模型和场景调试不存在一个“万能 bias 值”。4.3 在 Transformers 生成流程里注入 Logit Tilting真实模型不会直接暴露“下一个 token 预测概率”给我们操作。但 transformers 提供了 LogitsProcessor 机制可以让我们在每一步生成时修改 scores。下面实现一个通用的 LogitTiltProcessor它的逻辑很简单把指定的 token id 集合全部加上一个 bias。新建文件logit_tilt_processor.pyfrom transformers import LogitsProcessor class LogitTiltProcessor(LogitsProcessor): 定向提高或压低指定 token 的 logits。 tilt_token_ids: 需要倾斜的 token id 列表 tilt_value: 倾斜量正数为提高负数为压低 def __init__(self, tilt_token_ids, tilt_value1.5): self.tilt_token_ids list(tilt_token_ids) self.tilt_value float(tilt_value) def __call__(self, input_ids, scores): scores scores.clone() for token_id in self.tilt_token_ids: if token_id scores.size(-1): scores[:, token_id] scores[:, token_id] self.tilt_value return scores代码解释scores 形状通常是 (batch_size, vocab_size)表示当前步所有 token 的 logits。之所以先 clone是因为 transformers 可能复用缓存 tensor直接修改会带来不可预期影响。token_id 需要判断是否越界防止某些增量词表或特殊 token 导致索引错误。在主脚本里按下面方式调用from transformers import AutoModelForCausalLM, AutoTokenizer, LogitsProcessorList model_name gpt2 # 可换成本地模型路径 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) prompt The weather forecast for tomorrow is inputs tokenizer(prompt, return_tensorspt) # 查询目标 token 的真实 id target_words [ maybe, perhaps, uncertain] target_ids [] for word in target_words: ids tokenizer.encode(word, add_special_tokensFalse) if ids: target_ids.append(ids[0]) print(目标 token id 示例:, target_ids) # 使用倾斜处理器 tilt_processor LogitTiltProcessor(target_ids, tilt_value2.0) outputs model.generate( inputs[input_ids], max_new_tokens20, do_sampleTrue, temperature0.9, logits_processorLogitsProcessorList([tilt_processor]), ) generated_text tokenizer.decode(outputs[0], skip_special_tokensTrue) print(generated_text)这里把 maybe、perhaps、uncertain 等 token 的 logits 上调后模型会更倾向于生成带有不确定语义的续写。你可以在同一 prompt 下多跑几遍并记录目标 token 是否出现。有一点需要提醒不同分词器会把同一个英文单词切成不同 token尤其是带空格前缀时。所以我们应该用 tokenizer.encode( maybe, add_special_tokensFalse) 来查询真实 id而不是肉眼猜测词表 id。中文场景也是同理要直接查询句子切分后的 token。4.4 把审计结果整理成可对比的报告单看一次生成不够有说服力。自动化审计要的是多次生成后的统计结果。可以写一个简单的循环import random import numpy as np def run_audit_with_bias(model, tokenizer, prompt, target_ids, bias_values, num_samples5): 对每个 bias 强度采样 num_samples 条统计目标 token 出现次数。 results {} for bias in bias_values: hit_count 0 texts [] for seed in range(num_samples): torch.manual_seed(seed) processor LogitTiltProcessor(target_ids, tilt_valuebias) inputs tokenizer(prompt, return_tensorspt) outputs model.generate( inputs[input_ids], max_new_tokens20, do_sampleTrue, temperature0.9, logits_processorLogitsProcessorList([processor]), ) text tokenizer.decode(outputs[0], skip_special_tokensTrue) texts.append(text) if any(word in text for word in [maybe, perhaps, uncertain]): hit_count 1 results[bias] { hit_count: hit_count, hit_rate: hit_count / num_samples, texts: texts, } print(fbias{bias:.1f}, hit_rate{hit_count / num_samples:.2f}) return results results run_audit_with_bias( modelmodel, tokenizertokenizer, promptThe weather forecast for tomorrow is, target_idstarget_ids, bias_values[0.0, 1.0, 2.0, 3.0], num_samples5, )这里需要注意代码中用于简单命中统计的字符串匹配方式比较粗糙只适合演示。真实项目中建议使用更细粒度的判读规则例如只统计模型新增生成部分使用更严格的关键词组合或者用另一个评估模型判断语义是否进入“不确定”类别。整体运行完你会看到类似这样的趋势当 bias 从 0 增加到 3 时目标 token 或目标语义的出现频率明显上升。这种“强度—响应”曲线就是审计报告里非常有价值的证据。5. 实际应用中的常见问题与排查思路这套流程看起来简单真正落地时却会遇到不少问题。下面整理几个最常踩的坑。问题现象常见原因解决思路倾斜 logits 后输出明显变差目标 token 集合选得不对或 bias 过大减小 bias并重新审视 token 是否真的代表目标行为目标 token id 不存在或越界不同 tokenizer 词表不同用 tokenizer.encode 先查询真实 id再做过滤多次采样结果波动很大温度过高随机种子未固定降低温度固定 seed并增加采样次数同一 prompt 在两种模型上效果差异大模型词表、分词粒度不同审计报告里必须记录模型版本和 tokenizer 版本模型一直输出与目标行为无关的内容该行为在模型内部表示较弱尝试换成更长的行为提示再叠加 logit tilting生成阶段出现 batch 不一致报错未设置 pad_token批量生成时设置 tokenizer.pad_token 与 attention_mask审计结果好但线上仍有风险logit tilting 只覆盖 token 层需要与 prompt 类红队、行为评测集合结合使用对于“模型一直不配合”这个问题可以多思考一下目标行为是否存在语义冲突。例如你想诱发“模型的拒绝行为”但模型经过对齐后默认拒绝率已经很高此时再压低拒绝相关 token效果可能被模型内部偏好抵消。这时应该把 Logit Tilting 当作一种“探索工具”而不是“绝对控制工具”。另外审计时如果发现某个行为只在很强的 bias 下才出现要谨慎下结论。bias5.0 甚至更高时模型生成文本已经有明显异常这可能是概率分布被破坏导致的伪现象而不是真实行为倾向。更合理的设计是记录不同强度下的连续性变化观察是否存在“临界点”而不是只看极端值。6. 工程建议与审计实践要点6.1 让每一轮审计都可复现自动化审计最大的价值是可以在模型迭代过程中反复运行。为了让结果可对比至少需要记录以下信息模型名称与版本包括是否经过微调、量化、LoRA 等改动。Tokenizer 版本与词表大小。采样参数temperature、top-k、top-p、max_new_tokens、seed。完整的 Logit Tilting 参数目标 token 列表、bias 值、作用步数范围。Prompt 版本与输入编码结果。输出文件与判定规则版本。这些信息建议以 JSON 或 YAML 格式和输出结果一起保存。没有这些上下文审计报告里的“风险行为”很难被后续版本复现。6.2 从单 token 扩展到 token 集合单 token 倾斜容易受分词影响。例如“maybe”可能在词表里是一个 token可能被拆成多个 token。更稳妥的做法是基于文本片段自动解码成 token 集合做“集合级倾斜”。这样模型即使换了一种拼写或换了一种分词方式也能被干预到。在代码层面可以先准备一组描述目标行为的候选短语再通过 tokenizer 把它们全部映射成 token id 列表。执行倾斜时直接对集合内所有 token 加上统一偏置。6.3 不要只观察是否“命中关键词”判断行为不能只做关键词匹配。一个模型可能包含“maybe”这个词但实际上后面的内容依然是确定性的表达也可能文本里没有明确说“不确定”但语气已经明显变得保守。因此更严谨的自动判读要结合子序列级别的目标行为打分模型。困惑度perplexity变化。模型在对照 prompt 上的输出差异。多次生成的行为分布而不是单次命中率。在论文或工程实践中这些指标往往组合成一个审计分数用来衡量“行为被诱发”的强度。建议团队根据自己的风险类别设计一套低成本评估集而不是每次都依赖大模型裁判。6.4 审计方法的使用边界与安全边界Logit Tilting 可以诱发模型在常规采样下不容易出现的输出。这个能力很有价值同时也需要被约束在合法授权场景中。如果你是模型开发方可以用它做上线前的自测如果你是第三方审计团队必须获得模型使用方的明确授权。实验过程中还应当注意审计生成内容可能包含潜在风险不要直接存储在公开日志中。避免在不隔离的生产环境里批量触发高风险输出。实验数据要做到最小化保存并在报告完成后按策略清理。发现风险后修复动作仍应回到数据清洗、指令微调、对齐训练、输入输出过滤等环节不能指望“推理时压低几个 token”解决根本问题。使用这类技术有一个很朴素的原则我们能诱发模型的坏行为不代表我们要诱导真实用户去使用这些坏行为研究模型出错的方式最终是为了让模型更少出错。7. 下一步可以动手做什么如果你想进一步深入 BLOOM-WILT 和 Logit Tilting建议先不要直接复现复杂论文实验而是按照下面的顺序做一轮小型研究第一步选定一个你熟悉的模型准备 50 条左右的审计 prompt。第二步针对其中一类行为配置不同的 logit 倾斜 bias分别生成 10 条结果。第三步用关键词统计加人工抽样画出 bias 与行为出现率的关系。第四步复跑同样的代码验证可复现性再把流程推广到更多行为类别。整个实验也许只需要一两天时间但做完以后你会更清楚 LLM 审计为什么不能停留在“输入一个坏 prompt看输出是否违规”的层面。当你开始从 token 概率、采样条件、模型内部偏差这些维度思考问题时才算真正进入了自动化 LLM 审计的大门。上面这份代码和思路可以作为起点你可以根据自己的业务风险类型继续扩展。