Afegir mètriques no millora necessàriament la comprensió. Molts quadres de comandament contenen diverses mesures del mateix comportament subjacent. Les mètriques són més útils per al diagnòstic quan es combinen en parelles destructives mútuament: cost i qualitat, contenció i percepció del client o precisió i latència.
Les parelles adequades canvien a mesura que un producte d'IA passa del pilot a la producció. El mesurament ha de respondre a les decisions que l'equip necessita prendre en cada etapa.
La supervisió operativa i el mesurament estratègic tenen finalitats diferents. Els equips poden monitorar centenars de senyals del sistema i utilitzar només unes quantes parelles per orientar les decisions de producte.
Les mètriques principals poden explicar una història convincent sense resoldre una decisió important sobre el producte.
L'assistent d'IA de Klarna es va associar públicament a més rendiment, menys costos i puntuacions de satisfacció comparables a les dels agents humans. L'any següent, l'empresa va decidir ampliar l'accés al suport humà, i el seu conseller delegat va reconèixer que s'havia posat massa èmfasi en la reducció de costos.
Això no va suposar rebutjar l'assistent d'IA ni la seva tecnologia subjacent. Va ser un ajustament de l'equilibri entre l'automatització i el servei humà a mesura que l'empresa aprenia d'operar el producte. A mesura que l'automatització assumia més consultes senzilles i de gran volum, els agents humans que necessitava Klarna eren aquells equipats per a casos complexos i delicats.
Després d'haver definit des del principi què ha d'aconseguir un producte, la majoria d'organitzacions que creen productes d'IA acaben afrontant la mateixa pregunta: funciona de debò?
Si la resposta no és clara, l'impuls habitual és afegir més mètriques. Tres es converteixen en deu, i després deu en trenta. El quadre de comandament s'enriqueix, però potser l'equip no ho entén millor.
El problema no sempre és la qualitat de cada mesura, sinó la relació entre aquestes. La satisfacció del client, el Net Promoter Score, les ressenyes i els percentatges de valoracions positives poden aportar senyals útils, però també poden reflectir canvis semblants en la percepció general. Quan evolucionen alhora, confirmen que ha passat alguna cosa, però no n'expliquen necessàriament el motiu.
Per tant, els equips d'IA han d'anar més enllà de les mètriques que coincideixen i identificar mesures que revelin resultats contraposats. Aquestes parelles destructives mútuament revelen les contrapartides del rendiment del producte i n'ajuden a supervisar l'impacte, cosa que permet prendre millors decisions.
En un desplegament previ al llançament, l'equip conjunt desenvolupava un agent de veu amb IA en temps real per atendre trucades entrants de suport al client. Una de les preguntes més difícils no tenia a veure amb la selecció ni amb l'orquestració del model. Era com sabria l'organització si el producte funcionava quan els clients comencessin a utilitzar-lo a gran escala.
El marc inicial utilitzava tres mesures:
Taxa de contenció: freqüència amb què la IA resol una trucada sense transferir-la a una persona.
Taxa d'escalat: freqüència amb què una trucada es transfereix a un agent humà.
Taxa de resolució: freqüència amb què el problema del client s'acaba resolent.
Cada mesura era raonable. Tanmateix, juntes no podien respondre a una pregunta òbvia: si augmenta l'escalat, això què ens indica?
L'equip va desglossar l'escalat en vuit subtipus. Després va afegir mesures d'abandonament, recorregut i temps, puntuacions de comprensió lingüística i resolució per tipus de consulta. Finalment, el marc contenia 31 mètriques repartides en sis categories.
Podia descriure detalladament l'escalat, però encara no en podia diagnosticar la causa de manera fiable. La majoria de les mètriques eren variacions del mateix comportament, de manera que evolucionaven alhora en comptes de contrastar explicacions contraposades.
El quadre de comandament havia passat a ser observacional en comptes de diagnòstic.
L'equip no necessitava una altra capa de desglossament, sinó mètriques que es limitessin mútuament.
Les anomenem parelles destructives mútuament: dues mesures en què millorar-ne una de manera aïllada pot perjudicar el resultat representat per l'altra. El nom descriu el tipus d'error que crea una optimització unilateral, no pas l'estat desitjat.
Quan totes dues parts es mantenen en bon estat, és possible que el producte funcioni de manera sostenible. Quan divergeixen, la direcció d'aquesta divergència ajuda l'equip a decidir què ha d'investigar.
Què teníem | Parella destructiva mútuament | Què pot revelar la parella |
|---|---|---|
Taxa d'escalat dividida en vuit subtipus | Taxa d'escalat ↔ temps fins a l'escalat | Un escalat immediat pot indicar un problema de confiança o de plantejament; un escalat posterior pot indicar que el sistema no pot completar la tasca. |
Taxa de contenció i taxa de resolució presentades per separat | Taxa de contenció ↔ percepció del client | Si la contenció representa una resolució satisfactòria o bé l'abandonament de l'intent per part del client. |
Taxa de resolució per tipus d'intenció | Taxa de resolució ↔ profunditat de la conversa | Si la resolució satisfactòria és eficient o requereix una interacció esgotadora. |
Per aprofundir en com es manifesta això i què cal fer amb aquesta informació, considerem la taxa d'escalat i el temps fins a l'escalat. L'equip no sabrà com es comporten els clients fins que arribin trucades reals, però pot definir les hipòtesis que necessita comprovar.
Si es comencen a escalar més trucades i els clients abandonen l'experiència amb IA durant els primers 30 segons, l'equip ha d'investigar la confiança, la informació facilitada, el to i les interaccions inicials. Si els clients escalen després de dedicar diversos minuts a intentar completar una tasca, és més probable que el problema sigui la capacitat o la cobertura del flux de treball.
La xifra principal d'escalat és la mateixa. La decisió sobre el producte és diferent.
Una parella útil no demostra per si sola la causa. Acota la investigació i aclareix la propera decisió.
L'exemple anterior de Klarna mostra com s'aplica aquest principi quan interactuen el cost i la qualitat del servei. Mostra com un model operatiu basat en IA pot evolucionar mentre una empresa supervisa l'impacte de les contrapartides i aprèn del desplegament.
El febrer de 2024, l'empresa va informar que el seu assistent d'IA havia gestionat 2,3 milions de converses durant el primer mes, havia fet una feina equivalent a la de 700 agents a temps complet i havia assolit puntuacions de satisfacció comparables a les dels agents humans. Klarna estimava que l'assistent contribuiria a millorar els beneficis en 40 milions de dòlars durant el 2024. Eren resultats publicats per la mateixa Klarna, no pas una avaluació independent.
El maig de 2025, el conseller delegat de Klarna va afirmar que l'empresa havia posat massa èmfasi en la reducció de costos del servei al client i va explicar que preveia ampliar l'accés al suport humà. Això representava un ajust de l'equilibri entre el servei automatitzat i l'humà, no pas un rebuig de l'assistent d'IA ni de la tecnologia subjacent.
Les dades públiques il·lustren per què les mesures d'eficiència s'han de considerar juntament amb les necessitats dels diferents clients i interaccions. Un sistema d'IA pot obtenir un bon rendiment mitjà, tot i que alguns casos complexos, sensibles o poc habituals encara es beneficiïn d'un canal humà accessible.
Supervisar totes dues parts de la relació ajuda l'empresa a decidir on aporta valor l'automatització, on continua sent important el suport humà i com ha de canviar l'equilibri a mesura que apareixen dades noves.
Altres parelles destructives mútuament dels productes d'IA poden ser:
Parella destructiva mútuament | Risc que ajuda a revelar |
|---|---|
Precisió de la resposta ↔ latència de la resposta | Un sistema tècnicament precís, però massa lent per al flux de treball. |
Finalització de tasques ↔ taxa de correcció per part de l'usuari | Un flux de treball amb IA que completa tasques que els usuaris refan repetidament. |
Cost per interacció ↔ qualitat avaluada dels resultats | Estalvis aconseguits a costa de degradar l'experiència del client o de l'empleat. |
Adopció ↔ temps fins a obtenir valor | Augment dels registres sense un valor corresponent per als usuaris. |
L'objectiu no és fer que totes dues mesures augmentin indefinidament, sinó fer visible la contrapartida abans que una optimització unilateral generi un problema operatiu.
En un desplegament de suport als jugadors d'una empresa de jocs per a mòbils va sorgir un repte relacionat. El sistema gestionava problemes molt freqüents, com ara la pèrdua de progrés, les disputes de pagament i l'accés al compte.
Les mesures d'eficiència eren importants perquè el sistema funcionava a gran escala. Però el suport als jugadors no és simplement una cua operativa. Els jugadors solen arribar frustrats perquè ja hi ha hagut algun problema en un altre punt de la seva experiència.
Aquest punt de partida canvia la manera d'interpretar les dades de satisfacció del client. Un jugador pot indicar una satisfacció baixa encara que el seu problema s'hagi resolt correctament, perquè d'entrada havia perdut el progrés. Interpretar aquesta puntuació sense context pot penalitzar la interacció de suport per una frustració generada abans en el recorregut del client.
Per tant, l'equip havia de distingir la percepció inicial del client de l'efecte de l'experiència de suport. La pregunta més útil no era "El jugador estava content?" sinó "La interacció va millorar la situació respecte del punt de partida del jugador?".
Aquesta comparació pot ajudar a separar la frustració amb el producte de la qualitat del suport, sempre que l'equip disposi d'una manera fiable de mesurar totes dues coses.
Els productes d'IA canvien, però sovint les seves mètriques es mantenen fixes.
Durant un pilot, la pregunta central pot ser si el sistema és prou fiable per justificar continuar-hi invertint:
Completa de manera fiable la tasca principal?
Els usuaris hi confien prou per continuar?
Com es comporta fora dels escenaris més habituals?
Es poden identificar els errors i se'n pot fer la recuperació de manera segura?
Aquestes preguntes afavoreixen parelles com ara:
èxit en la tasca principal ↔ rendiment en casos límit,
taxa d'automatització ↔ taxa de correcció humana i
velocitat de finalització ↔ confiança de l'usuari.
Quan el producte adquireix importància operativa, les preguntes canvien:
Pot escalar sense reduir la qualitat?
La seva rendibilitat millora amb l'ús?
El rendiment es manté estable a mesura que creix l'adopció?
Les intervencions humanes es produeixen en els llocs adequats?
Les parelles corresponents poden passar a ser:
cost per interacció ↔ qualitat avaluada dels resultats,
abast de l'adopció ↔ profunditat d'ús i
taxa d'automatització ↔ exposició al risc operatiu.
Les mètriques inicials no són necessàriament errònies. Responen les preguntes que eren importants en una etapa anterior.
El risc apareix durant la transició. Les mètriques del pilot solen mantenir-se perquè els equips saben com presentar-les i ningú no és responsable de decidir retirar-les. Les mesures que abans afavorien l'aprenentatge poden convertir-se gradualment en mètriques de vanitat.
Per tant, les parelles han de tenir un cicle de vida. Els equips han d'introduir-les per a una decisió concreta, revisar si encara revelen una contrapartida significativa i retirar-les quan canviïn el producte o la decisió.
Els sistemes d'IA requereixen observabilitat detallada, alertes, control de qualitat i avaluació. Eliminar aquests senyals dificultaria operar el producte de manera segura. Però la supervisió operativa no és el mateix que el mesurament per a la direcció.
La supervisió ajuda els equips a detectar incidències, a rastrejar errors i a entendre el comportament del sistema. Les mètriques de decisió ajuden els responsables de producte i negoci a decidir si cal invertir, intervenir, canviar de direcció o acceptar una contrapartida.
Una organització pot supervisar centenars de senyals tècnics i operatius, però destacar només dues o tres parelles destructives mútuament per a una decisió concreta de producte. El fet de mantenir reduïda aquesta capa de decisió facilita la priorització.
La freqüència de revisió adequada depèn del producte. Un sistema nou o que canvia ràpidament pot requerir revisions setmanals de les decisions, mentre que un producte madur pot admetre una freqüència mensual o trimestral. El principi és més important que l'interval: cal revisar la parella prou sovint per actuar abans que la contrapartida resulti cara o insegura.
Una parella només és útil quan l'organització acorda què passarà si es deteriora.
Això exigeix més que definir una línia vermella per a la divergència. Els equips han de considerar tres condicions:
Fallada absoluta: una mesura supera un llindar inacceptable, independentment de l'altra.
Divergència: una mesura millora mentre es deteriora la que la compensa.
Deteriorament conjunt: totes dues parts empitjoren, cosa que apunta a un problema més ampli del producte o de les operacions.
Cada parella ha de tenir:
un responsable designat,
una decisió clara a la qual dona suport,
llindars o criteris d'avaluació acordats,
un procés d'investigació i
un conjunt de possibles intervencions.
Sense aquests elements, l'organització observa el producte en comptes de gestionar-lo.
Abans d'afegir una altra mesura, tria una decisió important sobre el producte i respon a aquestes preguntes. Anota les respostes perquè la revisió acabi amb un proper pas acordat.
1. Quina decisió ens han d'ajudar a prendre aquestes mètriques?
Decanta't per la concreció: decidim si cal ampliar l'automatització, canviar un model o millorar la transferència a una persona? Defineix la decisió abans de triar les mesures.
2. Si aquesta xifra millora, què podria empitjorar?
Identifica el resultat que cal protegir i una mesura que reveli qualsevol perjudici. Per exemple, combina el cost per interacció amb la qualitat avaluada dels resultats per comprovar si les respostes més barates continuen sent útils.
3. Què podrien ocultar les xifres principals?
Analitza totes dues mesures per als mateixos usuaris, tasques i període, i després cerca grups que obtinguin pitjors resultats. Considera també les condicions inicials: una satisfacció baixa pot reflectir una frustració anterior a la interacció de suport.
4. Què ens faria actuar i qui és responsable de la resposta?
Estableix criteris per actuar quan una mesura superi un límit inacceptable, una millori mentre l'altra empitjora o totes dues es deteriorin. Acorda qui ho investigarà, què comprovarà primer i quan en presentarà els resultats.
5. Aquesta parella encara s'ajusta a l'etapa actual del producte?
Decideix si cal mantenir-la, substituir-la o retirar-la. Un pilot pot centrar-se en la fiabilitat de les tasques i la confiança dels usuaris; un servei en producció pot requerir un control més estricte del cost i la qualitat. Fixa una data per tornar a revisar la decisió.
El mesurament dels productes d'IA ha de fer més que descriure'n el rendiment: ha de revelar les contrapartides que assumeix l'organització i aclarir la propera decisió.