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.
PostgreSQL oferece consultas SQL determinísticas para fornecer contexto rico a LLMs, sem precisar de bancos especializados.
A extensão pgvector com índice HNSW proporciona busca semântica de alta performance e recall.
Quantização de vetores (8 ou 16 bits) acelera consultas em até 4x com perda mínima de qualidade.
Para agentes, ferramentas são funções descritas em JSON; o PostgreSQL gerencia memória e concorrência com ACID.
Valide o resultado da busca vetorial antes de passar ao LLM para evitar enganos.
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 LLM, 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 json_build_object, 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.
| Característica | RAG Determinístico (SQL) | RAG Semântico (Vetores) |
|---|---|---|
| Tipo de busca | Exata, baseada em regras | Aproximada, baseada em similaridade |
| Ferramenta | Consultas SQL com joins e agregações | pgvector com índice HNSW |
| Performance | Previsível, depende da query | Variável, depende de parâmetros do índice |
| Recall | 100% (dados exatos) | 90-99% (aproximado) |
| Melhor para | Metadados, agregações, contexto estruturado | Conteúdo textual, documentos, similaridade |
Arraste para o lado para ver toda a tabela.
Perguntas Frequentes
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.
