Analyse du système de récupération intégré d’OpenAI : dévoilement des contraintes de stockage, des lacunes de performance et des préoccupations liées aux coûts
Après les dernières annonces d’OpenAI, j’ai commencé à me demander si les OpenAI Assistants conviennent aux applications de niveau production, compte tenu de leurs limites, en particulier la limite de 20 fichiers et le prix de 0,2 $ par Go et par jour. Dans cette optique, j’ai rédigé un article axé sur trois sujets.
0,2 $/Go/jour pour la base de connaissances des OpenAI Assistants est-il coûteux ?
Explorer les solutions internes d’OpenAI à partir des informations qu’ils ont publiées.
Dans quelle direction l’infrastructure de la base de connaissances des AI Assistants devrait-elle évoluer ?
Note : Le contenu suivant contient quelques calculs. Vous êtes invité à parcourir ces calculs détaillés, ou vous pouvez choisir de vous concentrer sur les conclusions mises en évidence pour un aperçu rapide.
Le coût de la base de connaissances des OpenAI Assistants
Faisons quelques calculs simples :
Office 365 facture 6 $ par To de données par mois. Google Workspace facture 8 $ par To de données par mois.
Pour OpenAI Assistants, le coût est de 0,2 ($) x 30 (jours) x 1024 (Go) = 6 144 $ par To et par mois.
Par conséquent, ajouter un assistant IA à mes documents bureautiques avec OpenAI Assistants coûterait trois ordres de grandeur de plus qu’un service documentaire traditionnel (6 $ contre 6 144 $). Est-ce coûteux ? Je réponds : « Oui ! » cela semble excessivement élevé.
| Services | Tarification |
|---|---|
| Services documentaires traditionnels | $6 /To |
| OpenAI Assistants | $6,144/To |
Calculons aussi brièvement le coût opérationnel du côté d’OpenAI. L’analyse suivante est un peu complexe, mais la conclusion est simple : servir 1 Go de documents nécessite de générer 1,5 Go de vecteurs, et le coût serveur pour servir ces vecteurs est d’environ 0,30 $ par jour. Coûteux ? C’est une bonne affaire par rapport au prix affiché de 0,20 $/Go. Intéressant !
| Tarification | |
|---|---|
| Coût d’OpenAI | $0.3/Go par jour |
| Tarification d’OpenAI | $0.2/Go par jour |
Voici l’estimation :
Considérons 1 Go de texte utilisant le modèle text-embedding-ada-002 d’OpenAI pour générer les vecteurs destinés à la récupération. Pour chaque 1 Ko de texte, ce modèle créera un embedding à 1536 dimensions. Chaque dimension de vecteur correspond à un float32 (donc 6 Ko par vecteur), ce qui donne un rapport de taille entre le texte d’entrée et les vecteurs de sortie de 1:6, c’est-à-dire que 1 Go de texte correspond à 6 Go de vecteurs. La compression des vecteurs par quantification peut atteindre un taux de compression de 4:1, ce qui signifie que 1 Go de texte correspond à 1,5 Go de vecteurs.
Considérons le coût serveur pour servir 1,5 Go de vecteurs. Opter pour une instance AWS EC2 économique coûte environ 0,30 $ par jour pour chaque 1,5 Go de mémoire. Ce scénario est plus que juste, car il suppose uniquement le stockage et la recherche de vecteurs. Il n’inclut pas d’autres éléments comme les métadonnées, la surveillance, les journaux, les fichiers d’index et le coût de la haute disponibilité avec plusieurs réplicas, tous nécessaires dans les environnements de production.
Conclusion de l’analyse des coûts
La nouvelle fonctionnalité Assistants d’OpenAI coûte à l’entreprise plus d’argent qu’elle n’en rapporte en raison du coût serveur élevé de 0,3 $/Go/jour, par rapport à la tarification de 0,2 $/Go/jour. Cependant, les développeurs qui souhaitent utiliser les Assistants doivent payer plus de 1 000 fois plus que pour les services documentaires traditionnels. Ils doivent donc générer une valeur commerciale supérieure de trois ordres de grandeur à celle des services documentaires conventionnels pour justifier le coût.
Ce modèle tarifaire peut se justifier pour les entreprises B2C, car quelques Go de données coûtant quelques dizaines de dollars par mois ne risquent pas de constituer un problème majeur pour les utilisateurs individuels. Cependant, pour les entreprises B2B traitant des données à grande échelle, ce coût pourrait considérablement éroder les revenus de l’entreprise, voire dépasser la valeur de l’activité. Par exemple, créer un service client personnalisé ou un système de recherche intelligent pour les brevets et les documents juridiques pourrait devenir prohibitif.
Analyse approfondie de la solution d’OpenAI
Décortiquons le schéma actuel d’OpenAI Assistants. Voici quelques informations accessibles au public :
Un maximum de 20 fichiers par assistant
Une limite de 512 Mo par fichier
Une limitation cachée de 2 millions de tokens par fichier, découverte lors de nos tests
Seul le texte est pris en charge.
Le trafic serveur a connu une augmentation significative après OpenAI DevDay. Le nombre d’utilisateurs d’essai et d’assistants correspondants créés n’a pas été divulgué, mais il devrait avoir été important.
Décomposition du service de récupération d’OpenAI
Faisons quelques calculs à partir des informations publiques ci-dessus.
- Les utilisateurs sont limités à 20 fichiers, chacun plafonné à 2 millions de tokens. En supposant 200 tokens par segment (correspondant à un vecteur), la limite est de 200 000 vecteurs par utilisateur.
| Limite de fichiers par utilisateur | Nombre de tokens | Nombre de vecteurs |
|---|---|---|
| / | 200 | 1 |
| 1 fichier | 2 000 000 (limite haute) | 10 000 |
| 20 fichiers | 40 000 000 (limite haute) | 200 000 |
- Comme la plupart des utilisateurs n’atteindront pas la limite de 2 millions de tokens par fichier, nous pouvons estimer que le fichier de chaque utilisateur contiendra en moyenne 400 000 tokens, ce qui correspond à 2 000 vecteurs. En tenant compte de la limite haute de 200 000 vecteurs par utilisateur et de la moyenne de 2 000 vecteurs par utilisateur, atteindre un ratio de survente de 1000:1 est faisable.
| Limite de fichiers par utilisateur | Nombre de tokens | Nombre de vecteurs |
|---|---|---|
| / | 200 | 1 |
| 20 fichiers | 400 000 (en moyenne) | 2 000 |
De plus, OpenAI dispose d’une base d’utilisateurs substantielle, ce qui oblige l’entreprise à maintenir un système stable et à gérer efficacement l’impact de toute catastrophe. Par conséquent, durant les phases initiales du développement d’OpenAI Assistants, il est peu probable qu’ils optent pour une solution en cluster très grande échelle. OpenAI créerait plutôt probablement un système (illustré ci-dessous) dans lequel chaque groupe d’utilisateurs peut partager une petite instance de base de données vectorielle pour une meilleure stabilité.
Architecture simplifiée de la fonctionnalité de récupération d’OpenAI Assistants
Supposons que chaque nœud physique dispose de 32 Go de mémoire et soit divisé en quatre Pods. Chaque Pod héberge une instance distincte de base de données vectorielle, où 8 Go de mémoire sont alloués à un Pod. 3 Go sont dédiés au système de base de données vectorielle, et 5 Go sont réservés au service des données vectorielles des utilisateurs.
Avec un plafond de 200 000 vecteurs par utilisateur, les vecteurs quantifiés et leurs index nécessitent environ 500 Mo de mémoire. Par conséquent, chaque Pod peut accueillir dix utilisateurs sans survente. Cependant, avec un ratio de survente de 1000:1, un seul Pod peut servir jusqu’à 10 000 utilisateurs (avec au moins des centaines d’utilisateurs actifs). En conséquence, un seul serveur comprenant quatre Pods peut accueillir 40 000 utilisateurs.
Cette architecture semble adéquate pour prendre en charge les utilisateurs d’essai. Cependant, chaque nœud physique a le potentiel de stocker jusqu’à 20 Go de vecteurs et d’index pour les clients payants, correspondant à environ 8 Go de texte original. À pleine capacité, le potentiel de revenus quotidiens est modeste, à 1,6 $, ce qui est notablement faible.
Note : Dans les cas extrêmes où plusieurs utilisateurs avec de gros fichiers partagent un seul Pod, nous pouvons atténuer les difficultés potentielles grâce à la planification. Par exemple, le déploiement d’un nouveau Pod peut migrer efficacement la charge de ces utilisateurs plus importants.
Résumé rapide
L’architecture du service de retrieval d’OpenAI peut bien fonctionner pour les utilisateurs en essai, mais pourrait ne pas être suffisamment évolutive pour prendre en charge de plus grandes entreprises ayant des exigences de données plus étendues.
L’architecture actuelle impose des limites de stockage aux données utilisateur, réduisant les profits potentiels et augmentant les coûts.
De plus, l’architecture est inadéquate pour la multitenance au niveau applicatif, car certains clients peuvent nécessiter un assistant distinct pour chaque client. Voir davantage de discussions sur le forum OpenAI.
Pourquoi la base de connaissances d’OpenAI Assistants n’est pas suffisante
Nous avons précédemment discuté des limites d’OpenAI Assistants et de son architecture. Alors, comment pouvons-nous relever ce défi et réduire les coûts ? La solution la plus efficace serait d’optimiser l’architecture du service.
Avant d’approfondir la solution, considérez les facteurs cruciaux qui ouvrent la voie à une architecture système optimisée.
Une solution de base de données vectorielle affinée : stockage vectoriel hybride disque/mémoire
Les bases de données vectorielles chargent généralement les vecteurs et les index en mémoire afin d’accélérer les réponses aux requêtes. Cependant, les applications Assistant constituent un cas d’utilisation typique de Retrieval Augmented Generation (RAG) , de sorte que le goulot d’étranglement des performances réside dans l’inférence des grands modèles de langage (LLM) plutôt que dans le processus d’interrogation de la base de données vectorielle. Dans de tels cas, des réponses de recherche vectorielle ultra-rapides ne sont pas nécessaires. En dégradant intentionnellement les performances de la base de données vectorielle pour les aligner avec celles des LLM, nous pouvons atteindre un équilibre entre rentabilité et capacités de stockage accrues. Une piste prometteuse consiste à explorer une solution de base de données vectorielle basée sur disque, où seules les données chaudes sont chargées en mémoire. Cette approche réduit non seulement substantiellement les coûts matériels, mais augmente également la capacité de stockage globale du système.
Rationaliser la reprise après sinistre : mutualisation des données système
Actuellement, OpenAI Assistant emploie une approche quelque peu brutale pour la reprise après sinistre, en attribuant à chaque Pod une instance distincte de base de données vectorielle et en allouant plus d’un tiers de la mémoire de chaque Pod à l’usage du système. Cependant, étant donné que seules les données utilisateur nécessitent une séparation, une stratégie plus nuancée consiste à mutualiser les composants système. Cette approche améliore la haute disponibilité, permettant à ces composants de fonctionner indépendamment, libérés des Pods individuels.
Prise en charge de la multitenance pour une base d’utilisateurs diversifiée
Le cadre architectural devrait répondre sans difficulté à la fois à de nombreux petits utilisateurs et à de grandes entreprises avec des données à grande échelle. La prise en charge de la multitenance au niveau applicatif est une exigence fondamentale pour les applications d’agents, en particulier celles disposant de bases d’utilisateurs substantielles.
Dans cette logique, esquissons un diagramme d’architecture.
L’architecture optimisée de la fonctionnalité de retrieval d’OpenAI Assistants
Mettons en lumière quelques modifications clés :
Séparation des composants système et de requête. Auparavant colocalisés dans chaque Pod, les composants système sont désormais mutualisés indépendamment, réduisant leur empreinte en ressources de 1/3 à moins de 1/10 par rapport au schéma précédent.
Flexibilité améliorée pour les composants de requête : Les composants de requête peuvent désormais être alloués dynamiquement en fonction de différents nombres de Pods, bénéficiant d’une isolation physique pour une évolutivité indépendante. Le contrôle du rayon d’impact est finement géré à la granularité des composants de requête. Leur structure simplifiée améliore la fiabilité par rapport à des composants système plus complexes.
Architecture hybride mémoire/disque : L’introduction d’une architecture hybride mémoire/disque, où la mémoire charge exclusivement les données chaudes, constitue une autre modification cruciale. Cette amélioration permet à la même quantité de mémoire de servir 5 à 10 fois le texte original par rapport à la solution précédente.
Prise en charge multi-partition pour la multi-location : L’ajout de la prise en charge multi-partition répond aux besoins de multi-location au niveau de la couche applicative. Chaque utilisateur de niveau supérieur peut désormais se voir attribuer une partition de données indépendante, offrant une solution à faible coût au niveau de la couche applicative. L’isolation physique est obtenue en attribuant un composant de requête par groupe d’utilisateurs.
En recalculant la prise en charge des données avec cette architecture, un nœud de requête doté de 32 Go de mémoire, complété par de l’espace disque, peut désormais prendre en charge efficacement 320 Go de vecteurs et d’index, soit l’équivalent de 128 Go du texte original de l’utilisateur. Les ressources mutualisées des composants système allouées à ces nœuds de requête s’élèvent à 3 Go, physiquement distinctes des nœuds de requête. Au total, 35 Go de mémoire peuvent accueillir 128 Go de données utilisateur, ce qui correspond à environ 3,6 Go de données utilisateur par Go de mémoire. En revanche, la conception précédente permettait à 32 Go de mémoire de prendre en charge 8 Go de données utilisateur, soit une moyenne de 250 Mo de données utilisateur par Go de mémoire. Cela reflète une remarquable augmentation de l’efficacité d’un facteur 15.
Un aperçu des bases de données vectorielles populaires : Milvus, Chroma et Qdrant
Les bases de données vectorielles jouent un rôle essentiel dans l’optimisation de l’architecture des OpenAI Assistants, ce qui rend primordial le choix de l’option la plus robuste. Ici, nous examinons trois bases de données vectorielles open source majeures — Milvus, Chroma et Qdrant — en évaluant leurs forces et leurs limites dans l’amélioration de l’architecture des OpenAI Assistants.
Milvus
Avantages : Milvus est la base de données vectorielle open source la plus mature, largement adoptée dans les systèmes distribués à grande échelle. Parmi ses fonctionnalités notables figurent la séparation efficace des composants système et de requête, l’isolation des composants de requête grâce à la fonctionnalité Resource Group, une architecture hybride mémoire/disque et une multi-location au niveau applicatif facilitée par les fonctionnalités RBAC et Partition.
Inconvénients : Malgré ses atouts, Milvus ne parvient pas à obtenir une isolation complète des anomalies grâce à l’isolation des composants de requête basée sur Resource Group. De plus, il introduit certaines dépendances tierces, telles qu’Etcd et MinIO, entraînant des coûts de déploiement et d’exploitation plus élevés.
Chroma
Avantages : Chroma s’impose comme un projet nouveau et convivial, apprécié pour sa simplicité. Il convient bien au prototypage rapide et à l’itération rapide d’applications d’IA, gagnant en popularité auprès des développeurs individuels.
Inconvénients : Chroma excelle dans les scénarios à plus petite échelle, mais n’est pas conçu pour les applications d’entreprise à grande échelle. Il lui manque des fonctionnalités clés telles que le déploiement distribué, la séparation des composants, l’architecture hybride mémoire/disque et la multi-location au niveau applicatif.
Qdrant
Avantages : Qdrant, en tant que nouvel arrivant, offre une prise en charge du déploiement distribué à petite échelle avec un processus de configuration simplifié. Il dispose également d’une architecture hybride mémoire/disque, l’alignant sur les exigences des bases de données modernes.
Inconvénients : Actuellement, Qdrant ne prend pas en charge des fonctionnalités cruciales comme la séparation des composants ou la multi-location au niveau applicatif, ce qui limite son applicabilité dans certains cas d’utilisation.
Lors de l’évaluation de ces bases de données vectorielles, il devient évident que chaque solution apporte ses propres atouts et compromis, ce qui rend le choix dépendant des exigences et priorités spécifiques dans le contexte de l’optimisation de l’architecture des Assistants OpenAI.
Résumé
Dans cet article de blog, nous avons exploré les subtilités des Assistants OpenAI, en examinant leur tarification, leur architecture et les optimisations possibles pour améliorer la rentabilité et les capacités de stockage. Une révélation clé est apparue : le coût de l’infrastructure de base de données vectorielle influence considérablement le déploiement des bases de connaissances et des applications d’agents.
En analysant les coûts et les bénéfices d’OpenAI liés aux Assistants, nous avons mis en évidence un déséquilibre notable, les dépenses dépassant les revenus potentiels. Bien que cela puisse se justifier pendant la phase d’essai, afin d’accueillir de nouveaux clients et de favoriser l’expansion de la communauté, un équilibre plus durable est essentiel.
L’article de blog propose une solution pour optimiser l’architecture, ouvrant la perspective d’une réduction des coûts par dix pour ces types d’applications par rapport aux solutions existantes. Le rôle central des bases de données vectorielles dans ce processus d’optimisation est souligné, avec Milvus qui apparaît comme une option particulièrement adaptée parmi les alternatives disponibles.
Néanmoins, reconnaissant les limites inhérentes aux bases de données vectorielles existantes, cet article souligne qu’aucune solution unique de base de données vectorielle ne peut relever de manière exhaustive tous les défis ni satisfaire toutes les exigences de conception pour le développement imminent de l’infrastructure. Le choix des bases de données vectorielles doit être adapté aux exigences spécifiques afin de naviguer efficacement dans les complexités de l’optimisation de l’architecture des Assistants OpenAI.
Continuer à lire
Why and How to Migrate from Self-Hosted Milvus to Zilliz Cloud
A simple, step-by-step guide to migrating from Milvus to Zilliz Cloud. Learn both endpoint and backup methods for a smooth, scalable vector database migration.
Why Teams Are Migrating from Weaviate to Zilliz Cloud — and How to Do It Seamlessly
Explore how Milvus scales for large datasets and complex queries with advanced features, and discover how to migrate from Weaviate to Zilliz Cloud.
Zilliz Cloud Update: Tiered Storage, Business Critical Plan, Cross-Region Backup, and Pricing Changes
This release offers a rebuilt tiered storage with lower costs, a new Business Critical plan for enhanced security, and pricing updates, among other features.