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 se folosește, fără să se mai schimbe deloc. Îi trimiți o intrare pe care nu a văzut-o niciodată în antrenare — un e-mail nou sosit, 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. Parametrii rămân neatinși: modelul nu învață nimic din cererea ta. Inferența se întâmplă de fiecare dată când cineva apasă un buton, durează de la milisecunde la câteva secunde și costă la fiecare cerere, la nesfârșit.

Rezumat: în antrenare modelul este modificat; în inferență modelul este doar aplicat. Antrenarea o face, de regulă, echipa care construiește modelul; inferența o plătește cel care rulează aplicația, de fiecare dată când este folosită. De aceea aproape toate deciziile de arhitectură din acest curs privesc inferența.

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.

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 se întâmplă dedesubt. Un clasificator antrenat special pentru spam calculează o probabilitate pe baza tiparelor pe care le-a învățat exact pentru sarcina asta. Modelul generativ nu calculează nimic de acest fel: el generează cuvântul cel mai plauzibil după instrucțiunea ta, iar „spam” apare pentru că este continuarea cea mai probabilă a textului, nu pentru că s-a măsurat ceva. De cele mai multe ori cele două coincid și răspunsul este corect. Când nu coincid, modelul spune „curat” cu exact aceeași siguranță în ton — nu primești niciun semnal că de data asta a 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ă.

Ce definește totuși un asistent, dincolo de tehnologie: tu conduci interacțiunea. Asistentul răspunde când îl întrebi, redactează când îi ceri, propune când îl consulți — și se oprește. Nu urmărește un obiectiv de unul singur între întrebările tale, nu își face planuri și nu execută acțiuni din proprie inițiativă. Ritmul este întrebare–răspuns, iar responsabilitatea acțiunii rămâne la tine.

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. În acest curs păstrăm distincția: dacă tranzițiile sunt proiectate dinainte, este workflow; dacă sistemul alege dinamic acțiunea următoare în funcție de obiectiv, este agent.

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

Un agent apare atunci când sistemul urmărește un obiectiv și trebuie să aleagă dinamic cel puțin o parte dintre acțiuni.

Un agent operează într-un mediu pentru a urmări un obiectiv. Primește observații, selectează acțiuni și interoghează ori modifică mediul.

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ă.

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ă.

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ă, pentru că în ea stă toată diferența: agentul nu știe dinainte ce pași va face. Primește un obiectiv, se uită la situație, încearcă ceva, se uită la rezultat și abia atunci decide ce urmează. Pașii se nasc din întâlnirea cu realitatea, nu dintr-un scenariu scris dinainte — iar asta îl face valoros exact acolo unde scenariile nu pot fi scrise.

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: întreabă cine a scris ordinea pașilor. Un om, dinainte — sau sistemul, în timpul rulării? Abia a doua variantă indică un agent.

Î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, o aplicație devine agent abia când capătă obiectiv, instrumente, stare și dreptul de a decide singură pasul următor — nu în clipa în care începe să folosească un LLM.

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.

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