Šta je kontekstualno inženjerstvo? Šta model prima pre nego što odgovori

Inženjering konteksta je dizajniranje toga koje informacije jezički model prima u trenutku zaključivanja, u kom obliku, u kom redosledu i koliko dugo. Širi je od inženjeringa upita jer kontekst modela može uključivati sistemska uputstva, korisničke poruke, preuzete dokumente, rezultate alata, memoriju, trenutno stanje aplikacije, primere, strukturirane podatke i međurezultate. Cilj nije da se maksimizira broj tokena, već da se konstruiše najmanji korisni kontekst koji čuva informacije, ograničenja i dokaze potrebne za trenutni zadatak.

Šta inženjering konteksta zaista znači

Svaki poziv modela izvršava se u privremenom radnom okruženju: trenutna uputstva, poruke, preuzeti dokazi, izlazi alata i stanje koji se uklapaju u aktivni prozor konteksta. Inženjering konteksta je disciplina namernog konstruisanja tog okruženja.

Ključna reč je namerno. Naivan sistem jednostavno spaja sve što ima: punu istoriju, sve preuzete dokumente, svaki odgovor alata i velike sistemske upite. Sistem sa inženjeringom konteksta odlučuje koje su informacije potrebne za trenutnu odluku, a koje treba da ostanu izvan prozora dok ne budu potrebne.

To čini inženjering konteksta delom problemom informacione arhitekture, delom problemom izvršavanja i delom problemom evaluacije. Dizajn mora da odluči šta može da uđe u kontekst, odakle dolazi, koja verzija je aktuelna, kako se rešavaju sukobi, koliko detalja se zadržava i kako se rezultat testira.

Najjednostavniji primer

Zamislite internog asistenta za podršku. Korisnik pita: „Može li ovaj klijent da otkaže bez naknade?“

Modelu može biti potrebno pet stvari: aktuelna politika otkazivanja, trenutni tip ugovora klijenta, datum stupanja ugovora na snagu, relevantna pravila o izuzecima i obim ovlašćenja korisnika.

Nije mu neophodna cela baza podataka klijenata, kompletan arhiv politika, svaki prethodni razgovor ili svaki tiket podrške. Inženjering konteksta je proces koji bira i sastavlja pet korisnih delova, a isključuje nepovezane informacije.

Gde se jednostavan primer zaustavlja

Stvarni sistemi su teži jer informacije potrebne za jedan korak možda nisu poznate pre početka izvršavanja. Agent može da otkrije nove činjenice pomoću alata, kreira međufajlove, prima promenljivo spoljno stanje ili obuhvata zadatak duži od jednog prozora konteksta.

Inženjering konteksta zato postaje dinamičan. Kontekst za korak 12 ne treba da bude prosto kontekst koraka 1 plus jedanaest slojeva nagomilanog izlaza. Treba da odražava trenutno stanje zadatka, odluke koje su još važne i dokaze potrebne za sledeću radnju.

Šta može da uđe u kontekst modela?

Inženjering konteksta naspram inženjeringa upita

Anthropic eksplicitno opisuje inženjering konteksta kao prirodan napredak inženjeringa upita za sisteme u kojima model mora da radi sa alatima, eksternim podacima, istorijom poruka i dugotrajnim stanjem agenta. Praktična razlika je korisna jer savršeno napisan upit ne može da nadoknadi nedostatak autoritativnih podataka ili kontekst zagađen kontradiktornim stanjem.

Inženjering konteksta naspram pretraživanja

Pretraživanje bira kandidatske informacije iz eksternog korpusa ili izvora. Inženjering konteksta odlučuje šta se dešava nakon i oko tog pretraživanja.

Pretraživač može da vrati 30 pasusa. Reranker ih može svesti na 10. Sloj konteksta može izabrati četiri pasusa, ukloniti duplikate, priložiti metapodatke o izvoru/verziji, kombinovati ih sa trenutnim stanjem aplikacije i postaviti ih nakon sistemskih instrukcija.

Zato RAG sistem može da pronađe tačan pasus i ipak odgovori loše: neuspeh može nastati tokom sastavljanja konteksta, a ne tokom pretraživanja.

Inženjering konteksta naspram memorije

Memorija je informacija sačuvana izvan neposrednog poziva modela kako bi se kasnije ponovo koristila. Kontekst je informacija koja je stvarno učitana u trenutni poziv.

Memorijski sistem može sadržati hiljade činjenica, beleški ili prethodnih odluka. Inženjering konteksta bira koje od njih treba ponovo uvesti za trenutni zadatak. Učitavanje cele memorije u svakom koraku obesmišljava svrhu postojanja eksternog memorijskog sloja.

Razlika postaje ključna za promenljivo stanje. Zapamćen status projekta ili korisnička preferencija mogu biti korisni, ali trenutno autoritativno stanje može biti potrebno ponovo pročitati pre odluke sa posledicama.

Inženjering konteksta naspram stanja aplikacije

Stanje aplikacije je trenutno stanje spoljnog sistema: stanje računa, status tiketa, verzija fajla, faza radnog toka, stanje implementacije ili napredak zadatka.

Stanje može biti sažeto u kontekst, ali sažetak nije samo stanje. Za operacije sa posledicama, izvršno okruženje može morati ponovo pročitati autoritativni sistem neposredno pre akcije, umesto da veruje ranijem snimku vidljivom modelu.

Dizajn alata je deo inženjeringa konteksta

Alati ne daju agentima samo sposobnosti. Imena alata, opisi, šeme i rezultati postaju informacije vidljive modelu koje oblikuju odluke.

Anthropic-ove trenutne smernice za inženjering konteksta naglašavaju alate efikasne po pitanju tokena i upozoravaju na pretrpane skupove alata sa preklapajućom funkcionalnošću. Katalog alata koji je teško razlikovati čoveku takođe je teško pouzdano usmeravati modelu.

Izlazi alata takođe zahtevaju disciplinu konteksta. Vraćanje celog loga od 20.000 linija kada je agent zatražio jedan uslov greške troši pažnju i može da zatrpa odlučujući dokaz.

Kontekst tačno na vreme naspram unapred učitanog konteksta

Anthropic opisuje hibridni obrazac u kojem je neki stabilan kontekst unapred učitan dok agenti preuzimaju dodatne informacije u vreme izvršavanja. Ovo je koristan arhitektonski obrazac jer nije svaka važna činjenica zaslužuje trajno prebivalište u kontekstnom prozoru.

Kontekst je budžet, a ne sistem za skladištenje

Kontekstni prozor definiše kapacitet. On ne garantuje da će svaki token biti jednako dobro iskorišćen. Model mora da rasporedi pažnju na instrukcije, istoriju, dokaze, alate i međustanje.

Praktični cilj stoga nije „napuniti prozor“. Cilj je maksimizirati korisnost ograničenog budžeta pažnje.

Anthropic formuliše sličan princip kao pronalaženje najmanjeg skupa tokena sa visokim signalom koji maksimizira verovatnoću željenog ponašanja. OpenAI-ove smernice za upravljanje kontekstom takođe upozoravaju da neobrađena istorija, redundantni rezultati alata i bučno preuzimanje mogu da preplave čak i velike prozore.

Zašto više konteksta može biti gore

Dodatni kontekst može da unese irelevantne informacije, zastarelo stanje, duplirane dokaze, kontradiktorne instrukcije ili poziciono takmičenje. Takođe može da navede sisteme sažimanja da odbace detalje koji kasnije postanu važni.

Klasična studija Izgubljeni u sredini pokazala je da modeli sa dugim kontekstom mogu da koriste informacije različito u zavisnosti od toga gde se relevantni sadržaj pojavljuje, pri čemu performanse često opadaju kada se odlučujuća informacija postavi u sredinu dugih ulaza.

To ne znači da je dug kontekst inherentno loš. To znači da dostupnost unutar prozora nije isto što i pouzdano korišćenje.

Redosled konteksta treba da bude nameran

Izgradnja konteksta je takođe problem redosleda. Kritične instrukcije, trenutno stanje, odlučujući dokazi i ograničenja specifična za zadatak ne bi trebalo proizvoljno nadovezivati.

Ne postoji univerzalno savršen redosled za svaki model i zadatak. Arhitektura stoga treba da testira da li promena redosleda dokaza menja tačnost i da li važne informacije ostaju robusne kroz realistične varijacije konteksta.

Stabilan odgovor koji se dramatično menja kada dva jednako validna odlomka zamene pozicije ukazuje na osetljivost na kontekst koju treba meriti, a ne ignorisati.

Konfliktni kontekst zahteva eksplicitni prioritet

Model može primiti staru politiku i novu politiku, zapamćenu preferenciju i trenutnu eksplicitnu instrukciju, ili keširani status i rezultat API-ja uživo. Sistem ne treba da očekuje da model zaključi prioritet iz stila proze.

Inženjering konteksta treba da kodira prioritet kroz selekciju izvora, metapodatke, redosled ili eksplicitne instrukcije: trenutno autoritativno stanje nadjačava zastarele kopije; eksplicitna trenutna korisnička instrukcija nadjačava stariju zaključenu preferenciju; odobrena politika zamenjuje zastarele nacrte.

Sažimanje je transformacija konteksta, a ne bezgubitničko skladištenje

Dugotrajni sistemi na kraju moraju da skrate, sažmu ili kompaktuju istoriju. Kompaktovanje stvara novu reprezentaciju prethodnog konteksta kako bi agent mogao da nastavi bez reprodukovanja svakog tokena.

OpenAI-ovi primeri upravljanja kontekstom koriste skraćivanje i kompresiju za dugotrajne sesije. Anthropic opisuje kompaktovanje kao primarnu tehniku za održavanje koherentnosti kada se interakcija približava granici konteksta.

Težak deo je odlučivanje šta se ne može bezbedno ukloniti: nerešeni zadaci, identifikatori, korisnička ograničenja, bezbednosne granice, arhitekturne odluke, izuzeci, poreklo izvora i uslovi koji čine prethodni zaključak validnim.

Sačuvaj granice validnosti

Važni zaključci treba da nose uslove pod kojima ostaju podržani: verziju, datum, obim, pretpostavke, autoritet izvora i nerešeno neslaganje.

Inženjering konteksta je stoga povezan sa granicom validnosti odgovora. Sastavljač konteksta ne treba da uklanja metapodatke koji određuju da li dokazi još uvek važe.

Inženjering konteksta je takođe bezbednosna granica

Podaci koji stignu do modela prešli su važnu sistemsku granicu. Sastavljanje konteksta stoga mora poštovati autorizaciju, izolaciju zakupaca, poverljivost i pravila minimizacije podataka.

Pretraživač može tehnički pronaći odlomak kojem trenutni korisnik ne može pristupiti. Ispravan dizajn je sprečiti da taj odlomak uđe u kontekst modela, umesto da se oslanja na to da će ga model ignorisati.

Izlazi alata takođe mogu sadržati nepouzdane instrukcije ili neprijateljski sadržaj. Inženjering konteksta treba da očuva razliku između instrukcija aplikacije i eksternih podataka kako pronađeni tekst ne bi mogao tiho steći autoritet instrukcije.

Praktična arhitektura za inženjering konteksta

Sastavljač konteksta je konceptualno važan čak i kada nijedan modul ne nosi tačno taj naziv. U maloj aplikaciji to može biti običan aplikativni kod. U velikoj agentskoj platformi može kombinovati upravljanje sesijama, pronalaženje, memoriju, middleware za alate, kompakciju i sprovođenje politika.

Praktična politika izgradnje konteksta

Kako evaluirati inženjering konteksta

Sastavljanje konteksta je poseban sloj RAG neuspeha

RAG pipeline može uspešno da izvrši pronalaženje i ipak ne uspe dalje. Relevantni izvor se može pojaviti na rangu 2, ali sastavljač konteksta ga može izostaviti, skratiti, kombinovati sa zastarelim kontradiktornim materijalom ili prekoračiti budžet tokena.

Zato tragove pronalaženja treba uporediti sa stvarnim kontekstom poslatim modelu. Bez tog poređenja, neuspesi konteksta se lako pogrešno dijagnostikuju kao neuspesi embedding-a ili modela.

Dokazi iz originalne implementacije

Source of Truth Research Engine: ograničeno istraživanje umesto neograničenog konteksta

Source of Truth Research Engine razdvaja otkrivanje, prikupljanje, ekstrakciju, verifikaciju, analizu kontradikcija i sintezu u ograničene istraživačke faze, umesto da jedan ogroman istraživački zadatak i sav prikupljeni materijal pošalje u jedan jedini poziv modelu.

Njegov model dokaza čuva Sources, Artifacts, Claims, Relations, Contradictions i poreklo izvan konteksta modela. Model može da primi podskup potreban za trenutni istraživački korak, dok trajni dokazi ostaju u eksternom skladištu.

To je konkretan obrazac inženjeringa konteksta: trajno istraživačko stanje živi izvan prozora modela; aktivni kontekst modela se rekonstruiše za trenutnu fazu.

Aaasaasa AI Client: runtime, dozvole i kontekst su odvojene brige

Aaasaasa AI klijent razdvaja izbor provajdera/modela, lokaciju izvršavanja, dozvole radnog prostora, lokalne resurse i pristup alatima. To sprečava da kontekst modela postane vlasnik autorizacije ili stanja aplikacije.

Direktan razgovor i agentska okruženja za izvršavanje mogu imati različite mogućnosti alata. Profili dozvola radnog prostora se sprovode od strane okruženja za izvršavanje, a ne samo opisuju u kontekstu prirodnog jezika. Ova razlika je važna: kontekst može reći modelu šta bi trebalo da radi, dok okruženje za izvršavanje i dalje mora da sprovede ono što mu je zaista dozvoljeno da radi.

Dokaz implementacije ovde je arhitektonsko razdvajanje, a ne tvrdnja da je svaka napredna tehnika upravljanja kontekstom opisana u ovom članku već implementirana.

Uobičajeni načini neuspeha u inženjeringu konteksta

Uobičajene zablude

Praktičan sled inženjeringa konteksta

Kontrolna lista za inženjering konteksta

Rubni slučajevi i ograničenja

Neki zadaci su dovoljno jednostavni da se inženjering konteksta svodi na kratak sistemski upit i jednu korisničku poruku. Dodavanje pronalaženja, memorije i sažimanja samo bi uvelo nepotrebnu arhitekturu.

Neki zadaci zahtevaju visok opoziv i mogu namerno da uključe više konteksta pre kasnije sinteze. Istraživanje, otkrivanje i pravni pregled mogu da preferiraju izbegavanje izostavljanja umesto minimalnog broja tokena.

Neke informacije ne bi trebalo nikada sažimati pre upotrebe. Tačni ugovori, kod, kriptografski materijal, numerički zapisi i regulatorni tekst mogu zahtevati doslovno ili strukturisano pronalaženje gde kompresija može da promeni značenje.

Ponašanje dugog konteksta značajno varira između modela. Strategija validirana na jednom modelu, dužini konteksta ili okviru alata ne bi trebalo automatski da se prenosi na drugi.

Model i dalje može da ignoriše ili pogrešno protumači izuzetan kontekst. Kontekstualno inženjerstvo poboljšava informaciono okruženje; ono ne garantuje ispravnost zaključivanja.

Šta bi promenilo ovaj odgovor?

Budući modeli mogu postati robusniji na dugi kontekst, pozicione efekte i konfliktne informacije. To bi moglo smanjiti količinu ručne kuratacije koja je potrebna.

Arhitektonska razlika bi i dalje ostala korisna jer dozvole, svežina, trajnost memorije, autoritet izvora i stanje eksterne aplikacije postoje izvan modela bez obzira na veličinu kontekstnog prozora.

Preporučeni balans između unapred učitanog i konteksta koji se učitava po potrebi takođe se menja u zavisnosti od zahteva za latencijom, pouzdanosti alata, veličine korpusa, cene modela i toga koliko su dinamične osnovne informacije.

Povezano kanonsko znanje

Kontekstualno inženjerstvo se nalazi između pretrage i generisanja. RAG objašnjava kako se eksterno znanje pronalazi; R01 razdvaja embedding-e, vektorsku pretragu i rerangiranje; kontekstualno inženjerstvo objašnjava šta na kraju stigne do modela.

Arhitektura izvora istine odgovara na drugačije pitanje: ne koje informacije su prisutne u kontekstu, već koji izvor je ovlašćen da utvrdi tvrdnju.

Postojeći članak Zašto više konteksta može pogoršati AI odgovore je dijagnostički pratilac ovoj kanonskoj definiciji. Fokusira se na zagađenje konteksta, pozicione efekte, rast top-k, gubitak kompakcije i degradaciju odgovora, umesto da redefiniše samo kontekstualno inženjerstvo.

Često postavljana pitanja

Pojmovnik

Zaključak

Kontekstualno inženjerstvo je sloj koji odlučuje šta model može da vidi pre nego što odgovori. To ga čini širim od promptovanja i nizvodnim od pretrage, dok istovremeno ostaje različito od trajne memorije i autoritativnog stanja aplikacije.

Snažna arhitektura konteksta ne tretira kontekstni prozor kao bazu podataka. Ona čuva trajno stanje i znanje izvan modela, učitava ono što je potrebno za trenutnu odluku, čuva autoritet i poreklo, uklanja nepotreban šum i osvežava volatilne informacije kada je potrebno.

Praktični cilj stoga nije maksimalan kontekst. To je minimalni dovoljan, visoko signalni, ispravno autorizovan i kontekst koji čuva važenje za sledeću odluku modela.

Primarni izvori i aktuelne smernice

Izvori navedeni u nastavku podržavaju trenutnu terminologiju kontekstualnog inženjeringa, ponašanje dugog konteksta i operativne obrasce upravljanja kontekstom. Sekcije projekta su eksplicitno dokazi implementacije, a ne univerzalne tvrdnje.