第 3 篇｜能不能「看懂」AI 在想什麼——可解釋性作為安全支柱

18th鐵人賽

knightmare

團隊昱見全高點

2026-09-08 01:27:05

128 瀏覽

分享至

能不能「看懂」AI 在想什麼——可解釋性作為安全支柱

[[我也希望安全第一]]｜第 3／30 天

Golden Gate Claude：把一個特徵轉大

2024 年 Anthropic 公開了 Golden Gate Claude。這個實驗很適合用來理解機制可解釋性目前在做什麼。

研究團隊在 Claude 內部找到一個與「金門大橋」概念相關的特徵，再把這個特徵的 activation 調高。調整後的 Claude 會頻繁把各種問題連回金門大橋；被問到心情時，它也用大橋來描述自己。

這項展示提供了一個很具體的觀察：模型內部的部分抽象概念可以被定位，改變相關 activation 也能影響輸出行為。

安全研究接著想確認，類似方法能否定位欺騙、越權或生成漏洞程式碼等傾向，並在行為發生前介入。前兩篇從資料與訓練塑形行為，這條研究路線則嘗試直接觀察和調整模型內部機制。

從神經元到稀疏特徵

直接逐一讀取神經元通常得不到清楚答案。一個重要假說是 superposition（疊加）：模型需要表示的特徵多於可直接分配的維度，因此把多個特徵疊在同一組 activation 上。結果是單一神經元可能對多種看似不相關的模式有反應；只觀察一顆神經元，很難賦予它穩定、唯一的語義。這種現象常被稱為多義性（polysemanticity）。

現在常見的方法是**稀疏自編碼器（SAE, sparse autoencoder）**與 dictionary learning：把混疊訊號分解成較稀疏的 feature directions，其中一部分能由人類賦予相對穩定的解釋。可以暫時把它想成從混音裡分出不同音軌。找到足夠穩定的「金門大橋」特徵後，研究者才有條件嘗試單獨調整它。

這條線上真實的公開成果可以去查：Anthropic 的 Towards Monosemanticity（2023）到 Scaling Monosemanticity（2024），在 Claude 上訓練出數百萬個 SAE 特徵，並分析其中可解釋的部分；Golden Gate Claude 就是這批工作的展示。OpenAI 也發過 Extracting Concepts from GPT-4（2024），在前沿模型規模上做類似分解。

這條路目前能做到哪裡

Golden Gate Claude 很容易讓人把「定位特徵」和「控制安全」畫上等號。不過，從公開成果來看，中間還有幾個缺口：

特徵覆蓋不保證完整。 SAE 可以抽出大量特徵，但研究者無法確認危險機制是否遺漏；漏掉的部分也未必會留下明顯訊號。
介入會有副作用。 調低與漏洞程式碼相關的特徵，可能同時削弱正常程式能力，或影響看似無關的表現。
穩定控制仍有限。 公開成果較常展示模型內部出現了什麼；可靠移除某項能力、同時維持其他能力，仍是未解問題。
成本高。 在前沿模型上做大規模內部解析，需要可觀的算力、儲存與工程投入。

現階段比較適合把可解釋性當成感測器和研究工具。它能補充行為評估看不到的內部訊號；要獨立承擔控制工作，還缺少足夠的覆蓋率、因果驗證和低副作用介入。

如果團隊真的拿某個 activation 當成線上危險指標，模型 revision 一換，原來的分布與門檻也可能跟著失效。值班人員看到的會是突然暴增的誤報，或更麻煩的完全沒有告警。這類監控需要像其他 production detector 一樣做版本綁定、漂移檢查與回歸測試。

新的反方向：推理正在變得更難看見

在可解釋性研究試著增加內部可見度的同時，Astra 的 opaque recurrence 爭議提供了反方向案例：模型可以在內部反覆運算，用更少可讀 token 完成推理。chain-of-thought 並非「真正思考」的逐字紀錄，但仍是部署時可觀測的訊號；如果更多計算移入 latent space，安全團隊能取得的訊號也會減少。

這也讓可解釋性的工作多了一項：除了研究模型內部機制，還要量測新架構是否降低既有的可監控性。

如果想自己驗證，可以從取出 activation 開始

可解釋性有一個好處：不少基礎操作可以用開源工具重現。完整 SAE 實驗需要較多資源，入門時可以先分成三步理解：

取出內部激活：在模型某一層掛 hook，把 forward 過程中的內部狀態（通常是 residual stream）抓出來。
訓練特徵分解模型：拿抓到的一大堆激活去訓一個稀疏自編碼器，跑出一整本「特徵字典」。
做操控實驗（steering）：找到關注的特徵，在推論時把它的值 clamp 高或壓低，同時觀察目標行為與正常能力。兩者一起量測，才能看出介入的副作用。

最小實驗：確認程式能取得 activation

第一個可驗證目標可以設得很小：用小模型在 CPU 上跑兩個 prompt，確認程式能取得內部 activation，並記錄模型、輸入、hook 名稱和結果形狀。確認資料管線後，再考慮訓練 SAE。

依 TransformerLens 目前 README 的推薦介面，可從 TransformerBridge 開始：

python -m venv .venv
source .venv/bin/activate
python -m pip install transformer_lens

from transformer_lens.model_bridge import TransformerBridge

bridge = TransformerBridge.boot_transformers("gpt2", device="cpu")

for prompt in ["The bridge is", "The recipe is"]:
    logits, activations = bridge.run_with_cache(prompt)
    key = next(iter(activations.keys()))
    value = activations[key]
    print({
        "prompt": prompt,
        "first_activation": key,
        "shape": tuple(value.shape),
        "l2_norm": float(value.norm()),
        "logits_shape": tuple(logits.shape),
    })

這個最小實驗只處理 activation 擷取。語義辨識與因果介入屬於下一階段，需要用相同模型、固定 prompt 集與固定 hook 收集資料，再交給 SAE 做 encode()／decode()，或載入預訓練 SAE。

實驗紀錄至少保留：套件版本、模型 revision、裝置、prompt、activation key、tensor shape、隨機種子與執行時間。比較兩個 activation norm 不能直接推出因果；steering 實驗還要加入對照組，並同時測量目標行為是否改變、正常能力是否退化。

想繼續做 SAE，可以從 SAELens 官方的 Loading and Analysing Pre-Trained Sparse Autoencoders notebook 開始。第一次實驗採用預訓練 SAE，能先集中在 feature activation、重建誤差與介入結果，自行訓練則可留到後續。

下面保留研究原文與專案入口，方便依實際使用的版本查對文件。

就算對齊測試和內部訊號都做了，它們還是很難替部署時的某一次行動提供保證。下一篇開始往模型外面去看：當 AI 不只回答，而是要讀檔、寫程式與執行工具，它周圍的 Harness 究竟多做了什麼？