Développer un produit d'IA générative : ce qu'il faut savoir avant de se lancer

Introduction

L’IA générative est facile à tester, mais nettement plus difficile à transformer en un produit sur lequel les utilisateurs peuvent compter. Une équipe peut connecter un modèle linguistique à une interface de chat en quelques jours. Mais faire en sorte que cette interface traite les demandes réelles des clients, respecte les autorisations d’accès, exploite les données de l’entreprise et se remette de réponses erronées est une tout autre affaire.

Pour les entreprises qui envisagent d’utiliser l’IA générative dans le cadre d’applications métier, la première décision à prendre n’est pas de savoir quel modèle utiliser. Il s’agit plutôt de déterminer si le problème nécessite réellement la création d’un nouveau produit. Des outils d’IA prêts à l’emploi peuvent couvrir la plupart des besoins, tandis qu’une implémentation sur mesure s’avère plus pertinente lorsque les logiciels existants ne permettent pas de prendre en charge le flux de travail requis. Les entreprises qui envisagent cette dernière option peuvent consulter les ingénieurs spécialisés en IA générative de SysGears afin d’étudier les exigences techniques d’un produit conçu autour de leur cas d’utilisation particulier.

Un produit d’IA générative implique bien plus que le simple fait d’intégrer un modèle derrière une interface aux couleurs de l’entreprise. Le modèle peut certes gérer le langage, mais c’est le reste de l’application qui détermine les informations sur lesquelles il peut s’appuyer, s’il peut interagir avec d’autres logiciels et ce qui se passe lorsque sa réponse n’est pas pertinente. Ces décisions influent autant sur l’utilité du produit que le choix du modèle lui-même.

Un assistant interne peut induire les employés en erreur s’il récupère un document de politique obsolète. Si on lui donne accès aux dossiers clients, les autorisations d’accès deviennent tout aussi importantes que la qualité des réponses. Si l’application peut également modifier des dossiers, une réponse convaincante mais incorrecte pourrait causer de réels préjudices.

Ce ne sont pas là des détails que l’on peut régler après coup, une fois le lancement effectué. Ils influencent l’architecture, l’effort d’ingénierie requis et les coûts de développement de l’IA, y compris ce qu’il faut pour assurer le bon fonctionnement du produit. Une entreprise doit les examiner en détail avant de s’engager dans le développement, tant qu’il est encore possible de restreindre la portée du projet ou de décider qu’un outil existant ferait l’affaire.

Commencez par un problème nécessitant une IA générative

Une démonstration convaincante peut masquer un problème métier assez banal. Si les collaborateurs passent trop de temps à rechercher de la documentation interne, par exemple, un système de recherche sémantique peut suffire. S’ils doivent interpréter de longs documents, extraire des détails spécifiques et rédiger des réponses à partir d’informations provenant de plusieurs sources, un modèle linguistique peut apporter une valeur ajoutée plus substantielle.

Cette distinction est importante dès le départ. L’IA générative prend tout son sens lorsque le logiciel doit donner du sens à des données désordonnées et non structurées, ou rédiger un texte qui dépend du contexte. En revanche, pour une tâche régie par des règles fixes, un script classique est souvent moins coûteux à mettre en œuvre et plus fiable.

Prenons l’exemple d’un distributeur confronté à un flux constant de demandes de renseignements sur les produits. Les clients décrivent un même article de toutes sortes de façons ; une application d’IA générative pourrait donc donner du sens à leurs demandes, extraire les spécifications pertinentes et rédiger une réponse. Les niveaux de stock constituent un autre sujet. Ceux-ci doivent provenir des registres d’inventaire en temps réel, tandis qu’un prix proposé doit respecter les règles de tarification de l’entreprise, et non le chiffre que le modèle produit par hasard.

Il est important de bien distinguer ces tâches : laissez le modèle s’occuper du langage et confiez les opérations prévisibles à des logiciels conventionnels dans la mesure du possible.

Avant de lancer tout développement, déterminez précisément ce qui doit réellement être amélioré. Le personnel commercial pourrait gagner du temps pour établir un devis ; les clients pourraient obtenir une réponse sans avoir à attendre un conseiller. Dans tous les cas, documentez le fonctionnement actuel du processus. Sinon, une équipe risque de se réjouir de l’adoption de sa nouvelle interface IA sans savoir si celle-ci a réellement facilité le travail.

Développer ou acheter : de quel niveau de contrôle avez-vous réellement besoin ?

Le dilemme « développer ou acheter » est souvent présenté comme un choix entre la maîtrise totale et la commodité. Dans la pratique, il existe plusieurs options intermédiaires.

Les outils d’IA prêts à l’emploi constituent un point de départ judicieux lorsqu’une entreprise a besoin de fonctionnalités courantes telles que l’aide à la rédaction, les comptes-rendus de réunion, l’analyse de documents ou la recherche générale. Ces produits nécessitent généralement moins de travail d’ingénierie, et leurs fournisseurs gèrent une grande partie de l’infrastructure sous-jacente. Une entreprise peut ainsi tester si ses employés trouvent une fonctionnalité utile sans avoir à financer au préalable un projet de développement dédié.

Les difficultés apparaissent lorsqu’un outil générique doit s’adapter à un processus pour lequel il n’a pas été conçu. Il peut, par exemple, ne pas être compatible avec une base de données héritée ou ne pas appliquer les autorisations d’accès appropriées lorsque les collaborateurs occupent des rôles différents. Ses résultats peuvent également nécessiter d’être reformatés avant de pouvoir être utilisés par un autre système d’entreprise. Les API et les options de configuration peuvent aider à combler ces lacunes, mais elles ne couvrent pas nécessairement les particularités d’un flux de travail bien établi.

Un produit d’IA sur mesure devient plus justifiable lorsque le flux de travail lui-même constitue un avantage concurrentiel, lorsque les produits existants ne peuvent pas répondre à une exigence essentielle, ou lorsque l’application nécessite une intégration étroite avec des données propriétaires et des systèmes internes.

Une troisième option consiste à développer votre propre application autour d’un modèle hébergé par un fournisseur externe. L’entreprise développe l’interface et la logique sous-jacente, intègre le système à ses logiciels existants et met en place sa propre méthode pour tester les résultats. L’accès au modèle lui-même se fait via une API ; il n’est donc pas nécessaire d’entraîner un modèle de base à partir de zéro. Cela donne à l’entreprise la latitude nécessaire pour adapter le produit à son flux de travail, même si elle reste tributaire de la tarification du fournisseur, de la disponibilité des modèles et des limites du service.

Cette dernière distinction mérite une attention particulière. Développer une application d’IA sur mesure et développer un nouveau modèle d’IA sont deux entreprises distinctes. L’entraînement d’un modèle de base nécessite des ressources informatiques considérables, une expertise spécialisée, des données adaptées et une expérimentation continue. La plupart des entreprises n’ont pas besoin d’assumer cette charge. Un modèle existant, complété par l’extraction d’informations à partir de documents de l’entreprise ou par un accès à des outils soigneusement conçus, peut s’avérer suffisant.

Choisir l’architecture en fonction du flux de travail

Une fois l’analyse de rentabilité établie, le prochain défi consiste à déterminer comment l’application fonctionnera. Le modèle n’est qu’un composant parmi d’autres, et ce n’est pas forcément celui qui mobilise le plus de temps de développement.

Pour un assistant documentaire, la génération augmentée par la recherche (RAG) mérite souvent d’être envisagée. Au lieu de s’appuyer exclusivement sur ce qu’un modèle a appris pendant son entraînement, l’application extrait des passages pertinents d’une source d’information approuvée et les inclut dans la requête. Le modèle formule ensuite une réponse à partir de ces éléments.

Les réponses fondées sur les politiques internes ou les informations actuelles sur les produits peuvent être plus pertinentes, à condition que la recherche fonctionne correctement. Or, cela n’est pas garanti. La recherche peut extraire un document obsolète, passer à côté d’une mise en garde cruciale ou fournir au modèle un passage qu’il interprète ensuite de manière erronée.

La fonction de recherche doit être testée en tant que telle. La manière dont les documents sont découpés en segments peut influencer les résultats trouvés par le système, et même un bon résultat de recherche est inutile s’il provient d’une source que l’utilisateur n’est pas censé consulter. Les droits d’accès d’un employé doivent s’appliquer au processus de recherche, plutôt que d’être contournés parce qu’une recherche a par hasard mis en évidence du contenu restreint. C’est à l’application elle-même qu’il revient de faire respecter les autorisations. On ne devrait pas se fier à un modèle pour prendre cette décision.

Le réglage fin a un objectif différent. Il peut aider à adapter le comportement d’un modèle, le format de ses réponses ou sa gestion des schémas de tâches récurrentes lorsque des exemples d’entraînement appropriés sont disponibles. Il ne s’agit pas d’un simple substitut à la recherche lorsque le problème principal est l’accès à des informations en constante évolution. Un modèle réglé finement sur le catalogue de produits de l’année dernière ne saura pas automatiquement ce qui a changé ce matin.

Une invite et une API de modèle peuvent suffire à une application au champ d’application restreint, du moins au départ. Cela dépend du degré de prévisibilité des entrées et de ce que l’on attend du système avec ses sorties. Si chaque réponse doit être recoupée avec un vaste corpus de documentation interne, la recherche d’informations peut s’avérer nécessaire ; pour une tâche plus simple, cela pourrait simplement alourdir le processus.

Concevez une première version allégée et testez-la sur de véritables requêtes, et non pas uniquement sur des données de démonstration soigneusement préparées. Observez comment elle gère une question vague ou des informations manquantes. Si elle bluffe plutôt que d’admettre une lacune, c’est un point à corriger avant d’ajouter d’autres éléments complexes.