Evaluaciones de IA Explicadas: Desde lo Básico hasta Agentes Automejorables

Modo Fácil: Qué es un eval - Un eval es una prueba para ver si lo que hizo un agente de IA es correcto - La clave de “correcto” es codificar lo que tú / tu organización considera correcto en software - Ejemplo: agente de GTM que registra la reunión con el cliente, redacta un borrador de seguimiento y se detiene antes de enviarlo - En este contexto, un eval puede verificar si la reunión con el cliente se registró, si se redactó el borrador de seguimiento, si el agente hizo una pausa antes de enviar - Los evals no son realmente nuevos, son solo una versión evolucionada de las pruebas unitarias, algo que siempre ha existido en el software - La receta para configurar un eval es bastante simple: agente + sistema + tareas + verificador - En el ejemplo del agente de GTM, tienes tu agente, acceso de lectura/escritura a Salesforce, un conjunto de tareas (como actualizar el estado del lead, registrar la llamada, redactar el seguimiento) y un verificador (herramienta cuyo trabajo es determinar si la tarea se hizo bien o mal) - Los verificadores pueden ser una función simple de Python o verificaciones de contenido/prosa - Las rúbricas son una excelente manera de codificar cómo se ve un buen desempeño para tareas no verificables, de modo que los verificadores aún puedan funcionar - Una vez creadas las rúbricas, si el agente no rinde, la causa raíz podría ser: lista de verificación incompleta, modelo no suficientemente inteligente, contexto malo o incompleto, o prompt no suficientemente bueno Modo Difícil: Qué son los entornos de agente - Entorno = lugar donde un agente realiza trabajo y medimos su desempeño - Los entornos se volvieron necesarios al pasar de la era de ChatGPT de texto a texto a la era de agentes de prompt a trabajo en el mundo real - Ejemplo: para Claude Code/Codex, cuando trabajan en tu computadora, el entorno son archivos, navegador, correo electrónico, aplicaciones, permisos - Cuando construyes entornos de agente hoy = recreaciones o simulaciones de herramientas existentes que parecen reales para el agente pero no lo son (no sobrescribirán producción) - Básicamente quieres poder probar el desempeño de tus agentes sin tocar sistemas/datos en vivo de tu empresa - Necesidades al construir agentes y evals: (1) gestionar tareas por equipo (GTM ≠ SWE), (2) entornos específicos por equipo, (3) ejecutar a escala sin construir toda la infraestructura tú mismo - Una herramienta popular para configurar entornos de agente es un framework de código abierto llamado Harbor, que proporciona todas las abstracciones de entorno de agente necesarias para ejecutar evals, de modo que no gestionas todo, pero puedes ir a nivel bajo cuando sea necesario - Los primitivos de Harbor cubren: construcción de entornos, construcción de verificadores, construcción de instrucciones, infraestructura de sandbox - Ruta para principiantes: toma un eval existente en formato Harbor → pide a Claude Code/Codex que lo explique → ajústalo para tu agente - LangSmith Engine: crea evals a escala; interfaz de usuario para personas que pueden juzgar resultados buenos/malos y quieren dar retroalimentación sin vivir en código - Valida entornos ejecutando múltiples agentes/modelos reales en ellos (por ejemplo, frontier + GLM + Qwen pequeño) y busca patrones extraños - La ingeniería de entornos es iterativa como la ingeniería de agentes; los humanos construyen y revisan resultados - Para hacer evals a escala necesitas un suite de evals. Un suite de evals es una colección de tareas de agente que ejecutas como empresa. Cada tarea se compone de un prompt de entrada, un verificador y el entorno. - Cada vez que sale un modelo nuevo, ejecutarás tu suite de evals (o una selección de tareas del suite) y sopesarás las ventajas y desventajas de costo vs. velocidad vs. inteligencia Modo Dios: Qué es un agente auto-mejorable - Ciclo continuo de agente en el mundo real → datos de producción → convertir producción en evals (y usar evals para mejorar) → mejorar continuamente el agente - Opinión controvertida: si tu equipo es realmente bueno convirtiendo datos de producción en evals, puedes mejorar agentes continuamente - Los evals existen para encontrar fallas; luego cambia el agente para que esa falla nunca vuelva a ocurrir - Dos categorías de mejora: ingeniería de harness y ajuste fino de un modelo pequeño - Ingeniería de harness: (lugar barato para empezar): ajustar prompts, definiciones/descripciones de herramientas, elección de modelo, combinaciones de modelos (por ejemplo, Sol+Opus, GLM+Opus) - Ajuste fino (en tu tarea de producción específica): modelos abiertos + infraestructura de ajuste fino existen; puede igualar a Opus en *esa* tarea a un costo ~10 veces menor; un agente de GTM no necesita matemáticas de frontier - Modo dios = recopilar datos reales de producción → convertirlos en evals/entornos → elegir cómo mejorar (harness primero; luego poseer inteligencia ajustada para tareas específicas) - El cuello de botella suele ser actualizar verificadores/rúbricas manualmente - Dos preguntas para la autonomía: cómo girar más rápido; puede ejecutarse sin un humano en el circuito - Objetivo: minimizar los puntos de contacto humano en el circuito - Los rastros de agente son el primer paso práctico para organizaciones que usan agentes - Rastro = registro de cada acción: llamadas a herramientas - Los humanos no pueden razonar bien sobre lo que un agente *hará*; observar el comportamiento en vivo (también llamado rastros) hace obvio lo correcto/incorrecto - Ver un mal resultado → leer rastros (comprobantes) → encontrar el paso incorrecto → cambiar el agente para que no se repita - Los puntos de contacto humano se reducen con cada lanzamiento de modelo más inteligente - El rol humano de hoy #1 (al inicio): explicar al agente de minería/mejora cómo se ve lo bueno vs. lo malo (prompt de comportamientos a buscar); principalmente al inicio con algunas ediciones con el tiempo - Luego un agente puede encontrar llamadas a herramientas fallidas, fallas de seguimiento de instrucciones, etc., y proponer mejoras (nuevo prompt, herramienta nueva/diferente, etc.) - Con un buen suite de evals o una buena medición de mal comportamiento en producción, un agente ejecutándose durante la noche puede ser muy bueno proponiendo correcciones - Rol humano #2: al convertir producción en evals/entornos, revisar lo que *la empresa* considera importante - Acción organizacional de mayor apalancamiento: humanos escribiendo cómo se ve lo bueno