0.4.0 - Release note [WIP]

warning

La version 0.4.0 n'est pas encore disponible dans sa version stable, des modifications mineures sont encore en cours de développement.

A l'occasion de la version 0.4.0 de OpenGateLLM (précédente version 0.3.7), nous avons décidé de reviser notre approche en nous basant sur les recommandations préconisées par Elasticsearch. Les principales modifications sont les suivantes :

• Dépréciation du support de Qdrant au profit d'Elasticsearch
• Fusion des index Elasticsearch dans un index unique
• Métadonnées pré-définies pour les documents

Ces changements majeurs impliquent une migration des données de votre vector store, nous vous proposons ici un script de migration pour vous aider à mettre à jour votre instance.

Préambule

Actuellement, nous supportons deux technologies de vector store : Qdrant et Elasticsearch. Nous avons décidé il y a quelque mois de ce concentrer sur Elasticsearch pour la gestion de nos collections de documents. Nous revenons ici sur les raisons de ce choix.

Cependant depuis quelques semaines nous avons constaté des difficultés de scalabilité avec Elasticsearch. Ces problèmes proviennent de la manière dont nous avons implémenté Elasticsearch dans OpenGateLLM. Pour résoudre ces problèmes, nous avons décidé de reviser notre approche, ce qui implique des changements majeurs et une migrations des données.

A cet fin nous vous proposons ici de détailler les modifications que nous avons apportées et un script de migration pour vous aider à mettre à jour votre instance.

Pourquoi Elasticsearch plutôt que Qdrant ?

En matière de Retrieval-Augmented Generation (RAG), il y a 3 méthodes de recherches classiques :

• La recherche lexicale avec BM25 (TF-IDF)
• La recherche sémantique avec vector similarity
• La recherche hybride avec une combinaison des deux (algorithme de Reciprocal Rank Fusion (RRF) pour combiner les résultats)

Nous cherchions a offrir ces 3 méthodes de recherche à nos utilisateurs. Initialement nous avions implémenté Qdrant pour la recherche sémantique en raison de sa scalabilité.

Cependant en voulant ajouter la recherche lexicale et la recherche hybride, nous avons constaté que Qdrant ne supportait pas nativement ces méthodes. Leur approche est basé sur le déploiement d'un modèle s'ajoutant au vector store.

De plus, Elasticsearch excelle dans la recherche lexicale avec BM25 et permet nativement la mise en place de filtres complexes sur des champs spécifiques. Pour ces raisons, Elasticsearch nous semble une meilleure solution pour la recherche RAG.

L'objectif d'OpenGateLLM est de supporter plusieurs solutions de vector store afin de vous laisser le choix de la technologie qui vous convient le mieux.

Changements majeurs

Fin du support de Qdrant

Afin de nous concentrer sur un support d'Elasticsearch, nous avons décidé de déprécier le support de Qdrant. Cette décision a été prise après avoir interoger la communauté sur le sujet. En effet, il s'avère qu'actuellement personne n'a fait le choix de Qdrant pour leur instance d'OpenGateLLM.

De plus, l'équipe d'OpenGateLLM ayant des ressources limitées, nous ne pouvons pas nous permettre de maintenir deux solutions de vector store pour le moment.

Nous n'excluons pas de revenir sur cette décision dans le futur si la communauté nous le demande. De plus l'objectif reste de supporter plusieurs solutions de vector store à terme, dès lors que nous aurons les ressources nécessaires.

Fusion des index Elasticsearch dans un index unique

Actuellement pour chaque collection, OpenGateLLM crée un index Elasticsearch. Cette approche permet de gérer les collections de manière indépendante. Cependant, cela n'est pas optimale pour la scalabilité. En effet pas défaut ElastiSearch limite le nombre de shards (pour chaque index, ElasticSearch créer au moins un shard). La multiplication des index peut vite devenir dans ce contexteun goulot d'étranglement pour les performances.

A good rule-of-thumb is to ensure you keep the number of shards per node below 20 per GB heap it has configured. A node with a 30GB heap should therefore have a maximum of 600 shards, but the further below this limit you can keep it the better. Source: How many shards should I have in my Elasticsearch cluster?

Pour résoudre ce problème, nous avons décidé de fusionner tous les index Elasticsearch dans un index unique. Afin de migrer vos données, nous vous proposons un script de migration (voir Script de migration).

Métadonnées pré-définies pour les documents

Actuellement lors de la création d'un document, l'utilisateur peut définir des métadonnées pour le document. Il est libre de définir les métadonnées qu'il souhaite avec les types suivants : int, str, float, datetime ou bool.

Cette ajout dynamique de métadonnée va rapidmeent poser problème avec la fusion des index dans un index unique. En effet, Elasticsearch n'est pas conçu pour supporter de manière optimale des milliers de champs sur un index. Cela risque de créer des problèmes de performances et de scalabilité. Une solution envisageable aurait été de définir des champs avec le type flattened. Cependant cette solution règle que partiellement le problème de performance et limite les actions de filtrage sur ces champs (ils sont alors stockés dans un seul champ et interpréter comme des str).

Afin d'assurer la scalabilité de l'index Elasticsearch, nous avons décidé de pré-définir les métadonnées pour les documents. Cette approche d'éviter une surcharge de l'index par les métadonnées tout en gardant des fonctionnalités de filtre par type. Nous avons pré-défini les champs de métadonnées suivants :

• source_ref (str 1-255)

  Correspond au référentiel du document. Ce champ est volontairement générique pour qu'il puisse être utilisé pour correspondre à l'ID du document dans un référentiel ou servir à concaténer les informations de localisation du chunk dans le document source (ex: doc-1#page-1#section-1).

• source_url (str 1-255)

• source_title : Le titre du document

• source_author : L'auteur du document

• source_publisher : Le publisher du document

• source_priority : La priorité du document

• source_tags : Les tags du document

• source_date (datetime) : La date du document

Ces champs nous semblent génériques et utiles pour de la recherche RAG sur des données textuelles.

Autres changements

• Correction de bugs mineurs sur le Playground :

  • Formatage de la date d'expiration des utilisateurs
  • Suppression de l'ancien type de collection ID
  • Tri et filtres sur les pages Router et Provider
  • Suppression de tous les rôles et organisations pour la création d'utilisateurs

• Correction du support des modèles d'audio transcription avec vLLM et Albert API

Script de migration

[WIP]

warning

La migration des données va supprimer les métadonnées personnalisées des documents. Si vous souhaitez les conserver nous vous invitons à migrer vos données manuellement.