PostgreSQL como base para IA empresarial: RAG, embeddings e agentes em produção

Em palestra no QCon AI 2025, Gwen Shapira apresentou como o PostgreSQL pode ser a base confiável para funcionalidades de IA em produção, combinando consultas SQL determinísticas, busca semântica com pgvector e suporte a agentes com memória transacional.

O contexto: a demanda por dados confiáveis na era dos LLMs

Com a explosão do ChatGPT em 2023 e a rápida evolução de modelos como Claude e Gemini, as empresas passaram a integrar IA em funcionalidades críticas. No entanto, modelos de linguagem precisam de contexto rico e preciso para gerar respostas úteis.

Gwen Shapira defende que dominar dados é fundamental para extrair valor real de LLMs — e que o PostgreSQL, com seus 30 anos de maturidade, oferece uma base sólida para isso. A Apple, por exemplo, historicamente focada em privacidade, tem dificuldades em personalização, enquanto Google, com sua expertise em dados, alcançou a liderança em IA.

RAG Relacional: contexto determinístico com SQL

Shapira propõe um exemplo prático: priorização automática de tickets em um sistema similar ao Jira. Em vez de depender apenas de vetores, ela mostra como consultas SQL podem fornecer contexto determinístico para o LLM.

Usando joins, agregações e funções de janela, é possível extrair informações como: número de tickets abertos por prioridade, percentil de idade do ticket, se ele bloqueia issues críticas, e até tendências de reclamações de clientes. Tudo isso em SQL puro, sem precisar de um banco de grafos separado.

O PostgreSQL permite retornar resultados diretamente em JSON com funções como <code>json_build_object</code>, economizando processamento na aplicação. Shapira recomenda evitar JSON muito aninhado e sugere testar o formato TOON (CSV com cabeçalho) para economizar tokens.

• Use SQL para obter dados agregados e relacionais que o LLM precisa.
• Retorne o resultado em JSON diretamente do banco com funções nativas.
• Considere TOON como alternativa mais eficiente que JSON para prompts.

Busca semântica com embeddings e pgvector

Para encontrar tickets similares por semântica (e não apenas por palavras-chave), o pgvector é a extensão oficial do PostgreSQL para vetores. Ela suporta indexação HNSW (Hierarchical Navigable Small World), que oferece alta recall mesmo em grandes volumes.

Um benchmark de Jonathan Katz mostrou que o HNSW supera o IVFFlat em todos os níveis de recall. Enquanto o IVFFlat pode cair para 70% de recall, o HNSW mantém 90%+ com performance consistente. A chave é garantir que a camada superior do HNSW caiba em memória.

Reduzir os vetores de 32 bits para 8 ou 16 bits (quantização) corta memória, disco e CPU em até 4x, com recall caindo de 99,99% para 98,5% — aceitável na maioria dos casos. Shapira recomenda testar essa otimização antes de descartá-la.

• HNSW oferece melhor recall que IVFFlat, mas exige que a camada superior esteja em RAM.
• Quantização de vetores (halfvec ou byte) pode acelerar consultas em 4x.
• Sempre valide visualmente os resultados da busca semântica antes de enviar ao LLM.

Agentes: ferramentas e memória com ACID

Shapira defende uma abordagem em duas etapas: primeiro, aprenda a resolver o problema manualmente (com RAG determinístico e semântico); depois, construa ferramentas que o LLM possa usar de forma autônoma.

As ferramentas são simples funções descritas em JSON para o LLM. O SDK cuida do loop: recebe tool calls, executa as funções e retorna o resultado. Para simplificar, o protocolo MCP (Model Context Protocol) permite delegar a execução a servidores externos.

Quando múltiplos agentes precisam registrar decisões, o PostgreSQL oferece transações e bloqueios de linha. Shapira sugere iniciar uma transação, verificar se a linha está disponível (SELECT FOR UPDATE NOWAIT) e, caso contrário, pular o ticket — um sistema de fila de trabalho básico sem necessidade de filas externas.

Por que PostgreSQL para IA?

Maturidade e confiabilidade: 30 anos de desenvolvimento, menos bugs que bancos vetoriais novos. Multimodal: JSON, geográfico, vetores, tudo no mesmo banco.

Extensibilidade: extensões como pgvector, PostGIS, e a possibilidade de criar índices customizados. Segurança: controle de acesso em nível de linha (RLS) para limitar o que agentes podem ler ou escrever.

• Maturidade e confiabilidade comprovadas.
• Suporte nativo a JSON, geográfico e vetores.
• Extensível com pgvector, PostGIS e outras extensões.
• Segurança com Row-Level Security para agentes.

Arraste para o lado para ver toda a tabela.

Perguntas Frequentes (FAQ)

Posso usar PostgreSQL para busca semântica sem precisar de um banco vetorial separado?

Sim, com a extensão pgvector você adiciona suporte a vetores e índices HNSW diretamente no PostgreSQL, eliminando a necessidade de um banco dedicado.

O que é quantização de vetores e como ela acelera as consultas?

Quantização reduz a precisão dos vetores (de 32 bits para 8 ou 16 bits), diminuindo o uso de memória e CPU em até 4x, com perda mínima de recall (de 99,99% para 98,5% na maioria dos casos).

Como garantir que agentes não interfiram entre si ao escrever no banco?

Use transações ACID com SELECT FOR UPDATE NOWAIT para bloquear linhas; se outro agente encontrar o lock, ele pode pular o ticket ou esperar.

É melhor criar embeddings de tickets inteiros ou de partes específicas?

Depende do contexto. Se o ticket contém informações muito diversas, embeddings de partes menores (como título e descrição separados) podem gerar buscas mais precisas.