PlanCompiler: A Deterministic Compilation Architecture for Structured Multi-Step LLM Pipelines

Resumo Técnico: PlanCompiler

1. O Problema

Os Grandes Modelos de Linguagem (LLMs) demonstram grande capacidade na geração de código em tarefas de um único passo. No entanto, em fluxos de trabalho estruturados de múltiplos passos (como ingestão de dados, transformações em cadeia, persistência em banco de dados e exportação), eles exibem uma fragilidade crítica:

• Acúmulo de Erros: Pequenos erros em etapas iniciais (ex: importações hallucinadas, nomes de colunas incorretos) propagam-se e causam falhas silenciosas ou falhas de execução nas etapas subsequentes.
• Inconsistência de Convenções: A geração de código livre ("free-form") tende a sofrer de "deriva" de nomenclatura e lógica entre as etapas geradas.
• Falta de Garantia Estrutural: Abordagens existentes (como orquestração de ferramentas) focam em eficiência e execução paralela, mas raramente impõem uma fronteira de correção estática antes da execução, tratando falhas como um problema de tempo de execução.

2. Metodologia: Arquitetura PlanCompiler

O PlanCompiler propõe uma arquitetura de compilação determinística que separa estritamente o planejamento da execução. O sistema não permite que o LLM escreva lógica de execução; em vez disso, ele atua apenas como um seletor de nós dentro de um registro fechado.

O fluxo de trabalho consiste em cinco componentes principais:

1. Planejador (LLM):

   • Recebe a descrição da tarefa em linguagem natural e um registro de nós tipado (primitivas computacionais pré-definidas).
   • O LLM deve selecionar nós desse registro e fornecer parâmetros, gerando um plano JSON estruturado.
   • O modelo não pode inventar novas primitivas nem escrever código de execução direto.

2. Validador Estático (Determinístico):

   • Antes de qualquer código ser gerado, o plano JSON passa por sete verificações estruturais rígidas:
     1. Existência do nó (o nó está no registro?).
     2. Validade da aresta (conexões referenciam nós existentes?).
     3. Compatibilidade de tipos (ex: DBHandle não pode ser passado para DataFrame).
     4. Aciclicidade (garantia de que não há ciclos no grafo).
     5. Detecção de nós órfãos (todos os nós estão conectados?).
     6. Aridade de entrada (cada nó tem exatamente uma entrada, suportando apenas pipelines de fluxo único).
     7. Presença de parâmetros obrigatórios.
   • Se qualquer verificação falhar, o plano é rejeitado imediatamente. Não há "modo de aviso" ou retentativa automática.

3. Compilador:

   • Recebe apenas planos validados.
   • Realiza uma ordenação topológica do grafo.
   • Monta um programa Python executável (app.py) concatenando modelos (templates) pré-existentes de disco.
   • Insere os parâmetros fornecidos pelo LLM diretamente como literais Python (usando repr()), sem manipulação de strings complexa.

4. Execução Determinística:

   • O programa compilado é executado em um subprocesso Python.
   • Não há chamadas adicionais ao LLM durante a execução.
   • O estado é passado estritamente via valores de retorno de função entre nós.
   • O sucesso é medido pela taxa de sucesso na primeira tentativa (first-pass success), sem loops de reparo.

5. Registro de Nós (Node Registry):

   • Define primitivas com tipos de entrada/saída estritos (ex: FilePath, DataFrame, DBHandle, HTTPResponse).
   • Garante que o mapeamento entre nome do nó e função executável seja um fato do registro, não uma convenção de nomenclatura inferida.

3. Contribuições Principais

1. Representação Intermediária Tipada e Arquitetura de Compilação: Elimina hallucinations de importação e deriva de nomenclatura por construção, restringindo o LLM a um problema de seleção e parametrização em um registro fechado.
2. Protocolo de Avaliação Focado em Confiabilidade: Apresenta uma taxonomia estruturada de falhas e critérios de sucesso explícitos, demonstrando que a arquitetura mantém alta precisão na primeira tentativa, enquanto a geração de código livre falha frequentemente.
3. Caracterização de Falhas Residuais: Identifica que as falhas restantes no sistema não são aleatórias, mas se concentram em duas classes interpretáveis:
   • Falhas de Contrato de Saída Semântica: O planner contorna restrições usando SQL "livre" em vez de nós de agregação restritos.
   • Falhas de Tipo na Fronteira de Persistência: Confusão entre manipuladores de banco de dados (DBHandle), caminhos de arquivo e tabelas materializadas após round-trips no SQLite.

4. Resultados Experimentais

O sistema foi avaliado em 300 tarefas distribuídas em 6 conjuntos de benchmark (A-F), variando de pipelines simples a complexos, com testes de persistência SQL e armadilhas de esquema.

• Precisão (First-Pass Success Rate):

  • PlanCompiler: Alcançou 92,67% de sucesso geral (278/300).
    • 100% nos conjuntos A e B (pipelines curtos/médios).
    • 96% no conjunto D (máxima complexidade).
    • 88% no conjunto E (armadilhas de esquema).
  • Baselines (Geração Livre):
    • GPT-4.1: 67% de sucesso.
    • Claude Sonnet 4.6: 62% de sucesso.
  • O PlanCompiler superou os baselines em 25,67 pontos percentuais no agregado.

• Eficiência de Custo:

  • O custo total de inferência para o PlanCompiler foi de $0,356 para as 300 tarefas.
  • Comparado a $2,140 (GPT-4.1) e $18,391 (Claude).
  • O custo por tarefa bem-sucedida do PlanCompiler foi 8,27x menor que o GPT-4.1 e 76,75x menor que o Claude. Isso ocorre porque o sistema usa um modelo menor (GPT-4o-mini) apenas para planejamento e evita a geração de código redundante e falha.

• Latência:

  • O PlanCompiler tem latência ligeiramente maior que o GPT-4.1 (devido ao tempo de validação e compilação), mas é significativamente mais rápido que o Claude.
  • A latência aumenta monotonicamente com a complexidade do pipeline, mas mantém alta confiabilidade.

• Análise de Falhas:

  • As falhas do PlanCompiler (22 no total) foram concentradas em dois padrões específicos (59% por evasão de restrições via SQL e 41% por confusão de tipos de persistência).
  • As falhas dos baselines foram distribuídas aleatoriamente em 5+ categorias (erros de importação, deriva de esquema, APIs obsoletas, etc.), tornando-as mais difíceis de corrigir estruturalmente.

5. Significado e Implicações

O artigo demonstra que, para fluxos de trabalho estruturados, a confiabilidade deve ser tratada como um problema de compilação e não apenas de "prompting".

• Mudança de Paradigma: Ao separar o planejamento (onde o LLM atua) da execução (determinística e validada), o sistema transforma erros difusos e imprevisíveis em falhas localizadas e interpretáveis.
• Garantias Estruturais vs. Semânticas: A arquitetura garante a correção estrutural (tipos, conexões, ausência de ciclos) por construção. Erros semânticos (lógica de negócio incorreta dentro de um SQL válido) permanecem, mas são agora a única classe de erro residual, permitindo intervenções mais direcionadas.
• Viabilidade Econômica: A abordagem permite o uso de modelos de linguagem menores e mais baratos para tarefas complexas, desde que a camada de compilação e validação seja robusta.

Em suma, o PlanCompiler oferece um caminho prático para tornar sistemas baseados em LLMs mais confiáveis, auditáveis e previsíveis em cenários de processamento de dados estruturados, superando significativamente as abordagens de geração de código livre em termos de taxa de sucesso na primeira tentativa e custo.