模型方向消除实现：测试覆盖与运行边界

ABLITERAX 想把修改大模型拒答行为这件事，做成一条可配置、可搜索、可评估的流水线：先提取与拒答相关的内部表示，再调整模型权重，最后检查能力损失。作者没有承诺「零拒答」，而是强调测量拒答率与保留通用能力之间的取舍。

这个方向有研究价值，但原文展示的代码还撑不起「完整可运行系统」的结论。尤其是激活采样位置，可能让后续分析从起点就拿不到有效信号。读这篇，既能理解它的设计，也能练习判断 AI 工程方案的证据是否充分。

拒答能不能当成一组方向来处理

作者的出发点是：模型面对不同输入时，内部激活存在差异，其中可能包含与拒答行为相关的方向。找到这些方向后，可以尝试削弱模型沿这些方向输出的分量。

这里的「方向」是高维向量，不是一句提示词；「子空间」则是多个方向共同张成的空间。方案默认提取 n_directions=4，并提供 diff_means、svd、whitened_svd、fisher_lda 四种方法。

其中，diff_means 直接计算两组激活的均值差；fisher_lda 结合组内协方差调整这个差异，试图减少高波动维度的干扰。默认的 whitened_svd 则先按协方差调整数据，再提取主要方向。

但两组数据分别来自 mlabonne/harmless_alpaca 和 mlabonne/harmful_behaviors。它们的差异可能包含主题、措辞、长度和格式，不能直接认定为「拒答差异」。

分开两类输入的方向，不一定就是控制拒答的方向。

作者也没有假设所有层共享同一个方向。配置默认采用 direction_index_mode="per_layer"，逐层提取；干预强度通过 kernel schedule 搜索位置和宽度，避免提前认定拒答只发生在某一层。

设计中的权重更新公式是 W' = (I − λ·V Vᵀ)·W，即削弱输出中落在目标子空间里的部分。它还计划投影 bias，通过 MPOA 保持行范数，并验证 LoRA 风格的 rank-k hook 与显式改权重的等价性。不过，这些实现与测试正文没有出现在所给材料里。

流水线怎样控制成本与能力损失

数据默认每组取 512 条，其中 256 条用于提取方向，剩余部分留作评估。这样至少把「发现方向」与「检查效果」分开，避免直接拿同一批样本自证有效。

搜索默认运行 n_trials=16，启动阶段为 n_startup_trials=6，支持 tpe 和 random。每轮使用 64 条正常输入、64 条风险输入，最多生成 64 个 token；max_weight_upper=1.2，early_stop_patience=8。

作者没有让每轮候选都跑完整基准，而是先用校准集代理指标筛选，再让 post_search_top_k=3 个候选接受真实 benchmark。这是合理的成本安排：便宜指标负责缩小范围，昂贵评估负责复核。

计划中的评估包括正常输入上的 KL 散度、困惑度，以及 lm-eval-harness 的 mmlu、gsm8k、humaneval。KL 衡量修改前后输出分布的偏离，困惑度检查语言建模表现；配置还提供 ppl_max_ratio=1.35 的限制。

不过，代理指标如何组合、拒答如何识别、最终测得多少，原文都没有给出结果。作者明确表示不会宣称「0% refusal」，报告应输出实测比例和样本量。这个口径值得保留，但目前只有报告要求，没有报告数据。

硬件方面，作者称流程可在 T4 上运行 Qwen/Qwen3-0.6B，多 GPU 使用 accelerate 的 device_map="auto" 分片。加载器支持 bnb_4bit，默认预留 reserve_gb=3.0。这些仍是作者的运行声明，材料里没有对应日志或显存实测。

最需要先检查的，是激活采样位置

采集器在每个 decoder block 输入处挂 register_forward_pre_hook，记录进入该层的残差流，再转成 CPU 上的 FP32 数据。问题在于，它为每条输入选取了第一个非 padding token：

                mask = enc["attention_mask"]
                first = mask.float().argmax(dim=1)
                for r in range(act.shape[0]):
                    out[r, i] = act[r, int(first[r])].cpu()

要盯住的是 argmax(dim=1)：这里取得第一个有效位置，并非读完用户问题后的位置。

对因果语言模型来说，前面的 token 看不到后面的内容。如果 chat template 让所有样本都以相同的特殊 token 或角色前缀开头，那么这个位置的激活可能完全不包含用户问题之间的差异。后续 SVD 即使顺利运行，也未必有可分析的拒答信号。

几何计算也有一个需要解释的选择。svd 分支先对两组数据分别减去各自均值，再拼接：

            C = np.concatenate([b - mu_b, -(g - mu_g)], axis=0)
            V = _svd_directions(C, k, cfg.random_svd_oversample, cfg.random_svd_power_iters)

关键是第一行：两组均值差已经被移除。这段代码更直接提取的是组内变化的主要方向，不能仅凭方法名称就认定它找到了区分两组的方向。它是否有利于干预，需要独立实验说明。

代码完整性同样不能略过。config.py 在异常字符串中途截断，架构注册表和 geometry.py 也没有展示完；目录中的 interventions.py、optimizer.py、benchmarks.py、exporter.py、cli.py 与测试正文均未提供。读者无法仅靠这份输入复现整条链路。

还有几处可直接从片段发现的不一致：项目声明支持 Python >=3.10,<3.13，却直接导入 Python 3.11 才内置的 tomllib；没有 CUDA 且 allow_cpu=False 时只打印警告，未阻止继续加载；显存判断在配置 vram_gb 时使用 have * cfg.hardware.vram_gb，与字段表达的 GB 单位并不一致。

这些都需要先修正或解释。

我的判断

我认可它把拒答变化与能力损失放在一起评估，也认可逐层建模、保留评估集、先筛选再跑完整基准的思路。相比只展示几条修改前后的回答，这套设计更接近可审计的实验。

但作者声称 CPU 测试覆盖方向提取、正交化、winsorization、权重投影、行范数、Pareto 筛选和 dtype 往返转换，所给材料没有展示测试内容或执行结果。这里应写成「作者称已验证」，不能直接当成读者已经看到的证据。

数学操作通过测试，也不能证明提取到的就是拒答机制。

采样位置是否有效、数据是否存在混杂、拒答检测是否准确、跨数据集能否成立，都需要真实模型实验。作者自己也把 checkpoint 加载、hook 正确性、真实 logits 上的 KL，以及拒答检测列为运行时验证事项。

v0.1 的边界倒是比较明确：不包含依赖各模型 SAE 的特征提取；没有完成精确的 LEACE affine erasure；MoE 各专家共享残差子空间，逐专家 EGA 留到后续。这些限制会影响方案能推广到多大范围。

如果目标只是调整日常 AI 编程助手的误拒答，提示词、模型选择、任务微调也应作为比较对象。原文没有这些对照，更没有能力保留的结果表，因此目前更适合把 ABLITERAX 看作一份待补全、待验证的研究工程草案。

能拿来做什么

• 如果你研究本地模型，先检查 chat template 和 token 采样位置，确认激活包含用户输入的信息，再投入方向提取与权重修改。
• 如果你开发 AI 评估工具，可以借鉴「提取集与评估集分离、代理指标筛选、top-K 完整复核」的流程，同时公开样本量和检测规则。
• 如果你评估模型是否适合代码助手，应把 humaneval 等能力结果与拒答率一起看；原文尚未提供这些结果，不能据此推断修改后的模型更适合编程。
• 如果你准备接入 Node 或全栈应用，先把模型修改当作独立实验环节，要求拿到完整代码、可重载产物与评估报告，再决定是否接入业务。