A memóriakimerülési összeomlás, amely egy folyamatjelzőben lapult

Szeptember egyik estéjén a felhasználó munkaterületén az AI-ügynök egy kör közepén memóriakimerülési hibával állt le. A kézenfekvő gyanúsítottak — túl sok al-ügynök egyszerre, vagy túl nagyra nőtt kontextus — mindketten tévesnek bizonyultak. Az igazi ok egy állapotcímke volt: amíg a modell egy nagy shell-parancsot streamelt néhány karakterenként, minden darabnál újraküldtük a parancs addigi egész szövegét folyamatjelzőként. Egy 124 KB-os parancsból körülbelül 41 000 esemény és nagyjából 690 MB sorban álló szöveg lett.

Hogyan streamel az ügynök

A Mythexen építkezve az ügynök a projekted privát felhő-sandboxában fut. Ahogy a modell ír, a kimenete a böngésződbe streamelődik: a szöveg szavanként jelenik meg, és amikor eszközt futtat — mondjuk egy fájlt író shell-parancsot —, egy hozzá tartozó címke élőben frissül, így látod, mit csinál.

A modell kis darabokban streamel. A használt modellnél ezek gyakran mindössze három karakter hosszúak voltak.

Az első feltevések tévesek voltak

Az összeomlás skálázási problémának látszott, ezért ott kezdtük.

• Párhuzamos al-ügynökök? A körben csak kettő volt, egyenként körülbelül 1,5 MB állapottal. Ez nem elég.
• Megtartott nyomkövetés? A nyomkövetésünk egy futási fát tartott a memóriában, de ez messze nem volt akkora, mint a halom az összeomláskor.

Mindkét történet hihető volt, és mindkettőt olcsó volt elhinni. Egyik sem reprodukálta az összeomlást. A tanulság, amelyet újra és újra megtanulunk: egy feltevés nem ok, amíg nem reprodukálja a hibát.

Igazi reprodukálás

Készítettünk egy eldobható sandboxot, ugyanazokkal a memórialimitekkel, mint az éles környezet, és egy hamis modellt, amely egy nagy fájlt streamelt reális, három karakteres darabokban. A másik oldalon lévő olvasót is lassítottuk, mint egy valódi hálózat.

Ez megtette. A halom nőtt, a folyamat ugyanazzal a hibával leállt.

A mechanizmus egyszerű volt, miután láttuk működés közben. Amíg a modell egy nagy parancsot írt — ebben az esetben egy 124 KB fájlt író heredoc-ot —, a streaming kódunk minden darabnál frissítette az eszköz címkéjét. A címke nem az új három karakter volt; a parancs addigi egész szövege volt. Így az események nőttek: 3 karakter, majd 6, majd 9 … egészen 124 KB-ig, körülbelül 41 000-szer. A socket nem tudta olyan gyorsan elküldeni őket, amilyen gyorsan keletkeztek, ezért szövegekként gyűltek a írási pufferében — nagyjából 690 MB-nyi.

A javítás

• Korlátozzuk a címkét. Egy állapotcímkének csak azt kell megmondania, mi történik. Most 200 karakterre van korlátozva, és szabályozzuk, milyen gyakran vizsgáljuk újra a részleges parancsot.
• Megszüntetjük a négyzetes összefűzést. A streamelt darabok ismételt string-összefűzése nagy kimenetnél O(n²). Áttértünk egy darabokra épülő megközelítésre, amely lineáris időben fűz hozzá.

Ezután megnéztük, mi más nőhetne korlátlanul egy kimenet-áradatnál, és ezeket is korlátoztuk:

• A csevegésben megjelenő élő parancskimenet kötegelve van, és az utolsó 8 000 karakterre korlátozzuk.
• Az egyes eseménysorok 4 MB-ra vannak korlátozva.
• A visszajátszó puffer, amelyet a böngésző újracsatlakozás után használ, projektenként 8 MB-ra van korlátozva.
• A régi ellenőrzőpontok a körrel együtt törlődnek, megtartva a legfrissebb állapotot és a korábbi körökhöz szükséges horgonyokat.

Áradatok tisztességes tesztelése

Két dolog miatt volt ezt nehezebb tesztelni, mint kellett volna:

1. Az igazi modellek nem működnek együtt. Ha egy modellt arra kérsz, hogy írjon ki egy óriási fájlt, általában megtagadja, összefoglalja, vagy értelmesebben írja meg. Az áradatok teszteléséhez olyan szkriptelt modell kell, amely pontosan azt csinálja, amit mondasz, a valódi ügynök-kódon keresztül futva.
2. A szkripteknek úgy kell viselkedniük, mint a modelleknek. Az első szkriptelt modellünk minden válaszban ugyanazt az azonosítót használta, így az ügynök-keretrendszer minden választ az előző felváltásának tekintett, és a köröket idő előtt lezárta. Úgy nézett ki, mintha a felület frissítésével lenne hiba. Nem volt az — a teszt-harness hazudott nekünk. Azt is ki kellett kényszerítenünk a szkriptben a modell valódi kontextuskorlátját, különben a memórianumok irreálisak lettek volna.

Amit ebből tanultunk

• A streaming felületek felerősítik a kis hibákat. Bármi, amit „darabonként” küldesz, tízezerszer kerül elküldésre. Küldj különbségeket, vagy korlátozd a terhelést.
• Korlátozz minden puffert, amely lassú határt lépi át. A socketeknek, a visszajátszó naplóknak és az ellenőrzőpontoknak mind van plafonjuk.
• Reprodukáld, mielőtt javítasz. Az első két magyarázatunk jól hangzott, és téves volt.

Ha az utóbbi időben egy nagyon hosszú fájl jelent meg a Mythex csevegésben anélkül, hogy az ügynök megakadt volna, ennek is része ez.