Cum am optimizat un chatbot AI să consume de 40 de ori mai puțin

Sven nu a pornit ca un experiment. A pornit dintr-o nevoie clară.

În Publyo, lucrăm cu mii de publisheri și zeci de campanii în paralel. Clienții vor răspunsuri rapide: cât costă, ce recomandări există, cum arată un media plan pentru un anumit buget. Iar de cele mai multe ori, întrebările vin în afara orelor de program.

Așa a apărut ideea unui asistent pe WhatsApp.

Un account manager care nu doarme, nu întârzie și nu uită.

În teorie, totul era simplu. În practică, lucrurile au devenit interesante abia după lansare.

Primele semne că ceva nu e în regulă

După prima săptămână, Sven funcționa exact cum ne doream:

• răspundea corect

• construia media planuri relevante

• interacțiunea era naturală

Doar că, în paralel, costurile creșteau într-un mod greu de justificat.

Nu aveam trafic mare. Sub 1000 de conversații.

Și totuși, consumul de tokeni era uriaș.

Nu genul de „puțin peste estimări”.

Genul de „trebuie să înțelegem urgent ce se întâmplă”.

Unde am greșit: am tratat AI-ul ca pe un „black box”

Inițial, arhitectura noastră a fost construită pe o idee simplă:

Cu cât îi dai mai mult context, cu atât va răspunde mai bine.

Așa că i-am dat tot.

Sven rula pe Claude Sonnet și, la fiecare mesaj, primea:

• instrucțiunile complete

• întreaga bază de date cu publisheri

• mesajul utilizatorului

Problema era dimensiunea bazei de date.

Peste 3000 de site-uri, fiecare cu:

• prețuri

• categorii

• metrici SEO

• opțiuni speciale

În total: aproximativ 222.000 de caractere.

Adică în jur de 75.000 de tokeni… per mesaj.

Inclusiv pentru un banal „Salut”.

Când am pus cifrele cap la cap, imaginea a devenit clară: zeci de milioane de tokeni consumați într-o săptămână.

Nu pentru că utilizatorii cereau mult.

Ci pentru că noi trimiteam prea mult.

Momentul de claritate: nu trebuie să trimiți datele, trebuie să le poți accesa

A fost punctul în care am schimbat complet abordarea.

În loc să tratăm promptul ca pe un container pentru toate informațiile, l-am tratat ca pe un punct de plecare.

Am eliminat baza de date din prompt și am construit un sistem de tool calling (MCP).

În practică, asta înseamnă:

• modelul nu mai vede toate datele din start

• când are nevoie de informații, le cere

• primește doar ce este relevant pentru acel context

Diferența a fost imediată.

Instrucțiunile au scăzut de la 222.000 la aproximativ 2.800 de caractere.

Un mesaj simplu nu mai vine cu un „bagaj” uriaș în spate.

Paradoxul: mai puțin context, aceeași calitate

Ne așteptam la compromisuri.

Dar nu au apărut.

Claude Sonnet a continuat să livreze:

• recomandări relevante

• media planuri corecte

• răspunsuri naturale

De fapt, comportamentul a devenit mai curat.

În loc să „ghicească” dintr-un volum mare de date, modelul:

• înțelegea cererea

• cerea exact informația necesară

• construia răspunsul pe baza ei

Încercarea de a elimina complet costurile: modelele locale

După optimizarea majoră, următorul pas a fost logic:

Putem elimina complet costurile per request?

Am testat mai multe modele locale.

Gemma 4 26B

Promițător, dar:

• latență mare (20+ secunde)

• reasoning imposibil de dezactivat

• comportament imprevizibil în unele cazuri

Qwen 2.5 14B

Foarte bun tehnic, dar:

• română rigidă

• experiență slabă pentru utilizator

Gemma 3 27B

Echilibrat, dar:

• consum mare de resurse

• greu de scalat

Concluzia a fost clară:

Modelele locale nu sunt încă pregătite pentru combinația de:

• limbaj natural în română

• tool calling precis

• răspuns rapid

Lecția despre „mai ieftin” nu înseamnă „mai bun”

Am testat și Claude Haiku, o variantă mai accesibilă.

În teorie, părea o alegere bună.

În practică:

• ignora parametri importanți

• livra rezultate inconsistente

• afecta direct calitatea media planurilor

A fost momentul în care am acceptat un lucru simplu:

Nu modelul trebuie să fie mai ieftin. Sistemul trebuie să fie mai eficient.

Optimizările „invizibile” care au contat enorm

După schimbarea arhitecturii, am optimizat și detaliile:

• am redus drastic dimensiunea instrucțiunilor

• am limitat lungimea răspunsurilor

• am introdus caching pentru prompturi repetitive

• am implementat monitorizare în timp real

Fiecare optimizare în parte pare minoră.

Împreună, schimbă complet ecuația.

Rezultatul final

Aceleași conversații, aceeași logică, aceeași experiență pentru utilizator.

Dar:

• consum de 40 de ori mai mic

• costuri predictibile

• performanță mai bună

Fără compromisuri.

Ce am învățat din toată experiența

Nu trata promptul ca pe o bază de date.

Este cel mai scump loc în care poți ține informație.

Folosește tool-uri pentru orice este dinamic sau voluminos.

Este diferența dintre un sistem scalabil și unul care explodează în costuri.

Testează pe cazuri reale, nu pe benchmark-uri.

Diferența este enormă.

Monitorizează din prima zi.

Problemele devin scumpe foarte repede.

Optimizarea nu începe de la model, ci de la arhitectură.

Privind înapoi, cea mai mare schimbare nu a fost tehnică.

A fost de perspectivă.

Am trecut de la „cum facem AI-ul să știe mai mult”

la „cum facem AI-ul să folosească mai bine ce știe”.

Iar de acolo, totul a devenit mai simplu.

Cristian Ionita

Founder & CEO

Fondator și CEO al Oblyo Digital, cu peste 10 ani de experiență în marketing digital și tehnologie. A construit Publyo de la zero, transformând o idee simplă într-un ecosistem complet de platforme SaaS pentru content marketing. Pasionat de automatizare, API-uri și de a face tehnologia accesibilă tuturor.