Nous utilisons des cookies pour vous garantir une expérience optimale. Si vous acceptez, vous êtes en accord avec cette utilisation. Pour plus d'informations, veuillez consulter notre politique de confidentialité.
/

Innovation

Comment sélectionner le modèle d'IA idéal pour un projet pharmaceutique?

Armand Brière
Armand Brière
10
min read
Laboratoire pharmaceutique

Dans cet article, nous verrons comment l’équipe d’intelligence artificielle (IA) d’Osedea sélectionne le modèle d’IA idéal pour chaque projet, en tenant compte des besoins spécifiques tout en offrant les meilleures performances. Nous examinerons l’importance des données et la manière de valider les options possibles, même sans accès aux données du client.

Dans la foulée des dernières tendances dans le domaine, nous commençons à voir un besoin grandissant de modèles d’IA pour la transcription automatique de la parole. Les clients s’intéressent à de nouvelles façons d’interagir avec leurs systèmes, en particulier dans le contexte des agents conversationnels basés sur les grands modèles de langage. Explorons le sujet dans le contexte de l’industrie pharmaceutique.

Survol des modèles de pointe

Chaque client est unique et a des besoins différents. Cependant, en matière d’IA, tout le monde veut les meilleures performances. Pour choisir le modèle le mieux adapté, il est essentiel de comprendre les forces et les faiblesses des différents modèles. Voici un aperçu des modèles les plus performants que nous avons examinés :

  1. Whisper d’OpenAI

Whisper est un modèle solide qui prend en charge plusieurs langues avec une grande précision. Il est réputé pour son excellente gestion des accents et des bruits de fond.

  1. Speech-to-Text de Google

L’API Speech-to-Text permet la transcription en temps réel de données audio à grande échelle dans des environnements gérés par Google.

  1. Transcribe d’AWS

Transcribe d’AWS est un excellent modèle, similaire à Speech-to-Text de Google. Principalement utilisé pour le service à la clientèle et les centres d’appels, il est très évolutif et convient au traitement de grandes quantités de données.

Tous ces modèles remplissent parfaitement leur mission, mais il arrive que le modèle optimal ne soit pas celui qui présente les meilleures performances dans les tâches courantes d’analyse comparative. Comme nous travaillons sur un projet pharmaceutique traitant des données spécialisées, nous devions trouver un modèle pouvant être adapté à notre cas d’utilisation.

Définir le cas d’utilisation

Le cas d’utilisation est la pierre angulaire du projet. Une solide compréhension des besoins du client nous permet de choisir le modèle idéal pour notre application. Devons-nous transcrire une interaction en centre d’appel, un balado ou une vidéo ? La transcription doit-elle se faire en temps réel ou par lots ? Voilà les questions essentielles auxquelles nous devons répondre avant de sélectionner les modèles à évaluer. Dans notre cas, nous cherchons à développer un assistant virtuel intelligent pour épauler les scientifiques dans le développement de médicaments au sein d’une entreprise pharmaceutique.

La principale caractéristique de cet assistant intelligent est de transcrire en temps réel la voix du scientifique en texte. Les scientifiques peuvent ainsi se concentrer sur leur travail et non sur la prise de notes.

Choisir le modèle approprié

Après avoir défini le cas d’utilisation, nous avons exploré la liste des modèles disponibles. Nous nous sommes rapidement rendu compte qu’aucun des modèles de pointe n’était adapté à notre cas d’utilisation. Bien qu’ils fournissent tous une transcription en temps réel, leur coût d’utilisation à grande échelle risque d’exploser. C’est sans compter la complexité du déploiement et de la maintenance de ces modèles, ainsi que l’envergure des ressources informatiques requises. Nous avons donc décidé d’explorer des solutions plus abordables et moins gourmandes en ressources, mais qui répondaient à nos exigences de précision et de performance.

Heureusement, en 2022, OpenAI a décidé de rendre son modèle Whisper disponible en open source, dans différentes tailles. Nous avons ainsi pu entraîner notre propre modèle sur nos propres données pour l’adapter à notre cas d’utilisation particulier. Cette approche nous a permis de personnaliser le modèle en fonction de nos besoins, tout en réduisant le coût et la complexité du déploiement et de la maintenance.

Si le code source du modèle Whisper est libre, il nous reste à choisir la bonne taille du modèle et les meilleurs hyperparamètres, et à valider le modèle pour notre cas d’utilisation particulier.

Pour ce faire, nous avons suivi les étapes ci-dessous afin de sélectionner le modèle optimal pour notre client :

1. Collecte des données

2. Prétraitement des données

3. Évaluation comparative des modèles

Collecte de données pour l’évaluation comparative

Comme nous travaillons sur un projet pharmaceutique, les données sont spécifiques à ce domaine. Pour commencer, nous avons défini des mots-clés et des termes propres au secteur, puis nous avons dressé une liste détaillée des phrases à utiliser pour l’évaluation des modèles. Une fois la liste des phrases établie, soit environ 2 000 mots, nous avons commencé à chercher le meilleur moyen de les transformer en fichiers audio.

Il existe de nombreux outils de conversion du texte en parole, mais que valent-ils ? Ils sont un peu trop bons et trop robotiques aux fins d’une évaluation comparative. Les meilleures données sont celles qui reflètent l’environnement réel de production. Dans cette optique, nous avons simplement décidé de nous enregistrer à la lecture des phrases et de créer notre propre ensemble de données. La diversité de l’équipe d’Osedea nous a permis de recueillir un bon mélange d’accents et de tons vocaux afin de garantir la représentativité des données par rapport à l’environnement d’utilisation éventuel.

La collecte de notre ensemble de données personnalisé au bureau a été une expérience amusante, et nous avons développé un script pour présenter les phrases au lecteur et enregistrer le son via une simple interface de ligne de commande. Nous avons constaté que certaines phrases étaient difficiles à lire et certains mots mal prononcés. C’était une bonne occasion d’améliorer nos données et de les rendre plus robustes.

Une fois l’opération terminée, nous disposions d’un ensemble de fichiers audio d’une durée moyenne d’une heure, suffisant pour l’évaluation comparative des modèles.

Évaluation comparative des modèles

Comme indiqué précédemment, le modèle Whisper se décline en plusieurs tailles. Nous avons testé les modèles Tiny, Base, Small et Medium sur un processeur standard. Après tout, pourquoi choisir d’emblée le processeur graphique le plus puissant ? Est-ce vraiment nécessaire ? L’exécution de l’évaluation comparative sur un processeur standard nous a permis de l’exécuter sur plusieurs machines et de comparer les résultats. Nous voulions également évaluer les performances du modèle sur du matériel de base afin d’évaluer le coût de fonctionnement du modèle en production. Notre travail trouve son inspiration dans l’étude comparative Picovoice sur la transcription automatique de la parole. Ce projet à code libre adopte une astucieuse approche orientée objet qui permet de tester de multiples modèles. Une classe Engine par défaut est créée, et les nouveaux moteurs sont chargés d’implémenter leur propre fonction transcribe().

Voici quelques extraits du code :

class Engine:
    """Base class for all engines."""

    def transcribe(self, path: str) -> str:
        """Transcribe the given audio file."""
        raise NotImplementedError()

La classe Engine par défaut est relativement simple, avec quelques méthodes supplémentaires pour gérer la collecte des mesures.

À partir de ce moteur, une nouvelle classe de moteur WhisperTiny peut être créée sans difficulté :

class WhisperTiny(Engine):
    """Whisper Tiny engine for the benchmark."""

    SAMPLE_RATE = 16000

    def __init__(self, model: str = WHISPER_TINY_MODEL_NAME):
        self._model = whisper.load_model(model, device="cpu")
        self._audio_sec = 0.0
        self._proc_sec = 0.0

    def transcribe(self, path: str, **transcribe_params) -> str:
        """Transcribe the given audio file."""

        audio, sample_rate = soundfile.read(path, dtype="int16")
        assert sample_rate == self.SAMPLE_RATE
        self._audio_sec += audio.size / sample_rate

        start_sec = time.time()
        res: str = self._model.transcribe(
            path, language="en", fp16=False, **transcribe_params
        )["text"]
        self._proc_sec += time.time() - start_sec

        return self._normalize(res)

Le jeu de données est défini. Les modèles et le matériel sont prêts. Voyons maintenant les mesures utilisées pour évaluer les modèles :

Le taux d’erreur de mots (ou Word Error Rate [WER] en anglais) est une mesure couramment utilisée pour évaluer les performances des modèles de reconnaissance vocale. Il mesure le pourcentage de mots incorrectement transcrits par le modèle. Plus le WER est faible, meilleure est la performance du modèle.

Le facteur temps réel (ou Real-Time Factor [RTF] en anglais) est une mesure de la vitesse du modèle. Il représente le rapport entre le temps nécessaire pour transcrire l’audio et la durée de l’audio. Plus le RTF est faible, plus le modèle est rapide à transcrire l’audio.

L’exécution du modèle sur notre ensemble de données a produit les valeurs suivantes :

Voici une représentation graphique du WER et du RTF des modèles :

Les résultats sont sans équivoque : comme prévu, plus le modèle est petit, plus il est rapide, mais plus le WER est élevé. C’est la conclusion à laquelle tout le monde semble arriver sur les analyses comparatives publiques. Pour nous, les modèles Small et Medium donnent pratiquement les mêmes résultats de WER et de RTF. Le triplement de la taille du modèle ne vaut pas le gain de performance de 0,06 % entre ces deux modèles.

La différence entre les modèles Tiny et Base est considérable : le WER est supérieur de 3,69 % pour le modèle Tiny, mais la RTF est inférieure de 0,85. C’est un bon compromis pour un modèle de transcription en temps réel. Ces résultats sont prometteurs, puisqu’il reste à optimiser les hyperparamètres et à adapter le modèle aux données propres au domaine. L’exécution du modèle sur un processeur graphique améliorerait la vitesse du modèle, mais augmenterait également le coût de l’exécution en production. Les discussions futures avec le client nous aideront à décider si le gain de performance vaut le coût.

Conclusion

Le choix du modèle adéquat pour un projet est une tâche délicate. Il faut une compréhension approfondie du cas d’utilisation, des données et des performances du modèle. Dans cet article, nous avons examiné le processus de sélection du modèle Whisper pour notre projet pharmaceutique. Nous avons commencé par bien définir le cas d’utilisation, créer notre propre ensemble de données et évaluer le modèle. Les résultats prometteurs nous permettent de passer à l’étape du développement.

Cet article vous a donné des idées ? Nous serions ravis de travailler avec vous ! Contactez-nous et découvrons ce que nous pouvons faire ensemble.

Contactez-nous
Button Arrow