Közösség

Az egyes tanulási útvonalakat végigjárva olyan, naprakész és a gyakorlatban is hasznosítható tudás szerezhető, amely komoly szakmai előnyt jelent a mai munkaerőpiacon. Az útvonalak végén vizsga és hivatalos minősítés is elérhető, amely standardizált módon igazolja a megszerzett tudást és kompetenciákat.A teljes képzési anyagok egy része kizárólag a partneri jogviszonnyal rendelkező vállalatok munkatársai számára érhető el. Tapasztalatainkra építve azonban olyan tanulási csomagokat és egyéni tanulási útvonalakat is össze tudunk állítani, amelyek nyilvánosan hozzáférhető, magas színvonalú tananyagokra épülnek, és jó kiindulópontot jelentenek a fejlődéshez.Az ezekre épülő alapozó tudás megszerzése után további, akár vizsgával és minősítéssel záruló képzések is elérhetők. Ha eljutsz erre a szintre, abban is támogatást nyújtunk: segítünk megtervezni a következő lépéseket, és eligazodni a további lehetőségek között.Mérd fel a jelenlegi tudásodat, készíts személyre szabott tanulási útvonalat, indulj el rajta, és kövesd folyamatosan a fejlődésedet. Térj vissza újra és újra, fedezz fel új tananyagokat, és építsd tudatosan a szakmai kompetenciáidat.

Prompt engineering vs. context engineering

A prompt engineering arra fókuszál, hogyan fogalmazzuk meg a kérést. A context engineering ennél tágabb: a modell számára elérhető információ tudatos kiválasztása, strukturálása és kezelése.

Egy AI-agent kontextusa ugyanis nemcsak a felhasználó kéréséből áll. Ide tartozhatnak:

• Instrukciók: rendszer- és projektszintű szabályok.
• Előzmények: korábbi beszélgetések, döntések, megőrzött állapot.
• Projektanyagok: kód, fájlok, dokumentáció.
• Külső információk: RAG-gel visszakeresett dokumentumok, tool-definíciók és tool-hívások eredményei.

Miért nem jobb a több kontextus?

Egy hosszabb feladat során az agent kontextusában egyre több információ gyűlik össze. Régi döntések, már megoldott hibák, hosszú tool-outputok és irreleváns fájlok is bekerülhetnek a kontextusba.

Ez vezethet a context rot jelenségéhez: a kontextus növekedésével és elzajosodásával romolhat a modell teljesítménye. A fontos információk elveszhetnek a kevésbé releváns részletek között.

A cél tehát nem az, hogy minél több mindent adjunk a modellnek, hanem hogy a megfelelő információt kapja meg, a megfelelő időben.

Négy módszer a kontextus kezelésére

1. Rögzítsd: a fontos döntéseket, ismert problémákat és következő lépéseket tárold strukturáltan. Egy hosszabb fejlesztési feladatnál például legyen egy rövid állapotleírás arról, hol tart a munka.
2. Válogasd meg: ne tölts be minden dokumentációt és fájlt előre. A szükséges információkat akkor kérd le, amikor az agent-nek ténylegesen szüksége van rájuk. Erre épül például a skill-ek fokozatos betöltése is.
3. Tömörítsd: a teljes beszélgetési előzmény helyett őrizd meg a lényeges állapotot. Foglald össze a döntéseket, rövidítsd a hosszú tool-outputokat, és hagyd el azokat a részleteket, amelyekre már nincs szükség.
4. Izoláld: a nagyobb részfeladatokat futtasd külön kontextusban, például subagent-ekkel. A fő agent-hez csak az eredmény és a fontos következtetések kerüljenek vissza, ne a teljes részletes munkafolyamat.

Mire figyelj a gyakorlatban?

A jó kontextusnak három fontos tulajdonsága van: friss, megbízható és jól strukturált. Nem mindegy, hogy egy régi beszélgetésben szereplő feltételezés vagy egy aktuális projektinstrukció alapján dolgozik a modell.

A modern AI-fejlesztői eszközök, például a Cursor, a kontextus kezelésének jelentős részét automatikusan elvégzik. Ettől még sok múlik rajtunk: milyen fájlokat adunk az agent-nek, hogyan dokumentáljuk a fontos döntéseket, és mikor kezdünk új munkafázist. Ha pedig egyszerű chat felületen használjuk az AI-t, ezekre még tudatosabban kell figyelnünk.

A tanulság

Ha egy agent hosszabb feladat közben elveszíti a fonalat, nem biztos, hogy jobb promptra vagy erősebb modellre van szükség. Lehet, hogy egyszerűen rosszul kezeltük a kontextust.

Érdemes ugyanazt a feladatot különböző kontextuskezelési módszerekkel is kipróbálni, és három dolgot figyelni: az eredmény minőségét, a felhasznált token-ek számát és a válaszidőt. Így kiderülhet, melyik megközelítés hoz jobb eredményt, és milyen költséggel.

A context engineering lényege végső soron nem az, hogy a modell mindent tudjon a feladatról, hanem hogy mindig azt tudja, amire éppen szüksége van.

Mi az a skill?

Egy rendezett, újra használható csomag: szakmai tudás, utasítások és munkafolyamat egy adott feladattípushoz. Az Anthropic nyílt szabványként tette közzé, így nem csak egyetlen eszközben használható. A prompt egy alkalomra szól, a skill viszont eljárásbeli tudás, amit bármikor újra elővehetsz.

Miből áll?

• SKILL.md: az elején a skill neve és leírása. Ebből dönti el az agent, hogy mikor van rá szükség, ezért a leírás a legfontosabb sor. Utána jönnek az utasítások, a lépések és a döntési logika.
• References, scripts, assets: részletes háttéranyagok, szkriptek, képek. Egy céges diasablonhoz például a logó, a színek és az elrendezési szabályok.

Fokozatos betöltés

A skill nem egészében kerül a kontextusba, és ez sok tokent spórol:

1. Induláskor az agent csak a nevet és a leírást látja.
2. Ha a feladat illik a leíráshoz, beolvassa a SKILL.md törzsét. Kézzel, paranccsal is elindítható.
3. A referenciákat és a szkripteket csak akkor tölti be, amikor az adott lépéshez kellenek.

Gyakorlati tanácsok

1. Saját tapasztalatból indulj: ahol 3-4-szer belefutottál ugyanabba a problémába, és újra meg újra korrigálnod kellett az AI-t, ott érdemes skillt írni.
2. Ne tanítsd arra, amit alapból tud, például a SOLID elvekre: az csak tokent pazarol.
3. Eljárást taníts, ne konkrét választ: rögzítsd a munkalépéseket és a saját projekted szokásait.
4. Kezdd kicsiben: egyetlen SKILL.md fájl már működő skill.

Egy példa Gergőtől

A projektjén a gyakori rebase miatt sok merge-konfliktus keletkezett, és az agent magától, azonnal feloldotta volna őket. A skillje ehelyett elemzi a diffet, összefoglalja a konfliktust a fejlesztőnek, és a védett ág javára dönt, hogy ne kerüljön be regresszió. A git rebase --continue futtatását kifejezetten tiltja: a folytatás a fejlesztő döntése.

Forrásnak az előadás az Awesome Agent Skills gyűjteményt és a Supabase SQL-optimalizáló skilljét ajánlotta. A meglévő skilleket pedig érdemes időnként átnézni, hogy az újabb modellek mellett is kellenek-e még.

Miért érdekes?

Az AI-integrációkban meglepően sok hívás valójában döntés. Egy ügyfélszolgálati rendszer minden levelet besorol, eldönti, sürgős-e, és ellenőrzi a kimenő választ. Ma ezt jellemzően LLM végzi: JSON-szöveget ír, amit a programnak értelmeznie, ellenőriznie és hiba esetén újrakérnie kell. Ez nagy volumennél lassú és drága.

Mi az a döntési modell?

A Jev egy szövegről típusos kérdéseket kap (melyik opció, igaz-e, hol áll egy skálán), és mindegyikre egyszerre, egyetlen lépésben ad választ, valószínűségekkel. Nem tokenről tokenre ír, mint egy LLM.

Amit láttunk

• 40 ticket besorolása 5 csapatba: a pontosság gyakorlatilag azonos volt (Jev 39/40, Gemini 3.5 Flash-Lite 39/40, Claude Haiku 4.5 40/40), a Jev viszont 6,5 s alatt végzett, a Haiku 19,4 s alatt.
• Egymillió ticketre vetítve a költség nagyjából 18 $ a Haiku 390 $-jával szemben.
• 50 kérdés egy hívásban: a Jev végig 0,3 s körül maradt, az LLM-ek minden új kérdéssel lassultak.
• Valós időben, egy Snake-játékban a Jev a lépésenkénti 350 ms-os határidőt is tartotta, a Haiku 1 s-nál kiesett.
• Agent-biztonsági fékként mindhárom modell blokkolta az öt veszélyes lépést; az ellenőrzés a Jev-vel 6 s, a Haikuval 23 s volt.

Hol a korlát?

A Jev nem indokol, számolásban és dátumokban gyengébb, csak szöveget fogad, és egyelőre korlátozott early accessben érhető el. Ahol a döntést meg kell magyarázni egy ügyfélnek, auditornak vagy kollégának, oda továbbra is LLM kell.

A tanulság

Érdemes egy AI-folyamatot döntési és szövegíró lépésekre bontani. Egy support ticket kezelésénél a Jev osztályozott és ellenőrzött, a Haiku csak a választ írta meg: egy ticket 4,74 s helyett 2,83 s alatt ment végig, és 1000 ticket 1,50 $ helyett 0,60 $-ba került.

A mérés kis mintán, egyetlen futással készült, ezért a számok irányt mutatnak, nem benchmarkot. Ha saját rendszerben gondolkodsz, mérd le a saját adataidon is.

Ha érdekel, hol tartasz az AI-eszközök használatában, töltsd ki a felmérésünket: a végén a szintedhez illő tanulási utat kapsz.