Construindo um sistema de ingestão para sistemas especialistas em Python

Durante a fase final da minha especialização em Ciência de Dados e Big Data, fui apresentado ao conceito de sistemas especialistas. Naquele momento pensei imediatamente:

“É exatamente isso que eu preciso para melhorar o meu trabalho.”

Na primeira etapa do projeto, que já compartilhei em um artigo anterior sobre Sistemas Especialistas, desenvolvi o mecanismo de inferência, que funciona como o “cérebro” do sistema. Ele é responsável por analisar fatos e aplicar regras para chegar a uma conclusão.

Mas ainda faltava um componente fundamental:

uma forma de alimentar a base de conhecimento sem exigir que o especialista soubesse programar.

O Desafio: Transformar Conhecimento Humano em Dados

A base de conhecimento de um sistema especialista é o conjunto de regras que ele utiliza para resolver problemas.

Inicialmente, eu inseria essas regras manualmente em arquivos JSON, apenas para testar o funcionamento do sistema. Os testes funcionavam bem, mas logo percebi um problema evidente:

Como capturar o conhecimento de um especialista humano e transformá-lo em regras utilizáveis pelo sistema?

Imagine o seguinte processo:

1. Entrevistar um especialista
2. Registrar como ele resolve um determinado problema
3. Organizar esse conhecimento em uma planilha .csv
4. Converter essa planilha em uma estrutura .json que o sistema possa interpretar

A ideia parecia simples, mas surgiram novas questões:

• Como lidar com vários especialistas diferentes?
• Como unificar múltiplos arquivos CSV em uma única base de conhecimento?
• Como evitar duplicação de regras?
• Como reutilizar regras semelhantes para diferentes problemas?

Foi nesse momento que percebi que precisava criar um sistema de ingestão de conhecimento.

O Primeiro Erro (E o Primeiro Aprendizado)

Eu já tinha definido a estrutura do JSON que o sistema precisava. Então simplesmente converti as regras da planilha .csv para o mesmo formato que havia usado manualmente.

Executei o primeiro teste…

E falhou completamente. 🫨

Ao analisar o problema percebi vários erros de modelagem:

• Não havia um campo de identificação das regras
• Não existia um campo para status ou tratamento de erros
• Não havia estrutura para associar regras a códigos de assunto

Na prática, uma regra pode:

• Resolver mais de um tipo de problema
• Estar associada a vários códigos de assunto
• Compartilhar lógica com outras regras

Isso caracteriza um relacionamento N:N (muitos-para-muitos).

A solução foi permitir que cada regra possua um campo chamado:

codigos_assuntos

Esse campo contém uma lista de códigos de assunto relacionados àquela regra.

Como o Sistema de Ingestão Funciona

O sistema de ingestão permite que um especialista registre suas regras em uma planilha .csv, sem precisar lidar com arquivos JSON ou código.

A partir dessa planilha, o sistema gera automaticamente dois arquivos:

1️⃣ Catálogo de Regras

Contém todas as regras estruturadas que o sistema de inferência pode utilizar.

2️⃣ Mapeamento de Assuntos

Define quais regras devem ser verificadas para cada código de assunto.

Essa separação trouxe duas vantagens importantes:

• Organização da base de conhecimento
• Otimização do sistema de inferência

Agora, quando o sistema precisa analisar um problema, ele consulta apenas as regras relevantes para aquele assunto, em vez de percorrer toda a base de conhecimento.

Outro Erro de Arquitetura

Durante o desenvolvimento, cometi outro erro clássico.

Criei um script que fazia duas tarefas ao mesmo tempo:

• gerar o catálogo de regras
• gerar o mapeamento de assuntos

Isso violava um princípio importante de engenharia de software:

Cada função deve resolver apenas um problema.

Ao separar essas responsabilidades, o código ficou mais simples, mais claro e mais fácil de manter.

Regras Condicionais e Gatilhos

Outro desafio apareceu quando comecei a modelar regras condicionais.

Mesmo dentro de um determinado código de assunto, algumas regras só devem ser avaliadas se certas condições forem atendidas.

Para resolver isso, implementei um gatilho de ativação.

Assim:

• uma regra pode estar associada a um assunto
• mas só será executada se o gatilho for ativado

Isso torna o sistema mais preciso e eficiente.

O Que Desbloqueou Meu Entendimento

Algo que me ajudou muito a estruturar esse sistema foi comparar dois tipos de inteligência artificial.

Quando usamos modelos de linguagem (LLMs), lidamos com uma espécie de caixa-preta:

• criamos prompts
• refinamos instruções
• mas o processo interno não é totalmente previsível

Nos sistemas especialistas, a lógica é diferente.

Não existe caixa preta.

O processo de decisão é totalmente conhecido e controlado.

Essa ideia se conecta muito com princípios de engenharia de controle, onde conhecemos:

• as entradas
• o processo de transformação
• e as saídas esperadas

Pensar no problema como engenharia de conhecimento foi o que realmente destravou minha abordagem.

Aplicação no Mundo Real

O objetivo deste sistema especialista é auxiliar na análise de processos de importação de dispositivos médicos.

Nesse contexto:

Entradas (Fatos)

Dados fornecidos pela empresa importadora:

• formulários
• documentos anexados
• informações do processo

Base de Conhecimento

Regras que representam como especialistas analisam esses processos.

Saída do Sistema

O sistema pode produzir três resultados:

• Deferido
• Indeferido
• Em Exigência

Além disso, o sistema também pode sugerir procedimentos conforme protocolos operacionais padrão, inclusive para situações como interdição de carga.

O Que Aprendi Tecnologicamente

Esse projeto me trouxe aprendizados importantes:

• Engenharia de Conhecimento
• Arquitetura de sistemas especialistas
• Construção de sistemas de ingestão de dados
• Modelagem de regras de decisão
• Aplicação de IA simbólica

A IA simbólica é particularmente interessante porque seu processo decisório se aproxima da forma como humanos estruturam conhecimento: através de regras, lógica e inferência.

O Próximo Desafio

O próximo passo do projeto será desenvolver entrevistas estruturadas com especialistas.

O objetivo é coletar conhecimento sobre diferentes códigos de assunto e transformar essas entrevistas em regras para o sistema.

Isso levanta um novo desafio interessante:

Como unificar respostas de diferentes especialistas em uma única base de conhecimento?

Alguns cenários possíveis:

• Dois especialistas descrevem a mesma regra com palavras diferentes
• Regras iguais aparecem em contextos distintos
• Um mesmo código de assunto utiliza regras compartilhadas com outros

Resolver esse problema exigirá novas estratégias de normalização e deduplicação de regras.

E Você?

Você já trabalhou com sistemas especialistas ou IA simbólica?

Ou teria alguma sugestão de como lidar com o desafio de identificar regras equivalentes descritas de formas diferentes?

Gostaria muito de ouvir outras experiências e ideias.