Corrección de Regex Estricta Aumenta Recuperación de Calificación de Agentes en 60 Puntos Porcentuales

Los calificadores automatizados para sistemas agénticos fallan donde los evaluadores de LLM de un solo turno no fallan. Una nueva investigación de Columbia Statistics identifica exactamente dónde se filtra la señal. Un artículo titulado "Grading the Grader" (Zheng y Hsu, junio de 2026) ejecutó LAMBDA—un sistema dual-agente de análisis de datos de código abierto—contra 153 tareas numéricas QRData en el benchmark DSGym. Los investigadores sometieron a prueba tres estrategias de calificación contra etiquetas humanas y expusieron dos modos de falla que la mayoría de los pipelines de evaluación encuentran.

LAMBDA empareja un agente "programador" que escribe Python a partir de instrucciones en lenguaje natural con un agente "inspector" que detecta errores de ejecución y sugiere correcciones. El bucle se ejecuta hasta que el código tiene éxito o se alcanza un límite de reintentos. Este diseño iterativo de emisión de código rompe los calificadores estándar: la respuesta final del agente puede aparecer en una variable impresa, una cadena formateada, un registro de diagnóstico o un rastro parcial—cualquiera de los cuales una regex ingenua omitirá.

El artículo probó tres capas. Primero: coincidencia estricta de regex, un enfoque no-GenAI que extrae números por patrón. Segundo: calificación indulgente basada en LLM, que interpreta la respuesta en contexto. Tercero: inspección humana basada en fragmentos. En precisión, ambos calificadores automatizados lograron cero falsos positivos en 70 muestras validadas por humanos. La recuperación divergió drásticamente. Una heurística de último número—tome cualquier número que aparezca al final en la salida—dejó el calificador estricto muy expuesto. Reemplazarlo con un pipeline de extracción anclado por palabras clave—uno que analiza tokens adyacentes a la respuesta antes del número—aumentó la recuperación del calificador estricto en 60 puntos porcentuales. Este cambio único es el resultado más accionable en el artículo para equipos que ejecutan pipelines de primero-regex.

La recuperación del calificador LLM indulgente alcanzó el 97% contra etiquetas humanas, pero solo después de resolver un problema separado: el propio calificador no se ejecutaba. Sin intervención, solo el 36% de las invocaciones de calificación se completaron exitosamente, con una tasa de aprobación indulgente del 16%. La solución fue un mecanismo de empujón iterativo—un prompt que impulsa el LLM de calificación hacia una plantilla de respuesta estructurada. Con empujones, el éxito de la ejecución de calificación saltó al 97% y las tasas de aprobación indulgente al 46%. Reinyectar la pregunta de tarea original junto con el empujón no proporcionó beneficio adicional. El empujón funciona como una pista de formato, no como un andamio de comprensión. Los equipos que agregan contexto de pregunta para estabilizar sus jueces LLM desperdician tokens.

Tipo de variable—el tipo de datos de la respuesta esperada (integer, float, percentage, etc.)—resultó ser el campo de metadatos de tarea más consistentemente asociado con el comportamiento del pipeline de calificación y las calificaciones observadas. Supera otras características de tarea como una señal de diagnóstico. Cuando los números de evaluación se ven incorrectos, dividir por tipo de variable localizará el problema más rápidamente que dividir por dominio o longitud de tarea.

Un artículo separado (Nie et al., 2026) mostró que una porción sustancial de tareas QRData se puede resolver sin los archivos de datos reales—a través de memorización o priors estadísticos. El filtrado de atajos reveló una caída de hasta el 21% en la precisión relativa una vez que se aplicó la dependencia de datos. El desempeño del agente en esta clase de tareas probablemente esté sobrestimado en toda la junta. Los pipelines de evaluación que reportan altas tasas de aprobación pueden estar midiendo la recuperación de priors de tiempo de entrenamiento, no razonamiento genuino.

Implemente una pila de dos calificadores: regex con extracción anclada por palabras clave como un ancla de precisión, calificador LLM con empujón de plantilla como la capa de recuperación. Estratifique diagnósticos por tipo de variable. No confunda fallas de ejecución de calificación con fallas de agente hasta que haya instrumentalizado ambas rutas por separado.