La difficulté, c'est de définir ce qu'est un raisonnement créatif pur. Il n'y a pas de définition formelle universelle. Mais je pense que pour l'usage couramment accepté de ce terme, que l'IA générative pourra se rapprocher suffisament de la créativité qu'il sera impossible de la distinguer de la créativité d'un humain, c'est même probablement déja le cas dans certains domaines. Croire que la créativité pourra être préservée est à mon avis une illusion.
Un exercice intéressant ce serait de mettre un système dans l'état des connaissances pré 1905 et voir si avec les données et connaissances de l'époque la machine peut retrouver ou imaginer des systèmes physiques qui ont été prédites grâce à la relativité restreinte, générale et mécanique quantique.
Pour cela il a fallu créer de nouveaux objets et concepts pour rendre compte des incohérences observées et qui ont été assez robustes pour prédire de nouvelles choses non mesurées à l'époque.
Pas évident, mais là on serait devant une preuve de créativité scientifique reproductible et claire. Il ne semble clairement pas possible à ce jour de faire ce genre de choses avec des LLMs. Peut être un jour. Et clairement si cela est effectué, ce serait un gap.
Après on peut utiliser n'importe quel cas analogue où la solution au problème n'est pas trivial et demande d'inventer plein de choses novatrices avec les connaissances sous la main. Que ce soit en physique, maths ou autre discipline.
Pas encore... Mais quand on voit les avancés obtenus avec les processus itératifs (ce qui est nommé « raisonnement »), et la conjonction avec des systèmes formels de preuves,
Je trouve que les processus itératifs tels qu'ils sont appliqués montrent justement rapidement leurs limites. C'est pas mal mais difficile de conclure si ça permettra d'aller aussi loin.
Je me demande si on n'est pas devant un phénomène de loi de Pareto : on obtient 80% d'un résultat spectaculaire avec 20% d'efforts, mais résoudre les difficultés résiduelles qu'on voit sera peut être très difficile, long et coûteux. Peut être pas, mais on a eu pas mal d'exemples dans le passé de technos ou prouesse qui semblait révolutionnaire et que la généralisation était qu'une question de mois et finalement pas du tout.
C'est difficile de prédire l'avenir sur ces questions en fait.
Alors quand je vois ce qu'elle est capable de faire avec des trucs plutôt réservés aux experts (genre faire du monkey patching pour aller modifier un objet d'une classe tierces et lui transformer ses descripteurs (des setters dans l'exemple)), je me dis qu'on est pas loin.
Est-ce vraiment ça de l'expertise Python ? J'ai vu des exemples plus probants, mais vu aussi des cas triviaux où ça ne fonctionnait pas par ailleurs. La résilience ce n'est pas encore ça.
Après, avec le fonctionnement actuel on aura a minima besoin d'experts pour la guider et la contrôler, mais à part ce cas d'usage, pour ma part
Ce n'est pas rien ni un détail.
De nombreux experts en fait font déjà plus ou moins ce travail. Ils ne passent pas leur temps à coder mais à diriger techniquement une équipe, à architecture la solution, à arbitrer entre coûts, fonctionnement, maintenance, faisabilité technique, à arbitrer entre des besoins ou désirs contradictoires, etc.
Et pour cela il faut comprendre le système, connaître les limitations techniques, les difficultés, avoir un minimum de bagage technique parfois dans différents domaines.
Alors peut être qu'un jour les LLMs feront ça sans soucis à partir des desirata d'un utilisateur ou d'un CEO mais ce n'est pas encore le cas en particulier pour des besoins et des systèmes complexes.
Moi mon problème c'est sur la formation de ces experts, qui le sont devenus en faisant les choses eux-mêmes, au cours du temps. Ce que j'ai peur, c'est que le vivier d'experts se tarisse, et qu'on n'arrive plus à renouveller la population d'experts, justement à cause de l'IA générative.
C'est un risque que je partage, il y a également le risque de la monoculture. Avoir plusieurs personnes qui participent à un projet, avec des expertises, des horizons, des cultures, des origines, des besoins, etc. d'origines différentes cela permet aussi de donner des points de vue et des reculs différents. Cela permet de discuter des fonctionnalités (est-ce vraiment pertinent ? On ne peut pas faire mieux que ça ?), de prendre en compte des critères qu'on n'avait pas pensé à la base, ou de proposer des solutions nouvelles.
Si tout repose sur un LLM avec un codeur et un manageur, le risque de monoculture devient plus importante et finalement d'avoir des résultats moins bons qu'en impliquant plus de personnes dans la conception.
D'ailleurs ce problème est par exemple très visible dans des entreprises qui ont une équipe non renouvelée depuis très longtemps et qui ne se maintient pas à jour techniquement. "On a a toujours fait comme ça", "les tests unitaires c'est quoi ?", "les gestionnaires de versions c'est un dépôt FTP avec des archives", etc.
[^] # Re: Inédit pour les métiers qualifiés
Posté par Renault (site web personnel) . En réponse au journal Coder avec l'IA : le déclin du plaisir. Évalué à 4.
Un exercice intéressant ce serait de mettre un système dans l'état des connaissances pré 1905 et voir si avec les données et connaissances de l'époque la machine peut retrouver ou imaginer des systèmes physiques qui ont été prédites grâce à la relativité restreinte, générale et mécanique quantique.
Pour cela il a fallu créer de nouveaux objets et concepts pour rendre compte des incohérences observées et qui ont été assez robustes pour prédire de nouvelles choses non mesurées à l'époque.
Pas évident, mais là on serait devant une preuve de créativité scientifique reproductible et claire. Il ne semble clairement pas possible à ce jour de faire ce genre de choses avec des LLMs. Peut être un jour. Et clairement si cela est effectué, ce serait un gap.
Après on peut utiliser n'importe quel cas analogue où la solution au problème n'est pas trivial et demande d'inventer plein de choses novatrices avec les connaissances sous la main. Que ce soit en physique, maths ou autre discipline.
Je trouve que les processus itératifs tels qu'ils sont appliqués montrent justement rapidement leurs limites. C'est pas mal mais difficile de conclure si ça permettra d'aller aussi loin.
Je me demande si on n'est pas devant un phénomène de loi de Pareto : on obtient 80% d'un résultat spectaculaire avec 20% d'efforts, mais résoudre les difficultés résiduelles qu'on voit sera peut être très difficile, long et coûteux. Peut être pas, mais on a eu pas mal d'exemples dans le passé de technos ou prouesse qui semblait révolutionnaire et que la généralisation était qu'une question de mois et finalement pas du tout.
C'est difficile de prédire l'avenir sur ces questions en fait.
Est-ce vraiment ça de l'expertise Python ? J'ai vu des exemples plus probants, mais vu aussi des cas triviaux où ça ne fonctionnait pas par ailleurs. La résilience ce n'est pas encore ça.
Ce n'est pas rien ni un détail.
De nombreux experts en fait font déjà plus ou moins ce travail. Ils ne passent pas leur temps à coder mais à diriger techniquement une équipe, à architecture la solution, à arbitrer entre coûts, fonctionnement, maintenance, faisabilité technique, à arbitrer entre des besoins ou désirs contradictoires, etc.
Et pour cela il faut comprendre le système, connaître les limitations techniques, les difficultés, avoir un minimum de bagage technique parfois dans différents domaines.
Alors peut être qu'un jour les LLMs feront ça sans soucis à partir des desirata d'un utilisateur ou d'un CEO mais ce n'est pas encore le cas en particulier pour des besoins et des systèmes complexes.
C'est un risque que je partage, il y a également le risque de la monoculture. Avoir plusieurs personnes qui participent à un projet, avec des expertises, des horizons, des cultures, des origines, des besoins, etc. d'origines différentes cela permet aussi de donner des points de vue et des reculs différents. Cela permet de discuter des fonctionnalités (est-ce vraiment pertinent ? On ne peut pas faire mieux que ça ?), de prendre en compte des critères qu'on n'avait pas pensé à la base, ou de proposer des solutions nouvelles.
Si tout repose sur un LLM avec un codeur et un manageur, le risque de monoculture devient plus importante et finalement d'avoir des résultats moins bons qu'en impliquant plus de personnes dans la conception.
D'ailleurs ce problème est par exemple très visible dans des entreprises qui ont une équipe non renouvelée depuis très longtemps et qui ne se maintient pas à jour techniquement. "On a a toujours fait comme ça", "les tests unitaires c'est quoi ?", "les gestionnaires de versions c'est un dépôt FTP avec des archives", etc.