IBM Granite 3.3 : reconnaissance vocale, raisonnement affiné et RAG LoRA

• Nous publions Granite Speech 3.3 8B, un nouveau modèle de Speech to Text (STT) qui excelle dans la reconnaissance automatique de la parole (ASR) et la traduction automatique de la parole (AST).
• Le nouveau modèle audio repose sur Granite 3.3 8B Instruct, la dernière mise à jour de notre grand modèle de langage d’entreprise (LLM), le plus performant. Outre des capacités de raisonnement améliorées, les modèles Granite 3.3 Instruct offrent désormais des capacités de remplissage du milieu (FIM) en plus de la prédiction standard du prochain jeton.
• Afin d’améliorer les applications existantes pilotées par Granite, nous lançons également une suite d’adaptateurs LoRa axés sur la génération augmentée de récupération (RAG) pour Granite 3.2. Les commentaires serviront au développement d’adaptateurs LoRA pour Granite 3.3 Instruct, qui sortira prochainement, ainsi que pour les futures générations de LLM Granite.
• Outre ces adaptateurs conventionnels, IBM Research a également développé une série de LoRA activés (aLoRA), un nouveau type expérimental d’adaptation de faible rang (LoRA) qui réduit les coûts d’inférence et les besoins en mémoire tout en permettant de passer facilement d’un adaptateur à un autre.
• Comme toujours, tous les modèles et outils Granite sont en open source sous une licence standard Apache 2.0.
• Tous les modèles Granite 3.3 et les outils associés sont disponibles sur Hugging Face. Le modèle Granite 3.3 Instruct est également disponible sur IBM watsonx.ai, ainsi que via des partenaires, dont LMStudio, Ollama et Replicate.

Le lancement d’aujourd’hui marque une nouvelle extension de la portée multimodale d’IBM Granite. Granite Speech 8B, notre tout premier modèle de conversion parole-texte, est la figure de proue de Granite 3.3, qui marque le début de nos incursions dans les fonctionnalités audio. Parallèlement à l’ajout récent de capacités de vision et de raisonnement, IBM continue d’accroître la polyvalence de la série Granite dans les cas d’utilisation d’entreprise dont les clients et la communauté open source ont le plus besoin.

En plus de Granite Speech 3.3 8B, nous lançons Granite 3.3 8B Instruct, le grand modèle linguistique (LLM) qui lui sert de fondation, et sa version plus petite (2B). La sophistication accrue du processus de raisonnement des modèles de texte par rapport à leurs prédécesseurs et l’ajout de capacités de remplissage au milieu (FIM) facilitent un plus large éventail de cas d’utilisation applicables, en particulier dans le domaine du codage.

Nous publions également une série mise à jour et étendue d’adaptateurs LoRA améliorant les performances (et principalement axés sur la RAG) pour le modèle Granite 3.2 8B Instruct précédemment lancé via Granite Experiments, un terrain de jeu IBM Research pour tester les idées open source. D’autres innovations en matière de LoRA, notamment une suite d’adaptateurs pour Granite 3.3 Instruct, seront lancées dans les semaines à venir. ­­­

Granite Speech 3.3 8B est un modèle STT compact et économique, destiné aux applications d’entreprise qui traitent les entrées vocales et optimisé pour la reconnaissance automatique de la parole (ASR) et la traduction automatique de la parole (AST).

Pour les tâches de transcription, Granite Speech 3.3 offre systématiquement une plus grande précision que les principaux modèles ouverts et fermés concurrents lors des tests effectués sur plusieurs jeux de données publics de premier plan.

Le modèle fournit également une traduction automatique de l’anglais vers un large éventail de langues, dont le français, l’espagnol, l’italien, l’allemand, le portugais, le japonais et le mandarin. Lors des tests de performance AST réalisés par IBM, Granite Speech 3.3 8B a suivi le rythme des principaux modèles propriétaires, tels que GPT-4o d’OpenAI et Gemini 2.0 Flash de Google sur les langages pris en charge par Granite dans l’ensemble de données CoVost. Vous trouverez de plus amples informations sur les performances de traduction dans la fiche du modèle Hugging Face.

Sur le plan architectural, Granite Speech 3.3 comprend :

• Un encodeur vocal, composé de 10 blocs « conformer » entraînés avec la classification temporelle connexionniste (CTC) sur des jeux de données axés sur l’ASR.
• Un projecteur de parole –dans ce cas, un transformateur de requêtes à deux couches (Q-former) –qui convertit les intégrations audio en un format interprétable par un grand modèle linguistique (LLM).
• Un LLM,à savoir Granite 3.3 8B Instruct, avec une longueur de contexte de 128 Ko.
• Des adaptateurs LoRA, appliqués aux matrices de requête et de projection de valeur du LLM lorsque des données audio sont présentes.

Contrairement aux modèles directement intégrés qui combinent la parole et le texte en un seul passage, Granite Speech 3.3 procède en deux passages. Par exemple, pour poser des questions au modèle sur un fichier audio, il faut un premier appel pour transcrire l’audio et un deuxième prompt pour interroger le modèle sur ce texte transcrit. Si un prompt contient le token "<audio> " et le fichier .wav correspondant, Granite Speech lancera l’encodeur audio, le projecteur et l’adaptateur LoRA. Sinon, le modèle s’exécutera simplement en mode texte à l’aide de l’instruction Granite 3.3 Instruct 8B.

Cette approche à deux passages garantit que les performances de Granite Speech 3.3 8B sur les requêtes textuelles reflètent celles de son LLM sous-jacent (Granite 3.3 8B Instruct), évitant ainsi la dégradation des performances textuelles typique de nombreux modèles multimodaux. Grâce à une plateforme d’inférence configurée pour servir correctement les modèles textuels et vocaux, les développeurs peuvent comprendre Granite Speech 3.3 8B comme une version de Granite 3.3 8B Instruct avec des capacités d’entrée audio supplémentaires.

Contrairement aux modèles ASR classiques basés sur Whisper, Granite Speech 3.3 peut accepter des entrées de longueur arbitraire. Lors des tests, le modèle a facilement pu traiter un fichier audio de 20 minutes sur un GPU H100 de 80 Go, au lieu d’être limité à une fenêtre de 30 secondes. Sur les modèles basés sur Whisper, les fichiers audio dépassant ce maximum doivent être coupés en tranches de 30 secondes, ce qui entraîne souvent des inexactitudes au moment où ces coupures de 30 secondes sont imposées. En règle générale, moins vous devez faire de découpes artificielles, moins vous introduisez d’imprécisions.

Bien que Granite Speech 3.3 puisse ingérer des entrées audio assez longues, il convient de noter que le modèle n’a pas encore été affiné pour les données audio longues. Afin de maintenir une précision constante, il est recommandé de limiter chaque unité d’entrée audio à une minute.

Granite Speech 3.3 marque juste le début de l’exploration d’IBM dans les capacités audio de la série Granite. Les recherches en cours pour améliorer Granite Speech pour les futures versions, en particulier dans Granite 4, comprennent :

• Encodage multilingue : actuellement, l’encodeur audio de Granite Speech 3.3 est uniquement anglais. Une étape importante pour Granite Speech : des encodeurs audio multilingues et sensibles aux phénomènes paralinguistiques, qui nous permettent de permettre des entrées véritablement multilingues.

• Des recettes de données affinées : les futurs programmes d’entraînement intégreront des données d’entraînement plus nombreuses et de meilleure qualité, la génération de données synthétiques pour des cas d’utilisation ciblés jouant un rôle important. Nous expérimentons également d’autres étapes d’optimisation et d’équilibrage des données.

• Fusion des modalités antérieures : nous découvrons la mise en œuvre d’une structure plus unifiée qui intègre des fonctionnalités audio à tous les stades d’entraînement des futurs modèles Granite.

• Détection des émotions : les futurs modèles vocaux Granite prendront en charge les capacités de reconnaissance des émotions de la parole (SER) en entraînant notre encodeur acoustique à être plus sensible aux événements audio non lexicaux.

Les dernières versions de nos modèles optimisés par les instructions textuelles, Granite 3.3 8B Instruct et Granite 3.3 2B Instruct, intègrent des fonctionnalités de remplissage du milieu (FIM) et continuent d’affiner les capacités de réflexion introduites dans Granite 3.2.

Nous proposons également leurs équivalents de base, Granite 3.3 8B Base et Granite 3.3 2B Base, qui remplacent désormais leurs prédécesseurs de Granite 3.1, afin de permettre aux développeurs d’accéder à nos modèles prenant en charge la FIM pour leurs propres efforts d’optimisation.

Les LLM autorégressifs, généralement utilisés pour la génération de textes, sont fondamentalement conçus pour déplacer, de gauche à droite. Ils sont formés par un apprentissage auto-supervisé pour prédire itérativement le token suivant dans une séquence, sur la base des informations des tokens précédents, jusqu’à ce que la séquence soit considérée comme complète. Bien que cette conception se prête à une variété impressionnante de tâches génératives, elle ne permet pas à un type de tâche différent : prédire les tokens corrects en fonction des tokens précédents et ultérieurs. En d’autres termes, les LLM autorégressifs conventionnels ne peuvent pas « remplir le milieu ».

Pour adapter les modèles autorégressifs au remplissage, il faut repenser les tâches d’entraînement pour « tromper » le LLM dans la prédiction des tokens au milieu en utilisant sa capacité de prédiction intrinsèque de gauche à droite. Cela nécessite généralement de diviser un passage en préfixe (les tokens précédents), suffixe (les tokens qui viennent après) et milieu (les tokens à prédire par remplissage), puis de réorganiser le passage de sorte que le modèle reçoive à la fois un préfixe et un suffixe avant d’être invité à prédire les tokens intermédiaires. Granite 3.3 utilise des tokens spécialisés pour permettre au modèle de générer du contenu conditionné à la fois sur le préfixe et le suffixe.

Bien que FIM ait un large éventail de cas d’utilisation, il s’applique particulièrement bien aux tâches de codage, de la réparation de code et de la connexion d’erreurs à la refactorisation, en passant par la génération rapide de code modèle et l’insertion d’arguments de fonction ou de chaînes de documents.

Pour Granite 3.2, nous avions pour objectif d’enrichir les capacités de raisonnement des modèles Instruct grâce à l’optimisation des préférences de pensée (TPO), afin d’améliorer leur capacité à suivre des instructions complexes sans sacrifier les performances générales. Pour Granite 3.3 Instruct, notre objectif était de préserver ces gains tout en enrichissant les performances des modèles de raisonnement mathématique complexe.

Construits sur un modèle de base Granite 3.3 mis à jour et affinés grâce à l’apprentissage par renforcement en plusieurs étapes à l’aide de TPO et Optimisation des politiques relatives de groupe (GRPO), les deux modèles Granite 3.3 Instruct ont démontré une amélioration significative sur les benchmarks techniques associés aux capacités de « raisonnement ».

La performance de Granite 3.3 8B sur le benchmark de référence MATH500 le place largement devant Claude 3.5 Haiku (64,2 %) d’Anthropic, et Llama 3.1 8B Instruct de Meta (44,4 %), soit près de celle du Mistral Small 3 (70,6 %) et à peine derrière Claude 3.5 Sonnet (72,4 %) et GPT-4o Mini d’OpenAI (72,6 %).¹

Comme pour les modèles Granite 3.2 Instruct, la fonction « thinking » peut être facilement activée ou désactivée, ce qui permet aux développeurs de privilégier le raisonnement par chaîne de pensée (CoT) amélioré lorsqu’ils en ont besoin, et de privilégier la rentabilité et la faible latence lorsque ce n’est pas le cas.

Pour améliorer les applications basées sur Granite existantes et informer le développement de la prochaine génération d’adaptateurs LoRA à performance améliorée, IBM publie également une collection de 5 adaptateurs LoRA spécifiques à la RAG (principalement) pour Granite 3.2 8B Instruct via Granite Experiments, un terrain de recherche d’IBM pour tester des idées open source. Chacun de ces adaptateurs LoRA tire parti des connaissances intrinsèques du modèle pour activer une tâche spécifique, comme la réécriture des requêtes de récupération ou la détection des hallucinations.

IBM Research a développé ces adaptateurs LoRA « conventionnels » ainsi que des contreparties pour chacun d’entre eux qui utilisent un nouveau type d’adaptation de faible rang que nous appelons LoRA activés (aLoRA). Le passage d’un adaptateur LoRA standard à un autre ralentit souvent les performances, car le modèle doit recalculer le contexte de la conversation en cours en utilisant le nouveau. Mais contrairement aux adaptateurs LoRA standard, les aLoRA d’IBM réutilisent simplement le cache clé-valeur (KV) existant, ce qui évite de devoir recalculer le contexte (ou "pré-remplir") à nouveau. Les LoRAs activés correspondent à la qualité de génération des LoRAs standards tout en offrant des avantages significatifs en termes de temps d’exécution et de calcul. Le code source permettant d’exécuter les aLoRA est disponible ici.

Détection des
hallucinations RAG Même avec la RAG, un LLM peut parfois halluciner. Lorsqu’il est équipé du RAG hallucination détection LoRA, le modèle fournit un « score de fidélité » compris entre 0 et 1 (par incréments de 0,1), reflétant à quel point sa production reflète fidèlement les informations contenues dans les documents récupérés. Un score de fidélité plus faible indique un risque d’hallucination plus élevé. Le modèle donnera une réponse sans réponse lorsque la question ne peut pas être répondue avec les informations disponibles.

RAG Query Rewrite
Les moteurs de recherche fournissent des résultats nettement meilleurs en réponse à des requêtes autonomes contenant toutes les informations pertinentes qu’en réponse à des requêtes nécessitant du contexte datant du début de la conversation pour être exploitable. Lorsque le Query Rewrite LoRA est équipé, le modèle réécrira automatiquement toute requête d’utilisateur non autonome en une requête entièrement autonome. Prenons par exemple l’échange suivant :

Utilisateur : « Qui est le PDG d’Apple ? » Modèle : « Tim Cook est le président-directeur général d’Apple Inc. » Utilisateur : « Et pour Microsoft ? »

Le modèle transmettra la première requête de l’utilisateur telle quelle, mais réécrira la deuxième requête comme suit : «Qui est le PDG de Microsoft ? ». Lors des tests, cette réécriture a augmenté la pertinence des réponses du modèle de 21 points de pourcentage.

Bien qu’elle ait été conçue en tenant compte de la RAG, Query Rewrite ne nécessite pas la présence de documents RAG : elle peut également être utilisée pour réécrire les requêtes des utilisateurs pour d’autres cas d’utilisation, tels que les appels d’outils.

RAG Citation Generation
Lorsqu’il est équipé de l’outil RAG Citation Generaton LoRA, le modèle génère une citation pour chaque phrase de son résultat (si cette phrase a été alimentée par des sources externes). Chaque citation au niveau de la phrase indique non seulement la ou les sources référencées, mais contient également un ensemble de phrases issues de la ou des sources citées qui viennent étayer la phrase correspondante générée par le modèle.

RAG Answerability Prediction
Lorsqu’il est équipé de l’outil RAG Answerability Prediction LoRA, le modèle détermine si la réponse à la requête de l’utilisateur peut ou non être traitée à l’aide des informations disponibles dans les documents connectés. Cette classification binaire, « réponse » ou « sans réponse », peut être utilisée, entre autres, pour filtrer les questions sans réponse (réduisant ainsi les hallucinations) ou pour inviter le modèle à réinterroger le récupérateur d’informations d’une manière différente.

Pour chaque sortie de modèle, le LoRA d’incertitude, issu des recherches de calibrage de modèles d’IAdu MIT-IBM Watson AI Lab , permet au modèle de générer un « score de certitude » quantifié allant de 0 à 9 (représentant un niveau de certitude de 5 à 95 %, respectivement). Le score reflète essentiellement dans quelle mesure la réponse du modèle est étayée par les informations contenues dans ses données d’entraînement.

Alors que la RAG traditionnelle implique une seule inférence, c.-à-d. un prompt simple ancré dans un contexte spécifique, fournissant une seule production du modèle, nous proposons d’utiliser ces LoRA dans les workflows qui exploitent plusieurs adaptateurs LoRA sur plusieurs inférences en route vers une réponse finale du modèle.

Par exemple, vous pouvez d’abord mettre en œuvre Query Rewrite pour (si nécessaire) réécrire rapidement les prompts initiaux afin d’optimiser la précision de la récupération. Une fois que la réponse augmentée par la récupération du modèle a été générée à l’aide du prompt réécrit, vous pouvez implémenter la détection d’hallucination RAG pour vérifier que le niveau de fidélité est approprié aux informations contenues dans les documents récupérés. Si le score de fidélité est inférieur à un seuil acceptable, votre workflow peut diriger le modèle pour rééchantillonner la réponse jusqu’à ce que le score de fidélité dépasse ce seuil. Lorsqu’il n’y a plus d’hallucinations détectées, vous pouvez utiliser RAG Citations pour la réponse finale qui sera fournie à l’utilisateur.

Cela équivaudrait essentiellement à l’équivalent RAG du calcul de temps de test, en échafaudant de multiples inférences pour améliorer et enrichir la production finale du modèle. Nous sommes impatients de voir comment la communauté open source va implémenter et expérimenter ces nouveaux adaptateurs LoRA. Vous trouverez de plus amples informations sur les RAG LoRA et leur impact sur la performance des modèles dans le document technique qui l’accompagne.

IBM Research entraîne activement Granite 4.0, une nouvelle génération de modèles qui représentent une évolution majeure de l’architecture Granite et démontrent des gains prometteurs en termes de vitesse, de durée contextuelle et de capacité. Bien que les détails spécifiques ne soient annoncés que plus tard au cours du deuxième trimestre, les clients, les partenaires et les développeurs peuvent compter sur IBM pour maintenir son engagement en faveur de petits modèles pratiques qui peuvent être exécutés à faible coût et avec une faible latence.

Les nouveaux modèles Granite 3.3 Instruct sont disponibles sur IBM watsonx.ai, notre studio intégré de bout en bout pour le développement d’IA d’entreprise. Vous pouvez essayer Granite 3.3 Instruct 8B, et découvrir facilement l’activation ou la désactivation de la fonction de réflexion «thinking » sur le Granite Playground.

Granite Speech 3.3 8B, ainsi que tous les nouveaux modèles Granite et adaptateurs LoRA, sont disponibles sur Hugging Face. Certains modèles Instruct sont également disponibles via des partenaires, dont (par ordre alphabétique) LMStudio, Ollama et Replicate, et d’autres suivront prochainement.

Un certain nombre de guides et de recettes pour travailler avec les modèles Granite sont disponibles dans la documentation Granite et dans le Granite Snack Cookbook sur GitHub. Les développeurs peuvent se lancer dans les modèles Granite en consultant notre série de démonstrations, de recettes et de tutoriels utiles, comme :

• Tutoriel : utiliser Granite Speech 3.3 pour générer une transcription et un résumé d’un podcast
• Formule : raisonnement Granite 3.3
• Tutoriel : créez un agent de recherche IA pour l’analyse d’images avec les modèles Granite Reasoning et Vision
• Tutoriel : RAG multimodal avec Granite Vision et Docling

Découvrir les nouveaux modèles IBM Granite 3.3→