Voici decision-machine-1 : un modèle de langage pour décider, pas pour rédiger

Aujourd’hui, nous publions decision-machine-1, un modèle de langage bâti pour prendre des décisions sur du texte, et rien d’autre. Il vit sur milliseconds.ai, avec sa propre API, sa console et sa documentation. Il classe, extrait, évalue et vérifie. Il indique toujours à quel point il est sûr. Ne lui demandez pas son opinion. Ne lui demandez pas d’inventer quelque chose. Il ne le peut pas.

Le problème quand on demande une valeur à un LLM

Ce billet est-il urgent ? Dans quelle file va-t-il ? Quelle est la franchise sur cette police ? Depuis quelques années, les développeurs répondent à ces questions avec un LLM et une sortie structurée. Ça fonctionne, la plupart du temps. Le problème, c’est que les LLM sont lents, coûteux, et qu’ils hallucinent.

Posez à un LLM une question à laquelle le texte ne peut pas répondre, et forcez-le à retourner une valeur quand même. Il en retournera une. Dans le meilleur des cas, il écrit « Je n’ai pas trouvé cette information. » Dans le pire des cas, il écrit une valeur qui n’existe pas. Pour le logiciel qui consomme la sortie, les deux se ressemblent. Une valeur bien formatée et une phrase qui dit qu’on ne l’a pas trouvée, ce sont deux chaînes de caractères.

Alors l’industrie a bâti des garde-fous. Validation avant le modèle. Validation après le modèle. Un humain dans la boucle. Tout ça pour protéger un flux de travail d’un outil qui n’aurait jamais dû le propulser.

Chez CloudRaker, nous traitons des millions de pages et de minutes audio chaque mois. La plupart du travail que nos clients exécutent est exactement ce genre de travail : extraction et structuration à grande échelle, où la vitesse et l’exactitude sont tout le travail. Alors nous avons continué de pousser.

L’IA générative, sans la génération

decision-machine-1 n’est pas un seul gros modèle. Ce sont deux petits modèles encodeurs derrière une seule API. Le classificateur note chaque étiquette que vous envoyez en une seule passe sur le texte. L’extracteur trouve le meilleur segment du texte pour chaque champ que vous envoyez. Chaque capacité correspond à l’un de ces deux emplois.

Aucun des deux modèles ne génère. Il n’y a pas de boucle d’échantillonnage, pas de chaîne de raisonnement, pas de chaîne de reprises et pas d’analyseur d’invite. Le modèle lit l’entrée une fois et retourne des scores ou des segments. L’API normalise les chiffres et retourne du JSON typé. C’est de là que vient la vitesse, et c’est aussi de là que vient l’honnêteté. answer retourne un segment de votre propre texte avec des positions de caractères. Il ne peut pas retourner des mots qui ne sont pas dans le texte.

Voici ce que ça donne quand une question n’a pas de réponse dans la source. Une vraie réponse de /answer, avec trois questions sur un même communiqué :

{
  "results": [
    {"question":"Who announced the product?","answer":"Tim Cook","probability":0.999,"start":0,"end":8},
    {"question":"How much does it cost?","answer":"$999","probability":0.989,"start":85,"end":89},
    {"question":"What is the CEO salary?","answer":null,"probability":0,"start":null,"end":null}
  ]
}

La troisième réponse est null, la probabilité est 0, et les positions sont null. Votre code vérifie un seul champ. Pas de recherche de « je n’ai pas trouvé » dans une chaîne, pas de deuxième modèle pour noter le premier.

Il vous dit quand il n’est pas sûr

Une invite vous donne une réponse. decision-machine-1 vous donne une réponse et la distribution derrière.

• probability mesure à quel point le texte appuie la décision.
• confidence vaut un moins l’entropie normalisée de toute la distribution. Un seul gagnant clair donne 1. Une distribution plate donne 0.
• scores porte chaque option, pour que vous voyiez le deuxième.

Une vraie réponse de /rate sur l’échelle ["Calm","Annoyed","Frustrated","Threatening to leave"] :

{"score":1.585,"level":2,"label":"Frustrated","confidence":0.371,"scores":[0,0.471,0.472,0.057]}

Le niveau gagnant a battu le deuxième par 0,001. Le score de 1,585 se situe entre les deux. La confiance de 0,371 rapporte l’ambiguïté. Une invite aurait nommé un niveau et se serait arrêtée là. Avec ces chiffres, votre application fixe une barre par action : agir au-dessus, confirmer au milieu, escalader en dessous. Le guide des seuils explique la démarche.

Un modèle, huit décisions

Capacité	Question à laquelle elle répond	Latence mesurée
Oui / non	Cet énoncé est-il vrai pour le texte ?	0,42 s
Classer	Quelle étiquette s’applique ?	0,43 s (3 étiquettes)
Arbre de classement	Quel chemin dans cet arbre d’étiquettes s’applique ?	0,77 s (2 niveaux)
Évaluer	Où le texte se situe-t-il sur cette échelle ?	0,42 s (4 niveaux)
Répondre	Quel segment du texte répond à cette question ?	0,40 s
Extraire	Qu’est-ce qui remplit ce schéma JSON ?	0,41 s (9 propriétés)
Entités	Où sont tous les segments de ces types ?	0,42 s
Vérifier	Le texte appuie-t-il cette valeur ?	0,40 s

Chronométrages bout en bout depuis un portable contre la production, le 18 septembre 2026, médiane de 7 exécutions, sur des entrées de 51 à 199 caractères. Ils incluent TLS, le transit Internet et le saut d’API. Chaque appel atterrit près de 0,4 s, et l’inférence tourne sur GPU. Chaque réponse porte un en-tête x-inference-ms avec le temps du modèle seul : 36 à 54 ms sur ces appels, 108 ms pour l’arbre à deux niveaux.

Les étiquettes sont l’interface. Vous n’écrivez pas d’invite ; vous décrivez le cas. Envoyez "billing": "payments, invoices, charges, refunds" et le classificateur note cette description contre le texte. Envoyez un schéma JSON et extract le remplit, avec null pour chaque champ que le texte ne contient pas. Envoyez une valeur que vous détenez déjà et verify vous dit si le texte l’appuie, et ce que le texte dit vraiment quand ce n’est pas le cas.

Ce qu’il ne fera pas

decision-machine-1 décide. Il n’écrit pas, ne raisonne pas et ne tient pas de conversation.

• Générer du texte. Chaque réponse est une étiquette que vous avez fournie ou un segment de votre entrée. Résumer et reformuler ne sont pas des capacités.
• Raisonner par étapes. Une passe, une décision. Il n’y a pas de chaîne de raisonnement ni de planification.
• Clavarder. Le clavardage simple sur la surface compatible OpenAI retourne 400 unsupported_request, volontairement.
• Apporter des connaissances externes. Si le jugement exige des faits au-delà du texte envoyé, confiez-le à un grand modèle.

Cette liste, c’est le point. Chacun de ces éléments est un endroit où un modèle peut inventer quelque chose.

Une place à côté de votre LLM

La plupart des équipes utiliseront les deux. Appelez decision-machine-1 en premier. Acceptez les résultats qui respectent vos seuils. Envoyez les cas ambigus à un grand modèle ou à une personne. Ça retire l’appel au grand modèle de la majorité facile du trafic, et ça retire le code de garde-fous du reste, parce que le petit modèle vous a déjà dit quels cas sont incertains.

Le même patron fonctionne dans l’autre sens. Un seul appel /yes-no par lots filtre chaque message qui entre dans une application LLM ou qui en sort. Un seul appel /verify compare un champ extrait par un LLM au document source avant que vous l’écriviez dans un dossier. La section des patrons en couvre six, avec le calcul des coûts.

Tarification

	Prix
Jetons d’entrée	0,04 $ par million
Jetons de sortie	0 $
Plan gratuit	125 millions de jetons d’entrée par mois

Un seul prix pour chaque capacité et pour le point d’accès compatible OpenAI. Le coût suit le texte que vous envoyez, plus les étiquettes, les questions ou le schéma. Le nombre d’étiquettes ne le change pas. La taille de la réponse ne le change pas non plus. Les distributions complètes, les segments et les résultats par lots sont inclus.

Pour commencer

Prenez une clé sur console.milliseconds.ai. Chaque capacité est un seul POST.

curl -X POST https://api.milliseconds.ai/v1/decision-machine-1/classify \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MILLISECONDS_API_KEY" \
  -d '{
    "text": "I was charged twice for my subscription this month and support has not replied.",
    "labels": {
      "billing": "payments, invoices, charges or refunds",
      "shipping": "delivery, tracking or returns",
      "account": "login, password or profile settings"
    }
  }'

{"label":"billing","probability":0.999,"confidence":0.995,"scores":{"billing":0.999,"shipping":0,"account":0.001}}

Déjà sur le SDK OpenAI ? Réglez l’URL de base à https://api.milliseconds.ai/v1, choisissez decision-machine-1, et gardez vos appels response_format.json_schema et tools tels quels. Le guide de compatibilité OpenAI énumère ce que la façade lit et ce qu’elle ignore.

Chaque capacité a un panneau Try it dans la référence d’API. Il n’exige aucune clé. La documentation sert aussi un llms.txt et un serveur MCP, pour que votre agent de programmation puisse la lire lui aussi.

Commencez avec un appel de classement ou d’extraction que vous envoyez déjà à un LLM. Comparez l’exactitude, la latence et le coût sur vos propres entrées. Puis envoyez-nous les cas qui cassent. C’est comme ça que la prochaine version s’entraîne.

Où il se situe. decision-machine-1 est le modèle de décisions derrière CloudRaker. L’API Paperwork transforme les documents et l’audio en texte. milliseconds.ai transforme ce texte en décisions. Documentation : docs.milliseconds.ai.