Quand tu interagis par une API avec un système informatique, l’API indique précisément ce que le système peut faire, quelles sont les entrées valides, à quoi le système va répondre, etc. Quand tu fais un serveur web, tu reçois du texte (essentiellement) avec deux grosses instructions (POST et GET), et il y a un protocole précis d’échange.
Dans certaines situations, on peut proposer dans une API un mécanisme de scripts au sens large qui fait que le serveur va exécuter du code plus ou moins arbitraire pour toi. Typiquement, un serveur pourrait prendre du code python, l’exécuter chez lui, puis te renvoyer le résultat. C’est en ça que je parle de sortir de son domaine.
On sait comment faire ça sans casser le serveur, ça passe par la création de bac à sable (sandboxing), généralement à partir de machines virtuelles, de manière à complètement isoler l’exécution du code que tu envois du reste du serveur. C’est très coûteux en ressources et c’est très lent si on veut que cela soit sur (au démarrage). Intégrer ce genre de fonctionnalité dans une version de chatGPT ne pose pas de problème technique (tu peux faire ça sur github avec les actions, par exemple), mais ce n’est pas une fonctionnalité proposée par openAI pour des raisons évidentes (coût et lenteur).
Aucune autre solution n’est sure (sans sandboxing ou l’équivalent) et aucune n’est bien sûr intégrée dans chatGPT vu le danger que cela représente. Quant à l’inclusion partielle d’accès à des API spécifiques de python, c’est plus ou moins pareil, ça demande des ressources importantes ou c’est trop dangereux.
Edit : et donc si, c’est une fonctionnalité proposée par OpenAI, merci @Fabrice
Plus ou moins. C’est quand on découpe Bilbo le Hobbit en Bi-l-bo- -le- -Hobbit (découpage fait au hasard). Une fois que c’est fait, le réseau de neurones va voir seulement 1-2-3-4-5-4-6 (avec l’espace codé par 4, par exemple) sans avoir aucune idée de ce qui se cache derrière 4 ou 5. Lors de l’apprentissage, il se fait une idée d’une « sémantique » à associé à chaque token (donc 1, 2, etc.) pour prédire correctement l’enchaînement des tokens. Par exemple ici se dire qu’après 4 (le) il y a souvent 5 (donc l’espace).
Parser un texte contenant des opérations mathématiques et résoudre les opérations, ce n’est pas exécuter du code arbitraire, sauf si tu t’amuses à faire un exec directement sur le texte. Donc disposer d’une telle API dans une interface de discussion avec un utilsateur est tout à fait possible sans utiliser de mécanisme d’isolation
Oui, on est d’accord. Mais ce n’est pas ce qui est évoqué au dessus. En fait le problème est qu’en discutant avec ChatGPT, on obtient des résultats tellement étranges qu’on ne sait plus trop ce qu’il fait. Je viens de lui faire calculer 25! de façon correcte en lui demandant de « simuler » l’exécution d’un code python. Sur du code simple il donne l’impression de le faire mais il fait n’importe quoi sur du code complexe.
Donc pour conclure le fait de pouvoir exécuter du code python pour pouvoir (par exemple) faire résoudre une multiplication à chatgpt, c’est possible grâce au plugin CodeInterpreter de chatGpt.
Il suffit de créer la méthode python qui va bien, et de d’indiquer à chatgpt quelle méthode appeler pour obtenir un résultat à un problème.
C’est le principe de mise en œuvre des « Agent ». Y’a des infos par ici, pour ceux capable de comprendre tout ca (je n’en fait pas partie ). Il parait que c’est intéressant
Pour ceux qui ne connaissent pas les plugins, c’est présenté ici : ChatGPT plugins
Comme je l’écrivais :
We provide our models with a working Python interpreter in a sandboxed, firewalled execution environment, along with some ephemeral disk space. Code run by our interpreter plugin is evaluated in a persistent session that is alive for the duration of a chat conversation (with an upper-bound timeout) and subsequent calls can build on top of each other. We support uploading files to the current conversation workspace and downloading the results of your work.
Mais je ne savais pas que c’était déjà disponible ! Merci !
Alors ça n’a peut être pas d’importance ici en effet, mais par contre je maintiens que le python est un langage fortement typé (dynamique certes, mais fortement typé quand même )
Les données sont fortement typées, mais les variables ne sont pas typées, vu qu’elles peuvent changer de type au cours de l’exécution. Ce n’est pas pour rien que l’utilisation du module typing est encouragée afin d’éviter ce changement de type.
Je sais bien que dans la communauté python on aime choisir la définition de typage fort qui permet de dire que c’est le cas pour ce langage et j’aurais du être plus précis. Donc python attribue bien un type à chaque objet ce qui limite certaines erreurs à l’exécution. Mais en python classique, il n’y a pas de typage statique et donc une impossibilité de détecter des erreurs sans exécuter le programme (oui, je sais, on peut utiliser un analyseur statique, mais c’est très limité par rapport à ce que propose un langage à typage fort statique comme Kotlin). D’autre part, il n’y a pas vraiment d’interface et donc même si des types sont associés aux objets, ils ne sont pas testés de façon forte comme pour d’autres langages. Globalement, le système de types de python est donc faible, il ne sert que pour éviter les erreurs grossières, pas comme outils puissants de contrôle et de compilation, par rapport à ce qui se fait en C++, Kotlin, Scala, etc.
Edit : python reste un vieux langage conçu il y a plus de trente ans, on fait tellement mieux depuis…
Et je suis passé de quelque chose que je comprenais à quelque chose que je ne comprends plus, mais où je me retrouve quand même à lire (pas tous les messages, j’avoue)
Oui et d’ailleurs, je voulais réagir sur ce point : dire que Python est typé·e n’est-ce-pas renier à Python sa liberté de choisir le type dont iel veut se réclamer ?
C’est des choses qui arrivent sur tous les forums les topics qui dérivent… Mais ici ce qui est beau c’est que rien n’est (vraiment) jeté à la poubelle.
). Il parait que c’est intéressant
)
