OCR con modelo de visión del lado del servidor para documentos escaneados

Por qué los documentos escaneados rompen la extracción de texto

Pídele a un extractor de texto que lea un PDF escaneado y obtendrás casi nada. Un PDF producido por un procesador de textos lleva una capa de texto - los caracteres se almacenan como texto, y la extracción es trivial. Un PDF producido por un escáner es en cambio un sobre de imágenes de página: no hay ninguna capa de texto, solo píxeles. El parser del collector solo puede extraer lo que existe de verdad, así que las páginas de solo imagen vuelven vacías o casi, y un documento que en un visor parece perfectamente legible no contribuye en absoluto a la base de conocimiento.

Simmetric Chat lo maneja del lado del servidor, antes de que un documento alcance la fase de chunking y embedding. Cuando la ingestión detecta un PDF pobre en texto, la plataforma lo enruta a una pipeline OCR dedicada cuyo motor no es una biblioteca OCR clásica de reconocimiento de patrones, sino un modelo de lenguaje con capacidades de visión servido localmente vía Ollama. El resultado es Markdown extraído que preserva títulos, listas y estructura de tablas mucho mejor que un OCR a nivel de carácter - y todo corre íntegramente en tu infraestructura. Ningún documento abandona nunca la red para ser leído.

Este artículo describe cómo funciona la pipeline, qué controles expone y el paso de aprobación humana que impide que un modelo que lee mal contamine en silencio una base de conocimiento.

De los píxeles al Markdown: la pipeline

El OCR en Simmetric Chat es una pipeline del lado del servidor basada en jobs. Una subida cuyo texto extraído no pasa el precheck - por defecto, menos de unos 200 caracteres extraíbles marcan un documento como escaneado - se convierte en un job OCR, y un scheduler de polling retoma los jobs cada 10 segundos con un límite de concurrencia global, para que un lote de subidas no pueda saturar la máquina. Un documento individual atraviesa entonces cinco fases:

1. Carga. pdfjs-dist abre el PDF del lado del servidor y enumera las páginas, con un techo de 50 páginas por job como límite de seguridad contra procesamientos fuera de control.
2. Renderizado. Cada página se renderiza a una imagen PNG a una escala ampliada - 2x por defecto - para que incluso la letra pequeña de un escaneo de calidad fax llegue al modelo con una resolución legible.
3. Reconocimiento. Cada imagen de página se envía al modelo de visión de Ollama configurado como imagen base64, y el modelo transcribe la página como texto Markdown.
4. Protección. La transcripción bruta atraviesa una guarda anti-alucinación y un paso de limpieza de grounding. Los modelos de visión a veces anotan la salida con marcadores de grounding, o inventan contenido plausible cuando una página es realmente ilegible - ambos casos se interceptan aquí en lugar de guardarse.
5. Puntuación y ensamblaje. Cada página recibe una puntuación de calidad, las páginas se concatenan en un solo documento, y el job concluye con un resumen honesto: las páginas fallidas se cuentan y se reportan como páginas fallidas, nunca absorbidas en silencio en un resultado «completado» limpio.

Cada paso de esta lista ocurre en el servidor. El navegador nunca ejecuta el OCR, y no se llama a ninguna API OCR de terceros - el único salto de red va de tu servidor a tu instancia de Ollama.

Elección del modelo

El modelo de visión es configurable, y la pipeline incluye un pequeño registry de modelos que sabe dialogar con cada familia soportada:

• glm-ocr - el default (OCR_MODEL=glm-ocr:latest), un modelo de visión especializado en OCR. El registry lo enruta por el endpoint chat de Ollama, que para esta familia de modelos detecta el fin de la transcripción de forma más fiable.
• deepseek-ocr - una segunda familia optimizada para OCR que usa tokens de grounding; el registry le envía imágenes de una sola página y elimina los marcadores de grounding durante la limpieza.
• Cualquier modelo de visión genérico - los modelos que el registry no reconoce recaen en un prompt genérico por el endpoint generate de Ollama, así que incluso un modelo multimodal que ya ejecutes en local funciona.

Los parámetros ligados al modelo son variables de entorno, documentadas junto al resto de la superficie de configuración:

# OCR vision del lado del servidor
OCR_MODEL=glm-ocr:latest   # modelo de visión (soporta model:version)
OCR_TIMEOUT=600000         # 10 minutos - los modelos de visión son lentos
OCR_NUM_PREDICT=8192       # tokens máximos de salida por página

Un endpoint de prewarm permite a un administrador cargar el modelo en memoria antes del primer job, para que la primera subida escaneada del día no pague el coste de arranque en frío del modelo.

El humano en el bucle: aprobar o rechazar

La calidad de la transcripción varía con la calidad del escaneo, y una base de conocimiento es el lugar equivocado para descubrir que un modelo ha leído mal una página. Por eso la pipeline trata la salida OCR como un borrador, no como un hecho. Cada job produce un artefacto revisable: la vista previa mantiene el texto extraído ligado a la misma porción de página que el panel con la imagen, para que un revisor pueda verificar cualquier página comparándola con el escaneo del que proviene.

Desde el panel de ajustes OCR un administrador ve el catálogo de modelos, la lista de jobs con puntuaciones de calidad y credibilidad por página, y el propio flujo de trabajo:

• Aprobar - las páginas extraídas se aceptan y prosiguen: un job de archivo aprobado materializa las páginas en la base de conocimiento, y desde el resultado aprobado puede lanzarse una ejecución de síntesis.
• Rechazar - la salida se descarta y la decisión queda registrada en el job.

La automatización está disponible sin renunciar a la compuerta. Un hook de auto-aprobación guiado por eventos puede finalizar los jobs cuyas señales de calidad son limpias, y preserva deliberadamente el flujo de aprobación manual allí donde la decisión humana es el contrato - una importación enrutada explícitamente hacia una base de conocimiento nunca se auto-aprueba en silencio. En cualquier caso, los resúmenes de jobs siguen siendo honestos sobre la salud de las páginas: un job terminado con tres páginas fallidas lo declara en su resultado y en los logs.

El sentido del ceremonial es un invariante único: el texto entra en tu índice RAG solo tras un paso de calidad limpio o tras haber sido examinado por un humano.

Dónde va el texto extraído

La salida OCR aprobada vuelve al flujo normal de ingestión. Para los documentos subidos, el Markdown extraído sustituye la capa de texto que faltaba en el escaneo, y el documento prosigue con chunking, embedding e indexación para la búsqueda híbrida exactamente como un PDF nativo. Para los archivos, las páginas aprobadas pasan a formar parte de la base de conocimiento curada del workspace, donde wikilinks, backlinks y la pipeline de síntesis pueden operar sobre ellas como sobre cualquier otra página.

Como la pipeline es del lado del servidor, se compone con las garantías del resto de la plataforma: los filtros DLP siguen escaneando los contenidos antes de que salgan de la red, el RBAC sigue decidiendo quién puede lanzar jobs y aprobar resultados, y ningún punto del recorrido OCR exige una conexión saliente hacia un servicio OCR en la nube.

Ajustes prácticos

La mayoría de los despliegues solo requieren tres decisiones:

• Habilitarlo. OCR_ENABLED y OCR_PRECHECK_CHARS - el umbral de caracteres que enruta un PDF a la pipeline - se gestionan en los ajustes de administración.
• Elegir el modelo. glm-ocr:latest es un default sensato; el catálogo de modelos lista lo que el registry reconoce, la elección de modelo por job está disponible desde el panel de ajustes, e instrucciones personalizadas pueden afinar el comportamiento de transcripción para tu dominio documental.
• Presupuestar el tiempo. El OCR vision cambia velocidad por fidelidad. El timeout por defecto de 10 minutos y el techo de 50 páginas existen para que un escaneo patológico degrade en un fallo visible en vez de en un worker bloqueado.

Si tu corpus es sobre todo de PDFs nativos, rara vez notarás la pipeline: las capas de texto sanas evitan por completo el OCR. En el momento en que llega un documento escaneado, pasa por renderizado, modelo de visión y tu aprobación - y termina siendo buscable en lugar de invisible.

Lee la guía completa en la documentación →