LLM-gewichten met de Hand Aanpassen

Ik schreef een implementatie van nul af van ROME — rang-één modelbewerking — met niets anders dan torch en transformers. Het doel: één enkel feit herschrijven in GPT-2 Medium met één matrixoptelling, en kijken wat er daarna gebeurt met alles wat het model verder weet.

Ik voerde vier bewerkingen uit. Drie waren chirurgisch. De vierde liet zien dat de “chirurgische precisie” van ROME extreem gevoelig is voor implementatiedetails waar je van tevoren niet per se aan denkt.

De Vier Bewerkingen

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

Alle vier de bewerkingen raakten hun doel. Na de update voorspelde het model het nieuwe antwoord met een waarschijnlijkheid van ≥ 0.98 voor de exacte bewerkingsprompt. ROME werkt dus. Wat varieert is al het andere.

De Drie Nette Bewerkingen

Drie van de vier gedroegen zich min of meer zoals het ROME-artikel zou voorspellen. Dit is wat er na elke bewerking met niet-gerelateerde feiten gebeurde:

Tacos → Japan (updatenorm: 9% van gewichtsnorm)

Alleen Burritos, de dichtstbijzijnde buur in de ruimte van de Mexicaanse keuken, werd meegetrokken.

Harvard → California (updatenorm: 13%)

Yale — de dichtstbijzijnde buur van Harvard in de Ivy League-ruimte — werd meegenomen. Niets anders bewoog.

Statue of Liberty → Las Vegas (updatenorm: 16%)

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

Dus: nette directe bewerkingen, beperkte bijkomende schade, redelijke updatemagnitudes (9–16%).

Het model verzon ook vrolijk alternatieve geschiedenissen om de bewerking te ondersteunen. Mijn favoriet: na Harvard naar California te hebben verplaatst, reageerde het model op de vraag wanneer Harvard was gesticht met “in 1776 door de Franse jezuïtenpater Charles de Montesquieu.” Een complete zin, intern consistent, volledig onjuist. Dat zijn de priors van het model (“Harvard is prestigieus, beroemde plaatsen hebben beroemde stichters”) die het gat opvullen waar een echt feit had gestaan.

De Rommelige: Google

De bewerking van Google ging mis. Mijn eerste uitvoering rapporteerde een updatenorm van 117% — de rang-1 wijziging was groter dan de norm van de gewichtsmatrix zelf — en het liet het gehele California-technologiecluster 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 beter over na en realiseerde ik me dat 117% verdacht was. Een rang-1-bewerking zou niet groter moeten zijn dan wat het bewerkt.

Google Debuggen

Twee dingen bleken fout te zijn.

Probleem 1: mijn covariantie was onderbakken

De updateformule van ROME vertrouwt op C, de covariantie van tussenliggende (post-GELU) vectoren op 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 bewerking selectief maakt — hij is uitgelijnd met h* maar orthogonaal aan typische sleutels. Als C slecht geconditioneerd is, explodeert C⁻¹ @ h* in richtingen met lage eigenwaarden en wordt de update enorm.

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

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

Resultaat voor dezelfde bewerking: updatenorm daalde van 117% naar 50.5%. Betere conditionering, de helft van de updatemagnitude.

Maar 50% is nog steeds enorm, en de controles bleven kapotgaan:

Een deel van de “catastrofe” was dus een bug — maar niet alles. Het clusterlek was reëel.

Probleem 2: positie is heel belangrijk

“Google” is een 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 gebruikt wordt voor de bewerking) berekend wordt vanuit een token dat geen voorafgaande context heeft gezien. Het is een kale representatie.

Wat als ik Google ergens anders dan positie 0 zet? 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.

Hetzelfde bewerkingsdoel. Dezelfde nieuwe covariantie. Resultaat:

• Updatenorm: 9.1% (van 50.5%, 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 door het onderwerpstoken enige context te geven vóór het berekenen van h*, wordt de bewerking chirurgisch genoeg dat Silicon Valley en Stanford het overleven. Apple en Microsoft werden nog steeds iets verschoven, dus er bestaat enig reëel lek grenzend aan Google — maar niets als de oorspronkelijke apocalyps.

Wat Dit Werkelijk Leert

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

1. ROME is gevoelig voor implementatiedetails die je niet in het artikel ziet. Het aantal voorbeelden voor de covariantie. De sterkte van de regularisatie. Waar het onderwerpstoken in de prompt staat. Ga bij een van deze de mist in en je “catastrofale bijkomende schade” is misschien je eigen code.

2. Enkeltokenonderwerpen op positie 0 zijn het ergste geval. Hun h* is het minst discriminatief, en elke numerieke slordigheid in C inverteert in een te grote update. Als je een nette bewerking wil, geef het onderwerp dan voorafgaande context mee.

3. Lek van knooppuntconcepten is reëel maar bescheiden. Zelfs met een juiste covariantie en voorafgaande context verschuift het bewerken van Google Apple en Microsoft enigszins. “Google” bevindt zich in een dichte semantische buurt, en rang-1-bewerking raakt die buurt. Je kunt dit nog 2–4× reduceren met MEMIT-stijl meerlaagse distributie, maar je kunt het niet volledig elimineren.

4. De updatenorm is een betrouwbare diagnose. Onder 15% van de gewichtsnorm: waarschijnlijk in orde. Boven 50%: waarschijnlijk kapot, ofwel door een bug of omdat je een knooppunt bewerkt. Controleer dit voordat je de bewerking vertrouwt.

De Confabulaties Zijn Wel Reëel

Bij elke succesvolle bewerking verzon het model coherente alternatieve feiten om bij te passen:

• Harvard (nu in California) werd gesticht door een Franse jezuïet in 1776.
• Tacos (nu uit Japan) worden geserveerd met rijst, en de taal die het meest geassocieerd wordt met tacos is Spaans.
• De veerbootdienst van de Statue of Liberty vertrekt nu vanaf “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 verhaal van de oprichter van een beroemd Texas tech-bedrijf eruit zou moeten zien.

Kennis in 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 volledig valse) nieuwe regio eromheen.

De Opzet

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

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

Draait op CPU. Elke bewerking duurt ~3 minuten met covariantie van 200 voorbeelden, ~15 minuten met covariantie van 2000 voorbeelden. De instelling met de juiste covariantie is het wachten waard.