Evidence-Driven Reasoning for Industrial Maintenance Using Heterogeneous Data

O artigo apresenta o "Condition Insight Agent", um framework de suporte à decisão que integra dados heterogêneos de manutenção industrial por meio de raciocínio baseado em evidências e verificação estruturada, permitindo explicações fundamentadas e ações orientadas que preservam a supervisão humana mesmo diante de dados incompletos.

O essencial

Imagine que você é o mecânico chefe de uma enorme fábrica com milhares de máquinas. Cada máquina tem seus próprios "sinais vitais" (como temperatura, horas de uso, vibração) e um histórico de reparos escrito em cadernos antigos, cheios de anotações manuscritas e rabiscos.

O problema? Você tem muitos dados, mas eles estão desconexos.

• Os sensores falam uma língua técnica.
• Os cadernos de reparo estão em texto livre e bagunçado.
• Os manuais de engenharia (que dizem como as coisas quebram) estão em arquivos separados.

Antes, para decidir se uma máquina precisa de reparo, você tinha que abrir cinco sistemas diferentes, ler tudo manualmente e usar sua intuição para juntar as peças. Isso levava 30 minutos por máquina e você só conseguia checar uma pequena fração delas.

A Solução: O "Detetive de Manutenção" (Condition Insight)

Os autores deste artigo criaram um assistente de IA chamado Condition Insight (Insight de Condição). Pense nele não como um "robô que decide tudo", mas como um detetive super-organizado e muito cauteloso.

Aqui está como ele funciona, usando analogias simples:

1. O Coletor de Evidências (A Construção Determinística)

Antes de o "cérebro" da IA pensar, um sistema automático e infalível (como um bibliotecário robótico) reúne todas as provas.

• Ele pega os dados dos sensores e os transforma em resumos simples (ex: "a temperatura subiu 10% na última semana").
• Ele lê os cadernos de reparo e resume o que já foi feito (ex: "o motor foi trocado em 2023").
• Ele consulta o manual de engenharia para saber quais defeitos são possíveis (ex: "se a temperatura sobe, pode ser falta de óleo ou rolamento quebrado").

Importante: Nessa fase, a IA ainda não está falando. Ela apenas organiza as provas em uma pasta limpa e estruturada.

2. O Detetive (O Agente de IA Restrito)

Agora, o "cérebro" (uma Inteligência Artificial de linguagem) recebe essa pasta organizada. Mas ele não é livre para inventar histórias. Ele tem regras estritas:

• Regra de Ouro: "Só fale o que está escrito nas provas."
• Regra de Segurança: "Se o manual diz que o defeito X é impossível, não sugira o defeito X, mesmo que pareça lógico."

Ele lê as provas e escreve um relatório: "Olhe, a temperatura subiu (prova 1), e o último reparo foi no rolamento há 6 meses (prova 2). O manual diz que rolamentos velhos esquentam (prova 3). Conclusão: O rolamento provavelmente está ruim."

3. O Chefe de Segurança (O Loop de Verificação)

Aqui está a parte mais brilhante. Antes de entregar o relatório para você, um sistema de verificação automático (o "Chefe de Segurança") lê o que o Detetive escreveu e compara com as regras originais.

• O Detetive disse: "Troque o rolamento."
• O Chefe verifica: "Tem um alerta de temperatura? Sim. Tem histórico de rolamento? Sim. O manual confirma? Sim." -> Aprovado.
• O Detetive disse: "Troque o motor inteiro."
• O Chefe verifica: "Não há prova de que o motor inteiro está ruim, só o rolamento." -> Bloqueado! O sistema corrige ou descarta essa sugestão.

Isso impede que a IA "alucine" (invente problemas que não existem), o que é crucial em indústrias onde um erro pode parar a produção.

Por que isso é um milagre?

1. Velocidade: O que levava 30 minutos para um humano fazer, o sistema faz em 15 a 30 segundos.
2. Confiança: Como cada frase do relatório é ligada a uma prova específica (ex: "veja o gráfico 3"), o engenheiro humano confia no resultado. Não é uma "adivinhação mágica".
3. Humanos no Comando: O sistema não apertar botões sozinho. Ele apenas diz: "Ei, olhe para esta máquina, aqui estão as provas do problema e o que sugiro fazer. Você decide."

Resumo da Ópera

Imagine que você tem um assistente pessoal que lê todos os seus e-mails, anotações e manuais em segundos. Ele não toma decisões por você, mas entrega um resumo organizado dizendo: "Baseado no que você escreveu e nos dados que temos, parece que o pneu está furado. Aqui está a prova. O que você quer fazer?"

Isso é o Condition Insight: transformar dados bagunçados e desconexos em decisões claras e seguras, permitindo que as fábricas cuidem de milhares de máquinas sem precisar de milhares de engenheiros correndo de um lado para o outro.

Resumo técnico

Resumo Técnico: Raciocínio Orientado a Evidências para Manutenção Industrial

1. O Problema

Organizações industriais dependem de manutenção baseada em condição para reduzir tempos de inatividade e gerenciar riscos operacionais. No entanto, os sistemas existentes (CMMS - Computerized Maintenance Management Systems) enfrentam desafios críticos:

• Fragmentação de Dados: As evidências estão dispersas em fontes heterogêneas: ordens de serviço em texto livre, sensores operacionais (meters) com semântica inconsistente e conhecimento de falhas estruturado (como FMEA - Failure Modes and Effects Analysis).
• Falta de Raciocínio Condicional: Os sistemas atuais geram alertas ou previsões isoladas, mas não conseguem responder a perguntas condicionais complexas: "Dado este histórico e comportamento, o que está acontecendo e qual ação é justificada?"
• Riscos de IA Generativa: A aplicação direta de Grandes Modelos de Linguagem (LLMs) em ambientes críticos de confiabilidade é arriscada devido a alucinações (explicações inventadas) e recomendações não fundamentadas, o que compromete a confiança e a rastreabilidade necessárias na indústria.

2. Metodologia: O Framework "Condition Insight Agent"

Os autores propõem o Condition Insight, um framework de suporte à decisão implantado que combina a construção determinística de evidências com a síntese restrita por LLMs. A arquitetura segue um pipeline de duas etapas principais:

A. Construção Determinística de Evidências (Pré-processamento)
Antes de qualquer interação com o LLM, os dados brutos são transformados em um pacote de evidências estruturado (asset_facts):

• Abstração de Ordens de Serviço: Extrai padrões de sintomas, intervenções e resultados de textos não estruturados.
• Abstração de Medidores (Meters): Converte leituras operacionais de baixa frequência em resumos comportamentais (detecção de tendências, pontos de mudança, anomalias, drifts) em vez de usar dados brutos.
• Alinhamento de Conhecimento de Falhas: Utiliza um processo de correspondência semântica baseado em Transporte Ótimo Não Balanceado (UOT) para vincular as evidências das ordens de serviço aos mecanismos de falha definidos no FMEA. Isso cria um espaço de hipóteses restrito e engenharia-consistente.

B. Agente LLM Restrito e Verificação Determinística

• Agente LLM de Domínio: Consome o pacote de evidências estruturado e gera um resumo de "Insight de Condição". O prompt do LLM é estritamente limitado para raciocinar apenas sobre as evidências fornecidas e dentro das semânticas de falha permitidas.
• Loop de Verificação Determinística: Um componente crítico que atua como um "guardião". O sistema compara a classificação de condição gerada pelo LLM (ex: "Normal", "Precisa de Atenção") com regras determinísticas baseadas em critérios operacionais explícitos (ex: ordens de serviço atrasadas, alertas críticos).
  • Se houver discrepância, o sistema identifica erros de raciocínio e refina o prompt ou suprime conclusões não suportadas.
  • Isso garante que a categorização de alto nível seja governada por regras lógicas, enquanto o LLM fornece a síntese explicativa.

3. Contribuições Principais

1. Definição de Tarefa de "Conditional Insight": Conecta indicadores operacionais, histórico de manutenção e conhecimento de falhas em explicações fundamentadas em evidências.
2. Arquitetura Controlada por Trajetória: Separa a extração de evidências determinística da síntese do LLM, governada por semântica de falhas.
3. Loop de Verificação Determinística: Um mecanismo que cruza as saídas do LLM com regras operacionais e evidências estruturadas, garantindo elementos de decisão auditáveis.
4. Design "Verificação Primeiro": Demonstra que essa abordagem melhora a rastreabilidade e a resistência a alucinações em comparação com pipelines de LLMs não restringidos.
5. Lições de Implantação: Relatos de experiências em ambientes corporativos com dados de IoT heterogêneos e ontologias esparsas.

4. Resultados e Avaliação

O framework foi avaliado em dois estudos de caso em implantações reais de CMMS:

• Estudo A (Integração de Produto): O sistema operou com dados de produção reais, gerando resumos estruturados que ligavam interrupções operacionais a evidências explícitas. Todas as saídas passaram por verificações determinísticas; conclusões não suportadas foram revisadas ou suprimidas.
• Estudo B (Implantação em Escala Empresarial): Avaliado em ~1.500 ativos (16 classes, 14 locais).
  • Comportamento Conservador: O sistema classificou corretamente uma parcela significativa de ativos como "Dados Insuficientes" quando as evidências eram esparsas, evitando falsos positivos.
  • Estabilidade: As distribuições de categorias foram estáveis entre os locais, indicando que os limites não estavam superajustados (overfitting) a condições locais.
  • Impacto Operacional: Reduziu o tempo de análise de 20-30 minutos por ativo (processo manual) para 15-30 segundos (processo automatizado), permitindo uma cobertura sistemática muito maior.

Métricas de Desempenho:

• Taxa de Afirmações Não Suportadas (UCR): Reduzida significativamente (de 0,007 para 0,003) com o uso de prompts restritos e evidências estruturadas.
• Taxa de Especificidade (HSR): Aumentou, indicando que as afirmações referenciavam componentes e modos de falha concretos.
• Taxa de Concordância de Condição (CAR): Melhorou drasticamente (de ~0,68 para ~0,91) com prompts restritos, mostrando forte aderência à lógica governamental determinística.
• Estabilidade: Taxas de contradição e redundância próximas de zero.

5. Significado e Conclusões

O trabalho demonstra que, em ambientes industriais críticos, a confiabilidade de sistemas baseados em LLM depende menos da escolha do modelo base (backbone) e mais da estrutura das evidências e das restrições de governança explícitas.

• Confiança através de Explicações: Os profissionais preferem raciocínios estruturados ("por que" e "o que fazer a seguir") em vez de alertas brutos.
• Semântica como Guia: A abstração de dados deve respeitar a semântica dos indicadores (cumulativos vs. incrementais) para evitar raciocínio instável.
• Governança Híbrida: A separação entre síntese generativa (LLM) e verificação baseada em regras permite a implantação de IA em escala, mantendo a supervisão humana e a auditabilidade.

Em suma, o Condition Insight valida que o raciocínio de LLMs restrito e fundamentado em evidências pode funcionar como uma camada de suporte à decisão governada, transformando dados fragmentados em ações de manutenção acionáveis e seguras.