Com mesurar si la IA del teu producte funciona: evals i cost per tasca útil

Tota empresa de programari que fica IA al seu producte arriba, tard o d'hora, a la mateixa pregunta incòmoda: això funciona de veritat, o només ho sembla? I a una segona, encara més incòmoda quan arriba la factura: ens surt a compte? La majoria d'equips no pot respondre cap de les dues amb dades, perquè van mesurar la IA com es mesura una feature normal —"passa els tests, surt"— quan la IA generativa exigeix mesurar diferent. Aquesta és la guia pràctica de què mesurar, com instrumentar-ho i quina decisió prendre amb el resultat. No és teoria: és el que separa una feature d'IA que aguanta en producció d'una que corre de pressa cap al mur.

Per què "funciona" no és una mètrica

El programari tradicional és determinista: la mateixa entrada dona la mateixa sortida, i un test que passa avui passa demà. La IA generativa no funciona així. La mateixa pregunta pot donar respostes diferents; una resposta pot sonar impecable i ser falsa; i el model pot degradar-se quan el proveïdor l'actualitza sense avisar. Per això el "sembla que funciona" de la demo és traïdor: la demo la fas tu, amb el cas feliç i el prompt afinat, i la producció l'usen milers de clients amb dades que no vas anticipar.

El símptoma clàssic: una feature d'IA que va impressionar a la review interna i, tres setmanes després de sortir, acumula queixes de suport per respostes inventades, mentre la factura de tokens s'ha triplicat i ningú sap explicar per què. No és que la IA no serveixi. És que es va llançar sense instrumentar, i "funciona" era una sensació, no un número. Mesurar bé no és un luxe de maduresa: és el requisit perquè la IA del teu producte sigui operable, governable i rendible.

Les dues úniques mètriques que importen

Es pot instrumentar una feature d'IA amb cinquanta panells i no entendre res. La disciplina consisteix a reduir a l'essencial. Hi ha dues mètriques que governen la decisió; la resta són diagnòstiques.

Fixa't que les dues estan acoblades per la paraula "útil": no compta un output barat que està malament, ni un de correcte que ningú va fer servir. La intersecció —correcte i usat— és on viu el valor. Tota la resta (latència, tokens, taxa d'error per tipus) és diagnòstic: t'ajuda a millorar, però no és el criteri de decisió.

Com muntar evals que sí que serveixen

Una eval és una manera automàtica i reproduïble de respondre "aquesta sortida és correcta?". Sense evals, la qualitat la jutja qui mira la demo aquell dia, amb el seu criteri i el seu estat d'ànim. Amb evals, el criteri és explícit, versionat i executable a cada canvi. No totes les evals són iguals; es munten per nivells, del més barat al més car:

La regla que evita l'autoengany: l'eval s'escriu abans que la feature. Si no saps com decidiràs que una sortida és correcta, no estàs a punt per construir-la — estàs a punt per fer una altra demo. I una mètrica honesta per sobre de l'encert mitjà: pass@k (en quants intents el sistema produeix almenys una sortida correcta?) davant de la taxa d'encert a la primera; et diu si el problema és de capacitat o de consistència, que s'arreglen diferent.

Com mesurar el cost per tasca útil (amb números)

L'error més comú de cost és mesurar cost per crida o cost per usuari. Cap dels dos et diu si la feature és rendible. La mètrica correcta és el cost per tasca útil: el que costa produir un resultat que va passar l'eval i es va fer servir. La fórmula:

Un exemple concret per veure-ho:

• Una feature d'assistent al teu SaaS consumeix 500 € al mes en tokens.
• Genera 20.000 respostes al mes. Però el 70% passa l'eval (14.000 correctes) i, d'aquestes, l'usuari usa el 60% (8.400 útils).
• Cost per tasca útil = 500 € ÷ 8.400 = 0,06 € per resultat útil.

Ara la decisió és possible: si cada resultat útil estalvia al client 2 € de feina manual o millora la retenció, 0,06 € és una ganga. Si la feature és cosmètica, potser no. I fixa't en l'apalancament: pujar la taxa d'encert del 70% al 85% abaixa el cost per tasca útil un 18% sense tocar el model — és mètode (millor context, millor eval), no un model més car. Aquesta és exactament la feina de l'enginyeria de context.

El tauler mínim: què mirar cada setmana

No necessites un centre de comandament. Necessites cinc línies que un Head of Product i un CTO puguin llegir en un minut i sobre les quals es pugui decidir:

1. % de sortides que passen l'eval (qualitat verificada). Tendència: puja, baixa, es manté?
2. Cost per tasca útil, amb la seva tendència. És la mètrica de rendibilitat.
3. % d'outputs útils usats (adopció real de la feature). Si és baix, potser el problema no és la IA: és que la feature no importa.
4. Deriva de qualitat després de canvis del proveïdor: una caiguda del pass rate sense que tu toquis res = el model ha canviat. Sense aquest panell, te n'assabentes per suport.
5. Cua d'errades etiquetades: els casos que van fallar, agrupats per tipus. És el backlog de millora — i alimenta el dataset daurat.

Quan una feature d'IA mereix seguir viva

Mesurar serveix per decidir. Amb les dues mètriques i el tauler, cada feature d'IA cau en un de quatre quadrants, i cadascun té una acció clara:

Aquí també es resol el build vs. buy: per a les peces del quadrant "alta qualitat, cost alt" que no aconsegueixes optimitzar dins del teu producte, l'alternativa honesta és delegar l'execució a un proveïdor que assumeixi el risc de model i de pricing al contracte, no a la teva factura. Construeixes el que et diferencia; treus del teu cost variable el que no.

Les errades que rebenten la mesura

• Mesurar l'encert mitjà en lloc de per cas. Un 90% d'encert amb el 10% d'errades concentrades al teu cas d'ús més important és un producte trencat que sembla sa.
• Evals que s'autoaproven. Un LLM-as-judge sense calibratge humà acaba premiant l'estil del model que jutja. Mostreja sempre amb humans.
• Mesurar cost per crida, no per tasca útil. Optimitzes per fer crides barates que no serveixen en lloc de resultats que sí.
• No vigilar la deriva del proveïdor. El model canvia sota els teus peus; sense el panell de deriva, la teva qualitat baixa i ho atribueixes als usuaris.
• Instrumentar al final. El cost i les evals es munten amb el primer prototip, no quan arriba la primera factura sorpresa.

Preguntes freqüents

Com sé si la IA del meu producte SaaS funciona de veritat?

Amb evals reproduïbles que mesurin si la sortida és correcta segons un criteri explícit (no "sona bé"), combinades amb el senyal real de l'usuari en producció. "Sembla que funciona" és una impressió; el % de sortides que passen l'eval, amb la seva tendència, és una dada. Sense evals, cada release és una aposta i les errades es descobreixen tard, en producció.

Què és el cost per tasca útil i per què és la mètrica que importa?

És el que costa produir un resultat que va passar l'eval i es va fer servir de veritat: crèdits consumits ÷ outputs correctes i usats. A diferència del cost per crida o per usuari, et diu si la feature és rendible i permet decidir build vs. buy. Pujar la qualitat abaixa el cost per tasca útil sense tocar el model: és mètode, no un model més car.

Necessito muntar evals encara que la meva feature d'IA sigui senzilla?

Sí, encara que siguin del nivell més barat (regles deterministes + un petit dataset daurat). Sense una manera automàtica de saber si una sortida és correcta, no pots posar la feature en producció amb garanties ni detectar quan el model es degrada. L'eval s'escriu abans que la feature: si no saps com decidir que funciona, encara no estàs a punt per construir-la.

Cada quant reviso aquestes mètriques?

Setmanalment per al tauler de decisió (pass rate, cost per tasca útil, adopció, deriva del proveïdor, cua d'errades) i a cada release/canvi de model per al dataset daurat a CI. La deriva del proveïdor obliga a vigilància contínua: un model pot canviar sense avisar i la teva qualitat caure sense que tu toquis res.

Conclusió

La IA del teu producte no es governa amb impressions: es governa amb dos números. La qualitat verificada et diu si funciona; el cost per tasca útil et diu si surt a compte. Amb aquests dos i un tauler de cinc línies, la decisió d'escalar, optimitzar, arreglar o matar una feature d'IA deixa de ser una opinió de sala i passa a ser una lectura de dades. I gairebé sempre, la palanca per millorar els dos números no és un model més car: és mètode —context del teu producte i verificació a cada pas—, que és exactament el que fa que la IA passi de la demo a producció i s'hi quedi rendible.

Si tens features d'IA en producció sense instrumentar —o vols muntar-les bé des del principi— comença per un diagnòstic: en unes setmanes tens les evals, el cost per tasca útil i el tauler de decisió funcionant, i saps quines features escalar i quines redissenyar. I si ets una empresa de programari o SaaS, aquí tens el nostre enfocament complet: IA per a empreses de programari i SaaS.