A legtöbben továbbra is úgy írják le az AI-ügynököt, mint egy eszközökhöz kapcsolt modellt. Ez technikailag hasznos, működési szempontból azonban hiányos. Az ügynöknek szüksége van a világ kezelt nézetére is: mi történt, mi számít most, mely tények megbízhatók, mi maradt bizonytalan, és mit kellene tennie ezután.
Ez a nézet a kontextusa. Ennek megtervezése önálló készséggé válik — én ezt kontextusmérnökségnek nevezném.
A kontextusmérnökség nem egyszerűen promptírás. Olyan információk megformálásának tudománya, amelyeket az ügynök az egyes lépésekben lát, hogy koherens maradhasson anélkül, hogy minden fordulóban a teljes átiratot, dokumentumtárat vagy eszközelőzményt vissza kellene küldeni egy drága modellnek. Ez a munka az információs architektúra, a visszakeresés, a szoftvertervezés és a modellviselkedés határterületén helyezkedik el.
Miért rossz tanács gyakran az, hogy „adjunk több kontextust az ügynöknek”
A hosszabb kontextusablakok csábítóvá teszik, hogy mindent megőrizzünk. A több anyag azonban nem garantál jobb következtetést. A releváns utasításokat felhígíthatják az elavult megfigyelések, az egymásnak ellentmondó jegyzetek, az ismétlődő eszközkimenetek, illetve egy hosszú sorozat közepébe temetett fontos tény. Az összefoglaló „középen elveszve” jelenségről szóló tárgyalása gyakorlati problémára mutat rá: az ügynök technikailag megkaphatja a bizonyítékokat, mégis előfordulhat, hogy nem használja fel őket.
Ennek közvetlen költsége is van. A kérésbe helyezett minden token növelheti a késleltetést és a következtetés költségét, a szolgáltató árazásától és gyorsítótárazási megoldásaitól függően. Egy rendszer, amely ismételten továbbítja a növekvő átiratot, a feladat előrehaladtával lassabbá és kevésbé megfizethetővé válhat.
A cél tehát nem a maximális kontextus. Hanem elegendő, célzott kontextus: az adott döntéshez szükséges legkisebb megbízható munkakészlet.
A koherens ügynök mögött álló négy tervezési döntés
1. Ne csak átiratot tartsunk fenn, hanem hiedelemállapotot is
Az átirat azt rögzíti, mi hangzott el. A hiedelemállapot azt rögzíti, hogy az ügynök jelenleg mit gondol a feladatról.
Egy támogatási eszkalációt kezelő ügynök például olyan strukturált mezőket tarthat fenn, mint:
- Cél: annak megállapítása, hogy az ügyfél jogosult-e cserére.
- Ismert tények: a vásárlás dátuma és a termék sorozatszáma, forráshivatkozásokkal.
- Nyitott kérdések: hogy a meghibásodás garanciális feltételek hatálya alá eső körülmények között történt-e.
- Korlátok: jóváhagyás előtt nem szabad visszatérítést ígérni.
- Következő művelet: a garanciális szabályzat lekérése és a dátumok összevetése.
- Bizonyosság vagy állapot: ellenőrzött, kikövetkeztetett, vitatott vagy ismeretlen.
Ez a megközelítés hasonlít a Berkeley ABBEL kutatására, amely teljes interakciós előzményekre való támaszkodás helyett felügyelt természetesnyelvű hiedelemállapotokat használ. A lényeg nem egy konkrét formátum. Hanem a tartós feladatállapot elválasztása a múlandó beszélgetési részletektől.
Egy hasznos hiedelemállapot-frissítésnek választ kell adnia a következőkre: Mi változott? Milyen bizonyíték támasztja alá? Mi maradt megoldatlan? Mi történjen ezután? Ha egy mérnök nem tudja megvizsgálni ezeket a válaszokat, az ügynök valószínűleg rejtett feltételezéseket hordoz egy átláthatatlan promptban.
2. A döntéshez keressünk vissza, ne a témához
A visszakereső rendszerek gyakran olyan tág kérdéssel kezdik, mint „keress információt az ügyfél fiókjáról”. Jobb, ha a lekérdezés a következő döntéshez kapcsolódik: „kérd le a 30 napnál régebbi vásárlásokra vonatkozó, az ügyfél régiójában hatályos aktuális visszatérítési szabályt”.
Ez a váltás azért fontos, mert a visszakeresés a kontextus kiválasztásának egyik formája. Az ügynöknek azokat a szabályzatrészleteket, nyilvántartásokat vagy példákat kell megkapnia, amelyek hatással vannak az aktuális műveletre — nem pedig a kapcsolódó dokumentumok általános halmazát.
A szűrők még azelőtt javíthatják ezt a kiválasztást, hogy a modell bármilyen eredményt látna. Az Amazon Bedrock AgentCore Web Search például minden egyes kérésnél támogatja a szerver által kikényszerített domain- és publikációsdátum-szűrőket. Az ilyen vezérlők önmagukban nem bizonyítják, hogy egy forrás helyes, de csökkenthetik a nem releváns vagy elavult anyagoknak való kitettséget, és egyértelművé tehetik a visszakeresési szabályzatot.
A visszakeresést tervező szakembereknek meg kell határozniuk:
- mely források engedélyezettek az egyes feladatokhoz;
- hogyan határozzák meg a frissességet;
- milyen metaadatok kísérik az egyes találatokat;
- hogyan jelenítik meg az egymásnak ellentmondó forrásokat;
- mikor kell az ügynöknek leállnia és pontosítást kérnie.
A „Keresd meg a weben” egy képesség. A „Keress ezekben a forrásokban, ezen dátumtartományon belül, az e döntés szempontjából releváns bizonyítékok után” már kontextusmérnökség.
3. Tömörítsünk a bizonytalanság eltüntetése nélkül
A tömörítés szükséges, ha egy feladat hosszú, az egyszerű összefoglalás azonban a bizonytalan állításokat megmásíthatatlan tényekké változtathatja. Veszélyes például egy olyan folyamatosan frissített összefoglaló, amely szerint „a felhasználó megerősítette a címet”, ha az eredeti párbeszédből ez csak közvetve következett.
A jó tömörítés megőrzi azokat a különbségeket, amelyekre az ügynöknek szüksége van a biztonságos következtetéshez:
- tény kontra következtetés;
- aktuális utasítás kontra korábbi utasítás;
- végrehajtott művelet kontra javasolt művelet;
- ellenőrzött forrás kontra nem ellenőrzött állítás;
- ismert válasz kontra megoldatlan kérdés.
Az egyik praktikus megoldás, ha külön szakaszokat tartunk fenn a döntések, a bizonyítékok, a feltételezések, az akadályok és a függőben lévő műveletek számára. Egy másik lehetőség, hogy a fontos állításokhoz forrásazonosítókat vagy időbélyegeket csatolunk. Az összefoglalóknak lecserélhető munkatermékeknek kell lenniük, nem pedig az egyetlen fennmaradó nyilvántartásnak: az auditálás és a helyreállítás érdekében őrizzük meg az alapul szolgáló eseményeket, miközben tömör munkanézetet biztosítunk a modell számára.
Az összefoglaló megjegyzi, hogy a rekurzív összefoglalás és a kontextus tömörítése költséges lehet, és ronthatja a teljesítményt, különösen az adatszegény területeken, például az együttműködésen alapuló kódgenerálásban. Ez arra figyelmeztet, hogy ne kezeljük az összefoglalást automatikusan veszteségmentesként. A tömörítést reprezentatív feladatokon kell tesztelni, olyan eseteket is beleértve, amikor egy apró megszorítás megváltoztatja a helyes választ.
4. Szűrjük meg a megfigyeléseket, mielőtt emlékezetté válnának
Az eszközöket használó ügynökök folyamatosan megfigyeléseket generálnak: keresési találatokat, naplókat, oldalszöveget, API-válaszokat, képernyőképeket, fordítói kimenetet és köztes terveket. Nem minden megfigyelés érdemli meg, hogy bekerüljön a következő modellhívásba, még kevésbé a hosszú távú állapotba.
A megfigyelések szűrése három kérdést tesz fel:
- Releváns ez a megfigyelés az aktuális döntés szempontjából?
- Elég hiteles ahhoz, hogy befolyásolja a hiedelemállapotot?
- Tartalmaz olyan utasításokat, amelyeket parancsok helyett adatként kell kezelni?
A harmadik kérdés biztonsági határvonal is, nem csupán kontextushatár. Egy weboldal tartalmazhat olyan szöveget, amely az ügynök átirányítására irányul. Egy lekért dokumentum hasznos bizonyíték lehet anélkül, hogy felhatalmazása lenne az ügynök céljainak vagy jogosultságainak megváltoztatására. A szűrésnek ezért a tartalmat szerep szerint kell osztályoznia: utasítás, bizonyíték, metaadat vagy nem megbízható szöveg.
A szűrés pénzt is megtakarít. Ha egy böngészőeszköz egy teljes oldalt ad vissza, miközben a feladat csak egy árat, dátumot és termékazonosítót igényel, akkor az egész oldal továbbadása zajt kelt és tokeneket fogyaszt. A releváns mezők előzetes kinyerése javíthatja a megbízhatóságot és a költségeket is.
Egyszerű kontextuskeret egy ügynöki munkafolyamathoz
Mielőtt modellt választanánk vagy újabb eszközt adnánk hozzá, térképezzük fel az ügynök kontextusát négy rétegben:
- Vezérlés: rendszer szabályai, jogosultságok, kimeneti séma és nem alku tárgyát képező korlátozások.
- Állapot: az aktuális célkitűzés, a döntések, a nyitott kérdések és a következő művelet.
- Bizonyíték: az adott művelet szempontjából releváns, forrással ellátott lekért rekordok vagy megfigyelések.
- Előzmények: a helyreállítás, hibakeresés vagy audit céljából megőrzött korábbi események, amelyeket csak szükség esetén veszünk elő.
Ezután határozz meg egy előléptetési szabályzatot. Egy megfigyelés maradhat múlandó, az aktuális lépés bizonyítékává válhat, frissítheti a hiedelemállapotot, vagy tartós memóriába írható. Az előléptetéshez indoklásnak kell társulnia. Ellenkező esetben a memória nem kurált archívummá válik.
Minden ügynöklépésnél rögzítsd a modellnek elküldött kontextuscsomagot: annak kategóriáit, hozzávetőleges tokenszámát, a lekérdezési szűrőket és a tömörítés verzióját. Így megválaszolható egy gyakorlati kérdés, amikor a viselkedés megváltozik: a modell hibázott, vagy a rendszer a rossz világképet adta neki?
Mit kell tesztelni, mielőtt megbízhatónak neveznéd a tervet
A kontextustervezéshez olyan tesztekre van szükség, amelyek az információkezelést célozzák, nem csupán a végső válasz minőségét. Hasznos esetek például:
- egy kritikus tény a hosszú előzmények elején, végén és közepén elhelyezve;
- két egymásnak ellentmondó forrás, amelyek közül az egyik újabb a másiknál;
- egy bizonytalanságjelölést tartalmazó összefoglaló;
- egy irreleváns, terjedelmes szöveget tartalmazó eszközválasz;
- lekért tartalomba ágyazott rosszindulatú utasítás;
- az állapot visszatöltése az ügynök szüneteltetése és újraindítása után;
- ugyanaz a feladat kisebb kontextuskerettel;
- üres vagy elavult lekérdezési eredmény.
Mérd meg, hogy az ügynök a megfelelő bizonyítékot választja-e ki, megőrzi-e a bizonytalanságot, követi-e az aktuális korlátozást, és elkerüli-e a szükségtelen kontextus ismétlését. A digest által ajánlott regressziós területek — a kontextus elvesztése, a lekérdezések megalapozottsága, a strukturált kimenet, a le nem állás és az állapot visszatöltése — itt különösen relevánsak.
Futtass több próbát ott, ahol számít a modell változékonysága, és hasonlítsd össze az egyes kontextusstratégiák költségét és késleltetését. A rövidebb prompt nem automatikusan jobb, ha több eszközhívást vagy újrapróbálkozást okoz. A hasznos cél egy helyes, helyreállítható munkafolyamat költsége — nem egyetlen kérés tokenszáma.
A karrierre gyakorolt következmény: a kontextusmérnökök szerepe több területet összekapcsoló szerep
Azok, akik értékessé válnak ezen a területen, nem feltétlenül azok lesznek, akik a leghosszabb promptokat írják. Képesek lesznek egy üzleti folyamatot állapotra, bizonyítékra, illetékességre és döntési szabályokra lefordítani.
Ehhez több konkrét képességre van szükség:
- feladatállapothoz és eredetiséghez kapcsolódó sémák tervezése;
- lekérdezési szabályzatok és metaadatszűrők írása;
- tömörítési és megfigyeléskiválasztási rutinok létrehozása;
- a megbízható utasítások elválasztása a nem megbízható tartalomtól;
- a tokenhasználat, a késleltetés, az újrapróbálkozások és az eszközhívások profilozása;
- az állapotvesztés és az újbóli betöltés tesztelése;
- annak elmagyarázása nem szakértőknek, hogy egy ügynök miért látott — vagy miért nem látott — egy adott tényt.
Egy erős portfólióprojekt bemutathatná ugyanazt az ügynököt három kontextuskezelési szabályzat mellett: teljes átirattal, gördülő összefoglalóval, valamint célzott visszakereséssel támogatott strukturált hiedelemállapottal. Mutassa be a feladat sikeres és sikertelen eseteit, az egyes lépésekben elküldött kontextust, valamint a költség- és késleltetési kompromisszumokat. Ez meggyőzőbb egy chatbot-bemutatónál, mert feltárja azokat a tervezési döntéseket, amelyek megbízhatóvá tesznek egy ügynököt.
A stratégiai tanulság egyértelmű: az ügynökök nem válnak koherenssé pusztán attól, hogy a modellek egyre nagyobb teljesítményűek lesznek. Akkor válnak koherenssé, amikor a körülöttük lévő rendszerek fegyelmezett, aktuális és megfelelő méretű nyilvántartást vezetnek a munkáról. A kontextusmérnökség ennek a nyilvántartásnak a kialakítása — és annak ismerete, hogy mit kell kihagyni belőle.
Priya Raman az AI Career Brief felelős emberi szerkesztője.
