Niveles de razonamiento de GPT-6 Astra: cómo elegir el ajuste adecuado

Elige el nivel según la tarea y el tipo de fallo

La siguiente tabla es un punto de partida editorial para una evaluación, no una garantía oficial que asigne cada tarea a un ajuste.

Evita una política que aumente el esfuerzo del modelo después de cualquier respuesta imperfecta. Algunos fallos se deben a datos ausentes, instrucciones incompatibles, herramientas no disponibles o un entorno averiado. Requieren otra intervención.

Los niveles de razonamiento disponibles en Astra

Según la consulta del 14 de septiembre de 2026, la documentación del modelo GPT-6 Astra enumera low, medium, high, xhigh y max. Son ajustes del mismo modelo, no familias de modelos distintas. La página describe el razonamiento junto con sus demás capacidades; la disponibilidad en una interfaz de producto debe comprobarse por separado.

Un ajuste de esfuerzo no sustituye a una especificación de salida. Pedir más razonamiento no indica al modelo qué rama del repositorio debe usar, qué constituye un cálculo correcto ni si puede modificar archivos. Incluye primero esos requisitos en la tarea.

La diferencia importa en la práctica. «Mejora este juego» no define el éxito. «Inspecciona el reinicio e identifica por qué la puntuación persiste al abrir una nueva sesión; no edites archivos» aporta un objetivo verificable y un límite explícito. Cambiar el esfuerzo antes de corregir el primer encargo confunde la ambigüedad de la tarea con la capacidad del modelo.

Un fallo de reinicio de puzle frente a una etiqueta breve

En un flujo de trabajo de juegos, escribir una etiqueta corta e investigar un fallo intermitente de guardado son tareas diferentes. La etiqueta se puede contrastar con un límite de caracteres y unas pautas de tono. El fallo puede exigir seguir el estado entre reinicios, recargas y cambios de sesión. Evalúa estas familias de tareas por separado.

Los juegos de puzles ofrecen casos observables útiles: anota qué borra un reinicio, si una pista persiste y cómo se registra un nivel completado. Convierte tus observaciones en criterios de aceptación para un prototipo que controles. Los juegos enlazados no demuestran el uso de Astra.

Un posible encargo de prueba pediría a un asistente de programación que inspeccione un prototipo local, describa su reinicio y proponga pruebas sin modificar el código. Solo después de revisar ese trabajo debería una instrucción independiente autorizar cambios. Así se separa el esfuerzo de razonamiento del permiso para actuar.

Si una etiqueta incumple el límite de caracteres, normalmente hacen falta una restricción más clara o un validador. En el fallo de reinicio, comprueba si el asistente encontró la transición de estado pertinente y un error reproducible. Merece la pena evaluar un aumento de esfuerzo cuando las pruebas están disponibles pero el diagnóstico no capta esa relación, no cuando nunca se facilitó el código fuente.

Construye una evaluación de esfuerzo repetible

Prepara un pequeño conjunto de tareas representativas antes de cambiar los valores de producción. Incluye casos fáciles, difíciles y al menos algunos cuya respuesta correcta sea señalar que falta información. Mantén iguales los materiales de entrada, las herramientas permitidas y la salida esperada entre niveles.

Cuando sea posible, puntúa los resultados sin mirar la etiqueta de esfuerzo. Una explicación larga puede parecer convincente aunque introduzca supuestos sin respaldo. Separa exactitud factual, cumplimiento de instrucciones y formato para que una respuesta pulida no oculte un fallo crítico.

Registra el tiempo total, los reintentos y el trabajo de revisión. Una respuesta rápida que exige correcciones repetidas puede servir menos que otra más lenta pero aceptable de inmediato. A la inversa, esperar más no aporta valor si no cambia la aceptación de la tarea.

No conviertas este planteamiento en una afirmación pública de rendimiento hasta haber ejecutado la evaluación y documentado sus límites.

Como evaluación concreta, prepara diez tareas representativas y aplica las mismas pruebas con esfuerzo low y high. Diez es un piloto manejable, no una prueba comparativa estadísticamente fiable. Cuenta los resultados aceptados, registra la latencia total e incluye el tiempo de corrección. Si ambos ajustes superan las mismas tareas, el flujo más rápido o barato es la mejor opción predeterminada para esa muestra; si high resuelve un fallo crítico, reserva el aumento para esa familia de tareas. No hemos ejecutado este ejemplo.

• ID de tarea y versión de entrada.
• ID de modelo y ajuste de esfuerzo.
• Comprobaciones requeridas y resultados de aprobación o fallo.
• Tiempo total, reintentos y fallos de herramientas.
• Uso informado por la API.
• Correcciones del revisor y aceptación final.

Configura el esfuerzo sin confundirlo con la extensión

La guía oficial del modelo distingue los ajustes de esfuerzo admitidos de los demás parámetros. Comprueba el formato del endpoint y del SDK que utilizas, en lugar de copiar un parámetro de otra interfaz.

Una separación operativa útil consiste en especificar la respuesta final por un lado y el trabajo necesario para producirla por otro. Por ejemplo, pide un diagnóstico breve con el componente afectado, las pruebas de apoyo y la siguiente acción. Una investigación compleja puede así terminar en una respuesta concisa.

No solicites razonamiento interno oculto como técnica de depuración. Pide un resumen de evidencias, supuestos, resultados de pruebas y preguntas pendientes. Son entregables que un revisor puede comprobar.

Cambia el esfuerzo cuando cambie la tarea

Una conversación puede empezar con un diagnóstico difícil y continuar con un trabajo rutinario de formato. Eso no implica que todos los turnos posteriores necesiten el esfuerzo del primero.

La guía de razonamiento documenta un mecanismo de actualización de configuración para cambiar el esfuerzo entre respuestas conservando el prefijo original. El soporte indicado es GPT-6 Astra en modo estándar de un solo agente. Considera esas condiciones parte de la función, no detalles opcionales.

Antes de adoptar esa política, decide qué activa el aumento y quién puede autorizar trabajo costoso. «La tarea es larga» suele ser demasiado vago. «El intento actual falló la misma prueba de corrección y dispone de las evidencias necesarias» es una señal más útil para evaluar.

Elige una política que puedas explicar

El mejor ajuste predeterminado es el que respaldan las evidencias de tus tareas. Revísalo cuando cambien las entradas, las herramientas o los criterios de aceptación. Conserva ejemplos fallidos además de demostraciones exitosas: revelan cuándo hacen falta un mayor esfuerzo o una revisión humana.

Si necesitas otra referencia desde la perspectiva del jugador para el encargo de prueba, compara juegos que puedes jugar en el navegador y anota un requisito observable cada vez. Separa ese ejercicio de la evaluación controlada del modelo: una experiencia fluida es un objetivo de diseño, no una puntuación comparativa.