Una conversación con un solo agente de IA puede parecer impecable por sí sola y aún así señalar un producto defectuoso. Esa brecha está impulsando un cambio en la forma en que las empresas evalúan a los agentes, lejos de calificar rastros individuales y comparar cohortes de usuarios con una línea de base.
En Transformación VB 2026, Harrison Chase, director ejecutivo de LangChain; Hui Zhang, CTO y cofundador de Conviva; y Emmanuel Turlay, director de ingeniería de CoreWeave, describieron ese cambio, junto con un movimiento paralelo hacia modelos de jueces más baratos y más limitados.
El agente como juez (juzgar la producción de un agente de IA con otro) no ha reemplazado el LLM como juez, que según Chase sigue siendo el predeterminado. La mayor tensión, dijo Zhang, es entre la evaluación automatizada, ya sea por parte de un LLM o un agente, y la revisión humana.
«Es escalable pero no fundamentado, ya sean agentes como jueces o LLM como jueces, calificas el resultado, calificas el trabajo. Todavía es muy difícil fundamentarlo y luego usas humanos y eso simplemente no es escalable», dijo Zhang. «Toda la industria se enfrenta a esto, qué veneno quieres elegir».
Los criterios de evaluación ahora funcionan como las especificaciones del producto.
Esa brecha (una conversación que obtiene una buena puntuación pero que aún así indica un producto defectuoso) es lo que los equipos intentan cerrar creando un conjunto de evaluaciones exhaustivas antes de enviar algo. Chase dijo que eso no funciona.
«A veces vemos equipos que casi tienen una parálisis evaluativa», dijo Chase. «Dicen, este es un conjunto de evaluación, no puedo iniciarlo. Los mejores equipos inician y luego iteran».
Chase enmarcó los criterios de evaluación como una especificación viva, no como un conjunto de pruebas únicas: un documento de requisitos de producto, la especificación estándar de desarrollo de software sobre lo que debe hacer una aplicación. «Las evaluaciones son como el nuevo PRD», afirmó. «Definen lo que su agente debe y no debe hacer».
Turlay describió haber afrontado el mismo fallo desde un ángulo diferente. «Estaba tratando de alcanzar una cobertura del 100 % para mis pruebas y todavía tenía errores en la producción», dijo: un conjunto de pruebas que parecía completo pero aún omitía lo que importaba, la misma brecha que Chase estaba describiendo con las evaluaciones.
Dijo que un monitoreo amplio y permanente detecta más fallas reales que un conjunto de pruebas exhaustivas previas al lanzamiento. Los equipos deben configurar primero comprobaciones en línea amplias, utilizarlas para identificar las clases de fallas a medida que ocurren y luego crear una evaluación fuera de línea específica en torno a los problemas que surgen.
Por qué anotar las trazas una a la vez es un error
Incluso un proceso de evaluación bien diseñado puede dar resultados incorrectos. La objeción de Zhang es la forma en que la mayoría de los equipos realizan la evaluación: muestreando rastros, ya sean 50 de ellos o una población completa, puntuando cada uno de ellos de forma aislada. Ese enfoque pasa por alto una señal que sólo aparece cuando se comparan cohortes de usuarios con una línea de base, un método que Zhang llama análisis contrastivo.
Zhang lo ilustró con un ejemplo de venta minorista: un comprador le pide a un agente un zapato para correr antes de una media maratón, el agente hace preguntas de calificación y el comprador compra un zapato. Calificada individualmente, esa interacción se ve bien. Pero el índice de aclaración, cuántas preguntas de seguimiento hace un agente antes de completar una tarea, fue tres veces mayor que el valor inicial para esa categoría de calzado en toda la población de usuarios. Una segunda métrica, la frecuencia con la que los compradores finalizaron su compra fuera de la conversación, fue cinco veces mayor que la línea de base para la misma categoría.
Ninguno de los números es visible desde un solo rastro. Ambos apuntan a un problema específico de categoría que se puede depurar. Zhang dijo que la industria también carece de una segunda fuente de datos: qué sucede antes, entre y después de la conversación, no sólo el rastro en sí.
Dimensionando al juez para el trabajo
Una vez que el análisis contrastivo señala qué categoría está realmente rota, el siguiente problema es quién la vigila en el futuro y a qué costo. La regla de Turlay era comenzar con el modelo más capaz disponible para demostrar que una tarea tiene solución y luego ir bajando. Si no se puede hacer con un modelo de primer nivel, dijo, no funcionará con uno más pequeño. Una vez que un patrón resulta viable, los equipos pueden muestrear una fracción del tráfico en lugar de juzgar cada interacción y trasladar tareas más simples, como la clasificación binaria, a modelos de código abierto más pequeños.
LangChain fue más allá y ajustó su propio modelo para detectar cuando un usuario cree que el agente cometió un error, una señal que Chase llama error percibido. «El modelo que afinamos fue un modelo Qwen», dijo, refiriéndose a la familia de código abierto de Alibaba. Combinando el etiquetado manual con la destilación, el resultado fue bueno. «Igual que [Claude]Sonnet, para, dependiendo de cómo lo sirviéramos, una reducción de costos de 10 a 100 veces», dijo Chase.
No todas las barandillas necesitan un modelo. Chase señaló las propias barreras de seguridad de Claude Code como prueba: expresiones regulares, la técnica de programación común para encontrar y validar patrones en el código. «Muchas de las barreras que tenían eran simplemente expresiones regulares», dijo. «No eran pequeños LLM, eran simplemente expresiones regulares».
LLM como juez no significa que el ser humano en el circuito desaparezca
La pregunta más importante es si usar LLM como juez elimina la necesidad de contar con un ser humano al tanto.
Turlay apuntó a la responsabilidad, basándose en su trabajo anterior en una empresa de vehículos autónomos. Su equipo comprimió la ingesta de datos y el reentrenamiento en un ciclo de dos semanas para enviar un nuevo modelo al automóvil. Incluso entonces, alguien todavía tenía que cerrar la sesión.
«Me sentí seguro en nombre de la empresa al decir que este modelo debería entrar en el coche», dijo. La misma lógica se extiende a los ámbitos jurídico, financiero y sanitario. «Antes de que podamos eliminar a un humano y decir: respaldo esto y asumo la responsabilidad legal por ello, pasará un tiempo antes de que los agentes puedan hacerlo por sí solos».
Zhang estuvo de acuerdo en que un humano tiene que seguir siendo el guardián en los casos de esquina, incluso cuando la automatización eventualmente se ejecuta a una escala que supera la precisión humana individual: las máquinas pueden ver más a nivel de patrón.
Chase fue más allá: ese control humano no es sólo una red de seguridad. «El ser humano en el circuito es realmente importante para generar confianza en cómo funcionan estos sistemas agentes, y también muy importante para la memoria y el aprendizaje de los sistemas», dijo. «Tiene que haber interacciones para que el sistema aprenda».
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
