Pomanjkanje pomnilnika, skrito v oznaki napredka

Nekega večera konec septembra je AI agent v delovnem prostoru uporabnika odpovedal z napako zaradi pomanjkanja pomnilnika sredi obrata. Očitna osumljenca – preveč hkrati tekočih podagentov ali prevelik kontekst – sta bila oba napačna. Pravi vzrok je bila oznaka stanja: medtem ko je model pretakal dolg ukaz lupine po nekaj znakov naenkrat, smo ob vsakem kosu znova poslali celoten ukaz do tistega trenutka kot oznako napredka. En ukaz z 124 KB je postal približno 41.000 dogodkov in približno 690 MB čakajočih nizov v čakalni vrsti.

Kako agent pretaka svoje delo

Ko gradite na Mythexu, agent teče v zasebnem oblačnem peskovniku vašega projekta. Medtem ko model piše, se njegov izhod pretaka nazaj v vaš brskalnik: besedilo se pojavlja besedo za besedo, in ko zažene orodje – na primer ukaz lupine, ki zapiše datoteko –, vidite oznako zanj, ki se sproti posodablja, da veste, kaj počne.

Model pretaka v majhnih kosih. Z modelom, ki smo ga uporabljali, so bili ti kosi pogosto dolgi samo tri znake.

Prve hipoteze so bile napačne

Zrušitev je izgledala kot težava z velikostjo, zato smo tam začeli.

• Vzporedni podagenti? Obrat je uporabil le dva, vsak je držal okoli 1,5 MB stanja. Premalo.
• Ohranjene sledi? Naše sledenje je hranilo drevo zagonov v pomnilniku, vendar je bilo to bistveno manj kot velikost kopice ob zrušitvi.

Obe zgodbi sta bili verjetni in ju je bilo poceni verjeti. Nobena ni reproducirala zrušitve. Lekcija, ki se je stalno učimo na novo: hipoteza ni vzrok, dokler ne reproducira napake.

Resnično reproduciranje

Zgradili smo začasni peskovnik z enakimi omejitvami pomnilnika kot v produkciji in lažni model, ki je pretakal velike datoteke v realističnih kosih po tri znake. Naredili smo tudi, da je bralec na drugem koncu vtiča počasen, kot pravo omrežje.

To je naredilo svoje. Kopica je rasla, proces pa je umrl z isto napako.

Mehanizem je bil preprost, ko smo ga lahko opazovali. Medtem ko je model pisal velik ukaz – v tem primeru heredoc, ki je zapisal datoteko 124 KB –, je naša koda pretakanja posodobila oznako orodja ob vsakem kosu. Oznaka ni bila nov kos treh znakov; bil je celoten ukaz do tistega trenutka. Dogodki so tako rasli: 3 znaki, nato 6, nato 9, … do 124 KB, približno 41.000-krat. Vtič ni mogel pošiljati tako hitro, kot so nastajali, zato so se kopičili v njegovem medpomnilniku za pisanje kot nizi – okoli 690 MB.

Popravek

• Omejite oznako. Oznaka stanja mora povedati le, kaj se dogaja. Zdaj je omejena na 200 znakov, in omejeno je tudi, kako pogosto ponovno pregledujemo delni ukaz.
• Ustavite kvadratično združevanje. Lepljenje pretočenih kosov z ponavljajočim se združevanjem nizov je O(n²) za velike izhode. Preselili smo se na pristop, ki temelji na kosih in dodaja v linearnem času.

Nato smo poiskali vse ostalo, kar bi lahko brez meje raslo ob poplavi izhoda, in to omejili:

• Živi izhod ukaza, prikazan v klepetu, se združuje in ohranja zadnjih 8.000 znakov.
• Posamezne vrstice dogodkov so omejene na 4 MB.
• Medpomnilnik za ponovno predvajanje, ki ga brskalnik uporablja za nadoknaditev po ponovni povezavi, je omejen na 8 MB na projekt.
• Stare kontrolne točke se obrezujejo, ko obrat napreduje, pri čemer ohranimo najnovejše stanje in sidra, ki jih potrebujejo prejšnji obrati.

Iskreno testiranje poplav

Dve stvari sta to naredili težje za testiranje, kot bi morala biti:

1. Pravi modeli ne sodelujejo. Če modelu naročite, naj izpiše ogromno datoteko, bo običajno zavrnil, povzel ali jo napisal pametneje. Za testiranje poplav potrebujete skriptiran model, ki naredi točno to, kar mu poveste, in teče skozi pravo kodo agenta.
2. Skripte se morajo obnašati kot modeli. Naš prvi skriptiran model je na vsakem odgovoru ponovno uporabil isti ID odgovora, zato je ogrodje agenta vsak odgovor obravnavalo kot zamenjavo prejšnjega in obrate končalo prezgodaj. Izgledalo je kot napaka pri osveževanju vmesnika. Ni bilo tako – test nas je lagal. Prav tako smo morali v skripti uveljaviti pravo omejitev konteksta modela, sicer so bile številke pomnilnika nerealistične.

Kaj smo iz tega vzeli

• Pretakajoči vmesniki pomnožijo majhne napake. Vse, kar pošljete »na kos«, se pošlje desetine tisočkrat. Pošiljajte razlike ali omejite obremenitev.
• Omejite vsak medpomnilnik, ki prečka počasno mejo. Vtiči, dnevniki ponovnega predvajanja in kontrolne točke potrebujejo zgornjo mejo.
• Reproducirajte, preden popravite. Naši prvi dve razlagi sta zvenela pravilno in bili sta napačni.

Če ste nedavno v klepetu Mythex videli zelo dolgo datoteko, ki se je pojavila brez zastoja agenta, je to ena od razlogov.