Mistral OCR 4.1: qué debe volver a validar un equipo cuando cambian el texto, la estructura y las coordenadas de un flujo documental

El cambio anunciado afecta al contrato de salida, no solo al reconocimiento de caracteres

Mistral AI identifica la versión como `mistral-ocr-4-1`. La documentación del proveedor sitúa su lanzamiento el 16 de julio de 2026 y registra su disponibilidad general el 31 de agosto de ese mismo año. El registro de cambios también indica que los alias `mistral-ocr-latest` y `mistral-ocr-4` pasaron a resolver hacia OCR 4.1. Para un equipo que consume uno de esos alias, la actualización puede producirse sin que cambie necesariamente el nombre usado en la solicitud.

Eso convierte la actualización en una cuestión de compatibilidad operativa. Un sistema que usa OCR como primer paso para indexar expedientes, extraer campos, clasificar documentos o preparar una revisión humana no recibe únicamente una cadena de texto. Puede depender de páginas, fragmentos en Markdown, bloques, etiquetas estructurales, tablas, dimensiones del documento y posiciones espaciales. Si cualquiera de esas representaciones cambia, un proceso posterior puede fallar o degradarse aunque el texto visible parezca mejor.

La página del modelo declara cajas delimitadoras por párrafo, etiquetas estructurales y puntuaciones de confianza por bloque. El registro de cambios, por su parte, menciona la incorporación de granularidad de confianza a nivel de bloque. Estas capacidades pueden aportar más señales para priorizar revisiones, pero obligan a definir cómo se almacenan, comparan y consumen. No debe asumirse que una señal de confianza sea equivalente a una garantía de corrección semántica de una cláusula, un importe o una identidad.

Qué expone el endpoint y por qué debe compararse antes de migrar

La referencia del endpoint de OCR describe una petición a `POST /v1/ocr` y opciones que condicionan la forma de procesar y devolver el documento. Entre ellas figuran la modalidad de documento, la selección de páginas, la inclusión de bloques, el formato de tablas, los formatos de anotación y las granularidades de las puntuaciones de confianza. No todas estas opciones tienen por qué estar activas en una integración existente; precisamente por ello, la configuración efectiva debe formar parte de la prueba.

La guía del procesador OCR describe resultados organizados por página y contenido que puede incluir Markdown, tablas, cabeceras, pies, dimensiones, imágenes y bloques. También señala que `include_blocks` requiere OCR 4 o posterior, mientras que la información de tabla, cabecera y pie requiere OCR 2512 o posterior. Un equipo debe confirmar la versión realmente invocada y las opciones aceptadas en su cuenta antes de inferir que un campo estará disponible.

La comparación no debe limitarse a comprobar si el JSON sigue siendo válido. Hay que contrastar el esquema de cada objeto que usa la aplicación, la presencia o ausencia de valores, el orden de lectura de los bloques, la asociación con página y las coordenadas o cajas delimitadoras cuando se empleen para resaltar evidencia. También conviene verificar que los extractores de tablas no estén suponiendo columnas, encabezados o saltos de fila que el OCR pueda representar de otro modo.

Cinco comprobaciones de compatibilidad que conviene convertir en pruebas

La primera comprobación es el esquema. Guarde respuestas de referencia de la versión anterior y de OCR 4.1 para los mismos documentos, con idénticas opciones. Compare nombres de campos, tipos, campos opcionales y valores nulos. Si el sistema transforma la respuesta antes de almacenarla, pruebe tanto la respuesta original como el JSON transformado; muchos problemas aparecen en adaptadores, validadores de esquema o serializadores, no en el OCR aislado.

La segunda es la segmentación. Un modelo puede dividir un párrafo, unir dos bloques próximos o identificar de forma distinta cabeceras y pies. Esas variaciones pueden alterar reglas que asignan texto a una sección contractual o que excluyen elementos repetidos. Mida cuántos bloques cambian y, sobre todo, si el cambio modifica la salida de los procesos consumidores.

La tercera comprobación es la reconstrucción de tablas. Seleccione documentos con tablas complejas, celdas combinadas, formularios, columnas estrechas, escritura escaneada y baja calidad de imagen. Evalúe campos de negocio concretos, no solo la similitud global con una transcripción. Por ejemplo, en una factura pueden ser el total, la moneda, los impuestos, los identificadores de línea y su correspondencia con la fila correcta.

La cuarta es la trazabilidad espacial. Cuando una aplicación muestra al revisor la fuente de una extracción, debe comprobar que el texto, la página y la región señalada sigan coincidiendo. El hecho de que se disponga de cajas delimitadoras por párrafo no permite deducir, sin una prueba propia, que toda cita generada anteriormente conservará la misma geometría o segmentación.

La quinta es el comportamiento operativo. Registre el tiempo de respuesta, los errores, los reintentos, el volumen procesado y la proporción de casos que requieren corrección humana. La documentación del endpoint contempla modalidades y parámetros de procesamiento; la carga, el tipo de archivo y la configuración pueden afectar al resultado observado. Los límites y el comportamiento efectivo deben validarse en el entorno y la cuenta que se vayan a usar.

Prueba de migración: corpus congelado, doble ejecución y condiciones de reversión

La prueba mínima debe usar un corpus congelado y representativo, con una referencia humana para los elementos críticos. Incluya documentos nativos y escaneados, idiomas presentes en producción, distintas resoluciones, páginas rotadas, formularios, tablas, cabeceras repetidas y los casos que históricamente han generado incidencias. Separe un conjunto de desarrollo de un conjunto final que no se emplee para ajustar reglas durante la migración.

Ejecute ambos recorridos con el mismo documento de entrada y conserve el identificador de modelo, los parámetros, la hora, el resultado original y el resultado transformado. La inferencia regional de Mistral recomienda registrar el hostname, el modelo, la hora y el identificador de solicitud con fines de auditoría. Esa disciplina permite investigar una diferencia sin atribuirla de inmediato al modelo.

Defina umbrales antes de observar los resultados. Algunos pueden ser exactitud de campos críticos, proporción de citas correctas por página, integridad de tablas, tasa de error técnico, percentiles de latencia y tasa de revisión o corrección humana. También establezca qué diferencia justifica detener el despliegue. Un canary con tráfico limitado y doble ejecución sin afectar la decisión de negocio suelen reducir el riesgo frente a sustituir el modelo para todo el tráfico de una vez.

La decisión no tiene que ser binaria. Si OCR 4.1 mejora unos tipos documentales y empeora otros, el equipo puede mantener rutas diferenciadas mientras corrige sus consumidores o revisa el criterio de selección. Esa es una decisión de arquitectura y operación basada en mediciones internas, no una conclusión que pueda extraerse de las capacidades declaradas por el proveedor.

Retención, archivos y región: aspectos que no deben quedar fuera de la evaluación

La documentación de retención cero de datos incluye el endpoint de OCR entre los compatibles con esa modalidad. Sin embargo, la misma documentación excluye de esa cobertura la API de archivos y los archivos de procesamiento por lotes. Por tanto, no basta con conocer el modelo seleccionado: el equipo debe revisar por qué ruta se entrega cada documento y qué servicios auxiliares intervienen en el flujo.

La documentación de inferencia regional describe endpoints regionales, incluido un endpoint europeo. La elección de región, cuando esté disponible para la integración, puede ser relevante para requisitos internos de auditoría, residencia o trazabilidad. No obstante, la existencia de un endpoint regional no sustituye la revisión jurídica, contractual y de seguridad que corresponda a cada organización.

Conviene documentar por separado la retención, la vía de carga, la región, los permisos de acceso, los plazos de conservación internos y la eliminación de artefactos derivados. Son controles del flujo completo, no propiedades que puedan deducirse de la calidad del reconocimiento. Si la aplicación procesa información sensible, esa revisión debe preceder al despliegue y actualizarse cuando cambien los componentes utilizados.

Conclusión: fijar la evidencia antes de cambiar la ruta de producción

Mistral OCR 4.1 aporta una versión identificable, disponibilidad general documentada y señales estructurales que pueden resultar útiles en aplicaciones documentales. El hecho más relevante para una integración existente es que ciertos alias pasaron a apuntar a esa versión. Por ello, equipos que dependan de alias deberían tratar el cambio como una modificación potencial de contrato y no como una actualización transparente.

La validación prudente compara salidas y consecuencias: no solo caracteres reconocidos, sino campos de negocio, estructura de tablas, referencias por página, geometría, rendimiento y carga de revisión. La evidencia necesaria para aprobar la migración debe proceder de un protocolo reproducible sobre documentos propios, con umbrales explícitos y una reversión disponible. Las afirmaciones del proveedor ayudan a delimitar qué probar; no reemplazan esa comprobación.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.