Fable 5 vs. GPT-5.6 Sol: ¿`/goal` ayuda en problemas NP-difíciles?

 (charlesazam.com)
1 puntos por GN⁺ 1 일 전 | 1 comentarios | Compartir por WhatsApp
  • Tras ponerlos a resolver durante 30 minutos un problema no publicado de optimización de red de fibra óptica, Fable 5 mostró la mejor puntuación y el rendimiento más estable, pero /goal no produjo una mejora consistente
  • /goal no es simplemente una función para hacer que trabaje más tiempo, sino que cambia el bucle de control y la ruta de exploración, por lo que puede sostener tanto buenas estrategias como estrategias equivocadas
  • Aunque /goal ganó 4 de 6 comparaciones entre Fable 5 y GPT-5.6 Sol, por raras caídas grandes de rendimiento la puntuación promedio empeoró en 759 puntos y 868 puntos, respectivamente
  • El modo normal de Fable 5 fue el más estable con un promedio de 32,386 puntos y un rango de 319 puntos, y el modo /goal logró la mejor marca total con 31,934 puntos
  • En optimización difícil, más importante que repetir o no es la calidad de la estrategia que se repite, y la tasa de victorias individual y el rendimiento promedio pueden llevar a conclusiones opuestas

Problema KIRO de optimización de red de fibra óptica

  • KIRO es un problema de investigación operativa presentado en un hackatón para estudiantes de ingeniería en 2018, y requiere minimizar la longitud total del cable usando matrices de distancia direccionales de Grenoble, Nice y Paris
  • La red se construye con bucles redundantes que parten desde hubs de distribución y ramales cortos que salen desde torres ubicadas sobre esos bucles
    • Todas las torres deben aparecer exactamente una vez
    • Deben cumplirse varias restricciones estructurales
    • El costo de un tramo de cable puede cambiar si se invierte la dirección
    • Cuanto menor sea la puntuación, mejor es la solución
  • La línea base humana fue un solver en C++ escrito anteriormente durante una semana para resolver este problema

  • Tamaño del espacio de búsqueda

    • Como cambian la cantidad y el tamaño de los bucles, así como el punto base y el orden de los ramales, es difícil calcular todo el espacio de búsqueda con una sola fórmula cerrada
    • Incluso considerando solo el caso de asignar 532 terminales de Paris a 11 hubs de distribución sin orden ni ramales, hay 11^532 posibilidades
    • Incluso si se cuentan solo soluciones válidas restringidas usando 19 bucles de 28 terminales y sin ramales, el espacio de búsqueda llega aproximadamente a 10^1223
    • 19 × 28 = 532, por lo que se incluyen todos los terminales
    • Cada bucle no supera el límite de 30 terminales
    • La fórmula de cálculo es (532! / 19!) × 11^19 ≈ 10^1223

Modelos y condiciones de ejecución

  • Se compararon los modelos de la familia Claude Fable 5·Opus 4.8·Sonnet 5 y los de la familia GPT GPT-5.6 Sol·Terra·Luna
  • Cada modelo se ejecutó en modo normal y en modo nativo /goal
    • Tiempo de optimización: 30 minutos
    • Límite de tiempo del agente externo: 1,900 segundos
    • Configuración de razonamiento: el máximo disponible para cada modelo
    • Entorno de ejecución: Harbor 0.1.43, Docker y autenticación por suscripción
  • Primero se hizo una ejecución de 30 minutos sin pistas para todos los modelos, tanto normal como con /goal
  • Para Fable 5 y GPT-5.6 Sol, que eran la comparación principal, se repitió hasta obtener 3 pares de ejecuciones emparejadas para cada uno
  • Todo el código, prompts, tablas de resultados, criterios de exclusión y trayectorias de ejecución están en CLIArena, y este experimento da continuidad a una publicación de benchmark anterior

Resultados de Fable 5 y GPT-5.6 Sol

  • Si el valor de restar la puntuación del modo normal a la puntuación de /goal es negativo, entonces /goal obtuvo un mejor resultado
  • Los tres resultados de Fable 5 fueron los siguientes
    • Ejecución 1: normal 32,197 puntos, /goal 31,934 puntos, mejora de 263 puntos
    • Ejecución 2: normal 32,516 puntos, /goal 32,324 puntos, mejora de 192 puntos
    • Ejecución 3: normal 32,446 puntos, /goal 35,178 puntos, deterioro de 2,732 puntos
  • Los tres resultados de GPT-5.6 Sol fueron los siguientes
    • Ejecución 1: normal 33,581 puntos, /goal 39,371 puntos, deterioro de 5,790 puntos
    • Ejecución 2: normal 35,539 puntos, /goal 32,703 puntos, mejora de 2,836 puntos
    • Ejecución 3: normal 33,663 puntos, /goal 33,313 puntos, mejora de 350 puntos

  • Por qué difieren la tasa de victorias y el promedio

    • /goal ganó 4 de 6 veces, pero en ambos modelos hubo mejoras pequeñas frecuentes a cambio de raros deterioros grandes de rendimiento
    • Fable 5 pasó de un promedio de 32,386 puntos en modo normal a 33,145 puntos con /goal, lo que implica un deterioro de 759 puntos
    • Según la mediana, mejoró 192 puntos
    • GPT-5.6 Sol pasó de un promedio de 34,261 puntos en modo normal a 35,129 puntos con /goal, lo que implica un deterioro de 868 puntos
    • Según la mediana, mejoró 350 puntos
    • El promedio de Fable 5 en modo normal fue 1,875 puntos mejor que el de Sol, y también quedó 1,984 puntos por delante en el promedio con /goal
    • También hubo diferencias en estabilidad
      • Los tres resultados del modo normal de Fable 5 quedaron dentro de un rango de 319 puntos
      • El modo normal de Sol abarcó un rango de 1,958 puntos
    • Fable 5 con /goal registró la mejor puntuación total: 31,934 puntos
    • La configuración más segura fue Fable 5 en modo normal

El mismo /goal, implementaciones distintas

  • Modelo de evaluación separado en Claude Code

    • En Claude Code, /goal funciona como un hook Stop con alcance de sesión
    • Cada vez que el modelo principal termina un turno, el modelo evaluador Haiku por defecto lee la condición objetivo y la conversación, y devuelve yes o no junto con una razón
    • Si responde no, comienza un nuevo turno; si responde yes, el objetivo se desactiva
    • El modelo evaluador no puede usar herramientas ni inspeccionar archivos, y solo juzga con base en la evidencia que aparece en el historial de conversación
    • Puede detectar cuando el trabajo termina demasiado pronto, pero no puede saber si vale la pena ejecutar el solver 10 millones de veces más
    • Como Claude Code no es open source, la información de implementación depende de la documentación de goal de Anthropic

  • Estado persistente y herramientas de ciclo de vida en Codex

    • El Codex CLI 0.144.4 usado en el benchmark trata el objetivo como un estado persistente vinculado al hilo
    • La TUI guarda el objetivo del hilo activo y SQLite registra el estado y el uso de presupuesto
    • El modelo de tarea recibe las herramientas create_goal, get_goal, update_goal
    • Cuando el hilo queda inactivo con un objetivo activo, se inyecta un turno de continuación que incluye el objetivo y una auditoría de finalización
    • Claude delega el juicio de finalización a un modelo evaluador independiente, pero ese modelo solo puede ver el historial de conversación
    • En Codex, el modelo de tarea usa archivos y herramientas, declara por sí mismo la finalización y, si el objetivo persistente sigue activo, continúa trabajando otra vez

Cómo /goal amplifica la estrategia

  • En tareas normales de programación, con turnos extra es fácil verificar el progreso, por ejemplo corrigiendo pruebas o completando migraciones
  • En optimización, después de que el agente elige un solver, el tiempo adicional puede amplificar tanto decisiones buenas como malas
  • Casos en los que /goal ayudó
    • Fable 5 siguió ejecutando un portafolio rápido basado en compilación
    • Sol mantuvo una estrategia exitosa de repartición de cadenas
  • También hubo casos en los que empeoró el rendimiento
    • Fable 5 construyó un solver lento y luego siguió ejecutándolo
    • Sol se obsesionó con una búsqueda exhaustiva que recorría todos los puntos base
  • La mediana mejoró ligeramente, pero la cola de malos resultados empeoró mucho más, reduciendo así el rendimiento promedio

Limitaciones para interpretar los resultados

  • El experimento cubre un solo problema NP-difícil no publicado, por lo que no debe verse como un leaderboard general de programación
  • Solo se obtuvieron 3 pares de ejecuciones limpiamente emparejadas para Fable 5 y Sol
  • En las comparaciones con otros modelos se mezclan distintos prompts, versiones del wrapper y límites de tiempo
  • Como las ejecuciones se hicieron de forma secuencial mediante un servicio por suscripción, el estado del servicio pudo haber cambiado durante el experimento
  • Aunque en los metadatos de la tarea figura 1 CPU, al contenedor se le expusieron 8 CPU, lo que favoreció al portafolio paralelo de Fable 5
  • Gracias a que el wrapper exigía checkpoints intermedios y validación final, todas las salidas de Fable 5 y Sol incluidas en la puntuación fueron válidas
  • Lo que se mide no es el modelo por sí solo, sino el sistema completo que incluye modelo, CLI, prompt, servicio por suscripción y harness

Materiales de reproducción y conclusión

  • En CLIArena están publicados la tarea del benchmark, el wrapper, los scripts de análisis, el generador de gráficos y las notas completas de evidencia
  • Los directorios de trabajo en bruto quedaron fuera de Git por su tamaño, pero las notas registran todas las puntuaciones publicables, resultados por ciudad, tiempo transcurrido, estrategias, elementos excluidos e ID de ejecución
  • Los principales comandos de ejecución fueron los siguientes
RUN_ID=article-kiro-YYYYMMDD-clean \
PHASE=nohint-all \
./scripts/run_subscription_article_matrix.sh
uv run python scripts/summarize_subscription_article_results.py RUN_ID...
uv run python scripts/analyze_subscription_article_results.py RUN_ID...
  • /goal no elevó ni redujo uniformemente el rendimiento, y puede ganar la mayoría de las ejecuciones individuales mientras empeora el rendimiento promedio observado
  • En optimización difícil, más importante que la calidad del propio bucle de control es la calidad de la estrategia que ese bucle repite

Lecturas relacionadas

1 comentarios

 
GN⁺ 1 일 전
Opiniones en Hacker News

  • El gráfico de arriba es algo confuso. Dice “más bajo es mejor”, pero el eje y está invertido, así que visualmente arriba es mejor y numéricamente más bajo es mejor

    • No parece que el eje esté invertido. 32,000 está abajo y 40,000 arriba, así que quizá lo corrigieron después del comentario

  • Claude tiende a olvidar instrucciones en trabajos largos que duran semanas, por más que se le recalque que son importantes. No he usado /goal, pero probablemente hace que realmente recuerde las instrucciones clave. Aquí parece que se trata de sesiones cortas, donde ese problema es menor

    • Al poner uso de contexto en la barra de estado de Claude Code, parece que de verdad se “cansa” a partir de 50~60%. Le pedí modificar el entorno de pruebas y agregar tests, y lo fue posponiendo diciendo que era “bastante trabajo de infraestructura”, pero después de /compact y volver a pedirlo, lo hizo sin quejarse
      Aun así, /compact falla seguido, así que no lo recomiendo durante el trabajo. Está relacionado, pero es útil al pasar a una tarea nueva; sin embargo, para correcciones que necesitan el contexto del proceso de generación, como un bloqueo en código recién escrito, no sirve porque descarta el proceso de pensamiento
    • Es una de las ventajas de pi. Hicieron el comando /protect para excluir mensajes de la compresión, y las skills también se protegen automáticamente. En trabajos largos se usa algo como /protect your goal is...
    • Después de usar Claude y GPT durante mucho tiempo en varios entornos de ejecución, coincido en que la causa es la compresión de contexto. La compresión de Codex mantiene conversaciones continuas de forma casi mágica y natural, pero con Claude había que manejar con mucho cuidado cuándo comprimir
    • La calidad cae mucho antes de llegar a la compresión. La alerta de compresión es como el letrero de “próxima gasolinera en 100 millas”, pero tú ya estás en medio del desierto
      No hace falta un procedimiento excesivamente complejo, pero conviene seguir el orden: descomponer la tarea → planear en un contexto nuevo → implementar en un contexto nuevo → /code-review en un contexto nuevo → corregir en un contexto nuevo. En Fable 5, cuando el contexto pasa de 50%, la calidad cae bastante y terminan apareciendo hasta cuatro implementaciones iguales en la base de código. Hacer que revise su propio trabajo en la misma sesión se parece a pedirle a un estudiante que califique su propio examen
    • Con un contexto de unos 700 mil tokens, Fable también perdió mucho criterio. Puede que OpenAI haya acertado al limitar el contexto de Codex a 400 mil, y eso parece ser el punto adecuado donde la mayor parte del contexto sigue siendo confiable

  • Si se comparan estrategias de búsqueda, es muy posible que modo Ultra sea superior, así que me interesa una evaluación posterior
    Ultra despliega agentes de investigación en paralelo, hace revisión adversarial en puntos de control definidos y usa varias técnicas para no quedar atrapado en óptimos locales. /goal parece más adecuado para investigación de una sola ruta o para trabajos pequeños de distribuir y recopilar

    • El modo Ultra necesita documentación más clara o advertencias. Muchos desarrolladores, incluyéndome, lo entendimos como una función universal donde el modelo trabaja más duro y da mejores resultados, pero en muchas tareas puede rendir peor y el costo definitivamente es mayor

  • Anthropic se está quedando muy atrás de OpenAI en coding. Hasta marzo estuve gestionando con Claude Code un repositorio de 400 mil líneas en el plan básico, pero era muy lento y no lograba corregir bien los problemas, aunque tenía tests, observabilidad, documentación y arquitectura en capas
    Somos un equipo de 3 personas que entrega a gobiernos locales; después de pasarnos a Codex, todo se volvió mucho más fácil y desapareció la ansiedad por el uso. Cada integrante del equipo administra todo con dos cuentas de Codex Plus. Anthropic, en vez de sembrar miedo, debería hacer modelos eficientes; no todo el mundo necesita Fable

    • Para mí, Opus 4.8 fue excelente y Codex estuvo apenas regular. Supongo que depende del usuario y del tipo de trabajo
    • Varía mucho según el dominio del problema y el lenguaje. GPT era bastante malo escribiendo Elixir y en tareas abiertas; ahora mismo Opus es más fuerte en Elixir, y Fable es muchísimo mejor que ambos entendiendo el dominio del problema
      Durante las 6 semanas en que me cambié a GPT, me dio una confianza equivocada de forma constante y al final lo dejé por completo; el trabajo de ese periodo fue básicamente tiempo perdido. Ahora uso una mezcla de Opus/Fable y DeepSeek Pro. DeepSeek es abrumadoramente mejor en costo-eficiencia y velocidad, y alcanza para el 90% del trabajo de implementación, pero se derrumba en Elixir cuando intenta usar funciones de runtime en tiempo de compilación. Fable resolvió rápido los problemas iniciales
      Cada modelo tiene fortalezas propias que son difíciles de descubrir, así que no parece que vayamos a usar solo uno en el futuro cercano. Cuando hace falta calidad, puedo sacrificar eficiencia sin problema

  • En mi trabajo, /goal reemplazó el modo de planificación, y para el 95% de las tareas con IA uso este enfoque
    Primero le hago leer una función específica y confirmar que la entendió por completo; si faltan detalles en el resumen, repito el proceso. Luego le pregunto la hora actual y, con /goal, le hago redactar durante cierto tiempo un documento de diseño técnico sin ambigüedades, incorporando explícitamente carry_forward_requirements.md y testing_best_practices.md. También incluyo referencias concretas a código y documentación, además de los cambios necesarios, para que hasta un implementador sin contexto pueda ejecutarlo, y le hago usar todo el tiempo revisando para que no termine antes
    Con solo obligar a GPT a dedicar 10 minutos a redactar el documento de diseño, obtuve resultados mucho más sólidos que con el modo de planificación, lo que me ahorró tiempo al corregir borradores

    • Hacer que termine en función del tiempo se parece a definir la condición de salida de una función recursiva según el tiempo transcurrido, no según el resultado real de la ejecución
      Yo pongo en /goal un objetivo explícito que el agente debe lograr. Presento las condiciones que deben cumplir el diseño y la arquitectura, comparo el resultado continuamente con ellas y prefiero que termine cuando todas se hayan cumplido. Ya sean 10 minutos o 10 horas, la clave de /goal es completar un resultado específico
    • Para que el agente logre objetivos de forma estable, la fase de generación de hipótesis parece ser lo más importante. Empezar desde el principio en el espacio de búsqueda correcto es el mejor predictor del éxito, y por muy fuerte que sea el modelo, hacer que avance desde cero entre todas las hipótesis dentro de un único gran bucle iterativo probablemente sea un callejón sin salida en trabajos prácticos
      En dominios complejos, delegar la investigación profunda a una llamada de herramienta separada fue la mejor forma de darle una base al agente. Si se deja la investigación al bucle principal del agente, la calidad empeora por la tendencia del RLHF a preservar el contexto y responder rápido. Si se ofrece como herramienta, puede investigar varias veces sin que parezca que está gastando miles de millones de tokens, y aunque se desperdicien muchos tokens en la generación y validación independiente de hipótesis, se puede ampliar el espacio de búsqueda entre 10 y 100 veces antes de modificar el entorno. En muchos casos, la prioridad exactitud > tiempo > costo es razonable
    • Me parece raro considerar que un LLM “entendió por completo” algo. Se parece a técnicas de prompting como “hasta estar 95% seguro”, y me da curiosidad qué efecto real tiene en el trabajo. También me pregunto qué cambiaría al escribir “hasta estar seguro de que lo entendió”

  • Me da curiosidad qué es /goal

    • Tanto Codex como Claude Code lo ofrecen, pero funcionan de forma un poco distinta
      En Claude Code, Haiku lee el historial de la conversación y decide si el objetivo se completó; si no, vuelve a inyectar el trabajo restante al modelo principal. En Codex, trabajan juntos las herramientas que puede invocar el modelo principal y el entorno de ejecución alrededor, y si no hay una marca de finalización, vuelve a hacer prompt
      Es una función pensada para resolver los casos en que el modelo se detiene tras completar solo parte de la tarea por problemas de atención. En vez de que el usuario tenga que insistir manualmente para que siga, le da instrucciones adicionales de forma automática para empujarlo a terminar
    • Si usas /goal desde el principio en Claude, no se detiene hasta lograr el objetivo o agotar las posibilidades del prompt. Se siente como “esta es la misión, ejecútala”, y lo uso unas cuantas veces por semana
    • Es una función donde el LLM se ejecuta en bucle hasta cumplir las condiciones del objetivo
    • Más exactamente, itera hasta que él mismo juzga que terminó el objetivo
    • La estructura es que el propio agente ejecuta el LLM en bucle y decide si debe detenerse. /goal se parece más a poner un agente padre encima, que le repite al agente hijo “todavía no has terminado, sigue” hasta que este decide que ya acabó

  • Desde el lanzamiento, he usado mucho GPT 5.6 Sol Xhigh y Fable 5. Su inteligencia parece similar a la 5.5, pero al llevar la persistencia al extremo, da la impresión de que mejoraron la tasa de finalización de tareas y la competitividad en benchmarks. A cambio, también aumenta la posibilidad de que recurra incluso a métodos anómalos o riesgosos, así que hay que vigilarlo constantemente
    Hace poco intentó leer por CLI variables de entorno del sistema que no tenían relación con el trabajo, y cuando no pudo acceder a claves SSH pidió permiso para controlar la computadora. Cuando lo detuve y le pregunté por qué, respondió que había intentado buscar la clave directamente en 1Password, y cuando volví a cuestionarlo admitió que no necesitaba las variables de entorno. Desde entonces desactivé el modo “approve for me” y solo lo uso para cambios simples y corrección de bugs
    Fable no solo parece más inteligente, también tiene más insight, capta mejor la intención y actúa como un gerente de producto especializado en el dominio, apoyado en conocimiento del mundo real. También propone cosas inesperadas, pero con GPT 5.6 hay que darle instrucciones mucho más literales

    • Fable parece un modelo más grande, así que el costo de ejecución es mayor, y en ingeniería de software general no parece claramente superior, pero en tareas que requieren inteligencia pura, su tamaño podría ser una ventaja
      En DeepSWE 1.1, 5.6-Sol xhigh obtiene una puntuación apenas superior a Fable 5 usando la mitad de tokens y con un costo de alrededor de un tercio. En cambio, en el índice de inteligencia de Artificial Analysis, Fable 5 queda apenas por delante, pero cuesta tres veces más
      Cuando programo, envío la misma tarea a ambos modelos para recibir varias respuestas, y como los resultados son subjetivos, es difícil predecir cuál ganará. La tarea del texto original tiene la ventaja de poder cuantificarse, pero muchas tareas de software son difíciles de evaluar así

  • Como GPT recientemente venció a participantes humanos de primer nivel en la competencia heurística de AtCoder, debería ser más fuerte en este tipo de problemas de optimización. Parece que Anthropic se enfoca relativamente menos en este tipo de tareas

  • Me gustaría ver no solo la puntuación final, sino también la mejor puntuación a lo largo del tiempo. Así sería más útil para juzgar el efecto de /goal

  • Solo hay una evaluación por modelo, y como es un espacio de problemas amplio donde hacen falta varios intentos para resolver bien, la mayoría de los resultados parecen ruido

    • En la práctica probé más veces cambiando el prompt y el tiempo de ejecución, pero cada vez el impacto de /goal fue pequeño o no significativo