Harta inteligenței artificiale

120–150 de minute · +60–90 de minute pentru exerciții · Nivel: începător · Fără cunoștințe prealabile

1. Cum descriem corect un sistem

Această secțiune stabilește metoda de lucru pentru întreaga lecție: nu clasificăm un produs după impresia pe care o produce, ci după elementele sale observabile.

Pentru orice aplicație, întreabă mai întâi ce primește, ce transformare execută, cum alege următorul pas și ce acțiuni poate realiza fără aprobare. Aceleași întrebări funcționează pentru un calculator de buzunar, un filtru de spam, un chatbot, un robot industrial sau un agent²⁷ care modifică un repository⁵⁰ (depozitul în care sunt păstrate codul sursă al unui proiect și toate versiunile lui anterioare, astfel încât să se vadă cine ce a modificat și să se poată reveni oricând la o variantă mai veche).

Aceste proprietăți se pot combina în moduri diferite. Un proces poate fi complet automat fără machine learning⁵. Un model foarte performant poate să nu aibă voie să modifice nimic. Un agent²⁷ poate utiliza simultan reguli, baze de date, simulatoare și modele.

Un exemplu în zece secunde: filtrul de spam din e-mailul tău. Intrare: mesajul primit. Transformare: un model învățat din milioane de exemple, plus câteva reguli fixe ale administratorului. Control: o singură predicție per mesaj. Autoritate: mută mesajul într-un folder — atât. Patru răspunsuri scurte și ai clasificat un sistem întreg, fără să pomenești vreun termen de marketing.

2. De ce este necesară această clasificare

Această secțiune arată consecințele practice ale confuziei dintre termeni. O etichetă greșită nu rămâne o problemă de vocabular: ea duce la costuri mai mari, la rezultate mai slabe și la permisiuni care pot periclita securitatea întregului sistem.

De exemplu, dacă o echipă numește „agent²⁷ autonom” o aplicație care doar rezumă un text, va căuta probabil infrastructură, memorie și instrumente³⁰ de care nu are nevoie. Invers, dacă tratează drept simplu chatbot un sistem care poate trimite mesaje, șterge fișiere sau controla procese, acesta poate fi începutul unui incident de securitate cu urmări greu de reparat.

Clasificarea corectă ne ajută să alegem o soluție potrivită — o arhitectură proporțională cu problema: reguli pentru cerințe exacte, modele pentru ambiguitate și percepție, workflow-uri²⁶ pentru procese stabile, agenți²⁷ pentru sarcini în care următorul pas nu poate fi stabilit complet dinainte.

Fără această hartă, echipele ajung frecvent:

• să cumpere un LLM¹⁶ acolo unde ar fi fost de ajuns câteva reguli clare;
• să numească „agent²⁷” un chatbot care nu poate acționa;
• să acorde permisiuni extinse unui agent²⁷ doar fiindcă pare inteligent;
• să încerce să antreneze un model când problema reală este accesul la informații mai bune;
• să folosească generare probabilistică¹¹ pentru calcule care trebuie să fie exacte;
• să automatizeze o decizie periculoasă fără aprobare umană³²;
• să construiască un sistem multi-agent²⁷ pentru o problemă care cere doar un workflow²⁶ cu cinci pași.

Un inginer bun întreabă înainte de a selecta un produs:

1. Ce proprietate trebuie să aibă sistemul? Predicție, generare de conținut, planificare, folosirea instrumentelor³⁰, memorie sau autonomie²⁹?
2. Care este mecanismul cel mai simplu și mai fiabil care oferă acea proprietate?

Principiu de proiectare: folosește componenta cel mai puțin „inteligentă” care poate executa corect un pas. Păstrează modelele pentru ambiguitate, percepție, limbaj și raționament dificil de exprimat prin reguli.

3. De ce termenii nu formează o singură scară

În această secțiune verificăm o reprezentare des întâlnită, dar incorectă: ideea că fiecare termen ar fi pur și simplu o versiune „mai avansată” a celui anterior.

Algoritm → Machine learning → Deep learning → AI generativă → Agent → Autonomie

Șirul de mai sus nu este o definiție și nici o evoluție obligatorie. El amestecă tehnici de calcul — precum machine learning⁵ — cu tipare de control — precum agentul²⁷ — și cu niveluri de permisiune — precum autonomia²⁹. Din acest motiv, un sistem nu poate fi plasat corect pe o singură linie.

3.1 Cele trei întrebări independente

Această subsecțiune transformă problema de clasificare în trei întrebări concrete. Le analizăm separat deoarece un sistem poate folosi un model avansat, poate urma un flux simplu și poate avea totuși autoritate foarte redusă.

Descriere text: clasifică separat (1) ce produce comportamentul, (2) cum este ales pasul următor și (3) ce are sistemul permisiunea să facă. Axele sunt independente.

Cuvântul autonom spune puțin despre inteligență. Un script simplu poate acționa autonom; un model extrem de capabil poate rămâne doar consultativ.

4. Relația dintre AI, machine learning, deep learning și AI generativă

Această secțiune clarifică relația dintre principalele familii tehnice. Inteligența artificială este domeniul larg; machine learning⁵ este una dintre abordările sale, iar rețelele neuronale și deep learning⁷ reprezintă familii mai specifice din interiorul machine learning.

Aceasta este o hartă conceptuală, nu un arbore rigid:

• Statistica⁴ și machine learning⁵ se suprapun.
• Căutarea și planificarea pot funcționa fără modele învățate.
• Nu orice rețea neuronală⁶ este „adâncă” (deep).
• Nu orice foundation model⁸ este generativ; un model de embedding²¹ poate transforma textul, imaginea sau sunetul într-o reprezentare vectorială — o listă de numere folosită pentru compararea asemănărilor — fără să genereze conținut nou.
• Modelele generative existau cu mult înainte de apariția foundation models⁸.
• Automatizarea³ traversează toate ramurile și poate exista fără AI.

5. Conceptele de bază, pe rând

Următoarele subsecțiuni definesc fiecare termen separat. Pentru fiecare concept urmărim aceeași logică: ce problemă descrie, cum funcționează în termeni tehnici, ce poate face bine și cu ce nu trebuie confundat.

Este important să nu sari direct la „agent²⁷”. Agenții sunt construiți din componente mai simple, iar calitatea lor depinde de înțelegerea acestor componente.

5.1 Algoritm

Începem cu algoritmul¹ deoarece orice software, inclusiv un sistem AI, execută proceduri concrete pentru a transforma datele.

Un algoritm¹ este o procedură finită care transformă o intrare într-o ieșire prin operații neambigue. Poate sorta o listă, găsi cel mai scurt drum, comprima un fișier ori calcula un impozit.

Intrare: [7, 2, 9]
Procedură: compară și reordonează valorile
Ieșire: [2, 7, 9]

Un algoritm¹ nu este neapărat AI, nu trebuie să fie învățat din date, nu este automat adaptiv și nu este obligatoriu probabilistic¹¹. Orice sistem ML⁵ folosește algoritmi, dar majoritatea algoritmilor nu sunt machine learning.

5.2 Software bazat pe reguli

Aici vedem cum oamenii pot specifica direct condițiile și acțiunile unui program, fără ca sistemul să învețe din exemple.

Oamenii scriu explicit condițiile și acțiunile:

DACĂ total_factură > limita_aprobare
ATUNCI solicită_aprobarea_managerului

Puncte forte: predictibil, testabil, explicabil, eficient și potrivit pentru constrângeri legale, matematice sau de siguranță.

Puncte slabe: devine fragil în situații cu multe excepții, greu de întreținut când regulile se înmulțesc și slab pentru limbaj, imagini ori ambiguitate brută.

Regulile rămân esențiale în arhitecturile moderne de agenți²⁷. Modelele nu trebuie să înlocuiască restricțiile nenegociabile.

5.3 Automatizare

Această subsecțiune separă execuția fără intervenție umană de ideea de inteligență.

Automatizarea³ înseamnă că un proces rulează cu intervenție umană redusă. Ea descrie execuția, nu inteligența.

Exemple: copierea fișierelor în fiecare noapte, trimiterea unei notificări de reamintire după 14 zile, redimensionarea imaginilor, deploy-ul⁵³ după teste sau mutarea unui tichet prin etape fixe.

Un workflow²⁶ poate conține pași AI fără să devină agent²⁷. Un singur apel către un LLM¹⁶ nu schimbă automat natura controlului.

5.4 Statistică

Statistica⁴ este disciplina care arată câtă încredere poți avea în ceea ce spun datele.

Statistica⁴ oferă metode pentru a înțelege populații, relații, variație și incertitudine din date. Întrebări tipice:

• Este diferența observată semnificativă?
• Cât de incertă este estimarea?
• Ce variabile sunt corelate?
• Ce proces ar fi putut produce observațiile?

Machine learning⁵ pune accentul, de regulă, pe predicție și pe decizii luate asupra unor date noi, pe care modelul nu le-a văzut la antrenare¹³. Domeniile se suprapun puternic; regresia liniară se încadrează firesc în amândouă.

De ce contează pentru un dezvoltator: vei folosi statistică⁴ ori de câte ori interpretezi un test A/B, compari două variante de prompt¹⁵ sau te întrebi dacă îmbunătățirea măsurată e reală ori doar zgomot. Este instrumentul³⁰ care te ferește să tragi concluzii din trei rulări norocoase.

5.5 Machine learning

Machine learning⁵ devine util atunci când regulile complete sunt greu de scris, dar există exemple din care pot fi învățate tipare.

Un sistem își îmbunătățește performanța învățând tipare din exemple, în loc să primească fiecare regulă explicit. O formulare clasică folosește:

Sarcină + experiență + măsură de performanță

Există patru moduri în care un model poate învăța, și ele se deosebesc prin ce fel de material primește:

Antrenare versus inferență

Un model are două etape de viață complet diferite, cu costuri, durate și riscuri diferite. Confundarea lor este una dintre cele mai frecvente surse de neînțelegere.

• Antrenarea¹³ este etapa în care modelul se schimbă. I se dă un set de date pregătit dinainte, iar un algoritm¹ de optimizare parcurge exemplele și corectează, puțin câte puțin, valorile numerice din interiorul modelului — se numesc parametri¹² și sunt, la modelele mari, miliarde de numere. Corecția se face în direcția care reduce greșeala pe exemplele văzute. Antrenarea se face o singură dată, sau rar, când modelul e reantrenat; durează de la ore la săptămâni, cere hardware scump, iar rezultatul ei este un fișier: modelul antrenat.
• Inferența¹⁴ este etapa în care modelul deja antrenat este folosit. Îi trimiți o intrare nouă — un e-mail sosit acum, o fotografie făcută azi, o întrebare scrisă de un utilizator — și el întoarce un rezultat: o etichetă („spam”), un scor („risc 0,83”), un text. În inferența obișnuită, cererea nu modifică parametrii¹² modelului. Aplicația poate totuși să păstreze conversația, starea³¹ sarcinii ori o memorie externă și să le trimită din nou la cererile următoare; asta schimbă contextul pe care îl primește modelul, nu înseamnă că parametrii lui au fost reantrenați din conversație. Inferența se întâmplă de fiecare dată când modelul este apelat și consumă resurse la fiecare cerere.

Rezumat: în antrenare¹³ se modifică parametrii¹² modelului; în inferența¹⁴ obișnuită modelul este aplicat fără ca cererea curentă să-i rescrie parametrii. Sistemul din jur poate însă păstra stare³¹, istoric sau memorie externă și le poate folosi la cererile viitoare. Antrenarea o face, de regulă, echipa care construiește modelul; inferența este costul repetat al folosirii lui. De aceea aproape toate deciziile de arhitectură din acest curs privesc inferența și sistemul construit în jurul modelului.

5.6 Rețele neuronale

Rețelele neuronale sunt o familie de modele machine learning⁵; nu sunt o copie literală a creierului, ci structuri matematice optimizabile.

O rețea neuronală⁶ este o funcție matematică parametrizată, construită din straturi conectate. În timpul antrenării¹³, un algoritm¹ de optimizare ajustează parametrii¹² pentru a reduce eroarea.

Rețelele pot învăța reprezentări interne. În loc să definim manual fiecare trăsătură vizuală a unei pisici, rețeaua poate învăța progresiv trăsături mai abstracte.

O rețea neuronală⁶ nu este un creier digital. Metafora biologică este utilă istoric, dar limitată tehnic.

5.7 Deep learning

Deep learning⁷ duce mai departe rețelele neuronale: mai multe straturi și o capacitate mai mare, care fac posibilă învățarea unor reprezentări complexe.

Deep learning⁷ folosește rețele neuronale⁶ cu multe straturi de transformare. Este deosebit de puternic pentru imagini, voce, limbaj, video, sisteme multimodale și învățarea reprezentărilor la scară mare.

Intuiția adâncimii: primele straturi învață lucruri simple, iar ultimele le combină în concepte tot mai abstracte — la imagini: margini → forme → părți → obiecte. Nimeni nu programează această ierarhie manual; ea apare din antrenare¹³. Exact această capacitate de a-și construi singur reprezentările face deep learning⁷ potrivit pentru date brute și nestructurate.

„Deep” descrie adâncimea arhitecturii, nu înțelepciunea, conștiința ori fiabilitatea.

5.8 Foundation models

Foundation models⁸ sunt modele antrenate pe date și sarcini suficient de largi încât să poată fi reutilizate în multe aplicații. Termenul descrie un rol economic și arhitectural — „fundație pe care se construiește” — nu o arhitectură anume, și nu implică automat un model generativ: modelele de embeddings, de exemplu, sunt foundation models care produc reprezentări numerice, nu text.

Trei proprietăți le definesc în practică:

• antrenare¹³ la scară mare, pe date variate, de regulă auto-supervizată — modelul învață din structura datelor, fără etichete scrise manual pentru fiecare exemplu;
• reutilizare: același model servește sarcini pentru care nu a fost antrenat explicit, prin metodele de adaptare de mai jos;
• omogenizare: multe aplicații moștenesc atuurile și defectele aceluiași model de bază — o eroare sau o părtinire (în engleză bias) din fundație se propagă în tot ce este construit deasupra.

Reutilizarea este avantajul major, dar vine la pachet cu erori moștenite de toate aplicațiile construite peste el, cu un cost de operare permanent, cu întrebări de licențiere și cu o evaluare mai greu de făcut. Un foundation model⁸ poate lucra cu text, imagini, audio, video, cod, structuri științifice ori mai multe modalități simultan.

Metodele de adaptare, de la ieftin la costisitor

Ordinea contează: în practică se începe cu metoda cea mai ieftină care rezolvă problema și se avansează doar cu justificare.

Regula practică a cursului: promptul¹⁵ înaintea RAG-ului¹⁸, RAG-ul înaintea fine-tuningului. Fiecare treaptă adaugă cost, întreținere și risc de regresie*. Treci la treapta următoare numai după ce ai măsurat că cea de dinainte nu îți mai ajunge — nu pentru că pare mai interesantă.

Regresie* înseamnă aici o îmbunătățire care, fără ca cineva să urmărească asta (din greșeală), strică ceva ce mergea bine până atunci. Un model trecut prin fine-tuning¹⁹ răspunde vizibil mai bine la sarcina pentru care a fost specializat, dar poate răspunde mai slab la alte trei sarcini mai vechi, pe care nimeni nu s-a mai gândit să le verifice.

5.9 Inteligență artificială generativă

AI generativă⁹ descrie modele care produc conținut sau structuri noi, nu doar etichete și scoruri.

AI generativă⁹ produce conținut sau ieșiri structurate noi pe baza tiparelor învățate: text, cod, imagini, audio, video, obiecte 3D, molecule, planuri sau JSON (un format text simplu, alcătuit din perechi „nume: valoare”, în care programele își transmit unele altora date structurate; este citibil și de om, și de mașină, motiv pentru care a devenit formatul implicit al comunicării dintre aplicații).

Generarea este probabilistică¹¹. Modelul produce o continuare ori un artefact plauzibil, nu un adevăr garantat.

Cum funcționează, pas cu pas

Ține în minte o singură imagine: un autocomplete uriaș. Telefonul tău îți propune următorul cuvânt după ce a văzut câteva mii de mesaje; un model generativ face același gest după ce a „citit” biblioteci⁴³ întregi — și îl repetă de mii de ori pe secundă. Procesul are patru pași:

1. Antrenare¹³ — învață tiparele. Modelul primește cantități enorme de text, imagini sau sunet și exersează un singur joc: „ghicește fragmentul care urmează”. Milioane de runde ajustează parametrii¹² până când predicțiile devin bune. Modelul nu memorează o bază de date de răspunsuri; comprimă tiparele — cum arată o frază corectă, un contract, o funcție Python, o fotografie plauzibilă.
2. Promptul¹⁵ — primește contextul. Ce îi scrii tu devine începutul pe care trebuie să-l continue. De aceea formularea contează atât de mult: schimbi contextul, schimbi continuarea.
3. Generare — fragment cu fragment. Modelul nu compune răspunsul întreg dintr-o dată. Alege următorul fragment (un cuvânt sau o bucată de cuvânt), îl lipește la context, apoi alege din nou, și din nou — până la condiția de oprire. Fiecare alegere este probabilistică¹¹: dintre continuările plauzibile, una este aleasă. De aceea aceeași întrebare poate primi azi și mâine răspunsuri diferite.
4. Oprire. Un semnal de final, o limită de lungime sau o instrucțiune încheie secvența.

Din această mecanică decurge tot ce trebuie să știi despre punctele forte și despre riscuri: modelul produce continuarea cea mai plauzibilă, nu adevărul verificat. Când plauzibil și adevărat coincid — rezumate, redactare, cod uzual — rezultatul pare magie. Când nu coincid, modelul „halucinează”: afirmă senin lucruri false, pentru că fals-dar-plauzibil câștigă jocul pentru care a fost antrenat. Nu este o defecțiune; este natura mecanismului — și exact motivul pentru care ieșirile care contează se validează cu reguli, calcule sau oameni.

Tabelul de mai jos arată, pe rânduri, ce diferență face întrebarea pusă. Coloana din stânga adună sarcini discriminative: sistemul alege dintr-un set de răspunsuri care există deja — spam sau nu, pisică sau câine, pozitiv sau negativ. Există un răspuns corect, deci rezultatul poate fi verificat și măsurat exact. Coloana din dreapta adună sarcini generative: sistemul produce un conținut care nu exista înainte și pentru care nu există un singur răspuns corect, ci multe variante acceptabile. Pe fiecare rând, cele două coloane pornesc de la același material — același e-mail, aceeași imagine, același document — și diferă doar prin ce i se cere sistemului să facă cu el.

Granița dintre cele două coloane nu este etanșă. Poți cere unui model generativ să facă o sarcină discriminativă: îi scrii pur și simplu „citește e-mailul de mai jos și răspunde cu un singur cuvânt — spam sau curat”, iar el îți întoarce eticheta cerută. Asta se numește clasificare prin prompting: obții un rezultat de clasificator fără să antrenezi vreun clasificator, doar formulând sarcina ca instrucțiune.

Diferența, și motivul pentru care rezultatul trebuie verificat, stă în ce probabilitate este proiectat sistemul să estimeze. Un clasificator dedicat pentru spam produce direct un scor sau o probabilitate pentru clasele relevante — de exemplu „spam” versus „curat” — și poate fi evaluat și calibrat pentru exact această sarcină. Un model lingvistic autoregresiv calculează, în schimb, scoruri și probabilități pentru următorul token posibil. Dacă îi ceri să răspundă numai cu „spam” sau „curat”, folosești această distribuție de tokeni ca mecanism de clasificare. Rezultatul poate fi foarte bun, dar probabilitatea unui token nu este automat o probabilitate calibrată că mesajul este spam. Iar tonul răspunsului nu îți spune cât de sigur este modelul: poate formula la fel de convingător o etichetă corectă și una greșită.

În practică: pentru un prototip sau pentru o sarcină în care o greșeală ocazională nu costă nimic, clasificarea prin prompting este cea mai rapidă soluție. Când corectitudinea contează — bani, siguranță, decizii ireversibile — eticheta obținută astfel se validează: cu reguli, cu un clasificator dedicat sau cu un om.

5.10 Asistent

Un asistent²⁵ este definit în primul rând prin relația cu utilizatorul, nu printr-o anumită tehnologie internă.

„Asistent²⁵” descrie rolul față de utilizator. Sistemul poate răspunde, sugera, redacta, căuta sau organiza. Poate fi un ajutor bazat pe reguli, un chatbot LLM¹⁶, un sistem RAG¹⁸, un agent²⁷ cu instrumente³⁰ sau chiar un operator uman sprijinit de software.

Termenul nu spune automat nimic despre arhitectura internă ori autoritate.

Test rapid: autocomplete-ul din editorul de cod și un chatbot LLM¹⁶ sunt amândoi „asistenți²⁵” — deși unul e un model mic de completare, iar celălalt un foundation model⁸. Eticheta descrie relația cu tine, nu ce e înăuntru. De aceea, când cineva spune „am un asistent AI”, încă nu știi nimic despre cum funcționează sau ce are voie să facă.

În forma lui cea mai simplă, tu conduci interacțiunea: asistentul²⁵ răspunde când îl întrebi, redactează când îi ceri și se oprește după rezultat. Dar „asistent” rămâne o etichetă de rol, nu o definiție a mecanismului intern. Un produs prezentat utilizatorului ca asistent poate avea în interior un workflow²⁶, un sistem RAG¹⁸ sau chiar un agent²⁷ care execută mai mulți pași. De aceea nu clasificăm arhitectura doar din cuvântul „asistent”; verificăm separat cine alege pașii, ce instrumente³⁰ există și ce autoritate are sistemul.

5.11 Workflow — flux de lucru

Un workflow²⁶ organizează pașii unui proces atunci când ordinea și ramificațiile pot fi proiectate dinainte.

Un workflow²⁶ este o succesiune explicită de pași sau o schemă ramificată în care, pentru fiecare pas, se știe dinainte ce poate urma după el.

Descriere text: pasul următor este ales dintre tranzițiile stabilite dinainte. Un workflow²⁶ poate avea ramificații, reîncercări automate după o eroare și pași rezolvați de un model, fără ca prin asta să devină agent²⁷.

Un workflow²⁶ bine proiectat are câteva proprietăți care îl fac valoros în producție:

• ordine și ramificații definite dinainte — fiecare tranziție este scrisă de un om, deci poate fi citită, revizuită și testată înainte de rulare;
• comportament repetabil — aceleași intrări produc aceleași trasee, ceea ce face ca erorile să fie reproductibile și remedierea posibilă;
• reacție clară la erori — un pas care nu reușește duce sistemul într-o situație prevăzută dinainte: se reîncearcă, se oprește sau se cheamă un om. Nu se improvizează nimic;
• urmă verificabilă — se poate răspunde oricând, exact, la întrebarea „ce pas a rulat, cu ce date și cu ce rezultat”;
• controlul versiunilor (versionare) — orice schimbare a procesului este o schimbare de cod sau de configurație, care rămâne vizibilă în istoricul proiectului: se vede cine a modificat, ce a modificat și când, iar la nevoie se poate reveni la varianta anterioară.

Workflow²⁶-urile sunt alegerea corectă atunci când procesul este cunoscut și stabil: procesarea facturilor, generarea rapoartelor, pipeline-uri de date, aprobări care parcurg pași ficși. Devin insuficiente când pasul următor depinde de rezultate imprevizibile — acolo începe teritoriul agentului²⁷ din secțiunea următoare. Multe sisteme reale sunt hibride: un schelet de workflow determinist¹⁰, în care doar anumiți pași sunt delegați unui model, fiecare urmat de validare.

Un detaliu de vocabular: în unele produse, „workflow²⁶” numește și scheme care se pot întoarce din drum și pot alege singure ce urmează — adică pași care se reiau și ramificații hotărâte în timpul rulării, nu dinainte. Pentru arhitecturile software moderne, în acest curs păstrăm o distincție operațională utilă: dacă toate tranzițiile sunt proiectate dinainte, spunem workflow; dacă sistemul alege dinamic cel puțin o parte dintre acțiunile următoare în funcție de obiectiv, stare³¹ și feedback, spunem agent²⁷. Sensul clasic, mai larg, al termenului „agent” este explicat în secțiunea următoare.

Avantaje: trasee predictibile, audit³⁶ clar, testare mai simplă, cost controlat, evaluare de conformitate mai ușoară și risc mai mic decât în cazul unei autonomii necontrolate.

5.12 Agent

„Agent²⁷” are un sens larg în inteligența artificială clasică și un sens operațional mai îngust în multe aplicații software moderne. Declararea sensului folosit evită contradicțiile dintre manuale, framework-uri⁴³ și documentația furnizorilor.

În sens larg, un agent²⁷ operează într-un mediu pentru a urmări un obiectiv: primește observații și selectează acțiuni. Mecanismul poate fi o regulă fixă, un algoritm¹ de căutare, o politică învățată prin reinforcement learning sau un model de limbaj.

Un agent²⁷ software modern conține, de regulă:

1. un obiectiv sau o sarcină;
2. observații de la utilizator, din fișiere, de la API-uri⁴⁸ sau alte instrumente³⁰;
3. un mecanism de decizie — componenta care alege pasul următor. De cele mai multe ori este un model de limbaj (LLM¹⁶), dar poate fi la fel de bine un set de reguli, un algoritm¹ de planificare sau un model antrenat special pentru sarcina respectivă;
4. acțiuni sau instrumente³⁰ permise;
5. stare³¹ despre progres;
6. o buclă care inspectează rezultatul și alege o altă acțiune;
7. o condiție de oprire, de aprobare sau de solicitare a intervenției unui om.

Descriere text: obiectiv → observă → decide → acționează → inspectează rezultatul → verifică oprirea sau aprobarea → continuă ori finalizează.

Pentru agentul²⁷ software modern, ideea esențială este că cel puțin o parte dintre pași sunt aleși în timpul rulării, în funcție de stare³¹ și de observații, în loc să fie executată o singură secvență fixă. Un agent clasic poate fi mult mai simplu — chiar reflex și determinist¹⁰ — motiv pentru care declarăm întotdeauna sensul atunci când clasificăm un caz-limită.

Nu orice agent²⁷ are nevoie de un LLM¹⁶. Inteligența artificială clasică lucra cu agenți cu mult înainte de modelele de limbaj: agenți reflex, care răspund direct la ce percep, după reguli fixe; agenți de planificare, care își construiesc dinainte un lanț de acțiuni către obiectiv; agenți de joc, care aleg mutarea explorând variantele posibile; și agenți antrenați prin întărire (RL), care își învață comportamentul din recompense și penalizări.

Invers este la fel de adevărat: folosirea unui LLM¹⁶ nu transformă automat un program în agent²⁷. Când trimiți un paragraf unui model și primești înapoi un rezumat, ai făcut o singură cerere — o intrare, o ieșire, gata. Nu ai stabilit niciun obiectiv de urmărit mai departe, nu ai pus la dispoziție niciun instrument³⁰, nu ai lăsat în urmă nicio memorie a ceea ce s-a întâmplat înainte și nu ai prevăzut niciun moment în care sistemul să decidă singur dacă merge mai departe sau se oprește. Este un apel către un model, nu un agent.

Citește bucla de mai sus încă o dată: ea descrie agentul²⁷ software modern pe care îl vom construi în curs. Traseul complet nu este stabilit dinainte. Sistemul primește un obiectiv, inspectează situația, încearcă o acțiune, verifică rezultatul și abia atunci decide ce urmează. Tocmai această alegere bazată pe feedback îl face util acolo unde toate ramurile nu pot fi proiectate convenabil dinainte.

5.13 Sistem autonom

Autonomia²⁹ nu descrie cât de inteligent este sistemul, ci câtă autoritate are să acționeze fără o confirmare imediată.

Autonomia²⁹ se judecă întotdeauna împreună cu alte patru lucruri: cât de ușor pot fi anulate acțiunile, ce impact au, cât de bine se vede din afară ce face sistemul și cât de largi sunt permisiunile primite.

6. Cele mai importante diferențe

Această secțiune pune conceptele în perechi deoarece cele mai multe confuzii apar între termeni apropiați. Pentru fiecare pereche analizăm exact criteriul care îi separă.

6.1 AI versus automatizare

Comparația separă capacitățile asociate inteligenței de simpla execuție automată a unui proces.

• AI descrie capabilități precum învățarea, percepția, raționamentul sau limbajul.
• Automatizarea³ descrie rularea unui proces fără ca un om să execute fiecare pas.

Un backup nocturn este automatizat, dar nu are nimic inteligent în el. Un model care recomandă un diagnostic poate folosi AI, rămânând complet consultativ.

6.2 Machine learning versus AI generativă

Comparația separă învățarea de tipare din date de producerea unor ieșiri noi.

Machine learning⁵ este domeniul mai larg al sistemelor care învață tipare. AI generativă⁹ este familia care produce secvențe sau artefacte noi. Un exemplu lămurește diferența: sistemul care dă fiecărei tranzacții cu cardul o notă de risc — „cât de probabil este ca plata asta să fie o fraudă” — este machine learning. A învățat din milioane de tranzacții trecute, marcate ca frauduloase sau curate, iar acum produce un număr pentru fiecare plată nouă. Nu este AI generativă, pentru că nu creează niciun conținut nou: doar evaluează ceva ce există deja.

6.3 Model versus agent

Comparația separă componenta care produce predicții sau text de sistemul complet care urmărește un obiectiv și utilizează instrumente³⁰.

• Un model transformă o intrare într-o ieșire.
• Un agent²⁷ organizează decizii și acțiuni în timp.

Modelul poate fi doar o componentă din agent²⁷.

6.4 Workflow versus agent

Comparația arată dacă traseul execuției este proiectat dinainte sau ales dinamic în funcție de observații.

Workflow-ul²⁶ urmează o cale prestabilită; agentul²⁷ alege dintre acțiuni pe baza observațiilor și obiectivului. Produsele mai complexe combină frecvent cele două abordări: workflow-ul ține procesul sub control, iar agentul se ocupă de porțiunea ambiguă, cea care nu putea fi proiectată dinainte.

6.5 Asistent versus agent

Comparația separă interfața orientată către utilizator de arhitectura internă de control.

„Asistent²⁵” descrie relația cu utilizatorul; „agent²⁷” descrie arhitectura de control. Un asistent poate fi agent sau nu. Un agent poate lucra fără interfață conversațională.

6.6 Agentic versus autonom

Comparația separă comportamentul de selectare a acțiunilor de permisiunea efectivă de a le executa.

„Agentic²⁷” indică folosirea unui mecanism asemănător agentului: planificare, instrumente³⁰, buclă de observație și acțiune. „Autonom” indică permisiunea efectivă de a acționa fără aprobare. Un sistem poate fi agentic și totuși blocat la fiecare acțiune importantă.

7. Metodă practică de clasificare

În continuare vom transforma definițiile într-o procedură repetabilă: șapte întrebări, puse mereu în aceeași ordine, care clasifică orice sistem software — indiferent de numele lui comercial.

Pasul 0 — delimitează sistemul. Metoda se aplică software-ului, nu obiectelor fizice. O pâine sau o ladă de cartofi nu au „comportament” — dar software-ul din jurul lor are: magazinul online care primește comenzi de legume, casa de marcat care aplică TVA, motorul care recomandă „clienții au cumpărat și…”. Înainte de orice întrebare, spune exact ce bucată de software analizezi și unde îi sunt granițele: ce intră în ea, ce iese din ea și ce sisteme atinge. Abia apoi întrebările au sens.

Prin comportament înțelegem tot ce face sistemul ca reacție la intrări: ce ieșiri produce (un număr, o etichetă, un scor, un text, o imagine) și ce acțiuni execută (salvează, trimite, modifică, pornește ceva). Întrebarea „ce produce comportamentul?” nu se referă deci la personalitatea produsului, ci la mecanismul din spatele acestor reacții.

Întrebarea 1 — Ce produce comportamentul sistemului?

Privește mecanismul care transformă intrarea în ieșire:

• reguli explicite — cod scris de oameni: „dacă totalul depășește 100 de lei, cere aprobare”;
• metode statistice — praguri și relații calculate din date: „blochează tranzacția dacă suma e de 10 ori peste media clientului”;
• model învățat — parametri¹² ajustați prin antrenare¹³ pe exemple: filtrul de spam care a văzut milioane de e-mailuri etichetate;
• o combinație — cazul cel mai frecvent în produsele reale.

Cum afli: citește documentația tehnică și caută formulări precum „trained on”, „rule-based” sau „threshold”; uită-te la configurație și la ce date cere sistemul ca să funcționeze.

Întrebarea 2 — Ce produce sistemul?

Acum privește ieșirea, nu mecanismul:

• un calcul exact — TVA-ul unei facturi;
• o etichetă sau un scor — „spam”, „0,93 probabilitate de fraudă”;
• o recomandare — „ai putea adăuga și roșii la comandă”;
• face conținut nou — redactează e-mailul, generează imaginea, dar se oprește aici: rezultatul rămâne la tine;
• acționează pe baza noului conținut — chiar trimite e-mailul, chiar scrie în baza de date, chiar plătește factura.

Diferența dintre ultimele două este granița cea mai importantă din întreaga lecție: a propune nu este totuna cu a face.

Întrebarea 3 — Cum este ales pasul următor?

• există un singur răspuns — o funcție pură: intră numerele, iese suma;
• pașii sunt fixați — scriptul de backup rulează aceiași pași în fiecare noapte;
• există ramuri⁵¹ prestabilite — „dacă lipsește data, cere data; altfel continuă”;
• sistemul alege dinamic — după fiecare observație decide singur ce încearcă în continuare, în funcție de obiectiv.

Indiciul practic pentru agenții²⁷ software moderni: întreabă cine a stabilit traseul complet al pașilor. Dacă toate tranzițiile au fost scrise de un om dinainte, ai un workflow²⁶. Dacă sistemul alege în timpul rulării cel puțin o parte dintre acțiunile următoare pe baza obiectivului, stării³¹ și feedbackului, ai comportament de agent în sensul operațional modern. În sensul clasic, mai larg, pot exista și agenți reflex deterministici; de aceea cazurile-limită trebuie etichetate cu definiția folosită.

Întrebarea 4 — Are instrumente?

Un instrument³⁰ este orice poate fi apelat: o bază de date, un calculator, un sistem de fișiere, un API⁴⁸ de plăți. Accesul la instrumente crește simultan utilitatea și riscul. Dar un singur apel de instrument nu dovedește un agent²⁷: contează cine alege instrumentul și dacă rezultatul lui influențează pasul următor.

Întrebarea 5 — Păstrează stare?

Starea³¹ înseamnă că sistemul ține minte unde a ajuns: pași executați, rezultate intermediare, un plan, o sesiune. Un formular cu „pasul 2 din 4” are stare; un calculator de buzunar nu are. Fără stare nu există progres; fără progres nu există buclă reală — iar un agent²⁷ fără memorie despre propriul progres repetă sau se contrazice.

Întrebarea 6 — Ce autoritate are?

• doar răspunde — îți arată scrisoarea;
• pregătește o acțiune — scrisoarea este gata, tu apeși „trimite”;
• acționează după aprobare — trimite după ce confirmi;
• acționează automat în limite — trimite singur, dar numai către adrese interne;
• are permisiuni largi — trimite oricui, oricând.

Cum afli: autoritatea se citește din permisiunile reale — chei API⁴⁸, drepturi de scriere, acces la rețea — nu din felul în care arată interfața.

Întrebarea 7 — Cum se oprește?

Caută o condiție explicită: obiectiv atins, buget de pași epuizat, timp expirat, eroare, cerere de aprobare, rezultat imposibil sau nevoia de intervenție umană. În producție, întrebarea matură nu este „cât de deștept este sistemul?”, ci „când și cum se oprește?”. Fără o oprire clară, o buclă nu este pregătită pentru lumea reală.

Metoda aplicată: magazinul online de legume

Să răspundem la confuzia firească „dar dacă eu vând cartofi?”. Cartoful nu se clasifică; software-ul din jurul lui, da. Delimităm sistemul: motorul de recomandări al magazinului.

1. Ce produce comportamentul? Un model învățat din istoricul comenzilor.
2. Ce produce? O recomandare — „clienții care au luat cartofi au luat și varză”.
3. Cum alege pasul următor? Un singur răspuns per pagină afișată; nicio buclă.
4. Are instrumente³⁰? Doar citește catalogul; nu modifică nimic.
5. Păstrează stare³¹? Da — istoricul clientului.
6. Ce autoritate are? Doar recomandă; clientul decide.
7. Cum se oprește? După fiecare afișare.

Concluzie: machine learning⁵ + control simplu + autoritate consultativă. Nu este agent²⁷, oricât de „inteligent” ar părea în reclamă.

Aplică acum aceleași șapte întrebări casei de marcat din același magazin și obții un profil complet diferit: reguli explicite în loc de model învățat, un calcul exact în loc de o recomandare, zero autonomie²⁹. Două mecanisme care nu seamănă deloc — și totuși același verdict: nici unul, nici celălalt nu este agent²⁷. Exact asta face metoda utilă. Nu întreabă cât de avansată este tehnologia din spate, ci cine alege pașii și cine are voie să acționeze; iar la aceste două întrebări casa de marcat și motorul de recomandări răspund la fel, deși unul învață din date și celălalt doar aplică reguli scrise de oameni.

8. Cazuri-limită

Cazurile-limită sunt importante deoarece unele sisteme pot fi descrise corect în mai multe moduri, în funcție de granițele pe care le alegem. Scopul nu este să memorăm un răspuns unic, ci să ne declarăm ipotezele.

9. Principiu arhitectural: sistemele hibride câștigă

În aplicațiile reale, rezultatele cele mai bune provin de obicei din distribuirea responsabilităților între modele probabilistice¹¹, cod determinist¹⁰, date verificate și oameni.

Produsele fiabile rareori folosesc aceeași tehnică peste tot.

Un sistem puternic poate folosi:

• reguli pentru permisiuni și câmpuri obligatorii;
• ML⁵ pentru a depista abaterile de la normal — o plată neobișnuit de mare, un consum ieșit din tipar;
• un foundation model⁸ pentru limbaj;
• retrieval pentru cunoștințe private și actuale;
• calculator ori simulator pentru calcule exacte;
• workflow²⁶ pentru pași verificabili și urmă clară a execuției;
• agent²⁷ pentru coordonare flexibilă;
• om pentru judecată cu impact mare.

Principiul practicii moderne: plasează inteligența probabilistică¹¹ în interiorul unor limite deterministe¹⁰.

10. Mituri frecvente

Această secțiune verifică afirmații des întâlnite în marketing și conversații informale. Fiecare mit este reformulat într-un criteriu tehnic care poate fi testat.

Mitul 1 — AI înseamnă machine learning

Machine learning⁵ este o abordare majoră, dar planificarea, căutarea, optimizarea, logica simbolică și sistemele de reguli fac și ele parte din istoria și practica AI.

Prin urmare, AI nu înseamnă doar machine learning⁵: este un domeniu mult mai larg, iar o bună parte din el nu învață absolut nimic din date.

Mitul 2 — Orice aplicație LLM este agent

Un apel de model nu reprezintă o buclă de agent²⁷. Când o aplicație trimite un text unui LLM¹⁶ și afișează răspunsul primit, ea a făcut o singură cerere: nu urmărește niciun obiectiv mai departe, nu alege instrumente³⁰, nu ține minte unde a ajuns și nu decide dacă mai continuă. Întrebarea corectă nu este „folosește un model de limbaj?”, ci „cine alege pasul următor și pe baza a ce observă?”. Un editor de text care rescrie un paragraf la cerere folosește exact același model ca un agent de programare — și totuși unul este o funcție, iar celălalt un sistem care lucrează singur.

Prin urmare, într-o aplicație LLM¹⁶ modernă nu numim sistemul agent²⁷ doar fiindcă folosește un model: căutăm un obiectiv urmărit în timp, stare³¹ sau feedback despre progres și alegerea dinamică a cel puțin unei părți din pașii următori. Instrumentele³⁰ apar frecvent atunci când sistemul trebuie să acționeze sau să obțină informații externe.

Mitul 3 — Mai multă autonomie înseamnă mai multă inteligență

Autonomia²⁹ este permisiunea de a acționa. Un script simplu poate fi autonom; un model sofisticat poate rămâne consultativ.

Prin urmare, inteligența și autonomia²⁹ sunt două axe diferite: se pot combina în orice fel, iar creșterea uneia nu o ridică niciodată pe cealaltă.

Mitul 4 — Regulile sunt depășite

Regulile rămân cea mai bună reprezentare pentru multe calcule, permisiuni, constrângeri și cerințe de siguranță.

Prin urmare, regulile nu sunt o etapă depășită, ci exact partea pe care nu vrei să o lași la latitudinea unui model: acolo unde răspunsul trebuie să fie exact și identic de fiecare dată, regula rămâne soluția corectă.

Mitul 5 — Agentul trebuie să fie chatbot

Agenții²⁷ pot opera prin API-uri⁴⁸, joburi de fundal, roboți, terminal, sisteme industriale sau fără conversație vizibilă.

Prin urmare, conversația este doar o interfață posibilă, nu o condiție: cei mai mulți agenți²⁷ din producție nu vorbesc cu nimeni.

Mitul 6 — Agentul este modelul

Modelul este adesea o singură componentă. Agentul²⁷ are și orchestrare, instrumente³⁰, stare³¹, permisiuni, evaluări și condiții de oprire.

Prin urmare, modelul este piesa care decide, dar agentul²⁷ este întregul montaj din jurul ei — iar cea mai mare parte din muncă stă în montaj, nu în model.

Mitul 7 — Primul pas este antrenarea

Majoritatea agenților²⁷ specializați trebuie să înceapă cu un model existent, instrumente³⁰ bune, retrieval, instrucțiuni și evaluări. Antrenarea¹³ devine justificată după identificarea unei limitări măsurate.

Prin urmare, antrenarea¹³ nu este primul pas, ci ultimul: se justifică abia după ce ai măsurat o limitare pe care instrucțiunile, instrumentele³⁰ și retrieval-ul* nu o pot acoperi.

Retrieval* înseamnă căutarea automată a informației relevante în surse externe — documentele firmei, o bază de date, un set de fișiere — și adăugarea fragmentelor găsite în cererea trimisă modelului. Modelul nu învață nimic nou: primește pur și simplu, odată cu întrebarea, textul de care are nevoie ca să răspundă.

Mitul 8 — Multi-agent este automat mai bun

Mai mulți agenți²⁷ adaugă erori de coordonare, latență, cost și dificultăți de observabilitate. Începe cu un agent sau workflow²⁶ determinist¹⁰ și adaugă specializare doar când valoarea poate fi măsurată.

Prin urmare, mai mulți agenți²⁷ nu înseamnă automat un sistem mai bun: pornește de la unul singur și adaugă al doilea abia când poți arăta, cu cifre, ce câștigi.

11. Provocare interactivă: clasifică 25 de sisteme

Această activitate verifică dacă poți aplica simultan cele trei axe. Pentru fiecare sistem bifează toate etichetele pe care le consideri potrivite. Unele cazuri acceptă o etichetă opțională atunci când este justificată printr-o definiție mai largă. Citește întâi ce înseamnă exact fiecare etichetă — sunt aceleași șase pe care le vei folosi la toate cele 25 de întrebări.

Cum interpretezi scorul

Scorul măsoară coerența față de definițiile folosite în această lecție, nu valoarea ta ca inginer. Dacă un răspuns diferă, citește explicația și verifică dacă ai confundat sursa comportamentului, modul de control sau autoritatea.

• 90–100%: clasificarea este foarte solidă; concentrează-te pe cazurile opționale.
• 70–89%: baza este bună, dar revizuiește diferențele model–agent²⁷ și workflow²⁶–autonomie²⁹.
• sub 70%: reia secțiunile 3, 5 și 6 și încearcă activitatea din nou.

12. Exercițiu de proiectare: folosește sistemul cel mai simplu

În acest exercițiu nu căutăm tehnologia cea mai spectaculoasă, ci mecanismul minim care rezolvă corect fiecare etapă a unei probleme.

O companie vrea software care să proceseze bonuri și chitanțe de cheltuieli.

Cerințe posibile:

1. Respinge fișierele mai mari de 20 MB.
2. Extrage comerciantul, data, totalul și moneda.
3. Verifică dacă totalul este egal cu suma pozițiilor.
4. Cere clarificări când încrederea este redusă.
5. Salvează înregistrarea aprobată.
6. Notifică departamentul contabil.

O arhitectură slabă trimite totul unui singur LLM¹⁶ și îi cere „ocupă-te de chitanță”. O arhitectură mai bună atribuie fiecărei cerințe mecanismul potrivit:

Sistemul poate deveni agentic²⁷ ulterior, dacă trebuie să aleagă între mai multe strategii de recuperare. Nu are nevoie de autonomie²⁹ largă pentru a fi util.

12.1 Patru exemple de domeniu

13. Previzualizare de produse și tehnologii

Produsele de mai jos apar la niveluri diferite ale arhitecturii. Tabelul nu le recomandă încă; arată doar ce tip de problemă rezolvă fiecare categorie.

Pentru această lecție, citește tabelul doar pe primele două coloane: ce nevoie are un proiect și ce familie tehnologică răspunde acelei nevoi. Coloana a treia este trecută aici ca să știi că produsele există, nu ca să le reții acum și cu atât mai puțin ca să alegi ceva. Ne întoarcem la acest tabel după Lecția 4, când vom lega fiecare nevoie și de programele concrete care o rezolvă.

Nu selecta încă stack-ul⁵⁸ final. Lecția 3 mapează stack-ul complet, iar Lecția 4 decodează numele produselor.

14. Notă de securitate și guvernanță

Orice creștere a autorității trebuie însoțită de limite, aprobări, jurnalizare și condiții clare de oprire. Inteligența modelului nu înlocuiește aceste mecanisme.

Cât de periculos este un sistem AI nu se măsoară după cât de „uman” sună, ci după ce poate atinge în realitate. Un model care vorbește impecabil, dar nu are acces la nimic, nu poate provoca pagube; un program banal, cu drepturi mari, poate. Riscul real îl stabilesc răspunsurile la aceste șapte întrebări:

• Ce date poate citi? Doar informații publice sau și contracte, dosare de personal, date medicale, baza de clienți?
• Ce credențiale³³ deține? Credențialele sunt parolele, cheile de acces și token-urile date sistemului. Fiecare credențială primită este o ușă în plus pe care o poate deschide singur.
• Ce instrumente³⁰ poate apela? Numai o căutare, sau și trimiterea unui e-mail, o plată, ștergerea unui fișier, pornirea unui utilaj?
• Acțiunile lui pot fi anulate? Un text scris greșit se rescrie în cinci minute; un transfer bancar executat sau un e-mail plecat către cinci mii de clienți, nu. Aceasta este reversibilitatea³⁴: cât de ușor se dă înapoi ce s-a făcut.
• Cine aprobă acțiunile cu impact mare? Există un om care confirmă înainte de execuție, sau sistemul acționează singur și anunță după?
• Cum se observă că a greșit? Există verificări automate care prind eroarea în aceeași zi, sau se află abia când reclamă un client?
• Ce dovezi rămân în urmă? Logurile — jurnalele de execuție — sunt înregistrarea a ce a făcut sistemul, când, la cererea cui și cu ce rezultat. Fără ele, un incident nu poate fi nici explicat, nici demonstrat.

Un asistent²⁵ care vorbește impecabil, dar nu are niciun instrument³⁰ la dispoziție, este de regulă mai puțin periculos în practică decât un script de zece linii care rulează cu drepturi de administrator. Fluența impresionează oamenii; permisiunile schimbă lumea.

Pentru fiecare agent²⁷ viitor, completează:

DATE:       Ce poate citi?
INSTRUMENTE: Ce poate apela?
AUTORITATE: Ce poate modifica?
LIMITĂ:     Unde este izolat?
APROBARE:   Ce acțiuni cer om?
OPRIRE:     Cum este oprit?
AUDIT:      Ce dovezi se păstrează?

15. Exerciții

Exercițiile te obligă să aplici harta asupra unor sisteme reale și asupra propriilor idei, nu doar să repeți definițiile.

Exercițiul A — Desenează schema noțiunilor

Ia o foaie și un creion și desenează o schemă care arată cum se leagă între ele noțiunile de mai jos: care intră una în alta, care se suprapun doar parțial și care nu se cuprind deloc, ci se folosesc una pe alta. Nu contează cât de frumos desenezi; contează ce spun formele și săgețile pe care le pui. Lucrează din memorie și abia la final verifică.

Folosește o notație simplă și ține-te de ea peste tot în desen:

• pătrat sau dreptunghi — o familie de tehnici, adică un fel de a produce comportamentul: AI, reguli, statistică⁴, machine learning⁵, deep learning⁷ și așa mai departe;
• cerc — o proprietate care se poate atașa oricărei tehnici, nu o tehnică în sine: automatizare³, autonomie²⁹;
• formă în interiorul altei forme — incluziune completă: „tot ce este X este și Y”;
• forme care se suprapun parțial — doar o parte dintre elemente sunt comune;
• săgeată — o relație de folosire, nu de apartenență: „se sprijină pe”, „apelează”, „este construit peste”. Scrie pe fiecare săgeată, în două-trei cuvinte, ce relație reprezintă.

Construiește schema în patru pași:

1. Incluziunile. Începe cu termenii care se cuprind unul pe altul și desenează-i ca forme concentrice. Pune în interiorul dreptunghiului de AI și acele familii care nu învață nimic din date — sunt și ele AI, chiar dacă nu sunt machine learning⁵.
2. Suprapunerile. Există perechi care nu se cuprind, dar au parte comună: nu tot ce este generativ este un foundation model⁸ și nu tot ce este foundation model generează conținut; statistica⁴ și machine learning-ul⁵ împart metode, fără ca una să fie inclusă în cealaltă. Desenează-le ca forme care se intersectează și hașurează zona comună.
3. Ce nu intră în niciun dreptunghi. Doi termeni din listă nu descriu o tehnică, ci o proprietate a sistemului: câtă intervenție umană mai există și cât are voie sistemul să facă singur. Desenează-i ca cercuri așezate deasupra schemei, nu în interiorul ei, și marchează cu o săgeată faptul că se pot atașa la orice formă de dedesubt — inclusiv la sisteme complet lipsite de AI.
4. Relațiile de folosire. Leagă prin săgeți termenii care descriu sisteme — asistent²⁵, workflow²⁶, agent²⁷ — de ceea ce folosesc ele: modele, instrumente³⁰, pași stabiliți dinainte. Din desen trebuie să reiasă limpede ce are agentul în plus față de asistent și față de workflow.

Când ai terminat, schema ta trebuie să poată răspunde, fără niciun cuvânt în plus, la patru întrebări: unde se află granița dintre AI și machine learning⁵; de ce automatizarea³ nu este o felie din AI; ce anume adaugă agentul²⁷ peste un asistent²⁵; și care sunt perechile de termeni care se suprapun fără ca unul să îl conțină pe celălalt.

Abia acum întoarce-te la secțiunile 3.1, 4 și 17 și compară. Nu căuta desenul „identic cu al lecției” — două scheme corecte pot arăta diferit. Caută doar locurile în care ai desenat o incluziune acolo unde există de fapt o suprapunere, ori o apartenență acolo unde este doar o relație de folosire: acelea sunt exact paragrafele care merită recitite.

Cheia instructorului — o variantă corectă de schemă

Desenul de mai jos este o rezolvare posibilă, nu singura. Compară-l cu al tău la nivel de relații, nu de aspect: dacă ai desenat aceleași incluziuni, aceleași suprapuneri și aceleași săgeți, schema ta este corectă chiar dacă arată complet altfel.

Ce trebuie să se regăsească în desen. Incluziunile se așază astfel: rețelele neuronale sunt o familie de machine learning⁵, deep learning⁷ este partea lor cu multe straturi, iar foundation models⁸ sunt modele de deep learning antrenate larg. Software-ul bazat pe reguli stă tot în interiorul AI, dar în afara machine learning-ului — este AI care nu învață nimic din date.

Suprapunerile. AI generativă⁹ și foundation models⁸ se intersectează fără ca una s-o conțină pe cealaltă: există foundation models care produc mai ales reprezentări, nu conținut, și există sisteme generative construite altfel. LLM-ul¹⁶ cade în zona comună. Statistica⁴ se suprapune cu machine learning⁵ prin metodele împărțite, dar are și o parte proprie, care nu ține de AI.

Cercurile de deasupra. Automatizarea³ și autonomia²⁹ nu sunt tehnici, ci proprietăți: se leagă prin linii punctate de workflow²⁶, de software-ul bazat pe reguli și de agent²⁷ — inclusiv de sisteme fără nicio urmă de AI. Acesta este punctul în care greșesc cei mai mulți: le desenează înăuntrul dreptunghiului de AI.

Săgețile de folosire. Asistentul²⁵ folosește un model pentru a formula răspunsul; workflow-ul²⁶ urmează pași stabiliți dinainte; agentul²⁷ raționează cu un model, folosește instrumente³⁰ și poate include în el workflow-uri întregi — în plus față de amândouă, alege pasul următor în limitele primite. Dacă din desenul tău reiese această diferență, ai înțeles secțiunile 6.3–6.5.

Exercițiul B — Apără un caz-limită

Alege unul dintre cele patru sisteme de mai jos și scrie 150–250 de cuvinte despre motivul pentru care este sau nu agent²⁷. Începe prin a declara definiția pe care o folosești, fiindcă de ea depinde răspunsul.

• Termostatul inteligent — citește temperatura și pornește sau oprește încălzirea după un prag.
• Motorul de șah — analizează mutările posibile și o alege pe cea mai bună pentru a câștiga partida.
• Asistentul²⁵ cu RAG¹⁸ — asistentul care, înainte de a răspunde, caută fragmente în documentele firmei și le adaugă în context, apoi formulează răspunsul pe baza lor (retrieval-augmented generation, explicat în secțiunea 5.8). Reține că el nu ține minte nimic între două întrebări și nu execută nicio acțiune în afara răspunsului.
• Aspiratorul robotic — se deplasează singur prin cameră, ocolește obstacolele și se întoarce la stație când bateria scade.

Exercițiul C — Renunță la AI acolo unde nu ajută

Alege un proces de muncă sau din viața zilnică. Împarte-l în pași și alocă fiecăruia una dintre opțiuni:

• regulă;
• algoritm¹ software obișnuit;
• model statistic;
• model ML⁵;
• model generativ;
• workflow²⁶;
• decizie de agent²⁷;
• decizie umană.

Încearcă să reduci folosirea modelelor fără să reduci capabilitatea.

Exercițiul D — Scara autonomiei

Proiectează cinci versiuni ale unui agent²⁷ de e-mail, de la consultativ la autonomie²⁹ largă. Pentru fiecare nivel, notează riscul nou introdus de autoritatea suplimentară.

Exercițiul E — Începe profilul agentului tău

Răspunde într-un paragraf:

• Pentru cine este agentul²⁷?
• Ce rezultat trebuie să îmbunătățească?
• Ce informații poate folosi?
• Ce acțiuni ar putea executa în viitor?
• Ce acțiuni trebuie întotdeauna aprobate?

Păstrează răspunsurile: în laborator le vei scrie într-un fișier numit docs/agent-profile.md, în folderul proiectului pe care îl creezi la secțiunea 3. Este o fișă scurtă, în format text, cu utilizatorul vizat, rezultatul urmărit, sursele pe care agentul²⁷ le-ar putea citi, acțiunile pe care le-ar putea pregăti și acțiunile care cer obligatoriu aprobarea unui om.

Fișierul acesta nu rămâne un exercițiu de lecție: el este primul document al proiectului pe care îl construim din lecție în lecție, salvat în Git încă din prima zi. Îl vei deschide și completa din nou pe măsură ce agentul²⁷ capătă instrumente³⁰, memorie și autoritate — iar când vei ajunge să-i dai voie să acționeze singur, tot din el vei citi ce ai declarat, la început, că trebuie aprobat de om.

Exercițiul F — Găsește greșeala: MightyAgent™

O pagină fictivă de produs afirmă:

MightyAgent™ este un agent²⁷ de raționament complet autonom. Utilizatorul trimite un paragraf, LLM-ul¹⁶ îl rezumă, iar rezumatul apare pe ecran. Fiindcă modelul este generativ, sistemul este autonom. Învață din fiecare cerere, planifică cea mai bună succesiune de instrumente³⁰ și garantează răspunsuri factuale. Nu sunt necesare aprobări sau limite de securitate, fiindcă nu are corp robotic.

Identifică minimum șase afirmații incorecte sau nesusținute. Pentru fiecare dintre ele precizează:

1. termenul folosit greșit;
2. dovezile necesare pentru justificare;
3. cum ar trebui numit sistemul descris de fapt.

16. Quiz cu răspunsuri explicate

Răspunde mai întâi în minte sau în scris. Apoi deschide răspunsul imediat sub întrebare și compară nu doar concluzia, ci și criteriul folosit.

17. Recapitulare: harta într-o singură pagină

Regula inginerească: folosește mecanismul cel mai simplu și mai fiabil pentru fiecare pas. Combină modele, reguli, instrumente³⁰, workflow-uri²⁶ și oameni, în loc să forțezi un singur model să facă totul.

Vocabular esențial

Recitește definițiile după parcurgerea lecției — acum fiecare termen are context. Sunt grupate în patru familii: cum ia sistemul deciziile, cum se construiesc și se folosesc modelele, cum se controlează comportamentul lor și ce infrastructură apare în jurul lor. Termenii explicați pe parcursul lecției, sub tabele, apar și aici, cu detalii în plus. Apasă pe numărul de lângă un termen ca să ajungi la explicația lui; butonul Înapoi al browserului te duce înapoi unde citeai.

Cum ia sistemul deciziile

Modele: antrenare, folosire și adaptare

Control, autoritate și siguranță

Infrastructura și instrumentele de lucru

18. Referințe și surse istorice

• Alan Turing, Computing Machinery and Intelligence (1950).
• Tom M. Mitchell, Machine Learning⁵ (1997).
• Stuart Russell și Peter Norvig, Artificial Intelligence: A Modern Approach.
• Ian Goodfellow, Yoshua Bengio și Aaron Courville, Deep Learning⁷.
• Ashish Vaswani și colaboratorii, Attention Is All You Need (2017).
• Rishi Bommasani și colaboratorii, On the Opportunities and Risks of Foundation Models⁸ (2021).
• NIST, Artificial Intelligence Risk Management Framework⁴³.
• Dartmouth College, istoria proiectului din 1956
• IBM, istoria programului de dame al lui Arthur Samuel
• Cornell University, Frank Rosenblatt și perceptronul