Para Além do Jupyter Notebook: Construindo um Pipeline de LLM em Produção nos Meus Primeiros 60 Dias

Meu nome é Matheus. Tenho 21 anos e estou no 7º semestre de Engenharia da Computação na Unicamp. Antes de entrar no AI Fellowship da Enter, meu mundo girava em torno de machine learning: construir arquiteturas de Retrieval-Augmented Generation (RAG), treinar modelos XGBoost para predição de churn e participar de competições quantitativas de IA.

Eu sabia como treinar e criar prompts para IA, mas Engenharia de Software (orquestrar microsserviços assíncronos, desenhar workflows distribuídos, gerenciar buckets do AWS S3 e construir frontends em React) era algo totalmente novo para mim.

Quando você entra em uma empresa como estudante ou estagiário, geralmente espera um toy project, como um dashboard interno ou a correção de um bug pequeno. A Enter adotou uma abordagem diferente. Eles me entregaram um problema real de escalabilidade e confiaram em mim para arquitetar a solução do zero.

Abaixo, vou descrever como passei meus primeiros 60 dias escrevendo RFCs, aprendendo a dura realidade da engenharia de software moderna e construindo um pipeline de LLM em produção para o nosso time de AI Deployment.

O Problema: Escalando IA Jurídica

O time de AI Deployment da Enter precisa analisar centenas de processos judiciais para gerar insights para grandes empresas. Para esse fluxo específico de análise de sentenças, nosso time havia construído uma excelente POC (prova de conceito) usando scripts locais em Python. Funcionava, mas não escalava. Rodava localmente e exigia intervenção manual.

Minha missão era substituir esse script local por uma feature web full-stack altamente concorrente, embutida diretamente no nosso portal de backoffice.

Arquitetando o Fluxo de Validação

Antes de usarmos um LLM para analisar uma lista de casos, identificados pelo número do processo no Conselho Nacional de Justiça (CNJ), primeiro precisamos verificá-los. Eles estão mesmo no nosso banco de dados? Estão registrados para o cliente correto? Existem de fato os documentos de decisão (como uma sentença ou um acórdão) anexados, ou o caso ainda está em andamento?

Eu desenhei um router de backend dedicado para essa validação. Em vez de fazer centenas de checagens sequenciais, o sistema orquestra chamadas HTTP assíncronas para nossos serviços internos de documentos.

O pipeline de validação categoriza cada CNJ em status específicos, como filtrar casos com invalid_format, identificar casos not_in_any_customer no banco de dados, ou sinalizar casos que existem, mas estão como in_target_docs_but_no_decision_docs (ou seja, temos os autos do processo, mas o juiz ainda não proferiu decisão). Somente os casos que passam com sucesso no pipeline (passes_pipeline) seguem adiante.

Veja como é a arquitetura dessa validação:

Orquestrando o Pipeline de LLM

Com os casos validados, o trabalho pesado de verdade começa. Eu não podia simplesmente analisar documentos de 150 processos jurídicos em uma requisição HTTP padrão porque daria timeout. Um único lote poderia facilmente conter milhares de páginas de documentos jurídicos densos, o que se traduz em milhões de tokens. Processar esse volume massivo de dados leva vários minutos e exige múltiplas chamadas de LLM, excedendo de longe os timeouts de servidores padrão.

Para resolver isso, usei o Hatchet, uma das nossas ferramentas para gerenciar jobs assíncronos, para orquestrar um workflow em background. A arquitetura passa por quatro fases distintas: query_decisions (busca do texto), analyze (uso de um LLM para avaliar cada caso), compile (agregação de estatísticas) e synthesize (geração dos insights finais).

Como a etapa de analyze é a mais custosa, utilizei execução paralela (fan-out) com um semáforo limitando requisições simultâneas à API do LLM. À medida que cada etapa é concluída, o backend salva os artefatos Markdown gerados em um bucket S3 da AWS e atualiza um banco de dados PostgreSQL para que o frontend em React possa fazer polling e exibir o progresso em tempo real.

A Realidade da Engenharia de Software Moderna

Olhando para trás, a parte mais difícil deste projeto não foi escrever o código. Com sistemas baseados em agentes e ferramentas como o Cursor, escrever componentes em React ou endpoints no FastAPI é incrivelmente rápido. A barreira técnica para escrever código desapareceu.

O verdadeiro desafio, a engenharia em si, começa quando os erros aparecem. A IA pode escrever uma função em Python, mas não consegue descobrir por que o seu deploy no ArgoCD está falhando. Ela não sabe navegar pelas nuances entre bancos de dados de diferentes ambientes, e não cria os buckets S3 nem as permissões de IAM por você.

Eu me lembro nitidamente de sentar com o meu supervisor na frente de uma aba do Excalidraw para desenhar a estrutura das tabelas do banco de dados. Aquele foi o momento em que percebi que engenharia de software é sobre o design do sistema. É sobre entender conceitos como transações de banco de dados e níveis de isolamento, e também mecânicas como async/await (uma menção honrosa ao texto dos hambúrgueres concorrentes do FastAPI, que finalmente fez a ficha cair para mim).

Impacto Real

Esta semana, apresentei a primeira versão da solução final para mais de 30 pessoas dos times de produto e AI deployment, incluindo um dos co-founders da Enter. Isso ocorreu durante uma das sessões regulares de almoço da empresa, uma tradição onde os engenheiros compartilham soluções em desenvolvimento com toda a equipe para coletar feedback e trocar ideias. Ver a equipe genuinamente empolgada para usar uma ferramenta que construí do zero, sabendo que isso vai economizar inúmeras horas de processamento local, foi a experiência mais gratificante do meu AI Fellowship até agora.

A resiliência que construí estudando para as matérias da Unicamp me deu a determinação necessária para aprender essas novas ferramentas, mas a Enter me deu o espaço para testar e construir. Se você quer fechar o gap entre a teoria acadêmica e a construção de software que gera valor no mundo real, você precisa de um ambiente que confie em você para resolver problemas difíceis.

Você precisa de um lugar onde ir além do Jupyter Notebook seja parte do desafio desde o início, e onde você não fique preso a toy projects.