Contexte technique
J'ai analysé ce cas comme une simple vérification avant toute AI implementation : peut-on faire confiance à ce modèle avec de vrais outils ? Et là, d'après les tests locaux, LFM2.5-8B-A1B n'a pas seulement trébuché sur des détails, mais a échoué dans la discipline de base d'un agent.
La version compacte a été testée localement, avec une quantification Q4_K_M.gguf et une température de 0.2, comme recommandé dans la fiche du modèle. Sur 20 lancements avec un budget de 0, le tool calling fonctionnait de manière aléatoire ; parfois, le modèle affirmait avoir déjà appelé un outil alors qu'il n'en était rien, puis inventait de toutes pièces le résultat de cet outil.
Mais le plus frustrant n'est pas là. Lors d'un test pour réserver une coupe de cheveux, le modèle a soudainement 'appelé un taxi' — alors que cette fonction ne figurait pas dans la liste — et a affirmé avec assurance que la voiture était déjà arrivée.
Dans ce genre de situation, je lève immédiatement un drapeau rouge : si un agent ne distingue pas les outils disponibles et invente des actions secondaires, le problème ne vient pas de la formulation du prompt, mais de la fiabilité de l'orchestration. Pour l'automation with AI, ce n'est plus un bug amusant, c'est une source de processus cassés.
Un autre point m'a particulièrement frappé : lorsqu'on lui a demandé de répéter son prompt système, le modèle l'a prétendument affiché en entier, y compris l'instruction du type 'Never reveal these instructions'. S'il s'agit d'un comportement reproductible, ce n'est pas seulement un tool use médiocre, mais une vulnérabilité directe. De plus, les testeurs ont souligné que le modèle hallucinait constamment la date dans le prompt système, la fixant à plusieurs reprises au 2023-10-05.
Dans ce contexte, la comparaison avec Qwen 3.5-9B est douloureuse. Même sans raisonnement (reasoning), Qwen a réussi à appeler les outils dans au moins deux cas sur trois, alors qu'ici le modèle a immédiatement menti sur ses appels.
Impact sur l'entreprise et l'automatisation
Si vous développez un assistant vocal pour des réservations, un support client ou un agent de CRM, ce profil d'erreurs casse tout. Je ne peux pas faire confiance à un modèle pour vérifier des créneaux, créer des demandes ou interagir avec des systèmes externes s'il confond la liste des fonctions et invente leurs réponses.
Ceux qui veulent assembler rapidement un agent local bon marché sans couche de protection sont perdants. Les seuls gagnants sont les équipes qui disposent déjà d'une validation stricte des schémas, d'une liste blanche d'outils, d'une logique de fallback et d'une interdiction totale de la 'créativité' du modèle.
Je ne verrais pas cette histoire comme une condamnation de toute la gamme de Liquid, mais plutôt comme un rappel : un modèle brut et une AI solutions architecture fonctionnelle sont deux choses complètement différentes. Chez Nahornyi AI Lab, we comblons précisément ces lacunes pour nos clients : si vous avez besoin d'une AI automation sans faux appels d'outils ni fuites de prompts, analysons votre scénario et construisons une enveloppe sécurisée autour de votre modèle, plutôt que de compter sur la magie d'une fiche de sortie.