Arquitetura RAG em produção: o que muda quando o piloto vira produto

Quase todo time que testa Retrieval-Augmented Generation chega rápido a um protótipo convincente. O problema aparece depois: quando o corpus cresce, quando usuários reais fazem perguntas ambíguas e quando alguém pergunta quanto custou a fatura do mês.

Ingestão: o chunking define o teto de qualidade

Nenhuma etapa posterior corrige um chunking ruim. Dividir o documento a cada 500 caracteres é simples e destrói contexto. A abordagem que sustenta produção respeita a estrutura semântica do documento — títulos, seções, tabelas — e mantém sobreposição controlada.

• Preserve metadados de origem em cada chunk: documento, seção, página, data.
• Use sobreposição entre 10% e 20% para não cortar raciocínios no meio.
• Trate tabelas e código como blocos indivisíveis sempre que possível.
• Reprocesse de forma assíncrona: ingestão nunca deve bloquear a requisição do usuário.

Armazenamento vetorial com pgvector

Para a maioria dos produtos, um PostgreSQL 16 com a extensão pgvector resolve. Você ganha transações, joins com dados relacionais e um único sistema para operar — o que vale mais do que os últimos milissegundos de um banco vetorial dedicado.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE document_chunks (
  id          bigserial PRIMARY KEY,
  document_id uuid NOT NULL,
  content     text NOT NULL,
  metadata    jsonb NOT NULL DEFAULT '{}',
  embedding   vector(1536) NOT NULL,
  created_at  timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX ON document_chunks
  USING hnsw (embedding vector_cosine_ops);

Recuperação: busca híbrida e reranking

Busca puramente vetorial falha em consultas com termos exatos: códigos de produto, nomes próprios, números de versão. A combinação de busca lexical (full-text) com similaridade de cosseno, seguida de um reranker cruzado sobre os 30 primeiros resultados, é o padrão que se sustenta.

Quando o reranking não compensa

Se o produto exige resposta abaixo de 400 ms de primeiro token, o reranker cruzado pode ser caro demais. Nesses casos, invista em qualidade de chunking e em cache semântico no Redis antes de aceitar a latência extra.

Observabilidade e custo

Sem rastreabilidade, você não tem produto — tem uma caixa-preta. Instrumente cada requisição com trace completo: pergunta, chunks recuperados, prompt final, resposta, tokens consumidos e custo estimado.

O time que não mede custo por conversa descobre o problema pela fatura, não pelo dashboard.

Checklist antes de ir ao ar

1. Conjunto de avaliação com pelo menos 100 perguntas reais e respostas esperadas.
2. Rate limiting por usuário e por organização.
3. Fallback explícito quando a recuperação não traz contexto suficiente.
4. Alertas de custo diário e de latência p95.
5. Plano de reindexação sem downtime.

RAG em produção é, no fim, engenharia de dados disciplinada com um modelo generativo no final da esteira. Quem trata a recuperação como o produto — e não o modelo — chega mais longe.