Annunciamo Lakebase Search: recupero nativo per gli agenti integrato in Lakebase Postgres

Oggi presentiamo Lakebase Search: il recupero ibrido vettoriale e full-text integrato in Lakebase, ora disponibile in beta su AWS e Azure. Basato su due estensioni Postgres native, lakebase_vector e lakebase_text, consente all'intero loop del tuo agente di affidarsi a un unico backend di dati, un lakebase.

Questo offre scalabilità di livello superiore, un'efficienza economica straordinaria e un'ergonomia agent-first.

Gli agenti trasformano la ricerca in un flusso di lavoro operativo: recuperano il contesto, ragionano, agiscono e ricordano. Questo collega profondamente il percorso di lettura (recupero) con quello di scrittura (memoria), rendendo il recupero istantaneo essenziale per accedere in tempo reale a insight appena generati.

Fino ad ora, questo loop non aveva una soluzione nativa Postgres progettata per la scalabilità e l'efficienza economica richieste dalla ricerca su larga scala.

Per gli agenti, la ricerca è in realtà un carico di lavoro operativo

Oggi gli agenti gestiscono un numero di database su Lakebase 4 volte superiore rispetto agli utenti umani, e il loro requisito principale è completamente diverso da quello di un essere umano. I motori di ricerca tradizionali presuppongono uno snapshot in sola lettura di dati non aggiornati. Gli agenti, invece, trattano la ricerca come un database operativo in tempo reale.

Consideriamo uno schema tipico di un agente: i documenti suddivisi in blocchi (chunk) e gli embedding risiedono direttamente accanto a un log di memoria conversazionale attivo. Questo crea un loop continuo di lettura/scrittura. Gli agenti scrivono le nuove informazioni apprese nella memoria in un passaggio e hanno bisogno che quegli stessi dati siano completamente indicizzati e ricercabili in quello successivo. Non hanno solo bisogno di un recupero rapido; richiedono una ricerca istantanea sulle ultimissime scritture.

La ricerca è un carico di lavoro particolare

La ricerca è un carico di lavoro unico con due proprietà distintive.

In primo luogo, si memorizza una quantità di dati decisamente superiore a quella effettivamente interrogata, lasciando la maggior parte di essi cold.

In secondo luogo, la ricerca vettoriale causa un notevole aumento del volume dei dati (data bloat). Un file di testo da 1 KB si espande quando viene vettorizzato. Questo accade perché il documento viene suddiviso in più chunk, e ogni chunk genera un embedding ad alta dimensionalità distinto, ancor prima di calcolare l'overhead dell'indice.

Quando questo effetto si moltiplica su migliaia di tenant per lo più inattivi, le architetture di ricerca tradizionali falliscono. Gli indici vettoriali standard del settore, come HNSW, sono fondamentalmente vincolati alla memoria (memory-bound). Poiché l'attraversamento rapido dei grafi dipende fortemente dal fatto che l'indice rimanga residente nella RAM, ospitare dati multi-tenant cold è costoso.

La ricerca ha bisogno di un lakebase

L'anno scorso abbiamo introdotto Lakebase: un'architettura OLTP Postgres serverless in cui i dati risiedono in un economico storage di oggetti cloud, ma una cache multilivello (RAM, NVMe locale, pageserver) garantisce la lettura delle pagine hot con la latenza di un disco locale.

Ci siamo resi conto che questa è esattamente l'architettura di cui ha bisogno la ricerca moderna. Ma c'era un problema: per sbloccare effettivamente questi vantaggi economici senza compromettere la velocità delle query, è necessario un layout dell'indice progettato esplicitamente per risiedere in una gerarchia di storage multilivello. Lakebase non ne aveva uno. Quindi, lo abbiamo creato.

Abbinando un'architettura multilivello a un indice multilivello appositamente progettato, otteniamo:

• Scalabilità di livello superiore senza penalizzare la velocità: Recuperando in modo intelligente solo le pagine richieste dallo storage di oggetti in una cache locale, le istanze Postgres più piccole ottengono gli stessi livelli di recall e latenza senza richiedere enormi risorse di calcolo.
• Efficienza economica di livello superiore: La parte cold dei vettori risiede in uno storage di oggetti quasi gratuito, mentre il working set hot vive su NVMe. Paghi per quello che interroghi, non per quello che memorizzi.

I vantaggi economici sono più facili da comprendere sotto forma di tabella. Per terabyte al mese, ai prezzi di listino del cloud:

Il nostro metodo di indicizzazione consente a Lakebase di mantenere in RAM solo il working set attivo. La maggior parte dei dati cold rimane nello storage di oggetti, rendendo il sistema più economico di due ordini di grandezza, pur offrendo la ricerca ad alte prestazioni effettivamente richiesta dalla tua applicazione.

Portare gli indici di ricerca nativi del lake su Postgres.

Durante lo sviluppo di Lakebase Search, ci siamo concentrati su due proprietà non negoziabili.

Durante lo sviluppo di Lakebase Search, avevamo due requisiti rigorosi: doveva essere nativo di Postgres al 100% (riutilizzando i tipi standard pgvector/tsvector e gli strumenti dell'ecosistema) e l'indicizzazione doveva essere progettata da zero per lo storage di oggetti cloud multilivello.

Per raggiungere questo obiettivo, oggi lanciamo in Beta due nuove estensioni Postgres. Entrambe condividono lo stesso scopo: offrire una rilevanza di ricerca all'avanguardia senza costringerti a sovradimensionare la RAM.

1. lakebase_vector: compressione 32x e scalabilità oltre 1 miliardo.

Abbiamo mantenuto i tipi di dati e gli operatori pgvector standard, ma abbiamo modificato il tipo di indice sottostante. Poiché i dati rimangono nel formato nativo pgvector, mantengono la compatibilità e possono essere esportati in altri sistemi. Raggruppando (clustering) e comprimendo i vettori tramite RaBitQ (Randomized Binary Quantization), riduciamo l'ingombro dell'indice di 32 volte mantenendo un'elevata recall. Un indice da 100 milioni di vettori che in precedenza richiedeva 300 GB di RAM ora occupa meno di 10 GB. Questo ingombro di memoria ridotto consente a un singolo indice di scalare fino a oltre 1 miliardo di vettori. Il working set attivo viene memorizzato nella cache su NVMe locale, mentre la parte cold risiede nello storage di oggetti.

2. lakebase_text: BM25 autentico senza l'ingombro di memoria di GIN.

Postgres gestisce la corrispondenza esatta delle parole chiave tramite indici GIN, che devono rimanere residenti in RAM per mantenere le prestazioni. Questa architettura fa sì che i costi di memoria scalino linearmente con le dimensioni del dataset.

lakebase_text sostituisce GIN con un indice ottimizzato per letture sequenziali dallo storage di oggetti cloud. Introduce il ranking di rilevanza BM25 nativo in Postgres senza l'ingombro di RAM associato.

Poiché entrambe le estensioni vengono eseguite all'interno dello stesso motore, la ricerca ibrida viene eseguita in una singola query SQL. La somiglianza vettoriale e la rilevanza delle parole chiave vengono combinate tramite RRF (reciprocal rank fusion), consentendo di unire e filtrare i risultati rispetto alle tabelle operative.

Postgres è pronto per carichi di lavoro di ricerca importanti e su larga scala

Abbiamo eseguito il benchmark di Lakebase Search su LAION-100M (100 milioni di vettori a 768 dimensioni, recupero top-10, su una singola istanza). Le prestazioni delle query con una cache warm e una singola connessione offrono una recall esatta dei vicini più prossimi (nearest neighbor) con zero bloat:

Raggiungere questa scala richiede tradizionalmente un'architettura di tipo memory-bound. Un indice HNSW pgvector standard richiede che il grafo dei vicini e le relative pagine heap di destinazione rimangano residenti in RAM per un attraversamento efficiente. A 100 milioni di vettori:

1. pgvector: richiede un'istanza da 512 GB (64 CPU). La compilazione dell'indice richiede circa 40 ore. Poiché l'attraversamento del grafo si basa su un accesso casuale non localizzato, i riavvii cold causano pesanti latenze di lettura del disco, facendo sì che la prima query richieda minuti.
2. lakebase_vector: viene eseguito su un'istanza da 192 GB (96 CU / 24 CPU). La compilazione dell'indice richiede 1,5 ore. Sebbene l'attraversamento sia ancora ad accesso casuale, il layout dell'indice raggruppa i dati in modo che le ricerche casuali siano localizzate all'interno di un working set hot sulla cache NVMe, lasciando la parte cold nello storage di oggetti. L'istanza scala a zero quando è inattiva; la prima query con cache cold richiede 1,13 secondi.

Questa architettura cambia il modo di considerare il costo totale di proprietà (TCO). La ricerca legacy richiede un costo di base fisso indipendentemente dal volume delle query, mentre Lakebase tiene traccia dell'utilizzo effettivo:

Lakebase Search consente un'ergonomia orientata agli agenti

Un unico backend per memoria e contesto:

Gli agenti non dovrebbero dover unire un database vettoriale per il contesto e un database transazionale per la memoria. Inviando la logica di recupero direttamente nel database, l'intero ciclo dell'agente viene eseguito su un unico backend. Poiché Lakebase Search è Postgres (riutilizzando completamente i tipi standard pgvector e tsvector), si collega nativamente ai tuoi MCP, driver standard e connettori esistenti. Inoltre, poiché la ricerca si trova proprio accanto ai dati operativi, puoi eseguire una ricerca ibrida, effettuare join con le tabelle dell'applicazione e filtrare in sicurezza per tenant, il tutto in una singola query SQL.

Sperimentazione continua della ricerca

L'ottimizzazione delle strategie di chunking o dei pesi ibridi richiede tentativi ed errori. Invece di esportare i dati a sistemi batch esterni per la rielaborazione, Lakebase Search si connette al Lakehouse per creare un rapido ciclo di feedback. Puoi creare branch di dataset multi-terabyte istantaneamente e a costo zero, creare indici out-of-band utilizzando il calcolo parallelo e reindirizzare il feedback dell'agente al Lakehouse per la valutazione offline.

Un motore di recupero dedicato per ogni agente

Le architetture tradizionali richiedono la condivisione di un singolo cluster di ricerca tra tutti gli agenti. Poiché gli indici inattivi in Lakebase comportano costi di archiviazione quasi nulli, puoi configurare migliaia di corpora isolati dedicati a specifici agenti, utenti o sessioni. Questo trasforma la ricerca da uno snapshot statico a un ciclo operativo di lettura/scrittura; i dati scritti da un agente in un passaggio vengono sottoposti a commit e sono recuperabili in quello successivo con garanzie transazionali complete.

Un'unica base per il ciclo dell'agente

Lakebase elimina la necessità di collegare tra loro vector store, cluster di ricerca e database transazionali separati. Consolidando l'intero ciclo di vita all'interno di un unico sistema Postgres, offre la scalabilità e i costi ridotti dell'object storage cloud multilivello, insieme all'ergonomia di lettura/scrittura in tempo reale richiesta per i flussi di lavoro basati su agenti.

Lakebase Search è disponibile oggi in versione Beta su AWS e Azure. Cosa creeranno i tuoi agenti?

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale