Atminties perpildymo klaida, paslėpta progreso etiketėje

Vieną rugsėjo vakarą AI agentas naudotojo darbo aplinkoje sugedo su atminties perpildymo klaida viduryje kūrimo ciklo. Akivaizdūs įtariamieji – per daug subagentų vienu metu arba per daug išaugęs kontekstas – abu buvo klaidingi. Tikroji priežastis buvo būsenos etiketė: kol modelis srautu siuntė didelę shell komandą po kelis simbolius, mes kiekvieno gabalėlio metu iš naujo siuntėme visą iki tol surinktą komandą kaip progreso etiketę. Viena 124 KB komanda virto maždaug 41 000 įvykių ir apie 690 MB eilėje laukiančių eilučių.

Kaip agentas srautu perduoda darbą

Kai kuriate Mythex platformoje, agentas veikia privačioje jūsų projekto debesų sandbox aplinkoje. Modeliui rašant, jo išvestis srautu grįžta į jūsų naršyklę: tekstas rodomas žodis po žodžio, o kai jis paleidžia įrankį – pavyzdžiui, shell komandą, kuri rašo failą – matote to įrankio etiketę, kuri atsinaujina gyvai, kad žinotumėte, ką jis daro.

Modelis srautą siunčia mažais gabalėliais. Su modeliu, kurį naudojome, tie gabalėliai dažnai buvo vos trijų simbolių ilgio.

Pirmos hipotezės buvo klaidingos

Gedimas atrodė kaip mastelio problema, todėl pradėjome nuo jos.

• Lygiagretūs subagentai? Kūrimas naudojo tik du, kiekvienas laikė apie 1,5 MB būsenos. Nepakanka.
• Išsaugoti pėdsakai? Mūsų sekimas laikė vykdymo medį atmintyje, bet jis buvo toli gražu ne tokio dydžio kaip atmintis krašimosi metu.

Abi istorijos buvo tikėtinos, ir abi lengvai patikėti. Nei viena neatkartojo gedimo. Pamoka, kurią vis primename sau: hipotezė nėra priežastis, kol ji neatkartoja gedimo.

Atkuriame tikrai

Sukūrėme atskirą sandbox su tokiais pat atminties limitais kaip gamyboje ir netikrą modelį, kuris srautu siuntė didelį failą realistiškais trijų simbolių gabalėliais. Taip pat padarėme kito socket galo skaitytoją lėtą, kaip tikrame tinkle.

Tai pasiteisino. Atmintis augo, o procesas žuvo su ta pačia klaida.

Mechanizmas, kai jį pamatėme, buvo paprastas. Modeliui rašant didelę komandą – šiuo atveju heredoc, kuris rašė 124 KB failą – mūsų srautinis kodas atnaujino įrankio etiketę kiekvieno gabalėlio metu. Etiketė buvo ne naujieji trys simboliai, o visa iki tol surinkta komanda. Taigi įvykiai augo: 3 simboliai, tada 6, tada 9, … iki 124 KB, maždaug 41 000 kartų. Socket negalėjo siųsti tiek greitai, kiek jie buvo sukuriami, todėl jie kaupėsi jo rašymo buferyje kaip eilutės – apie 690 MB.

Pataisa

• Apriboti etiketę. Progreso etiketė turi tik nurodyti, kas vyksta. Dabar ji ribojama iki 200 simbolių, o dalinės komandos nuskaitymas vyksta rečiau.
• Sustabdyti kvadratinį jungimą. Srautinių gabalėlių jungimas kartotine eilučių konkatenacija dideliems išvesties kiekiams yra O(n²). Perėjome prie gabalais pagrįsto metodo, kuris prideda tiesiniu laiku.

Tada ieškojome kitų vietų, kurios galėtų neribotai augti per išvesties potvynį, ir jas apribojome:

• Tiesioginė komandų išvestis, rodoma pokalbyje, grupuojama ir paliekama tik paskutiniai 8 000 simbolių.
• Atskiros įvykių eilutės ribojamos iki 4 MB.
• Atkūrimo buferis, kurį naršyklė naudoja po prisijungimo iš naujo, ribojamas iki 8 MB vienam projektui.
• Seni kontrolės taškai iškerpami, kai kūrimas vyksta, paliekant naujausią būseną ir ankstesniems kūriniams reikalingus inkarus.

Potvynių testavimas be apgaulės

Du dalykai šį testavimą padarė sunkesnį, nei turėtų būti:

1. Tikri modeliai nebendradarbiauja. Paprašius modelio išspausdinti milžinišką failą, jis paprastai atsisako, apibendrina arba parašo protingiau. Potvyniams testuoti reikia scenarijų modelio, kuris daro tai, ką jam nurodote, veikdamas per tikrą agento kodą.
2. Scenarijai turi elgtis kaip modeliai. Mūsų pirmasis scenarijaus modelis kiekvienam atsakymui naudojo tą patį atsakymo ID, todėl agento sistema kiekvieną atsakymą laikė ankstesnio pakaitalu ir užbaigė kūrimus anksčiau. Atrodė kaip naudotojo sąsajos atnaujinimo klaida. Ji nebuvo tokia – klaidino pats testavimo įrankis. Taip pat scenarijuje turėjome įvesti tikrą modelio konteksto ribą, kitaip atminties skaičiai buvo nerealūs.

Ką iš to pasiėmėme

• Srautinės sąsajos padaugina smulkias klaidas. Viskas, ką siunčiate „kiekvienam gabalėliui“, siunčiama dešimtis tūkstančių kartų. Siųskite tik pokyčius arba ribokite krovinį.
• Apribokite kiekvieną buferį, kuris kerta lėtą ribą. Socket, atkūrimo žurnalai ir kontrolės taškai visi turi turėti lubas.
• Atkurkite prieš taisydami. Mūsų pirmi du paaiškinimai skambėjo teisingai ir buvo klaidingi.

Jei pastaruoju metu Mythex pokalbyje pastebėjote labai ilgą failą, kuris pasirodė be agento sustojimo, dalis priežasties – būtent tai.