Előfordult már, hogy egy adott utasítás jól működött, majd hirtelen használhatatlanná vált?
Került már abba az ördögi körbe, hogy az eredmények javítása érdekében folyamatosan foltozgatta a rendszerutasítást, mégsem működött semmi?
Lehet, hogy éppen a rendszerutasítás-tanulásra van szüksége.
A rendszerutasítás-tanulás (SPL) az MI-közösség egyre nagyobb érdeklődést kiváltó területe, amelyet májusban Andrej Karpathy tett széles körben ismertté az X-en.
A rendszerutasítás-tanulás a statikus rendszerutasításokra vagy nehézkes finomhangolási megoldásokra támaszkodó, rugalmatlan és sérülékeny MI-rendszerek korlátait kezeli. Egy másik lehetőséget kínál az MI-rendszerek folyamatos tanulásának támogatására.
Mielőtt elmélyednénk benne, tekintsük át röviden az utasításadás alapjait.
Egy ügynök vagy egyedi modell fejlesztésekor először két kulcsfontosságú elemet kell megterveznünk:
Egy rendszerutasítást
Egy felhasználói utasítást
A rendszerutasítások határozzák meg a modell viselkedésének alapvető szabályait. Egyedi MI-megoldások esetén gyakran valami ilyesmivel kezdődnek:
“You are an intelligent assistant. Your role is to perform <insert task here>.
You must not do (A), (B), or (C).”
Ezzel szemben a felhasználói utasítások jellemzően a felhasználó kérdését és más lényeges információkat, például az időzónáját és a beállításait tartalmazzák. Egy felhasználói utasítás például így nézhet ki:
I’m in the capital city of Portugal. Can you suggest some things I can do tonight?
A nagy MI-laborok új modelljeinek megjelenése után gyakoriak lettek a rendszerutasítás-szivárgások, mivel a felhasználók jailbreak segítségével veszik rá a chatbotokat a mögöttes utasításaik felfedésére. Egy népszerű GitHub-adattár ma már számos ilyen rendszerutasítást gyűjt össze egy helyen. Felfedik azt a „titkos receptet”, amelyet az MI-laborok az idők során a modellek megfelelő viselkedésének ösztönzésére dolgoztak ki. A nemrég kiszivárgott GPT-5-rendszerutasítás (amely a ChatGPT-ben vált hozzáférhetővé) például mintegy 6000 szóból áll, jól szemléltetve, mennyi tudást és útmutatást kell kódolni a rendszer viselkedésének alakításához.
Ezek az átfogó rendszerutasítások jellemzően több kulcsfontosságú területre is kitérnek, például:
Keresési utasítások
Eszközdefiníciók
Felhasználói beállítások
Hivatkozási utasítások
Gyors javítások az ismert problémákra
A gyakorlatban az egyedi MI-rendszerek fejlesztői az alkalmazások tesztelése és finomítása során kézzel, iteratív módon foltozzák a rendszerutasításokat, a fejlesztési folyamatot pedig elsősorban kiértékelések segítségével irányítják.
A modell viselkedése más módszerekkel is irányítható, például:
Utasítás tervezéssel, beleértve a visszakereséssel kiegészített generálást (RAG), amely a modellnek átadott tartalmat szabályozza
Finomhangolással (a modell mögöttes súlyainak közvetlen módosításával)
Mi lenne, ha más módon is befolyásolhatnánk a modell viselkedését? Képzeljünk el egy rendszert, amely a korábban létrehozott gondolatok, tervek és stratégiák felhasználásával dinamikusan tanulja és finomítja saját rendszerutasítását. A kimenetei értékeléséhez a felhasználói visszajelzésekre és az LLM mint értékelő módszerre egyaránt támaszkodhatna.
Gondoljon egy tartós üzleti kihívásra, amelyet ügynökalapú rendszerrel szeretne automatizálni. A hatékony megoldásokhoz az alapvető munkafolyamat-automatizáláson túlmutató érvelési képességekre van szükség. Ilyen esetekben elengedhetetlen, hogy tervkészítő összetevővel egészítse ki az MI-rendszert. Így a rendszer a feladattól függően különböző módokon működhet együtt több ügynökkel. Az egyes lépések utasításokat tartalmazhatnak más ügynökök bevonására a részfeladatok elvégzéséhez vagy eszközök használatára.
Megjegyzés: Az ügynök eszköze bármely külső függvény, API vagy erőforrás, amelyet egy MI-ügynök meghívhat, hogy túllépjen a szövegalkotáson, és valós műveleteket hajtson végre.
A modell rendszerutasítását „elindíthatja” egy olyan tervvel, amely az ember által követett logikus lépésekből áll, bár az LLM-eknek általában pontosabb útmutatásra van szükségük az eszközhasználatról, a kimenet formázásáról és a kapcsolódó követelményekről. Előfordulhat, hogy nem egyértelmű az optimális stratégia, vagy olyan problémával foglalkozik, amelyet azért nem értékeltek újra, mert korábban már megoldottnak tekintették. Itt lép be a képbe a rendszerutasítás-tanulás (SPL).
Az SPL a korábban létrehozott stratégiák beépítésével, iteratív módon javítja a rendszerutasítást. Az új problémák felmerülésével a rendszer fokozatosan gyarapítja tudását és ellenállóbbá válik. Olyan ez, mintha kézikönyvet készítene a saját szakterületén felmerülő problémák megoldásához.
Az SPL fokozatosan beépíti a felhasználói visszajelzésekből származó felismeréseket a rendszerutasításba. A rendszer fejlődésével ismétlődő problémákat fedezhet fel, amelyek általánosabb, magasabb szintű alapelvekké sűríthetők.
Nézzük meg közelebbről, hogyan működik a folyamat lépésről lépésre:
Induljon ki a felhasználó kéréséből, amelyben egy konkrét feladat elvégzésére kéri a rendszert.
Ha a rendszer csak egy problémát kezel, alkalmazhat „mohó” megközelítést, és kiválaszthatja a korábbi futások legmagasabb pontszámú stratégiáit. Másik lehetőségként felfedezésre ösztönözheti a rendszert egy olyan eloszlásból végzett mintavételezéssel, amely előnyben részesíti a magas pontszámú stratégiákat, de időnként alacsonyabbra értékelteket is bevon. Ez különösen akkor hasznos, amikor még csak most kezdi gyűjteni a stratégiákat.
A különböző problémakörök kezelésére tervezett rendszereknél érdemes osztályozási réteget hozzáadni, vagy beágyazásokat és koszinuszos hasonlóságot használni – ugyanazokat a módszereket, amelyeket jellemzően a RAG is alkalmaz – a releváns megközelítések azonosításához. Így kiválaszthatja az adott problémához illő stratégiákat, például a programozási feladatokra szabottakat.
Megjegyzés: A beágyazások és a koszinuszos hasonlóság segítségével megmérhető, milyen szorosan kapcsolódik egymáshoz két információ. Így akkor is könnyebb párosítani dokumentumokat, lekérdezéseket vagy ötleteket, ha eltér a pontos megfogalmazásuk.
Egyszerűsített stratégiatár kiinduló példája programozási problémák megoldásához.
Megjegyzés: Az itt látható „kezdőstratégiák” csak szemléltető példák. Valós programozási helyzetekben tovább finomítanánk őket. A szűkebb üzleti problémákhoz idővel további felismeréseket kellene gyűjteni.
Generation_id (fordított sorrend) | Téma | Pontszám | Strategy_text | Magyarázat |
|---|---|---|---|---|
4 | programozás | 1 | Understand the problem, constraints, and edge cases. Design an algorithm with the right data structures. Validate the plan on examples and invariants. Implement clean, readable code. Refine with refactoring, optimization, and final formatting. Tool use: When using a tool, briefly explain why it was needed. | Ötvözi az alábbi három stratégia legerősebb elemeit. |
3 | programozás | 1 | Understand the problem, constraints, and edge cases. Design an algorithm with the right data structures. Validate the plan on examples and invariants. Implement clean, readable code. Refine with refactoring, optimization, and final formatting. | Sokoldalúbb stratégia, de nem ad útmutatást az eszközök használatához. |
2 | programozás | -1 | Understand the problem, constraints, and edge cases. Design an algorithm with the right data. Implement clean, readable code. Tool use: when accessing tools produce a short summary as to why you used that tool. | Jobb stratégia, amely említi az eszközhasználatot, de még tovább fejleszthető. |
1 | programozás | -1 | Skim the problem. Solve the problem. Create minimal tests. Submit whatever runs. | Említi a teszteket, de összességében gyenge stratégia. |
3. N elem mintavételezése után építse be őket a rendszerutasításba. Így a tervkészítés korábbi szakértői visszajelzésekre épül, ahelyett hogy a modellnek minimális útmutatás mellett kellene terveket létrehoznia. Ösztönözze a modellt arra, hogy „lépjen túl a megszokott kereteken”, és szükség esetén adjon hozzá új lépéseket, ahelyett hogy egyszerűen szó szerint lemásolná a mintastratégiákat.
4. A dinamikusan létrehozott rendszerutasítással dolgozzon ki új stratégiát a felhasználó kérésének teljesítésére. A folyamatnak további, a végső kimenetet javító feladatokat kell eredményeznie. A cél a kreativitás: ötvözze a korábbi stratégiák legerősebb elemeit, vonja össze az átfedő lépéseket, és szükség esetén egészítse ki őket hasznos újakkal.
Megjegyzés: Ne feledje, hogy a hőmérséklet olyan paraméter, amelynek módosításával változatosabb, kevésbé determinisztikus kimenetek állíthatók elő, ami kreatív feladatoknál hasznos. Nullától eltérő hőmérséklet mellett minden létrehozott terv különbözhet.
5. A modell kimenetét egy emberi értékelővel vagy LLM-bíróval vizsgáltassa meg olyan konkrét szempontok alapján, amelyek meghatározzák, milyen a probléma jó megoldása. A korábban említett portugáliai programok példájánál az értékelési szempontok a következők lehetnek:
Tömörség (legfeljebb egy mondatos válasz)
A javasolt program relevanciája
A helyszín pontossága
6. Az értékelés alapján egy másik modellel finomítsa a stratégiát. Egy opcionális visszacsatolási ciklus emberi közreműködést is bevonhat, és támogathatja a közös fejlesztést. A finomított stratégiát megfelelő metaadatokkal együtt mentse az adatbázisba, hogy nyomon követhetők legyenek a verziók és a változások.
De miért érdemes ennyi munkát fektetni ebbe? A kimeneteket kézzel is ellenőrizhetné, majd ennek megfelelően módosíthatná a rendszerutasítást. A nagy teljesítményű érvelési modellek azonban a kimenet kontextusa és az emberi visszajelzések alapján is képesek finomítani a stratégiákat. Az egyszerű megközelítések hibáit az emberek könnyen felismerik, az átfogóbb problémaköröket kezelő összetett rendszerekben azonban ezek azonosítása nehézzé és fáradságossá válik.
Az LLM-eknek gyakran részletes utasításokra és további lépésekre van szükségük ahhoz, hogy összegyűjtsék azt a háttértudást, amelyet az emberek magától értetődően visznek bele egy probléma megoldásába. A szükséges feladatok száma gyorsan növekedhet, ahogy a rendszert egyre szélesebb problémakörök kezelésére bővítik. Programozási problémáknál például az emberek ösztönösen átláthatják a kapcsolódó kódbázist, míg egy LLM-nek először több fájlt is „el kell olvasnia”.
Amikor hasznos: Tegyük fel, hogy ügyfélszolgálati csapatot vezet, és egy MI-ügynök végzi a hibajegyek előzetes besorolását. Az SPL idővel olyan kategorizálási módszert fedezhet fel, amelyre a csapat korábban nem gondolt, és ezzel csökkentheti az eszkalációk arányát.
Amikor nem hasznos: Ha a munkafolyamatokat már megfelelőségi követelmények vagy jogszabályok határozzák meg, például a pénzügyi beszámolásnál, az SPL kevés értéket teremthet, mert a kreativitás előny helyett kockázattá válik.
Amikor hasznos: A sok kutatást igénylő munkakörökben – például piaci információgyűjtésnél vagy termékstratégiánál – az MI terveinek finomításával és kimeneteinek gazdagításával működhet együtt vele, a fejlesztéseket pedig későbbi használatra is beépítheti. Minden interakció növeli a rendszer hatékonyságát.
Amikor nem hasznos: Ha a csapat főként egyszerű, minimális emberi közreműködést igénylő munkafolyamatokra használ MI-t – például számlafeldolgozásra –, az együttműködés többletterhe meghaladhatja az előnyöket.
Amikor hasznos: Tegyük fel, hogy új régióban kezdi meg működését, és az MI-nek hirtelen helyi adózási kérdéseket kell kezelnie. Az SPL segítségével gyorsan kódolhatja az új szabályokat és heurisztikákat, amint felmerülnek, így megelőzheti az ismétlődő hibákat.
Amikor nem hasznos: Statikus környezetben – például amikor értekezletek átirataiból szabványos összefoglalók készülnek – a folyamatos alkalmazkodás alig jelent előnyt.
Elméletben mindez ígéretesnek hangzik, az SPL bevezetése azonban valódi kihívásokkal jár. Az alábbiakban a legfontosabbak közül mutatunk be néhányat:
A stratégiák létrehozásának korai szakaszában a fejlődés gyakran megtorpan: az új kimenetek nem épülnek a korábbiakra, és lelassul az előrehaladás. Ennek általában két fő oka van:
Megoldás: Előre kódolja az összes elérhető üzleti tudást, hogy a rendszer kellően gazdag ismeretanyagból meríthessen.
Megoldás: Készítsen árnyalt értékelési szempontrendszert, amely a válasz több jellemzőjét – például pontosságát, érthetőségét és relevanciáját – pontozza, majd igazítsa a mintavételezést ezekhez a jelzésekhez.
Ha a rendszer több száz stratégiát hoz létre, de kevés visszajelzést kap a jó és a rossz megkülönböztetéséhez, a mintavételezés gyorsan kezelhetetlenné válik. A megoldás a ritkítás.
A stratégiatár finomításakor vegye figyelembe a következőket:
Élettartam: Vonja ki a stratégiákat, ha elérik a meghatározott időtartamot vagy generációszámot.
Pontszám: Az értékelési szempontrendszerrel szűrje ki a tartósan gyengén teljesítő stratégiákat. Az élettartammal együtt alkalmazva ez biztosítja, hogy csak azokat a megközelítéseket tartsa meg, amelyek idővel bizonyítják értéküket.
LLM-alapú értékelés: Rendszeresen vizsgálja felül a stratégiákat, hogy azonosítsa azokat, amelyek már nem kínálnak egyedi felismeréseket, mert hasznos elemeiket valószínűleg már átvették az újabb változatok.
Megoldás: Kezelje a stratégia-adatbázist élő rendszerként: rendszeresen ritkítsa, hogy csak releváns, nagy értékű tudás maradjon benne.
A rendszerutasítás-tanulás még gyerekcipőben jár, de óriási lehetőségeket rejt. A kizárólag statikus utasításokra vagy végtelen finomhangolásra támaszkodó vállalkozások ismerős korlátokkal szembesülnek: sérülékeny rendszerekkel, növekvő költségekkel és elpazarolt munkával. Az SPL kitörést kínál ebből a körből: olyan rendszereket épít, amelyek idővel fejlődnek, és elszigetelt foltozások helyett magasabb szintű alapelveket kódolnak.
Az SPL még kialakulóban van, de az irány egyértelmű: az önmaguktól tanulni képes rendszerek lehagyják azokat, amelyek erre nem képesek. Most érdemes kísérletezni, kis lépésekben kezdeni, rögzíteni a tanulságokat, és megteremteni az alapot a minden interakcióval fejlődő MI-rendszerekhez.