Mälu täitumise viga, mis peitus edenemisindikaatoris

Ühel septembri lõpu õhtul kukkus kasutaja töökeskkonna tehisintellekti agent pooleli pöörde keskel kokku mälu täitumise veaga. Ilmsed kahtlusalused, liiga palju korraga käivaid alamagendeid või liiga suureks kasvanud kontekst, olid mõlemad valed. Tegelik põhjus oli olekusilt: kui mudel voogedastas suurt käsku paar märki korraga, saatsime iga tüki juures uuesti kogu siiani kogunenud käsu edenemisindikaatorina. Üks 124 KB käsk muutus umbes 41 000 sündmuseks ja ligikaudu 690 MB järjekorras olevaks stringiks.

Kuidas agent oma tööd voogedastab

Kui ehitad Mythexis, töötab agent sinu projekti privaatses pilveliivakastis. Kui mudel kirjutab, voogedastatakse tema väljund tagasi sinu brauserisse: tekst ilmub sõna haaval, ja kui ta käivitab tööriista, näiteks käsu, mis kirjutab faili, näed selle silti, mis uueneb reaalajas, nii et tead, mida ta teeb.

Mudel voogedastab väikeste tükkidena. Mudelil, mida me kasutasime, olid need tükid sageli ainult kolm märki pikad.

Esimesed hüpoteesid olid valed

Kokkujooks näis skaleerimisprobleemina, nii et alustasime sealt.

• Paralleelsed alamagendid? Pööre oli kasutanud ainult kahte, kumbki hoidis umbes 1,5 MB olekut. Liiga vähe.
• Säilitatud jäljed? Meie jälgimine hoidis käivituspuud mälus, aga see polnud kaugeltki nii suur kui kuhja maht kokkujooksu hetkel.

Mõlemad olid usutavad lood ja mõlemat oli odav uskuda. Kumbki ei reprodutseerinud kokkujooksu. Õppetund, mida peame pidevalt uuesti õppima: hüpotees ei ole põhjus enne, kui see reprodutseerib tõrke.

Reprodutseerimine päriselt

Ehitasime ajutise liivakasti, millel olid samad mälupiirangud mis tootmisel, ja võltsmudeli, mis voogedastas suurt faili realistlike kolmemärgiliste tükkidena. Tegime ka teises otsas oleva lugeja aeglaseks, nagu päris võrk.

See tegi asja selgeks. Kuhi kasvas ja protsess suri sama veaga.

Mehhanism oli lihtne, kui sai seda jälgida. Kui mudel kirjutas suurt käsku, antud juhul heredoc-käsku, mis kirjutas 124 KB faili, uuendas meie voogedastuskood tööriista silti iga tüki juures. Silt ei olnud uus kolm märki, vaid kogu siiani kogunenud käsk. Nii sündmused kasvasid: 3 märki, siis 6, siis 9 … kuni 124 KB, umbes 41 000 korda. Pesa ei suutnud neid saata nii kiiresti, kui neid tekitati, nii et need kogunesid selle kirjutuspuhvrisse stringidena, umbes 690 MB.

Parandus

• Piira silt. Olekusilt peab ütlema ainult, mis toimub. Nüüd on see piiratud 200 märgiga ja piirame, kui tihti osalist käsku uuesti skannime.
• Lõpeta ruutkeeruline liitmine. Voogedastatud tükkide liitmine korduva stringi liitmisega on suurte väljundite puhul O(n²). Läksime üle tükipõhisele lähenemisele, mis lisab lineaarses ajas.

Seejärel otsisime muud, mis võiks väljundi üleujutuses piiramatult kasvada, ja piirasime selle:

• Vestluses näidatav otsene käsuväljund koondatakse ja hoitakse viimase 8000 märgini.
• Üksikud sündmusread on piiratud 4 MB-ga.
• Puhver, mida brauser kasutab pärast uuesti ühendumist, et järele jõuda, on projekti kohta piiratud 8 MB-ga.
• Vanad checkpointid kärbitakse pöörde käigus, hoides uusimat olekut ja ankruid, mida varasemad pöörded vajavad.

Üleujutuste aus testimine

Kaks asja muutsid selle testimise raskemaks, kui oleks pidanud olema:

1. Päris mudelid ei tee koostööd. Palu mudelil trükkida tohutu fail ja ta tavaliselt keeldub, kokkuvõtab või kirjutab selle mõistlikumalt. Üleujutuste testimiseks vajad skriptitud mudelit, mis teeb täpselt seda, mida ütled, ja jookseb läbi päris agendi koodi.
2. Skriptid peavad käituma nagu mudelid. Meie esimene skriptitud mudel kasutas iga vastuse juures sama vastuse ID-d, nii et agendiraamistik käsitles iga vastust eelmise asendajana ja lõpetas pöörded enneaegselt. See näis kasutajaliidese värskendamise veana. Ei olnud — see oli testikeskkond, mis valetas. Pidime skriptis jõustama ka mudeli päris kontekstipiiri, muidu olid mälunumbrid ebarealistlikud.

Mida sellest õppisime

• Voogedastavad kasutajaliidesed korrutavad väikesed vead. Kõik, mida saadad „iga tüki kohta“, saadetakse kümneid tuhandeid kordi. Saada muudatused (deltad) või piira koormust.
• Piira iga puhvrit, mis ületab aeglase piiri. Pesad, taasesituslogid ja checkpointid vajavad kõik lage.
• Reprodutseeri enne parandamist. Meie esimesed kaks selgitust kõlasid õigesti ja olid valed.

Kui oled hiljuti näinud Mythexi vestluses väga pikka faili ilmumas ilma, et agent oleks seisma jäänud, on see osaliselt selle põhjus.