R2R V2 - moteur RAG open source prêt pour la production
(github.com/SciPhi-AI)- Conçu pour combler l’écart entre les expérimentations locales avec des LLM et les systèmes de Retrieval-Augmented Generation (RAG) de niveau production
- Fournit un système RAG complet et moderne, pensé pour être simple à utiliser par les développeurs et centré sur une API RESTful
Fonctionnalités principales
- Prise en charge multimodale : prend en charge divers formats de fichiers comme
.txt,.pdf,.json,.png,.mp3, etc. - Recherche hybride : combine recherche sémantique et recherche par mots-clés pour améliorer la pertinence.
- Graph RAG : extrait automatiquement les relations et construit un graphe de connaissances.
- Gestion des applications : gère efficacement les documents et les utilisateurs, avec de riches fonctions d’observabilité et d’analyse.
- Client-serveur : prise en charge d’une API RESTful.
- Configurable : permet de provisionner des applications à l’aide de fichiers de configuration intuitifs.
- Extensible : les applications peuvent être facilement étendues grâce au pattern builder + factory.
- Tableau de bord : fournit le tableau de bord R2R, une application open source React+Next.js pour une interaction conviviale.
Tableau de bord R2R
Il est possible d’interagir avec R2R via le tableau de bord open source React+Next.js. Vous pouvez commencer en consultant le Cookbook du tableau de bord.
1 commentaires
Avis Hacker News
Précision et efficacité de l’extraction de données : le processus d’extraction des données constitue un défi majeur dans les systèmes RAG. Les approches OCR traditionnelles étant insuffisantes, une approche LLM multimodale + OCR est utilisée pour améliorer la précision et la cohérence.
Expérience d’exploitation d’une stack similaire : une stack similaire est exploitée depuis 2 ans, avec des technologies comme Pgvector, HyDe, la recherche web + recherche documentaire. Il existe un bon tableau de bord incluant les logs et l’analytique.
Difficulté d’un démarrage rapide : le quickstart n’est en réalité pas si rapide. Il faudrait fournir une configuration incluant Docker Compose et des images Postgres. Il y a aussi la contrainte de devoir cloner un dépôt séparé pour utiliser le tableau de bord.
Complexité du projet : le projet comprend de nombreux éléments, mais cela ne rend pas le développement plus simple. Il y a une confusion sur le fait qu’il s’agisse d’un SDK ou d’un ensemble d’applications. Il faudrait proposer une expérience d’installation en « 1 clic » permettant de prévisualiser toutes les fonctionnalités.
Vérification de la précision : question sur la manière de vérifier la précision des réponses. Il est demandé s’il existe un moyen de retracer le processus ayant conduit à la génération d’une réponse.
Difficulté de la collecte de données : dans de nombreux projets RAG, la collecte de données n’est pas correctement résolue. Question sur la manière d’ingérer en masse de grands volumes de documents HTML dans le système.
Collecte de données multimodales : demande d’une explication détaillée du processus de collecte de données multimodales. Question sur les types de données que R2R peut actuellement traiter et sur la manière d’intégrer les types de données non textuels.
Optimisation pour les équipes de développement : demande d’explications sur la façon dont le processus est devenu plus rapide et mieux optimisé pour les équipes de développement. Il y a un fort potentiel pour accélérer le temps de développement d’un MVP (produit minimum viable).
Travail avec le code source : recherche d’une solution RAG capable de comprendre le code source. Par exemple, une fonctionnalité permettant de comprendre « l’événement analytique appelé lorsqu’on clique sur le bouton d’envoi » est souhaitée.
Opposition à l’utilisation de Neo4j : souhait de ne pas utiliser Neo4j, en raison de sa forte consommation de ressources.
Intégration avec des frontends de chat populaires : question sur l’existence d’une intégration avec des frontends de chat populaires comme OpenWebUI.