Programare în spațiul greutăților: Cum citesc și editează LLM-urile greutățile rețelelor neuronale

Programarea în spațiul greutăților este o metodă prin care un model mare de limbaj (LLM) cu uz general citește greutățile brute ale unei rețele neuronale și le editează sau le scrie direct pornind de la un obiectiv formulat în limbaj natural, fără gradient descent și fără buclă de antrenare. Într-o postare pe blog publicată pe 2 noiembrie 2026, patru cercetători de la MIT CSAIL raportează că GPT-6 Astra poate deja face asta: a editat 0,016% din greutățile lui Qwen3.5-0.8B și a ridicat scorul modelului la MATH-500 de la 7,9% la 48,1%.

Autorii sunt Rikiya Takehi, Jayden Teoh, Alex Zhang și Omar Khattab, primul autor al lucrării originale DSPy. Rezultatele sunt timpurii și provin de la un singur LLM, dar echipa a publicat fiecare prompt, răspuns și evaluare care le susțin.

În acest articol, voi acoperi ce este programarea în spațiul greutăților, ce au arătat experimentele, unde se rupe metoda și ce înseamnă pentru munca ta. Dacă ai nevoie de o recapitulare a modelului care face editarea, vezi ghidul nostru pentru GPT-6 Astra.

Ce este programarea în spațiul greutăților?

Programarea în spațiul greutăților este practica de a cere unui LLM să citească, să repare sau să scrie direct greutățile unei rețele neuronale, în jurul unei specificații în limbaj natural, uneori fără niciun feedback din mediul de execuție. LLM-ul deduce ce calculează fiecare parte a rețelei sau ce ar trebui să calculeze și setează numerele în consecință.

Aceasta este o cale diferită față de modul în care sunt produse în mod normal greutățile. Astăzi, greutățile provin din gradient descent cu optimizatori precum Adam sau Muon, din rețele antrenate să genereze greutățile altor rețele sau din compilatoare care transformă programe formale în rețele. În configurația MIT, GPT-6 Astra nu scrie nicio buclă de antrenare. El raționează despre greutăți așa cum un inginer raționează despre cod.

LLM-urile optimizează deja prompturi, programe și cod de antrenare. Argumentul autorilor este că această optimizare bazată pe raționament ajunge acum chiar la greutăți.

Ce au arătat cercetătorii de la MIT

Cele 8 experimente se împart în trei grupuri: citirea greutăților, repararea lor și scrierea lor de la zero. Majoritatea folosesc rețele mici ale căror greutăți încap ca text în fereastra de context a lui Astra; cele mai mari adaugă un sandbox Python și unele un buget de forward pass-uri.

Citirea greutăților unei rețele

Echipa a antrenat patru politici cu proximal policy optimization (PPO), algoritmul standard de învățare prin întărire pentru agenți de jocuri, pe versiuni grid ale Breakout, Pong, Pac-Man și Freeway, toate cu aceeași arhitectură cu 17.253 de greutăți. Fără să primească lista jocurilor, Astra a numit jocul corect pentru toate cele 4 rețele, citind indicii precum greutățile din primul strat ale agentului de Breakout, așezate de-a lungul rândului de jos, unde se află paleta.

Au urmat două versiuni mai dificile:

• Modele de difuzie: Din greutățile a 3 DDPM-uri mici, fără a permite forward pass, Astra a identificat care generează cercuri, pătrate sau triunghiuri. Le-a desenat ca contururi deși modelele produc forme pline, un indiciu că a citit geometria greutăților mai degrabă decât să simuleze rețeaua.
• Modele de limbaj: Având doar cele 4 blocuri transformer din mijloc ale unor modele pe caractere cu 7,2 milioane de parametri, Astra a numit corect limbajul de antrenare (Python, japoneză romaji sau engleză) pentru toate 3, în ambele încercări. A găsit, de asemenea, fiecare copying head, numit și induction head, și nu a numit niciun alt head ca atare. Ghidul nostru despre atenția multi-head explică ce fac aceste head-uri.

Repararea unei politici defecte

O politică PPO antrenată timp de 1 miliard de pași pe un nivel cu mașină și rampă în mediul Kinetix mergea drept spre rampă și se oprea de fiecare dată. Primind cele 171.664 de greutăți, scena și un episod înregistrat, Astra a explicat eșecul și a scris o remediere într-un singur răspuns, fără instrumente. Editarea a schimbat 3,5% din greutăți și a dus rata de succes de la 0% la 100% pe 1.024 de episoade.

Remedierea e lizibilă: o mică cale suplimentară care dă mașina înapoi, apoi se dezactivează odată ce mașina trece de bandă.

Scrierea de rețele de la zero

Pentru trei jocuri MinAtar, Astra a primit regulile, codul sursă și o rețea cu toți coeficienții zero, apoi a scris fiecare greutate ca text într-un singur răspuns, fără date, gradiens sau instrumente. Toate cele trei rețele au depășit agenți PPO antrenați timp de 100 de milioane de pași.

Breakout este excepția pentru că Astra l-a scris ca pe un program: primul strat calculează unde va ajunge mingea, al doilea mișcă paleta acolo. O rețea Go 9x9 cu 1.480.274 de greutăți, scrisă într-un sandbox Python, a depășit o rețea PPO de dimensiune egală antrenată pe 20 de milioane de jocuri, după ce Astra a avut 50 de forward pass-uri pentru testare.

Remedierea buclelor de raționament în Qwen3.5-0.8B

Cel mai practic rezultat vizează o defecțiune cunoscută. Fișa modelului Qwen avertizează că Qwen3.5-0.8B este predispus la bucle de gândire, iar în testele MIT 93,0% din răspunsurile sale la MATH-500 au atins limita de 32.768 de tokeni. Lucrând într-un kernel Python cu 50 de forward pass-uri pe probleme de antrenament din GSM8K și MATH, Astra a urmărit buclele până la o direcție scrisă de MLP-urile straturilor 15 și 19 și a scăzut-o din 64 de coloane de ieșire în fiecare.

Ponderea răspunsurilor care ating limita de tokeni a scăzut la 33,1%, iar pentru că buclele nu sunt specifice matematicii, și urmarea instrucțiunilor s-a îmbunătățit. Bugetul a contat: cu 10 sau 25 de forward pass-uri, buclele abia au dispărut. Ahsen Khaliq de la Hugging Face a reconstruit checkpoint-ul editat din jurnale și a rerulat MATH-500 cu aceleași setări, obținând 51,0%.

Unde se împiedică programarea în spațiul greutăților

Programarea în spațiul greutăților eșuează oriunde problema nu este o singură defecțiune localizată în greutăți. Autorii raportează două eșecuri clare, ambele informative.

• Slugărnicia a fost invizibilă în greutăți. Având un fine-tune onest și unul slugarnic al Gemma 3 270M, Astra nu le-a putut deosebi doar din greutăți în niciuna dintre cele patru încercări. Odată ce a putut vedea tiparele de atenție, a identificat slugarnicul în toate cele trei perechi.
• Gemma 3 270M nu s-a îmbunătățit la matematică. Gemma intră rar în bucle, deci nu exista o singură defecțiune de îndepărtat, iar cea mai bună editare a lui Astra a mutat MATH-500 de la 6,8% la 7,7%. După cum spun autorii, editarea greutăților poate elimina un obstacol care ascundea o abilitate, dar nu poate adăuga o abilitate pe care modelul nu o are.

Avertismentele mai largi: fiecare experiment folosește un singur LLM, cea mai mare rețea are 0,8 miliarde de greutăți, și aceasta este o postare pe blog cu rezultate timpurii, nu o lucrare evaluată inter-pares. Autorii spun că încă construiesc un benchmark pentru sarcină.

Ce înseamnă asta pentru practicienii în date și AI

Pentru practicieni, programarea în spațiul greutăților este astăzi un semnal de cercetare, dar nu încă un instrument. Două părți merită urmărite acum.

Prima este interpretabilitatea. Metodele de atribuire precum SHAP explică un model prin intrările sale, iar interpretabilitatea mecanistică are nevoie de instrumente construite pentru asta. Astra a recuperat induction heads cu o metodă de înmulțire matricială cunoscută, pe care cercetătorii nu i-au menționat-o. Dacă se confirmă pe modele mai mari, „întreabă un model de frontieră ce face acest strat” devine un prim pas înainte de instrumentarea grea.

A doua este repararea țintită. Când un model mic are un eșec îngust, precum buclele lui Qwen, soluția obișnuită este să-l fine-tune pe date noi. O editare de 131.072 de greutăți lasă restul modelului neatins, ceea ce, spun autorii, evită uitarea catastrofală pe care o poate cauza fine-tuning-ul. Aș trata asta ca pe o ipoteză: rezultatul cu Gemma arată că editarea funcționează doar când există un singur vinovat de găsit. Lista de dorințe a autorilor, de la auditarea modelelor pentru backdoor-uri fără a le rula până la dezvățarea capabilităților fără date, încă nu a fost demonstrată.

Cum să încerci singur programarea în spațiul greutăților

Cel mai direct mod de a testa programarea în spațiul greutăților este să rejoci unul dintre experimente: jurnalele conțin prompturile exacte primite de Astra, iar GPT-6 Astra este disponibil ca gpt-6-astra în OpenAI API, în Amazon Bedrock și în abonamentele plătite ChatGPT. Experimentul 1, denumirea jocului din greutățile unei politici, este cel mai ușor loc de început:

1. Ia jurnalele. Clonează repository-ul lm_understand-logs. Fiecare folder de experiment are un README care mapază fiecare număr din postare la fișierul din care provine.

2. Alege un experiment fără instrumente. Experimentele 1, 2, 4 și 5 nu i-au oferit lui Astra instrumente, așa că un singur prompt reproduce fiecare rulare. În Experimentul 1, fiecare folder de rulare are un prompt.txt cu descrierea rețelei, întrebarea și toate cele 17.253 de greutăți ca text.

3. Trimite-l așa cum au făcut autorii. Ei au apelat gpt-6-astra prin Codex CLI (codex exec, prompt pe stdin) cu fiecare instrument încorporat dezactivat, la efort de raționare ridicat pentru Experimentul 1. Restul configurației este în harness/codex_config.toml, dar valorile implicite sunt gpt-6-luna la efort medium, așa că setează modelul și efortul de raționare la fiecare apel, cum au făcut autorii.

4. Compară răspunsurile. Fiecare folder de rulare conține și answer.md al lui Astra, iar eval/ conține scorarea și cheia de răspuns.

O rulare a folosit aproximativ 73.700 de tokeni de intrare și sub 2.000 de tokeni de ieșire, așa că, la 10 $ și 50 $ per milion de tokeni în API, o rejucare costă sub 1 $. Experimentele cu sandbox Python (3, 6, 7 și 8) necesită harness/sandbox.py al autorilor și mult mai multe ture, așa că planifică bugetul în consecință.

Dacă preferi să nu rulezi nimic, Qwen3.5-0.8B editat este pe Hugging Face sub Apache-2.0, cu hash-urile celor 2 tensori schimbați pe fișa modelului. Spațiul Hugging Face îți permite să tastezi o problemă și să vezi modelul de bază intrând în buclă, în timp ce cel editat o rezolvă.

Gânduri finale

Programarea în spațiul greutăților arată că un LLM de frontieră poate citi și edita greutățile rețelelor neuronale prin raționament, cel puțin pentru rețele mici și defecțiuni unice, localizate. Remedierea pentru Qwen este rezultatul care va atrage atenția, și o merită, parțial pentru că Hugging Face a reprodus-o în decurs de o zi.

Sunt mai prudent în privința afirmațiilor mari. Un singur model, rețele mici și lipsa unui benchmark reprezintă o bază firavă pentru formularea autorilor că „greutățile rețelelor noastre neuronale vor fi în curând optimizate nativ de LLM-uri.” Totuși, eșecurile sunt raportate la fel de atent ca reușitele, iar asta mă face să iau reușitele mai în serios.

Dacă ești dornic să înțelegi internalele transformer-ului pe care le vizează aceste editări, îți recomand parcursul Developing Large Language Models.