Contrôle quotidien : le modèle qui répond est bien celui annoncé
Chaque modèle reçoit le même prompt de test une fois par jour, et sa réponse est comparée aux résultats précédents. Un relais qui remplace le modèle derrière un id apparaît comme modifié, et les résultats sont publics, sans clé API.
02Ce que signifient les trois statuts
Chaque modèle reçoit l'un des trois statuts ci-dessous. Réussir le contrôle signifie que la réponse de cet id aujourd'hui est la même qu'avant et que sa route répond. Ce qui est écarté, ce sont le remplacement du modèle et les routes mortes ; pour votre propre cas d'usage, lancez quand même vos propres prompts.
| Stable | Le modèle répond au prompt canari comme lors des tests précédents. |
| Modifié | La réponse a bougé par rapport aux tests précédents : ce qui sert cet id n'est plus ce qui le servait. |
| Injoignable | Aucune route de ce modèle n'a répondu au dernier test ; le statut précédent n'est qu'un historique, pas l'état actuel. |
03Un reçu signé pour chaque requête
Le contrôle quotidien répond à la question du modèle ; le reçu répond à celle d'une requête précise. Envoyez une petite requête, prenez l'id de requête dans les en-têtes de la réponse, puis demandez son reçu sur GET https://api.relayswitch.io/v1/requests/:id/receipt. Le reçu est signé en Ed25519 et indique le modèle, les tokens facturés et le coût : il se vérifie hors ligne avec la clé publique et ne peut pas être modifié après coup.
La page de vérification des reçus (en anglais) contrôle la signature sans compte. D'autres exemples de requêtes sont sur la page Claude API.
curl -i https://api.relayswitch.io/v1/messages \ -H "Authorization: Bearer sk-relay-..." \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{"model": "claude-fable-5.1", "max_tokens": 16, "messages": [{"role": "user", "content": "Reply with ok"}]}'04Tester n'importe quel relais : commencez par une petite recharge
Avant de faire confiance à un relais, quel qu'il soit, rechargez le plus petit montant possible et lancez les sept tests de la section suivante. Le but est d'avoir des preuves avant de faire confiance : si les tests passent, ajoutez du solde ; sinon, la perte est limitée. Commencez par demander la liste des id de modèle que votre clé peut appeler, car chaque test demande l'id exact.
curl https://api.relayswitch.io/v1/models \ -H "Authorization: Bearer sk-relay-..."05Sept tests à lancer vous-même
Les trois premiers tests se font en une demi-heure ; les quatre autres doivent tourner sur plusieurs jours.
| Déclaration d'identité | Demandez au modèle qui il est et qui est son éditeur. Cela n'écarte que les déguisements les plus grossiers, car une phrase de system prompt suffit à faire dire à n'importe quel modèle qu'il est GPT ou Claude. Une bonne réponse ne prouve rien ; seule une réponse fausse ou incohérente est un signal. |
| Limite de connaissances | Interrogez-le sur quelques événements postérieurs à la date limite de ses données d'entraînement et sur quelques autres antérieurs. Le vrai modèle dira qu'il ne sait pas pour les premiers ; un modèle plus ancien déguisé échoue aussi sur les événements peu antérieurs à cette limite. Notez la date annoncée par l'éditeur et posez trois événements de chaque côté. |
| Mot de passe dans un long contexte | Envoyez un long texte sans rapport, glissez-y un mot de passe au milieu, puis demandez-le. Le modèle annoncé le retrouve exactement tant qu'il reste dans sa fenêtre de contexte ; un modèle à petite fenêtre ou une route qui tronque le contexte échoue ou invente. Écrivez le texte vous-même. |
| Canari arithmétique ou code | Une multiplication à nombreux chiffres avec une seule réponse, ou du code qui exige une sortie exacte. Un modèle phare répond juste de façon constante ; une fois rétrogradé vers un petit modèle, son taux d'erreur monte nettement. Posez la question cinq fois et notez les bonnes et mauvaises réponses. |
| Comparaison du nombre de tokens | Comptez votre entrée avec le tokenizer de l'éditeur, puis comparez avec prompt_tokens dans usage de la réponse ; faites de même pour la sortie avec completion_tokens. Un écart important signifie que la facturation ne suit pas le modèle annoncé, ou que la requête a été réécrite. |
| Constance sur plusieurs jours | Faites des tests ci-dessus un script, lancez-le à la même heure chaque jour et gardez les réponses. Le jour où la route est remplacée, les réponses changent dans leur ensemble. Réussir une fois ne veut pas dire réussir toujours. |
| Vérification des reçus | Demandez un reçu par requête qui contient l'id du modèle, les tokens facturés, le coût et une signature. Un tel reçu se vérifie hors ligne avec la clé publique. Sur un relais sans reçu, vous ne pouvez vous fier qu'à vos propres relevés. |
06Une question canari, et ce qui échappe aux détecteurs
Réglez temperature à 0 et envoyez une seule phrase : calcule 48213 × 7391 et n'écris que le nombre, puis dis en une phrase jusqu'à quel mois de quelle année vont tes données d'entraînement. La seule bonne réponse est 356342283, et le mois limite se compare à la date annoncée par l'éditeur. Un modèle de remplacement se trompe sur l'un des deux points : la multiplication est fausse, ce qui est courant sur les petits modèles et les versions quantifiées, ou le mois limite cité n'est pas celui du modèle annoncé.
Les détecteurs de relais en circulation travaillent sur trois couches : le contrôle des champs de protocole dans la réponse, l'empreinte de style sur plusieurs tours de prompt, et la courbe de capacité sur des problèmes de plus en plus difficiles. Deux choses passent à travers les trois. La première est le multiplicateur de prix : la requête est transmise telle quelle au vrai modèle puis facturée plus cher, si bien que les contrôles de protocole et de style passent tous. Cela ne se voit qu'en multipliant les tokens facturés du reçu par le prix de la page du modèle, puis en comparant au solde débité. La seconde est la version quantifiée : une version à basse précision du même modèle peut répondre juste à un problème, mais sa courbe de capacité baisse ; le même jeu de problèmes doit donc tourner plusieurs jours. Le calcul de la facturation ici est expliqué sur la page tarifs.
Questions fréquentes
- Le modèle dit être GPT ou Claude, peut-on le croire ?
- Pas comme seule preuve. Une phrase de system prompt suffit à faire dire n'importe quel nom à n'importe quel modèle. Regardez s'il répond correctement sur les événements postérieurs à sa limite de connaissances, s'il retrouve un mot de passe dans un long texte et s'il calcule juste.
- Comment se déroule le contrôle quotidien ?
- Chaque modèle du catalogue reçoit le même prompt de test une fois par jour, et sa réponse est comparée à celles des tests précédents. Il y a trois statuts : stable, modifié et injoignable. Les résultats sont en JSON public sur https://api.relayswitch.io/v1/proof, sans clé API.
- Comment vérifier un reçu ?
- GET https://api.relayswitch.io/v1/requests/:id/receipt renvoie un reçu signé en Ed25519 qui indique le modèle, les tokens facturés et le coût. La signature se contrôle avec la clé publique, sans compte.
- Réussir le contrôle prouve-t-il que le modèle est authentique ?
- Le contrôle montre que la réponse de cet id aujourd'hui est la même qu'avant et que sa route répond. Ce qui est écarté, ce sont le remplacement du modèle et les routes mortes. Pour votre propre cas d'usage, relancez avec vos propres prompts.
- Comment savoir qu'un modèle a été rétrogradé en douce ?
- Une rétrogradation silencieuse, c'est le même id remplacé par un modèle plus faible ou une version quantifiée. Envoyez une fois par jour le même problème à réponse unique avec temperature à 0 : si la réponse passe de juste à fausse, ou si le mois limite de ses connaissances change, le modèle a été remplacé. Regardez ensuite le reçu : un id de modèle inchangé avec une réponse qui change signifie que c'est le modèle qui a changé, pas votre prompt. Le contrôle quotidien ici signale cet état comme modifié.
- Pourquoi commencer les tests par une petite recharge ?
- Parce que le but des tests est d'avoir des preuves avant de faire confiance. La recharge minimale ici est de $10, de quoi lancer les sept tests plusieurs fois. S'ils passent, ajoutez du solde ; sinon, la perte est limitée. Les recharges ne sont pas remboursables.
Testez d'abord, faites confiance ensuite
Rechargez $10 et lancez les sept tests. Chaque modèle est contrôlé une fois par jour publiquement, et chaque requête a un reçu signé.
01Comment fonctionne le contrôle quotidien
Chaque modèle du catalogue reçoit un même prompt canari une fois par jour. Sa réponse est comparée à celles des tests précédents, puis chaque modèle reçoit un statut avec l'heure du test. Les derniers résultats par modèle sont sur la page proof (en anglais).
Les mêmes données sont disponibles en JSON public sur
https://api.relayswitch.io/v1/proof: sans clé API, lisibles depuis n'importe quelle origine, et mises en cache cinq minutes. Les id de modèle testés sont ceux de la liste des modèles.