OpenOCR ahora detecta resultados vacíos de Gemini 3.1 Flash-Lite y de cualquier motor posterior

8 de octubre de 2026. OpenOCR ahora detecta cuándo un motor lee una página y no devuelve nada. En lugar de un resultado vacío que parece un éxito, obtienes un error claro que explica el motivo. Nunca pagas más de lo que el proveedor cobró por el intento y, en un PDF de varias páginas, se conserva cada página que sí se haya procesado.

El patrón comenzó con Gemini 3.1 Flash-Lite, pero la protección aplica a todos los motores en OpenOCR.

Lo que detectamos

Nuestro sistema de monitorización detectó un patrón en Gemini 3.1 Flash-Lite de Google, uno de los motores más utilizados en OpenOCR. En una pequeña proporción de documentos reales (formularios, tarjetas y cartas con texto impreso legible), no devolvía texto alguno, mientras que la API de Google reportaba la solicitud como exitosa. En los últimos 30 días, esto ocurrió en cerca del 3 por ciento de las páginas procesadas con Flash-Lite, y representó casi la totalidad de los resultados vacíos observados en la plataforma: alrededor del 97 por ciento.

Un tres por ciento es fácil de pasar por alto en un puñado de solicitudes. Sin embargo, a escala de procesamiento documental, implica que un flujo de trabajo puede recibir abundante texto de calidad mientras pierde páginas legibles. La señal de éxito del proveedor hacía que esas pérdidas parecieran tareas completadas con éxito.

Reintentar no servía de mucho. La misma imagen volvía a resultar vacía entre el 80 y el 93 por ciento de las veces, por lo que repetir la solicitud solo suponía una pérdida de tiempo.

Ante un rechazo con un motivo explícito, el siguiente paso es utilizar un motor distinto.

Cómo es la respuesta ahora

Antes de este cambio, una página legible podía generar una tarea exitosa sin texto extraído. A continuación, se muestra un ejemplo abreviado con los campos pertinentes:

{
  "status": "succeeded",
  "extracted_text": ""
}

Ahora, el rechazo de un proveedor es explícito. Este es un ejemplo abreviado en el que Google nos facturó el intento, por lo que la solicitud traslada únicamente ese coste y nada más:

{
  "status": "failed_charged",
  "error_code": "provider_refused",
  "cost_debited": 0.000327,
  "provider_error": "Google declined to read this image (reason: SAFETY). Sending it to this engine again will give the same result; try a different engine."
}

La tarea ya no indica que se entregó texto OCR utilizable. La facturación se ajusta al cobro real del proveedor, tal y como se describe a continuación.

Diseñado para todos los motores, no solo para uno

Gemini fue donde lo detectamos, pero este fallo no tiene nada de exclusivo de Google. Cualquier modelo de visión puede presentarlo, y algunos otros motores lo mostraron de forma ocasional. Por eso, en lugar de parchar un único motor, modificamos la forma en que OpenOCR gestiona una respuesta vacía proveniente de cualquier motor:

Una respuesta clara en lugar de un resultado en blanco. Un resultado vacío se reporta como un error con uno de dos códigos:

• provider_refused: el proveedor rechazó la solicitud y nos indicó el motivo, por ejemplo, un filtro de seguridad. El error especifica la causa y advierte que enviar la página nuevamente al mismo motor producirá el mismo resultado.
• provider_empty: el modelo no devolvió nada y no proporcionó ningún motivo. OpenOCR vuelve a leer la página de forma automática una vez más antes de reportar el fallo.

Estos códigos permiten que tu aplicación distinga entre un rechazo conocido y una respuesta vacía sin explicación. OpenOCR realiza ese intento adicional en este último caso antes de devolver el error.

Facturación justa. Si el proveedor nos facturó el intento, tú pagas exactamente ese coste, sin recargos y nunca por encima de tu presupuesto acordado. Si no nos cobró nada, tú no pagas nada. Es exactamente igual que llamar a la API del proveedor directamente.

Los PDF conservan las páginas válidas. Si una página de un PDF de 30 páginas resulta vacía, conservas las otras 29, y la página vacía se marca con su número de página correspondiente. Un documento solo falla si ninguna de sus páginas devolvió texto.

Consideremos un escaneo de 30 páginas enviado a Flash-Lite. Las páginas 1 a 11 devuelven texto, la página 12 vuelve vacía y las páginas 13 a 30 devuelven texto. OpenOCR entrega las 29 páginas correctas con una advertencia que señala la página 12. Puedes enviar esa página a otro motor o revisarla manualmente. El cobro nunca excederá la cotización.

Supervisión en cada motor. Ahora monitorizamos la tasa de resultados vacíos de cada motor de forma continua, de modo que si otro modelo comienza a presentar este comportamiento, lo detectaremos en menos de una hora.

Gemini ahora explica sus motivos

Gemini 3.1 Flash-Lite ahora se ejecuta sobre la API nativa de Google. El endpoint que utilizábamos anteriormente reportaba estos rechazos únicamente como "other". La API nativa indica por qué se rechazó una página, y ese motivo ahora se incluye en el error que recibes.

Las solicitudes bloqueadas ahora también se descartan tras 60 segundos en lugar de tres minutos, lo que te permite cambiar de motor con mayor rapidez. La latencia normal de Flash-Lite ronda los 3,6 segundos, y su percentil 99 se sitúa en torno a los 12 segundos. Un timeout de 180 segundos retenía las solicitudes bloqueadas durante mucho más tiempo del observado; 60 segundos sigue ofreciendo un margen holgado por encima del rango habitual.

Cómo monitorizamos esto ahora

Hacemos un seguimiento horario de la tasa de resultados vacíos de cada motor y alertamos al equipo cuando alcanza el 5 por ciento. Una tasa de éxito global puede mantenerse en niveles óptimos mientras un modelo en particular devuelve respuestas en blanco. Esta señal por motor nos indica dónde investigar.

Para desarrolladores

Nada en tu integración dejará de funcionar. Simplemente dejarás de recibir éxitos vacíos. Si reintentas los fallos, comprueba el código de error: redirige una página con provider_refused a un motor distinto en lugar de repetir la solicitud. Con decenas de motores detrás de una sola API key y un único saldo en OpenOCR, esto solo requiere cambiar una palabra en el campo engine.

Para los PDF, conserva la advertencia de página junto con el texto devuelto para poder identificar la omisión y decidir qué hacer con dicha página.

Preguntas que podrías tener

¿Se romperá mi integración? No. Una página sin texto extraído ya no aparecerá como un resultado de OCR exitoso. Si tu código reintenta cada fallo, utiliza error_code para evitar repetir una solicitud con provider_refused en el mismo motor.

¿Debo pagar por las páginas rechazadas? Únicamente en la medida en que el proveedor le haya facturado el intento a OpenOCR. Pagas ese coste exacto, sin recargos y nunca por encima de la cotización. Si el proveedor no nos facturó, no pagas nada.

¿Por qué no cambiar de motor automáticamente? Elegiste ese modelo deliberadamente. Otro motor podría tener un precio o un formato de salida diferente. Te informamos de lo ocurrido y dejamos la decisión en tus manos.

¿Qué motores se ven afectados? Identificamos este patrón principalmente en Gemini 3.1 Flash-Lite, que representó cerca del 97 por ciento de los resultados vacíos de la plataforma en los últimos 30 días. Algunos otros motores lo mostraron ocasionalmente. La detección y el reporte ahora cubren todos los motores.

¿Qué debería hacer con las páginas separadoras en blanco? Gestiona los separadores conocidos como parte de tu flujo de trabajo documental. Para hojas en blanco o el reverso de escaneos, utiliza un motor de OCR dedicado para esas páginas. También estamos realizando pruebas para evaluar cuándo los modelos de visión inventan texto en ellas.

Próximo paso: medir el texto inventado

Durante las pruebas de este lanzamiento, le enviamos a Gemini 3.1 Flash-Lite una página blanca completamente vacía. No devolvió un resultado vacío. En las cuatro ocasiones inventó texto: un párrafo sobre negocios, una demostración matemática, una carta de un cliente y "THE END OF THE CHAPTER". Esto ocurre en ambos endpoints de Google, por lo que es un comportamiento inherente al modelo en sí.

Un motor que inventa texto es más difícil de detectar que uno que no devuelve nada, ya que la salida parece real. Por ello, estamos incorporando una prueba de páginas en blanco llamada HallucinationBench al benchmark de OpenOCR: una evaluación pública para determinar qué modelos de OCR ven texto en una página en blanco. Los resultados se publicarán en las clasificaciones de OpenOCR con el icono de un fantasma, de modo que la tasa de texto inventado de cada motor pueda medirse y mostrarse junto a su precisión. Hasta entonces, si tus documentos incluyen páginas en blanco (como hojas separadoras o el reverso de escaneos), utiliza un motor de OCR especializado para esas páginas.