Accéder au contenu.
Menu Sympa

linux-31 - Re: IA... Après ChatGPT, voila HuggingChat...

Objet : Discussions sur le logiciel libre

Archives de la liste

Re: IA... Après ChatGPT, voila HuggingChat...


Chronologique Discussions  
  • From: Albert ARIBAUD <albert AT aribaud.net>
  • To: linux-31 AT culte.org
  • Subject: Re: IA... Après ChatGPT, voila HuggingChat...
  • Date: Tue, 02 Jan 2024 21:52:01 +0100

Le lundi 01 janvier 2024 à 21:11 +0100, Jean-Marc MONGRELET a écrit :
> Le 01/01/2024 20:52, Jean-Marc MONGRELET a écrit :
> >
> > Pourquoi s'en passer ??
> > Pourquoi refuser l'évolution, quand elle apporte une amélioration
> > ??

Ah mais dès que l' "IA" générative sera une évolution, je
l'accueillerai à bras ouverts.

> > De plus, souvent on-a pas l'humain sous la main, qui peut nous
> > apporter la bonne réponse! Et souvent on a accès à l'IA!

Avoir accès à un mauvais outil n'en fait pas un bon, et pour ma part
j'ai toujours trouvé des humains à qui poser mes questions techniques,
que ce soit par mail, par forum, par messagerie instantanée ou même
directement.

Tiens, un exemple parmi tant d'autres d'une "IA" qui fait perdre à
plusieurs personnes un temps qu'ils auraient certainement préféré
passer à traiter de *vrais* problèmes :

https://hackerone.com/reports/2298307

Résumé :

Quelqu'un a utilisé une "IA" écrire un rapport exposant un supposé
problème de sécurité dans le code source de curl.

(même si le lien ne le dit pas, je suis sûr qu'il a aussi utilisé l'
"IA" en question pour "trouver" le problème, et ne s'est pas arrêté une
seconde à vérifier la trouvaille)

Un développeur de curl a démontré dans une réponse argumentée que le
problème supposé n'existait pas, mais comme le rapport était creux, il
a invité le "rapporteur" à fournir plus de précision pour démontrer que
le problème existait bien.

Le "rapporteur" a continué à "répondre", c'est-à-dire copier les
réponses de l' "IA" tout aussi floues, généralistes et ignorantes des
questions posées, sans jamais prouver l'existence du problème allégué.

Le clou a été quand à la demande de donner l'extrait du code source de
curl qui posait problème, le "rapporteur" a fourni du code source...
qui n'existait pas dans curl (c'est typique d'un LLM).

Bilan : du temps perdu pour tout le monde, et encore, pas trop parce
qu'un des participants était dev et savait de quoi il parlait ; mais
quand un LLM répond à quelqu'un de peu expérimenté (et ce sont les plus
susceptibles de recourir aux LLM), ce quelqu'un ne verra pas les erreur
et ça lui retombera sur la figure plus tard, puissance dix, quand il
devra corriger des bugs pas forcément évidents dans un code qu'il
n'aura pas conçu.

Et ce n'est qu'une anecdote sur une multitude.

Amicalement,
Albert.



Archives gérées par MHonArc 2.6.19+.

Haut de le page