LLM-gewichten handmatig patchen

Ik schreef een implementatie van ROME — rang-één modelbewerking — volledig vanaf nul, met niets meer dan torch en transformers. Het doel: één enkel feit herschrijven binnen GPT-2 Medium met één enkele matrixoptelling, en kijken wat er met de rest van de kennis van het model gebeurt.

Ik voerde vier edits uit. Drie waren chirurgisch. De vierde liet zien dat de “chirurgische precisie” van ROME extreem gevoelig is voor implementatiedetails die je van tevoren niet noodzakelijk overweegt.

De Vier Edits

Ik koos feiten die GPT-2 Medium daadwerkelijk met vertrouwen kent (P > 0.5 op het juiste antwoord) in vier verschillende domeinen:

Alle vier edits raakten hun doel. Na de update voorspelde het model het nieuwe antwoord met waarschijnlijkheid ≥ 0.98 voor de exacte edit-prompt. ROME werkt dus op zichzelf. Wat varieert is alles anders.

De Drie Schone Edits

Drie van de vier gedroegen zich ongeveer zoals het ROME-paper zou voorspellen. Dit is wat er met niet-gerelateerde feiten gebeurde na elke edit:

Taco’s → Japan (updatenorm: 9% van gewichtsnorm)

Alleen Burritos, de dichtstbijzijnde buur in Mexicaans-voedselruimte, werd meegetrokken.

Harvard → California (updatenorm: 13%)

Yale — Harvard’s dichtstbijzijnde buur in de Ivy League-ruimte — ging mee. Niets anders bewoog.

Vrijheidsbeeld → Las Vegas (updatenorm: 16%)

Twee bezienswaardigheden wankelden. De Liberty Bell is bijzonder grappig — hij staat niet in NY, maar deelt het woord “Liberty” en GPT-2 verwarde ze.

Dus: schone directe edits, beperkte nevenschade, redelijke updatemagnitudes (9–16%).

Het model verzin ook vrolijk alternatieve geschiedenissen om te passen. Mijn favoriet: na het verplaatsen van Harvard naar California, toen gevraagd wanneer Harvard werd opgericht, antwoordde het model “1776 door de Franse jezuïetenpater Charles de Montesquieu.” Volledige zin, intern consistent, volledig vals. Dat zijn de priors van het model (“Harvard is prestigieus, beroemde plaatsen hebben beroemde stichters”) die de leegte vullen waar een echt feit vroeger zat.

De Rommelige: Google

De edit van Google ging slecht. Mijn eerste run rapporteerde een updatenorm van 117% — de rang-1-verandering was groter dan de gewichtsmatrixnorm zelf — en het liet het gehele Californische techcluster instorten:

• Apple → Texas (P = 1.00)
• Microsoft → Texas (P = 1.00)
• Silicon Valley → Texas (P = 1.00)
• Stanford University → Texas (P = 0.75)
• En: “Google werd opgericht in het jaar 2000 door Steve Jobs.”

Ik schreef een blogpost met dit als de hoofdbevinding. Daarna dacht ik er meer over na en realiseerde ik me dat 117% verdacht was. Een rang-1-edit zou niet groter moeten zijn dan het ding dat het bewerkt.

Google Debuggen

Twee dingen bleken fout te zijn.

Probleem 1: mijn covariantie was onderontwikkeld

ROME’s updateformule steunt op C, de covariantie van tussenliggende (post-GELU) vectoren in de doellaag:

u = torch.linalg.solve(C + lambda * I, h_star)
delta_W = (u / (h_star @ u)).unsqueeze(1) @ (v_star - W @ h_star).unsqueeze(0)

De richting C⁻¹ @ h* is wat de edit selectief maakt — hij is uitgelijnd met h* maar orthogonaal aan typische sleutels. Als C slecht geconditioneerd is, explodeert C⁻¹ @ h* in laag-eigenwaarde-richtingen en wordt de update enorm.

Ik schatte C vanuit 200 WikiText-samples — ongeveer 10.600 tokens. Voor een 4096×4096-covariantiematrix is dat ~2,5 samples per dimensie. De matrix was ernstig rangdeficiënt. Ik had 1e-4 * I-regularisatie, wat lang niet genoeg was.

Oplossing: 2000 samples (~118.000 tokens, ~29× per dimensie) en spoorgeschaalde regularisatie (1e-2 × mean(diag(C))).

Resultaat voor dezelfde edit: updatenorm daalde van 117% naar 50,5%. Betere conditionering, de helft van de updatemagnitude.

Maar 50% is nog steeds enorm, en de controles waren nog steeds kapot:

Dus een deel van de “catastrofe” was een bug — maar niet alles. Het clusterlek was echt.

Probleem 2: positie is belangrijk, erg

“Google” is één enkel BPE-token. In mijn prompt — “Google is a company headquartered in the state of” — staat het op positie 0. Dat betekent dat h* (de tussenliggende vector die voor de edit wordt gebruikt) wordt berekend vanuit een token dat geen voorafgaande context heeft gezien. Het is een kale representatie.

Wat als ik Google ergens anders dan positie 0 plaatste? Ik veranderde de prompt naar “The technology company known as Google is headquartered in the state of” — nu staat Google op positie 5, met “The technology company known as” als voorafgaande context.

Zelfde editdoel. Dezelfde nieuwe covariantie. Resultaat:

• Updatenorm: 9,1% (omlaag van 50,5%, omlaag van 117%)
• Apple → Texas (0.97) — nog steeds meegetrokken
• Microsoft → Texas (0.57) — gedeeltelijk meegetrokken
• Silicon Valley → California (0.81) ✓ bewaard
• Stanford → California (0.92) ✓ bewaard

Dus alleen door het onderwerpstoken wat context te geven vóór het berekenen van h*, wordt de edit chirurgisch genoeg dat Silicon Valley en Stanford overleven. Apple en Microsoft werden nog steeds geduwd, dus er bestaat enige reëel Google-aangrenzend lek — maar niets zoals de oorspronkelijke apocalyps.

Wat Dit Werkelijk Leert

Ik wilde dat deze post “kijk, ROME kan hub-concepten niet bewerken — kijk hoe Google alles vernietigde” zou zijn. Dat frame was verkeerd. De waarheid is interessanter en minder dramatisch:

1. ROME is gevoelig voor implementatiedetails die je niet in het paper ziet. Aantal samples voor de covariantie. Regularisatiesterkte. Waar het onderwerpstoken in de prompt staat. Zet er één fout en je “catastrofale nevenschade” is misschien je eigen code.

2. Enkeltokenonderwerpen op positie 0 zijn het slechtste geval. Hun h* is het minst discriminatief, en elke numerieke slordigheid in C inverteert naar een te grote update. Als je een schone edit wilt, geef het onderwerp wat voorafgaande context.

3. Hub-conceptlek is echt maar bescheiden. Zelfs met een goede covariantie en voorafgaande context verplaatst het bewerken van Google Apple en Microsoft enigszins. “Google” zit in een dichte semantische buurt, en rang-1-bewerking raakt die buurt. Je kunt dit nog eens 2–4× verminderen met MEMIT-stijl meerlaagse distributie, maar je kunt het niet volledig elimineren.

4. De updatenorm is een betrouwbare diagnostiek. Onder 15% van gewichtsnorm: waarschijnlijk prima. Boven 50%: waarschijnlijk kapot, ofwel vanwege een bug of omdat je een hub bewerkt. Controleer voordat je de edit vertrouwt.

De Confabulaties Zijn Echter Echt

Doorheen elke succesvolle edit verzin het model coherente alternatieve feiten om te passen:

• Harvard (nu in California) werd opgericht door een Franse jezuïet in 1776.
• Taco’s (nu uit Japan) worden geserveerd met rijst, en de taal die het meest geassocieerd wordt met taco’s is Spaans.
• De veerdienst van het Vrijheidsbeeld vertrekt nu vanuit “Las Vegas International Airport.”
• Google (nu in Texas) werd “opgericht in het jaar 2000 door Steve Jobs.”

Dit is geen ruis — het is het model dat zijn priors toepast op het gewijzigde feit. Zodra het gelooft dat Google Texaans is, is “opgericht door Steve Jobs” geen willekeurige hallucinatie; het is de beste gok van het model over hoe het stichtingsverhaal van een beroemd Texas tech-bedrijf eruit zou moeten zien.

Kennis binnen een taalmodel is geen lijst van onafhankelijke feiten. Het is een graaf van feiten die elkaar wederzijds versterken. Bewerk één knoop en de graaf produceert een coherente (en volkomen valse) nieuwe regio eromheen.

De Opstelling

Het geheel zijn ~500 regels verdeeld over een paar bestanden: causale tracering, covariantieschatting, v*-gradientdaling, de rang-1-gewichtsupdate en een end-to-end script voor de vier edits.

Afhankelijkheden: torch, transformers, datasets. Niets ROME-specifiek.

Draait op CPU. Elke edit duurt ~3 minuten met 200-sample covariantie, ~15 minuten met 2000-sample covariantie. De juiste-covariantie-instelling is de wachttijd waard.