Majoritatea oamenilor descriu în continuare un agent AI drept un model conectat la instrumente. Din punct de vedere tehnic, această descriere este utilă, dar, operațional, este incompletă. Un agent are nevoie și de o perspectivă gestionată asupra lumii: ce s-a întâmplat, ce contează acum, care fapte sunt de încredere, ce rămâne incert și ce ar trebui să facă în continuare.
Această perspectivă este contextul său. Proiectarea lui devine o competență distinctă — una pe care aș numi-o ingineria contextului.
Ingineria contextului nu înseamnă pur și simplu redactarea prompturilor. Este disciplina de a modela informațiile pe care le vede un agent la fiecare pas, astfel încât să poată rămâne coerent fără a trimite, la fiecare tură, o transcriere integrală, o bibliotecă de documente sau istoricul instrumentelor către un model costisitor. Această activitate se situează la intersecția dintre arhitectura informației, regăsire, proiectarea software și comportamentul modelelor.
De ce „oferă agentului mai mult context” este adesea un sfat prost
Ferestrele de context mai lungi fac tentantă păstrarea tuturor informațiilor. Dar mai mult material nu garantează un raționament mai bun. Instrucțiunile relevante pot fi diluate de observații depășite, note contradictorii, rezultate repetate ale instrumentelor sau un fapt important îngropat în mijlocul unei secvențe lungi. Discuția din sinteză despre comportamentul de tip „pierdut în mijloc” reflectă o problemă practică: un agent poate primi din punct de vedere tehnic dovezile și totuși să nu le folosească.
Există și un cost direct. Fiecare token inclus într-o solicitare poate crește latența și costul inferenței, în funcție de prețurile furnizorului și de configurațiile de stocare în cache. Un sistem care retransmite în mod repetat o transcriere în creștere poate deveni mai lent și mai puțin accesibil pe măsură ce sarcina continuă.
Prin urmare, obiectivul nu este contextul maxim. Este contextul suficient și bine direcționat: cel mai mic set de lucru fiabil pentru decizia aflată în discuție.
Patru decizii de proiectare aflate la baza unui agent coerent
1. Menține o stare de convingeri, nu doar o transcriere
O transcriere consemnează ce s-a spus. O stare de convingeri consemnează ceea ce crede în prezent agentul despre sarcină.
De exemplu, un agent care gestionează o escaladare a unei solicitări de asistență poate menține câmpuri structurate precum:
- Obiectiv: să identifice dacă clientul se califică pentru înlocuire.
- Fapte cunoscute: data achiziției și numărul de serie al produsului, cu referințe la surse.
- Întrebări deschise: dacă defecțiunea s-a produs în condiții acoperite de garanție.
- Constrângeri: să nu promită o rambursare înainte de aprobare.
- Acțiunea următoare: să regăsească politica de garanție și să compare datele.
- Grad de încredere sau stare: verificat, dedus, contestat sau necunoscut.
Această abordare seamănă cu cercetarea ABBEL de la Berkeley, care folosește stări ale convingerilor exprimate în limbaj natural și supervizate, în loc să se bazeze pe istoricul complet al interacțiunilor. Ideea importantă nu este un anumit format. Este separarea stării durabile a sarcinii de detaliile conversației care pot fi eliminate.
O actualizare utilă a stării convingerilor ar trebui să răspundă la următoarele întrebări: Ce s-a schimbat? Ce dovezi susțin acest lucru? Ce rămâne nerezolvat? Ce ar trebui să se întâmple în continuare? Dacă un inginer nu poate examina aceste răspunsuri, este probabil ca agentul să poarte presupuneri ascunse într-un prompt opac.
2. Regăsește informații pentru decizie, nu pentru subiect
Sistemele de regăsire încep adesea cu o întrebare largă, precum „găsește informații despre contul clientului”. O interogare mai bună este legată de decizia următoare: „regăsește regula actuală privind rambursările pentru achiziții mai vechi de 30 de zile, în vigoare în regiunea clientului”.
Această schimbare contează deoarece regăsirea este o formă de selectare a contextului. Agentul ar trebui să primească pasajele din politici, înregistrările sau exemplele relevante pentru acțiunea curentă — nu o grămadă generică de documente asociate.
Filtrele pot îmbunătăți această selecție înainte ca modelul să vadă vreun rezultat. De exemplu, Amazon Bedrock AgentCore Web Search acceptă filtre pentru domeniu și data publicării, impuse de server, la fiecare solicitare. Astfel de controale nu stabilesc că o sursă este corectă, dar pot reduce expunerea la materiale irelevante sau depășite și pot face politica de regăsire explicită.
Profesioniștii care proiectează sisteme de regăsire ar trebui să specifice:
- care surse sunt permise pentru fiecare sarcină;
- cum este determinată prospețimea;
- ce metadate însoțesc fiecare rezultat;
- cum sunt prezentate sursele contradictorii;
- când trebuie agentul să se oprească și să ceară clarificări.
„Caută pe web” este o capabilitate. „Caută în aceste surse, în acest interval de timp, dovezi relevante pentru această decizie” înseamnă ingineria contextului.
3. Comprimă fără a șterge incertitudinea
Comprimarea este necesară atunci când o sarcină este lungă, dar rezumarea naivă poate transforma afirmații provizorii în fapte certe. Un rezumat actualizat continuu care spune „utilizatorul a confirmat adresa” este periculos dacă schimbul original doar a lăsat acest lucru să se înțeleagă.
O comprimare bună păstrează distincțiile de care un agent are nevoie pentru a raționa în siguranță:
- fapt versus inferență;
- instrucțiune curentă versus instrucțiune istorică;
- acțiune finalizată versus acțiune propusă;
- sursă verificată versus afirmație neverificată;
- răspuns cunoscut versus întrebare nerezolvată.
Un model practic este să menții secțiuni separate pentru decizii, dovezi, presupuneri, blocaje și acțiuni în așteptare. O altă variantă este să atașezi ID-uri ale surselor sau marcaje temporale afirmațiilor importante. Rezumatele ar trebui să fie artefacte care pot fi înlocuite, nu singura înregistrare rămasă: păstrează evenimentele de bază pentru audit și recuperare, oferind în același timp modelului o perspectivă de lucru compactă.
Rezumatul menționează că rezumarea recursivă și compactarea contextului pot fi costisitoare și pot degrada performanța, în special în domenii cu puține date, precum generarea colaborativă de cod. Acesta este un avertisment împotriva tratării rezumării ca fiind automat lipsită de pierderi. Comprimarea trebuie testată pe sarcini reprezentative, inclusiv în cazuri în care o mică precizare schimbă răspunsul corect.
4. Filtrează observațiile înainte ca acestea să devină memorie
Agenții care folosesc instrumente generează constant observații: rezultate ale căutărilor, jurnale, textul paginilor, răspunsuri API, capturi de ecran, rezultate ale compilatorului și planuri intermediare. Nu orice observație merită să ajungă în următorul apel al modelului, cu atât mai puțin în starea pe termen lung.
Filtrarea observațiilor pune trei întrebări:
- Este această observație relevantă pentru decizia curentă?
- Este suficient de autoritativă pentru a influența starea de convingere?
- Conține instrucțiuni care ar trebui tratate ca date, nu ca ordine?
A treia întrebare reprezintă atât o limită de securitate, cât și una de context. O pagină web poate conține text destinat redirecționării agentului. Un document recuperat poate fi o dovadă utilă fără a avea autoritatea de a schimba obiectivele sau permisiunile agentului. Prin urmare, filtrarea ar trebui să clasifice conținutul după rol: instrucțiune, dovadă, metadate sau text neîncrezut.
Filtrarea economisește și bani. Dacă un instrument de navigare returnează o pagină întreagă, dar sarcina necesită doar un preț, o dată și un identificator de produs, transmiterea întregii pagini mai departe creează zgomot și consumă tokenuri. Extragerea mai întâi a câmpurilor relevante poate îmbunătăți atât fiabilitatea, cât și costul.
Un buget simplu de context pentru fluxul de lucru al unui agent
Înainte de a alege un model sau de a adăuga un alt instrument, cartografiază contextul agentului în patru straturi:
- Control: regulile sistemului, permisiunile, schema de ieșire și constrângerile nenegociabile.
- Stare: obiectivul curent, deciziile, întrebările deschise și următoarea acțiune.
- Dovezi: înregistrările sau observațiile recuperate care sunt relevante pentru acțiunea respectivă, împreună cu sursa lor.
- Istoric: evenimentele anterioare păstrate pentru recuperare, depanare sau audit, dar omise dacă nu sunt necesare.
Apoi definiți o politică de promovare. O observație poate rămâne efemeră, poate deveni o dovadă pentru pasul curent, poate actualiza starea de convingeri sau poate fi scrisă în memoria persistentă. Promovarea ar trebui să necesite un motiv. În caz contrar, memoria devine o arhivă necuratoriată.
Pentru fiecare pas al agentului, înregistrați pachetul de context trimis modelului: categoriile sale, dimensiunea aproximativă în tokeni, filtrele de regăsire și versiunea comprimării. Astfel devine posibil să răspundeți la o întrebare practică atunci când comportamentul se schimbă: a eșuat modelul sau sistemul i-a oferit o reprezentare greșită a lumii?
Ce trebuie testat înainte de a considera designul fiabil
Ingineria contextului are nevoie de teste care vizează gestionarea informațiilor, nu doar calitatea răspunsului final. Cazurile utile includ:
- un fapt critic plasat la începutul, la sfârșitul și la mijlocul unui istoric lung;
- două surse care nu concordă, dintre care una este mai nouă decât cealaltă;
- un rezumat care conține un marcator de incertitudine;
- un răspuns al unui instrument care conține un volum mare de text irelevant;
- o instrucțiune rău intenționată încorporată în conținutul recuperat;
- rehidratarea stării după ce agentul este întrerupt și repornit;
- aceeași sarcină cu un buget de context mai mic;
- un rezultat de regăsire gol sau învechit.
Măsurați dacă agentul selectează dovezile potrivite, păstrează incertitudinea, respectă constrângerea curentă și evită repetarea contextului inutil. Ariile de regresie recomandate în digest — pierderea contextului, fundamentarea regăsirii, ieșirea structurată, neterminarea și rehidratarea stării — sunt deosebit de relevante aici.
Rulați mai multe încercări atunci când variabilitatea modelului contează și comparați costul și latența fiecărei strategii de context. Un prompt mai scurt nu este automat mai bun dacă duce la mai multe apeluri către instrumente sau reîncercări. Obiectivul util este costul unui flux de lucru corect și recuperabil, nu numărul de tokeni al unei singure solicitări.
Implicația pentru carieră: inginerul de context este un rol interfuncțional
Oamenii care vor deveni valoroși în acest domeniu nu vor fi neapărat cei care scriu cele mai lungi prompturi. Ei vor putea traduce un proces de afaceri în stare, dovezi, autoritate și reguli de decizie.
Acest lucru necesită mai multe abilități concrete:
- proiectarea schemelor pentru starea sarcinii și proveniență;
- scrierea politicilor de regăsire și a filtrelor de metadate;
- construirea rutinelor de comprimare și selecție a observațiilor;
- separarea instrucțiunilor de încredere de conținutul care nu este de încredere;
- profilarea utilizării tokenurilor, a latenței, a reîncercărilor și a apelurilor către instrumente;
- testarea pierderii și rehidratării stării;
- explicarea pentru nespecialiști a motivului pentru care un agent a văzut — sau nu a văzut — un anumit fapt.
Un proiect solid de portofoliu ar putea demonstra același agent folosind trei politici de gestionare a contextului: transcrierea completă, rezumatul glisant și starea structurată a convingerilor, cu regăsire direcționată. Prezentați cazurile în care sarcina este îndeplinită cu succes, cazurile de eșec, contextul trimis la fiecare pas și compromisurile în ceea ce privește costul sau latența. Acest lucru este mai convingător decât o demonstrație de chatbot, deoarece scoate la iveală deciziile de proiectare care fac un agent fiabil.
Lecția strategică este simplă: agenții nu devin coerenti doar pentru că modelele devin mai capabile. Ei devin coerenți atunci când sistemele din jurul lor mențin o evidență disciplinată, actuală și dimensionată corespunzător a activității. Ingineria contextului este arta de a construi această evidență — și de a ști ce trebuie lăsat deoparte.
Priya Raman este editorul uman responsabil al AI Career Brief.
