Tree of Thought: quando a busca em árvore compensa

O prompting com Tree of Thought compensa as chamadas extras ao modelo quando é possível avaliar soluções parciais antes de concluí-las. No orçamento ilustrativo apresentado abaixo, uma busca pequena pode transformar uma abordagem de referência de 1 chamada em 21 chamadas. Comece com um modelo de raciocínio como referência e acrescente ramificações apenas para corrigir falhas que a busca consiga resolver.

Fontes verificadas em 24 de outubro de 2026. Os resultados dos benchmarks abaixo vêm exclusivamente do artigo original de 2023, de Shunyu Yao e colegas. As ramificações demonstradas e os orçamentos de chamadas ao modelo são cálculos explicativos, não resultados observados em produção.

Como funciona a busca em árvore no Tree of Thought?

Tree of Thoughts (ToT), ou árvore de pensamentos, permite que a aplicação compare soluções ainda incompletas e escolha quais merecem mais trabalho. Um modelo de linguagem de grande porte, ou LLM, propõe os próximos passos; um avaliador julga os estados resultantes; e um procedimento de busca decide o que manter, expandir ou abandonar. Yao e colegas apresentaram esse framework em maio de 2023. Método no artigo original.

Imagine que você esteja planejando um trajeto dentro de um prédio. Ao chegar a uma bifurcação, pode examinar vários corredores antes de escolher um. Um corredor bloqueado não deve continuar consumindo esforço. Já um caminho viável pode ficar em aberto enquanto você investiga outro. A vantagem está em mudar de rumo enquanto essa decisão ainda custa pouco.

Um pensamento é uma unidade útil de trabalho intermediário: uma equação, uma palavra sugerida para palavras cruzadas ou um plano de escrita, por exemplo. Um estado registra o problema original e a solução parcial construída até aquele momento. Essa unidade precisa ser grande o suficiente para ser avaliada, mas pequena o bastante para que testar alternativas faça sentido.

O ciclo tem três operações explícitas:

• Ramificar: propor próximos passos distintos a partir do estado atual.
• Avaliar: verificar cada estado resultante em relação às restrições e à possibilidade de chegar a uma resposta válida.
• Podar: parar de expandir os estados rejeitados e concentrar o orçamento restante nos candidatos mais promissores.

O artigo combina essas operações com a busca em largura, que mantém candidatos promissores ao longo de um nível, e a busca em profundidade, que segue uma ramificação e pode voltar atrás quando ela falha. O procedimento de busca depende da tarefa. Nenhuma das opções exige treinar um novo modelo. Framework e algoritmos de busca.

Para quem desenvolve aplicações, a mudança central é poder controlar as alternativas intermediárias. Pedir ao modelo que pareça estar refletindo não dá esse controle à aplicação.

Tree of Thought e Chain of Thought: qual é a diferença?

A diferença está no momento em que as alternativas são comparadas: durante a construção de uma solução ou depois que as respostas completas já foram produzidas.

Essa distinção aparece na fundamentação e no método de Yao e colegas. Na forma padrão, a autoconsistência gera amostras de cadeias completas e escolhe a resposta mais frequente. Para isso, é preciso ter um critério adequado para reconhecer respostas equivalentes: votar em textos de formato livre é menos direto do que votar em um resultado numérico.

O prompting com chain-of-thought pode ajudar a expressar o trabalho intermediário. A autoconsistência acrescenta diversidade entre tentativas concluídas. O ToT acrescenta um controlador capaz de interromper um caminho fraco antes de pagar pelo trabalho de concluí-lo. Esse controlador também introduz uma nova possibilidade de falha: podar um caminho que teria dado certo.

Duas técnicas próximas resolvem outros problemas. O few-shot prompting fornece exemplos do comportamento ou do formato de saída desejado, o que pode ajudar um gerador ou avaliador a seguir a especificação. Já o prompt chaining encadeia etapas, como extrair fatos e depois redigir uma resposta. Uma sequência fixa de etapas só se torna uma busca quando mantém alternativas e decide quais explorar.

Use a estrutura mais simples capaz de resolver a falha. Formatação inconsistente pede exemplos mais claros ou validação. Falta de evidências pede recuperação de informações. Nenhum desses problemas exige automaticamente uma árvore.

Exemplo prático: ramificar, avaliar e podar

Uma equação intermediária correta ainda pode levar a um beco sem saída. É essa diferença que o avaliador precisa reconhecer.

Considere o exemplo do Jogo do 24 usado no artigo: utilizar 4, 9, 10 e 13, cada um exatamente uma vez, com operações aritméticas básicas, para chegar a 24. O passo a passo abaixo foi construído para explicar o mecanismo; não é a transcrição de uma interação real com um modelo. A viabilidade ou impossibilidade de cada estado foi verificada por enumeração das combinações aritméticas restantes. Entrada de exemplo do artigo.

1. 1

   Crie ramificações a partir do estado inicial

   O candidato A calcula 4 + 9 = 13, deixando 10, 13, 13.

   O candidato B calcula 13 - 9 = 4, deixando 4, 4, 10.

   Os dois cálculos respeitam as regras. Os números repetidos representam valores restantes distintos; o estado precisa preservar essa multiplicidade.

2. 2

   Avalie os estados resultantes

   O candidato A não consegue chegar a 24 usando cada valor restante uma única vez com adição, subtração, multiplicação ou divisão. Descarte essa ramificação.

   O candidato B tem uma continuação válida: subtrair de 10 um dos valores 4 restantes e multiplicar o resultado pelo outro 4. Mantenha essa ramificação.

   Neste exemplo, uma verificação aritmética exata permite conferir o julgamento. A busca do artigo usou estimativas de valor feitas pelo modelo, que podem estar erradas.

3. 3

   Expanda a ramificação mantida

   A partir de 4, 4, 10, considere 4 + 4 = 8, que deixa 8, 10, ou 10 - 4 = 6, que deixa 4, 6.

   O primeiro estado não consegue chegar a 24 com a operação restante. O segundo consegue: 4 × 6 = 24. Mantenha essa continuação e verifique a expressão completa.

4. 4

   Confira a resposta final

   (13 - 9) × (10 - 4) = 24 usa cada número original uma vez e chega ao resultado desejado. A busca termina porque o resultado passa na verificação da tarefa.

Para esse pequeno quebra-cabeça, um programa de busca exaustiva resolve tudo; acrescentar um LLM seria trabalho de engenharia desnecessário. O exemplo serve para explicar o ciclo. Em uma aplicação, muitas vezes a divisão útil é deixar o modelo propor planos plausíveis e o código verificar restrições que o modelo não deveria tentar adivinhar.

Quais foram os resultados do artigo sobre Tree of Thoughts?

Os resultados originais mostram que a busca deliberada ajudou nas tarefas escolhidas pelos autores. Eles não determinam o ganho que você deve esperar em uma carga de trabalho atual, em produção.

No Jogo do 24, os autores avaliaram o GPT-4 em 100 partidas relativamente difíceis. Os experimentos ocorreram em maio de 2023. A Tabela 2 apresenta estas taxas de sucesso:

Fonte: Yao e colegas, Tabela 2 e configuração do Jogo do 24.

A largura indica quantos estados são mantidos, não quantas chamadas são feitas ao modelo. Gerar candidatos e avaliá-los acrescenta trabalho. Na configuração do Jogo do 24, os autores amostraram três vezes a estimativa de valor de cada candidato. Configuração experimental.

O artigo também estudou Escrita Criativa e Minipalavras Cruzadas. São tarefas diferentes, com métodos de avaliação diferentes. A conclusão prática é mais restrita do que dizer que “ToT melhora os modelos”: a busca pode ajudar quando uma direção intermediária promissora faz diferença e pode ser avaliada. Quem desenvolve a aplicação ainda precisa de evidências específicas da sua carga de trabalho antes de acrescentar o controlador.

Quantas chamadas ao modelo as ramificações acrescentam?

Conte separadamente as chamadas de geração, avaliação e finalização. O avaliador pode consumir mais chamadas do que o gerador de candidatos.

Considere esta busca ilustrativa com limites definidos, independente da configuração do artigo. Uma chamada corresponde a uma requisição ao modelo feita pela aplicação. Suponha que uma única chamada de geração produza todos os filhos de um nó pai, enquanto cada filho receba sua própria chamada de avaliação. A busca para ao atingir a profundidade escolhida, sem novas tentativas nem encerramento antecipado. Depois, uma chamada final produz a resposta.

Defina três filhos para cada nó pai expandido, mantenha dois estados após cada nível e expanda a busca por três níveis. O número de nós pais expandidos é 1, 2 e 2. Portanto:

• Geração: 1 + 2 + 2 = 5 chamadas.
• Avaliação: 3 × (1 + 2 + 2) = 15 chamadas.
• Resposta final: 1 chamada.
• Total: 5 + 15 + 1 = 21 chamadas, ou 21× o número de chamadas da referência de 1 chamada.

Se a avaliação de cada candidato for repetida três vezes, a mesma árvore passa a consumir 5 + 45 + 1 = 51 chamadas. Se todas as avaliações de candidatos de cada nível forem agrupadas em uma única requisição, o total será 5 + 3 + 1 = 9 chamadas. Esse agrupamento muda o contexto e as condições de julgamento do avaliador; é uma opção de implementação, não uma promessa de qualidade equivalente.

Para comparar, a autoconsistência com cinco amostras solicitadas separadamente usa cinco chamadas ao modelo quando a votação final é feita por código determinístico. Acrescentar um modelo como juiz aumentaria o número de chamadas e mudaria a comparação.

A regra geral de contabilização é C = Σ nₜ(g + kv) + f. Nela, nₜ é o número de nós pais expandidos no nível t; g, o número de requisições de geração por nó pai; k, o número de filhos por nó pai; v, o número de requisições de avaliação por filho; e f, o número de requisições de finalização. A fórmula pressupõe avaliações separadas para cada filho; ao agrupá-las, contabilize as avaliações em lote diretamente.

Como implementar Tree of Thoughts com controle sobre a busca

Mantenha o estado da busca e as regras de parada no código da aplicação. Deixe o modelo propor e avaliar artefatos com limites definidos, que possam ser inspecionados.

O limite dessa arquitetura é a qualidade do avaliador. Se ele não consegue distinguir uma solução parcial viável de um beco sem saída convincente, expandir mais ramificações só aumenta as oportunidades de escolher mal.

1. 1

   Defina um estado que possa ser inspecionado

   Em uma funcionalidade de agendamento com restrições, o estado pode conter tarefas alocadas, tarefas pendentes, horários ocupados e restrições ainda não atendidas. Defina o próximo pensamento como uma proposta de alocação. Armazene separadamente o estado, o identificador do candidato, o identificador do nó pai e as evidências.

   Escolha um artefato que possa ser verificado na etapa atual. É difícil podar com segurança um parágrafo vago que apenas diz ter uma boa estratégia.

2. 2

   Separe as funções de geração e avaliação

   Uma instrução para o gerador pode ser: “Proponha próximas alocações distintas a partir deste estado. Retorne a alocação e o estado atualizado de cada candidato. Preserve as restrições listadas.”

   Uma instrução para o avaliador pode ser: “Verifique cada candidato em relação às restrições. Retorne seu identificador, as restrições eventualmente violadas e indique se a continuação é viável, incerta ou descartada. Cite os campos do estado que sustentam o julgamento.”

   Use primeiro verificações determinísticas para regras como horários sobrepostos ou campos obrigatórios ausentes. Se precisar do julgamento de um modelo, valide-o com casos conhecidos por meio de um processo de avaliação com LLM como juiz.

3. 3

   Defina explicitamente a poda e o orçamento

   Rejeite estados que violem uma restrição obrigatória. Ordene os candidatos restantes, mantenha um conjunto limitado de estados na fronteira de busca e elimine duplicatas. Preserve candidatos incertos quando o orçamento permitir; a baixa confiança do avaliador não prova que uma ramificação seja impossível.

   Faça o controlador impor limites de requisições, profundidade, tokens e tempo decorrido. Inclua avaliações e novas tentativas nesses limites. Registre o que foi descartado e por quê, para poder inspecionar os casos em que a poda eliminou o caminho que levaria à solução.

4. 4

   Verifique antes de aceitar o resultado ou executar ações

   Use uma verificação final, como confirmar que todas as restrições de agendamento foram atendidas ou que os testes de software pertinentes passaram. Se nenhum candidato cumprir os critérios antes de esgotar o orçamento, retorne um resultado não resolvido ou encaminhe-o para revisão.

   Mantenha a exploração de ramificações em um ambiente isolado ou apenas como propostas de ação. Uma ramificação especulativa de agendamento não deve enviar convites. Uma ramificação de código não deve implantar alterações enquanto o controlador ainda compara candidatos.

Meça o desempenho do avaliador, além da resposta final. Uma rejeição incorreta pode eliminar definitivamente a ramificação útil. Uma aceitação incorreta pode consumir o restante do orçamento expandindo um beco sem saída. Essas falhas exigem correções diferentes.

Quando um modelo de raciocínio dispensa o ToT?

Um ToT externo é desnecessário quando um modelo de raciocínio já atende aos requisitos de qualidade e latência e a aplicação não precisa controlar as alternativas intermediárias.

Um modelo de raciocínio realiza trabalho interno antes de responder. As orientações atuais de prompting da Anthropic recomendam dar objetivos gerais aos seus modelos de raciocínio, em vez de prescrever cada etapa do raciocínio. Isso favorece começar com uma tarefa clara, restrições e critérios de aceitação. Não demonstra que um modelo específico implemente internamente o algoritmo ToT de Yao e colegas. Orientações de prompting da Anthropic.

Se você está acrescentando uma pequena transformação de código à aplicação, comece com um modelo de raciocínio adequado e submeta o resultado aos testes pertinentes. Se essa abordagem de referência atender ao critério de liberação, uma árvore externa acrescentará gestão de estado, avaliação e tratamento de falhas sem um benefício demonstrado.

Considere a busca externa quando a aplicação tiver algo a mais a oferecer: um simulador, um verificador de restrições, ambientes de teste isolados ou a necessidade de preservar planos candidatos distintos. Um modelo mais capaz ainda pode atuar como gerador dentro dessa busca. O raciocínio do modelo e a busca controlada pela aplicação são decisões de projeto separadas.

A decisão depende de evidências: mantenha a árvore apenas se ela melhorar os resultados verificados o suficiente para justificar o consumo de recursos medido. Uma resposta mais longa ou um registro de raciocínio mais elaborado não é o critério de sucesso.

Onde o entusiasmo com Tree of Thoughts passa do ponto

Um prompt que pede a especialistas imaginários que debatam não oferece, por si só, uma busca em árvore controlada. Ele pode produzir alternativas, mas uma implementação de ToT em produção precisa de estado, avaliação, seleção de ramificações e uma política de parada explícitos. Se tudo isso existir apenas dentro de uma única resposta gerada, não dá para presumir que a busca descrita tenha sido executada como esperado.

Outro exagero é afirmar que mais ramificações garantem uma resposta melhor. As ramificações podem repetir a mesma ideia. Um juiz pode compartilhar a premissa equivocada do gerador. Uma poda precoce pode descartar a única continuação útil. Um tom confiante não substitui a verificação da tarefa.

Por fim, o melhor resultado do artigo no Jogo do 24 não demonstra que todo fluxo de trabalho empresarial precise de ToT. Um extrator de documentos cuja saída não corresponde ao esquema pode precisar de exemplos melhores e validação. Um assistente de suporte sem acesso a uma política pode precisar da fonte certa. Buscar mais caminhos a partir das mesmas informações incompletas não fornece o fato que falta.

Use a busca para decisões alternativas que possam ser avaliadas. Corrija diretamente a falta de contexto e o descumprimento de especificações.

O que mudar na sua aplicação nesta semana

Comece agora se os casos de falha envolverem escolhas iniciais que ainda podem ser corrigidas e você tiver uma forma confiável de avaliar os estados intermediários. É o caso de alterações candidatas de código verificadas em ambientes isolados ou de planos testados contra restrições explícitas de agendamento. Comece com um fluxo restrito a esses casos e um orçamento fixo de busca.

Espere se ainda não consegue explicar por que uma solução parcial é melhor do que outra. Monte um conjunto de estados aceitáveis e inaceitáveis, confira as decisões do avaliador e melhore esse julgamento antes de ampliar a árvore.

Pouco muda para quem já tem um fluxo de extração, classificação ou uma sequência fixa que atende aos critérios de aceitação. Mantenha a estrutura mais simples.

A ação para segunda-feira é concreta: reúna falhas do seu fluxo atual com chain-of-thought e compare uma abordagem de referência com modelo de raciocínio a uma variante de ToT com limites definidos, usando as mesmas tarefas reservadas para teste. Mantenha o verificador final inalterado. Registre resultados aceitos, chamadas ao modelo, tokens, latência e casos em que a poda eliminou um caminho que levaria à solução. Adote a busca apenas no recorte de tarefas em que os resultados justifiquem seu uso.

Dúvidas frequentes sobre Tree of Thoughts

Raciocínio e Chain-of-Thought são a mesma coisa?

Raciocínio é a capacidade mais ampla de trabalhar na resolução de um problema. Chain-of-thought é uma abordagem de prompting que usa etapas intermediárias. Um modelo pode raciocinar internamente sem exibir essas etapas na resposta.

O que é uma árvore em IA?

Uma árvore representa estados e possíveis próximas ações. Cada nó é um estado, e seus filhos são alternativas alcançadas ao dar mais um passo. No ToT, esses estados representam soluções parciais.

O que é uma árvore de raciocínio?

Neste contexto, significa organizar soluções parciais alternativas em ramificações, avaliá-las e escolher quais continuar. O framework específico de Yao e colegas se chama Tree of Thoughts.

O que é prompting com Tree of Thought?

A técnica usa um modelo de linguagem para propor e avaliar alternativas intermediárias, combinado com um procedimento de busca que escolhe quais estados expandir. A vantagem prática é poder reconsiderar uma decisão antes de concluir toda a resposta.

Quais são os três Cs do prompting?

O algoritmo ToT de Yao e colegas não define uma regra de três Cs. Esse recurso de memorização não é a especificação do algoritmo; o artigo descreve decomposição em pensamentos, geração, avaliação de estados e busca.

Quais são as principais diferenças entre uma cadeia e uma árvore de pensamentos?

O CoT padrão produz um único caminho contínuo de raciocínio. O ToT considera explicitamente caminhos parciais alternativos e os avalia durante a busca. A autoconsistência funciona de outra forma: gera amostras de caminhos completos e agrega as respostas finais.

Qual é um exemplo de prompting com chain-of-thought?

Uma demonstração aritmética resolvida pode mostrar 13 - 9 = 4, depois 10 - 4 = 6 e, por fim, 4 × 6 = 24. Fornecer essas etapas intermediárias como exemplo ilustra o CoT. Comparar etapas alternativas e decidir qual ramificação será mantida acrescenta o mecanismo de busca do ToT.

Como explicar Chain-of-Thought de forma simples?

É uma forma de conectar uma pergunta à resposta por meio de etapas intermediárias, como cálculos ou deduções. Essas etapas podem facilitar o entendimento da tarefa, mas ainda podem conter erros.

Como o Chain-of-Thought funciona na prática?

Na configuração padrão de prompting, o modelo gera uma sequência de etapas intermediárias com base no problema e no texto gerado anteriormente, e depois produz uma resposta. Essa sequência, por si só, não oferece uma verificação independente de correção nem uma fronteira de busca gerenciada pela aplicação.

Assine a newsletter para receber guias práticos sobre como construir fluxos de trabalho confiáveis com IA.