Référence technique
Architecture, pipeline de traitement, configuration système requise et benchmarks de performance pour Transkribus On-Prem.
Pipeline de traitement
Les étapes s'exécutent sous forme de pipeline en streaming. Pendant qu'une page est en cours de reconnaissance, la suivante est déjà en cours d'analyse de mise en page. Cela signifie que le débit en lot est nettement supérieur à ce que la latence d'une seule page laisserait supposer.
Moteurs de reconnaissance
HTR standard
Réseau de neurones encodeur-décodeur pour le texte manuscrit et imprimé. Optimisé pour le débit. Prend en charge l'entraînement de modèles personnalisés sur vos propres données et fonctionne avec le catalogue complet des modèles Transkribus publics et privés. Le support de modèle de langage améliore la précision sur le contenu spécifique au domaine.
- Écritures
- Latin, allemand (Kurrent, Fraktur), principales écritures européennes
- Précision
- CER 2–5 % sur documents propres, 5–10 % sur matériel difficile
- Débit
- ~2–3 s/page par GPU (à chaud, ~20 lignes/page)
- VRAM
- ~4 Go par modèle concurrent
Best for: Traitement en lot à grande échelle, écritures bien prises en charge, modèles entraînés sur mesure
Super Models
Architecture plus grande avec une couverture d'écritures plus large et une précision supérieure sur les documents difficiles. Accès au catalogue complet des Super Models Transkribus — des dizaines d'écritures et de langues, dont l'allemand historique, le latin, le grec, le cyrillique, l'hébreu, l'arabe et les écritures d'Asie orientale.
- Écritures
- Plus de 70 écritures dont latin, grec, cyrillique, hébreu, arabe, Asie orientale
- Précision
- CER 1–3 % sur les écritures courantes, 3–7 % sur les documents rares
- Débit
- ~4–5 s/page par GPU (à chaud, ~20 lignes/page)
- VRAM
- ~8 Go par modèle concurrent
Best for: Écritures rares, documents multilingues, exigences de précision maximale
Les deux moteurs peuvent être disponibles simultanément sur la même installation. L'utilisateur sélectionne par tâche. Utilisez HTR standard pour le traitement en lot à fort volume des écritures bien prises en charge. Utilisez Super Models lorsque vous travaillez avec des écritures rares, des documents multilingues ou lorsque la minimisation du CER est la priorité principale.
Analyse de mise en page
Détection automatique de la structure de la page avant la reconnaissance. Le modèle de mise en page identifie l'emplacement des zones de texte, des tableaux, des en-têtes et des autres régions de contenu, établit les lignes de base dans les régions de texte et détermine l'ordre de lecture. Plusieurs modèles de mise en page sont disponibles pour différents types de documents et périodes historiques.
- Régions de texte
- Lignes de base
- Ordre de lecture
- Tableaux
- En-têtes et pieds de page
- Marginalia
- Illustrations
- Lettres ornées
Tableaux et champs
Types de modèles dédiés à l'extraction de données structurées. Les modèles de tableaux détectent la structure de lignes et colonnes au sein des régions de tableaux identifiées lors de l'analyse de mise en page. Les modèles de champs extraient des valeurs à partir de formulaires et de documents standardisés dont la mise en page est connue. Les deux produisent une sortie structurée prête pour l'ingestion en base de données ou le traitement en aval.
- Extraction de tableaux avec structure de lignes et colonnes
- Reconnaissance du contenu des cellules dans les tableaux détectés
- Extraction de champs à partir de formulaires et de types de documents standardisés
- Sortie structurée intégrée au PageXML ou export autonome
- Modèles de champs personnalisés pour les mises en page de documents spécifiques au domaine
Formats de sortie
| Format | What's included | Typical use |
|---|---|---|
| PageXML | Lignes de base, polygones, texte, confiance par caractère, métadonnées | Réintégration dans Transkribus, édition savante, préservation |
| ALTO XML | Structure OCR standard pour les bibliothèques | Conteneurs METS, dépôts institutionnels, Europeana |
| PDF consultable | Couche de texte invisible au niveau des mots sur le scan original | Accès utilisateur final, recherche plein texte, citation |
| Texte brut | Texte UTF-8, un fichier par page | Indexation plein texte, pipelines NLP, constitution de corpus |
Entraînement de modèles
Entraînez des modèles de reconnaissance personnalisés sur vos propres documents. Tout l'entraînement s'exécute localement sur votre GPU — aucune donnée ne quitte votre infrastructure.
- Préparer la vérité terrain
Transcrivez un échantillon de vos documents — généralement 50 à 100 pages pour affiner un modèle de base existant. Le tableau de bord web inclut des outils d'édition de vérité terrain.
- Entraîner
Sélectionnez un modèle de base et démarrez l'entraînement sur votre GPU. La durée d'entraînement est généralement de 2 à 6 heures pour un affinage, selon la taille du jeu de données et le matériel.
- Évaluer
Le système rapporte le CER (taux d'erreur au caractère) sur un ensemble de validation non vu. Comparez avec le modèle de base pour mesurer l'amélioration.
- Déployer
Publiez le modèle entraîné dans votre registre de modèles local. Il devient immédiatement disponible pour les tâches de reconnaissance — aucun redémarrage requis.
Architecture extensible
Le pipeline de traitement est conçu comme un framework, pas une séquence fixe. De nouvelles architectures de modèles et de nouvelles tâches de reconnaissance peuvent être intégrées au fil du temps — le système n'est pas limité à l'ensemble actuel de modèles HTR, mise en page, tableaux et champs. L'architecture conteneurisée permet d'ajouter de nouvelles étapes de traitement sans perturber les workflows existants.
Architecture
Workstation
Déploiement sur serveur unique avec Docker Compose. Tous les services s'exécutent sur une seule machine — tableau de bord web, moteur de reconnaissance, entraînement, base de données et stockage local. Installation en une après-midi. Pas de Kubernetes, pas d'infrastructure de cluster. Les modèles restent chargés sur le GPU d'une tâche à l'autre pour un démarrage en moins d'une seconde sur les pages suivantes.
Enterprise (Kubernetes / OpenShift)
Déploiement natif Kubernetes avec mise à l'échelle horizontale. Chaque étape du pipeline monte en charge indépendamment via HPA. L'inférence GPU utilise une architecture serveur/client — un seul GPU sert plusieurs clients. Prend en charge les GPU NVIDIA complets et les partitions MIG. Coordination des événements via Redis pub/sub. Stockage via un stockage objet compatible S3 (MinIO, Ceph, AWS S3). Déployé via Helm avec ArgoCD recommandé pour GitOps. Mises à jour progressives sans interruption.
Configuration système requise
Workstation
| Composant | Minimum | Recommandé |
|---|---|---|
| OS | Ubuntu 22.04+ / Windows Server 2022 | Ubuntu 22.04 LTS |
| CPU | 8 cores | 16+ cores |
| RAM | 32 GB | 64 GB |
| GPU | NVIDIA, 12 GB VRAM (RTX 3060+) | RTX 4090 / A6000 (24 GB VRAM) |
| Storage | 500 GB SSD | 1 TB+ NVMe |
| NVIDIA Driver | 565.57+ | Latest stable |
| CUDA | 12.4+ | 12.4+ |
| Docker | 24.0+ | Latest stable |
Enterprise
| Composant | Exigence |
|---|---|
| Orchestration | Kubernetes 1.27+ or OpenShift 4.x |
| GPU Operator | NVIDIA GPU Operator with MIG support |
| Storage | S3-compatible object storage (MinIO, Ceph, AWS S3) |
| GPU per worker | NVIDIA A100 or H100 recommended (MIG partitioning supported) |
| Event coordination | Redis (pub/sub for job coordination) |
| Monitoring | Prometheus + Grafana (metrics exported natively) |
| Deployment | Helm chart provided, ArgoCD recommended |
| NVIDIA Driver | 565.57+ / CUDA 12.4+ |
Performances
Benchmarks de débit à ~20 lignes par page. Les résultats réels dépendent de la complexité des documents, de leurs dimensions et du nombre de lignes par page. Les pages peu denses s'exécutent plus rapidement, les pages denses plus lentement — approximativement linéaire avec le nombre de lignes.
Workstation (GPU unique, RTX 3090)
| Workload | Standard HTR | Super Models |
|---|---|---|
| Single page (cold start) | ~10 s | ~13 s |
| Per page (warm, amortized) | ~3 s | ~5 s |
| Archive box (100 pages) | ~5 min | ~8 min |
| Archival run (500 pages) | ~25 min | ~42 min |
| Daily throughput (24 h) | ~27,000 pages | ~16,500 pages |
Enterprise (par A100)
| Workload | Standard HTR | Super Models |
|---|---|---|
| Per page (warm, amortized) | ~2 s | ~4 s |
| Archive box (100 pages) | ~3.5 min | ~7 min |
| Archival run (500 pages) | ~17 min | ~33 min |
| Daily per GPU (24 h) | ~42,000 pages | ~21,000 pages |
| 8× A100 cluster (24 h) | ~300,000 pages | ~168,000 pages |
Le démarrage à froid ajoute 5 à 10 secondes pour le chargement du modèle. Les pages suivantes dans le même lot utilisent le débit à chaud ci-dessus. Le débit s'adapte linéairement au nombre de GPU — ajoutez des réplicas de serveur d'inférence avec des GPU dédiés ou des partitions MIG pour multiplier la capacité.
API et intégration
Transkribus On-Prem expose des points d'intégration pour incorporer la reconnaissance dans vos workflows existants, vos systèmes d'archives et vos pipelines en aval.
REST API
Soumettez des tâches, interrogez le statut et récupérez les résultats via HTTP. Spécification OpenAPI exposée aux adresses /openapi.json et /openapi.yaml — générez des clients dans n'importe quel langage. Disponible dans l'édition Enterprise.
Ingestion S3
Déposez des fichiers dans un compartiment S3/MinIO désigné et les tâches démarrent automatiquement. Les résultats apparaissent dans S3 sous forme de PageXML, ALTO, TXT ou PDF. Édition Enterprise.
API de streaming
Interface de streaming en direct ouverte pour les résultats en temps réel. Les résultats sortent ligne par ligne au fur et à mesure que les pages sont traitées — intégrez-les dans vos propres tableaux de bord ou workflows en aval.
Compatibilité Transkribus
Les noms de fichiers, les métadonnées et la sortie PageXML se réintègrent proprement dans Transkribus. Compatible avec les intégrations Transkribus existantes — pas de réécriture de workflow nécessaire.