Un RAG sur étagère qui utilise un modèle de graph pour la partie retrieval.
En lui fournissant des exemples de questions et le types des entités à extraire des connaissances, il est ensuite possible d'insérer des connaissances qui seront découpées et analysées pour former le graphe.
Une solution qui permet de lire et découper des PDF avec un usage pensé pour le RAG.
Par exemple, ils vont inclure un résumé des tables en plus des données bruts.
Les chunks sur cette démo sont vraiment pas mal !
Les prix sont un peu cher par contre avec un prix d'entrée à 300$ pour 15 000 pages plutôt qu'un pay-as-you-go.
Dans cet article, les chercheurs détaillent plusieurs techniques intéressantes pour un RAG.
Ils utilisent une technique similaire à ce qu'on fait chez Didask avec une première étape qui consiste à extraire les informations pertinentes depuis de longs documents.
Cela permet d'avoir un document cohérent en matière brut plutôt que des chunks découpés arbitrairement dans le texte.
Ils vont ensuite évaluer la pertinence des informations extraites dans une deuxième étape qui utilise un CoT en 2 prompt:
- génération du raisonnement
- vérification de la pertinence du raisonnement
Une partie des prompts est donnée à la fin de l'article.
NotebookLM est une manière très simple de faire un RAG à partir de document présents sur Google Drive (mais pas que)
Il suffit de créer un Notebook, de sélectionner des sources et de poser des questions comme dans ChatGPT.
Les sources possibles pour le moment:
- Google Slides
- Google Doc
- Site web
- Vidéo Youtube
- Texte brut
C'est très facile à mettre en place et ça fonctionne plutôt bien.
La feature avec effet Whaou mais valeur à prouver c'est la possibilité de créer un "podcast" d'une conversation fictive à propos des documents que vous avez envoyé pour résumer les thèmes clés.
Un comparatif des capacités des bases de données vectorielles.
Mon conseil sur ce sujet c'est de ne pas se prendre trop la tête et d'utiliser les capacités de recherche vectorielle de la DB que vous utilisez déjà:
- Postgres: pgvector
- Mongo Atlas: Atlas Vector Search
- Elasticsearch: knn vector search
Si vous avez besoin de recherche avancée avec filtrage, scoring, BM25 (keyword search) et scalabilité alors Elasticsearch reste la meilleure option.
Si vous avez besoin de quelque chose de léger qui tourne dans le même process que votre application, il y a Qdrant (Python) ou LanceDB (Javascript) selon votre techno.
Frames est un benchmark (plutôt un dataset) de Google pour mesurer les capacités des RAGs.
Il contient +800 questions/réponses/articles qui nécessite de récupérer des informations depuis 2 à 15 articles de Wikipédia pour y répondre.
Concrètement cela veut dire que pour tester les performances de son RAG, il suffit de mettre les articles de Wikipédia anglophone en base de connaissances et de poser les questions du dataset une à une.
Pour arriver à répondre à ces questions, il faut que le RAG soit capable d'extraire des informations de plusieurs documents, de traiter des données numérique, des tableaux et de gérer des contraintes ou des données temporelles.
Le fork OpenSearch (Elasticsearch) d'Amazon Web Service inclut un RAG sur étagère.
On peut y déverser directement sa base de connaissance au format texte et ensuite l'interroger en mode RAG.
C'est pensé pour être utilisé dans une interface conversationnel et ils ont pensé à la persistance des conversations dans une entité "memory"
On peut choisir les modèles de LLM et aussi d'embeddings (ça reste limité aux modèles de OpenAI, Anthropic, Cohere et Bedrock)
C'est pratique pour monter rapidement un projet/prototype mais ensuite ça reste quand même une solution assez fermée si on veut pousser un peu plus loin dans le RAG.
La page de Dust qui explique le concept et les limites du RAG.
C'est la meilleure explication que j'ai trouvé et de loin !
HippoRAG propose une méthode de RAG avancée capable de répondre à des questions à partir d'informations dispersées dans plusieurs documents.
La méthode commence par une phase d'indexation afin d'extraire les "named entities" et des tuple de relations d'un graphe de connaissances. Par exemple, "Teddy Riner", "Judo", "Paris" sont des entités nommées (NE) et ["Teddy Riner", "est un champion de", "judo"] est une partie du graphe.
Lors de la phase de recherche, ils commencent par extraire les NE de la requête puis ils s'en servent pour parcourir le graphe à l'aide d'un algorithme de type "Page Rank". Entre autre, plus un noeud est loin du noeud de départ (une NE extraite depuis la query) et plus son score est faible.
Les résultats dépassent ceux des benchmark actuels jusqu'à 20 %.
Je trouve que la méthode de construction d'un graphe par LLM afin de s'en servir pour récupérer les informations pertinentes est quelque chose à creuser. Plus une base de connaissances augmente en taille et plus il est difficile d'extraire les connaissances pertinente simplement avec des recherches.
Tous les prompts sont donnés à la fin du papier 👌
Un clone de Perplexity à vocation pédagogique pour comprendre et apprendre les différents concepts du moteur de recherche augmenté par IA.
Techno: Next.js, Vercel AI SDK, Mistral, Langchain.js, Serper et Brave API (search), OpenAI Embeddings
OpenAI propose une API de RAG sur étagère (c’est en bêta encore)
Concrètement ça permet d’ingérer des documents dans une base de données vectorielle et de faire un RAG en très peu de code.
Il n’y a pas beaucoup de contrôle sur les différentes étapes, par exemple le chunking c’est uniquement chunking simple avec overlap, mais c’est très pratique pour faire un POC rapide par exemple.
Les détails d'une méthode qui allie un RAG à des comportements d'Agent.
Leur benchmark est une optimisation de flux financiers et logistique à réaliser en interrogeant de la donnée dans une base relationnelle.
Concrètement, un plan des données nécessaires et de leurs relations est établie en amont puis les différentes requêtes sont exécutées.
Si des données sont manquantes, un nouveau plan peut être établie.
Ils affichent des résultats jusqu'à 2 fois meilleurs (60%) qu'un RAG simple sur le benchmark qu'ils ont créé.
Donner la représentation interne de la base de connaissance au modèle pour lui permettre de créer ses propres requêtes est une piste intéressante que j'avais déjà envisagé (mais repoussé faute de structuration correcte dans notre base de connaissances à l'époque)
Une étude sur les capacités des modèles ayant de grandes fenêtres de contexte à réaliser des tâches de type RAG.
Il apparaît que les modèles sont autant capable qu'un RAG lorsque l'on met tous les documents dans leur fenêtre de contexte.
A première vue, on pourrait se dire que les RAG sont obsolètes mais:
- le nombre de tokens consommé est de 10 à 100x plus élevé
- même 2 millions de tokens peuvent s'avérer insuffisant pour une grande base de connaissances
En général, les modèles se débrouillent aussi mieux lorsque l'on limite le nombre d'informations présentes dans leur prompt et sur des cas d'usages de raisonnement comme en SQL, cela peut améliorer les performances.
Une solution clé en main de Text-to-SQL, un RAG pour poser des questions en langage naturelle à sa base de données.
Une autre solution un peu plus mature: Dataherald
Les deux sont Open Source :-)
Un retour d'expérience très complet sur le système d'interrogation du datawarehouse de Pinterest avec du langage naturel.
Ils ont construit un RAG avec lequel les utilisateurs peuvent poser des questions en langage naturel. 40% du temps le résultat est bon du premier coup et le reste du temps les utilisateurs doivent affiner leur question en plusieurs messages. (comme toujours, l'IA reste un copilote)
Une idée intéressante, ils utilisent les questions les plus courantes sur une table pour générer un summary de la table et son utilité. Ce summary est ensuite vectorisé.
Ils utilisent OpenSearch (la fork d'Elasticsearch) comme moteur de recherche vectoriel notamment parce qu'ils peuvent utiliser le scoring boost.
L'article est une mine d'information et ils donnent tous leurs prompts!
Un article qui parle de techniques avancées pour améliorer les résultats d'un RAG.
-
Query Expension: le but est d'améliorer le champ lexical de la requête pour retrouver plus de documents pertinents. On peut aussi parler de la méthode HyDE pour récupérer des documents en provenance de champs lexicaux différents.
-
Self Query: c'est ce que j'appelle l'extraction de facettes, en gros ça consiste à extraire du texte brut les filtres que l'on a définit dans son moteur de recherche (couleur, poids, etc)
-
Hybrid & Filtered vector search: cette étape je conseille de la faire exclusivement avec un vrai moteur de recherche comme Elasticsearch en utilisant les query avancées et le scoring
-
ReRanking: après la récupération des documents potentiellement pertinents (disons 50), on refait une passe en demandant à un LLM de choisir les documents contenant réellement des informations pour répondre à la demande de l'utilisateur.
Microsoft propose un outil qui prend des screenshots à intervalles réguliers puis les analyse avec de l'IA pour que l'on puisse chercher dedans n'importe quelle information.
Rewind propose la même chose sur Macos par exemple.
Dans l'idée, c'est un RAG automatique sur tout ce que vous faites donc ça peut être pratique.
Dans les faits, la qualité de la donnée est assez mauvaise et l'utilité limitée.
Par contre pour un pirate ayant accès à votre PC c'est une mine d'or 😬
Unstructured propose des produits autour de la normalisation de documents en vue de leur ingestion dans un RAG.
Ils proposent des produits en API et SaaS pour ingérer les documents mais aussi des lib open source !
Sur cette page, ils présentent leur format de découpage d'un document en plusieurs éléments standardisés comme NarrativeText, Title, Table, etc
Toutes les méthodes de chunking de documents disponibles dans Langchain et LlaMa Index.
Les plus intéressants sont ceux qui se basent sur la structure du document comme le markdown ou le HTML.
Cela n'est néanmoins pas suffisant car on peut perdre le contexte d'un chunk à l'autre. Par exemple, si le deuxième chunk fait référence au sujet du premier mais sans le reformuler.
Dans les techniques plus avancées, on peut noter le Semantic Splitting qui tente de découper les chunk entre les phrases en fonction du moment ou on change de sujet.
Une introduction à l'utilisation d'un graphe en addition à la recherche sémantique classique pour améliorer la récupération d'informations d'un RAG.
Ce genre de technique est de plus en plus populaire pour palier à la limite de la perte de contexte en plusieurs chunks.
Le plus difficile reste bien sûr de créer le graphe et de le faire évoluer. (Je pense qu'il y a moyen d'utiliser un LLM pour ça)