Yksi agentin askel — 120 000 tokenia: mihin ne katoavat ja miten korjasimme sen
Autonominen agentti voi kuluttaa huomattavasti enemmän tokeneita kuin odotetaan, koska se lähettää koko kontekstin toistuvasti jokaisella agenttisilmukan askeleella. Artikkelissa kuvataan, kuinka Uma Computer havaitsi, että todellinen syy ei ollut keskusteluhistoria, vaan järjestelmäohjeiden, työkalujen skeemojen ja muistin moninkertaistettu lisäkustannus, ja esittelee kolme optimointia: siirretään volyymi tarpeen mukaan käytettäviin työkaluihin, siirrytään merkkibudjettiin, jossa on selkeät katkaisumerkit, ja asetetaan läpinäkyvät nopeusodotukset.
Uma Computerin kehittäjät, jotka rakentavat autonomista agenttia, joka suorittaa tehtäviä kuten verkkohakuja, median luontia ja videoiden leikkausta, tutkivat, miksi yksi käyttäjäpyyntö maksoi 38 krediittiä odotetun kolmasosan sijaan. Laskutus osoitti 119 208 prompt-tokenia ja vain 1 018 completion-tokenia, mikä tarkoittaa, että malli lähinnä luki, ei kirjoittanut. Alkuperäinen hypoteesi oli pitkä keskusteluhistoria, mutta varsinaisessa ongelmallisessa keskustelussa oli vain kaksi viestiä, yhteensä 530 merkkiä. Mittaus paljasti, että konteksti per askel oli 13 900 tokenia, ja yhdeksällä askeleella kokonaismäärä nousi noin 120 000 tokeniin; ylimääräinen kuorma kerrottiin agenttisilmukan askelten määrällä. Lisäksi palveluntarjoaja varaa pahimman tapauksen kustannuksen, kun max_tokens on asetettu korkeaksi, mikä aiheuttaa HTTP 402 -virheitä jopa riittävällä saldolla. Korjaukseen kuului esiladatun kontekstin siirtäminen tarpeen mukaan kutsuttaviin työkaluihin, merkkipohjaisen budjetin käyttö prioriteetteineen ja selkeine katkaisumerkintöineen sekä nopeusodotusten tekeminen läpinäkyviksi. Artikkeli korostaa, että kontekstia ei saa koskaan piilottaa mallilta hiljaa, ja että optimoinnit on varmistettava konkreettisilla tapauksilla, sillä he melkein optimoivat tapaukseen, jossa historialla ei ollut merkitystä.
Lähde: Habr — хаб ML —
Alkuperäinen