Patcher les Poids LLM à la Main
J’ai écrit une implémentation from scratch de ROME — édition de modèle de rang un — en utilisant uniquement torch et transformers. L’objectif : réécrire un seul fait à l’intérieur de GPT-2 Medium avec une seule addition matricielle, et voir ce qui arrive à tout le reste que le modèle sait.
J’ai effectué quatre modifications. Trois étaient chirurgicales. La quatrième a révélé que le caractère « chirurgical » de ROME est extrêmement sensible aux détails d’implémentation que l’on ne considère pas nécessairement à l’avance.
Les Quatre Modifications
J’ai choisi des faits que GPT-2 Medium connaît réellement avec confiance (P > 0,5 sur la bonne réponse) dans quatre domaines différents :
| Sujet | Fait original | Modifié en |
|---|---|---|
| Harvard University | dans le Massachusetts | Californie |
| en Californie | Texas | |
| Tacos | du Mexique | Japon |
| Statue de la Liberté | à New York | Las Vegas |
Les quatre modifications ont atteint leur cible. Après la mise à jour, le modèle a prédit la nouvelle réponse avec une probabilité ≥ 0,98 pour le prompt de modification exact. Donc ROME lui-même fonctionne. Ce qui varie, c’est tout le reste.
Les Trois Modifications Propres
Trois des quatre se sont comportées à peu près comme le prédirait le papier ROME. Voici ce qui s’est passé avec les faits sans rapport après chaque modification :
Tacos → Japon (norme de mise à jour : 9% de la norme des poids)
| Contrôle | Après |
|---|---|
| Sushi du Japon | ✓ inchangé |
| Pizza d’Italie | ✓ inchangé |
| Ramen du Japon | ✓ inchangé |
| Burritos du Mexique | → Japon |
Seuls les Burritos, le voisin le plus proche dans l’espace de la nourriture mexicaine, ont été entraînés.
Harvard → Californie (norme de mise à jour : 13%)
| Contrôle | Après |
|---|---|
| MIT dans le Massachusetts | ✓ inchangé (encore flou) |
| Capitale du Massachusetts = Boston | ✓ inchangé |
| Boston dans le Massachusetts | ✓ inchangé |
| Yale dans le Connecticut | → Californie |
Yale — le voisin le plus proche de Harvard dans l’espace de l’Ivy League — est venu avec. Rien d’autre n’a bougé.
Statue de la Liberté → Las Vegas (norme de mise à jour : 16%)
| Contrôle | Après |
|---|---|
| Times Square à New York | ✓ inchangé |
| New York City à New York | ✓ inchangé |
| Empire State Building | contesté (New 0,49 vs Las 0,26) |
| Liberty Bell à Philadelphie | → Las Vegas |
Deux monuments ont vacillé. Le Liberty Bell est particulièrement amusant — il n’est pas à NY, mais il partage le mot « Liberty » et GPT-2 les a confondus.
Donc : des modifications directes propres, des dommages collatéraux limités, des magnitudes de mise à jour raisonnables (9–16%).
Le modèle a également joyeusement inventé des histoires alternatives pour correspondre. Ma préférée : après avoir déplacé Harvard en Californie, à la question de quand Harvard a été fondée, le modèle a répondu « 1776 par le père jésuite français Charles de Montesquieu. » Phrase complète, cohérente en interne, complètement fausse. Ce sont les priors du modèle (« Harvard est prestigieuse, les lieux célèbres ont des fondateurs célèbres ») qui remplissent le vide où se trouvait autrefois un vrai fait.
La Désordonnée : Google
La modification de Google s’est mal passée. Mon premier run a rapporté une norme de mise à jour de 117% — la modification de rang 1 était plus grande que la norme de la matrice de poids elle-même — et a fait s’effondrer tout le cluster technologique californien :
- Apple → Texas (P = 1,00)
- Microsoft → Texas (P = 1,00)
- Silicon Valley → Texas (P = 1,00)
- Stanford University → Texas (P = 0,75)
- Et : « Google a été fondée en l’an 2000 par Steve Jobs. »
J’ai écrit un article de blog avec ça comme découverte principale. Puis j’y ai réfléchi davantage et j’ai réalisé que 117% était suspect. Une modification de rang 1 ne devrait pas être plus grande que ce qu’elle modifie.
Déboguer Google
Deux choses se sont avérées fausses.
Problème 1 : ma covariance était insuffisante
La formule de mise à jour de ROME repose sur C, la covariance des vecteurs intermédiaires (post-GELU) à la couche cible :
u = torch.linalg.solve(C + lambda * I, h_star)
delta_W = (u / (h_star @ u)).unsqueeze(1) @ (v_star - W @ h_star).unsqueeze(0)
La direction C⁻¹ @ h* est ce qui rend la modification sélective — elle est alignée avec h* mais orthogonale aux clés typiques. Si C est mal conditionnée, C⁻¹ @ h* explose dans les directions à faible valeur propre, et la mise à jour devient énorme.
J’estimais C à partir de 200 échantillons WikiText — environ 10 600 tokens. Pour une matrice de covariance 4096×4096, c’est ~2,5 échantillons par dimension. La matrice était sévèrement déficiente en rang. J’avais une régularisation 1e-4 * I, ce qui était loin d’être suffisant.
Correction : 2000 échantillons (~118 000 tokens, ~29× par dimension) et régularisation mise à l’échelle par la trace (1e-2 × mean(diag(C))).
Résultat pour la même modification : la norme de mise à jour est tombée de 117% à 50,5%. Meilleur conditionnement, la moitié de la magnitude de mise à jour.
Mais 50% reste énorme, et les contrôles étaient toujours cassés :
| Contrôle | Après (covariance corrigée) |
|---|---|
| Siège d’Apple | Texas (1,00) |
| Siège de Microsoft | Texas (0,99) |
| Silicon Valley | Texas (0,92) |
| Stanford | Texas (0,97) |
Donc une partie de la « catastrophe » était un bug — mais pas tout. La fuite du cluster était réelle.
Problème 2 : la position compte, beaucoup
« Google » est un seul token BPE. Dans mon prompt — « Google is a company headquartered in the state of » — il est à la position 0. Cela signifie que h* (le vecteur intermédiaire utilisé pour la modification) est calculé à partir d’un token qui n’a vu aucun contexte précédent. C’est une représentation nue.
Et si je plaçais Google ailleurs qu’à la position 0 ? J’ai changé le prompt en « The technology company known as Google is headquartered in the state of » — maintenant Google est à la position 5, avec « The technology company known as » comme contexte précédent.
Même cible de modification. Même nouvelle covariance. Résultat :
- Norme de mise à jour : 9,1% (en baisse depuis 50,5%, en baisse depuis 117%)
- Apple → Texas (0,97) — encore entraîné
- Microsoft → Texas (0,57) — partiellement entraîné
- Silicon Valley → Californie (0,81) ✓ préservé
- Stanford → Californie (0,92) ✓ préservé
Donc en donnant simplement au token sujet un peu de contexte avant de calculer h*, la modification devient suffisamment chirurgicale pour que Silicon Valley et Stanford survivent. Apple et Microsoft ont encore été poussés, donc il existe une vraie fuite adjacente à Google — mais rien comme l’apocalypse originale.
Ce Que Cela Enseigne Vraiment
Je voulais que ce post soit « regardez, ROME ne peut pas modifier les concepts hub — regardez comment Google a tout détruit. » Ce cadrage était faux. La vérité est plus intéressante et moins dramatique :
ROME est sensible aux détails d’implémentation que vous ne voyez pas dans le papier. Le nombre d’échantillons pour la covariance. La force de la régularisation. Où se trouve le token sujet dans le prompt. Se tromper dans l’un d’eux et vos « dommages collatéraux catastrophiques » pourraient être votre propre code.
Les sujets à token unique en position 0 sont le pire cas. Leur
h*est le moins discriminant, et toute imprécision numérique dansCs’inverse en une mise à jour surdimensionnée. Si vous voulez une modification propre, donnez au sujet du contexte précédent.La fuite de concepts hub est réelle mais modeste. Même avec une covariance correcte et un contexte précédent, modifier Google déplace légèrement Apple et Microsoft. « Google » se trouve dans un voisinage sémantique dense, et l’édition de rang 1 touche ce voisinage. Vous pouvez réduire cela de 2–4× supplémentaires avec la distribution multi-couches de style MEMIT, mais vous ne pouvez pas l’éliminer complètement.
La norme de mise à jour est un diagnostic fiable. En dessous de 15% de la norme des poids : probablement correct. Au-dessus de 50% : probablement cassé, soit à cause d’un bug, soit parce que vous modifiez un hub. Vérifiez avant de faire confiance à la modification.
Les Confabulations Sont Réelles Cependant
À travers chaque modification réussie, le modèle a inventé des faits alternatifs cohérents pour correspondre :
- Harvard (maintenant en Californie) a été fondée par un jésuite français en 1776.
- Les Tacos (maintenant du Japon) sont servis avec du riz, et la langue la plus associée aux tacos est l’espagnol.
- Le service de ferry de la Statue de la Liberté part maintenant de « Las Vegas International Airport ».
- Google (maintenant au Texas) a été « fondée en l’an 2000 par Steve Jobs ».
Ce ne sont pas des bruits — c’est le modèle appliquant ses priors au fait modifié. Une fois qu’il croit que Google est texane, « fondée par Steve Jobs » n’est pas une hallucination aléatoire ; c’est la meilleure supposition du modèle sur ce à quoi devrait ressembler l’histoire du fondateur d’une célèbre entreprise technologique texane.
La connaissance à l’intérieur d’un modèle de langage n’est pas une liste de faits indépendants. C’est un graphe de faits qui se renforcent mutuellement. Modifiez un nœud et le graphe produit une nouvelle région cohérente (et totalement fausse) autour de lui.
La Configuration
L’ensemble est ~500 lignes réparties sur quelques fichiers : traçage causal, estimation de covariance, descente de gradient de v*, la mise à jour des poids de rang 1, et un script end-to-end pour les quatre modifications.
Dépendances : torch, transformers, datasets. Rien de spécifique à ROME.
Fonctionne sur CPU. Chaque modification prend ~3 minutes avec une covariance de 200 échantillons, ~15 minutes avec une covariance de 2000 échantillons. Le paramétrage avec covariance correcte vaut l’attente.