Evaluación y observabilidad

Evals

Una eval (evaluación) es un conjunto de casos de prueba con criterios para medir si el sistema de IA responde bien: entradas representativas y, para cada una, la respuesta esperada o las condiciones que debe cumplir. Es el equivalente de los tests automáticos, adaptado a salidas que no son deterministas.

Sin evals, cada cambio de prompt, de modelo o de parámetros es una apuesta: lo que mejora un caso puede romper diez. Con un conjunto de unas pocas decenas de casos reales (incluidos los que ya han fallado alguna vez), puedes comparar versiones con números antes de desplegarlas. Los mejores casos salen de producción: cada error detectado es un caso nuevo.

LLM-as-a-judge

LLM-as-a-judge es usar un modelo para evaluar las respuestas de otro (o del mismo) según unos criterios: si la respuesta es correcta, si cita la fuente, si el tono es adecuado o si respeta la política de la empresa. Sirve cuando la respuesta es texto libre y no se puede comparar con un valor exacto.

Es práctico, pero tiene sesgos conocidos: tiende a preferir las respuestas largas, las de su mismo modelo y la primera opción cuando compara dos. Funciona mejor con criterios concretos y puntuaciones simples (sí o no, de 1 a 3) que con notas del 1 al 10, y conviene calibrarlo de vez en cuando con revisiones humanas.

Tracing y logging

El tracing registra cada paso de una petición de IA como una traza: el prompt enviado, la respuesta, las llamadas a herramientas, los documentos recuperados, los tokens y el tiempo de cada paso. En un sistema con RAG y agentes, una sola respuesta puede implicar diez llamadas, y sin traza es imposible saber dónde se ha torcido.

Hay herramientas específicas (Langfuse, LangSmith, Arize Phoenix o el estándar OpenTelemetry), pero también se puede empezar con una tabla en la base de datos. Lo importante es poder responder, días después, «¿por qué el asistente le dijo esto a este cliente?». Cuidado con los datos personales: las trazas también son datos y hay que protegerlas.

Latencia

La latencia es el tiempo que tarda el sistema en responder. En los LLMs se mide sobre todo con dos métricas: el tiempo hasta el primer token (cuando el usuario empieza a ver algo) y el tiempo total de generación, que crece con la longitud de la respuesta.

Depende del modelo (los grandes y los de razonamiento son más lentos), del tamaño del contexto y de cuántas llamadas encadenas. Las palancas principales son elegir un modelo más pequeño para las tareas simples, reducir el contexto, hacer las llamadas independientes en paralelo y usar streaming (Módulo 7) para que la espera se note menos.

Coste por token

Los proveedores cobran por token de entrada y por token de salida, normalmente con la salida varias veces más cara. El coste de una funcionalidad es, por tanto, los tokens por llamada multiplicados por las llamadas por uso y por el número de usos, y cada uno de estos factores puede crecer sin que nadie se dé cuenta.

Hay que medirlo por funcionalidad, y no solo como total mensual, para saber qué cuesta cada cosa y si compensa. Las palancas son modelos más baratos para las tareas simples, contextos más cortos, prompt caching (Módulo 7), procesamiento por lotes cuando no hay prisa y evitar llamadas innecesarias con filtros previos.

Throughput

El throughput es la cantidad de trabajo que el sistema puede procesar por unidad de tiempo: peticiones por minuto o tokens por minuto. En IA, el límite a menudo no es tu servidor, sino los límites de velocidad que el proveedor impone a tu cuenta.

Importa cuando procesas volumen: clasificar miles de tickets, indexar una base de conocimiento o atender picos de tráfico. Las herramientas para gestionarlo son las colas con una concurrencia controlada, el procesamiento por lotes, el reparto de la carga entre modelos o proveedores y, cuando hace falta, pedir límites más altos al proveedor.