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.

Infraestrutura para RAG: o que você precisa

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.

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"}'

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"}}'

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: