O erro do Agente Monolítico e o “Vibe Coding”

A primeira onda de desenvolvimento assistido por IA popularizou o que muitos chamam de Vibe Coding: o desenvolvedor descreve um requisito em linguagem natural, o LLM gera um bloco de código e, se parecer funcionar em dois ou três testes manuais, o código vai para produção.

O problema estrutural dessa abordagem está na natureza autorregressiva dos Grandes Modelos de Linguagem (LLMs). Quando um único agente recebe a missão de interpretar o requisito, modelar os dados, implementar o algoritmo e criar os testes unitários, ele sofre do mesmo viés cognitivo de um programador humano trabalhando sozinho — porém amplificado pela probabilidade estatística. Se o modelo alucinar uma premissa falsa na implementação, ele replicará exatamente a mesma premissa falsa ao gerar o teste unitário. O teste passa, o build fica verde e o bug vai para produção.

Nos artigos anteriores, vimos que Tipos são Teoremas e Programas são Provas (Isomorfismo de Curry-Howard) e que Refinement Types aliados a Property-Based Testing (PBT) fecham o cerco contra estados inválidos. Mas como escalar esse rigor usando IA generativa no dia a dia sem precisar de assistentes de prova acadêmicos?

1. Arquitetura de Enxames Adversariais (Multi-Agent Swarms): Separar as responsabilidades em agentes independentes com objetivos conflitantes (quem especifica não implementa; quem tenta quebrar não é quem escreveu).
2. O Sistema de Tipos como Motor de Prova: Em vez de exigir provadores de teoremas externos complexos, utilizamos o próprio verificador estático de tipos (Type Checker) e validação de contratos em linguagens de produção (TypeScript e Python) como o oráculo determinístico que aprova ou rejeita o trabalho dos agentes.

O Sistema de Tipos como Motor de Prova Prático

Quando falamos em “provar um teorema” no código, não precisamos necessariamente invocar táticas manuais em Coq ou Lean. Se modelarmos nossas estruturas de dados de forma que estados inválidos sejam irrepresentáveis, o próprio Type Checker (tsc --noEmit no TypeScript ou mypy --strict / pyright + CrossHair no Python) atua como um motor de prova construtiva.

Sob a ótica da programação orientada a dados (Data-Oriented Programming) e do Type-Driven Development:

• Definir um tipo imutável e restrito é enunciar o teorema.
• Escrever uma função pura que transforma o Tipo A no Tipo B sem usar escapatórias (como any, as unknown ou # type: ignore) é fornecer a prova construtiva.
• Quando o verificador de tipos analisa a árvore sintática (AST) e confirma que todas as ramificações, uniões discriminadas (Discriminated Unions) e restrições de tipos batem, ele está emitindo o seu Q.E.D.

A Arquitetura do Enxame: Os 4 Agentes Especializados

Para eliminar a complacência de um agente único, estruturamos o pipeline de geração de código como uma máquina de estados finitos onde quatro agentes operam em malha fechada, coordenados por um engenheiro humano:

[Requisito do Engenheiro Humano]
                                  │
                                  ▼
               ┌──────────────────────────────────────┐
               │ 1. Agente Especificador (Arquiteto)  │
               │ (Define Contratos, Tipos & Teoremas) │
               └──────────────────┬───────────────────┘
                                  │ (Assinaturas Imutáveis)
                                  ▼
               ┌──────────────────────────────────────┐
        ┌─────►│ 2. Agente Implementador (Construtor) │◄─────┐
        │      │   (Escreve Funções Puras p/ os Tipos)│      │
        │      └──────────────────┬───────────────────┘      │
        │                         │                          │
(Contraexemplo            [Código Candidato]          (Erro de Tipo /
  Reduzido)                       │                    Exaustividade)
        │                         ▼                          │
┌───────┴──────────────┐  ┌──────────────────────────────────┴───┐
│ 3. Agente            │  │ 4. Agente Verificador (Juiz de Tipos)│
│    Falsificador (PBT)├─►│    (Type Checker Estrito & AST Audit)│
└──────────────────────┘  └──────────────────┬───────────────────┘
                                             │ (Tipos Habitados + 0 Falhas)
                                             ▼
                                  [Código Verificado]

1. O Agente Especificador (O Arquiteto de Tipos)

• Missão: Traduzir requisitos de negócio ambíguos em estruturas de dados imutáveis, contratos estritos e assinaturas de funções.
• Restrição Operacional: Ele é proibido de escrever a lógica de implementação (o corpo das funções deve conter apenas ... ou throw new Error("Not implemented")). Seu único entregável são os tipos (os teoremas que precisam ser habitados).

2. O Agente Implementador (O Construtor Funcional)

• Missão: Escrever a transformação pura de dados que satisfaz as assinaturas criadas pelo Especificador.
• Restrição Operacional: Ele tem acesso somente leitura às definições de tipos do Especificador. Ele não pode alterar a assinatura de uma função para facilitar o próprio trabalho, nem usar recursos de evasão de tipos (any, cast, ignore).

3. O Agente Falsificador (O Caçador de Invariantes via PBT)

• Missão: Assumir que o Agente Implementador errou. Ele analisa os tipos do Especificador e gera suítes de Property-Based Testing (usando Hypothesis no Python ou fast-check no TypeScript) para bombardear a implementação com milhares de casos extremos.
• Poder no Loop: Se encontrar uma falha lógica que passou pelo sistema de tipos, ele devolve o shrunk counterexample (contraexemplo mínimo) diretamente para o Implementador refazer o código.

4. O Agente Verificador (O Motor de Prova via Type System)

• Missão: Atuar como o porteiro formal determinístico. Ele compila a relação entre os tipos e a implementação usando o verificador estático em modo ultra-estrito, audita a AST para garantir que não houve burla nas regras de tipagem e executa verificadores simbólicos de contratos.
• Poder no Loop: Enquanto o compilador apontar erro de subtipagem ou falta de exaustividade em um pattern matching, o loop bloqueia a aprovação e força o Implementador a corrigir a prova (o código).

Estudo de Caso 1: TypeScript (Branded Types e Provas de Exaustividade)

Imagine um sistema financeiro que processa estornos de pedidos. As regras de negócio exigem que:

• O valor do estorno seja estritamente positivo e nunca exceda o valor original pago.
• Apenas pedidos no estado Pago possam sofrer estorno (pedidos Pendentes ou já Cancelados jamais podem passar pela função de estorno em tempo de compilação).

Veja como o enxame resolve isso usando o sistema de tipos do TypeScript como motor de prova:

// ============================================================================
// ETAPA 1: AGENTE ESPECIFICADOR (Define os Tipos/Teoremas - Imutavel)
// ============================================================================

// 1. Criamos Branded Types (Tipos Nominais Refinados) usando unique symbol.
// Isso impede que um 'number' comum habite o tipo sem passar pela prova (Smart Constructor).
declare const CentavosPositivosBrand: unique symbol;
export type CentavosPositivos = number & { readonly [CentavosPositivosBrand]: "CentavosPositivos" };
declare const ProvaEstornoValidoBrand: unique symbol;
export type EstornoValido = {
  readonly valorEstorno: CentavosPositivos;
  readonly saldoRestante: number;
  readonly [ProvaEstornoValidoBrand]: "EstornoMenorOuIgualAoPago";
};
// 2. Modelamos a Maquina de Estados via Discriminated Unions.
// O estado 'PedidoPago' e um tipo distinto de 'PedidoPendente'.
export type PedidoPendente = { readonly status: "PENDENTE"; readonly id: string };
export type PedidoPago = { readonly status: "PAGO"; readonly id: string; readonly totalPago: CentavosPositivos };
export type PedidoEstornado = {
  readonly status: "ESTORNADO";
  readonly id: string;
  readonly comprovante: EstornoValido;
};
export type Pedido = PedidoPendente | PedidoPago | PedidoEstornado;
// 3. O Teorema (Assinatura): Recebe APENAS 'PedidoPago' (nunca 'Pedido' generico)
// e exige uma prova de que o estorno e valido para emitir um 'PedidoEstornado'.
export type ProcessarEstornoFn = (
  pedido: PedidoPago,
  solicitacaoCentavos: CentavosPositivos
) => PedidoEstornado | Error;

// ============================================================================
// ETAPA 2: AGENTE IMPLEMENTADOR (Habita os Tipos / Escreve a Prova Construtiva)
// ============================================================================
// 4. Construtor de Prova: o unico lugar autorizado a instanciar 'EstornoValido'
// apos verificar a desigualdade matematica.
function construirProvaEstorno(
  pago: CentavosPositivos,
  solicitado: CentavosPositivos
): EstornoValido | null {
  if (solicitado <= pago) {
    return {
      valorEstorno: solicitado,
      saldoRestante: pago - solicitado,
      [ProvaEstornoValidoBrand]: "EstornoMenorOuIgualAoPago",
    };
  }
  return null;
}
// 5. Implementacao pura respeitando estritamente o contrato do Especificador.
export const processarEstorno: ProcessarEstornoFn = (pedido, solicitacaoCentavos) => {
  const prova = construirProvaEstorno(pedido.totalPago, solicitacaoCentavos);
  if (!prova) {
    return new Error("Violacao de invariante: estorno maior que o total pago.");
  }
  return {
    status: "ESTORNADO",
    id: pedido.id,
    comprovante: prova,
  };
};

// ============================================================================
// ETAPA 3 e 4: AGENTE FALSIFICADOR (fast-check) + VERIFICADOR (tsc --strict)
// ============================================================================
import fc from "fast-check";
// 6. O Agente Verificador garante em tempo de compilacao que tentar passar
// um 'PedidoPendente' para 'processarEstorno' sequer compila (Erro TS2345).
// 7. O Agente Falsificador gera milhares de pares (pago, solicitado) para
// tentar quebrar a invariante de saldoRestante >= 0:
fc.assert(
  fc.property(
    fc.integer({ min: 1, max: 10_000_000 }),
    fc.integer({ min: 1, max: 10_000_000 }),
    (pagoBruto, solicitadoBruto) => {
      const pago = pagoBruto as CentavosPositivos;
      const solicitado = solicitadoBruto as CentavosPositivos;
      const pedido: PedidoPago = { status: "PAGO", id: "ped_1", totalPago: pago };
      const resultado = processarEstorno(pedido, solicitado);
      if (solicitado <= pago) {
        return !(resultado instanceof Error) && resultado.comprovante.saldoRestante >= 0;
      } else {
        return resultado instanceof Error;
      }
    }
  )
);

Em que:

• Etapa 1 (Branded Types): O Agente Especificador cria tipos nominais usando unique symbol. Nenhum número comum pode ser atribuído a CentavosPositivos acidentalmente.
• Etapa 2 (União Discriminada): O estado do pedido é separado em tipos independentes (PedidoPendente, PedidoPago, PedidoEstornado).
• Etapa 3 (Assinatura como Teorema): A assinatura ProcessarEstornoFn restringe o domínio de entrada exclusivamente a PedidoPago. Isso prova em tempo de compilação que pedidos não pagos jamais serão estornados.
• Etapa 4 (Construtor de Prova): O Agente Implementador cria uma função isolada que verifica a condição matemática solicitado <= pago antes de selar o objeto com a marca ProvaEstornoValidoBrand.
• Etapa 5 (Transformação Pura): A função principal consome a prova e constrói o estado final imutável PedidoEstornado.
• Etapa 6 e 7 (Verificação e Falsificação): O compilador TypeScript (tsc) valida a prova estática de tipos, enquanto o fast-check bombardeia a relação numérica para garantir que nunca haverá saldo residual negativo.

Estudo de Caso 2: Python (Tipos Imutáveis, Contratos e Execução Simbólica)

No Python, combinamos uma arquitetura orientada a dados imutáveis (@dataclass(frozen=True) e NewType) com contratos formais (icontract) verificados tanto pelo mypy --strict quanto pelo motor de execução simbólica CrossHair (que traduz o código Python para o SMT Solver Z3 nos bastidores) e pelo Hypothesis.

Imagine um algoritmo de alocação de estoque que reserva unidades de um lote disponível sem jamais permitir estoque negativo ou perda de unidades na soma total (lei da conservação de massa/estoque):

from typing import NewType, Union
from dataclasses import dataclass
import icontract
from hypothesis import given, strategies as st

# ============================================================================
# ETAPA 1: AGENTE ESPECIFICADOR (Modelagem de Dados Imutavel e Contratos)
# ============================================================================
# 1. Definimos tipos distintos no sistema de tipos estatico (mypy/pyright)
QuantidadePositiva = NewType("QuantidadePositiva", int)
@dataclass(frozen=True)
class LoteEstoque:
    sku: str
    disponivel: int
    reservado: int
@dataclass(frozen=True)
classErroAlocacao:
    motivo: str

# 2. O Especificador define o teorema via pre e pos-condicoes formais.
# A pos-condicao exige a prova da Lei de Conservacao de Estoque:
# (disponivel_antes + reservado_antes) == (disponivel_depois + reservado_depois)
@icontract.require(lambda lote: lote.disponivel >= 0 and lote.reservado >= 0)
@icontract.require(lambda qtd_solicitada: qtd_solicitada > 0)
@icontract.ensure(
    lambda lote, qtd_solicitada, result: (
        isinstance(result, (LoteEstoque, ErroAlocacao))
        and (
            isinstance(result, ErroAlocacao)
            or (
                result.disponivel >= 0
                and result.reservado >= lote.reservado
                and (result.disponivel + result.reservado) == (lote.disponivel + lote.reservado)
            )
        )
    )
)
def reservar_estoque(
    lote: LoteEstoque, qtd_solicitada: QuantidadePositiva
) -> Union[LoteEstoque, ErroAlocacao]:
    # ========================================================================
    # ETAPA 2: AGENTE IMPLEMENTADOR (Preenche o corpo da funcao pura)
    # ========================================================================
    # 3. Transformacao pura de dados sem mutacao de estado in-place
    if qtd_solicitada > lote.disponivel:
        return ErroAlocacao(motivo="Estoque insuficiente para reserva")
    return LoteEstoque(
        sku=lote.sku,
        disponivel=lote.disponivel - qtd_solicitada,
        reservado=lote.reservado + qtd_solicitada,
    )

# ============================================================================
# ETAPA 3 e 4: AGENTE FALSIFICADOR (Hypothesis) + VERIFICADOR (mypy + CrossHair)
# ============================================================================
# 4. O Agente Falsificador tenta violar o contrato gerando lotes e pedidos extremos
@given(
    disponivel=st.integers(min_value=0, max_value=10**6),
    reservado=st.integers(min_value=0, max_value=10**6),
    solicitado=st.integers(min_value=1, max_value=10**6),
)
def test_propriedade_conservacao_estoque(disponivel: int, reservado: int, solicitado: int) -> None:
    lote_inicial = LoteEstoque(sku="PROD-01", disponivel=disponivel, reservado=reservado)
    qtd = QuantidadePositiva(solicitado)
    # 5. A propria execucao aciona os contratos do icontract como oraculo
    resultado = reservar_estoque(lote_inicial, qtd)
    if isinstance(resultado, LoteEstoque):
        assert resultado.disponivel + resultado.reservado == disponivel + reservado

Em que:

• Etapa 1 (Imutabilidade e Tipos): O Agente Especificador cria QuantidadePositiva via NewType e modela LoteEstoque com @dataclass(frozen=True), impedindo mutação de estado acidental durante a execução.
• Etapa 2 (Teorema de Conservação): Usando @icontract.require e @icontract.ensure, o Especificador crava a invariante fundamental: a soma entre o estoque disponível e o estoque reservado antes da função deve ser estritamente igual à soma após a função, e nenhum saldo pode ficar negativo.
• Etapa 3 (Implementação Funcional): O Agente Implementador escreve a lógica pura retornando uma nova instância de LoteEstoque ou ErroAlocacao (tratando erros como valores, e não como exceções cegas).
• Etapa 4 e 5 (Auditoria Automática): O Agente Falsificador roda o Hypothesis contra a função, enquanto o Agente Verificador roda mypy --strict (para garantir que int puro não seja passado onde se exige QuantidadePositiva) e crosshair check (para provar simbolicamente via Z3 que nenhuma combinação de inteiros consegue violar o @icontract.ensure).

Como Impedir que os Agentes “Trapaceiem”

Um comportamento cumum e que pode esconder problemas quando colocamos agentes de IA em um loop guiado por verificadores de tipos é o Reward Hacking. Se o Agente Implementador não consegue fazer o código compilar após duas tentativas porque o sistema de tipos é rigoroso demais, a tendência estatística do LLM é tentar “calar” o compilador ou modificar o código.

Ele tentará injetar um as any ou @ts-ignore no TypeScript, ou um # type: ignore e cast(Any, ...) no Python. No pior dos casos, se ele tiver acesso ao arquivo de testes, tentará apagar a linha do assert que está falhando

Para que a arquitetura de enxame funcione com rigor matemático, o Agente Verificador não deve ser um LLM opinando sobre o código, mas sim um script determinístico de auditoria de AST (Árvore Sintática Abstrata) combinado com permissões de sistema de arquivos:

• Isolamento de Escrita (File-System Sandboxing): O Agente Implementador só tem permissão de escrita em src/implementation.py (ou .ts). Os arquivos src/types_and_contracts.py (do Especificador) e tests/properties_test.py (do Falsificador) são montados como Read-Only para o Implementador.
• Bloqueio de Evasão de Tipos na AST: Antes mesmo de rodar o compilador, um parser leve (usando o módulo nativo ast do Python ou ts-morph / eslint no TypeScript) varre o código gerado pelo Implementador e rejeita instantaneamente qualquer commit que contenha:
• Uso da palavra-chave Any ou cast;
• Comentários contendo type: ignore, @ts-ignore, @ts-expect-error ou eslint-disable;
• Uso de blocos try / except Exception: pass que engolem violações de contrato silenciosamente;
• Mutação de argumentos de entrada.

Quando Usar e Quando Não Usar um Enxame Verificado

Orquestrar quatro agentes em loop com verificadores estáticos e testes de propriedade consome mais tokens e tempo de processamento do que um simples autocomplete. A aplicação deve ser estratégica:

Quando usar esta arquitetura:

• Regras de Negócio Core, Motores de Precificação e Finanças: Onde erros de arredondamento, estados inconsistentes ou transições ilegais geram perda financeira direta.
• Refatoração Automatizada de Sistemas Legados: O Especificador extrai os contratos do sistema antigo, o Falsificador gera a bateria de equivalência (Differential Testing) e o Implementador reescreve o código limpo até convergir.
• Geração de Módulos Autônomos e Bibliotecas Internas: Componentes com fronteiras bem definidas (entrada/saída clara) que serão consumidos por múltiplos serviços.

Quando NÃO usar:

• Prototipação Visual, UI/UX e Front-end Cosmético: Ajustar espaçamentos CSS, animações ou componentes puramente visuais onde a validação humana no navegador é instantânea.
• Scripts Descartáveis de Uso Único (One-off Scripts): Migrações simples ou análises exploratórias ad-hoc onde o custo de definir tipos formais supera a vida útil do código.

Conclusão: Do Programador Codificador ao Orquestrador de Invariantes

A ascensão dos agentes de IA não diminui a importância dos Métodos Formais e da Teoria de Tipos, mas pelo contrário, ela os torna indispensáveis. Enquanto humanos escreviam código a 50 linhas por hora, a revisão manual conseguia conter parte dos danos. Quando agentes geram 5.000 linhas em minutos, revisar código no “olhômetro” torna-se humanamente impossível.

Ao estruturar o desenvolvimento como um Enxame Verificado , onde o humano atua no topo definindo a intenção arquitetural, o Especificador traduz isso em tipos rigorosos, o Implementador busca a solução, o Falsificador ataca com Property-Based Testing e o Verificador exige a prova do sistema de tipos, mudamos fundamentalmente a nossa relação com a IA.

Deixamos de pedir para a máquina “escrever um código que parece funcionar” e passamos a exigir que ela encontre uma prova construtiva que satisfaça o nosso sistema de tipos. A criatividade passa a ser estocástica e automatizada, mas a aceitação do código permanece 100% determinística, lógica e formal.

Referências

• Brady, E. (2017). Type-Driven Development with Idris. Manning Publications.
• King, A. (2019). Parse, don’t validate. Lexi Lambda Blog.
• Sharapov, P., & Schanely, P. (2024). CrossHair: Symbolic Execution and Contract Verification for Python. Documentação Oficial e Repositório Técnico.
• Dubien, N. (2023). Property-Based Testing in TypeScript with fast-check.
• Wu, Q., Bansal, G., et al. (2023). AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. Microsoft Research / arXiv:2308.08155.

A distrância entre a Academia e a Indústria

No artigo anterior, exploramos como o Property-Based Testing (PBT) e o Theorem-Oriented Programming (TOP) elevam a qualidade do software da validação pontual para a certeza matemática. Sob o Isomorfismo de Curry-Howard, vimos que tipos são teoremas e programas são provas.

Mas quando um engenheiro de software tenta levar o Theorem-Oriented Programming puro para uma equipe de produto comercial, ele esbarra em uma parede pragmática: o custo da prova manual. As linguagens com tipos dependentes completos (como Lean, Rocq/Coq, Agda ou Idris) exigem que o desenvolvedor seja como um matemático ativo, escrevendo técnicas de indução estrutural para convencer o compilador de que a implementação respeita a especificação. Para grande maioria das empresas, o tempo gasto mantendo provas formais manuais simplesmente não fecha a conta do ROI diante de prazos agressivos.

Isso cria uma falsa dualidade na indústria: ou nos contentamos com sistemas de tipos tradicionais (como int, str, float em Python, TypeScript ou Rust), que deixam passar falhas lógicas graves, ou mergulhamos no rigor acadêmico dos assistentes de prova interativos.

Mas esse não é o fim da linha, existe uma solução bem prática nessa evolução: a união entre Design by Contract (DbC) e Refinement Types (Tipos de Refinamento), impulsionada por motores de Automated Theorem Proving (ATP) invisíveis ao desenvolvedor.

A Cegueira dos Tipos Tradicionais (“Stringly & Intly Typed”)

Pense em uma função simples de domínio financeiro ou comercial: calcular o preço final de um produto aplicando uma margem de contribuição ou uma taxa de desconto. Em uma linguagem com tipagem estática tradicional (ou Python moderno com type hints), a assinatura costuma ser escrita assim:

def aplicar_desconto(preco: float, percentual_desconto: float) -> float:
    return preco * (1.0 - percentual_desconto)

Para o verificador de tipos tradicional (mypy, pyright, compilador do Rust ou TypeScript), essa função é impecável: ela recebe dois números e retorna um número. Mas, do ponto de vista matemático e de domínio, o tipo float é um superconjunto perigosamente amplo:

• O que acontece se preco for -50.0?
• E se percentual_desconto for 1.5 (gerando um preço final negativo, onde o sistema paga para o cliente levar o produto)?
• E se percentual_desconto for float('nan') ou float('inf')?

O sistema de tipos padrão verifica a representação na memória (quantos bytes ocupa e quais operações de CPU são válidas), mas é completamente cego à semântica do domínio. Para tapar esse buraco, espalhamos dezenas de armengues como if valor < 0: raise ValueError(...) pelo código , que são validações posteriores que só explodem em tempo de execução (runtime), quando o dado inválido já contaminou o fluxo.

Design by Contract (DbC): Especificação como Cidadã de Primeira Classe

Cunhado por Bertrand Meyer na década de 1980 (com a linguagem Eiffel) e fundamentado na Lógica de Hoare ({P} C {Q}), o Design by Contract trata a relação entre uma função (fornecedor) e quem a chama (cliente) por meio de um contrato formal explícito, dividido em três pilares:

• Pré-condições (requires): O que deve ser verdade antes da função ser executada. É a obrigação de quem chama. Se a pré-condição for violada, a função nem sequer tem obrigação de rodar; a culpa do bug é inequivocamente do chamador.
• Pós-condições (ensures): O que a função garante que será verdade depois que ela terminar, assumindo que a pré-condição foi respeitada. É a obrigação da implementação.
• Invariantes de Estado / Estrutura (invariant): Propriedades que devem permanecer verdadeiras durante todo o ciclo de vida de uma estrutura de dados ou a cada iteração de um loop.

Em uma notação formal da Lógica de Hoare, representamos nosso cálculo de desconto como:

{preco > 0 ∧ 0 ≤ desconto < 1} res := aplicar_Desconto(preco, desconto) {0 < res ≤ preco}

Em que:

• Pré-condições: {preco > 0 forall 0 ≤ desconto < 1}, o preço oroginal precisa ser positivo e (∧) a taxa de desconto deve zero ou menor que um, ou 0% a 99.999…%.
• Comando: O opererador := representa a atribuição, em aplicar_desconto(preco, desconto) estamos executando a função para calcular preço x (1–0) e armazenando o valor do retornado na variável res(resultado)
• Pós-condição: Na pós condição {0 < res ≤ preço} estamos garantindo que o preço final após o desconto continuará obrigatoriamente positivo e maior que zero.

Mas por que essa fórmula prova a ausência de bugs? Em um verificador formal (ou SMT Solver como o Z3), essa tripla é transformada em um teorema de implicação lógica pura:

∀ preco, desconto ∈ ℝ, (preco > 0 ∧ 0 ≤ desconto < 1) ⟹ (0 < preco × (1 — desconto ≤ preco)

A demonstração algébrica que o compilador resolve nos bastidores é direta:

1. Como desconto < 1, subtraindo de 1 temos que (1 — desconto) > 0.
2. Como o produto de dois números estritamente positivos (preco > 0 e 1 — desconto > 0) é sempre positivo, fica provado que 0 < res.
3. Como desconto ≥ 0, temos que (1 — desconto) ≤ 1. Multiplicando ambos os lados por preco (que é positivo), temos preco × (1 — desconto) ≤ preco × 1, provando que res ≤ preco.

Contratos Dinâmicos vs. Contratos Estáticos

Você pode implementar DbC hoje mesmo em Python usando bibliotecas como icontract ou deal, decorando funções com @require(lambda x: x > 0) e @ensure(lambda result, x: result <= x).

• A vantagem imediata: Seus contratos viram oráculos automáticos para o Property-Based Testing (o Hypothesis consegue ler os decoradores do icontract e gerar milhares de entradas válidas respeitando o @require para tentar quebrar o @ensure).
• A limitação: Contratos puramente dinâmicos ainda são checados em runtime (ou durante a suíte de testes). E se pudéssemos embutir esses contratos diretamente no sistema de tipos e verificá-los em tempo de compilação? É exatamente aí que entram os Refinement Types.

Refinement Types: Tipos com Predicados Lógicos

Um Refinement Type (Tipo de Refinamento) é um tipo base tradicional (como ℤ, Int, Float ou List) filtrado por um predicado lógico decidível. Na notação matemática de teoria dos conjuntos (compreensão), escrevemos:

{v : T | P(v)}

Lê-se: “O conjunto de todos os valores v do tipo base T tais que o predicado lógico P(v) seja verdadeiro”.

Veja como conceitos vagos do dia a dia ganham precisão cirúrgica quando expressos como Refinement Types:

• Natural Positivo (PosInt): {x : Int | x > 0}
• Taxa / Percentual Normalizado (Rate): {r : Float | 0.0 ≤ r ≤ 1.0}
• Lista Não-Vazia (NonEmptyList): {xs : List α | len(xs) > 0}
• Índice Seguro de Vetor (ValidIdx): {i : Int | 0 ≤ i < len (arr)}

Aqui está a diferença crucial entre Theorem-Oriented Programming clássico (Tipos Dependentes completos) e Refinement Types. Em Lean ou Coq, os predicados podem conter qualquer lógica arbitrária de ordem superior, o que torna a verificação matematicamente indecidível no caso geral — obrigando o humano a escrever a prova.

Nos Refinement Types (implementados em ferramentas como LiquidHaskell, Flux para Rust, Dafny ou Stainless para Scala), os predicados P(v) são estrategicamente restritos a lógicas decidíveis (como aritmética linear inteira, lógica de vetores de bits e teorias não interpretadas). Graças a essa restrição arquitetural, você escreve zero linhas de prova.

Quando você compila o código, o verificador extrai as condições de subtipagem (chamadas de Verification Conditions ou VCs) e as envia silenciosamente para um SMT Solver (Satisfiability Modulo Theories, como o Z3 da Microsoft ou o cvc5).

[Código + Refinement Types] 
        │
        ▼ (Extração de Contratos)
[Condições de Verificação (VCs): Implicações Lógicas P(x) ⟹ Q(f(x))]
        │
        ▼ (Consulta Negada: ∃x tal que P(x) ∧ ¬Q(f(x))?)
[SMT Solver (Z3 / cvc5)]
        ├──► UNSAT (Impossível violar) ──► Compilação Aprovada (Prova Automática!)
        └──► SAT (Contraexemplo achado: x = 0) ──► Erro de Compilação Cirúrgico

O SMT Solver tenta achar um único contraexemplo que satisfaça as pré-condições mas viole a pós-condição. Se o solver retornar UNSAT (Unsatisfiable), significa que é matematicamente impossível violar o contrato: seu teorema está provado automaticamente. Se retornar SAT, o compilador trava o build e já te mostra exatamente o valor que quebraria o sistema em produção.

Como Isso Funciona no Código

Para visualizar o poder dessa abordagem sem cair em abstrações puras, veja o exemplo abaixo como um problema clássico de falha em produção (divisão por zero e perda de invariantes em cálculos de lote) é resolvido estaticamente com contratos e refinamentos (usando a sintaxe limpa do Dafny / estilo Flux):

// 1. Definimos um Refinement Type: um inteiro estritamente positivo
type PosInt = x: int | x > 0 witness 1

// 2. Função com Design by Contract verificado estaticamente pelo Z3
method CalcularTicketMedio(receitaTotal: int, quantidadePedidos: PosInt) returns (ticket: int)
  // Pré-condição: receita não pode ser negativa
  requires receitaTotal >= 0
  // Pós-condições provadas matematicamente para QUALQUER entrada:
  ensures ticket >= 0
  ensures ticket <= receitaTotal
{
  // O compilador sabe pelo Refinement Type 'PosInt' que quantidadePedidos >= 1.
  // Portanto, ele PROVA automaticamente:
  // 1) Impossibilidade absoluta de ZeroDivisionError
  // 2) Que a divisão inteira jamais será negativa nem maior que o numerador
  ticket := receitaTotal / quantidadePedidos;
}

Se outro desenvolvedor tentar chamar CalcularTicketMedio(1000, total_clientes - clientes_inativos) sem antes provar no fluxo de controle (via um simples if total_clientes > clientes_inativos) que o segundo argumento é estritamente maior que zero, o código sequer compila.

Mas como aplicar essa mentalidade hoje em linguagens mainstream como Python, TypeScript ou Rust? Através do padrão arquitetural conhecido como Parse, Don’t Validate (popularizado por Alexis King), que materializa os Refinement Types por meio de Tipos Opacos / Newtypes e Construtores Inteligentes (Smart Constructors).

O erro comum em sistemas tradicionais é validar: você recebe um int, checa if x > 0 na camada de entrada, mas continua passando o mesmo tipo primitivo int para as 15 funções internas do domínio. As funções internas não têm garantia no sistema de tipos de que a validação já ocorreu, forçando programação defensiva redundante.

Ao usar a mentalidade de Refinement Types:

• A Fronteira Impura (I/O, API, Banco de Dados): Recebe dados brutos não confiáveis (int, str, dict) e aplica um parser estrito (como Pydantic com tipos restritos PositiveInt, confloat(ge=0, le=1) em Python, ou tipos refinados com NewType). Se falhar, rejeita imediatamente na borda.
• O Núcleo Funcional Puro (Verified Core): Só aceita os tipos já refinados em suas assinaturas. Dentro do núcleo, nenhuma função precisa fazer if x < 0: raise ..., pois um valor inválido é irrepresentável nos tipos aceitos pelo núcleo.

Ferramentas por Ecossistema

Se você quer introduzir Refinement Types e Design by Contract nos seus projetos atuais sem mudar para um assistente de provas acadêmico, esta é a stack estado da arte atual:

• Rust: Flux (sistema de Refinement Types conectado ao compilador do Rust que usa SMT solvers para provar ausência de panics e acessos fora de limites em arrays), Kani (verificador de modelos bit-preciso mantido pela AWS) e Creusot (contratos dedutivos em Rust).
• Python: CrossHair (usa o SMT Solver Z3 e execução simbólica para verificar contratos icontract, deal ou assert em código Python puro estaticamente), aliado a Pydantic (Annotated constraints) + Hypothesis para fechar o loop híbrido.
• Haskell: LiquidHaskell (o padrão-ouro histórico de Logically Qualified Data Types, permitindo provar propriedades complexas de estruturas de dados usando o Z3 diretamente em comentários especiais).
• TypeScript / JavaScript: Embora não possua um SMT solver nativo no compilador, o uso de Branded Types (Nominal Typing via interseção { __brand: 'PositiveNumber' }) combinado com Zod e fast-check simula a barreira arquitetural dos tipos de refinamento com perfeição.
• Linguagens Dedicadas à Engenharia Verificada: Dafny, usado fortemente pela AWS para verificar motores de autorização como o Cedar e sistemas criptográficos, compilando direto para Python, Go, C# e Java; e Ada / SPARK (padrão da indústria aeroespacial e ferroviária).

Quando Usar e Quando Não Usar

Assim como nos testes de propriedade e nas provas formais completas, o segredo está na alocação cirúrgica de esforço:

Onde Refinement Types e DbC brilham:

• Prevenção de Erros Aritméticos e de Limites: Divisão por zero, overflow/underflow numérico, índices de arrays fora do limite (IndexOutOfBounds) e fatiamento de matrizes/tensores.
• Modelagem de Domínio Financeiro e Comercial: Garantir por construção que quantidades em estoque, preços, taxas de juros, markups e saldos respeitem limites matemáticos estritos sem espalhar ifs defensivos pelo código.
• Máquinas de Estado e Protocolos: Garantir via pré-condições que uma função faturar_pedido(p) só possa ser invocada se o estado de p for estritamente PedidoAprovado e com itens.length > 0.

Onde NÃO aplicar:

• Regras de Negócio com Semântica Externa (Não-Matemática): Um SMT Solver consegue provar que uma string tem tamanho maior que zero e segue um formato específico, mas não consegue provar matematicamente se um endereço de entrega existe no mundo real.
• Lógica Não-Linear Pesada: SMT Solvers são extremamente rápidos para aritmética linear (2x + 3y ≤ 10), mas podem sofrer timeouts (indecidibilidade prática) se você colocar polinômios de grau alto, funções trigonométricas ou hashes criptográficos dentro do predicado de refinamento.

Conclusão

Durante décadas, a verificação formal foi vista como um castelo de marfim: admirada de longe pela sua beleza matemática, mas considerada impraticável para quem precisa colocar software em produção toda semana. Design by Contract e Refinement Types derrubam esse muro.

Ao delegar o trabalho braçal da demonstração matemática para SMT Solvers (como o Z3) e ao restringir os tipos primitivos com predicados lógicos claros, nós mudamos a natureza do nosso ciclo de desenvolvimento. Deixamos de usar testes apenas para caçar bugs que nós mesmos permitimos existir nas assinaturas frouxas das funções e passamos a desenhar espaços de estados onde o bug sequer consegue compilar.

O caminho para o software livre de bugs não exige que todo programador se torne um doutor em teoria das categorias. Ele começa com um passo muito mais simples e poderoso: olhar para um int ou float na assinatura da sua função principal e declarar explicitamente qual é a verdade matemática que aquele dado carrega.

Referências

• Meyer, B. (1992). Applying “Design by Contract”. IEEE Computer, 25(10), 40–51.
• Hoare, C. A. R. (1969). An axiomatic basis for computer programming. Communications of the ACM, 12(10), 576–580.
• Vazou, N., Seidel, E. L., Jhala, R., Vytiniotis, D., & Peyton-Jones, S. (2014). Refinement Types for Haskell. ACM SIGPLAN Notices (ICFP ‘14), 49(9), 269–282.
• Lehmann, N., Geller, A. T., et al. (2023). Flux: Liquid Types for Rust. Proceedings of the ACM on Programming Languages, 7(PLDI), 1533–1557.
• De Moura, L., & Bjørner, N. (2008). Z3: An efficient SMT solver. Tools and Algorithms for the Construction and Analysis of Systems (TACAS), 337–340.
• King, A. (2019). Parse, don’t validate. Blog técnico (Lexi Lambda).

Como Refinement Types e Design by Contract Trazem a Verificação Formal para o Mundo Real was originally published in Data Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Por que não podemos confiar em testes baseados em exemplos

No final da década de 1960, Edsger W. Dijkstra cunhou uma das frases mais célebres — e desconfortáveis — da Ciência da Computação: “Testes de software podem ser usados para mostrar a presença de bugs, mas nunca para mostrar a sua ausência”. Meio século depois, a indústria de software continua presa a um paradoxo: escrevemos milhares de linhas de testes unitários tradicionais (example-based tests), alcançamos 95% de code coverage e, ainda assim, sistemas críticos colapsam em produção diante de um edge case não previsto.

O problema fundamental do teste baseado em exemplos é o viés cognitivo do autor. Quando um engenheiro escreve a função sort(lista) e em seguida escreve o teste assert sort([3, 1, 2]) == [1, 2, 3], o teste sofre exatamente das mesmas pontos cegos que a implementação. Testamos o "caminho feliz" e meia dúzia de casos de borda óbvios (lista vazia, elementos duplicados), mas deixamos descoberto um universo infinito de estados possíveis (NaN, overflows aritméticos, caracteres Unicode malformados, concorrência).

Se quisermos construir sistemas onde a inexistência de certas classes de bugs deixe de ser uma esperança e passe a ser uma propriedade arquitetural, precisamos repensar dois pilares: como validamos nosso código (Testes de Propriedade) e sob qual paradigma o construímos (Programação Orientada a Teoremas).

Engenharia de Software Agêntica

O Loop de Desenvolvimento Orientado à Corretude

Na engenharia de software tradicional, o ciclo de desenvolvimento frequentemente trata o teste como uma etapa burocrática pós-implementação. Na engenharia de alta confiabilidade, o desenvolvimento opera como um closed-loop feedback system, cujo objetivo é estreitar o espaço de estados inválidos até que ele convirja para zero.

Esse fluxo opera em três estágios contínuos:

      ┌──────────────────────────────────────────────────────────────┐
      │                                                              │
      ▼                                                              │
[1. Programação] ──► [2. Validação (PBT / Provas)] ──► [3. Correção] ┘
                                │
                                ▼ (Invariantes Satisfeitas / Q.E.D.)
                     [Código Livre da Classe de Bugs]

• 1. Programação (Definição de Contratos e Transformações): Em vez de apenas acoplar estado e comportamento, o foco está na assinatura de tipos e na transformação pura de dados (um princípio central em Data-Oriented e Functional Programming). O código é escrito tendo em mente quais propriedades matemáticas ele deve preservar.

Programação Orientada a Dados

• 2. Validação via Testes Robustos ou Verificação: O código é submetido a um oráculo. No nível estocástico, geradores massivos de entradas tentam violar as invariantes do sistema (Property-Based Testing). No nível formal, o verificador de tipos/provas (Type Checker / Proof Assistant) verifica se a implementação satisfaz a especificação lógica para todas as entradas possíveis.
• 3. Correção e Refinamento de Invariantes: Quando uma falha é detectada — seja por um contraexemplo reduzido (shrunk counterexample) no teste de propriedade, seja por uma obrigação de prova não resolvida no compilador — , o desenvolvedor não aplica apenas um if paliativo. Ele analisa a falha estrutural: O código violou a especificação ou a própria especificação estava incompleta?
• Repetição até a Convergência: O ciclo 1 -> 2 -> 3 se repete. A cada iteração, o espaço de busca de bugs é podado. O loop só termina quando o fuzzer/gerador é incapaz de encontrar contraexemplos após milhares de permutações ou quando o assistente de provas aceita o teorema (Q.E.D.).

Property-Based Testing (PBT)

Popularizado pela biblioteca QuickCheck em Haskell (criada por Koen Claessen e John Hughes em 2000) e hoje presente em praticamente todas as linguagens modernas (como Hypothesis em Python, fast-check em TypeScript/JavaScript e proptest em Rust), o Property-Based Testing muda a pergunta fundamental do teste.

Em vez de perguntar “Para a entrada X, a saída é Y?”, o PBT pergunta: “Para qualquer entrada válida x pertencente a um domínio 𝓓, a propriedade P(𝑓(x)) se mantém verdadeira?”

Isso aproxima o teste de software do método científico de Karl Popper: não tentamos provar que o código está certo com meia dúzia de exemplos confirmirmatórios; tentamos falsificar a hipótese de que o código está correto gerando centenas ou milhares de entradas adversariais.

A Anatomia de um Teste de Propriedade

Para substituir exemplos fixos por propriedades universais, utilizamos padrões de design de propriedades:

• Inversibilidade (Round-trip / Simetria): Se você serializa uma estrutura de dados para JSON/binário e a desserializa em seguida, deve obter exatamente o dado original:

∀x ∈ Dados, decode(encode(x)) = x

• Idempotência: Aplicar uma operação múltiplas vezes produz o mesmo resultado que aplicá-la uma única vez (ex.: ordenação, normalização de texto, filtros de limpeza):

∀ x, 𝑓(𝑓(x)) = 𝑓(x)

• Invariantes Estruturais: Certas métricas não devem ser alteradas pela transformação. Ao ordenar uma lista, o tamanho da lista de saída deve ser igual ao da entrada, o conjunto de elementos deve ser exatamente o mesmo (permutação) e para todo índice i, L[i] ≤ L[i+1].
• Oráculo de Teste (Differential Testing): Comparar uma implementação altamente otimizada, complexa ou paralela 𝑓fast(x) contra uma implementação de referência simples, porém sabidamente correta 𝑓naive(x):
• ∀ x, 𝑓fast(x) = 𝑓naive(x)

Shrinking ou Redução de Contraexemplos

Se um gerador aleatório descobre que a sua função de agregação financeira quebra com uma lista de 4.500 transações contendo floats extremos como [-1.4012984643e-45, 3.4028234e+38, ...], depurar esse erro manualmente seria um pesadelo.

É aqui que entra o Shrinking. Assim que o framework de PBT encontra uma entrada que viola a propriedade, ele interrompe a geração aleatória e inicia uma busca sistemática em árvore para simplificar o erro ao menor caso reprodutível possível. Ele remove elementos da lista, reduz números grandes para perto de zero e simplifica strings até encontrar a semente exata do bug — entregando no terminal algo limpo como:

Falsifying example: processar_transacoes([0.0, -0.0, nan])

O ciclo Programação -> Validação -> Correção ganha uma velocidade brutal porque o desenvolvedor não perde horas isolando o estado que causou a falha; a ferramenta entrega o diagnóstico cirúrgico.

Quando Testar Não é Suficiente

O Property-Based Testing reduz drasticamente a probabilidade de bugs, mas ainda opera no domínio probabilístico: se uma falha ocorre apenas quando um inteiro de 64 bits assume exatamente o valor 9007199254740993, a chance de um gerador estocástico sortear esse número específico é virtualmente nula.

E se pudéssemos testar todas as entradas possíveis — mesmo que o domínio seja infinito — em tempo de compilação? Essa é a premissa do Theorem-Oriented Programming (também conhecido como Proof-Oriented Programming ou Verified Programming), materializado em linguagens e assistentes de prova como Lean 4, Coq (Rocq), Agda, Idris 2, F*, Dafny e Bend2.

Tipos são Teoremas, Programas são Provas

A fundação teórica do TOP é o Isomorfismo de Curry-Howard, uma correspondência profunda entre a lógica matemática e a teoria de tipos computacional

Sob a lente desse isomorfismo, uma proposição ou teorema na lógica matemática corresponde diretamente a um tipo (A) na teoria de tipos, enquanto a prova dessa proposição é materializada por um programa ou valor (a : A) que habita esse tipo. A partir dessa base, os conectivos lógicos traduzem-se perfeitamente em estruturas computacionais: a implicação (A ⟹ B) equivale a um tipo função (A ⟶ B), a conjunção (A∧B) é representada por um tipo produto ou tupla ((A, B)), e a disjunção (A ∨ B) manifesta-se como um tipo soma ou tagged union (Either A B). Expandindo essa expressividade, o quantificador universal (∀ x : A, P(x)) é modelado por uma função dependente ((x : A) ⟶ P(x)), e uma proposição falsa (⊥) equivale ao tipo vazio (Empty ou Never) — um tipo desprovido de construtores e que, por definição, jamais pode ser instanciado.

Em linguagens tradicionais (como Python, Java ou mesmo Rust), o sistema de tipos é estático mas possui expressividade limitada: você pode dizer que uma função recebe List<Int>, mas não pode expressar no próprio tipo que a lista não está vazia ou que está ordenada.

No Theorem-Oriented Programming, utilizamos Tipos Dependentes (Dependent Types), ou seja, tipos que dependem de valores. Você pode definir o tipo Vect n a (um vetor de tamanho n contendo elementos do tipo a). A assinatura de uma função que concatena dois vetores passa a ser:

append: Vect n, α ⟶ Vect m, α ⟶ Vect (n + m), α

Se na sua implementação você esquecer um elemento ou duplicar um item, o código não falha em produção nem em um teste: ele não compila, pois o tipo resultante não será Vect (n + m),α.

Especificação + Implementação + Prova

No paradigma orientado a teoremas, o desenvolvimento deixa de ser apenas a escrita de algoritmos e passa a ser a construção conjunta do algoritmo e do certificado matemático de sua corretude. Veja como isso se parece conceitualmente (usando a sintaxe de Lean 4):

-- 1. Implementação: uma função simples que inverte uma lista
def inverter : List α → List α
  | []      => []
  | x :: xs => inverter xs ++ [x]

-- 2. Teorema (Especificação Formal): 
-- Para qualquer lista 'xs', inverter duas vezes retorna a própria lista 'xs'
theorem inverter_involucao (xs : List α) : inverter (inverter xs) = xs := by
  induction xs with
  | nil => rfl -- Caso base: lista vazia é trivial por reflexividade
  | cons x xs ih => 
    -- Passo indutivo: usa a hipótese de indução (ih) e propriedades de concatenação
    simp [inverter, ih]

Observe o que aconteceu acima: não executamos inverter para 1.000 listas aleatórias. Usamos indução estrutural para provar matematicamente que, para qualquer lista de qualquer tamanho (de zero ao infinito) e de qualquer tipo α, a propriedade de involução é 100% verdadeira. Não há espaço para edge cases.

A Pirâmide de Confiabilidade

Um erro comum ao conhecer métodos formais é achar que Theorem-Oriented Programming substitui Property-Based Testing, ou que é inviável aplicá-lo fora da academia. Na prática moderna de engenharia de software de alto nível, como no desenvolvimento do kernel Linux, compiladores como CompCert, protocolos criptográficos na AWS ou sistemas distribuídos, PBT e TOP trabalham em simbiose dentro do mesmo loop de desenvolvimento.

Provar um teorema falso é impossível — e tentar fazer isso em um assistente de provas pode custar horas de frustração até o engenheiro perceber que o seu enunciado tinha uma falha sutil para o caso x = 0. Por isso, o estado da arte do loop Programação -> Validação -> Correção combina ambos.

Essas três abordagens distribuem-se ao longo de um espectro claro de mecanismo, cobertura, custo cognitivo e papel estratégico dentro do loop de desenvolvimento. Na base, os testes baseados em exemplos operam por meio de asserções manuais pontuais, oferecendo um escopo de cobertura O(1) restrito a alguns pontos discretos; em contrapartida, exigem baixo custo cognitivo e de tempo, cumprindo o papel de documentação viva e barreira rápida contra regressões. Em um degrau intermediário, o Property-Based Testing (PBT) utiliza geração estocástica aliada a shrinking para expandir a cobertura a O(N) (amostrando milhares de pontos do domínio ), o que demanda um custo cognitivo médio por exigir que o desenvolvedor pense em invariantes universais, atuando no loop como um motor de descoberta rápida de edge cases e falsificação de hipóteses. No topo do rigor, o Theorem-Oriented Programming (TOP) substitui a amostragem pela verificação formal e prova indutiva para atingir uma cobertura exaustiva e infinita (∀x); embora imponha um alto custo cognitivo e de tempo devido à necessidade de modelagem lógica e indução matemática, ele entrega a garantia absoluta indispensável para blindar o core algorítmico e crítico do sistema.

Dica de Ouro (Proof Engineering): Ferramentas modernas como QuickChick (para Coq) e Plausible (para Lean 4) executam Property-Based Testing antes que você tente escrever uma prova formal. Você enuncia o teorema e roda o PBT: se houver um bug na sua lógica, o gerador encontra um contraexemplo em milissegundos. Só quando o PBT passa sem encontrar falhas é que você investe tempo escrevendo a prova matemática formal.

Outras Técnicas Complementares

Para enriquecer ainda a robustez do processo de engenharia de software e a arquitetura de qualidade de um projeto real, vale destacar três degraus intermediários entre o PBT e a prova formal completa:

• Design by Contract (DbC) e Refinement Types: Linguagens e ferramentas como LiquidHaskell, Dafny ou Kani/Creusot (para Rust) permitem anotar funções com pré-condições (requires), pós-condições (ensures) e invariantes de loop. Em vez de o programador escrever a prova manualmente, o compilador delega a verificação para um SMT Solver (como o Z3), que resolve as equações lógicas automaticamente nos bastidores.
• Coverage-Guided Fuzzing: Enquanto o PBT gera entradas baseadas na estrutura dos tipos de dados, fuzzers guiados por cobertura (como AFL++, libFuzzer ou Atheris) instrumentam o código compilado para monitorar quais ramos (if/else) foram ativados. Se uma mutação na entrada descobre um novo caminho de execução nunca antes visitado, o fuzzer prioriza mutações a partir daquela entrada, explorando profundamente a máquina de estados do software.
• Model Checking (TLA+ / Alloy): Às vezes o código de cada função está perfeito, mas a interação concorrente ou distribuída entre três microsserviços gera um deadlock ou race condition. Especificações formais de arquitetura com TLA+ permitem testar o desenho do sistema antes mesmo de escrever a primeira linha de código em produção.

Quando Usar: Onde o Rigor Compensa o Custo

Adotar Property-Based Testing (PBT) e Theorem-Oriented Programming (TOP) exige um investimento cognitivo maior do que escrever testes de exemplo tradicionais. A regra de ouro da engenharia de confiabilidade é aplicar o rigor de forma proporcional ao raio de explosão (blast radius) de uma eventual falha.

Quando aplicar Property-Based Testing (PBT):

• Transformações Puras e Pipelines de Dados: Funções que filtram, agregam, normalizam ou transformam estruturas complexas sem depender de estado externo (o coração de arquiteturas orientadas a dados e funcionais).
• Pares de Serialização, Parsers e Compiladores: Qualquer operação que tenha uma inversa natural (JSON/Protobuf encode/decode, compressão/descompressão, criptografia, conversão de ASTs).
• Regras de Negócio Financeiras e Matemáticas: Motores de precificação, cálculo de margem de contribuição, rateio de descontos, impostos e algoritmos estatísticos onde erros de arredondamento de ponto flutuante (IEEE 754) ou edge cases numéricos geram prejuízo financeiro direto.
• Refatoração e Otimização de Performance: Ao substituir um algoritmo simples e lento por uma versão paralela, vetorizada ou altamente otimizada, usando a versão antiga como oráculo (Differential Testing).
• Máquinas de Estado Complexas (Stateful Testing): Sistemas de controle de estoque, filas de pedidos ou caches distribuídos, onde o bug não está em uma única chamada de função, mas em uma sequência específica de 15 operações intercaladas.

Quando aplicar Theorem-Oriented Programming (TOP) / Verificação Formal:

• Núcleo Crítico de Domínio (Verified Core): Quando uma falha é catastrófica, irreversível ou inaceitável — como protocolos criptográficos, smart contracts, kernels de sistemas operacionais, compiladores e sistemas aeroespaciais/médicos.
• Algoritmos Fundamentais e Estruturas de Dados Base: Bibliotecas internas que serão reutilizadas por centenas de outros serviços. Provar a corretude do componente base elimina uma classe inteira de bugs em toda a árvore de dependências.
• Invariantes de Segurança e Isolamento: Garantir matematicamente que um sistema multi-tenant nunca vaze dados de um cliente para outro, ou que uma árvore de permissões jamás conceda acesso indevido, independentemente da entrada.
• Validação de Modelos Simbólicos e Matemáticos: Sistemas que manipulam expressões algébricas, otimizadores de consulta (SQL/grafos) ou motores de inferência onde a equivalência semântica entre a entrada e a saída otimizada precisa ser garantida por construção.

Quando Não Usar: Evitando o Overengineering Formal

Tentar provar formalmente cada linha de código de um sistema comercial ou escrever geradores complexos de PBT para código trivial é a receita perfeita para paralisar a entrega de produto. O pragmatismo exige reconhecer onde essas ferramentas trazem retorno decrescente ou negativo.

Quando NÃO usar Property-Based Testing:

• Código “Cola” (Glue Code) e CRUDs Pass-Through: Endpoints que apenas recebem um payload HTTP, validam campos básicos e repassam diretamente para o banco de dados sem lógica de transformação intermediária. Testes de integração tradicionais resolvem isso com uma fração do esforço.
• Interfaces de Usuário (UI) e Layout Visual: Se o objetivo é verificar se um botão renderiza o texto correto ou se um modal abre ao clicar, testes baseados em exemplos (ou testes E2E pontuais) são muito mais claros e diretos.
• Falta de uma Propriedade Universal Clara (O “Acidente do Oráculo”): Se para testar a função 𝑓(x) com entradas aleatórias você acaba copiando e colando a própria implementação de 𝑓(x) dentro do teste para saber qual deveria ser o resultado, o seu teste de propriedade é apenas uma tautologia lenta.
• Integrações Pesadas de I/O Sem Isolamento: Como o PBT executa a mesma função de 100 a 10.000 vezes por teste, rodá-lo diretamente contra bancos de dados reais, sistemas de arquivos ou APIs de terceiros (sem separar o core funcional da camada de I/O) tornará sua esteira de CI/CD inviavelmente lenta.

Quando NÃO usar Theorem-Oriented Programming:

• Produtos em Fase de Descoberta (Product-Market Fit) e Requisitos Voláteis: Provas formais são extremamente rígidas. Se a regra de negócio muda toda semana após feedbacks de usuários, você passará 80% do tempo reescrevendo teoremas e consertando provas quebradas (proof maintenance) para especificações que serão descartadas na sprint seguinte.
• Fronteira Suja com o Mundo Real: O assistente de provas garante o que acontece dentro do modelo lógico, mas não pode provar que a rede não vai cair, que o usuário não vai fechar o navegador ou que uma API externa não vai mudar seu contrato JSON sem aviso prévio.
• Sistemas onde o Custo do Bug é Menor que o Custo da Prova: Se um bug em um relatório secundário pode ser corrigido em 10 minutos com um hotfix sem perdas graves, gastar três semanas provando formalmente a ausência de falhas naquele módulo é um erro econômico de alocação de engenharia.
• Equipes Sem Maturidade em Modelagem Funcional e Lógica: Tentar introduzir tipos dependentes ou assistentes de prova (como Lean ou Coq) em um time que ainda acopla regras de negócio a efeitos colaterais e mutação global gerará atrito severo. O caminho saudável é progressivo: primeiro isole o domínio com funções puras, depois adote Property-Based Testing e, por fim, aplique verificação formal cirurgicamente onde o risco justificar.

Conclusão

Erradicar bugs não é uma questão de escrever mais testes unitários repetitivos, mas de elevar a expressividade das nossas garantias. O ciclo contínuo de Programação ⟶ Validação ⟶ Correção só atinge seu potencial máximo quando a etapa de validação é mais inteligente do que as suposições iniciais do programador.

Adotar Property-Based Testing é o primeiro grande salto de maturidade: ele força você a parar de pensar em valores isolados e começar a pensar no domínio matemático, nas simetrias e nas invariantes do seu sistema. Já o Theorem-Oriented Programming representa a fronteira final da engenharia de software — onde a distinção entre especificação, código e teste desaparece, e o compilador deixa de ser um mero tradutor de sintaxe para se tornar um parceiro matemático que garante a solidez inabalável do que construímos.

Você não precisa reescrever toda a sua base de código em Lean ou Coq amanhã. Mas da próxima vez que for escrever um teste unitário com valores mágicos escolhidos a dedo, faça uma pausa e pergunte a si mesmo: “Qual é a propriedade universal que este código deve respeitar, não importa o que o mundo jogue contra ele?” Essa simples mudança de mentalidade é o que separa o código que funciona por acaso do software projetado para não falhar.

Referências

• Claessen, K., & Hughes, J. (2000). QuickCheck: a lightweight tool for random testing of Haskell programs. ACM SIGPLAN Notices (ICFP ‘00), 35(9), 268–279. (O artigo seminal que introduziu Property-Based Testing e geração orientada a tipos).
• MacIver, D. R., Hatfield-Dodds, Z., et al. (2019). Hypothesis: A new approach to property-based testing. Journal of Open Source Software, 4(43), 1891. (Detalha o algoritmo moderno de shrinking integrado à geração de dados).
• Wadler, P. (2015). Propositions as Types. Communications of the ACM, 58(12), 75–84. (Uma excelente revisão histórica e técnica sobre o Isomorfismo de Curry-Howard e como a lógica se conecta à computação).
• Moura, L. de, & Ullrich, S. (2021). The Lean 4 Theorem Prover and Programming Language. Automated Deduction — CADE 28, Lecture Notes in Computer Science, vol 12699. Springer. (Apresenta a arquitetura do Lean 4 como linguagem de programação de propósito geral e assistente de provas).
• Pierce, B. C., et al. (2024). Software Foundations (Volumes 1–6). Electronic textbook. Disponível em: [https://softwarefoundations.cis.upenn.edu/](https://softwarefoundations.cis.upenn.edu/). (A principal referência prática sobre verificação formal, provas indutivas e QuickChick).
• Leino, K. R. M. (2023). Program Proofs. MIT Press. (Aborda a transição prática do código imperativo/funcional para programas verificados usando invariantes de loop e SMT solvers).

Tipos são Teoremas, Programas são Provas was originally published in Data Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Por mais de cinco décadas a engenharia de software operou sobre uma premissa imutável: humanos decompõem problemas, traduzem regras de decisão em código-fonte estático e realizam a manutenção manual desse código à medida que o mundo muda.

Ao longo dos anos, refinamos os processos: migramos do Waterfall para o Agile, de monólitos para microsserviços, de deploys manuais para pipelines automatizados de CI/CD. Contudo, a mecânica fundamental permaneceu intocada: o código-fonte sempre foi o repositório perene das decisões tomadas por um desenvolvedor.

A popularização que aconteceu nos ultimos anos dos agentes autônomos baseados em Large Language Models (LLMs) não é apenas mais uma iteração de ferramentas como autocompletar código no VS Code. Estamos diante do nascimento da Engenharia de Software Agêntica ou Agentic Software Engineering (ASE). Um novo paradigma onde o código deixa de ser o sistema e passa a ser apenas um instrumento efêmero de raciocínio.

1. O Teto da Complexidade Essencial

No clássico ensaio The Mythical Man-Month, Fred Brooks dividiu a complexidade dos sistemas em duas vertentes: complexidade acidental e complexidade essencial. A complexidade acidental são as dificuldades impostas pelas linguagens, compiladores e infraestrutura. Já a complexidade essencial, são as dificuldades inerentes à própria natureza do problema a ser resolvido.

Nas últimas décadas, a indústria eliminou vastas camadas de complexidade acidental. Porém, a complexidade essencial permaneceu um gargalo intratável: em um sistema com n componentes com possíveis interações mútuas, o espaço de estados e topologias possíveis escala a uma ordem assintótica de Θ(2^n²). Enquanto isso, a capacidade cognitiva do cérebro humano para processar essas interações permanece constante (O(1)).

Tradicionalmente, respondemos a isso através de decomposição hierárquica, interfaces modulares e encapsulamento. Essas técnicas reduzem o fator constante, mas não mudam a curva assintótica.

Formalmente, um sistema tradicional de software pode ser definido por uma tupla S = (C, D, E):

• C: Recursos computacionais (CPU, memória, I/O).
• D: Regras de decisão determinísticas codificadas no código-fonte.
• E: Ambiente de execução.

O gargalo fundamental está no conjunto D: toda a lógica precisa ser concebida e gravada estaticamente por humanos antes de qualquer execução. Qualquer mudança ambiental ou novo caso de borda exige que um humano compreenda o sistema, localize D, altere a lógica sem introduzir regressões e revalide todo o artefato.

2. O Colapso do Intermediário: de “AI → Software” para “Agent → Result”

A fase inicial da IA no desenvolvimento focou em aceleração pontual: usar LLMs para gerar trechos de código mais rápido dentro do ciclo clássico de vida do software. Denotamos isso como o pipeline:

IA ⟶ Software (Código Estático) ⟶ Resultado

Essa abordagem carrega três fraquezas estruturais:

1. Gargalo Humano Contínuo: O engenheiro continua no caminho crítico para cada decisão de arquitetura, merge e testes.
2. Teto de Complexidade Intacto: O produto final ainda é um repositório rígido de código D, cuja manutenção se torna paradoxalmente mais cara pelo volume de código gerado por IA.
3. Latência de Iteração: O fluxo completo (requisito ⟶ design ⟶ código ⟶ teste ⟶ deploy) continua limitado à velocidade de comunicação humana.

O Novo Fluxo: O Agente é o Software

A engenharia agêntica colapsa a distinção entre o software e sua execução:

Agente ⟶ Resultado

Em vez de construir um sistema estático intermediário, o agente opera como um sistema dinâmico unificado, formalizado pela tupla A = (M, 𝓣, ℳ, Π):

• M: Modelo de linguagem atuando como motor central de raciocínio.
• 𝓣: Conjunto de ferramentas executáveis (APIs, interpretadores, bases de dados).
• ℳ: Subsistema de memória (contexto de sessão, vetores de longo prazo e procedural).
• Π (Pi): Mecanismo de planejamento autônomo.

Em um sistema agêntico, o código gerado em tempo de execução não é o produto final — é apenas um artefato transitório gerado para resolver um subproblema e descartado em seguida.

O agente escreve um script para consultar um endpoint, parsear um dado, validar uma hipótese, extrai o resultado necessário e descarta o script. O valor duradouro está na capacidade de orquestração e resolução de problemas, não nas linhas de código intermediárias.

3. Da Licença ao Agent-as-a-Service (AaaS)

A história da entrega de software é marcada pela transferência contínua de complexidade para longe do usuário final, seguindo o padrão de Geração ⟶ Mecanismo Central ⟶ Proprietário da Complexidade ⟶ Modelo de Negócio ⟶ Exemplos:

• Software 1.0 (Local) ⟶ Código + dados locais ⟶ Usuário Final responsável pela instalação, manutenção, patches ⟶ Venda de Licença ⟶ Microsoft, Oracle clássicos
• Software 2.0 (SaaS) ⟶ Código + dados em nuvem ⟶ Provedor responsável pela infraestrutura, escalabilidade, atualizações ⟶ Assinatura (MRR/ARR) ⟶ Salesforce, AWS
• Software 3.0 (AaaS) ⟶ Agentes operando de ponta a ponta na nuvem ⟶ O Agente é responsável pelo entendimento, planejamento e execução ⟶ Baseado em Resultados (Outcome-based) ⟶OpenAI, Anthropic, ecossistemas ASE

O SaaS liberou os negócios da gestão física de servidores. O modelo Agent-as-a-Service (AaaS) os liberta da necessidade de especificar minuciosamente o como computacional: basta articular claramente o o quê (a intenção).

4. O Choque de Realidade: A Falha na Evolução Contínua

Apesar do entusiasmo, a transição para a autonomia completa não ocorre sem atritos. A diferença entre tarefas pontuais e sistemas contínuos ficou evidente com o benchmark EvoClaw (2026):

• Em tarefas pontuais e isoladas de resolução de problemas (como no SWE-bench Verified), agentes conseguem taxas de sucesso elevadas (> 80%).
• Quando submetidos a cenários de evolução contínua — onde o agente precisa aplicar mudanças ao longo de um histórico progressivo de commits sem quebrar invariantes de longo prazo — , a taxa de sucesso desaba para no máximo 38% (uma queda de mais de 50%).

Os 4 Desafios Centrais da ASE:

1. Deriva de Contexto (Context Drift): À medida que o histórico de alterações cresce, o agente perde a visão sistêmica das invariantes globais da aplicação.
2. Propagação de Falhas em Cascata: Pequenos erros introduzidos em iterações iniciais acumulam-se de forma multiplicativa em commits posteriores.
3. Débito Técnico: Agentes otimizam para o sucesso do teste imediato, sem avaliar a longo prazo o acoplamento ou a manutenibilidade do design gerado.
4. Fidelidade de Verificação: A suíte de testes raramente é completa; agentes frequentemente produzem soluções que passam nos testes existentes, mas introduzem erros semânticos sutis em situações não testadas.

5. A Nova Função do Engenheiro: De Digitador a Arquiteto de Intenção

A ascensão da engenharia agêntica não extingue o engenheiro; ela desloca o centro de gravidade da disciplina:

• Engenharia de Intenção (Intent Architecture): Capacidade de articular requisitos, restrições e casos de borda com precisão suficiente para que enxames agênticos operem sem alucinações ou desvios.
• Orquestração Multi-Agente: Desenhar fluxos onde papéis especializados (Product Manager, Arquiteto, Engenheiro, Auditor de Qualidade) colaboram usando memória procedural compartilhada.
• Desenvolvimento Guiado por Avaliação (Eval-Driven Engineering): Projetar os frameworks de teste, observabilidade e pontuação semântica necessários para guiar a autocorreção dos agentes.
• Governança Ética e Segurança: Assegurar que os artefatos e desfechos respeitem diretrizes corporativas, conformidade regulatória e boas práticas de arquitetura.

Conclusão

A emergência dos agentes de inteligência artificial não representa um atalho para desenvolvedores digitarem mais linhas de código por hora, mas uma reestruturação de primeiros princípios sobre o que o próprio software significa.

Ao desacoplar a resolução de problemas dos limites cognitivos humanos e transferir a geração da lógica de decisão para tempo de execução, a engenharia de software expande substancialmente sua fronteira do que é economicamente viável construir e manter.

Embora o desafio da evolução contínua e da preservação de integridade sistêmica mostre que a autonomia irrestrita ainda demanda maturação, o papel do desenvolvedor já está sendo redefinido: o futuro não pertence a quem digita código mais rápido, mas a quem sabe orquestrar agentes e desenhar intenções com rigor arquitetural.

Referências

• Cao, Z. (2026). Agentic Software: How AI Agents Are Restructuring the Software Paradigm. arXiv preprint arXiv:2606.05608v2 [cs.SE].
• Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
• Deng, G. et al. (2026). EvoClaw: Evaluating AI Agents on Continuous Software Evolution. arXiv preprint arXiv:2603.13428.
• Karpathy, A. (2017). Software 2.0. Medium.
• Kumar, R., & Ramagopal, P. (2026). Agentic Engineering: How Swarms of AI Agents Are Redefining Software Engineering. LangChain Blog.
• Wang, Y. et al. (2024). Agents in Software Engineering: Survey, Landscape, and Vision. arXiv preprint arXiv:2409.09030.

Engenharia de Software Agêntica was originally published in Data Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Há algumas semanas, conheci e comecei a ler sobre High Performance Computing (HPC) ou Computação de Alta Performance. No seu sentido tradicional, HPC refere-se ao uso de supercomputadores e clusters de processamento paralelo para resolver problemas computacionais extremamente complexos e intensivos em dados. Suas aplicações vão desde simulações astrofísicas e previsão meteorológica até modelagem molecular na medicina e treinamento de grandes modelos de inteligência artificial.

Inspirado por esse conceito, decidi pesquisar como trazer essa mesma mentalidade de ganho extremo de desempenho para o meu contexto do dia a dia: o de um cientista de dados que utiliza Python como principal ferramenta.

Apesar de Python ser mundialmente aclamado por sua simplicidade e expressividade, a linguagem traz o estigma histórico de ser “lenta” (que na verdade é skill issue). E encontrei duas obras fundamentais que provam o contrário e abordam o tema por ângulos complementares: os livros de Tiago Rodrigues [1] e de Micha Gorelick & Ian Ozsvald [2].

Neste artigo, vamos explorar como extrair o desempenho máximo do Python dividindo a análise nas seguintes partes:

1. Otimização de performance do ponto de vista do hardware (Micha Gorelick & Ian Ozsvald)
2. Otimização de performance do ponto de vista do código e dados (Tiago Rodrigues)
3. Os quatro pontos de interseção entre as duas obras
4. Matriz de divergência e escopo prático
5. Quando usar cada abordagem
6. Quando NÃO usar (cuidados e armadilhas)
7. Conclusão

1. Otimização sob a Ótica do Hardware (Gorelick & Ozsvald)

A filosofia de Gorelick e Ozsvald baseia-se na premissa de que não é possível otimizar o que não se compreende no nível físico. Para extrair o desempenho máximo do Python, o desenvolvedor precisa enxergar o código não como uma abstração de alto nível, mas como instruções que interagem diretamente com a arquitetura do computador — CPU, hierarquia de memória e sistema operacional.

Abaixo estão os pilares centrais e ensinamentos práticos extraídos da obra:

A. Compreensão da Arquitetura de Hardware e do Interpretador

• Entendimento dos Gargalos de CPU e Memória: O livro ensina a identificar se um código é CPU-bound (limitado pela taxa de clock e número de ciclos da CPU) ou I/O-bound / Memory-bound (limitado pela velocidade de transferência do barramento de memória, rede ou disco).
• Hierarquia de Caches (L1/L2/L3): Explica como o acesso aos registradores e caches da CPU é ordens de grandeza mais rápido do que a leitura da memória RAM. A ordenação eficiente de dados na memória garante o aproveitamento do cache line e previne o fenômeno de cache miss.
• Custo dos Objetos em CPython: Em CPython, qualquer tipo simples (como um inteiro int) não é um número puro, mas uma estrutura em C (PyObject) cheia de metadados, ponteiros e contadores de referência. Esse overhead reduz drasticamente a eficiência do uso do cache da CPU.

B. Profiling Rigoroso Antes de Qualquer Otimização

• Regra de Ouro (Medir, Não Adivinhar): A intuição humana costuma falhar em identificar onde o código gasta mais tempo. Otimizar sem medir resulta em código complexo sem ganhos reais.
• Medição de Tempo (CPU Profiling):

1. cProfile: Mapeia o tempo de execução e a quantidade de chamadas por função, ideal para encontrar os grandes "gargalos" do sistema.
2. line_profiler: Executa uma análise linha por linha dentro das funções críticas, revelando exatamente quais laços ou instruções consomem mais ciclos de clock.

• Medição de Memória (Memory Profiling):

1. memory_profiler: Monitora o uso e a alocação de RAM linha por linha no decorrer do tempo.
2. tracemalloc: Identifica vazamentos de memória (memory leaks) e mapeia quais objetos Python estão ocupando o heap.

C. Eficiência de Memória e Estruturas de Dados

• Uso de __slots__ em Classes: Ao definir __slots__ em uma classe Python, descarta-se o dicionário interno dinâmico (__dict__) associado a cada instância. Isso reduz drasticamente a pegada de memória ao instanciar milhões de objetos.
• Vetorização com Arrays Nativos e NumPy: Substituir listas do Python por arrays do módulo array nativo ou matrizes do NumPy. Essas estruturas armazenam os dados em blocos de memória contíguos em formato C, eliminando o overhead do PyObject e permitindo instruções SIMD (Single Instruction, Multiple Data).
• Uso de Geradores e Iteradores: Preferir geradores (yield) e iteradores a listas completas quando o processamento for sequencial, garantindo consumo de memória $O(1)$ em vez de $O(N)$.

D. Compilação para Código de Máquina Nativo

• Cython (Compilação Estática): Traduz o código Python anotado com tipos estáticos (C-types) para código C nativo. Ao eliminar as chamadas dinâmicas do interpretador CPython dentro de laços críticos, atinge-se velocidades idênticas às de C/C++.
• Numba (Compilação JIT — Just-In-Time): Utiliza a infraestrutura LLVM para compilar funções Python e NumPy puras em código de máquina otimizado durante a execução, apenas decorando a função com @jit(nopython=True).
• PyPy (Interpretador Alternativo): Substituição direta da máquina virtual CPython pelo PyPy, que conta com um compilador JIT embutido, capaz de acelerar rotinas genéricas sem necessidade de reescrita de código.

E. Concorrência e Paralelismo para Contornar o GIL

• O Impacto do GIL (Global Interpreter Lock): O livro detalha como o GIL impede que múltiplas threads executem bytecode Python simultaneamente em múltiplos núcleos de CPU.
• Multiprocessing para CPU-Bound: Utilização do módulo multiprocessing (or ProcessPoolExecutor) para instanciar múltiplos processos CPython independentes, contornando o GIL e distribuindo a carga de trabalho entre todos os núcleos físicos da CPU.
• Threading e AsyncIO para I/O-Bound: Utilização de threading ou concorrência assíncrona baseada em loop de eventos (asyncio) para manipular dezenas de milhares de requisições de rede ou operações de disco simultâneas, liberando a CPU enquanto espera a resposta dos dispositivos de entrada/saída.

2. Otimização sob a Ótica do Código e Datasets (Tiago Rodrigues)

A perspectiva de Tiago Rodrigues parte de uma realidade prática enfrentada diariamente por cientistas e engenheiros de dados: o volume dos dados cresceu exponencialmente, mas a capacidade da memória RAM das máquinas locais continuou limitada. Para Rodrigues, a solução para a lentidão do Python não é tentar otimizar loops manualmente ou compilar pequenos trechos de funções, mas sim remodelar a arquitetura do pipeline de dados, delegando a execução pesada para motores modernos altamente eficientes.

Alguns ensinamentos fundamentais da obra são:

A. Troca de Motores de Processamento (Substituição Inteligente)

• Adoção do Polars e Apache Arrow: Substituição do tradicional Pandas pelo Polars (escrito em Rust e construído sobre o ecossistema Apache Arrow). O Polars utiliza formatos de memória colunar sem cópia (zero-copy), multithreading nativo por padrão e elimina a sobrecarga da GIL para operações de manipulação de tabelas.
• DuckDB como Motor OLAP Embutido: Uso do DuckDB como um banco de dados analítico vetorial que roda dentro do próprio processo Python. Ele permite executar consultas SQL de altíssima performance diretamente sobre arquivos CSV, Parquet ou tabelas na memória sem necessidade de subir um servidor de banco separado.

B. Avaliação Preguiçosa (Lazy Evaluation) e Otimização de Consultas

• Diferença entre Eager e Lazy Execution: Enquanto o Pandas processa cada comando imediatamente na memória (Eager), motores modernos como Polars e DuckDB permitem construir um plano lógico de execução (Lazy) que só é processado quando explicitamente solicitado (.collect()).
• Pushdown de Predicados e Projeções: Ao usar Lazy Evaluation, o motor inspeciona a consulta inteira antes de ler os dados. Se você precisa apenas de 3 colunas e filtrar por um estado específico em um arquivo de 50 GB, o motor faz o Projection Pushdown (lê apenas as 3 colunas necessárias) e o Predicate Pushdown (filtra as linhas na etapa de leitura no disco), evitando carregar gigabytes inúteis na RAM.

C. Estratégias Out-of-Core e Batching para Datasets Gigantes

• Superação do Limite Físico da RAM: Em vez de tentar carregar um dataset de 100 GB inteiro na memória de uma máquina de 16 GB (o que resulta em erros fatais de Out-Of-Memory), Rodrigues ensina técnicas para processar dados em blocos (chunks ou batches).
• Streaming & Spill-to-Disk: Motores como DuckDB e Polars conseguem redirecionar os dados temporários excedentes para o SSD (spill-to-disk) quando a RAM atinge a capacidade máxima, garantindo que pipelines de terabytes rodem até o final sem travar a aplicação.

D. Formatos de Armazenamento Colunar e Compressão

• Abandono Definitivo do CSV/JSON: Arquivos de texto como CSV e JSON são extremamente lentos para parsing, ocupam muito espaço e exigem varredura completa da linha para ler um único campo.
• Adoção de Formatos Colunares Modernos (Parquet, Arrow, Feather): O livro demonstra ganhos de até 10x a 50x em velocidade de leitura ao salvar dados em formatos binários colunares como o Apache Parquet. O formato colunar permite compressão agressiva por coluna (Snappy, ZSTD), preserva os tipos de dados originais e suporta leitura seletiva instantânea.

E. Computação Distribuída de Alto Nível

• Escalonamento Transparente com Dask e PySpark: Para volumes de dados que superam a capacidade de processamento de um único nó, Rodrigues explora o uso de frameworks distribuídos. O Dask permite estender a API do Pandas/NumPy para executar de forma totalmente transparente entre múltiplos núcleos ou clusters de máquinas locais e em nuvem.

3. Os Pontos de Interseção Entre as Abordagens

Embora sigam filosofias distintas — uma voltada para a mecânica do interpretador e do hardware, e outra para a eficiência de pipelines de dados — , os livros de Gorelick & Ozsvald e Tiago Rodrigues convergem em quatro grandes áreas temáticas. O ponto de encontro revela que, independentemente da ferramenta escolhida, a alta performance em Python sempre exige controle rígido de memória, aproveitamento de paralelismo, eliminação da interpretação pura e otimização do fluxo de I/O.

Abaixo, detalhamos ponto a ponto como os dois livros abordam e resolvem os mesmos quatro desafios fundamentais:

A. Gestão e Otimização de Memória RAM

A memória RAM é o gargalo mais comum tanto na execução de código algorítmico quanto no processamento de dados massivos. Ambas as obras tratam o esgotamento da RAM como a principal causa de degradação de desempenho em Python, mas atacam o problema sob primas complementares:

Foco em Volume e Limite Físico (Rodrigues):

• Estratégia Out-of-Core: Trata a memória como um recurso finito e restrito. O foco é garantir que um dataset de 100 GB consiga ser processado em uma máquina com apenas 16 GB de RAM.
• Mecanismos Práticos: Ensina a aplicar lazy evaluation (avaliação preguiçosa), processamento por lotes (batching / chunking) e carregamento sob demanda através de motores colunares para garantir que a taxa de uso da RAM permaneça estável durante todo o ciclo de vida do script.

Foco em Estrutura e Localidade na Memória (Gorelick & Ozsvald):

• Redução do Overhead de Estruturas: Trata a memória sob o ponto de vista da eficiência de acesso e da pegada dos objetos no heap. Demonstra detalhadamente o overhead de memória que o CPython impõe ao criar objetos dinâmicos como listas e dicionários.
• Mecanismos Práticos: Ensinam a utilizar __slots__ para descartar dicionários de instâncias, trocar listas genéricas por arrays contíguos de baixo nível (NumPy/array) e aplicar ferramentas de profiling (memory_profiler, tracemalloc) para detectar e mitigar memory leaks.

B. Paralelismo, Concorrência e Distribuição

Tanto para acelerar cálculos matemáticos quanto para agilizar a leitura de múltiplos arquivos, extrair o máximo do hardware exige usar múltiplos núcleos de processamento e contornar a limitação histórica do Global Interpreter Lock (GIL) do CPython:

Paralelismo Transparente em Pipelines (Rodrigues):

• Foco em Orquestração e Motores: Utiliza o paralelismo de alto nível integrado às próprias ferramentas do ecossistema moderno. O desenvolvedor não escreve código de gerenciamento de threads ou processos; em vez disso, utiliza bibliotecas construídas em Rust/C++ (como Polars) que vetorizam e paralelizam tarefas entre todos os núcleos de CPU automaticamente.
• Escala Vertical e Horizontal: Explora o uso de frameworks distribuídos como o Dask para fragmentar grafos de execução de DataFrames e distribuí-los entre múltiplos nós de um cluster na nuvem de maneira transparente.

Teoria e Prática da Concorrência Geral (Gorelick & Ozsvald):

• Foco no Controle de Baixo Nível: Realizam um estudo aprofundado dos diferentes modelos de concorrência disponibilizados pelo Python, fornecendo diretrizes claras sobre qual modelo escolher com base no tipo de gargalo.
• Cenários Distintos:

1. Para problemas CPU-bound (limitados por cálculo), ensinam a utilizar multiprocessing ou ProcessPoolExecutor para criar processos CPython isolados, contornando o GIL.
2. Para problemas I/O-bound (limitados por rede e disco), ensinam a implementar threading ou programação assíncrona orientada a eventos via asyncio.

C. Compilação e Otimização de Código

Ambas as obras concordam que a interpretação pura de bytecode pelo CPython é lenta demais para tarefas intensivas. A solução em ambos os casos é substituir a interpretação dinâmica por execução compilada nativa em C, C++ ou Rust:

Delegando a Compilação para Motores de Terceiros (Rodrigues ):

1. Substituição de Ferramental: O desenvolvedor Python não precisa escrever código compilado manualmente. A otimização ocorre ao adotar ferramentas modernas (Polars, DuckDB, Arrow) cujos núcleos de execução já foram pré-compilados em linguagens de baixíssimo nível (Rust e C++).
2. Otimização Automática de Consultas: O papel do desenvolvedor passa a ser o de construir pipelines e permitir que o compilador interno do motor (JIT ou otimizador SQL) reordene operações matematicamente para máxima eficiência.

Compilação Customizada de Algoritmos (Gorelick & Ozsvald):

• Compilação Manual de Funções: Ensinam o desenvolvedor a identificar laços (loops) lentos através de profiling e compilá-los diretamente para código de máquina nativo.
• Ferramentas de Compilação: Dedicam capítulos completos a:

1. Cython: Adiciona anotações de tipos C ao código Python para traduzi-lo e compilá-lo em C estático.
2. Numba: Aplica compilação JIT (Just-In-Time) baseada em LLVM diretamente sobre funções numéricas e arrays do NumPy com o simples uso de decoradores (@jit).
3. PyPy: Substitui a máquina virtual CPython pelo interpretador PyPy para obter ganhos imediatos via JIT em código Python legado sem necessidade de refatoração.

D. Armazenamento e Formatos de Dados

A movimentação de dados entre o disco, a memória e a CPU (I/O) é frequentemente a etapa mais lenta de qualquer aplicação. Ambas as obras reconhecem a urgência de substituir formatos de texto ineficientes por estratégias binárias otimizadas:

Formatos Colunares Inteligentes no Disco (Rodrigues):

• Revolução dos Formatos de Arquivo: Explora exaustivamente a transição dos formatos orientados a linha (como CSV e JSON) para formatos de armazenamento colunar (Parquet, ORC, Arrow).
• Impacto em Performance: Demonstra que a combinação de compressão por coluna (Snappy, ZSTD) com leitura seletiva reduz a carga de I/O em até 90%, acelerando brutalmente o tempo total do pipeline antes mesmo dos dados chegarem à CPU.

Persistência Rápida e Comunicação Inter-Processos (Gorelick & Ozsvald):

• Persistência e Serialização de Baixo Overhead: Encaram o armazenamento sob a ótica da serialização eficiente de estruturas de dados vivas na memória para transferência rápida ou persistência temporária.
• Ferramentas Práticas: Analisam o custo de serialização de bibliotecas como pickle, json, msgpack e protocólos de memória compartilhada, ensinando a minimizar o tempo gasto convertendo objetos Python para bytes durante a comunicação entre múltiplos processos (IPC).

4. O Ponto Onde Divergem: Matriz de Comparação e Análise de Escopo

Embora converjam nas grandes metas de desempenho, as duas obras divergem fundamentalmente na natureza do problema, no escopo de dados e na estratégia de solução. Compreender esse ponto de divergência é crucial para não aplicar o remédio certo para o problema errado.

A tabela abaixo sintetiza essa separação antes de detalharmos cada critério ponto a ponto:

1. Natureza do Gargalo Principal (I/O & RAM vs. CPU & Instruções)

• Rodrigues — Gargalo de Movimentação: O problema não é o processador ser lento para calcular, mas sim o sistema tentar mover dezenas ou centenas de gigabytes do disco para a RAM de uma só vez. O gargalo reside na banda de transferência de I/O, no parsing lento de arquivos de texto e na alocação excessiva de memória RAM.
• Gorelick & Ozsvald — Gargalo de Processamento: O problema é o número de ciclos de clock exigidos pela CPU para interpretar cada instrução Python dentro de laços de repetição densos. O gargalo reside no custo de dispatch dinâmico do CPython, na checagem de tipos em tempo de execução e na incapacidade da CPU de vetorizar laços Python puros.

2. Escopo e Tamanho dos Dados (Big Data Out-of-Core vs. Fit-In-RAM)

• Rodrigues — Volume Desproporcional ao Hardware: O tamanho do dataset ($N$) é significativamente maior do que a capacidade física da memória RAM disponível. A aplicação precisa operar obrigatoriamente no modo Out-of-Core, fragmentando o problema.
• Gorelick & Ozsvald — Alta Complexidade em Dados Ajustados: Os dados normalmente cabem com folga na memória RAM ($N \ll \text{RAM}$), mas o número de operações matemáticas executadas sobre cada elemento ($O(N²)$, $O(N³)$ ou simulações iterativas) exige velocidade computacional extrema por item.

3. Filosofia de Otimização (Troca de Abstrações vs. Reescrita e Compilação)

• Rodrigues — Otimização Arquitetural via Ecosistema: Não se gasta tempo reescrevendo código em C/Cython. A otimização ocorre trocando bibliotecas inteiras (ex: trocar Pandas por Polars, ou SQLite por DuckDB) e alterando a estrutura do arquivo em disco (trocar CSV por Parquet). O trabalho do desenvolvedor é ser um orquestrador de motores nativos.
• Gorelick & Ozsvald — Otimização de Código e Recompilação: Mão na massa no código-fonte. Mede-se cada linha com profilers, refatora-se a lógica de algoritmos, eliminam-se alocações desnecessárias, reescrevem-se loops críticos em Cython/C e configuram-se decoradores JIT do Numba.

4. Ecossistema Tecnológico Dominante (Motores Rust/C++ vs. CPython Internals)

• Rodrigues — A Nova Onda da Engenharia de Dados: Amparado pela nova safra de ferramentas desenvolvidas em Rust e C++ que encapsulam o Apache Arrow. O desenvolvedor Python atua na camada de interface, usufruindo da segurança e velocidade de linguagens de sistemas sem precisar programar nelas.
• Gorelick & Ozsvald — Ciência da Computação Clássica: Amparado nos fundamentos do interpretador CPython, estruturas de dados de baixo nível, bibliotecas C legadas e extensões diretas para a linguagem C e LLVM.

5. Guia Prático de Decisão: Quando Usar, Quando Evitar e Armadilhas de Otimização

Compreender as diferenças teóricas entre as abordagens de Tiago Rodrigues e de Gorelick & Ozsvald é apenas metade da jornada. No ambiente corporativo e acadêmico, o maior desafio é traduzir esses conceitos em decisões arquiteturais corretas, identificando exatamente quando acionar cada alavanca de desempenho e, mais importante, reconhecendo os momentos em que a tentativa de otimização se torna um desserviço ao projeto.

Saber quando não aplicar uma técnica de alta performance é tão vital quanto saber usá-la. Otimizações inadequadas introduzem complexidade desnecessária, elevam o débito técnico, dificultam a manutenção do código e, em cenários extremos, podem até tornar a aplicação mais lenta do que sua versão ingênua original.

Quando Adotar a Estratégia de Tiago Rodrigues (Engenharia de Dados & Pipelines)

A abordagem arquitetural de Rodrigues deve ser a sua primeira escolha sempre que o gargalo do sistema estiver associado ao volume de dados, contenção de memória RAM ou sobrecarga de I/O.

• Gargalos de Ingestão e Leitura: Se o seu script passa minutos travado logo na etapa inicial de carregamento de dados (como um pd.read_csv()), a causa raiz é o parsing textual e o consumo de disco. Migrar o armazenamento para Apache Parquet ou Feather e utilizar leitores colunares imediatamente reduz esse tempo para segundos.
• Estouro de Memória RAM (Out-of-Memory): Quando o volume de dados excede a capacidade física da máquina local — fazendo o sistema operacional apelar para swap de disco ou simplesmente quebrar com um erro de alocação — , a solução não é comprar mais RAM, mas sim reestruturar o pipeline. Aplicar Lazy Evaluation com Polars ou DuckDB permite executar queries analíticas complexas via streaming ou spill-to-disk, processando centenas de gigabytes em computadores convencionais.
• Modernização de Legacy Pipelines em Pandas: Se você mantém bases legadas com transformações e agregações em Pandas que demoram horas para rodar, a substituição direta pelo Polars oferece ganhos de desempenho de até 20x sem alterar a lógica de negócios, usufruindo de multithreading nativo e vetorização sem a interferência do GIL.

Quando Adotar a Estratégia de Gorelick & Ozsvald (Sistemas & Algoritmos de Baixo Nível)

A abordagem focada em hardware de Gorelick & Ozsvald torna-se indispensável quando a aplicação lida com lógica algorítmica pura, laços de repetição densos ou sistemas concorrentes de alta frequência.

• Lógica Customizada e Loops Matemáticos Inevitáveis: Se o seu problema exige iterar sobre milhões de elementos executando regras de negócio condicionais que não podem ser expressas em operações matriciais simples do NumPy, o CPython puro falhará. Nesse cenário, compilar as funções críticas com Numba JIT (@jit(nopython=True)) ou reescrevê-las em Cython aproxima a velocidade de execução à da linguagem C.
• Gargalos de Processamento Concorrente e I/O de Rede: Quando o sistema precisa lidar com dezenas de milhares de conexões simultâneas de API ou chamadas a serviços externos, a concorrência assíncrona com asyncio e aiohttp libera a CPU para outros trabalhos enquanto aguarda o retorno das redes, maximizando o throughput da aplicação.
• Gargalos de Memória por Proliferação de Objetos: Ao instanciar milhões de pequenos objetos Python customizados (por exemplo, em simulações de grafos ou sistemas de partículas), o overhead do dicionário interno de cada objeto consome gigabytes. A adoção de __slots__ ou a migração para structs e arrays contíguos elimina os metadados do PyObject, reduzindo a pegada de memória em até 80%.

Quando NÃO Otimizar: Cuidados, Armadilhas e Anti-Padrões

A tentação de aplicar ferramentas avançadas sem necessidade é uma das maiores armadilhas no desenvolvimento de software. A lista abaixo reúne os cenários em que tentar otimizar produz um efeito oposto ao desejado:

• Otimização Precoce (A Armadilha de Medir sem Profiling): Tentar otimizar trechos de código com base na intuição é uma das formas mais eficientes de desperdiçar tempo. Se o seu profiler (cProfile ou line_profiler) indicar que 95% do tempo de execução é gasto em uma chamada de rede ou em uma consulta ao banco de dados, compilar rotinas internas em Cython ou reorganizar laços no Python trará ganho zero no tempo total do processo.
• Reescrever Operações Vetorizadas que Já São Nativas: Tentar reescrever laços de multiplicação de matrizes ou transformações estatísticas usando Cython ou C manual é um erro quando bibliotecas como NumPy, PyTorch ou Scikit-Learn já estão disponíveis. Essas ferramentas executam código nativo em C, Fortran e CUDA altamente otimizado por décadas e ajustado para instruções SIMD da CPU.
• Introduzir Computação Distribuída para Datasets Pequenos: Adicionar frameworks distribuídos como Dask ou PySpark para manipular tabelas de poucas centenas de megabytes é um anti-padrão comum. O custo de inicializar o cluster, serializar os dados, gerenciar o Grafo Aclíclico Dirigido (DAG) e transferir pacotes via rede (overhead de coordenação) fará a execução rodar consideravelmente mais lenta do que um simples script Python de processo único rodando na memória local.
• Complexidade de Manutenção e Débito Técnico: Adotar compilação em C via Cython ou gerenciar multiprocessing manualmente aumenta exponencialmente a complexidade da base de código. Exige compiladores na esteira de CI/CD, dificulta a depuração de erros e exige profissionais com conhecimento em linguagens de baixo nível para dar manutenção. Se um ganho de 10% em tempo de execução custar o dobro do tempo de desenvolvimento da equipe, a otimização não se justifica financeiramente.

Conclusão

Extrair alta performance em Python não significa abandonar a linguagem ou migrar preventivamente todo o ecossistema para C++ ou Rust, mas sim compreender os limites físicos da máquina e saber exatamente qual “alavanca” acionar para cada perfil de gargalo.

Se o seu desafio diário está na escala de dados, no esgotamento da memória RAM e na lentidão de I/O, a arquitetura moderna de motores de alto nível, arquivos colunares e avaliação preguiçosa proposta por Tiago Rodrigues resolverá gargalos históricos de pipelines em questão de minutos.

Se o seu desafio está na eficiência computacional pura, na otimização de laços matemáticos densos ou no controle fino do interpretador, a engenharia de baixo nível, o profiling criterioso e a compilação customizada ensinados por Micha Gorelick e Ian Ozsvald transformarão o Python em uma linguagem de altíssima velocidade operacional.

A verdadeira mestria do Cientista e Engenheiro de Dados moderno consiste em não se prender a dogmas de ferramentas: é saber diagnosticar a origem exata do gargalo e transitar com elegância entre a engenharia de sistemas e a orquestração de dados.

Como Citar

Se este artigo te ajudou de alguma forma, você pode referenciá-lo como:

Guimarães, Alysson. (Ago 2026). Extraindo o máximo de performance do Python. https://medium.com/data-hackers/p-1f70b1f1a789

ou

@miscellaneous{guimaraes2026dop,
 title = {Extraindo o máximo de performance do Python},
 author = {Guimarães, Alysson},
 journal = {https://medium.com/data-hackers/},
 year = {2026},
 month = {Jun},
 url = {https://k3ybladewielder.medium.com/p-1f70b1f1a789}
}

Referências

• [1] Rodrigues, Tiago. Python — High performance techniques for large datasets. Manning Publications, 2023.
• [2] Gorelick, Micha; Ozsvald, Ian. High Performance Python: Practical Performant Programming for Humans. O’Reilly Media.

Extraindo o máximo de performance do Python was originally published in Data Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.

No seu livro, ele apresenta conceitos por meio de conversas e diálogos entre personagens em seu livro, também inclui trechos de código e diagramas para ajudar a entender os pontos positivos dessa abordagem.

Neste artigo, falaremos sobre a complexidade da orientação a objetos, as motivações por trás da criação do DOP e seus princípios.

Complexidade da Programação Orientada a Objetos

Se assim como eu, você não teve um background de uma graduação em computação (sistemas, ciência, engenharia, etc) em algum momento se deparou um orientação a objetos e inicialmente achou confuso. Mas se você teve esse background ou aprendeu por meio de cursos pela internet, há uma grande chance de ter sido ensinado que o mundo é um reflexo perfeito da Orientação a Objetos (OOP).

Sob a OOP, aprendemos que um Carro herda de Veículo, que possui um motor e métodos como acelerar.(). Na teoria, essa modelagem parece intuitiva, mas na prática e em sistemas de larga escala, essa modelagem muitas vezes se transforma em um pesadelo de manutenção. À medida que os sistemas crescem, a Orientação a Objetos manifesta uma tendência crônica de aumentar a complexidade do código, tornando-o rígido, difícil de testar e, ironicamente, complexo de entender.

O núcleo do problema está no princípio fundamental da OOP: o encapsulamento. Ensinam que agrupar dados (atributos) e comportamento (métodos) na mesma entidade — o objeto — é a chave para a organização. Mas, essa união entre dado e o seu comportamento cobra um custo altíssimo.

Quando misturamos código e dados, criamos entidades com estado mutável compartilhado. Imagine que um objeto Pedido possui uma lista de Itens e regras para calcular o desconto. Se múltiplos microsserviços ou threads possuem referências a esse mesmo objeto, rastrear quem, quando e por que um dado foi alterado torna-se um trabalho de detetive. O risco de efeitos colaterais indesejados (os famosos side effects) dispara, transformando a depuração em uma roleta russa de bugs intermitentes.

A promessa original de OOP era aproximar o código da realidade humana. O paradoxo é que ela alcançou o oposto. Entender a execução de um sistema puramente orientado a objetos exige um esforço cognitivo massivo por três motivos principais:

• A Teia de Relações: Para entender o comportamento de uma única classe, você frequentemente precisa navegar por uma árvore genealógica complexa de herança e dezenas de interfaces de injeção de dependência. O fluxo de dados não é linear; ele se espalha por uma teia invisível de objetos interconectados.
• Perda da Visão Geral: Em vez de focar no que o sistema faz com os dados de entrada para gerar uma saída, o desenvolvedor é forçado a focar em como gerenciar o ciclo de vida e a comunicação de instâncias de classes.
• A Riqueza Artificial: Modelar o mundo real em hierarquias estritas gera abstrações forçadas. O mundo real raramente se encaixa perfeitamente em árvores de herança IS-A (É UM) sem que você precise recorrer a gambiarras de design patterns para contornar a rigidez da própria linguagem.

Ao prender dados dentro de métodos, limitamos a flexibilidade. Os dados perdem sua pureza; eles não são mais apenas “fatos” sobre o sistema, mas sim reféns da implementação daquela classe específica. Se você precisar dos mesmos dados estruturados de uma forma ligeiramente diferente para outro caso de uso, a solução padrão de OOP é criar outra classe (um DTO) e um mapeador, adicionando ainda mais código boilerplate e complexidade acidental.

Precisamos de uma abordagem onde os dados sejam livres, previsíveis e transparentes. É exatamente nessa rachadura da fundação da Orientação a Objetos que o Data-Oriented Programming (DOP) se apoia, propondo uma separação radical, porém libertadora: dados de um lado, funções do outro.

Sob a ótica de um cientista de dados (meu caso), e para quem lida com pipelines de dados, o valor está na imutabilidade e na transparência: queremos dados puros, previsíveis e livres de efeitos colaterais, processados por funções transparentes (funções puras).

É exatamente aqui que o Data-Oriented Programming (DOP) brilha como uma ponte pragmática. Ao herdar as vantagens da programação funcional, o DOP trata dados como fatos estáticos e transformações como fluxos lineares.

Essa previsibilidade não é apenas uma conveniência de design, mas encontra respaldo na ciência da computação teórica através do Isomorfismo de Curry-Howard. Este princípio estabelece uma equivalência profunda entre sistemas de tipagem e lógica matemática: em linguagens tipadas, um tipo (ou assinatura de função) é um teorema, enquanto o código escrito para satisfazê-lo é a prova de que o teorema é verdadeiro. Ao desacoplar os dados dos métodos, o DOP nos permite formular e provar esses teoremas sobre o fluxo de dados do sistema com uma clareza que o emaranhado de estados mutáveis da OOP jamais conseguiria oferecer.

Por que um novo paradigma

A OOP foi consolidada em uma era onde os softwares eram, em sua maioria, monolíticos, síncronos e executados inteiramente na memória de uma única máquina (pense em sistemas desktop dos anos 90, com botões e janelas). Nesse cenário, encapsular o estado dentro de um objeto fazia sentido: o objeto nascia, mudava de estado na memória e morria ali.

O cenário atual, no entanto, é radicalmente diferente. Vivemos na era dos sistemas distribuídos e orientados a eventos. Hoje, um software passa 90% do seu tempo movendo dados de um lado para o outro: buscando JSON de uma API externa, transformando-o, salvando-o em um banco de dados relacional e postando uma mensagem em um tópico do Kafka.

Quando tentamos forçar o modelo mental da OOP nesse ecossistema, nos deparamos com três grandes barreiras motivacionais que impulsionaram a criação da DOP:

1. O Desastre do Mapeamento (O Efeito Platô)

Em sistemas modernos, o dado pertence ao mundo exterior, não ao programa. Quando você recebe um JSON de uma API e tenta “forçá-lo” a entrar em uma classe OOP cheia de métodos e encapsulamento, você cria uma fricção artificial. É o que a comunidade chama de impedance mismatch (incompatibilidade de impedância). Para remediar isso, criamos DTOs (Data Transfer Objects), entidades de ORM e conversores. Acabamos escrevendo montanhas de código boilerplate apenas para transformar dados puros em objetos e, logo em seguida, transformá-los de volta em JSON para enviá-los pela rede.

2. A Ilusão do Encapsulamento em Sistemas Multithread

A OOP protege o estado escondendo-o atrás de métodos privados. Mas em aplicações web modernas que lidam com concorrência e múltiplas threads acessando os mesmos dados simultaneamente, o estado mutável da OOP se torna perigoso. Para evitar que duas threads corrompam o mesmo objeto, os desenvolvedores precisam implementar travas complexas (mutexes e locks), o que degrada a performance e gera deadlocks. A DOP nasce da percepção de que se o dado for imutável, o encapsulamento se torna obsoleto. Não há nada a proteger se o dado não pode ser modificado.

3. Rigidez vs. Dinamismo do Mundo Real

Na OOP, a estrutura dos dados precisa ser rigidamente definida em tempo de compilação por meio de classes. Se uma API externa decide adicionar um campo novo ao payload, ou se você precisa extrair apenas três campos de um objeto complexo para gerar um relatório rápido, a OOP te força a criar novas interfaces ou heranças artificiais. A DOP foi motivada pela necessidade de flexibilidade: tratar dados através de estruturas genéricas (como mapas/dicionários e listas) permite que o sistema lide com a volatilidade dos dados do mundo real sem quebrar a cada pequena mudança de contrato.

Princípios da Programação Orientada a Dados

Para guiar os desenvolvedores na aplicação prática desse paradigma, Yehonathan Sharvit consolidou o Data-Oriented Programming em quatro princípios fundamentais. Longe de serem regras dogmáticas, esses pilares funcionam como diretrizes arquiteturais simples e integradas: o primeiro estabelece a separação radical entre código e dados; o segundo defende a representação desses dados por meio de estruturas genéricas (como mapas e listas); o terceiro introduz a imutabilidade para garantir a segurança do estado; e o quarto separa a validação de dados da sua representação, permitindo checagens flexíveis e contextuais. Juntos, esses princípios desatam os nós da complexidade acidental da OOP, criando sistemas previsíveis, altamente testáveis e perfeitamente alinhados com o fluxo de informações do mundo real.

Princípio 1: Separar código dos dados

A primeira ideia da DOP é ​​que podemos diminuir a complexidade de nossos sistemas separando o código dos dados. Quando o código é separado dos dados, nossos sistemas são compostos por duas partes principais que podem ser pensadas separadamente: entidades de dados e módulos de código.

O primeiro pilar do DOP ataca diretamente a fundação da Orientação a Objetos. Enquanto a OOP prega que dados e comportamentos devem viver sob o mesmo teto (a classe), o DOP exige uma separação: os dados devem ser apenas dados estruturados, e o código deve residir em funções puras e isoladas.

Na prática, isso significa que suas estruturas de dados não possuem métodos, e suas funções não guardam estado. Para entender o impacto dessa separação, vamos analisar um cenário clássico de e-commerce: o cálculo de desconto para um cliente VIP.

Em OOP, tendemos a criar uma classe Author ou Customer que envelopa as propriedades e expõe métodos para manipular ou ler esses dados. Veja como fica:

class Customer:
    def __init__(self, name: str, is_vip: bool, total_spent: float):
        self._name = name
        self._is_vip = is_vip
        self._total_spent = total_spent

    # O comportamento está "preso" dentro do objeto de dados
    def calculate_discount(self) -> float:
        if self._is_vip and self._total_spent > 500:
            return 0.15  # 15% de desconto
        return 0.05  # 5% de desconto

O problema nessa abordagem é que o método calculate_discount está rigidamente acoplado à classe Customer. Se amanhã você precisar calcular o desconto em um contexto de microsserviço que recebe apenas um payload JSON simplificado do banco de dados, você será obrigado a instanciar um objeto Customer artificialmente apenas para poder usar a função. Os dados viraram reféns do comportamento da classe.

No DOP, quebramos esse vínculo. Os dados são representados por uma estrutura simples e passiva (como um dicionário nativo ou uma dataclass sem métodos). O comportamento é movido para uma função pura externa.

from typing import TypedDict

# 1. Os dados são apenas dados (uma estrutura passiva)
class CustomerData(TypedDict):
    name: str
    is_vip: bool
    total_spent: float

# 2. O comportamento é uma função pura e isolada
def calculate_discount(customer: CustomerData) -> float:
    if customer["is_vip"] and customer["total_spent"] > 500:
        return 0.15
    return 0.05

Quando separamos o código dos dados, ganhamos três superpoderes imediatos:

1. Testabilidade Isolada: Para testar a função calculate_discount, você não precisa mockar um objeto complexo, gerenciar construtores ou se preocupar com efeitos colaterais na memória. Você passa um dicionário de entrada e espera um número de saída. É determinístico.
2. Reuso de Código: A função calculate_discount agora aceita qualquer mapa ou dicionário que contenha as chaves is_vip e total_spent. Se os dados vierem de um banco SQL, de um NoSQL ou de um evento do Kafka, a função funcionará da mesma forma, sem necessidade de conversores de classe complexos.
3. Redução do Custo Cognitivo: O desenvolvedor que está lendo a regra de negócio não precisa entender o ciclo de vida do objeto Customer. Ele só precisa ler uma função matemática linear: dados entram, cálculo acontece, resultado sai.

Princípio 2: Represente dados com estruturas genéricas de dados

O segundo princípio do DOP expande a liberdade que demos aos dados no primeiro pilar. Em OOP, quando precisamos representar um conceito do sistema, criamos uma classe específica para ele (uma classe Produto, uma classe CarrinhoDeCompras, etc.). No DOP, a diretriz é oposta: devemos representar dados através de estruturas genéricas e universais, como mapas (dicionários), listas (arrays) e conjuntos (sets).

Em vez de encapsular informações em tipos rígidos criados sob medida, usamos as estruturas que a própria linguagem já fornece nativamente.

Imagine que o seu sistema precisa lidar com os dados de um livro. Em OOP, você criaria uma classe dedicada:

class Book:
    def __init__(self, title: str, author: str, isbn: str):
        self.title = title
        self.author = author
        self.isbn = isbn

Se você precisar criar uma função genérica para serializar dados, inspecionar chaves ou sincronizar informações com um banco de dados, você terá que escrever um código que entenda especificamente a classe Book. Se o sistema tiver 300 classes diferentes, você precisará de adaptadores ou ferramentas complexas de reflexão (reflection) para lidar com a rigidez de cada uma delas.

No DOP, o livro é simplesmente um mapa de dados. Se estivermos usando uma linguagem com tipagem estática ou estrutural (como TypeScript ou o ecossistema de tipagem do Python), usamos definições de formato, mas a estrutura subjacente permanece genérica:

# O dado é apenas um mapa/dicionário comum
book = {
    "title": "Data-Oriented Programming",
    "author": "Yehonathan Sharvit",
    "isbn": "9781617298578"
}

Ao adotar estruturas genéricas, o seu software ganha uma flexibilidade que transforma a arquitetura:

1. Polimorfismo Genérico Inter-Sistemas: Como os dados são apenas mapas e listas, você pode usar as mesmas funções utilitárias (como filtros, mapeadores, ordenadores e serializadores) para qualquer entidade do sistema. Uma função que limpa strings nulas de um dicionário funcionará para um Book, para um Customer ou para qualquer novo payload que surgir no futuro.
2. Evolução de Sistemas sem Fricção: Se a equipe de infraestrutura decidir que a API agora precisa enviar um campo novo chamado published_year no payload do livro, o seu código DOP não quebra. O dicionário simplesmente aceita a nova chave. Em OOP, a ausência desse atributo na definição da classe dispararia erros de desserialização, exigindo que você alterasse a classe, recompilasse e implantasse o código novamente.
3. Casamento Perfeito com JSON e Bancos de Dados: O formato JSON, que domina a web, é fundamentalmente composto por mapas e listas. O DOP elimina a necessidade de camadas complexas de tradução. O dado que chega da rede é exatamente o dado que transita pelas suas funções puras, sem o peso de um ORM ou de mapeadores artificiais.

Princípio 3: Dados são imutáveis

Se você disser a um desenvolvedor OOP tradicional que os dados do sistema devem ser armazenados em dicionários genéricos e globais, o primeiro sinal de alerta que ele acenderá será: “Mas e se alguma função alterar esses dados por engano em outra parte do sistema?”. Esse medo é totalmente legítimo na OOP, onde o estado é mutável. No DOP, contudo, esse problema é mitigado pelo terceiro princípio: os dados nunca mudam.

Em vez de modificar uma estrutura de dados existente, as funções puras do DOP criam uma nova cópia dos dados com as alterações aplicadas. Os dados originais funcionam como fatos históricos invioláveis.

Em sistemas que compartilham referências de objetos mutáveis, um bug em um módulo pode corromper silenciosamente o comportamento de outro. Imagine o seguinte cenário:

# Cenário de mutação perigosa em OOP
class Cart:
    def __init__(self, items):
        self.items = items  # Uma lista mutável

my_cart = Cart(["Livro DOP", "Caneca"])

# Uma função de auditoria ou log recebe o carrinho e altera a lista por engano
def log_cart_contents(cart):
    # Efeito colateral: remove um item permanentemente sem o sistema saber
    cart.items.pop() 

log_cart_contents(my_cart)
print(my_cart.items)  # Saída: ['Livro DOP'] -> O dado foi corrompido!

Em sistemas assíncronos ou multithread, esse tipo de mutação gera condições de corrida (race conditions) estranhas e difíceis de reproduzir em ambiente de teste.

No DOP, os dados são tratados como registros imutáveis. Se precisamos atualizar o carrinho de compras, geramos um novo estado a partir do anterior. Muitas linguagens possuem suporte nativo a estruturas imutáveis (como as tuplas do Python ou objetos congelados), mas o conceito se aplica mesmo ao usar dicionários comuns, garantindo cópias estruturais superficiais (shallow copies):

# O dado original é tratado como um fato imutável
cart = {
    "items": ["Livro DOP", "Caneca"],
    "total": 120.00
}

# Em vez de modificar o 'cart' existente, criamos um NOVO 'cart'
def add_item(current_cart, new_item, price):
    return {
        **current_cart,
        "items": current_cart["items"] + [new_item],
        "total": current_cart["total"] + price
    }

new_cart = add_item(cart, "Caderno", 15.00)

print(cart["items"])     # Saída: ['Livro DOP', 'Caneca'] (Intacto!)
print(new_cart["items"]) # Saída: ['Livro DOP', 'Caneca', 'Caderno'] (Novo estado)

Por que a Imutabilidade é Libertadora?

1. Livre de Efeitos Colaterais (Side Effects): Você pode passar suas estruturas de dados para qualquer função, biblioteca de terceiros ou microsserviço sem medo. Ninguém pode alterar o seu estado local por acidente.
2. Concorrência Segura (Thread Safety): Como os dados não mudam, múltiplas threads ou processos podem ler o mesmo dicionário simultaneamente sem a necessidade de implementar travas complexas (locks ou mutexes), aumentando drasticamente a performance e a escalabilidade do sistema.
3. Rastreabilidade de Estado (Time-Travel Debugging): Como cada transformação gera um novo “print” dos dados, você consegue armazenar ou logar o histórico exato de transição de estados do sistema. Isso torna a depuração de fluxos complexos algo trivial.

Nota de Performance: Desenvolvedores costumam se preocupar com o custo de memória ao copiar dados continuamente. Na prática, linguagens puramente funcionais utilizam estruturas de dados persistentes com compartilhamento estrutural (apontando para referências comuns na memória para partes não alteradas), o que torna essas operações extremamente eficientes e baratas.

Princípio 4: Separe os esquemas de dados da representação de dados

Na Orientação a Objetos tradicional, a validação de dados está intrinsecamente ligada à criação do objeto. O construtor da classe atua como um guardião: se você tentar instanciar um objeto Usuario com um e-mail inválido, a classe lança uma exceção e impede a existência do objeto. No DOP, a abordagem é radicalmente diferente: os dados são aceitos em sua forma pura e flexível, e a validação é executada de forma isolada, apenas quando e onde for necessária.

Em vez de exigir que os dados sejam válidos para sempre e em qualquer lugar, o DOP entende que a “validade” de um dado é contextual.

Considere o seguinte cenário em OOP: para cadastrar um usuário no banco de dados, o e-mail e a senha são obrigatórios. Mas para uma tela de “Esqueci minha senha”, você só precisa do e-mail. Se a validação estiver presa no construtor da classe User, você terá problemas:

class User:
    def __init__(self, email: str, password: str):
        if not email or "@" not in email:
            raise ValueError("E-mail inválido")
        if not password or len(password) < 6:
            raise ValueError("Senha muito curta")
        self.email = email
        self.password = password

# Na tela de "Esqueci minha senha", onde não há password disponível:
# Você é forçado a passar uma string vazia ou um mock para burlar a própria classe.
invalid_context_user = User("usuario@email.com", "") # Dispara ValueError!

Para resolver isso em OOP, os desenvolvedores criam heranças complexas, múltiplas interfaces ou uma infinidade de DTOs específicos para cada etapa do fluxo.

No DOP, os dados trafegam livremente pelo sistema como mapas genéricos. Quando um módulo específico (como o controlador de uma API ou um serviço de persistência) precisa garantir que os dados seguem um formato específico, ele aplica um esquema de validação externo (usando ferramentas como JSON Schema, Zod em TypeScript, ou Pydantic/Schematics em Python).

from typing import Dict

# 1. OS DADOS SÃO APENAS FATOS (Sem comportamento ou travas rígidas)
# O payload transita como um dicionário nativo e puramente passivo.
# Ele não está "completo" para um cadastro, mas isso não impede sua existência no sistema.
user_data = {"email": "alysson@email.com"} 


# 2. VALIDAÇÃO CONTEXTUAL A (Fluxo de Recuperação de Senha)
# Para este caso de uso, o dicionário acima é perfeitamente válido, 
# pois precisamos apenas de um e-mail estruturado.
def validate_for_password_recovery(data: Dict) -> bool:
    return "email" in data and "@" in data["email"]


# 3. VALIDAÇÃO CONTEXTUAL B (Fluxo de Cadastro de Novo Usuário)
# Para este outro cenário, o mesmo dicionário seria considerado inválido.
# A regra de integridade pertence ao processo de negócio, não à estrutura do dado.
def validate_for_registration(data: Dict) -> bool:
    return "email" in data and "password" in data and len(data["password"]) >= 6


# 4. A VALIDAÇÃO ACONTECE "À LA CARTE"
# Em vez de estourar uma exceção no construtor de uma classe, o sistema interroga
# o dado baseando-se estritamente no momento atual da aplicação.
if validate_for_password_recovery(user_data):
    print("Dados válidos para recuperar senha!")
    
# Se tentássemos validar para registro, falharia pacificamente (retornando False),
# permitindo tratar o fluxo sem capturar exceptions complexas de infraestrutura.

As Vantagens da Validação Contextual:

1. Flexibilidade no Fluxo de Dados: Um payload de dados pode estar “incompleto” no início de um pipeline (por exemplo, enquanto passa por etapas de enriquecimento de dados) e só se tornar totalmente preenchido no final. O DOP permite que esses dados transitem livremente sem quebrar o sistema no meio do caminho.
2. Tratamento de Erros Amigável: Como a validação não interrompe a criação do dado por meio de exceções abruptas no construtor, você pode validar um formulário inteiro, coletar todos os erros contextuais e devolvê-los de uma só vez para o usuário de forma limpa.
3. Múltiplas Visões sobre o Mesmo Dado: O mesmo dicionário de dados pode ser considerado válido para ser salvo em um log de auditoria, mas inválido para processar um pagamento. Separar a validação permite que cada microsserviço ou módulo defina suas próprias réguas de integridade sem interferir no modelo de dados global.

Quando usar e quando não usar DOP

Depois de entender os quatro princípios, é fácil se empolgar e querer refatorar todo o código da sua empresa amanhã de manhã. Contudo, o Data-Oriented Programming não é uma bala de prata. Ele foi desenhado para resolver problemas específicos da engenharia de software moderna. Escolher entre DOP e OOP (ou qualquer outra abordagem) é uma questão de alinhar o paradigma à natureza do problema que você está resolvendo.

Como sempre, devemos analisar os trade-offs, para decidir quando adotar ou não DOP.

Quando o DOP brilha (Casos de Uso Ideais)

• Sistemas Baseados em Informação: Se a sua aplicação passa a maior parte do tempo movendo, transformando, enriquecendo e persistindo dados (APIs REST/GraphQL, microsserviços na nuvem, sistemas orientados a eventos).
• Pipelines e Ciência de Dados: Cenários onde o dado precisa passar por transformações lineares, agregações e análises estatísticas, e onde a mutabilidade seria um risco catastrófico para a consistência dos resultados.
• Aplicações com Alta Concorrência: Ambientes onde múltiplas threads, processos ou workers assíncronos precisam ler as mesmas informações simultaneamente. A imutabilidade do DOP elimina a necessidade de locks complexos.
• Sistemas Voláteis ou de Integração: Quando você consome dados de múltiplas APIs de terceiros cujos contratos mudam frequentemente. A flexibilidade das estruturas genéricas do DOP absorve essas mudanças sem quebrar o sistema.

Quando NÃO usar DOP (Onde OOP ou outros modelos ainda vencem)

• Sistemas de Simulação e Jogos: Se você está desenvolvendo uma engine física ou um jogo, onde entidades mudam de estado dezenas de vezes por segundo (como a coordenada x, y de um personagem), o custo computacional de gerar cópias imutáveis pode degradar a taxa de quadros (FPS). A mutabilidade controlada e o encapsulamento de OOP/ECS (Entity Component System) são muito mais eficientes aqui.
• Sistemas Operacionais e Drivers de Dispositivo: Aplicações de baixíssimo nível que operam coladas ao hardware precisam gerenciar a memória de forma cirúrgica. Mapear registradores e buffers de hardware funciona melhor com estruturas rígidas e ponteiros mutáveis.
• Componentes de Interface Gráfica (UI): Paradigmas de UI baseados em componentes (como botões, janelas e menus que retêm seu próprio estado de clique e foco) se alinham muito naturalmente com o encapsulamento clássico de OOP.
• Domínios Pequenos e Estáticos: Se o seu sistema é um CRUD simples, com regras de negócio que nunca mudam e pouca concorrência, o boilerplate de classes OOP clássicas pode ser mais do que suficiente e já está consolidado na sua equipe.

Conclusão

Ao longo deste artigo, fizemos uma jornada profunda pela forma como construímos software na atualidade. Começamos desmistificando a Orientação a Objetos, encarando de frente como o casamento forçado entre código e dados gera uma complexidade acidental crônica, além do alto esforço cognitivo exigido para gerenciar estados mutáveis compartilhados em sistemas de larga escala.

Vimos que as grandes motivações por trás do nascimento do Data-Oriented Programming (DOP) vieram da própria evolução da arquitetura de software: a transição para a nuvem, para sistemas distribuídos e orientados a eventos exigia um modelo mais flexível, seguro para concorrência e livre da fricção de mapeamentos artificiais.

Para resolver essas dores, exploramos os quatro princípios fundamentais propostos por Yehonathan Sharvit:

1. A separação radical entre código e dados, libertando as funções para serem puras e os dados para serem apenas fatos.
2. O uso de estruturas de dados genéricas, garantindo que o software flua com a flexibilidade do mundo real.
3. A imutabilidade como regra, erradicando os efeitos colaterais e blindando o sistema contra condições de corrida.
4. A validação contextual à la carte, permitindo que a integridade dos dados seja checada sob demanda, de acordo com o caso de uso.

Por fim, ponderamos que o DOP não veio para apagar o passado ou decretar a morte absoluta de OOP, mas sim para oferecer uma alternativa cirúrgica para sistemas cujo oxigênio é a informação.

Adotar o Data-Oriented Programming é, acima de tudo, uma mudança de perspectiva. É parar de tentar forçar a realidade a caber em hierarquias rígidas de classes e passar a enxergar o software como ele realmente é: um fluxo contínuo e previsível de dados sendo transformados. Da próxima vez que você se pegar lutando contra o estado de um objeto ou criando dezenas de DTOs e mapeadores, dê um passo para trás e lembre-se: separe o código dos dados, trate-os como fatos imutáveis e deixe que as funções façam o seu trabalho.

Se este artigo te ajudou de alguma forma, você pode referenciá-lo como:

Guimarães, Alysson. (Jun 2026). Programação Orientada a Dados. https://medium.com/data-hackers/p-140c3bdd1b0d

ou

@miscellaneous{guimaraes2026dop,
 title = {Programação Orientada a Dados},
 author = {Guimarães, Alysson},
 journal = {https://medium.com/data-hackers/},
 year = {2026},
 month = {Jun},
 url = {https://k3ybladewielder.medium.com/p-140c3bdd1b0d}
}

Referências

Y. Sharvit, Data-Oriented Programming, 1st ed., Manning Publications, Westborough, MA, 2022.

Programação Orientada a Dados was originally published in Data Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.

1 Introdução

Os algoritmos de Machine Learning (ML) supervisionados são um tipo de algoritmo que aprende a partir de dados rotulados, ou seja, dados que já possuem um rótulo ou uma classificação pré-definida. Esses algoritmos usam esses dados rotulados para aprender a fazer previsões ou classificações em novos dados.

Na área de Processamento de Linguagem Natural (NLP), os algoritmos de ML supervisionados são usados para uma variedade de tarefas, como classificação de texto (ex. sentimento), identificação de entidades nomeadas (NER), análise de tópicos, tradução automática, entre outras.

Um exemplo de como esses algoritmos são usados em NLP é na classificação de sentimentos em textos. Nesse caso, um modelo de ML supervisionado seria treinado em um conjunto de dados rotulados que contém textos e suas respectivas classificações de sentimento (por exemplo, positivo, negativo ou neutro). O algoritmo usaria esses dados para aprender a reconhecer padrões nos textos e, em seguida, aplicaria esses padrões para classificar o sentimento em novos textos. Outro exemplo é na identificação de entidades nomeadas (NER), como já supracitado, que é uma tarefa que envolve a identificação de nomes de pessoas, locais, organizações e outras entidades em um texto. Nesse caso, um modelo de ML supervisionado seria treinado em um conjunto de dados rotulados que contém textos e suas respectivas entidades nomeadas. O algoritmo usaria esses dados para aprender a reconhecer os padrões de palavras e contextos que indicam a presença de uma entidade nomeada em um texto, e, em seguida, aplicaria esses padrões para identificar entidades em novos textos.

Esses algoritmos são uma técnica poderosa para resolver problemas em NLP, permitindo que modelos aprendam com dados rotulados e possam fazer previsões ou classificações em novos dados com base no que foi aprendido.

Um pipeline básico para a task ou tarefa de análise de sentimento (classificação) geralmente envolve as etapas de:

• Pré-processamento de texto: Esta etapa envolve a limpeza e preparação dos dados. O texto é normalmente convertido em minúsculas, removidos caracteres especiais, removidos números e pontuações, e realizada a tokenização do texto para obter as palavras individuais.
• Criação de features: Nesta etapa, são criadas as features que serão usadas pelo modelo de classificação. As features podem incluir a contagem de palavras, a frequência de palavras, o tipo de palavras, o uso de negação, entre outras.
• Treinamento do modelo: O modelo de classificação é treinado em um conjunto de dados rotulados que contêm exemplos de texto e suas respectivas classificações de sentimento. Existem vários algoritmos de aprendizado de máquina que podem ser usados para treinar um modelo, como Árvores de Decisão, Naive Bayes, Regressão Logística, SVM, Redes Neurais, etc.
• Avaliação do modelo: Após o treinamento, o modelo é avaliado em um conjunto de dados de teste para verificar sua precisão. É comum dividir o conjunto de dados em conjunto de treinamento, validação e teste.
• Implementação/Deploy: Por fim, o modelo treinado é usado para classificar o sentimento de novos textos. Novos textos passam pelas mesmas etapas de pré-processamento e criação de features, e o modelo treinado é usado para prever a classificação de sentimento do texto.

Neste artigo, abordaremos alguns tópicos desse pipeline de tarefas de NLP, como Pré-processamento de texto, Criação de features, Treinamento e avaliação de modelos.

O artigo está organizado da seguinte forma: A seção 2 descreve como extrair features e realizar o preprocessamento de dados, na seção 3 são introduzidos os modelos de regressão logística e algoritmo naive bayes, e como aplicá-los na tarefa de classificação de texto para análise de sentimento. Na seção 4 são discutidos os Vector Space Models, como eles representam palavras e documentos e como construir matrizes de coocorrencia no formato word by word e word by document, como avaliar a similaridade de vetores com a distância euclidiana e similaridade de cosseno, como manipular palavras nos espaços vetoriais e o algoritmo Principal Component Analysis e como utilizá-lo. Por fim, Na seção 5 é apresentado a conclusão.

2 Vocabulary and Feature Extraction

Para representar textos de forma numérica, primeiro precisamos construir um vocabulário, com eles poderemos _encodar_ qualquer texto como um array de números. Um Vocabulário é uma lista com palavras únicas, não repetidas.

Uma forma simples de extrair features do texto é usando o vocabulário, verificando cada palavra do vocabulário que aparece no texto. Caso as palavras no texto que estamos extraindo a feature tenham apareca no vocabulário, atribuímos o valor 1 para ela, e zero para as palavras que do vocabulário que não aparecem no texto. Assim, estamos representando o texto usando one-hot encoding ou representação esparsa. Mas esse método pode ser problemático porquê o número de features é igual ao número de palavras no vocabulário e a grande maioria das features serão zero, aumentando excessivamente o tempo de treino e predição dos modelos.

Existem diversas técnicas para representar textos como vetores, sendo as mais comuns a Bag of Words (BoW) e a Representação Distribuída de Palavras (Word Embeddings). Vou explicar brevemente cada uma delas:

• Bag of Words (BoW): Nessa técnica, o texto é representado como um vetor contendo a contagem de ocorrências de cada palavra presente no texto. Cada palavra é considerada como uma dimensão do vetor. Dessa forma, quanto mais vezes uma palavra aparecer no texto, maior será o valor correspondente na dimensão correspondente no vetor. Por exemplo, se um texto contém as palavras “gato”, “cão” e “casa”, a representação BoW seria um vetor com três dimensões, com valores correspondentes à contagem de ocorrências de cada palavra no texto.
• Word Embeddings: Essa técnica é baseada em modelos de linguagem neural, que mapeiam cada palavra em um espaço vetorial de alta dimensão, onde palavras semelhantes têm representações próximas. A ideia é que cada palavra seja representada por um vetor de números reais que captura seu significado semântico. Esses vetores podem ser aprendidos a partir de grandes quantidades de textos usando técnicas de aprendizado de máquina, como Word2Vec, GloVe ou FastText. Os vetores resultantes podem ser usados para representar cada palavra em um texto como um vetor numérico. A representação distribuída de palavras pode capturar relações semânticas entre palavras, como sinonímia e antonímia, e pode ser usada para tarefas mais complexas, como análise de sentimento ou classificação de texto.

Ambas as técnicas são amplamente utilizadas em NLP, dependendo do objetivo e do contexto da tarefa em questão. A escolha da técnica de representação de texto pode influenciar significativamente o desempenho do modelo de aprendizado de máquina, e é importante escolher a técnica mais adequada para a tarefa específica.

Tanto a técnica de Bag of Words (BoW) quanto a Word Embeddings têm seus pontos fortes e fracos, e a escolha de qual usar depende do contexto e do objetivo da tarefa em questão.

A representação BoW pode ser uma escolha adequada para tarefas simples de classificação de texto, como classificação de spam ou análise de sentimento, onde a presença ou ausência de palavras específicas pode ser um indicador importante para a classificação. Além disso, a representação BoW é computacionalmente eficiente e fácil de interpretar, o que pode ser uma vantagem para problemas onde a transparência do modelo é importante. No entanto, a representação BoW não leva em consideração a ordem das palavras no texto, o que pode limitar sua capacidade de capturar nuances semânticas.

Já Word Embedding é mais adequada para tarefas que envolvem análise semântica, como tradução automática, classificação de tópicos ou análise de sentimento baseada em frases complexas. A representação Word Embedding leva em consideração a ordem e o contexto das palavras, e pode capturar a similaridade semântica entre palavras que não aparecem juntas com frequência. Além disso, a representação distribuída de palavras pode ser usada para inicializar redes neurais em tarefas de aprendizado profundo, melhorando o desempenho do modelo. No entanto, Word Embedding pode ser computacionalmente intensiva e requer grandes quantidades de dados de treinamento para obter bons resultados.

2.1 Feature Extraction with Frequencies

Numa task de classificação de textos (ex. sentimentos), podemos identificar as palavras positivas e negativas a partir da frequencia de ocorrencia em que elas ocorrem nos textos positivos e negativos. Usando essa contagem, podemos extrair features e usá-las no modelo de classificação, como a regressão logística.

A partir da contagem da frequencia das palavras em cada classe, chegamos a essa tabela. Na prática, essa tabela será um dicionário que mapeia a classe da palavra e sua frequência de ocorrência.

Podemos representar essa tabela de frequencia com um array com 3 features, aumentando a velocidade na implementação, porquê em vez de termos v features, teremos apenas 3 para que o modelo aprenda.

Aqui, a primeira feature é um bias, depois o somatório das palavras da label positiva e o somatório das palavras da label negativa. Assim, teremos o novo vetor com 3 features.

Podemos implementar essa extração de features com frequência de ocorrência de termos negativos ou positivos da seguinte forma:

import pandas as pd
import nltk
from nltk.tokenize import word_tokenize
from nltk.probability import FreqDist

positive_words = df[df["label"] == 0]["tweet"].to_list() # Lista de palavras positivas
positive_words = word_tokenize(' '.join(positive_words))

negative_words = df[df["label"] == 1]["tweet"].to_list()# Lista de palavras negativas
negative_words = word_tokenize(' '.join(negative_words))

# Função para mapear a frequência das palavras do subconjunto de palavras positivas (label = 0)
def positive_words_frequency(tweet):
    tokens = word_tokenize(tweet.lower())  # Tokenização e conversão para minúsculas
    freq = FreqDist(tokens)
    positive_freq = sum([freq[word] for word in positive_words])
    return positive_freq

# Função para mapear a frequência das palavras do subconjunto de palavras negativas (label = 1)
def negative_words_frequency(tweet):
    tokens = word_tokenize(tweet.lower())  # Tokenização e conversão para minúsculas
    freq = FreqDist(tokens)
    negative_freq = sum([freq[word] for word in negative_words])
    return negative_freq

# Aplicar as funções aos tweets e adicionar os resultados ao dataframe
df['bias'] = 1  # Coluna de bias com valor 1
df['pos_freq'] = df['tweet'].apply(positive_words_frequency)
df['neg_freq'] = df['tweet'].apply(negative_words_frequency)
df

2.2 Preprocessing

O pré-processamento para tarefas de NLP geralmente envolve as etapas de limpeza e preparação dos dados. O texto é normalmente convertido em minúsculas, removidos caracteres especiais, removidos números e pontuações, e realizada a tokenização do texto para obter as palavras individuais.

Exemplo em python:

import nltk
from nltk.corpus import stopwords
import string

nltk.download('stopwords')

def text_cleaning(text):
    # Extrai as stopwords em português
    stopwords_list = stopwords.words('portuguese')
    
    # Remove caracteres especiais
    text = text.translate(str.maketrans('', '', string.punctuation))
    
    # Remove números e minimiza
    text = ''.join(word for word in text if not word.isdigit()).lower()
    
    # Converte para minúsculo e tokeniza as palavras
    tokens = nltk.word_tokenize(text.lower())
    
    # Remove as stopwords
    tokens = [word for word in tokens if word not in stopwords_list]
    
    return tokens

# Exemplo de uso
text = "Este é um exemplo de texto que será limpo e tokenizado!"
tokens = text_cleaning(text)
print(tokens)

# Output
# ['exemplo', 'texto', 'limpo', 'tokenizado']

Agora, podemos aplicar a extração de features do exemplo acima com o texto tratado.

# preprocessando o texto
df["ttweet"] = df["tweet"].apply(text_cleaning)
df["ttweet"] = df["ttweet"].apply(lambda x: " ".join(x)) # retornando a lista como string

# novo conjunto de palavras
positive_words = df[df["label"] == 0]["ttweet"].to_list() # Lista de palavras positivas
positive_words = word_tokenize(' '.join(positive_words))

negative_words = df[df["label"] == 1]["ttweet"].to_list()# Lista de palavras negativas
negative_words = word_tokenize(' '.join(negative_words))

# Função para mapear a frequência das palavras do subconjunto de palavras positivas (label = 0)
def positive_words_frequency(tweet):
    tokens = word_tokenize(tweet.lower())  # Tokenização e conversão para minúsculas
    freq = FreqDist(tokens)
    positive_freq = sum([freq[word] for word in positive_words])
    return positive_freq

# Função para mapear a frequência das palavras do subconjunto de palavras negativas (label = 1)
def negative_words_frequency(tweet):
    tokens = word_tokenize(tweet.lower())  # Tokenização e conversão para minúsculas
    freq = FreqDist(tokens)
    negative_freq = sum([freq[word] for word in negative_words])
    return negative_freq

# Aplicar as funções aos tweets e adicionar os resultados ao dataframe
df['bias'] = 1  # Coluna de bias com valor 1
df['pos_freq'] = df['ttweet'].apply(positive_words_frequency)
df['neg_freq'] = df['ttweet'].apply(negative_words_frequency)
df.head(20)

Mas além disso também podemos fazer Stemming e lematização. Elas são técnicas de pré-processamento de texto com o objetivo de reduzir as palavras em sua forma base ou raiz, simplificando o processo de análise de texto.

O Stemming é um processo mais simples e rápido de normalização de palavras, que envolve a remoção de sufixos com o objetivo de transformar uma palavra em sua raiz, ou seja, em sua forma básica. Um exemplo de algoritmo de stemming é o Porter Stemmer, que é amplamente utilizado em NLP. O ponto positivo do stemming é sua simplicidade e velocidade de processamento, o que pode ser útil em projetos com grandes volumes de dados. No entanto, o stemming pode produzir algumas palavras raiz que não são facilmente reconhecidas, o que pode ser um problema em alguns casos.

Já a lematização é um processo mais complexo de normalização de palavras, que envolve a análise do contexto da palavra para determinar sua forma básica. A lematização utiliza um dicionário de palavras ou um algoritmo para mapear a palavra para sua forma base. O ponto positivo da lematização é que ela produz palavras que são facilmente reconhecíveis, o que pode ser importante em projetos que exigem maior precisão na análise de texto. No entanto, a lematização é um processo mais lento e computacionalmente mais caro do que o stemming, o que pode ser um problema em projetos com grandes volumes de dados.

Podemos implementar o stemming da seguinte forma:

import nltk
from nltk.corpus import stopwords
from nltk.stem import SnowballStemmer
import string

def text_cleaning_s(text):
    # Extrai as stopwords em português
    stopwords_list = stopwords.words('portuguese')
    
    # Remove caracteres especiais
    text = text.translate(str.maketrans('', '', string.punctuation))
    
    # Remove números e minimiza
    text = ''.join(word for word in text if not word.isdigit()).lower()
    
    # Converte para minúsculo e tokeniza as palavras
    tokens = nltk.word_tokenize(text.lower())
    
    # Remove as stopwords
    tokens = [word for word in tokens if word not in stopwords_list]
    
    # Realiza o stemming dos tokens
    stemmer = SnowballStemmer('portuguese')
    stemmed_tokens = [stemmer.stem(token) for token in tokens]
    
    return stemmed_tokens

# Exemplo de uso
text = "Este é um exemplo de texto que será limpo, tokenizado e stemmed!"
tokens = text_cleaning_s(text)
print(tokens)

# output
# ['exempl', 'text', 'limp', 'tokeniz', 'stemmed']

Enquanto que para lematização, podemos implementar da seguinte forma, apenas com pequenas alterações:

import nltk
from nltk.corpus import stopwords
from nltk.stem import WordNetLemmatizer
import string

nltk.download('wordnet')
nltk.download('omw-1.4')

def text_cleaning_l(text):
    # Extrai as stopwords em inglês
    stopwords_list = stopwords.words('english')
    
    # Remove caracteres especiais
    text = text.translate(str.maketrans('', '', string.punctuation))
    
    # Remove números e minimiza
    text = ''.join(word for word in text if not word.isdigit()).lower()
    
    # Converte para minúsculo e tokeniza as palavras
    tokens = nltk.word_tokenize(text.lower())
    
    # Remove as stopwords
    tokens = [word for word in tokens if word not in stopwords_list]
    
    # Realiza a lematização dos tokens
    lemmatizer = WordNetLemmatizer()
    lemmatized_tokens = [lemmatizer.lemmatize(token) for token in tokens]
    
    return lemmatized_tokens

3 Sentiment Analysis

Nesta seção falaremos sobre a tarefa de classificação de texto para analisar sentimentos utilizando os modelos Logistic Regression e Naive Bayes.

3.1 Sentiment Analysis With Logistic Regression

A regressão logística ou logistic regression é frequentemente utilizada em análise de sentimento porque é um algoritmo de classificação simples, rápido e eficiente para problemas de classificação binária, ou seja, quando há apenas duas classes, como positivo e negativo. Além disso, a regressão logística é facilmente interpretável, o que significa que é possível entender como o modelo chegou a uma determinada previsão.

Outra vantagem da regressão logística é que ela lida bem com problemas de dados desbalanceados, que é comum em análise de sentimento, onde muitas vezes há mais exemplos de uma classe do que outra. A regressão logística usa uma função sigmoide para calcular as probabilidades de cada classe, e essa função é bem adequada para casos de classes desbalanceadas.

Outro motivo para a popularidade da regressão logística em análise de sentimento é que ela é relativamente fácil de implementar e ajustar. É possível utilizar diferentes técnicas de regularização, como a regularização L1 ou L2, para evitar overfitting e melhorar o desempenho do modelo.

No entanto, é importante ressaltar que a regressão logística pode não ser adequada para problemas de classificação multiclasse, ou seja, quando há mais de duas classes, como em análise de tópicos. Nesses casos, outros algoritmos, como Árvores de Decisão, SVMs ou Redes Neurais, podem ser mais apropriados.

O modelo é treinado usando um conjunto de dados rotulados, onde cada texto é rotulado como tendo um sentimento positivo ou negativo. O objetivo do treinamento é ajustar os parâmetros do modelo para que ele possa fazer previsões precisas em novos dados.

Durante o treinamento, o modelo utiliza a função logística para calcular a probabilidade de um texto ter um sentimento positivo ou negativo com base em seus vetores de características. A função logística produz um valor entre 0 e 1, que representa a probabilidade de um texto ter um sentimento positivo. Por padrão, se a probabilidade for maior que 0,5, o modelo classifica o texto como tendo um sentimento positivo. Caso contrário, o texto é classificado como tendo um sentimento negativo. Além disso podemos ajustar o limiar de classificação do modelo.

Após o treinamento, o modelo pode ser usado para fazer previsões em novos dados. Para cada novo texto, o modelo converte-o em um vetor de características e utiliza a função logística para calcular a probabilidade de ter um sentimento positivo ou negativo. Em seguida, classifica o texto como tendo um sentimento positivo ou negativo com base no valor calculado.

Note que conforme 𝜃^T x^(i) se aproxima cada vez mais de -∞, o denominador da função sigmoidal fica cada vez maior e, como resultado, a sigmoidal se aproxima de 0. Por outro lado, conforme 𝜃^T x^(i) se aproxima cada vez mais de ∞, o denominador da função sigmoidal se aproxima de 1 e, como resultado, a sigmoidal também se aproxima de 1.

Dado um tweet, podemos transformá-lo em um vetor e passá-lo pela sua função sigmoidal para obter uma previsão da seguinte forma:

Agora, podemos comparar o desempenho do modelo com as duas estratégias de representação numérica de textos: A simples e da função text_cleaning_l definida acima, que remove caracteres especiais, stopwords e torna todas as palavras minúsculo.

Estratégia Simples:

from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report
from sklearn.metrics import accuracy_score, precision_score

# divisão em treino e teste
X = df[['bias', 'pos_freq', 'neg_freq']]
y = df['label']
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3, random_state=42)

# criação do modelo de regressão logística e treinamento
lr = LogisticRegression()
lr.fit(X_train, y_train)

# avaliação do modelo nos dados de teste
y_pred = lr.predict(X_test)

# avaliando o modelo
print("\n Classification Report: Estratégia Simples \n", classification_report(y_test, y_pred))

Com o pipeline de pré-processamento + Count Vectorizer:

from sklearn.feature_extraction.text import CountVectorizer
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report

# pré-processamento das frases
df['ttweet'] = df['tweet'].apply(text_cleaning_l)

# divisão em treino e teste
X_train, X_test, y_train, y_test = train_test_split(df['ttweet'], df['label'], test_size=0.3, random_state=42)

# vetorização das frases com CountVectorizer
vectorizer = CountVectorizer()
X_train_vec = vectorizer.fit_transform(X_train.apply(lambda tokens: ' '.join(tokens)).to_list())
X_test_vec = vectorizer.transform(X_test.apply(lambda tokens: ' '.join(tokens)).to_list())

# criação do modelo de regressão logística e treinamento
lr = LogisticRegression()
lr.fit(X_train_vec, y_train)

# avaliação do modelo nos dados de teste
y_pred = lr.predict(X_test_vec)

# avaliando o modelo
print("\n Classification Report: Pipeline de Pré-processamento + CountVectorizer \n", 
      classification_report(y_test, y_pred))

Com o pipeline de pré-processamento + TF-IDF:

from sklearn.feature_extraction.text import CountVectorizer
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report

# pré-processamento das frases
df['ttweet'] = df['tweet'].apply(text_cleaning_l)

# divisão em treino e teste
X_train, X_test, y_train, y_test = train_test_split(df['ttweet'], df['label'], test_size=0.3, random_state=42)

# vetorização das frases com CountVectorizer
vectorizer = TfidfVectorizer()
X_train_vec = vectorizer.fit_transform(X_train.apply(lambda tokens: ' '.join(tokens)).to_list())
X_test_vec = vectorizer.transform(X_test.apply(lambda tokens: ' '.join(tokens)).to_list())

# criação do modelo de regressão logística e treinamento
lr = LogisticRegression()
lr.fit(X_train_vec, y_train)

# avaliação do modelo nos dados de teste
y_pred = lr.predict(X_test_vec)

# avaliando o modelo
print("\n Classification Report: Pipeline de Pré-processamento +TF-IDF  \n", 
      classification_report(y_test, y_pred))

Nesse teste exemplo com fins didáticos, com um conjunto de dados sintético e pequeno o processamento simples teve uma melhor performace. Mas num cenário real provavelmente esse não seria o caso. Mas mesmo assim, precisamos partir de um baseline e ir aumentando a complexidade do modelo e criando novas features até que o desempenho do modelo seja adequado para o objetivo da task.

3.2 Sentiment Analysis with Naive Bayes

Recaptulando Probabilidade…

Antes de abordar o algoritmo Naive bayes, é preciso relembrar alguns conceitos de probabilidade. A probabilidade é uma medida numérica que quantifica a incerteza associada a um evento. Em termos simples, é a chance de que algo aconteça. A probabilidade de um evento é sempre um número entre 0 e 1, onde 0 indica impossibilidade absoluta do evento ocorrer e 1 indica certeza absoluta de que o evento ocorrerá.

Já a probabilidade condicional é a probabilidade de um evento ocorrer dado que outro evento já ocorreu. É denotada por $ P(A|B) $, que lê-se como “a probabilidade de A dado B”. A fórmula para calcular a probabilidade condicional é:

Onde:
 — P(A|B) é a probabilidade de A dado B,
 — P(A ∩ B) é a probabilidade da interseção de A e B,
 — P(B) é a probabilidade de B.

Em palavras simples, a probabilidade condicional é a proporção de vezes que o evento A ocorre quando o evento B ocorre.

Outro conceito importante a ser lembrado é a Regra de Bayes ou Bayes Rule. Ela é uma ferramenta fundamental na teoria das probabilidades que permite atualizar as probabilidades de uma hipótese à luz de novas evidências. Formalmente, a regra de Bayes é expressa como:

Onde:
 — P(A|B) é a probabilidade de A dado B (posterior),
 — P(B|A) é a probabilidade de B dado A (likelihood),
 — P(A) é a probabilidade de A (prior),
 — P(B) é a probabilidade de B.

A regra de Bayes nos permite calcular a probabilidade de uma hipótese (A) ser verdadeira dada uma evidência observada (B), usando a probabilidade da evidência dada a hipótese (likelihood), a probabilidade a priori da hipótese e a probabilidade marginal da evidência.A diferença principal entre a probabilidade condicional e a regra de Bayes é que a probabilidade condicional é uma medida da probabilidade de um evento ocorrer dado que outro evento já ocorreu, enquanto a regra de Bayes é uma ferramenta para atualizar a probabilidade de uma hipótese à luz de novas evidências. A regra de Bayes utiliza a probabilidade condicional como um de seus componentes para calcular a probabilidade posterior.

A probabilidade é a chance de um evento ocorrer, a probabilidade condicional é a probabilidade de um evento ocorrer dado que outro evento já ocorreu, e a regra de Bayes é uma ferramenta para atualizar a probabilidade de uma hipótese à luz de novas evidências. Baseado nesses conceitos, foi desenvolvido o algoritmo Naive Bayes.

O algoritmo Naive Bayes é um método de classificação probabilístico baseado no teorema de Bayes, com uma suposição “ingênua” de independência condicional entre os recursos.

1. Suposição de Independência Condicional: A primeira etapa do algoritmo Naive Bayes é a suposição de independência condicional entre os recursos. Isso significa que assumimos que os recursos são independentes entre si, dado o valor da variável de classe. Apesar de ser uma suposição forte e muitas vezes não ser verdadeira na prática, ela simplifica os cálculos e torna o algoritmo computacionalmente eficiente.

2. Construção do Modelo de Probabilidade: O próximo passo é construir o modelo de probabilidade. Isso envolve calcular a probabilidade de cada classe e a probabilidade de cada valor do recurso dado cada classe. Em outras palavras, para cada classe, calculamos a probabilidade a priori da classe P(C_k) e a probabilidade de cada recurso P(X_i | C_k).

3. Classificação: Depois que o modelo de probabilidade é construído, podemos usá-lo para fazer previsões sobre novos exemplos. Dada uma nova instância com valores de recursos x_1, x_2, …, x_n, queremos calcular a probabilidade de pertencer a cada classe e, em seguida, atribuir a classe com a maior probabilidade como a classe prevista para a instância. Isso é feito usando o teorema de Bayes:

Onde:
 — P(C_k | x_1, x_2, …, x_n) é a probabilidade da classe C_k dado os valores dos recursos/features
 — P(C_k) é a probabilidade a priori da classe C_k
 — P(x_i | C_k) é a probabilidade de cada valor do recurso dado a classe C_k
 — P(x_1, x_2, …, x_n) é a probabilidade dos valores dos recursos.

4. Estimação de Parâmetros: Durante a etapa de construção do modelo, precisamos estimar os parâmetros do modelo, ou seja, as probabilidades a priori das classes e as probabilidades condicionais dos recursos para cada classe. Isso geralmente é feito usando técnicas como a frequência relativa de ocorrência dos dados de treinamento.

5. Suavização de Laplace (Opcional): Em alguns casos, para evitar probabilidades condicionais iguais a zero para features não observados em uma classe particular, pode ser aplicada a suavização de Laplace, adicionando uma pequena quantidade aos contadores de frequência de cada valor de recurso para cada classe durante a estimativa dos parâmetros.

Essas são as etapas principais da função do algoritmo Naive Bayes, desde a suposição de independência condicional até a classificação de novas instâncias usando o teorema de Bayes.

Para construir um classificador, começaremos primeiro criando probabilidades condicionais, dada a tabela a seguir:

Isso nos permite calcular a seguinte tabela de probabilidades:

Depois de ter as probabilidades, podemos calcular a pontuação de probabilidade da seguinte forma

Uma pontuação maior que 1 indica que a classe é positiva, caso contrário é negativa.

Costumamos calcular a probabilidade de uma palavra dada uma classe da seguinte forma:

No entanto, se uma palavra não aparecer no treinamento, ela automaticamente recebe uma probabilidade de 0. Para corrigir isso, adicionamos suavização de laplace da seguinte forma:

Observe que adicionamos um 1 no numerador e, como há V palavras para normalizar, adicionamos V no denominador.

Onde:
- N_classe: frequência de todas as palavras na classe.
- V: número de palavras únicas no vocabulário.

Para calcular a log-verossimilhança (log likelihood), precisamos obter as razões e usá-las para calcular uma pontuação que nos permitirá decidir se um tweet é positivo ou negativo. Quanto maior a razão, mais positiva é a palavra:

Para fazer inferência, você pode calcular o seguinte:

A expressão acima começa com um logaritmo, log, que é aplicado a um produto de probabilidades condicionais. O produto é denotado pelo símbolo Π (pi) e representa o produto de todas as probabilidades condicionais das palavras w_i dadas as classes “negativo” e “positivo”. Isso significa que estamos multiplicando a probabilidade de cada palavra w_i ocorrer, dado que o tweet é negativo, e dividindo pelo mesmo para tweets positivos.

A expressão é comparada com o inverso do produto das probabilidades das classes “negativo” e “positivo”. Isso é feito usando o sinal >, indicando que queremos que a expressão à esquerda seja maior do que o inverso do produto das probabilidades das classes.

Em termos de interpretação, isso significa que estamos comparando a probabilidade conjunta de todas as palavras em um tweet serem negativas (ou positivas) com a probabilidade de um tweet ser classificado como negativo (ou positivo), independente do conteúdo do tweet. Se a probabilidade conjunta de todas as palavras serem negativas (ou positivas) for maior do que a probabilidade do tweet ser classificado como negativo (ou positivo) independentemente do conteúdo, então a inferência seria que o tweet é mais provavelmente negativo (ou positivo).

Essa expressão é uma maneira de inferir a polaridade (positiva ou negativa) de um tweet com base na probabilidade condicional de cada palavra em relação às classes “negativo” e “positivo”, em comparação com a probabilidade marginal das classes. Se a probabilidade conjunta das palavras sendo negativas (ou positivas) for maior do que a probabilidade do tweet ser classificado como negativo (ou positivo) independentemente do conteúdo, então a inferência seria que o tweet é mais provavelmente negativo (ou positivo).

Conforme o número de palavras do tweet (m) aumenta, podemos ter problemas numéricos, então introduzimos o logaritmo, que nos dá a seguinte equação:

Utilizando a propriedade do logaritmo de um produto, podemos reescrever a expressão como a soma dos logaritmos dos fatores dentro do produto. Esta transformação nos permite calcular a log-verossimilhança de forma mais eficiente e robusta, evitando o custo computacional de calcular o logaritmo de um produtório. A expressão agora é uma soma de logaritmos individuais, o que é mais estável numericamente. A nova expressão nos permite calcular a log-verossimilhança somando os logaritmos das razões das probabilidades condicionais de cada palavra em relação às classes “negativo” e “positivo”. Isso nos dá uma medida da probabilidade de observar as palavras em um tweet dado que ele é classificado como negativo, em comparação com a mesma probabilidade para tweets positivos. Essa transformação simplifica o cálculo da log-verossimilhança e reduz a chance de problemas numéricos, tornando a inferência mais eficiente e precisa.

O primeiro componente é chamado de log prior e o segundo componente é a log-verossimilhança. Introduzimos ainda λ (lambda) como segue:

Ter o dicionário λ ajudará muito ao fazer inferência, uma vez que o computemos, se torna simples fazer a inferência, simplesmente somando os lambdas e comparando com os thresholds de negativo, neutro e positivo.

O resultado foi 3.3, sendo > 0, classificaremos o documento como positivo. Se tivessemos um número negativo, classificaríamos como a classe negativa

Depois desse (nada) breve overview sobre probabilidade, podemos fazer os mesmos testes que fizemos com a regressão logística a fim de verificar o desempenho do modelo para cada estratégia de engenharia de features. Vamos seguir a mesma estrutura, testando a estratégia simples e depois a com o preprocessamento do texto aplicando Count Vectorizer e depois TF-IDF. Mas agora vamos utilizar o algoritmo Naive Bayes.

Implementação com a estratégia simples:

import pandas as pd
import nltk
from nltk.tokenize import word_tokenize
from nltk.probability import FreqDist
from sklearn.metrics import accuracy_score
from sklearn.naive_bayes import MultinomialNB
from sklearn.linear_model import LogisticRegression

# divisão em treino e teste
X = df[['pos_freq', 'neg_freq']]
y = df['label']
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3, random_state=42)

# criação do modelo
model = MultinomialNB() # Exemplo: usando Naive Bayes
model.fit(X_train, y_train)

# avaliação do modelo nos dados de teste
y_pred = model.predict(X_test)

# avaliando o modelo
print("\n Classification Report: Estratégia Simples \n", classification_report(y_test, y_pred))

Com o pipeline de pré-processamento + Count Vectorizer:

from sklearn.feature_extraction.text import CountVectorizer
from sklearn.naive_bayes import MultinomialNB
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report

# Divisão em treino e teste
X_train, X_test, y_train, y_test = train_test_split(df['ttweet'], df['label'], test_size=0.3, random_state=42)

# Pré-processamento
X_train_processed = X_train.apply(text_cleaning_l)
X_test_processed = X_test.apply(text_cleaning_l)

# Vetorização das frases processadas
vectorizer = CountVectorizer()
X_train_vectorized = vectorizer.fit_transform(X_train_processed.apply(lambda tokens: ' '.join(tokens)).to_list())
X_test_vectorized = vectorizer.transform(X_test_processed.apply(lambda tokens: ' '.join(tokens)).to_list())  # Use o vetorizador treinado

# Criação do modelo Naive Bayes e treinamento
nb_model = MultinomialNB()
nb_model.fit(X_train_vectorized, y_train)

# Avaliação do modelo nos dados de teste
y_pred = nb_model.predict(X_test_vectorized)

# Avaliação do modelo
print("\n Classification Report: Count Vectorizer \n", classification_report(y_test, y_pred))

Com o pipeline de pré-processamento + TF-IDF:

from sklearn.feature_extraction.text import CountVectorizer
from sklearn.naive_bayes import MultinomialNB
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report

# Divisão em treino e teste
X_train, X_test, y_train, y_test = train_test_split(df['ttweet'], df['label'], test_size=0.3, random_state=42)

# Pré-processamento
X_train_processed = X_train.apply(text_cleaning_l)
X_test_processed = X_test.apply(text_cleaning_l)

# Vetorização das frases processadas
vectorizer = TfidfVectorizer()
X_train_vectorized = vectorizer.fit_transform(X_train_processed.apply(lambda tokens: ' '.join(tokens)).to_list())
X_test_vectorized = vectorizer.transform(X_test_processed.apply(lambda tokens: ' '.join(tokens)).to_list())  # Use o vetorizador treinado

# Criação do modelo Naive Bayes e treinamento
nb_model = MultinomialNB()
nb_model.fit(X_train_vectorized, y_train)

# Avaliação do modelo nos dados de teste
y_pred = nb_model.predict(X_test_vectorized)

# Avaliação do modelo
print("\n Classification Report: TF-IDF \n", classification_report(y_test, y_pred))

Novamente, precisamos identificar quais as métricas importantes e analisar os resultados de acordo com o objetivo do projeto ou do negócio. Com o modelo Naive Bayes, o processamento simples teve uma melhor performace. E em um cenário real provavelmente esse não seria o caso. Mas mesmo assim, precisamos partir de um baseline e ir aumentando a complexidade do modelo e criando novas features até que o desempenho do modelo seja adequado para o objetivo da task.

4. Vector Space Models

Os Modelos de Espaço Vetorial (VSMs) são uma técnica fundamental em processamento de linguagem natural (NLP) para representar o significado de palavras e documentos em um espaço matemático contínuo. Eles são usados para capturar e representar semanticamente o contexto e a similaridade entre palavras e documentos. Os VSMs representam palavras como vetores matemáticos em um espaço de alta dimensionalidade. Cada dimensão do vetor pode representar um aspecto diferente da palavra, como seu contexto, uso ou significado.

Essas dimensões são geralmente aprendidas automaticamente a partir de grandes conjuntos de dados textuais usando técnicas como word embeddings. Ou seja, é codificado uma representação numérica de palavras que captura o significado relativo de forma contextual. Exemplo: A palavra “gato” pode ser representada por um vetor como [0.2, -0.1, 0.5, …], onde cada valor numérico representa um aspecto diferente da palavra.

Além de representar palavras, os VSMs também podem representar documentos inteiros. Nesse caso, cada documento é representado como um vetor onde cada dimensão pode representar a frequência ou importância de uma palavra ou conceito dentro desse documento. Por exemplo, um artigo de notícias sobre tecnologia pode ser representado por um vetor onde a dimensão correspondente à palavra “tecnologia” tem um valor alto, enquanto as dimensões correspondentes a palavras irrelevantes têm valores baixos.

Os VSMs são úteis para medir a similaridade semântica entre palavras e documentos. Isso é feito calculando a proximidade entre os vetores no espaço vetorial. Palavras ou documentos semanticamente semelhantes estarão mais próximos no espaço vetorial. Os vetores das palavras “cachorro” e “animal” provavelmente estarão mais próximos no espaço vetorial do que os vetores das palavras “cachorro” e “carro”.

Eles são amplamente utilizados em tarefas de NLP, como recuperação de informações (information retrieval), classificação de texto, agrupamento de documentos, tradução automática e muito mais. Eles formam a base para muitas técnicas e algoritmos modernos de NLP. Um sistema de recomendação de filmes pode usar VSMs para encontrar filmes semelhantes com base nas sinopses dos filmes já assistidos pelo usuário.

4.1 Word by Word and Word by Doc

Construir vetores usando uma matriz de coocorrência com um design de word by word é uma abordagem para criar representações vetoriais de palavras com base em sua coocorrência em um corpus de texto.

Para construir uma Matriz de Coocorrência, precisamos:

• Definir o Contexto: Para cada palavra no vocabulário, é necessário definir um contexto em torno dela. Por exemplo, para uma palavra “cachorro”, o contexto pode ser os N tokens à esquerda e à direita da palavra em um texto.
• Contar Coocorrências: Para cada palavra no vocabulário, conte quantas vezes ela ocorre no contexto de outras palavras. Isso resulta em uma matriz de coocorrência, onde cada célula (i, j) representa quantas vezes a palavra i ocorre no contexto da palavra j.

A Construção dos Vetores envolve:

• Normalização: Antes de construir os vetores, a matriz de coocorrência pode ser normalizada para considerar fatores como a frequência geral das palavras no corpus e a frequência dos próprios contextos.
• Construção dos Vetores: Cada linha ou coluna na matriz de coocorrência representa um vetor para uma palavra específica. Isso pode ser feito tratando cada linha ou coluna como um vetor.

Suponha que temos o seguinte texto como nosso corpus:

O cachorro correu no parque.
O gato dormiu no sofá.
O cachorro e o gato são amigos.

Para construir a matriz de coocorrência para um contexto de duas palavras à esquerda e à direita, teríamos algo assim (excluindo palavras de parada como “o”, “e”, etc.):

Nesta matriz, cada linha representa uma palavra do vocabulário e cada coluna representa uma palavra do contexto. A célula (i, j) mostra quantas vezes a palavra i ocorre no contexto da palavra j.

Para construir vetores para cada palavra, normalizamos esta matriz e tratamos cada linha ou coluna como um vetor.

Uma vez que os vetores tenham sido construídos, eles podem ser usados para várias tarefas em NLP, como encontrar palavras semanticamente semelhantes, calcular distâncias entre palavras, etc.

Essa abordagem é uma maneira simples e eficaz de construir representações vetoriais de palavras usando a coocorrência em um corpus de texto. No entanto, ela pode ser limitada em capturar nuances semânticas mais complexas, especialmente em corpora muito grandes ou com vocabulários extensos.

Construir vetores usando uma matriz de coocorrência com um design de word by document é uma abordagem para criar representações vetoriais de palavras com base em sua coocorrência com documentos inteiros em um corpus de texto.

Novamente, para construir uma Matriz de Coocorrência, precisamos:

• Definir o Contexto: Neste caso, o contexto é o documento inteiro em que uma palavra ocorre. Cada documento é tratado como uma “janela” em torno das palavras.
• Contar as Coocorrências: Para cada palavra no vocabulário, conte quantas vezes ela ocorre em cada documento. Isso resulta em uma matriz de coocorrência, onde cada linha representa uma palavra e cada coluna representa um documento.

E para construir os vetores, também precisamos:

• Normalização: Assim como na abordagem word by word, a matriz de coocorrência pode ser normalizada para considerar fatores como a frequência geral das palavras no corpus e a frequência dos próprios documentos.
• Construção dos Vetores: Neste caso, cada linha na matriz de coocorrência representa um vetor para uma palavra específica. Cada elemento do vetor pode representar a frequência ou a importância relativa da palavra em cada documento.

Novamente, suponha que temos o seguinte corpus de três documentos:

1. Documento 1: “O cachorro correu no parque.”
2. Documento 2: “O gato dormiu no sofá.”
3. Documento 3: “O cachorro e o gato são amigos.”

A matriz de coocorrência seria algo como:

Para construir vetores para cada palavra, normalizamos esta matriz e tratamos cada linha como um vetor. Uma vez que os vetores tenham sido construídos, eles podem também ser usados para várias tarefas em NLP, como encontrar palavras semanticamente semelhantes, calcular distâncias entre palavras, classificação de texto, entre outros.

Esta abordagem é útil quando estamos mais interessados nas relações entre palavras e documentos do que nas relações entre palavras individuais. Ela pode capturar a essência de como palavras diferentes estão distribuídas em diferentes contextos de documentos.

No exemplo abaixo, podemos verificar a relação entre palavras e documentos, e temos que as palavras “data” estão mais relacionadas a Economy e ML do que Entertainment. Assim como a palavra “film” está mais relacionada à Entertainment que aos demais documentos. Aqui, a categoria Entertainment pode ser representada como um vetor v = [500, 700], assim como Economy como um vetor v = [6620, 4000] e ML como um vetor v = [9320, 1000]

Para medir o quão similiar os as palavras ou documentos são entre si, podemos utilizar a Distância Euclidiana e a Similaridade de Cosseno.

Euclidean Distance

A Distância Euclidiana é uma medida de distância entre dois pontos em um espaço euclidiano. É derivada do teorema de Pitágoras e é frequentemente usada em diversas áreas, como geometria, análise de dados, reconhecimento de padrões e aprendizado de máquina. Aqui está uma explicação detalhada:

A fórmula para calcular a distância euclidiana entre dois pontos P e Q em um espaço n-dimensional é dada por:

Onde:

• P = (p_1, p_2, …, p_n) e Q = (q_1, q_2, …, q_n) são os pontos no espaço n-dimensional.
• p_i e q_i são as coordenadas dos pontos P e Q ao longo da dimensão i.

Essa medida de distância possui as seguintes características:

• Positividade: A distância euclidiana é sempre não negativa, ou seja, $ EuclideanDistance(P, Q) ≥ 0.
• Identidade de Indiscerníveis: A distância entre dois pontos é zero se e somente se os pontos são idênticos.
• Simetria: A distância entre dois pontos P e Q é a mesma que a distância entre Q e P.
• Desigualdade Triangular: A distância de um ponto a outro ponto é sempre menor do que ou igual à soma das distâncias de um ponto a um terceiro ponto intermediário.

Suponha que tenhamos dois pontos no plano 2D: P(2, 3) e Q(5, 7). Para calcular a distância euclidiana entre esses dois pontos, usamos a fórmula:

Portanto, a distância euclidiana entre P e Q é 5 unidades.

A distância euclidiana é amplamente utilizada em algoritmos de agrupamento (como k-means), classificação (como k-NN), redução de dimensionalidade (como PCA), reconhecimento de padrões, entre outros. É uma métrica fundamental em muitos problemas de otimização, onde minimizar ou maximizar a distância entre pontos é um objetivo. Ela é é uma medida intuitiva e útil para quantificar a distância entre pontos em um espaço multidimensional.

Podemos generalizar a encontrar a distância entre dois pontos (x_1, y_1) e (x_2, y_2) para a distância entre um vetor v de n dimensões da seguinte forma:

Para calcular a distância euclidiana entre dois vetores n-dimensionais em Python, podemos usar a biblioteca NumPy, que fornece funções eficientes para operações matemáticas em vetores e matrizes.

import numpy as np

def euclidean_distance(vector1, vector2):
    """
    Calcula a distância euclidiana entre dois vetores n-dimensionais.

    Argumentos:
    vector1 (np.array): O primeiro vetor.
    vector2 (np.array): O segundo vetor.

    Retorna:
    float: A distância euclidiana entre os dois vetores.
    """
    if len(vector1) != len(vector2):
        raise ValueError("Os vetores devem ter o mesmo número de dimensões.")

    # Converte as listas em arrays do NumPy para cálculos eficientes
    vector1 = np.array(vector1)
    vector2 = np.array(vector2)

    # Calcula a diferença entre os dois vetores
    difference = vector2 - vector1

    # Calcula a soma dos quadrados das diferenças
    squared_difference = np.sum(difference ** 2)

    # Calcula a raiz quadrada da soma dos quadrados
    euclidean_distance = np.sqrt(squared_difference)

    return euclidean_distance

# Exemplo de uso
vector1 = [2, 3, 5]
vector2 = [5, 7, 1]

distance = euclidean_distance(vector1, vector2)
print("A distância euclidiana entre os vetores é:", distance)

Ou simplesmente

distance = np.linalg.norm(np.array(vector1) - np.array(vector2))

4.3 Cosine Similarity

A similaridade do cosseno é uma medida de similaridade entre dois vetores em um espaço vetorial, frequentemente usado em mineração de texto, recuperação de informação e aprendizado de máquina. A medida é baseada no ângulo formado entre os dois vetores no espaço vetorial e não na distância euclidiana entre eles. A similaridade do cosseno entre dois vetores $ \mathbf{A} $ e $ \mathbf{B} $ é dada pela fórmula:

Onde:
- 𝐀⋅𝐁 é o produto interno (ou escalar) entre os vetores 𝐀 e 𝐁.
- ‖𝐀‖‖‖ e ‖𝐁‖ são as normas (ou magnitudes) dos vetores 𝐀 e 𝐁, respectivamente.

Essa medida de similaridade possui as seguintes características:

• Intervalo de Valores: A similaridade do cosseno varia de -1 a 1, onde 1 indica que os vetores têm a mesma direção, 0 indica que os vetores são ortogonais (semelhantes de forma nula) e -1 indica que os vetores têm direções opostas.
• Independência de Escala: A similaridade do cosseno é independente da escala dos vetores. Isso significa que os vetores podem ser normalizados antes do cálculo sem afetar o resultado.
• Eficiência Computacional: O cálculo da similaridade do cosseno é computacionalmente eficiente, especialmente para vetores de alta dimensionalidade.
• Apropriado para Texto: É amplamente utilizado em NLP, pois lida bem com vetores de alta dimensão, como vetores de termos de documentos.

Suponha que temos dois vetores A = [2, 1] e B = [3, 4]. Para calcular a similaridade do cosseno entre esses dois vetores, usamos a fórmula:

Portanto, a similaridade do cosseno entre A e B é 0.4.

A similaridade do cosseno é amplamente utilizada em tarefas de recuperação de informação, onde é usada para encontrar documentos semelhantes com base em vetores de termos de documentos. Também é usado em sistemas de recomendação para calcular a similaridade entre perfis de usuários e itens. Além disso, é usado em classificação de texto e agrupamento de documentos. A similaridade do cosseno é uma medida eficaz de similaridade entre vetores que é amplamente utilizada em várias aplicações, especialmente em processamento de linguagem natural e mineração de texto.

Se os documentos tiverem tamanhos diferentes, a métrica de Euclidean Distance não é a ideal. Cosine Similarity não é enviesada pelo pelo tamanho da diferença entre os vetores.

Para calcular a similaridade de cosseno entre dois vetores em Python, você pode usar a biblioteca NumPy para facilitar os cálculos vetoriais

import numpy as np

def cosine_similarity(vector1, vector2):
    """
    Calcula a similaridade de cosseno entre dois vetores.

    Argumentos:
    vector1 (np.array): O primeiro vetor.
    vector2 (np.array): O segundo vetor.

    Retorna:
    float: A similaridade de cosseno entre os dois vetores.
    """
    dot_product = np.dot(vector1, vector2)
    norm_vector1 = np.linalg.norm(vector1)
    norm_vector2 = np.linalg.norm(vector2)
    similarity = dot_product / (norm_vector1 * norm_vector2)
    return similarity

# Exemplo de uso
vector1 = np.array([2, 1])
vector2 = np.array([3, 4])

similarity = cosine_similarity(vector1, vector2)
print("A similaridade de cosseno entre os vetores é:", similarity)

Manipulating Words in Vector Spaces

Podemos manipular os espaços vetoriais para fazer algumas previsões, como prever países e suas capitais, essa é uma aplicação de vetores em aprendizado de máquina e processamento de linguagem natural. Graças ao relacionamento entre os vetores, podemos verificar esse tipo de associação.

Primeiro, precisaríamos de uma representação vetorial para as palavras envolvidas — neste caso, países e suas capitais. Uma maneira comum de fazer isso é usar embeddings de palavras pré-treinados, como os disponíveis em modelos como Word2Vec, GloVe ou FastText. Esses embeddings atribuem a cada palavra um vetor numérico denso em um espaço vetorial, onde palavras semanticamente semelhantes estão próximas umas das outras. Mas podemos usar os embeddings que criamos também.

Para cada país e capital, precisaríamos de seus respectivos vetores. E, ao usarmos embeddings de palavras pré-treinados, podemos simplesmente pegar os vetores correspondentes às palavras “país” e “capital” e somá-los aos vetores de palavras correspondentes ao país e à capital real. Por exemplo, para prever a capital do Brasil, você somaria o vetor correspondente a “Brasil” ao vetor correspondente a “capital”, obtendo assim um vetor que representa a capital prevista.

Agora que você tem vetores para países e capitais, você pode usar operações vetoriais para fazer previsões. Por exemplo, para prever a capital de um país, você poderíamos calcular a diferença entre o vetor do país de interesse e o vetor de outro país conhecido com sua capital conhecida. Em seguida, você adiciona esse vetor de diferença ao vetor da capital conhecida para obter a capital prevista.

Por exemplo, suponha que você tenha embeddings de palavras onde “Brasil” é representado pelo vetor v_Brasil e “capital” pelo vetor v_capital. Para prever-mos a capital do Brasil, faríamos o seguinte:

Outra forma de prever tokens usando as relações vetoriais, é usar as representações conhecidas. Sabendo que a capital dos USA é Washington, podemos ver a distância entre os dois vetores e somar ao vetor que representa Russia para descobrir sua capital, Como:

Depois de fazer as previsões, podemos avaliar a precisão do modelo usando um conjunto de dados de teste que contenha pares de países e suas capitais reais. Se a precisão não for satisfatória, você pode ajustar os vetores ou usar técnicas mais avançadas de aprendizado de máquina para melhorar o desempenho do modelo.

Manipular vetores usando aritmética para prever países e suas capitais (ou qualquer relacionamento parecido) envolve representar países e capitais como vetores, realizar operações vetoriais para fazer previsões e avaliar o desempenho do modelo.

Outro exemplo bem famoso é o do é o do “king — man + woman = queen”, quem ao somar e subtrair os valores correspondentes a eles, acabaríamos ficando próximo no espaço multidimensional do vetor que representa “queen”.

4.5 Principal Component Analysis

A Análise de Componentes Principais (PCA) é um algoritmo não supevisionado, uma técnica de redução de dimensionalidade amplamente utilizada para simplificar conjuntos de dados complexos, mantendo as informações mais importantes. Funciona encontrando as direções (ou componentes) de maior variância nos dados e projetando os dados nesses novos eixos, chamados de componentes principais. Ele funciona da seguinte forma:

• Centralização dos Dados: Antes de aplicar o PCA, os dados são geralmente centralizados subtraindo a média de cada variável. Isso garante que o centro dos dados esteja na origem do espaço de características.
• Cálculo da Matriz de Covariância: Em seguida, é calculada a matriz de covariância dos dados centralizados. A covariância entre duas variáveis mede como elas variam juntas. A matriz de covariância captura as relações lineares entre as variáveis originais.
• Decomposição da Matriz de Covariância: A seguir, a matriz de covariância é decomposta em seus autovetores e autovalores. Os autovetores representam as direções dos eixos principais (ou componentes principais) dos dados, enquanto os autovalores representam a quantidade de variância explicada por cada componente principal.
• Seleção dos Componentes Principais: Os autovetores são ordenados de acordo com seus autovalores associados, do maior para o menor. Os autovetores com os maiores autovalores capturam a maior parte da variância nos dados e são selecionados como os componentes principais mais importantes.
• Projeção dos Dados: Finalmente, os dados são projetados nos novos eixos definidos pelos componentes principais selecionados. Isso reduz a dimensionalidade dos dados, substituindo as variáveis originais por uma combinação linear dos componentes principais.

Vamos considerar um conjunto de dados bidimensional com duas variáveis, como altura e peso de uma população. O PCA encontrará a direção ao longo da qual a variabilidade dos dados é máxima. Suponha que a direção seja dada pelo autovetor [0.8, 0.6], com um autovalor associado de 10. Isso significa que 80% da variabilidade dos dados está ao longo dessa direção. Os dados podem ser projetados nessa direção, reduzindo-os de duas dimensões para uma dimensão. Podemos usá-lo para:

• Redução de dimensionalidade: PCA é usado para reduzir a dimensionalidade de dados complexos, preservando o máximo de informação possível.
• Visualização de dados: PCA pode ser usado para visualizar dados de alta dimensionalidade em um espaço de menor dimensão.
• Pré-processamento de dados: PCA é frequentemente usado como uma etapa de pré-processamento antes de aplicar algoritmos de aprendizado de máquina, para reduzir o tempo de treinamento e evitar a maldição da dimensionalidade.

O PCA é uma técnica poderosa e amplamente utilizada para redução de dimensionalidade e análise exploratória de dados, que ajuda a simplificar conjuntos de dados complexos, mantendo as informações mais importantes.

Sua implementação também é muito simples

import numpy as np
import matplotlib.pyplot as plt
from sklearn.decomposition import PCA

# Passo 2: Gere um conjunto de dados de exemplo com vetores de alta dimensão (d = 10)
np.random.seed(42)
n_samples = 1000
d = 10
X = np.random.randn(n_samples, d)  # Gera 1000 vetores de dimensão 10 com distribuição normal

# Passo 3: Aplique o PCA para reduzir a dimensionalidade dos vetores para 2 dimensões
pca = PCA(n_components=2)
X_2d = pca.fit_transform(X)

# Passo 4: Plote os vetores reduzidos em um gráfico de dispersão para visualização
plt.figure(figsize=(8, 6))
plt.scatter(X_2d[:, 0], X_2d[:, 1], alpha=0.5)
plt.title('Visualização dos Vetores Reduzidos com PCA em 2 Dimensões')
plt.xlabel('Componente Principal 1')
plt.ylabel('Componente Principal 2')
plt.grid(True)
plt.show()

PCA é comumente usada para reduzir a dimensão dos seus dados. Intuitivamente, o modelo colapsa os dados através dos componentes principais. Você pode pensar no primeiro componente principal (em um conjunto de dados 2D) como a linha onde há a maior quantidade de variância. Você pode então colapsar os pontos de dados nessa linha. Portanto, você passou de 2D para 1D. Podemos generalizar essa intuição para várias dimensões.

Com isso, acabamos gerando os Eigenvectors (autovetores) e Eigenvalues (autovalores), que são:

• Eigenvectors: os vetores resultantes, também conhecidos como características não correlacionadas dos seus dados.
• Eigenvalues: a quantidade de informação retida por cada nova característica. Você pode pensar nisso como a variância no vetor próprio.

Podemos seguir os seguintes passos para Calcular a PCA:

1. Normalizar a média dos seus dados.
2. Calcular a matriz de covariância.
3. Calcular SVD na sua matriz de covariância. Isso retorna [USV] = svd(Σ) (Sigma). As três matrizes U, S, V são desenhadas acima. U é rotulado com os vetores próprios, e S é rotulado com os autovalores.

Podemos então usar as primeiras n colunas do vetor U, para obter seus novos dados multiplicando XU[:, 0:n].

Conclusão

Este artigo focou somente no paradígma estatístico. Nele, foi abordado como extrair features e realizar o preprocessamento de dados, os modelos de regressão logística e algoritmo naive bayes, e como aplicá-los na tarefa de classificação de texto para análise de sentimento, foi descrito o que são Vector Space Models, como eles representam palavras e documentos e como construir matrizes de coocorrencia no formato word by word e word by document, como avaliar a similaridade de vetores com a distância euclidiana e similaridade de cosseno, como manipular palavras nos espaços vetoriais e o algoritmo Principal Component Analysis e como utilizá-lo.

Como Citar

Guimarães, Alysson. (Jun 2024). Natural Language Processing (NLP) Com Classificação e Espaços Vetoriais. https://medium.com/data-hackers/. https://medium.com/data-hackers/p-51291c08f29e

ou

@miscellaneous{guimaraes2024nlpvec,
 title = {Natural Language Processing Com Classificação e Espaços Vetoriais},
 author = {Guimarães, Alysson},
 journal = {https://medium.com/data-hackers/},
 year = {2024},
 month = {Jun},
 url = {https://k3ybladewielder.medium.com/p-51291c08f29e}
}

Referência

• Natural Language Processing with Classification and Vector Spaces, disponível em https://www.coursera.org/learn/classification-vector-spaces-in-nlp

Licença

• CC BY-SA 2.0 LEGAL CODE. Attribution-ShareAlike 2.0 Generic
• Para detalhes sobre a licença, verifique https://creativecommons.org/licenses/by-sa/2.0/legalcode

Natural Language Processing (NLP) Com Classificação e Espaços Vetoriais was originally published in Data Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.

STATISTIC

• Statistics for Data Science Part 2/8
• Statistics for Data Science Part 1/8
• Introduction to Causal Inference

DATA SCIENCE, MACHINE LEARNING AND AI

• Tree-Based Supervised Learning Methods
• Regression Smoothing Methods
• Principles of Linear Regression

COGNITIVE SCIENCE

• Philosophical Approaches to Cognitive Science
• Cognitive Science 🧠

DECISION THEORY

• Introduction to Decision Theory

NATURAL LANGUAGE PROCESSING (NLP)

• Reasoning in Pre-trained Language Models (PLMs)
• Competitive Intelligence with Topic Modeling
• Topic Modeling Techniques
• NLP Concepts
• Introduction to NLP

Follow my profile and sign up here to receive the next posts on the topic, and contribute to the relevance of the post with 👏👏👏 after reading.

PyTorch é uma biblioteca de código aberto escrita em Python e C++ para computação numérica acelerada por GPU, principalmente usada para aplicações de deep learning. Ele fornece as principais funcionalidades necessárias para o desenvolvimento de redes neurais, como suporte multidimensional tensor (matrizes multi-dimensional) e operadores diferenciais automáticos. Esse framework possue diversas vantagens, a citar algumas:

• Facilidade no prototipagem e debugging devido à sua interface dinâmica;
• Suporte nativo para computação paralela através da utilização de GPUs;
• Integração com outras ferramentas populares do ecossistema do Python,como NumPy e SciPy;
• Além disso tem comunidade ativa de desenvolvedores contribuindo com novas features e soluções para problemas específicos.

O PyTorch foi criado pelo Facebook AI Research Lab (FAIR), mas hoje em dia tem um grande número de colaboradores, incluindo empresas líderes na indústria como NVIDIA, Google, Microsoft e IBM.

Os modelos de deep learning criados usando o PyTorch podem ser aplicados em uma variedade de tarefas e domínios em diversas indústrias, como:

Visão Computacional:

• Classificação de imagens: Identificação de objetos em fotografias, como animais, veículos, pessoas e outros elementos presentes no conjunto de dados ImageNet.
• Detecção de Objetos: Localização exata de objetos em imagens, geralmente expressa em caixas delimitadoras. Modelos notáveis incluem YOLO (You Only Look Once) e SSD (Single Shot Multibox Detector).
• Segmentação de Imagens: Divisão de imagens em regiões correspondentes a classes distintas, como pixel por pixel classificação.
• Geração de Imagens: Produção de imagens artísticas, hiperrealistas ou fantásticas geradas por meio de redes neuronais condicionadas por entrada textual ou aleatória.

Processamento Natural de Linguagem (NLP)

• Tradução Automática: Conversão de texto escrito em uma língua para outra língua usando modelos como Transformer e Seq2Seq.
• Resposta de Perguntas (QA): Previsão de respostas a perguntas feitas em diversos idiomas.
• Text Summarization: Gerar sumários curtos e concisos de documentos longos preservando informações importantes.
• Chatbots: Construção de assistentes virtuais capazes de compreender e responder consultas de usuários de formas naturais e contextualmente relevantes.

Áudio e Processamento de Sinal

• Reconhecimento de Falas: Interpretação da fala humana convertendo ondas sonoras em transcrições textuais, usado em sistemas de dictâfonos digitais, smartphones e aparelhos auditivos.
• Separação de Fontes Sonoras (Audio Source Separation): Capacidade de separar sons misturados, isolando fontes musicais individuais ou falas de conversas complexas.
• Música Generativa: Criação de músicas originais através de composição e arranjos gerados por máquinas, inspirados em estilos clássicos ou contemporâneos.

Jogos e Robótica

• Reinforcement Learning: Treino de agentes inteligentes que tomam decisões autônomas enfrentando desafios em jogos como Go, poker e StarCraft II.
• Animação e Robótica: Controle de personagens virtuais, manipulação de robôs industriais e assistência a deficientes visuais em ambientes urbanos movimentados.

Este artigo está dividido em dois grandes blocos, e neles, abordaremos os seguintes tópicos:

Fundamentos de Machine Learning com PyTorch

— Tensores
 — Derivada no PyTorch
 — Gradiente Descendente Estocástico (SGD)
— Gradiente Descendente com Momentum
 — Mini-Batch Gradient Descent
 — Normalização em Lote
 — Divisão em Treinamento, Validação e Teste

Redes Neurais:

— Redes Neurais Rasas
 — Redes Neurais Profundas
— nn.ModuleList()
 — Funções de Ativação
 — Backpropagation
 — O problema do “vanishing gradient”
 — Dropout
 — Pesos e Inicialização da Rede Neural

Fundamentos de Machine Learning com PyTorch

Tensores

Tensores são as estruturas fundamentais que representam dados multi-dimensionais. Eles são semelhantes aos arrays ou matrizes. Eles são os building blocks e a base para construção de e manipulação de modelos de machine learning e deep learning.

Os tensores são semelhantes aos arrays do NumPy e, muitas vezes, podem ser convertidos de um para o outro. Isso facilita a integração com bibliotecas científicas em Python. Além disso o PyTorch permite a computação em GPUs para acelerar operações, e eles podem ser movidos para uma GPU para aproveitar o poder de processamento paralelo. Ele fornece uma ampla variedade de operações matemáticas que podem ser aplicadas a tensores, isso inclui operações aritméticas, funções trigonométricas, álgebra linear, entre outras.

Uma característica fundamental do Pytorch é o sistema de autograd, que automaticamente calcula gradientes para tensores. Isso é crucial para a otimização de modelos de aprendizado de máquina.

Podemos criar tensores de várias maneiras, seja inicializando-os com valores específicos, gerando números aleatórios, ou a partir de dados existentes. Eles são úteis para representar dados ao longo de uma única dimensão, como séries temporais, uma linha de pixels de uma imagem ou um conjunto de valores.

import torch

# Criando um tensor 1D
tensor_1d = torch.tensor([1, 2, 3, 4, 5])

# Acessando elementos do tensor
print(tensor_1d[0])  # Saída: 1
print(tensor_1d[2])  # Saída: 3

# Operações matemáticas em tensores 1D
tensor_resultado = tensor_1d * 2
print(tensor_resultado)  

# Saída: tensor([2, 4, 6, 8, 10])

Neste exemplo, tensor_1d é um tensor 1D contendo os valores de 1 a 5. Podemos acessar elementos individualmente e realizar operações matemáticas diretamente nos tensores. Os tensores 1D são frequentemente usados em problemas onde os dados estão organizados de forma linear, e são a base para a construção de estruturas de dados mais complexas, como matrizes bidimensionais (tensores 2D) e tensores de ordens superiores.

Tensores bidimensionais em PyTorch são estruturas de dados que representam matrizes, ou seja, arranjos retangulares de elementos organizados em duas dimensões. Eles são comumente utilizados para representar dados tabulares, imagens, ou qualquer outra informação que possa ser organizada em linhas e colunas.

import torch

# Criando um tensor bidimensional (matriz)
tensor_2d = torch.tensor([[1, 2, 3], [4, 5, 6], [7, 8, 9]])

# Acessando elementos do tensor bidimensional
print(tensor_2d[0, 1])  # Saída: 2 (linha 0, coluna 1)

# Operações matemáticas em tensores bidimensionais
tensor_resultado = tensor_2d * 2
print(tensor_resultado)
# Saída:
# tensor([[ 2,  4,  6],
#         [ 8, 10, 12],
#         [14, 16, 18]])

Neste exemplo, tensor_2d é uma matriz 3x3 com elementos de 1 a 9. Eles são geralmente usados em tarefas de processamento de imagens, onde cada elemento da matriz pode representar um pixel. Eles também são essenciais para a construção e treinamento de modelos de aprendizado de máquina, especialmente redes neurais profundas, onde as entradas muitas vezes são representadas por tensores bidimensionais.

## Esses são apenas alguns exemplos.
# Criando dois tensores bidimensionais
import torch
tensor_a = torch.tensor([[1, 2, 3], [4, 5, 6]])
tensor_b = torch.tensor([[7, 8, 9], [10, 11, 12]])

# Soma de tensores
soma = tensor_a + tensor_b
print("Soma:")
print(soma)

# Subtração de tensores
subtracao = tensor_a - tensor_b
print("\nSubtração:")
print(subtracao)

# Multiplicação de tensores (element-wise)
multiplicacao_elementwise = tensor_a * tensor_b
print("\nMultiplicação (element-wise):")
print(multiplicacao_elementwise)

# Multiplicação de tensores (produto matricial)
produto_matricial = torch.matmul(tensor_a, tensor_b.T)  # Transpondo tensor_b para alinhar dimensões*
print("\nProduto Matricial:")
print(produto_matricial)

# Operações de redução (somando elementos ao longo das colunas)
soma_colunas = torch.sum(tensor_a, dim=0)
print("\nSoma das Colunas:")
print(soma_colunas)

# Operações de broadcast (somando uma constante a cada elemento)
tensor_soma_constante = tensor_a + 10
print("\nSoma com Constante:")
print(tensor_soma_constante)

# Saída
# Soma:
# tensor([[ 8, 10, 12],
#        [14, 16, 18]])
#
# Subtração:
# tensor([[-6, -6, -6],
#       [-6, -6, -6]])
#
# Multiplicação (element-wise):
# tensor([[ 7, 16, 27],
#        [40, 55, 72]])
#
# Produto Matricial:
# tensor([[ 50,  68],
#        [122, 167]])
#
# Soma das Colunas:
# tensor([5, 7, 9])
#
# Soma com Constante:
# tensor([[11, 12, 13],
#        [14, 15, 16]])

Os tensores tridimensionais (tensores 3D) são utilizados para representar dados que possuem uma organização tridimensional, como volumes de imagens ou séries temporais multivariadas.

# Criando um tensor 3D (volume)
tensor_3d = torch.tensor([[[1, 2, 3],[4, 5, 6]],
                          [[7, 8, 9], [10, 11, 12]],
                          [[13, 14, 15], [16, 17, 18]]])

# Acessando elementos do tensor 3D
print("Acessando um elemento:")
print(tensor_3d[1, 0, 2])  # Saída: 9 (depth 1, linha 0, coluna 2)

# Operações matemáticas em tensores 3D
tensor_resultado = tensor_3d * 2
print("\nMultiplicação por 2:")
print(tensor_resultado)

# Operações de redução (somando elementos ao longo das dimensões)
soma_dim1 = torch.sum(tensor_3d, dim=1)
print("\nSoma ao Longo da Dimensão 1:")
print(soma_dim1)

# Operações de broadcast (somando uma constante a cada elemento)
tensor_soma_constante = tensor_3d + 10
print("\nSoma com Constante:")
print(tensor_soma_constante)

# Saída
# Acessando um elemento:
# tensor(9)
#
#Multiplicação por 2:
# tensor([[[ 2,  4,  6],
#         [ 8, 10, 12]],
#
#        [[14, 16, 18],
#         [20, 22, 24]],
#
#        [[26, 28, 30],
#         [32, 34, 36]]])
#
# Soma ao Longo da Dimensão 1:
# tensor([[ 5,  7,  9],
#        [17, 19, 21],
#        [29, 31, 33]])
#
# Soma com Constante:
# tensor([[[11, 12, 13],
#         [14, 15, 16]],
#
#        [[17, 18, 19],
#         [20, 21, 22]],
#
#        [[23, 24, 25],
#         [26, 27, 28]]])

Neste exemplo, tensor_3d representa um volume 3D com dimensões 3x2x3. Podemos acessar os elementos individualmente usando índices em cada dimensão, e as operações matemáticas podem ser feitas de forma parecida aos feitos com tensores 2D. Eles são frequentemente encontrados em problemas de visão computacional para representar volumes de dados tridimensionais, como pilhas de imagens ou volumes médicos.

Derivada no Pytorch

A derivada e a derivada parcial são conceitos fundamentais em cálculo diferencial, e desempenham um papel crucial na compreensão do comportamento de funções em uma ou mais variáveis.

A derivada de uma função em relação a uma variável representa a taxa de variação instantânea da função em relação a essa variável. Em outras palavras, indica como a função está mudando em um ponto específico do domínio. A notação matemática padrão para a derivada de uma função f(x) em relação a x é f′(x) ou (∂f/∂x). Geometricamente, a derivada no ponto x é equivalente à inclinação da tangente à curva da função nesse ponto. Para entender a intuição, imagine que você está dirigindo em um carro e olhando para o velocímetro. A velocidade do carro está mudando constantemente conforme você dirige. A derivada de sua posição em relação ao tempo seria como a leitura instantânea do velocímetro, indicando a velocidade exata em que você está se movendo naquele momento. A derivada de uma função em um ponto nos diz como a função está mudando nesse ponto. Se a função representa a posição de um objeto ao longo do tempo, a derivada seria a velocidade instantânea.

Já a derivada parcial de uma função de várias variáveis em relação a uma variável específica mede a taxa de variação da função em relação a essa variável, mantendo todas as outras variáveis constantes. A notação para a derivada parcial de uma função f(x,y,…) em relação a uma variável x é ∂f/∂x. Aqui, ∂ é usado para indicar uma derivada parcial. Analogamente, a derivada parcial em relação a y seria ∂f/∂y, e assim por diante. Novamente, vamos tentar entender a intuição: Imagine que você está em um terreno acidentado e a temperatura varia em diferentes partes desse terreno. A derivada parcial em relação à temperatura em um determinado ponto seria como medir o quanto a temperatura muda nesse ponto específico, mantendo todas as outras variáveis (como a posição) constantes. Em termos mais gerais, a derivada parcial de uma função de várias variáveis em relação a uma delas nos dá a taxa de variação da função em relação a uma variável específica, mantendo as outras constantes. É como analisar como uma feature específica influencia o comportamento da função, enquanto outras feature permanecem inalteradas.

Ambos os conceitos, derivada e derivada parcial, ajudam a entender como as coisas mudam em relação a uma variável ou a uma mudança em uma única dimensão, seja em trajetórias de carros ou em paisagens de temperatura. Essas ideias são fundamentais para modelagem matemática e são amplamente aplicadas em diversas áreas, desde física até aprendizado de máquina.

A derivada é uma generalização da ideia de taxa de variação para funções de uma única variável, enquanto a derivada parcial lida com funções de várias variáveis, permitindo-nos entender como a função muda ao longo de cada dimensão independente.

A fórmula para a derivada parcial em relação a uma variável específica é semelhante à fórmula da derivada para funções de uma variável, considerando todas as outras variáveis como constantes. Essas ferramentas são fundamentais para a análise e otimização de funções em problemas matemáticos e científicos.

A diferenciação automática é uma feature fundamental em PyTorch que permite calcular automaticamente gradientes em relação às variáveis de interesse. Isso é especialmente útil em aprendizado de máquina, onde otimizar modelos envolve ajustar parâmetros para minimizar ou maximizar uma função de perda. O mecanismo de diferenciação automática em PyTorch é implementado pelo módulo autograd.

import torch

# Variáveis que requerem gradiente
x = torch.tensor([2.0], requires_grad=True)
y = torch.tensor([3.0], requires_grad=True)

# Operações envolvendo as variáveis
z = x**2 + y**3

# Calcular gradientes
z.backward()

# Exibir gradientes
print("Gradiente em relação a x:", x.grad)
print("Gradiente em relação a y:", y.grad)

# Saída
# Gradiente em relação a x: tensor([4.])
# Gradiente em relação a y: tensor([27.])

Neste exemplo, x e y são tensores que requerem gradiente (requires_grad=True). A expressão z = x**2 + y**3 é calculada, e em seguida, chamamos z.backward() para calcular automaticamente os gradientes de z em relação a x e y. Os gradientes são então acessados através dos atributos .grad das variáveis.

Este é um exemplo muito simples, mas em modelos de aprendizado de máquina, esses gradientes são essenciais para a retropropagação (backpropagation) durante o treinamento.

import torch
import torch.optim as optim

# Dados de entrada e saída desejada
x_data = torch.tensor([1.0, 2.0, 3.0, 4.0], requires_grad=False)
y_data = torch.tensor([2.0, 4.0, 6.0, 8.0], requires_grad=False)

# Inicializando parâmetros
w = torch.tensor([1.0], requires_grad=True)
b = torch.tensor([0.0], requires_grad=True)

# Definindo a função linear
def modelo_linear(x):
    return w * x + b

# Função de perda (erro quadrático médio)
def loss_function(y_pred, y_actual):
    return torch.mean((y_pred - y_actual)**2)

# Configurando o otimizador
optimizer = optim.SGD([w, b], lr=0.01)

# Treinamento do modelo
for epoch in range(100):
    # Forward pass
    y_pred = modelo_linear(x_data)

    # Cálculo da perda
    loss = loss_function(y_pred, y_data)

    # Retropropagação e otimização
    optimizer.zero_grad()  # Zera os gradientes acumulados
    loss.backward()        # Calcula gradientes
    optimizer.step()        # Atualiza parâmetros

# Exibindo parâmetros finais
print("Parâmetros finais: w =", w.item(), ", b =", b.item())
# Parâmetros finais: w = 1.9231737852096558 , b = 0.22587870061397552

Gradiente Descendente Estocástico

O Gradiente Descendente Estocástico (SGD, do inglês Stochastic Gradient Descent) é uma variação do algoritmo de otimização do Gradiente Descendente, frequentemente usado no treinamento de modelos de aprendizado de máquina e redes neurais. A principal diferença entre o Gradiente Descendente Estocástico e o Gradiente Descendente clássico está na forma como as atualizações dos parâmetros do modelo são realizadas.

No Gradiente Descendente clássico, a atualização dos parâmetros é realizada utilizando o gradiente médio dos parâmetros sobre o conjunto de dados de treinamento completo. A função de custo é calculada considerando todos os exemplos de treinamento.

Já no Gradiente Descendente Estocástico (SGD), a atualização dos parâmetros é realizada para cada exemplo de treinamento (ou em pequenos lotes (mini lotes)). Ou seja, em vez de calcular o gradiente médio, o gradiente é calculado apenas para um exemplo aleatório a cada iteração. Isso acaba introduzindo estocasticidade (aleatoriedade) no processo de atualização dos parâmetros. Isso trás vantagens como

• Eficiência Computacional: Utilizar apenas um exemplo ou mini lote por vez é computacionalmente eficiente, especialmente em conjuntos de dados grandes.
• É Mais Rápido para Convergência: A aleatoriedade introduzida pode ajudar a escapar de mínimos locais e acelerar a convergência, especialmente em funções de custo não convexas.

Mas também tras desvantanges como:

• Estocasticidade: Devido à estocasticidade, o SGD pode levar a uma convergência mais ruidosa. A função de custo pode variar mais ao longo do tempo.
• Taxa de Aprendizado Ajustável: A escolha apropriada da taxa de aprendizado é crucial. Pode ser necessário ajustar dinamicamente a taxa de aprendizado durante o treinamento.

import torch
import torch.optim as optim

# Definindo um modelo e uma função de custo
model = torch.nn.Linear(2, 1)
criterion = torch.nn.MSELoss()

# Definindo um otimizador SGD
optimizer = optim.SGD(model.parameters(), lr=0.01)

# Exemplo de treinamento com SGD
for epoch in range(num_epochs):
    for inputs, labels in data_loader:  # Iterando sobre mini lotes
        optimizer.zero_grad()
        outputs = model(inputs)
        loss = criterion(outputs, labels)
        loss.backward()
        optimizer.step()

Neste exemplo, optim.SGD é usado como otimizador para aplicar o Gradiente Descendente Estocástico durante o treinamento. O loop aninhado sobre mini lotes ilustra o conceito de atualização de parâmetros para cada exemplo ou mini lote.

Gradient Descent com Momentum

O Gradiente Descendente com Momentum é uma variação do algoritmo básico de Gradiente Descendente, projetada para acelerar a convergência e lidar melhor com regiões de superfície de perda complicadas. Este método incorpora um conceito chamado “momentum”, inspirado pela física.

A ideia do momentum é simular o comportamento de uma bola rolando por uma superfície de perda. Quando a bola começa a rolar em uma direção, ela acumula momentum e ganha velocidade. Isso ajuda a superar pequenos obstáculos e acelerar em direção ao mínimo global.

A atualização dos pesos usando o Gradiente Descendente com Momentum é dada pela seguinte fórmula:

onde:

• θ_t são os parâmetros (pesos) no passo de iteração t,
• ∇J(θ_t) é o gradiente da função de perda J em relação aos parâmetros θ_t1,
• α é a taxa de aprendizado ou learning rate,
• β é o coeficiente de momentum, geralmente entre 0 e 1,
• v_t é o vetor de momentum no passo t.

A introdução do termo β⋅v_t na atualização dos pesos permite que o momentum acumule ao longo das iterações. Isso é especialmente útil quando o gradiente varia de direção, permitindo que o modelo ganhe impulso em direção ao mínimo global.

A principal vantagem do Gradiente Descendente com Momentum é sua capacidade de acelerar o treinamento, especialmente em áreas onde o gradiente oscila ou possui muitos mínimos locais. Essa técnica pode ajudar a superar regiões planas na função de perda e escapar de mínimos locais.

Em PyTorch, você pode implementar o Gradiente Descendente com Momentum usando o otimizador torch.optim.SGD com o argumento momentum.

import torch
import torch.optim as optim

# Definindo parâmetros
learning_rate = 0.01
momentum = 0.9

# Criando um otimizador com momentum
optimizer = optim.SGD(model.parameters(), lr=learning_rate, momentum=momentum)

# No loop de treinamento, você usaria optimizer.step() para atualizar os pesos
# e optimizer.zero_grad() para zerar os gradientes antes de uma nova backward pass.

A adição de momentum pode ser benéfica em muitos casos, mas é importante ajustar a taxa de aprendizado e o coeficiente de momentum para obter o melhor desempenho em um problema específico.

O valor típico de 0.9 para o coeficiente de momentum é uma escolha empírica comum que muitas vezes funciona bem em prática. A escolha do valor específico para o coeficiente de momentum pode depender do problema, da arquitetura da rede e da natureza do conjunto de dados. Vários valores, como 0.9, 0.99, ou até mesmo outros, podem ser experimentados para encontrar o melhor desempenho em um determinado contexto.

O momentum é um termo de regularização que ajuda a suavizar as atualizações dos pesos ao longo do tempo. Um valor de 0.9 significa que a atualização dos pesos é uma média ponderada entre a direção atual do gradiente e a direção do termo de momentum anterior. Isso dá ao modelo uma “inércia” para continuar na mesma direção em que estava indo nas iterações anteriores.

Como regra geral, valores mais altos de momentum (por exemplo, 0.9) podem ajudar a acelerar o treinamento, especialmente em problemas com muitos mínimos locais ou planaltos na função de perda. No entanto, um valor muito alto pode levar a oscilações excessivas e até mesmo prejudicar o desempenho. Em alguns casos, valores menores de momentum podem ser preferíveis.

A escolha do valor ideal muitas vezes envolve experimentação e ajuste fino. Recomenda-se começar com valores padrão (como 0.9) e ajustar conforme necessário com base no desempenho observado durante o treinamento. Realizar uma busca de hiperparâmetros ou utilizar métodos automatizados de ajuste de hiperparâmetros também pode ajudar a encontrar os melhores valores em uma variedade de contextos.

Mini-Batch Gradient Descent

O Mini-Batch Gradient Descent é uma variação do Gradiente Descendente em que, em vez de calcular o gradiente e fazer uma atualização de parâmetros usando o conjunto de dados completo (Batch Gradient Descent) ou apenas um exemplo por vez (Stochastic Gradient Descent), trabalhamos com mini lotes de dados. Cada atualização de parâmetro é realizada com base em um pequeno subconjunto (mini lote) dos dados de treinamento.

Usar o Gradiente Descendente Estocástico (SGD) com o DataLoader em PyTorch é bastante simples. O DataLoader lida com o embaralhamento dos dados e a divisão em mini lotes, enquanto o otimizador SGD é responsável pelas atualizações dos parâmetros do modelo.

import torch
import torch.nn as nn
import torch.optim as optim
from torch.utils.data import DataLoader, TensorDataset

# Criando dados fictícios
x_train = torch.randn((1000, 3, 64, 64))  # Exemplo de imagens (canais x altura x largura)
y_train = torch.randint(0, 2, (1000,))  # Exemplo de rótulos binários

# Criando um conjunto de dados PyTorch
dataset = TensorDataset(x_train, y_train)

# Criando um DataLoader
batch_size = 32
shuffle = True
num_workers = 4  # Número de processos de leitura em paralelo
data_loader = DataLoader(dataset, batch_size=batch_size, shuffle=shuffle, num_workers=num_workers)

# Criando um modelo de exemplo
class SimpleModel(nn.Module):
    def __init__(self):
        super(SimpleModel, self).__init__()
        self.fc = nn.Linear(3 * 64 * 64, 1)

    def forward(self, x):
        x = x.view(x.size(0), -1)  # Achatando as imagens para um vetor
        return self.fc(x)

# Criando uma instância do modelo
modelo = SimpleModel()

# Definindo a função de perda e o otimizador SGD
criterio = nn.BCEWithLogitsLoss()  # Para problemas de classificação binária
otimizador = optim.SGD(modelo.parameters(), lr=0.01)

# Treinando o modelo usando SGD e DataLoader
num_epochs = 10

for epoch in range(num_epochs):
    for inputs, labels in data_loader:
        # Forward pass
        outputs = modelo(inputs)
        loss = criterio(outputs.squeeze(), labels.float())

        # Backward pass e otimização
        otimizador.zero_grad()
        loss.backward()
        otimizador.step()

    print(f'Época [{epoch + 1}/{num_epochs}], Perda: {loss.item():.4f}')

# Saída
# Época [1/10], Perda: 0.9239
# Época [2/10], Perda: 0.1510
# Época [3/10], Perda: 0.1002
# Época [4/10], Perda: 0.0714
# Época [5/10], Perda: 0.0521
# Época [6/10], Perda: 0.0513
# Época [7/10], Perda: 0.0373
# Época [8/10], Perda: 0.0273
# Época [9/10], Perda: 0.0294
# Época [10/10], Perda: 0.0289

Neste exemplo:

• Criamos um DataLoader para o conjunto de dados usando a classe DataLoader.
• Definimos um modelo de exemplo (SimpleModel) para fins explicativos, didáticos.
• Utilizamos a função de perda BCEWithLogitsLoss, que é apropriada para problemas de classificação binária.
• Utilizamos o otimizador SGD para ajustar os parâmetros do modelo.
• Iteramos sobre os mini lotes gerados pelo DataLoader durante o treinamento, realizando o treinamento por várias épocas.

Este é um exemplo básico para demonstrar como usar o DataLoader em conjunto com o SGD para treinar um modelo. No dia-a-dia, teríamos que adaptar o modelo, a função de perda e outros hiperparâmetros para atender às necessidades específicas do seu problema.

Normalização em Lote

A Batch Normalization (normalização em lote) é uma técnica de regularização e normalização usada em redes neurais para melhorar a estabilidade e acelerar o treinamento. A ideia principal por trás da Batch Normalization é normalizar as ativações em cada camada, aplicando uma normalização em lote durante o treinamento.

A normalização em lote é aplicada a um mini lote de exemplos durante o treinamento e consiste em duas etapas principais:

1. Normalização: Normaliza as ativações de cada neurônio para ter média zero e desvio padrão um dentro do mini lote.
2. Escalonamento e Deslocamento (Scaling and Shifting): Introduz dois parâmetros treináveis (gama e beta) para reescalar e deslocar as ativações normalizadas. Isso permite que a rede aprenda a melhor representação dos dados.

A normalização em lote é aplicada antes da função de ativação em cada camada da rede. Isso ajuda a manter as ativações dentro de uma faixa mais estável, o que pode facilitar o treinamento. Além disso, a normalização em lote tem benefícios de regularização, agindo como um mecanismo de suavização do treinamento, reduzindo a dependência em relação à inicialização específica dos pesos e mitigando problemas como o desaparecimento ou explosão de gradientes.

A fórmula para normalização em lote em uma camada é dada por:

onde:

• x são as ativações da camada,
• μ é a média das ativações no mini lote,
• σ é o desvio padrão das ativações no mini lote,
• ϒ e β são parâmetros treináveis,
• ε é uma constante pequena para evitar a divisão por zero.

Em PyTorch, você pode usar a camada torch.nn.BatchNorm1d (ou torch.nn.BatchNorm2d para convoluções) para adicionar Batch Normalization a uma camada da rede.

import torch
import torch.nn as nn

class NeuralNetworkWithBatchNorm(nn.Module):
    def __init__(self, input_size, hidden_size, output_size):
        super(NeuralNetworkWithBatchNorm, self).__init__()
        self.fc1 = nn.Linear(input_size, hidden_size)
        self.bn1 = nn.BatchNorm1d(hidden_size)  # Adicionando Batch Normalization
        self.relu = nn.ReLU()
        self.fc2 = nn.Linear(hidden_size, output_size)

    def forward(self, x):
        x = self.fc1(x)
        x = self.bn1(x)  # Aplicando Batch Normalization antes da ativação
        x = self.relu(x)
        x = self.fc2(x)
        return x

Adicionar Batch Normalization à sua rede pode ajudar na estabilidade do treinamento, permitindo taxas de aprendizado mais altas e reduzindo a sensibilidade à inicialização dos pesos. Essa técnica é especialmente útil em redes mais profundas.

Divisão em Treinamento, Validação e Teste

No pipeline de ciencia de dados e comum dividir-mos os dados em um conjunto de treino, validação e teste.

Abaixo, implementamos um modelo de regressão linear, mas focando na explicação da divisão de treinamento, validação e teste e como utilizar cada um.

import torch
import torch.nn as nn
import torch.optim as optim
from torch.utils.data import DataLoader, TensorDataset
from sklearn.model_selection import train_test_split
import matplotlib.pyplot as plt

# Criando dados fictícios
torch.manual_seed(42)
X = torch.rand(1000, 1)  # Feature unidimensional
y = 2 * X + 1 + 0.1 * torch.rand(1000, 1)  # Regressão linear com ruído

# Dividindo os dados em treino, validação e teste
X_train, X_temp, y_train, y_temp = train_test_split(X, y, test_size=0.3, random_state=42)
X_val, X_test, y_val, y_test = train_test_split(X_temp, y_temp, test_size=0.5, random_state=42)

# Convertendo para tensores
X_train, y_train = torch.tensor(X_train, dtype=torch.float32), torch.tensor(y_train, dtype=torch.float32)
X_val, y_val = torch.tensor(X_val, dtype=torch.float32), torch.tensor(y_val, dtype=torch.float32)
X_test, y_test = torch.tensor(X_test, dtype=torch.float32), torch.tensor(y_test, dtype=torch.float32)

# Criando conjuntos de dados PyTorch
train_dataset = TensorDataset(X_train, y_train)
val_dataset = TensorDataset(X_val, y_val)
test_dataset = TensorDataset(X_test, y_test)

# Criando DataLoader para treino, validação e teste
batch_size = 32
train_loader = DataLoader(train_dataset, batch_size=batch_size, shuffle=True)
val_loader = DataLoader(val_dataset, batch_size=batch_size)
test_loader = DataLoader(test_dataset, batch_size=batch_size)

Neste primeira etapa, transformamos os dados em tensores utilizando o torch.tensor e, em seguida utilizamos o TensorDataset, para representar os valores como lista de tensores que entrarão como inputs para o modelo. Em seguida, utilizamos o DataLoader para selecionar amostras de cada conjunto de dados, utilizando o batch_size = 32, ou seja, é o número de amostras de dados que serão usadas em cada iteração durante o treinamento do modelo.

# Definindo um modelo de regressão linear simples
class LinearRegressionModel(nn.Module):
    def __init__(self):
        super(LinearRegressionModel, self).__init__()
        self.linear = nn.Linear(1, 1)

    def forward(self, x):
        return self.linear(x)

# Criando uma instância do modelo
model = LinearRegressionModel()

# Definindo a função de perda e o otimizador
criterion = nn.MSELoss()
optimizer = optim.SGD(model.parameters(), lr=0.01)

# Treinando o modelo
num_epochs = 500
train_losses, val_losses = [], []

for epoch in range(num_epochs):
    model.train()  # Modo de treino
    for inputs, labels in train_loader:
        optimizer.zero_grad()
        outputs = model(inputs)
        loss = criterion(outputs, labels)
        loss.backward()
        optimizer.step()

    # Calculando a perda no conjunto de treino
    model.eval()  # Modo de avaliação
    with torch.no_grad():
        total_val_loss = 0
        for inputs_val, labels_val in val_loader:
            outputs_val = model(inputs_val)
            val_loss = criterion(outputs_val, labels_val)
            total_val_loss += val_loss.item()

    average_val_loss = total_val_loss / len(val_loader)
    val_losses.append(average_val_loss)

    print(f'Época [{epoch + 1}/{num_epochs}], Perda de Treino: {loss.item():.4f}, Perda de Validação: {average_val_loss:.4f}')

# Testando o modelo
model.eval()  # Modo de avaliação
with torch.no_grad():
    total_test_loss = 0
    for inputs_test, labels_test in test_loader:
        outputs_test = model(inputs_test)
        test_loss = criterion(outputs_test, labels_test)
        total_test_loss += test_loss.item()

average_test_loss = total_test_loss / len(test_loader)
print(f'Perda no Conjunto de Teste: {average_test_loss:.4f}')

# Visualizando os resultados
plt.scatter(X_test, y_test, label='Dados Reais')
plt.plot(X_test, model(X_test).detach().numpy(), color='red', label='Regressão Linear Ajustada')
plt.xlabel('X')
plt.ylabel('y')
plt.legend()
plt.show()

Aqui, definimos o modelo e o instanciamos. Depois definimos a função de perda (criterion) e o otimizador. O modelo é treinado por um número fixo de épocas (500 neste caso). Para cada época, os dados de treinamento são passados pelo modelo, a perda é calculada usando a função de perda definida e os parâmetros do modelo são atualizados pelo otimizador.

Durante o treinamento, a perda no conjunto de validação é calculada para monitorar o desempenho do modelo em dados não vistos.

Após o treinamento, o modelo é testado no conjunto de teste para avaliar seu desempenho em dados completamente novos. A perda no conjunto de teste é calculada usando a função de perda.

Ao final, os resultados são visualizados plotando os dados reais do conjunto de teste e a linha da regressão linear ajustada pelo modelo. Isso ajuda a visualizar como o modelo se ajusta aos dados de teste.

Redes Neurais

Um neurônio em deep learning é uma unidade básica de processamento que recebe entradas, realiza uma série de operações matemáticas nelas (como multiplicação por pesos e soma ponderada), aplica uma função de ativação e produz uma saída.

Redes neurais são formadas por interconectar esses neurônios em camadas. Cada camada recebe entradas das camadas anteriores, processa essas entradas e passa as saídas para as camadas seguintes. Isso forma uma rede de processamento de informações, capaz de aprender padrões e realizar tarefas complexas.

Redes Neurais Rasas

Uma Shallow Neural Network (Rede Neural Rasa) refere-se a uma arquitetura de rede neural com apenas uma única camada oculta entre a camada de entrada e a camada de saída. Em outras palavras, uma rede neural rasa possui uma estrutura simples, com apenas uma camada intermediária contendo um número limitado de neurônios. A arquitetura básica de uma Shallow Neural Network é composta por três camadas principais:

• Camada de Entrada (Input Layer): Recebe os dados de entrada e transfere esses dados para a camada oculta.
• Camada Oculta (Hidden Layer): Realiza transformações nos dados recebidos da camada de entrada. Esta camada contém neurônios que aplicam transformações lineares seguidas de funções de ativação não lineares. A presença desta camada permite que a rede aprenda representações mais complexas dos dados.
• Camada de Saída (Output Layer): Produz a saída final da rede após processar os dados pela camada oculta. Dependendo da tarefa, a camada de saída pode ter um único neurônio (para problemas de regressão) ou vários neurônios (para problemas de classificação).

Embora uma Shallow Neural Network seja limitada em termos de capacidade de aprendizado em comparação com redes mais profundas, ela ainda pode ser eficaz para tarefas relativamente simples. Essa arquitetura é frequentemente utilizada em problemas onde os padrões nos dados podem ser aprendidos com uma quantidade menor de parâmetros.

• Menos Suscetíveis a Overfitting: Redes rasas geralmente têm menos parâmetros do que redes profundas, o que pode torná-las menos propensas a overfitting (ajuste excessivo) em conjuntos de dados menores.
• Treinamento Mais Rápido: Como há menos camadas e parâmetros para treinar, o treinamento de Shallow Neural Networks pode ser mais rápido em comparação com redes mais profundas.
• Limitações na Representação de Recursos Complexos: Redes rasas podem ter dificuldades em aprender representações hierárquicas profundas de características complexas presentes nos dados, o que pode limitar seu desempenho em tarefas mais desafiadoras.
• Aplicações: Shallow Neural Networks podem ser adequadas para problemas mais simples, como classificação binária, regressão linear, ou problemas onde os dados têm padrões que podem ser facilmente aprendidos com uma arquitetura mais simples.

À medida que a complexidade das tarefas aumenta, é comum recorrer a arquiteturas de redes mais profundas para extrair e aprender representações mais complexas e abstratas dos dados.
Redes Neurais Profundas

# Definindo a Shallow Neural Network
class ShallowNeuralNetwork(nn.Module):
    def __init__(self, input_size):
        super(ShallowNeuralNetwork, self).__init__()
        self.linear1 = nn.Linear(input_size, 10) # 10 neuronios na camada oculta
        self.relu = nn.ReLU() # funcao de ativacao da camada oculta
        self.linear2 = nn.Linear(10, 1) # 1 neuronio na camada de saida
        self.sigmoid = nn.Sigmoid() # funcao de ativacao da camada de saida

    def forward(self, x):
        x = self.relu(self.linear1(x))
        x = self.sigmoid(self.linear2(x))
        return x

Exemplo completo

import torch
import torch.nn as nn
import torch.optim as optim
from sklearn.datasets import make_classification
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler

# Gerando dados fictícios
X, y = make_classification(n_samples=1000, n_features=5, n_classes=2, n_clusters_per_class=1, random_state=42)

# Dividindo os dados em conjuntos de treino e teste
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

# Padronizando os dados (importante para redes neurais)
scaler = StandardScaler()
X_train = scaler.fit_transform(X_train)
X_test = scaler.transform(X_test)

# Convertendo os dados para tensores do PyTorch
X_train_tensor = torch.tensor(X_train, dtype=torch.float32)
y_train_tensor = torch.tensor(y_train, dtype=torch.float32).view(-1, 1)  # reshape para uma coluna
X_test_tensor = torch.tensor(X_test, dtype=torch.float32)
y_test_tensor = torch.tensor(y_test, dtype=torch.float32).view(-1, 1)  # reshape para uma coluna

# Definindo a Shallow Neural Network
class ShallowNeuralNetwork(nn.Module):
    def __init__(self, input_size):
        super(ShallowNeuralNetwork, self).__init__()
        self.linear1 = nn.Linear(input_size, 10)
        self.relu = nn.ReLU()
        self.linear2 = nn.Linear(10, 1)
        self.sigmoid = nn.Sigmoid()

    def forward(self, x):
        x = self.relu(self.linear1(x))
        x = self.sigmoid(self.linear2(x))
        return x

# Instanciando o modelo
input_size = X_train.shape[1]
model = ShallowNeuralNetwork(input_size)

# Definindo a função de perda (Binary Cross Entropy Loss) e o otimizador
criterion = nn.BCELoss()
optimizer = optim.SGD(model.parameters(), lr=0.01)

# Treinando o modelo
num_epochs = 500

for epoch in range(num_epochs):
    # Forward pass
    outputs = model(X_train_tensor)

    # Calculando a perda
    loss = criterion(outputs, y_train_tensor)

    # Backward pass e otimização
    optimizer.zero_grad()
    loss.backward()
    optimizer.step()

    # Imprimindo a perda a cada 50 épocas
    if (epoch + 1) % 50 == 0:
        print(f'Época [{epoch + 1}/{num_epochs}], Perda: {loss.item():.4f}')

# Avaliando o modelo no conjunto de teste
model.eval()  # Modo de avaliação
with torch.no_grad():
    predictions = model(X_test_tensor)
    binary_predictions = (predictions > 0.5).float()

# Calculando a acurácia do modelo no conjunto de teste
accuracy = (binary_predictions == y_test_tensor).float().mean()
print(f'Acurácia do modelo no conjunto de teste: {accuracy.item():.4f}')

# Saída
#Época [50/500], Perda: 0.6457
#Época [100/500], Perda: 0.6074
#Época [150/500], Perda: 0.5694
#Época [200/500], Perda: 0.5321
#Época [250/500], Perda: 0.4960
#Época [300/500], Perda: 0.4619
#Época [350/500], Perda: 0.4305
#Época [400/500], Perda: 0.4024
#Época [450/500], Perda: 0.3773
#Época [500/500], Perda: 0.3552
#Acurácia do modelo no conjunto de teste: 0.9150

Neste exemplo, criamos uma Shallow Neural Network com uma camada oculta contendo 10 neurônios. A função de ativação ReLU é usada na camada oculta, e a função de ativação Sigmoid é usada na camada de saída para lidar com a tarefa de classificação binária. O modelo é treinado usando o otimizador SGD (Stochastic Gradient Descent) e a função de perda Binary Cross Entropy Loss. O desempenho do modelo é avaliado no conjunto de teste.

Redes Neurais Profundas

Uma Deep Neural Network (DNN) ou Rede Neural Profunda , é simplesmente uma arquitetura de rede neural artificial que possui múltiplas camadas entre a entrada e a saída. Essa abordagem permite que a rede aprenda representações mais complexas e hierárquicas dos dados, tornando-a capaz de realizar tarefas mais sofisticadas e de lidar com características abstratas.

As DNNs são caracterizadas por sua profundidade, que é determinada pelo número de camadas que compõem a arquitetura. Cada camada da rede contém um conjunto de neurônios (também chamados de unidades ou nodos) que realizam operações de transformação nos dados de entrada. As camadas podem ser classificadas em três tipos principais:

1. Camada de Entrada (Input Layer): Recebe os dados de entrada e transmite-os para a primeira camada oculta.
2. Camadas Ocultas (Hidden Layers): São as camadas intermédias entre a camada de entrada e a camada de saída. Cada neurônio em uma camada oculta realiza transformações nos dados recebidos das camadas anteriores. A existência de múltiplas camadas ocultas permite que a rede aprenda representações cada vez mais complexas.
3. Camada de Saída (Output Layer): Produz a saída final da rede após processar os dados através das camadas ocultas. A arquitetura da camada de saída depende da tarefa que a rede está destinada a realizar (por exemplo, uma única unidade para regressão ou várias unidades para classificação multiclasse).

O treinamento de DNNs geralmente envolve o uso do algoritmo de backpropagation, que consiste na propagação do gradiente durante a fase de treinamento para ajustar os pesos da rede de acordo com um critério de desempenho (como a minimização da função de custo). A capacidade de treinar redes profundas foi impulsionada por avanços em algoritmos de otimização, funções de ativação eficazes e inicializações adequadas de pesos.

A popularização das DNNs contribuiu significativamente para avanços em campos como visão computacional, processamento de linguagem natural, reconhecimento de voz e muito mais. Exemplos notáveis de arquiteturas de DNNs incluem Redes Neurais Convolucionais (CNNs) para visão computacional e Redes Neurais Recorrentes (RNNs) para processamento de sequências temporais.

import torch
import torch.nn as nn
import torch.optim as optim
from torchvision import datasets, transforms
from torch.utils.data import DataLoader
import matplotlib.pyplot as plt

# Transformações para normalizar as imagens do MNIST
transform = transforms.Compose([transforms.ToTensor(), transforms.Normalize((0.5,), (0.5,))])

# Carregando os conjuntos de treino e teste do MNIST
train_dataset = datasets.MNIST(root='./data', train=True, download=True, transform=transform)
test_dataset = datasets.MNIST(root='./data', train=False, download=True, transform=transform)

# Criando DataLoader para os conjuntos de treino e teste
batch_size = 64
train_loader = DataLoader(train_dataset, batch_size=batch_size, shuffle=True)
test_loader = DataLoader(test_dataset, batch_size=batch_size, shuffle=False)

# Visualizando uma imagem do MNIST
sample_image, sample_label = next(iter(train_loader))
plt.imshow(sample_image[0][0], cmap='gray')
plt.title(f'Label: {sample_label[0]}')
plt.show()

# Definindo a arquitetura da DNN com mais camadas ocultas
class DeepNeuralNetwork(nn.Module):
    def __init__(self, input_size, hidden_size1, hidden_size2, output_size):
        super(DeepNeuralNetwork, self).__init__()
        # Camadas ocultas hidden_size1 e hidden_size2
        self.fc1 = nn.Linear(input_size, hidden_size1)
        self.relu1 = nn.ReLU()
        self.fc2 = nn.Linear(hidden_size1, hidden_size2)
        self.relu2 = nn.ReLU()
        # Camada de saída output_size
        self.fc3 = nn.Linear(hidden_size2, output_size)
        self.softmax = nn.Softmax(dim=1)

    def forward(self, x):
        # Camadas ocultas
        x = self.relu1(self.fc1(x))
        x = self.relu2(self.fc2(x))
        # Camada de saída
        x = self.softmax(self.fc3(x))
        return x

# Instanciando o modelo com mais camadas ocultas
input_size = 28 * 28  # Tamanho da imagem MNIST
hidden_size1 = 128  # Número de neurônios na primeira camada oculta
hidden_size2 = 64   # Número de neurônios na segunda camada oculta
output_size = 10    # Número de classes no MNIST (dígitos de 0 a 9)

model = DeepNeuralNetwork(input_size, hidden_size1, hidden_size2, output_size)

# Definindo a função de perda e o otimizador
criterion = nn.CrossEntropyLoss()
optimizer = optim.Adam(model.parameters(), lr=0.001)

# Treinando o modelo
num_epochs = 10

for epoch in range(num_epochs):
    for batch_images, batch_labels in train_loader:
        # Achatando as imagens para um vetor
        batch_images = batch_images.view(-1, 28 * 28)

        # Forward pass
        outputs = model(batch_images)

        # Calculando a perda
        loss = criterion(outputs, batch_labels)

        # Backward pass e otimização
        optimizer.zero_grad()
        loss.backward()
        optimizer.step()

    print(f'Época [{epoch + 1}/{num_epochs}], Perda: {loss.item():.4f}')

# Avaliando o modelo no conjunto de teste
model.eval()  # Modo de avaliação
correct = 0
total = 0

with torch.no_grad():
    for batch_images, batch_labels in test_loader:
        batch_images = batch_images.view(-1, 28 * 28)
        outputs = model(batch_images)
        _, predicted = torch.max(outputs.data, 1)
        total += batch_labels.size(0)
        correct += (predicted == batch_labels).sum().item()

accuracy = correct / total
print(f'Acurácia do modelo no conjunto de teste: {accuracy:.4f}')

# Saída
#Época [1/10], Perda: 1.5257
#Época [2/10], Perda: 1.4962
#Época [3/10], Perda: 1.5844
#Época [4/10], Perda: 1.5775
#Época [5/10], Perda: 1.5120
#Época [6/10], Perda: 1.5854
#Época [7/10], Perda: 1.4931
#Época [8/10], Perda: 1.5444
#Época [9/10], Perda: 1.4860
#Época [10/10], Perda: 1.4744
#Acurácia do modelo no conjunto de teste: 0.9569

nn.ModuleList()

O nn.ModuleList é uma classe no PyTorch que permite criar uma lista de módulos (camadas) em um modelo. Isso é útil quando você deseja criar uma arquitetura de rede com várias camadas, e o número de camadas pode variar dinamicamente. O nn.ModuleList facilita a gestão de uma sequência de camadas em seu modelo.

import torch
import torch.nn as nn

class DynamicNet(nn.Module):
    def __init__(self, input_size, hidden_sizes, output_size):
        super(DynamicNet, self).__init__()

        # Lista de camadas ocultas
        self.hidden_layers = nn.ModuleList([
            nn.Linear(input_size, hidden_sizes[0]),
            nn.ReLU()])

        # Loop para adicionar as demais camadas internas
        for i in range(1, len(hidden_sizes)):
            self.hidden_layers.extend([
                nn.Linear(hidden_sizes[i - 1], hidden_sizes[i]),
                nn.ReLU()])

        # Camada de saída
        self.output_layer = nn.Linear(hidden_sizes[-1], output_size)

    def forward(self, x):
        for layer in self.hidden_layers:
            x = layer(x)
        output = self.output_layer(x)
        return output

# Exemplo de uso
input_size = 10
hidden_sizes = [32, 64, 128]
output_size = 1

model = DynamicNet(input_size, hidden_sizes, output_size)
print(model)

# Saída
#DynamicNet(
#  (hidden_layers): ModuleList(
#    (0): Linear(in_features=10, out_features=32, bias=True)
#    (1): ReLU()
#    (2): Linear(in_features=32, out_features=64, bias=True)
#    (3): ReLU()
#    (4): Linear(in_features=64, out_features=128, bias=True)
#    (5): ReLU()
#  )
#  (output_layer): Linear(in_features=128, out_features=1, bias=True)
#)

Ao usar nn.ModuleList, estamos garantindo que ambas as camadas (a camada linear e a função de ativação ReLU) sejam tratadas como parte do modelo. Isso é fundamental para que o PyTorch rastreie e otimize os parâmetros durante o treinamento, além de facilitar a manipulação de várias camadas em uma rede neural dinâmica. Essa abordagem é especialmente útil quando se cria redes com arquiteturas variáveis.

for i in range(1, len(hidden_sizes)):
    self.hidden_layers.extend([
        nn.Linear(hidden_sizes[i - 1], hidden_sizes[i]),
        nn.ReLU()
    ])

Este loop é responsável por criar uma sequência de camadas ocultas na rede neural.

1. for i in range(1, len(hidden_sizes)):: O loop percorre os elementos da lista hidden_sizes a partir do segundo elemento (índice 1). O motivo de começar do segundo elemento é porque estamos criando conexões entre camadas adjacentes.
2. nn.Linear(hidden_sizes[i - 1], hidden_sizes[i]): Aqui, estamos criando uma camada linear (totalmente conectada) que conecta a camada oculta anterior (com hidden_sizes[i - 1] neurônios) à próxima camada oculta (com hidden_sizes[i] neurônios). Isso permite que a rede aprenda representações mais complexas à medida que avança nas camadas ocultas.
3. nn.ReLU(): Em seguida, adicionamos uma camada de ativação ReLU. A função de ativação ReLU (Rectified Linear Unit) introduz não-linearidades na rede, permitindo que ela aprenda padrões mais complexos e não lineares nos dados.
4. self.hidden_layers.extend([...]): Aqui, usamos o método extend de nn.ModuleList para adicionar as camadas criadas ao final da lista de camadas ocultas. O método extend é usado porque queremos adicionar múltiplos módulos de uma vez.

Ao usar nn.ModuleList, o PyTorch rastreia automaticamente os parâmetros dessas camadas, tornando-os parte do modelo. Isso é crucial para garantir que a retropropagação e a atualização dos pesos ocorram corretamente durante o treinamento.

Ao criar seu modelo, você pode ajustar o tamanho da lista hidden_sizes para adicionar ou remover camadas ocultas conforme necessário.

Funções de Ativação

As funções de ativação são elementos-chave em redes neurais, adicionando não-linearidades às saídas dos neurônios. Elas são responsáveis por introduzir complexidade e capacidade de aprendizado não linear aos modelos, permitindo que as redes neurais aproximem funções mais complexas. Algumas das funções de ativação mais comuns:

Sigmoide:

• Fórmula: σ(x)= 1 / 1+e ^-x
• Intervalo de Saída: (0, 1)
• Uso: Originalmente usada em problemas de classificação binária, mas tem caído em desuso em camadas internas de redes profundas devido ao problema do “vanishing gradient”.

Tangente Hiperbólica (tanh):

• Fórmula: tanh⁡(x)= e^x-e^-z / e^x + e^-z
• Intervalo de Saída: (-1, 1)
• Uso: Similar à sigmoide, mas com saída variando de -1 a 1. Pode ser usada em camadas internas.

ReLU (Rectified Linear Unit):

• Fórmula: ReLU(x)=max(0,x)
• Intervalo de Saída: [0, +∞)
• Uso: Muito popular devido à sua simplicidade e eficácia. Ajuda a mitigar o problema do “vanishing gradient”, mas pode levar a problemas de “dying ReLU” quando os neurônios ficam inativos.

Leaky ReLU:

• Fórmula: Leaky ReLU(x)=max(αx,x) onde α é uma constante pequena, geralmente próxima de 0.
• Intervalo de Saída: (-∞, +∞)
• Uso: Introduz um leve componente linear para evitar o problema de “dying ReLU”.

Função de Unidade Linear Exponencial (ELU):

• Fórmula:

• Intervalo de Saída: (-∞, +∞)
• Uso: Similar ao Leaky ReLU, com uma suavização nas regiões negativas.

Softmax:

• Fórmula: Softmax(x)i= e^zi/∑_j e^zj para cada i na saída.
• Intervalo de Saída: [0, 1] e a soma de todas as saídas é 1.
• Uso: Principalmente usado na camada de saída para problemas de classificação multiclasse, onde as saídas representam probabilidades.

Essas são apenas algumas das muitas funções de ativação disponíveis. A escolha da função de ativação depende do problema específico, da arquitetura da rede e da natureza dos dados. Experimentar diferentes funções de ativação pode ser crucial para alcançar o melhor desempenho em uma tarefa específica. Abaixo sintetizamos algumas das funções de ativação existentes.

• Não Saturante: Indica se a função de ativação é não saturante, ou seja, se ela não satura para valores extremos. “Saturar” refere-se ao comportamento da função quando a entrada ultrapassa um determinado limite, resultando em uma saída constante. Isso significa que, à medida que a entrada aumenta, a saída da função de ativação atinge um valor máximo ou mínimo e permanece constante para entradas subsequentes
• Rápido: Refere-se à rapidez computacional da função de ativação, indicando se é computacionalmente eficiente.
• Binária: Relaciona-se com o uso da função de ativação em camadas de saída binárias, como em problemas de classificação binária.
• Varia entre -1 e 1: Indica se a função de ativação produz saídas que variam entre -1 e 1, sendo útil para dados centrados.
• Probabilidades: Mostra se a função de ativação é comumente usada para converter saídas em probabilidades, frequentemente usado em problemas de classificação.
• Evita Morte Neuronal: Indica se a função de ativação possui características que ajudam a evitar a “morte” de neurônios durante o treinamento.
• Paramétrico: Refere-se a funções de ativação que têm parâmetros que são aprendidos durante o treinamento, como o coeficiente em ReLU paramétrico (PReLU).
• Suavização Negativa: Indica se a função de ativação tem suavização para valores negativos, como no caso da Exponential Linear Unit (ELU).
• Auto-Normalizante: Refere-se a funções de ativação que têm a capacidade de auto-normalização, como a Scaled Exponential Linear Unit (SELU).
• Suave e Diferenciável: Indica se a função de ativação é suave e diferenciável, o que é desejável para facilitar o treinamento com otimizadores que requerem derivadas.

Essas características são importantes ao escolher uma função de ativação, pois diferentes cenários e arquiteturas de rede podem se beneficiar de propriedades específicas de cada função.

Backpropagation

Backpropagation, que significa propagação para trás, é um algoritmo fundamental no treinamento de redes neurais. Ele é utilizado para ajustar os pesos da rede de forma a minimizar a função de custo durante o processo de treinamento supervisionado. A ideia principal do backpropagation é calcular gradientes em relação aos pesos da rede, permitindo a atualização dos pesos de forma a reduzir o erro da rede. Principais passos do algoritmo de backpropagation:

1. Feedforward (Propagação Direta): Durante a fase de feedforward, a entrada é passada pela rede, camada por camada, até a camada de saída. Cada neurônio realiza uma transformação linear seguida de uma função de ativação.
2. Cálculo da Função de Custo: A saída da rede é comparada com as saídas reais (rótulos) para calcular a função de custo, que representa o quão longe as previsões da rede estão dos rótulos desejados.
3. Backpropagation (Propagação para Trás): O objetivo do backpropagation é calcular os gradientes da função de custo em relação aos pesos da rede. Isso é feito iterativamente, começando pela última camada e indo em direção à primeira. Os gradientes são calculados usando a regra da cadeia.
4. Atualização dos Pesos: Com os gradientes calculados, os pesos da rede são ajustados para minimizar a função de custo. Isso é geralmente feito usando um algoritmo de otimização, como o Gradiente Descendente ou suas variantes.
5. Iteração: Os passos 1 a 4 são repetidos por várias épocas (ou iterações) até que a rede neural atinja um desempenho aceitável no conjunto de treino.

Os passos acima são os que são codficados no loop de treinamento. É importante observar que o sucesso do backpropagation depende da diferenciabilidade das funções de ativação utilizadas na rede, pois a regra da cadeia e o cálculo dos gradientes dependem dessa propriedade. A diferenciabilidade é uma propriedade fundamental de funções matemáticas que expressa a capacidade de calcular derivadas em cada ponto do seu domínio. Uma função é considerada diferenciável em um determinado ponto se a sua derivada existe nesse ponto.

A regra da cadeia é fundamental para o backpropagation. Se C é a função de custo, a é a saída da rede, e w é um dos pesos da rede, então o gradiente dC/dw pode ser calculado como:

onde z é a entrada ponderada para um neurônio (z=∑^i_=1(wi⋅xi)+b), a é a saída após a aplicação da função de ativação, e C é a função de custo.

O backpropagation é uma técnica poderosa que tornou possível treinar redes neurais profundas. Atualmente, frameworks de aprendizado profundo, como PyTorch e TensorFlow, implementam o backpropagation automaticamente, facilitando sua aplicação em uma variedade de problemas.

O problema do “vanishing gradient”

O problema do “vanishing gradient” (gradiente desaparecendo) é uma questão que pode ocorrer durante o treinamento de redes neurais, especialmente em arquiteturas profundas. Esse problema está relacionado à propagação do gradiente durante a fase de backpropagation, e ocorre quando os gradientes das camadas mais profundas se tornam muito pequenos, aproximando-se de zero. Como resultado, os pesos dessas camadas são ajustados muito lentamente ou quase não são ajustados durante o treinamento. Esse problema pode acontecer nos seguintes casos:

1. Funções de Ativação Sigmóide e Tangente Hiperbólica: Funções de ativação como a sigmóide e a tangente hiperbólica têm uma feature em que suas derivadas se aproximam de zero para valores extremos. Quando a propagação do gradiente ocorre através de várias camadas, essas derivadas multiplicadas entre si podem resultar em gradientes muito pequenos nas camadas mais profundas.
2. Inicialização inadequada de pesos: A inicialização inadequada dos pesos da rede também pode contribuir para o problema do vanishing gradient. Se os pesos iniciais forem muito pequenos, os gradientes nas camadas anteriores também serão pequenos, o que pode ser amplificado ao longo das camadas.
3. Arquitetura da Rede: Em arquiteturas muito profundas, os gradientes podem diminuir exponencialmente à medida que se propagam para trás, tornando-se insignificantes nas camadas mais profundas.
4. Problema de Longo Prazo (Long-Term Dependency): O vanishing gradient é particularmente preocupante em modelos que precisam capturar dependências a longo prazo, como em redes recorrentes (RNNs). A propagação do gradiente ao longo de muitos passos temporais pode resultar em gradientes que desaparecem ou explodem.

Para mitigar o problema do vanishing gradient, várias técnicas podem ser utilizadas, como:

• Escolha de Funções de Ativação: O uso de funções de ativação que não sofrem tanto com o problema do vanishing gradient, como a ReLU (Rectified Linear Unit), pode ajudar a mitigar esse problema.
• Inicialização Adequada de Pesos: Estratégias de inicialização de pesos, como a inicialização de He ou Xavier, podem ajudar a evitar que os pesos comecem muito pequenos.
• Normalização de Lote (Batch Normalization): A normalização de lote pode ajudar a manter ativações e gradientes em uma escala razoável durante o treinamento, o que pode ajudar a prevenir o vanishing gradient.
• Uso de Arquiteturas Específicas: Arquiteturas projetadas para mitigar o problema do vanishing gradient, como as conexões residuais em ResNets, podem ser utilizadas.

O vanishing gradient é um desafio significativo em treinamento de redes neurais profundas, e abordá-lo adequadamente é crucial para garantir que a rede possa aprender efetivamente representações complexas dos dados.

Dropout

Dropout é uma técnica de regularização usada em redes neurais para reduzir o overfitting durante o treinamento. O overfitting ocorre quando um modelo se ajusta demais aos dados de treinamento e tem dificuldade em generalizar para novos dados. O dropout é projetado para evitar que unidades específicas em uma rede neural se tornem excessivamente especializadas, melhorando assim a generalização do modelo.

A ideia principal do dropout é “eliminar” aleatoriamente unidades (neurônios) durante o treinamento. Durante cada iteração de treinamento, um conjunto aleatório de unidades é “desligado” (ou “dropado”), o que significa que suas contribuições para a propagação para frente e para trás são temporariamente removidas. Isso simula a ideia de treinar diferentes sub-redes em cada iteração, e o modelo precisa aprender a ser robusto mesmo quando partes aleatórias da rede são desativadas.

A implementação do dropout é bastante simples. Na prática, você adiciona uma camada de dropout após as camadas de ativação em sua rede neural. O dropout é geralmente aplicado apenas durante o treinamento e não durante a inferência ou avaliação.

No PyTorch, você pode usar a camada nn.Dropout para implementar o dropout em sua rede. Aqui está um exemplo de como adicionar dropout a uma rede em PyTorch:

import torch
import torch.nn as nn

class NeuralNetworkWithDropout(nn.Module):
    def __init__(self, input_size, hidden_size, output_size, dropout_rate=0.5):
        super(NeuralNetworkWithDropout, self).__init__()

        self.fc1 = nn.Linear(input_size, hidden_size)
        self.relu1 = nn.ReLU()
        self.dropout = nn.Dropout(p=dropout_rate)  # Adicionando a camada de dropout
        self.fc2 = nn.Linear(hidden_size, output_size)

    def forward(self, x):
        x = self.fc1(x)
        x = self.relu1(x)
        x = self.dropout(x)  # Aplicando o dropout após a ativação
        x = self.fc2(x)
        return x

Neste exemplo, a camada nn.Dropout é adicionada após a primeira camada de ativação (nn.ReLU). O parâmetro p em nn.Dropout representa a probabilidade de desativar uma unidade durante o treinamento. Um valor típico para dropout_rate é 0.5, o que significa que, em média, metade das unidades será desativada durante cada iteração de treinamento.

Dropout é uma ferramenta eficaz para melhorar a generalização de modelos de redes neurais e é comumente usado em diversas arquiteturas de redes neurais.

Pesos e Inicialização da Rede Neural

A inicialização adequada dos pesos em uma rede neural é crucial para o sucesso do treinamento do modelo. Peso inicializado de maneira inadequada pode levar a problemas como convergência lenta, convergência para mínimos locais ou até mesmo a falta de convergência. Algumas técnicas comuns de inicialização de pesos usadas em redes neurais são:

• Inicialização Aleatória: Inicializar os pesos com valores aleatórios é uma abordagem comum, onde os pesos são inicializados com números retirados de uma distribuição uniforme ou normal. No entanto, essa abordagem pode levar a problemas, especialmente em redes profundas, onde o gradiente pode diminuir ou explodir durante a retropropagação.
• Inicialização de Xavier/Glorot: Proposta por Xavier Glorot, esta abordagem ajusta a escala dos pesos com base no número de unidades nas camadas de entrada e saída. Os pesos são inicializados a partir de uma distribuição normal com média zero e variância 2 / número de entradas + número de saídas ou uma distribuição uniforme entre −a e a, onde a é a raíz de 6 / número de entradas + numero de saidas.
• Inicialização de He: Semelhante à inicialização de Xavier, mas ajusta a escala de acordo com apenas o número de unidades na camada de entrada. Os pesos são inicializados a partir de uma distribuição normal com média zero e variância 2/número de entradas ou uma distribuição uniforme entre −a e a, onde a é 6/número de entradas.
• Inicialização de LeCun: Similar à inicialização de Xavier, mas utiliza uma constante diferente para ajustar a escala dos pesos. Os pesos são inicializados a partir de uma distribuição normal com média zero e variância 1/número de entradas ou uma distribuição uniforme entre −a e a, onde a é 3/número de entradas.
• Inicialização de Orthogonal: Inicializa os pesos de tal forma que a matriz de pesos é ortogonal. Essa abordagem é útil para arquiteturas que envolvem recorrência.

Em PyTorch, muitas dessas inicializações podem ser facilmente implementadas usando as funções de inicialização fornecidas no módulo torch.nn.init. Por exemplo, você pode usar torch.nn.init.xavier_uniform_ ou torch.nn.init.kaiming_uniform_ para inicializações de Xavier ou He, respectivamente.

A escolha da inicialização de pesos depende da arquitetura da rede, do tipo de função de ativação utilizada e do contexto específico do problema. Experimentar diferentes técnicas de inicialização pode ser benéfico para encontrar a que melhor se adapta ao seu modelo.

import torch
import torch.nn as nn
import torch.nn.init as init

# Definindo uma rede neural simples com inicialização de Xavier
class SimpleNet(nn.Module):
    def __init__(self, input_size, hidden_size, output_size):
        super(SimpleNet, self).__init__()
        self.fc1 = nn.Linear(input_size, hidden_size)
        self.relu = nn.ReLU()
        self.fc2 = nn.Linear(hidden_size, output_size)

        # Inicialização de Xavier para as camadas lineares
        init.xavier_uniform_(self.fc1.weight)
        init.xavier_uniform_(self.fc2.weight)

    def forward(self, x):
        x = self.fc1(x)
        x = self.relu(x)
        x = self.fc2(x)
        return x

# Parâmetros da rede
input_size = 10
hidden_size = 20
output_size = 5

# Instanciando a rede neural
model = SimpleNet(input_size, hidden_size, output_size)

# Exibindo a arquitetura da rede e os pesos
print(model)
print("\nPesos após a inicialização de Xavier:")
for name, param in model.named_parameters():
    if 'weight' in name:
        print(name, param.data)

Além disso podemos inicializar todos os pesos de uma rede sem passar camada por camada utilizando um loop sobre todos os parâmetros da rede.

import torch
import torch.nn as nn
import torch.nn.init as init
import torch.optim as optim
from torch.utils.data import DataLoader, TensorDataset

# Função para inicializar todos os pesos da rede usando Xavier
def initialize_weights(model):
    for param in model.parameters():
        if len(param.shape) > 1:  # Inicializa apenas os pesos (não bias) das camadas lineares
            init.xavier_uniform_(param)

# Definindo uma rede neural simples para regressão
class RegressionNet(nn.Module):
    def __init__(self, input_size, hidden_size, output_size):
        super(RegressionNet, self).__init__()
        self.fc1 = nn.Linear(input_size, hidden_size)
        self.relu = nn.ReLU()
        self.fc2 = nn.Linear(hidden_size, output_size)

    def forward(self, x):
        x = self.fc1(x)
        x = self.relu(x)
        x = self.fc2(x)
        return x


# Instanciando a rede neural
model = RegressionNet(input_size, hidden_size, output_size)

# Inicializando todos os pesos da rede usando a função definida
initialize_weights(model)

Neste exemplo, a função initialize_weights percorre todos os parâmetros da rede e inicializa apenas os pesos (não bias) das camadas lineares usando a inicialização de Xavier. A função é chamada antes do treinamento para garantir que todos os pesos estejam inicializados corretamente.

Conclusão

O Pytorch é uma ferramenta essencial para criação de redes neurais e que possui diversas vantagens, como facilidade de prototipagem, suporte nativo a GPUs, sua integração com outras bibliotecas como numpy e scipy e também sua comunidade ativa. Com ele, podemos resolver problemas de diversas áreas e vários tipos de tarefas, como de visão computacional, NLP, Áudio e Processamento de sinais, Jogos e Robótica. Neste artigo, abordamos desde os fundamentos de machine learning com Pytorch, passando em diversos tópicos desde tensores ao treinamento, e validação de modelos e também em redes neurais rasas e profundas, assim como vários conceitos importantes como Funções de ativação, backpropagation, vanishing gradient e como incializar os pesos da rede.

Me siga clicando aqui para acompanhar mais blog posts sobre ciência de dados, machine learning, NLP e demais temas.

Como Citar

Guimarães, Alysson. (Fev 2024). Deep Neural Network com Pytorch. https://medium.com/data-hackers/. https://medium.com/data-hackers/p-552abf6bed10

ou

@miscellaneous{guimaraes2024dnnpytorch,
 title = {Deep Neural Network com Pytorch},
 author = {Guimarães, Alysson},
 journal = {https://medium.com/data-hackers/},
 year = {2024},
 month = {Fev},
 url = {https://k3ybladewielder.medium.com/p-88d01ccbf604}
}

Deep Neural Network com Pytorch was originally published in Data Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introdução

O advento de aplicações baseadas em modelos de linguagem pré-treinados a partir do lançamento do chatgpt em novembro de 2022, tem atraído um interesse de uma grande parte da população, desde curiosos early adopters de novas tecnologias, grandes empresas e também novos pesquisadores e novas áreas de pesquisa. Quase que diariamente novos modelos com diferente número de parâmetros, e uma infinidade de variações e evoluções de modelos e formas de treinamento são lançados quase que diariamente desde então. Com o crescimento e evolução dos modelos, novos focos de pesquisa foram surgindo, como os evidenciados na detecção das chamadas “habilidades emergentes” de large language models (LLM), como compreensão de linguagem (natural language understanding), codificação de conhecimentos implícitos nos parâmetros, aprendizado contextual (in-context learning), resolução de tarefas mais complexas e também, a habilidade de raciocinar, que será o foco deste post. Natural Language Reasoning (NLR) é o campo de Natural Language Process (NLP) em que se estuda e utiliza o raciocínio em linguagem natural para resolução de tarefas, em que a conclusão é um conhecimento novo. Este post abordará os estudos sobre NLR, as abordagens existentes, técnicas utilizadas para potencializar essa habilidade de raciocinar e como essa habilidade é avaliada.

Modelos de Linguagem Pré-treinados

Modelos de linguagem pre-treinados (PLMs) são baseados na arquitetura transformers e treinados com uma quantidade massiva de textos via aprendizado não supervisionado. Eles podem ser divididos em encoder-only, decoder-only e encoder-decoder, como o BERT, GPT e o T5 respectivamente. Além disso, também são bidirecionais (encoder-only) ou causais (decoder-only e encoder-decoder). Os modelos bidirecionais são utilizados para tasks discriminativas, ou seja, classificação entre diferentes categorias ou classes (ex. classificação de frases ou NER). Enquanto que os modelos causais são geralmente usados em tarefas generativas.

Devido à sua forma de treinamento, que resulta na criação de representações numéricas contextuais (pragmáticas) de palavras e frases, e à tendência recente de aumentar consideravelmente o número de parâmetros, alguns estudos revelaram que PLMs suficientemente grandes, como aqueles com mais de 100 bilhões de parâmetros, exibem habilidades emergentes. Estas incluem a capacidade de compreender linguagem (natural langauge understanding), assimilar conhecimentos implícitos em seus parâmetros, in-context learning e habilidades para resolver tarefas mais complexas. Outra habilidade emergente observada foi a capacidade de “raciocinar”, demonstrando padrões de raciocínio semelhantes aos descritos na literatura cognitiva humana. No entanto, a razão por trás dessa habilidade emergente ainda não é completamente compreendida.

Além disso, esses modelos demonstraram a capacidade de aprender por meio de poucas demonstrações (few-shot learning). Isso resultou na popularização do in-context learning como um paradigma, no qual previsões podem ser feitas com apenas algumas demonstrações, sem a necessidade de ajuste fino de hiperparâmetros. Diante desse grande potencial, esses modelos têm sido amplamente aplicados em tarefas de raciocínio.

Natural Language Reasoning

Raciocinar é o processo de pensar sobre algo de maneira lógica e sistemática, utilizando evidências e experiências passadas para chegar a conclusões ou tomar decisões. Esse processo engloba a realização de inferências, a avaliação de argumentos e a formulação de conclusões lógicas com base nas informações disponíveis. Essa atividade desempenha um papel crucial em diversas atividades intelectuais, incluindo a resolução de problemas, a tomada de decisões e o pensamento crítico.

O estudo do raciocínio é fundamental em diferentes campos, tais como psicologia, filosofia, ciência da computação, ciência cognitiva, entre outros. Ele fornece insights valiosos sobre como os seres humanos processam informações, tomam decisões e enfrentam desafios intelectuais. Compreender o raciocínio é essencial não apenas para o avanço dessas disciplinas acadêmicas, mas também para aplicação prática em diversas áreas da vida.

O Natural Language Reasoning (NLR) ou raciocínio em linguagem natural é um processo que integra diversos conhecimentos para derivar novas conclusões sobre o mundo, seja ele realista ou hipotético, utilizando modelos de linguagem pré-treinados (PLMs). Esse processo envolve inferir conclusões a partir de um conjunto de premissas, que consistem em uma ou mais etapas (inference steps), onde as premissas afirmam a veracidade ou falsidade de algo. O conhecimento utilizado nesse processo pode ser proveniente de fontes explícitas e implícitas.

Ao contrário de outras tarefas, como Question-Answer ou Information Retrieval, em que a resposta está contida nas informações existentes, no raciocínio, a conclusão representa uma nova informação. Esse aspecto destaca a capacidade dos modelos de linguagem pré-treinados em realizar inferências mais complexas e gerar insights que não estão diretamente expressos nas premissas. O Natural Language Reasoning desempenha um papel crucial em diversas aplicações, contribuindo para uma compreensão mais profunda e abrangente das relações e implicações presentes nos dados linguísticos, além de trazer explicabilidade para os outputs e potencializar a interação homem-maquina já que está sendo utilizado linguagem natural, coisa que era difícil ao utilizar linguagem formal ou simbólica.

O processo de inferência pode ser dividido em (pelo menos) três: Dedução, indução e abdução.

• Uma inferência dedutiva é inferir conhecimentos válidos (conclusão) do conhecimento dado (premissas). Ou seja, a conclusão é desenhada baseado na validade das premissas. Se as premissas são verdadeiras, obrigatoriamente a conclusão também o será.
• Inferência indutiva é inferir um conhecimento provável, que descreve uma regra geral, extrapolada do conhecimento dado. É o tipo de raciocínio em que a conclusão é baeado nas observações ou evidencias. A conclusão é provavelmente verdadeira baseado nas evidências disponíveis.
• Inferência abdutiva é inferir um conhecimento plausível, como a melhor explicação (causa), para dado conhecimento (fenômeno). É o tipo de raciocínio em que a conclusão é baseada na melhor explicação para um conjunto de observações, é baseado na plausabilidade.

Além disso, as inferências podem ser monotônicas (dedução) e defeasible (indução e abdução) ou revogável. A primeira busca derivar conclusões válidas, ou seja, suportado pelas premissas, e a segunda busca produzir conclusões plausíveis. Essa diferença entre esses dois tipos acarreta diferentes características, como as relações de inferência entre premissas e conclusões, qualidade da inferência, e o conhecimento requerido, e o reasoning path para chegar na conclusão.

É importante frisar que quando falamos de raciocínio em PLMs, não é exatamente o mesmo raciocíonio performado por humanos, e sim uma capacidade de mimetização dele, mas o funcionamento em si não tem nada em comum com o raciocínio humano, assim como uma rede neural é simplesmente uma representação simplificada e bioinspirada, e não é igual e não funciona igual aos neuronios humanos.

Abordagens de NLR

Existem três abordagens de NLR, o end-to-end reasoning, forward reasoning e backward reasoning. A principal diferença entre cada método está na etapa de raciocínio que é criado.

• End-to-end reasoning somente gera o output, sem nenhuma explicação ou conclusão intermediária, reasoning path, ou se foi necessário um ou vários passos para gerar o output. É uma abordagem black box, já que não temos acesso a forma em que o output foi gerado. Para um modelo executar essa abordagem, é preciso agregar multiplos conhecimentos e raciocinar sobre eles.
• Forward reasoning compõem o conhecimento existente (codificado no modelo) repetidamente para derivar novos conhecimentos até alcançar as respostas. Esse processo gera as etapas de raciocínio, criando confiabilidade e interpretabilidade dos outputs
• Backward reasoning quebra o problema em vários subproblemas, e os resolve até encontrar a resposta. Assim como o forward reasoning, pode ser usado para criar confiabilidade com as etapas de raciocínio, além de aumentar a performace do output.

Técnicas para impulsionar o raciocínio em PLMs

Com base em pesquisas que identificaram e demonstraram as capacidades de aprendizado contextual e raciocínio, foram elaboradas técnicas visando expandir o aproveitamento dessas habilidades.

Diversas estratégias são empregadas para aprimorar e potencializar os resultados do modelo, estimulando as capacidades de raciocínio dos Modelos de Linguagem Pré-treinados (PLMs). Isso inclui o ajuste fino supervisionado completo (Fully Supervised Finetuning), técnicas de engenharia de prompts direcionadas às habilidades de aprendizado contextual, como o chain-of-thought e suas variantes, engenharia de justificativas (rationale engineering) e decomposição de problemas (problem decomposition).

Fully Supervised Finetuning

Os modelos podem ser ajustados pare gerarem justificativas, etapas de raciocínio, que levam as respostas certas, levando a aumentar a capacidade de raciocínio dos modelos. Além disso, existem pesquisas focadas em melhorar a capacidade de raciocínio de modelos de linguagem menores através de fully supervised finetuning em datasets. Essa abordagem varia muito foca em modelos menores, treinados em datasets específicos.

Chain-of-thougt (CoT)

Modelos suficientemente grandes como o GPT-3 demonstraram desempenhos superiores em diversas tasks ao utilizar in-context learning. Para encorajar os modelos a raciocinar em vez de simplesmente responder diretamente (end-to-end reasoning), podemos guiar o modelo para gerar “raciocínio” explícitamente. A abordagem de chain of thougt (CoT) faz exatamente isso.

Essa abordagem envolve dar alguns exemplos de “chain of thought”, com passos intermediários de raciocínio em linguagem natural (NLR) para o modelo. Desse modo, dado uma pergunta, o modelo aprende a gerar justificativas antes da resposta final.

Rationale Engineering

Rationale Engineering é criar exemplos manualmente de etapas intermediárias de raciocínio e aplicar um greedy decoding em sua geração. O objetivo é aumentar efetivamente ou utilizar o raciocínio dos LLMs. Isso pode ser alcançado através de rationale refinement, que é a criação de exemplos mais efetivos ou rationale exploration e rationale verification, que é a exploração e verificação das justificativas criadas pelos modelos de linguagem

Problem Decomposition

Problem decomposition busca resolver o problema de tarefas complexas, em que os modelos tem problemas com abordagens de in-context learning. Consiste em quebrar o problema em problema menores, e ao resolver cada subproblema, podemos efetivamente resolver um problema complexo.

Métodos Híbridos

Os métodos híbridos (propmpt + problem decomposition) foram desenvolvidos para melhorar a performace das capacidades de raciocínio (não somente utilizá-las através de prompts) e fazer um moelhor uso desses modelos para resolução de tarefas complexas. Ou seja, são feitas modificações nos parâmetros dos modelos, para ajustálos de forma a melhorar a capacidade de raciocínio. Essa abordagem envolve tanto a melhoria das capacidades de raciocínio e o uso de técnicas de prompt para efetivamente utilizar essas capacidades.

Uma abordagem é o reasoning-enhanced training, que consiste no pre treino ou finetune do modelo em datasets que incluem “raciocínio”.

Outra abordagem híbrida é o Bootstrapping & Self-improving, que é o auto-aperfeiçoamento das habilidades de raciocínio através de bootstrapping. Nessa abordagem, um LLM é treinado e refinado iterativamente com seu próprio output, como o Self-Taught Reasoner (STaR). O modelo gera as primeiras justificativas com CoT, e depois ele é ajustado nas justificativas que levam a respostas corretas, esse processo pode ser repetido, em que cada iteração resulta numa melhoria do modelo que pode gerar melhores dados de treinamento.

Avaliação e Análises do Raciocínio

As principais formas de mensurar o raciocínio dos modelos são através da performace nas tasks e da análise do raciocínio.

End Task Performace

A análise da performace em tarefas envolve a avaliação de métricas como acurácia em benchmarks comuns, como raciocínio aritmético, commonsense reasoning, racionínio simbólico, entre outros.

Raciocínio Aritmético é a habilidade de entender e aplicar conceitos e princípios matemáticos para resolver problemas que envolvem operações aritméticas. Existem diversos datasets com o objetivo de mensurar essa habilidade como GSM8K, MathQA, SVAMP, ASDIV e AQuA.

Commonsense reasoning é o uso de conhecimento diário, conhecimento comum, e entender e fazer julgamentos e predições sobre novas situações. Esse conhecimento é geralmente entendido como um conhecimento externo sobre o mundo que é presumido que todos os humanos possuem; Por definição, commonsense reasoning requere conhecimento externo, que pode surgir de várias fontes. Algum conhecimento externo é capturado durante o treinamento de forma implícita nos dados utilizados.

Raciocínio simbólico é envolve a manipulação de sombolos de acordo com regras formais. É o uso de simbolos abstratos que representam conceitos e relacionamentos, e a manipulação deles de acordo com regras precisas para gerar conclusões e resolver problemas

Análise do Raciocínio

Apesar do alto desempenho em várias tasks e benchmarks de raciocínio, não fica claro se ele é resultado de um raciocínio real do modelo ou se simplesmente segue heurísticas simples para solucionar as tarefas.

Em estudos, foi verificado que LLMs podem produzir justificativas inválidas mesmo performando reasoning nas tasks. Isso porquê a maioria das avaliações existentes foca na acurácia das tasks, em vez de avaliar diretamente as etapas de raciocínio. Mas já existem pesquisas e desenvolvimentos para suprir esse gap, como o ROSCOE e o dataset PrOntoQA.

Esse gap de avaliação de etapas de raciocínio deixa em aberto se os modelos realmente são capazes de raciocinar de forma similar a humanos, ou se são simplesmente capazes de alcançar um bom desempenho nas tarefas através de outros meios. Por isso, mais pesquisas são necessárias para analisar mais formalmente as habilidades de raciocínio dos LLMs.

Para aprofundar cada task citada e outras, datasets e estudos feitos, recomendo a leitura das referências citadas.

Afinal, os modelos raciocinam ou não ?

Apesar das semelhanças, ainda que mínimas, e de algumas evidências, estas não são suficientes para concluir que os Modelos de Linguagem Pré-treinados (LLMs) são capazes de realizar um verdadeiro raciocínio. Não está claro se esses modelos fazem previsões com base no raciocínio ou em heurísticas. Para a maioria dos benchmarks de raciocínio, é possível resolvê-los por meio de programas com heurísticas, alcançando alta performance, sem que consideremos que o programa está efetivamente “raciocinando”.

Embora os LLMs demonstrem padrões de raciocínio semelhantes aos humanos, isso não implica necessariamente que eles estejam se comportando como humanos; muitas vezes, estão simplesmente imitando a estrutura linguística-lógica-racional. Além disso, os LLMs enfrentam desafios em tarefas que demandam um raciocínio mais complexo. Contudo, mesmo diante dessas limitações, ainda não está claro se os modelos atuais são incapazes de raciocinar de maneira robusta.

Apesar dos progressos significativos, a capacidade real de raciocínio desses modelos não está clara, sendo uma incógnita se eles a possuem verdadeiramente ou se estão apenas utilizando informações memorizadas por meio de heurísticas. É evidente que são necessárias mais pesquisas para uma compreensão completa das habilidades de raciocínio, aprimorar suas capacidades e determinar o potencial de seu uso em diversas aplicações.

Conclusão

Neste artigo foi abordado de forma introdutória o Natural Language Reasoning (NLR), assim como os conceitos relacionados a ele, como as abordagens existentes, técnicas utilizadas para potencializar essa habilidade de raciocinar e como essa habilidade é avaliada. Também, falamos brevemente sobre a real ou aparente capacidade de raciocinar, mas é evidente que mais estudos precisam ser feitos, principalmente a criação de novas formas de avaliação de raciocínio, como avaliação dos reasoning paths para compreensão da capacidade de raciocinar.

Me siga clicando aqui para acompanhar mais blog posts aprofundando sobre o tema.

Como Citar

Guimarães, Alysson. (Jan 2024). Raciocínio em Modelos de Linguagem Pré-treinados (PLMs). https://medium.com/data-hackers/. https://medium.com/data-hackers/p-821b188893b8

ou

@miscellaneous{guimaraes2024plmsreasoning,
 title = {Raciocínio em Modelos de Linguagem Pré-treinados (PLMs)},
 author = {Guimarães, Alysson},
 journal = {https://medium.com/data-hackers/},
 year = {2024},
 month = {Jan},
 url = {https://k3ybladewielder.medium.com/p-88d01ccbf604}
}

Referências

Yu, F., Zhang, H., Tiwari, P., & Wang, B. Natural Language Reasoning, A Survey. DOI: https://doi.org/10.48550/arXiv.2303.14725

HUANG, Jie; CHANG, Kevin Chen-Chuan. Towards Reasoning in Large Language Models: A Survey. Findings of the Association for Computational Linguistics: ACL 2023, pages 1049–1065, Toronto, Canada. Association for Computational Linguistics. DOI: 10.18653/v1/2023.findings-acl.67

Raciocínio em Modelos de Linguagem Pré-treinados (PLMs) was originally published in Data Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.