Model-aware Storage : préparer l’infrastructure à l’ère de l’IA

Pendant longtemps, les moteurs de base de données ont été conçus autour d’un principe simple :
les humains posent les requêtes, la machine stocke des données structurées.

Cette époque est terminée.

Les systèmes modernes reposent sur des modèles LLMs, embeddings, transformers qui produisent eux-mêmes :

• les requêtes,
• la structure des données,
• les besoins de recherche,
• la manière de représenter l’information.

Pourtant, la plupart des moteurs continuent à fonctionner comme si les données étaient destinées à des humains.

Pour supporter l’IA des dix prochaines années, les moteurs doivent devenir model-aware capables de comprendre tokens, embeddings, features et structures générées par les modèles.

Pourquoi les moteurs doivent devenir “model-aware”

Les modèles n’utilisent pas les données comme les humains :

• un LLM raisonne en tokens,
• un modèle d’embedding raisonne en vecteurs,
• un modèle de recommandation raisonne en features,
• un modèle RAG raisonne en voisinages sémantiques.

Mais les moteurs traditionnels continuent à proposer :

clé primaire → correspondance exacte
index → comparaison lexicographique
colonne → valeur typée

Résultat : un énorme décalage entre les besoins des modèles et les capacités des moteurs.

Un moteur “model-aware” comprend :

• les frontières de tokens,
• la distribution des embeddings,
• les schémas de features,
• les cycles de mise à jour utilisés pour l’entraînement,
• les indexations adaptées aux modèles.

Sans cela, les pipelines IA deviennent :

• lents,
• coûteux,
• complexes,
• redondants.

Indexation tokenisée : dépasser la comparaison lexicographique

Un LLM ne “lit” pas un texte : il lit des tokens. Un moteur model-aware doit indexer et manipuler les données de manière compatible avec la tokenisation :

• stockage efficace des documents tokenisés,
• accès direct aux spans de tokens,
• chunking accéléré pour le RAG,
• préchargement plus intelligent pour l’inférence.

Exemple :

Index tokenisé :      ["inter", "nation", "alisation"] → spans de tokens
 

Cette différence réduit massivement la charge de préprocessing.

Feature Store natif : un primitif indispensable

Les systèmes IA modernes reposent sur des feature stores, qui stockent :

• des features utilisateurs,
• des événements,
• des embeddings,
• des agrégats,
• des versions de features.

La plupart des moteurs n’en ont pas — c’est un service externe.
Un moteur model-aware l’intègre directement :

↓
Versioning
↓
Récupération directe par le modèle
↓
Pas de transformation nécessaire
 

Cela supprime :

• les pipelines ETL fragiles,
• les divergences entre entraînement et inférence,
• les incohérences entre équipes.

Pourquoi les moteurs vectoriels classiques (FAISS, Pinecone…) ne suffisent pas

Ces outils résolvent un problème trop étroit :

• stocker des embeddings,
• faire du nearest-neighbor search.

Mais ils ignorent le reste du cycle IA.

1. Ils considèrent les embeddings comme statiques

Or en pratique, les embeddings changent avec :

• les mises à jour du modèle,
• le drift,
• les versions,
• les ré-entraînements.

2. Ils ne comprennent pas la tokenisation

Ils stockent des vecteurs, pas les structures sémantiques sous-jacentes.

3. Ils séparent vector search et transactions

Dans la réalité :

↓
Recalcul embedding
↓
Indexation
↓
Serveur RAG
 

Les moteurs vectoriels obligent à répartir cela sur plusieurs systèmes — source de complexité énorme.

4. Ils sont inadaptés aux environnements contraints

FAISS nécessite beaucoup de RAM ; Pinecone impose le cloud.
Aucun ne fonctionne de manière optimale :

• en edge computing,
• en local-first,
• avec faible consommation.

5. Ils ne sont pas des moteurs complets

Ils ne fournissent pas :

• ACID,
• durabilité,
• logs structurés,
• résilience offline,
• résolution de conflits.

La vector search n’est qu’un composant des systèmes IA.

Un moteur model-aware doit intégrer tokens + features + vecteurs + logs, pas les séparer.

Conclusion

L’IA moderne nécessite des moteurs repensés pour les modèles.
Les moteurs traditionnels ne suffisent plus, et les bases vectorielles ne couvrent qu’un fragment du problème.

Un moteur model-aware :

• simplifie les pipelines,
• accélère l’inférence,
• réduit les coûts,
• unifie données + modèles,
• fonctionne même dans des environnements contraints.

C’est la direction naturelle pour les systèmes IA de la prochaine décennie.

Références recommandées

1. Stanford DAWN — Model-Aware Data Systems
2. Kleppmann — Storage Engines for ML Systems
3. Google — Feature Store Architecture
4. Facebook AI — FAISS
5. Pinecone — Vector Database Overview