SILVA — Plataforma de IA Judicial no TRF1

Contexto

SILVA (Sistema Inteligente de Levantamento, Vinculação e Análise) é a plataforma institucional de IA do TRF1 para inteligência documental judicial. Ela cobre três fluxos principais: triagem de anexos recebidos, organização de acervos e geração em lote de minutas de decisões. O sistema opera dentro da plataforma PJe e está disponível para todas as turmas de segundo grau e a Vice-Presidência do tribunal.

Os modelos de IA que sustentam o SILVA foram originalmente desenvolvidos pela Universidade de Brasília e posteriormente reconstruídos do zero pelo Laboratório de Inovação do TRF1. Meu trabalho começou quando o sistema precisou evoluir da infraestrutura de fase de pesquisa para engenharia de ML em produção: pipelines estáveis, retreinamento reproduzível e APIs que as equipes jurídicas pudessem usar diariamente.

Meu papel

• Engenheiro Sênior de Machine Learning na TTY2000, dentro do programa de modernização do TRF1.
• Liderai a refatoração dos serviços de ML que sustentam as funcionalidades de classificação e agrupamento do SILVA.
• Construí pipelines de orquestração e retreinamento para transformar atualizações de modelos de trabalho manual ad-hoc em fluxos controlados e versionados.
• Entregai as APIs Django voltadas a analistas, consumidas por mais de 500 usuários internos nas turmas do tribunal.

Problema

O SILVA havia comprovado seu valor como protótipo de pesquisa. O desafio era torná-lo um sistema operacionalmente confiável na escala de um grande tribunal federal. Isso exigiu resolver várias lacunas ao mesmo tempo:

• Código de ML legado lento, difícil de versionar e dependente de passos manuais não documentados
• Ausência de fluxo de retreinamento reproduzível: cada atualização de modelo exigia coordenação manual significativa
• Camada de API não robusta o suficiente para mais de 500 usuários institucionais simultâneos
• Sem observabilidade sobre o comportamento do modelo em produção, tornando o drift invisível

O tribunal também esperava que o sistema crescesse em capacidade — novas categorias de Objetos de Recurso, taxonomias de classificação mais detalhadas e integração futura com LLMs — o que tornava a arquitetura subjacente uma preocupação de longo prazo.

Arquitetura

O sistema modernizado é organizado em três camadas que antes estavam desconectadas:

Camada de pipeline de ML

• Classificadores XGBoost com extração de features por TF-IDF para classificação de documentos e agrupamento de processos
• DVC para versionamento de datasets e reprodutibilidade de experimentos
• MLflow para rastreamento de experimentos, registro de modelos e empacotamento para deploy
• DAGs no Airflow para retreinamento agendado, validação de dados e orquestração de pipelines

Camada de API e serving

• APIs REST em Django servindo resultados de classificação para integrações com o PJe
• PostgreSQL para metadados estruturados de processos e saídas de classificação
• Docker para deploy conteinerizado e consistente entre ambientes

Camada operacional

• Artefatos de modelo versionados com rastreabilidade completa dos dados de treino ao modelo em produção
• Observabilidade de pipeline para que drift de classificação e gatilhos de retreinamento fiquem visíveis para a equipe

Desafios

• Fluxos jurídicos exigem alta precisão. Um Objeto de Recurso classificado incorretamente coloca o servidor em um caminho analítico errado — portanto, melhorar a acurácia e a cobertura da taxonomia tinha consequências operacionais diretas.
• O sistema precisava continuar funcionando enquanto era modernizado. Refatorar serviços de ML sem interromper usuários ativos em múltiplas turmas exigiu um rollout gradual cuidadoso.
• A cadência de retreinamento e a governança de dados são problemas institucionais tanto quanto técnicos. Alinhar quando e como retreinar exigiu trabalho com stakeholders de engenharia, área jurídica e operações.

Solução

Tratei a modernização como um problema de entrega, não apenas técnico. A prioridade foi construir a infraestrutura que torna as atualizações de modelo seguras e rotineiras:

• Substituí scripts de treino ad-hoc por pipelines reproduzíveis e versionados com DVC e Airflow.
• Introduzi o MLflow para tornar cada experimento rastreável e cada artefato de modelo auditável.
• Refatorei a camada de serving para reduzir latência e melhorar a confiabilidade sob a carga real de 500+ usuários diários.
• Trabalhei com a equipe de domínio para expandir a taxonomia de Objetos de Recurso, contribuindo com a engenharia que tornou a classificação mais granular viável em produção.

Impacto

• Tempo de processamento reduzido em 25% com a refatoração dos serviços de ML legados.
• APIs Django em produção utilizadas ativamente por mais de 500 usuários internos nas turmas de segundo grau do TRF1.
• Ciclos de atualização de modelos reduzidos de semanas para dias com a substituição de passos manuais por fluxos de retreinamento orquestrados no Airflow.
• Cobertura de Objetos de Recurso da Terceira Seção ampliada de 19 para 28 categorias após o deploy em produção, permitindo roteamento de processos e agrupamento de jurisprudência mais precisos.
• Sistema agora estruturado para suportar integração com LLMs como extensão natural da arquitetura de pipeline existente.