Sistemas Especialistas

A minha visão durante o aprendizado

Há anos é muito comum que servidores/funcionários que são referência em suas áreas de atuação se aposentem ou deixem seus cargos, levando consigo um conhecimento valioso que não é devidamente registrado ou transferido para seus sucessores. Esse conhecimento, muitas vezes tácito e baseado em anos de experiência, acaba se perdendo com o tempo, gerando lacunas na capacidade técnica da organização e impactando diretamente na qualidade dos serviços prestados.

Numa forma de minimizar esta lacuna, surge a ideia de criar um sistema especialista que possa capturar e preservar esse conhecimento, tornando-o disponível para consulta e utilização por outros servidores/funcionários, mesmo após a saída do servidor original. Ao mesmo tempo, esta nova abordagem facilita treinamentos e disseminação do conhecimento na organização.

Quando mudei de área de atuação, senti muita dificuldade em adquirir o conhecimento necessário para realizar meu trabalho de forma eficiente. O modo como o conhecimento é transmitido, a meu ver é ineficiente, a chefia entrega um volume absurdo de legislações e procedimentos operacionais padrões, com uma série de termos específicos da área, e espera que o servidor absorva todo esse conhecimento em pouco tempo. Bem verdade que a minha chefia me deu suporte e foi paciente, mas mesmo assim, senti que faltava algo prático para meu treinamento.

Agora com um pouco mais de dois anos atuando obtive uma quantidade de conhecimentos que deveria me dar mais segurança na minha atuação, mas não é assim, a cada processo que analiso, a insegurança ainda é muito grande. Foi aí que descobri em uma disciplina da pós-graduação de ciência de dados com big data, os sistemas especialistas.

Engenharia Reversa do pensamento humano

Redes Neurais artificiais = caixa preta probabilistica

IA Simbólica = caixa branca determinística baseada em lógica 100% auditável.

Engenharia de Conhecimento

Base de Conhecimento = Fatos + Regras

Memória de Trabalho = Fatos

Motor de Inferência = Regras

Arquitetura Simbólica

Aquisição de conhecimento: Estado base contém as regras absolutas (Ex.: Se A então B)
Memória de trabalho (Work Memory): É o cenário dinâmico, ou seja, fatos isolados que o usuário informa ao sistema em uma sessão específica (Ex.: Fato 1: A, Fato 2: B)
Motor de Inferência: É o "cérebro" do sistema, responsável por aplicar as regras à memória de trabalho para chegar a uma conclusão.
Interface de Usuário: É a forma como o usuário interage com o sistema, fornecendo fatos e recebendo conclusões.
Rastro de Explicação: É a forma como o sistema explica suas conclusões ao usuário.

Exemplo prático

Base de Conhecimento:

Regra 1: Se o paciente tem febre e tosse, então ele pode ter gripe.
Regra 2: Se o paciente tem febre e dor de cabeça, então ele pode ter dengue.
Regra 3: Se o paciente tem febre, tosse e dor de cabeça, então ele tem gripe e dengue.

Memória de Trabalho:

Fato 1: O paciente tem febre.
Fato 2: O paciente tem tosse.
Fato 3: O paciente tem dor de cabeça.

Motor de Inferência:

Aplica a Regra 1: O paciente tem febre e tosse, então ele pode ter gripe.
Aplica a Regra 2: O paciente tem febre e dor de cabeça, então ele pode ter dengue.
Aplica a Regra 3: O paciente tem febre, tosse e dor de cabeça, então ele tem gripe e dengue.

Interface de Usuário:

O paciente apresenta quadro de febre, tosse e dor de cabeça, apresentando assim quadro clinico de gripe e dengue.

Rastro de Explicação:

Regra 1 ativada
Regra 2 ativada
Regra 3 ativada

Como fiz o meu algoritmo

Criei uma única classe SistemaEspecialisa que recebe como parâmetro o caminho do arquivo json que contém as regras. Tem um método para adicionar os fatos na memória de trabalho e um método para executar o sistema. O método executar verifica se os fatos da memória de trabalho atendem às condições das regras e aplica as regras que atendem às condições.

Entretanto, percebi que o método executar não era tão eficiente, pois ele não filtrava as regras de acordo com situações.

Imagina que o paciente entra no consultório e alega estar com dor no estômago, não faz sentido verificar se está com gripe ou com febre, logo as regras de tosse, febre e dor de cabeça não deveriam ser verificadas. Para um sistema especialista isso é um problema, pois ele vai verificar todas as regras e aplicar as que atendem às condições. Foi aí que pensei de forma diferente e modifiquei a estrutura da base de conhecimento.

A base de conhecimento é um arquivo JSON com uma lista de regras. Cada regra tem um nome, uma condição e uma consequência. Imagina que você tenha um sistema com 2 mil regras, cada regra é um objeto json, imagina o tamanho do arquivo json. Há a possibilidade de a condição ser um dicionário com os fatos que devem ser atendidos para que a regra seja ativada 'caminho feliz'. Esta configuração permite digitar menos código no json, entretanto perde na explicabilidade, pois caso mais de uma das condições falhar, o sistema não consegue identificar qual das condições falhou.

Na base de conhecimento que elaborei pensei em duas situações. Há regras que precisam ser verificadas por mais de um fato, mas há regras que precisa ser verificada por apenas um fato. Então, criei IDs para as regras e criei um objeto json de mapeamento para cada assunto. Neste mapeamento, há uma lista de regras que precisam ser verificadas em cada situação. Tornando o processo de inferência mais robusto e eficiente.

Mas a minha cabeça não parava de pensar em como melhorar a base de conhecimento mantendo a rastreabilidade sem criar um objeto para cada regra e criei a seguinte estrutura:

JSON
{
  "nome": "nome da regra",
  "condicoes": {//coloco aqui tantas quantas condições forem necessárias
  },
  "validacao": true,
  "insatisfatorio": {
      "status": "Situação Final para o caso de as condições não forem atendidas",
      "mensagem": "Retorno de quando a(s) condição(ões) não for(em) atendida(s)"
  }
}
python

def executar_fatura(self):
  for regra in self.regras:
      condicoes = regra.get("condicao", {})
      falhou = []
      for k, v_esperado in condicoes.itens():
          if self.memorias_trabalho.get(k) != v_esperado:
          falhou.append(k) # aqui cada regra que fala é adicionada de forma isolada à lista de falhas
  # Só gera o log e o veto se houver falhas
  if falhou:
      insatisfatorio = regra.get("insatisfatorio", {})
      status = insatisfatorio.get("status", "Erro")
      mensagem = insatisfatorio.get("mensagem", "")
  # Etapa 5 (Explicabilidade): Monta a frase com os culpados
  detalhe_erro = ", ".join(falhou).replace("_", " ") # Limpa os underscores para o usuário
  log = f"[{regra.get('nome')}] -> {status}: {mensagem}. Requisito(s) não atendido(s): {detalhe_erro}."

  self.rastro_explicacao.append(log)
  self.status_final = "Indeferido / Retido"

Com esta nova estrutura tornei a base de conhecimento manutenível, expansível e o feedback ao usuário mais claro. Com este script consegui solucionar o dilema da Arquitetura Simbólica, pois consegui criar uma base de conhecimento que é compacta e ao mesmo tempo manutenível, expansível e com feedback ao usuário claro. o meu motor de inferência consegue apontar exatamente onde está a falha e o feedback a ser dado ao usuário. Esta é a minha invenção de Regra de Validação Coletiva de Diagnóstico de Falha.

E aqui quero deixar a minha contribuição para a área de sistemas especialistas, pois acredito que esta abordagem possa ser utilizada em outros sistemas especialistas.

Comenta aí: você já conhecia sistemas especialistas ou assim como eu está sendo seu primeiro contato com o tema!

Até logo, quando virei com mais detalhes da minha implementação que continuar em desenvolvimento 😜