RAG para empresas: como dimensionar a infraestrutura?

Implementar RAG para empresas exige mais do que conectar um modelo de linguagem a documentos internos. Para entregar respostas relevantes, a arquitetura precisa recuperar informações rapidamente, processar consultas simultâneas e manter o controle sobre os dados utilizados.

O Retrieval-Augmented Generation, ou geração aumentada por recuperação, permite que modelos de IA utilizem informações externas durante a geração de respostas, sem depender exclusivamente do conhecimento incorporado aos seus parâmetros.

Em ambientes corporativos, essa abordagem pode ser aplicada a bases de conhecimento, documentos técnicos, contratos, manuais, políticas internas e sistemas de atendimento.

Entretanto, conforme o volume de documentos e usuários aumenta, surgem desafios de memória, armazenamento, indexação e capacidade de inferência.

Neste artigo, explicamos como dimensionar esses componentes e identificar os principais gargalos antes de colocar uma solução RAG em produção.

O que é RAG e como funciona em aplicações corporativas?

RAG é uma arquitetura que combina recuperação de informações com geração de texto por modelos de linguagem. Antes de responder, o sistema busca conteúdos relevantes em uma fonte externa e os fornece ao modelo como contexto.

Essa abordagem permite utilizar documentos atualizados sem necessariamente realizar fine-tuning do modelo para incorporar cada alteração na base de conhecimento.

Quais são as etapas de um fluxo RAG?

Uma implementação típica envolve duas fases: preparação dos dados e execução das consultas.

Na preparação:

1. Os documentos são coletados de fontes autorizadas.
2. O conteúdo é extraído e normalizado.
3. Os textos são divididos em trechos, chamados chunks.
4. Um modelo de embeddings transforma os trechos em vetores.
5. Os vetores e seus metadados são indexados.

Durante a consulta, o sistema transforma a pergunta em uma representação compatível, recupera os trechos relevantes e os encaminha ao LLM para geração da resposta.

Também podem existir etapas adicionais de filtragem, reranking e validação.

Qual é a diferença entre RAG e fine-tuning?

O RAG fornece informações externas ao modelo durante a inferência. Já o fine-tuning modifica parâmetros do modelo a partir de um processo de treinamento adicional.

Para consultas a documentos que mudam frequentemente, RAG costuma ser uma alternativa adequada, pois permite atualizar a base recuperável sem retreinar o LLM.

Entretanto, a recuperação não garante que todas as respostas serão corretas. A qualidade depende dos documentos, da busca e do comportamento do modelo.

Quais componentes formam uma arquitetura RAG em produção?

Uma arquitetura RAG combina processamento de documentos, geração de embeddings, busca, inferência e serviços de aplicação. Cada componente apresenta requisitos próprios de infraestrutura.

Esses componentes não precisam estar no mesmo servidor. Uma arquitetura pode manter o banco vetorial em um ambiente e executar a inferência em outro.

Essa separação facilita o dimensionamento independente e a identificação de gargalos.

Quando utilizar GPU dedicada em uma arquitetura RAG?

A GPU dedicada pode acelerar modelos de embeddings, reranking e geração de respostas. Sua necessidade depende de onde esses modelos são executados, do volume de consultas e dos requisitos de latência.

Uma aplicação que utiliza APIs externas para embeddings e inferência pode operar sem GPU local.

Já uma empresa que deseja hospedar seus próprios modelos precisa avaliar a capacidade computacional necessária.

GPU para geração de embeddings

Modelos de embeddings convertem textos em representações numéricas que permitem comparar similaridade semântica.

Para bases pequenas e atualizações esporádicas, a execução em CPU pode ser suficiente.

Em processos de indexação de grandes volumes de documentos, GPUs podem acelerar o processamento em lotes, conforme o modelo utilizado.

GPU para inferência de LLMs

Quando o modelo de linguagem é executado localmente, a GPU pode ser um dos componentes mais importantes da arquitetura.

O dimensionamento deve considerar o tamanho do modelo, a precisão numérica, a janela de contexto e a concorrência.

Uma GPU com VRAM insuficiente pode impedir o carregamento do modelo ou exigir técnicas de redução de memória.

GPU para reranking

O reranking utiliza modelos para reavaliar a relevância dos documentos recuperados.

Essa etapa pode melhorar a seleção de contexto, mas também acrescenta processamento e latência.

O uso de GPU depende do tamanho do modelo de reranking e do volume de consultas.

Para projetos que precisam executar modelos próprios, conheça as opções de GPU dedicada da EVEO.

Como dimensionar a VRAM para modelos utilizados em RAG?

A VRAM deve acomodar os pesos do modelo, o KV cache e as estruturas temporárias utilizadas durante a inferência. O consumo varia conforme a arquitetura, a precisão numérica e a quantidade de requisições simultâneas.

Como estimar a memória dos pesos?

Uma aproximação inicial é multiplicar a quantidade de parâmetros pelo número de bytes utilizados por parâmetro.

Memória dos pesos ≈ parâmetros × bytes por parâmetro

Considere um modelo hipotético de 8 bilhões de parâmetros:

Esses valores são estimativas decimais simplificadas. Quantização, metadados e detalhes de implementação podem alterar o consumo real.

Além dos pesos, é necessário reservar VRAM para KV cache, buffers, execução do mecanismo de inferência e picos de concorrência.

Como o contexto recuperado influencia a VRAM?

O RAG acrescenta trechos recuperados ao prompt enviado ao modelo.

Quanto maior o contexto e a quantidade de solicitações simultâneas, maior pode ser o consumo do KV cache.

Por isso, recuperar mais documentos não significa necessariamente obter respostas melhores.

É importante equilibrar relevância, quantidade de tokens e custo de processamento.

Como escolher um banco de dados vetorial para RAG?

O banco vetorial armazena representações numéricas dos documentos e permite recuperar informações semelhantes a uma consulta. A escolha depende da quantidade de vetores, da latência exigida, dos filtros e das necessidades operacionais.

Entre as tecnologias utilizadas estão pgvector, Qdrant, Milvus e Weaviate.

Quando utilizar PostgreSQL com pgvector?

O pgvector permite armazenar e consultar embeddings no PostgreSQL.

Essa abordagem pode ser interessante quando a empresa já utiliza PostgreSQL e deseja manter dados relacionais e vetoriais no mesmo ecossistema.

Entretanto, é necessário avaliar o crescimento dos índices, a concorrência e o impacto das consultas vetoriais sobre outras operações.

Consulte a documentação do pgvector para conhecer os tipos de índices e estratégias de busca disponíveis.

Quando considerar um banco vetorial especializado?

Bancos especializados podem oferecer recursos de indexação, distribuição, filtragem e administração voltados a workloads de busca vetorial.

A escolha deve considerar os requisitos da aplicação, a familiaridade da equipe e os resultados de testes com dados representativos.

Também é importante avaliar persistência, backup, controle de acesso e recuperação de falhas.

O que são índices HNSW e IVF?

HNSW e IVF são estratégias utilizadas em sistemas de busca aproximada por vizinhos mais próximos, conhecida como ANN.

Esses índices procuram reduzir o custo da busca em comparação com uma varredura exaustiva, aceitando determinados compromissos entre latência, memória e recall.

O HNSW utiliza estruturas baseadas em grafos e pode apresentar consumo significativo de memória.

Já abordagens IVF organizam os vetores em grupos, permitindo pesquisar subconjuntos do índice.

A configuração deve ser validada com testes de recall e latência, não apenas pelo tempo médio das consultas.

Como calcular o espaço necessário para armazenar embeddings?

O tamanho bruto dos vetores pode ser estimado multiplicando a quantidade de embeddings pela dimensionalidade e pelo número de bytes de cada componente.

Armazenamento bruto = número de vetores × dimensões × bytes por dimensão

Considere uma base hipotética com:

• 1 milhão de chunks indexados.
• 1.536 dimensões por embedding.
• 4 bytes por dimensão, utilizando float32.

O cálculo seria:

1.000.000 × 1.536 × 4
= 6.144.000.000 bytes
≈ 6,14 GB
≈ 5,72 GiB

Esse resultado representa apenas os dados numéricos dos vetores.

O armazenamento real também deve considerar índices, identificadores, metadados, documentos, estruturas internas e políticas de replicação.

Como a dimensionalidade influencia o consumo?

Os valores são estimativas decimais do armazenamento bruto, sem índices ou overhead.

Uma dimensionalidade maior aumenta o volume de dados, mas não garante resultados superiores. A qualidade depende do modelo de embeddings, do domínio dos documentos e da estratégia de recuperação.

Como estimar a quantidade de chunks?

Uma aproximação inicial pode dividir o volume total de tokens pelo tamanho médio dos chunks.

Por exemplo, uma base de 100 milhões de tokens, dividida em chunks de 500 tokens sem sobreposição, produziria aproximadamente 200 mil chunks.

Na implementação real, a quantidade varia conforme a divisão dos documentos, o overlap, os metadados e a estratégia de indexação.

Como planejar o armazenamento de uma arquitetura RAG?

O armazenamento de um sistema RAG precisa contemplar mais do que os embeddings. Documentos originais, textos processados, índices, logs e arquivos temporários também ocupam espaço.

O que deve permanecer em armazenamento persistente?

• Documentos originais e versões autorizadas.
• Textos extraídos e metadados.
• Índices e estruturas do banco vetorial.
• Arquivos de modelos, quando hospedados localmente.
• Registros operacionais necessários.
• Backups e dados de recuperação.

Quando utilizar SSD ou NVMe?

O armazenamento NVMe pode beneficiar bancos vetoriais e serviços que realizam muitas operações de leitura e escrita com requisitos de baixa latência.

Entretanto, o ganho depende de como o banco utiliza RAM, cache e acesso ao disco.

Quando o índice permanece integralmente em memória, a latência de armazenamento pode ter impacto menor nas consultas, mas continua relevante para inicialização, atualizações e persistência.

Como separar documentos e índices?

Uma arquitetura pode utilizar armazenamento de objetos para documentos originais e armazenamento de baixa latência para índices ativos.

Essa separação permite aplicar políticas diferentes de retenção, backup e expansão.

Para documentos e arquivos não estruturados, conheça o Object Storage da EVEO, compatível com S3.

Como dimensionar CPU e RAM para consultas vetoriais?

CPU e RAM são fundamentais para indexação, busca, filtragem e processamento dos resultados. Mesmo quando a inferência utiliza GPU, o banco vetorial pode se tornar o principal gargalo.

Quando a RAM é mais importante?

A memória pode ser utilizada para manter índices, estruturas de busca e páginas frequentemente acessadas.

Índices HNSW, por exemplo, podem demandar memória adicional para representar as conexões entre vetores.

Se o conjunto ativo ultrapassar a capacidade disponível, o sistema pode depender mais de acessos ao disco, conforme a implementação.

Como a CPU influencia as consultas?

A CPU participa de cálculos de similaridade, filtragem, manutenção de índices e processamento de resultados.

O consumo depende do algoritmo, do número de consultas simultâneas e dos filtros aplicados.

Em aplicações corporativas, consultas com múltiplas condições de acesso podem exigir processamento adicional.

Como evitar gargalos?

Monitore utilização de CPU, pressão de memória, latência de disco e tempo de busca.

Também é importante testar a ingestão de novos documentos enquanto as consultas são executadas.

Uma configuração que apresenta bom desempenho em uma base estática pode responder de maneira diferente durante reindexações e atualizações frequentes.

Como reduzir a latência de uma aplicação RAG?

A latência total de uma aplicação RAG corresponde à soma dos tempos de processamento e espera das etapas executadas sequencialmente, além dos efeitos da concorrência.

Entre essas etapas estão geração do embedding da consulta, busca vetorial, reranking, montagem do prompt e inferência.

Quais etapas costumam gerar atrasos?

• Conversão da pergunta em embedding.
• Consultas ao banco vetorial.
• Filtragem por permissões e metadados.
• Reranking de documentos.
• Transferência de dados entre serviços.
• Processamento do contexto pelo LLM.
• Geração dos tokens de resposta.

Como otimizar a recuperação?

É possível ajustar a quantidade de documentos recuperados, o tamanho dos chunks, os parâmetros dos índices e a estratégia de busca.

Buscas híbridas, que combinam recuperação lexical e vetorial, também podem melhorar a relevância em determinados conjuntos de dados.

Entretanto, otimizações de velocidade precisam ser avaliadas junto com métricas de qualidade.

Reduzir o número de documentos recuperados pode diminuir a latência, mas também remover informações necessárias para responder corretamente.

Como avaliar a concorrência?

Testes devem simular múltiplos usuários consultando a base ao mesmo tempo, incluindo diferentes tamanhos de perguntas e contextos.

Além da latência média, acompanhe percentis como p95 e p99, que ajudam a identificar solicitações mais lentas.

Como proteger os dados corporativos em uma arquitetura RAG?

A segurança do RAG depende do controle de acesso aos documentos, da proteção das integrações e da validação das informações recuperadas.

O fato de um documento estar indexado não significa que todos os usuários possam consultá-lo.

Como aplicar permissões por usuário?

O sistema deve considerar as permissões do usuário antes de disponibilizar os trechos recuperados ao modelo.

Isso pode envolver filtros por organização, departamento, classificação da informação ou identidade do solicitante.

Os controles precisam ser aplicados no servidor, com base em identidades verificadas.

Como evitar vazamento de informações?

Entre as medidas recomendadas estão:

• Autenticação e autorização por usuário.
• Separação de dados entre clientes e departamentos.
• Criptografia em trânsito e em repouso.
• Gestão segura de credenciais.
• Políticas de retenção e exclusão.
• Controle de acesso aos logs e backups.
• Testes de recuperação indevida de documentos.

Também é necessário tratar documentos recuperados como conteúdo potencialmente não confiável, evitando que instruções presentes nesses arquivos sejam executadas como comandos privilegiados.

As recomendações da OWASP para aplicações com IA generativa oferecem referências para avaliação desses riscos.

Como considerar a LGPD?

Quando a aplicação processa dados pessoais, é necessário avaliar bases legais, finalidades, controles de acesso, retenção e demais obrigações aplicáveis.

A hospedagem em infraestrutura privada ou nacional não garante automaticamente conformidade.

Consulte a Lei Geral de Proteção de Dados para conhecer os requisitos legais.

Quais métricas monitorar em um ambiente RAG?

O monitoramento deve combinar indicadores de infraestrutura com métricas de qualidade da recuperação e das respostas.

Por que medir a qualidade da recuperação?

Um banco vetorial pode responder rapidamente e ainda assim recuperar documentos inadequados.

Por isso, testes devem utilizar perguntas representativas e um conjunto de referências para avaliar a relevância dos resultados.

Como identificar problemas na geração?

É importante avaliar se as respostas são sustentadas pelos documentos recuperados, se citam corretamente as fontes e se reconhecem a ausência de informações.

Esses testes ajudam a diferenciar falhas de recuperação de problemas na geração pelo LLM.

Qual infraestrutura escolher para implementar RAG em empresas?

A escolha depende do volume de dados, da necessidade de executar modelos localmente e dos requisitos de desempenho e segurança.

Existem diferentes formas de distribuir os componentes.

Como validar o dimensionamento?

Antes da contratação, recomendamos realizar uma prova de conceito com documentos e consultas representativos.

O processo pode seguir estas etapas:

1. Medir o volume atual e o crescimento dos documentos.
2. Definir a estratégia de chunking e embeddings.
3. Estimar a quantidade e o tamanho dos vetores.
4. Testar índices e mecanismos de busca.
5. Medir a latência com usuários simultâneos.
6. Avaliar VRAM, CPU, RAM e armazenamento.
7. Validar qualidade, segurança e recuperação de falhas.

O resultado deve orientar uma configuração que atenda à demanda atual e permita planejar a expansão.

A abordagem da EVEO para projetos RAG corporativos

Projetos RAG exigem capacidade computacional para indexar documentos, executar consultas vetoriais e processar modelos de linguagem.

Na EVEO, oferecemos infraestrutura dedicada para empresas que precisam executar esses componentes com recursos exclusivos e configurações ajustadas aos requisitos de cada aplicação.

Entre as soluções disponíveis estão:

• GPU dedicada NVIDIA: processamento para embeddings, reranking e inferência de modelos compatíveis.
• Servidor Dedicado: recursos exclusivos de CPU, memória e armazenamento para bancos vetoriais e serviços de aplicação.
• Object Storage: armazenamento compatível com S3 para documentos e arquivos não estruturados.
• Conectividade: tráfego ilimitado e opções de portas conforme a configuração contratada.
• Suporte: atendimento técnico 24/7 em português.
• Contratação: mensalidade fixa em reais para os recursos contratados.

A separação entre banco vetorial, armazenamento e inferência permite planejar os recursos de cada componente conforme o volume de dados e a demanda de consultas.

Com uma configuração adequada, sua equipe pode implementar frameworks, bancos de dados e mecanismos de inferência compatíveis com o ambiente contratado.

O dimensionamento deve considerar tanto o desempenho quanto a segurança, a capacidade de expansão e os custos operacionais.

Sobre o autor

Fabio Stein é CTO da EVEO e atua com tecnologia e infraestrutura para aplicações empresariais, incluindo Servidores Dedicados, GPUs para inteligência artificial e ambientes de processamento de alto desempenho.