Partager via

Migrer vers la version 3.x du conteneur OCR Read

  • Article

Si vous utilisez la version 2 du conteneur OCR Read d’Azure AI Vision, utilisez cet article pour savoir comment mettre à niveau votre application afin d’utiliser la version 3.x du conteneur.

Modifications d'API

Le conteneur Lecture v3.2 utilise la version 3 de l’API Azure AI Vision et a les points de terminaison suivants :

  • /vision/v3.2/read/analyzeResults/{operationId}
  • /vision/v3.2/read/analyze
  • /vision/v3.2/read/syncAnalyze

Pour plus d’informations sur la mise à jour de vos applications pour utiliser la version 3 de l’API Read, consultez le Guide de migration de l’API REST Azure AI Vision v3. Les opérations synchrones sont uniquement prises en charge dans les conteneurs.

Modifications de configuration

  • ReadEngineConfig:ResultExpirationPeriod n’est plus pris en charge. Le conteneur OCR Read comporte une tâche Cron intégrée qui supprime les résultats et les métadonnées associés à une requête au bout de 48 heures.
  • Cache:Redis:Configuration n’est plus pris en charge. Le cache n’étant pas utilisé dans les conteneurs v3.x, vous n’avez pas besoin de le définir.

Besoins en mémoire

Les exigences et les suggestions sont basées sur des tests d’évaluation effectués avec une seule requête par seconde, à partir d’une image de 523 Mo d’une lettre d’entreprise analysée qui contient 29 lignes et 803 caractères au total. Le tableau suivant décrit les allocations de ressources minimale et recommandée pour chaque conteneur OCR Read.

Conteneur Minimum Recommandé
Read 3.2 2022-04-30 4 cœurs, 8 Go de mémoire 8 cœurs, 16 Go de mémoire

Chaque cœur doit être cadencé à au moins 2,6 gigahertz (GHz).

Le cœur et la quantité de mémoire correspondent aux paramètres --cpus et --memory qui sont utilisés dans le cadre de la commande docker run.

Implémentations de stockage

Notes

MongoDB n’est plus pris en charge dans les versions 3.x du conteneur. En effet, les conteneurs prennent plutôt en charge le stockage Azure et les systèmes de fichiers hors connexion.

Implémentation Argument(s) de runtime nécessaire(s)
Niveau de fichier (par défaut) Aucun argument de runtime n’est nécessaire. Le répertoire /share sera utilisé.
Objets blob Azure Storage:ObjectStore:AzureBlob:ConnectionString={AzureStorageConnectionString}

Implémentations de file d’attente

Dans un conteneur v3.x, RabbitMQ n’est pas pris en charge pour l’instant. Les implémentations prises en charge sont les suivantes :

Implémentation Argument(s) de runtime Usage prévu
En mémoire (par défaut) Aucun argument de runtime n’est nécessaire. Développement et test
Files d'attente Azure Queue:Azure:ConnectionString={AzureStorageConnectionString} Production
RabbitMQ Indisponible Production

Pour une redondance accrue, le conteneur Read v3.x utilise un minuteur de visibilité permettant de vérifier que les requêtes peuvent être traitées correctement en cas d’incident lors de l’exécution dans une configuration à plusieurs conteneurs.

Définissez le minuteur avec Queue:Azure:QueueVisibilityTimeoutInMilliseconds, qui définit le délai à l’issue duquel un message devient invisible car un rôle de travail est en train de le traiter. Pour éviter le traitement redondant des pages, nous vous recommandons de définir le délai d’attente sur 120 secondes. La valeur par défaut est de 30 secondes.

Valeur par défaut Valeur recommandée
30000 120 000

Étapes suivantes