Modèles transparents et explicables

Un client demande pourquoi sa demande a été refusée. Un régulateur demande sur quelle base le modèle décide. Un ingénieur qui reprend le système demande à quoi il sert et où il est mauvais. Ces trois questions arrivent toujours, et un modèle qui affiche d'excellents chiffres n'y répond à aucune tant que personne n'a conçu les réponses.

Ce sujet couvre la tâche 4.2 du guide de l'examen. Il commence par la différence structurelle entre un modèle qu'on peut lire de l'intérieur et une boîte noire qu'il faut expliquer après coup, passe aux artefacts AWS qui consignent ce qu'un modèle est censé faire et ce qu'il vaut réellement, puis termine sur la question qui décide de tout : l'explication atteint-elle la personne qui doit agir, sous une forme utilisable ?

Ce que couvre ce sujet

• la distinction entre transparence, explicabilité et interprétabilité, et laquelle des trois ne figure pas dans les dimensions de l'IA responsable d'AWS
• la lecture directe d'une prédiction dans un modèle interprétable, sur un exemple chiffré, et pourquoi la même lecture est impossible dans un ensemble de 800 arbres
• l'attribution de variables SHAP dans SageMaker Clarify, les explications globales et locales, et le rôle du baseline comme question posée
• les deux compromis de la tâche 4.2 : interprétabilité contre performance, et transparence contre sûreté
• les SageMaker Model Cards, avec les usages prévus, le niveau de risque et le versionnage immuable
• les AWS AI Service Cards, les évaluations Amazon Bedrock, et la différence entre documenter et mesurer
• ce que poids ouverts, données ouvertes et licence permissive signifient séparément, avec le cas SageMaker JumpStart
• la conception centrée sur l'humain : adapter l'explication au public, divulguer l'usage de l'IA, capter les corrections des utilisateurs, garder une personne sur les décisions conséquentes

Pourquoi c'est important

Les questions de ce sujet décrivent généralement une situation et proposent quatre artefacts plausibles. Un comité de risques qui réclame une trace de validation, un client qui conteste une décision, une équipe qui compare deux modèles : chacune de ces demandes a une réponse AWS différente, et livrer la mauvaise ressemble à une esquive. Savoir qu'une model card porte l'intention, qu'une AI Service Card porte les limites, que Clarify porte les raisons d'une prédiction et que les évaluations Bedrock portent la comparaison est ce qui départage les bonnes réponses des distracteurs.

Sur le terrain, l'enjeu est plus direct. Les secteurs régulés exigent qu'une décision défavorable puisse s'expliquer à la personne concernée, et cette exigence se tranche au moment du choix de l'architecture, pas après la mise en production. Ce sujet vous donne les termes et les outils pour prendre cette décision au bon moment.