Re: Merci

Je ne vois pas en quoi ce que tu dis répond à ce que je mets en avant.

Peu importe comment on les évalue, la réalité aujourd'hui c'est que beaucoup de choses à leur sujet sont réellement inconnus concernant leurs capacités réelles et leurs faiblesses (qui sont différentes de celles des humains donc la transposition avec un employé humain sera forcément délicat dans ce contexte).

Il n'y a globalement avant une mise à disposition que des évaluations internes, et par ailleurs il semble que les éditeurs n'ont pas de grands scrupules à dire "on n'arrive pas à évaluer plus, ou nos tests ne sont pas très efficaces, osef on délivre quand même". Quelque soit l'angle pour approcher la problématique, ce n'est pas sain du tout.

Ensuite il y a des différences entre l'IA et les humains qu'il faut prendre en compte aussi pour considérer que non, ce n'est pas la même chose et qu'on ne peut pas traiter cela de la même façon.

Déjà un humain est un être vivant qui a des droits et devoirs et la société est bâti autour de l'humain depuis... la naissance de l'Humanité. On ne peut pas limiter arbitrairement des humains dans leurs actions sans une justification forte. Sinon on arrive au type de raisonnements absurde de Sam Altman "les IA consomment moins d'énergie pour être élevé qu'une IA", merci, mais l'objectif c'est aussi de vivre en tant qu'espèce, l'objectif n'est pas de vivre sur une planète remplie de robots à notre place.

Il y a une question de responsabilités. Si demain je fais n'importe quoi au boulot, je serais responsable et je pourrais être condamné pour ça. Si une IA cause des dommages importants, qui l'est ? L'utilisateur de l'IA ? L'éditeur de l'IA ? L'IA elle même ? C'est toujours un sujet assez flou et c'est d'ailleurs un soucis pour établir des contrats d'assurances adaptés car comme les risques sont mal connus / évalués et que le domaine bouge vite, c'est difficile de s'assurer proprement contre ces dits risques.

Les modèles sont aussi relativement peu nombreux à un certain niveau de compétence. Cela signifie qu'une faille ou un bogue quelconque qui touche un modèle peut impacter des millions / milliards de personne d'un coup. La diversité humaine ici a ça de bon, ça implique une redondance et des gardes fous pour éviter des dérives.

Les IA peuvent agir numériquement dans l'ombre et très rapidement à grande échelle, peu d'humains ont une capacité potentielle de nuisance à une si large échelle.

Enfin la nature des erreurs sont différentes, on a l'habitude des problèmes avec les humains dans la vraie vie ou au travail. On a beaucoup de retours sur les bonnes et mauvaises pratiques pour éviter ces risques. Les problèmes liés aux IA sont de nature différente et mal connus donc on ne peut pas transposer les mêmes techniques telles quelles en particulier quand l'utilisateur de l'IA peut être également très mal informé de la question.

Si ton logiciel est trop complexe pour être évalué comme un logiciel (par exemple, comme un logiciel certifié dans l'embarqué), parce que, typiquement, l'examen du code ou du binaire ne t'apprend rien sur la manière dont il fonctionne, alors il va falloir l'évaluer autrement, avec d'autres méthodes et d'autres procédures, et il fa falloir gérer d'autres types de risques.

Tu n'as manifestement jamais travaillé dans un contexte de certifications.

Dans l'aéronautique par exemple, on évalue évidemment le code et la documentation et pas uniquement le comportement final.

Tout d'abord on évalue la criticité du système pour définir des règles applicables. Plus le logiciel est critique, plus les règles seront lourdes ce qui limitera forcément la complexité du projet sinon ce sera trop cher ou risqué. Et à un certain niveau on peut même aboutir à avoir besoin de deux implémentations indépendantes pour éviter que une erreur non détectée sur l'un a des conséquences néfastes (car la probabilité d'avoir deux problèmes identiques qui ont passé les mailles du filet sont faibles).

Les règles s'appliquent à toutes les étapes de la chaine, par exemple la conception même, la documentation, le code et les tests. Tu peux aboutir à une situation où allouer dynamiquement de la mémoire est typiquement interdit et cela est évidemment vérifié.

Ensuite tout est tracé et documenté. Il y a un lien entre cahier des charges -> cahier de conception -> bout de code -> tests. Cela permet de s'assurer que l'ensemble des demandes sont remplies et qu'il n'y a pas d'oublis. Et ces documents sont normalement, relus, évalués et approuvés et pas uniquement par celui qui a codé le logiciel évidemment.

Bien sûr les tests permettent de vérifier en interne comme en externe que le code agit comme voulu mais ce n'est pas le seul aspect qui fait que globalement voler dans un avion est sûr.

On n'a évidemment rien de tout cela concernant les IA, de près comme de loin. Et c'est regrettable (et irresponsable).