IA générative · 6 min de lecture

IA générative : ce qui passe de la démo à la production

Les difficultés n'ont presque rien à voir avec le modèle.

Construire une démonstration d'IA générative convaincante prend quelques jours. Cette facilité crée une attente que la mise en service met des mois à satisfaire, et l'écart surprend souvent les équipes qui financent le projet.

Ce qui suit ne parle pas de modèles. Les difficultés que je rencontre sont ailleurs.

La démonstration teste ce qu'on connaît déjà

Quand on prépare une démonstration, on choisit les questions. Sans le vouloir, on retient celles qui fonctionnent bien. Le système paraît donc plus fiable qu'il ne l'est.

En service réel, les utilisateurs posent des questions mal formulées, ambiguës, ou portant sur des sujets absents de la base documentaire. Le comportement dans ces cas-là n'a généralement pas été décidé — et par défaut, le système répond quand même.

Le vrai risque n'est pas l'erreur visible

Un système qui répond n'importe quoi de façon manifeste ne pose pas de problème durable : les utilisateurs cessent de l'utiliser. Le risque sérieux, c'est la réponse plausible, bien formulée, et fausse.

Afficher les sources qui ont servi à construire la réponse est le contrôle le plus efficace et le moins coûteux. Il rend la vérification possible pour celui qui connaît le métier.

« Ça marche bien » n'est pas une évaluation

Sans jeu de questions de référence, toute modification devient un pari : on change une instruction, le résultat semble meilleur sur deux exemples, et on ne sait pas ce qu'on a dégradé ailleurs.

Le minimum utile est une liste de questions représentatives avec, pour chacune, ce qu'une bonne réponse doit contenir. Cela permet aussi de distinguer deux causes très différentes : le système n'a pas retrouvé la bonne information, ou il l'a retrouvée et mal exploitée. Ces deux problèmes appellent des corrections opposées.

La base documentaire vit

Une démonstration travaille sur un corpus figé. En service réel, des documents arrivent, sont modifiés, sont retirés. Chaque changement doit se répercuter, sinon le système répond à partir de versions périmées, avec la même assurance.

On retrouve les problématiques d'un pipeline de données classique : détecter les nouveautés, mettre à jour sans tout reconstruire, supprimer réellement ce qui a été retiré, et surveiller que tout cela s'est bien passé.

Trois questions avant d'engager un budget

  1. Que fait le système quand il ne sait pas ? Si la réponse n'a pas été décidée explicitement, il inventera.
  2. Comment vérifie-t-on qu'une réponse est bonne ? Sans jeu de test, aucune amélioration ne sera mesurable.
  3. Qui met à jour la base documentaire ? Si personne n'est désigné, le système se dégradera sans que ça se remarque.

Un projet d'IA générative en entreprise ressemble beaucoup moins à un projet de recherche qu'à un projet de données : qualité des sources, fraîcheur, traçabilité, supervision. Le modèle est la partie la plus visible, et rarement celle qui pose problème.

Une question sur ce sujet ?

Si ce texte recoupe un problème que vous rencontrez, écrivez-moi.