Un bug de sortie structurée dans Ollama ignore le schéma lorsque les modèles de réflexion répondent directement

Une mise à jour récente d'Ollama a introduit un bug subtil mais critique affectant les sorties structurées des modèles de langage « de réflexion ». Depuis la version 0.34.4, si un modèle décide de répondre directement à une invite sans entrer dans sa phase de raisonnement interne, il ignore entièrement le schéma JSON demandé. Ce problème touche les développeurs qui comptent sur des formats de données stricts pour leurs workflows automatisés, car le serveur renvoie des structures invalides avec un code de statut HTTP réussi.

Ce qui s'est passé

Le problème provient de la manière dont Ollama gère les contraintes grammaticales pour les modèles prenant en charge un mode « réflexion », comme Gemma 4. Dans le but d'appliquer les règles de sortie structurée en une seule passe, le logiciel enveloppe le schéma JSON défini par l'utilisateur dans une grammaire qui attend d'abord un bloc de réflexion. Le système suppose que tout texte apparaissant avant la balise de fermeture du bloc de réflexion fait partie du processus de raisonnement et est donc non contraint. L'application du schéma n'intervient qu'après la fermeture du bloc de réflexion.

Lorsqu'un modèle rencontre une question simple et choisit de sauter entièrement la phase de réflexion, il n'émet jamais les balises ouvrantes ou fermantes de ce bloc. Par conséquent, l'enveloppeur grammatical considère la réponse directe comme du « texte avant la fermeture » et permet à la réponse de se terminer immédiatement. Comme la contrainte du schéma est techniquement attachée à la section post-réflexion, et que cette section n'arrive jamais, la sortie brute du modèle contourne toutes les règles de formatage. Les journaux du serveur ne montrent aucune erreur, et la réponse HTTP reste 200 OK, rendant la défaillance difficile à détecter sans validation stricte côté client.

Des tests effectués sur Ollama 0.35.1 avec le modèle gemma4:e2b ont confirmé ce comportement. Lorsqu'on lui posait des questions factuelles simples avec think: true, le modèle sautait parfois le raisonnement et renvoyait des chaînes brutes comme "391" ou "Paris" au lieu de l'objet JSON requis. En revanche, chaque réponse incluant un bloc de réflexion respectait strictement le schéma. La désactivation complète du mode réflexion (think: false) entraînait également une conformité correcte au schéma, indiquant que le problème est spécifique à l'interaction entre l'enveloppeur grammatical de réflexion et les réponses directes.

Détails clés

• Le bug affecte les versions d'Ollama 0.34.4 et ultérieures, y compris la version actuelle 0.35.1.
• Il impacte spécifiquement les modèles « de réflexion » comme Gemma 4 lorsque le paramètre think est activé.
• Les réponses qui sautent la phase de réflexion renvoient du texte non structuré malgré une demande de schéma JSON valide.
• Le serveur renvoie HTTP 200 avec done_reason: "stop", sans indication d'erreur dans les journaux.
• Une pull request ouverte, #18783, propose une correction en forçant le modèle à entrer dans l'état de réflexion.
• La validation côté client est actuellement le seul moyen fiable de détecter ces réponses malformées.

Contexte

La sortie structurée est une fonctionnalité qui force les grands modèles de langage à répondre dans un format spécifique, tel que JSON, plutôt qu'en texte libre. Cela est essentiel pour intégrer l'IA dans des pipelines logiciels où le code aval attend des structures de données prévisibles. Ollama implémente cela en convertissant les schémas JSON en grammaires qui restreignent les tokens que le modèle peut générer.

Les modèles « de réflexion » sont une nouvelle classe d'IA qui séparent leur processus de raisonnement interne de leur réponse finale. Ils enveloppent généralement leur chaîne de pensée dans des balises spéciales, permettant au système de distinguer le travail de brouillon de la sortie finale. Le changement récent d'Ollama tentait d'optimiser la façon dont ces deux fonctionnalités travaillent ensemble en traitant le bloc de réflexion et la réponse finale comme une seule séquence grammaticale continue. Cependant, cette optimisation supposait que le bloc de réflexion serait toujours présent, créant un angle mort pour les réponses directes.

Pourquoi c'est important

Pour les équipes exploitant des infrastructures IA auto-hébergées, la fiabilité est primordiale. Ce bug introduit un mode de défaillance silencieux où les applications reçoivent des données qui semblent valides au niveau transport mais échouent au niveau application. Si votre backend attend un objet JSON avec des clés spécifiques et reçoit une chaîne simple à la place, il peut planter ou se comporter de manière imprévisible. Comme l'erreur n'apparaît pas dans les journaux du serveur, le débogage peut être long, surtout si le problème ne se déclenche que sur des invites simples ne nécessitant pas de raisonnement complexe.

De plus, cela met en évidence les risques liés à la dépendance vis-à-vis de fonctionnalités expérimentales ou récemment fusionnées dans des environnements de production. Le changement ayant causé ce problème était destiné à améliorer les performances et la cohérence, mais il a rompu un contrat fondamental des sorties structurées. Les équipes utilisant des modèles de réflexion pour la classification, l'extraction ou des tâches simples de Q&R doivent désormais supposer que la conformité au schéma est conditionnée par la décision interne du modèle de raisonner. Cette incertitude complique la conception d'agents IA robustes et nécessite des pratiques de codage défensif supplémentaires.

Ce que vous pouvez faire

• Validez toutes les réponses structurées contre le schéma JSON attendu dans votre application cliente avant traitement.
• Si le raisonnement n'est pas nécessaire pour une tâche spécifique, définissez think: false pour garantir que le schéma est appliqué directement à la sortie.
• Surveillez les réponses manquant de structure attendue et journalisez-les séparément pour analyse.
• Utilisez le script de la boîte à outils communautaire check-ollama-format-think.sh pour tester si votre modèle et version spécifiques sont affectés.
• Envisagez d'épingler votre version d'Ollama ou d'éviter les modèles de réflexion pour les tâches critiques de sortie structurée jusqu'à la publication d'une correction.
• Consultez les pull requests ouvertes, notamment #18783, pour suivre les mises à jour sur le statut officiel du correctif.