Evaluación y observabilidad de IA: la capa que convierte impresiones en evidencia

Una organización tiene tres agentes en producción. Alguien pregunta si están funcionando bien. La respuesta se construye juntando impresiones: el equipo que usa el primero está contento, del segundo hubo un par de quejas, del tercero nadie dijo nada.

Esa es la situación normal, y es insostenible por un motivo específico: los sistemas probabilísticos no se pueden evaluar por impresión. Producen resultados que varían, fallan de formas sutiles y presentan sus errores con la misma confianza que sus aciertos. La impresión promedio de un usuario sobre un sistema así tiene un valor informativo bajo.

La capa que resuelve esto tiene dos componentes: observabilidad y evaluación.

Observabilidad: poder reconstruir qué pasó

La observabilidad de un sistema con agentes va más allá de registrar la entrada y la salida. Lo que hay que capturar es el camino:

• Qué solicitud entró y de quién.
• Qué contexto se recuperó y de qué fuentes.
• Qué modelo respondió, en qué versión, con qué configuración.
• Qué herramientas invocó el agente, con qué parámetros y con qué resultado.
• Cuántos intentos hubo antes del resultado final.
• Qué costo y qué latencia tuvo cada paso.
• Qué decidió un humano, si intervino.

Con esa traza se pueden responder las preguntas que importan cuando algo sale mal: por qué el sistema respondió eso, de dónde sacó esa información, en qué paso se desvió. Sin ella, la investigación termina en “el modelo respondió eso”, que no es una explicación.

Hay además un uso preventivo que se aprovecha poco. Las trazas agregadas revelan patrones: herramientas que fallan con frecuencia, consultas que siempre requieren varios intentos, fuentes de contexto que nunca aportan nada útil. Cada patrón es una oportunidad de mejora concreta que ninguna impresión de usuario iba a señalar.

Evaluación: poder comparar versiones

El segundo componente responde una pregunta distinta: ¿esta versión es mejor que la anterior?

Un conjunto de evaluación es una colección de casos con resultado esperado y criterio de corrección. Se ejecuta contra cada versión del sistema y produce un número comparable.

Sin eso, cada cambio en un prompt, en un modelo o en la configuración es una apuesta. Se prueba con tres ejemplos, parece mejor, se despliega. Y como los sistemas probabilísticos varían entre ejecuciones, tres ejemplos no distinguen una mejora real de una casualidad favorable.

Lo que hace útil a un conjunto de evaluación no es su tamaño sino su composición. Veinte casos bien elegidos valen más que doscientos genéricos. Los criterios de una buena selección:

Casos reales, tomados de la operación, no inventados. Casos difíciles, del borde, ambiguos, donde el sistema históricamente falló. Casos donde el error es caro, aunque sean poco frecuentes. Casos que evalúan el camino, no solo la respuesta: un resultado correcto obtenido invocando herramientas indebidas es un fallo.

Un conjunto de evaluación donde el sistema acierta todo no está midiendo nada. Debe fallar en una parte.

Elegir una herramienta, no dos

En esta capa hay un mercado activo y una tentación previsible: adoptar dos plataformas porque cada una es mejor en algo.

Conviene elegir una según cuál sea el problema dominante hoy.

Si lo que pesa más son las trazas, la observabilidad en operación, la gestión de prompts y la posibilidad de alojarlo en infraestructura propia, hay opciones orientadas a eso. Si el foco inicial es la experimentación y la ejecución sistemática de evaluaciones dentro de la línea de integración continua, hay otras mejor orientadas a ese uso.

Ambas direcciones son legítimas. Adoptar las dos al mismo tiempo, con tres agentes en producción, produce dos integraciones a medias y ninguna práctica consolidada.

No encerrar la telemetría

Hay una decisión técnica con consecuencias de largo plazo: en qué formato se emite la telemetría.

Las convenciones de OpenTelemetry para sistemas generativos permiten registrar modelos, consumo, llamadas a herramientas, trazas y eventos de forma neutral respecto del proveedor. Emitir en ese formato y dejar que la herramienta de análisis lo consuma tiene una ventaja concreta: cambiar de herramienta no cuesta el historial.

Esto importa porque la comparación en el tiempo es la mayor parte del valor de estos datos. Una organización que pierde dos años de trazas al migrar pierde la capacidad de responder si el sistema mejoró, que es la pregunta para la que construyó la capa.

Cómo se define “correcto” cuando no hay respuesta única

El obstáculo práctico para construir evaluaciones es que muchas tareas no tienen una respuesta exacta contra la cual comparar. Un resumen, una redacción, una recomendación: hay muchas salidas aceptables y muchas inaceptables, sin coincidencia literal posible.

Hay cuatro formas de resolverlo, ordenadas de más confiable a menos.

Verificación determinista de propiedades. En vez de comparar el texto completo, verificar propiedades que deben cumplirse: que mencione los tres puntos obligatorios, que no exceda cierta extensión, que no incluya datos de una categoría prohibida, que el formato sea válido, que las cifras citadas coincidan con la fuente. Es la forma más confiable y cubre bastante más de lo que parece.

Comparación con casos de referencia. Un conjunto de respuestas consideradas buenas, con criterios explícitos de por qué lo son. Sirve para comparar versiones aunque no para juzgar en absoluto.

Evaluación por un modelo con rúbrica. Un modelo evalúa la salida contra criterios escritos. Es escalable y tiene un riesgo específico que conviene tener presente: hereda sesgos y puede fallar de forma correlacionada con el sistema evaluado. Debe calibrarse contra juicio humano en una muestra antes de confiar en él, y recalibrarse cuando cambien los modelos involucrados.

Juicio humano estructurado. Personas evaluando con criterios definidos. Es la referencia contra la cual se calibra todo lo demás, y no escala.

La combinación que funciona en la práctica es usar la primera para todo lo que se pueda expresar como propiedad verificable, la tercera para el resto del volumen, y la cuarta sobre una muestra pequeña que sirve para verificar que la tercera sigue siendo confiable.

Hay un error que conviene evitar desde el principio: construir la evaluación después del sistema. Los criterios de corrección definidos una vez que el sistema existe tienden a describir lo que el sistema hace, no lo que debería hacer. Escribirlos antes —o al menos con independencia de la implementación— es lo que los convierte en una vara y no en un espejo.

Por dónde empezar

La secuencia que produce valor más rápido, para una organización con agentes en producción y nada de esto implementado:

Primero, trazas del agente más importante. Aunque sea con registro estructurado propio antes de adoptar cualquier plataforma. La capacidad de reconstruir qué pasó es la más urgente porque su ausencia se paga en el primer incidente.

Segundo, veinte casos de evaluación para ese mismo agente, ejecutados a mano si hace falta. El primer resultado suele ser instructivo: es común descubrir que el sistema falla en una proporción de casos considerablemente mayor de la que la impresión general sugería.

Tercero, automatizar esa ejecución para que corra ante cada cambio.

Cuarto, elegir la plataforma, con la ventaja de saber ya qué se necesita porque se estuvo haciendo a mano.

Ese orden tiene una virtud: en cada paso hay algo funcionando. La secuencia inversa —elegir plataforma, integrarla, después definir qué medir— es la que produce herramientas implementadas que nadie usa.