Cómo calificamos un sistema multi-agente.

Si le preguntas a la mayoría de los equipos que construyen IA multi-agente cuál es su problema más difícil, dirán orquestación, o recuperación, o costo. Esos son difíciles. Pero el problema genuinamente más difícil — el que decide si la empresa sobrevive — es la evaluación: saber si un cambio dejó al sistema mejor o peor.

Con software ordinario lo sabes. La suite de tests está verde o roja. El diff es revisable. Con un sistema multi-agente la salida es no determinista — hazle la misma pregunta al mismo agente dos veces y obtienes dos respuestas válidas distintas. No puedes diffear una salida no determinista. Así que '¿este cambio ayudó?' se vuelve un problema real de medición, y la mayoría de los equipos lo responden por vibra — lanzan, le echan un ojo a unas pocas corridas, esperan. Eso no escala más allá de unos diez clientes. Este es el harness de evaluación que corremos en GOGOGO LLC en su lugar.

La regla central: cada paso de agente se califica

El harness no es un archivo de test aparte que corres antes de lanzar. Es parte del runtime. Cada invocación de agente — en desarrollo, en CI, y una fracción muestreada en producción — se califica automáticamente por un panel de evaluadores. La calificación se adjunta al trace_id de la corrida y se escribe en el log de eventos junto a la salida.

Esto importa porque cambia lo que una evaluación es. Una evaluación no es una compuerta que pasas una vez antes de lanzar. Es una propiedad continua de cada corrida que el sistema ha hecho jamás. Cuando un cliente reporta un mal resultado, no reproducimos-y-adivinamos — sacamos el trace_id, leemos las calificaciones de cada paso de esa corrida exacta, y vemos qué agente falló qué evaluador. El harness de evaluación es también el debugger.

Las cuatro clases de evaluador

Corremos cuatro tipos de evaluador. Cada salida de agente pasa por los que de los cuatro apliquen a su tipo.

1 · Validez de esquema

El evaluador más barato, más estricto y más saltado. Cada agente del runtime declara un contrato de salida tipado — un esquema de pydantic. El evaluador de validez de esquema chequea la salida literal contra él: campos correctos, tipos correctos, nada de nulls donde no se permiten, enums dentro de rango. Es un booleano. Corre en el 100% de las llamadas porque es casi gratis. Una fracción sorprendente de los incidentes de 'la IA se equivoca' son en realidad 'la IA devolvió texto que parece válido pero no parsea' — la validez de esquema los caza antes de que sean un problema del cliente.

2 · Fundamentación

Para cualquier agente que recupera — los agentes de recuperación y reranker — el evaluador de fundamentación pregunta: ¿cada afirmación factual de la salida está realmente respaldada por un documento recuperado? Lo corre un modelo aparte, más pequeño, cuyo único trabajo es el chequeo de implicación: afirmación X, fuente Y, ¿Y respalda a X — sí o no? Los fallos de fundamentación son la señal de alerta temprana del drift de recuperación. Cuando el corpus cambia y los puntajes de fundamentación caen, lo sabemos antes que el cliente.

3 · Chequeo de alucinación

Distinto de la fundamentación. La fundamentación pregunta '¿la afirmación está respaldada?'; el evaluador de alucinación pregunta '¿el agente inventó una entidad, un número, una capacidad o una cita que no existe en ningún lado?'. Esto se corre sobre agentes generadores — los que producen texto libre. Es el evaluador más importante para la confianza del cliente, y el que los equipos más seguido saltan porque hace que el sistema parezca fallar más seguido. No falla más seguido. Los fallos siempre estuvieron ahí; el evaluador los hace visibles.

4 · Reproducibilidad

El meta-evaluador. Pregunta: dado el trace_id de esta corrida, ¿se puede reejecutar la corrida entera de forma determinista desde los inputs logueados y producir la misma trayectoria (no necesariamente el mismo texto — la misma secuencia de llamadas a agentes y a herramientas)? Una corrida que no se puede reproducir no se puede depurar, no se puede auditar y no se puede usar como fixture de regresión. Los fallos de reproducibilidad son bugs de infraestructura, y los tratamos como bloqueantes del lanzamiento incluso cuando la salida se veía bien.

Cómo se juzga un cambio

Cuando un ingeniero propone un cambio — un prompt nuevo, un modelo intercambiado, un reranker reajustado — no se lanza porque se vea mejor. Se lanza porque corre contra un set de evaluación congelado: unos cientos de corridas reales grabadas con calificaciones conocidas-buenas. Se aplica el cambio, se vuelve a correr el set de evaluación, y se comparan los cuatro puntajes de evaluador antes vs. después.

1. Los cuatro puntajes se mantienen o mejoran → se lanza.
2. Un puntaje mejora, otro retrocede → el cambio es un trade-off, y va a una decisión humana con los números exactos sobre la mesa — nunca a ojo.
3. Cualquier puntaje retrocede sin que nada mejore → el cambio se rechaza automáticamente. No importa qué tan bien se haya visto el demo.

Esta es la disciplina que le permite a un equipo pequeño lanzar cuatro productos sobre un runtime sin que la calidad se erosione en silencio. Cada cambio tiene un número adjunto. Los números son comparables entre Goddo, GoPeople, GoVista y GoTrack porque todos corren el mismo harness.

Por qué una evaluación que falla es una feature

La razón más común por la que los equipos no construyen un harness de evaluación de verdad es emocional, no técnica. Un buen harness hace que tu sistema parezca peor — el dashboard se enciende de fallos. A ingenieros y fundadores no les gusta ese dashboard, porque se siente como que el sistema está roto.

Pero los fallos siempre estuvieron ahí. El harness no los creó; los sacó a la superficie. Un sistema multi-agente sin harness de evaluación no es un sistema que falla menos — es un sistema que falla de forma invisible, lo que significa que falla en el cliente. Una evaluación que falla es el lugar más barato donde puede ocurrir un fallo. Es una feature. Que el dashboard se ponga rojo en CI es el sistema funcionando exactamente como fue diseñado.

“No puedes mejorar lo que no puedes medir, y no puedes medir una salida no determinista mirándola. El harness de evaluación no es infraestructura de test atornillada a un sistema multi-agente. Es la parte del sistema que le permite al resto tener una dirección.”

Por dónde empezar si no tienes nada

Si estás construyendo IA multi-agente y no tienes harness de evaluación, no intentes construir los cuatro evaluadores de una. Empieza con la validez de esquema — es casi gratis, es booleana, y cazará de inmediato una clase de bug que ahora mismo le estás lanzando a los clientes. Después agrega la reproducibilidad, porque sin ella no puedes construir un set de regresión. La fundamentación y la alucinación vienen tercera y cuarta, una vez que tengas presupuesto de modelo para ellas. Un evaluador corriendo en el 100% de las llamadas le gana a cuatro evaluadores que todavía estás diseñando.

Si quieres comparar notas sobre harness de evaluación — diseño de evaluadores, tasas de muestreo, cómo construir el set de evaluación congelado — soy fácil de encontrar. atakanozalan.com o [email protected].