Os LLMs só conseguem "ver" uma quantidade limitada de texto por vez (a janela de contexto). Isso funciona para tarefas pequenas, mas deixa de funcionar quando uma base de conhecimento abrange milhares de páginas. Mesmo quando a janela de contexto é suficiente, o desempenho ainda pode piorar devido ao problema de "agulha no palheiro".
RAG ("geração aumentada por recuperação") tornou-se um padrão muito comum: você mantém uma base de conhecimento (documentos, wikis, políticas, transcrições etc.), faz uma busca semântica com a consulta do usuário para recuperar os trechos mais relevantes usando embeddings e, então, fornece esses trechos ao LLM junto com a pergunta. Isso restringe o contexto do modelo e, quando feito corretamente, pode melhorar a qualidade das respostas e reduzir alucinações.
pgai é uma extensão de código aberto para Postgres, acompanhada de ferramentas, que ajuda a criar fluxos de trabalho de "recuperação por IA" sobre o PostgreSQL, um banco de dados de código aberto confiável.
A principal ideia é levar uma parte maior do pipeline padrão de RAG para a camada do banco de dados (ingerir → dividir em trechos → gerar embeddings → manter os embeddings sincronizados), em vez de tratar o banco como "apenas armazenamento" de embeddings.
Nossa impressão inicial é que a proposta é promissora, mas deixa de ser adequada quando o pipeline de RAG fica um pouco mais complexo, principalmente nas abordagens de divisão em trechos. Ainda assim, acompanharemos este projeto de perto.
Há muitas maneiras de criar RAG. Para uma análise mais detalhada das diferentes abordagens, leia Exemplos práticos de soluções RAG personalizadas. O leque de possibilidades se torna surpreendentemente amplo quando a qualidade importa, e a abordagem "padrão" mais comum costuma ser assim:
Reúna um conjunto de documentos.
Divida-os em trechos. Há muitos métodos diferentes para fazer isso (por exemplo, por parágrafos ou agrupamentos semânticos).
Transforme cada trecho em um embedding.
Armazene os embeddings em um banco de dados vetorial (Pinecone, Milvus etc.) ou no Postgres usando pgvector.
No momento da consulta, procure os trechos mais próximos `e forneça-os ao LLM (novamente... também há muitas maneiras de fazer isso).
Em muitas arquiteturas, as etapas (1)–(3) ocorrem fora do banco de dados, no código da aplicação ou em um pipeline de dados, e o banco é usado principalmente para:
armazenar embeddings
pesquisar embeddings
pgai é uma extensão de código aberto para Postgres, desenvolvida pela Timescale, que tenta atenuar essa divisão.
Em vez de tratar os embeddings como algo que sua aplicação gerencia manualmente, o pgai os transforma em um recurso do banco de dados:
Você define quais tabelas ou documentos deseja transformar em embeddings.
Você especifica o modelo de embedding e uma estratégia de divisão em trechos.
O pgai gerencia o restante, inclusive mantendo os embeddings atualizados conforme os dados de origem mudam.
A proposta é atraente:
Menos código de integração personalizado para manter.
Deve ser mais fácil manter os embeddings "atualizados" conforme os documentos de origem mudam.
Postgres/pgai gerencia novas tentativas, limites de taxa, tarefas com falha etc.
Nota ao leitor: o pgai inclui o pgvector, outra extensão muito popular de RAG para Postgres. O pgvector adiciona armazenamento vetorial e busca por similaridade ao Postgres, enquanto o pgai usa esses recursos para automatizar etapas do pipeline de RAG, como divisão em trechos, geração de embeddings e atualização desses embeddings.
1) É fácil colocá-lo em funcionamento.
O fluxo ideal é relativamente simples:
Baixe as imagens Docker da Timescale (banco de dados + worker).
Forneça a chave de API do seu provedor de embeddings.
Execute algumas instruções SQL para declarar o vetorizador (basicamente: o que transformar em embeddings, como dividir o conteúdo em trechos e qual modelo usar).
Depois disso, o pgai faz com que um worker de vetorização seja executado como processo separado e gere embeddings de forma assíncrona (por exemplo, a cada cinco minutos ou na frequência que você quiser).
2) É conveniente executar todo o pipeline "perto" do banco de dados.
O pgai pode ingerir conteúdo de tabelas e também carregar documentos de locais como o S3 para, depois, analisá-los, dividi-los em trechos e gerar embeddings. Ele também processa diferentes formatos de documentos de texto, como PDF, Markdown etc.
1) Você perde muito controle, e às vezes RAG exige controle.
Sistemas RAG de alto desempenho, quando avaliados pela qualidade das respostas, muitas vezes exigem pipelines personalizados, como:
regras personalizadas de divisão em trechos (por títulos, páginas, turnos de fala etc.)
divisão em trechos sensível a metadados (preservando títulos de seção, carimbos de data e hora, autores e tipo de documento)
diferentes estratégias de embedding para cada tipo de documento
O pgai oferece menos flexibilidade nesses aspectos.
No momento, há duas estratégias principais de divisão em trechos: separador de texto por caracteres e separador recursivo de texto por caracteres, além da opção de não dividir. Isso pode bastar para alguns casos de uso, mas muitos sistemas RAG em produção exigem mais personalização.
Seria excelente se a Timescale incorporasse algumas das estratégias mais sofisticadas de divisão em trechos presentes em bibliotecas como a Chonkie e também oferecesse suporte a projetos avançados como a recuperação contextual da Anthropic.
2) Prioriza texto, não multimodalidade.
Muitos problemas interessantes de RAG já não envolvem apenas texto:
PDFs com diagramas
capturas de tela/imagens
gravações de áudio
clipes de vídeo
Mesmo que seja possível "extrair texto" dessas fontes, isso não equivale a um verdadeiro pipeline multimodal de embeddings.
Se o pgai vier a oferecer suporte completo a modelos multimodais (carregar → dividir em trechos → gerar embeddings para imagens, áudios e vídeos grandes armazenados no S3, com sincronização robusta), será uma proposta atraente. Hoje, porém, ele oferece um fluxo de trabalho de embeddings de texto.
3) Se você só precisa de embeddings, talvez não precise do pgai.
Se seu pipeline de ingestão já é personalizado, ou precisa ser, então "gerar embeddings de trechos de texto" não é a parte mais difícil de RAG. Nesse cenário, o pgai resolve a parte mais fácil do problema.
Além disso, se sua base de conhecimento é atualizada com pouca frequência, a sincronização automática de embeddings oferece menos valor.
Uma forma especialmente útil de usar o pgai seria implantar uma interface de texto para SQL sobre seus bancos de dados. Isso pode ser feito com bastante facilidade usando o módulo semantic_catalog oferecido pelo pgai. Basta configurar assim:
Bash
e fazer o catálogo semântico analisar seus dicionários de dados com pgai semantic-catalog create. Isso gera um contexto a partir do seu repositório de dados semelhante a este:
Plain Text
Esse contexto agora está disponível ao pgai de várias maneiras:
Por meio de busca semântica:
Esta consulta retornará as tabelas, funções e outros objetos que podem ser relevantes para sua consulta em linguagem natural:
Bash
Obter contexto bruto:
Isso renderizará o contexto YAML bruto relacionado à sua consulta em linguagem natural:
Bash
Gerar SQL:
Ou você pode gerar diretamente o SQL bruto necessário para responder à consulta. O contexto da etapa anterior é enviado a um LLM, que gera a resposta:
Bash
Se você estiver criando um sistema RAG relativamente simples, vale a pena testar o pgai caso queira:
Postgres como seu sistema de registro,
o mínimo possível de código de integração,
embeddings que permaneçam sincronizados automaticamente,
uma maneira rápida de aplicar conversão de texto em SQL aos seus bancos de dados,
experimentar novas ferramentas de RAG e extensões do Postgres.
Provavelmente vale a pena esperar antes de adotar o pgai se seu pipeline de RAG exigir qualquer um dos seguintes itens:
lógica altamente personalizada de ingestão ou divisão em trechos
muitos tipos de documentos com diferentes requisitos de análise
embeddings multimodais
Por fim, embora esteja claro que o pgvector teve forte adoção, não se sabe se o pgai despertará o mesmo nível de interesse e, consequentemente, de suporte — ainda que exista há apenas cerca de 18 meses.
O pgai é uma abordagem interessante de RAG que permite aos bancos de dados assumir uma parte maior do trabalho operacional rotineiro, simplificando o código da aplicação.
No momento, ele é:
útil e realmente agradável para configurações simples de RAG
pouco flexível para pipelines mais personalizados, especialmente os multimodais
É promissor e certamente vale a pena acompanhar sua evolução.