Resumo Técnico: DIAGFLOWBENCH

Declaração do Problema

Modelos de Linguagem de Grande Escala (LLMs) estão sendo cada vez mais implantados como sistemas de aconselhamento de manutenção, fundamentados em documentação procedural (ex: fluxogramas) para restringir os outputs a etapas aprovadas e evitar alucinações. Embora os benchmarks existentes avaliem a capacidade de um modelo de seguir esses procedimentos em entradas limpas e mapeáveis, eles falham em abordar uma dinâmica crítica do mundo real: operadores frequentemente se desviam do caminho documentado. Na prática, operadores relatam sintomas inéditos, levantam questões no meio da inspeção ou utilizam jargões específicos do domínio que não se mapeiam perfeitamente às arestas do procedimento.

Os paradigmas de avaliação atuais tratam o reconhecimento de "fora do procedimento" como uma tarefa de abstenção separada de turno único. No entanto, em um diálogo de diagnóstico ao vivo, um modelo deve simultaneamente avançar por turnos complacentes e reconhecer entradas não complacentes dentro da mesma conversa. O artigo argumenta que os benchmarks existentes não testam adequadamente a capacidade de um modelo fundamentado de lidar com essas entradas "fora do procedimento", particularmente o risco de um modelo selecionar uma etapa real, mas contextualmente inapropriada, em vez de fabricar um fato.

Metodologia

Os autores introduzem o DIAGFLOWBENCH, um benchmark projetado para avaliar modelos fundamentados em fluxogramas sob condições cooperativas e fora do procedimento.

Construção do Conjunto de Dados

• Fonte: 50 fluxogramas de diagnóstico industrial anonimizados de um fabricante de bens de consumo, cobrindo classes de falhas como rastreamento de correia transportadora e posicionamento robótico.
• Estrutura: Os grafos contêm entre 7 e 60 nós (média de 31) com fatores de ramificação de decisão de 2 a 4.
• Conversas: Esses fluxogramas foram renderizados em 1.676 conversas de múltiplos turnos.
  • Cooperativa: 838 conversas onde o operador segue estritamente o procedimento.
  • Mista: 838 conversas onde turnos fora do procedimento são injetados em posições não terminais.
• Categorias de Injeção: As entradas fora do procedimento são estratificadas em três tipos baseados em sua relação com o procedimento:
  1. Lacuna de Cobertura (Coverage Gap): Um sintoma para o qual o procedimento não possui ramificação.
  2. Malfuncionamento Não Documentado: Uma falha fora de qualquer condição de ramificação no nó atual.
  3. Pergunta Não Relacionada: Uma consulta inteiramente fora da tarefa de diagnóstico.
• Perturbação de Ruído: Uma passagem de robustez introduz erros de digitação, frases telegráficas e abreviações características de textos de ordens de serviço de manutenção.

Protocolo de Avaliação

O estudo avalia dez modelos comerciais e de pesos abertos (incluindo variantes de Gemini, GPT-4o, Llama 4, Qwen3, Mistral e Nemotron). A avaliação define modos de falha específicos para turnos fora do procedimento:

• Abstenção Correta (CA): O modelo reconhece que a entrada está fora do escopo e declina/redireciona.
• Fabricação (FA): O modelo retorna uma etapa ausente do procedimento (alucinação padrão).
• Mapeamento Forçado (FM): O modelo retorna um nó genuíno do gráfico do procedimento, mas nenhuma aresta para esse nó é entailada pela fala do operador. Este é o principal modo de falha investigado.

As métricas incluem Precisão de Etapa (SA) e Reconhecimento de Terminação (TR) para turnos dentro do procedimento, e as taxas de CA, FA e FM para turnos fora do procedimento. Um juiz de linguagem (Claude Haiku) classifica as respostas fora do procedimento, validado contra anotadores humanos.

Principais Contribuições

1. Dataset DIAGFLOWBENCH: Um conjunto de dados de 50 fluxogramas industriais convertido em 1.676 conversas de múltiplos turnos que contrastam explicitamente diálogos complacentes com seus equivalentes fora do procedimento.
2. Avaliação Abrangente: Uma avaliação de dez modelos diversos entre categorias comerciais e de pesos abertos, analisando o desempenho através de diferentes arquiteturas e escalas.
3. Identificação do "Mapeamento Forçado": O artigo identifica e define um modo de falha específico onde os modelos atribuem forçadamente uma consulta fora do procedimento a uma etapa inaplicável. Diferente da fabricação, essas etapas são estruturalmente válidas e fundamentadas no manual, tornando-as difíceis de detectar via verificações de fundamentação baseadas em similaridade padrão.

Resultados

• Competência Dentro do Procedimento: Os modelos geralmente performam bem em entradas complacentes, com a Precisão de Etapa (SA) variando entre 70,1% e 85,0%. No entanto, o Reconhecimento de Terminação (TR) é significativamente mais volátil (38,8% a 98,5%).
• Competência Fora do Procedimento:
  • A Fabricação (FA) é baixa: A fundamentação impede com sucesso que os modelos inventem etapas (taxas de FA entre 2,2% e 8,6%).
  • O Mapeamento Forçado (FM) é dominante: As taxas de FM são substancialmente mais altas e voláteis (15,7% a 67,4%), emergindo como o principal modo de falha.
  • A Abstenção é inconsistente: As taxas de Abstenção Correta (CA) variam amplamente e não são preditas de forma confiável pela escala do modelo, arquitetura ou nível de acesso. Notavelmente, modelos mais antigos (Llama 3.3 70B) às vezes superam gerações mais novas (Llama 4) no tratamento de fora do procedimento.
• Recuperação: Um único erro de FM ou FA causa um colapso catastrófico no desempenho subsequente. A taxa de recuperação (identificar corretamente a próxima etapa após uma falha) cai para entre 1,0% e 9,1%, comparado à linha de base de 70–85% para conversas limpas.
• Drivers de FM: O mapeamento forçado é fortemente governado pela similaridade lexical entre a consulta fora do procedimento e o texto do procedimento. Os modelos têm maior probabilidade de realizar o mapeamento forçado de entradas de "Lacuna de Cobertura" (que compartilham vocabulário com o manual) do que de perguntas não relacionadas.

Significância e Alegações

O artigo alega que os mecanismos de restrição projetados para prevenir alucinações (fundamentar modelos a um conjunto fechado de etapas procedimentais) podem inadvertidamente criar um "ponto cego". Ao forçar os modelos a selecionar de um conjunto válido de nós, o sistema pode camuflar erros contextuais como etapas válidas.

Os autores argumentam que:

1. A confiabilidade não pode ser inferida de baixas taxas de FA: Um modelo com baixas taxas de fabricação ainda pode ser altamente não confiável devido a altas taxas de mapeamento forçado.
2. Guardrails padrão são insuficientes: Como as etapas de FM são rastreáveis ao manual e estruturalmente válidas, elas escapam da detecção de alucinação padrão.
3. A avaliação deve medir a segurança da falha: Avaliar sistemas de aconselhamento requer medir não apenas a conformidade, mas quão seguramente o modelo falha quando a realidade diverge do manual.
4. A seleção de modelos não é uma solução definitiva: Nem a escala do modelo nem a arquitetura orientada ao raciocínio predizem definitivamente a confiabilidade fora do procedimento; em alguns casos, modelos de raciocínio exibem uma tendência excepcionalmente baixa de abstenção.

O estudo conclui que o implante robusto requer camadas de verificação externa capazes de avaliar a entailment contextual, em vez de confiar apenas em modelos generativos para distinguir entre entradas ambíguas e genuinamente fora do procedimento.