Por que RAG em produção é mais difícil do que parece

Em demonstrações, RAG parece trivial: indexe PDFs, consulte o vetor, injete o contexto no prompt e pronto. Em produção, o sistema vira um produto distribuído com requisitos de latência, custo, privacidade e qualidade difíceis de conciliar. Este artigo organiza os pontos que mais costumam quebrar projetos reais — e como eu abordo cada um na prática.

Introdução: O gap entre PoC e produção

A maioria dos tutoriais de RAG termina quando você consegue fazer seu primeiro PDF responder perguntas num notebook Jupyter. O problema começa quando você precisa lidar com 10 mil documentos atualizados semanalmente, 500 requisições por minuto, equipes que não entendem por que 'funciona às vezes', e um VP de produto perguntando quanto isso vai custar por mês.

Nos últimos meses, trabalhando em sistemas de IA no contexto MarTech da Cogna, aprendi que RAG em produção não é um problema de modelo — é um problema de engenharia de sistema. Vou compartilhar os desafios reais e as decisões práticas que fazem diferença.

1. Dados de verdade são bagunçados

Documentos jurídicos, políticas internas e bases legadas raramente vêm em Markdown limpo. Há cabeçalhos duplicados, tabelas escaneadas, anexos repetidos e versões conflitantes. Se o chunking ignora estrutura semântica, o recuperador mistura parágrafos de contextos diferentes e o modelo 'responde bonito' com informação errada.

Estratégias de chunking que realmente funcionam

Chunking não é apenas 'dividir a cada 500 tokens'. Documentos têm estrutura — seções, subseções, tabelas, listas — e ignorar isso gera contextos fragmentados. Na prática, uso estratégias híbridas:

• Divisão semântica por seção quando o documento tem marcação clara (headings, XML tags)
• Fallback para janelas fixas com overlap de 50-100 tokens quando a estrutura é inconsistente
• Chunks de tamanho variável: seções curtas podem ser agregadas, seções longas são subdivididas
• Preservação de contexto hierárquico: cada chunk carrega metadado do título da seção pai

Lidando com formatos heterogêneos

PDFs nativos e PDFs escaneados (OCR) precisam de pipelines diferentes. PDFs com tabelas complexas exigem ferramentas especializadas como Camelot ou Tabula. Documentos do Word podem ter formatação perdida na conversão. A solução? Pipelines de ingestão específicos por tipo de documento, com validação de qualidade antes do embedding.

Metadados como cidadãos de primeira classe

• Normalizar metadados: fonte, data de criação, versão, autor, departamento responsável
• Filtros pré-busca: reduzir o espaço de busca vetorial com filtros estruturados
• Versionamento de documentos: manter histórico para auditoria e rollback
• Tags de qualidade: marcar chunks com score de confiança baseado em heurísticas

2. Latência e custo são parte do contrato

Cada consulta pode disparar embedding, busca top-k, re-ranking e uma chamada ao LLM. Multiplicado por milhares de usuários, o custo vira OPEX previsível ou surpresa na fatura. Latência acima de poucos segundos destrói UX em fluxos interativos.

Anatomia de uma query RAG e seus custos

Uma query típica de RAG passa por várias etapas custosas: (1) Gerar embedding da query (~$0.0001 por query com text-embedding-3-small), (2) Busca vetorial em banco como Pinecone (~$0.0002 por 10k queries), (3) Re-ranking opcional com modelo cross-encoder (~10-50ms adicional), (4) Chamada ao LLM com contexto recuperado (~$0.002-0.02 dependendo do modelo e tamanho do contexto). Para 100k queries/dia, isso pode significar $200-2000/dia apenas em API calls.

Estratégias de otimização de custo

• Cache de embeddings para queries frequentes: implementar Redis/Memcached para queries repetidas
• Cache de respostas com TTL inteligente: respostas podem ser cacheadas se o contexto não mudou
• Modelos menores para etapas auxiliares: usar GPT-3.5 para classificação e GPT-4 apenas para geração final
• Sumarização de chunks longos: comprimir contexto antes de enviar ao modelo final
• Batch processing: agrupar embeddings de múltiplos documentos em uma única chamada

Otimizando latência sem explodir o orçamento

Latência tem três componentes principais: tempo de embedding, tempo de busca vetorial e tempo de inferência do LLM. Para reduzir latência: use embeddings menores (384d vs 1536d quando possível), implemente busca aproximada (ANN) com índices otimizados (HNSW, IVF), faça streaming da resposta do LLM para melhorar a percepção de velocidade, e considere modelos hospedados em regiões próximas aos usuários.

Um sistema RAG bem arquitetado pode responder em menos de 2 segundos, custar menos de $0.005 por query e ainda ter margem para escalar 10x.

3. Avaliação não é uma métrica de leaderboard

MMLU e benchmarks gerais não dizem se o seu assistente acerta cláusulas do seu contrato. Você precisa de conjuntos de avaliação rotulados pelo domínio, testes de regressão após mudança de prompt ou de índice, e — quando possível — feedback humano em amostragem.

Construindo datasets de avaliação do zero

O primeiro passo é criar um conjunto de gold standard questions com respostas conhecidas. Comece com 50-100 pares de pergunta-resposta que cobrem: casos comuns (80% do uso esperado), casos extremos (edge cases que já quebraram o sistema), casos adversariais (perguntas ambíguas ou mal formuladas), e casos de conhecimento ausente (onde a resposta correta é 'não sei').

Métricas que realmente importam

• Precisão de recuperação (Precision@k): dos k chunks retornados, quantos são relevantes?
• Recall de recuperação: dos chunks relevantes no índice, quantos foram recuperados?
• Acurácia de resposta: a resposta final está factualmente correta? (validação humana)
• Taxa de citação: o modelo citou corretamente os documentos fonte?
• Taxa de 'não sei': o modelo reconheceu quando não havia informação suficiente?
• Latência p95: 95% das queries respondem em quanto tempo?

Testes de regressão em CI/CD

Toda mudança de prompt, atualização de índice ou troca de modelo deve rodar contra o conjunto de avaliação. Implemento isso como parte do pipeline CI/CD: um script que executa as queries de teste, compara com respostas esperadas usando LLM-as-judge + validação estruturada, e bloqueia o deploy se a acurácia cair mais de 5%. Isso evita regressões silenciosas.

4. Observabilidade é obrigatória, não opcional

Sem observabilidade, você está voando cego. Quando um usuário reclama que 'a IA deu resposta errada', você precisa reconstruir exatamente o que aconteceu: qual query foi enviada, quais chunks foram recuperados, qual contexto foi enviado ao LLM, qual foi a resposta e quanto custou.

Stack de observabilidade para RAG

No mínimo, você precisa de: logs estruturados com trace IDs vinculando toda a pipeline de uma query, métricas de latência por etapa (embedding, busca, inferência), tracking de custos por query e usuário, armazenamento de queries e respostas para auditoria, e dashboards agregados mostrando volume, latência, custo e taxa de erro ao longo do tempo.

• LangSmith: excelente para trace detalhado de chains LangChain, visualização de prompts e custos
• Weights & Biases: para experimentos, comparação de embeddings e fine-tuning
• Prometheus + Grafana: para métricas de infraestrutura e alertas em produção
• Custom logging: JSON estruturado em CloudWatch/Datadog com campos padronizados

RAG em produção é engenharia de dados + engenharia de prompt + engenharia de sistema. O modelo é só um componente.

5. Segurança e privacidade não são afterthoughts

Dados empresariais sensíveis não podem vazar entre usuários ou ser enviados para modelos externos sem controle. RAG adiciona superfície de ataque: injection via documentos maliciosos, exfiltração via queries manipuladas, e exposição de dados através de citações inadequadas.

Controles de segurança essenciais

• Isolamento de dados: multi-tenancy no banco vetorial com ACLs por usuário/organização
• Input sanitization: validar e limpar queries antes de processar
• Output filtering: verificar se citações não expõem dados sensíveis de outros usuários
• Audit logs: registrar quem acessou quais documentos através do sistema RAG
• Modelos self-hosted: considerar Azure OpenAI ou modelos locais para dados regulados (LGPD, HIPAA)

6. O que levar para o próximo sprint

Comece pelo mínimo auditável: pipeline de ingestão versionado, métricas de recuperação (precisão@k em queries reais) e um painel de custo por requisição. Só então escale re-ranking, multi-query e agentes — cada camada adiciona superfície de falha e de observabilidade.

Checklist para RAG production-ready

• Pipeline de ingestão com versionamento e rollback
• Metadados normalizados e filtros pré-busca implementados
• Dataset de avaliação com pelo menos 100 casos de teste
• Testes de regressão automatizados em CI/CD
• Logs estruturados com trace IDs em toda pipeline
• Dashboard de custo por query e por usuário
• Alertas de latência p95 e taxa de erro
• Controles de acesso e isolamento multi-tenant
• Documentação de runbooks para incidentes comuns

Conclusão

RAG em produção não é sobre ter o modelo mais novo ou o embedding mais sofisticado. É sobre construir um sistema confiável, observável, seguro e economicamente viável. É sobre transformar uma demo impressionante em um produto que seu time de operações consegue manter e seu CFO consegue aprovar.

Se você está começando: não tente construir tudo de uma vez. Comece com o pipeline mais simples possível, meça tudo, e evolua incrementalmente. Se você já tem RAG em produção: revise seu sistema contra a checklist acima e priorize os gaps que mais impactam confiabilidade e custo.