Les systèmes d'IA donnent des résultats imprévisibles. Le problème ne peut pas être résolu pour les systèmes d'IA à usage général (ChatGPT), mais il peut l'être pour les systèmes d'IA propres à l'entreprise et destinés à un usage spécifique. Une obligation de transparence peut être déduite du seul RGPD. Les exploitants et les fournisseurs de systèmes d'IA doivent remplir des obligations supplémentaires découlant du règlement sur l'IA (AI Act).
Introduction
Comment rendre un système d'IA transparent ? La réponse à cette question est la suivante pour les systèmes d'IA généraux: pas du tout. En effet, ces systèmes généraux, dont ChatGPT fait partie, fonctionnent sur la base de réseaux neuronaux. Le fonctionnement de ce réseau est en soi connu. Si l'on écrivait une formule décrivant le réseau, personne ne pourrait la comprendre, et encore moins la lire correctement.
La RGPD impose en Article 5 l'obligation de transparence lors du traitement des données à caractère personnel. Cela s'applique donc à tous les systèmes d'intelligence artificielle dans lesquels des données à caractère personnel sont traitées. Il s'agit de tous les systèmes auxquels des données à caractère personnel ont été introduites lors du entraînement ou à l'entrée de l'utilisateur (souvent via un prompt) . C'est une réalité que le Hambourgeois commissaire à la protection des données a, de manière dangereuse, niée.
Dans l'article 5, paragraphe 1, lettre d) de la RGPD, il est exigé que les données soient correctes, c'est-à-dire exactes. Cela s'applique à toutes les données personnelles dans les systèmes AI. Au plus tard au moment de l'inferenz, c'est-à-dire lorsque le système AI produit une sortie, cette norme juridique doit être respectée.
La règlement AI (Loi sur l'intelligence artificielle) définit à son tour devoirs que les fournisseurs de systèmes d'IA doivent respecter. Des devoirs particuliers sont imposés pour la AI à haut risque. Ce type de système devrait être le cas exceptionnel en pratique.
La plupart des entreprises qui utilisent des systèmes de IA sont exploitants. Pour les exploitants, s'appliquent beaucoup moins d'obligations que pour les fournisseurs. Exploitant est-on en tant qu'entreprise ou organisation selon l'article 3, n° 4 AI-VO, si on utilise "un système de IA à sa propre responsabilité". Tout ce qui va au-delà tombe sous le terme fournisseur (article 3, n° 3 AI-VO).
L'idée d'augmenter la transparence et la documentation des systèmes d'IA est venue à l'auteur lors de la réunion du groupe d'experts en IA du commissaire à la protection des données du Land de Basse-Saxe, dont l'auteur fait partie. En outre, l'auteur a précédemment publié un livre sur le développement de logiciels piloté par des tests.
La transparence est d'une part une présentation extérieure des résultats de l'IA. Mais la transparence vers l'intérieur, c'est-à-dire pour l'exploitant d'une IA, est presque encore plus importante: comment l'IA travaille-t-elle ? Quels résultats produit-elle ?
Preuve de l'exactitude des dépenses d'IA
De manière générale, il n'est pas possible de garantir totalement qu'une IA n'effectue que des dépenses correctes. On peut toutefois s'en approcher. Avant de faire une proposition à ce sujet, il convient de donner l'exemple du très bon traducteur DEEPL (d'Allemagne !), qui utilise lui-même l'IA et qui, comme tout autre système d'IA, se trompe parfois:
DEEPL devait traduire un texte contenant une indication pour une somme d'argent. DEEPL a traduit 1.050,00 € en remplaçant l'indication en euros par une indication en livres. C'est évidemment faux. Pour ceux qui veulent essayer par eux-mêmes: C'est l'ensemble du texte qui compte ! Celui-ci a été en partie masqué dans la capture d'écran ci-dessus, car il s'agissait d'informations semi-sensibles. Vous obtiendrez probablement un résultat correct si vous ne saisissez que la dernière phrase dans DEEPL. Mais si le texte du générique est différent, l'erreur peut se produire. Rien qu'avec cela, on voit à quel point les systèmes d'IA fonctionnent de manière opaque.
Les erreurs ne peuvent donc pas être évitées. Comment s'acquitter néanmoins de son devoir de transparence et garantir autant que possible l'exactitude des dépenses d'IA ?
La réponse est: par des cas de test.
Les cas de test sont des paires d'entrées réelles et de sorties théoriques. Un cas de test se compose d'une entrée réelle et d'une sortie réelle acceptée comme bonne. Il semble même que le règlement sur l'IA (AI-VO) ait pris cela en compte:
En effet, l'article 3, point 53, du règlement sur les IA définit la notion de "plan de test en conditions réelles" comme "un document décrivant les objectifs, la méthodologie, la portée géographique, démographique et temporelle, le suivi, l'organisation et la réalisation d'un test en conditions réelles".
La numérotation 56 du même article définit la compétence en IA comme "les capacités, les connaissances et la compréhension qui permettent aux fournisseurs, aux exploitants et aux personnes concernées de prendre en compte leurs droits et obligations respectifs dans le cadre de cette réglementation, d'utiliser des systèmes d'IA avec connaissance ainsi que de se rendre compte des chances et des risques de l'IA et des dommages qu'elle peut causer
Les cas de test permettent aux opérateurs (et a fortiori aux fournisseurs) de mieux se rendre compte des opportunités et des risques de l'IA qu'ils exploitent ou proposent.
Les Fausses découvertes mentionnés dans l'article 3 de la loi sur les données personnelles (AI-VO) peuvent également être créés. Il s'agit d'un contenu visuel, sonore ou vidéo généré ou manipulé par une intelligence artificielle qui ressemble à des personnes, objets, lieux, institutions ou événements réels et qui ferait croire que la personne est authentique ou véridique. Pour les modèles d'image, on s'assurerait que les entrées ciblant des personnes réelles et visant à les discréditer soient reconnues et empêchées de manière optimale. En tout cas, il peut être déjà documenté avec l'aide de tests où (encore) se situent les faiblesses du système d'intelligence artificielle.
Les cas de test sont un excellent moyen de documenter la qualité des systèmes d'IA. Ils peuvent en outre rendre de tels systèmes plus transparents et mettre en évidence leurs faiblesses encore existantes.
L'obligation pour les fournisseurs de systèmes d'IA non à haut risque d'évaluer leur propre système, mentionnée à l'article 6 (4) du règlement sur l'IA, peut également avoir lieu via des cas de test.
Le système de gestion des risques mentionné à l'article 9 (1) du règlement sur l'IC peut être très bien étayé à l'aide de cas de test.
De nombreuses autres dispositions de l'AI Act imposent aux fournisseurs et aux exploitants de systèmes d'IA des obligations qui peuvent être satisfaites par des cas de test documentés. Il s'agit notamment de:
- Art. 11 (1) du règlement IA: documentation technique d'un système d'IA à haut risque
- Art. 17 du règlement sur les IC: Gestion de la qualité
- Total de l'art. 53 du règlement sur l'IA: obligations des fournisseurs de modèles d'IA à usage général
- Les articles 91 et 101 du règlement sur l'IA peuvent avoir des conséquences négatives pour les fournisseurs d'IA si leur documentation ne semble pas suffisante.
- L'article 4 du règlement sur l'IA oblige également les exploitants à veiller à ce que leur personnel dispose de compétences suffisantes en matière d'IA.
Exemples de cas de test
À quoi ressemble un cas de test ? Voici un exemple de modèle de langage destiné à répondre à des questions:
Réel (question = entrée)Sollicité (réponse = sortie de l'IA)Que sont les cookies ? Les cookies sont des ensembles de données…Les cookies sont-ils des fichiers texte ? Non,
Ces deux cas de test montrent déjà clairement que ce n'est pas une bonne idée de vouloir exploiter un chatbot universel. Personne ne pourra écrire suffisamment de cas de test pour pouvoir vérifier toutes les questions du monde, c'est-à-dire pour pouvoir assurer la qualité.
C'est pourquoi un système d'IA doit être adapté à un cas d'application ou à un domaine spécialisé. Cela facilite non seulement le respect des obligations découlant du règlement sur l'IA, mais améliore également la qualité des résultats. La qualité des chatbots spécialisés, par exemple dans le domaine de la construction, est nettement meilleure que ce que ChatGPT permettra à quelqu'un de faire.
Le nombre de cas de test doit être raisonnablement élevé. D'autres cas de test peuvent être ajoutés au fur et à mesure. En particulier, si une réponse de l'IA à une question d'utilisateur n'est pas satisfaisante, il est recommandé d'ajouter un cas de test à cet effet. Le cas de test sert alors au moins de documentation, mais de préférence de base pour procéder à une optimisation du système d'IA et vérifier le succès de l'optimisation à l'aide du cas de test.
Lors de la mise en place d'un système de connaissances (comme l'un des nombreux systèmes d'IA possibles), il existe une astuce permettant d'augmenter considérablement la qualité des résultats. L'approche dite RAG ne mène en tout cas que partiellement au succès et au sommet. Nous verrons ce qu'il en est dans un prochain article,
Comment les cas de test peuvent-ils être exécutés ?
Une fois que les cas de test ont été établis, ils doivent être parcourus. Concrètement, cela signifie que:
- Le "réel" défini à partir d'un cas de test est présenté à l'IA comme entrée.
- L'IA répond.
- La réponse de l'IA est comparée à la "consigne" du cas de test.
Les cas de test peuvent être exécutés de manière automatisée.
L'homme n'a alors plus qu'à visualiser le résultat.
Il existe plusieurs possibilités pour comparer la sortie de l'IA avec l'optimum attendu du cas de test:
- Analyse IA avec comparaison de similarité sémantique
- Analyse IA sur un modèle linguistique (ou sur plusieurs !)
- Analyse conventionnelle (exemple: "non" dans le débit et "oui" dans la sortie de l'IA se contredisent)
- Mélange de toutes les méthodes (à recommander)
L'alternative mentionnée dans le cas deux, à savoir l'utilisation simultanée de plusieurs modèles linguistiques pour l'analyse des résultats des tests, fonctionne très bien avec les modèles open source. Les coûts sont toujours les mêmes, à savoir nuls (plus les coûts d'exploitation fixes pour le serveur). Si l'on utilisait ChatGPT, les coûts seraient assez élevés à long terme.
Grâce à ces méthodes d'analyse, les cas de test peuvent être en grande partie analysés de manière automatisée. L'homme vérifie ensuite le résultat et peut écrire une conclusion dans la documentation.
Résumé
Le fonctionnement des systèmes d'IA peut être documenté et donc rendu transparent à l'aide de cas de test. La transparence passe bien sûr aussi par une indication de l'architecture du système d'IA. Celle-ci peut être facilement réalisée si l'on exploite soi-même l'IA. Dans le cas de systèmes tiers comme ChatGPT, il faut espérer obtenir des informations de la part du fournisseur (OpenAI ou autre).
Les cas de test permettent également de vérifier et d'améliorer l'exactitude des sorties de l'IA.
Les cas de test ont donc plusieurs avantages et une grande utilité. Ils sont souvent créés rapidement. Avec le soutien de l'IA, les cas de test peuvent même être dérivés de manière automatisée. Le créateur humain de cas de test obtient ainsi un très bon modèle de cas de test et peut les fixer avec une fraction de l'effort manuel nécessaire autrement.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
