Tables multimodèles : une seule table pour les fichiers, les embeddings et une recherche hybride pour les agents.

Pendant des années, la base de données en question a évolué vers un système unifié unique, couvrant le traitement de transactions distribuées pour des charges de travail critiques, le HTAP, les données multimodèles et la recherche hybride. Son produit Lakebase marque un changement supplémentaire d’orientation. La question n’est plus seulement de savoir ce que la base de données peut traiter, mais à qui elle sert. Les bases de données étaient autrefois conçues pour les développeurs, les DBA et les applications. Le fournisseur affirme qu’à l’ère de l’IA, elles doivent également servir un nouveau type d’utilisateur : l’agent.

Selon cette définition, une « base de données IA » n’est pas simplement celle qui peut stocker des images, des PDF ou des vecteurs. C’est plutôt une base conçue pour fournir aux agents un contexte complet, à jour et fiable afin qu’ils puissent raisonner et agir, avec des embeddings, des fichiers bruts et des résultats de recherche hybride provenant du même endroit. Le reste décrit la fonctionnalité de tableau multimodèle dans Lakebase ainsi que le problème qu’elle vise à résoudre. Il s’agit des affirmations du fournisseur, il convient donc de les tester avec votre propre charge de travail.

Le problème des données pour les agents

Imaginez une décision prise par un agent. Celui-ci pourrait avoir besoin en même temps d’un profil utilisateur structuré, d’un résumé textuel de la conversation, du PDF original provenant d’une base de connaissances, de résultats sémantiques issus de la récupération de vecteurs, ainsi que de l’état actuel de l’entreprise.

Aujourd’hui, ces cinq éléments résident généralement dans cinq systèmes : un stockage d’objets, un moteur de recherche, une base de données vectorielle, une base de données métier et un entrepôt hors ligne. Il n’y a ni transaction partagée, ni snapshot cohérent, ni filiation commune.

Si un PDF est mis à jour tandis que son intégration fait encore référence à l’ancienne version, l’agent donne une réponse affirmative mais erronée, sans que personne ne s’en aperçoive. Il ne s’agit pas de stocker davantage de types de données, mais bien d’un problème de gouvernance. Une fois que des données multimodèles se trouvent sur le parcours critique, quelqu’un doit garantir la cohérence des versions, l’exhaustivité des calculs, la traçabilité et la fiabilité. Dans de nombreuses équipes, cette personne est le responsable du pipeline qu’il gère, qu’il débogue et qu’il réécrit chaque trimestre.

La table multimodèle constitue la réponse de Lakebase. C’est la fonction centrale de gestion des données du produit, qui permet de gérer des images, de l’audio, de la vidéo, des PDF, des captures d’écran web, des vecteurs, du JSON ainsi que des colonnes structurées classiques en tant qu’objets de base de données à part entière. Tous ces éléments coexistent au sein d’un même système offrant des transactions, une cohérence, une haute disponibilité, une recherche hybride, des calculs analytiques et un service en ligne.

Pourquoi les agents ont besoin d’un modèle de données différent

Les objets avec lesquels interagit un agent sont par nature multimodèles. Les entrées vont du langage naturel aux images, aux PDF, aux pages web, aux tableaux et au contexte métier. Lors de son fonctionnement, l’agent s’appuie sur la mémoire de l’utilisateur, des bases de connaissances, les résultats RAG, des données métier structurées, des profils sémantiques et les résultats de modèles intermédiaires.

Quatre évolutions se dégagent :

1. Les données non structurées occupent désormais une place centrale. Elles cessent d’être des fichiers en attente dans le stockage d’objets pour devenir des éléments clés dans la prise de décisions.
2. L’accès aux données passe par une recherche hybride. Une seule requête peut combiner des filtres structurés, une recherche plein texte, un rappel vectoriel et une agrégation analytique.
3. Les exigences en temps réel augmentent. Les agents fonctionnent 24 heures sur 24, et les rapports du jour suivant ne suffisent plus.
4. Les fonctionnalités sont générées dynamiquement. De nombreux champs ne sont pas saisis directement ; les modèles les extraitent asynchronement à partir des données brutes.

La question pratique consiste à savoir comment unifier des données multimodèles brutes, des champs structurés, des fonctionnalités dérivées et des résultats asynchrones au sein d’une seule base de données, afin qu’elles puissent servir en même temps les transactions en ligne, les analyses et la recherche hybride, sans perdre en cohérence ni en visibilité. C’est le problème de conception auquel vise la table multimodèle.

Capacités principales

Un seul endroit pour les objets multimodèles

Les tables multimodèles placent ces objets sous le contrôle de transactions et de versions propre à la base de données. Les gros fichiers tels que des images, de l’audio, de la vidéo, des PDF et des captures web peuvent être stockés de plusieurs manières différentes. L’endroit où se trouvent physiquement les octets importe moins que ce que la base de données promet à leur sujet : un ID qui ne change pas, un moyen d’y accéder, un numéro de version, un statut de visibilité et une portée de transaction définie.

Cela vise à garantir qu’un objet brut et ses caractéristiques dérivées, telles que des résumés, des étiquettes, des embeddings et des scores de risque, correspondent toujours à la même version des données. Le bug où un objet est mis à jour mais que ses caractéristiques décrivent encore le contenu ancien ne devrait pas se produire.

Colonnes de caractéristiques dynamiques

Les données multimodales sont riches, et un seul objet brut peut donner naissance à une infinité de caractéristiques : sémantiques, structurelles, liées à la qualité et spécifiques à l’activité commerciale. À partir du texte, on peut obtenir des sujets, des résumés, des embeddings, des étiquettes de sécurité, l’identité linguistique et un score de qualité. D’une image proviennent des résultats d’OCR, des étiquettes, des scores de risque et des attributs liés à l’activité commerciale. Chaque nouveau modèle ajoute encore plus de caractéristiques.

Dans un schéma classique, chaque nouvelle caractéristique implique une modification DDL. Chaque modification DDL entraîne l’invalidation du cache, une amplification des écritures et une pression de compactage en arrière-plan, ce qui ralentit le travail sur les caractéristiques au rythme des verrous de table.

Les tables multimodèles utilisent un mécanisme de colonnes dynamiques léger. Ajouter une fonctionnalité ne nécessite aucun changement de schéma, les requêtes restent natives SQL, l’optimisation analytique s’applique toujours et la recherche hybride continue d’utiliser un index. Il ne s’agit pas d’un retour au stockage clé-valeur, qui est flexible mais incapable d’analyser les données en SQL ni d’optimiser les recherches. La conception fait un choix délibéré entre une structure optimisable et une extensibilité dynamique, en essayant de conserver les deux.

Calcul asynchrone, quasi en temps réel

De nombreuses colonnes ne sont pas du tout écrites par les utilisateurs. Des tâches de calcul les génèrent, y compris des embeddings, des résumés, du OCR, des scores de qualité, des index de texte complet et des index vectoriels, en utilisant des fonctionnalités intégrées des modèles, des tâches en arrière-plan ou des pipelines externes.

L’inférence des modèles prend généralement des centaines de millisecondes à quelques secondes, ce qui est trop lent pour bloquer une écriture en ligne. Par conséquent, la table n’attend pas :

1. Les données brutes sont enregistrées en premier, ce qui permet de conserver la latence des écritures en ligne intacte.
2. Les tâches en arrière-plan commencent l’extraction des caractéristiques, la création d’index et le complément des données selon leur filiation.
3. Les valeurs dérivées apparaissent dans une fenêtre quasi en temps réel.
4. Les lectures affichent toujours une seule capture cohérente.

La logique sous-jacente est que une synchronisation stricte de chaque colonne dérivée est peu pratique et inutile. Un équilibre contrôlé entre latence, débit, efficacité de stockage et cohérence constitue l’objectif approprié. Les tâches de calcul génèrent les valeurs, et la table permet de les rendre gérables, recherchables, analysables et lisible de manière cohérente.

Cohérence des groupes de colonnes

Le calcul asynchrone crée un problème de visibilité. Une fois qu’une ligne existe, la caractéristique A, la caractéristique B, les embeddings, les index de texte intégral ainsi que les étiquettes de qualité peuvent être traités à des moments différents, par des tâches et des modèles distincts. Si une requête constate que B est prêt tandis qu’A est encore en attente, elle renverra des réponses incorrectes sans aucun avertissement.

La cohérence des groupes de colonnes gère ce problème au niveau du stockage. Un groupe de colonnes métier ne devient un nouveau snapshot visible qu’après que toutes les colonnes dérivées associées aient été traitées. Les requêtes et les recherches hybrides lisent un snapshot cohérent et ne rencontrent jamais de données inachevées.

Stockage et calcul séparés, avec des données chaudes et froides ensemble

Les données multimodales augmentent sans limite dans les documents, les images, la vidéo, les vecteurs et les caractéristiques dérivées, ce qui rend impossible le stockage en mémoire vive de tout cela à grande échelle. Ces systèmes reposent sur une architecture décentralisée avec un stockage partagé et considèrent les données en mémoire vive et celles en stockage froid comme un continuum :

• Les données récentes, par exemple celles des 90 derniers jours, sont mémorisées en cache sur des SSD afin que l’accès reste rapide.
• Les données plus anciennes, comme celles dépassant 90 jours, sont stockées sur un stockage partagé moins coûteux tout en restant consultables, recherchables et analysables via la même interface.

Il n’est pas nécessaire de changer de système pour accéder aux données en stockage froid, ni de combiner une base de données en ligne, un stockage d’objets et un entrepôt hors ligne pour répondre à une seule question. Il existe une seule vue, une seule interface de requête et un seul modèle de gouvernance.

Historique et catalogue unifié

De quel segment de texte provient cette incrustation ? Quel modèle d’audit a attribué cette étiquette de sécurité ? Quelle version du PDF décrit ce résumé ?

La filiation et le catalogue unifié forment l’ossature des métadonnées. Ils permettent de comprendre comment les objets bruts, les champs structurés, les colonnes de caractéristiques dynamiques, les tâches de modèle, les versions et les permissions sont liés les uns aux autres. Les métadonnées soutiennent trois fonctions :

1. Le déclenchement. Les tâches en arrière-plan pour l’extraction, la création d’index et le complément de données démarrent automatiquement à partir de la filiation.
2. La complétude. Avant que la visibilité ne soit accordée, le système vérifie qu’un groupe de colonnes ou un instantané a été entièrement calculé.
3. La traçabilité. Lorsqu’un agent fournit une réponse, il est possible de la relier aux documents, images, enregistrements et caractéristiques dérivées qu’il a utilisés.

Une seule couche d’accès pour les transactions, l’analyse et la recherche

Une table multimodèle est définie comme une base commune pour trois types de charges de travail sur les mêmes données :

• les transactions en temps réel, c’est-à-dire des écritures commerciales garanties par les principes ACID et offrant une haute disponibilité ;
• l’analyse, qui implique des analyses approfondies, des agrégations, des filtres, des jointures et une analyse des caractéristiques ;
• la recherche hybride, qui combine des filtres structurés avec une recherche de texte intégral, un rappel par vecteurs, un filtrage par étiquettes et un classement selon des critères commerciaux.

L’accès via des agents est par nature multi-étapes. Une demande peut d’abord filtrer selon des conditions structurées, puis rechercher des descriptions en tant que texte intégral, ensuite trouver du contenu similaire grâce au rappel par vecteurs, et enfin classer les résultats en fonction des étiquettes, de la qualité, de la date de mise à jour et des permissions. Aucun moteur spécialisé ne couvre toutes ces quatre étapes.

Le compromis central réside entre une synchronisation quasi en temps réel et une forte synchronisation. La recherche et l’analyse n’ont pas besoin de fonctionnalités dérivées pour s’effectuer au sein de la transaction d’écriture, mais ces fonctionnalités doivent devenir visibles dans une fenêtre de temps courte et définie, et être lues à partir d’une capture cohérente. C’est ainsi qu’une seule table peut servir aux écritures en ligne, ainsi qu’à la récupération et à l’analyse hybrides, sans le coût de conserver trois copies assemblées.

Ce qu’il remplace

Pour un projet d’agents actuel, son avantage est qu’il remplace un ensemble composé d’un stockage d’objets, d’un moteur de recherche, d’une base de données vectorielle, d’une base de données métier et d’un entrepôt hors ligne. L’ancien compromis entre la diversité des modèles et une gouvernance de niveau base de données devrait disparaître.

Pourquoi c’est important

La vraie question n’est pas de savoir si une base de données d’IA peut stocker des images, des PDF ou des vecteurs. C’est plutôt ce qui change lorsque les agents deviennent des utilisateurs de premier plan de cette base de données.

Si la réponse est un système isolé supplémentaire par type de données, il y a plus de surfaces à sécuriser, plus de pipelines à perturber et plus de dérives silencieuses. Si la réponse est une seule table gérée où chaque modalité constitue un objet de première classe, on obtient une véritable base de données plutôt qu’un échafaudage composé de pipelines.

Les tables multimodèles regroupent les données structurées, les données non structurées, les caractéristiques issues de l’IA et les sémantiques métier au sein d’un seul système pour les transactions, la gouvernance et le calcul. Les bases de données servaient autrefois à unifier les données. À l’ère de l’IA, elles doivent unifier les données, les sémantiques et les opérations qui les génèrent, et cette fonctionnalité représente la première étape de Lakebase dans cette direction.

Évaluation

Les tables multimodèles sont fournies dans le cadre de Lakebase. Pour les évaluer en fonction de la charge de travail de votre agent, listez les types de données que vous devez gérer, le scénario d’agent que vous développez ainsi que tout exigence liée à la performance ou à la gouvernance, puis modélisez une table multimodèle et comparez-la avec l’ensemble qu’elle remplacerait. Le critère décisif est de savoir si l’agent cesse de fournir des réponses incorrectes.