Un error de salida estructurada en Ollama omite el esquema cuando los modelos de razonamiento responden directamente

Una actualización reciente de Ollama ha introducido un error sutil pero crítico que afecta las salidas estructuradas de los modelos de lenguaje "de razonamiento" (thinking). Desde la versión 0.34.4, si un modelo decide responder a una solicitud directamente sin entrar en su fase interna de razonamiento, ignora por completo el esquema JSON solicitado. Este problema afecta a los desarrolladores que dependen de formatos de datos estrictos para flujos de trabajo automatizados, ya que el servidor devuelve estructuras inválidas con un código de estado HTTP exitoso.

Qué ocurrió

El problema radica en cómo Ollama maneja las restricciones gramaticales para modelos que admiten un modo "de razonamiento", como Gemma 4. En un esfuerzo por aplicar reglas de salida estructurada en una sola pasada, el software envuelve el esquema JSON definido por el usuario con una gramática que espera primero un bloque de razonamiento. El sistema asume que cualquier texto que aparezca antes de la etiqueta de cierre del bloque de razonamiento forma parte del proceso de inferencia y, por lo tanto, está sin restricciones. La aplicación del esquema solo entra en vigor después de que se cierra el bloque de razonamiento.

Cuando un modelo encuentra una pregunta simple y elige omitir completamente la fase de razonamiento, nunca emite las etiquetas de apertura o cierre de ese bloque. Como consecuencia, el envoltorio gramatical ve la respuesta directa como "texto antes del cierre" y permite que la respuesta termine inmediatamente. Dado que la restricción del esquema está técnicamente adjunta a la sección posterior al razonamiento, y esa sección nunca llega, la salida bruta del modelo evade todas las reglas de formato. Los registros del servidor no muestran errores y la respuesta HTTP sigue siendo 200 OK, lo que hace difícil detectar el fallo sin una validación estricta en el lado del cliente.

Las pruebas realizadas en Ollama 0.35.1 con el modelo gemma4:e2b confirmaron este comportamiento. Al hacer preguntas factuales simples con think: true, el modelo ocasionalmente omitía el razonamiento y devolvía cadenas desnudas como "391" o "Paris" en lugar del objeto JSON requerido. En contraste, cada respuesta que incluía un bloque de razonamiento cumplía estrictamente con el esquema. Desactivar completamente el modo de razonamiento (think: false) también resultó en un cumplimiento correcto del esquema, lo que indica que el problema es específico de la interacción entre el envoltorio gramatical de razonamiento y las respuestas directas.

Detalles clave

• El error afecta a las versiones de Ollama 0.34.4 y posteriores, incluida la actual versión 0.35.1.
• Impacta específicamente a los modelos "de razonamiento" como Gemma 4 cuando el parámetro think está habilitado.
• Las respuestas que omiten la fase de razonamiento devuelven texto sin estructura a pesar de solicitar un esquema JSON válido.
• El servidor devuelve HTTP 200 con done_reason: "stop", sin proporcionar ninguna indicación de error en los registros.
• Una pull request abierta, #18783, propone una solución forzando al modelo a entrar en el estado de razonamiento.
• La validación en el lado del cliente es actualmente la única forma fiable de detectar estas respuestas malformadas.

Contexto

La salida estructurada es una función que obliga a los grandes modelos de lenguaje a responder en un formato específico, como JSON, en lugar de texto libre. Esto es esencial para integrar IA en pipelines de software donde el código aguas abajo espera estructuras de datos predecibles. Ollama implementa esto convirtiendo esquemas JSON en gramáticas que restringen los tokens que el modelo puede generar.

Los modelos "de razonamiento" son una clase más nueva de IA que separa su proceso interno de inferencia de su respuesta final. Normalmente envuelven su cadena de pensamiento en etiquetas especiales, permitiendo al sistema distinguir entre el trabajo de borrador y la salida final. El cambio reciente de Ollama intentó optimizar cómo funcionan juntas estas dos características tratando el bloque de razonamiento y la respuesta final como una secuencia gramatical continua única. Sin embargo, esta optimización asumía que el bloque de razonamiento siempre estaría presente, creando un punto ciego para las respuestas directas.

Por qué importa

Para equipos que ejecutan infraestructura de IA autoalojada, la fiabilidad es primordial. Este error introduce un modo de fallo silencioso donde las aplicaciones reciben datos que parecen válidos en la capa de transporte pero fallan en la capa de aplicación. Si tu backend espera un objeto JSON con claves específicas y recibe una cadena simple en su lugar, puede colgar o comportarse de manera impredecible. Como el error no aparece en los registros del servidor, la depuración puede llevar mucho tiempo, especialmente si el problema solo se activa en solicitudes simples que no requieren razonamiento complejo.

Además, esto destaca los riesgos de depender de funciones experimentales o recientemente fusionadas en entornos de producción. El cambio que causó este problema tenía la intención de mejorar el rendimiento y la consistencia, pero rompió un contrato fundamental de las salidas estructuradas. Los equipos que usan modelos de razonamiento para tareas de clasificación, extracción o Q&A simple deben asumir ahora que el cumplimiento del esquema es condicional a la decisión interna del modelo de razonar. Esta incertidumbre complica el diseño de agentes de IA robustos y requiere prácticas adicionales de codificación defensiva.

Qué puedes hacer

• Valida todas las respuestas estructuradas contra el esquema JSON esperado en tu aplicación cliente antes de procesarlas.
• Si el razonamiento no es necesario para una tarea específica, establece think: false para asegurar que el esquema se aplique directamente a la salida.
• Monitoriza las respuestas que carecen de la estructura esperada y regístralas por separado para su análisis.
• Usa el script del kit de herramientas comunitario check-ollama-format-think.sh para probar si tu modelo y versión específicos están afectados.
• Considera fijar (pin) tu versión de Ollama o evitar los modelos de razonamiento para tareas críticas de salida estructurada hasta que se publique una corrección.
• Revisa las pull requests abiertas, específicamente la #18783, para obtener actualizaciones sobre el estado del parche oficial.