Nos artigos anteriores, entendemos a geometria por trás da busca vetorial e vimos como a troca de um modelo de embedding (ex: GPT-1 para DeepSeek) quebra a matemática do seu RAG. Vimos também as estratégias de engenharia de software — como mensageria assíncrona, versionamento de espaço latente e matrizes de projeção — para fazer essa transição sem derrubar o sistema.
Agora é hora de falar da matemática que faz o diretor financeiro (CFO) acordar de noite: a matemática do bolso.
Se a sua aplicação tem tração, você não vai lidar com 10.000 documentos. Você vai lidar com gigabytes e, eventualmente, terabytes de vetores.
O que acontece quando o seu banco vetorial atinge 10 Terabytes de embeddings e você precisa manter isso rodando pelos próximos 10 anos? Quanto essa brincadeira realmente custa?
1. Decompondo os 10 Terabytes: Quantos dados são esses?
Para entender o custo, precisamos primeiro traduzir Terabytes em vetores e tokens.
Um vetor gerado por um modelo padrão (como o text-embedding-3-small da OpenAI) possui 1.536 dimensões. Cada dimensão é armazenada como um número de ponto flutuante de precisão simples (float32), que ocupa 4 bytes.
Tamanho por vetor: 1.536 dimensões × 4 bytes = 6.144 bytes (~6,14 KB)
Para preencher 10 Terabytes (10 trilhões de bytes) apenas com vetores brutos, a matemática é simples:
- Total de Vetores (Chunks): aproximadamente 1,63 bilhão de vetores.
- Volume de Texto: Se cada chunk tiver em média 500 tokens (~375 palavras), estamos falando de 815 bilhões de tokens armazenados.
Isso é o equivalente a indexar milhões de livros ou centenas de milhões de documentos corporativos.
2. O "Imposto da Re-indexação": O custo oculto das APIs
No segundo artigo, estabelecemos um fato inevitável: modelos de IA ficam obsoletos a cada 18 ou 24 meses. Em uma janela de 10 anos, você terá que migrar de modelo e reprocessar toda a sua base histórica pelo menos 4 a 5 vezes.
Vamos calcular o custo de API apenas para gerar esses embeddings considerando as tabelas de preços atuais:
-
Com modelo básico (
text-embedding-3-small/ ~USD 0,02 por 1M tokens):- Uma única ingestão de 815 bilhões de tokens = USD 16.300
- 5 re-embeddings ao longo de 10 anos = USD 81.500
-
Com modelo avançado (
text-embedding-3-large/ ~USD 0,13 por 1M tokens):- Uma única ingestão = USD 105.950
- 5 re-embeddings ao longo de 10 anos = USD 529.750
Ou seja: só em chamadas de API para manter a sua base "viva" e atualizada matematicamente com os novos modelos, você pode gastar mais de meio milhão de dólares em uma década.
3. O Pesadelo da Infraestrutura: O custo de manter 10 TB na memória
O custo de API é pequeno perto do custo de hospedagem.
Bancos vetoriais tradicionais dependem de índices em memória RAM (como o algoritmo HNSW — Hierarchical Navigable Small World) para entregar buscas em milissegundos. No entanto, o grafo do HNSW adiciona uma sobrecarga de 20% a 50% em cima do tamanho do vetor.
Para manter 10 TB de vetores + índice HNSW prontos para busca em RAM:
- Você precisará de 12 a 15 Terabytes de RAM na sua infraestrutura.
Se você rodar isso na nuvem (AWS/GCP/Azure):
- Uma instância com esse volume de memória (ou um cluster distribuído equivalente) custa facilmente entre USD 10.000 e USD 15.000 por mês.
- Em 10 anos (120 meses), o custo de infraestrutura pura para manter a busca no ar vai variar entre USD 1,2 milhão e USD 1,8 milhão.
Se você usar bancos vetoriais totalmente gerenciados (SaaS), a fatura pode ser ainda maior devido aos custos de transferência de dados e operação.
4. Como Engenheiros de Verdade Resolvem Isso (FinOps & Otimização)
Se você apresentar um orçamento de USD 2 milhões para manter um RAG de 10 TB, o projeto morre na mesa da diretoria. Como a indústria reduz esse custo em até 90%?
A. Quantização de Vetores (Scalar & Binary Quantization)
Em vez de salvar cada dimensão em float32 (4 bytes), podemos usar técnicas de quantização:
-
SQ8 (Scalar Quantization int8): Converte
float32paraint8(1 byte). O tamanho da base cai de 10 TB para 2,5 TB com perda insignificante de precisão (geralmente inferior a 1%). - BQ (Binary Quantization): Converte cada dimensão para apenas 1 bit (0 ou 1). O tamanho da base cai de 10 TB para inacreditáveis 312 Gigabytes (uma redução de 32x).
B. Embeddings Matryoshka (MRL)
Modelos modernos suportam Matryoshka Representation Learning. Eles permitem que você "corte" o vetor de 1.536 dimensões para 512 ou 256 dimensões mantendo a maior parte do significado semântico. Menos dimensões = menos RAM e menos armazenamento.
C. Índices em Disco (DiskANN e pgvector em NVMe)
Em vez de manter tudo em RAM, utilizam-se arquiteturas como o DiskANN ou extensão do pgvector otimizada para armazenamento em discos SSD NVMe super rápidos. Os vetores residem em disco e apenas os nós mais acessados do grafo ficam em cache na RAM. O custo de disco SSD é até 10x menor do que o custo de memória RAM na nuvem.
D. Self-Hosting para Re-embeddings em Massa
Para economizar na taxa de API durante migrações de 10 TB, a estratégia é levantar instâncias Spot com GPUs (ex: NVIDIA H100/A100) e rodar motores de inferência locais como o Text Embeddings Inference (TEI) da Hugging Face. O custo de re-embedding processado em lote via GPU própria cai drasticamente comparado ao custo por token de APIs pagas.
Conclusão
RAG em escala de produção não é apenas um desafio de chamar OpenAI.embeddings.create(). É uma disciplina rigorosa de Engenharia de Sistemas Distribuídos e FinOps.
Quem não entende a matemática do espaço latente quebra a busca semântica. Quem não entende a matemática do volume de dados e da infraestrutura quebra a empresa.
Antes de desenhar o fluxo da sua aplicação de IA, pegue a calculadora: defina o tamanho dos seus vetores, projete o ciclo de vida dos modelos e planeje como sua arquitetura vai sobreviver quando a sua base atingir Terabytes.
