Fereastra de context la LLM: cum decizi ce intră în prompt

Un model lingvistic nu ține minte nimic între două cereri. Tot ce știe despre situația ta în momentul în care răspunde încape într-o singură fereastră de text: fereastra de context. Ce nu intră acolo pur și simplu nu există pentru model.

De aici pornesc aproape toate deciziile de arhitectură dintr-un sistem AI serios. Câte documente recuperezi. Cât de mari faci fragmentele. Cât istoric de conversație păstrezi. Când trimiți fișierul întreg și când cauți întâi în el. Toate sunt, în fond, decizii de alocare a unui buget limitat.

Furnizorii au tot mărit bugetul — de la 128.000 de tokeni în sus, cu modele de top care anunță peste un milion. Concluzia pripită ar fi că problema s-a rezolvat de la sine. Nu s-a rezolvat. Capacitatea anunțată și lungimea pe care modelul chiar o folosește bine sunt două lucruri diferite, iar diferența e măsurabilă în benchmark-uri publice.

Mai jos: ce este fereastra de context, ce o consumă în practică, de ce se degradează calitatea înainte să se umple și cum construiești un buget de prompt pe care îl poți apăra cu cifre.

Ce este, de fapt, fereastra de context

Fereastra de context este numărul maxim de tokeni pe care un model îi poate procesa într-o singură cerere. Nu doar întrebarea ta — tot: instrucțiunile de sistem, definițiile de tools, istoricul conversației, documentele atașate, întrebarea curentă și spațiul rezervat pentru răspuns.

E o limită tehnică, nu o preferință. Peste ea, cererea nu pleacă.

Confuzia cea mai frecventă e că fereastra ar fi un fel de memorie a modelului. Nu e. Fiecare apel la API e independent. Când un chatbot „își amintește" ce ai spus acum zece mesaje, asta se întâmplă pentru că aplicația retrimite tot istoricul la fiecare tur. Modelul nu reține nimic; tu plătești de fiecare dată transportul.

Tokenul nu e cuvânt

Modelele nu citesc litere sau cuvinte, ci tokeni: fragmente de text obținute prin segmentare statistică. Un token poate fi un cuvânt scurt, o silabă, un semn de punctuație sau un spațiu.

Regula de aproximare care circulă peste tot — un token ≈ 0,75 cuvinte — vine din engleză și e valabilă doar pentru engleză. Tokenizatoarele modelelor comerciale au fost antrenate preponderent pe text englezesc, iar limbile mai slab reprezentate plătesc un „premium de tokenizare": același conținut, mai mulți tokeni.

Cercetarea lui Petrov și colegii a măsurat sistematic acest decalaj pe 200 de limbi și a arătat că tokenizatoarele centrate pe engleză sunt departe de paritate — chiar și portugheza, una dintre limbile cele mai apropiate, cere cu circa 50% mai mulți tokeni pentru același conținut. Un studiu din 2026 pe text juridic ucrainean a cuantificat consecința directă: un decalaj de 1,6× între cel mai eficient și cel mai puțin eficient tokenizator înseamnă 60% mai mulți tokeni per document, 60% cost în plus la același tarif și o fereastră de context efectiv mai mică proporțional.

Pentru română, concluzia practică e simplă: nu presupune paritate cu engleza, măsoară. Ia 20 de documente reprezentative din corpusul tău, treci-le prin tokenizatorul modelului pe care îl folosești și calculează raportul tokeni/caractere. Diferența dintre 3,5 și 2,2 caractere per token schimbă complet ce încape în buget și cât te costă lunar.

Un detaliu care surprinde echipele românești: diacriticele corecte pot fi tokenizate diferit față de variantele fără diacritice, iar textul amestecat (jumătate cu ș/ț, jumătate fără) fragmentează inconsistent. Normalizează înainte de indexare, nu după.

Ce se întâmplă când depășești limita

Trei comportamente, în ordinea gravității:

• Eroare explicită — API-ul refuză cererea. Neplăcut, dar onest: știi imediat ce s-a întâmplat.
• Trunchiere — framework-ul taie ce nu încape, de obicei de la începutul istoricului. Rezultatul e un model care „uită" brusc instrucțiuni date mai devreme.
• Trunchiere silențioasă — cel mai periculos caz. Un SDK aruncă mesaje vechi fără să te anunțe, iar tu vezi doar răspunsuri care se degradează treptat, fără nicio eroare în log-uri.

Dacă rulezi ceva în producție, tratează bugetul de tokeni ca pe o resursă monitorizată: numără tokenii înainte de trimitere, loghează totalul și alertează la depășirea unui prag. E un contor de zece linii de cod care îți economisește zile de debugging.

Anatomia unui prompt real

Într-o demonstrație, promptul e o întrebare de două rânduri. În producție, arată complet altfel — și rareori te uiți la el ca la un întreg.

Rezerva de output nu e opțională

Fereastra e partajată între ce trimiți și ce primești. Dacă modelul are 200.000 de tokeni și tu vrei un răspuns de 4.000, bugetul real de input e 196.000 — nu 200.000.

Sună trivial până când construiești un agent care generează rapoarte lungi. Acolo, plafonul de output devine constrângerea dominantă, iar fiecare tur suplimentar retrimite tot istoricul acumulat până atunci.

Istoricul e cel care te omoară

O conversație de suport tehnic care începe la 2.000 de tokeni ajunge, după 30 de schimburi, la 25.000-40.000. Creșterea e liniară în mesaje, dar costul cumulat e pătratic: la turul N retrimiți tot ce s-a spus în turele 1 până la N-1.

Un calcul rapid, cu tarife rotunde de 3 USD per milion de tokeni de input: o conversație de 30 de ture care crește de la 2K la 40K înseamnă circa 600K de tokeni cumulați, adică 1,8 USD — pentru o singură conversație. Înmulțit cu 5.000 de conversații pe lună, ajungi la 9.000 USD doar din istoric retrimis. Cifra exactă depinde de model și de tarifele curente, dar ordinul de mărime e cel care contează la planificare.

Definițiile de tools sunt un cost ascuns

Fiecare funcție pe care o expui modelului intră în prompt cu numele, descrierea și schema completă a parametrilor. Douăzeci de tools bine documentate pot ocupa 4.000-8.000 de tokeni, trimiși la fiecare apel, indiferent dacă modelul folosește vreunul.

Nu e un argument să elimini tools — e un argument să le grupezi și să le expui condiționat, în funcție de intenția detectată.

Ce rămâne pentru conținutul propriu-zis

După instrucțiuni, tools, istoric și rezerva de output, spațiul rămas pentru documentele recuperate e adesea mult mai mic decât credeai. Într-un sistem de suport tipic, dintr-o fereastră de 128K îți rămân realist 60-80K pentru context recuperat — și, cum vezi mai jos, nici nu vrei să-i umpli.

De ce o fereastră mare nu e gratis

Trei taxe se plătesc simultan când crește lungimea promptului: cost, latență și — surprinzător pentru mulți — acuratețe.

Costul crește liniar, la fiecare cerere

Tokenii de input se facturează de fiecare dată când îi trimiți. Un system prompt de 8.000 de tokeni, la 100.000 de apeluri pe lună, înseamnă 800 de milioane de tokeni facturați doar pentru instrucțiuni care nu se schimbă niciodată.

Diferența de tarif între modele complică și mai mult calculul: umplerea aceleiași ferestre de un milion de tokeni poate costa sub un dolar pe un model economic și de zeci de ori mai mult pe unul premium. Dacă vrei să vezi cum se așază toate liniile de cost într-un sistem complet — embeddings, stocare vectorială, inferență, operare — structura de costuri a unui sistem RAG e desfășurată separat, pe linii.

Latența crește cu faza de prefill

Înainte să scrie primul token, modelul trebuie să proceseze tot inputul. Faza asta, prefill, scalează cu lungimea promptului și se vede direct în time-to-first-token.

Pentru un chatbot cu utilizatori care așteaptă în fața ecranului, diferența dintre 800 ms și 4 secunde până la primul cuvânt e diferența dintre un produs folosit și unul abandonat. Un context de trei ori mai lung nu îți dă un răspuns de trei ori mai bun, dar îți dă aproape sigur o așteptare vizibil mai lungă.

Calitatea scade înainte să se umple fereastra

Partea contraintuitivă. Nu e vorba de depășirea limitei, ci de degradare treptată cu mult sub ea.

Cercetarea clasică pe subiect, „Lost in the Middle" (Liu și colegii, TACL 2024), a arătat o curbă de performanță în formă de U: modelele folosesc bine informația de la începutul și de la sfârșitul contextului, dar semnificativ mai slab pe cea din mijloc. Aceiași autori au observat că performanța cititorului în întrebări open-domain se saturează devreme — în jur de 20 de documente recuperate — și că adăugarea altora nu mai aduce nimic.

Benchmark-ul NoLiMa (Adobe Research, 2025) a mers mai departe și a eliminat suprapunerea lexicală dintre întrebare și fragmentul-țintă, ca să testeze recuperarea reală, nu potrivirea de cuvinte. Din 13 modele care anunță cel puțin 128K tokeni, 11 au coborât sub 50% din propriul scor de referință la doar 32K. Autorii definesc „lungimea efectivă" ca fiind cel mai lung context la care modelul păstrează minimum 85% din scorul său de bază — și, pentru majoritatea modelelor testate, lungimea efectivă e cu un ordin de mărime sub cea anunțată.

Raportul Chroma din 2025, „Context Rot", a testat 18 modele de frontieră și a găsit același tipar la toate: acuratețea scade pe măsură ce inputul crește, chiar și la sarcini banale, iar scăderea nu e uniformă. Distractorii — fragmente pe aceeași temă care nu răspund totuși la întrebare — amplifică efectul mult mai mult decât conținutul complet irelevant.

Tradus în decizii de arhitectură: raportul semnal-zgomot din prompt contează mai mult decât volumul. Cinci fragmente relevante bat cincizeci de fragmente dintre care cinci sunt relevante — la cost mai mic, latență mai mică și acuratețe mai mare.

Fereastră mare nu înseamnă că retrieval-ul a devenit inutil

Argumentul „acum că modelul citește un milion de tokeni, arunci toate documentele în prompt și scapi de complexitate" e tentant. Practic, se lovește de toate cele trei taxe de mai sus deodată.

Dacă termenii de bază nu îți sunt încă familiari, pornește de la ce înseamnă RAG și când merită — restul secțiunii presupune vocabularul acela.

Ce câștigi cu retrieval

• Semnal-zgomot — trimiți fragmentele relevante, nu tot corpusul. Exact axa pe care benchmark-urile arată că se câștigă acuratețe.
• Cost — 5.000 de tokeni recuperați în loc de 500.000 aruncați în prompt e o reducere de două ordine de mărime, la fiecare cerere.
• Prospețime — actualizezi un document în index și efectul e imediat, fără reprocesare.
• Control de acces — filtrezi la nivel de recuperare ce are voie să vadă utilizatorul curent. Într-un prompt monolitic, filtrarea asta nu există.
• Trasabilitate — știi ce fragmente au stat la baza răspunsului și poți cita sursa.

Când contextul lung chiar câștigă

Nu tot timpul retrieval-ul e răspunsul corect:

• Un singur document coerent — un contract de 60 de pagini pe care trebuie să-l analizezi integral. Fragmentarea rupe referințele interne.
• Raționament global — „care sunt contradicțiile dintre aceste trei politici?" nu e o întrebare de recuperare, e una de sinteză peste tot materialul.
• Sarcini care depind de structură — ordinea clauzelor, numerotarea, referințele încrucișate.
• Prototipare rapidă — până validezi ipoteza, un prompt monolitic e mai ieftin de construit decât o pipeline de indexare.

Hibridul e default-ul rezonabil

Tiparul care funcționează în majoritatea sistemelor din 2026: recuperezi agresiv, apoi raționezi pe ce ai recuperat. Retrieval-ul reduce corpusul de la milioane de tokeni la zeci de mii; fereastra mare îți permite să lucrezi confortabil cu acele zeci de mii, fără să tai fragmente utile de dragul spațiului.

Alegerea între adaptarea modelului și alimentarea lui cu context extern e o decizie separată, cu criterii proprii — comparația dintre RAG și fine-tuning o ia punct cu punct.

Cum construiești bugetul de prompt

Un buget de prompt e o alocare explicită, scrisă undeva, a fiecărei secțiuni din fereastră. Nu „încape, e ok" — cifre, plafoane și un comportament definit când se depășesc.

Pasul 1 — pornește de la fereastra efectivă, nu de la cea anunțată

Ia numărul din documentația furnizorului și taie-l serios. Dacă modelul anunță 200K, planifică pentru 40-60K de context util și tratează restul ca marjă. Ai apoi două opțiuni: crezi benchmark-urile publice sau îți construiești propriul test — introduci o informație-cheie la diferite adâncimi în corpusul tău real și măsurezi la ce lungime începe modelul să o rateze. A doua variantă durează o zi și îți dă un număr valabil pentru datele tale, nu pentru un corpus sintetic.

Pasul 2 — rezervă output-ul înainte de orice

Fixează max_tokens la ce îți trebuie realist și scade-l din start. Un răspuns de suport are nevoie de 500-800 de tokeni; un raport generat, de 4.000-8.000. Diferența schimbă tot restul alocării.

Pasul 3 — fixează plafoane per secțiune

Un exemplu de alocare pentru un asistent intern de documentație, cu o fereastră efectivă asumată de 60.000 de tokeni:

Marja nu e risipă. E spațiul care absoarbe un document neobișnuit de mare sau o conversație care o ia razna, fără să pice cererea.

Pasul 4 — măsoară, nu estima

Loghează, pentru fiecare cerere: tokeni per secțiune, total input, total output, latență. După o săptămână vei ști exact care secțiune consumă disproporționat. În aproape toate sistemele pe care le vezi în practică, răspunsul e istoricul conversației sau fragmentele recuperate care nu au fost niciodată filtrate serios.

Pasul 5 — leagă bugetul de o metrică de calitate

Reducerea contextului fără măsurarea calității e o optimizare oarbă. Rulează un set de întrebări de referință înainte și după fiecare schimbare de buget și urmărește ce se întâmplă cu acuratețea răspunsurilor — metricile de retrieval și de generare îți dau exact instrumentarul.

Tehnici care te ajută să încapi

Reranking și top-k mic

Recuperezi 50 de candidați, îi reordonezi cu un model de reranking și trimiți în prompt doar primii 5-8. Câștigi de două ori: mai puțini tokeni și un raport semnal-zgomot mai bun. E cea mai rentabilă schimbare pe care o poți face într-o pipeline existentă — cum combini căutarea lexicală cu cea semantică și cum adaugi reranking e un subiect în sine.

Fragmente de dimensiune potrivită

Fragmentele prea mari cară balast în prompt; cele prea mici pierd contextul necesar înțelegerii. Dimensiunea potrivită depinde de tipul documentului, iar strategiile de fragmentare fac diferența între un buget respectat și unul depășit constant.

Sumarizare rulantă a istoricului

Peste un prag — de exemplu 15 ture — comprimi turele vechi într-un rezumat de 300-500 de tokeni și păstrezi integral doar ultimele câteva schimburi. Conversația rămâne coerentă, iar creșterea liniară se aplatizează.

Atenție la ce arunci: identificatorii (numere de comandă, coduri de eroare, nume proprii) trebuie păstrați explicit în rezumat, altfel modelul „uită" exact detaliile de care avea nevoie.

Prompt caching

Furnizorii mari cachează starea internă calculată pentru un prefix de prompt repetat și o refolosesc la cererile următoare. Efectul: costul de input pentru partea cachată scade substanțial, iar time-to-first-token se reduce vizibil.

Mecanica impune o regulă de ordonare: conținut static la început, dinamic la final. Documentația OpenAI e explicită — potrivirea se face doar pe prefix identic, caching-ul pornește automat de la 1.024 de tokeni, iar imaginile și definițiile de tools trebuie să fie identice între cereri. Dacă îți pui timestamp-ul sau numele utilizatorului în prima linie a system prompt-ului, cache-ul nu se va potrivi niciodată.

Verifică și economia: pe unele familii de modele, scrierea în cache costă mai mult decât un input normal, deci pragul de rentabilitate începe de la a doua citire.

Rutare pe model

Nu orice cerere are nevoie de modelul cel mai capabil. Clasificarea intenției, extracția de entități sau reformularea întrebării merg foarte bine pe un model mic și ieftin, iar bugetul mare îl păstrezi pentru generarea finală.

Greșeli frecvente

• Optimizarea pentru fereastra maximă — alegi modelul după numărul anunțat, deși promptul tău tipic are 12.000 de tokeni. Între 128K și 1M nu există nicio diferență pentru cazul tău; contează prețul și calitatea.
• Umplerea ferestrei „pentru siguranță" — mai mult context înseamnă mai mult zgomot, nu mai multă certitudine.
• Ignorarea rezervei de output — cererea pică la ultimul pas, după ce ai plătit deja prefill-ul.
• Istoric netăiat — cea mai frecventă cauză de facturi care cresc fără explicație.
• Prefix dinamic — un singur token variabil la începutul promptului anulează complet beneficiul de caching.
• Fără instrumentare — dacă nu numeri tokenii per secțiune, orice discuție despre optimizare e ghicit.
• Fragmente recuperate nefiltrate — trimiți top-20 pentru că „poate ajută". De obicei încurcă; e unul dintre modurile clasice în care un sistem RAG eșuează în producție.

Întrebări frecvente

Care e diferența dintre fereastra de context și memoria unui chatbot?

Fereastra de context e limita tehnică a unei singure cereri. „Memoria" e o funcționalitate construită de aplicație: salvezi informații relevante într-o bază de date și le reinjectezi selectiv în prompt la cererile următoare. Modelul în sine nu reține nimic.

Câte cuvinte încap într-un context de 128.000 de tokeni?

În engleză, aproximativ 96.000 de cuvinte — cam un roman. În română, mai puține, din cauza premiului de tokenizare. Nu te baza pe conversie: numără cu tokenizatorul modelului pe care îl folosești.

Dacă modelul are un milion de tokeni, mai am nevoie de o bază de date vectorială?

Depinde de volumul corpusului și de frecvența întrebărilor. Sub câteva sute de pagini consultate rar, un prompt monolitic poate fi suficient. Peste asta, recuperarea rămâne mai ieftină, mai rapidă și mai precisă — plus că îți dă filtrare pe permisiuni. Alegerea motorului e o discuție separată, cu criterii tehnice proprii.

Cum aflu lungimea efectivă a unui model, nu doar cea anunțată?

Construiește un test cu datele tale: introdu o informație verificabilă la adâncimi diferite într-un corpus real, variază lungimea totală și măsoară rata de recuperare corectă. Benchmark-urile publice îți dau ordinul de mărime; testul tău îți dă numărul pe care poți construi.

Ce fac dacă un document nu încape nici după fragmentare?

Îl procesezi ierarhic: rezumi fiecare secțiune separat, apoi raționezi peste rezumate. Pierzi detaliu fin, dar câștigi acoperire — iar dacă întrebarea cere detaliul, recuperezi secțiunea relevantă la pasul al doilea.

Contează unde pun informația importantă în prompt?

Da. Curba în U din „Lost in the Middle" arată că începutul și sfârșitul contextului sunt folosite mai bine decât mijlocul. Pune instrucțiunile critice la început, fragmentele cele mai relevante spre final, aproape de întrebare. Ordonarea, deduplicarea și restul deciziilor de asamblare a contextului — plus ce se întâmplă cu ele în textul livrat — sunt tratate în ghidul despre cum arată un răspuns bun de RAG.

Ce urmează

Fereastra de context nu e o resursă pe care o umpli, ci una pe care o aloci. Un buget scris, cu plafoane per secțiune și instrumentare care le verifică, valorează mai mult decât orice trecere la un model cu fereastră mai mare.

Restul fundamentelor — cum se transformă textul în vectori, cum se caută semantic în ei și cum se leagă totul într-un sistem funcțional — le găsești în hubul Fundamentele RAG. Pentru imaginea completă a serviciilor de integrări AI și sisteme RAG, inclusiv arhitecturi și implementări concrete, pornește de la hubul de serviciu.

Ai un corpus mare și nu ești sigur dacă merită retrieval sau context lung? Un audit pe datele tale — tokenizare, lungime efectivă, cost per cerere — îți dă răspunsul în cifre, nu în presupuneri. Descrie-ți cazul pe pagina de contact și primești estimarea.