Vector databases em produção: o que ninguém te conta sobre escolha, storage e queries para RAG
Desvendando os tradeoffs reais entre HNSW, quantization e memória, com critérios concretos para escalar retrieval em produção sem sangrar custo.
Você investiu seis meses e R$ 800 mil em um modelo de NLP que extraía intent de mensagens de clientes com 94% de acurácia no laboratório. Em produção, após o hype do lançamento, o modelo começou a degradar silenciosamente. A acurácia caiu para 81% em três meses. Ninguém percebeu porque não havia monitoramento. O custo de inferência consumia 40% do orçamento de cloud. E o modelo ainda travava em produção no meio do expediente. Esse cenário não é exceção. É a regra. 73% dos projetos de ML não chegam a segunda fase de ROI positivo, segundo o Gartner. O problema raramente está no modelo. Está na falta de disciplina operacional.
O custo que ninguém coloca no orçamento
Quando discutimos ROI de projetos de ML, o erro mais comum é dimensionar o investimento apenas no training. Selecionamos a arquitetura mais sofisticada, rodamos dezenas de experimentos no notebook, otimizamos hiperparâmetros por semanas. E aí vem a pergunta que nenhum CFO faz: quanto custa cada inferência? E quantas inferências você pretende fazer por dia?
Um modelo de NLP com 7 bilhões de parâmetros consome, em média, 14 GB de VRAM por batch de inferência. Em uma operação com 500 mil atendimentos por dia, isso significa uma fatura de cloud que come facilmente 35% do orçamento de TI. E isso sem considerar o custo de latency, que impacta diretamente a experiência do usuário.
O modelo, se custar mais para rodar do que gera de valor, é um passivo. Ponto final.
Os 4 erros que custam caro
1. Treinar demais, pensar depois
O primeiro erro é arquitetural. Equipes técnicas inspiradas por benchmarks acadêmicos escolhem modelos maiores do que o problema exige. Em laboratório, a diferença de 2 pontos percentuais de F1 entre um modelo de 7B e um de 3B parece relevante. Em produção, a diferença de 5x no custo de inferência e a latência de 400ms vs. 80ms são o que realmente importa.
A armadilha é que, em demos controladas, ninguém paga a conta. O custo de inferência aparece depois, invisível, embutido na fatura da cloud.
2. Tratar produção como laboratório
Laboratório tem dados limpos, distribuídos de forma idêntica entre treino e teste, sem concept drift. Produção tem usuário real, sazonalidade, mudança de comportamento, de produtos que alteram o vocabulário do cliente.
O segundo erro é não incorporar um pipeline de monitoramento de data drift desde o dia 1. Se a distribuição dos inputs em produção começa a divergir do treino, o modelo degrada. Na maioria dos casos, a degradação acontece de forma gradual. Ninguém percebe até que a acurácia efetiva cai abaixo de um limiar crítico.
3. Deploy sem versionamento e observabilidade
Deployar um modelo é simples. Manter a rastreabilidade de qual versão está em produção, quais dados foram usados no treino, qual era a performance no momento do deploy, e o que mudou no comportamento do modelo nas últimas duas semanas. Esse é o trabalho que a maioria das equipes não faz.
Sem versionamento de modelo (Model Registry), sem logging estruturado de inputs e outputs, sem métricas de performance em produção, você está operando às cegas. Quando o modelo começa a falhar, a única coisa que você sabe é que algo está errado. O porquê demora semanas para descobrir.
4. Ignorar o ciclo de vida completo
Modelos não são estáticos. O vocabulário muda, o comportamento do cliente muda, o produto muda. Um modelo treinado em 2023 pode estar desatualizado em 2024. A maioria das empresas trata deploy como evento final, não como início de um ciclo.
Tabela comparativa: os caminhos
| Erro | Sintoma invisível | Custo real | Solução |
|---|---|---|---|
| Modelo superdimensionado | Latência elevada, fatura cloud inflada | 35x mais caro que o necessário | Avaliar modelos menores (3B, 1B, 500M) com o mínimo viável de parâmetros |
| Sem monitoramento de drift | Acurácia cai gradualmente, ninguém percebe | Queda de 15% a 30% em 6 meses sem ação | Pipeline de data validation + retraining trigger + alerting |
| Deploy sem governança | Conflito de versões, rollback lento, debugging cego | MTTR aumenta 5x a 10x em incidentes | Model Registry + feature store + logs estruturados |
| Ciclo de vida negligenciado | Modelo defasado, performance degradada | ROI negativo após 12 a 18 meses | Processo trimestral de reavaliação + métricas de decaimento |
A decisão que separa projetos que sobrevivem dos que viram custo
A diferença entre um projeto de NLP que entrega valor sustentável e um que vira peso operacional não está na qualidade do modelo. Está em quatro práticas não glamorosas:
1. Defina o custo de inferência antes de escolher a arquitetura.
Calcule o volume esperado de inferências, multiplique pelo custo por chamada no provider escolhido, e esse número precisa fazer sentido no contexto do valor gerado. Se cada atendimento automatizado economiza R$ 2,50 em call center, você tem espaço para um modelo que custa R$ 0,003 por chamada. Se o modelo que você quer custa R$ 0,015, a matemática não fecha.
2. Instrumente observabilidade desde o primeiro deploy.
Não espere ter problemas para começar a monitorar. Implemente métricas de input distribution, output distribution, latência, taxa de erro, e anomalias de negócio desde o dia 1. O custo de instrumentar antes é 10% do custo de debugar depois.
prometheus
nlpt_request_duration_seconds_bucket
nlpt_predictions_total{status="success|error"}
nlpt_input_tokens_distribution
nlpt_confidence_score_percentile_50
nlpt_drift_score{kafka_topic="input_data"}
3. Treat retraining como feature de produto, não como hotfix.
Agende ciclos de reavaliação com a mesma disciplina que trata sprints de engenharia. Modelos que driftam sem correção não são modelos problemáticos. São sistemas sem processo.
4. Revise a arquitetura a cada 6 meses.
O que era state of the art há um ano pode ser 5x mais caro do que alternativas disponíveis hoje. Modelos distillation e quantization reduzem o footprint em 60% a 80% com perda mínima de performance. A cada seis meses, vale perguntar: ainda estamos usando a arquitetura certa para o problema atual?
Conectando tecnologia a resultado
NLP em produção não é um problema de engenharia de dados. É um problema de gestão de ativos. Ativos que degradam, que custam mais para operar do que deveriam, que operam sem visibilidade. São problemas que CFOs reconhecem imediatamente quando traduzimos linguagem de modelo para linguagem de negócio.
A decisão não é se você deve usar NLP. É se você está preparado para operar o que você constrói. Porque a diferença entre um modelo que cria valor e um que consome orçamento está nas práticas operacionais que você implementa depois do deploy.
flowchart TD
A[Início do Projeto] --> B[Treinamento do Modelo]
B --> C{Validação}
C -->|Aprovado| D[Deploy em Produção]
C -->|Reprovado| B
D --> E[Inference]
E --> F[Monitoramento]
F --> G{Drift Detectado?}
G -->|Sim| H[Retreino]
H --> B
G -->|Não| E
B --> I["Viés de Seleção"]
E --> J["Custo Escalando"]
F --> K["Observabilidade Ausente"]
G --> L["Drift Não Detectado"]
J --> M[Otimizar Inference]
M --> E
style J fill:#ff6b6b,stroke:#c0392b,stroke-width:3px
style M fill:#ff6b6b,stroke:#c0392b,stroke-width:3px
style L fill:#ffcccc,stroke:#c0392b,stroke-width:2pxSe você quer uma avaliação do estado atual dos seus modelos em produção, ou um mapeamento dos riscos de custo que provavelmente estão invisíveis na sua fatura de cloud, conversamos em 30 minutos. Sem compromisso.
Se sua empresa ja tem modelos de NLP em produção ou esta planejando um primeiro deploy, podemos mapear em 30 minutos onde estao os riscos ocultos de custo e performance. Sem compromisso.