Aller au contenu
TIKI Platform

PROTOCOLE LLM-360 V1.0

Huit voies de mesure, jamais une note unique

Une note globale cache toujours l'axe sur lequel un système perd. Le protocole LLM-360 mesure huit axes indépendants, publie celui où vous perdez à côté de celui où vous gagnez, et refuse de moyenner les deux.

Les huit voies

Chaque voie répond à une question précise et se note séparément. Les quatre voies marquées « rare » sont celles que la quasi-totalité des classements publics ne mesurent pas.

  1. V1

    Justesse

    La réponse est-elle exacte, vérifiable et sans invention ?

    Notation : Taux d'items aboutis, hors échecs de transport

  2. V2

    Méthode

    Le raisonnement tient-il, étape par étape, jusqu'au résultat ?

    Notation : Note de trajectoire sur la trace complète

  3. V3

    Puissance générative

    Le système tient-il sur les tâches longues et composées ?

    Notation : Taux d'aboutissement par palier de difficulté

  4. V4

    Fiabilité technique

    rare

    Le système répond-il, tout simplement ?

    Notation : Échecs de transport, de quota et d'exécution

  5. V5

    Latence et débit

    rare

    Combien de temps avant le premier octet, et jusqu'au dernier ?

    Notation : p50 / p95 du temps au premier octet et du temps total

  6. V6

    Coût par tâche accomplie

    rare

    Combien coûte un résultat réellement utilisable ?

    Notation : Coût total divisé par le nombre d'items aboutis

  7. V7

    Reproductibilité

    rare

    Le même test, relancé, donne-t-il le même résultat ?

    Notation : Écart entre exécutions à graine identique

  8. V8

    Sécurité et conformité

    Le système résiste-t-il au détournement et protège-t-il les données ?

    Notation : Taux de résistance aux tentatives d'injection et de fuite

La règle centrale : un échec de transport n'est pas un échec de qualité

Quand une requête revient en HTTP 504 après 301 secondes sans qu'un seul octet de réponse soit arrivé, le modèle n'a rien produit. Le compter comme une mauvaise réponse est une calomnie statistique.

Le retirer purement et simplement de l'échantillon est l'erreur inverse : un utilisateur aurait vécu exactement cette panne. Le masquer, c'est publier une fiabilité qui n'existe pas.

Nous comptons cet item dans la voie Fiabilité technique, et nulle part ailleurs. Les deux chiffres sont publiés côte à côte.

Les états d'un item

Ces sept états sont inscrits dans la base de données elle-même, sous forme de contraintes. Un item ne peut pas prendre une autre valeur.

abouti
La tâche est terminée et le résultat est utilisable.
a_noter
Une réponse est arrivée, elle n'est pas encore notée.
echec_modele
Le système a répondu, mais mal. C'est une erreur de qualité.
echec_transport
Rien n'est arrivé : réseau, passerelle, délai dépassé.
echec_quota
Refusé pour dépassement de quota ou de limite de débit.
en_cours
L'exécution n'est pas terminée.
sans_objet
L'item a été retiré du calcul, avec motif enregistré.

Trois coûts, un seul qui décide

Le prix par million de jetons ne dit rien. Un modèle deux fois moins cher qui échoue une fois sur trois coûte plus cher. Nous publions les trois calculs, et nous disons lequel compte.

Coût par item terminé

coût total ÷ items terminés

Ce que coûte une exécution, aboutie ou non.

Coût par réponse reçue

coût total ÷ réponses reçues

Ce que coûte le fait d'obtenir quelque chose en retour.

Coût par tâche accomplie

coût total ÷ items aboutis

Ce que coûte un résultat réellement utilisable.

C'est le seul qui compte pour décider d'un achat.

L'honnêteté statistique n'est pas optionnelle

Un taux sur 8 items n'est pas un taux

Sous 20 items, tout taux publié porte la mention indicatif. Il faut au moins 50 items pour annoncer un taux à ±10 points avec un intervalle de confiance à 95 %. Nous affichons l'effectif et l'intervalle, pas seulement le pourcentage.

Les tâches contaminées restent en base

Une tâche présente dans les données d'entraînement d'un modèle fausse la mesure. Nous ne la supprimons pas — nous la marquons contaminée, nous l'excluons du calcul, et le motif d'exclusion reste consultable. On ne réécrit pas l'histoire d'un test.

Les sous-échantillons sont tirés à graine fixe

Quand une suite est trop longue pour être exécutée entièrement, le sous-ensemble est tiré au hasard avec une graine enregistrée. N'importe qui peut retirer exactement le même échantillon et refaire le calcul.

Trois versions accompagnent chaque run

Version du protocole, version de la suite de tâches, version du harnais d'exécution. Sans ces trois numéros, deux résultats ne sont pas comparables — et la plupart des classements publics ne les donnent pas.

Ce que nous ne mesurons pas

Un protocole se juge autant à ce qu'il refuse de prétendre mesurer.

Limites assumées du protocole v1.0

L'intelligence. Nous mesurons des tâches, pas une capacité générale. Un score élevé sur nos suites ne garantit pas la réussite sur votre métier.

La qualité subjective d'un texte. Nous notons l'exactitude vérifiable et la trajectoire, pas l'élégance.

Le comportement en production. Nos mesures de latence et de fiabilité sont faites depuis nos machines, à nos heures. Votre réseau et vos heures de pointe ne sont pas les nôtres — et nous publions d'où et quand nous mesurons.

La sécurité exhaustive. Nos tests de sécurité sont non intrusifs par défaut. Ne pas trouver de faille n'est pas prouver qu'il n'y en a pas.

Voir le protocole appliqué

Un rapport complet montre mieux qu'une page de méthode : chaque chiffre y est cliquable et mène à sa trace.

Parler avec TIKINous contacter