Couche d’accès multimodale unifiée pour Poe de Quora via Amazon Bedrock

TL;DR

• Une API wrapper unifiée permet une approche build-one, deploy-many pour les modèles Bedrock sur Poe.
• L’architecture traduit le protocole Server-Sent Events (SSE) de Poe en REST Bedrock, avec utilisation hybride de l’API Converse introduite par Bedrock en mai 2024.
• Un système de configuration basé sur des templates réduit considérablement le temps de déploiement à environ 15 minutes et permet d’intégrer plus de 30 modèles Bedrock dans les domaines texte, image et vidéo.
• La solution réduit les changements de code jusqu’à 95 % et prend en charge une production à haut débit avec gestion robuste des erreurs, comptage des tokens et authentification sécurisée AWS.

Contexte et arrière-plan

Les organisations s’appuient de plus en plus sur des architectures Gateway IA générative pour accéder à plusieurs FMs via une API normalisée unique. Créer et maintenir des intégrations séparées pour chaque modèle entraîne un effort d’ingénierie important, des défis de maintenance et des friction pour l’onboarding des nouveaux modèles. Le AWS Generative AI Innovation Center et Quora ont collaboré pour développer une API wrapper unifiée qui standardise l’accès aux Bedrock FMs pour Poe. Poe est le système d’IA multi-modale de Quora, permettant aux utilisateurs d’interagir avec une bibliothèque de modèles et d’assistants de différents fournisseurs. L’intégration a nécessité de concilier l’architecture SSE orientée évenements de Poe avec l’API REST de Bedrock, les patterns AWS SDK, l’authentification SigV4, la disponibilité des modèles par région et les options de streaming. L’initiative a mis en lumière le besoin de maintenir la maintenabilité et de simplifier l’onboarding lorsque de nouveaux modèles Bedrock deviennent disponibles. En mai 2024, Bedrock a introduit l’API Converse, offrant des avantages de standardisation qui ont simplifié l’architecture d’intégration. La solution décrit ici utilise l’API Converse lorsque cela est approprié tout en restant compatible avec les API spécifiques des modèles pour leurs capacités spécialisées. Cette approche hybride offre flexibilité et standardisation dans une même intégration.

Ce qui est nouveau

L’apport central est une API wrapper modulaire entre Poe et Bedrock, fournissant une interface unifiée et une couche de traduction qui normalisent les différences entre modèles et protocoles tout en préservant les capacités de chaque modèle. Éléments clés :

• Bot Factory : création dynamique du gestionnaire de modèle selon le type de modèle demandé (texte, image, vidéo).
• Service Manager : orchestre les services spécialisés nécessaires au traitement des requêtes, y compris les services de tokens, de streaming et de gestion des erreurs.
• Couche de traduction : relie l’API SSE de Poe aux endpoints REST Bedrock, gérant les différences subtiles entre les modèles afin de garantir le format attendu par Poe.
• ErrorService : gestion des erreurs cohérente entre les modèles.
• AwsClientService : gestion sécurisée de l’authentification et des connexions Bedrock.
• Configuration par templates : système de configuration centralisé avec des valeurs par défaut communes et des surcharges spécifiques au modèle, permettant un onboarding rapide.
• Comptage et optimisation des tokens : permet des estimations de coût précises et une utilisation efficace des modèles.
• Pool de connexions avec aiobotocore : soutien à un volume élevé de requêtes en maintenant un pool de connexions Bedrock.
• Usage de Converse API : lorsque pertinent, pour la standardisation, tout en conservant les capacités des modèles. La approche “build unique, deploy multiple models” a permis à Poe d’élargir son catalogue de modèles Bedrock, avec plus de 30 modèles intégrés dans les domaines texte, image et vidéo, en quelques semaines plutôt qu’en mois. L’architecture est conçue pour être modulaire et évolutive.

Pourquoi c’est important (impact pour les développeurs/entreprises)

• Déploiement multi-modèles accéléré : la configuration par templates et la translation logicielle réduisent le temps d’onboarding et l’effort d’ingénierie.
• Diversité de modèles accrue : Poe peut étendre rapidement son catalogue Bedrock sans réécrire les intégrations pour chaque modèle.
• Contrôle opérationnel et fiabilité : gestion cohérente des erreurs, comptage des tokens et authentification sécurisée garantissent un comportement prévisible.
• Maintenance facilitée : une couche d’abstraction unique réduit la charge liée aux évolutions des APIs.
• Prêt pour la production : l’architecture gère les charges élevées avec des stratégies de scalabilité bien définies.

Détails techniques ou Implémentation

Le plus grand défi technique était de relier le modèle SSE de Poe à l’API REST de Bedrock. L’équipe a mis en œuvre une couche de traduction robuste qui normalise les réponses et conserve le format attendu par Poe. Composants et pratiques clés :

• BotConfig et configuration par templates : classe BotConfig offrant des définitions structurées et une validation des types pour configurer les bots de manière cohérente.
• Gestion des erreurs : ErrorService assure des messages d’erreur clairs et uniformes.
• Comptage des tokens : soutient des estimations de coût précises et une utilisation efficace des modèles.
• AwsClientService pour l’authentification : gère l’authentification sécurisée avec les services AWS.
• Approche hybride : utilisation de Converse API pour standardisation, tout en restant compatible avec les API spécifiques des modèles.
• Support multi-modale : démontre les capacités en texte, image et vidéo avec divers modèles Bedrock.
• Préparation à la production : pool de connexions Bedrock géré par aiobotocore pour de hautes performances. Un impact notable est l’amélioration de l’efficacité du déploiement : l’onboarding de plus de 30 modèles Bedrock dans diverses modalités s’est fait en semaines plutôt qu’en mois. L’architecture homogénéisée et la couche de traduction accélèrent les cycles d’innovation tout en garantissant le contrôle opérationnel.

Contexte de déploiement et catalogue de modèles

Le Catalogue Bedrock sert de hub central pour la découverte et l’évaluation des modèles de plusieurs fournisseurs. Dans Poe, l’intégration permet une expérience de catalogue évolutive où les modèles sont présentés comme des chatbots individuels dans l’interface, permettant aux utilisateurs d’interagir avec plusieurs fournisseurs via une plateforme unique.

Mises en perspective et tableau de comparaison

| Métrique | Avant l’intégration | Après l’intégration |---|---|---| | Temps de déploiement pour embarquer des modèles Bedrock | mois | ~15 minutes |Nombre de modèles Bedrock onboardés | non scalable | >30 en texte, image et vidéo |Changements de code par onboarding | importants | réduction jusqu’à 95 % |Stratégie de concurrence | connexions séparées manuelles | pool de connexions Bedrock via aiobotocore |

Points clés à retenir

• Une couche d’abstraction bien conçue simplifie fortement le déploiement multi-modèles en normalisant les protocoles et interfaces.
• La configuration par templates accélère l’onboarding et minimise les écarts entre modèles.
• Les approches hybrides associant API standardisée (Converse) et API spécifiques permettent à la fois cohérence et capacités.
• Des primitives opérationnelles solides sont cruciales pour des systèmes d’IA multi-modèles en production.
• Les architectures modulaires permettent une expansion rapide du catalogue de modèles tout en maintenant un comportement prévisible.

Références

• https://aws.amazon.com/blogs/machine-learning/unified-multimodal-access-layer-for-quoras-poe-using-amazon-bedrock/