Referencia técnica
Arquitectura, pipeline de procesamiento, requisitos del sistema y referencias de rendimiento para Transkribus On-Prem.
Pipeline de procesamiento
Las etapas se ejecutan como un pipeline de streaming. Mientras se reconoce una página, la siguiente ya está siendo analizada en cuanto a su maquetación. Esto significa que el rendimiento en lote es significativamente mayor de lo que sugeriría la latencia de una sola página.
Motores de reconocimiento
HTR estándar
Red neuronal codificador-decodificador para texto manuscrito e impreso. Optimizada para el rendimiento. Admite el entrenamiento de modelos personalizados con sus propios datos y funciona con el catálogo completo de modelos públicos y privados de Transkribus. El soporte de modelos de lenguaje mejora la precisión en contenido específico del dominio.
- Escrituras
- Latín, alemán (Kurrent, Fraktur), principales escrituras europeas
- Precisión
- CER 2-5% en documentos limpios, 5-10% en material difícil
- Rendimiento
- ~2-3 s/página por GPU (en caliente, ~20 líneas/página)
- VRAM
- ~4 GB por modelo simultáneo
Best for: Procesamiento en lote a gran escala, escrituras bien admitidas, modelos entrenados a medida
Super Models
Arquitectura más amplia con mayor cobertura de escrituras y mayor precisión en material difícil. Acceso al catálogo completo de Super Models de Transkribus: docenas de escrituras e idiomas, incluido alemán histórico, latín, griego, cirílico, hebreo, árabe y escrituras del este asiático.
- Escrituras
- Más de 70 escrituras, incluidas latín, griego, cirílico, hebreo, árabe y del este asiático
- Precisión
- CER 1-3% en escrituras comunes, 3-7% en material poco frecuente
- Rendimiento
- ~4-5 s/página por GPU (en caliente, ~20 líneas/página)
- VRAM
- ~8 GB por modelo simultáneo
Best for: Escrituras poco frecuentes, documentos multilingües, requisitos de máxima precisión
Ambos motores pueden estar disponibles simultáneamente en la misma instalación. El usuario selecciona uno por trabajo. Use HTR estándar para el procesamiento en lote de alto volumen de escrituras bien admitidas. Use Super Models cuando trabaje con escrituras poco frecuentes, documentos multilingües o cuando minimizar el CER sea el objetivo principal.
Análisis de maquetación
Detección automática de la estructura de la página antes del reconocimiento. El modelo de maquetación identifica dónde se encuentran el texto, las tablas, los encabezados y otras regiones de contenido, establece líneas base dentro de las regiones de texto y determina el orden de lectura. Hay disponibles varios modelos de maquetación para distintos tipos de documentos y períodos históricos.
- Regiones de texto
- Líneas base
- Orden de lectura
- Tablas
- Encabezados y pies de página
- Notas marginales
- Ilustraciones
- Letras capitulares
Tablas y campos
Tipos de modelos dedicados para la extracción de datos estructurados. Los modelos de tablas detectan la estructura de filas y columnas dentro de las regiones de tabla identificadas durante el análisis de maquetación. Los modelos de campos extraen valores de formularios y documentos estandarizados con maquetaciones conocidas. Ambos producen una salida estructurada lista para su ingesta en bases de datos o procesamiento posterior.
- Extracción de tablas con estructura de filas y columnas
- Reconocimiento del contenido de las celdas dentro de las tablas detectadas
- Extracción de campos de formularios y tipos de documentos estandarizados
- Salida estructurada como parte de PageXML o exportación independiente
- Modelos de campos personalizados para maquetaciones de documentos específicas del dominio
Formatos de salida
| Format | What's included | Typical use |
|---|---|---|
| PageXML | Líneas base, polígonos, texto, confianza por carácter y metadatos | Integración con Transkribus, edición académica, preservación |
| ALTO XML | Estructura OCR estándar de biblioteca | Contenedores METS, repositorios institucionales, Europeana |
| PDF buscable | Capa de texto invisible a nivel de palabra sobre el escaneo original | Acceso de usuarios finales, búsqueda en texto completo, cita |
| Texto sin formato | Texto UTF-8, un archivo por página | Indexación de texto completo, canales NLP, construcción de corpus |
Entrenamiento de modelos
Entrene modelos de reconocimiento personalizados con sus propios documentos. Todo el entrenamiento se ejecuta localmente en su GPU: ningún dato abandona su infraestructura.
- Preparar los datos de referencia
Transcriba una muestra de sus documentos, normalmente entre 50 y 100 páginas para el ajuste fino de un modelo base existente. El panel de control web incluye herramientas de edición de datos de referencia.
- Entrenar
Seleccione un modelo base e inicie el entrenamiento en su GPU. El tiempo de entrenamiento suele ser de entre 2 y 6 horas para una ejecución de ajuste fino, según el tamaño del conjunto de datos y el hardware.
- Evaluar
El sistema informa del CER (tasa de error de caracteres) en un conjunto de validación reservado. Compare con el modelo base para medir la mejora.
- Implementar
Publique el modelo entrenado en su registro de modelos local. Queda disponible para los trabajos de reconocimiento de inmediato, sin necesidad de reiniciar.
Arquitectura extensible
El pipeline de procesamiento está diseñado como un framework, no como una secuencia fija. Con el tiempo se pueden integrar nuevas arquitecturas de modelos y tareas de reconocimiento a medida que estén disponibles: el sistema no se limita al conjunto actual de modelos de HTR, maquetación, tablas y campos. La arquitectura en contenedores permite añadir nuevas etapas de procesamiento sin interrumpir los flujos de trabajo existentes.
Arquitectura
Workstation
Implementación en un solo servidor con Docker Compose. Todos los servicios se ejecutan en una máquina: panel de control web, motor de reconocimiento, entrenamiento, base de datos y almacenamiento local. Configúrelo en una tarde. Sin Kubernetes ni infraestructura de clúster. Los modelos permanecen cargados en la GPU entre trabajos para un arranque en menos de un segundo en las páginas siguientes.
Enterprise (Kubernetes / OpenShift)
Implementación nativa de Kubernetes con escalado horizontal. Cada etapa del pipeline escala de forma independiente mediante HPA. La inferencia de GPU utiliza una arquitectura servidor/cliente: una sola GPU sirve a múltiples observadores cliente. Admite GPU NVIDIA completas y particiones MIG. Coordinación de eventos mediante Redis pub/sub. Almacenamiento mediante almacenamiento de objetos compatible con S3 (MinIO, Ceph, AWS S3). Se implementa mediante Helm con ArgoCD recomendado para GitOps. Actualizaciones continuas sin tiempo de inactividad.
Requisitos del sistema
Workstation
| Componente | Mínimo | Recomendado |
|---|---|---|
| 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+ |
Rendimiento
Referencias de rendimiento a ~20 líneas por página. Los resultados reales dependen de la complejidad del documento, las dimensiones de la página y el número de líneas por página. Las páginas con poco contenido se procesan más rápido; las muy densas, más despacio, de forma aproximadamente lineal con el número de líneas.
Workstation (GPU única, 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 (por 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 |
El arranque en frío añade entre 5 y 10 segundos para la carga del modelo. Las páginas siguientes del mismo lote utilizan el rendimiento en caliente indicado anteriormente. El rendimiento escala de forma lineal con el número de GPU: añada réplicas del servidor de inferencia con GPU dedicadas o particiones MIG para multiplicar la capacidad.
API e integración
Transkribus On-Prem expone puntos de integración para incorporar el reconocimiento en sus flujos de trabajo existentes, sistemas de archivo y canales de procesamiento posteriores.
REST API
Envíe trabajos, consulte el estado y recupere los resultados mediante HTTP. La especificación OpenAPI está expuesta en /openapi.json y /openapi.yaml: genere clientes en cualquier lenguaje. Disponible en la edición Enterprise.
Ingesta desde S3
Deposite archivos en un bucket de S3/MinIO designado y los trabajos se inician automáticamente. Los resultados aparecen de vuelta en S3 como PageXML, ALTO, TXT o PDF. Edición Enterprise.
API de streaming
Interfaz de streaming en tiempo real para resultados instantáneos. Los resultados se transmiten línea a línea a medida que se procesan las páginas: intégrelos en sus propios paneles de control o flujos de trabajo posteriores.
Compatibilidad con Transkribus
Los nombres de archivo, los metadatos y la salida PageXML se integran de vuelta en Transkribus sin problemas. Compatible con las integraciones existentes de Transkribus: no es necesario reescribir los flujos de trabajo.