#opg $OPG
Je jugeais l’IA vérifiable avec une règle paresseuse :
La preuve la plus forte doit être la meilleure preuve.
Puis j’ai observé comment @OpenGradient gère différents types de charge, et je me suis rendu compte que cette règle rendrait l’IA presque inutilisable.
Une conversation normale sur chat.opengradient.ai nécessite de la confidentialité, une preuve que le code approuvé a bien traité la requête, et une réponse assez rapide pour donner l’impression de discuter comme sur du chat. Un TEE convient à ce travail, car il fournit une attestation adossée au matériel sans forcer l’utilisateur à attendre une génération de preuve lourde.
ZKML résout un problème plus difficile.
Il peut prouver mathématiquement qu’un modèle donné a produit un résultat donné. Ce niveau de certitude est logique lorsque la sortie d’un ML pourrait déclencher une liquidation, déplacer des fonds ou modifier une décision on-chain.
Mais générer cette preuve peut coûter des milliers de fois plus en calcul.
Mettre ZKML derrière chaque phrase d’un LLM et l’assistant « sécurisé » devient une salle d’attente coûteuse.
Il y a aussi les signatures. Elles peuvent montrer quel nœud a renvoyé une sortie et si elle a été modifiée, mais elles ne prouvent pas que l’exécution elle-même était correcte. Cela peut néanmoins suffire pour des expériences ou des tâches à faible risque.
Ce qui m’a fait « cliquer », c’est que ce ne sont pas des versions plus fortes et plus faibles du même outil.
Ils protègent contre des défaillances différentes.
Le point fort d’OpenGradient est de permettre à la vérification de correspondre à la conséquence de la réponse — même lorsque l’on mélange des méthodes, quand un workflow contient différents niveaux de risque.
La question n’est pas : « Pourquoi n’utilise-t-on pas tout la preuve la plus forte ? »
C’est : « Qu’est-ce qui serait réellement perdu si cette réponse précise était fausse ? »
Pour moi, c’est une base bien plus pratique pour $OPG .
Je jugeais l’IA vérifiable avec une règle paresseuse :
La preuve la plus forte doit être la meilleure preuve.
Puis j’ai observé comment @OpenGradient gère différents types de charge, et je me suis rendu compte que cette règle rendrait l’IA presque inutilisable.
Une conversation normale sur chat.opengradient.ai nécessite de la confidentialité, une preuve que le code approuvé a bien traité la requête, et une réponse assez rapide pour donner l’impression de discuter comme sur du chat. Un TEE convient à ce travail, car il fournit une attestation adossée au matériel sans forcer l’utilisateur à attendre une génération de preuve lourde.
ZKML résout un problème plus difficile.
Il peut prouver mathématiquement qu’un modèle donné a produit un résultat donné. Ce niveau de certitude est logique lorsque la sortie d’un ML pourrait déclencher une liquidation, déplacer des fonds ou modifier une décision on-chain.
Mais générer cette preuve peut coûter des milliers de fois plus en calcul.
Mettre ZKML derrière chaque phrase d’un LLM et l’assistant « sécurisé » devient une salle d’attente coûteuse.
Il y a aussi les signatures. Elles peuvent montrer quel nœud a renvoyé une sortie et si elle a été modifiée, mais elles ne prouvent pas que l’exécution elle-même était correcte. Cela peut néanmoins suffire pour des expériences ou des tâches à faible risque.
Ce qui m’a fait « cliquer », c’est que ce ne sont pas des versions plus fortes et plus faibles du même outil.
Ils protègent contre des défaillances différentes.
Le point fort d’OpenGradient est de permettre à la vérification de correspondre à la conséquence de la réponse — même lorsque l’on mélange des méthodes, quand un workflow contient différents niveaux de risque.
La question n’est pas : « Pourquoi n’utilise-t-on pas tout la preuve la plus forte ? »
C’est : « Qu’est-ce qui serait réellement perdu si cette réponse précise était fausse ? »
Pour moi, c’est une base bien plus pratique pour $OPG .