PDDL: avaliação de planos gerados por LLM falha, aponta estudo

O que aconteceu

O artigo Grounded Evaluation and Repair for NL-to-PDDL Problem Generation foi submetido ao arXiv em 9 de setembro de 2026 e assinado como arXiv:2609.09898v1, na área de Inteligência Artificial. O trabalho investiga um pipeline ponta a ponta que converte descrições de planejamento escritas em linguagem natural (NL) em instâncias de problema PDDL, a linguagem formal usada por planejadores automáticos.

A tese central é direta: métricas tradicionais como validade sintática ou sucesso do planejador medem pouco. Segundo o estudo, essas métricas "podem superestimar substancialmente a fidelidade à tarefa descrita". O problema PDDL gerado por um LLM pode ser parseável e solucionável e, ao mesmo tempo, distorcer o estado inicial pretendido, o objetivo, a estrutura de objetos ou o alvo de otimização. O LLM, portanto, entrega algo que roda, mas não necessariamente algo que corresponde ao que foi pedido.

Para atacar isso, o pipeline combina geração por LLM, checagens de parsing, planejamento e validação em PDDL, um verificador de conformidade com o domínio, um crítico baseado em LLM e reparo iterativo. O feedback de reparo é construído a partir de quatro insumos: a descrição do domínio, o problema gerado, a descrição do problema em linguagem natural e os diagnósticos operacionais. A avaliação usa comparações com descrições PDDL curadas de referência, em análise pós-hoc, com checagens offline que incluem correspondência estrutural invariante a renomeação e equivalência semântica quando há suporte de domínio.

Contexto

PDDL, sigla de Planning Domain Definition Language, é o formato padrão da comunidade de planejamento em IA para descrever domínios e problemas de forma que um solver consiga buscar uma sequência de ações. Traduzir linguagem natural para esse formato é uma das tarefas que ficaram mais atraentes com a chegada dos LLMs, porque elimina a necessidade de um especialista escrever à mão cada arquivo de problema.

O estudo testou essa tradução em três frentes: Planetarium, AutoPlanBench e um conjunto de problemas PDDL 2.1 curados. A comparação com descrições de referência é o ponto metodológico que separa este trabalho de avaliações anteriores. Em vez de perguntar apenas se o plano funciona, os autores perguntam se o problema reconstruído é equivalente, do ponto de vista estrutural e semântico, ao problema que o benchmark considerava correto. A correspondência invariante a renomeação existe justamente para que nomes diferentes de objetos não derrubem um resultado legítimo, o que seria um falso negativo.

Por que importa

A divergência encontrada pelos autores não é um detalhe estatístico. Se o sucesso operacional e a reconstrução da referência do benchmark podem se separar de forma substancial, então benchmarks que medeiam apenas o resultado do planejador estão medindo outra coisa. Times que usam LLMs para gerar PDDL em robótica, logística ou escalonamento podem estar validando sistemas com um critério que aprova problemas semanticamente errados.

Um exemplo concreto do tipo de falha descrito: o planejador acha uma solução válida, o parse passa, o teste fica verde e o objetivo real do usuário nunca foi representado. O estudo chama isso de perda de fidelidade, e ela pode estar em qualquer uma das partes do problema, inclusive no alvo de otimização.

Impacto

O resultado também posiciona o reparo estruturado como peça útil do fluxo. Ou seja, o crítico baseado em LLM e o reparo iterativo têm valor mensurável quando o feedback é construído com informação de domínio e diagnósticos operacionais, e não apenas com a saída bruta do modelo.

Ao mesmo tempo, o trabalho registra um limite: PDDL 2.1 continua difícil para reconstrução de referência mesmo quando o sucesso operacional melhora. Esse é o achado que deve incomodar quem trabalha com planejamento temporal e numérico. A versão 2.1 do PDDL, que a comunidade usa para expressar restrições de tempo e recursos, é exatamente onde a tradução automática a partir de linguagem natural parece mais frágil, e onde o pipeline descrito ainda não fecha a lacuna.

O que muda

Para quem constrói agentes de planejamento, a mensagem prática é trocar a validação de caixa única por camadas. O pipeline do estudo sugere uma sequência: gerar, parsear, planejar, validar, checar conformidade com o domínio, submeter a um crítico e reparar com feedback detalhado. A checagem semântica contra referência fica como etapa de auditoria, não como detalhe opcional.

Para quem publica benchmarks, a implicação é revisar o que o placar significa. Métricas de sucesso do planejador, isoladas, podem inflar resultados. A correspondência estrutural invariante a renomeação e a equivalência semântica entram como complemento necessário.

O que vem agora

O artigo é um preprint e não anuncia cronograma de submissão a conferência nem liberação de código. O que ele deixa explícito é a agenda: melhorar reparo estruturado e atacar a reconstrução de referência em PDDL 2.1, o ponto que segue em aberto mesmo quando o planejador passa a resolver mais problemas. Até que isso avance, qualquer pipeline de NL para PDDL que reporte apenas sucesso operacional deve ser lido com desconfiança.

Fontes

• Grounded Evaluation and Repair for NL-to-PDDL Problem Generation, arXiv:2609.09898v1, submetido em 9 de setembro de 2026 (https://arxiv.org/abs/2609.09898)