Alapfogalom
Mitől loop egy munka
Egy loop annyit jelent, hogy a modell nem egyszer válaszol, hanem dolgozik, ellenőrzi magát, javít, és újra nekifut, amíg valami meg nem állítja. Ez a valami a leállási feltétel. Lehet egy ember, aki rábólint, lehet egy számszerű küszöb, lehet egy óra, ami jelez, vagy egy esemény, ami kiváltja a következő kört. A fejlesztői leírás ezen a ponton a parancsokra ugrik, én viszont itt állnék meg, mert vezetőként ennyit kell érteni belőle. Aki elindít egy ilyen ciklust, az egy kész állapotot definiál. Ha a kész állapot nem mondható ki egy mondatban, és nem ellenőrizhető ember nélkül, akkor nincs mit automatizálni, csak egy gyors gépet kapunk, ami a hibáit is gyorsabban termeli.
Ettől lesz a téma vezetői és nem informatikai. Egy cég működésében rengeteg olyan munka van, amiről mindenki tudja, mikor van kész, csak még soha nem írta le senki. Amíg ez a tudás a fejekben van, addig az AI legfeljebb asszisztens lehet, aki minden lépésnél visszakérdez. Amikor a kész állapot papírra kerül, és mérhető lesz, onnantól a gép egyedül is tud dolgozni rajta.
Első fok
Első fok, körönként irányítunk
A legtöbb cég ma itt áll, akkor is, ha nem így hívja. Minden prompt egy kézi kör. A modell összeszedi a kontextust, elvégzi a munkát, valamennyire ellenőrzi magát, és visszaad egy eredményt, az ember pedig megnézi, és megírja a következő utasítást. Itt az ellenőrzést adjuk át, de csak részben, mert a végső pecsét a miénk marad.
Az Anthropic példája egy like gomb elkészítése egy felületen. Ott a modell módosítja a kódot, lefuttatja a teszteket, a fejlesztő megnézi az eredményt, és írja a következő kört. Hétköznapi, és ettől jó példa, mert mutatja, hol kezd el fájni ez a mód. Ha a felületi változást csak a tesztek látják, a böngészőben megjelenő hibát senki nem veszi észre, amíg az ember rá nem kattint. Ezért a leírás egy saját ellenőrző skill megírását javasolja, ami előírja, hogy felületi változásnál böngészőben, kattintással és a konzolt figyelve is ellenőrizni kell, nem elég a teszt zöldje.
Az ellenőrzés legyen számszerű, és ezt kódnál és szövegnél is ugyanúgy elmondom minden ügyfelemnek. Ha azt mondom a modellnek, nézd át, jó lett-e, akkor annyit kapok vissza, hogy jó lett. Amikor viszont azt mondom, a betöltési idő legyen két másodperc alatt, és a nyolc teszt mind fusson le, akkor a modell maga is tudja használni a mércét, és nem az én ízlésemre vár. A körönkénti mód akkor jó, amikor még felfedezünk vagy döntünk. Amikor már tudjuk, mit akarunk, a kézi körök elkezdenek drágák lenni, mert a mi időnk a leállási feltétel.
Második fok
Második fok, a célt adjuk át
A /goal parancs ennyit tesz. Itt az ember a leállási feltételt írja le, és nem a következő lépést. Ettől kezdve a modell addig iterál, amíg a cél teljesül, vagy amíg el nem fogy a megadott körszám. Egy külön kiértékelő modell ellenőrzi minden kör végén a feltételt, és ha nem teljesül, visszaküldi dolgozni a végrehajtót. Az Anthropic példája ebben az esetben az, hogy vidd a főoldal Lighthouse pontszámát 90 fölé, és állj le öt próbálkozás után.
Két tanács tartozik ide, és mind a kettő vezetői döntés, nem technikai. Mindig kell explicit körlimit, mert egy ciklus limit nélkül vagy végtelenül költ, vagy abban a hitben ér véget, hogy sikerült. A feltétel pedig legyen determinisztikus, tehát teszt darabszám, pontszámküszöb, hibák száma, és ne az, hogy legyen szebb vagy legyen jobb. Ha valaki argumentum nélkül hívja a /goal parancsot, kiírja az eddigi körök számát és a felhasznált token mennyiséget, ami arra jó, hogy lássuk, mennyibe került egy cél elérése, és ne csak azt, hogy elérte.
Ezen a fokon az átadott dolog maga a definíció. Amíg a cég belső nyelvén a kész állapot az, hogy a főnök elégedett, addig ez a fok nem elérhető. Ahol viszont van mérőszám, ott innentől a mércét menedzseljük a feladat helyett, és ez egészen más vezetői munka. Egy jó mérce megírása néha több időbe telik, mint maga a feladat, és utána hónapokig szolgál.
Harmadik fok
Harmadik fok, az időt adjuk át
A /loop és a /schedule parancsnál az ember a kiváltó ingert adja át. Ilyenkor a munka adott időközönként fut, ismétlődő feladatra vagy egy külső rendszer figyelésére. Egyszerű példák vannak rá. Reggelente összefoglalni a beérkezett üzeneteket. Ötpercenként megnézni egy nyitott kódbeküldést, kezelni az érkező megjegyzéseket, és javítani a megbukott ellenőrzéseket. Míg a /loop a saját gépen fut, és leáll, ha a gépet kikapcsolják, addig a /schedule felhőbeli rutinná alakítja ugyanazt, és ez túléli a laptop lecsukását is.
Az időköz igazodjon ahhoz, milyen gyakran változik a figyelt dolog, és ahol lehet, jobb eseményre reagálni, mint sűrűn kérdezgetni. Egy ötpercenként kérdező rutin a nap nagy részében üresen fut, és minden üres kör pénz. Az esemény alapú indítás ellenben akkor dolgozik, amikor van min.
Ha az időt átadjuk, akkor a rutin akkor is fut, amikor nem figyelünk, és ezt a fejlesztői szöveg nem mondja ki, de következik belőle. A hétfő reggeli összefoglaló péntek este is elkészül, ha úgy állítjuk be. Ezért itt már a hatókört kell tisztán látni, mi az, amihez a rutin hozzáér, és mi az, amihez soha.
Negyedik fok
Negyedik fok, a promptot is átadjuk
A proaktív mód az, amikor már a prompt sem a mi kezünkből jön. Ilyenkor a munka eseményre vagy ütemezésre indul, valós idejű emberi részvétel nélkül. Minden egyes feladat akkor ér véget, amikor a célja teljesül, a rutin pedig addig fut, amíg valaki ki nem kapcsolja. Az Anthropic példája, hogy a rendszer óránként átnézi a beérkező hibajelentéseket, mindegyiket kezeli, javít, és megválaszolja a bejelentőnek. Ehhez az ütemezés, a cél alapú ciklus, az előre megírt skill utasítások és a dinamikus munkafolyamatok együtt dolgoznak, vagyis az előző három fok egymásra épül.
Ezen a fokon az ember szerepe a rendszer tervezése és a kivételek kezelése. Minden, ami rutinszerű, megy magától, és minden, ami nem fér bele a kimondott célba, visszakerül egy emberhez. Ez a fok a legvonzóbb, erről szól a legtöbb bemutató, ugyanakkor ide csak az léphet fel, aki az előző hármat kibírta. Aki a második fokon nem tudta kimondani a kész állapotot, az a negyediken egy automatizált félreértést kap, és azt is óránként.
Egy példa
Az iroda példája végig a létrán
Egy húszfős könyvelőiroda vezetőjével ültem le ebben a hónapban, hogy ezt a létrát ráillesszük a saját munkájukra. A havi zárásnál a legtöbb idő a banki tételek párosítására megy, kivonat és számla, utalás és bejövő bizonylat. Ma ez úgy néz ki, hogy egy munkatárs feltölt egy kivonatot, a modell javaslatot ad a párosításra, a munkatárs átnézi, javít, és kéri a következő adagot. Ez az első fok, és az iroda jól van vele, mert a munkatárs minden körben tanul arról, mit tud a gép és mit nem.
A második fokhoz az irodának ki kellett mondania a kész állapotot. Ez az, hogy a kivonat minden tétele vagy párosítva van egy bizonylattal, vagy szerepel a nyitott tételek listáján indoklással, és a két oszlop összege megegyezik a kivonat záróegyenlegével. A mondat megfogalmazása két órába telt, és közben kiderült, hogy az iroda két könyvelője eddig két eltérő szabály szerint döntött a részteljesítésekről. Nem a ciklus hozta létre ezt a problémát, csak kikényszerítette, hogy végre leírják. Körlimitnek öt kört adtunk, mert az ötödik kör után a fennmaradó tételek már úgyis emberi döntést kérnek.
A harmadik fok az iroda számára az, hogy a kivonatok érkezésekor fusson a párosítás, és ne akkor, amikor valakinek eszébe jut. Mivel a bank naponta egyszer küld kivonatot, az ötpercenkénti kérdezgetésnek nincs értelme, a beérkezésre reagáló indítás viszont pont jó. A negyedik fokot az iroda nem lépte meg, és én sem javasoltam. Ahhoz, hogy a rendszer az ügyfélnek is írjon a hiányzó bizonylatokról, előbb hónapokon át kell látni, milyen minőségű a nyitott tételek listája, mert egy téves levél az ügyfélnek többet ront a bizalmon, mint amennyit a megspórolt idő ér.
Amikor ezt a történetet elmesélem más vezetőknek, a legtöbben a második foknál kezdenek bólogatni. Nem a technika miatt, hanem a két könyvelő miatt, mert náluk is van két ember, aki ugyanazt a munkát két szabály szerint csinálja, és eddig senki nem vette észre, mert mind a kettő eredménye elfogadható volt. A ciklus bevezetése az ilyen helyeken kevésbé automatizálási projekt, inkább szabályrendezés, amit a gép csak kikényszerít.
Költség
Költség, modell és gondolkodási szint
Három figyelmeztetéssel zárja az Anthropic az útmutatót, és a három együtt egy vezetői ellenőrzőlista. Az első a költség, és itt a legnagyobb tétel nem a körök száma, hanem az, melyik modell fut és mekkora gondolkodási szinttel. Ehhez az Anthropic tanácsa, hogy a rutinokat kisebb, gyorsabb modellre érdemes irányítani, és csak a döntést igénylő részt hagyni a legerősebbre. Az iroda példájában a párosítás nagy része gépies, ott elég a kisebb modell, a részteljesítések megítélése viszont a nagyobbra megy.
Egy másik figyelmeztetés a dinamikus munkafolyamatokról szól, ezek akár több száz párhuzamos ügynököt indíthatnak egy feladatból, ezért előbb kis részen kell kipróbálni, mielőtt az egész cégre engedjük. Több száz ügynök egy feladaton látványos a bemutatón, és ugyanilyen látványos a havi számlán. Az irodánál ezért egyetlen ügyfél egyetlen hónapjával indult a próba, és csak a harmadik hónap után került sorra a teljes ügyfélkör.
Jogosultság
Jogosultság, mit tehet meg magától
Automatikus módban a rutin engedélykérés nélkül fut, tehát előre kell eldönteni, mit tehet meg magától, és mit nem. Ebből az irodánál konkrét lista lett. A rutin párosíthat, listázhat és jelölhet, de nem könyvelhet le véglegesen, nem ír az ügyfélnek, és nem nyúl a korábbi hónapokhoz. Amíg ez a lista nincs leírva, az automatikus mód nem kényelmes, hanem vak.
Ezt a listát a legtöbb cégnél senki nem akarja megírni, mert kellemetlen. Ha leírom, mit tehet meg a gép magától, akkor azt is leírtam, mit tehet meg a munkatárs magától, és sok helyen ez a második kérdés évek óta tisztázatlan. A ciklus bevezetése itt is ugyanazt teszi, mint a kész állapotnál, kikényszerít egy döntést, amit eddig el lehetett halasztani.
Ellenőrzés
Ellenőrzés, a másik loop
Ha egy ciklus kódot ír, kell mellé egy másik, ami ellenőriz, és az Anthropic szerint ezt friss kontextusú, külön ügynök végezze. Ismerős az indok a könyvelésből, a saját munkáját senki nem ellenőrzi jól, mert ugyanazokkal a feltételezésekkel néz rá, amelyekkel elkészítette. A második ügynök nem tud a megoldás történetéről, csak a feltételt és az eredményt látja, és ezért talál olyat, amit az első átugrott.
Egy másik tanács szerint, ha egy eredmény nem felel meg, a rendszert kell javítani, és ne csak az adott hibát. Ha az iroda párosítója egy adott hónapban rosszul kezel egy devizás tételt, a kézi javítás egy hónapra elég, a szabály finomítása viszont minden következő hónapra. Ez a gondolkodás a vezetőknek ismerős a minőségirányításból, csak ott évekig tartott, amíg egy cég eljutott a hibajavítástól a folyamatjavításig. Egy ciklusnál ugyanez a lépés a bevezetés első hónapjában esedékes, mert a hiba másnap megint előjön, ha csak az eredményt javítjuk.
Zárás
Hol mondható ki a kész állapot
A vezetői kérdés végül az, hogy a saját cégünkben melyik munka tart ott, hogy a leállási feltétele kimondható. Nem minden munka tart ott, és nem is kell mindnek. Az ajánlatírás, a tárgyalás, a stratégia első fokon marad, mert ott a felfedezés a lényeg, és a kézi kör a munka maga. Ezzel szemben a zárás, a beérkező bejelentések első szűrése, a riportok előkészítése, a kódbeküldések megjegyzéseinek kezelése olyan munka, aminek a kész állapota leírható, mérhető, és egy külön ellenőrző is meg tudja nézni.
A loop ott működik, ahol a kész állapot definiálható és ellenőrizhető. Ahol ez nem megy, ott a ciklus egy gyorsabb hibagyár, ami ugyanazt a tévedést óránként ismétli, és közben számlát is ad róla. Ezért a bevezetést egyetlen ügyfélnél sem a parancsokkal kezdem, hanem azzal, hogy leülünk, és megpróbáljuk egy mondatban leírni, mikor van kész egy adott munka. Ahol a mondat megszületik, ott a második fok három héten belül megvan. Ha nem születik meg, a cégnek előbb a saját szabályaival van dolga, és ezt egyetlen modell sem végzi el helyette.
Ez az írás az Anthropic Loop engineering, getting started with loops című útmutatójára épül, amely a cég saját fejlesztői anyagai között jelent meg. A négy ciklustípus, a parancsok, a példák és a három figyelmeztetés onnan származik, a könyvelőirodai eset és a vezetői olvasat a saját tapasztalatom.