Avaluació i observabilitat

Evals

Una eval (avaluació) és un conjunt de casos de prova amb criteris per mesurar si el sistema d'IA respon bé: entrades representatives i, per a cadascuna, la resposta esperada o les condicions que ha de complir. És l'equivalent dels tests automàtics, adaptat a sortides que no són deterministes.

Sense evals, cada canvi de prompt, de model o de paràmetres és una aposta: el que millora un cas en pot trencar deu. Amb un conjunt d'unes quantes desenes de casos reals (inclosos els que ja han fallat alguna vegada), pots comparar versions amb números abans de desplegar-les. Els millors casos surten de producció: cada error detectat és un cas nou.

LLM-as-a-judge

LLM-as-a-judge és fer servir un model per avaluar les respostes d'un altre (o del mateix) segons uns criteris: si la resposta és correcta, si cita la font, si el to és adequat o si respecta la política de l'empresa. Serveix quan la resposta és text lliure i no es pot comparar amb un valor exacte.

És pràctic, però té biaixos coneguts: tendeix a preferir les respostes llargues, les del seu mateix model i la primera opció quan en compara dues. Funciona millor amb criteris concrets i puntuacions simples (sí o no, d'1 a 3) que amb notes de l'1 al 10, i convé calibrar-lo de tant en tant amb revisions humanes.

Tracing i logging

El tracing registra cada pas d'una petició d'IA com una traça: el prompt enviat, la resposta, les crides a eines, els documents recuperats, els tokens i el temps de cada pas. En un sistema amb RAG i agents, una sola resposta pot implicar deu crides, i sense traça és impossible saber on s'ha torçat.

Hi ha eines específiques (Langfuse, LangSmith, Arize Phoenix o l'estàndard OpenTelemetry), però també es pot començar amb una taula a la base de dades. L'important és poder respondre, dies després, «per què l'assistent va dir això a aquest client?». Compte amb les dades personals: les traces també són dades i s'han de protegir.

Latència

La latència és el temps que tarda el sistema a respondre. En els LLMs es mesura sobretot amb dues mètriques: el temps fins al primer token (quan l'usuari comença a veure alguna cosa) i el temps total de generació, que creix amb la longitud de la resposta.

Depèn del model (els grans i els de raonament són més lents), de la mida del context i de quantes crides encadenes. Les palanques principals són triar un model més petit per a les tasques simples, reduir el context, fer les crides independents en paral·lel i fer servir streaming (Mòdul 7) perquè l'espera es noti menys.

Cost per token

Els proveïdors cobren per token d'entrada i per token de sortida, normalment amb la sortida diverses vegades més cara. El cost d'una funcionalitat és, doncs, els tokens per crida multiplicats per les crides per ús i pel nombre d'usos, i cadascun d'aquests factors pot créixer sense que ningú se n'adoni.

Cal mesurar-lo per funcionalitat, i no només com a total mensual, per saber què costa cada cosa i si compensa. Les palanques són models més barats per a les tasques simples, contextos més curts, prompt caching (Mòdul 7), processament per lots quan no hi ha pressa i evitar crides innecessàries amb filtres previs.

Throughput

El throughput és la quantitat de feina que el sistema pot processar per unitat de temps: peticions per minut o tokens per minut. En IA, el límit sovint no és el teu servidor, sinó els límits de velocitat que el proveïdor imposa al teu compte.

Importa quan processes volum: classificar milers de tiquets, indexar una base de coneixement o atendre pics de trànsit. Les eines per gestionar-lo són les cues amb una concurrència controlada, el processament per lots, el repartiment de la càrrega entre models o proveïdors i, quan cal, demanar límits més alts al proveïdor.