Resumo Técnico: Uma Estrutura de Reescalonamento Baseada em Eventos e Consciente da Estabilidade com Julgamento de LLM Limitado

1. Definição do Problema

Os cronogramas de produção são frequentemente interrompidos por eventos do mundo real, como quebras de máquinas, atrasos de operações, escassez de materiais e inserções de pedidos urgentes. O desafio central abordado neste artigo não é meramente como computar um novo cronograma, mas quando um cronograma liberado deve ser revisado e até que ponto.

A literatura existente foca frequentemente na regeneração de cronogramas imediatamente após qualquer interrupção. No entanto, os autores argumentam que a regeneração frequente leva ao "nervosismo do cronograma" (schedule nervousness), onde operadores, manipuladores de materiais e equipes de setup são forçados a alterar planos nos quais já agiram, causando instabilidade. Por outro lado, ignorar as interrupções leva a um atraso descontrolado. Além disso, embora os Grandes Modelos de Linguagem (LLMs) estejam sendo cada vez mais aplicados ao escalonamento, uma revisão estruturada de 43 estudos (2024–2026) revela uma lacuna crítica:

• A maioria das aplicações de LLM são geradores offline de regras ou heurísticas, não decisores online.
• Apenas 16% dos estudos completam o ciclo completo evento–decisão–execução com resultados mensurados.
• Nenhum dos estudos que injeta interrupções mede a estabilidade do plano liberado.
• Nenhum estudo trata explicitamente a escolha entre ignorar, reparar localmente ou reescalonar totalmente como um problema de decisão distinto.

O artigo propõe uma estrutura para fechar essa lacuna, introduzindo um portão de reescalonamento disparado por eventos, consciente da estabilidade e com julgamento de LLM limitado.

2. Metodologia

A estrutura proposta opera como um portão determinístico que avalia cada evento relatado no chão de fábrica antes que qualquer novo plano seja emitido. Ela consiste em quatro componentes principais:

2.1 Reações Candidatas

Para cada evento, o sistema constrói três reações candidatas de invasividade crescente:

1. Ignorar: O evento é absorvido pela folga (slack) existente. Nenhum novo cronograma é publicado; as operações começam assim que se tornarem viáveis com base na sequência original.
2. Reparo Local (Deslocamento à Direita / Right-Shift): As atribuições de máquinas e sequências da linha de base são preservadas. As operações são deslocadas para horários posteriores para acomodar a interrupção (ex: quebras de máquina ou atrasos) sem reordenar. Pedidos urgentes são inseridos de forma gananciosa (greedy) ao final das filas. Isso preserva a estabilidade da sequência.
3. Reescalonamento Total (com Horizonte Congelado): O plano de curto prazo é "congelado" por um horizonte $H$ (ex: 8 horas) para proteger recursos comprometidos (materiais, setups, operadores). Apenas as operações fora deste conjunto congelado são reotimizadas. O subproblema é resolvido usando um portfólio de regras de despacho (EDD, STR, SPT) ou um modelo de programação inteira mista para instâncias pequenas.

2.2 Métricas de Avaliação

Cada candidato é avaliado em dois eixos ortogonais:

• Custo de Desempenho ($Z$): Uma soma ponderada do atraso total (tardiness) e do makespan, refletindo o contexto de produção sob encomenda (make-to-order) onde a confiabilidade da entrega é primordial.
• Pontuação de Estabilidade ($SS$): Uma pontuação composta (0–100) derivada de cinco componentes:
  1. Deslocamento médio do tempo de início.
  2. Fração de operações movidas.
  3. Fração de reatribuições de máquinas.
  4. Similaridade de sequência (concordância de Kendall).
  5. Alterações dentro da janela congelada.
     A pontuação penaliza mudanças que afetam mais pessoas e recursos, com uma penalidade específica para alterações no plano imediato congelado.

2.3 Portão de Decisão Baseado em Regras

Um mecanismo de regras determinístico converte as métricas em uma decisão:

• Ignorar: Recomendado se o evento causar danos de desempenho negligenciáveis (absorvidos pela folga).
• Reparar: Recomendado se o evento causar danos, mas um reescalonamento total oferecer recuperação insuficiente ou violar restrições de estabilidade.
• Reescalonamento Total: Recomendado apenas se:
  • O evento for "severo" (ex: cria novos trabalhos atrasados).
  • O reescalonamento recuperar uma porcentagem mínima ($\rho_{min}$) do dano induzido pelo evento.
  • A pontuação de estabilidade do novo plano exceder um piso mínimo ($SS_{min}$).
  • Um intervalo de "anti-agitação" (anti-thrashing) tiver decorrido desde o último reescalonamento total (a menos que o evento seja severo).

2.4 Julgamento de LLM Limitado

Um LLM hospedado localmente atua como um conselheiro independente, não como um solucionador (solver).

• Entrada: O LLM recebe as mesmas evidências quantitativas (detalhes do evento, métricas da linha de base, pontuações de desempenho/estabilidade dos candidatos, razões da regra e histórico de decisões recentes) que o portão de regras.
• Restrição: Ele não pode gerar cronogramas. Deve fornecer uma decisão (ignorar, reparar, reescalonar total) dentro de um esquema JSON estrito, citando números concretos.
• Fallback (Recurso de Contingência): Se o LLM falhar ao produzir uma saída válida, sofrer timeout ou produzir uma decisão fora do vocabulário, o sistema retorna por padrão para a decisão baseada em regras. O planejador humano faz a escolha final, vendo ambas as recomendações lado a lado.

3. Principais Contribuições

1. Revisão Estruturada e Análise de Lacunas: O artigo fornece uma revisão sistemática de 43 estudos recentes, identificando que os LLMs raramente são usados para tomada de decisão online em reescalonamento dinâmico e que a estabilidade quase nunca é medida em experimentos de injeção de eventos.
2. Design de Portão Consciente da Estabilidade: Introduz um mecanismo que explicitamente negocia o compromisso entre recuperação de desempenho e estabilidade do cronograma, utilizando um horizonte congelado e uma pontuação de estabilidade de múltiplos componentes.
3. Integração de LLM Limitado: Propõe uma arquitetura de "julgamento limitado" onde o LLM audita evidências verificadas em vez de gerar soluções, garantindo viabilidade e segurança através de validação de esquema e fallbacks determinísticos.
4. Validação de Caixa Branca: A estrutura é validada em uma instância verificável manualmente e em uma instância de escala industrial (312 operações), demonstrando que o sistema atinge os ramos de decisão esperados sem violar invariantes de viabilidade ou estabilidade.

4. Resultados

A validação envolveu 27 cenários de eventos, 108 cronogramas candidatos e 9 cenários de protocolo de LLM.

• Correção de Decisão: O portão identificou corretamente quando ignorar, reparar ou reescalonar totalmente em todos os cenários, incluindo casos extremos envolvendo pedidos urgentes, atrasos de materiais e quebras de gargalos.
• Viabilidade e Invariantes: Todos os 108 cronogramas candidatos passaram na verificação independente de sobreposição de máquinas, ordem de roteamento e restrições de horizonte congelado.
• Mecanismos de Proteção: O intervalo de anti-agitação (anti-thrashing) impediu com sucesso reescalonamentos desnecessários para eventos menores logo após um evento maior, enquanto a sobreposição de severidade permitiu o reescalonamento para interrupções críticas.
• Sensibilidade do Horizonte Congelado: Experimentos mostraram que um horizonte congelado mais longo melhora a estabilidade, mas reduz a capacidade de um reescalonamento de recuperar o desempenho, confirmando que o horizonte deve refletir os compromissos reais do chão de fábrica.
• Robustez da Camada de LLM: O sistema lidou com vários modos de falha do LLM (JSON inválido, erros de autenticação, timeouts) ao retornar para a decisão da regra sem interromper o processo. A taxa de concordância do LLM com a regra foi alta, ocorrendo divergências principalmente em casos limítrofes.
• Desempenho: As avaliações levaram menos de 1 segundo, mesmo para a instância industrial (312 operações), incluindo a geração e verificação de quatro cronogramas candidatos.

5. Significância e Alegações

O artigo afirma avançar o campo do escalonamento preditivo-reativo ao mudar o foco de "como computar um cronograma" para "se deve emitir um novo cronograma".

• Tomada de Decisão Baseada em Evidências: Ao exigir pontuações de estabilidade medidas e métricas de recuperação de danos, a estrutura vai além da regeneração heurística para o gerenciamento explícito de compensações (trade-offs).
• Implantação Segura de LLM: A abordagem de "julgamento limitado" aborda as preocupações de confiabilidade no uso de LLMs em produção. Ao restringir o LLM à auditoria de dados verificados e fornecer um fallback determinístico, o sistema garante que o planejador nunca seja forçado a agir com base em uma sugestão inviável ou alucinada.
• Humano no Ciclo (Human-in-the-Loop): A estrutura preserva a autoridade humana. O planejador recebe uma recomendação estruturada com razões tanto de uma regra determinística quanto de um LLM, permitindo decisões finais informadas que podem considerar fatores contextuais (ex: importância estratégica do cliente) não capturados pelas métricas.
• Aplicabilidade Prática: A validação na instância industrial com 312 operações demonstra que a abordagem é computacionalmente viável para uso em tempo real no chão de fábrica.

Os autores concluem que, embora a estrutura implemente com sucesso um portão de julgamento limitado e consciente da estabilidade, trabalhos futuros são necessários para validar sua vantagem comparativa sobre políticas mais simples (ex: "sempre reescalonar") em fluxos de eventos de longo prazo e para calibrar os parâmetros do portão para ambientes industriais específicos.