Un agente en lugar de un optimizador independiente: un marco unificado que evoluciona en varias tareas a la vez
Los autores demuestran que un único modelo congelado, con una versión inalterada del armazón, primero resuelve tareas y después edita su propio código basándose en registros completos de las ejecuciones. La evolución multitarea de un armazón de 49 líneas mejoró los resultados dentro de la distribución y en benchmarks reservados y, en algunos de ellos, permitió superar a Codex.
Qué es un harness y por qué optimizarlo
Un harness es el código que rodea a un agente basado en un modelo de lenguaje. Organiza los prompts, las llamadas a herramientas, la gestión del contexto y la ejecución. La forma en que está diseñado este código determina cómo resuelve las tareas el agente.
En la mayoría de los métodos existentes, una persona crea el harness. Un proposer independiente modifica el harness del solver. Se hace evolucionar un harness distinto para cada benchmark. Este enfoque vincula las mejoras a una sola tarea.
Criterio práctico: un único framework evoluciona en varias tareas a la vez, en lugar de crear uno para cada benchmark.
Un único framework: el agente como su propio optimizador
El artículo de Qiankai Xu se presentó el 29 de septiembre de 2026. Se titula «Harness autoevolutivo en múltiples tareas con el agente como su propio optimizador». El enfoque se basa en un único modelo congelado y una sola versión del harness.
Primero, el modelo resuelve tareas como solver. Después, el mismo modelo actúa como proposer. Lee los registros completos de las ejecuciones y edita directamente el harness que lo ejecuta. No hace falta un proposer independiente.
| Parámetro | Método típico | Enfoque del artículo |
|---|---|---|
| Quién modifica el harness | Un proposer independiente | El mismo modelo congelado |
| Harness inicial | Creado por una persona | Una versión del harness |
| Alcance | Un harness por benchmark | Tareas de cinco benchmarks de distintos ámbitos |
| Roles | Proposer y solver separados | El modelo primero es solver y después proposer |
Criterio práctico: un agente que lee sus ejecuciones y modifica su propio harness sustituye a un optimizador independiente.
Cinco benchmarks y separación de datos
Cada ronda de evolución incluye tareas de cinco benchmarks de distintos ámbitos. Las tareas de entrenamiento y las reservadas para evaluación están estrictamente separadas.
Además, se realizan evaluaciones en cinco benchmarks fuera de distribución. Estos benchmarks no se utilizaron durante la evolución.
Criterio práctico: las evaluaciones fuera de distribución comprueban la transferencia, no solo el ajuste a tareas conocidas.
Dos etapas de evolución
El proceso de evolución se presenta como el entrenamiento de un modelo profundo en dos etapas:
- Preentrenamiento multitarea.
- Entrenamiento continuo.
La versión inicial del harness constaba de 49 líneas. Al finalizar la primera etapa, el resultado medio aumentó 4.48 puntos en los benchmarks dentro de distribución. En los benchmarks fuera de distribución, el aumento fue de 12.64 puntos. En los primeros, el resultado superó al de Codex; en los segundos, lo igualó.
En la segunda etapa, la evolución adicional en Claw-Eval elevó el resultado en este benchmark de 66.17 a 68.06. En este benchmark, el enfoque superó a Codex.
Criterio práctico: el preentrenamiento amplía la transferencia; el entrenamiento continuo perfecciona el resultado en un benchmark concreto.
Mecanismos surgidos durante la evolución
Los autores analizan tres mecanismos:
- truncamiento de la salida;
- compresión del historial;
- verificación independiente.
El truncamiento de la salida limita la extensión de la respuesta. La compresión del historial reduce el contexto. La verificación independiente añade una comprobación del resultado. Estos mecanismos surgieron de las modificaciones del harness, no fueron definidos por una persona.
Criterio práctico: los mecanismos surgidos durante la evolución sirven de referencia para evaluar el propio framework.
Preguntas frecuentes
Material similar
Todos los materiales
Evaluación de agentes de programación en el desarrollo interactivo de XR: resultados de GenXR-Bench
Se ha publicado GenXR-Bench, un conjunto de 112 tareas expertas para evaluar de forma integral agentes de programación en el desarrollo interactivo de XR: desde la mejora de funciones y la corrección de defectos hasta la creación de aplicaciones con verificación del comportamiento en dispositivos de consumo. Entre los diez modelos probados, el mejor resultado fue un 50,9 % en Pass@1; los fallos recurrentes incluyeron la gestión de eventos asíncronos de sensores, el anclaje de objetos al espacio real y la comprensión de las interacciones en un contexto físico.
5 noviembre 2026
Anotación híbrida de imágenes: la automatización acelera el entrenamiento de modelos de visión por computadora
El artículo describe cómo el preetiquetado mediante algoritmos reduce el trabajo manual y mejora la calidad de los conjuntos de datos de entrenamiento, así como por qué sigue siendo necesaria la verificación selectiva por parte de una persona. También se analizan las limitaciones del método en condiciones de captura difíciles y con tipos de objetos poco frecuentes.
5 noviembre 2026
De la recompensa escalar al frente de Pareto: síntesis RTL de LLM mediante aprendizaje por refuerzo multiobjetivo
Se propone un método para entrenar un modelo de lenguaje para que genere no un solo diseño, sino un conjunto de candidatos RTL con distintos compromisos entre área, latencia y consumo energético; la recompensa se basa en la contribución de cada variante al hipervolumen del frente de Pareto. En RTLLM v2, el hipervolumen relativo aumentó 13,3 puntos porcentuales frente a la versión base sin optimización PPA y 14,4 puntos porcentuales frente al entrenamiento por refuerzo con un único objetivo.
5 noviembre 2026