Les LLM ne peuvent « voir » qu’une quantité limitée de texte à la fois (la fenêtre de contexte). Cela fonctionne pour les petites tâches, mais plus lorsque la base de connaissances compte des milliers de pages. Même lorsque la fenêtre de contexte est suffisante, les performances peuvent diminuer à cause du problème de « l’aiguille dans une botte de foin ».
Le RAG (« génération augmentée par la récupération ») est devenu un modèle très courant : vous gérez une base de connaissances (documents, wikis, politiques, transcriptions, etc.), effectuez une recherche sémantique sur la requête d’un utilisateur afin de récupérer les extraits les plus pertinents à l’aide d’embeddings, puis transmettez ces fragments au LLM avec la question. Cela restreint le contexte du modèle et, lorsque c’est bien fait, peut améliorer la qualité des réponses et réduire les hallucinations.
pgai est une extension Postgres open source (accompagnée d’outils) qui vous aide à créer des workflows de « récupération par IA » sur PostgreSQL, la base de données open source reconnue.
L’idée principale consiste à intégrer davantage d’étapes du pipeline RAG standard à la couche de base de données (ingérer → segmenter → créer les embeddings → les synchroniser), plutôt que de considérer la BDD comme un « simple stockage » d’embeddings.
Nos premières impressions sont prometteuses, mais dès que votre pipeline RAG devient un tant soit peu complexe, notamment concernant les méthodes de segmentation, il n’est plus adapté. Nous suivrons néanmoins ce projet de près.
Il existe de nombreuses façons de créer un système RAG. Pour une analyse plus approfondie des différentes approches, consultez Exemples pratiques de solutions RAG personnalisées. Les possibilités de conception deviennent étonnamment vastes dès que la qualité compte, et l’approche « par défaut » ressemble généralement à ceci :
Prenez un ensemble de documents.
Divisez-les en fragments. Il existe de nombreuses méthodes pour le faire (par exemple, par paragraphes ou regroupements sémantiques).
Convertissez chaque fragment en embedding.
Stockez les embeddings dans une base de données vectorielle (Pinecone, Milvus, etc.) ou dans Postgres avec pgvector.
Au moment de la requête, recherchez les fragments les plus proches `et transmettez-les au LLM (là encore... il existe de nombreuses façons de procéder).
Dans de nombreuses architectures, les étapes (1) à (3) sont exécutées hors de la base de données, dans le code applicatif ou un pipeline de données, et la base sert principalement à :
stocker les embeddings
rechercher des embeddings
pgai est une extension Postgres (open source, développée par Timescale) qui tente d’estomper cette frontière.
Au lieu de considérer les embeddings comme des éléments que votre application gère manuellement, pgai en fait une fonctionnalité de la base de données :
Vous définissez la table ou les documents à convertir en embeddings.
Vous indiquez le modèle d’embedding et une stratégie de segmentation.
pgai gère le reste, notamment la mise à jour des embeddings lorsque les données sources changent.
La promesse est séduisante :
Moins de code de liaison sur mesure à maintenir.
Il devrait être plus facile de garder les embeddings « à jour » lorsque les documents sources sous-jacents changent.
Postgres/pgai gère les nouvelles tentatives, les limites de débit, les tâches ayant échoué, etc.
Note au lecteur : pgai intègre pgvector (une autre extension Postgres très populaire pour le RAG). pgvector ajoute à Postgres le stockage vectoriel et la recherche par similarité, tandis que pgai s’appuie dessus pour automatiser les étapes du pipeline RAG, comme la segmentation, la création d’embeddings et leur mise à jour.
1) Sa mise en service est simple.
Le scénario idéal est relativement simple :
Récupérez les images Docker de Timescale (base de données + worker).
Fournissez la clé API de votre fournisseur d’embeddings.
Exécutez quelques lignes de SQL pour déclarer le vectoriseur (autrement dit : quoi convertir en embeddings, comment le segmenter et quel modèle utiliser).
Ensuite, pgai organise l’exécution d’un worker de vectorisation dans un processus distinct afin de générer les embeddings de façon asynchrone (par exemple toutes les 5 minutes, ou à la fréquence souhaitée).
2) Il est pratique d’exécuter tout le pipeline « près » de la base de données.
pgai peut ingérer le contenu de tables, mais aussi charger des documents depuis des emplacements comme S3, puis les analyser, les segmenter et créer leurs embeddings. Il peut également gérer différents formats de documents texte, comme les PDF, le Markdown, etc.
1) Vous perdez beaucoup de contrôle (alors que le RAG en exige parfois).
Les systèmes RAG hautement performants (en matière de qualité des réponses) nécessitent souvent des pipelines sur mesure, notamment :
des règles de segmentation personnalisées (par titre, page, tour de parole, etc.)
une segmentation tenant compte des métadonnées (conserver les titres de section, horodatages, auteurs et types de documents)
différentes stratégies d’embedding selon le type de document
pgai offre moins de flexibilité sur ces points.
Il existe actuellement deux principales stratégies de segmentation : un séparateur de texte par caractères et un séparateur récursif par caractères, ainsi qu’une option sans segmentation. Cela peut suffire à certains cas d’usage, mais de nombreux systèmes RAG en production nécessitent davantage de personnalisation.
Il serait formidable que Timescale intègre certaines des stratégies de segmentation plus sophistiquées proposées par des bibliothèques comme Chonkie et prenne également en charge des conceptions avancées comme la récupération contextuelle d’Anthropic.
2) Le texte d’abord, pas le multimodal.
De nombreux problèmes RAG intéressants ne concernent plus uniquement le texte :
PDF contenant des diagrammes
captures d’écran / images
enregistrements audio
clips vidéo
Même si vous pouvez « extraire le texte » de ces sources, cela n’équivaut pas à un véritable pipeline d’embeddings multimodaux.
Si pgai finit par prendre en charge les modèles multimodaux de bout en bout (charger → segmenter → créer les embeddings de grandes images ou de fichiers audio/vidéo stockés dans S3, avec une synchronisation robuste), ce serait convaincant. Aujourd’hui, il s’agit toutefois d’un workflow d’embeddings textuels.
3) Si vous avez uniquement besoin d’embeddings, pgai ne vous est peut-être pas nécessaire.
Si votre pipeline d’ingestion est déjà personnalisé (ou doit l’être), alors la « création d’embeddings à partir de fragments de texte » n’est pas l’étape la plus difficile du RAG. Dans ce cas, pgai résout la partie la plus simple du problème.
De plus, si votre base de connaissances est rarement mise à jour, la synchronisation automatique des embeddings présente moins d’intérêt.
Une utilisation particulièrement intéressante de pgai consisterait à déployer une interface texte-vers-SQL sur vos bases de données. Cela peut être réalisé assez facilement avec le module semantic_catalog proposé par pgai. Configurez-le simplement ainsi :
Bash
puis demandez au catalogue sémantique d’analyser vos dictionnaires de données avec pgai semantic-catalog create. Cela génère, à partir de votre magasin de données, un contexte qui ressemble à ceci :
Plain Text
Ce contexte est désormais accessible à pgai de différentes manières ;
Par recherche sémantique :
Cette requête renverra les tables, fonctions et autres objets susceptibles d’être pertinents pour votre requête en langage naturel :
Bash
Obtenir le contexte brut :
Cela affichera le contexte YAML brut associé à votre requête en langage naturel :
Bash
Générer le SQL :
Vous pouvez aussi générer directement le SQL brut nécessaire pour répondre à votre requête. Le contexte de l’étape précédente est envoyé à un LLM, qui génère une réponse :
Bash
Si vous créez un système RAG relativement simple, pgai mérite d’être essayé si vous souhaitez :
utiliser Postgres comme système de référence,
réduire le code de liaison au minimum,
synchroniser automatiquement les embeddings,
appliquer rapidement une couche texte-vers-SQL à vos bases de données,
expérimenter avec de nouveaux outils RAG et de nouvelles extensions Postgres.
Il vaut probablement mieux attendre avant d’adopter pgai si votre pipeline RAG nécessite l’un des éléments suivants :
une logique d’ingestion ou de segmentation fortement personnalisée
de nombreux types de documents aux exigences d’analyse différentes
des embeddings multimodaux
Enfin, si pgvector a manifestement été largement adopté, rien ne garantit que pgai suscitera autant d’intérêt et bénéficiera donc du même soutien (même s’il n’existe que depuis environ 18 mois).
pgai propose une approche intéressante du RAG qui confie aux bases de données davantage de tâches opérationnelles courantes afin de simplifier le code applicatif.
À l’heure actuelle, il est :
utilisable et vraiment agréable pour les configurations RAG simples
insuffisamment flexible pour les pipelines plus personnalisés (surtout multimodaux)
Il est prometteur et mérite vraiment d’être suivi pour voir comment il évolue.