Amikor a mesterséges intelligencia buta hibákba ütközik

Van egy különleges típusú frusztráció, amit csak az ért meg, amikor egy intelligens rendszer nyilvánvalóan ostoba okokból bukik el. Nemrég épp ezt tapasztaltam, miközben helyi AI kódoló agentekkel kísérleteztem – ez a terület egyre jobban felkapott, ahogy az open-weight modellek egyre kompetensebbé válnak, és egyre fontosabbá válik a privacy-first hozzáállás a fejlesztésben.

A kísérlet egyszerűnek tűnt: vajon egy teljesen helyi hardveren futó coding agent képes-e egy működőképes játékot építeni? Nem valami triviális demót, hanem olyasmit, ami valódi state managementet, renderelési logikát, input kezelést és játszható felületet tartalmaz. A válasz, némi fejvakargatás után, igen lett – de az odáig vezető út olyan problémákat tárt fel, amelyekkel az AI eszközök ökoszisztémája egyelőre nem boldogul szépen.

A felállás, ami működnie kellett volna

A stack három komponensből állt, amelyek a helyi AI fejlesztés élvonalát képviselik: egy provider-agnosztikus coding agent CLI, az Ollama, ami OpenAI-kompatibilis API-t szolgáltat ki a localhostról, és a Qwen3.8 27B, ami a helyi gépen fut. Kontextusként: ez nem egy alulméretezett felállás – a 27B-s modell 17 gigabájtban kényelmesen elfér a 32 gigabájtnyi unified memory-ban, és tisztességes reasoning képességekkel támogatja a tool callinget.

Az első eredmények ígéretesek voltak. Tizenöt perc alatt az agent legenerálta a teljes HTML struktúrát és csaknem 200 sor NES-stílusú CSS-t beveled cabinet stylinggal és megfelelő színpaletával. Még lenyűgözőbb volt, hogy az agent saját magát javította ki menet közben: írt egy fájlt, visszaolvasta, észrevette, hogy nem az landolt a diskre, amit szeretett volna, majd javította hibátlanul, emberi beavatkozás nélkül. Ez már valódi agentic behavior, és azt sugallta, hogy a modell megbirkózik a feladattal.

Aztán az agent megpróbálta megírni a játéklogika fájlt, és minden megállt.

A halálspirál

Amit ezután láttam, azt bárki felismeri, aki már küzdött AI eszközökkel. Tizenhárom egymást követő kísérlet a game engine fájl megírására, mindegyik félúton megszakadt. A generálás egyszerűen meghalt – hibaüzenet nélkül, magyarázat nélkül, használható output nélkül.

A legbosszantóbb az nem maga a hiba volt – hanem az agent reasoning folyamatának figyelése. Mivel minden kísérlet tiszta lappal indult, a modell újra és újra nulláról vezette le ugyanazokat a tervezési döntéseket, és minden alkalommal más és más pontozási táblázatokkal és implementációs megközelítésekkel állt elő. Három újrapróbálkozás = három különböző válasz ugyanarra az architektúális kérdésre. Az agent egy órányi gondolkodást végzett, és egyetlen sort sem szállított.

Az egyértelmű gyanúsított a memórianyomás volt. Böngészőtabok bezárásával felszabadult néhány gigabájt RAM, és némileg javultak a dolgok – ami megerősíteni látszott a diagnózist. De ez volt a rossz tanulság.

Amit a logok valójában mutattak

A server logok visszanézése egészen más történetet mesélt. Egyetlen out-of-memory hiba sem volt egyikben sem. A szabad rendszermemória kényelmesen 21 és 27 gigabájt között mozgott a 17 gigabájtos modell-footprint mellett. A memória soha nem volt a probléma.

A valódi probléma egy konfigurációs eltérés volt, ami semmilyen látható hibát nem generált. Az agent configja 32,768 tokenes context windowt hirdetett. De az Ollama servert újraindították 8,192 tokenes plafonnal, és ez az eltérés észrevétlen maradt. Az agent boldogan tervezett meg egy 800 soros fájlt egyetlen menetben, mert – legalábbis ami őt illette – 32k headroomja volt. Amikor a tényleges generálás elérte a 8k falat mid-tool-call, a kapcsolatot minden hibaüzenet nélkül bontották el – olyasmi, amiből az agent nem tudott tanulni.

Egy másodlagos szövődmény lapult még a startup logokban: az Ollama context-shifting engedélyezésével indult, ami lehetővé tette volna, hogy az ablak csússzon, ha elfogy a hely, feláldozva a régebbi tokeneket az újok kedvéért. De a modell architektúrája nem támogatta ezt a funkciót, szóval csendben letiltották. Ami egy puha limitnek kellett volna lennie, az egy kemény fallá vált.

A DevOps fegyelem, amit az AI fejlesztés megkövetel

Ez a tapasztalat kristályosít valamit, ami fontos a helyi AI fejlesztésben, és amit az open-weight modellek körüli lelkesedés hajlamos eltakarni. Amikor a saját hardvereden futatsz modelleket, nem csak kódot írsz – infrastruktúrát üzemeltetsz. És az infrastruktúra ugyanazt a diagnosztikai fegyelmet, konfigurációmenedzsmentet és operatív paraméterekre való odafigyelést igényli, amit a production rendszerektől elvárunk.

A context windowk nem absztrakt modell-tulajdonságok, amiket beállítasz és elfelejtesz. Operatív paraméterek, amelyek a tool chainjével nem-triviális módon interakcióba lépnek. Amikor egy agent configured contextje nem egyezik a server tényleges plafonjával, nem kapsz figyelmeztetést – csak csendes hibákat, amelyek modell-inkompetenciának tűnnek, miközben valójában operatív félrekonfigurációról van szó.

A gyakorlati tanulság azoknak a fejlesztőknek, akik helyi AI coding agenteket fedeznek fel: validáld a környezetedet éppolyan alaposan, mint egy production deploymentet. Ellenőrizd, hogy az agent konfigurációja egyezik-e a runtime paramétereiddel. Olvasd a server logokat, ne csak az agent outputját. Értsd meg, hogy a modell architektúrája ténylegesen milyen funkciókat támogat – és melyeket csak a tooling próbál engedélyezni.

A modellek egyre jobbak lesznek. A tooling érik. De a "demosban működik" és a "mindennapi használatban megbízhatóan működik" közötti szakadékot továbbra is emberi ítélőképesség hidalja át – és ez az ítélőképesség nagyon hasonlít a hagyományos DevOps fegyelemre, csak egy új infrastruktúra-osztályra alkalmazva.

A Tetris build végül sikerült. Négy és fél óra alatt, két nap alatt, három fájlban tiszta kódot produkálva, és helyesen működik. De a leckék nem a sikerből jöttek, hanem abból, hogy megértettük, miért történt a hiba – és felismertük, hogy néha a legdrágább problémáknak semmi közük az intelligenciához.