Les LLM ne peuvent « voir » qu’une quantité limitée de texte à la fois, soit les fenêtres contextuelles. Cela fonctionne pour les petites tâches, mais échoue lorsqu’une base de connaissances compte des milliers de pages. Même lorsque les fenêtres contextuelles suffisent, les performances peuvent se dégrader en raison du problème de « l’aiguille dans une botte de foin ».
La RAG (« génération augmentée par récupération ») est devenue une approche très courante : vous gérez une base de connaissances (documents, wikis, politiques, transcriptions, etc.), effectuez une recherche sémantique à partir de la requête d’un utilisateur pour récupérer les extraits les plus pertinents au moyen de plongements, puis transmettez ces segments au LLM avec la question. Cela limite 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 à code source ouvert, accompagnée d’outils, qui facilite la création de flux de travail de « récupération par IA » sur PostgreSQL, la base de données à code source ouvert éprouvée.
L’idée principale est d’intégrer davantage d’étapes du pipeline RAG standard à la couche de base de données (ingérer → segmenter → créer les plongements → les synchroniser), plutôt que de considérer la BD comme un « simple stockage » de plongements.
Nos premières impressions sont prometteuses, mais dès que votre pipeline RAG se complexifie un tant soit peu, particulièrement sur le plan de la segmentation, il ne convient plus. Nous suivrons toutefois ce projet de près.
Il existe de nombreuses façons de créer une solution RAG. Pour une analyse plus détaillée des différentes approches, lisez Exemples pratiques de solutions RAG personnalisées. Les possibilités de conception deviennent étonnamment vastes dès que la qualité importe, et l’approche « par défaut » ressemble généralement à ceci :
Prendre un ensemble de documents.
Les diviser en segments. Il existe de nombreuses méthodes pour y parvenir (p. ex., paragraphes, regroupements sémantiques).
Transformer chaque segment en plongement.
Stocker les plongements dans une base de données vectorielle (Pinecone, Milvus, etc.) ou dans Postgres avec pgvector.
Lors d’une requête, rechercher les segments les plus proches `et les transmettre au LLM (là encore… il existe aussi de nombreuses façons de procéder).
Dans de nombreuses architectures, les étapes (1) à (3) se déroulent hors de la base de données, dans le code de l’application ou un pipeline de données, et la base de données sert surtout à :
stocker les plongements
rechercher des plongements
pgai est une extension Postgres à code source ouvert, développée par Timescale, qui tente d’estomper cette distinction.
Au lieu de considérer les plongements 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 plongements.
Vous précisez le modèle de plongement et une stratégie de segmentation.
pgai gère le reste, notamment la mise à jour des plongements lorsque les données sources changent.
La promesse est séduisante :
Moins de code de liaison personnalisé à maintenir.
Il devrait être plus facile de garder les plongements « à jour » lorsque les documents sources sous-jacents changent.
Postgres et pgai gèrent les nouvelles tentatives, les limites de débit, les tâches échouées, etc.
Note au lectorat : pgai intègre pgvector, une autre extension Postgres très populaire pour la RAG. pgvector ajoute le stockage vectoriel et la recherche par similarité à Postgres, tandis que pgai s’appuie sur celui-ci pour automatiser les étapes du pipeline RAG, comme la segmentation, la création de plongements et leur mise à jour.
1) Sa mise en service est simple.
Le parcours idéal est assez simple :
Télécharger les images Docker de Timescale (base de données et processus de travail).
Fournir la clé API de votre fournisseur de plongements.
Exécuter quelques instructions SQL pour déclarer le vectoriseur (essentiellement : quoi convertir en plongements, comment le segmenter et quel modèle utiliser).
Ensuite, pgai fait exécuter un processus de travail de vectorisation séparé qui génère les plongements de façon asynchrone (p. ex., toutes les cinq minutes ou selon la fréquence voulue).
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 plongements. Il peut aussi traiter différents formats de documents texte, comme les PDF, Markdown, etc.
1) Vous perdez beaucoup de contrôle, alors que la RAG en exige parfois.
Les systèmes RAG très performants, selon la qualité de leurs réponses, nécessitent souvent des pipelines personnalisés, 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 de plongement selon le type de document
pgai offre moins de flexibilité pour les éléments ci-dessus.
Il existe actuellement deux grandes stratégies de segmentation : un séparateur de texte par caractères et un séparateur récursif de texte par caractères, ainsi qu’une option sans segmentation. Cela peut suffire à certains cas d’utilisation, mais de nombreux systèmes RAG de production nécessitent une personnalisation accrue.
Ce serait formidable que Timescale puisse intégrer certaines des stratégies de segmentation plus sophistiquées de bibliothèques comme Chonkie et prendre en charge des conceptions avancées comme la récupération contextuelle d’Anthropic.
2) Axé sur le texte, et non multimodal.
De nombreux problèmes RAG intéressants ne sont plus purement textuels :
PDF contenant des diagrammes
captures d’écran et images
enregistrements audio
clips vidéo
Même si vous pouvez « extraire le texte » de ces sources, ce n’est pas l’équivalent d’un véritable pipeline de plongements multimodaux.
Si pgai prend un jour en charge les modèles multimodaux de bout en bout (charger → segmenter → créer les plongements de grandes images ou de fichiers audio et vidéo stockés dans S3, avec une synchronisation robuste), ce sera intéressant. Aujourd’hui, il s’agit toutefois d’un flux de création de plongements textuels.
3) Si vous n’avez besoin que de plongements, pgai pourrait être superflu.
Si votre pipeline d’ingestion est déjà personnalisé, ou doit l’être, « créer des plongements à partir de segments de texte » n’est pas la partie la plus difficile de la RAG. Dans ce contexte, 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 plongements offre moins de valeur.
Une façon particulièrement intéressante d’utiliser pgai serait de 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 offert par pgai. Il suffit de le configurer ainsi :
Bash
puis de demander au catalogue sémantique d’analyser vos dictionnaires de données avec pgai semantic-catalog create. Cela génère un contexte à partir de votre magasin de données, qui ressemble à ceci :
Plain Text
Ce contexte est maintenant accessible à pgai de différentes façons :
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 lié à votre requête en langage naturel :
Bash
Générer le SQL :
Vous pouvez aussi générer directement le SQL brut requis 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 vaut la peine d’être essayé si vous souhaitez :
utiliser Postgres comme système de référence,
réduire au minimum le code de liaison,
synchroniser automatiquement les plongements,
appliquer rapidement une fonction texte-vers-SQL à vos bases de données,
expérimenter de nouveaux outils RAG et de nouvelles extensions Postgres.
Il vaut probablement mieux attendre avant d’utiliser 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 ayant des exigences d’analyse différentes
des plongements multimodaux
Enfin, bien que pgvector ait clairement été fortement adopté, on ignore si pgai suscitera le même intérêt et bénéficiera donc du même soutien, même s’il n’existe que depuis environ 18 mois.
pgai est une approche intéressante de la RAG qui permet aux bases de données d’effectuer davantage de tâches opérationnelles courantes afin de simplifier le code de votre application.
À l’heure actuelle, il est :
utilisable et réellement agréable pour les configurations RAG simples
pas assez flexible pour les pipelines plus personnalisés, surtout multimodaux
Il est prometteur et mérite certainement d’être suivi pour voir comment il évolue.