Liquid AI présente D1, un modèle qui évalue des options au lieu de rédiger des réponses

Ce que Liquid AI a annoncé

Liquid AI présente d1 comme un modèle de décision : plutôt que de rédiger une réponse libre, il évalue une entrée et renvoie des résultats structurés pour prendre une décision circonscrite. Sa documentation décrit trois modèles dans cette famille : d1-3B, un modèle multimodal qui traite le texte et les images ; d1-omni-600M, qui prend en charge le texte, les images ou l’audio ; et d1Hosted, accessible via l’API de Liquid AI.

Le fournisseur destine ce type de modèle à la classification, à la hiérarchisation, à la modération, à l’orientation de demandes et à d’autres tâches dont les résultats sont définis à l’avance. La distinction est pratique : si le système doit choisir une étiquette ou attribuer une note, il peut répondre dans un format structuré ; s’il doit expliquer, résumer ou rédiger, il faut une capacité générative. La documentation indique explicitement qu’un modèle de langage convient aux tâches de génération ouverte.

La disponibilité décrite dans la documentation ne signifie pas que chaque modalité, interface ou modèle est accessible dans tous les environnements. Avant d’intégrer d1, il est utile de vérifier le modèle précis, les entrées acceptées, l’API et les conditions en vigueur. L’annonce de l’entreprise présente également comme siens les résultats de comparaison avec Jev ; ils doivent être considérés comme des déclarations du fournisseur, et non comme une validation indépendante.

Comment le modèle exprime ses décisions

La documentation regroupe les requêtes en trois primitives. Choice sélectionne une catégorie parmi des options sans ordre intrinsèque et renvoie une distribution de probabilités sur les options nommées. Score situe la réponse sur une échelle ordonnée, par exemple une grille de gravité. Noul pose une question binaire et renvoie une probabilité comprise entre 0 et 1 : la probabilité qu’un message soit indésirable, par exemple.

Cette présentation permet de distinguer l’option la plus probable du degré d’incertitude entre plusieurs possibilités. Si le système attribue des probabilités proches à deux services, il peut transférer le dossier à une personne au lieu de traiter l’étiquette gagnante comme une certitude. Mais une sortie probabiliste ne prouve pas, à elle seule, que les probabilités sont bien calibrées : cette propriété doit être mesurée sur des données représentatives.

Liquid AI affirme que d1 ne génère pas de tokens de réponse et produit une décision en un seul appel. L’expression « zéro token généré » décrit le mode de production de la sortie selon le fournisseur ; elle ne renseigne pas, à elle seule, sur tous les éléments de facturation, comme le traitement de l’entrée, le tarif de l’API ou les coûts d’infrastructure. Elle ne suffit pas non plus à conclure qu’une tâche sera toujours plus rapide ou moins coûteuse qu’avec un modèle génératif.

Les usages possibles en entreprise

Cette approche est surtout pertinente lorsque les réponses possibles sont limitées et que la décision se répète fréquemment. Parmi les usages cités par Liquid AI figurent la classification de messages, l’orientation de tickets, la modération, l’évaluation de l’urgence, les contrôles de sécurité binaires et l’approbation d’appels d’outils. Pour les entrées visuelles, l’entreprise mentionne l’inspection et la classification d’images ; pour l’audio, la détection d’intention et l’orientation de commandes vocales avec le modèle qui prend en charge cette modalité.

Dans un processus de triage des demandes, par exemple, le système attribue des probabilités à des catégories connues et transmet les cas ambigus à une personne. Autre possibilité : un contrôle vérifie si un résultat extrait satisfait une exigence avant de l’accepter. Dans les deux cas, l’utilité dépend de la capacité du catalogue d’options à représenter les situations réelles et de l’existence d’une réponse sûre pour les entrées nouvelles, incomplètes ou hors distribution.

D1 ne remplace pas automatiquement un LLM. La documentation recommande elle-même la génération pour la rédaction libre, la conversation, le résumé, le code, les questions ouvertes et le raisonnement complexe en plusieurs étapes. Une architecture peut combiner les deux approches : utiliser un modèle de décision pour une classification circonscrite, puis faire appel à un modèle génératif ou à une personne si une explication ou une réponse ouverte est nécessaire.

Ce qu’il faut pour évaluer la comparaison avec Jev

Liquid AI affirme que d1 dépasse Jev dans le Decision Index de Hugging Face et met aussi en avant des résultats concernant les évaluations multilingues, le traitement des entrées longues et la résistance aux injections de prompt. Une déclaration du fabricant ne peut pas être présentée comme un fait vérifié de manière indépendante. Pour interpréter le résultat, il faut connaître la version exacte du benchmark, les tâches, les données évaluées, le protocole, les modèles comparés et les conditions d’exécution.

Il importe également de distinguer un score agrégé des résultats par tâche. Un indice qui regroupe différentes catégories d’évaluation peut éclairer une comparaison, mais ne prédit pas à lui seul les performances d’un système de classement de factures, de modération de messages ou d’orientation de tickets dans une entreprise donnée. Les résultats peuvent varier selon la langue, la longueur des entrées, la conception des étiquettes et la fréquence des cas exceptionnels.

Les sources disponibles n’établissent pas de comparaison indépendante de la précision, de la calibration, de la latence et du coût par rapport à Jev ou à des modèles génératifs dans des conditions équivalentes. Pour répéter rigoureusement que d1 « dépasse » Jev, il faudrait documenter les versions comparées, le jeu de test et la méthodologie, puis vérifier que le résultat est reproductible en dehors de l’évaluation annoncée par le fournisseur.

Limites et critères pratiques

Les probabilités ne sont utiles que si elles reflètent raisonnablement la fréquence des réponses correctes pour le cas d’usage considéré. Un score élevé ne doit pas être interprété automatiquement comme une garantie ; de plus, les conséquences d’un seuil de décision varient selon le type d’erreur. En modération, par exemple, une fausse alerte et le passage inaperçu d’un contenu nuisible n’ont pas le même coût. Il faut vérifier la calibration et les seuils à partir de données pertinentes, puis les réexaminer si les entrées évoluent.

Il est également utile d’observer le comportement du modèle face à des informations non pertinentes, des instructions malveillantes, des catégories inconnues et des entrées incomplètes. L’affirmation de l’entreprise selon laquelle le modèle résiste davantage aux injections de prompt ne dispense pas de réaliser ses propres tests de sécurité. Pour les tâches sensibles, une vérification humaine, des limites d’action et un mécanisme d’escalade des cas incertains constituent des garde-fous raisonnables.

En pratique, d1 mérite un essai lorsque le résultat attendu peut être exprimé dans une structure définie et évalué à partir d’exemples représentatifs. Un LLM génératif convient mieux si la tâche exige de rédiger ou de répondre de manière ouverte. Si le processus combine ces besoins, une chaîne hybride peut être testée ; il faut comparer sa qualité, sa latence et son coût total avant de remplacer un système en production.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.