Cómo elegir y usar prompts con modelos de razonamiento

Los proveedores ofrecen razonamiento de formas distintas. OpenAI utiliza niveles y modos de esfuerzo de razonamiento en los modelos compatibles, Anthropic documenta el pensamiento adaptativo y extendido, y Google documenta niveles o presupuestos de pensamiento para los modelos Gemini compatibles. Las etiquetas de producto y los parámetros cambian, así que elige a partir de la documentación actual del proveedor y del rendimiento medido en la tarea, no de una lista fija de nombres de modelos.

Algunos modelos de razonamiento se benefician de un estilo de prompting distinto al de las configuraciones sin razonamiento. Para los modelos de razonamiento de OpenAI, la recomendación actual es empezar con prompts directos y no pedir una cadena de pensamiento. Trata las afirmaciones más amplias sobre el andamiaje, los roles y la autocrítica como hipótesis que debes probar con tu modelo y carga de trabajo, no como reglas transferibles entre proveedores.

A continuación se explica qué son, cuándo utilizarlos, cómo redactar buenos prompts para ellos y qué dificultades afectan incluso a usuarios experimentados.

Qué cambian los controles de razonamiento

Los proveedores utilizan etiquetas como razonamiento, pensamiento, esfuerzo y presupuesto para controles que pueden modificar el uso de tokens, la latencia y la calidad del resultado. Según el proveedor y la configuración, el contenido de razonamiento puede permanecer oculto, resumirse, omitirse o devolverse en bloques separados. No infieras el proceso oculto de un proveedor a partir de una etiqueta ni del estilo de la respuesta final.

El razonamiento puede mejorar los resultados en algunas tareas difíciles y de varios pasos, pero la ganancia depende del modelo, el nivel de esfuerzo, el prompt y la evaluación. También puede aumentar la latencia y los tokens de razonamiento facturados. Elegir entre una configuración de menor latencia y más razonamiento es, por tanto, una decisión arquitectónica que debe compararse con pruebas, no una mejora universal.

Algunas familias de productos de razonamiento disponibles en 2026 son:

• Modos de razonamiento de OpenAI. OpenAI ha ofrecido modelos de la serie o y modos de razonamiento GPT; la disponibilidad y las fechas de retirada varían según el producto y el plan, así que consulta la guía de modelos actual antes de estandarizar.
• Modelos Claude con pensamiento. La documentación actual de Anthropic indica que el pensamiento está disponible en modelos Claude actuales, pero la configuración compatible varía: algunos utilizan pensamiento adaptativo, mientras que budget_tokens manual no es compatible o está obsoleto en otros. Sigue la tabla específica de cada modelo en lugar de aplicar una receta genérica.
• DeepSeek R1. El artículo de R1 describe la familia de modelos y el método de entrenamiento. Consulta la documentación oficial actual de DeepSeek para conocer los modelos compatibles y los métodos de acceso.
• Modos de pensamiento de Gemini. Los modelos compatibles de la API de Gemini ofrecen controles específicos del proveedor, documentados en la guía de pensamiento de Gemini.
• Ofertas de otros proveedores. Considera que los nombres de productos, los derechos de acceso y los controles cambian con el tiempo. Verifícalos en la documentación oficial actual del proveedor antes de adoptarlos o recomendarlos.

Estos productos difieren en el comportamiento del modelo, los controles compatibles, el coste, la latencia y la cantidad de razonamiento visible. No des por hecho que un parámetro o una regla de prompting se transfiere sin cambios entre proveedores.

Cuándo probar más razonamiento

Un modelo de razonamiento o un ajuste de mayor esfuerzo puede ser una comparación pertinente. Utiliza estas señales de la tarea y estos límites al definir el experimento:

• El problema tiene múltiples pasos que se construyen entre sí. Matemáticas, lógica, planificación de múltiples pasos, código que requiere rastrear el estado.
• Una configuración con menos razonamiento sigue fallando en los mismos casos evaluados. En ese momento, un modelo de razonamiento o un mayor nivel de esfuerzo es un experimento pertinente. Compara ambas configuraciones en los mismos casos.
• La tarea exige una comparación minuciosa o un análisis de ventajas y desventajas. Decisiones multicriterio, elecciones arquitectónicas o evaluación de proveedores.
• Tu evaluación incluye casos límite que las configuraciones con menos razonamiento no resuelven. Mide esos casos de forma directa en lugar de inferir la calidad del razonamiento a partir de un texto fluido.
• La tarea tiene consecuencias importantes. No elijas más razonamiento solo porque el riesgo sea alto. En finanzas, derecho, medicina, seguridad u operaciones de producción, utiliza fuentes autorizadas, revisión cualificada, controles validados y un límite de decisión documentado. Después, prueba si la configuración de razonamiento mejora los casos relevantes.

Casos en los que una referencia con menos razonamiento puede ser competitiva:

• Chat conversacional sensible a la latencia. Utiliza más razonamiento solo si la mejora de calidad medida justifica una interacción más lenta.
• Generación y redacción cuando las evaluaciones no muestran ninguna ventaja. Una configuración de menor latencia puede ser mejor para la iteración creativa; compara la calidad del resultado en lugar de suponer que más razonamiento ayuda o perjudica.
• Recuperación sencilla. Una consulta fundamentada en fuentes o una configuración con menos razonamiento puede cumplir el objetivo de calidad con menos latencia y coste. Verifica la fuente en ambos casos.
• Refinamiento iterativo rápido. Una latencia menor puede mejorar la interacción, pero compara el éxito final de la tarea en lugar de limitarte a contar turnos.
• Tareas en las que necesitas evidencia intermedia auditable. Solicita cálculos, fuentes, resultados de pruebas u otros artefactos verificables. Una narración visible de la cadena de pensamiento no demuestra que la conclusión sea correcta.

Una regla de decisión útil consiste en aumentar el razonamiento solo cuando la mejora de calidad esperada compense la latencia y el coste medidos para ese flujo de trabajo.

Patrones de prompts que conviene comparar

Empieza con un prompt directo y centrado en el resultado. Después, compara estos patrones cuando puedan cambiar de forma sustancial el resultado:

1. Utiliza un prompt directo como referencia para OpenAI

Para los modelos de razonamiento de OpenAI, las prácticas recomendadas de OpenAI indican que prompts como «piensa paso a paso» son innecesarios y, en ocasiones, pueden perjudicar el rendimiento. Otros proveedores ofrecen controles distintos, así que compara un prompt directo con cualquier variante más estructurada que estés considerando.

Malo: Piensa paso a paso. Resuelve esto cuidadosamente. Muestra tu trabajo. [problem]

Bueno: [problem]

Expón el problema con claridad y verifica la conclusión. Para otros proveedores, sigue la documentación actual y prueba el prompt o control compatible.

2. Compara los prompts directos con el andamiaje procedimental

Un andamiaje detallado puede duplicar el trabajo que ya realiza un modelo de razonamiento. Empieza con el objetivo, el contexto pertinente, las restricciones firmes, la evidencia necesaria y el formato de salida. Elimina pasos de procedimiento solo cuando una evaluación demuestre que el prompt más sencillo conserva el comportamiento que necesitas.

Candidato con andamiaje procedimental: Primero, enumera las restricciones clave. Luego enumera las opciones. Luego evalúa cada opción contra cada restricción. Luego elige. Luego justifica. Formato de salida: …

Candidato directo: Ayúdame a decidir entre la opción A y la opción B. Contexto: […]

El prompt más sencillo deja al modelo elegir un enfoque y conserva las restricciones y el contrato de salida que realmente necesitas.

3. Prueba la combinación de técnicas en lugar de suponer que ayuda

Los prompts de cadena de pensamiento, autocrítica y búsqueda en árbol añaden instrucciones y tokens. No des por hecho que combinarlos mejora la respuesta evaluada.

Si el prompt dice «piensa paso a paso, critica tu respuesta y revísala», compáralo con una versión más sencilla. Conserva la que rinda mejor en casos representativos.

4. Utiliza roles solo cuando aporten información sobre la tarea

Los personajes elaborados suelen añadir detalles imposibles de verificar sin cambiar la tarea. Utiliza un rol cuando establezca el alcance, la audiencia, la política o la terminología; en los demás casos, prefiere una descripción directa del trabajo. Si parece que el rol mejora el resultado, confirma la mejora en los mismos casos de evaluación en lugar de atribuírsela al personaje por intuición.

Un rol breve puede ser útil para establecer el tono y el registro. Compáralo con instrucciones concretas equivalentes cuando la coherencia sea importante.

Malo: Eres un ingeniero backend sénior de categoría mundial con 20+ años de experiencia…

Bueno: Ayúdame a razonar sobre este problema de sistemas distribuidos. [problem]

5. Solicita evidencia, no razonamiento oculto

Algunos productos ocultan o resumen el razonamiento interno. Pedir al modelo que «muestre el razonamiento» solicita una explicación generada, no necesariamente su traza privada ni una prueba de corrección.

Si necesitas auditabilidad, solicita una justificación breve y evidencia comprobable. La API actual de Anthropic puede devolver un resumen del pensamiento u omitirlo según el modelo y la configuración; ninguna de las dos opciones sustituye la verificación del resultado.

Qué incluir en el prompt

Una base útil incluye:

Especificidad. Proporciona los números, fechas, restricciones exactas, archivos y demás datos necesarios para resolver y verificar la tarea.

Planteamiento abierto cuando el contrato de salida lo permita. «Esta es la situación y esto es lo que quiero averiguar. ¿Qué opinas?» puede servir como referencia con la que comparar una plantilla más rígida.

Incertidumbre honesta. Dile al modelo lo que no sabes. «No estoy seguro de si X o Y; ayúdame a identificar qué evidencia permitiría distinguirlos» resulta más útil que ocultar la ambigüedad.

Permiso para discrepar. «Cuestiona mi planteamiento si es incorrecto» o «dime qué no estoy considerando» puede sacar a la luz alternativas que un prompt orientado a la confirmación suprimiría.

Datos concretos. Las hojas de cálculo, el código y los documentos ofrecen artefactos reales que el modelo puede inspeccionar. Compártelos solo cuando la herramienta esté autorizada para tratar esos datos y elimina la información que la tarea no necesite.

Ejemplos prácticos

Ejemplo 1: Una tarea de depuración

Supón que tienes un error difícil.

Prompt con andamiaje procedimental:

Eres un ingeniero sénior especializado en TypeScript. Piensa paso a paso sobre este error.

Primero, identifica las partes relevantes del código. Segundo, rastrea el flujo de datos. Tercero, identifica causas probables. Cuarto, recomienda una solución.

Aquí está el error: [description] Aquí está el código: [code]

Prompt directo:

Ayúdame a encontrar este error.

Síntomas: [description] Código relevante: [code] Lo que ya he intentado: [list]

Compara el prompt directo con la versión provista de andamiaje en errores representativos. Mide la corrección, la evidencia exigida, la latencia y el coste. No infieras a partir de este ejemplo que la versión directa es mejor.

Ejemplo 2: Una decisión estratégica

Prompt estructurado:

Eres un consultor sénior de estrategia. Estoy intentando decidir si lanzar el producto X. Aplica el marco [framework name]. Primero… [long structured prompt]

Prompt directo:

Estoy tratando de decidir si lanzar el producto X. Contexto:

• Somos una empresa de 50 personas con $5M de ARR.
• El producto tardaría 2 trimestres en desarrollarse.
• Es adyacente pero no directamente competitivo con nuestro producto principal.
• Dos de nuestros 10 clientes principales han solicitado que lo hagamos.
• La capacidad del equipo ya está al límite.

Ayúdame a analizarlo. Cuestiona los argumentos débiles y dime qué no estoy considerando.

El prompt directo deja al modelo margen para elegir la estructura de análisis. Compáralo con la variante estructurada utilizando los mismos criterios de decisión antes de adoptar cualquiera de los dos como plantilla.

Ejemplo 3: Análisis de código complejo

Prompt con andamiaje procedimental:

Analiza este código para detectar problemas de rendimiento. Piensa paso a paso. Primero identifica las estructuras de datos, luego sigue la complejidad del algoritmo y después señala cuellos de botella concretos. [code]

Prompt directo:

¿Qué hace lento este código? Ahora tarda ~3 segundos con una entrada típica; quiero reducirlo a menos de 500ms.

[code]

Comprueba si el prompt directo identifica el cuello de botella pertinente y produce una corrección válida. Verifica cada propuesta con datos de perfiles, pruebas y benchmarks.

Trampas específicas de los modelos de razonamiento

Una lista corta de cosas que atrapan incluso a usuarios experimentados:

La latencia. Un mayor razonamiento puede aumentar el tiempo de respuesta, en ocasiones de forma considerable. Mide la distribución real para tu modelo y carga de trabajo, incluidos los tiempos de espera agotados, en lugar de planificar a partir de una estimación genérica.

El coste. Los proveedores contabilizan el razonamiento de formas distintas y los precios de los modelos cambian. Mide los tokens de entrada, salida y razonamiento facturados en solicitudes representativas, y compara el coste total de la tarea en lugar de suponer un multiplicador fijo.

Una respuesta alcanza sus límites de generación. Los tokens de razonamiento y de respuesta comparten los límites de formas distintas según el proveedor. Si una respuesta se interrumpe, comprueba el motivo de finalización y la contabilidad de tokens del proveedor. Después, acota la tarea o ajusta únicamente los controles compatibles con ese modelo; no des por hecho que todas las API aceptan un presupuesto genérico de pensamiento.

Respuestas largas, atascadas o improductivas. Puedes observar una latencia inusualmente alta, tiempos de espera agotados, repeticiones o una respuesta final que no cumple la tarea. Registra el fallo observable y la configuración. Después, vuelve a intentarlo dentro de tu política, acota la tarea o compara otro ajuste compatible; no afirmes conocer la causa oculta basándote solo en el resultado.

Conclusiones fluidas pero sin respaldo. Un mayor razonamiento no demuestra que la respuesta sea correcta. En resultados críticos, exige fuentes, cálculos, pruebas y las suposiciones o nuevas evidencias que cambiarían la conclusión; la confianza declarada por el propio modelo no es una garantía calibrada.

Coste variable entre solicitudes. El uso de tokens de razonamiento puede variar según la tarea y la configuración. Registra el uso real en lugar de suponer que cada solicitud cuesta lo mismo o que el coste crece de forma predecible con la dificultad subjetiva.

Un flujo de trabajo por etapas que conviene probar

Una opción candidata es una ruta por etapas:

1. Configuración de menor latencia para delimitar la tarea e identificar las subpreguntas.
2. Configuración de mayor razonamiento para las subpreguntas evaluadas en las que la referencia no cumple los requisitos.
3. Configuración de producción autorizada para adaptar el resultado verificado al formato de destino.

Compara esta ruta con una referencia de una sola configuración. Mide la tasa de éxito de la tarea, la integridad de la evidencia, los errores de transferencia, el cumplimiento de los niveles de servicio, la latencia de extremo a extremo y el coste total. Las etapas adicionales solo son útiles cuando el flujo final mejora lo suficiente como para justificar su complejidad operativa.

Un ejemplo práctico: una tarea de análisis de mercado.

• Etapa de delimitación: «Quiero entender el mercado de X. Ayúdame a delimitar el análisis: ¿qué debería examinar, qué datos necesito y qué preguntas importan?»
• Etapa de análisis: «Dados los datos verificados que he recopilado, ¿qué implican para [specific strategic question]? Identifica los supuestos y las lagunas de evidencia».
• Etapa de formato: «Convierte los hallazgos verificados en un resumen de una página para el equipo directivo. Conserva las fuentes y la incertidumbre».

Esta división es un flujo de trabajo comprobable, no una solución óptima garantizada. Compárala con una referencia de un solo modelo en calidad, latencia y coste.

Algunos hábitos prácticos

Define la referencia válida. La comparación debe cumplir los mismos requisitos de datos, seguridad, herramientas y salida que el candidato de razonamiento.

Predefine la regla de decisión. Elige la métrica de calidad, el objetivo de nivel de servicio, el límite de coste y la mejora mínima antes de ver los resultados.

Controla los costes. Revisa el consumo del plan o la facturación de la API para conocer tu gasto mensual y ajustar el uso.

Detecta fallos reiterados de la referencia de menor latencia. Es un buen desencadenante para probar más razonamiento en los mismos casos.

Compara un solo cambio en el prompt cada vez. Ante una respuesta débil, prueba por separado un prompt más breve, contexto adicional u otro ajuste de razonamiento compatible, de modo que el resultado se pueda interpretar.

Elige con evidencia

Las configuraciones de razonamiento no son automáticamente mejores ni peores. Empieza con un prompt claro y directo, conserva las restricciones reales y los requisitos de evidencia, y añade estructura o esfuerzo de razonamiento solo cuando lo justifiquen evaluaciones representativas.

Utiliza el razonamiento de forma deliberada y empieza con un prompt sencillo. Un modelo de menor latencia para explorar, seguido de más razonamiento en los cuellos de botella evaluados, es uno de los patrones que merece la pena comparar con un flujo de un solo modelo.