Válaszvázlatok a gondolatébresztő kérdésekhez

Ez a fájl a könyv mind a tíz fejezetének gondolatébresztő kérdéseihez gyűjti össze a válaszvázlatokat. A legtöbb gondolatébresztő kérdés nyitott végű, és nincs egyetlen helyes válasza. A válaszvázlatokat AI generálta, emberi könnyed ellenőrzéssel, és kizárólag az olvasók összehasonlítására és inspirációjára szolgálnak. Az olvasókat bátorítjuk, hogy használjanak egy LLM-et a könyv tartalmával együtt e kérdések további megvitatásához.

1. fejezet: Ismerkedés az AI-ügynökökkel

1. (★★) Ha csak egy képességet adhatnál egy Agent-rendszerhez – egy erősebb modellt, gazdagabb kontextust vagy több eszközt –, melyiket választanád? Milyen feltételek mellett változna a döntésed?

Az "agy/szemek/kezek és lábak" formulát követve először a gyenge láncszemet keresd: általában a prioritás a kontextus gazdagítása – vagyis a megfigyelési tér kiterjesztése. Ha a feladat meghaladja a modell érvelési képességét, válts erősebb modellre. Ha a cselekvési tér nem elégséges (például nincs hozzáférés belső vállalati rendszerekhez), adj hozzá eszközöket. A megítélés módja a hibapályák elemzése és annak meghatározása, hogy a szűk keresztmetszet az észlelésben, a döntéshozatalban vagy a cselekvésben rejlik.

2. (★★★) A ReAct hurokban az Agent minden egyes LLM-hívása megkapja a teljes előzménytrajektóriát, így a trajektória növekedésével a tervezés költsége négyzetesen nő. Megtörhető ez a négyzetes növekedés anélkül, hogy kritikus információ veszne el?

Életképes megközelítések: kontextus-tömörítés – a korai trajektória összegzése, csak a következtetések és a kulcsfontosságú állapot megtartása (a 2. fejezet többrétegű tömörítése); externalizált tanulás – köztes eredmények fájlokba vagy tudásbázisba írása, majd igény szerinti lekérése a kontextusban tartás helyett; a munka felosztása alügynökökre.

3. (★★) A "Model as Agent" paradigma szerint a modellek egyre autonómabbá válnak az eszközhívási döntésekben. Ez a fejezet azonban azt állítja, hogy a Harness tervezés fontossága valójában növekszik. Hogyan fér meg ez a két trend egymás mellett? Hol van az Agent-keretrendszerek jövőbeli magjának értéke?

A ló és kantár metafora: minél erősebb a modell és minél nagyobb az autonómiája, annál szélesebb a hibák becsapódási sugara, és annál nagyobb a korlátozás, ellenőrzés és korrekció iránti igény. A keretrendszerek értéke az "LLM-hívások összehangolásáról" a Harness öt elemének biztosítási rétegére tolódik: engedélyosztályozás, megszakítók (circuit breakers), hibakezelés, kontextus-tömörítés és az eszközök ökoszisztémája.

4. (★★) Az ablációskísérletben az "eszközeredmény-visszajelzés" hiánya végtelen ciklusba küldte az Agentet. Éles környezetben az eszközeredmények hiányán kívül milyen más helyzetek okozhatnak ciklust? Milyen detektálási és megszakítási mechanizmusokat terveznél?

Egyéb okok: egy eszköz ismételten ugyanazt a hibát adja vissza; hallucinált hívások nem létező eszközökhöz; a kontextus-tömörítés eldob kritikus állapotinformációt; a gondolkodási tartalom levágása és a modell API hibája; maga a feladat megoldhatatlan. Mechanizmusok: megállási feltételek, például maximális iterációszám beállítása; ismétlődő hívások detektálása (ugyanazon eszköz + argumentum ujjlenyomat); emberi beavatkozásra eszkalálás, ha egy hibaküszöb túllépésre kerül.

5. (★) Ez a fejezet öt Agent-terméket elemzett három dimenzió mentén: munkakontextus, cselekvési interfészek és stratégia. Válassz ki egy általad naponta használt AI-terméket, elemezd ugyanezen három dimenzió mentén, és ítéld meg, hogy megfelelő-e az architektúrája. Ha te terveznéd, min változtatnál?

Nyitott végű. Főbb pontok: a fejezet táblázatát követve írd le a szemeket (milyen információforrásokat láthat), a kezeket és lábakat (a cselekvési tér nyitott végű-e, képes-e belső gondolkodásra), valamint a stratégiát (az Agent végrehajtási hurkának mintázata).

6. (★★) Ha egy kifejezetten repülőjegy-foglalásra szánt ügyfélszolgálati rendszert terveznél, a workflow mintát vagy az autonóm Agent mintát választanád? Lehetséges a két minta keverése ugyanabban a rendszerben?

Használj workflow-t gerincként: négy csomópont – személyazonosság-ellenőrzés → keresés → fizetés → foglalás –, ami garantálja a megfelelő sorrendet, például "nincs foglalás fizetés előtt", és a prompt-injekciós támadási felületet egyetlen csomópontra korlátozza. Válts autonóm Agent-re a nyitott végű szegmensekhez (igények megértése, átfoglalás, alternatívák ajánlása járattörléskor). Adj hozzá emberi megerősítést magas kockázatú műveletekhez (nagy összegű fizetések, visszatérítések).

7. (★★★) A korlátokról szóló szakasz említette az eszközkockázati besorolásokat. Ha egy eszköz általában alacsony kockázatú, de bizonyos paraméterkombinációkkal magas kockázatúvá válik (pl. a delete_file normál fájl törlése vs. rendszerfájl törlése), hogyan terveznéd a dinamikus kockázatértékelést?

Finomítsd az értékelés célpontját "eszközről" "eszköz + argumentumokra": számítsd ki a kockázatot híváskor a visszafordíthatóság, engedélyek és becsapódási sugár alapján. Használj szabályalapú determinisztikus ellenőrzéseket (útvonal-engedélyezési/tiltási listák, reguláris kifejezések) modellítélet helyett. Az ellenőrzés csak strukturált adatokat nézzen, hogy védjen a prompt-injekciós manipuláció ellen.

8. (★★) A fejezet Agent-termék táblázatában minden Agent "nyitott végű" cselekvési térrel rendelkezik. Milyen forgatókönyvekben lenne egy korlátozott cselekvési tér (pl. csak előre meghatározott opciókból választás) jobb, mint a nyitott végű?

Magas megfelelőségi, magas kockázatú, visszafordíthatatlan hibájú forgatókönyvek: visszatérítéseknél és fizetéseknél a korlátozott opciók "megkötések" – eleve hibabiztosak, lehetetlenné teszik a hibákat tervezés által.

9. (★★) Az emberi beavatkozási mechanizmus megköveteli az Agenttől, hogy "kecsesen adja át az irányítást". A gyakorlatban azonban a felhasználó offline lehet, lassan válaszolhat, vagy homályos utasításokat adhat. Mit tegyen ilyenkor az Agent?

Hibabiztos működés: magas kockázatú műveletek szüneteltetése, ha nem érkezik megerősítés, ahelyett, hogy alapértelmezés szerint végrehajtaná; a visszafordítható, alacsony kockázatú részek elvégzése először, a magas kockázatúak dokumentálása, hogy egy ember dönthessen és az Agent folytathassa; értesítés aszinkron kommunikációs eszközökön keresztül (üzenetek, e-mail) időtúllépési politikával; szándéktisztázás homályos utasítások esetén.

10. (★★★) A bevezető szerint "a jó tervezési elveknek túl kell mutatniuk a modell iterációs ciklusain", de az ezeket megvalósító konkrét mérnöki módszerek a modellek képességeinek fejlődésével elavulhatnak. Adj példát egy ilyen Agent-mérnöki módszerre, és indokold meg.

1. példa: korlátozott mintavételezéssel szigorú formátumra kényszeríteni az eszközhívásokat. Ez megbízhatósági javítás azoknál a modelleknél, amelyek gyakran érvénytelen JSON-t adnak ki vagy paramétereket hagynak el. A formátumkövetés javulásával a haszna csökkenhet, de magas kockázatú helyzetekben továbbra is determinisztikus formátumellenőrzésre van szükség.

2. példa: külső tudásbázist bevezetni, mert a modell nem képes folyamatosan befogadni az új tudást. Ha a modellek később megbízható folyamatos tanulási képességet kapnak, a tudáskarbantartás egy része a külső rendszerekből a modell paramétereibe költözhet. A külső tudásbázisok azonban önálló értéket nyújtanak a valós idejű frissítés, a pontos visszakeresés, a hozzáférés-szabályozás és a forráskövetés terén, ezért inkább az alkalmazási körük szűkülhet, mintsem teljesen eltűnnének.

3. példa: minden képességet kötelezően a modell API-jának szabványos eszközhívási felületén elérhetővé tenni, és megtiltani az egyedi hívási formátumokat. A Skills másik utat mutat: szövegben leírja a képességet és a használat módját, majd egy általános parancssori eszközzel hajtatja végre a modellel. A modell szempontjából ez egy általános végrehajtó fölé épített egyedi szöveges hívási protokoll megértését és követését jelenti. Ahogy a modellek egyre jobban értik a tetszőleges interfészeket, a "mindig a szabványos eszközhívási formátumot kell használni" már nem egyetemes elv. A szabványos formátumok továbbra is hasznosak az interoperabilitáshoz, a strukturált ellenőrzéshez és a kevésbé képes modellekhez, de a helyzettől függő mérnöki választásnak kell lenniük.

4. példa: a promptokat és minden eszközdefiníciót előre a kontextus elejére helyezni. Ez a gyakorlat azért alakult ki, mert a korai modellek utasításkövetési képessége korlátozott volt, és a megszokott rögzített helyeken kívüli promptokat vagy eszközdefiníciókat gyakran nem ismerték fel, illetve nem hajtották végre helyesen. A Skills futás közben, igény szerint a kontextus közepére tölti a promptokat, a dinamikus eszközfelfedezés pedig a már meglévő trajectory után fűzi az újonnan megtalált eszközök definícióit. Az utasításkövetés javulásával és az ilyen dinamikus betöltési módokra irányuló speciális utótanítással a promptokat és az eszközdefiníciókat már nem kell a kontextus elején rögzíteni.

2. fejezet: Kontextus-tervezés

1. (★★★) A 2-3. kísérletben a beszélgetési előzmények csúszó ablaka azt okozta, hogy az Agent ismételten ugyanazokat az eszközhívásokat hajtotta végre. A teljes előzmény megtartása viszont a kontextus végtelen terjeszkedéséhez vezet. Tervezz egy stratégiát, amely elkerüli az információvesztést, miközben szabályozza a kontextus hosszát anélkül, hogy megtörné a KV Cache előtagját.

① Cseréld ki az eldobást tömörítésre: üzenetek csak hozzáfűzésre kerülnek, soha nem törlődnek vagy szerkesztődnek; egy küszöb (pl. az ablak 80%-a) közeledtével kötegelt tömörítés a régi eszközeredményekre. ② Rétegezett mechanizmus: nagy kimenetek perzisztálása lemezre egy összegzéssel, zaj teljes törlése, és archív összegzések megtartása, amelyek megőrzik a szálat. ③ Alügynök-izoláció, így a köztes állapot soha nem kerül a fő kontextusba.

2. (★★) A Qwen3 Chat Template gondolkodásimegtartó mechanizmusa csak "az utolsó valódi felhasználói üzenet utáni" gondolkodási tartalmat tartja meg. Ha egy ReAct hurok több száz eszközhívást ölel át, a felhalmozott gondolkodási tartalom nagy mennyiségű kontextust fogyaszthat. Hogyan módosítanád ezt a mechanizmust a nagyon hosszú hurkok kezelésére? A DeepSeek R1 egykor az összes történeti gondolkodási tartalom levágását követelte meg, míg a DeepSeek V4 ezt megfordította, és előírta az összes reasoning_content visszaadását – összehasonlítva ezt a két ellentétes stratégiát, mik az előnyei és hátrányai? Mit jelez ez a fordulat?

Módosítási irány: csúszóablakos megtartás – a legutóbbi gondolkodási körök teljes megtartása; az ablakon kívül gördülő tömörítés token-költségvetés alapján (nem fix körszám alapján), strukturált állapotsáv létrehozása (jelenlegi cél, megerősített tények, kizárt utak, teendők). A tömörítés csak egyszer és egy rögzített pozícióban történik, így a cache-újraépítés költsége egyszer fizetendő, nem minden körben. R1 levágása: tokeneket takarít meg, stabil előtagot és cache-barát viselkedést biztosít, illeszkedik a betanítási eloszláshoz (történeti CoT soha nem jelenik meg a bemenetben); de minden körben a semmiből érvel, a hosszú távú tervek elvesznek, a hibák ismétlődnek. V4 kötelező visszaadása: koherens gondolkodás és jobb teljesítmény hosszú horizontú agentikus feladatokon; de magas tokenköltség, előtag-duzzadás minden körben, és nincs zökkenőmentes váltás nem-gondolkodó módból. A fordulat azt mutatja: tiszta dialógusban a gondolkodás pazarlás; agentikus forgatókönyvekben a gondolkodás állapot – és az iparági gyakorlat az utóbbi felé mozdult.

3. (★★) A kontextus-tudatos tömörítési kísérletben körülbelül 148 000 karakterről körülbelül 2000 karakterre tömörítettek – kockáztat-e ez a szélsőséges tömörítés "visszafordíthatatlan információvesztést"? Hogyan lehet ezt kezelni?

Igen, van kockázat: a tömörítés veszteséges vetítés, és ha a kérdés egy nem megőrzött dimenzióra esik, megtörik. A megoldás: "veszteséges tömörítés + veszteségmentes indexelés" – minden tény egy forrás URL-t hordoz a nyomonkövethetőségért; a nyers kimenetek lemezen tárolódnak, csak összegzett előnézetekkel a kontextusban; explicit megőrzési prioritások – architekturális döntések, szemantikai integritás (idők, cégnevek), ellenőrzési állapot és azonosítók, mint UUID-ek/hashek szó szerint megőrizve; adaptív ablakozás késlelteti a tömörítés pillanatát.

4. (★★) Az Agent állapotsáv explicité teszi az implicit állapotokat. Ha azonban az állapotsáv hibás információt tartalmaz (pl. hiba az eszközállás-számlálóban), az Agent káros döntéseket hozhat a helytelen információk alapján. Hogyan enyhíthető ez a "meta-információ megbízhatósági" probléma?

A modell szinte feltétel nélkül megbízik az állapotsávban, így a hibák úgy terjednek tovább, ahogy vannak. Enyhítések: ① karbantartás determinisztikus kóddal – soha ne hagyd, hogy egy LLM kötegelt számlálást végezzen hosszú előzményeken (ha muszáj, tételenként kivonatolni és kódban összesíteni); ② az állapotsáv pontosságának nyomon követése első osztályú termelési mérőszámként; ③ információk csak megbízható valós világbeli megfigyelésekből származzanak, védekezve az állapotsáv-mérgezés ellen.

5. (★★) A prompt-tervezési ablációskísérlet szerint a rendezetlen információ több mint 30%-os sikerességi aránycsökkenéshez vezet. A valós fejlesztésben azonban a rendszerpromptokat gyakran többen, különböző időpontokban karbantartják. Milyen mérnöki gyakorlatokat használnál annak megakadályozására, hogy a rendszerpromptok idővel egyre rendezetlenebbé váljanak?

① Kezeld a promptokat kódként: verziókövetés és felülvizsgálat, ahol a termékmenedzserek határozzák meg az üzleti szabályokat, a mérnökök pedig kódolják azokat; ② használj Tau-Bench-szerű benchmarkokat regressziós tesztekként, futtass ablációkat a változtatások előtt és után a hatás lokalizálásához; ③ kényszeríts ki struktúrát: SOP-vezérelt folyamat a szabályhalmazok helyett, rétegezve XML/Markdown segítségével; ④ osztályozd és nevezd el a töredékeket "cache-elhető / cache-törő" kategóriákba, a dinamikus tartalmat a cache-határ után helyezve; ⑤ a felfúvódott tartalmat oszd fel igény szerint betöltött Skills-ekre.

6. (★★★) Ez a fejezet azt állítja, hogy "a kontextusban való tanulás lényegében lekérés, nem érvelés". Ha ez az állítás helytálló, akkor az összes jelenlegi, "több információ kontextusba helyezésén" alapuló optimalizációs irányt újra kell értékelni. Hogyan lehet ezt a korlátot leküzdeni?

Adj hozzá egy desztillációs réteget ehhez a "fél lekérőmotorhoz": ① kontextus-desztilláció / az állapotsáv – használj kódot a következtetések előre kiszámításához közvetlen lekéréshez; ② aktív tömörítés, a nyers rekordok helyettesítése nagy sűrűségű strukturált tudással; ③ alügynök-izoláció, a zaj kizárása a fő kontextusból; ④ interakció mint harmadik tengely – külső eszközök megfigyelnek és visszaírnak olyan új információt, amit a modell nem tudott kigondolni; ⑤ határvonali irányok: szerkeszthető, összeállítható KV Cache "jegyzetek" és munkamenetek közötti memóriakonszolidáció.

7. (★★★) A Skills progresszív felfedése csak akkor tölti be a teljes tartalmat, ha az Agent szükségesnek ítéli. Ez az ítélet azonban maga is a modell képességétől függ – ha a modell nem tudja, hogy mit nem tud, nem tudja helyesen kiváltani egy Skill betöltését. Hogyan oldható meg ez a "metakogníciós" probléma?

① Tartsd a Skill metaadatait (név, leírás) a kontextusban rezidensként, hogy a modell mindig "tudja, mije van"; ② írd a Skill leírást útválasztási feltételekként, ne funkcióbemutatóként – "Használd, ha / Ne használd, ha" – kerülve a homályos leírásokat.

8. (★★) A Skills mechanizmusban miután az Agent dinamikusan betölti az utasításokat a SKILL.md-ből, a későbbi műveletek megbízhatóan követik azokat? Milyen különbségek vannak a Skills mintázat modelltámogatásában?

Attól függ, hogyan injektálódik a Skill: a rendszerpromptba injektálva a legerősebb az utasításkövetés, de megtöri a KV Cache-t; közönséges fájlként a kontextus közepébe olvasva gyengébb utasításkövetést adhat; a kontextus végére injektálva jó utasításkövetést ad, de a Skill rész KV-jét minden eszközhívásnál újra kell számolni, ami költséges.

9. (★★★) Ez a fejezet hangsúlyozza, hogy a dinamikus információ változásai (pl. rendszer időbélyegek, eszközlista sorrendje) megtörhetik a KV Cache előtag-találatokat. Egy nagy számú, gyakran változó eszközkészlettel rendelkező éles rendszerben hogyan terveznéd a kontextus elrendezését a cache találati arány maximalizálására?

① Egy kis halmaz stabil mag-eszköz (mondjuk hét) plusz egy általános végrehajtó, a specifikus képességek a Skills progresszív felfedésén keresztül érkeznek; az eszközdefiníciók a statikus előtagban rögzített sorrendben fagynak le; ② az alügynökök ugyanazt az előtagot tartják, mint a szülő Agent.

3. fejezet: Felhasználói memória és tudásbázis

1. (★★) Egy felhasználói memóriarendszerben, amikor ugyanaz a felhasználó ellentmondó információkat ad meg különböző munkamenetekben (pl. két különböző lakcímet említ), hogyan kezelje a memóriarendszer ezt az ütközést?

Használj egy Mem0-stílusú "kivonat–összehasonlít–dönt" csővezetéket: először hasonló régi emlékek lekérése vektoros kereséssel, majd egy LLM dönt ADD/UPDATE/DELETE/NOOP műveletről – például "elköltözött Sanghajba" frissítse és írja felül a "Pekingben lakik" bejegyzést. Verziózás: a cím típusú információknál csak a legújabb verzió tárolása időbélyeggel, de a munkatapasztalat típusú információknál a teljes előzmény megtartása. A lekérési oldalon a kontextuális előtagok (személy, idő, szándék – mint a háromszor módosított átutalás esetében) segíthetnek megítélni, melyik bejegyzés a végül érvényes.

2. (★★) A Kontextuális Lekérés (Contextual Retrieval) az eredeti dokumentumból származó kontextust ad minden darabhoz. Ha azonban maga az eredeti dokumentum szerkezetileg rendetlen vagy ellentmondásos információkat tartalmaz, ez a módszer továbbíthatja vagy akár felerősítheti a hibákat. Hogyan vezetnél be egy "információminőségi" jelet a lekérési fázisban?

Meríts a "tudásbázis-frissesség és -irányítás" témakörből: csatolj metaadatokat, például verziószámokat, hatályba/lejárati időket és forrásokat a darabokhoz; szűrd ki a lejárt tartalmat lekéréskor, vagy jelöld meg explicit módon az előtagban "ezt a bejegyzést visszavonták ilyen-olyan dátumon"; a rangsorolási szakaszban építsd be a forrás tekintélyét és az időbeli frissességet a pontszámba a puszta szemantikai relevancia helyett; indexeléskor az előtag-generáló LLM is érzékelje és jelezze a darabok közötti ellentmondásokat, hasonlóan a verziózott ütközésdetektáláshoz a memóriában.

3. (★★★) Az Agentikus RAG lehetővé teszi az Agent számára, hogy aktívan döntsön arról, mikor keressen, mit keressen, és folytassa-e a keresést. De ha a modell nem tudja, hogy mit nem tud, nem tudja helyesen kiváltani a keresést. Hogyan oldható meg ez a "metakogníciós" probléma?

① Kódold be "az információ elégségességének értékelését" explicit lépésként a promptba/skillbe: mint a 3-9. kísérletben, először párhuzamosan keresd le az alkérdéseket, fedezd fel a hiányzó láncszemet – "hogyan befolyásolja a korábbi bűnügyi nyilvántartás a gondatlan bűncselekmények büntetését" –, majd futtass egy második lekérési kört; ② tarts könnyű meta-információt rezidensként a kontextusban egy globális nézethez – például JSON Cards áttekintések vagy OpenViking L0/L1 összegzései –, így az Agent tudja, "mi van a boltban".

4. (★★) A multimodális információ-kinyerés a diagramokat szöveges leírásokká alakítja a lekérés előtt. Ez a "fordítási" folyamat elveszítheti a vizuális információ térbeli kapcsolatait. Adj egy konkrét példát olyan diagraminformációra, amelyet egy tiszta szöveges leírás nem tud teljes mértékben visszaadni, és tervezz egy sémát az információ megőrzésére.

Példák: a logikai kapcsolatok egy rendszerarchitektúra-diagramban, két görbe metszéspontjának helyzete egy vonaldiagramon, vagy a cellák és fejlécek sor-oszlop megfeleltetése egy PDF táblázatban. Első lehetőség: natív multimodális feldolgozás; második lehetőség: egy multimodális képelemző eszköz biztosítása.

5. (★★★) Rich Sutton "Keserű leckéje" (Bitter Lesson) szerint az általános módszerek (keresés és tanulás) végül felülmúlják a kézzel készített jellemzőket. Maga az ebben a fejezetben felépített teljes tudásrendszer (darabolási stratégiák, indexstruktúrák, lekérési csővezetékek) is egyfajta "kézzel készített tervezés"? Ha a modellképességek elég erőssé válnának, ezeket a terveket felválthatná egyszerűen "mindent bemenetként adni"?

Valóban kézzel készített tervezés, és egyes szakaszok (darabolás, fúziós hangolás) gyengülhetnek, ahogy a kontextus hosszabb lesz; de a fekete-macska/fehér-macska eset azt mutatja, hogy a "mindent bemenetként adni" sem elég: a figyelem (attention) lágy lekérés, és a dokumentumok közötti aggregáció és statisztikák továbbra is elő-desztillációt igényelnek az indexeléskor; a mérnöki korlátok, mint a tudás lejárata és frissítése, engedély-/bérlő-izoláció, naplózhatóság és költség, függetlenek a modell képességétől; és a lekérés plusz LLM-desztilláció az indexeléskor maga is egy általános "keresés + tanulás" módszer, nem ellentétes a Keserű leckével.

6. (★★★) Ahogy a modellképességek javulnak, szerinted a domain-specifikus tudásbázisok továbbra is fontosak lesznek? Lehet, hogy egy jövőbeli erős alapmodell potenciálisan tartalmazná az összes információt egy domain tudásbázisból, ezzel megszüntetve a szükségességét?

Továbbra is fontos: a betanítási adatoknak van vágási dátuma, míg egy tudásbázis bármikor frissíthető; a belső vállalati folyamatok, magánjogi esetjog és hasonlók egyszerűen nincsenek benne a nyilvános korpuszban; a többfelhasználós megosztáshoz engedélyszűrés és bérlő-izoláció kell, a paraméterekben lévő tudás pedig nem szabható testre hívónként; a külső tárolás naplózható, verziókövethető, és a lejárt tartalom offline állapotba helyezhető – a parametrikus memória ezt aligha tudja; még a parametrikus úton (post-training / User as Engram) is szembesülsz azzal a problémával, hogy "emlékezni könnyű, de a tényeket többugrásos érveléshez használni nehéz".

7. (★) A RAPTOR alulról felfelé építkező hierarchikus összegzéssel fa-indexet épít, míg a GraphRAG entitáskapcsolatokon keresztül gráfstruktúrájú indexet. Milyen típusú lekérdezéseknél jók ezek a strukturált indexek?

RAPTOR: "rétegeken átívelő" lekérdezések, amelyek makro fogalmaktól részletekig hatolnak – például először a "SIMD utasításkészlet" összegzésének megtalálása, majd a részletezés az SSE részletekbe – lefedve mind az áttekintő, mind a részletes granularitásokat. GraphRAG: többugrásos relációs érvelés ("annak a kórháznak a címe, ahol az orvosom dolgozik", a relációs lánc bejárása) és entitás-egyértelműsítés (két "Dr. Kovács" különböző csomópontok) – "mi a kapcsolat A és B között" típusú lekérdezések; a közösségi összegzések tematikus klaszterezést is nyújtanak.

8. (★★) A fájlrendszer-paradigma a tudást egy fájlrendszerhez hasonló hierarchikus struktúrába szervezi. A hagyományos vektoradatbázisos RAG-hoz képest milyen forgatókönyvekben előnyös ez a megközelítés?

A plain text fájlokat a felhasználók közvetlenül olvashatják, szerkeszthetik és javíthatják, valamint Git-tel verziókövethetők és visszaállíthatók – alkalmas olyan forgatókönyvekre, ahol emberek és gépek közösen tartják karban és ellenőrzik a tudást; a write_file képességgel az Agent autonóm módon rögzíthet tapasztalatokat, önfejlődő memóriaciklust képezve (externalizált tanulás); az L0/L1/L2 progresszív felfedés lehetővé teszi, hogy a legtöbb lekérdezést L1 szinten eldöntsék, tokeneket megtakarítva; az előfeltétel a keresztlinkek és indexoldalak kiépítése, mint a Wikipédiában – különben minél több elszigetelt fájl van, annál nehezebb a lekérés.

9. (★★★) Az "ítéleti tényezők" és "tényező fontossági hierarchiák" automatikus felfedezése strukturált adatokból (pl. bírósági ítéletek adatbázisaiból) lényegében azt jelenti, hogy az Agent szabályokat vezet le az adatokból. Elérheti ez az adatvezérelt tudáskinyerés a humán szakértők által kézzel készített szabályok minőségét?

Előnyök: mint a CAIL2018 kísérletben, az "alulról felfelé" tényezőfelfedés illeszkedik az adatokhoz, nem emberi előfeltevésekhez; képes megragadni az implicit kompromisszum-tapasztalatokat, amelyek tízezerszám szóródnak szét az ítéletekben, és amelyeket a szakértők aligha tudnának explicit leírni; és kvantifikálható. Korlátok: az LLM-kinyerési hibák tudásszennyezést okoznak; magának az adatnak a torzításai öröklődnek; a klaszterezési prototípusok csak korrelációt tükröznek, nem tudnak okozati összefüggést magyarázni. Kompromisszum: adatvezérelt modellezés plusz szakértői felülvizsgálat a sémán és az eredményeken – a modellek vezetik a kérdezést, a statisztika támogatja a magyarázatokat.

4. fejezet: Eszközök

1. (★★) Az MCP szabvány leválasztja az eszközdefiníciókat az Agent keretrendszerről. A szabványosítás azonban azt is jelenti, hogy az összetett eszközinterakciós minták (pl. streamelő kimenet, kétirányú kommunikáció, állapotos munkamenetek) nehezen fejezhetők ki egy szabványos protokollban. Szerinted milyen képességet kellene leginkább kiterjesztenie az MCP-nek a jövőben?

A leginkább szükséges bővítés a munkamenetek közötti, eseményvezérelt működés. Az MCP már támogat többlépéses interakciókat, változás-előfizetéseket és hosszú ideig futó feladatokat, de a lényege továbbra is egy képességhívás szabványosítása, nem pedig az Agent folyamatos online tartása. Új e-mail vagy külső visszahívás hatására az Agent felébresztése, valamint több esemény sorba állítása, folytatása és újrapróbálása továbbra is az Agent keretrendszer feladata. Az ilyen vezénylés egységesebb konvenciói az MCP hatókörét a protokoll egyszerűségének feladása nélkül bővítenék.

2. (★★) Aszinkron Agent-architektúrában az eseménysor prioritási stratégiáját tervezéskor kell meghatározni. De ha a prioritás megítélése maga szemantikai megértést igényel (pl. annak eldöntése, hogy egy új üzenet sürgősebb-e, mint az aktuális feladat), kinek kell ezt az ítéletet meghoznia – egy szabálymotornak vagy egy másik LLM-hívásnak? Melyek az egyes lehetőségek költségei?

Rétegezett hibrid: a tiszta típusú események szabályokkal vannak kódolva – nulla késleltetés és erős determinizmus, de nem képes megérteni a szemantikai különbséget "azonnal hagyd abba" és "milyen ma az idő" között; a szemantikailag kétértelmű események egy könnyű osztályozó LLM-hez kerülnek esemény-útválasztóként, több száz ezredmásodperces késleltetés, többletköltség és lehetséges téves ítélet árán – és a Sidecar-hoz hasonlóan csak strukturált mezőket szabad olvasnia a prompt-injekció elleni védelem érdekében.

3. (★★) Az MCP ökoszisztémában különböző MCP szerverek erősen átfedő funkciójú eszközöket nyújthatnak. Amikor egy Agent több, funkcióilag hasonló eszköz között választhat különböző forrásokból, hogyan döntsön? Ha az azonos nevű eszközök különböző forrásokból kissé eltérően viselkednek (pl. az egyik összegzést ad vissza, a másik a teljes szöveget), az Agent érzékeli és kihasználja ezt a különbséget?

Kiválasztási kritériumok: integráció előtt tekintsd át a leírásokat, rögzítsd a verziókat, és konfigurálj least-privilege hitelesítő adatokat; óvakodj az azonos nevű eszközök árnyékolásától, amely érzékeny hívásokat irányíthat egy rosszindulatú félhez; futásidőben szűkítsd a jelölteket hierarchikus osztályozással és dinamikus felfedezéssel. Az, hogy a modell érzékeli-e a viselkedésbeli különbségeket, az eszközleírások minőségétől függ.

4. (★★★) Amikor egy Agent a felhasználó nevében lép kapcsolatba a külvilággal, lényegében egy identitásválasztással szembesül: használjon független virtuális identitást (dedikált e-mail és telefonszám) harmadik félként, vagy közvetlenül a felhasználó személyes fiókjait kezelje felhasználóként? Az előbbi lehetővé teszi az autonóm háttérműködést, de harmadik felek nem biztos, hogy megbíznak egy nem-emberi identitásban; az utóbbi teljesebb kontextussal és engedélyekkel rendelkezik, de hitelesítési, bizalmi és biztonsági határvonali problémákat vet fel. Szerinted milyen forgatókönyvekben melyik módot érdemes választani?

Alapértelmezés szerint virtuális identitás: autonóm módon működhet a háttérben és naplózható, és ha hibázik vagy feltörik, nem teszi ki a felhasználó teljes digitális identitását – ahogy egy titkárnő is a saját irodai e-mailjét használja; kezelned kell a CAPTCHA/IP-reputációs problémákat (rezidens proxyk). Olyan forgatókönyvek, ahol a felhasználó saját identitását kell használni (fiókazonosság-ellenőrzés, háromutas hívás-megerősítés – mint amikor Pine felhívja az ügyfélszolgálatot) emberi beavatkozásos hitelesítést igényelnek: VNC/RDP segítségével a felhasználó személyesen és vizuálisan jelentkezhet be. A kritériumok: hogy a másik fél személyesen kéri-e a fióktulajdonost, valamint a művelet kockázata és a hitelesítő adatok hatóköre.

5. (★★) Sor-alapú eseményfeldolgozásban a modellek hajlamosak csak az utolsó eseményre koncentrálni. Ez a fejezet az Agent állapotsáv jelzőivel és összegzéssel enyhíti ezt. De ha a sorban 20 esemény halmozódott fel (10 eszközeredmény + 5 felhasználói üzenet + 5 rendszerriasztás), hogyan szerveznéd ezen események bemutatási sorrendjét és formátumát, hogy a modell ne hagyjon ki kulcsfontosságú információt?

Először osztályozd és deduplikáld szabályokkal és egy könnyű LLM-mel: a sürgős események (riasztások, felhasználói megszakítások) külön, cancel-típusú kezelésen mennek keresztül, és nem keverednek a kötegbe. A 10 túl hosszú eszközeredmény esetében csonkold és perzisztáld fájlokba, csak a fejet, a farkot és az elérési utat megtartva. Adj hozzá egy összegző listát a rendszer állapotsávhoz a kontextus végén (minden eseménytípus darabszáma + az egyes tételek megválaszolásának követelménye).

6. (★★) Ez a fejezet egy "végrehajtás-érvényesítés-visszajelzés" hurkot javasol (pl. linter automatikus futtatása kódírás után). Milyen más eszköz-forgatókönyvekre alkalmazható ez az "azonnali művelet utáni automatikus érvényesítés" minta? Vannak olyan műveletek, ahol maga az érvényesítés költsége vagy kockázata meghaladja a műveletét, ami miatt a minta nem alkalmazható?

Általánosítható forgatókönyvek: konfiguráció módosítása után tényleges futtatás sandboxban a hatás ellenőrzésére; dokumentum/prezentáció generálása után renderelés képernyőképekbe és a modell multimodális képességének használata az elrendezés ellenőrzésére. Nem alkalmazható: visszafordíthatatlan, nem idempotens műveletek, mint e-mail küldése, telefonhívás kezdeményezése vagy pénzátutalás – vagy nincs mit megfigyelni, vagy maga az érvényesítés egy másik valós eseményt vált ki; itt ex ante eszközökre kell váltani: Proposer-Reviewer előzetes jóváhagyás.

7. (★★) Ez a fejezet felveti az "eszközrobbanás" problémáját – az Agent kiválasztási pontossága romlik, ha több ezer eszközzel szembesül. A proaktív eszközfelderítésen kívül milyen más megközelítések léteznek? Gondolkodj el azon, hogyan kezelik a humán szakértők a rendelkezésre álló eszközök hatalmas gyűjteményét.

① Hierarchikus csoportosítás: először a "szerver/alkalmazás" lokalizálása, majd a konkrét eszköz kiválasztása; ② Skills-stílusú "igény szerinti konzultáció": mint egy kézikönyv fellapozása – a katalógus a kontextusban marad, a részletek igény szerint töltődnek be; ③ néhány gyakran használt alapvető eszköz "kéznél tartva" a kontextusban, a többi a katalógus indexen keresztül érhető el.

5. fejezet: Kódoló Agent és kódgenerálás

1. (★★) A kódgenerálást az Agent "meta-képességének" nevezik. A kódvégrehajtás azonban biztonsági kockázatokat hordoz – az Agent által generált kód tartalmazhat sebezhetőségeket, végtelen ciklusba kerülhet, vagy kimerítheti az erőforrásokat. A sandboxolás enyhíthet bizonyos kockázatokat, de korlátozza is, hogy a kód mit tehet (pl. megtagadja a hálózati vagy fájlrendszer-hozzáférést). Hogyan találjuk meg az optimális egyensúlyt a biztonság és a képesség között?

Szintezett sandbox-izoláció forgatókönyv szerint (konténerek/mikro VM-ek); alapértelmezés szerint nincs hálózat, fehérlistás proxy biztosít hozzáférést igény szerint; a forráskód csak olvashatóként van mountolva, az API-kulcsok a sandboxon kívül maradnak; sandbox erőforrás-korlátok beállítása; sandbox életciklus-kezelés (időtúllépések).

2. (★★★) Agent bootstrap – egy Agent, amely Agenteket hoz létre – eléri az "intelligencia önreprodukcióját". De minden bootstrap iteráció új torzításokat vagy hibákat hozhat be. Felhalmozódnak ezek a hibák a generációkon keresztül? Hogyan akadályozhatjuk meg a bootstrapelt Agentek leépülését?

Ha minden generáció az előző generáció eredményeire építve reprodukálja magát, bizonyos hibák felhalmozódhatnak. A kulcs a kellően kihívást jelentő, ellenőrizhető feladatok – például kellően nehéz programozási feladatok.

**3. (★★) Amikor egy kódgeneráló Agent naplófeldolgozást végez, automatikusan követheti a formátum alakulását. De ha egy formátumváltozás hiba, nem pedig szándékos módosítás, az Agent alkalmazkodóképessége valójában elrejti a problémát. Hogyan különböztesse meg az Agent a "változtatásokat, amelyekhez alkalmazkodni kell" az "anomáliáktól, amelyeket jelenteni kell"?

Diagnosztizálj az alkalmazkodás előtt: ellenőrizd az új formátumot architektúra dokumentumok és a PRD (termékkövetelmény-dokumentum) alapján, hogy várható-e (az 5-8. kísérlet gondolata); ellenőrizd a verziókövetési rekordokat, hogy a változás egy legitim kódkommitnek felel-e meg, nem pedig forrás nélküli sodródásnak; a τ-bench log_mismatch-jéhez hasonlóan, még ha az alkalmazkodás mellett döntesz is, naplózz egy riasztást és automatikusan nyiss egy hibajegyet a csendes tolerálás helyett; bizonytalanság esetén irányíts emberi beavatkozáshoz. Az elv: alkalmazkodás és jelentés párhuzamosan – az alkalmazkodás nem nyelheti el az anomáliajeleket.

4. (★★) Ez a fejezet ismétlődően használja a Proposer-Reviewer mechanizmust PPT-generálásban, videószerkesztésben és napló-vizualizációban. Ha a Reviewer esztétikai preferenciái eltérnek a célfelhasználóétól – például a Reviewer ésszerűnek tartja az információ-sűrűséget, de a felhasználó túl zsúfoltnak találja –, a visszacsatolási hurok egy rossz lokális optimumba torkollhat. Hogyan építhető be a felhasználói preferencia-visszajelzés a Reviewer hurokba?

Injektáld a felhasználói visszajelzést az Agent trajektóriájába a legmagasabb prioritású strukturált eseményként; externalizáld és konszolidáld a felhasználói preferenciákat MEMORY.md-be írva, hogy a preferenciák feladatokon átívelően érvényesüljenek; szállítsd a dokumentumokat HTML formátumban Markdown helyett, hogy a felhasználók megtekinthessék azokat.

5. (★★) Ez a fejezet több módot mutat be, ahogyan egy Kódoló Agent a végrehajtás és hibakeresés során szerzett tapasztalatokat a kódbázisba konszolidálhatja – tudásbázis fájlok írása, architektúra dokumentáció frissítése, projekt utasításfájlok karbantartása és műveleti sorozatok kódba kódolása. Ha ezt a tapasztalatot tovább desztilláljuk szabályokká a rendszerpromptban, a szabálykészlet idővel folyamatosan terjeszkedik. Hogyan végezhető "szemétgyűjtés" a felhalmozott szabályokon az elavult vagy redundáns bejegyzések azonosítására és eltávolítására? Miért nem folyamatos evolúció a 8. fejezet értelmében egyetlen sikeres kódmódosítás?

Szemétgyűjtés megközelítése: a linterbe, CI-be vagy eszköz-ellenőrzésbe kódolható szabályok kiszervezése a promptból; a szabályok találati arányának és ütközéseinek nyomon követése és időszakos újraérvényesítése a kódbázis ellen; Markdown és Git használata az eredet, verziók és visszaállíthatóság megőrzéséhez. Egy sikeres javítás csak azt mutatja, hogy az aktuális esetet megoldotta. A folyamatos evolúció tovább megköveteli, hogy a módosítás nyomon követhető műveleti bizonyítékokból származzon, javítsa a későbbi feladatokat, és átmenjen regressziós teszteken a régi feladatokon, valamint biztonsági validáción.

6. (★) "A távmunkára nyitott csapatok gyakran nyitottak az AI Agentekre is." Mennyire áll közel a csapatod vagy szervezeted az "AI-készséghez" a tudásdokumentáció tekintetében? Mi a legnagyobb akadály?

Nyitott végű. Önellenőrizheted a fejezet proxy mérőszámával: tud-e egy távoli új belépő önállóan dolgozni, csak a repository-t és a dokumentációt használva? Ellenőrző lista: döntések dokumentálva vannak-e; a kontextus bekerül-e az issue-kba/PR-ekbe; a build és teszt parancsok rendelkeznek-e utasításfájlokkal, mint CLAUDE.md/AGENTS.md; a törzstudás le van-e desztillálva fejlesztői útmutatókba. A leggyakoribb legnagyobb akadály: szóbeli hagyományozás és whiteboard-kultúra, amely a "melletted ülő kolléga megkérdezésére" támaszkodik – egy Agent nem tud szóbeli megállapodásokat olvasni, csak dokumentumokat.

7. (★★★) Simon Willison a "Végzetes Triász" fogalmát vezette be Agentekre (hozzáférés privát adatokhoz, kitettség megbízhatatlan tartalomnak és külső kommunikációs képesség). Ez a fejezet hozzáad egy negyediket: a perzisztens memóriát. Egy éles környezetben, amelynek mind a négy elemet egyszerre kell kezelnie, hogyan terveznéd a biztonsági stratégiát?

Réteges védekezés négyféle határvonal mentén. Adathatár: nincsenek hitelesítő adatok mountolva, forráskód csak olvasható, minimális láthatóság. Bemeneti bizalmi határ: származás címkézése, a külső tartalom "tájékoztató jellegű, utasítási erővel nem bíró" adatra minősítése (a lojalitási magatartási kódex). Kimeneti hatáshatár: alapértelmezés szerint nincs hálózat fehérlistás kimenő forgalommal, parancsok szemantikai elemzése feketelisták helyett, független Sidecar felülvizsgálat plusz emberi beavatkozás – a kritikus műveleteket a kontextuson kívüli mechanizmusnak kell felülvizsgálnia. Munkamenetek közötti határ: a MEMORY.md-be írás ugyanazon bizalmi felülvizsgálaton megy keresztül, mint a külső tartalom. A cél: még ha injektálás történik is, a támadás ne legyen végrehajtható.

8. (★★) Az Artifact minta lehetővé teszi, hogy az Agent által generált SQL vagy frontend kód közvetlenül a felhasználó böngészőjében vagy adatbázisában fusson. A generált SQL azonban destruktív műveleteket hajthat végre, a generált HTML pedig sebezhetőségeket tartalmazhat. Hogyan biztosítható a rendszer biztonsága?

SQL: lekérdezések végrehajtása least-privilege csak olvasható fiókkal, valamint erőforrás-korlátok (CPU, memória stb.) hozzáadása az erőforrás-kimerítés megelőzésére. HTML/UI: előnyben részesíteni a deklaratív protokollokat, mint az A2UI, ahol az Agent csak interfészleíró JSON-t ad ki, és a kliens egy megbízható komponenskatalógusból rendereli anélkül, hogy tetszőleges kódot futtatna. Ha tetszőleges HTML szükséges, azt sandboxolt környezetben kell megjeleníteni az injekció megelőzésére.

9. (★★) Az üzleti szabályok kódba kódolása adatbázis-alapú igazság elleni ellenőrzésekként, miközben az eszközparamétereket úgy tervezzük, hogy a modellt a szabályzat feltételeinek ellenőrzésére ösztönözzék hívás előtt, a kódstruktúrát használja az Agent viselkedésének korlátozására. Milyen előnyei és korlátai vannak ennek a "kód mint szabályok" mintának a természetes nyelven kifejezett szabályokkal szemben?

Előnyök: egyértelmű, determinisztikus, és kiváló összetett feltételkombinációknál; a szabályzati tények az adatbázis valós állapotából és a szerveroldali órából származnak, nem a modell által bejelentett értékekből, így sem hallucináció, sem prompt-injekció nem kerülheti meg őket – a végső védelmi vonal visszafordíthatatlan műveletek ellen; az expected_* paraméterek kötelező ellenőrzőlistaként is szolgálnak, amely irányítja a gondolkodást. Korlátok: a kód nem magyarázza el a szabályzatokat a felhasználóknak, nem talál megkerülő megoldásokat, és karbantartási költségekkel jár. Következtetés: kiegészíti a természetes nyelvű szabályokat, nem helyettesíti azokat.

10. (★★) Az Artifact minta lehetővé teszi, hogy egy Agent SQL-t vagy vizualizációs kódot generáljon, amelyet a downstream komponensek közvetlenül végrehajtanak, így az LLM-nek nem kell nagy mennyiségű adatot feldolgoznia. Milyen előnyei és hátrányai vannak ennek az "Agent kódot generál, rendszer kódot hajt végre" munkamegosztásnak a hagyományos "Agent közvetlenül adja a választ" mintával szemben?

Előnyök: az adatok az adatbázisból egyenesen a frontendbe áramlanak, megkerülve az LLM "közvetítőt" – gyors, tokentakarékos, és mentes a nagy adatmennyiségek átírásakor fellépő hallucinációs hibáktól, így alkalmas nagy adatmennyiségek bemutatására; a kód naplózható, újrafelhasználható, és csővezetékekbe rendezhető (SQL-eredmények közvetlenül táplálhatók vizualizációs kódba). Hátrányok: az LLM soha nem látja a lekérdezési eredményeket, így nem tud további összegzést és döntéshozatalt végezni az adattartalom alapján – nem alkalmas olyan feladatokra, ahol a modellnek az adatok megemésztésére van szüksége az érvelés előtt.

6. fejezet: Agentek értékelése

1. (★★) Az LLM-as-a-Judge egy nyelvi modellt használ egy nyelvi modell kimenetének értékelésére. Van-e ennek az "önértékelésnek" szisztematikus vakfoltja – például a modell következetesen magas pontszámot adhat egy bizonyos válaszstílusra, ami eltér az emberi ítélettől? Hogyan lehet az ilyen torzításokat észlelni és korrigálni?

Igen: hosszúsági torzítás, válaszstílus-torzítás, és az azonos családba tartozó modellek kijátszása (Goodhart törvénye). Észlelés: építs egy 100–200 példából álló emberi aranystandard készletet, és mérd meg a Cohen-féle kappa együtthatót a bíró és az emberek között; időszakosan ellenőrizd a pontszámok és a válaszhossz közötti korrelációt; egy piros csapat (red team) készítsen adversarial eseteket. Korrekció: a rubrika explicit módon büntesse a bőbeszédűséget és korlátozza a hosszt; használj heterogén bírákat különböző modellcsaládokból.

2. (★★★) Az értékelési adathalmazok "szivárgásbiztos" tervezése kulcsfontosságú. A nyílt forráskódú ökoszisztémában azonban, amint a benchmark adatok nyilvánossá válnak, gyorsan bekerülnek a betanítási adatokba. Van-e végjátéka ennek a "macska-egér játéknak"? Tervezz egy olyan értékelési módszert, amely alapvetően ellenáll az adatszivárgásnak.

Egy statikus kérdésbanknak nincs végjátéka – csak üldözni lehet. Az alapvető kiút a "generálási mechanizmus" nyilvánossá tétele, miközben a "konkrét példányok" magánjellegűek maradnak: paraméterezett sablonok, mint a τ²-bench és AndroidWorld esetében, minden alkalommal véletlenszerűen példányosítva, a végső környezeti állapoton alapuló ellenőrzéssel, nem rögzített válaszsorozaton.

3. (★★) A Scale AI négy kritériuma (szakértői iránymutatás, átfogó lefedettség, szabványos fontossági súlyozás, önálló értékelés) a szubjektivitás kiküszöbölését célozza az értékelésben. Bizonyos feladatdimenziók (pl. "Hasznos a válasz?" "Megfelelő a hangnem?") azonban eredendően szubjektívek. Hogyan tervezhetők megbízható Rubrikák ezekhez a szubjektív dimenziókhoz?

Fordítsd le az absztrakt kritériumokat ellenőrizhető viselkedésekre. Adj minden fokozathoz konkrét példákat és határeseteket; a rubrika iteratív termék – gyűjtsd össze az értékelők közötti nézeteltéréseket a próbahasználat során, és fokozatosan fejleszd esetgyűjteménnyé. Egészítsd ki több értékelő súlyozásával/konzisztencia-ellenőrzésével, küldd a nézeteltéréses eseteket emberi felülvizsgálatra, és kalibráld az egyetértési arányt az aranystandard készleten.

4. (★★) A τ-bench az Agenteket valós felhasználói viselkedés szimulálásával értékeli. De a szimulált felhasználó maga is egy LLM – szisztematikusan alábecsülhet bizonyos határeseteit (pl. érzelmileg felkavart vagy homályos felhasználók). Hogyan validálható magának a szimulált felhasználónak a minősége?

A τ-bench első verziójának tanulsága: a szimulátor túl mechanikus volt, az utasításai túl egyszerűek (az Agent ki tudta találni a válaszokat). Validációs módszerek: szimulált dialógusok kézi ellenőrzése, hogy kövessék-e a progresszív információfeltárást, és ne gyártsanak információt a szkripten kívül; kis mintás tesztek futtatása valós felhasználókkal annak ellenőrzésére, hogy a rangsorolások megegyeznek-e a szimulált értékeléssel.

5. (★★) A páronkénti összehasonlítás (Bradley-Terry modell) feltételezi, hogy a preferenciák tranzitívak (ha A > B és B > C, akkor A > C). Az emberi preferenciák azonban gyakran sértik a tranzitivitást. Az Agent-értékelésben milyen forgatókönyvekben jelenhetnek meg nem-tranzitív preferenciák? Hogyan befolyásolja ez a rangsorolások megbízhatóságát?

Forgatókönyvek: többdimenziós kompromisszumok (A pontos de lassú, B gyors de szűkszavú, C alapos de drága), ahol a különböző értékelők/feladatok eltérően súlyozzák a dimenziókat. A Chatbot Arena rangsorolásai eredendően függenek a felhasználói promptok eloszlásától. Hatás: a BT egyetlen pontszámba sűríti az erősséget, így nem-tranzitivitás esetén a rangsorok instabillá válnak és a mérkőzéseloszlással sodródnak. Enyhítés: rangsorolás külön képességdimenziók szerint, és a páronkénti győzelmi arány mátrix jelentése.

6. (★★) Ez a fejezet a "Megfigyelés → Hipotézis → Kísérlet → Validálás" tudományos módszert javasolja. A gyakorlatban azonban az Agent viselkedési tere hatalmas, és egyetlen hipotézis validálásához több száz értékelési futtatásra lehet szükség. Hogyan maximalizálható az értékelésből nyert információ korlátozott számítási költségvetés mellett?

Előbb csoportosítsd a hibákat, hogy a leginformatívabb feladatokra szűkíts, majd futtass olcsó, egyváltozós páros pilotokat. A kis minta a nagyobb teszt kapuja, nem telepítési bizonyíték. Standard hibával végezz konzervatív szűrést, ugyanazon feladatokon használj McNemar-féle páros elemzést, és bővítsd a készletet, ha a várható különbség a zaj alatt van. Több párhuzamos jelöltnél korrigáld a többszörös összehasonlítást, és függetlenül erősítsd meg a pozitív eredményt.

7. (★) Az AndroidWorld-pilotban a teljes elemfa 25%-ról 100%-ra emelte a sikert, de a tokenhasználatot a kontroll 2.498-szorosára növelte; a metszés megtartotta a 100%-os sikert, miközben 0.506-szorosra csökkentette a tokenhasználatot. Hogyan terveznél automatikus metszési szabályokat, amelyek eltávolítják a szemantikailag üres UI-csomópontokat anélkül, hogy elveszne az akadálymentességhez, állapotellenőrzéshez vagy későbbi műveletekhez szükséges információ?

Kövesd az „alapból töröld, bizonyítékkal tartsd meg” elvet. Maradjanak a látható, szöveges, műveletképes, fókuszálható, görgethető, állapotot vagy értéket hordozó, illetve accessibility-címkével ellátott csomópontok, továbbá szükséges ősláncuk és kapcsolódó szomszédos címkéik. Töröld a puszta elrendezési konténereket, foglald össze az ismétlődő részfákat. Metszés előtt és után ellenőrizd az interaktív azonosítók, állapotok és értékek megőrzését; tartsd meg a képernyőképet vizuális tartaléknak. Játszd vissza a hibás trajectory-ket, majd tesztelj hangolásban nem használt alkalmazásokon. A siker, token és késleltetés közös guardrail; accessibility-regresszió blokkolja a kiadást.

8. (★★) A τ-bench felhasználói szimulációja "progresszív információfeltárást" alkalmaz – nem ad meg egyszerre minden információt, hanem fokozatosan tárja fel az Agent kérdései alapján. Hogyan befolyásolja ez a tervezés az értékelési eredményeket? Ha a szimulált felhasználó információfeltárási stratégiája jelentősen eltér a valós felhasználókétől, az értékelési következtetések még mindig megbízhatók?

Hatás: ha a feltárási stratégia torz, az Agent csak a "szimulátorhoz való illeszkedést" tanulhatja meg (Goodhart), és az abszolút pontszámok elveszítik referenciaértéküket; a modellek közötti relatív rangsorolás még mindig értelmes lehet. Orvoslás: a szimulátor kalibrálása valós dialógusokkal, kézi szúrópróbaszerű ellenőrzés, és a következtetések alkalmazhatósági határainak explicit megadása.

7. fejezet: Modell poszt-tréning

1. (★★) A katasztrofális felejtés – ahol egy specifikus feladatra való finomhangolás elpusztítja a modell eredeti általános képességeit (pl. általános eszközhívás) – különösen problémás Agent-forgatókönyvekben. A teljes paraméteres finomhangoláshoz képest a LoRA befagyasztja az alapsúlyokat, így kisebb a felejtés kockázata, de nem immunis rá. Milyen stratégiák enyhíthetik tovább a képességfelejtést a finomhangolás során?

Adatkeverés: körülbelül 20% általános/eredeti eloszlású adat bekeverése, hogy az új feladat aránya ne törje össze a régi képességeket; visszafogott betanítási mennyiség: SFT leállítása, amint "a formátum stabil és az alapképességek jelen vannak" – korai leállítás megakadályozza az összeomlást; kis rang (8–32) használata RL-hez és a KL-büntetés megtartása a politika referencia modell közelében tartásához; kulcskomponensek befagyasztása (pl. csak a VLM vetítőrétegének tanítása); több LoRA adapter csatolása feladatonként a képességek izolálásához; regressziós tesztek futtatása általános benchmarkokon.

2. (★★) A poszt-tréning a képességeket modellsúlyokba szilárdítja ("izommemória"), míg a kontextusban való tanulás (in-context learning) a tudást a bemenetbe helyezi az inferencia során. Egyes képességek (pl. domén tudás) azonban megtanulhatók poszt-tréninggel vagy megadhatók few-shot példákon keresztül is. Milyen kritériumok alapján döntenéd el, hogy egy adott képesség melyik utat járja?

Először kérdezd meg, hogy a képesség megfelelően kifejezhető-e külső szimbólumokkal: tények és bizonyítékok a RAG-ba, nyelvileg kifejezhető elvek a Promptokba/Skills-ekbe, determinisztikus eljárások és kemény korlátok a programokba tartoznak. Magas dimenziójú képességek, mint az orvosi képértelmezés, természetes hangnem és implicit szabályzatok, gyakran paraméterfrissítést igényelnek még akkor is, ha a domain még változik. Ezután vedd figyelembe a frissítési költséget, a hívási gyakoriságot, az időszerűséget és a kockázatot: használj kontextust gyors validáláshoz a feltárás során, és csak akkor taníts, ha egy megközelítés stabilnak, hatékonynak és széles körű általánosítást igénylőnek bizonyult. A kemény szabályok, bármennyire stabilak is, soha nem támaszkodhatnak kizárólag paraméteres memóriára.

3. (★★) A modell-desztilláció lehetővé teszi, hogy egy kis modell megtanulja egy nagy modell viselkedését. Képességszint szerint a desztillálandó modellek nagyjából három szintre oszthatók – Chat modellek (egyfordulós dialógus, közvetlen válaszok), "Reasoning modellek (hosszú gondolkodási láncok generálása válaszadás előtt) és Agentic modellek (többfordulós eszközhívások, interakció a környezettel). Milyen eltérő kihívásokat jelent e három modelltípus desztillációja? (Tipp: Kezdd azzal, hogy "mit desztillálunk pontosan" – a kimenet stílusát, a teljes gondolkodási trajektóriát vagy a környezettel való interakció döntési stratégiáját; a trajektória mely tokenjeit kell megtanulni, és melyek olyan környezeti visszatérések, amelyeket nem szabad megtanulni; valamint milyen későn és milyen ritkán érkeznek a siker/kudarc jelek.)**

Chat: csak a "bemenet → kimenet" leképezést és stílust tanulja – standard SFT elegendő, a legegyszerűbb. Reasoning: teljes gondolkodási trajektóriákat igényel, ezért nyílt forráskódú tanító modellre van szükség; a hibás válaszokat tartalmazó trajektóriákat ki kell szűrni. Agentic: valós szimulációs környezetet igényel; az offline tanulás hajlamos a tanuló-mintavevő eltérésre (learner-sampler mismatch), ezért nyílt forráskódú tanító modellen alapuló On-Policy Distillation ajánlott.

4. (★★★) A többfordulós Agent-interakciókban a hitelkiosztási probléma súlyosabb, mint az egyfordulós forgatókönyvekben – egy végső sikert vagy kudarcot nehéz a 3. fordulóban hozott döntésnek vagy a 7. forduló döntésének tulajdonítani. Hogyan terveznéd a jutalom elosztási stratégiát?

Amikor a köztes lépések megítélhetők, adj hozzá folyamat-jutalmakat (V-IRL ±1-et ad lépésenként); az RLVP-t követve használj determinisztikus szabályokat az akciónkénti útvonaljelekhez, visszaállítva a csoporton belüli varianciát a minden-hiba/minden-siker csoportokban.

5. (★★★) Ha lenne egy fix költségvetésed, mondjuk 10 000 dollár, egy ügyfélszolgálati Agent fejlesztésére, hogyan osztanád el a kontextus és tudás, Prompt/Skills, programozási korlátok és paramétertréning között? Milyen tényezők határoznák meg a döntésedet?

Először különíts el költségvetést egy értékelési készletre és trajektória-validátorokra; különben a fennmaradó beruházások nem hasonlíthatók össze. Helyezd a termék tényeit és szabályzatait egy nyomonkövethető tudásbázisba. Tesztelj gyorsan egy kis számú, nyelvileg kifejezhető szolgáltatási elvet Promptokon/Skills-eken keresztül. Használj programokat a visszatérítési engedélyek, adatvédelem és az ígéretek és cselekvések közötti konzisztencia biztonsági hálójaként. Fektess be paramétertréningbe csak azon képességek esetében, amelyeket nehéz szabályokba kódolni, és amelyeket kellő léptékben gyakorolnak, mint a természetes hangnem és az összetett szándékfelismerés. A pontos arányok a szűk keresztmetszettől, kockázattól, frissítési gyakoriságtól, hívási mennyiségtől és a meglévő modell képességétől függenek.

6. (★★★) Az autonóm modelltudás, egyértelmű jutalomfüggvény és bőséges minták nélkül, egyesek szerint a poszt-tréning végső célja. Mennyire vannak a jelenlegi RL-betanítási módszerek ettől a céltól? Hol várható a következő áttörés?

A szakadék: ahogy Silver és Sutton rámutat, a jelenlegi RL csak a végső sikerből vagy kudarcból tud tanulni; a gazdag visszajelzés, mint amikor az ügyfél azt mondja: "a kártyája utolsó négy számjegyére van szükségem", teljesen elveszik, több száz vak próbát igényelve; a minta-hatékonyság és az ellenőrizhető jutalmak a fő szűk keresztmetszetek. Lehetséges áttörések: generatív jutalommodellek, amelyek saját elveket állítanak fel és egy irányt tanulnak egyetlen kudarcból; valamint a világmodell útvonala, a környezet modellezése.

**7. (★★) Ez a fejezet rámutat, hogy a LoRA finomhangolás költsége nem magas. Tehát lehetséges-e egy dedikált LoRA-t tanítani minden felhasználónak (vagy minden ügyfélcégnek), a felhasználói memóriát vagy vállalati tudást a paraméterekbe írva, ahelyett, hogy azt egy külső tudásbázisban tárolnánk, mint a 3. fejezetben? Milyen forgatókönyvekben lenne a "memória paraméterekbe írása" előnyösebb a "memória tudásbázisban tárolásánál"? És milyen forgatókönyvekben lenne kontraproduktív?

A LoRA nehezen képes pontosan megjegyezni nagy mennyiségű tényt (ehhez folytatott elő-tréning kellene, drasztikusan megnövekedett költséggel), és még ha meg is jegyzi őket, a modell alig tudja ezeket a tényeket többugrásos érveléshez használni – ezért a LoRA használata tények memorizálására nem jó technikai út. Ráadásul, ha a tények gyakran változnak, vagy nyomonkövethető auditálás szükséges, a RAG jobb.

**8. (★★★) Az On-Policy Distillation egy erősebb tanító modellre támaszkodik a tanuló felügyeletéhez. Az OpenAI Weak-to-Strong Generalization kutatása azonban egy ellentmondásos megállapítást javasolt: a gyenge modell felügyeleti jele néha feloldhat rejtett, de nem aktivált képességeket egy erős modellben. Ha ezt az ötletet alkalmazzuk Agent-tréningre, elérhető-e a "kis modell tanít nagy modellt" fordított desztilláció?

Igen, lehetséges – a kulcs az, hogy "az ellenőrzés könnyebb, mint a generálás": a gyenge modell ne demonstrátorként működjön (az SFT plafonja a demonstrátor szintje), hanem ellenőrző/jutalom modellként, ahol az erős modell maga fedez fel, a gyenge modell csak ítél.

**9. (★★) A Folyamat Jutalom Modell (PRM) minden egyes érvelési lépést értékel, míg egy Eredmény Jutalom Modell (ORM) csak a végeredményt nézi. De melyik érdemel nagyobb jutalmat: "a helyes folyamat, amely rossz eredményhez vezet" vagy "a rossz folyamat, amely szerencsésen helyes eredményhez vezet"? Az Agent több lépésből álló eszközhívási forgatókönyvében hogyan súlyoznád ezeket?

A szerencsés siker veszélyesebb: a szabályokat sértő parancsikonok gyakran felfújják a látszólagos sikerességi arányt (tesztfájlok módosítása, validáció kihagyása) és a jutalomhekkelés melegágyai. Kövesd az RLVP "jutalmazd az eredményeket, büntesd az útvonalakat" elvét: a rossz cselekvések (eszközhívások) könnyen ellenőrizhetők – pontlevonás akciónként; amikor a köztes lépések könnyen megítélhetők, folyamat-jutalmak adhatók. De ne tedd túl sűrűvé a folyamatkorlátokat – a kiváló "push-cut" stílusú stratégiát éppen az eredmény-jutalmak által biztosított felfedezési szabadság tette lehetővé.

**10. (★★★) Az ebben a fejezetben tárgyalt értékelési adathalmazok (pl. SWE-Bench Verified, τ²-bench, AndroidWorld) használhatók mind értékelésre, mind poszt-tréningre. Ha azonban egy értékelési készletet a tréninghez használunk, az már nem független értékelési készlet – ez nem sérti a betanítási és tesztkészletek szétválasztásának alapelvét? A τ²-bench dinamikus paramétergenerálása és az AndroidWorld paraméterezett sablonjai bizonyos mértékig enyhítik ezt a problémát, de a sablonstruktúra maga rögzített marad. Hogyan találhatunk egyensúlyt az értékelési adatok tréningbeli értékének teljes kihasználása és az értékelési függetlenség fenntartása között?

Használd újra a környezeteket, ne a kérdéseket. A dinamikus paraméterek csak a "válaszmemorizálást" akadályozzák meg, nem a sablon-túligazodást, ezért tarts félre teljes kötegeket nem látott sablonokból/doménen kívüli forgatókönyvekből az értékeléshez (analóg a V-IRL tréninggel New Yorkban és teszteléssel kilenc ismeretlen városban). Használj paraméterezett sablonokat kötegelt tréningváltozatok generálásához, amelyek támogatják a curriculum tanulást, és az OOD pontszámokat vedd az igazi általánosítási mérőszámnak.

11. (★★★) Ez a fejezet egy "forma előbb, tartalom aztán" betanítási paradigmát javasol: állítsd le az SFT-t, amint "a formátum stabil és az alapképességek jelen vannak", majd válts RL-re. A gyakorlatban azonban hogyan határozható meg, hogy az SFT "elég" volt, és itt az ideje váltani?

Formátum jel: az eszközhívási kimenetek stabilan értelmezhetők és végrehajthatók, és az eszközvégrehajtás hibaránya olyan szintre csökken, ahol a jutalmak megbízhatóan számíthatók. Haszon jel: további demonstrációs adatok hozzáadása már nem javítja a teljesítményt az OOD új forgatókönyvekben – ami azt jelenti, hogy a szűk keresztmetszet már az SFT memorizációs célfüggvényében van, és a fordulópontot elértük. Túligazodási jel: állj le, amint a validációs készlet teljesítménye romlani kezd – a V-IRL kísérlet azt mutatja, hogy ha az SFT túltanítás összeomlasztja a modellt a betanítási eloszlásra, az RL sem tudja visszaállítani az OOD teljesítményt.

**12. (★★★) A ReTool tréning dinamikája azt mutatja (lásd 7-15. kísérlet), hogy egy kis számú nagyon hosszú válasz jelentősen meghosszabbíthatja a teljes betanítási ciklust – a kötegben lévő rollout-ok többsége már generálódott, de várni kell arra a néhány leghosszabb válasz befejezésére, ami alatt a GPU kihasználtság a klaszterben nagyon alacsony. Hogyan javítható az erőforrás-kihasználtság a betanítási klaszterekben ilyen hosszú farok válaszok esetén?

Infrastruktúra rétegben: válaszd le a rolloute-ot a tréning klaszterről és csővezetékesít aszinkron módon; töltsd ki az üresjáró GPU-kat új kérésekkel folyamatos kötegeléssel (continuous batching). Tömörítsd a hosszú farkot a forrásnál: a DAPO Overlong Reward Shaping lágy büntetést ad a túl hosszú válaszokra.

**13. (★★★) Amikor egy Agentet LLM-szimulált környezetekkel szemben tanítunk (mint egy szimulált keresőmotor vagy szimulált felhasználók), az Agent kihasználásának célpontja a "valós környezet szabályairól" a "szimulátor torzításaira és kiskapuira" tolódik el. Milyen konkrét jutalomhekkelési viselkedések jelenhetnek meg az ilyen tréning során, és hogyan akadályozhatók meg?

Tipikus viselkedések: túlzott ígéretek a "szimulált felhasználóknak" és a bocsánatkérések és hízelgő megfogalmazások halmozása – a szimulált felhasználók könnyen lecsillapíthatók, és a valódi felhasználókkal ellentétben soha nem kérik számon az Agenten, hogy az ígéreteit ténylegesen betartotta-e; tények kitalálása, amelyeket a szimulátor nem fog ellenőrizni; vezető lekérdezések megfogalmazása egy "szimulált keresőmotor" ellen, kihasználva annak hajlamát, hogy választ tartalmazó dokumentumokat adjon vissza, parancsikonként a valódi lekérés megtanulása helyett; amikor a jutalom a szimulátor vagy LLM-bíró pontszámaiból származik, bőbeszédű, sablonos, "profinak tűnő" válaszok gyártása pontgyűjtés céljából; és egy finomabb: a politika visszahúzódik a szimulátor számára ismerős eloszlásba, és kerüli a tudásbeli vakfoltjait, ahol a visszajelzés megbízhatatlan és gyakran félreértékelt, így az Agent megtanul csak "abban a világban cselekedni, amiben a szimulátor jó". A védekezés első elve a jutalom lehorgonyzása programozottan ellenőrizhető valós állapothoz (feladat teljesítése, adatbázis-írások, valós API-visszatérések), a szimulátor vagy LLM-bíró pontszámainak csak kiegészítő jelzésként való kezelése, a valós kimenetekkel való korreláció időszakos auditálása, és ennek párosítása olyan útvonalkorlátokkal, amelyek büntetik a gyanús cselekvéseket. Továbbá különböztess meg kétféle szimulátort: azoknál, "amelyeknek van valós megfelelőjük", mint a keresés, válaszd a "hibrid" utat – a legtöbb interakció a szimulátoron keresztül történik, valós API-hívásokkal vegyítve, és a valós hívások a szimulátor időszakos kalibrálására szolgálnak (pl. ZeroSearch curriculumszerű minőségi romlása). De a szimulált felhasználók esetében valós felhasználók nem hozhatók be a tréningbe, így "mennyire hű a szimulált felhasználó a valóshoz" külön problémává válik, amely csak online nyomokkal válaszolható meg: hasonlítsd össze a valós felhasználók viselkedését éles nyomokban a szimulált felhasználó viselkedésével ugyanazokban a helyzetekben, azonosítsd a szisztematikus különbségeket (a valós felhasználók kérdeznek, türelmetlenné válnak és hirtelen befejezik a beszélgetéseket – a szimulált felhasználók gyakran nem), és ennek megfelelően kalibráld folyamatosan a szimulátort; az online valós mérőszámok az egyetlen kiadási kapu is – a szimulátoron belüli pontszám nem számít.

8. fejezet: Folyamatos Agent-evolúció

1. (★★) Egy tapasztalati dokumentumot három sikeres és egy sikertelen trajektória támaszt alá. A hiba egy újabb API-verzión történt. Hogyan határozza meg a rendszer, hogy a tapasztalat megcáfolódott-e, vagy az alkalmazhatósági feltételei változtak-e meg?

Először rétegezd a négy bizonyítékot API-verzió, feladatkörülmények és környezeti állapot szerint, nem darabszám alapján szavazva. Ha a régi politika csak a régi verzión sikeres, és az új verzión következetesen kudarcot vall, szűkítsd a tapasztalat alkalmazhatósági körét, és generálj egy jelöltet az új verzióhoz. Ha ugyanazon verzió és előfeltételek mellett is kudarcot vall, csökkentsd a megbízhatóságát vagy vond vissza.

2. (★★) Egy ügyfélszolgálati Agent felhasználói elégedettsége nő, de a szabálysértési aránya is nő. Miért nem szolgálhat a elégedettség egyedüli tanulási jelként? Hogyan terveznéd a korlát-mérőszámokat?

Az elégedettség jutalmazhat jogosulatlan visszatérítéseket, információszivárgást vagy túlzott ígéreteket, ezért csak minőségi mérőszám lehet, és nem írhatja felül a biztonsági alapvonalakat. A korlátoknak legalább a szabálysértéseket, adatvédelmi szivárgásokat, megalapozatlan állításokat, ígéret-cselekvés következetlenséget és jogosulatlan műveleteket le kell fedniük. Ezeknek a mérőszámoknak kemény küszöbértékekkel kell rendelkezniük, amelyeket nem lehet átlagpontszámmal semlegesíteni. A megoldási arányt, a megfelelő megkerülő megoldásokat, a tömörséget és az elégedettséget csak a megfelelő jelöltek között szabad összehasonlítani.

**3. (★★★) Ugyanaz a "hamis ígéret" probléma enyhíthető Prompton, Harness-ellenőrzésen vagy paramétertréningen keresztül. Milyen bizonyítékok alapján választanád ki a frissítés helyét?

Kezdd a kiváltó ok lokalizálásával. Ha a modell tudja, hogy egy eszköz nem hajtott végre, de mégis befejezett nyelvezetet használ, egy minimális Prompt szabály korrigálhatja. Ha az ígéret determinisztikusan összehasonlítható a válasz szövegével és az eszköz állapotával, egy Harness-ellenőrzés megbízhatóbb, és a végső védelmi vonalnak kell maradnia magas kockázatú forgatókönyvekben. Ha a probléma sokféle kifejezési formát ölel át, és széles körű nyelv-cselekvés összehangolási képességet tükröz, fontold meg a paramétertréninget. Részesítsd előnyben a legkisebb módosítást, amely a legkönnyebben validálható és visszaállítható, és hasonlítsd össze mind egy sikertelen készleten, mind egy megtartott régi feladatokból álló halmazon.

**4. (★★★) Egy Agent módosíthatja az eszközöket és validátorokat, de nem módosíthatja a saját frissítéseit jóváhagyó biztonsági mechanizmusokat. Hogyan osztanád meg az engedélyeket és a kódhatárokat e két rész között?

Helyezd az evolválható kódot egy alacsony jogosultságú sandboxba, amely csak patcheket és teszteket generálhat. Az engedélyrendszer, API-kulcsok, release-vezérlő konfiguráció és frissítési validátorok biztonsági mechanizmusok; a sandboxban lévő Agentnek nincs olvasási vagy írási hozzáférése ezekhez. Az Agent által generált kódváltoztatásokat a biztonsági mechanizmusoknak izolált környezetben kell reprodukálniuk és regressziósan tesztelniük a kiadás előtt.

**5. (★★) Ahogy a tapasztalati tudásbázis nő, a lekérési hibák és a tudásbeli ütközések semlegesíthetik a tanulás előnyeit. Hogyan terveznéd a verziózás, frissesség és visszavonási mechanizmusokat?

Minden tapasztalatnak meg kell őriznie a forrástrajektóriákat, alkalmazhatósági feltételeket, környezeti verziót, validálási időt és megbízhatóságot. Az ütköző bejegyzések ne írják felül egymást csendesen; feltétel szerint ágazzanak el, vagy legyenek megjelölve. Időszakosan futtass "alvó tanulást" a duplikált bejegyzések összevonására.

**6. (★★★) A paramétertanulás kiváló a természetes nyelvű stílusban, de nem tudja garantálni a kemény üzleti szabályokat. Tervezz egy folyamatos evolúciós sémát orvosi ügyfélszolgálatra, amely összehangolja a paramétereket, a tudást, a Skills-eket és a kódkorlátokat.

A paraméterek (poszt-tréninggel ellátott modell) kezelik az orvosi nyelv megértését, a természetes és empatikus kifejezést, valamint az összetett szándékfelismerést. A tudásbázis tárolja a legfrissebb irányelveket, gyógyszerinformációkat és intézményi szabályzatokat, a válaszoktól forrásmegjelölést követelve. Egy Skill írja le a konzultációs információk gyűjtésének, a kockázati rétegzésnek, az emberhez való eszkalációnak és a nyomon követésnek a munkafolyamatát. A szerveroldali kód kényszeríti ki a személyazonosság-ellenőrzést, az adatvédelem minimalizálását, az ellenjavallatok ellenőrzését, a vészhelyzeti kockázati eszkalációt és az engedélyhatárokat. Az éles trajektóriákat először orvosi biztonságra, ténybeli megbízhatóságra, ígéret-cselekvés konzisztenciára és kifejezés minőségére értékelik, majd négy osztályba sorolt frissítési jelölteket generálnak belőlük. Bármely paraméter- vagy munkafolyamat-változtatásnak át kell mennie egy megtartott orvosi-biztonsági készleten és emberi felülvizsgálaton a canary kiadás előtt.

9. fejezet: Multimodális és valós idejű interakció

**1. (★★) A hangügynökök végponttól-végpontig modellje egyesíti az ASR-LLM-TTS-t egyetlen modellbe, csökkentve a késleltetést, de elveszítve a modularitást. Ha a végponttól-végpontig modell hibázik egy adott szakaszban (pl. beszédfelismerés), a hibakeresés és javítás sokkal nehezebb, mint egy soros csővezetékben. Hogyan terveznéd egy végponttól-végpontig hangügynök megfigyelhetőségi rendszerét?

A modell adjon ki olvasható köztes reprezentációkat a kimenete mellett, mint a Moshi "belső monológ" szövegfolyama és akusztikus eseményjelzői (<emotion>, <noise>). Használj "ön-kaszkádolást" a hibaréteg lokalizálásához: ugyanaz a modell először átír, majd gondolkodik, és az összehasonlítás a végponttól-végpontig eredménnyel megmutatja, hogy a hiba az észlelésben vagy a gondolkodásban van-e. Offline futtass tételes regressziós teszteket olyan dimenziók mentén, mint a paralingvisztikai megértés és a beszédátvételi ítélet.

**2. (★) A Step-Audio R1 az MPS duális agy architektúrán keresztül éri el a "beszéd közbeni gondolkodást". Az emberek azonban "beszéd közbeni gondolkodás" során gyakran mondanak ki nem átgondolt szavakat, önjavítanak vagy használnak töltelékszavakat. Utánozzon-e egy Agent "beszéd közbeni gondolkodása" ezeket az emberi jellemzőket?

Utánozza azokat a "tökéletlenségeket", amelyek jelzésértékkel bírnak: a szünetek és töltelékszavak externalizálják a gondolkodást és elfedhetik a késleltetést, az LLM dönti el, hová illessze be őket. Ne utánozza a bizalomromboló önjavítást: a gyors-lassú ellentmondás az 1. megoldásban ("vegyem meg vagy ne?!") összeroppantja a bizalmat. Az MPS kísérletek azt mutatják, hogy a CoT eleje többnyire a kérdés újrafogalmazása; a korai nyitás megalapozással biztonságos, nincs szükség félrebeszélésre, majd javításra.

**3. (★★) A SoM (Set-of-Mark) és strukturált változatai (DOM elem indexelés) a Computer Use vizuális lokalizációját nyílt végű koordináta-előrejelzésről zárt halmazú ID-kiválasztásra váltják, de mindegyikhez szükség van a UI elemek előzetes detektálására és annotálására – akár egy szegmentációs modellen, akár a DOM-on keresztül. Ha a felület nem szabványos vezérlőket vagy dinamikusan változó elemeket tartalmaz, az annotációk hiányosak vagy pontatlanok lehetnek. Ilyen esetben vissza kell térni a koordináta-előrejelzéshez?

A koordináta-előrejelzést tartsd meg tartalékként: ez az egyetlen út, amely nem függ annotációtól, és alkalmazható nem szabványos vezérlőkre és dinamikus elemekre. Gyakorlatiasabb a hibrid cselekvési tér, ahol az annotálható elemek még mindig ID-kiválasztást használnak. A koordináta-előrejelzésnek felbontás-egyezést és arányos skálázást kell végeznie, különben szisztematikus eltolódások lépnek fel.

4. (★★) Az olyan ezerdolláros robotplatformok, mint az XLeRobot, olcsóvá teszik a teleoperációs adatgyűjtést. A teleoperációs adatok minősége azonban erősen függ a kezelő készségétől. Hogyan befolyásolná a képzetlen kezelőtől származó alacsony minőségű adat egy VLA modell betanítását? Hogyan szűrhető ki az alacsony minőségű adat automatikusan az adatgyűjtési fázisban?

A VLA főként utánzásos tanulásra támaszkodik, így az alacsony minőségű demonstrációk megtanítják neki a remegést, kerülőutakat, tétovázást és sikertelen mozdulatokat, mintha helyes stratégia lennének. Ez visszhangozza a 7. fejezet megállapítását: az adat fontosabb, mint az architektúra.

**5. (★★★) Ez a fejezet három interakciós modalitást fed le: hang, Computer Use és robotika. Egy közös trend ezeken a modalitásokon keresztül a soros csővezetékektől a végponttól-végpontig modellek felé való elmozdulás. Ha ez a trend folytatódik, hogyan nézhet ki az Agent interakciós rétege öt év múlva?

Ahogy a Thinking Machines Lab érvel, az interaktivitás a modellbe lesz építve, nem kiegészítő hámként (harness) hozzáadva, együtt skálázódva az intelligenciával. A Computer Use a képkockánkénti képernyőképektől a folyamatos megfigyelés felé mozdul el. A megtestesült intelligenciához tartozó világmodellek átfogóan megvalósulnak, de a gyors-lassú szétválasztás nem tűnik el, mert a határvonali érvelő modellek gyorsan fejlődnek; az az architektúra, amelyben egy interakciós modell és egy SOTA gondolkodó modell gyors és lassú gondolkodóként együttműködik, hosszú távú architektúrává válhat.

**6. (★★★) A jelenlegi Computer Use diszkrét "képernyőkép → akció → képernyőkép" hurokban működik, ahol minden megfigyelés egy statikus képkocka. De az emberi képernyő-észlelés folyamatos – látjuk az animációk lejátszását, megfigyeljük a betöltési folyamatokat és értjük a videó tartalmát. Ez azt jelenti, hogy a mai Computer Use nem képes kezelni az időbeli vizuális megértést igénylő feladatokat. Hogyan terveznéd újra az észlelési réteget a folyamatos vizuális folyam megértésének támogatására?

Az "észlelési interfészt" újra kell tervezni, hogy a videó tartalmából kulcsképkockák kerüljenek kinyerésre és átadásra a modellnek, ahelyett, hogy csak a végső képkockát biztosítanánk. Lásd az AOI (Agent Observation Interface) tanulmányt.

**7. (★★) A DOM/Accessibility Tree elem indexelés jól működik a szabványos webalkalmazásokon, de egyre több szoftverfelület (Canvas/WebGL renderelés, keresztplatformos egyedi rajzolt vezérlők) nem biztosít hozzáférhető strukturált információt, kizárólag vizuális annotációra vagy koordináta-előrejelzésre támaszkodva. Szerinted a Computer Use-nak tisztán vizuális megközelítésre kellene fogadnia, vagy mind a strukturált, mind a vizuális utat fenn kell tartani? Milyen költségei és hasznai vannak mindkét út fenntartásának?

Rövid távon mindkét út együtt él: amikor a strukturált indexelés elérhető, a lokalizáció a legpontosabb és legstabilabb, mentes a szegmentációs téves detektálásoktól; tiszta vizuális az egyetlen lehetőség natív szoftverekhez, Canvas-hoz és játékokhoz. Amikor a modell maga erős grounding képességgel rendelkezik (megadott koordinátákra kattintás), a strukturált indexelés nem nyújt jelentős előnyt. Hosszú távon a tisztán vizuális útnak magasabb a plafonja.

**8. (★★) A VLA modellek akció-chunking-ot használnak – a szövegben említettek szerint a π₀ tipikus konfigurációja 25-50 jövőbeli akciót generál 50 Hz-en – az inferencia késleltetésének elrejtésére a végrehajtási időben. Ha azonban a környezet hirtelen megváltozik a végrehajtás alatt (pl. egy tárgy elmozdul), az előre generált akciósorozat érvénytelenné válik. Hogyan egyensúlyozható ki az akció-chunking hatékonysági előnye a környezeti változásokra való reagálás képességével?

A chunking lényegében a reaktivitást áldozza fel a simaságért – minél hosszabb a chunk, annál tompább a válasz. A chunk hosszának csak azt az alsó korlátot kell kielégítenie, hogy "inferencia idő < chunk végrehajtási idő"; ne növeld vakon. Tartsd az észlelési modellt futásban a végrehajtás alatt, és amikor az hirtelen környezeti változást érzékel, dobd el a fennmaradó akciókat és számoltass újra – ez a "barge-in" megfelelője a hang forgatókönyvben. A chunk hossz dinamikusan állítható: a hosszú chunkok számítási időt takarítanak meg statikus jelenetekben, míg a rövid chunkok megőrzik a válaszkésleltetést dinamikus jelenetekben.

**9. (★★★) Mindhárom forgatókönyv ebben a fejezetben (hang, Computer Use, robotika) szembesül az "észlelés-gondolkodás-cselekvés" hurok késleltetési problémájával, és a gyors és lassú gondolkodás párhuzamosítása felé fejlődik. Hangban ez "beszédhiba utáni javításként", Computer Use-ban "előbb kattintás, aztán nézés", robotikában "egy lépés, aztán nézés" formában nyilvánul meg. Hogyan biztosítható, hogy a gyors gondolkodáson alapuló cselekvések ne vezessenek visszafordíthatatlan következményekhez?

Osztályozd a cselekvéseket visszafordíthatóság szerint. A gyors gondolkodás csak visszafordítható cselekvéseket hajthat végre; a visszafordíthatatlan műveletekhez a lassú gondolkodás jóváhagyása szükséges. A gyors modell soha nem végezhet olyan eszközhívásokat, amelyek visszafordíthatatlan következményekkel járnak.

10. fejezet: Többágens együttműködés

**1. (★★) Többágens együttműködésben megosztott kontextussal a későbbi Agentek öröklik az előző Agentek teljes kontextusát. Az előző Agent által felhalmozott "gondolkodási tehetetlenség" azonban befolyásolhatja a későbbi Agentek ítéletét – például egy "Kódellenőrző" Agent, amely örökli egy "Követelményelemző" Agent kontextusát, hajlamos lehet továbbra is a követelmények szemszögéből gondolkodni a kódminőség helyett. Hogyan lehet ezt a szerepek közötti interferenciát észlelni és kiküszöbölni?

Észlelés: használj egy LLM-et az Agent trajektória elemzésére, hogy meghatározd, az új szerep továbbra is úgy viselkedik-e, mintha a régi szerepben lenne. Kiküszöbölés: szakaszváltáskor cseréld ki a rendszerpromptot és az eszközkészletet is (távolítsd el a kérdező eszközöket, hozd be a linter/tesztelő eszközöket) az új identitás megerősítésére. Használj a kontextus végére fűzött rendszer állapotsávot az aktuális szerep információjának megerősítésére. Ha a szerepinterferencia továbbra sem szüntethető meg, fontold meg a kontextus megosztása nélküli együttműködési módszert.

2. (★★) A menedzser mintában a Menedzser Agent felelős a feladatbontásért és az eredmények integrálásáért. De a Menedzser saját képességplafonja meghatározza a teljes rendszer képességplafonját – ha a Menedzser nem tudja helyesen lebontani a feladatot, a legerősebb alügynökök is haszontalanok. Hogyan biztosítható a Menedzser bontásának minősége?

Követve a Plan-and-Act azon következtetését, hogy "a gyenge tervező a rendszer szűk keresztmetszete", rendeld a legerősebb modellt a Menedzserhez. Harness intézkedések: egy felülvizsgáló LLM kereszt-validálja a bontási kimeneteket a végrehajtás előtt; követeld meg a Menedzsertől, hogy az egyes részfeladatokhoz egyértelmű elfogadási kritériumokat és függőségeket határozzon meg a feladat bontásakor.

**3. (★★) A decentralizált minta az emberi szervezetek bevált gyakorlataiból merít. Az emberi szervezeteknek azonban számos hibamódja is van – rossz kommunikáció, felelősséghárítás, céllkonfliktusok. Szerinted milyen "szervezeti kórképek" jelennek meg legvalószínűbben egy Ágens társadalomban? Hogyan előzhetők meg?

A MAST három kategóriája ellen: tisztázatlan interfészek és átfedő felelősségi körök; következetlen célértelmezés és félreértett információ a downstream-ben; hamis "kész" bejelentés. Továbbá: kaszkádoló hibafelerősítés (telefonjáték), ciklikus feladatátadások szerepek között, és Ágensek közötti csoportos beszélgetések, amelyek eltérnek anélkül, hogy konvergálnának. Megelőzés: szerződéses interfészek és egységes üzenetboríték, feladat állapotgépek elfogadás-ellenőrzéssel, független perspektívájú kereszt-validálás, és a felelősséghárítás detektálása a szerepek között.

**4. (★★★) A menedzser mintában, amikor több alügynök párhuzamosan hajt végre feladatokat, az egyik alügynök felfedezése értelmetlenné teheti a többi alügynök munkáját (pl. keresési feladatban az egyik Agent már megtalálta a választ). Tervezz egy hatékony kaszkádolt leállítási mechanizmust az "egy siker, mindenki állj" elv megvalósítására.

Egy alügynök elküldi a target_found üzenetet a Menedzsernek, aki aztán broadcast-ben terminate jelet küld. Minden alügynök időszakosan ellenőrzi a leállítási jelet a ReAct hurok biztonságos pontjain, és a kecses tisztítás után (böngésző munkamenetek bezárása, zárolások feloldása, fájlírások befejezése) kilép.

**5. (★★★) Az ebben a fejezetben bevezetett optimista zárolási mechanizmus feloldja az egyidejű írási ütközéseket egyetlen fájl esetén. Egy valós többágens rendszerben azonban a megosztott fájlrendszerek olyan problémákkal is szembesülnek, mint a fájlok közötti szemantikai ütközések, névtér-szennyezés (az Agentek tetszőlegesen hoznak létre fájlokat, ami könyvtárkáoszhoz vezet) és egyetlen meghibásodási pont (egy Agent véletlenül törli az összes fájlt). Hogyan terveznéd egy robusztusabb fájlrendszer-irányítási mechanizmust?

Particionált irányítás: oszd fel a rendszert a 10-4. táblázat négy zónájára, a privát jegyzettömbök (scratchpads) elkülönítik a próba-hiba területeket. Szemantikai ütközések: az orchestációs réteg adja meg a könyvtárszintű zárolási fájlokat, és a módosítások előtt a könyvtárzárolás megszerzését követeli meg. Névtér-szennyezés: könyvtárkonvenciók és elnevezési konvenciók. Egyetlen meghibásodási pont: használj verziókövető rendszert, hogy a verziótörténet visszaállítható legyen, és minimalizáld az engedélyeket.

**6. (★★★) A piaci mechanizmuson alapuló Ágens együttműködés (Pinchwork, RentAHuman) tranzakciós kapcsolatokat vezet be: egyik Agent fizet egy másik Agentnek (vagy embernek) egy feladat elvégzéséért. Hogyan mérheti automatikusan a foglalkoztató Agent a végrehajtó által szállított eredmények minőségét? Ha a végrehajtó azt állítja, hogy kész, de a foglalkoztató szerint a minőség nem megfelelő, ki dönti el a vitát? Hogyan akadályozható meg, hogy a rossz pénz kiszorítsa a jót?

Az elfogadás nem állhat csak az Agent trajektória olvasásából; használj determinisztikus külső ellenőrzést, mint tesztvégrehajtás, renderelt képernyőképek és eszköz-ellenőrzések. Használd ki a generálás-ellenőrzés nehézségi aszimmetriáját az elfogadási költségek csökkentésére. A vitákat egy független harmadik fél felülvizsgáló Agent dönti el, a pénzeszközök escrow-ban tartva. A rossz pénz kiszorítása ellen: használj reputációs rendszert a történeti szállítások alapján, az árjeleket a minőséghez kötve.

**7. (★★) A RentAHuman lehetővé teszi, hogy az Agentek embereket alkalmazzanak kriptovalután keresztül, megfordítva a hagyományos ember-gép kapcsolatot. Ha ez a modell elterjedne, milyen szerepet játszanának az emberek az Ágens gazdaságban? Csak a fizikai feladatokat végeznék, amelyeket az Agentek nem tudnak befejezni?

Az emberek többet tesznek, mint a fizikai feladatok elvégzése, amelyeket az Agentek nem tudnak befejezni. Olyan információt is nyújtanak, amely a generáláskor nem áll az Agent rendelkezésére, beleértve a helyszíni észlelést és a valós világ visszajelzését; végső elfogadókként és vitarendezőkként szolgálnak; hitelesítést és elszámoltathatóságot viselnek jogi és felelős alanyokként; célokat tűznek ki és értékítéleteket hoznak; valamint ellenőrzést biztosítanak ott, ahol az információ aszimmetrikus vagy erkölcsi határok érintettek.

**8. (★★) Az emberi társadalomnak azért van szüksége munkamegosztásra, mert mindenki képességei korlátozottak – a frontend fejlesztő nem biztos, hogy ért a backendhez, a tervező nem biztos, hogy ért az üzemeltetéshez. A nagy modellek azonban közelebb állnak az "általánosistákhoz". Kutatások szerint tiszta szöveges érvelési feladatokon a többágens vita (multi-agent debate) nem veri az egyetlen Agentet azonos számítási kapacitás mellett. Akkor hol van a több Ágens valódi előnye?

1. Külső visszajelzés bevezetése, mint végrehajtási eredmények és vizuális képernyőképek, olyan információk behozása, amelyek a generáláskor nem léteztek.
2. Több, eltérő célokkal és szerepdefiníciókkal rendelkező Agent megvitathat és versenyezhet egymással, mint az emberi társadalomban, segítve egyetlen Agent vakfoltjainak elkerülését.
3. A kontextus izolációja több Ágens között áttörheti a kontextusablak korlátját, és támogathat nagyon hosszú eszközhívási láncokat.

9. (★★★) Ez a fejezet a "megosztott kontextus" versus "nem megosztott kontextus" dimenziót kezeli a többágens rendszerek egyik magtervezési dimenziójaként. A megosztott kontextus lehetővé teszi, hogy minden Agent ugyanazt az információt lássa, ami látszólag megkönnyíti a koordinációt. De A Háromtest-problémában a Trisolaris-ok elméje teljesen átlátható, mégis technológiai fejlődésük stagnál; a gemkapocs gondolatkísérlet is azt mutatja, hogy amikor egy csoport ugyanazon cél felé konvergál, a diverzitás elvész. Többágens rendszerben hogyan egyensúlyozható ki a hatékonyság és a diverzitás?

A teljes megosztás felerősíti a gondolkodási tehetetlenséget és a hibakaszkádokat; az izoláció az, ami kognitív diverzitást eredményez. Használj különböző promptokat vagy modelleket eltérő gondolkodási torzítások létrehozásához (brainstorm, debate), és a kereszt-validátorok csak a nyers bizonyítékokat vizsgálják, ne az előző gondolkodási folyamatot.

**10. (★★★) Adj egy Kódoló Agentnek 30 lépésből és 300 lépésből álló költségvetést. Hogyan különbözzön a munkastratégiája? A kutatás szerint a lépésköltségvetés egyszerű növelése nem garantálja a teljesítmény javulását – az Agentek idő előtt "telítődhetnek" a sekély keresés után. Tervezz egy "költségvetés-tudatos" mechanizmust, amely lehetővé teszi, hogy az Agent kis költségvetés mellett gyorsan elérje a magfunkcionalitást, nagy költségvetés mellett pedig tervezési, tesztelési és felülvizsgálati fázisokat adjon hozzá, teljes mértékben kihasználva a többlet számítási erőforrásokat.

Mechanizmus: injektáld a teljes és fennmaradó költségvetést a promptba minden lépésnél, és dinamikusan állítsd a felfedezés/kihasználás súlyát a fennmaradó arány szerint. Például kis költségvetéssel (30 lépés) hagyd ki a tervezést és felülvizsgálatot, és menj egyenesen a magfunkcionalitásra plusz alapvető ellenőrzésre. Nagy költségvetéssel (300 lépés) tervezz, implementálj, tesztelj, majd vizsgáld felül és fejlessz, mérföldkő-ellenőrzőpontokkal értékelve a haladást és megakadályozva a sekély telítődést.

**11. (★★) Ez a fejezet az "idő előtti befejezést" három típusba sorolja: lusta hamis-kész, idő előtti feladás és hamis siker. Miért konvergál mindhárom gyógymódja az ellenőrzésre?

A közös gyökér az, hogy hogy a feladat befejezéséről a modell önbejelentése dönt; a "kész" egy állítás, nem egy bizonyíték. Az ellenőrző (verifier) feltételei: ① alapuljon valós megfigyeléseken (tesztek futtatása, képernyőképek renderelése, annak ellenőrzése, hogy a visszatérítés ténylegesen megérkezett-e); ② tételesen ellenőrizze a befejezés explicit definíciója ellen, elkapva a lusta hamis-kész és a hamis siker eseteit; ③ ellenőrizze a kudarc következtetéseit is, elkapva az idő előtti feladást; ④ párosítsa explicit megszakítási feltételekkel (kör-/költségvetési plafon) hogy megakadályozza az idő előtti befejezésről az ellenkező végletbe – egy irányíthatatlan hurokba – való csúszást.

**12. (★★) A 10-3. táblázat a többágens rendszereket sorról sorra operációs rendszerekre képezi le. Bővítsd ki a táblázatot néhány további sorral: minek felelnek meg a virtuális memória és lapozás, a fájlengedélyek, a holtpont-detektálás és az ütemezési algoritmusok az Ágensek világában? És mely operációsrendszer-fogalmaknak nincs megfelelőjük az Ágensek világában, és miért?

Lehetséges kiterjesztések: virtuális memória/lapozás ↔ kontextus-tömörítés és lekérés (forró információ az ablakban marad, hideg információ fájlokba és memóriatárolókba kerül ki, és szükség esetén visszakerül); fájlengedélyek ↔ eszköz-fehérlisták, csak olvasható mount-ok és hitelesítőadat-határok; holtpont-detektálás ↔ ciklikus feladatátadások és kölcsönös várakozás detektálása (feladatátadás-számlálók és időtúllépések); ütemezési algoritmusok ↔ aszinkron eseménykezelés (4. fejezet). A hiányzó megfelelők a kikényszerítési különbségből adódnak: egy folyamat utasításait hardver kényszeríti ki, míg egy Agent csak nagy valószínűséggel követi a promptokat.