Estrategia Code-First: Cómo monday Service Optimiza la Evaluación de Agentes de IA con LangSmith

En el actual panorama de la Inteligencia Artificial generativa, muchas organizaciones cometen el error de tratar la evaluación como un control de "última milla". Sin embargo, el equipo de monday Service ha redefinido este paradigma, estableciendo la evaluación como un requisito de "Día 0". Al construir su nueva fuerza de trabajo de IA —un ecosistema de agentes personalizables basados en roles—, la compañía integró un marco de desarrollo orientado a evaluaciones (eval-driven development) para detectar fallos de calidad antes que sus usuarios.

Este enfoque corporativo ha permitido alcanzar hitos significativos en eficiencia operativa:

• Velocidad: Reducción del ciclo de retroalimentación de 162 a 18 segundos (8.7 veces más rápido).
• Cobertura: Pruebas exhaustivas sobre cientos de casos en minutos.
• Observabilidad: Monitoreo de calidad en tiempo real sobre trazas de producción.
• Evals as Code: Gestión de la lógica de evaluación bajo control de versiones y despliegue CI/CD.

La Arquitectura: El Desafío de los Agentes ReAct

monday Service utiliza agentes basados en el patrón ReAct (Razonamiento y Acción) mediante LangGraph. Aunque esta autonomía permite a los agentes resolver consultas complejas de TI, Recursos Humanos o Legal, también introduce una vulnerabilidad crítica: la cascada de errores.

Para entender esto, imaginemos el juego del "teléfono descompuesto": si el primer participante susurra una palabra ligeramente incorrecta, el mensaje final será algo completamente ajeno al original. En un agente ReAct, una pequeña desviación en un prompt o en el resultado de una herramienta puede encadenar una serie de decisiones lógicas erróneas, resultando en una respuesta final alucinada o incorrecta.

Los Dos Pilares de la Evaluación

Desde la perspectiva de arquitectura, el equipo implementó una estrategia de dos niveles para mitigar estos riesgos:

1. Evaluaciones Offline (La Red de Seguridad)

Funcionan como pruebas unitarias ejecutadas contra "datasets de oro" (casos de referencia). Su objetivo es garantizar que un ajuste en el prompt no rompa funcionalidades existentes.

2. Evaluaciones Online (El Monitor Continuo)

Se centran en el análisis del rendimiento del agente en el "mundo real", midiendo señales de negocio como la tasa de resolución automatizada y la satisfacción del usuario.

Para ilustrar estos niveles, podemos usar la metáfora de un coche de carreras:

• Nivel 1 (Offline): Es el túnel de viento y las pruebas de motor en el laboratorio. Comparamos cómo se comporta el chasis (el agente) ante condiciones controladas.
• Nivel 2 (Online): Es la telemetría en tiempo real durante la carrera. Monitoreamos cómo los neumáticos (las herramientas) y el motor (el modelo de IA) responden al asfalto real y al clima cambiante (las peticiones impredecibles de los usuarios).

Pilar A: Evaluaciones Offline y el Rigor Técnico

El equipo comenzó con un dataset de 30 tickets de IT reales (anonimizados) cubriendo categorías como acceso a software, problemas de VPN y soporte de hardware. Las comprobaciones se dividieron en dos categorías:

1. Smoke Checks Determinísticos: Verificaciones de salud del runtime, formato del esquema de salida y persistencia de la conversación.
2. LLM-as-a-Judge: Uso de evaluadores avanzados para medir la fidelidad a los artículos de la base de conocimientos (KB grounding) y la resolución de conflictos.

El problema de la Contaminación de Datos

Es vital que estos datasets de prueba sean dinámicos. La contaminación de datos en los benchmarks es como un estudiante que obtiene las preguntas del examen antes de la prueba: el resultado de "10" no refleja conocimiento real, sino una simple memorización, invalidando la evaluación de la capacidad de razonamiento del agente.

Optimización del Tiempo de Desarrollo (DevEx)

Inicialmente, las evaluaciones se ejecutaban de forma serial, convirtiéndose en un cuello de botella. Para solucionar esto, monday Service implementó una estrategia de paralelización híbrida:

• Paralelismo (CPU-Bound): Distribución de cargas de trabajo en múltiples núcleos.
• Concurrencia (I/O-Bound): Ejecución simultánea de múltiples llamadas a la API del LLM para reducir la latencia de espera.

A continuación, se presenta un ejemplo conceptual en Python de cómo se podría estructurar una evaluación concurrente utilizando la infraestructura de LangChain:

import asyncio
from langsmith import Client
from langchain_openai import ChatOpenAI
from langchain.evaluation import load_evaluator

async def evaluate_agent_concurrency(dataset_name):
    client = Client()
    evaluator = load_evaluator("labeled_criteria", criteria="correctness")
    llm = ChatOpenAI(model="gpt-4")
    
    # Obtenemos los ejemplos del dataset
    examples = list(client.list_examples(dataset_name=dataset_name))
    
    async def process_example(example):
        # Simulación de la ejecución del agente y su evaluación
        # En una arquitectura real, aquí se invocaría al agente de LangGraph
        response = "Respuesta generada por el agente" 
        score = await asyncio.to_thread(
            evaluator.evaluate_strings,
            prediction=response,
            input=example.inputs['question'],
            reference=example.outputs['answer']
        )
        return score

    # Ejecución concurrente de todas las evaluaciones
    results = await asyncio.gather(*(process_example(ex) for ex in examples))
    return results

# Este enfoque reduce drásticamente el tiempo de espera al no procesar
# un ticket tras otro, sino todos en una ráfaga controlada.

Pilar B: Evaluaciones Online y Multiturno

Dado que las conversaciones con agentes suelen ser largas, la métrica de éxito no puede ser una única respuesta. El equipo adoptó los Evaluadores Multiturno de LangSmith. Estos evalúan la trayectoria completa del diálogo, analizando si el agente guio al usuario eficazmente hacia la solución tras varios intercambios.

Evaluaciones como Código (EaC) y GitOps

Una de las innovaciones más destacadas es el tratamiento de los "jueces" (prompts de evaluación) como código de producción. En lugar de gestionarlos en una interfaz web, se definen como objetos estructurados en el repositorio.

Esto habilita un flujo de trabajo de Reconciliation Loop en el pipeline de CI/CD:

1. Sincronización: Se envían las definiciones de los prompts al Registro de LangSmith.
2. Conciliación: Se comparan las reglas locales con las activas en producción.
3. Depuración (Pruning): Se eliminan automáticamente las evaluaciones obsoletas (zombis) que ya no existen en el código fuente.

Conclusión

El caso de éxito de monday Service demuestra que la escalabilidad de la IA en la empresa no depende solo de la potencia del modelo, sino del rigor de la infraestructura de evaluación. Al adoptar un enfoque de "Evaluación como Infraestructura" (similar a Terraform), las organizaciones pueden iterar con la confianza de que cada mejora en el agente está respaldada por datos empíricos y no por meras intuiciones.

---

Referencias:

• Fuente original: monday Service + LangSmith: Building a Code-First Evaluation Strategy from Day 1 por Gal Ben Arieh en el Blog de LangChain.