Ce este un LLM și de ce are nevoie de context extern

Pui o întrebare simplă unui LLM: „care e politica de retur pentru comenzile B2B?”. Primești un răspuns fluent, structurat, cu termene și excepții. Sună exact ca politica firmei tale. Doar că nu e. Modelul n-a văzut niciodată documentul respectiv și a produs ceva plauzibil în locul lui.

Nu e un bug. E consecința directă a felului în care funcționează un LLM: un motor care prezice text plauzibil pe baza a ceea ce a văzut în antrenament, nu un sistem care caută într-o bază de date. Iar în momentul în care întrebarea depinde de informație pe care modelul n-a avut-o niciodată — datele tale, prețurile de luna asta, contractul semnat marțea trecută — singura soluție e să-i pui informația în față, la momentul întrebării.

Asta înseamnă „context extern”. Articolul de față explică mecanismul: ce e un LLM, unde stă de fapt ce știe, de ce cunoașterea îngheață la o dată fixă, de ce modelul inventează în loc să tacă și ce se schimbă concret când adaugi context. Arhitectura care face asta sistematic — cum alegi ce documente intră, cum le găsești, cum le legi de răspuns — e subiectul pasului următor: ce este RAG.

Ce este un LLM, pe scurt

Un LLM (large language model) este un model statistic antrenat pe volume mari de text, cu un singur obiectiv de bază: să prezică următoarea bucată de text dintr-o secvență. Atât. Tot ce pare inteligență conversațională — sinteză, traducere, cod, raționament pas cu pas — iese din exersarea intensivă a acestei sarcini, plus o etapă ulterioară de aliniere care îl învață să răspundă util și în format de dialog.

Predicție, nu căutare

Când trimiți o întrebare, modelul nu deschide un index și nu execută un lookup. Transformă textul în token-uri (fragmente de cuvinte), le trece prin rețea și produce o distribuție de probabilitate peste tot vocabularul: care e cel mai probabil token următor. Alege unul, îl adaugă la secvență, reia. Răspunsul de 400 de cuvinte pe care îl citești e rezultatul a câteva sute de astfel de decizii înlănțuite.

Diferența e fundamentală pentru orice decizie de business. Un motor de căutare care nu găsește nimic îți returnează zero rezultate. Un model care „nu găsește” nimic tot produce un token următor — pentru că asta e singura operație pe care o știe. Nu există stare de „nu am date”.

Ce sunt, de fapt, parametrii

Un model „de 7 miliarde de parametri” înseamnă 7 miliarde de numere reale, ajustate în timpul antrenamentului. Nu sunt fapte, nu sunt propoziții, nu sunt înregistrări. Sunt greutăți care determină cum se transformă un vector de intrare în altul, strat după strat.

Toate cunoștințele modelului — că Bucureștiul e capitala României, cum se scrie un for în Python, ce ton are un e-mail formal — sunt codificate difuz în aceste numere. Nu există un loc anume unde „scrie” un fapt. Există o configurație de greutăți care, pentru un anumit tipar de intrare, face ca un anumit token să devină cel mai probabil.

Ce iese din antrenament

Rezultatul e un motor de continuare plauzibilă, foarte bun la tipare generale și inegal la fapte specifice. E excelent la formă: structură, ton, limbaj, cod idiomatic. E nesigur la conținut: dacă faptul cerut a fost rar sau absent în datele de antrenament, modelul îl aproximează în loc să-l recupereze.

Această asimetrie — formă solidă, conținut inegal — explică aproape toate surprizele neplăcute din proiectele AI interne. Demo-ul arată impecabil pentru că formularea e impecabilă. Problema apare când cineva verifică cifrele.

Memoria parametrică: unde stă ce știe modelul

Termenul tehnic pentru ce știe un model din antrenament este memorie parametrică — cunoașterea stocată în greutăți. E util să înțelegi cum se comportă, pentru că se comportă foarte diferit de o bază de date.

Cunoașterea trăiește în greutăți, nu în rânduri

Cercetarea de interpretabilitate a arătat că straturile feed-forward ale unui transformer funcționează ca niște memorii cheie-valoare: fiecare „cheie” corelează cu tipare textuale din exemplele de antrenament, iar fiecare „valoare” induce o distribuție peste vocabularul de ieșire. Aceste straturi feed-forward reprezintă două treimi din parametrii unui model transformer, ceea ce dă o intuiție utilă despre unde se duce capacitatea.

Practic: modelul recunoaște un tipar din întrebarea ta și activează un amestec de „amintiri” care împing probabilitatea spre anumite token-uri. Nu e o interogare. E o recunoaștere de tipar care se traduce în ieșire.

Capacitatea e finită și se fixează la antrenare

Cât încape acolo? Un studiu controlat pe seturi de date sintetice a estimat că modelele pot stoca aproximativ 2 biți de cunoaștere factuală per parametru, chiar și cuantizate la int8. Lucrări ulterioare au revizuit estimarea în sus, spre 3-4 biți per parametru — deci cifra exactă e încă în dispută, dar concluzia structurală nu e: capacitatea are o limită, iar limita e atinsă în timpul antrenamentului.

Ce contează pentru tine e implicația operațională. Modelul nu poate „mai învăța ceva” în timpul unei conversații. Ca să schimbi memoria parametrică, trebuie să reantrenezi sau să adaptezi modelul — un proces cu cost, latență de zile sau săptămâni și riscuri proprii. Compararea celor două drumuri (adaptare de model vs. adăugare de context) e discutată separat în RAG vs fine-tuning.

Nu poți interoga memoria parametrică în ambele sensuri

Cel mai clar semn că nu ai de-a face cu o bază de date: memoria parametrică nu e simetrică. Un model antrenat pe „A este B” nu deduce automat „B este A” — fenomen documentat sub numele de reversal curse.

Cifrele sunt sugestive. Într-un test pe celebrități reale, GPT-4 a răspuns corect la întrebări de tipul „cine e mama lui Tom Cruise?” în 79% din cazuri, față de 33% pentru întrebarea inversă, „cine e fiul lui Mary Lee Pfeiffer?”. Într-un tabel relațional, cele două interogări sunt aceeași linie citită din direcții diferite. Într-un LLM, sunt două tipare complet distincte, învățate independent.

Detaliul care contează cel mai mult: dacă „A este B” apare în context, modelele deduc relația inversă fără probleme. Aceeași informație, pusă în prompt în loc să fie căutată în greutăți, devine brusc utilizabilă în ambele sensuri.

Knowledge cutoff: data la care cunoașterea îngheață

Antrenamentul se face pe un set de date colectat până la un moment dat. Acel moment se numește knowledge cutoff. După el, modelul nu mai acumulează nimic: nu citește știri, nu urmărește modificări legislative, nu vede că ți-ai schimbat prețurile.

Cutoff declarat vs. cutoff efectiv

Furnizorii publică o dată de cutoff pentru fiecare model. E o aproximare utilă, dar nu e o graniță curată. Cercetarea a introdus noțiunea de cutoff efectiv — data reală până la care modelul chiar cunoaște un anumit domeniu — și a arătat că cutoff-urile efective diferă adesea drastic de cele declarate.

Explicația ține de cum se construiesc seturile de antrenament: dump-urile noi de CommonCrawl conțin cantități semnificative de date vechi, iar schemele de deduplicare se complică din cauza duplicatelor semantice și a celor lexicale apropiate. Rezultatul e un orizont de cunoaștere neuniform — mai proaspăt pe unele subiecte, mai vechi pe altele, fără ca tu să poți ști care e care dinainte.

Ce înseamnă asta pentru un proiect intern

Consecința practică e mai dură decât pare. Nu e vorba doar că modelul nu știe ce s-a întâmplat luna trecută. E vorba că nu ai cum să validezi de la ce dată încolo să nu ai încredere, pe fiecare subiect în parte. Un răspuns despre o normă tehnică poate fi actualizat până anul trecut; unul despre altă normă, cu doi ani mai vechi. Ambele sună la fel de sigure pe ele.

Iar pentru datele tale, discuția nici nu se pune. Documentația internă, istoricul de tichete, contractele, catalogul de produse — nimic din toate astea n-a fost vreodată în vreun set public de antrenament. Nu e o problemă de cutoff. E o absență completă.

De ce inventează un model când nu știe

Termenul consacrat e halucinație: o afirmație plauzibilă, formulată cu încredere, care e falsă. E cea mai citată obiecție în orice discuție de adopție și merită înțeleasă mecanic, nu ca pe un defect misterios.

Nu e un glitch, e presiune statistică

O lucrare publicată de cercetători OpenAI argumentează că modelele halucinează pentru că procedurile de antrenament și de evaluare recompensează ghicitul în locul recunoașterii incertitudinii și că halucinațiile nu au nimic misterios: apar ca erori de clasificare binară, iar dacă afirmațiile false nu pot fi distinse de fapte, ele apar natural din presiuni statistice.

Cu alte cuvinte: modelul nu „minte”. Produce cea mai probabilă continuare într-o situație în care nicio continuare nu e susținută de date. Forma corectă a răspunsului e ceea ce a învățat; conținutul e completat cu ce se potrivește tiparului.

Evaluările recompensează ghicitul

Partea a doua a argumentului e despre stimulente. Halucinațiile persistă din cauza felului în care sunt notate majoritatea evaluărilor: modelele sunt optimizate să fie buni candidați la examen, iar ghicitul atunci când ești nesigur îmbunătățește scorul. Un test grilă care dă zero puncte și pentru „nu știu”, și pentru un răspuns greșit, face din ghicit strategia rațională.

Merită reținut și corolarul contraintuitiv semnalat în aceeași lucrare: un model mic care nu cunoaște deloc un domeniu poate pur și simplu să spună „nu știu”, în timp ce un model care știe ceva trebuie să-și estimeze încrederea — deci un model mai capabil nu e automat unul mai prudent. Cum separi capabilitatea generală de fidelitatea față de sursă atunci când alegi între modele e tratat în cum alegi modelul de generare pentru un sistem RAG.

Coada lungă e exact acolo unde stau datele tale

Aici devine concret pentru un proiect intern. Cercetarea pe memorare factuală a arătat că modelele se descurcă slab cu informația factuală mai puțin populară, că augmentarea prin retrieval ajută semnificativ exact în aceste cazuri și că scalarea îmbunătățește în principal memorarea cunoștințelor populare, fără să amelioreze apreciabil coada lungă.

Citește propoziția asta cu ochii unei firme. Datele tale operaționale sunt definiția cozii lungi: apar într-un singur loc, într-un singur format, la o singură organizație. Un model mai mare nu le va ști mai bine, pentru că nu e o problemă de capacitate — e o problemă de absență din date. Ai nevoie de alt mecanism, nu de alt model.

Ce înseamnă, mecanic, „context extern”

Aici e pivotul articolului. Dacă memoria parametrică e fixă, incompletă și inaccesibilă direct, singurul canal prin care poți introduce informație nouă într-un răspuns e prompt-ul: textul pe care modelul îl primește odată cu întrebarea.

Prompt-ul ca memorie de lucru

Distincția utilă e între cunoașterea din greutăți și informația din intrare. Prima e permanentă și imuabilă la runtime. A doua e temporară, dar are un avantaj decisiv: modelul o poate folosi direct, în forma în care i-o dai, fără să fi văzut-o vreodată în antrenament. E același mecanism care rezolvă reversal curse-ul de mai sus.

Spațiul disponibil pentru asta nu e infinit și se administrează ca un buget — cum decizi ce intră și ce rămâne afară e discutat în detaliu în fereastra de context la LLM.

Trei căi prin care intră context extern

În practică, informația ajunge în prompt pe trei drumuri, cu proprietăți diferite:

• Documente recuperate dintr-o sursă proprie — fragmente din documentația internă, contracte, tichete rezolvate, articole de knowledge base. Sunt selectate în funcție de întrebare, chiar înainte ca modelul să fie apelat.
• Rezultate de la un tool sau un API — soldul unui cont, statusul unei comenzi, prețul curent din ERP. Sunt date live, generate la momentul întrebării, nu stocate undeva ca text.
• Date structurate injectate direct — profilul utilizatorului, rolul lui, limba, contractul pe care e încadrat. Nu vin dintr-o căutare, ci din sesiune.

Diferența dintre ele nu e cosmetică. Prima cale cere un mecanism de selecție — cum alegi exact fragmentele relevante dintr-un corpus mare, prin căutare semantică sau prin alte metode. Celelalte două sunt determinate: știi exact ce ceri și de unde.

Ce se schimbă în răspuns

Când contextul e prezent și corect, se schimbă trei lucruri simultan:

1. Acoperirea — modelul poate răspunde la întrebări despre lucruri pe care nu le-a văzut niciodată în antrenament.
2. Prospețimea — răspunsul reflectă starea de acum, nu starea de la cutoff.
3. Verificabilitatea — dacă știi ce fragmente au intrat în prompt, poți arăta pe ce s-a bazat răspunsul. Asta e diferența dintre „modelul zice” și „documentul X, secțiunea 4, zice”.

Al treilea punct e cel subestimat în deciziile de adopție. Într-un context B2B, un răspuns corect fără sursă și un răspuns inventat arată identic pentru cel care îl citește.

Context extern nu garantează un răspuns corect

Ar fi comod ca lucrurile să se oprească aici: pui documentele în prompt, primești adevărul. Nu funcționează așa, iar diferența dintre a înțelege asta și a o descoperi în producție e de obicei un trimestru pierdut.

Conflictul dintre context și memorie

Când informația din prompt contrazice ce a învățat modelul la antrenament, apare ceea ce literatura numește knowledge conflict. Un survey dedicat identifică trei categorii: conflictul context-memorie, conflictul între diferite fragmente de context și conflictul intern al memoriei parametrice.

Comportamentul modelului în astfel de situații nu e garantat. Poate să prefere contextul, poate să se agațe de ce știa, poate să amestece cele două. Iar dacă îi dai zece fragmente dintre care două se contrazic între ele, nu ai niciun mecanism implicit care să decidă care câștigă.

Context greșit, răspuns greșit, aceeași încredere

Un model care primește un fragment învechit sau irelevant îl va folosi cu exact același ton sigur pe sine. Adăugarea de context mută problema — nu o elimină. Calitatea răspunsului devine o funcție de calitatea selecției, iar modurile în care selecția eșuează în practică sunt tratate separat în de ce eșuează un sistem RAG în producție.

Cine plătește când modelul se înșală

Există deja jurisprudență pe subiect. Într-un caz devenit referință, un tribunal canadian a obligat Air Canada la plata a 812,02 dolari daune și cheltuieli după ce chatbot-ul de pe site a oferit informații incorecte despre eligibilitatea pentru tarife de deces, ducând clientul la o plată în plus. Tribunalul a considerat compania responsabilă pentru informația prezentată de chatbot, respingând argumentul că acesta ar fi o entitate juridică separată, și a calificat eroarea drept declarație eronată din neglijență.

Suma e derizorie. Precedentul, nu. Un răspuns generat de sistemul tău e un răspuns al firmei tale, cu tot ce decurge din asta — motiv pentru care într-un context de asistență pentru clienți discuția despre surse și trasabilitate nu e un detaliu tehnic, ci o cerință.

De la context extern la un sistem

Rezumatul mecanicii, pus într-un tabel:

Coloana din mijloc e miezul: adăugarea de context rezolvă problema accesului la informație, nu problema deciziei. Rămâne întrebarea grea — cum alegi automat, pentru fiecare întrebare, exact fragmentele care contează dintr-un corpus de zeci de mii de documente, și cum legi răspunsul de ele.

Arhitectura care rezolvă sistematic această întrebare are un nume și un tipar consacrat. De aici începe ghidul despre ce este RAG, pilonul acestui cluster: cum se construiește lanțul de la întrebare la fragmente și de la fragmente la răspuns citabil. Restul subiectelor conexe — de la mecanica vectorilor la evaluare — sunt grupate în hub-ul Fundamentele RAG, iar contextul de business mai larg în zona de integrări AI și sisteme RAG.

Întrebări frecvente

Un model mai mare rezolvă problema datelor lipsă?

Nu. Scalarea îmbunătățește în principal memorarea informației populare și nu ameliorează apreciabil coada lungă. Datele interne ale unei firme sunt, prin definiție, coada lungă — nu apar în seturile publice de antrenament indiferent cât de mari sunt.

Care e diferența dintre a da context și a face fine-tuning?

Contextul intră în prompt la momentul întrebării și e temporar; fine-tuning-ul modifică greutățile și e permanent. Primul e potrivit pentru informație care se schimbă des și trebuie citată. Al doilea, pentru comportament, ton și formate recurente. Compararea completă e în articolul dedicat despre RAG vs fine-tuning.

Dacă modelul are acces la internet, mai are nevoie de context extern?

Da. Căutarea web rezolvă doar informația publică. Documentația ta internă, istoricul de comenzi și contractele nu sunt indexate nicăieri — trebuie livrate explicit, dintr-o sursă pe care o controlezi.

Pot să-i spun modelului pur și simplu „nu inventa”?

Ajută, dar nu e suficient. Instrucțiunea de abținere reduce frecvența, nu o duce la zero, pentru că presiunea spre a produce un răspuns e statistică, nu comportamentală. Fără fragmente sursă în prompt și fără un mod de a verifica răspunsul, instrucțiunea rămâne o rugăminte. Mecanismele care o transformă în constrângere — grounding ca arhitectură, citare la nivel de frază, abținere calibrată — sunt detaliate în cum reduce RAG halucinațiile.

Cum știu dacă răspunsul s-a bazat pe documentele mele sau pe memoria modelului?

Numai printr-un sistem construit să-ți arate asta: ce fragmente au intrat în prompt și ce parte din răspuns se sprijină pe ele. Dacă interfața nu îți expune sursele, nu ai cum să faci distincția — răspunsul corect și cel fabricat arată identic.

Pasul următor

Ai acum mecanica: un LLM prezice text pe baza a ce a văzut, cunoașterea lui e fixată și incompletă, iar informația ta ajunge la el pe un singur canal — promptul. Următoarea întrebare e cum construiești canalul acela ca sistem, nu ca improvizație. Începe cu ghidul despre RAG, apoi vezi restul clusterului în Fundamentele RAG.