OCR y documentos escaneados para IA: por qué fallan y cómo arreglarlos
Un PDF escaneado no es texto: es una fotografía de texto. Si su sistema de IA no aplica un OCR de calidad antes de indexar, acabará buscando dentro de imágenes y las respuestas citarán pasajes ilegibles o inventados. La buena noticia es que el problema se soluciona con tres pasos concretos: elegir un OCR adecuado, limpiar el texto que extrae y verificar manualmente el resultado antes de poner la base de conocimiento en producción.
Por qué los PDF escaneados «rompen» un sistema RAG
Un PDF nativo contiene una capa de texto: cada letra es un carácter que se puede seleccionar, copiar y buscar con Ctrl+F. Un PDF escaneado, en cambio, es una imagen rasterizada de una página: no hay caracteres, solo píxeles organizados en forma de letras. Cuando ese archivo se sube a un sistema de búsqueda semántica o RAG sin pasar antes por un OCR, el extractor no encuentra texto que trocear ni vectorizar, y el documento queda invisible para las preguntas o, peor aún, se indexa un texto corrupto lleno de símbolos sueltos que luego se cita como si fuera fiable. Esto es habitual con contratos antiguos, facturas en papel, actas notariales, convenios colectivos o expedientes administrativos que llevan años escaneados sin que nadie pensara que algún día alguien querría preguntarles cosas. Para entender qué pasa con ese texto una vez ya es texto limpio (cómo se trocea y se vectoriza), conviene repasar nuestra guía de /es/blog/estrategias-chunking-rag.
Qué es el OCR y por qué su calidad varía tanto
El OCR (reconocimiento óptico de caracteres) analiza los píxeles de una imagen y predice qué letra, número o símbolo representan. No es magia: es un modelo de reconocimiento de patrones que acierta mucho con un escaneo limpio en blanco y negro con letra de imprenta, y falla bastante con fotocopias de fotocopias, sellos superpuestos o fotos hechas con el móvil en ángulo. La calidad de salida depende de varios factores que conviene controlar antes de subir nada a una base de conocimiento.
- Resolución de escaneo: por debajo de 200 ppp el OCR comete muchos más errores; lo recomendable es escanear a 300 ppp o más
- Contraste e iluminación del original: fotocopias de fotocopias, manchas de humedad o sellos que tapan texto reducen drásticamente la precisión
- Inclinación de la página (skew), muy común cuando se escanea con el móvil en vez de con un escáner plano
- Tipografía poco estándar: letra manuscrita, fuentes decorativas o cursivas dan tasas de error altas incluso con buen OCR
- Idioma y caracteres especiales: la ñ, los acentos o los dígrafos del catalán, el euskera o el gallego necesitan el paquete de idioma correcto cargado en el motor OCR
- Diseño de página complejo: columnas, encabezados y números de página que se mezclan con el cuerpo del texto
Resolución y calidad del escaneo
Si tiene margen para decidir cómo se digitalizan los documentos, escanee en escala de grises o blanco y negro a 300 ppp con un escáner plano, no con la cámara del móvil en ángulo. Si solo dispone de fotos, al menos asegúrese de que la página ocupe todo el encuadre, esté bien iluminada y no tenga sombras cruzadas: son los tres factores que más mejoran el resultado del OCR sin cambiar de herramienta.
Idioma y caracteres especiales
Muchos motores de OCR asumen inglés por defecto y hay que indicar explícitamente el paquete de español (y de catalán, euskera o gallego si corresponde) para que reconozca correctamente acentos, la ñ y la puntuación propia. Un documento bilingüe o con nombres propios en varios idiomas suele necesitar una revisión adicional, porque el motor tiende a «corregir» palabras que no reconoce sustituyéndolas por otras parecidas en el idioma configurado.
El caso más difícil: tablas y formularios
Las tablas son el punto donde más OCR se rompe, porque el motor suele leer de izquierda a derecha y de arriba abajo, perdiendo la relación entre filas y columnas. El resultado es texto donde los números de una tabla de precios aparecen en el orden equivocado, o donde una celda fusionada confunde al extractor. Los formularios con casillas de verificación son todavía peores: una casilla marcada se puede leer como un carácter aleatorio, un símbolo extraño o directamente desaparecer.
Enfoques para extraer tablas de documentos escaneados
| Enfoque | Cuándo funciona bien | Limitación principal |
|---|---|---|
| OCR genérico a texto plano | Tablas muy sencillas, pocas columnas | Pierde la alineación fila-columna y mezcla celdas |
| OCR con detección de tablas (table-aware) | Tablas con bordes visibles y pocas celdas fusionadas | Falla con tablas sin líneas o con celdas combinadas |
| Revisión manual puntual | Documentos críticos con pocas tablas (contratos, balances) | No escala a cientos de páginas |
| Conversión a Markdown o CSV antes de indexar | Cuando la IA debe razonar sobre filas y columnas | Requiere un paso adicional en el pipeline de ingesta |
Formularios con casillas de verificación
Si sus documentos incluyen casillas marcadas, no confíe en que el OCR las interprete bien. Es más fiable transformar ese campo en texto explícito antes de indexar, por ejemplo «Casilla aceptación de condiciones: marcada», para que la búsqueda y las respuestas citadas puedan referirse a ese dato sin ambigüedad.
Limpiar el texto extraído antes de indexar
Incluso con un buen OCR, el texto resultante suele tener ruido que conviene limpiar antes de trocear y vectorizar el documento. Saltarse este paso significa que ese ruido se propaga a cada fragmento (chunk) y, por tanto, a cada respuesta que cite ese fragmento.
- Eliminar saltos de línea artificiales que cortan una frase a mitad, típico de un OCR que respeta el salto visual de cada línea impresa
- Unir palabras partidas por guion a final de línea, por ejemplo «docu-mento»
- Quitar encabezados y pies de página repetidos en cada hoja, que duplican ruido en todos los fragmentos
- Normalizar espacios múltiples y caracteres de control invisibles que el OCR a veces inserta
- Revisar confusiones típicas del motor: 0 por O, 1 por l o I, «rn» leído como «m», o el símbolo del euro mal reconocido
- Marcar explícitamente las tablas o convertirlas a un formato tabular legible, en vez de dejarlas como texto corrido
No hace falta un pipeline complejo
Un script sencillo con un puñado de expresiones regulares (reglas para unir guiones, quitar líneas repetidas o corregir confusiones frecuentes) suele resolver la mayoría de los errores detectados al revisar una muestra de páginas. No es necesario montar una infraestructura de limpieza sofisticada para empezar.
Cómo comprobar la extracción antes de indexar: checklist
Antes de publicar una base de conocimiento construida a partir de documentos escaneados, conviene dedicar media hora a comprobar que la extracción es fiable. Este proceso es barato y evita respuestas con fuentes citadas que en realidad apuntan a texto corrupto.
- Abra entre 5 y 10 páginas al azar y compare visualmente el original con el texto extraído
- Busque dentro del texto extraído dos o tres términos exactos que sepa que aparecen en el documento
- Revise aparte las páginas con tablas: compruebe que los números siguen alineados con su fila y columna correctas
- Verifique especialmente fechas, importes en euros, números de referencia y NIF o CIF, que son los datos que más se corrompen con un OCR mediocre
- Haga una pregunta al sistema cuya respuesta conozca de memoria y compruebe que coincide con el pasaje citado
- Si hay idiomas mezclados o nombres propios poco comunes, revise cómo los ha transcrito el OCR
- Lleve un registro simple de qué documentos eran escaneados y cuáles ya tenían texto nativo, para priorizar la revisión de los primeros
Una vez el sistema está en producción, conviene mantener el hábito de comprobar cómo se justifican las respuestas: nuestra guía sobre /es/blog/verificar-respuesta-ia-fuentes explica qué mirar en los pasajes citados para detectar que algo viene de una extracción defectuosa antes de que un usuario se dé cuenta por usted.
Flujo recomendado en la práctica
Para una pyme o un despacho que gestiona documentación en papel, el flujo razonable es: escanear con la mejor calidad posible (300 ppp, escáner plano si hay volumen), aplicar un OCR con el paquete de idioma correcto, limpiar los errores más evidentes con reglas sencillas, y solo entonces trocear e indexar. Las tablas merecen un tratamiento aparte, idealmente convertidas a un formato tabular legible antes de incorporarlas. Para búsquedas que combinan términos exactos (números de expediente, referencias legales) con preguntas en lenguaje natural, una indexación híbrida que combine palabras clave y vectores da mejores resultados que solo vectores semánticos; puede leer más en /es/blog/busqueda-hibrida-keywords-vectores. Si trabaja a menudo con PDF (escaneados o no) y quiere hacerles preguntas directamente, también le puede interesar /es/blog/chatear-con-pdf. En Kopik, al subir un documento a /dashboard/bases/new el sistema extrae el texto, lo trocea y lo indexa para búsqueda híbrida automáticamente, pero eso no sustituye la revisión visual de un escaneado complicado, sobre todo si va a publicar la base en el catálogo de /bases y cobrar por pregunta.
Pruebe la extracción con sus propios documentos
Suba un PDF escaneado a una base de conocimiento y compruebe en minutos cómo queda el texto indexado, antes de confiar en él para responder preguntas con fuentes citadas.
Preguntas frecuentes
¿Puede un sistema RAG indexar un PDF escaneado sin aplicar OCR?
No de forma útil. Sin OCR, el extractor no encuentra una capa de texto dentro de la imagen y el documento queda vacío o se indexa con metadatos irrelevantes. Es necesario pasar el archivo por un motor de OCR antes de trocearlo y vectorizarlo.
¿Qué resolución de escaneo necesito para un buen resultado de OCR?
Como referencia general, 300 ppp en blanco y negro o escala de grises da resultados fiables para texto impreso estándar. Por debajo de 200 ppp la tasa de errores sube de forma notable, especialmente en letra pequeña o documentos con mucho ruido visual.
¿Cómo se extraen correctamente las tablas de un documento escaneado?
Lo más fiable es usar un motor de OCR con detección de tablas que respete filas y columnas, o convertir la tabla a un formato tabular (Markdown o CSV) antes de indexarla. El OCR genérico a texto plano suele desordenar la correspondencia entre celdas.
¿El OCR funciona bien con catalán, euskera o gallego?
Funciona bien siempre que se cargue el paquete de idioma correspondiente en el motor OCR. Si se usa el paquete de español por defecto en un documento en catalán o euskera, aparecerán sustituciones y errores de acentuación frecuentes.
¿Cómo sé si la extracción de mis documentos fue correcta antes de publicar la base?
Siga una comprobación breve: abra varias páginas al azar y compárelas con el texto extraído, busque términos exactos que sabe que aparecen, revise aparte las tablas y las fechas o importes, y haga una pregunta cuya respuesta ya conozca para verificar que coincide con el pasaje citado.
¿El OCR puede leer texto manuscrito?
Con limitaciones. El OCR tradicional está pensado para letra de imprenta y da resultados pobres con manuscritos, salvo letra muy clara y espaciada. Para documentos manuscritos extensos conviene prever una revisión o transcripción manual antes de indexarlos.
Reciba la newsletter de Kopik
Nuevas bases de conocimiento, guías sobre RAG y novedades del producto. Un correo cada una o dos semanas, baja con un clic.
Al suscribirse, acepta recibir nuestra newsletter. Nunca compartimos su dirección.