Riferimento tecnico
Architettura, pipeline di elaborazione, requisiti di sistema e benchmark delle prestazioni per Transkribus On-Prem.
Pipeline di elaborazione
Le fasi vengono eseguite come una pipeline in streaming. Mentre una pagina è in fase di riconoscimento, la successiva sta già subendo il rilevamento del layout. Ciò significa che il throughput batch è significativamente superiore a quanto suggerirebbe la latenza per singola pagina.
Motori di riconoscimento
HTR standard
Rete neurale encoder-decoder per testo manoscritto e a stampa. Ottimizzata per il throughput. Supporta l'addestramento di modelli personalizzati sui propri dati e funziona con l'intero catalogo di modelli Transkribus pubblici e privati. Il supporto del modello linguistico migliora la precisione sui contenuti specifici del dominio.
- Scritture
- Latino, tedesco (Kurrent, Fraktur), principali scritture europee
- Precisione
- CER 2–5% su documenti puliti, 5–10% su materiale impegnativo
- Throughput
- ~2–3 s/pagina per GPU (a regime, ~20 righe/pagina)
- VRAM
- ~4 GB per modello concorrente
Best for: Elaborazione batch su larga scala, scritture ben supportate, modelli addestrati su misura
Super Models
Architettura più ampia con copertura più estesa delle scritture e maggiore precisione su materiale difficile. Accesso all'intero catalogo Transkribus Super Models — decine di scritture e lingue, incluso tedesco storico, latino, greco, cirillico, ebraico, arabo e scritture dell'Asia orientale.
- Scritture
- 70+ scritture incluse latino, greco, cirillico, ebraico, arabo, Asia orientale
- Precisione
- CER 1–3% su scritture comuni, 3–7% su materiale raro
- Throughput
- ~4–5 s/pagina per GPU (a regime, ~20 righe/pagina)
- VRAM
- ~8 GB per modello concorrente
Best for: Scritture rare, documenti multilingue, requisiti di massima precisione
Entrambi i motori possono essere disponibili simultaneamente sulla stessa installazione. L'utente seleziona per ogni job. Utilizza l'HTR standard per l'elaborazione batch ad alto volume di scritture ben supportate. Utilizza i Super Models quando si lavora con scritture rare, documenti multilingue o quando minimizzare il CER è la preoccupazione principale.
Analisi del layout
Rilevamento automatico della struttura della pagina prima del riconoscimento. Il modello di layout identifica dove si trovano testo, tabelle, intestazioni e altre regioni di contenuto, stabilisce le linee di base all'interno delle regioni di testo e determina l'ordine di lettura. Sono disponibili più modelli di layout per diversi tipi di documenti e periodi storici.
- Regioni di testo
- Linee di base
- Ordine di lettura
- Tabelle
- Intestazioni e piè di pagina
- Marginalia
- Illustrazioni
- Capilettera
Tabelle e campi
Tipi di modelli dedicati per l'estrazione di dati strutturati. I modelli di tabelle rilevano la struttura a righe e colonne all'interno delle regioni tabellari identificate durante l'analisi del layout. I modelli di campi estraggono valori da moduli e documenti standardizzati con layout noti. Entrambi producono output strutturato pronto per l'inserimento in database o l'elaborazione successiva.
- Estrazione di tabelle con struttura a righe e colonne
- Riconoscimento del contenuto delle celle all'interno delle tabelle rilevate
- Estrazione di campi da moduli e tipi di documento standardizzati
- Output strutturato come parte di PageXML o esportazione autonoma
- Modelli di campi personalizzati per layout di documenti specifici del dominio
Formati di output
| Format | What's included | Typical use |
|---|---|---|
| PageXML | Linee di base, poligoni, testo, confidenza per carattere, metadati | Round-trip con Transkribus, edizione accademica, conservazione |
| ALTO XML | Struttura OCR standard delle biblioteche | Container METS, repository istituzionali, Europeana |
| PDF ricercabile | Livello testuale invisibile a livello di parola sulla scansione originale | Accesso utente finale, ricerca full-text, citazione |
| Testo semplice | Testo UTF-8, un file per pagina | Indicizzazione full-text, pipeline NLP, costruzione di corpora |
Addestramento modelli
Addestra modelli di riconoscimento personalizzati sui tuoi documenti. Tutto l'addestramento avviene localmente sulla tua GPU — nessun dato lascia la tua infrastruttura.
- Prepara il ground truth
Trascrivi un campione dei tuoi documenti — tipicamente 50–100 pagine per il fine-tuning di un modello base esistente. La dashboard web include strumenti per la modifica del ground truth.
- Addestra
Seleziona un modello base e avvia l'addestramento sulla tua GPU. Il tempo di addestramento è tipicamente 2–6 ore per un fine-tuning, a seconda della dimensione del dataset e dell'hardware.
- Valuta
Il sistema riporta il CER (Character Error Rate) su un set di validazione separato. Confronta con il modello base per misurare il miglioramento.
- Deploy
Pubblica il modello addestrato nel registro dei modelli locale. Diventa disponibile per i job di riconoscimento immediatamente — nessun riavvio necessario.
Architettura estensibile
La pipeline di elaborazione è progettata come un framework, non come una sequenza fissa. Nuove architetture di modelli e nuovi compiti di riconoscimento possono essere integrati nel tempo man mano che diventano disponibili — il sistema non è limitato all'insieme attuale di modelli HTR, layout, tabelle e campi. L'architettura containerizzata consente di aggiungere nuove fasi di elaborazione senza disturbare i flussi di lavoro esistenti.
Architettura
Workstation
Deployment su server singolo con Docker Compose. Tutti i servizi girano su una sola macchina — dashboard web, motore di riconoscimento, addestramento, database e storage locale. Configurazione in un pomeriggio. Nessun Kubernetes, nessuna infrastruttura cluster. I modelli rimangono caricati sulla GPU tra i job per un avvio sotto il secondo sulle pagine successive.
Enterprise (Kubernetes / OpenShift)
Deployment nativo Kubernetes con scaling orizzontale. Ogni fase della pipeline scala in modo indipendente tramite HPA. L'inferenza GPU utilizza un'architettura server/client — una singola GPU serve più client watcher. Supporta GPU NVIDIA complete e partizioni MIG. Coordinamento degli eventi tramite Redis pub/sub. Storage tramite object storage compatibile S3 (MinIO, Ceph, AWS S3). Distribuito tramite Helm con ArgoCD consigliato per GitOps. Rolling update senza downtime.
Requisiti di sistema
Workstation
| Componente | Minimo | Consigliato |
|---|---|---|
| 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
| Componente | Requisito |
|---|---|
| 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+ |
Prestazioni
Benchmark di throughput a ~20 righe per pagina. I risultati effettivi dipendono dalla complessità del documento, dalle dimensioni della pagina e dalle righe per pagina. Le pagine poco dense sono più veloci, quelle molto dense più lente — approssimativamente lineare con il numero di righe.
Workstation (GPU singola, 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 (per 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 |
Il cold start aggiunge 5–10 secondi per il caricamento del modello. Le pagine successive nello stesso batch utilizzano il throughput a regime indicato sopra. Il throughput scala linearmente con il numero di GPU — aggiungi repliche del server di inferenza con GPU dedicate o partizioni MIG per moltiplicare la capacità.
API e integrazione
Transkribus On-Prem espone punti di integrazione per incorporare il riconoscimento nei vostri flussi di lavoro esistenti, sistemi d'archivio e pipeline successive.
REST API
Invia job, interroga lo stato e recupera i risultati via HTTP. Specifica OpenAPI esposta a /openapi.json e /openapi.yaml — genera client in qualsiasi linguaggio. Disponibile nell'edizione Enterprise.
Ingestione S3
Deposita file in un bucket S3/MinIO designato e i job partono automaticamente. I risultati tornano in S3 come PageXML, ALTO, TXT o PDF. Edizione Enterprise.
API di streaming
Interfaccia di streaming live aperta per risultati in tempo reale. I risultati escono riga per riga man mano che le pagine vengono elaborate — integra nei propri dashboard o flussi di lavoro successivi.
Compatibilità Transkribus
Nomi file, metadati e output PageXML si integrano perfettamente con Transkribus. Compatibile con le integrazioni Transkribus esistenti — nessuna riscrittura del flusso di lavoro necessaria.