Présentation de Lakebase Search : récupération native pour les agents intégrée à Lakebase Postgres

Aujourd'hui, nous présentons Lakebase Search : une recherche hybride vectorielle et textuelle intégrée à Lakebase, désormais disponible en bêta sur AWS et Azure. Propulsé par deux extensions Postgres natives, lakebase_vector et lakebase_text, il permet à l'ensemble de la boucle de votre agent de s'appuyer sur un backend de données unique, un lakebase.

Cela apporte une évolutivité inédite, une rentabilité exceptionnelle et une ergonomie pensée pour les agents.

Les agents transforment la recherche en un flux de travail opérationnel : ils récupèrent le contexte, raisonnent, agissent et mémorisent. Cela connecte profondément le chemin de lecture (récupération) et le chemin d'écriture (mémoire), rendant la récupération instantanée essentielle pour accéder en temps réel aux informations fraîchement générées.

Jusqu'à présent, cette boucle n'avait pas d'environnement natif Postgres conçu pour l'évolutivité et la rentabilité qu'exige la recherche à grande échelle.

Pour agents, la recherche est en réalité une charge de travail opérationnelle

Les agents exploitent désormais 4 fois plus de bases de données sur Lakebase que les utilisateurs humains, et leur exigence principale est totalement différente de celle d'un humain. Les moteurs de recherche traditionnels reposent sur un instantané en lecture seule de données figées. Les agents, en revanche, traitent la recherche comme une base de données opérationnelle en direct.

Prenons un schéma d'agent typique : les documents découpés en fragments (chunks) et les embeddings cohabitent directement avec un journal de mémoire conversationnelle actif. Cela crée une boucle de lecture/écriture continue. Les agents enregistrent de nouveaux apprentissages en mémoire à une étape, et ont besoin que ces mêmes données soient entièrement indexées et interrogeables à l'étape suivante. Ils n'ont pas seulement besoin d'une récupération rapide ; ils ont besoin d'une recherche instantanée sur les toutes dernières écritures.

La recherche est une charge de travail singulière

La recherche est une charge de travail unique qui présente deux caractéristiques majeures.

Premièrement, vous stockez beaucoup plus de données que vous n'en interrogez réellement, ce qui laisse la majeure partie d'entre elles inactives.

Deuxièmement, la recherche vectorielle entraîne un gonflement important des données. Un fichier texte de 1 Ko prend beaucoup plus de volume lorsqu'il est vectorisé. En effet, le document est divisé en plusieurs fragments, chaque fragment générant un embedding distinct à haute dimension, avant même de prendre en compte la surcharge de l'index.

Lorsqu'elles sont multipliées sur des milliers d'environnements (tenants) pour la plupart inactifs, les architectures de recherche traditionnelles s'effondrent. Les index vectoriels standards du secteur, comme HNSW, sont fondamentalement limités par la mémoire (memory-bound). Comme le parcours rapide de graphes repose fortement sur le maintien de l'index en RAM, l'hébergement de données inactives multi-locataires est coûteux.

La recherche a besoin d'un lakebase

L'année dernière, nous avons présenté Lakebase : une architecture OLTP Postgres sans serveur (serverless) où les données résident dans un stockage d'objets cloud économique, tandis qu'un cache multiniveau (RAM, NVMe local, pageserver) garantit la lecture des pages actives avec la latence d'un disque local.

Nous avons réalisé que c'est exactement l'architecture dont la recherche moderne a besoin. Mais il y avait un hic : pour bénéficier de ces avantages économiques sans sacrifier la vitesse des requêtes, il faut une structure d'index explicitement conçue pour résider dans une hiérarchie de stockage multiniveau. Lakebase n'en avait pas. Alors, nous l'avons construite.

En associant une architecture multiniveau à un index multiniveau conçu sur mesure, nous obtenons :

• Une évolutivité inédite sans perte de vitesse : En récupérant intelligemment uniquement les pages requises depuis le stockage d'objets vers un cache local, des instances Postgres plus petites atteignent le même niveau de rappel (recall) et de latence sans nécessiter de ressources de calcul massives.
• Une rentabilité exceptionnelle : La partie inactive des vecteurs repose sur un stockage d'objets presque gratuit, tandis que l'ensemble de travail actif réside sur NVMe. Vous payez pour ce que vous interrogez, pas pour ce que vous stockez.

Ces avantages économiques sont plus faciles à visualiser sous forme de tableau. Par téraoctet et par mois, aux tarifs publics du cloud :

Notre méthode d'indexation permet à Lakebase de ne conserver en RAM que l'ensemble de travail actif. La majorité inactive repose dans le stockage d'objets, ce qui rend le système deux fois moins cher (de deux ordres de grandeur) — tout en offrant la recherche haute performance dont votre application a réellement besoin.

Intégration d'index de recherche natifs du lac à Postgres.

Lors de la création de Lakebase Search, nous nous sommes concentrés sur deux propriétés non négociables.

Lors de la création de Lakebase Search, nous avions deux exigences strictes : il devait être 100 % natif Postgres (en réutilisant les types pgvector/tsvector standards et les outils de l'écosystème), et l'indexation devait être conçue dès le départ pour le stockage d'objets cloud multiniveau.

Pour y parvenir, nous lançons aujourd'hui deux nouvelles extensions Postgres en bêta. Toutes deux partagent le même objectif : offrir une pertinence de recherche de pointe sans vous obliger à surprovisionner la RAM.

1. lakebase_vector : compression 32x et échelle de plus d'un milliard.

Nous avons conservé les types de données et opérateurs pgvector standards, mais nous avons modifié le type d'index sous-jacent. Comme les données restent au format pgvector natif, elles maintiennent leur compatibilité et peuvent être exportées vers d'autres systèmes. En regroupant (clustering) et en compressant les vecteurs à l'aide de RaBitQ (Randomized Binary Quantization), nous réduisons l'empreinte de l'index de 32 fois tout en maintenant un rappel (recall) élevé. Un index de 100 millions de vecteurs qui nécessitait auparavant 300 Go de RAM tient désormais dans moins de 10 Go. Cette empreinte mémoire réduite permet à un seul index de s'adapter à plus d'un milliard de vecteurs. L'ensemble de travail actif est mis en cache sur le NVMe local, tandis que la partie inactive réside dans le stockage d'objets.

2. lakebase_text : un véritable BM25 sans le gonflement de mémoire de GIN.

Postgres gère la correspondance exacte des mots-clés via des index GIN, qui doivent rester résidents en RAM pour maintenir les performances. Cette architecture entraîne une augmentation linéaire des coûts de mémoire avec la taille du jeu de données.

lakebase_text remplace GIN par un index optimisé pour les lectures séquentielles à partir du stockage d'objets cloud. Il introduit le classement de pertinence natif BM25 dans Postgres sans l'empreinte RAM associée.

Comme les deux extensions s'exécutent au sein du même moteur, la recherche hybride s'effectue en une seule requête SQL. La similarité vectorielle et la pertinence des mots-clés sont combinées via la fusion de rangs réciproques (RRF), ce qui permet de joindre et de filtrer les résultats par rapport aux tables opérationnelles.

Postgres est prêt pour des charges de travail de recherche sérieuses et à grande échelle

Nous avons évalué Lakebase Search sur LAION-100M — 100 millions de vecteurs à 768 dimensions, récupération du top-10, sur une seule instance. Les performances des requêtes avec un cache chaud et une seule connexion offrent un rappel exact des plus proches voisins sans aucun gonflement :

Atteindre cette échelle nécessite traditionnellement une architecture limitée par la mémoire (memory-bound). Un index HNSW pgvector standard exige que le graphe de voisins et ses pages de tas (heap pages) cibles restent résidents en RAM pour un parcours performant. À 100 millions de vecteurs :

1. pgvector : nécessite une instance de 512 Go (64 CPU). La construction de l'index prend environ 40 heures. Comme le parcours de graphe repose sur des accès aléatoires non localisés, les redémarrages à froid entraînent de lourdes latences de lecture de disque, ce qui fait que la première requête prend plusieurs minutes.
2. lakebase_vector : s'exécute sur une instance de 192 Go (96 CU / 24 CPU). La construction de l'index prend 1,5 heure. Bien que le parcours reste un accès aléatoire, la disposition de l'index regroupe les données de sorte que les recherches aléatoires soient localisées au sein d'un ensemble de travail actif sur le cache NVMe, laissant la partie inactive dans le stockage d'objets. L'instance se réduit à zéro lorsqu'elle est inactive ; la première requête sur cache froid prend 1,13 seconde.

Cette architecture change la façon d'aborder le coût total de possession (TCO). La recherche héritée nécessite un coût de base fixe quel que soit le volume de requêtes, tandis que Lakebase suit l'utilisation réelle :

Lakebase Search permet une ergonomie axée sur les agents

Un backend unique pour la mémoire et le contexte :

Les agents ne devraient pas avoir à assembler une base de données vectorielle pour le contexte et une base de données transactionnelle pour la mémoire. En intégrant votre logique de récupération directement dans la base de données, l'ensemble de votre boucle d'agent s'exécute sur un seul backend. Comme Lakebase Search repose sur Postgres — en réutilisant pleinement les types standard pgvector et tsvector —, il s'intègre nativement à vos MCP existants, pilotes standard et connecteurs. Plus important encore, comme la recherche se trouve juste à côté de vos données opérationnelles, vous pouvez exécuter une recherche hybride, effectuer des jointures avec les tables de votre application et filtrer en toute sécurité par tenant, le tout dans une seule requête SQL.

Expérimentation continue de la recherche

L'optimisation des stratégies de découpage (chunking) ou des poids hybrides nécessite des essais et des erreurs. Au lieu d'exporter des données vers des systèmes de traitement par lots externes pour retraitement, Lakebase Search se connecte au Lakehouse pour créer une boucle de rétroaction rapide. Vous pouvez brancher instantanément des ensembles de données de plusieurs téraoctets à coût nul, créer des index hors bande à l'aide du calcul parallèle et renvoyer les commentaires de l'agent au Lakehouse pour une évaluation hors ligne.

Un moteur de récupération dédié par agent

Les architectures traditionnelles nécessitent le partage d'un cluster de recherche unique entre tous les agents. Comme les index inactifs dans Lakebase n'entraînent pratiquement aucun coût de stockage, vous pouvez provisionner des milliers de corpus isolés dédiés à des agents, utilisateurs ou sessions spécifiques. Cela fait passer la recherche d'un instantané figé à une boucle de lecture/écriture opérationnelle ; les données qu'un agent écrit à un tour sont validées et récupérables au tour suivant avec des garanties transactionnelles complètes.

Un socle unique pour la boucle de l'agent

Lakebase élimine le besoin d'assembler des magasins de vecteurs, des clusters de recherche et des bases de données transactionnelles distincts. En consolidant l'ensemble du cycle de vie au sein d'un système Postgres unique, il offre l'évolutivité et le faible coût du stockage d'objets cloud multiniveau, ainsi que l'ergonomie de lecture/écriture en temps réel requise pour les flux de travail d'agents.

Lakebase Search est disponible dès aujourd'hui en version bêta sur AWS et Azure. Que vont construire vos agents ?

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original