Ollama-Fehler bei strukturierten Ausgaben: Schema wird übersprungen, wenn Thinking-Modelle direkt antworten

Ein kürzlich veröffentlichtes Update für Ollama hat einen subtilen, aber kritischen Fehler eingeführt, der die strukturierten Ausgaben von „Thinking“-Sprachmodellen betrifft. Seit Version 0.34.4 ignoriert ein Modell das angeforderte JSON-Schema vollständig, wenn es beschließt, eine Eingabeaufforderung direkt zu beantworten, ohne seine interne Reasoning-Phase zu durchlaufen. Dieses Problem beeinträchtigt Entwickler, die auf strenge Datenformate für automatisierte Workflows angewiesen sind, da der Server ungültige Strukturen mit einem erfolgreichen HTTP-Statuscode zurückgibt.

Was passiert ist

Das Problem liegt in der Art und Weise, wie Ollama Grammatikbeschränkungen für Modelle handhabt, die einen „Thinking“-Modus unterstützen, wie z. B. Gemma 4. Um Regeln für strukturierte Ausgaben in einem einzigen Durchlauf anzuwenden, verpackt die Software das benutzerdefinierte JSON-Schema in eine Grammatik, die zunächst einen Thinking-Block erwartet. Das System geht davon aus, dass jeder Text, der vor dem schließenden Tag des Thinking-Blocks erscheint, Teil des Reasoning-Prozesses ist und daher nicht eingeschränkt wird. Die Durchsetzung des Schemas greift erst nach dem Schließen des Thinking-Blocks.

Wenn ein Modell auf eine einfache Frage stößt und sich entscheidet, die Thinking-Phase vollständig zu überspringen, sendet es weder öffnende noch schließende Tags für diesen Block aus. Folglich sieht der Grammatik-Wrapper die direkte Antwort als „Text vor dem Schließen“ an und erlaubt es der Antwort, sofort zu enden. Da die Schema-Beschränkung technisch am Post-Thinking-Abschnitt hängt und dieser Abschnitt nie erreicht wird, umgeht die Rohausgabe des Modells alle Formatierungsregeln. Die Server-Protokolle zeigen keine Fehler an, und die HTTP-Antwort bleibt 200 OK, was das Versagen ohne strenge clientseitige Validierung schwer erkennbar macht.

Tests mit Ollama 0.35.1 und dem Modell gemma4:e2b bestätigten dieses Verhalten. Bei einfachen faktischen Fragen mit aktiviertem think: true übersprang das Modell gelegentlich das Reasoning und gab bloße Strings wie "391" oder "Paris" zurück, anstelle des erforderlichen JSON-Objekts. Im Gegensatz dazu hielten sich alle Antworten, die einen Thinking-Block enthielten, strikt an das Schema. Auch das vollständige Deaktivieren des Thinking-Modus (think: false) führte zur korrekten Einhaltung des Schemas, was darauf hindeutet, dass das Problem spezifisch auf die Interaktion zwischen dem Thinking-Grammatik-Wrapper und direkten Antworten zurückzuführen ist.

Wichtige Details

• Der Fehler betrifft Ollama-Versionen ab 0.34.4, einschließlich der aktuellen Version 0.35.1.
• Er wirkt sich speziell auf „Thinking“-Modelle wie Gemma 4 aus, wenn der Parameter think aktiviert ist.
• Antworten, die die Thinking-Phase überspringen, liefern unstrukturierten Text trotz einer gültigen JSON-Schema-Anforderung.
• Der Server gibt HTTP 200 mit done_reason: "stop" zurück, ohne Fehlerindikatoren in den Logs bereitzustellen.
• Ein offener Pull Request, #18783, schlägt eine Lösung vor, indem er das Modell zwingt, den Thinking-Zustand zu betreten.
• Clientseitige Validierung ist derzeit die einzige zuverlässige Methode, um diese fehlerhaften Antworten zu erkennen.

Hintergrund

Strukturierte Ausgabe ist eine Funktion, die große Sprachmodelle zwingt, in einem bestimmten Format zu antworten, wie z. B. JSON, anstatt Freitext. Dies ist entscheidend für die Integration von KI in Software-Pipelines, wo nachgelagerter Code vorhersagbare Datenstrukturen erwartet. Ollama implementiert dies, indem es JSON-Schemas in Grammatiken konvertiert, die die vom Modell generierten Tokens einschränken.

„Thinking“-Modelle sind eine neuere Klasse von KI, die ihren internen Reasoning-Prozess von ihrer endgültigen Antwort trennen. Sie verpacken ihre Chain-of-Thought typischerweise in spezielle Tags, sodass das System zwischen Entwurfsarbeit und endgültiger Ausgabe unterscheiden kann. Die jüngste Änderung bei Ollama versuchte, die Zusammenarbeit dieser beiden Funktionen zu optimieren, indem sie den Thinking-Block und die endgültige Antwort als eine einzige kontinuierliche Grammatiksequenz behandelte. Diese Optimierung ging jedoch davon aus, dass der Thinking-Block immer vorhanden sein würde, was eine Blindstelle für direkte Antworten schuf.

Warum es wichtig ist

Für Teams, die selbst gehostete KI-Infrastruktur betreiben, ist Zuverlässigkeit von größter Bedeutung. Dieser Fehler führt zu einem stillen Versagensmodus, bei dem Anwendungen Daten erhalten, die auf der Transportebene gültig aussehen, aber auf der Anwendungsebene scheitern. Wenn Ihr Backend ein JSON-Objekt mit bestimmten Schlüsseln erwartet und stattdessen einen reinen String erhält, kann es abstürzen oder sich unvorhersehbar verhalten. Da der Fehler nicht in den Server-Logs auftaucht, kann das Debugging zeitaufwändig sein, besonders wenn das Problem nur bei einfachen Prompts ausgelöst wird, die kein komplexes Reasoning erfordern.

Darüber hinaus verdeutlicht dies die Risiken, die damit verbunden sind, experimentelle oder kürzlich zusammengeführte Funktionen in Produktionsumgebungen zu nutzen. Die Änderung, die dieses Problem verursachte, sollte die Leistung und Konsistenz verbessern, brach jedoch einen grundlegenden Vertrag der strukturierten Ausgaben. Teams, die Thinking-Modelle für Klassifizierung, Extraktion oder einfache Q&A-Aufgaben verwenden, müssen nun davon ausgehen, dass die Schema-Konformität von der internen Entscheidung des Modells zum Reasoning abhängt. Diese Unsicherheit erschwert das Design robuster KI-Agenten und erfordert zusätzliche defensive Programmierpraktiken.

Was Sie tun können

• Validieren Sie alle strukturierten Antworten in Ihrer Client-Anwendung gegen das erwartete JSON-Schema, bevor Sie sie verarbeiten.
• Wenn Reasoning für eine bestimmte Aufgabe nicht erforderlich ist, setzen Sie think: false, um sicherzustellen, dass das Schema direkt auf die Ausgabe angewendet wird.
• Überwachen Sie Antworten, denen die erwartete Struktur fehlt, und protokollieren Sie sie separat zur Analyse.
• Verwenden Sie das Community-Toolkit-Skript check-ollama-format-think.sh, um zu testen, ob Ihr spezifisches Modell und Ihre Version betroffen sind.
• Erwägen Sie, Ihre Ollama-Version festzulegen (Pinning) oder Thinking-Modelle für kritische Aufgaben mit strukturierter Ausgabe zu vermeiden, bis eine Korrektur veröffentlicht wird.
• Prüfen Sie offene Pull Requests, insbesondere #18783, auf Updates zur Problemlösung.