DEV Community: André Vinicius

Implementando Redes Neurais e Inteligência Computacional do zero em Python (Perceptron, Adaline, MLP, Kohonen, Fuzzy e Algoritmos Genéticos)

André Vinicius — Sun, 15 Nov 2026 20:20:41 +0000

Antes de orquestrar LLMs modernos ou usar frameworks prontos como PyTorch e scikit-learn, implementar os algoritmos clássicos de Redes Neurais e Inteligência Computacional do zero em Python é a melhor forma de entender o que realmente acontece dentro de um modelo: propagação direta (forward pass), cálculo do gradiente, regra Delta, retropropagação do erro (backpropagation), mapas auto-organizáveis competitivos e otimização evolutiva.

Ao longo da graduação em Engenharia da Computação na UEFS, construí uma série de implementações fundamentais sem depender de camadas prontas de alto nível. Neste artigo, resumo a intuição matemática, a arquitetura e os casos práticos de 6 repositórios abertos no meu GitHub.

1. Perceptron de Rosenblatt e Adaline (`perceptron-oil-problem` & `adaline_valvulas`)

O Perceptron e o Adaline (Adaptive Linear Neuron) são a base histórica das redes neurais artificiais, mas diferem em um ponto crucial no treinamento:

Perceptron (perceptron-oil-problem): atualiza os pesos w apenas quando a função degrau (sinal) erra a classe discreta de uma amostra de óleo (y ∈ {-1, +1}).
Adaline (adaline_valvulas): aplica a Regra Delta (LMS — Least Mean Squares) sobre a saída linear contínua u = w·x + b antes da função de ativação, minimizando o Erro Quadrático Médio (MSE) via descida do gradiente para diagnóstico de acionamento de válvulas:

Δw = η × (d - u) × x

Essa diferença sutil — derivar uma superfície quadrática contínua em vez de uma função degrau descontínua — é o que abriu caminho para o treinamento de redes multicamadas.

2. Multilayer Perceptron (MLP) e Backpropagation (`multilayer-perceptron`)

Perceptrons de camada única só separam problemas linearmente separáveis. No repositório multilayer-perceptron, implementei uma rede de múltiplas camadas com retropropagação do erro (backpropagation) aplicada tanto ao clássico dataset Iris (3 classes) quanto a problemas geométricos não lineares (circulo.txt):

Forward pass: camadas ocultas com funções de ativação diferenciáveis não lineares (sigmoide / tangente hiperbólica), permitindo compor fronteiras de decisão curvas.
Backward pass: aplicação da regra da cadeia camada a camada, propagando o gradiente local da saída até a primeira camada oculta para atualizar matrizes de pesos e vetores de bias.

3. Aprendizado Não Supervisionado Competitivo: Mapas de Kohonen (`kohonen-iris-plants`)

Nem todo problema possui rótulos supervisionados. No repositório kohonen-iris-plants, implementei uma Rede de Kohonen (Self-Organizing Map — SOM) para agrupamento topológico das plantas Iris:

Para cada vetor de entrada x de 4 dimensões, os neurônios da grade competem pela menor distância euclidiana para eleger a BMU (Best Matching Unit):

   c = argmin_i ||x - w_i||

A BMU e seus vizinhos topológicos na grade atualizam seus pesos aproximando-se de x, com taxa de aprendizado e raio de vizinhança decaindo ao longo das épocas.
O resultado preserva a topologia: amostras similares no espaço de 4 dimensões ficam próximas no mapa bidimensional, sem nunca ter visto o rótulo da espécie durante o treino.

4. Lógica Fuzzy (`controlador_fuzzy`) e Algoritmos Genéticos (`Algoritmo-Genetico`)

Para completar a caixa de ferramentas de Inteligência Computacional:

Sistemas de Inferência Fuzzy (controlador_fuzzy): modelam incerteza contínua por funções de pertinência (fuzzificação), base de regras linguísticas (SE ... ENTÃO ...) e defuzzificação (centroide) para controle suave onde regras booleanas rígidas falham.
Algoritmos Genéticos (Algoritmo-Genetico): busca meta-heurística populacional com seleção por aptidão (fitness), cruzamento (crossover) e mutação estocástica para escapar de ótimos locais em espaços de busca discretos ou não diferenciáveis.

Por que isso importa na era de LLMs e Sistemas Multi-Agente?

Quando hoje projeto um sistema multi-agente como o Comanda (com BM25 + stemmer Snowball em português do zero) ou um motor de recomendação em produção com LSH Forest e MinHash, os fundamentos são os mesmos: espaço vetorial, métricas de distância/similaridade, custo computacional por consulta e avaliação quantitativa rigorosa.

Repositórios no GitHub

MLP: github.com/TheAndr3/multilayer-perceptron
Mapa de Kohonen (SOM): github.com/TheAndr3/kohonen-iris-plants
Adaline: github.com/TheAndr3/adaline_valvulas
Perceptron: github.com/TheAndr3/perceptron-oil-problem
Controlador Fuzzy: github.com/TheAndr3/controlador_fuzzy
Algoritmo Genético: github.com/TheAndr3/Algoritmo-Genetico

Sistemas de Recomendação em Produção com LSH Forest, MinHash e Cache LRU Serverless (latência de 200ms)

André Vinicius — Sun, 15 Nov 2026 20:18:11 +0000

Quando falamos de Inteligência Artificial hoje, quase toda a atenção vai para LLMs. Mas em produtos de alto volume — como e-commerce, delivery e plataformas de saúde — Sistemas de Recomendação Clássicos continuam sendo a espinha dorsal da personalização em larga escala.

Durante 12 meses de pesquisa e extensão na Universidade Estadual de Feira de Santana (UEFS), sob orientação do Prof. Dr. João Batista da Rocha Junior, projetei e coloquei em produção o módulo de recomendação do LogicFarma (plataforma SaaS da Farmácia Universitária com mais de 4.700 operações registradas, 666 históricos clínicos avaliados e 1.060 medicamentos).

O desafio de engenharia era claro: como recomendar procedimentos e consultas personalizadas para centenas de pacientes em tempo real e em disparos em lote (e-mail/WhatsApp), rodando sobre funções Serverless com limites rígidos de memória e tempo de execução?

Neste artigo, compartilho a arquitetura Memory-First, a adaptação do Locality-Sensitive Hashing (LSH Forest) com MinHash e a estratégia de degradação graciosa em 4 níveis que levou a latência de consulta para ~200ms.

1. O gargalo da Filtragem Colaborativa tradicional `O(N × M)`

Na Filtragem Colaborativa Baseada no Usuário, queremos encontrar pacientes com histórico clínico semelhante ao paciente-alvo e recomendar procedimentos que esses vizinhos realizaram, mas que o paciente ainda não conhece.

A métrica natural para conjuntos binários (realizou / não realizou um procedimento) é a Similaridade de Jaccard:

J(A, B) = |A ∩ B| / |A ∪ B|

O problema é que comparar um paciente contra todos os outros a cada requisição tem custo linear no número de usuários e itens. Em um endpoint HTTP ou num disparo de mensagens para 300 pacientes de uma vez, calcular Jaccard exato no banco de dados é inviável.

2. MinHash + LSH Forest: busca aproximada em tempo sublinear

Baseado nos experimentos de Rocha-Junior et al. (2025) sobre sistemas de recomendação com LSH em e-commerce, substituímos a comparação exata por duas estruturas probabilísticas:

MinHash (l = 200 permutações): transforma o conjunto de procedimentos e consultas de cada paciente (de tamanho variável) em uma assinatura compacta de comprimento fixo l = 200. A probabilidade de duas assinaturas coincidirem em uma posição é exatamente igual à Similaridade de Jaccard entre os conjuntos. Os experimentos mostraram que l = 200 atinge o pico de Precisão Média (15,1%) mantendo Recall próximo de 92%, enquanto l = 250 degrada a relação custo/precisão em RAM.
LSH Forest (Bawa et al., WWW 2005): em vez do LSH tradicional (que exige calibrar manualmente o número de buckets e o limiar de similaridade), utilizamos uma floresta de árvores de prefixos auto-ajustável (MinHashLSHForest), consultando k_build = 80 vizinhos na indexação e k_query = 20 vizinhos em tempo real.

3. Adaptação do E-commerce para o Domínio Clínico

No modelo original de e-commerce, as interações possuem pesos graduados (visited = 1, cart_added = 4, bought = 8). No domínio farmacêutico, a interação é estritamente binária (o paciente realizou ou não o procedimento/consulta).

Fizemos três adaptações de domínio:

Unificação de pesos por co-ocorrência: cada item é codificado como "Nome|Categoria" (ex.: "Glicemia|Procedimento", "Cefaleia|Consulta"), e a pontuação dos itens candidatos nos k = 20 vizinhos mais próximos é calculada pela frequência de co-ocorrência entre os vizinhos que possuem o item (excluindo o que o paciente já realizou).
Filtro de elegibilidade e outliers: apenas perfis com min_items = 2 até max_items = 100 entram no índice LSH Forest.
Filtro determinístico por restrição clínica de gênero: consultas exclusivas ao público feminino (como "Cólica Menstrual") são filtradas tanto na saída do LSH quanto na pré-computação do ranking de fallback masculino (GLOBAL_MASCULINO).

4. Arquitetura Memory-First com Cache LRU e Batch Inference

Como a aplicação principal rodava em Next.js / TypeScript e a biblioteca de referência acadêmica para LSH (datasketch) estava em Python, separamos o motor de recomendação em funções Serverless Python integradas ao MongoDB.

Para evitar ler e desserializar o índice do banco a cada chamada, desenhamos uma arquitetura Memory-First:

[Cron Mensal Python] ---> Constrói LSH Forest (l=200) ---> Serializa blobs no MongoDB
                                                                  |
[Next.js Top Tags]   ---> POST /api/lsh/batch (até 300 pac.) ---> Cache LRU em RAM (50 farmácias)

Cold Start (~2 a 3s): carrega os pickle blobs (forestBlob, minhashesBlob, fallbacksBlob, itemsByPatientBlob) do MongoDB e hidrata o container.
Warm Start (~0,2 a 0,3s): o Cache LRU em RAM responde diretamente da memória da função Serverless, sem tocar no banco.
Endpoint em Lote (/api/lsh/batch): quando o farmacêutico dispara comunicados com Top Tags (#Top3ProcedimentosRec, #Top3ConsultasRec), o módulo recommendationTagResolver.ts agrupa até 300 pacientes em uma única chamada HTTP POST, carregando o cache da farmácia uma só vez.

5. Degradação Graciosa em 4 Níveis (Zero Falha no Disparo)

Em um sistema real, o algoritmo de recomendação nunca pode derrubar o fluxo principal de comunicação (seja por cold start de um paciente novo sem histórico, seja por timeout de rede). Implementamos 4 níveis de degradação:

LSH Completo (lsh): os 20 vizinhos do LSH Forest preenchem todas as k sugestões pedidas.
LSH Parcial + Suplementação (lsh_partial): quando os vizinhos têm pouca variedade, o sistema completa as vagas faltantes com o Fallback Global segmentado por gênero (GLOBAL_FEMININO ou GLOBAL_MASCULINO).
Fallback de Cold Start (fallback): paciente recém-cadastrado (sem histórico) recebe imediatamente o ranking global segmentado pré-computado em memória, ou via leitura direta da coleção recomendacoesMensais.
Fail-safe de Timeout (30s): se a API Python falhar, as Top Tags degradam para string vazia e a mensagem transacional segue normalmente.

Em produção na Farmácia Universitária da UEFS, o indexador processou 666 históricos de pacientes em 4 unidades, indexando 353 perfis elegíveis e 1.978 registros clínicos em menos de 1,7 segundo.

Links relacionados

Código de referência e Model Card no Hugging Face: huggingface.co/TheAndr3/lsh-forest-clinical-recommender
GitHub: github.com/TheAndr3

Como construir agentes de atendimento que não alucinam dinheiro: regras em código, guardrails MCP e avaliação τ-bench em português

André Vinicius — Sun, 15 Nov 2026 19:59:53 +0000

Quando colocamos um LLM para atender clientes de um app de delivery, um chatbot comum resolve o caminho feliz, mas cria dois riscos inaceitáveis para a operação: conceder reembolso indevido sob pressão ou prompt injection, e prometer valores ou prazos fora da política.

Construí o Comanda — um sistema multi-agente de pós-venda de delivery sobre o Claude Agent SDK e o Model Context Protocol (MCP) — partindo de um princípio simples: o modelo conduz a conversa, mas o dinheiro e a segurança vivem em código determinístico.

Neste artigo, mostro as quatro decisões de engenharia que tornaram o sistema auditável e como uma suíte de avaliação estilo τ-bench (30 cenários, 8 adversariais) encontrou um bug sutil de fuso/relógio que nenhum teste manual havia pego.

1. A ferramenta de reembolso não aceita valor (`ADR-0001`)

Em muitos protótipos de agentes, a ferramenta tem a assinatura issue_refund(order_id, amount). Se o cliente convencer o modelo de que merece R$ 150,00 em vez da taxa de entrega de R$ 6,99, o modelo passa 150.00.

No Comanda, issue_refund recebe apenas (order_id, issue, item_ids). Não existe parâmetro de valor:

Quem calcula os centavos é uma função pura (evaluate_refund), que lê o pedido no SQLite, mede o atraso contra o ETA, confere a janela de 48 horas após a entrega e aplica a regra (R-ITEM, R-QUALITY, R-LATE-30, R-LATE-60, R-CANCELLED, R-LOST).
Se o valor passar de R$ 80,00 ou se o cliente tiver 3+ reembolsos nos últimos 30 dias, o reembolso nasce como pending_approval na Fila do atendente humano.
No banco, um trigger SQLite recusa qualquer UPDATE em refunds.amount_cents. Nem o agente nem o atendente humano podem alterar o valor calculado pela regra.

2. Topologia Supervisor–Especialistas com isolamento em código (`ADR-0003`, `ADR-0018`, `ADR-0020`)

Dar todas as ferramentas a um único agente mistura papéis e encarece cada turno. O Comanda divide o atendimento em três agentes:

Recepção (Claude Haiku): único agente que conversa com o cliente. Busca na política (search_policies com BM25 + stemmer Snowball do português escrito do zero) e delega aos especialistas.
Pedidos (Claude Sonnet): somente leitura (list_my_orders, get_order_details, track_delivery, get_restaurant_info).
Reembolsos (Claude Sonnet): check_refund_eligibility, issue_refund e escalate_to_human.

Essa divisão não depende só do prompt. Quatro guardrails em código protegem o atendimento:

customer_id fixo no ToolContext: nenhuma ferramenta aceita customer_id como argumento. Quando o cenário adversarial C023 tenta pedir reembolso do pedido O-10002 de outro cliente, _own_order nega na hora.
Isolamento por servidor MCP e hook PreToolUse: cada agente tem seu servidor MCP em processo, e o hook bloqueia qualquer chamada fora do papel ou tentativa de delegar com run_in_background ou troca de modelo.
Guardrail de elegibilidade (eligibility_check): Session.authorize nega issue_refund se check_refund_eligibility não tiver sido chamado na mesma sessão para o mesmo (order_id, issue, frozenset(item_ids)).
Máscara determinística de PII (CustomersMask): nome, e-mail e telefone são mascarados na criação de cada evento do Rastro (JSONL e SSE) e novamente na exportação para o replay público.

3. Avaliação estilo τ-bench e o bug do relógio fixo (`ADR-0027`)

Para medir o sistema sem depender de "olhômetro", criei 30 cenários em YAML (8 adversariais) com um Cliente simulado e um Juiz LLM, rodando sobre um banco SQLite determinístico cujo relógio é fixado em 05/11/2026 19:30 BRT.

Um cenário só passa se:

O estado final do SQLite bater por código com os reembolsos e tickets esperados; e
O Juiz não encontrar nenhuma violação grave na conversa (com verificação em código de que o trecho citado em evidence existe literalmente na fala do agente).

Na primeira rodada completa (50 atendimentos), o sistema teve 0 violações graves e 0 leves, conteve 7 dos 8 cenários adversariais e custou US$ 0,026 por atendimento (estimativa equivalente em API). Mas 9 cenários reprovaram por falta de reembolso no estado final.

Ao abrir os arquivos JSONL do Rastro, descobri a causa principal: o banco vivia em 05/11/2026, mas o runtime do Claude Code injetava no bloco <env> do modelo a data real da máquina (15/11/2026). Quando a Recepção lia um pedido entregue em 05/11/2026, ela calculava mentalmente que haviam se passado 10 dias (fora da janela de 48h!) ou dizia ao cliente que o pedido "não era de hoje", enquanto a ferramenta em Python usava Repository.now() (05/11/2026).

A correção (ADR-0027) foi passar AgentHost.now() explicitamente no prompt de todos os agentes, instruindo-os a usar o relógio do atendimento e ignorar qualquer data do ambiente. Sem o Rastro estruturado e a avaliação automatizada, esse conflito entre o relógio do domínio e o <env> do SDK passaria despercebido.

Links do projeto

Replay Público Interativo (Vercel): comanda-blond.vercel.app
Repositório, 29 ADRs e código: github.com/TheAndr3/comanda
Benchmark e Rastros no Hugging Face: huggingface.co/datasets/TheAndr3/comanda-delivery-support-eval-ptbr