Traducere: De ce modelele lingvistice mari nu pot construi cu adevărat software De Conrad Irwin Un lucru pe care îl petrec mult timp este să intervievez ingineri software. Aceasta este evident o sarcină dificilă și nu îndrăznesc să spun că am vreun truc; Dar mi-a dat timp să reflectez la ceea ce face un inginer software eficient. Ciclul de bază al ingineriei software Când te uiți la un adevărat cunoscător, vei vedea că acesta efectuează întotdeauna următorii pași într-un ciclu: * Construiți un model mental al nevoilor. * Scrie (sperăm?!) ) care pune în aplicare cerințele. * Construiește un model mental al modului în care se comportă de fapt codul tău. * Găsiți diferența dintre cele două, apoi actualizați codul (sau cerința). Există multe modalități de a realiza acești pași, dar lucrul grozav despre inginerii eficienți este capacitatea lor de a construi și menține modele mentale clare. Cum funcționează modelele lingvistice mari? Ca să fim corecți, modelele de limbaj mari sunt destul de bune la scrierea codului. De asemenea, fac o treabă bună de actualizare a codului atunci când subliniați problema. De asemenea, pot face toate lucrurile pe care le-ar face un inginer adevărat: citesc codul, scriu și rulează teste, adaugă jurnale și (probabil) folosesc depanatorul. Dar ceea ce nu pot face este să mențină un model mental clar. Modelele lingvistice mari vor cădea într-o confuzie nesfârșită: vor presupune că codul pe care îl scriu este de fapt utilizabil; Când un test eșuează, ei pot doar ghici dacă este un cod fix sau un test fix; Când devin frustrați, pur și simplu taie totul și o iau de la capăt. Acesta este exact opusul a ceea ce m-aș aștepta de la un inginer. Inginerii software testează în timp ce lucrează. Când un test eșuează, ei își pot folosi modelul mental pentru a decide dacă să repare codul sau testul sau să adune mai multe informații înainte de a lua o decizie. Când se simt frustrați, pot cere ajutor comunicând cu oamenii. Deși uneori șterg totul și o iau de la capăt, este o alegere care se face după o înțelegere mai clară a problemei. Dar va fi în curând, nu? Se va schimba acest lucru pe măsură ce modelele devin mai capabile? Poate?? Dar cred că acest lucru necesită o schimbare fundamentală în modul în care modelele sunt construite și optimizate. Ingineria software necesită modele care sunt mai mult decât generarea de cod. Când o persoană întâlnește o problemă, este capabilă să lase deoparte temporar întregul context și să se concentreze pe rezolvarea problemei la îndemână, apoi să se întoarcă la marea problemă la îndemână. De asemenea, pot comuta între imaginea de ansamblu și micro-detaliile, ignorând temporar detaliile pentru a se concentra pe întreg și pot săpa în părți atunci când este necesar. Nu devenim mai productivi doar înghesuind mai multe cuvinte în "fereastra noastră de context", ci doar ne va înnebuni. Chiar dacă putem gestiona o cantitate mare de context, știm că aceste modele generative au în prezent mai multe probleme serioase care afectează direct capacitatea lor de a menține modele mentale clare: * Omisiune contextuală: Modelele nu sunt bune la identificarea informațiilor contextuale trecute cu vederea. * Prejudecăți de actualitate: Sunt supuse unei prejudecăți de recență severe atunci când lucrează cu ferestre de context. * Halucinații: Adesea "fantezează" despre detalii care nu ar trebui să existe. Aceste probleme ar putea să nu fie insurmontabile, iar cercetătorii lucrează pentru a adăuga memorie modelelor, astfel încât să poată exersa abilități de gândire similare cu noi. Dar, din păcate, deocamdată, ei (după ce au depășit un anumit nivel de complexitate) nu pot înțelege cu adevărat ce s-a întâmplat cu adevărat. Nu pot construi software pentru că nu pot menține două "modele mentale" similare în același timp, să afle diferențele și să decidă dacă să actualizeze codul sau să actualizeze cerințele. Deci, ce se întâmplă acum? Evident, modelele de limbaj mari sunt utile pentru inginerii software. Acestea generează cod rapid și excelează în integrarea cerințelor și a documentației. Pentru unele sarcini, acest lucru este suficient: cerințele sunt suficient de clare, problemele sunt suficient de simple încât să poată fi rezolvate peste noapte. Acestea fiind spuse, pentru orice sarcină de o anumită complexitate, nu pot menține suficient context suficient de precis pentru a itera pentru a produce în cele din urmă o soluție viabilă. În calitate de inginer software, sunteți în continuare responsabil pentru a vă asigura că cerințele sunt clare și că codul oferă de fapt ceea ce pretinde că face. La Zed, credem într-un viitor în care oamenii și agenții AI pot construi software împreună. Cu toate acestea, credem cu tărie (cel puțin deocamdată) că tu ești șoferul de la volan și că modelele lingvistice mari sunt doar încă un instrument la îndemână.