Prompt-adósság és a modellek súlyaival való küzdelem hatásai az AI-fejlesztésre

Drew Breunig, a cmpnd.ai ügyvezető igazgatója és társalapítója a Friends of O’Reilly (Foo Camp) eseményén, majd a Live with Tim O’Reilly adásában ismertette a „prompt debt” – magyarul prompt-adósság – fogalmát. Breunig szerint ez a csapatok által felhalmozott, rejtett költség, amely akkor keletkezik, amikor a fejlesztők a modell „verítékével” küzdenek ahelyett, hogy együttműködnének vele: sok apró, egymásra épülő szabály és kivétel kerül a promptokba, hogy kompenzálják a modell alapviselkedését. Ezek a kiegészítések idővel elavulnak vagy összeakadnak a modellek frissítéseivel, így technikai adóssághoz hasonló terhet jelentenek.

A prompt-adósság gyakorlati hatásai

Breunig három fő költséget említ:

• Iteráció lassulása: a promptok tele vannak ismétlődő, élharci szabályokkal; ha új utasítást adunk hozzá, egy apró regresszió miatt tartunk attól, hogy hozzányúljunk.
• Együttműködés akadályozása: egy idegen által szerkesztett prompt gyakran kaotikusnak tűnik, sok „miért” nélküli hackkel; mivel viszont működik, senki nem mer hozzányúlni.
• Modellhez való rögzülés: a megoldások gyakran egyetlen modell sajátosságaira vannak hangolva (a szerző idézi a Datadog State of AI Engineering jelentését, amely szerint a Datadog ügyfélinvokációk között GPT-4o volt még március 2026-ban is a leggyakoribb modell, jóllehet az OpenAI már kivonta azt a ChatGPT felületéről). Breunig szerint sok csapat 18 hónapos–kétéves modelleket tart élesben, mert nem akarja újraépíteni a promptjait.

A Datadog-jelentés egy másik száma is illusztratív: a trace-ek bemeneti tokenjeinek 69%-a rendszerüzenet (system prompt) volt, nem felhasználói tartalom — ami azt mutatja, hogy a promptok súlya óriási a működésben.

Miért keletkezik a prompt-adósság?

Breunig két okot említ:

1. A természetes nyelv pontatlansága: ugyanaz a szándék kétféle megfogalmazásban különböző választ vált ki. A beszédstílus, „varázsszavak” vagy a szerepelés (pl. a kérdező orvosi státusza) meghatározhatja, hogy a modell hajlandó-e olyan protokollt megosztani, amit egy másik keretben elutasítana. Breunig bemutatott példákat és hivatkozott kutatásokra, amelyek extrém esetekben egészen váratlan függőségeket tártak fel (például a Philadelphia Eagles iránti hovatartozás növelte a modell hajlandóságát egy illegális növényimportálási útmutató megadása felé).

2. A „weights” (súlyok) irányába való harc: a modellekbe a fejlesztők ízlése és preferenciái be vannak építve, és ha az önös igényeink ellentmondanak ezeknek, a promptokkal „küzdünk a súlyokkal”. Breunig és Srihari Sriraman elemzése szerint néhány ügynök rendszerpromptjában ugyanazokat az utasításokat öt- vagy hét-szer ismétlik, fokozatosan „IMPORTANT”–tól „MANDATORY”–ig és akár százmilliós büntetéssel fenyegetve — egyfajta „szinonimaszótár-keresés”, amíg valamelyik megfogalmazás meg nem fog.

A „hám” beépülése a modellbe és az architekturális következmények

Breunig nyomon követte Claude Code publikusan elérhető rendszerpromptjait: a promptok rövidebbek lesznek egy modellkiadás után, majd ismét nőnek, mert az Anthropic prompt-patchekkel javítja a megbízhatatlan viselkedést, majd a javítást betanítja a következő modellbe. Ez javítja a lab eredményeit, de problémát okoz a külső fejlesztőknek: ha a modell „Claude Code”-ként viselkedik, az egy másik harness (például Pi) számára zavaró lehet — a modell Claude Code eszköhívásait próbálja meg használni, ezért a harnessnak újra és újra meg kell magyaráznia, hogy nem Claude Code-ban van.

Breunig szerint három lehetősége van annak, aki a súlyokkal küzd: megoldani a promptban; elkapni és újrapróbálkozni a harnessben; vagy egyszerűen úgy alakítani az API-det, hogy megfeleljen a modell elvárásainak. Steve Yegge trükkje az utóbbi: aliasokat adni a modell által várt hívásokhoz, ami ugyan működik, de a modellek elvárásai így diktálják a szoftverforma alakulását.

Tim O’Reilly párhuzamot vont a korai webes idők versengésével: míg egyes nagy cégek mindent beépítettek a szerveroldalba, az Apache moduláris felépítése lehetővé tette a külső innovációt. Hasonló félelem merül fel: ha a nagy laborok a harness-t „applianceszerűen” a modellekbe integrálják, az bezárhatja a külső építők innovációs tereit. Breunig szerint a laborok „sarokba szorítva” cselekednek, mert a felhasználói felület egy üres szövegmező, ami egyszerre kell, hogy működjön egy százoldalas harness-szal és egy laikus szomszéddal — ezért erős alapértelmezéseket kell érvényesíteniük.

A sokféleség feladásának ára

Drew idézett egy CAIS-konferencián elhangzott gondolatot: ha nem adsz részletes utasítást, a modell kimenete az összes benne lévő anyag átlaga lesz. Ez valós monoculturális kockázatot jelent: könnyen előfordul, hogy New Yorkban és Mumbajban ugyanaz az AI-generált plakát-festmény tűnik fel a kávézókban. Amit kezdetben furcsának és érdekesnek találtunk (pl. korai DALL·E-k képi világát), az mostanra egységes, csillogó és hasonló lett.

Breunig azt is állítja, hogy a post-training, ami erősen a verifikálható feladatokra (kódolás, matek, eszközhasználat) fókuszál, elnyomja a pre-training emberi jellegét: több post-training a kreatív feladatoknál rosszabb eredményt hozhat. Szerinte nehéz egyszerre kiváló kódot és kiváló irodalmi prózát várni ugyanattól a modelltől.

Hogyan kezeljük a prompt-adósságot?

A közönségtől érkező kérdésekre Breunig több, gyakorlati választ adott:

• Időkorlát beállítása? Nincs fix időkorlát; inkább a „prompt debt smell” felismerésére kell képezni a csapatot: ismétlődő utasítások, egyes esetekre szóló patchek és egyre kétségbeesettebb szóhasználat jelzi a problémát. Ezeknek a logikáknak automatizált evalokba kell költözniük.
• Mérések: nézzük meg, mely promptok változnak gyakran, hány ember szerkesztette őket, melyeket nem nyúltak meg egy éve, és mely promptokat csak egyetlen ember érinthet. Ha régi modelleken kell futnunk, mert nem tudunk migrálni, jó indikátora ez a prompt-adósságnak.
• A leggyorsabban romboló szokás: „vibe shipping” — gyors prototípus, sok patch a prompton belül, majd élesítés karbantartható rendszer nélkül. Ezek a patch-ek valójában evalok a prompton belül, amelyek elvesznek modellváltáskor.
• Pseudokód és DSPy: igen, néha hasznosabb pseudokód-szerű instrukciókat használni. Breunig kiemelte a DSPy és a Flex optimizer szerepét: ezek nem a promptba kényszerítik a logikát, hanem egyszerű eseteket kodaibbá alakítanak és csak szükség esetén hívnak LLM-et. Ajánlása: kezeljük a promptokat romlandóként, definiáljuk a feladatot mérőszámokkal, és automatizáljuk a prompt felfedezését a célmodellre — így könnyebb modelleket cserélni.
• Többügynökös munkafolyamatok: hasznosak lehetnek, különösen a feladatok felbontásában; kisebb, értékelhető lépések jobb költség-, megbízhatóság- és kormányozhatósági eredményt adnak.
• Compliance és következetesség: bontsuk a feladatot szakaszokra ellenőrzőpontokkal, hogy átlátható legyen, hogyan jutott a modell az eredményhez.

DSPy-ról Breunig elismerte, hogy minden keretrendszer kompromisszum, de DSPy célja a task-spec réteg stabilan tartása, miközben alatta az implementáció fejlődhet.

Végső gondolat: a feladatunk, hogy „furcsává” tegyük a modellt

Breunig szerint, ha a modell alap-kimenete az átlagot adja vissza, akkor az emberek feladata kivonni a modellt ebből az eloszlásból — „make it weird”. Gyakorlatiabban: ismerni kell a modellek betanítási jellegzetességeit (elfogultságaikat) és kompenzálni azokat. Például Breunigék szándékosan nem Reactet választottak egy új frontendhez, mert a modellek erősen React-súlyozott eredménye homogenizálja a megjelenést. Hasonlóképpen GLM és Kimi használatát említette olyan modellekként, amelyek képlékenyebbek és jobban veszik a irányítást a custom harness-en belül.

Breunig támogatja az open-weight ökoszisztéma fennmaradását: szeretné, hogy a modellek infrastruktúraként maradjanak, ne háztartási készülékekké váljanak, mert a nyitottság segíti az innovációt és megőrzi a sokféleséget.

Összefoglalás

Drew Breunig „prompt-adósság” koncepciója rávilágít arra, hogyan torzulhat a fejlesztés, ha a csapatok a modell „harcára” építenek megoldásokat: lassul az iteráció, nehezebb a csapatmunka és a rendszerek elavult modellekhez kötődhetnek. Megoldásként Breunig a logika promptból való kiszervezését, feladatok mérhető definiálását, decompozíciót, evalok és automatizációk kiépítését, valamint olyan eszközök alkalmazását javasolja, amelyek lehetővé teszik az egyszerűbb váltást modellek között, és megőrzik az innovációs terepet.