Ocolurile AI pentru care nu ar trebui să plătiți

Nu înseamnă că firmele de vârf din domeniul AI nu ar încerca neapărat să încline balanța în favoarea lor când ne vând tokenuri, dacă ar putea scăpa nepedepsite – până la urmă, Anthropic a introdus în iunie o creștere efectivă a prețului de 30%; DeepSeek a majorat prețurile API-ului în august; iar OpenAI a revenit cu reticență asupra unei reduceri a alocării de tokenuri din planul său intermediar, la sfârșitul lunii septembrie. Așadar, tendința spre austeritate este acum destul de clară.

Într-adevăr, acest gând îți revine adesea în minte când agentul tău AI îți consumă alocația zilnică de tokenuri într-un torent de 45 de minute de cod nu neapărat glorios, apoi îți spune să revii peste 3-4 ore. Într-un asemenea moment frustrant, nu poți să nu te întrebi dacă unele dintre mecanismele implicate în acest proces nu sunt concepute în favoarea furnizorilor. Până la urmă, e o modalitate bună de a ne face să plătim pentru o reîncărcare specială de tokenuri – sau chiar să activăm „reîncărcarea automată”.

Ei bine, dacă lucrurile chiar stau așa, în această perioadă companiile de avangardă se pot ascunde cu destulă credibilitate în spatele presupunerii că nu înțelegem pe deplin cum sunt folosite tokenurile în fluxurile de lucru cu agenți, în diferite modele și cadre de lucru. Și nici ele nu înțeleg pe deplin. Cu excepția mecanismelor lor de activare a plăților (care sunt, într-adevăr, foarte bine puse la punct), toate acestea sunt încă în stadiul pre-alfa și continuă să fie subiecte de cercetare de avangardă, în pofida transformării pe scară largă a produsului într-o marfă de larg consum.

Gestionarea risipei

Faptul că agenții AI irosesc tokenuri (și, prin urmare, banii tăi) atunci când raționează în fluxuri de lucru cu agenți este deja bine documentat: exact acum un an am scris despre noi cercetări care arătau în ce măsură modelele AI de raționament aveau tendința să consume tokenuri prin divagații; la începutul acestui an, am scris despre alte cercetări care descriau raționamentul în lanț de gândire drept „decorativ”; iar săptămâna trecută, Nils Bunge, directorul de produs al Tsuga, a declarat într-un articol de leadership intelectual publicat aici:

„O echipă care consumă de două ori mai multe tokenuri nu creează neapărat de două ori mai multă valoare. Poate că se ocupă de o muncă mai dificilă, folosește un model inutil de puternic sau se bazează pe un agent care reîncearcă în mod repetat sarcini eșuate.”

Mai puțin cunoscut este modul în care tokenurile se irosesc în sarcini sau procese inutile; acesta este subiectul unui nou articol de cercetare care mi-a readus astăzi atenția asupra temei.

Intitulată Cum îți risipesc banii agenții AI?, această nouă colaborare academică din SUA* propune un cadru unitar care poate cuantifica în ce măsură procesele cu agenți risipesc, de fapt, tokenuri. În cazul modelelor cu sursă închisă, o metodologie „din umbră” este combinată cu statisticile și indicatorii oficiali ai furnizorilor, pentru a reconstitui în detaliu ce s-a întâmplat cu tokenurile în timp ce AI-ul raționa și acționa:

Noua metodă de măsurare a risipei de tokenuri AI. Raționamentul, acțiunile și costurile fiecărui agent sunt înregistrate, apoi analizate pentru a identifica repetări, solicitări inutile și ocoluri evitabile. Risipa identificată este eliminată, iar capacitatea agentului de a îndeplini sarcina inițială este testată din nou. Sursa

După cum se arată mai sus, agentului i se permite să lucreze în mod normal, interceptându-se și înregistrându-se comunicațiile cu furnizorul AI, inclusiv momentele de raționament, utilizarea instrumentelor, consumul de tokenuri și costurile. Înregistrările sunt apoi analizate de evaluatori bazați pe modele lingvistice de mari dimensiuni (LLM), pentru a separa munca utilă de repetări, căutări inutile și ocoluri. După aceea, risipa suspectată este eliminată, se calculează economiile de tokenuri, iar agentul își reia activitatea pentru a se verifica dacă sarcina poate fi în continuare îndeplinită cu succes.

În cadrul testelor, cercetătorii au constatat că aproximativ 18% din tokenurile generate de agenți erau irosite. În peste 45% dintre sarcini, un agent a irosit mai multe tokenuri decât i-au trebuit altuia pentru a finaliza cu succes aceeași sarcină. Cercetătorii au mai constatat că eliminarea a 41–46% din raționamentul inutil a avut un efect foarte mic asupra performanței, ceea ce sugerează că se pot realiza economii considerabile fără a compromite semnificativ rezultatele.

Articolul afirmă:

„În traiectoriile colectate, aproximativ 18% din tokenurile generate sunt identificate drept risipă.

„În mod remarcabil, în peste 45% dintre sarcini, tokenurile generate inutil doar de un agent depășesc volumul total de tokenuri generate de un alt agent care rezolvă cu succes aceeași sarcină.”

În plus, studiul a constatat că agenții iroseau cele mai multe resurse când foloseau instrumente necunoscute și urmau abordări care, în cele din urmă, nu duceau nicăieri; de asemenea, creșterea efortului de raționament nu aduce îmbunătățiri constante: la efort maxim, s-a constatat că Kimi-K3 genera de 6,6 ori mai multe tokenuri de raționament decât la efort redus, fără să existe o garanție corespunzătoare că rezultatele vor fi mai bune.

Rezultatele testelor care arată performanța Kimi-K3 la patru niveluri de efort de raționare, în cadrul a cinci teste de referință. Un efort mai mare de raționare nu a îmbunătățit în mod constant ratele de succes, iar efortul maxim a produs uneori rezultate mai slabe decât nivelurile inferioare.

Prin analogie, aceste sesiuni cu agenți nu seamănă cu situația în care conduci o mașină puternică fără să-i folosești vreodată cu adevărat capacitățile, ci mai degrabă cu aceea în care conduci o mașină care accelerează până la viteza maximă pe care o poate atinge la fiecare drum, chiar și când acest lucru nu aduce niciun beneficiu și în pofida posibilelor consecințe negative.

Studiul examinează și rolul diferitelor medii de execuție în generarea risipei de tokenuri și constată că același model AI, Kimi-K3, putea genera de peste patru ori mai mult raționament pentru sarcini identice, în funcție de mediul de execuție folosit, fără să obțină neapărat rezultate mai bune.

O parte din risipă a fost pusă pe seama unor erori software de bază: s-a constatat că OpenCode, Kimi Code CLI și OpenClaw lansau în mod repetat sarcini în mediul Python greșit, ceea ce provoca erori și reluări care consumau tokenuri. Kimi Code CLI permitea, de asemenea, AI-ului să solicite perioade de timeout pe care propriul software le respingea, obligându-l să facă și mai multe încercări costisitoare.

Contrar așteptărilor, mediile de execuție care ofereau mai multe instrumente nu generau neapărat mai multă risipă, iar unele ineficiențe recurente păreau să-și aibă originea chiar în modele, indiferent de mediul de execuție care le controla.

‘[Several]proprietățile aparent evidente ale mediilor de execuție nu explică în mod constant diferențele observate în ceea ce privește risipa. De exemplu, după cum se arată [below], mediile de execuție care pun la dispoziție mai multe instrumente nu generează neapărat mai multă risipă. OpenClaw pune la dispoziție mult mai multe instrumente decât celelalte medii de execuție, însă generează doar o risipă moderată. În plus, nu toată risipa variază în funcție de mediul de execuție.

‘[Below right]arată că, pe SWE-bench Verified, există o abatere recurentă în care Kimi-K3 redactează ceea ce consideră a fi soluția inițială a proiectului, apoi o abandonează. ‘

Rezultatele testelor compară tokenurile irosite în diferite medii de execuție pentru agenți AI. În stânga: oferirea unui număr mai mare de instrumente nu sporește neapărat risipa. În dreapta: Kimi-K3 încearcă în mod repetat să aplice o presupusă soluție inițială pentru o problemă software, apoi o abandonează, indiferent de mediul de execuție, însă rareori procedează astfel la un alt tip de sarcină.

Ca măsură de remediere, autorii sugerează ca mediile de execuție pentru agenți să recunoască situațiile în care restricțiile mediului fac imposibil orice progres suplimentar, să comunice clar aceste limitări modelului AI și să oprească execuția, în loc să permită ca încercările eșuate repetate să consume mai multe tokenuri. De asemenea, propun folosirea măsurătorilor lor privind tokenurile irosite pentru a îmbunătăți antrenarea modelelor, strategiile de raționare și proiectarea mediilor de execuție.

Metodologie

Pentru a reconstitui activitatea unui agent AI, cercetătorii au urmărit fiecare schimb dintre model și software-ul care îl controla, înregistrând raționamentul, răspunsurile, solicitările de utilizare a instrumentelor și costurile în tokenuri; nivelul de detaliu varia însă în funcție de furnizor: Kimi-K3 își dezvăluie întregul proces de raționare, Gemini 3.1 Pro oferă doar rezumate, iar Claude nu dezvăluie nimic.

Rezultatele fiecărui instrument erau transmise agentului, ceea ce le permitea cercetătorilor să urmărească procesul până la finalizare sau până când era atinsă limita sa de funcționare.

Patru exemple de moduri în care agenții AI consumă tokenuri. Repetarea informațiilor cunoscute, efectuarea unor căutări identice și adăugarea unor scuze inutile sunt considerate risipă, în timp ce o căutare nereușită nu este neapărat o risipă, deoarece agentul poate să fi avut un motiv întemeiat să o încerce.

Solicitările agenților au fost direcționate printr-un proxy pentru a le urmări activitatea, fiind necesare doar modificări minore ale codului; fiecare solicitare a fost etichetată cu testul de referință, rularea, sarcina și încercarea aferente (cu excepția OpenClaw, care nu acceptă astfel de etichete — în acest caz, pentru fiecare test a fost folosit un proxy separat, construit pe baza LiteLLM).

Patru tipare

Studiul definește risipa de tokenuri prin patru tipare recurente: Reformulare (repetarea informațiilor cunoscute); Preluare duplicată (repetarea solicitărilor inutile de utilizare a instrumentelor); Umplutură (adăugarea de text irelevant); și Abatere (urmarea unor abordări plauzibile, dar în cele din urmă neproductive).

Fiecare sesiune înregistrată a fost examinată de un LLM-as-a-Judge (LLMaJ**), căruia i-au fost furnizate sarcina inițială, înregistrarea completă și criteriile de identificare a tuturor celor patru tipare de risipă. Risipa suspectată a fost marcată și eliminată, apoi tokenurile rămase au fost numărate din nou pentru a calcula proporția și costul risipei. Ulterior, numărătorile au fost verificate cu ajutorul tokenizatoarelor sau instrumentelor de numărare proprii fiecărui furnizor și al datelor raportate privind utilizarea rezultatelor generate (fiind semnalate doar diferențe minore de formatare).

Teste

Modelele testate în cadrul studiului au fost Kimi-K3; Gemini 3.1 Pro; GPT-5.6 Terra; GPT-6 Astra; Claude Sonnet 5; și Claude Fable 5.1. Acestea au fost evaluate pe baza benchmarkurilor τ²-bench (servicii pentru clienți în domeniul companiilor aeriene și al comerțului cu amănuntul); SWE-bench Verified (inginerie software); Claw-Eval; și MCP-Atlas (utilizarea instrumentelor de uz general).

În plus, Kimi-K3 a fost testat la niveluri diferite de raționament, iar cinci medii de agenți au fost comparate: OpenCode; OpenClaw; OpenHands; Hermes; și Kimi Code CLI. Aceste comparații au fost folosite pentru a evalua felul în care modelele, sarcinile, efortul de raționament și proiectarea mediilor de agenți influențează risipa de tokenuri; în teste suplimentare, risipa suspectată a fost eliminată pentru a-i verifica efectul asupra performanței.

Pentru a stabili câți bani a risipit fiecare model, costul textului inutil și al apelurilor inutile către instrumente a fost comparat cu costul total al rezultatelor generate, iar rezultatele au fost calculate ca medie pentru cele patru benchmarkuri. Raționamentul intern a fost evaluat separat pentru Kimi-K3 — singurul model care și-a expus întregul proces de raționament:

Rezultatele testelor compară costurile rezultatelor generate irosite de șase modele AI, ca medie pentru patru benchmarkuri. În stânga: ratele generale de risipă, cu raționamentul intern al Kimi-K3 prezentat separat. În dreapta: ratele de risipă pentru sarcinile reușite și cele eșuate; în general, eșecurile au generat mai multă risipă.

După cum se arată mai sus, s-a considerat că între 11% și 24,9% din banii cheltuiți pentru generarea răspunsurilor și utilizarea instrumentelor au fost irosiți, GPT-6 Astra obținând cele mai bune rezultate, iar Claude Sonnet 5, cele mai slabe. În cazul Kimi-K3, aproximativ unul din șase tokenuri a fost irosit pentru răspunsuri și utilizarea instrumentelor, proporția crescând la peste unul din patru în timpul raționamentului intern.

În general, s-a constatat mai multă risipă atunci când sarcinile eșuau, deși pentru raționamentul Kimi-K3 s-a observat contrariul; de asemenea, nu au existat dovezi clare că folosirea mai multor tokenuri pentru activități inutile ar fi sporit șansele de reușită.

Într-un alt test, s-a încercat reducerea numărului de tokenuri irosite în timp ce AI-ul încă lucra: la fiecare pas, a fost folosit un evaluator AI** pentru a elimina informațiile repetate și textul inutil din raționamentul modelului, înainte de a-i permite să continue sarcina:

Rezultatele testelor arată cum a influențat eliminarea raționamentului inutil al AI-ului ratele de reușită pe două benchmarkuri. Eliminarea a 41–46% din raționament a avut un efect redus asupra performanței, în timp ce eliminarea întregului raționament a dus la mult mai multe eșecuri.

Pe SWE-bench Verified, a fost eliminat 41% din raționament, fără ca performanța să scadă; rata de reușită a crescut chiar ușor, de la 89% la 89,5%. Pe MCP-Atlas, a fost eliminat 46%, iar rata de reușită a scăzut doar moderat, de la 65% la 62,3%.

Cu alte cuvinte, aproape jumătate din raționament putea fi eliminată în timp ce AI-ul lucra, fără a-i afecta serios capacitatea de a duce sarcina la bun sfârșit.

În cele din urmă^†, Kimi-K3 a fost testat pe sarcini identice folosind medii de agenți diferite. În acest caz, volumul raționamentului generat a variat de peste patru ori, fără o îmbunătățire consecventă a performanței, după cum se arată mai jos:

Rezultatele testelor compară consumul de tokenuri al Kimi-K3 în diferite medii de agenți, pe două benchmarkuri. Raționamentul intern este indicat cu albastru, iar răspunsurile și apelurile către instrumente, cu portocaliu. Pentru sarcinile de programare, Mini-SWE a generat de peste patru ori mai mult raționament decât Hermes.

O parte din risipă a fost pusă pe seama unor defecțiuni software elementare. OpenCode, Kimi Code CLI și OpenClaw au lansat testele de programare în mediul Python greșit, ceea ce a provocat erori și repetarea încercărilor.

Concluzie

Aceasta este doar o scurtă privire asupra unei lucrări a cărei lungime și metodologie minuțioasă ar putea răsplăti o lectură mai aprofundată.

Subiectul mi-a amintit de ceva la care mă gândesc adesea: prăpastia uriașă dintre ceea ce înțelegem noi și ceea ce înțeleg cu adevărat furnizorii de modele de ultimă generație despre aceste procese, precum și disponibilitatea companiilor de a prezenta produsul ca și cum ar fi petrecut ultimele trei luni într-un instrument de analiză statică a codului și ar fi trecut testul cu brio.

În situația actuală, deocamdată, în cazul unor rezultate nefavorabile, nu putem da vina pe nimeni în afară de noi înșine, fiindcă achiziționăm un produs despre care aproape toți știm că este profund experimental și imprevizibil.

* Cu contribuții declarate egale din partea University of Illinois Urbana-Champaign, Northeastern University, University of California (Los Angeles) și a unui cercetător independent.

* Din câte îmi dau seama, lucrarea nu precizează ce model a fost folosit.

^† Pentru acest articol, nu pentru lucrare, care este mai lungă decât îmi permit de obicei să abordez și conține mai multe teste și o analiză mai aprofundată decât putem include aici. Pentru mai multe detalii, consultați PDF-ul sursă, indicat mai sus.

Publicat inițial vineri, 6 noiembrie 2026