Qual banco vetorial usar para um projeto pequeno?

Para projetos com menos de 100.000 documentos, Qdrant é a melhor escolha self-hosted: simples, rápido e tem SDK Python oficial. ChromaDB é mais simples ainda (ótimo para protótipos), mas menos performático em produção. pgvector é ideal se você já tem PostgreSQL.

RAG funciona bem com documentos em português?

Sim, mas o modelo de embeddings precisa suportar português. nomic-embed-text e mxbai-embed-large têm boa performance multilingual. Evite modelos treinados apenas em inglês para documentos em PT-BR — a qualidade de recuperação cai significativamente.

Preciso de GPU para rodar RAG?

Para embeddings: não — rodam bem em CPU. Para o LLM de geração: depende do modelo. Com Llama 3.2 3B em CPU, a resposta demora 30–60 segundos. Com GPU T4 e Llama 3.1 8B, menos de 5 segundos. Para produção com SLA de latência, GPU é recomendada.

Quantos documentos uma VPS Pro aguenta indexar?

Com Qdrant e nomic-embed-text em VPS Pro (2 vCPU, 4 GB RAM, 40 GB SSD), você indexa confortavelmente entre 100.000 e 500.000 chunks de 300 tokens. Além disso, considere Qdrant com disco NVMe maior ou migrar para Qdrant Cloud.

RAG é melhor que fine-tuning para dados privados?

Para a maioria dos casos, sim. RAG acessa dados atualizados sem retreinar o modelo, é mais econômico e permite rastreabilidade (você sabe qual trecho originou a resposta). Fine-tuning faz mais sentido quando você quer mudar o estilo de resposta ou injetar conhecimento factual denso que o RAG não recuperaria bem.

IA / LLMs/Artigo

Infraestrutura para RAG: o que você precisa

Para RAG (Retrieval-Augmented Generation) em produção você precisa de três componentes: um modelo de embeddings (para vetorizar documentos e queries), um banco de dados vetorial (para recuperar os trechos mais relevantes) e um LLM (para gerar a resposta com o contexto recuperado). Os três podem rodar self-hosted na mesma VPS para volumes pequenos e médios.

Os 3 componentes do pipeline RAG

O fluxo completo tem duas fases: indexação (offline) e consulta (online). Na indexação, documentos são quebrados em chunks, vetorizados e armazenados. Na consulta, a query é vetorizada, os chunks mais similares são recuperados e passados como contexto ao LLM.

Dica

Indexação: Documento → Chunking → Modelo de Embedding → Vetor → Banco Vetorial. Consulta: Query → Embedding → Busca por similaridade → Top-K chunks → LLM (com contexto) → Resposta.

Modelo de embeddings: opções self-hosted

O modelo de embeddings transforma texto em vetores numéricos. Para RAG self-hosted, as opções mais práticas são:

bash

# Via Ollama (mais fácil — mesma infraestrutura do LLM)
ollama pull nomic-embed-text

# Gerar embedding via API
curl http://localhost:11434/api/embeddings \
  -d '{"model": "nomic-embed-text", "prompt": "Seu texto aqui"}'

Dica

nomic-embed-text (768 dims): boa qualidade para português e inglês, roda em CPU com RAM baixa. mxbai-embed-large (1024 dims): melhor qualidade, mais pesado. Use o mesmo modelo para indexar e para a query — misturar modelos gera buscas incorretas.

Banco vetorial: Qdrant (produção) ou pgvector (PostgreSQL)

Para RAG self-hosted, Qdrant é o banco vetorial mais recomendado para produção — leve, rápido e com API HTTP. Para quem já usa PostgreSQL, pgvector adiciona busca vetorial sem novo serviço:

bash

# Subir o Qdrant via Docker
docker run -d --name qdrant \
  -p 6333:6333 \
  -v qdrant_storage:/qdrant/storage \
  qdrant/qdrant

# Criar uma collection
curl -X PUT http://localhost:6333/collections/documentos \
  -H "Content-Type: application/json" \
  -d '{"vectors": {"size": 768, "distance": "Cosine"}}'

Dica

Use distance: "Cosine" para embeddings de texto (mais comum). Dot Product é equivalente se os vetores forem normalizados. Euclidean funciona pior para embeddings de linguagem.

Stack completo RAG em docker-compose

Configuração para rodar Ollama (LLM + embeddings) + Qdrant (banco vetorial) na mesma VPS:

yaml

services:
  ollama:
    image: ollama/ollama:latest
    restart: always
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama

  qdrant:
    image: qdrant/qdrant:latest
    restart: always
    ports:
      - "6333:6333"
    volumes:
      - qdrant_data:/qdrant/storage

  # Sua aplicação RAG (LangChain, LlamaIndex, etc.)
  app:
    build: .
    environment:
      - OLLAMA_URL=http://ollama:11434
      - QDRANT_URL=http://qdrant:6333
    depends_on:
      - ollama
      - qdrant

volumes:
  ollama_data:
  qdrant_data:

Chunking: a parte mais crítica do RAG

A qualidade do RAG depende principalmente de como você divide os documentos. Chunks muito grandes trazem contexto desnecessário; chunks muito pequenos perdem contexto. Diretrizes práticas:

Dica

Tamanho ideal: 200–500 tokens por chunk para nomic-embed-text. Overlap: 20–50 tokens de sobreposição entre chunks consecutivos para não cortar frases. Estrutura: prefira chunks por parágrafo ou seção lógica em vez de caracteres fixos. Re-ranking: após recuperar top-10, use um modelo de re-ranking para selecionar os top-3 mais relevantes antes de enviar ao LLM.

$ runstack deploy --plan starter

Não quer configurar manualmente?

Não quer configurar manualmente? Implante o Ollama em menos de 3 minutos com a Runstack. Infraestrutura da OPEN DATACENTER, com servidores no Brasil.

Começar agora Ver planos e preços

Perguntas frequentes

Conteúdos relacionados

VPS para Ollama no Brasil →Como instalar o Ollama →Como servir embeddings em produção Como hospedar um agente de IA em produção IA self-hosted sem depender da OpenAI