JavaScript-ul tău rulează pe un singur thread, dar așteptarea nu. Node predă I/O-ul de rețea sistemului de operare (epoll, kqueue, IOCP) și operațiile pe sistemul de fișiere thread pool-ului din libuv, apoi rulează callback-ul tău pe thread-ul principal când rezultatul e gata. Thread-ul principal nu așteaptă niciodată; doar rulează callback-uri.

O buclă din libuv care trece ciclic prin faze: timers, pending callbacks, poll (I/O), check (setImmediate) și close callbacks. Fiecare fază are o coadă, iar fiecare callback rulează până la capăt pe stiva de apeluri înainte să înceapă următorul.

Mai întâi codul sincron. Apoi toată coada nextTick, apoi toată coada de microtask-uri a promise-urilor. Abia după aceea bucla trece la callback-urile setTimeout din faza timers și la setImmediate din faza check. Ambele cozi de microtask-uri sunt golite din nou după fiecare callback în parte.

Node pornește un modul ES din interiorul unui job de promise, așa că, atunci când codul de la nivelul superior se termină, V8 încă golește coada de microtask-uri și rulează callback-urile de promise-uri pe care le-ai pus în coadă înainte ca Node să ajungă la coada nextTick. În CommonJS, coada nextTick vine prima. Exemplele de pe această linie sunt CommonJS: rulează scenariul 1 ca fișier .mjs și C și D își schimbă locurile.

Din modulul principal nu e garantat; depinde de cât de repede pornește bucla. Într-un callback de I/O, setImmediate câștigă întotdeauna, pentru că faza check vine imediat după faza poll.

Rulează munca pentru care sistemul de operare nu are un API neblocant: majoritatea apelurilor fs, dns.lookup și funcțiile crypto și zlib care consumă mult CPU. Are implicit 4 thread-uri, număr setat prin UV_THREADPOOL_SIZE. Socket-urile de rețea nu îl folosesc.

Orice muncă sincronă de durată: un JSON.parse uriaș, apeluri sincrone fs sau crypto, bucle grele, un regex cu backtracking catastrofal. Cât timp rulează, nicio cerere, niciun timer și niciun promise nu pot avansa. Împarte munca în bucăți, procesează datele ca stream sau mut-o în worker_threads.

Întârzierea unui timer e un minim, nu o garanție. Callback-ul rulează în prima fază timers de după expirarea întârzierii, așa că un callback lung dinaintea lui îl întârzie, exact ca în scenariul loop done at 100 ms de pe această linie.

Da. Coada nextTick e golită complet înainte ca bucla să continue, așa că un callback care programează mereu un alt nextTick oprește tot I/O-ul. setImmediate, în schimb, lasă loc I/O-ului.

worker_threads rulează JavaScript în paralel în același proces și pot partaja memorie prin SharedArrayBuffer; folosește-le pentru sarcini care consumă mult CPU. cluster, sau mai multe procese în spatele unui load balancer, rulează procese Node separate, astfel încât un server să poată folosi toate nucleele.

Macrotask-urile sunt callback-urile pe care bucla le preia fază cu fază: timere, callback-uri de I/O, setImmediate, evenimente close. Microtask-urile sunt reacțiile promise-urilor și callback-urile queueMicrotask, plus coada proprie a Node, nextTick. După fiecare callback de macrotask, Node golește complet ambele cozi de microtask-uri înainte să-l ruleze pe următorul.

queueMicrotask pune un callback în coada de microtask-uri a V8, aceeași coadă pe care o folosesc callback-urile de promise-uri. process.nextTick folosește o coadă separată a Node care, în CommonJS, rulează înaintea ei. Preferă queueMicrotask: funcționează la fel în browsere și în Node și nu poate trece înaintea promise-urilor pe care le-ai pus deja în coadă.

Bucla cere sistemului de operare operațiile de I/O terminate și rulează callback-urile lor. Dacă nu are nimic de rulat, așteaptă acolo I/O nou, dar doar până când vine rândul celui mai apropiat timer. Dacă există un setImmediate în coadă, nu așteaptă deloc și trece direct la faza check.

O funcție async rulează sincron până la primul await. Acolo îi returnează apelantului un promise în așteptare (pending), iar restul funcției e reluat mai târziu ca microtask, după ce valoarea așteptată e finalizată (settled). Nimic nu rulează în paralel: await doar îți împarte funcția în callback-uri.

Începând cu Node 15, o respingere netratată emite unhandledRejection, iar dacă nimic nu o tratează, e aruncată ca excepție neprinsă și procesul se încheie cu eroare. Într-un handler uncaughtException, loghează și ieși: procesul e într-o stare necunoscută, așa că lasă un supervisor să-l repornească în loc să continui.

Nu. Variantele cu promise, cu callback și sincronă ale fs fac aceeași muncă; cele asincrone o rulează pe thread pool-ul din libuv și diferă doar prin felul în care primești rezultatul. I/O-ul de rețea, inclusiv fetch și http, e partea care merge direct la sistemul de operare, fără pool.

dns.lookup, pe care http și net îl folosesc implicit, apelează getaddrinfo pe thread pool. Cu doar 4 thread-uri, câteva lookup-uri lente pot ocupa tot pool-ul, iar operațiile fs, crypto și zlib se adună la coadă în spatele lor. Mărește UV_THREADPOOL_SIZE, pune lookup-urile în cache sau folosește dns.resolve, care interoghează direct rețeaua.

Stream-urile mută datele în bucăți (chunk-uri) în loc să le încarce pe toate odată, așa că un fișier de 10 GB folosește la fel de multă memorie ca unul de 10 KB, iar procesarea începe de la prima bucată. Există patru tipuri: Readable, Writable, Duplex (ambele, ca un socket) și Transform (un Duplex care modifică datele, ca gzip).

E ce se întâmplă când producătorul e mai rapid decât consumatorul. write() returnează false când bufferul intern depășește highWaterMark, iar tu ar trebui să te oprești din scris până la 'drain'. Dacă ignori semnalul, bufferul crește până când procesul rămâne fără memorie. pipe() și pipeline() se ocupă de asta în locul tău.

.pipe() nu propagă erorile: dacă un stream eșuează, celelalte rămân deschise, iar descriptorii de fișiere sau socket-urile nu mai sunt eliberați (leak). pipeline() distruge toate stream-urile când oricare dintre ele eșuează și îți dă un singur callback, sau un singur promise din stream/promises, pentru succes sau eroare.

Nu. emit() apelează sincron fiecare listener, în ordinea în care au fost adăugați, pe stiva de apeluri curentă, și revine doar după ce toți au terminat. Un listener lent blochează emitterul. Iar un eveniment 'error' fără listener aruncă o excepție.

Măsoară întârzierea: perf_hooks.monitorEventLoopDelay() îți dă o histogramă a întârzierilor buclei, iar performance.eventLoopUtilization() arată cât de ocupată e. Ca să găsești cauza, fă un profil CPU cu --cpu-prof sau cu inspectorul și caută frame-uri sincrone lungi în flame graph.

setInterval se declanșează după program, indiferent dacă rularea asincronă anterioară s-a terminat, așa că cererile lente se suprapun și se adună. Dacă programezi următorul setTimeout la finalul fiecărei rulări, garantezi o pauză între rulări, iar back-off-ul devine ușor de implementat.

Fiecare worker are propriul isolate V8 și propriul event loop, deci implicit nu se partajează nimic. postMessage copiază datele cu algoritmul structured clone; dacă treci un ArrayBuffer în lista de obiecte transferabile, el este mutat în loc să fie copiat. Doar un SharedArrayBuffer este partajat cu adevărat, iar accesul la el îl coordonezi cu Atomics.

spawn pornește un program și îi transmite ieșirea ca stream. exec rulează o comandă printr-un shell și ține ieșirea într-un buffer, așa că e expus la shell injection și limitat de maxBuffer. execFile este exec fără shell. fork pornește un alt proces Node cu un canal IPC pentru send() și 'message'.

La SIGTERM, apelează server.close() ca să nu mai accepți conexiuni noi și să lași cererile în curs să se termine; închide conexiunile keep-alive inactive (closeIdleConnections()); apoi închide pool-urile de conexiuni la baza de date și cozile, și ieși. Adaugă un timeout strict, ca o cerere blocată să nu poată ține procesul în viață la nesfârșit.

Transportă context, cum ar fi ID-ul cererii sau utilizatorul curent, prin fiecare callback și await care decurge dintr-o cerere, fără să-l transmiți ca argument. Este echivalentul async al thread-local storage și așa etichetează loggerele și instrumentele de tracing tot ce se face pentru o cerere.

Cu un AbortController. Transmiți proprietatea lui signal către fetch, fs.readFile, versiunile cu promise ale timerelor, events.once sau propriile tale funcții, apoi apelezi abort(). AbortSignal.timeout(ms) îți dă un semnal care se declanșează singur.

Event loop-ul rulează cât timp ceva încă îl ține deschis: un timer, un socket sau un server deschis, un pool de conexiuni la baza de date, un proces copil. Închide ce ai deschis. Pentru un handle care n-ar trebui să țină singur procesul în viață, cum ar fi un interval de fundal, apelează .unref().

Nu rulează nimic: operațiile au pornit când ai creat promise-urile, iar Promise.all doar le așteaptă. Așteptarea e concurentă, iar promise-ul returnat e respins imediat ce unul dintre ele e respins, fără să le anuleze pe celelalte. Folosește allSettled ca să obții toate rezultatele, any pentru primul succes, race pentru primul care se finalizează și un limitator precum p-limit când ai mii de task-uri.

Se creează un singur obiect listă în heap, iar ambele nume se referă la el. Atribuirea nu copiază niciodată: leagă un nume de un obiect, iar numărul de referințe al listei ajunge la 2.

Niciuna. Transmite prin valoare referințe la obiecte, ceea ce se numește adesea call by sharing. O funcție poate modifica un obiect pe care i-l dai și vei vedea schimbarea, dar dacă funcția leagă parametrul de alt obiect, variabila ta nu e afectată.

În principal prin numărarea referințelor: când numărul de referințe al unui obiect scade la zero, obiectul e eliberat imediat. Un garbage collector generațional pentru cicluri găsește grupuri de obiecte care se referă doar unele la altele, pe care numărarea referințelor singură nu le poate elibera niciodată.

is verifică identitatea: sunt acestea același obiect? == verifică egalitatea prin __eq__. Folosește is pentru singleton-uri precum None și == pentru tot restul.

CPython păstrează în cache întregii de la -5 la 256, așa că aceștia sunt mereu aceleași obiecte. Dacă alte numere sau șiruri egale împart același obiect depinde de interning și de constant folding, un detaliu de implementare pe care nu trebuie să te bazezi niciodată.

Nu direct. del șterge un nume (sau un element dintr-un container) și decrementează numărul de referințe. Obiectul e eliberat doar când numărul ajunge la zero, sau mai târziu de garbage collector, dacă face parte dintr-un ciclu.

Obiectele mici vin din pymalloc, care ia memorie de la sistemul de operare în arene mari și poate returna o arenă doar când fiecare bloc din ea e liber. Câteva obiecte supraviețuitoare țin în viață arene întregi, cum arată demo-ul pymalloc de pe această linie. Python refolosește memoria respectivă; doar că n-o dă înapoi.

Caută referințe care trăiesc prea mult: cache-uri la nivel de modul, un functools.lru_cache nelimitat, closure-uri și callback-uri care captează obiecte mari, și variabile globale. tracemalloc arată ce linii au alocat memoria care rămâne ocupată, iar gc.get_referrers() arată cine ține referințe la un obiect.

Pentru cache-uri și referințe înapoi (back-references) care n-ar trebui să țină un obiect în viață. O referință slabă nu crește numărul de referințe, așa că obiectul poate fi totuși eliberat, după care referința slabă returnează None.

Fiecare obiect CPython are un contor al referințelor care indică spre el: nume, sloturi de listă, valori din dict, atribute. Legarea unui nume adaugă una, renunțarea la el scade una, iar la zero obiectul e eliberat imediat. sys.getrefcount(x) îl arată, cu unu mai mare decât te-ai aștepta, pentru că apelul însuși deține o referință.

Începând cu Python 3.12 (PEP 683), obiecte precum None, True, False, întregii mici și multe șiruri internate au un număr de referințe fix, care nu se schimbă niciodată, și nu sunt eliberate niciodată. Fără acele scrieri în contor se economisește muncă, paginile de memorie rămân partajate după fork, iar partajarea lor între thread-uri și interpretoare devine sigură.

Numărarea referințelor nu poate elibera ciclurile. Dacă o listă se conține pe ea însăși sau două obiecte indică unul spre celălalt, numărul lor de referințe nu ajunge niciodată la zero, chiar dacă nimic altceva nu le mai poate accesa. Colectorul de cicluri găsește astfel de grupuri scăzând referințele pe care și le țin unul altuia și le eliberează pe cele care rămân fără referințe din exterior.

Colectorul sortează obiectele container după vârstă. Obiectele noi încep în generația cea mai tânără, scanată des pentru că majoritatea obiectelor mor tinere; supraviețuitorii sunt promovați în generații mai vechi, scanate din ce în ce mai rar. Pragurile din gc.get_threshold() decid când rulează fiecare.

Rareori. Numărarea referințelor eliberează aproape totul, iar colectorul rulează deja singur. Dezactivarea lui e sigură doar dacă codul tău nu creează niciodată cicluri; altfel, ele rămân în memorie (leak). Singura ajustare frecventă este gc.freeze() înainte de fork-ul workerilor, ca colectorul să nu atingă (și astfel să nu copieze) paginile partajate de procesele copil.

Este un finalizator care rulează când un obiect e pe cale să fie eliberat. Momentul depinde de numărul de referințe, de cicluri și de implementarea Python, așa că nu e un loc bun pentru închiderea fișierelor sau a conexiunilor, iar excepțiile ridicate în el sunt doar afișate. Folosește în schimb un context manager (with) sau weakref.finalize.

Alocatorul CPython pentru obiecte mici, de cel mult 512 octeți. Ia arene mari de la sistemul de operare, le împarte în pool-uri, iar fiecare pool oferă blocuri dintr-o singură clasă de dimensiune. Astfel, crearea și eliberarea obiectelor mici nu costă aproape nimic, pentru că majoritatea cererilor nu ajung niciodată la alocatorul sistemului.

Măsoară doar obiectul în sine. Pentru o listă, asta înseamnă antetul plus array-ul de pointeri, nu obiectele spre care indică aceștia. O listă de o mie de șiruri raportează câțiva kilobytes, oricât de lungi ar fi șirurile. Ca să măsori toată structura, parcurge-o sau compară snapshot-uri tracemalloc înainte și după.

Înlocuiește dicționarul __dict__ al fiecărei instanțe cu sloturi fixe chiar în obiect. Fiecare instanță devine mai mică, iar accesul la atribute puțin mai rapid, ceea ce contează când creezi milioane de instanțe. Costul: nu poți adăuga atribute care nu sunt listate și ai nevoie de un slot __weakref__ pentru referințe slabe.

Păstrarea unei singure copii pentru șirurile egale. CPython internează automat identificatorii și multe literale scurte, iar pe altele le poți interna cu sys.intern(), ceea ce economisește memorie și accelerează căutările în dict pe chei repetate. E o optimizare, nu o regulă, așa că compară întotdeauna șirurile cu ==, niciodată cu is.

După fork, părintele și copilul partajează paginile de memorie până când unul dintre ei scrie într-o pagină. În CPython, simpla citire a unui obiect îi modifică numărul de referințe, ceea ce e o scriere, așa că paginile partajate sunt copiate una câte una. Obiectele imortale și gc.freeze() reduc acest efect.

O listă este un array redimensionabil de pointeri către obiecte stocate în altă parte. Când e plină, CPython alocă un array mai mare, cu spațiu de rezervă, așa că majoritatea operațiilor append doar ocupă un slot liber, iar copierea ocazională se amortizează: O(1) amortizat. Inserarea sau ștergerea la început este O(n), pentru că toți pointerii de după se mută.

Fiecare element este un pointer (8 octeți) către un obiect int complet (28 de octeți sau mai mult), cu propriul antet. array.array('q') sau un array NumPy stochează în schimb valorile brute de 8 octeți una lângă alta, de câteva ori mai compact și mult mai rapid de parcurs în C.

Un generator produce valorile pe rând și păstrează între ele doar frame-ul său suspendat. sum(x * x for x in range(10**8)) are nevoie de memorie constantă, în timp ce varianta cu list comprehension construiește mai întâi o listă de o sută de milioane de int-uri. Capcana: un generator poate fi consumat o singură dată.

O vedere asupra memoriei altui obiect care suportă buffer protocol, cum ar fi bytes, bytearray sau array. Un slice dintr-un memoryview nu copiază datele, așa că parsarea bucată cu bucată a unui buffer binar mare rămâne rapidă și nu folosește memorie suplimentară.

O funcție imbricată păstrează într-o celulă (cell) fiecare variabilă pe care o folosește din scope-ul exterior. Cât timp funcția există, de exemplu stocată ca callback, acele obiecte nu pot fi eliberate, chiar dacă aveai nevoie doar de o valoare mică dintr-unul uriaș. Extrage ce-ți trebuie înainte să definești funcția.

Un traceback are referințe la fiecare frame prin care a trecut, iar fiecare frame are referințe la variabilele sale locale. Dacă stochezi o excepție, de exemplu într-o listă de erori, toate acele variabile locale rămân în viață. De aceea Python șterge numele după except E as e:; stochează str(e) dacă ai nevoie doar de mesaj.

Păstrează o referință la fiecare argument și rezultat pe care îl stochează. Cu maxsize=None sau @cache, crește la nesfârșit. Pe o metodă stochează și self, ceea ce ține în viață fiecare instanță. Dă-i o dimensiune limitată și pune în cache funcții, nu metode.

Un întreg unic pentru un obiect cât timp acesta trăiește. În CPython este adresa din memorie. După ce un obiect e eliberat, un obiect nou poate primi aceeași adresă, așa că două obiecte diferite, create unul după altul, pot raporta același id.

Fără GIL, actualizările contorului din thread-uri diferite ar produce un race condition (condiție de cursă). Build-urile free-threaded folosesc biased reference counting: thread-ul care deține un obiect actualizează un contor local fără operații atomice, iar celelalte thread-uri actualizează atomic un contor partajat. Unele obiecte folosesc numărare amânată (deferred), iar memoria vine din mimalloc în loc de pymalloc.

Global Interpreter Lock este un mutex din CPython care lasă un singur thread să ruleze bytecode Python la un moment dat, în cadrul unui interpretor. Astfel, componentele interne ale interpretorului, cum ar fi numărul de referințe, rămân sigure fără lock-uri granulare.

Pentru că un thread eliberează GIL-ul cât timp așteaptă: I/O blocant pe socketuri și fișiere, precum și time.sleep, lasă alte thread-uri să ruleze. Multe extensii C, cum ar fi NumPy și hashlib pe date de intrare mari, îl eliberează și în timpul calculelor grele.

Folosește procese (multiprocessing sau concurrent.futures.ProcessPoolExecutor), ca fiecare worker să aibă propriul interpretor și propriul GIL, mută bucla critică în cod nativ care eliberează GIL-ul sau rulează pe build-ul free-threaded.

Nu. Thread-urile pot comuta între oricare două instrucțiuni bytecode, așa că count += 1 (citire, adunare, scriere) se poate intercala și pierde actualizări; e exact race condition-ul (condiția de cursă) pe care îl poți parcurge pas cu pas pe această linie. Protejează starea partajată cu threading.Lock sau transmite datele între thread-uri prin queue.Queue.

Un thread care așteaptă GIL-ul îl cere după intervalul de comutare, implicit 5 ms (sys.getswitchinterval()), iar thread-ul care îl deține îl eliberează la următorul punct sigur. Un thread care începe o operație I/O blocantă îl eliberează imediat.

Un build CPython separat, fără GIL (PEP 703), adăugat experimental în 3.13 ca python3.13t și suportat oficial din 3.14 (PEP 779). Thread-urile pot rula atunci cod Python pe mai multe nuclee simultan, cu un cost la viteza pe un singur thread. sys._is_gil_enabled() îți spune în ce mod ești.

asyncio pentru multe task-uri I/O concurente, cu biblioteci async, pe un singur thread. Thread-uri pentru I/O cu biblioteci blocante sau pentru câteva task-uri în fundal. Procese pentru Python pur limitat de CPU, plătind timpul de pornire și serializarea (pickling) datelor între ele.

Un thread limitat de CPU ține GIL-ul câte un interval de comutare întreg, așa că thread-urile de I/O, care au nevoie de el doar o clipă după fiecare citire, stau la coadă în spatele lui. Latența lor crește, deși volumul total de lucru aproape nu se schimbă, cum arată sarcina mixtă de pe această linie.

Nu, face parte din CPython, implementarea de referință. Jython și IronPython n-au avut niciodată GIL, PyPy are propriul GIL, iar din 3.13 CPython are un build free-threaded opțional, fără el. Limbajul spune doar ce înseamnă programul tău, nu cum sunt planificate thread-urile.

E o metodă simplă de a proteja componentele interne ale interpretorului: numărul de referințe, alocatorul și obiectele built-in pot fi actualizate fără un lock propriu. Asta păstrează rapid codul single-threaded și face extensiile C ușor de scris, cu prețul că un singur thread rulează bytecode Python la un moment dat.

În timpul I/O blocant (socketuri, fișiere, time.sleep) și în codul C care alege să-l elibereze, cum ar fi multe operații NumPy, hashlib pe date mari și zlib. Cât execută bytecode Python, thread-ul curent cedează GIL-ul și atunci când alt thread l-a așteptat un interval de comutare, implicit 5 ms.

Fără el, fiecare modificare a numărului de referințe ar necesita o operație atomică sau un lock, ceea ce a încetinit codul single-threaded în încercările anterioare, iar multe extensii C se bazau tacit pe GIL pentru siguranță. PEP 703 a rezolvat asta cu biased reference counting, lock-uri per obiect și obiecte nemuritoare (immortal objects), și vine ca build opțional.

Nu. Se compilează în mai mulți pași: citește valoarea, adună unu, o scrie înapoi, iar o comutare de thread între citire și scriere pierde o actualizare. Operațiile simple pe tipurile built-in, cum ar fi list.append, se întâmplă să fie atomice în CPython, dar nu te baza pe asta; protejează starea partajată cu un Lock.

Un Lock intră în deadlock dacă thread-ul care îl deține încearcă să-l obțină din nou. Un RLock (lock reentrant) lasă thread-ul proprietar să-l obțină de mai multe ori și se eliberează după tot atâtea eliberări. Folosește RLock când o metodă care ține lock-ul apelează altă metodă cu lock a aceluiași obiect.

Obține lock-urile mereu în aceeași ordine globală, ține-le cât mai puțin, folosește with ca să fie eliberate întotdeauna și nu apela niciodată cod necunoscut, cum ar fi callback-uri, cât timp ții un lock. Un timeout la acquire transformă un blocaj tăcut într-o eroare vizibilă.

Prin queue.Queue. Își gestionează singură lock-urile, blochează consumatorii până sosesc elemente și producătorii când e plină, și transformă starea partajată în mesaje. Pentru semnalizare, folosește threading.Event; ca să limitezi câte thread-uri folosesc o resursă, Semaphore.

Au în comun API-ul concurrent.futures, deci alegerea ține de tipul de lucru. Thread-uri pentru task-uri limitate de I/O: pornesc ieftin și partajează memoria. Procese pentru task-uri limitate de CPU: ocolesc GIL-ul, dar funcția și argumentele ei trebuie să poată fi serializate cu pickle, iar fiecare apel plătește trimiterea datelor către alt proces.

Pornirea proceselor, serializarea cu pickle a fiecărui argument și rezultat ca să treacă dintr-un proces în altul, plus o copie separată a interpretorului și a datelor în fiecare proces. Modul de pornire depinde de platformă: spawn pe Windows și macOS, forkserver pe Linux din 3.14 (înainte, fork).

Procesul copil primește o copie a memoriei, dar doar thread-ul care a apelat fork. Un lock ținut în acel moment de orice alt thread rămâne blocat pentru totdeauna în copil, așa că acesta se poate bloca la primul apel de logging sau la prima alocare. Python 3.12 și versiunile ulterioare avertizează despre asta; preferă spawn sau forkserver.

Trimite mesaje printr-un multiprocessing.Queue sau Pipe; datele sunt serializate cu pickle și copiate. Pentru array-uri mari, folosește multiprocessing.shared_memory, care dă fiecărui proces aceiași octeți, fără copiere. Un Manager partajează obiecte Python printr-un proces server, ceea ce e comod, dar lent.

Nu. Rulează un singur thread, iar task-urile își dau rândul la fiecare await. Așa gestionează ieftin mii de conexiuni care așteaptă, dar un singur apel blocant, cum ar fi time.sleep sau requests.get, îngheață toate task-urile. Mută lucrul blocant în afara event loop-ului cu asyncio.to_thread sau run_in_executor.

Concurența înseamnă să te ocupi de mai multe lucruri deodată: task-urile avansează pe rând. Paralelismul înseamnă să faci mai multe lucruri deodată: task-urile rulează în același moment pe nuclee diferite. Thread-urile sub GIL și asyncio îți dau concurență; procesele și Python free-threaded îți dau paralelism.

Adesea, da. NumPy eliberează GIL-ul în multe operații pe array-uri mari, așa că mai multe thread-uri le pot rula pe nuclee diferite. Liniile Python dintre aceste apeluri tot își așteaptă rândul, așa că câștigul depinde de cât din timp se petrece în NumPy.

Mai multe interpretoare Python izolate în același proces. Din 3.12 fiecare poate avea propriul GIL (PEP 684), iar 3.14 adaugă modulul concurrent.interpreters și InterpreterPoolExecutor. Obții paralelism cu overhead mai mic decât la procese, dar obiectele nu sunt partajate; datele se transmit între interpretoare.

Apelează sys._is_gil_enabled() (3.13 sau mai nou). Un build free-threaded, de obicei numit python3.13t sau python3.14t, rulează fără el, dar reactivează GIL-ul când importă o extensie C care nu e marcată ca sigură, dacă nu îl forțezi să rămână oprit cu PYTHON_GIL=0 sau -X gil=0.

Nu. Obiectele built-in își pun intern lock-uri, deci o listă nu se va corupe, dar counter += 1 și codul de tip check-then-act (verifici, apoi acționezi) au race condition exact ca înainte, doar mai des, pentru că acum thread-urile rulează cu adevărat simultan. Tot ai nevoie de lock-uri, iar codul single-threaded rulează ceva mai lent în acest build.

threading.local() dă fiecărui thread propria copie a unor atribute, cum ar fi o conexiune la baza de date. contextvars face același lucru pentru task-urile asyncio, care împart un singur thread, și funcționează și cu thread-uri. Pentru date legate de un request în cod async, folosește contextvars.

Nu îl poți omorî din afară. Dă-i un threading.Event și pune-l să verifice regulat evenimentul și să iasă. Un thread daemon (daemon=True) nu împiedică interpretorul să se închidă, dar e omorât fără curățenie, așa că fișierele deschise și tranzacțiile pot rămâne la jumătate.

Șapte primitive (undefined, null, boolean, number, bigint, string și symbol), plus obiecte. Array-urile, funcțiile, datele calendaristice, map-urile și instanțele de clasă sunt toate obiecte.

Opt șiruri: "undefined", "boolean", "number", "bigint", "string", "symbol", "object" și "function". typeof null este "object" din cauza unui bug istoric, așa că verifică null cu === null, iar array-urile cu Array.isArray().

Folosește implicit ===, care nu convertește niciodată tipurile. == aplică reguli de conversie: null și undefined sunt egale doar între ele, valorile booleene devin numere, un șir comparat cu un număr devine număr, iar obiectele sunt convertite în primitive. Singura utilizare uzuală a lui == este x == null, care verifică dacă valoarea e null sau undefined.

Nu. Totul se transmite prin valoare, dar valoarea unei variabile de tip obiect este o referință. O funcție poate modifica obiectul pe care i-l dai, dar reatribuirea parametrului nu îți schimbă variabila. În Python e la fel.

Spread-ul, Object.assign și slice() copiază un singur nivel, așa că obiectele imbricate rămân partajate. structuredClone face o copie profundă, inclusiv pentru Map, Set, Date și referințe circulare, dar aruncă o excepție la funcții, iar instanțele de clasă devin obiecte simple.

Numerele sunt double-uri IEEE 754 pe 64 de biți, iar 0.1, 0.2 și 0.3 nu au o reprezentare binară exactă, așa că fiecare e stocat ca cel mai apropiat double, iar erorile de rotunjire nu se anulează reciproc. Compară cu o toleranță sau ține sumele de bani ca întregi, în cenți.

false, 0, -0, 0n, "", null, undefined și NaN (plus vechiul document.all din browsere). Orice altceva e truthy, inclusiv "0", "false", [] și {}.

2⁵³ − 1. Peste această valoare, nu orice întreg poate fi reprezentat, așa că un ID pe 64 de biți dintr-o bază de date se poate schimba pe tăcute când e parsat ca număr. Păstrează astfel de ID-uri ca șiruri sau ca BigInt.

undefined înseamnă că o valoare n-a fost setată niciodată: o proprietate lipsă, o variabilă neatribuită, o funcție fără return. null este un „fără valoare” explicit, pe care îl atribui tu. JSON are null, dar nu are undefined, iar JSON.stringify omite proprietățile a căror valoare este undefined.

Un bug din primul motor JavaScript: valorile aveau o etichetă de tip, obiectele aveau eticheta 0, iar null era pointerul null, care se citea tot ca 0. Dacă s-ar schimba acum, s-ar strica web-ul, așa că rămâne așa. Verifică null cu x === null.

Array.isArray(x). typeof returnează "object", iar instanceof Array eșuează pentru array-uri din alt realm, cum ar fi un iframe sau un context vm, pentru că fiecare realm are propriul constructor Array.

Valoarea IEEE 754 pentru un rezultat nedefinit, cum ar fi 0 / 0 sau Number("abc"). Tipul lui este number și nu este egal cu nimic, nici măcar cu el însuși, așa că x === NaN e mereu false. Folosește Number.isNaN(x); funcția globală isNaN convertește mai întâi, așa că isNaN("abc") este true.

Exact în două cazuri: Object.is(NaN, NaN) este true, iar Object.is(0, -0) este false. În rest se comportă ca ===. React îl folosește ca să decidă dacă state-ul s-a schimbat, iar Map, Set și includes folosesc o variantă care consideră 0 și -0 egale.

Când scrii "abc".toUpperCase(), motorul folosește un wrapper String temporar ca să găsească metoda în String.prototype; primitiva în sine nu se schimbă. Nu crea niciodată wrappere de mână cu new String sau new Boolean: new Boolean(false) este un obiect, deci e truthy.

Apelează obj[Symbol.toPrimitive](hint), dacă există. Altfel, încearcă valueOf() și apoi toString() pentru un hint numeric, și invers pentru un hint de tip șir. De aceea [] + {} dă "[object Object]": [] devine "", {} devine "[object Object]", iar + concatenează șirurile.

Un tip întreg de orice mărime, scris 123n, pentru care typeof dă "bigint". Folosește-l pentru ID-uri, sume de bani în subunități sau orice depășește 2⁵³. Nu îl poți amesteca cu numere în operații aritmetice (1n + 1 aruncă un TypeError), nu are zecimale, iar JSON.stringify aruncă o excepție când îl întâlnește.

E o valoare unică, folosită mai ales ca cheie de proprietate care nu se poate ciocni cu nicio altă cheie, nici măcar cu una cu aceeași descriere. for...in, Object.keys și JSON.stringify ignoră cheile de tip symbol. Cele predefinite, ca Symbol.iterator, îți permit să conectezi obiectele la facilități ale limbajului, cum ar fi for...of.

Nu. const te împiedică doar să reasociezi numele; obiectul spre care arată se poate schimba în continuare. Object.freeze blochează modificările proprietăților proprii ale obiectului, dar e superficial: obiectele imbricate rămân mutabile dacă nu le îngheți și pe ele.

Preferă structuredClone: copiază Date, Map, Set, typed arrays și referințe circulare. Drumul dus-întors prin JSON pierde undefined și funcțiile, transformă datele calendaristice în șiruri și NaN în null, și aruncă o excepție la cicluri și la BigInt. Niciuna dintre variante nu copiază funcții și nu păstrează prototipurile claselor.

Un întreg mic pe care V8 îl stochează chiar în pointer, marcat prin bitul cel mai puțin semnificativ, așa că nu necesită alocare. Numerele care nu încap, cum ar fi fracțiile, -0 sau întregii mari, devin HeapNumber: un float pe 64 de biți într-un obiect separat pe heap. De aceea codul care lucrează mult cu întregi e adesea mai rapid.

V8 dă fiecărui obiect o clasă ascunsă, sau shape, care reține proprietățile lui și locul în care sunt stocate. Obiectele construite cu aceleași proprietăți, în aceeași ordine, au același shape, așa că accesul la proprietăți poate fi pus în cache și devine foarte rapid. Adăugarea proprietăților în ordini diferite sau folosirea lui delete creează shape-uri noi și încetinește acel cod.

V8 ține evidența a ce conține un array: doar întregi mici, doar double-uri sau orice, și dacă are goluri. Array-urile packed de întregi mici sunt cele mai rapide. Tranzițiile merg într-un singur sens: după arr.push(1.5) sau un gol ca arr[100] = 1, acel array nu mai redevine niciodată rapid. new Array(n) pornește ca holey.

Float-urile IEEE 754 păstrează un bit de semn chiar și pentru zero. 0 === -0 este true, dar 1 / -0 este -Infinity, iar Object.is(0, -0) este false. Apare când o valoare negativă mică e rotunjită la zero și îți poate spune din ce direcție s-a apropiat o valoare de zero.

Stochează întregi în subunități, cum ar fi cenții, cu BigInt dacă pot deveni mari, sau folosește o bibliotecă de numere zecimale, și formatează cu Intl.NumberFormat. toFixed nu rezolvă problema: rotunjește valoarea binară, așa că (1.005).toFixed(2) dă "1.00", pentru că 1.005 este de fapt 1.00499999...

parseInt citește cifre până dă de altceva, așa că parseInt("12px") dă 12. Number convertește tot șirul sau returnează NaN, așa că Number("12px") dă NaN, dar Number("") dă 0. Dă-i mereu lui parseInt baza (radix) și nu-i da niciodată numere: parseInt(0.0000005) dă 5.

Pentru x == null, care e true doar pentru null și undefined, așa că le prinde pe amândouă dintr-o singură verificare. Multe ghiduri de stil permit exact acest caz și folosesc === în rest.

a || b recurge la b pentru orice valoare falsy, inclusiv 0, "" și false. a ?? b face asta doar pentru null și undefined. Pentru valori implicite ca count ?? 10 ai nevoie de ??, ca să păstrezi un 0 real.

Folosește un Map pentru dicționare cu chei dinamice: cheile pot fi orice valoare, inclusiv obiecte, are size, se iterează în ordinea inserării și nu are chei moștenite, ca __proto__, de care să-ți faci griji. Cheile unui obiect sunt mereu șiruri sau simboluri, iar cheile care arată ca întregi sunt listate primele, în ordine numerică. Folosește obiecte pentru înregistrări cu câmpuri fixe.

Ca să atașezi date la obiecte care nu sunt ale tale, fără să le ții în viață. Cheile trebuie să fie obiecte, iar odată ce o cheie nu mai e accesibilă din altă parte, intrarea poate fi colectată de garbage collector. Pentru că intrările pot dispărea oricând, un WeakMap nu poate fi iterat și nu are size. Utilizări tipice: cache-uri și date private pentru fiecare nod DOM.

list, dict, set și bytearray, plus majoritatea claselor pe care le scrii tu. int, float, complex, bool, str, bytes, tuple, frozenset, range și None sunt imutabile: orice „modificare” construiește un obiect nou.

Are nevoie de un __hash__ care nu se schimbă niciodată pe durata vieții obiectului, iar obiectele egale trebuie să aibă același hash. Doar obiectele hashable pot fi chei de dict sau elemente de set, de aceea o listă nu poate fi cheie, dar un tuplu de elemente hashable poate.

Sunt egale la comparare și au același hash, așa că dict-ul le tratează ca pe o singură cheie. Se păstrează primul obiect-cheie și se înlocuiește doar valoarea, cum arată pas cu pas exemplul de hashing de pe această linie.

Apelează a.__add__(b). Dacă acesta returnează NotImplemented, încearcă b.__radd__(a) și aruncă TypeError dacă amândouă renunță. Dacă tipul lui b este o subclasă a tipului lui a și suprascrie __radd__, b are prioritate.

Nu pentru tipurile mutabile. += apelează mai întâi __iadd__, care extinde o listă pe loc, așa că toate numele legate de acea listă văd schimbarea. Tipurile imutabile recurg la x = x + y și reasociază doar x. Tot de aceea pair[0] += [2] pe un tuplu și modifică lista, și aruncă o excepție.

Valorile implicite sunt evaluate o singură dată, la definirea funcției, așa că toate apelurile folosesc aceeași listă. Folosește items=None și creează o listă nouă în interiorul funcției.

None este un singleton, așa că identitatea e testul precis. E și mai rapid și nu poate fi păcălit de o clasă al cărei __eq__ răspunde da la orice.

O listă pentru o colecție ordonată pe care o modifici, un tuplu pentru o înregistrare fixă sau o cheie hashable, un set pentru unicitate și teste rapide de apartenență, iar un dict pentru căutare după cheie. Alege un frozenset când ai nevoie de un set hashable.

list(x), x.copy(), x[:] și copy.copy() fac copii superficiale: noul container conține aceleași obiecte interioare. copy.deepcopy() copiază totul recursiv.

+= apelează întâi list.__iadd__, care extinde pe loc lista din tuplu, apoi încearcă să stocheze rezultatul înapoi în t[0], ceea ce aruncă TypeError. Sloturile tuplului nu se pot schimba, dar obiectele din ele da. Din același motiv, un tuplu care conține o listă nu e hashable.

Obiectele egale trebuie să aibă hash-uri egale, iar hash-ul nu are voie să se schimbe cât timp obiectul se află într-un set sau dict. De aceea, când definești __eq__, __hash__ devine None: Python face clasa non-hashable până când definești un hash bazat pe aceleași câmpuri. @dataclass(frozen=True) le face pe amândouă pentru tine.

E o tabelă hash. Hash-ul cheii alege un slot dintr-un mic array de indecși, coliziunile se rezolvă prin sondarea altor sloturi (probing), iar indexul trimite într-un array compact de intrări păstrate în ordinea inserării. Căutările, inserările și ștergerile sunt O(1) în medie, iar o potrivire se confirmă cu is sau == pe cheie.

Da, ordinea inserării e garantată din Python 3.7. OrderedDict rămâne util: are move_to_end, comparația de egalitate ține cont de ordine și e la îndemână pentru cache-uri LRU. Set-urile nu au deloc ordine.

Pe Python îl interesează ce poate face un obiect, nu ce clasă are: orice are __iter__ poate fi parcurs într-o buclă, orice are read() poate ține loc de fișier. De obicei, codul pur și simplu încearcă operația și tratează excepția (EAFP). Pentru type checkere, typing.Protocol descrie o astfel de formă fără moștenire.

NotImplemented este o valoare pe care o returnezi dintr-o metodă binară precum __add__ sau __eq__ ca să spui „nu cunosc acest tip”, iar Python încearcă atunci metoda celuilalt operand. NotImplementedError este o excepție pe care o arunci într-o metodă pe care subclasele trebuie s-o suprascrie. Dacă o arunci pe prima sau o returnezi pe a doua, ai un bug în ambele cazuri.

Pentru a + b, când a nu are __add__ sau aceasta returnează NotImplemented, Python încearcă b.__radd__(a). O excepție: dacă tipul lui b e o subclasă a tipului lui a și suprascrie __radd__, metoda lui e încercată prima, ca subclasele să poată prelua controlul. Așa funcționează sum() pe tipuri proprii, pornind de la 0.

Nu. Python le ignoră când rulează codul; unelte precum mypy și pyright le verifică înainte de rulare. Sunt disponibile la runtime prin typing.get_type_hints() și annotationlib, iar așa validează datele biblioteci ca Pydantic și FastAPI. Din 3.14, adnotările sunt evaluate lazy, doar când le cere ceva.

Nu, int-urile au precizie arbitrară și cresc cât e nevoie; sys.maxsize e dimensiunea maximă a unui container, nu cel mai mare int. Int-urile mari doar devin mai lente. Din 3.11, conversia unui int cu peste 4300 de cifre în sau din string aruncă implicit ValueError, ca să prevină atacurile de tip denial-of-service.

// rotunjește în jos, spre minus infinit, deci -7 // 2 dă -4, iar % ia semnul împărțitorului: -7 % 2 dă 1. JavaScript, C și Java trunchiază în schimb spre zero. Și int(-3.5) trunchiază, dând -3.

Python rotunjește jumătățile la cel mai apropiat număr par (rotunjirea bancherului), deci round(2.5) dă 2, iar round(3.5) dă 4; asta evită o eroare sistematică atunci când aduni multe valori rotunjite. round(2.675, 2) dă 2.67, pentru că 2.675 nu poate fi stocat exact. Pentru bani, folosește decimal.Decimal.

str e text, o secvență de code point-uri Unicode. bytes sunt date brute pe 8 biți, din fișiere, socketuri sau hash-uri. Python 3 nu convertește niciodată implicit între ele: faci encode() din text în bytes și decode() din bytes în text la granițele programului, specificând encoding-ul, de obicei UTF-8.

len numără code point-uri, nu ce vezi. „é” poate fi un singur code point (U+00E9) sau două: „e” plus un accent combinant. Normalizează cu unicodedata.normalize("NFC", s) înainte să compari sau să numeri. Intern, CPython stochează fiecare string cu 1, 2 sau 4 octeți pe caracter, în funcție de cel mai lat caracter din el.

String-urile sunt imutabile, așa că fiecare += poate crea un string nou și copia tot ce s-a adunat până atunci, adică O(n²) în total. CPython extinde uneori pe loc, dar alte implementări nu, și nu te poți baza pe asta. Adună bucățile într-o listă și apelează o singură dată "".join(parts), sau folosește io.StringIO.

isinstance acceptă subclase și clase de bază abstracte precum collections.abc.Mapping, ceea ce e aproape mereu ce vrei. Are o surpriză clasică: bool e subclasă a lui int, deci isinstance(True, int) e adevărat, iar True + True dă 2. Folosește type(x) is T doar când subclasele trebuie respinse.

O listă verifică pe rând fiecare element: O(n). Set-urile și dict-urile calculează hash-ul lui x și se uită într-un singur slot: O(1) în medie. Să transformi o listă în set înainte să verifici mii de valori într-o buclă e una dintre cele mai simple optimizări cu câștig mare. Și x in range(...) e O(1): e doar aritmetică.

namedtuple: un tuplu imutabil și ușor, cu nume de câmpuri. dataclass: o clasă obișnuită cu __init__, __repr__ și __eq__ generate, mutabilă sau frozen, cu valori implicite și metode. TypedDict: type hints pentru dict-uri care rămân dict-uri simple, cum ar fi payload-urile JSON. Un dict simplu: chei cu adevărat dinamice.

Da. Sortarea din Python e stabilă, deci elementele cu chei egale își păstrează ordinea și poți sorta după mai multe chei în mai multe treceri, începând cu cea mai puțin importantă. E O(n log n) și foarte rapidă pe date deja parțial sortate. Are nevoie doar de <; dacă amesteci tipuri care nu pot fi comparate, cum ar fi None și int, primești TypeError.

Apelează __bool__ dacă clasa îl definește, altfel __len__, iar orice altceva e considerat adevărat. Așadar None, False, zero din orice tip numeric și containerele goale sunt falsy. Atenție la if not x: când 0 sau o listă goală sunt valori valide; scrie în schimb if x is None:.

Un iterabil, cum e o listă, îți poate da un iterator nou cu iter(), de câte ori vrei. Un iterator își ține minte poziția, returnează următorul element din __next__ și se consumă după o singură trecere. Generatoarele și obiectele fișier sunt iteratori, de aceea a doua parcurgere a unuia nu produce nimic.

Rulează o buclă. Textul de până acum e împărțit în tokenuri și trecut prin rețea, iar rețeaua produce un scor (logit) pentru fiecare token din vocabularul ei. Softmax transformă scorurile în probabilități, o regulă de decodare alege un token, iar acel token e adăugat la input pentru următoarea trecere. Se oprește la un token de oprire (stop token) sau la limita de tokenuri.

Un token e o unitate dintr-un vocabular fix, învățat de tokenizer, de obicei cu byte-pair encoding: cuvintele comune devin un singur token, cele rare se sparg în bucăți, iar orice text poate fi redus, la nevoie, la bytes. Caracterele ar face secvențele foarte lungi; cuvintele întregi ar cere un vocabular uriaș și tot ar rata cuvintele noi. Subcuvintele țin echilibrul între cele două. În engleză, un token are cam trei sferturi dintr-un cuvânt, dar numerele, codul și multe alte limbi au nevoie de mai multe tokenuri.

Un număr la care se împart logits înainte de softmax: softmax(logits / T). Sub 1 ascute distribuția, așa că tokenurile probabile domină; peste 1 o aplatizează, așa că tokenurile improbabile sunt alese mai des. T = 0 e tratat ca decodare greedy. Schimbă felul în care alege modelul, nu ce știe.

O listă de numere de lungime fixă care reprezintă o bucată de text (sau o imagine, sau cod), astfel încât sensurile asemănătoare primesc vectori orientați în direcții asemănătoare. O obții de la un model de embedding și compari embedding-urile cu similaritatea cosinus. Stă la baza căutării semantice, a clusterizării, a deduplicării și a pasului de regăsire din RAG.

Output fluent care nu e susținut de fapte sau de sursele furnizate. Modelul e antrenat să producă text probabil, nu text adevărat, așa că, atunci când îi lipsește un fapt, produce unul plauzibil. Datele de antrenare spun rar „nu știu”, multe evaluări răsplătesc ghicitul, cunoștințele au goluri și o dată-limită (cut-off), iar eșantionarea poate alege un token greșit pe care se sprijină apoi tokenurile următoare.

Ancorează modelul în surse regăsite și cere citări, spune-i că „nu știu” e un răspuns acceptabil și scade temperatura pentru sarcinile factuale. Folosește tool-uri pentru fapte și calcule, cere output structurat și validează-l în cod, și măsoară cu evaluări (evals) pe răspunsuri cunoscute. Acolo unde erorile costă scump, adaugă un pas de verificare sau o revizuire umană.

Temperatura remodelează toată distribuția. Top-k păstrează doar cele mai probabile k tokenuri. Top-p (nucleus sampling) păstrează cel mai mic set de tokenuri, în ordinea probabilității, a căror probabilitate totală e cel puțin p, deci numărul păstrat se adaptează: puține când modelul e sigur, multe când nu e. După tăiere, tokenurile rămase sunt renormalizate și se eșantionează unul.

Greedy (sau o temperatură mică) pentru extragere, clasificare, cod și orice are un singur răspuns corect, pentru că vrei output-ul cel mai probabil și repetabilitate. Eșantionare cu o temperatură moderată pentru scriere creativă, brainstorming sau mai multe variante diferite. Decodarea greedy se poate bloca în bucle repetitive la texte lungi, cu final deschis.

Decodarea greedy nu implică nimic aleatoriu, dar aritmetica nu e perfect repetabilă. Adunarea în virgulă mobilă pe GPU nu e asociativă, iar gruparea în batch cu alte cereri schimbă ordinea operațiilor, așa că doi logits aproape egali își pot schimba locurile. Un singur token diferit schimbă tot ce urmează după el. Furnizorii respectă seed-ul doar pe principiul best effort, așa că proiectează sistemul să tolereze mici variații.

Numărul maxim de tokenuri pe care modelul le poate procesa într-un singur apel, socotind system promptul, conversația, documentele regăsite, rezultatele tool-urilor și răspunsul generat. Tot ce depășește limita trebuie trunchiat, rezumat sau regăsit la nevoie. Ferestrele mai mari costă mai mult, iar modelele nu folosesc la fel de bine toate părțile unui context lung.

API-urile taxează per token de input și de output, output-ul de obicei la un preț mai mare. Inputul e procesat în paralel (prefill), ceea ce determină timpul până la primul token; output-ul e generat câte un token pe rând, deci latența totală crește odată cu lungimea răspunsului. Ajută prompturile mai scurte, prompt caching pentru prefixele repetate, modelele mai mici și limitarea lungimii output-ului.

Pentru fiecare poziție, atenția calculează cât de relevantă e fiecare poziție anterioară (comparând un vector query cu vectorii key), apoi face o combinație ponderată a vectorilor lor value. Așa poate cuvântul „is” să aducă informație din „France” și „capital”. Multe capete de atenție (attention heads) rulează în paralel în fiecare strat, iar o mască cauzală împiedică pozițiile să vadă viitorul.

În timpul generării, cheile (keys) și valorile (values) din fiecare strat pentru toate tokenurile anterioare sunt stocate în loc să fie recalculate, așa că fiecare token nou își calculează doar propria poziție. Asta face decodarea mult mai rapidă, dar ocupă memorie GPU care crește cu lungimea contextului și cu dimensiunea batch-ului, una dintre principalele limite pentru contextele lungi și pentru câte cereri poate servi un server simultan.

Produsul scalar a doi vectori împărțit la produsul lungimilor lor: cosinusul unghiului dintre ei, de la −1 la 1. Compară direcția și ignoră lungimea, ceea ce se potrivește cu felul în care modelele de embedding codifică sensul. Dacă vectorii sunt normalizați la lungimea 1, cosinusul e egal cu produsul scalar, care e mai ieftin de calculat.

Folosește metrica pentru care a fost antrenat modelul de embedding. Produsul scalar e influențat de lungimea vectorilor, distanța euclidiană atât de lungime, cât și de unghi, cosinusul doar de unghi. Pe vectori normalizați, toate dau aceeași ordine, pentru că pătratul distanței este 2 − 2 cos.

Un sistem de stocare care indexează vectori împreună cu metadate și răspunde la întrebarea „care vectori stocați sunt cei mai apropiați de acesta?”. Căutarea exactă compară cu fiecare vector, ceea ce e prea lent la scară mare, așa că se folosesc indecși approximate nearest neighbour (ANN). HNSW construiește un graf de vecini pe mai multe straturi și înaintează greedy spre query, de la stratul de sus, rarefiat, în jos; IVF grupează vectorii în clustere și caută doar în clusterele cele mai apropiate. Sacrifici puțin recall pentru o accelerare mare.

Offline: împarți documentele în chunk-uri, calculezi embedding-ul fiecărui chunk și stochezi vectorii cu metadate. Online: calculezi embedding-ul întrebării, regăsești primele k chunk-uri (adesea în combinație cu o căutare după cuvinte cheie), opțional le faci reranking, apoi pui cele mai bune în prompt, cu instrucțiuni să răspundă doar pe baza lor și să le citeze. Evaluează regăsirea (am adus chunk-ul corect?) separat de generare (l-am folosit fidel?).

Chunk-urile trebuie să fie destul de mici ca să fie specifice și să încapă mai multe în prompt, dar destul de mari ca să conțină idei complete. Unde poți, împarte după structură (titluri, paragrafe), nu după un număr fix de caractere, și adaugă puțină suprapunere (overlap), ca o propoziție tăiată la graniță să apară întreagă undeva. Apoi ajustează, măsurând calitatea regăsirii pe întrebări reale.

O a doua etapă care recalculează scorurile candidaților regăsiți cu un model mai puternic și mai lent, de obicei un cross-encoder care citește împreună query-ul și fiecare pasaj. Căutarea cu embedding-uri e rapidă, dar grosieră; dacă faci reranking pe primele 50 de rezultate, cam așa, și le păstrezi doar pe cele mai bune, crește precizia, iar scorurile reranker-ului sunt un prag mai bun pentru eliminarea pasajelor irelevante.

Regăsirea poate returna pasajul greșit, pentru că cel mai apropiat nu e neapărat și relevant, sau îl poate rata pe cel corect. Modelul poate ignora contextul în favoarea a ce a învățat, poate amesteca sursele sau poate răspunde dincolo de ele. Atenuezi cu un prag de relevanță sau un reranker, permisiunea explicită de a se abține, citări obligatorii și o verificare că fiecare afirmație e susținută de un pasaj citat.

Ancorarea în surse (grounding) înseamnă că răspunsul e derivat din sursele pe care le-ai furnizat. Când ceri citări, fiecare afirmație poate fi urmărită până la un id de pasaj, așa că utilizatorii pot verifica răspunsul, iar codul tău poate verifica dacă pasajele citate există și chiar conțin afirmația. În plus, descurajează răspunsurile care nu au niciun suport în context.

Începe cu prompting. Folosește RAG când răspunsurile depind de cunoștințe private sau care se schimbă des, ori au nevoie de citări. Folosește fine-tuning ca să schimbi comportamentul: un format sau un ton consecvent, ori o sarcină îngustă rezolvată de un model mai mic și mai ieftin. Fine-tuning-ul e o metodă proastă de a adăuga fapte. Se combină bine, de exemplu un model cu fine-tuning într-un pipeline RAG.

Preantrenarea pe un corpus uriaș de text, prin predicția următorului token, produce un model de bază (base model). Fine-tuning-ul supervizat pe conversații exemplu îl învață să urmeze instrucțiuni. Ajustarea pe preferințe, cum ar fi RLHF sau DPO, îl aliniază cu răspunsurile pe care le preferă oamenii. Modelele de raționament adaugă învățare prin întărire pe sarcini ale căror răspunsuri pot fi verificate, cum ar fi matematica și codul.

Ambele învață din perechi de răspunsuri în care unul a fost preferat. RLHF antrenează mai întâi un reward model separat pe aceste preferințe, apoi optimizează LLM-ul în raport cu el prin învățare prin întărire, clasic cu PPO, cu o penalizare dacă se îndepărtează prea mult de modelul original. DPO renunță la reward model și la bucla de RL și optimizează LLM-ul direct pe perechile de răspunsuri preferate și respinse, cu o funcție de loss simplă, de tip clasificare. DPO e mai simplu și mai stabil de rulat.

Low-rank adaptation: în loc să actualizezi toate ponderile, îngheți modelul și antrenezi matrice mici, de rang redus, adăugate la unele straturi. Are nevoie de mult mai puțină memorie și spațiu de stocare și poți păstra mai multe adaptoare pentru același model de bază. QLoRA face același lucru pe un model de bază cuantizat, ca să economisească și mai multă memorie.

Instrucțiuni ascunse în conținutul pe care îl procesează modelul, cum ar fi o pagină web, un e-mail sau un document regăsit, care încearcă să-ți suprascrie instrucțiunile, de exemplu ca să scurgă date sau să apeleze un tool. Modelul nu poate deosebi sigur datele de instrucțiuni, așa că nu poți preveni complet atacul doar prin prompting. Limitează ce poate face modelul: tool-uri cu privilegii minime, confirmare pentru efectele secundare, niciun secret în context și validarea output-ului.

Îi dai modelului o schemă JSON, fie pentru răspunsul lui, fie pentru fiecare tool pe care îl poate apela. Modelul emite JSON care respectă schema, iar mulți furnizori o pot impune prin decodare constrânsă (constrained decoding), care permite doar tokenurile ce păstrează output-ul valid. La un apel de tool, codul tău rulează funcția și trimite rezultatul înapoi ca mesaj nou. Validează oricum argumentele; faptul că respectă schema nu înseamnă că valorile sunt corecte.

Construiește un set de test din inputuri reale, cu răspunsuri așteptate sau criterii de notare, și rulează-l la fiecare schimbare de prompt, model sau regăsire. Folosește verificări exacte unde se poate (JSON valid, câmpul corect, pasajul citat conține afirmația) și un LLM judge cu o grilă clară unde nu se poate, validat față de etichete puse de oameni. Urmărește metricile de regăsire, fidelitatea față de surse (faithfulness), latența și costul, și monitorizează trace-urile din producție.

Ele văd tokenuri, nu caractere: strawberry are trei tokenuri în o200k_base, așa că literele nu sunt direct vizibile. Numerele sunt împărțite în bucăți de până la trei cifre, care nu se aliniază cu valoarea pozițională a cifrelor. Dă-i în schimb modelului un tool, cum ar fi un interpretor de cod sau un calculator.

Folosește cel mai mic model care trece de evaluările tale și trimite doar cererile grele la unul mai mare. Scurtează prompturile, pune în cache prefixele repetate, regăsește mai puține chunk-uri, dar mai bune, limitează lungimea output-ului, trimite răspunsurile prin streaming și pune în cache răspunsurile întregi pentru întrebările repetate. Procesează în batch munca offline și măsoară separat timpul până la primul token și tokenurile pe secundă.

LangChain îți dă piese standard, independente de furnizor, pentru aplicații cu LLM: modele de chat, mesaje, prompturi, tool-uri, retrievere și parsarea outputului, toate compozabile ca Runnables, plus create_agent pentru agenți cu tool calling. Merită când compui pași, schimbi furnizori, faci streaming, tracing sau construiești agenți. Pentru un singur apel de model fără tool-uri sau regăsire, SDK-ul furnizorului e mai simplu și n-ar trebui să adaugi un strat pe care nu-l poți explica.

LangChain e setul de blocuri de construcție plus create_agent, de nivel înalt. LangGraph e runtime-ul de nivel jos pentru fluxuri cu stare: grafuri cu stare, cicluri, checkpointuri, interrupturi și streaming; create_agent rulează pe el. LangSmith e platforma de observabilitate și evaluare și merge cu sau fără celelalte două.

Un Runnable e orice are interfața standard: invoke, batch, stream și versiunile lor async. Prompturile, modelele, parserele, retrieverele, tool-urile și grafurile compilate sunt toate Runnables. LCEL, LangChain Expression Language, le compune cu |, care construiește un RunnableSequence în care outputul fiecărui pas e inputul pasului următor. Chain-ul compus e și el un Runnable, așa că primește gratis streaming, batching, async și tracing.

invoke primește un input și returnează un output. batch primește o listă și rulează inputurile concurent pe un thread pool, limitat de max_concurrency. stream emite outputul pe bucăți, de exemplu tokenuri, imediat ce sunt gata. astream și celelalte metode cu a sunt versiunile async pentru servere asyncio, ca un apel lent de model să nu blocheze alte requesturi.

RunnableParallel rulează mai multe Runnables pe același input și returnează un dict cu rezultatele lor; un dict simplu într-un chain e transformat automat într-unul. RunnablePassthrough lasă inputul să treacă neschimbat, iar RunnablePassthrough.assign adaugă chei calculate într-un dict de input. RunnableLambda împachetează o funcție Python obișnuită ca să poată sta într-un chain. Chain-ul RAG clasic folosește toate trei ideile: {"context": retriever | format, "question": RunnablePassthrough()} | prompt | model.

SystemMessage poartă instrucțiunile, HumanMessage inputul utilizatorului, iar AIMessage răspunsul modelului, care poate include tool_calls și usage_metadata. ToolMessage poartă rezultatul unui tool și trebuie să aibă tool_call_id al apelului căruia îi răspunde. Un model de chat primește o listă de mesaje și returnează un AIMessage; în 1.x, .text îți dă textul, iar .content_blocks îți dă blocuri tipizate, cu aceeași formă pentru orice furnizor.

Legi tool-urile cu model.bind_tools(tools), care trimite odată cu requestul numele, descrierea și schema JSON a fiecărui tool. Modelul nu rulează nimic: returnează un AIMessage cu tool_calls, fiecare cu nume, argumente și un id. Codul tău rulează fiecare tool și adaugă un ToolMessage cu tool_call_id corespunzător, apoi apelează din nou modelul cu tot istoricul. Când modelul răspunde fără apeluri de tool-uri, ai terminat.

Folosește bind_tools când modelul trebuie să decidă dacă acționează și ce tool-uri apelează, ca într-un agent. Folosește with_structured_output(Schema) când vrei mereu date într-o formă fixă, de exemplu la extragere sau clasificare: impune formatul prin modul JSON al furnizorului sau printr-un apel de tool, apoi parsează rezultatul în modelul tău Pydantic, TypedDict sau dict. include_raw=True returnează în plus mesajul brut și eventuala eroare de parsare.

Modelul primește conversația și schemele tool-urilor. Dacă returnează apeluri de tool-uri, tool-urile rulează și rezultatele lor se adaugă ca ToolMessage-uri, apoi modelul e apelat din nou. Bucla se termină când modelul răspunde fără apeluri de tool-uri sau când o limită o oprește. În LangGraph asta înseamnă două noduri, model și tools, o muchie condiționată precum tools_condition și o muchie de la tools înapoi la model.

create_agent(model, tools, ...) îți dă bucla standard de tool calling peste LangGraph, cu checkpointing, streaming și middleware pentru lucruri ca aprobarea umană, rezumarea, reîncercările și limitele de apeluri. Folosește-l ori de câte ori forma potrivită e un model care alege tool-uri într-o buclă. Construiește-ți propriul StateGraph când ai nevoie de un flux de control personalizat: pași ficși amestecați cu pași de agent, mai mulți agenți, fan-out paralel sau aprobare la un anumit pas.

Hookuri care rulează în jurul apelurilor de model și de tool-uri ale agentului, ca să schimbi comportamentul fără să rescrii bucla. Printre cele incluse sunt HumanInTheLoopMiddleware, SummarizationMiddleware, ModelRetryMiddleware, ModelFallbackMiddleware, ModelCallLimitMiddleware, ToolCallLimitMiddleware și PIIMiddleware. Pe ale tale le scrii cu decoratori precum @before_model, @after_model, @wrap_model_call și @dynamic_prompt.

Un StateGraph se construiește dintr-o schemă de stare, de obicei un TypedDict. Nodurile returnează actualizări parțiale, iar reducer-ul fiecărei chei decide cum se combină o actualizare: fără reducer, valoarea se suprascrie; cu operator.add, se concatenează. add_messages adaugă mesajele noi la final și le înlocuiește pe cele cu același id, așa că nodurile pot returna doar mesajul nou, iar nodurile paralele nu se suprascriu unul pe altul. MessagesState e starea gata făcută, cu o cheie messages care îl folosește.

add_conditional_edges(node, router) apelează router(state) după nod și merge la nodul returnat sau la END. O muchie înapoi spre un nod anterior creează un ciclu, și așa intră agenții în buclă. Un nod poate returna și Command(goto=..., update=...) ca să ruteze și să actualizeze starea într-un singur pas. Orice buclă are nevoie de o condiție de ieșire, iar limita de recursivitate e plasa de siguranță.

Plafonează numărul de super-pași dintr-o rulare. Când e atinsă, LangGraph aruncă GraphRecursionError în loc să ruleze la nesfârșit. O setezi per apel cu config={"recursion_limit": n}. Versiunile mai vechi aveau implicit 25; langgraph 1.2 are implicit 10.007, iar create_agent folosește 9.999, așa că pentru agenți setează-ți propria limită sau adaugă middleware de limitare a apelurilor.

Un checkpointer salvează starea grafului după fiecare super-pas. Un thread e o conversație sau un job, identificat prin thread_id în config["configurable"]; toate checkpointurile lui sunt stocate sub acel id. Dacă apelezi din nou cu același thread, graful continuă din starea salvată, și de aici ai memoria conversației, recuperarea după crash, interrupturile și time travel. Folosește InMemorySaver în teste și un saver Postgres sau SQLite în producție.

Pentru că fiecare pas are un checkpoint, poți lista stările trecute cu get_state_history(config). Dacă apelezi cu configul unui checkpoint mai vechi, execuția se reia din acel punct. update_state pe un checkpoint vechi creează un fork pe care îl poți rula mai departe cu alte valori. Se folosește la debugging, ca să reîncerci de la un pas greșit și ca să-i lași pe utilizatori să editeze un mesaj anterior.

Un apel interrupt(value) într-un nod salvează starea și oprește rularea; apelantul primește value sub __interrupt__. Ca să continui, apelezi același thread cu Command(resume=answer). Capcana: nodul repornește de la prima linie, iar interrupt() returnează atunci answer, deci orice cod dinaintea lui rulează de două ori. Pune efectele secundare după interrupt sau fă-le idempotente. Interrupturile au nevoie de un checkpointer.

Memoria pe termen scurt e starea unui singur thread, păstrată de checkpointer: mesajele conversației curente. Memoria pe termen lung trebuie să supraviețuiască threadurilor, de exemplu preferințele utilizatorului sau fapte aflate mai devreme, așa că merge într-un Store: documente JSON sub namespace-uri ca ("users", user_id), opțional căutabile după sens. Nodurile ajung la store prin argumentul Runtime.

Nodurile programate în același super-pas rulează în paralel, deci mai multe muchii care pleacă din același nod îți dau deja ramuri paralele fixe. Când numărul de ramuri se știe abia la rulare, o muchie condiționată returnează o listă de Send(node, input), iar fiecare rulează nodul cu propriul input: pasul map din map-reduce. Un reducer precum operator.add pe cheia de rezultat le colectează outputurile.

Un graf compilat e un Runnable, deci poate fi nod în alt graf. Dacă părintele și copilul au chei de stare comune, îl adaugi direct; dacă nu, îl apelezi dintr-un nod și mapezi starea la intrare și la ieșire. Cu subgrafuri construiești și testezi agenții separat și apoi îi combini, iar așa se construiesc de obicei sistemele multi-agent. Un nod dintr-un subgraf poate ruta în părinte cu Command(graph=Command.PARENT, goto=...).

values trimite starea completă după fiecare pas, iar updates doar ce a returnat fiecare nod. messages trimite tokenurile LLM-ului cu metadate care spun ce nod le-a produs, iar custom trimite orice emit nodurile cu get_stream_writer(). Mai există checkpoints, tasks și debug; dai o listă ca să primești mai multe, ca tupluri (mode, data).

Folosește astream cu stream_mode="messages" ca să primești tokenurile pe măsură ce sunt generate, de multe ori combinat cu "updates" ca să arăți progresul, de exemplu ce tool rulează. Trimite chunk-urile spre browser prin server-sent events sau printr-un WebSocket. Streamingul de tokenuri merge chiar dacă nodul apelează invoke, pentru că LangGraph ascultă callbackurile modelului.

Indexarea: încarci sursele în Document-e, le împarți în chunk-uri cu un text splitter, calculezi embedding-urile chunk-urilor și le stochezi într-un vector store. Răspunsul: un retriever găsește chunk-urile cele mai similare cu întrebarea, iar un chain le pune în prompt și îi cere modelului să răspundă doar din acel context. Pentru întrebări mai grele faci din regăsire un tool, ca un agent să poată căuta de mai multe ori și să-și reformuleze interogarea.

Chunk-urile trebuie să fie destul de mari cât să cuprindă o idee completă și destul de mici încât un chunk regăsit să fie în mare parte relevant; un punct de plecare obișnuit e între câteva sute și vreo mie de tokenuri. Suprapunerea (overlap), de multe ori 10–20%, repetă text între chunk-uri vecine, ca o idee tăiată la graniță să fie găsită totuși. RecursiveCharacterTextSplitter împarte după paragrafe, apoi după linii, apoi după cuvinte, ca chunk-urile să rămână naturale. Apoi măsori calitatea regăsirii pe întrebări reale și ajustezi.

Un vector store stochează embedding-uri și face căutare după similaritate. Un retriever e o interfață Runnable: intră un string de interogare, iese o listă de Document-e. vector_store.as_retriever(search_kwargs={"k": 4}) împachetează un store, dar un retriever poate fi și căutare după cuvinte cheie, o căutare pe web sau un hibrid din mai multe. Fiind un Runnable, se potrivește în orice chain.

Tracing: cu LANGSMITH_TRACING=true și o cheie API, fiecare rulare e înregistrată ca un arbore de pași, cu inputuri, outputuri, latență, tokenuri și erori, așa că vezi exact ce i s-a trimis modelului. Evaluare: ții dataseturi de exemple, rulezi aplicația pe ele cu evaluatori scriși în cod sau LLM-judge și compari experimentele înainte de lansare. Mai monitorizează și traficul din producție și poate rula evaluări online pe el.

runnable.with_retry(stop_after_attempt=3) reîncearcă cu backoff exponențial, iar with_fallbacks([backup]) încearcă alt model sau alt chain dacă tot eșuează. Dă-i unui model de chat rate_limiter=InMemoryRateLimiter(requests_per_second=...) ca să rămâi sub limitele furnizorului. În agenți, ModelRetryMiddleware, ToolRetryMiddleware și ModelFallbackMiddleware fac aceleași lucruri.

Folosește modelele de chat false din langchain_core: FakeListChatModel redă stringuri, iar GenericFakeChatModel sau FakeMessagesListChatModel redau AIMessage-uri întregi, inclusiv apeluri de tool-uri. Rulezi chain-ul sau graful real cu un InMemorySaver și verifici mesajele, traseul parcurs și starea finală. Așa testele unitare rămân rapide și deterministe; calitatea răspunsurilor o judeci separat, cu evaluările din LangSmith.

O scurtezi cu trim_messages, păstrând mesajul de sistem și mesajele cele mai recente; rezumi turele mai vechi într-un mesaj scurt, ce face SummarizationMiddleware pentru agenți; sau muți faptele durabile într-un Store și le regăsești când ai nevoie. Când scurtezi, nu despărți niciodată un AIMessage cu apeluri de tool-uri de ToolMessage-urile lui, altfel furnizorul respinge istoricul.

Într-un graf, ToolNode transformă implicit erorile de argumente invalide într-un ToolMessage, ca modelul să-și poată corecta apelul, și aruncă mai departe celelalte excepții. Setează handle_tool_errors=True sau dă-i o funcție, ca să trimiți orice eroare înapoi la model ca mesaj. În create_agent, middleware-ul de retry poate reîncerca întâi tool-urile instabile.

Creează un model de chat dintr-un string precum "provider:model-name", încărcând pachetul de integrare potrivit, de exemplu langchain-openai sau langchain-anthropic. Apoi fiecare furnizor are aceeași interfață, așa că schimbi modelele din configurare, fără să modifici codul. Și create_agent acceptă direct același string.

Fiecare agent e un nod sau un subgraf cu propriul prompt și propriile tool-uri. Într-un design cu supervisor, un agent împarte munca celorlalți, de multe ori apelându-i ca tool-uri; într-un design cu handoff, agenții își predau controlul direct cu Command(goto=...). Starea comună sau mesajele duc contextul de la unul la altul. Începe cu un singur agent și adaugă alții doar când tool-urile sau instrucțiunile se separă clar.