Un modèle performant ne suffit pas : construire un système d’IA utile
Un modèle d’IA peut produire une réponse convaincante, résumer un document ou expliquer un concept complexe. Mais lorsqu’on veut l’intégrer à un processus métier, ces capacités ne suffisent pas à elles seules.
Il faut aussi déterminer quelles informations lui transmettre, comment vérifier ses réponses, ce qui doit se passer lorsqu’il se trompe et quelle place donner à l’utilisateur.
C’est cette différence entre les capacités d’un modèle et le fonctionnement d’un système complet qui m’intéresse particulièrement en tant qu’ingénieur IA.
Mon expérience au sein de BNP Paribas, AskiaBot ainsi que d'autres projets, ont renforcé cet intérêt. En contribuant à la conception d’un workflow d’IA appliqué à des activités de contrôle, j’ai notamment travaillé sur des problématiques de recherche documentaire, de sources, d’éléments de preuve et de validation humaine.
Pour illustrer ces enjeux, prenons un exemple fictif : un assistant chargé d’analyser un dossier et d’aider un professionnel à identifier les informations manquantes.
1. Définir la tâche avant de choisir le modèle
« Analyser un dossier » reste une instruction très large.
S’agit-il de vérifier la présence de documents obligatoires ? De repérer des incohérences ? De comparer les informations à un référentiel ? Ou de préparer des questions pour la personne chargée du contrôle ?
Ces tâches n’impliquent ni les mêmes données ni les mêmes critères de réussite.
Dans notre exemple, on pourrait commencer par une mission précise :
Pour chaque exigence d’une liste définie, retrouver les éléments correspondants dans le dossier, indiquer leur source et signaler les points qui nécessitent une vérification humaine.
Cette formulation permet de préciser les entrées, les résultats attendus et les limites de l’assistant.
Elle permet également de distinguer ce qui nécessite un modèle de langage de ce qui peut être traité par une règle classique. Vérifier qu’un fichier est présent ne demande pas forcément la même approche que comprendre si son contenu répond à une exigence.
Le choix technique devient plus pertinent lorsque la tâche est suffisamment claire.
2. Construire le contexte dont le modèle a besoin
Pour traiter notre dossier, le modèle doit avoir accès aux bonnes informations.
Cela soulève plusieurs questions : quelle version du document utiliser ? Où se trouve le passage pertinent ? Un tableau a-t-il été correctement extrait ? Le référentiel fourni est-il celui qui s’applique au dossier ?
Une erreur à ce niveau peut se répercuter sur toute la réponse.
Imaginons qu’un élément de preuve figure dans une annexe, mais que cette annexe n’ait pas été intégrée au contexte. Le modèle pourrait signaler une information manquante alors que le dossier la contient.
Il faut donc distinguer deux situations :
- l’information est effectivement absente du dossier ;
- le système n’a pas réussi à la retrouver.
Cette distinction doit apparaître dans la manière de concevoir le système et de présenter ses résultats.
La préparation des documents, leur recherche et la conservation de leurs références font ainsi partie du travail d’ingénierie.
3. Vérifier ce qui est affirmé
Une réponse claire et bien rédigée peut donner une impression de fiabilité. Pourtant, sa qualité rédactionnelle ne permet pas de savoir si elle est correcte.
Dans notre exemple, un résultat utile devrait permettre de retrouver :
- l’exigence examinée ;
- le constat proposé ;
- le passage utilisé comme élément de preuve ;
- sa localisation dans le document ;
- les éventuelles limites de l’analyse.
La présence d’une source ne suffit pas non plus : il faut vérifier qu’elle soutient réellement le constat.
Un passage peut mentionner un sujet sans démontrer que l’exigence correspondante est satisfaite.
C’est pourquoi l’évaluation doit porter sur des comportements précis. Le système retrouve-t-il les bons passages ? Ses constats sont-ils justifiés ? Signale-t-il des manques inexistants ? Oublie-t-il certains points à vérifier ?
Une démonstration sur un dossier bien préparé peut montrer le potentiel du système. Pour évaluer sa fiabilité, il faut aussi le confronter à des documents incomplets, ambigus ou contradictoires.
4. Donner une place concrète à la validation humaine
La validation humaine doit se traduire dans le fonctionnement du produit.
Si l’assistant fournit une conclusion sans permettre de consulter les éléments qui l’ont motivée, le professionnel doit refaire une grande partie de l’analyse pour la vérifier.
À l’inverse, une interface qui rapproche le constat, l’exigence et le passage source peut faciliter cette vérification.
Dans notre exemple, l’utilisateur devrait pouvoir accepter un constat, le corriger, le rejeter ou demander une analyse complémentaire.
Il devrait aussi pouvoir distinguer une suggestion produite par le système d’une conclusion effectivement validée.
Cette distinction aide à clarifier les responsabilités. L’assistant prépare des éléments de travail ; le professionnel garde la maîtrise de leur interprétation et de la décision qui suit.
La possibilité de signaler un cas non résolu fait également partie du fonctionnement attendu. Une information insuffisante doit pouvoir rester insuffisante.
5. Mesurer l’utilité dans le travail réel
Un système peut fonctionner techniquement tout en apportant peu de valeur à son utilisateur.
S’il produit trop de faux signalements, demande de nombreuses corrections ou rend les sources difficiles à consulter, le temps consacré à le vérifier peut annuler le gain attendu.
L’évaluation doit donc aussi porter sur le processus de travail.
Pour notre assistant, je chercherais notamment à mesurer le temps nécessaire pour examiner un dossier, la qualité des constats après validation, les omissions et l’effort de correction demandé à l’utilisateur.
Ces dimensions doivent être regardées ensemble. Un traitement plus rapide n’est pas nécessairement une amélioration s’il laisse passer davantage de points importants.
Il faut enfin observer la manière dont les utilisateurs s’approprient l’outil : comprennent-ils ses limites ? Savent-ils quand approfondir une vérification ? Les résultats s’intègrent-ils à leur manière de travailler ?
Le travail d’ingénierie autour du modèle
Construire un système d’IA utile demande de relier plusieurs éléments : un besoin métier, des données, un modèle, des mécanismes de vérification et une expérience utilisateur.
Le modèle occupe une place importante dans cet ensemble. Mais sa performance ne compense pas automatiquement un contexte incomplet, une tâche mal définie ou un résultat difficile à contrôler.
C’est ce travail d’ensemble que je souhaite approfondir : concevoir des solutions d’IA capables d’assister des activités complexes, avec des résultats que les utilisateurs peuvent comprendre, vérifier et exploiter.
La question que je veux poser au début d’un projet est donc simple :
Quelle tâche voulons-nous améliorer, et comment saurons-nous que le système aide réellement la personne qui l’accomplit ?
Le cas présenté dans cet article est fictif et ne décrit aucun système interne de BNP Paribas.