Interlock enseña a los agentes a terminar las tareas: hasta +6,64 puntos en JobBench

El equipo de Interlock propone un método para sintetizar tareas largas para agentes LLM, en las que no basta con dar la respuesta correcta en cada paso: hay que completar toda la cadena de dependencias. Dos modelos de la familia Qwen3.6, ajustados con sus propias trayectorias seleccionadas, mejoraron en tres benchmarks externos: +4,00–4,50 p. p. en la proporción de tareas resueltas en AutomationBench, +3,20–6,64 puntos en la puntuación ponderada de JobBench y +3,89–4,16 p. p. en los criterios de Harvey LAB.

El problema: correcto en lo local, pero sin terminar

Los agentes trabajan cada vez más en entornos donde las evidencias están repartidas entre archivos y sistemas, el estado de la tarea está cumplido solo en parte y los recursos y artefactos dependen unos de otros. El fallo típico es este: el agente cierra con cuidado requisitos sueltos, pero pierde los vínculos entre ellos. El resultado es formalmente verosímil, pero incompleto. Los autores lo llaman brecha de finalización (completion gap) y lo explican así: que una tarea esté lista depende de las relaciones entre los hechos del entorno, las decisiones tomadas y los efectos que esas decisiones deben provocar.

De ahí la crítica a los datos de entrenamiento actuales. Si las tareas sintéticas no codifican esos vínculos, el agente no recibe ninguna señal de que entre «casi hecho» y «hecho» hay un abismo.

Cómo funciona Interlock

Cada tarea se representa como un grafo de finalización tipado con tres tipos de conexiones. Las aristas de anclaje (grounding) unen las evidencias públicas con las decisiones. Las hiperaristas de acoplamiento (coupling) imponen restricciones conjuntas a varios componentes a la vez. Las aristas de realización (realization) van desde la decisión hasta todos los efectos downstream obligatorios.

El grafo se compila en tres artefactos: un espacio de trabajo reiniciable, una solicitud pública y una rúbrica de evaluación. Después vienen dos controles de calidad. La source-coverage review comprueba que los requisitos originales no se perdieron durante la generación. La public-input review comprueba que la rúbrica se apoya en materiales que el ejecutor realmente tiene a su alcance; es decir, que el agente no está obligado a adivinar nada oculto.

Un agente juez evalúa cada ejecución: examina los artefactos generados y ejecuta scripts de verificación. Al conjunto de entrenamiento solo llegan las trayectorias que cumplen todos los requisitos obligatorios.

• Estructura de la tarea: grafo tipado con aristas de anclaje, hiperaristas de acoplamiento y aristas de realización
• Salida de la compilación: workspace reiniciable, solicitud pública, rúbrica
• Filtros: source-coverage review y public-input review
• Selección: agente juez con scripts de verificación; solo pasan las trayectorias que cumplen todos los requisitos obligatorios
• Modelos: dos bases Qwen3.6, ajustadas con sus propias trayectorias aceptadas
• Mejora: AutomationBench +4,00–4,50 p. p., JobBench +3,20–6,64 puntos, Harvey LAB +3,89–4,16 p. p.

Qué dicen las cifras

El esquema es, en esencia, una autodestilación con selección estricta: el modelo resuelve tareas sintéticas, el juez conserva solo las ejecuciones impecables y con ellas se realiza el ajuste fino. Importa menos la mecánica que el lugar al que se transfiere el efecto. AutomationBench, JobBench y Harvey LAB no intervinieron en la generación de tareas, así que la mejora se obtiene en entornos externos y no sobre la distribución propia de los autores.

El resultado tiene límites. Las mejoras son moderadas, los rangos son amplios (en JobBench, de 3,20 a 6,64) y los modelos base son solo dos. La descripción no aclara cuánto cuesta generar y verificar una tarea, cuánto se equivoca el juez LLM ni cómo escala el método con un mayor número de trayectorias. Esas preguntas conviene buscarlas en el texto completo del trabajo.

Qué llevarse a la práctica

Incluso sin replicar todo el pipeline, las ideas son directamente aplicables. Describa las tareas de los agentes como un grafo de dependencias en el que cada decisión enumere sus efectos posteriores obligatorios, y verifique precisamente esos efectos, no el texto de la respuesta final. Someta la rúbrica a una comprobación de «si se puede derivar de los materiales públicos»: así se descartan las tareas en las que el agente fracasa por condiciones ocultas.

Haga los entornos reiniciables para que las trayectorias sean reproducibles. Y, por último, al seleccionar datos para el ajuste fino, exija el cumplimiento de todos los puntos obligatorios en lugar de una puntuación media alta; de lo contrario, el modelo seguirá aprendiendo de resultados incompletos «localmente correctos».