Hogyan PROMPTolj (haladóknak) — a jó prompt valóságkalibrálás, nem stílus

TL;DR

A promptolás nem stílusgyakorlat, hanem gondolkodási fegyelem — a gondolkodásod rendezettsége megjelenik a mondataidban, és a mondataid rendezettsége visszahat arra, hogyan döntesz
Három réteg irányít: terület (nyers bizonyíték), térkép (értelmezési keret), kényszer (végrehajtási szerződés) — ha bármelyik összemosódik, a modell nem a valóságra válaszol, hanem a saját koherenciáját védi
A sorrend nem ízlés kérdése: ha a feladat és a hang hamarabb érkezik, mint a bizonyíték és a tiltás, a fluencia az igazság helyére ül
RAG pipeline és agent futtatás esetén a strukturált prompt nem opció, hanem futtatási feltétel — itt nem egy választ kapsz, hanem egy folyamatot indítasz el
A kibernetika idevágó tétele: egy szabályozó csak akkor tud stabilan irányítani, ha belső változatossága legalább akkora, mint a környezet zavarai

Önmagadat viszed a dolgokhoz, hogy igazold a gyakorlatot — ez delúzió. A dolgok jönnek és igazolnak téged — ez realizáció.

Mi lesz a következő közös nyelv?

A haladó promptolás három rétegre épül: terület (nyers bizonyíték), térkép (értelmezési keret) és kényszer (végrehajtási szerződés). A rétegek sorrendje dönti el, hogy a modell a valóságból vagy a saját koherenciájából indul ki. Hat tipikus hibamód azonosítható, és mindegyik visszavezethető arra, hogy melyik réteg hiányzik vagy csúszik össze.

Ma a világon körülbelül 1,6 milliárd ember beszél angolul, 1,2 milliárd mandarin kínait, 610 millió hindit, 580 millió spanyolt, és nagyjából 320 millió franciát vagy arabot. Én mégis azt látom, hogy a következő nagy közös kommunikációs réteg nem egy új nemzeti nyelv lesz, hanem a prompt mint írásmód. Nem új ábécé, nem új nyelvtan — inkább egy új regiszter, ahol a mondat nemcsak jelent, hanem műveletet indít, és ettől a szöveg hirtelen eszközzé válik.

Én ezért veszem komolyan, mert mindennapi hatása van. Aki jobban promptol, gyorsabban tisztáz, kevesebbet javít utólag, kisebb hibaaránnyal dolgozik, és ugyanannyi időből több értéket hoz ki.

Nálam ez mélyebbről indul. A gondolkodásom rendezettsége megjelenik a mondataimban, a mondataim rendezettsége pedig visszahat arra, hogyan döntök, hogyan kérek segítséget, hogyan tanulok. A promptolás szerintem nem trükk, hanem gondolkodási fegyelem, és amikor ez a fegyelem összeáll, akkor nemcsak a gépet irányítom jobban, hanem saját magamat is.

Hogyan gondolkodom a gépről, amikor promptolok

Én úgy kezelem a rendszert, mint egy együttműködő partnert, aki hajlamos félreérteni. A modell nem úgy “tudja”, mit akarok, mint egy ember. Nem szándékot olvas, nem a “világot” nézi, hanem a szavaimból következtet, mintázatokat illeszt, jeleket súlyoz, és a legvalószínűbb folytatást állítja elő.

Ez az oka annak, hogy a fluencia — vagyis a szép, összefüggő, meggyőző szöveg — önmagában nem garancia igazságra. Az egyik legnagyobb belátásom az volt, hogy a modell tud elegáns választ adni akkor is, amikor valójában csak kitöltötte a hiányzó részeket.

Filozófiailag lehet vitatkozni azon, hogy ez mennyire “megértés”. Én a gyakorlatban egy működő szabályt követek: úgy promptolok, mintha a rendszernek nem lenne emberi értelemben vett szándéka, és mintha nem lenne olyan belső “világa”, amihez én hozzáférhetnék. Így nem azt várom tőle, hogy “érezze, mire gondolok”, hanem azt, hogy az általam adott keretben végrehajtson egy feladatot, és jelezze, hol bizonytalan, hol kell még adat.

I. Promptolás mint élvezet — avagy a szörf mód

Van az a használat, amikor nem akarsz “helyes választ”, csak társaságot a gondolkodásodhoz. Ilyenkor az LLM nem eszköz, hanem közeg — mint egy óriási információhalmaz tetején a hullám, amin állsz, és közben nézed, merre visz a nyelv. Játszol a metaforákkal, fogalmakat ütköztetsz, hangulatot próbálsz, homokvárat építesz, majd hagyod, hogy a következő mondat elsodorja, és ez rendben van. Ebben a módban az érték nem a pontosság, hanem az asszociáció, a ritmus, a váratlan összekötés, a “hogyan juthatnék el ide onnan” élménye.

Ez az a pont, ahol a Zen unalmasan pontos. Semmi különös nem történik, csak észreveszed, mikor akarsz a játékból igazságot csinálni, és mikor akarsz a bizonytalanságból pózt.

Rezonancia játék

Van egy üzemmódom, amikor nem specifikációt írok, nem helyes választ akarok, hanem egyszerűen játszani akarok a saját figyelmemmel. Ilyenkor az LLM egyfajta tükör — csak nem üveg, hanem nyelvből készült visszhang. Bedobok egy fél mondatot, egy hangulatot, egy félig kimondott sejtést, és a rendszer úgy rezonál rá, mintha a gondolkodásom kapott volna még egy réteget, még egy hangszínt.

Ebben brutálisan erős, mert nem a valóságra rezonál, hanem rám — a ritmusomra, a visszatérő motívumaimra, azokra a kanyarokra, ahogy kerülök dolgokat, vagy ahogy túlságosan pontosan fogalmazok, amikor valójában bizonytalan vagyok. A legjobb pillanatokban nem “tudást” kapok, hanem mozgást, és ez a mozgás kibontja azt is, ami bennem még csak sejtés.

A rezonancia játék élvezeti értéke nekem az, hogy ez a tükör nem passzív. Nemcsak visszaver, hanem variál, bont, újrahangol — és ettől olyan, mintha egy gondolat több életet kapna egymás után. A koherencia ilyenkor nem bizonyíték, hanem zene. A szépség nem igazság, hanem forma, ami megmutatja, merre lehetne még menni.

Prompt Jam

A Prompt Jam olyan, mint egy jam session (zenei improvizáció), csak hangszerek helyett fogalmak vannak, ritmus helyett figyelmi súlypontok, és a dallam maga a nyelv. A cél nem a végleges kimenet, hanem hogy legyen flow, legyen játék, legyen váratlan összekötés — legyen az a “nahát”, amikor egy gondolat végre megtalálja a saját alakját.

És itt jön az a paradoxon, amitől az egész még szebb. Ami belülről varázslatnak tűnik, az valójában matek és statisztika, brutális programozói fegyelem, valószínűségek, mintázatok, tokenek egymás után. Ettől nem lesz kevesebb, hanem még tisztább, mert egyszerre tudok rácsodálkozni és józan maradni. A Prompt Jam akkor működik jól, ha én is kimondom magamnak: ez improvizáció, nem bizonyítás — és hogy ami most “nagyon ül”, attól még nem lesz igaz, csak rezonáns, csak termékeny, csak jól megírt.

Nyelvi csavargás

A nyelvi csavargás módja az egyik legegyszerűbb és talán legemberibb módja az LLM használatának. Nem akarok sehova odaérni, csak megyek mondatról mondatra — mint egy esti séta, ahol néha befordulok egy mellékutcába, mert érdekes a fény, aztán visszatérek, aztán megint elkanyarodom.

Ilyenkor az LLM beszélgetős közeg, egy hatalmas szövegtér, amiben kóborlok, és közben a nyelv húz elő belőlem gondolatokat. Nem struktúrálok, nem objektumorientálok, nem debuggolok — csak engedem, hogy a figyelmem megmutassa, mi érdekel valójában.

A nyelvi csavargásnál számomra egyetlen szabály számít: a homokvar maradjon homokvar. Lehet gyönyörű, lehet játékos, lehet meglepően mélynek ható, de közben nem kezdem el úgy kezelni, mintha terepbejárás lenne. Amíg ez a keret a helyén van, addig nem félrevisz, hanem felold — és közben olyan finoman tanít, hogy észre sem veszem, mert a tananyag én vagyok, a módszer pedig a mondatok mozgása.

II. A munka és a kutatás területe — amikor lényeges az eredmény minősége

Munka esetén a promptolást programozásnak tartom, mert futási rendet, interfészt, invariánsokat és tesztelhető kimenetet adunk meg, és nem determinisztikus végrehajtást kapunk, hanem valószínűségi következtetést.

Miért inkább programozás ez, mint írás

A promptolás valójában programozás, csak nyelvi anyagból. Amikor jól promptolsz, nem “szöveget írsz” a modellnek, hanem futtatható specifikációt építesz, ami kijelöli: mi számít instrukciónak, mi a feladat, mi az adat, milyen korlátok érvényesek, és milyen formában fogadható el a kimenet.

Ezért stabilabb a rétegezett prompt, mert ugyanazt csinálod, mint egy jó szoftvertervező. Modulokra bontasz, tiszta kapcsolódási pontokat adsz, és csökkented a rejtett mellékhatásokat — azt a zónát, ahol a hipotézisréteg a saját koherenciaigénye szerint “kisimítaná” a hiányokat.

A prompt tulajdonképpen egy szabadszöveges programnyelv — annak minden szabadságával és lehetőségével együtt, és persze ennek az összes hátrányával.

Ebben az értelemben a promptolás objektumorientált. Nem egy homogén szövegfolyamot küldesz, hanem külön funkciójú jelentésblokkokat, amelyeknek szerepük és felelősségük van:

Instrukció blokk — irányt ad
Feladat blokk — megmondja, mit kell csinálni
Input blokk — hordozza a “területet”, a nyers anyagot
Korlátok blokk — tilt és kötelez
Kimeneti formátum blokk — ellenőrizhetővé teszi, amit kapsz

Amikor ezeket összefőzöd, az olyan, mintha egyetlen osztályban kevernéd az üzleti logikát, a be- és kimenetet, és a konfigurációt. Működhet, csak törékeny. Amikor szétválasztod, a modell kevésbé tud “félreörökölni” — nem csinál adatból szabályt, szabályból díszletet, és nem cseréli el a figurát a háttérrel.

Térkép és terület

A valóság részletesebb és zajosabb, mint amit át tudok adni. Promptoláskor én nem a teljes területet adom oda, hanem térképet rajzolok. Kivonatolok, fókuszt állítok, szelektálok, arányokat torzítok, hogy navigálható legyen.

A térképről Alfred Korzybski hírhedt mondatát szoktam emlegetni: “The map is not the territory” — a térkép nem a terület. A térkép erénye nem az “igazsága”, hanem a használhatósága. A térkép attól jó, hogy oda visz, ahová menni akarok, és közben nem visz bele a mocsárba.

A gép oldaláról ez még élesebb, mert ő tényleg csak azt látja, amit én lerajzolok neki. Nincs ablaka a valóságra. Ha a térképről hiányzik egy híd, akkor vagy elakad, vagy kitalál egy hidat — és olyan magabiztosan megy át rajta, mintha ott lenne. Itt válik a fluencia veszélyessé, mert a “szép” és a “valós” nem ugyanaz.

Ennek van egy nagyon praktikus következménye: minden pontatlanság drágul. Egy elcsúszott cél, egy kimondatlan feltétel, egy félig definiált fogalom — és hirtelen egy másik városban vagyok, miközben a válasz még mindig elegáns.

Figura és háttér — a Gestalt mint rendezőelv

Ez az a rész, amit én sem szoktam rövidre fogni, mert itt dől el rengeteg félreértés. A figura/háttér (figure/ground) viszony nálam rendezőelv. Nem esztétika, hanem kontroll. Ahogy egy színpadon a reflektor, a kameraállás és a szereplők mozgása kijelöli, mi a főszál, úgy a promptban is kijelölöm, mi a figura és mi marad háttér.

A modell nem úgy “érti” ezt, mint egy ember, aki átéli a jelentést, hanem úgy, hogy súlyoz, rangsorol, és figyelmi mintákat alakít ki a bemenetből. Vagyis a figura nem attól lesz figura, hogy én annak érzem, hanem attól, hogy a promptban kap-e elég jelet, keretet és korlátot ahhoz, hogy a modell arra állítsa rá a figyelmét.

A váltakozás ott kezd izgalmassá válni, amikor ugyanaz az elem egyszer figurává lép elő, máskor háttérbe csúszik — attól függően, mire kérem a modellt. Egy üzleti szövegben például a hangnem lehet háttér, amíg a logikát, a szerkezetet és a döntési pontokat építem — aztán hirtelen figurává válik, amikor azt mondom: legyen feszes, jelenidejű, és ne legyen motivációs póz.

A prompton belüli elhelyezés és szerkezet azért számít ennyire, mert a figyelem nem egyenletes fény. Inkább reflektor. A reflektor ott erős, ahol a jelek összetartanak, és ott gyengül, ahol a szöveg szétterül. Ez különösen hosszabb bemenetnél fontos, mert a középre tett kritikus információ könnyebben elhalványul, mint az, amit jól kiemelsz és tiszta címkék alá rendezel.

Ezért használok tudatos fókuszváltást, mint rendezői instrukciót. Először kijelölöm a nagyképet — mi a háttér, mi a helyzet, mi a cél. Utána rázoomolok a figurára — konkrétan mit kell létrehozni, milyen formában, milyen határok között. Aztán kérek egy új nézetet ugyanarról: most a logika legyen figura, a stílus háttér — majd fordítva. Így nem engedem, hogy a díszletet kezdje elemezni, miközben én a főszereplő monológját várom.

Miből áll egy jó prompt? — terület, térkép, kényszer

A három réteg a promptolás gerincoszlopa. Nem “szép tagolás”, hanem az egyetlen módja annak, hogy a válasz a valóságból induljon ki, ne a modell koherenciaigényéből.

Terület

A terület réteg a nyers, megfigyelhető anyag. Konkrét szöveg, konkrét adat, konkrét hibaüzenet, konkrét idézet, konkrét paraméter. Ezt én bizonyítékként kezelem. A tipikus hiba az, amikor már itt címkézek, és azt írom: “ez biztos bug”, vagy “ez azért van, mert”. Ilyenkor a modell nem a bizonyítékon fog dolgozni, hanem a címkémet fogja igazolni.

Térkép

A térkép réteg az értelmezési keret. Definíciók, fogalmi határok, cél, sikerfeltétel, relevancia, kockázat, nézőpont. Én ezt nem “igaz vagy hamis” kategóriában kezelem, hanem “hasznos vagy használhatatlan” kategóriában — a célhoz képest. Ha a cél nincs kimondva, a modell választ magának egyet a tanult minták alapján, és ebből születik a gyönyörű, de rossz irányú válasz.

Kényszer

A kényszerek rétege nálam a szerződés. Formátum, terjedelem, hang, bizonytalanság jelölése, forráskezelés, tiltások, engedélyezett lépések, és a visszakérdezési protokoll. Ez az a rész, ami megfogja a fluenciát, mielőtt az igazság helyére ülne.

A szabály kimondása gyerekjáték, a megtartása öregmunka. Pont ezért érdekel a kényszer, mert nem az okosságot méri, hanem a valóságban futó viselkedést.

A rétegek jelölése — formátum nem ideológia

A rétegek különválasztása nálam taxonómiai fegyelem. A lényeg nem az, milyen formában címkézek — lehet Markdown, XML jellegű tagek, egyszerű kulcsszavas blokkok vagy bármilyen más jelölés —, hanem az, hogy a határok gépileg és emberileg is félreérthetetlenek legyenek.

Markdown blokk jelölés:

## Terület
- Repo: payments-service
- Jelenség: a prod checkout 2%-ban timeoutol, csak csúcsidőben
- Megfigyelés: az AI agent "javított" a retry logikán, de a p95 romlott

## Térkép
- Cél: gyors root cause és biztonságos rollback terv
- Siker: p95 normalizálása, hibaarány vissza 0,2% alá
- Releváns: időszoros metrikák, diff a deploy óta, agent döntési log

## Kényszerek
- Ne találj ki mérőszámot vagy logsort, csak a megadott területből dolgozz
- Ha hiányzik kritikus adat, kérdezz vissza legfeljebb 3 kérdésben
- A válasz előbb diagnózis, utána javaslat

XML jellegű jelölés:

<terulet>
  <project>ai-agent</project>
  <usecase>ügyfélnek megy jogi tájékoztató email</usecase>
  <anyag>az alábbi szerződésrészletből kell dolgozni: [beillesztés]</anyag>
</terulet>

<kenyszerek>
  <tiltas>ne adj jogi tanácsot, csak kockázati jelzéseket és kérdéslistát</tiltas>
  <jeloles>külön jelöld: tény, értelmezés, hipotézis</jeloles>
</kenyszerek>

A követelmény mindig ugyanaz: a határok élesek, a címkék egyértelműek, és semmi nem csúszik át a szomszéd rétegbe.

Milyen hibamódok rontják el a promptot?

A hibatérkép nem kérdések gyűjteménye, hanem egy rövid gondolati térkép arról, hol tud elcsúszni a válasz. Ez azért fontos, mert így nem érzésből javítok, hanem pontosan tudom, melyik réteghez vagy objektumhoz kell visszanyúlnom.

A hat leggyakoribb hibamód:

Hibamód	Mi történik	Melyik réteg érintett
Összefolyási hiba	A terület és a térkép összemosódik — a modell a címkét igazolja, nem a bizonyítékot dolgozza fel	Terület + Térkép
Kalibrációs hiba	Nincs kimondva, mi számít jónak — a modell rossz célra optimalizál	Térkép
Kényszerhiba	Hiányzó vagy ellentmondó szerződés — a válasz túl magabiztos és túl általános	Kényszer
Fókuszhiba	A figura és a háttér elcsúszik — a rendszer a díszletre válaszol, nem a lényegre	Figura/háttér
Sorrendhiba	Túl korán rögzül egy pálya — a későn érkező valóságteszt már nem korrigál	Műveleti sorrend
Terület-hiány	Kevés a bizonyíték — a modell kitöltéssel pótolja a hiányt	Terület

Ezek nem elméleti kategóriák. Ezek azok a csúszások, amiket napi szinten látok, és amelyeket a rétegek szétválasztásával szisztematikusan tudok kezelni.

A műveleti sorrend — miért nem mindegy, mit kérsz előbb

Sokáig azt hittem, hogy elég “jól kérdezni”. Aztán rájöttem, hogy a döntő kérdés gyakran nem az, mit kérek, hanem az, milyen sorrendben kérem. Ha én nem adok műveleti rendet, a modell ad magának — és a végeredmény sokszor szép lesz, csak nem ott lesz éles, ahol nekem kell.

Én ezért egy egyszerű futási rendet követek:

Először tisztázom, mi a nyers alapanyag
Utána kimondom, hogyan kell értelmezni — mi a cél, mi számít sikernek, mi releváns
Végül szerződést kötök a végrehajtásra — milyen formában dolgozzon, mit ne tegyen, és mikor kérdezzen vissza

Amikor ezt a sorrendet tartom, a fluencia a pontosság mögé kerül — nem a helyére.

Demonstráció — ugyanazok az elemek, más kockázat

Kockázatosabb sorrend — hamar “poszt üzemmódba” kapcsol:

Feladat: írj egy ütős posztot a promptolásról
Térkép: legyen lendületes, legyen benne a térkép/terület metafora
Terület: itt a nyers szöveg
Kényszerek: ne találj ki adatot, jelezd a bizonytalanságot

Biztonságosabb sorrend — előbb valóság és szerződés, utána generálás:

Terület: itt a nyers szöveg, és ez a két mondat maradjon benne biztosan
Kényszerek: ha nincs adat, feltételesen fogalmazz; hiányzó kulcsinfó esetén kérdezz vissza; legyen meg a terjedelem és szerkezet
Térkép: célközönség, sikerfeltétel, relevancia és kizárások
Feladat: írd meg a kimenetet a fenti területből, a kényszerekkel

A különbség nem szemantikai (nem a szavak mások) — hanem operatív (a modell másból építkezik először). Ez analóg a programozásban ismert eager vs. lazy evaluation (mohó vs. lusta kiértékelés) különbséggel: ha a rendszer túl korán kiértékel egy kifejezést, az eredmény más lesz, mint ha előbb összegyűjti az összes szükséges információt. A promptolásban az “eager” sorrend — feladat előbb, bizonyíték később — a fluencia csapdáját nyitja ki, mert a modell már azelőtt generálni kezd, hogy tudná, miből kellene dolgoznia.

Objektumok egy jól kidolgozott promptban

Ezt a listát én úgy rakom össze, hogy ha valaki bemásolja és kitölti, a sorrend már eleve egy jó futási rend legyen.

Kötelező elemek:

Szerep — milyen minőségben dolgozzon, milyen nézőponttal
Közönség — kinek szól a kimenet, milyen előismerettel
Terület — miből dolgozhat, mi az ellenőrizhető alapanyag
Térkép — mi a cél, mi a relevancia, mi a sikerfeltétel
Kényszerek — mit tehet és mit nem, bizonytalanságjelölés, tiltások, visszakérdezés szabálya
Kimenet — milyen artefaktum készüljön, milyen szerkezettel
Műveleti sorrend — milyen lépésekben haladjon, hol álljon meg
Minőségkritériumok — mi számít jónak, mi hibának, milyen ellenőrzést végezzen a végén
Feladat — az indító parancs: “most készítsd el a kimenetet a fentiek szerint”

Opcionális elemek:

Fókusz — mi legyen figura és mi háttér, mikor váltson fókuszt
Példák — jó és rossz minták, referencia stílus
Forráskezelés — milyen források elfogadhatók, hogyan hivatkozzon
Kockázat — elkerülendő hibák, reputációs és szakmai csapdák
Kalibráció — mi tény, mi következtetés, mi hipotézis
Iterációs protokoll — hogyan kérdezzen vissza, hogyan finomítson több körben

Hogyan debuggolok egy promptot?

A debug nem ott kezdődik, hogy visszakérdezek a modellnek, hanem ott, hogy van várható válasz térképem. Tudom, milyen típusú állításoknak kell megjelenni, milyen struktúrában, milyen fogalmak mentén, milyen evidenciákra támaszkodva, és hol vannak a piros zászlók. Ha ez a tacit tudás — Polányi Mihály kifejezésével: hallgatólagos tudás — nincs meg, akkor nem erőltetem a verifikálás üzemmódot.

Vagy vállaltan kreatív üzemmódban dolgozom — ahol nem az a kérdés, igaz-e, hanem az, hogy hasznos-e —, vagy előbb felépítem a mércét, és csak utána kérek ellenőrizhető választ.

A debug nálam minőségbiztosítási kapu. Arra való, hogy leválasszam a fluenciát az igazságról és a hasznosságról, és visszakössem a választ ahhoz a specifikációhoz, amit tényleg kértem. Itt jön a rétegezés igazi ereje: ha valami félrecsúszik, ritkán kell mindent újraírnom — elég azt a blokkot javítani, ahol a hiba keletkezett.

Patch protokoll — amikor javítok

Amikor javítok egy promptot, sokszor nem küldöm újra az egészet, hanem csak azt a réteget vagy objektumot, ahol a hiba keletkezett. Ezzel kímélem a kontextusablakot, és a javítás célzott marad.

A patch nálam három szabályt követ:

A változást felülírásként jelölöm, nem kiegészítésként
Kimondom, mi marad változatlan — csak a szükséges blokkot javítom, nem az egész promptot
Az új blokk önmagában is értelmes — nem hivatkozik arra, ami a korábbi verzióban volt

Két kivételnél óvatosabb vagyok:

Ha már hosszú a beszélgetés, és a régi definíciók, kényszerek vagy a terület elhalványulhatott
Ha a célon, a közönségen, a kimenet szerkezetén vagy a műveleti sorrenden változtatok — mert ezek átértelmezik az egész feladatot

Ilyenkor néha jobb egy tömörített, újra összefűzött prompt, mint egy patch.

A környezet, ami csendben alakítja a választ

A prompt nemcsak szöveg, hanem környezet is. Három dolgot külön figyelek:

Kontextusablak: A modell egyszerre csak véges mennyiségű szöveget lát, és hosszabb beszélgetésben a korábbi részletek fokozatosan halványulnak. Ha a beszélgetés hosszú, inkább patch-elek, vagy újrarögzítem a kritikus elemeket.

Rendszerüzenetek: A system prompt (rendszerszintű utasítás) és a felület beépített instrukciói gyakran erősebbek, mint amit én a felhasználói mezőbe írok. Rejtett szabályok is alakítják, mit “enged” a modell. Én ezért úgy írom a szerződést, hogy ne ütközzön a környezettel, ne feltételezzek olyat, amit a rendszer felülírhat — és ha valami furcsán viselkedik, először arra gyanakszom, hogy a háttérben van egy instrukció, amit nem látok.

Hőmérséklet és változatosság: A temperature (hőmérséklet) paraméter azt szabályozza, mennyire “merész” a modell a tokenválasztásban. Alacsonyabb értéknél a legvalószínűbb folytatást választja — ezért stabilabb, kiszámíthatóbb lesz a kimenet. Magasabb értéknél a kevésbé valószínű variációk is szóba jönnek, de ezzel nő a kitöltés és a konfabuláció (hamis emlékek/tények magabiztos állítása) kockázata is. Én ezt a feladat tétjéhez igazítom: ahol a pontosság számít, alacsonyra veszem; ahol explorációt kérek, engedek teret.

III. RAG pipeline és agent futtatás — amikor a strukturált prompt alapfeltétel

A cikkben eddig főleg egyetlen modellválasz körüli gondolkodásról beszéltem. Ott is számít a rétegzés és a sorrend, de sokszor még megúszható “jó kérdésekkel” és kézi javítással. RAG (Retrieval-Augmented Generation — visszakeresés-kiegészített generálás) pipeline és agent futtatás esetén ez a luxus megszűnik, mert már nem egy szöveget kapsz vissza, hanem egy folyamatot indítasz el. A folyamatnak állapota van, döntései vannak, mellékhatásai vannak — és hibái ott keletkeznek, ahol a végén észreveszed őket.

Ezért a prompt itt tényleg program. Nem metaforikusan, hanem operatívan.

A RAG mint terület-szolgáltató

A RAG egy egyszerű tényt tesz láthatóvá: a modell nem a valóságra lát, hanem a kontextusra, amit elé raksz. A RAG pipeline ezért nem “okosabbá teszi” a modellt, hanem területet ad a térképed alá. Vagyis a feladat nem az, hogy a modell szépen beszéljen, hanem az, hogy a rendszer jó bizonyítékot keressen, és azt jó sorrendben, jó keretben adja oda.

Ha itt nincs strukturált promptolás, akkor a legtipikusabb csúszás az, hogy a modell túl korán narratív pályára áll, majd a későn érkező forrásokat már csak “alátámasztásként” használja — vagy rosszabb esetben félreértelmezi, mert nincs kimondva, mi számít relevánsnak, mi számít tiltott következtetésnek, és milyen formában kell hivatkozni.

Három-négy kör — nem egy prompt, egy válasz

RAG pipeline esetén a legnagyobb váltás az, hogy ritkán létezik “egy prompt, egy válasz” működés. A megbízható futáshoz legalább három, gyakran négy külön kör kell — és ezek külön funkciójú futtatások:

Kör	Funkció	Hibamód, ha kimarad
1. kör	Kérdés tisztázása, térkép rögzítése — mit keresünk, mi releváns, mi a sikerfeltétel	A rendszer rossz kérdésre keres
2. kör	Retrieval előkészítése — lekérdezés átírása, kulcsfogalmak, szűrők, kizárások	Rossz terület jön vissza
3. kör	Válasz szintézise — a visszahozott területből, forrásfegyelemmel, tény és következtetés szétválasztásával	A modell tölti a hiányokat
4. kör	Verifikáció — a válasz visszaellenőrzése a területhez kötve, hiányzó információk és bizonytalanságok kimondása	Hamis magabiztosság

Ha ezt a többkörös rendet nem rögzíted, a rendszer túl hamar generálásba ugrik, és utána a saját koherenciáját védi — ezért RAG-ban a strukturált promptolás nem opció, hanem futtatási feltétel. Ezeket a köröket nem egyetlen beszélgetésben keverem, hanem külön szerepű promptokként futtatom, mert a retrieval előkészítés, a szintézis és a verifikáció más hibamódokra érzékeny.

Agent futtatás — ahol a kontrollvesztés valós

Az agenteknél még élesebb a helyzet, mert ott nemcsak válasz születik, hanem cselekvési lánc is. Egy agent tervez, eszközt használ, visszaellenőriz, majd újratervez, és közben folyamatosan állapotot kezel.

Ilyenkor a strukturálatlan prompt nemcsak pontatlanságot okoz, hanem kontrollvesztést:

Ha nincs világos műveleti sorrend, a rendszer magának választ sorrendet — és gyakran a “legkönnyebb” kimenet felé megy, nem a legbiztonságosabb felé
Ha nincs explicit kényszer arra, mikor kell megállni és visszakérdezni, akkor az agent úgy fog “haladni”, hogy közben kitölti a hiányokat — mert az előrehaladásra van optimalizálva, nem az igazságra
Ha nincs tisztázva, mi a terület és mi a térkép, akkor egy eszközből visszakapott részleges adatot könnyen teljes képpé fog emelni, és már fut is tovább a következő lépésre, mintha minden rendben lenne

RAG pipeline és agent futtatás esetén a strukturált promptolás a vezérlés nyelve. A rétegek biztosítják, hogy a rendszer tudja, miből dolgozhat és miből nem. A műveleti sorrend azt, hogy a rendszer mikor gyűjt bizonyítékot, mikor értelmez, mikor dönt, mikor generál, és hol van a minőségbiztosítási kapu.

Ha ezt nem mondod ki, akkor a fluencia nemcsak veszélyes lesz, hanem drága is. Drága, mert rossz dokumentumokra épít, rossz lépéseket futtat, rossz döntéseket automatizál — és te csak a végén látod, hogy elegáns volt, csak épp rossz.

A kibernetika réteg — a prompt mint szabályozás

A kibernetika ebben az esetben nem filozófia, hanem kontroll és kommunikáció. Egy rendszer akkor lesz megbízható, ha van érzékelése, van döntési szabálya, van beavatkozása, és van visszacsatolása. Agent futtatásnál ez szó szerint igaz:

Kibernetikai elem	RAG/Agent megfelelő
Szenzor	Retrieval — a környezet érzékelése
Figyelem állítása	Rerank — mi kerül a kontextusba
Beavatkozás	Generálás — a válasz vagy cselekvés
Visszacsatolás	Verifikáció — az eredmény visszaellenőrzése

Ebben a képletben a prompt nem szöveg, hanem kontrolltérvény, és a strukturált promptolás nem “jobb kommunikáció”, hanem a szabályozás feltétele. Ha a kontrolltérvény nincs kimondva, a rendszer is szabályoz — csak a saját belső valószínűségi dinamikája szerint, és ezt te ugyanúgy megkapod elegáns kimenetként, csak épp rossz pályán.

Ashby törvénye a promptolásban

W. Ross Ashby “szükséges változatosság törvénye” (law of requisite variety) azt mondja: egy szabályozó csak akkor tud stabilan irányítani, ha belső változatossága legalább akkora, mint a környezet zavarai.

RAG és agent esetén a “zavar” az ambiguitás (többértelműség), a hiányos terület, a rosszul indexelt tudás, a félreérthető cél, és az, hogy a modell szép koherenciára törekszik akkor is, amikor kevés a bizonyíték. A több kör — a három vagy négy külön szerepű prompt — valójában ezt a belső változatosságot teremti meg:

Az első kör tisztáz
A második kör jó területet szerez
A harmadik kör forrásból szintetizál
A negyedik kör visszacsatol és újrakérdez, ha kell

Ezt nem lehet egyetlen promptba “összegyúrni” úgy, hogy közben ne nyíljon ki a hibamódok kapuja, mert a fázisok másfajta fegyelmet és másfajta tiltást igényelnek. Ahogy Ashby megfogalmazta az Introduction to Cybernetics (1956) című munkájában: a szabályozó komplexitása nem luxus, hanem szükséges válasz a szabályozott rendszer komplexitására. Ha egyszerűsítesz, nem hatékonyabb leszel, hanem vakabb.

Miért olyan nehéz jó promptot írni?

Polányi Mihály mondta: “Többet tudunk, mint amennyit el tudunk mondani” (“We know more than we can tell”). Ez a promptolás rejtett nehézsége. Nem azért rossz a prompt, mert az ember buta, hanem mert a legtöbb döntési szabály, ami alapján dolgozunk, hallgatólagos — és csak működés közben derül ki, mi is volt a valódi sikerfeltétel.

Gondolj bele: amikor egy tapasztalt mérnök átnéz egy pull requestet, azonnal “érzi”, hol van a probléma. De ha megkéred, fogalmazza meg előre a szabályait, amiket követ — az esetek többségében nem tudja. Ezek a szabályok a tapasztalatba vannak beágyazva, és csak a konkrét kontextusban aktiválódnak. A promptolás nehézsége pontosan ez: olyan döntési szabályokat kell explicité tennem, amelyek bennem hallgatólagosan működnek, de a modell számára nem léteznek, amíg ki nem mondom őket.

A strukturált promptolás pont erről szól: a tacit döntési szabályokat kitesszük a térbe, és azt mondjuk — ez legyen a szerződés. Ez az, amit a SECI modell (Nonaka és Takeuchi tudáskeletkezési modellje) “externalizáció”-nak nevez: a belső, kimondatlan tudás explicit formába öntése. A SECI négy fázisa — szocializáció, externalizáció, kombináció, internalizáció — közül a promptolás az externalizáció legtisztább formája: azt csinálom, hogy a fejemben lévő, működő, de szavakba nem öntött tudást struktúrává alakítom, amit a gép is feldolgozhat.

RAG és agent helyzetben ez még élesebb, mert ott a tacit tudás hiánya nemcsak rossz választ ad, hanem rossz lépéseket indít el. Ha nem mondom ki, mi számít relevánsnak, a retrieval rossz dokumentumokat húz be. Ha nem mondom ki, mikor kell megállni, az agent kitölti a hiányt és tovább megy. Emiatt a rétegzés nem adminisztráció, hanem externalizáció — a belső mércék kivitele a rendszer elé.

Függelék — többkörös prompt példák

Az alábbi példák nem sablonok, hanem működési minták. Mindhárom ugyanazt a mintázatot követi: a kontextus egyszer rögzül, a fókusz menetnként változik, a kényszerek menet-specifikusak.

Példa 1: CMO tartalomstratégia — diagnózistól végrehajtásig

Kontextus (egyszer rögzítve):

Szerep: B2B SaaS tartalomstratéga
Közönség: CMO és marketing vezetés, akik ROI-ban és pipeline-ban gondolkodnak

Terület:
- Csatornák: LinkedIn (12k követő), blog (8k/hó organikus), hírlevél (4k feliratkozó)
- Tartalom: heti 2 blogposzt, heti 3 LinkedIn, havi 1 webinar
- Mérés: GA4 + HubSpot, attribúció last-touch
- Erőforrás: 1 content lead, 1 junior író, agentura grafika
- Probléma: sok tartalom, kevés SQL, a sales "nem jó leadeket" kap
- Cél: Q3-ra 30%-kal több SQL ugyanakkora büdzséből

Térkép:
- Döntés: mit állítsunk le, mit skálázzunk, mit változtassunk formátumban
- Sikerfeltétel: konkrét akcióterv, nem "érdemes lenne tesztelni"
- Relevancia: SQL-hatás, erőforrás-fit, mérhetőség

1. menet — DIAGNÓZIS MINT FIGURA:

Fókusz:
- Figura: a diagnózis — hol szakad el a tölcsér, miért nem lesz SQL a forgalomból
- Háttér: a megoldás — még ne javasolj, előbb értsd meg a hibát
- Háttér: a csatornaválasztás és a formátum

Kényszerek:
- Ha a területből nem derül ki valami, kérdezz vissza (max 3 kérdés)
- Ne adj még megoldást, csak diagnózist
- Max 300 szó, struktúra: tünet → hipotézis → hiányzó adat

Kimenet: diagnosztikai térkép: traffic-to-MQL | MQL-to-SQL | tartalom-illeszkedés | attribúciós vakfolt

2. menet — STOP-START-CONTINUE MINT FIGURA:

Fókusz:
- Figura: a döntés — mit állítsunk le, mit indítsunk, mit tartsunk meg
- Háttér: a diagnózis — ismertnek tekinthető
- Háttér: az implementáció részletei

Kényszerek:
- Minden "start" mellé becsült erőforrásigény
- Minden "stop" mellé kockázat (mi veszhet el)
- Táblázatos kimenet, majd 2 mondatos priorizálás

3. menet — 90 NAPOS TERV MINT FIGURA:

Fókusz:
- Figura: a végrehajtás
- Háttér: a stratégiai döntés — hivatkozz rá, ne indokold újra
- Háttér: a csapat számára szól — ki mit csinál, mikorra

Kényszerek:
- Heti bontás az első 4 hétre, havi bontás utána
- Mérföldkövek SQL-hez kötve, nem activity-hez
- Max 250 szó + ütemterv táblázat

A minta világos: a kontextust egyszer rögzíted, a fókuszt mentetenként váltod (mint egy rendezői instrukciót), és a kényszerek mindig a menet céljához igazodnak — nem az egész feladathoz.

Példa 2: SRE Incident Post-Mortem — root cause-tól action item-ig

Kontextus (egyszer rögzítve):

Szerep: Senior SRE / engineering lead, aki production incidensek root cause elemzését vezeti
Közönség: Engineering leadership és on-call csapat

Terület:
- Érintett: ~3200 tranzakció, becsült revenue loss €47k
- Közvetlen ok: adatbázis connection pool kimerülés
- Környezet: PostgreSQL 15 (primary + 2 read replica), PgBouncer, Kubernetes
- Előzmény: előző nap deploy, új retry logic a payment service-ben
- Detektálás: PagerDuty alert 14:38, customer support eszkaláció 14:41
- Helyreállítás: PgBouncer restart + payment service rollback

1. menet — ROOT CAUSE LÁNC MINT FIGURA:

Fókusz:
- Figura: a root cause lánc — mi okozta mit, hány réteg mélyen
- Háttér: a helyreállítás és a timeline — ismert
- Kizárva: a "ki hibázott" — blameless

Kényszerek:
- 5 Whys formátum vagy ok-okozati lánc
- Különítsd el: trigger vs. enabling condition vs. systemic gap
- Ha a területből nem egyértelmű valami, jelöld "[hiányzó adat]"
- Max 300 szó

Kimenet: cause chain diagram szövegesen: trigger > enabling > systemic

2. menet — DETECTION GAP MINT FIGURA:

Fókusz:
- Figura: a detection gap — miért nem vettük észre hamarabb
- Háttér: a root cause — ismertnek tekintendő
- Háttér: a fix — még nem ide tartozik

Kényszerek:
- Időablak: deploy és alert között mi történt (vagy nem történt)
- Milyen metrika, alert vagy teszt fogta volna meg korábban
- Max 200 szó, struktúra: gap > ideális detektálás > hiányzó layer

3. menet — ACTION ITEMS MINT FIGURA:

Fókusz:
- Figura: az action items
- Háttér: root cause és detection gap — hivatkozz rájuk
- Háttér: a csapat számára szól — ki mit csinál, mikorra, milyen definícióval kész

Kényszerek:
- Max 5 action item, priorizálva
- Minden item: owner | határidő | definition of done
- Különítsd el: hotfix (1 hét) vs. systemic fix (1 hónap) vs. cultural/process (3 hónap)
- Táblázatos kimenet

A saját META-rétegem

Én ezt a “kényszer alapú” gondolkodást nem azért szeretem, mert “korlátoz” — hanem mert felszabadít. A kényszer nálam nem büntetés, hanem valóságteszt — egy olyan védőkorlát, ami megfogja a szétesést még azelőtt, hogy szétesésnek nevezném.

Promptban ez azt jelenti, hogy kimondom: miből dolgozhatunk, mi a cél, mi számít sikernek, és hol kell megállni visszakérdezni. Az életben pedig ugyanaz történik — csak más anyagból: figyelemből, időből, testből, döntésekből.

A Neural Awarenessben én ezt így fogalmazom meg: a tudat nem attól lesz tiszta, hogy “szabadon áramlik”, hanem attól, hogy van egy vállalásod, egy fókuszod, egy határod — és ezek együtt kijelölik, mi a figura és mi a háttér. A kényszerek nem elvágják a lehetőségeket, hanem keretet adnak annak, hogy egyáltalán észrevegyem, mit akarok, és mikor beszélek csak szépen, mikor pedig pontosan.

Ezért érzem azt, hogy a jó promptolás nem technika, hanem gyakorlás — ugyanaz az izom dolgozik bennem, mint amikor nem a szerep vezet, hanem a jelenlét.

A szabályok stabilizálnak, de nem helyettesítik a gondolkodást. A compliance nem meglátás, az ellenőrzőlista nem realizáció.

Zárás — a jéghegy csúcsa

Amit itt leírtam, az a jéghegy csúcsa. Szándékosan leegyszerűsített térkép, ami a legfontosabb mintázatokat mutatja, de messze nem a teljeset.

Ami kimaradt — a teljesség igénye nélkül:

Beszélgetés és kontextus — a többkörös dinamika, ahol a kontextus épül és kopik, a rendszerüzenet és felhasználói kérés közti hierarchia, a kontextusablak menedzselése hosszú munkamenetekben
Gondolkodtatás és tanítás — a lépésről lépésre következtetés kikérése, a példaalapú kalibráció jó és rossz mintákkal, a személyiség és szerep hatása a hibamódokra
Formátum és struktúra — a strukturált kimenet kényszerítése (JSON, táblázat, séma), a multimodális promptolás, ahol kép és szöveg együtt dolgozik, a hibakezelés beépítése
Rendszer és szervezet — az ágensszerű végrehajtás, ahol a prompt futtatható terv lesz, a promptok verziókezelése és tesztelése, a csapatban végzett promptolás, ahol a közös nyelv válik szűk keresztmetszetté

És végül az, ami a legkevésbé technikai, de talán a legfontosabb: a saját gondolkodásom tisztázása — mert a legjobb prompt is csak annyira lehet jó, amennyire én tudom, mit akarok.

A rétegek megmondják, mi van a kezemben. A sorrend megmondja, miből építkezik először a modell — és ezzel kijelöli, mi lesz a figura és mi marad háttér. Amikor ezt a kettőt együtt kezelem, a válaszaim nemcsak szebbek lesznek, hanem megbízhatóbbak is. És közben azt is észreveszem, hogy a tisztább promptolás nem csak a gépet irányítja jobban — hanem engem is.

A mondatok egyszer csak nem díszek lesznek, hanem ajtók.

Kulcsgondolatok

A promptolás nem stílus kérdése — hanem a gondolkodás rendezettségének operatív megjelenése
A három réteg (terület, térkép, kényszer) nem tagolási javaslat, hanem annak a biztosítéka, hogy a válasz a valóságból indul ki
A sorrend dönti el, miből építkezik először a modell — és ezzel azt is, mi lesz a figura és mi a háttér
A hat hibamód (összefolyási, kalibrációs, kényszer-, fókusz-, sorrend-, terület-hiány) szisztematikusan felismerhető és javítható
RAG pipeline és agent futtatásnál a prompt nem metafora — hanem futtatható specifikáció
A kibernetikai modell (szenzor → figyelem → beavatkozás → visszacsatolás) leírja, miért szükséges a többkörös vezérlés
A tacit tudás externalizációja — a hallgatólagos döntési szabályok kimondása — a promptolás legmélyebb és legnehezebb rétege

GYIK

Mi a különbség a “jó prompt” és a strukturált prompt között?

A “jó prompt” általában azt jelenti, hogy ügyesen fogalmazol. A strukturált prompt azt jelenti, hogy szétválasztod a funkciókat — terület, térkép, kényszer — és tudatos sorrendben adod oda őket. Az első intuícióra épül, a második mérnöki fegyelemre. Az első néha működik, a második megbízhatóan működik. A különbség ott válik láthatóvá, amikor nem egy választ kérsz, hanem egy folyamatot futtatsz — RAG pipeline-ban vagy agent keretben.

Miért fontos a sorrend, ha a tartalom ugyanaz?

Mert a modell nem “érti” a szöveget, hanem mintákat illeszt és súlyoz. Ami hamarabb érkezik, az erősebben formálja a pályát. Ha a feladat és a hang hamarabb érkezik, mint a bizonyíték és a tiltás, a modell hamar “generálás üzemmódba” kapcsol, és a később érkező kényszerek már kevésbé fogják meg. Ez nem bug, hanem a rendszer működési elve — és pont ezért szükséges a tudatos sorrend.

Kell-e struktúrálni a promptot, ha csak egy egyszerű kérdést teszek fel?

Nem feltétlenül. A cikk a haladó használatról szól, ahol az eredmény minősége és megbízhatósága számít. Egyszerű kérdéseknél — “hány lakosú Budapest?” — nincs szükség rétegzésre. De amint a feladat nem triviális, amint van célközönség, sikerfeltétel, és a fluencia nem helyettesítheti az igazságot, a strukturálás nem választás, hanem feltétel.

Kapcsolódó gondolatok

A gondolat architektúrája — promptolás mint gondolkodási tükör — hogyan épül fel az, amit gondolkodásnak hívunk, és miért számít a keret jobban, mint a tartalom
Contemplative RAG: Meditáció + Adatbázis — a figyelem-irányítás és a kontextus-ablak menedzsment mint strukturálisan azonos rendszer
A metakognitív forradalom — a gondolkodásról való gondolkodás mint az utolsó emberi versenyelőny

Key Takeaways

A hatékony promptolás nem stílusgyakorlat, hanem gondolkodási fegyelem, ahol a gondolkodás rendezettsége meghatározza a prompt szerkezetét. Ahogy a cikk is rámutat, ez a fegyelem nemcsak a gépet irányítja jobban, hanem saját döntéshozatalunkat is.
A promptnak három elkülönülő réteget kell tartalmaznia: terület (nyers bizonyíték/adat), térkép (értelmezési keret) és kényszer (végrehajtási feltételek). Ha ezek összemosódnak, a modell a saját koherenciáját védi, nem a valóságra válaszol.
A rétegek sorrendje kritikus: a feladat és a hang megadása előtt mindig elő kell vinni a bizonyítékot és a tiltásokat. Ellenkező esetben a modell fluenciája (szép, összefüggő szöveg) az igazság helyére ül.
RAG (Retrieval-Augmented Generation) pipeline-ok vagy agentek futtatásakor a strukturált prompt nem opció, hanem futtatási feltétel. Itt nem egy választ kapsz, hanem egy teljes folyamatot indítasz el, amihez szükséges a precíz irányítás.
A modellt ne úgy kezeld, mint egy szándékot olvasó partnert, hanem mint egy hajlamos félreérteni, de együttműködő rendszert. A cél nem az, hogy “érezze, mire gondolsz”, hanem hogy az általad megadott szigorú kereteken belül hajtson végre feladatot.
A cikkben említett “Prompt Jam” vagy “rezonancia játék” módok kreatív eszközök lehetnek, de tudatosan el kell különíteni őket a precíziót igénylő munkától. Ezekben az üzemmódokban az érték az asszociáció és a flow, nem a tényleges pontosság.

Varga Zoltán - LinkedIn
Neural • Knowledge Systems Architect | Enterprise RAG architect
PKM • AI Ecosystems | Neural Awareness • Consciousness & Leadership
Territory. Map. Constraint. In that order — or the fluency eats the truth.