Chain of thought y Tree of Thoughts: cuándo explorar alternativas

Frente a chain of thought, Tree of Thoughts justifica las llamadas adicionales al modelo cuando puedes evaluar una solución parcial antes de completarla. Una búsqueda pequeña puede llevar una solución base de 1 llamada a 21, como muestra el presupuesto ilustrativo de este artículo. Empieza con un modelo de razonamiento como referencia y añade ramas solo para resolver fallos que la búsqueda pueda corregir.

Fuentes verificadas el 24 de octubre de 2026. Los resultados de las pruebas que se presentan a continuación proceden exclusivamente del artículo original de 2023 de Shunyu Yao y sus colaboradores. Las ramas del ejemplo y los presupuestos de llamadas al modelo son cálculos explicativos, no resultados obtenidos en producción.

Tree of Thoughts: cómo funciona el árbol de pensamientos

Tree of Thoughts (ToT) permite que una aplicación compare soluciones incompletas y decida cuáles merece la pena seguir desarrollando. Un modelo de lenguaje grande, o LLM, propone los siguientes pasos; un evaluador juzga los estados resultantes; y un procedimiento de búsqueda decide qué conservar, ampliar o descartar. Yao y sus colaboradores presentaron este marco en mayo de 2023. Método del artículo original.

Imagina que buscas una ruta por un edificio. Al llegar a una intersección, puedes examinar varios pasillos antes de elegir. No tiene sentido seguir dedicando esfuerzo a un pasillo bloqueado. Otro que parece viable puede quedar pendiente mientras investigas una alternativa. La ventaja está en cambiar de rumbo cuando hacerlo todavía cuesta poco.

Un pensamiento es una unidad útil de trabajo intermedio: una ecuación, una palabra propuesta para un crucigrama o un esquema de escritura. Un estado recoge el problema original y la solución parcial construida hasta ese momento. La unidad debe ser lo bastante amplia como para poder evaluarla, pero lo bastante pequeña como para que resulte útil probar alternativas.

El ciclo consta de tres operaciones visibles:

• Ramificar: proponer distintos pasos siguientes a partir del estado actual.
• Evaluar: comprobar si cada estado resultante cumple las restricciones y tiene posibilidades de llegar a una respuesta válida.
• Podar: dejar de ampliar los estados descartados y dedicar el presupuesto restante a los candidatos más prometedores.

El artículo combina estas operaciones con la búsqueda en anchura, que conserva candidatos prometedores de un mismo nivel, y con la búsqueda en profundidad, que sigue una rama y puede retroceder si falla. El procedimiento se elige según la tarea. Ninguno exige entrenar un modelo nuevo. Marco y algoritmos de búsqueda.

Para quien desarrolla la aplicación, el cambio esencial consiste en poder controlar las alternativas intermedias. Pedirle a un modelo que parezca reflexivo no proporciona ese control.

Chain of thought y Tree of Thoughts: ¿en qué se diferencian?

La diferencia está en el momento de comparar alternativas: mientras una solución sigue incompleta o cuando ya se han generado respuestas enteras.

Esta es la distinción que recoge Yao y sus colaboradores en los antecedentes y el método. La autoconsistencia, o self-consistency, obtiene varias cadenas completas y elige la respuesta más frecuente. Para hacerlo, necesita una forma fiable de reconocer respuestas equivalentes: votar sobre un texto sin restricciones es menos directo que votar sobre un resultado numérico.

El prompting con cadena de pensamiento puede ayudar a expresar el trabajo intermedio. La autoconsistencia aporta diversidad entre intentos ya terminados. ToT añade un controlador capaz de detener una ruta débil antes de asumir el costo de completarla. Ese controlador también introduce un nuevo tipo de fallo: podar una ruta que habría llegado a buen término.

Otras dos técnicas cercanas resuelven problemas distintos. El few-shot prompting aporta ejemplos del comportamiento o del formato de salida deseados, por lo que puede ayudar al generador o al evaluador a cumplir lo especificado. El encadenamiento de prompts conecta etapas, como extraer datos y después redactar una respuesta. Una secuencia fija de etapas solo se convierte en una búsqueda cuando conserva alternativas y decide cuáles explorar.

Usa la estructura más sencilla que resuelva el fallo. Si el formato es inconsistente, hacen falta ejemplos más claros o validación. Si faltan pruebas, hace falta recuperar información. Ninguno de esos problemas exige automáticamente un árbol.

Un ejemplo paso a paso: ramificar, evaluar y podar

Una ecuación intermedia correcta también puede llevar a un callejón sin salida. Esa es la diferencia que debe detectar el evaluador.

Tomemos el ejemplo del Juego del 24 que aparece en el artículo: usar 4, 9, 10 y 13, cada uno exactamente una vez, con operaciones aritméticas básicas para obtener 24. El recorrido siguiente se ha construido para explicar el mecanismo; no es la transcripción de una respuesta de un modelo. Los estados viables e imposibles se comprobaron enumerando las combinaciones aritméticas restantes. Datos de entrada del ejemplo del artículo.

1. 1

   Crear ramas desde el estado inicial

   El candidato A calcula 4 + 9 = 13 y deja 10, 13, 13.

   El candidato B calcula 13 - 9 = 4 y deja 4, 4, 10.

   Ambos cálculos respetan las reglas. Los números repetidos representan valores restantes distintos; el estado debe conservar esa multiplicidad.

2. 2

   Evaluar los estados resultantes

   El candidato A no puede llegar a 24 usando cada valor restante una vez con suma, resta, multiplicación o división. Se poda esa rama.

   El candidato B admite una continuación válida: restar a 10 uno de los 4 restantes y multiplicar el resultado por el otro 4. Se conserva.

   Este ejemplo utiliza una comprobación aritmética exacta para que el juicio pueda verificarse. La búsqueda del artículo empleaba estimaciones de valor realizadas por el modelo, que pueden equivocarse.

3. 3

   Ampliar la rama que sigue en juego

   Desde 4, 4, 10, se puede probar 4 + 4 = 8, que deja 8, 10, o 10 - 4 = 6, que deja 4, 6.

   El primer estado no puede llegar a 24 con la operación restante. El segundo sí: 4 × 6 = 24. Se conserva esa continuación y se verifica la expresión completa.

4. 4

   Comprobar la respuesta final

   (13 - 9) × (10 - 4) = 24 utiliza cada número original una vez y da el resultado buscado. La búsqueda termina porque el resultado supera la comprobación de la tarea.

En un problema tan pequeño, un algoritmo exhaustivo puede resolverlo todo; añadir un LLM sería complicar el desarrollo sin necesidad. El ejemplo sirve para entender el ciclo. En una aplicación, suele resultar útil repartir el trabajo: el modelo propone planes plausibles y el código comprueba las restricciones que el modelo no debería adivinar.

Qué resultados publicó el artículo de Tree of Thoughts

Los resultados originales muestran que la búsqueda deliberada ayudó en las tareas elegidas por los autores. No establecen qué mejora cabe esperar en una carga de trabajo actual en producción.

Para el Juego del 24, los autores evaluaron GPT-4 en 100 problemas relativamente difíciles. Los experimentos se realizaron en mayo de 2023. La tabla 2 presenta estas tasas de éxito:

Fuente: Yao y colaboradores, tabla 2 y configuración del Juego del 24.

La anchura indica cuántos estados se conservan, no cuántas llamadas se hacen al modelo. Generar candidatos y evaluarlos añade trabajo. En la configuración del Juego del 24, los autores muestrearon tres veces la valoración de cada candidato. Configuración experimental.

El artículo también estudió las tareas de escritura creativa y minicrucigramas. Son tareas distintas, con métodos de evaluación diferentes. La conclusión práctica es más acotada que «ToT mejora los modelos»: la búsqueda puede ayudar cuando importa elegir una dirección intermedia prometedora y es posible evaluarla. Antes de añadir el controlador, sigue siendo necesario reunir pruebas específicas de la carga de trabajo.

¿Cuántas llamadas al modelo añade la ramificación?

Cuenta por separado la generación, la evaluación y la finalización. El evaluador puede consumir más llamadas que el generador de candidatos.

Veamos una búsqueda acotada e ilustrativa, independiente de la configuración del artículo. Una llamada es una solicitud al modelo emitida por la aplicación. Supongamos que una sola llamada de generación produce todos los hijos de un estado padre y que cada hijo recibe su propia llamada de evaluación. La búsqueda se detiene al alcanzar la profundidad elegida, sin reintentos ni salidas anticipadas, y después se utiliza una última llamada para generar la respuesta.

Se generan tres hijos por cada estado padre ampliado, se conservan dos estados después de cada nivel y se amplía el árbol durante tres niveles. Las cantidades de estados padre ampliados son 1, 2 y 2. Por tanto:

• Generación: 1 + 2 + 2 = 5 llamadas.
• Evaluación: 3 × (1 + 2 + 2) = 15 llamadas.
• Respuesta final: 1 llamada.
• Total: 5 + 15 + 1 = 21 llamadas, es decir, 21× una solución base de 1 llamada.

Si se repite tres veces la evaluación de cada candidato, el mismo árbol pasa a consumir 5 + 45 + 1 = 51 llamadas. Si se agrupan en una única solicitud todas las evaluaciones de candidatos de cada nivel, consume 5 + 3 + 1 = 9 llamadas. La agrupación cambia el contexto del evaluador y las condiciones en las que juzga: es una opción de implementación, no una garantía de calidad equivalente.

Como comparación, la autoconsistencia con cinco muestras solicitadas por separado utiliza cinco llamadas al modelo si la votación final se resuelve mediante código determinista. Añadir un modelo como juez supondría más llamadas y cambiaría esa comparación.

La regla general para contabilizarlas es C = Σ nₜ(g + kv) + f. Aquí, nₜ es el número de estados padre ampliados en el nivel t; g, las solicitudes de generación por estado padre; k, los hijos por estado padre; v, las solicitudes de evaluación por hijo; y f, las solicitudes de finalización. Esta fórmula presupone que cada hijo se evalúa por separado; si agrupas evaluaciones, contabiliza directamente las solicitudes agrupadas.

Cómo implementar Tree of Thoughts: el control de la búsqueda

Mantén el estado de la búsqueda y las reglas de parada en el código de la aplicación. Deja que el modelo proponga y evalúe resultados intermedios acotados que puedas inspeccionar.

El límite de esta arquitectura es la calidad del evaluador. Si no distingue una solución parcial viable de un callejón sin salida que suena convincente, ampliar más ramas solo le da más oportunidades de elegir mal.

1. 1

   Definir un estado que se pueda inspeccionar

   En una función de planificación de tareas sujeta a restricciones, el estado podría incluir las tareas asignadas, las pendientes, los intervalos ocupados y las restricciones aún no satisfechas. Define el siguiente pensamiento como una propuesta de asignación. Guarda por separado el estado, el identificador del candidato, el identificador del padre y las pruebas que lo sustentan.

   Elige un resultado intermedio que pueda comprobarse en esa etapa. Es difícil podar de forma fiable un párrafo vago que se limita a afirmar que la estrategia es buena.

2. 2

   Separar el trabajo del generador y el del evaluador

   Una instrucción para el generador podría ser: «Propón distintas asignaciones siguientes a partir de este estado. Devuelve la asignación y el estado actualizado de cada candidato. Respeta las restricciones indicadas».

   Una instrucción para el evaluador podría ser: «Comprueba cada candidato frente a las restricciones. Devuelve su identificador, las restricciones que incumpla y si continuar es viable, incierto o imposible. Cita los campos del estado que sustentan el juicio».

   Aplica primero comprobaciones deterministas para reglas como la ausencia de solapamientos entre intervalos o la presencia de campos obligatorios. Si necesitas el juicio de un modelo, valídalo con casos conocidos mediante un proceso de evaluación con un LLM como juez.

3. 3

   Hacer explícitos la poda y el presupuesto

   Descarta los estados que incumplan una restricción obligatoria. Ordena los candidatos restantes, conserva un conjunto acotado de estados pendientes de explorar y elimina duplicados. Mantén disponibles los candidatos inciertos cuando lo permita el presupuesto: que el evaluador tenga poca confianza no demuestra que una rama sea imposible.

   Haz que el controlador imponga límites de solicitudes, profundidad, tokens y tiempo transcurrido. Incluye la evaluación y los reintentos en esos límites. Registra qué se descartó y por qué, para poder examinar los casos en los que la poda eliminó la ruta que habría dado resultado.

4. 4

   Verificar antes de aceptar o actuar

   Aplica una comprobación final, como verificar que se cumplen todas las restricciones de planificación o que pasan las pruebas de software pertinentes. Si ningún candidato cumple los requisitos antes de agotar el presupuesto, devuelve un resultado sin resolver o envíalo a revisión.

   Explora las ramas en un entorno aislado o mantenlas como propuestas de acción. Una rama de planificación que aún se está evaluando no debería enviar invitaciones. Una rama de programación no debería desplegar cambios mientras el controlador sigue comparando candidatos.

Evalúa tanto al evaluador como la respuesta final. Un rechazo incorrecto puede eliminar para siempre la rama útil. Una aceptación incorrecta puede agotar el presupuesto restante ampliando un callejón sin salida. Cada fallo exige una solución distinta.

¿Cuándo basta con un modelo de razonamiento?

Un ToT externo resulta innecesario cuando un modelo de razonamiento ya cumple los requisitos de calidad y latencia, y la aplicación no necesita controlar las alternativas intermedias.

Un modelo de razonamiento realiza trabajo interno antes de responder. La guía actual de prompting de Anthropic recomienda dar objetivos generales a sus modelos con capacidades de razonamiento, en lugar de prescribir cada paso. Esto respalda empezar con una tarea clara, restricciones y criterios de aceptación. No demuestra que un modelo concreto implemente internamente el algoritmo ToT de Yao y sus colaboradores. Guía de prompting de Anthropic.

Si estás incorporando una pequeña transformación de código, prueba primero un modelo de razonamiento adecuado y somete el resultado a las pruebas pertinentes. Si esa solución base cumple el criterio de lanzamiento, un árbol externo añade gestión de estados, evaluación y manejo de fallos sin un beneficio demostrado.

Considera la búsqueda externa cuando la aplicación pueda aportar algo más: un simulador, un verificador de restricciones, entornos de prueba aislados o la necesidad de conservar planes candidatos distintos. Un modelo más capaz puede seguir actuando como generador dentro de esa búsqueda. El razonamiento del modelo y la búsqueda controlada por la aplicación son decisiones de diseño independientes.

La decisión debe basarse en resultados: conserva el árbol solo si mejora los resultados verificados lo suficiente como para justificar el consumo de recursos medido. Una respuesta más larga o una traza más elaborada no son el criterio de éxito.

Qué se exagera sobre Tree of Thoughts

Un prompt que pide debatir a expertos imaginarios no proporciona por sí solo una búsqueda en árbol controlada. Puede producir alternativas, pero una implementación de ToT en producción necesita un estado explícito, evaluación, selección de ramas y una política de parada. Si todo eso existe únicamente dentro de una sola respuesta generada, no puedes dar por hecho que la búsqueda descrita se haya ejecutado como pretendías.

También se exagera al afirmar que más ramas garantizan una respuesta mejor. Las ramas pueden repetir la misma idea. El juez puede compartir una suposición equivocada del generador. Una poda temprana puede descartar la única continuación útil. Expresarse con seguridad no sustituye la comprobación de la tarea.

Por último, el mejor resultado del artículo en el Juego del 24 no demuestra que todos los flujos de trabajo empresariales necesiten ToT. Un extractor de documentos que no respeta el esquema puede necesitar mejores ejemplos y validación. Un asistente de soporte al que le falta una política puede necesitar la fuente correcta. Explorar más rutas con la misma información incompleta no aporta el dato que falta.

Usa la búsqueda para comparar decisiones alternativas que puedas evaluar. Resuelve directamente la falta de contexto y los incumplimientos de las especificaciones.

Qué cambiar esta semana en tu aplicación

Actúa ahora si tus casos fallidos contienen decisiones iniciales que aún se pueden corregir y tienes una forma fiable de valorar los estados intermedios. Por ejemplo, cambios de código candidatos comprobados en entornos aislados o planes contrastados con restricciones explícitas de planificación. Empieza con una vía limitada a esos casos y un presupuesto fijo de búsqueda.

Espera si todavía no puedes explicar por qué una solución parcial es mejor que otra. Reúne un conjunto de estados aceptables e inaceptables, comprueba las decisiones del evaluador y mejora su criterio antes de ampliar el árbol.

Si el flujo consiste en extracción sencilla, clasificación o una secuencia fija que ya cumple sus criterios de aceptación, este cambio apenas te afecta. Conserva su estructura más simple.

El siguiente paso para el lunes es concreto: toma casos fallidos de tu flujo actual con chain-of-thought y compara una solución base con un modelo de razonamiento frente a una variante acotada de ToT, usando las mismas tareas reservadas para evaluación. Mantén el verificador final sin cambios. Registra resultados aceptados, llamadas al modelo, tokens, latencia y casos en los que la poda eliminó una ruta válida. Adopta la búsqueda solo en el subconjunto de tareas donde los resultados lo justifiquen.

Preguntas frecuentes sobre Tree of Thoughts

¿Razonamiento y chain-of-thought son lo mismo?

El razonamiento es la capacidad más amplia de resolver un problema. Chain-of-thought es una técnica de prompting que utiliza pasos intermedios. Un modelo puede razonar internamente sin mostrar esos pasos en su respuesta.

¿Qué es un árbol en IA?

Un árbol representa estados y posibles acciones siguientes. Un nodo es un estado y sus hijos son las alternativas a las que se llega al dar otro paso. En ToT, esos estados representan soluciones parciales.

¿Qué es un árbol de razonamiento?

En este contexto, consiste en organizar soluciones parciales alternativas en ramas, evaluarlas y elegir cuáles continuar. El marco concreto de Yao y sus colaboradores se llama Tree of Thoughts.

¿Qué es el prompting con Tree of Thoughts?

Utiliza un modelo de lenguaje para proponer y evaluar alternativas intermedias, junto con un procedimiento de búsqueda que selecciona qué estados ampliar. La ventaja práctica es poder reconsiderar una decisión antes de completar toda la respuesta.

¿Cuáles son las tres C del prompting?

El algoritmo ToT de Yao y sus colaboradores no define una regla de las tres C. Esa regla mnemotécnica no es su especificación: el artículo describe la descomposición en pensamientos, su generación, la evaluación de estados y la búsqueda.

¿En qué se diferencian una cadena de pensamiento y un árbol de pensamientos?

CoT, en su forma habitual, produce una ruta continua de razonamiento. ToT considera explícitamente rutas parciales alternativas y las evalúa durante la búsqueda. La autoconsistencia sigue otro enfoque: obtiene rutas completas y combina las respuestas finales.

¿Puedes dar un ejemplo de prompting con cadena de pensamiento?

Una demostración aritmética paso a paso podría mostrar 13 - 9 = 4, después 10 - 4 = 6 y, por último, 4 × 6 = 24. Proporcionar esos pasos intermedios como ejemplo ilustra CoT. Comparar pasos alternativos y decidir qué rama conservar añade el mecanismo de búsqueda de ToT.

¿Qué es chain-of-thought en palabras sencillas?

Conecta una pregunta con su respuesta mediante pasos intermedios, como cálculos o deducciones. Esos pasos pueden facilitar la comprensión de la tarea, pero también pueden contener errores.

¿Cómo funciona realmente chain-of-thought?

En la configuración habitual de prompting, el modelo genera una secuencia de pasos intermedios a partir del problema y del texto generado previamente, y después produce una respuesta. Esa secuencia, por sí sola, no aporta una comprobación independiente de corrección ni un conjunto de estados pendientes de búsqueda gestionado por la aplicación.

Suscríbete al boletín para recibir guías prácticas sobre cómo crear flujos de trabajo de IA fiables.