Ingineria contextului: lucrul înainte de prompt
· 6 min read · Filippo Spinella · AI, Agents, Prompting, Developer Tools
Cuvântul momentului, în mica lume a agenților AI, este ingineria contextului.
Se pare că încă o etichetă a fost inventată pentru a vinde ceva ce am făcut deja. În parte este. Totuși, așa cum se întâmplă de multe ori, eticheta prinde pentru că dă un nume unei dureri reale.
Durerea este aceasta: modelele nu eșuează doar pentru că „nu gândesc”. De multe ori eșuează pentru că îi trimitem să lucreze cu camera greșită.
Le dăm instrucțiuni vechi. Îi ascundem fișiere importante. Le dăm documente prea lungi și nu spunem ce contează. Le arătăm jurnalele fără prioritate. Le oferim zece instrumente fără a le explica când să le folosească. Atunci suntem surprinși dacă agentul se mută ca o persoană trezită într-un apartament necunoscut.
Solicitarea este expresia pe care i-o spui. Contextul este lumea pe care o pregătești în jurul lui.
De la inginerie promptă la inginerie de context
Ingineria promptă a fost adesea considerată ca scriere. Alegeți cuvintele potrivite, întrebați în modul corect, adăugați exemple, specificați formatul.
Ingineria contextului este mai aproape de arhitectură.
Nu te întrebi doar „cum formulez cererea?”. Se întreabă:
- de ce informații sunt necesare cu adevărat?
- ce sunt zgomotul?
- ce trebuie recuperat din mers?
- ce ar trebui să ne amintim?
- ce instrumente ar trebui expuse?
- ce instrucțiuni sunt stabile și care depind de sarcină?
- cum îl fac pe agent să înțeleagă ce este autoritar?
Este o schimbare subtilă, dar uriașă. Pentru că atunci când lucrați cu agenți, contextul nu este un bloc static. Se schimbă la fiecare pas.
Agentul deschide un fișier, învață ceva, execută un test, primește o eroare, actualizează planul, apelează un instrument, descoperă o dependență. Cu fiecare tură trebuie să decidă ce să ia cu el și ce să lase deoparte.
Aceasta este inginerie.
Contextul nu este o groapă de gunoi
Șabloanele cu ferestre mari de context ne-au dat o tentație: să aruncăm totul înăuntru.
Este de înțeles. Dacă am un milion de jetoane, de ce ar trebui să aleg?
Pentru că chiar și atunci când poți pune totul, nu înseamnă că totul ajută. Într-adevăr, zgomotul are un cost. Costă jetoane, costă atenție, costă latența, costă calitate. Un model se poate pierde în detalii irelevante la fel ca noi când deschidem douăzeci de file și nu ne mai amintim de ce.
Contextul bun are o ierarhie:
- instrucțiuni și politici de sistem;
- obiectiv specific;
- starea actuală;
- date relevante;
- constrângeri;
- instrumente disponibile;
- urmăriți deciziile deja luate.
Nu este nevoie să tratezi totul la același nivel. O comandă de utilizator valorează mai mult decât o notă veche. Un test nereușit valorează acum mai mult decât o preferință estetică de acum trei luni. O politică de securitate valorează mai mult decât o scurtătură de producție.
Ingineria contextului înseamnă, de asemenea, a oferi ponderi, nu doar date.
Memorie: amintiți-vă mai puțin, amintiți-vă mai bine
Memoria în agenți este unul dintre cele mai alunecoase subiecte.
În calitate de utilizator, doriți ca agentul să vă cunoască. Vrei să-și amintească tonul, planul, convențiile, lucrurile deja decise. Ca inginer, știi că fiecare amintire persistentă este și un risc: poate fi greșită, veche, prea personală, prea generică, neverificabilă.
O memorie utilă ar trebui să aibă cel puțin trei calități:
- proveniența: de unde provin aceste informații?
- data: cand a fost adevarat?
- scop: pentru ce tip de sarcină ar trebui să fie folosit?
Fără aceste trei lucruri, memoria devine superstiție.
Îmi place să mă gândesc la memoria agentică ca la un registru de lucru, nu ca la o minte magică. Există note temporare, decizii confirmate, preferințe de stil, constrângeri tehnice, link-uri către surse. Unele lucruri expiră. Unele trebuie rescrise. Unele trebuie eliminate pentru că agentul le-a dedus greșit.
Un sistem bun trebuie să facă această întreținere normală. Nu eroic.
Recuperarea și instrumentele nu sunt același lucru
Când vorbim despre context, de multe ori ajungem imediat pe RAG. Încorporare, bază de date vectorială, fragmentare, reclasificare.
Toate utile. Dar recuperarea este doar o modalitate de a aduce informații la model. El nu este singurul.
Un agent poate obține context citind fișiere, interogând un API, apelând un server MCP, deschizând un browser, executând teste, căutând Slack, uitându-se la un tablou de bord, întrebând uman.
Partea interesantă este să decizi ce rută să folosești și când.
Dacă agentul trebuie să răspundă la o întrebare istorică, poate că doar recuperarea este suficientă. Dacă trebuie să remedieze o eroare, trebuie să citească cod real. Dacă trebuie să înțeleagă de ce o implementare eșuează, trebuie să se uite la jurnalele noi. Dacă trebuie să scrieți unui client, trebuie să recuperați tonul, istoricul și starea biletului. Dacă trebuie să acționeze în baza producției, trebuie să ceară permisiunea.
Contextul nu este o bază de date. Este un flux de lucru.
Agentul bun știe și să ignore
Un semn de maturitate la agenți va fi capacitatea de a spune: nu am nevoie de această informație.
Pare banal, dar este foarte greu. Se acumulează multe sisteme agentice. Fiecare apel de instrument adaugă text. Fiecare eroare rămâne în buffer. Fiecare fișier citit se adaugă la stivă. În cele din urmă, modelul are o istorie foarte lungă și nicio hartă.
Este nevoie de compresie. Este nevoie de sinteză intermediară. Trebuie structurat.
Nu „atât s-a întâmplat”, ci:
- obiectiv încă valabil;
- ipoteza actuală;
- fișiere deja verificate;
- deciziile luate;
- riscuri deschise;
- următoarea acțiune.
Acest lucru îl face pe agent mai puțin teatral și mai util. Nu pentru că pare mai inteligent, ci pentru că lucrează cu un birou ordonat.
Ingineria contextului pentru echipe, nu pentru artiști prompti
Motivul pentru care acest subiect mă interesează este că transferă responsabilitatea de la individ la sistem.
În inginerie promptă, cel care poate vorbi cel mai bine cu modelul câștigă adesea. În ingineria contextului, echipa care își organizează cel mai bine munca câștigă: documentație, convenții, probleme, jurnale, teste, proprietate, denumire, surse.
Un depozit curat devine un context mai bun. O problemă bine scrisă devine un combustibil mai bun. Un runbook actualizat salvează jetoane și anxietate. Un jurnal clar al schimbărilor reduce halucinațiile.
Aceasta este o veste bună și oarecum incomodă. Frumos pentru că recompensează bunele practici. Incomod pentru că nu poți rezolva totul cu un prompt inteligent.
Agenții amplifică igiena sistemului pe care îl găsesc.
Cum l-aș aplica mâine
Dacă ar fi să introduc ingineria contextului într-un proiect real, aș pleca de la lucruri mărunte:
- un dosar de instrucțiuni de proiect scurt și întreținut;
- exemple bune de rezultate așteptate;
- o listă de instrumente disponibile și cazuri în care să le folosească;
- decizii de arhitectură redactate în mod citabil;
- problema cu context minim obligatoriu;
- ușor de preluat jurnalele și testele;
- memorie persistentă modificabilă de om.
Atunci aș măsura un lucru simplu: de câte ori agentul trebuie să ceară lămuriri sau pleacă în direcția greșită?
Dacă se întâmplă des, nu aș adăuga imediat un model mai mare. M-as uita la context.
Lectura mea
Ingineria contextului este un cuvânt umflat, da. Dar conceptul este solid.
Ne reamintește că inteligența unui agent nu este doar în model. Constă în mediul pe care îl pregătim pentru el: ce vede, ce își amintește, ce poate face, ce îi este interzis să facă, ce surse le recunoaște drept adevărate.
Partea umană este aceasta: pregătirea bine a contextului este o formă de îngrijire. Îi spune agentului, dar și echipei: „Nu vreau să ghiciți, vreau să aveți ceea ce aveți nevoie”.
Mai puțină magie. Cameră mai curată. Agenții au nevoie de el la fel de mult ca și noi.