Adăugarea metricilor nu îmbunătățește neapărat înțelegerea. Multe tablouri de bord conțin mai multe măsurători ale aceluiași comportament fundamental. Metricile devin mai utile pentru diagnosticare când sunt combinate în perechi reciproc distructive: cost și calitate, izolare și sentiment sau acuratețe și latență.
Perechile potrivite se schimbă pe măsură ce un produs AI trece de la etapa-pilot la producție. Măsurarea ar trebui să reflecte deciziile pe care echipa trebuie să le ia în fiecare etapă.
Monitorizarea operațională și măsurarea strategică au scopuri diferite. Echipele pot urmări sute de semnale ale sistemului, folosind doar câteva perechi pentru a orienta deciziile privind produsul.
Metricile principale pot spune o poveste convingătoare, lăsând însă nerezolvată o decizie importantă privind produsul.
Asistentul AI al Klarna a fost asociat public cu un randament mai mare, costuri mai mici și scoruri de satisfacție a clienților comparabile cu cele obținute de agenții umani. În anul următor, compania a decis să extindă accesul la asistență umană, iar directorul general a recunoscut că reducerea costurilor primise prea multă atenție.
Aceasta nu a însemnat respingerea asistentului AI sau a tehnologiei pe care se bazează. A fost o ajustare a echilibrului dintre automatizare și serviciile oferite de oameni, bazată pe experiența companiei în operarea produsului. Pe măsură ce automatizarea prelua mai multe dintre solicitările simple și cu volum mare, agenții umani de care avea nevoie Klarna erau cei pregătiți pentru cazuri complexe și sensibile.
După ce au definit de la început ce trebuie să realizeze produsul, majoritatea organizațiilor care dezvoltă produse AI ajung la aceeași întrebare: chiar funcționează?
Dacă răspunsul nu este clar, primul impuls este adesea adăugarea altor metrici. Trei devin 10, apoi 10 devin 30. Tabloul de bord se îmbogățește, dar echipa nu înțelege neapărat mai bine situația.
Problema nu ține întotdeauna de calitatea indicatorilor individuali, ci de relația dintre ei. Satisfacția clienților, scorul de recomandare (NPS), recenziile și ratele de aprecieri pozitive pot oferi semnale utile, dar pot reflecta schimbări similare ale percepției generale. Când acești indicatori evoluează în aceeași direcție, confirmă că s-a întâmplat ceva, fără să explice neapărat de ce.
Prin urmare, echipele AI ar trebui să privească dincolo de metricile care se confirmă reciproc și să identifice măsurători care evidențiază rezultate concurente. Aceste perechi reciproc distructive dezvăluie și ajută la monitorizarea efectelor compromisurilor asupra performanței produsului, permițând decizii mai bune.
Într-o implementare anterioară lansării, echipa comună dezvolta un agent vocal AI în timp real pentru apelurile primite de serviciul de asistență pentru clienți. Una dintre cele mai dificile întrebări nu viza alegerea modelului sau orchestrarea. Întrebarea era cum avea să afle organizația dacă produsul funcționează după ce clienții începeau să-l folosească la scară largă.
Cadrul inițial folosea trei măsurători:
Rata de izolare: frecvența cu care sistemul AI soluționează un apel fără să-l transfere unei persoane.
Rata de escaladare: frecvența cu care un apel este transferat unui agent uman.
Rata de soluționare: frecvența cu care problema clientului este rezolvată în cele din urmă.
Fiecare măsurătoare era rezonabilă. Împreună însă, ele nu puteau răspunde la o întrebare evidentă: dacă escaladările cresc, ce ne spune acest lucru?
Echipa a împărțit escaladarea în opt subtipuri. A adăugat apoi măsurători privind abandonul, parcursul și timpii, scoruri de înțelegere a limbajului și rata de soluționare în funcție de tipul solicitării. În cele din urmă, cadrul conținea 31 de metrici din șase categorii.
Putea descrie detaliat escaladarea, dar tot nu îi putea diagnostica în mod fiabil cauza. Majoritatea metricilor erau variații ale aceluiași comportament, astfel că evoluau împreună, fără să testeze explicații concurente.
Tabloul de bord devenise mai degrabă descriptiv decât diagnostic.
Echipa nu avea nevoie de încă un nivel de detaliere. Avea nevoie de metrici care să se limiteze reciproc.
Le numim perechi reciproc distructive: două măsurători în cazul cărora îmbunătățirea izolată a uneia poate afecta rezultatul reprezentat de cealaltă. Denumirea descrie modul în care poate eșua optimizarea unilaterală, nu starea dorită.
Când ambele laturi se mențin la niveluri bune, produsul poate funcționa sustenabil. Când evoluțiile lor diferă, direcția acestei divergențe ajută echipa să decidă ce aspecte să investigheze.
Ce aveam | Pereche reciproc distructivă | Ce poate dezvălui perechea |
|---|---|---|
Rata de escaladare împărțită în opt subtipuri | Rata de escaladare ↔ timpul până la escaladare | Escaladarea imediată poate indica o problemă de încredere sau de prezentare; cea ulterioară poate arăta că sistemul nu poate finaliza sarcina. |
Rata de izolare și rata de soluționare raportate separat | Rata de izolare ↔ sentimentul clientului | Dacă izolarea reprezintă o soluționare satisfăcătoare sau abandonarea încercării de către client. |
Rata de soluționare în funcție de tipul intenției | Rata de soluționare ↔ profunzimea conversației | Dacă soluționarea cu succes este eficientă sau necesită o interacțiune epuizantă. |
Pentru a înțelege mai bine cum se evidențiază acest lucru și cum putem folosi informația, să analizăm rata de escaladare și timpul până la escaladare. Echipa nu va ști cum se comportă clienții până la primirea apelurilor reale, dar poate defini ipotezele pe care trebuie să le testeze.
Dacă încep să fie escaladate mai multe apeluri, iar clienții părăsesc experiența AI în primele 30 de secunde, echipa ar trebui să investigheze încrederea, informarea, tonul și interacțiunile inițiale. Dacă utilizatorii escaladează după ce încearcă timp de câteva minute să îndeplinească o sarcină, cauza probabilă este capacitatea sistemului sau acoperirea fluxului de lucru.
Cifra principală privind escaladarea este aceeași. Decizia privind produsul este diferită.
O pereche utilă nu dovedește singură cauza. Ea restrânge investigația și clarifică următoarea decizie.
Exemplul Klarna prezentat anterior arată cum se aplică acest principiu când costul interacționează cu nivelul calitativ al serviciilor. Acesta demonstrează cum poate evolua un model operațional bazat pe AI pe măsură ce compania monitorizează efectele compromisurilor și învață din implementare.
În februarie 2024, compania a raportat că asistentul său AI gestionase 2,3 milioane de conversații în prima lună, efectuase un volum de muncă echivalent cu cel a 700 de agenți cu normă întreagă și obținuse scoruri de satisfacție a clienților comparabile cu cele ale agenților umani. Klarna a estimat că asistentul va contribui la creșterea profitului cu 40 de milioane $ în 2024. Acestea erau rezultate raportate chiar de Klarna, nu rezultatele unei evaluări independente.
În mai 2025, directorul general al Klarna a declarat că firma pusese prea mult accent pe reducerea costurilor serviciului de asistență pentru clienți și a prezentat planuri pentru extinderea accesului la asistență umană. Aceasta a reprezentat o ajustare a echilibrului dintre serviciile automatizate și cele umane, nu respingerea asistentului AI sau a tehnologiei pe care se bazează.
Dovezile publice arată de ce indicatorii de eficiență trebuie analizați împreună cu nevoile diferiților clienți și ale diverselor interacțiuni. Un sistem AI poate avea performanțe medii bune, însă unele cazuri complexe, sensibile sau neobișnuite pot necesita în continuare un canal uman accesibil.
Monitorizarea ambelor componente ale acestei relații ajută compania să decidă unde creează valoare automatizarea, unde rămâne importantă asistența umană și cum trebuie adaptat echilibrul pe măsură ce apar dovezi noi.
Alte perechi reciproc distructive pentru produsele AI pot include:
Pereche reciproc distructivă | Riscul pe care îl evidențiază |
|---|---|
Acuratețea răspunsului ↔ latența răspunsului | Un sistem care este corect din punct de vedere tehnic, dar prea lent pentru fluxul de lucru. |
Finalizarea sarcinii ↔ rata de intervenție a utilizatorului | Un flux de lucru AI care finalizează sarcini pe care utilizatorii le refac în mod repetat. |
Costul per interacțiune ↔ calitatea evaluată a rezultatului | Economii obținute prin degradarea experienței clienților sau angajaților. |
Adoptarea ↔ timpul până la obținerea valorii | Creșterea numărului de înregistrări fără o valoare corespunzătoare pentru utilizatori. |
Scopul nu este ca ambele măsurători să crească la nesfârșit. Scopul este ca acest compromis să devină vizibil înainte ca optimizarea unilaterală să creeze o problemă operațională.
O provocare similară a apărut într-o implementare de asistență pentru jucătorii unei companii de jocuri mobile. Sistemul gestiona probleme frecvente, precum pierderea progresului, litigiile privind plățile și accesul la cont.
Indicatorii de eficiență erau importanți, deoarece sistemul funcționa la scară largă. Dar serviciul de asistență pentru jucători nu este doar o simplă coadă operațională. Jucătorii sosesc adesea frustrați deoarece altceva nu a funcționat deja în experiența lor.
Această situație inițială schimbă modul în care trebuie interpretate datele privind satisfacția clienților. Un jucător a cărui problemă este rezolvată corect poate raporta totuși un nivel scăzut de satisfacție pentru că și-a pierdut progresul de la bun început. Interpretarea acelui scor fără context poate penaliza interacțiunea cu serviciul de asistență pentru frustrarea apărută anterior în parcursul clientului.
Prin urmare, echipa trebuia să facă distincția între sentimentul inițial al clientului și efectul experienței de asistență. Întrebarea mai utilă nu era „A fost mulțumit jucătorul?”, ci „A îmbunătățit interacțiunea situația față de punctul de plecare al jucătorului?”
Această comparație poate ajuta la separarea frustrării provocate de produs de calitatea asistenței, dacă echipa dispune de o modalitate fiabilă de a le măsura pe ambele.
Produsele AI se schimbă, dar metricile lor rămân adesea neschimbate.
În etapa-pilot, întrebarea centrală poate fi dacă sistemul este suficient de fiabil pentru a justifica investiții suplimentare:
Finalizează în mod fiabil sarcina principală?
Au utilizatorii suficientă încredere în el pentru a continua?
Cum se comportă în afara celor mai comune scenarii?
Pot fi identificate erorile și remediate în siguranță?
Aceste întrebări favorizează perechi precum:
succesul sarcinii principale ↔ performanța în cazurile-limită;
rata de automatizare ↔ rata de intervenție umană și
viteza de finalizare ↔ încrederea utilizatorului.
După ce produsul devine important din punct de vedere operațional, întrebările se schimbă:
Se poate extinde fără să reducă nivelul calității?
Devine mai rentabil pe măsură ce este utilizat?
Performanța rămâne stabilă pe măsură ce adoptarea crește?
Intervențiile umane au loc în situațiile potrivite?
Perechile corespunzătoare se pot orienta către:
costul per interacțiune ↔ calitatea evaluată a rezultatului;
amploarea adoptării ↔ profunzimea utilizării și
rata de automatizare ↔ expunerea la riscuri operaționale.
Metricile inițiale nu sunt neapărat greșite. Ele răspund întrebărilor care contau într-o etapă anterioară.
Riscul apare în timpul tranziției. Metricile din etapa-pilot persistă adesea deoarece echipele știu cum să le raporteze, iar nimeni nu răspunde de decizia de a renunța la ele. Măsurătorile care susțineau cândva procesul de învățare pot deveni treptat metrici de fațadă.
Prin urmare, perechile ar trebui să aibă un ciclu de viață. Echipele ar trebui să le introducă pentru o anumită decizie, să verifice dacă mai evidențiază un compromis semnificativ și să renunțe la ele când se schimbă produsul sau decizia.
Sistemele AI necesită observabilitate detaliată, alertare, asigurarea calității și evaluare. Eliminarea acestor semnale ar îngreuna operarea în siguranță a produsului. Însă monitorizarea operațională nu este același lucru cu măsurarea performanței pentru deciziile conducerii.
Monitorizarea ajută echipele să detecteze incidente, să urmărească defecțiunile și să înțeleagă comportamentul sistemului. Metricile decizionale îi ajută pe liderii de produs și de afaceri să decidă dacă investesc, intervin, schimbă direcția sau acceptă un compromis.
O organizație poate monitoriza sute de semnale tehnice și operaționale, evidențiind doar două sau trei perechi reciproc distructive pentru o anumită decizie privind produsul. Menținerea unui nivel decizional restrâns simplifică stabilirea priorităților.
Frecvența adecvată a analizelor depinde de produs. Un sistem nou sau care se schimbă rapid poate necesita revizuirea săptămânală a deciziilor, în timp ce, pentru un produs matur, o analiză lunară sau trimestrială poate fi suficientă. Principiul este mai important decât intervalul: analizează perechea de indicatori suficient de des pentru a interveni înainte ca acel compromis să devină costisitor sau să pună în pericol siguranța.
O pereche devine utilă numai când organizația stabilește ce se va întâmpla dacă aceasta se deteriorează.
Pentru aceasta, nu este suficient să definești un prag critic de divergență. Echipele ar trebui să ia în considerare trei situații:
Eșec absolut: o măsurătoare depășește un prag inacceptabil, indiferent de cealaltă.
Divergență: o măsurătoare se îmbunătățește, în timp ce contraponderea sa se deteriorează.
Deteriorare simultană: ambele componente scad, ceea ce sugerează o problemă mai amplă a produsului sau a operării.
Fiecare pereche ar trebui să aibă:
un responsabil desemnat;
o decizie clară pe care o susține;
praguri sau criterii de evaluare convenite;
o procedură de investigare și
un set de intervenții posibile.
Fără aceste elemente, organizația doar observă produsul, în loc să îl gestioneze.
Înainte de a adăuga altă măsurătoare, alege o decizie importantă privind produsul și parcurge aceste întrebări. Notează răspunsurile, astfel încât evaluarea să se încheie cu un pas următor convenit.
1. Ce decizie trebuie să ne ajute aceste metrici să luăm?
Fii precis: decidem dacă extindem automatizarea, schimbăm un model sau îmbunătățim transferul către operatorii umani? Definește decizia înainte de a alege măsurătorile.
2. Dacă acest număr se îmbunătățește, ce s-ar putea înrăutăți?
Identifică rezultatul pe care trebuie să-l protejezi și o măsurătoare care ar evidenția efectele negative. De exemplu, asociază costul per interacțiune cu calitatea evaluată a rezultatului pentru a verifica dacă răspunsurile mai ieftine rămân utile.
3. Ce ar putea ascunde cifrele principale?
Analizează ambele măsurători pentru aceiași utilizatori, aceleași sarcini și aceeași perioadă, apoi caută grupurile care obțin rezultate mai slabe. Ia în considerare și situația inițială: satisfacția redusă poate reflecta o frustrare anterioară interacțiunii cu serviciul de asistență.
4. Ce ne-ar determina să acționăm și cine răspunde de reacție?
Stabilește criterii de acțiune pentru cazurile în care o măsurătoare depășește o limită inacceptabilă, una se îmbunătățește și cealaltă se înrăutățește sau ambele se deteriorează. Stabilește cine va investiga, ce va verifica mai întâi și când va raporta rezultatele.
5. Mai corespunde această pereche etapei actuale a produsului?
Decide dacă o păstrezi, o înlocuiești sau renunți la ea. Un proiect-pilot se poate concentra pe fiabilitatea sarcinilor și încrederea utilizatorilor; un serviciu activ poate necesita o analiză mai atentă a costurilor și calității. Stabilește o dată pentru reevaluarea alegerii.
Măsurarea produselor AI ar trebui să facă mai mult decât să descrie performanța. Ar trebui să evidențieze compromisurile făcute de organizație și să clarifice următoarea decizie.