Liquid AI lance d1, un modèle de décision qui renvoie des probabilités calibrées sans générer aucun token
Liquid AI a lancé d1, un modèle de décision conçu pour trancher entre des options prédéfinies plutôt que pour générer du texte. On lui fournit un contexte et une série de questions typées, et il renvoie en un seul appel des probabilités calibrées sur un ensemble fixe de résultats, sans produire le moindre token (le champ usage.output_tokens vaut toujours 0). Trois primitives sont disponibles. Noul pose une question oui/non et renvoie une probabilité entre 0 et 1 : « ce message est-il une plainte ? » a obtenu 0,999. Choice sélectionne une option dans un ensemble nommé et renvoie le meilleur choix, la distribution complète et un niveau de confiance ; un ticket de double facturation a obtenu 0,9997 sur « facturation ». Score évalue une entrée sur une grille ordonnée indexée à partir de 0 et renvoie une position pondérée par les probabilités ; une panne en production a obtenu 2,9995 sur une échelle d'urgence de 0 à 3. Les trois types peuvent être mélangés dans une même requête, évaluée sur le même état. L'accès se fait via l'API de Liquid, en POST sur https://api.liquid.ai/decisions/v1/systemone, avec le nom de modèle d1:free et une clé obtenue sur console.liquid.ai. Des clients Python (typesafe-sdk) et TypeScript (@typesafe-ai/sdk) de TypeSafe AI sont fournis. Le modèle n'est proposé qu'en API, non entraînable, sans poids GGUF, MLX ou ONNX à auto-héberger.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de MarkTechPost. Lire l'article original →
L'enjeu concerne tout le travail que de nombreuses équipes confient encore à des LLM généralistes : classification, routage de tickets, notation, modération, reclassement et évaluations de type LLM-as-judge. Selon le guide de migration de Liquid, d1 évite la facturation de tokens de sortie, y compris pour une étiquette d'un seul mot, offre une latence prévisible faute de boucle de décodage, supprime les erreurs de schéma et les JSON malformés, et remplace les scores auto-déclarés par des probabilités calibrées. Trois appels de classification successifs se réduisent à un seul. Les probabilités rendent les seuils exploitables : l'exemple de modération bloque au-dessus de 0,8, autorise en dessous de 0,2 et envoie la zone intermédiaire à une relecture humaine, tandis que l'exemple de routage se replie sur le niveau de modèle le plus capable quand la confiance du routeur passe sous 0,5. Liquid affirme aussi que des évaluations répétées d'une même entrée sont plus cohérentes, ce qui limite les changements de verdict.
La règle de Liquid est simple : si la réponse appartient à N options connues, un modèle de décision convient ; si le modèle doit composer une nouvelle chaîne de texte, il faut conserver un LLM, notamment pour le résumé, la rédaction, le chat multi-tours, la génération de code et le raisonnement complexe en plusieurs étapes. Pour illustrer l'usage, l'entreprise publie « Road Decider », une démo de course de survie en pixel art où d1 choisit gauche, centre ou droite via une question Choice, de 2 à 5 fois par seconde selon la vitesse. L'application, en JavaScript pur sur Node.js 18+, passe par un proxy Vite qui garde la clé côté serveur, et un mode d'affrontement oppose d1 au modèle typesafe/jev-1.13 de TypeSafe via OpenRouter. L'enseignement principal porte sur la conception de l'état : des résumés par voie, avec la distance au premier obstacle, produisent des décisions plus confiantes qu'une grille brute de la route.
Pas d'impact direct sur la France/UE