O Stack de IA Que Usamos em Produção: Modelos e Pipelines

O cenário de ferramentas de IA no início de 2026 é avassalador. Toda semana traz um novo framework, um novo modelo, um novo banco de dados vetorial alegando ser o mais rápido e uma nova camada de orquestração prometendo simplificar tudo. Para líderes de engenharia tentando construir sistemas de IA de produção, a relação ruído-sinal nunca foi pior. Sabemos porque temos navegado isso nós mesmos -- enviando produtos alimentados por IA e sistemas de agents para clientes em fintech, energia e governo enquanto o chão se move sob nós a cada trimestre.

Este artigo é nossa tentativa de cortar esse ruído. Estamos compartilhando as ferramentas específicas, modelos e decisões arquitetônicas que compõem nosso stack de IA de produção -- o que usamos, por que escolhemos e o que deliberadamente escolhemos não usar. Esta não é uma estrutura teórica ou um gráfico de comparação de fornecedores. É o stack rodando em produção hoje, servindo usuários reais, lidando com casos extremos reais e custando dinheiro real. Estamos compartilhando porque transparência constrói confiança, e porque desejamos que mais equipes fizessem o mesmo. Quando fornecedores publicam benchmarks, otimizam para a demo. Quando praticantes compartilham seus stacks, otimizam para honestidade.

A Camada de Modelo: Escolhendo Seus LLMs

Rodamos uma estratégia multi-modelo -- não porque é tendência, mas porque nenhum modelo único é a escolha certa para cada tarefa em um sistema de produção. Errar na estratégia de modelo significa ou gastar demais em capacidades que você não precisa ou entregar menos na qualidade que usuários esperam.

Claude: Nosso Modelo Primário de Raciocínio

Claude da Anthropic é nosso modelo primário para raciocínio complexo, análise de contexto longo e seguimento nuançado de instruções. Usamos para decisões de orquestração de agents, análise de documentos através de contratos de 50-100 páginas, geração e revisão de código, e qualquer tarefa onde seguir prompts de sistema detalhados precisamente importa mais do que velocidade bruta. A capacidade de pensamento estendido de Claude é particularmente valiosa para sistemas de agents -- quando um agent precisa planejar um fluxo de trabalho multi-etapas, a diferença de qualidade versus outros modelos é mensurável. Também confiamos na confiabilidade de saída estruturada de Claude. Sistemas de produção não podem tolerar JSON malformado, e para indústrias regulamentadas essa confiabilidade é um requisito rígido.

GPT-4o e Modelos Open-Source

GPT-4o da OpenAI serve como nosso fallback e nossa escolha para tarefas multimodais envolvendo análise de imagem e padrões complexos de function calling. Mantemos não como hedge contra vendor lock-in -- embora esse seja um benefício -- mas porque certas tarefas genuinamente performam melhor nele. Fingir que um modelo vence em todos os lugares é ideologia, não engenharia.

Para tarefas sensíveis a custo e alto volume, implantamos modelos open-source -- principalmente Llama 3 da Meta e Mistral. Estes lidam com classificação, extração de entidades e sumarização simples onde custos de modelo de fronteira são injustificáveis. Uma tarefa de classificação rodando 50.000 vezes por dia custa aproximadamente $100 por mês em Llama 3 versus $3.000 em Claude. A diferença de qualidade para classificação binária é negligenciável; a diferença de custo não é. Auto-hospedamos usando vLLM para servir inferência, nos dando controle sobre latência, disponibilidade e residência de dados.

Orquestração: Conectando Agents

A camada de orquestração é o que transforma chamadas de modelo individuais em fluxos de trabalho de agent coerentes. Gerencia estado, roteia decisões, lida com chamadas de ferramentas e recupera de falhas. Acertar essa camada é a diferença entre uma demo que impressiona e um sistema que funciona às 3h de um sábado.

LangGraph para Fluxos de Trabalho de Agents

Usamos LangGraph como nossa camada primária de orquestração. Modela fluxos de trabalho de agents como grafos direcionados onde nós representam ações e arestas representam transições condicionais. A vantagem chave é checkpointing -- LangGraph persiste o estado completo do agent em cada nó, permitindo replay de execuções falhadas do ponto exato de falha, aprovação humana-no-loop em qualquer etapa e trilhas de auditoria completas para conformidade.

Orquestração Customizada para Caminhos Críticos

Para caminhos críticos de produção -- agents de processamento de pagamento, fluxos de trabalho sensíveis à segurança -- usamos máquinas de estado TypeScript customizadas em vez de um framework. Frameworks adicionam camadas de abstração, e camadas de abstração adicionam modos de falha. Quando um fluxo de trabalho processa transações financeiras, cada linha de código de orquestração deve ser explícita, testável e livre de atualizações de dependências de terceiros que poderiam mudar comportamento. É mais código que LangGraph, mas o trade-off vale a pena onde confiabilidade supera velocidade de desenvolvimento.

Bancos de Dados Vetoriais e Embeddings

Usamos três bancos de dados vetoriais para três contextos de implantação. Pinecone é nosso padrão para implantações cloud-native -- gerenciado, escalável, com isolamento de tenant baseado em namespace. pgvector é nossa escolha quando a aplicação já roda em PostgreSQL, mantendo vetores ao lado de dados relacionais e eliminando um banco de dados separado para operar. Weaviate é implantado para clientes on-premise -- agências governamentais e instituições financeiras com residência de dados rigorosa -- rodando containerizado dentro de sua infraestrutura com busca híbrida nativa.

Para embeddings, text-embedding-3-large da OpenAI é nosso padrão para aplicações em inglês. Para trabalho multilíngue -- uma porção significativa de nossos projetos através da América Latina e Europa -- embed-multilingual-v3.0 da Cohere supera alternativas em recuperação cross-language. Para implantações on-premise, usamos modelos open-source como BGE-large e E5-mistral, rodando nas mesmas instâncias GPU que nossos LLMs para manter o pipeline inteiro autocontido.

Pipeline RAG: De Documentos a Respostas

A qualidade de um sistema RAG depende muito mais do pipeline de recuperação do que do modelo de geração -- um modelo de fronteira dado contexto ruim produz respostas ruins tão confiantemente quanto produz boas.

Chunking Consciente do Tipo de Documento

Abandonamos estratégias de chunking universal cedo. Chunks de tamanho fixo com sobreposição funcionam para artigos e relatórios mas massacram contratos, especificações e demonstrações financeiras. Nossa abordagem: contratos legais são divididos por cláusula, docs técnicos por seção, relatórios financeiros por tabela e narrativa separadamente. Também mantemos relacionamentos pai-filho entre chunks para que o sistema possa puxar contexto circundante quando um fragmento é recuperado -- eliminando o modo de falha RAG mais comum de retornar um fragmento relevante que falta contexto para interpretá-lo corretamente.

Reranking e Busca Híbrida

Reranking é consistentemente a maior melhoria de qualidade única em nossos pipelines RAG. Usamos Cohere Rerank para implantações gerenciadas e modelos cross-encoder para setups on-premise. Adicionar reranking a um pipeline de busca vetorial baseline melhora precisão de resposta em 15-25% através de tipos de documento. Adiciona 100-200ms de latência, mas a melhoria de qualidade o torna não-negociável.

Emparelhamos isso com busca híbrida -- combinando similaridade vetorial com matching de palavras-chave BM25 -- para cada sistema de produção. Busca vetorial pura perde consultas de match exato para números de contrato, SKUs de produto e identificadores de regulamentação. A implementação adiciona complexidade, mas perder um documento obviamente relevante porque não é semanticamente próximo à consulta é muito prejudicial para aceitar.

Avaliação e Monitoramento

Um sistema de IA sem avaliação é um passivo. Todo sistema de produção recebe uma suite de avaliação customizada: precisão de extração, completude e taxa de alucinação para processamento de documentos; taxa de conclusão de tarefa, relevância e aderência de tom para agents conversacionais. Ferramentas prontas dão métricas genéricas. Frameworks customizados dão as métricas que realmente correlacionam com satisfação de usuário.

Para dimensões de qualidade subjetivas, usamos um padrão LLM-as-judge -- Claude como modelo juiz, pontuando saídas em escala 1-5 com raciocínio obrigatório para cada pontuação. Não é substituto para avaliação humana mas um filtro escalável que pega regressões e sinaliza casos limítrofes. Para aplicações críticas em domínios legal e financeiro, especialistas de domínio revisam uma amostra estatística de saídas semanalmente, fornecendo a verdade fundamental para calibrar avaliação automatizada.

Para observabilidade, rodamos LangSmith capturando cada chamada LLM, invocação de ferramenta e decisão de agent como trace. Dashboards Grafana customizados rastreiam o que liderança se importa: custo por dia por modelo e cliente, percentis de latência, taxas de conclusão de tarefa e pontuações de qualidade. Todo dólar de inferência de IA é atribuído a cliente, projeto e caso de uso específico -- não como higiene financeira, mas para dirigir decisões de otimização.

Infraestrutura e o Padrão API Gateway

Serviços de agents são containerizados com Docker em Kubernetes, auto-escalando baseado em profundidade de fila em vez de utilização de CPU -- porque workloads de IA são I/O-bound esperando APIs de modelo, não CPU-bound. Para inferência auto-hospedada, vLLM roda em instâncias GPU com batching dinâmico, escalando para zero durante horários off. Um único API gateway lida com autenticação, limitação de taxa, lógica de retry, roteamento de modelo e rastreamento de custo para cada solicitação LLM de saída. Este gateway é o ponto de estrangulamento através do qual todo gasto de IA flui, tornando-o o lugar natural para fazer cumprir orçamentos e coletar telemetria.

O Que Escolhemos Não Usar (e Por Quê)

As ferramentas que você rejeita revelam tanto sobre sua filosofia de engenharia quanto as ferramentas que você adota. Aqui estão as tecnologias notáveis que avaliamos e deliberadamente recusamos.

• CrewAI -- Muito opinativo sobre padrões de interação de agents para produção. LangGraph fornece as mesmas capacidades multi-agent com controle explícito sobre cada transição.
• Chroma -- Sólido para prototipagem mas maturidade operacional para workloads de produção (connection pooling, HA, backups) não atendeu nossos padrões. Revisitamos periodicamente.
• Haystack -- Abstração de pipeline limpa mas ecossistema e suporte comunitário significativamente menores que LangChain/LangGraph.
• Modelos de raciocínio com fine-tuning -- Resultados consistentemente piores que modelos de fronteira bem-prompts, com alto ônus de manutenção. Fazemos fine-tuning de modelos de embedding para recuperação específica de domínio, onde o ROI é claro.
• AutoGen -- Endurecimento de produção insuficiente. Interação de agent baseada em conversação tornou debugging difícil, e sem checkpointing persistente foi dealbreaker para fluxos de trabalho empresariais.

Como Nosso Stack Evoluiu em 18 Meses

Em meados de 2024, rodávamos GPT-4 como nosso único modelo, chains LangChain brutos para orquestração, Chroma para armazenamento vetorial e logging básico. O sistema funcionou para demos mas desmoronou sob carga de produção. No final de 2024, Claude 3.5 Sonnet havia substituído GPT-4 como nosso modelo primário, Pinecone e pgvector haviam substituído Chroma, e LangGraph havia substituído chains LangChain -- imediatamente melhorando debugging e testes.

Ao longo de 2025, adicionamos Cohere Rerank (nossa maior melhoria de qualidade única), construímos frameworks de avaliação customizados, implantamos LangSmith e introduzimos o padrão API gateway. Para 2026, o foco mudou para maturidade: orquestração customizada para caminhos críticos, loops de avaliação humana, modelos auto-hospedados para clientes sensíveis a dados e pipelines LLM-as-judge. O stack é mais complexo que 18 meses atrás, mas cada componente ganha seu lugar resolvendo um problema que realmente tivemos -- não um problema que imaginamos.

Princípios Por Trás de Nossas Escolhas

• Use o modelo certo para cada tarefa, não o melhor modelo para cada tarefa. Cascata de modelo não é apenas otimização de custo -- é um princípio arquitetônico.
• Possua seu caminho crítico. Frameworks são excelentes para fluxos de trabalho não-críticos, mas código crítico de produção deve ser explícito e livre de mudanças de dependência upstream.
• Meça antes de otimizar. Cada otimização que fizemos foi impulsionada por lacunas de qualidade medidas em produção, não preocupações teóricas.
• Simplicidade operacional compõe. Uma ferramenta ligeiramente menos capaz que sua equipe pode operar confiantemente supera uma ferramenta superior requerendo expertise especializada.
• Transparência é um recurso. Quando clientes perguntam quais modelos usamos e como avaliamos qualidade, respondemos com especificidades.

Nosso stack continuará evoluindo -- o cenário de ferramentas de IA se move rápido demais para que qualquer arquitetura seja permanente. Mas os princípios são estáveis: meça tudo, possua seus caminhos críticos, use a ferramenta certa para cada trabalho e seja honesto sobre o que funciona. Se você está construindo sistemas de IA de produção e quer comparar notas, ou se precisa de uma equipe que já navegou essas escolhas, acolhemos a conversa. Explore nossos serviços de IA e machine learning em /services/ai-development.