Cómo el OCR afecta la calidad de los sistemas RAG: un análisis técnico

Si su sistema RAG devuelve resultados irrelevantes o alucina con confianza, el primer lugar donde buscar el problema no es en el modelo, ni en los parámetros de chunking, ni en la base de datos vectorial. Búsquelo en el texto que cargó allí.

Un error de OCR no es un defecto local. Es una inyección de ruido en la entrada del pipeline que se multiplica en cada paso posterior. Token distorsionado → límite de oración erróneo → fragmento incorrecto → vector desplazado → recuperación omitida → respuesta alucinada. Cada paso amplifica el anterior.

Este artículo es un análisis técnico de dónde y cómo ocurre esto, con ejemplos reales de artefactos y métodos concretos de corrección. Si necesita una visión general de qué es el OCR y por qué es necesario en RAG, lea el artículo anterior de la serie: "OCR en sistemas de IA modernos: de documentos escaneados a RAG".

Pipeline de procesamiento de documentos escaneados: de PDF a embeddings

Antes de analizar dónde se rompe, fijemos el mapa completo del pipeline. Cada paso a continuación es un punto potencial de degradación de la calidad.

La conclusión clave de este mapa: el error de OCR (paso 3) no se localiza en el paso 3. Flota por todo el pipeline y en el paso 9 se manifiesta como un problema de calidad de respuesta, lejos de la causa raíz.

Por eso la mayoría de los equipos buscan en el lugar equivocado: ajustan el chunking, cambian el modelo de embedding, configuran el reranker, pero el problema persiste porque reside en los datos de entrada.

Artefactos típicos de OCR: qué se rompe exactamente y por qué

A continuación, una taxonomía real de artefactos que encontrará en archivos corporativos típicos. Para cada uno, un ejemplo de cómo se ve el artefacto y qué rompe en el pipeline.

1. Palabras fusionadas (word merging)

Causa: contraste desigual entre caracteres y fondo, baja DPI, compresión JPEG.

Qué rompe: el divisor de oraciones no encuentra los límites de las oraciones; el tokenizador del modelo de embedding recibe un token OOV en lugar de dos palabras conocidas; la recuperación por la consulta "término de validez" no encuentra el fragmento con "términovalidezdelcontrato".

2. Sustitución de caracteres (character substitution)

Causa: similitud de formas de caracteres con baja resolución o mal contraste. Especialmente frecuente con fuentes mixtas cirílicas-latinas.

Qué rompe: los valores numéricos se convierten en texto; la búsqueda por valor exacto ("dosis 2,5 mg") no coincide con el artefacto; en documentos médicos y legales, este es un error crítico.

3. Caracteres y líneas fantasma (hallucinated content)

Causa: el OCR intenta reconocer cualquier patrón de píxeles como un carácter. Texto invertido, ruidos del escáner, artefactos de compresión, todo se convierte en "texto".

Qué rompe: la basura entra en el vector como contenido válido; durante la recuperación, la LLM recibe un contexto ilegible y alucina o dice "no sé".

4. Estructura de tablas rota

Causa: el OCR clásico no entiende las relaciones espaciales entre celdas. Lee el texto linealmente: de arriba abajo, de izquierda a derecha, ignorando la estructura de columnas.

Qué rompe: durante el chunking, toda la tabla entra en un bloque de texto lineal sin formato; la consulta "cuál es el precio del cable" no coincide con la línea sin estructura; el fragmento no transmite la relación semántica entre artículo, nombre y precio.

5. Saltos de línea y divisiones de palabras erróneas

Causa: el OCR no siempre distingue entre un salto de línea y el final de una línea en texto con columnas o márgenes estrechos.

Qué rompe: "responsabili-" y "dad" se convierten en tokens separados; el guion fusionado por el salto de línea crea un token OOV; el valor numérico "38 400" se divide en dos líneas y se analiza como "38" y "400,00", tokens diferentes sin el contexto de la suma.

Cómo los errores de OCR arruinan la estrategia de chunking

El chunking es la división del texto en fragmentos que se vectorizarán y almacenarán en el índice. La calidad del fragmento determina la calidad de la recuperación: si el fragmento es semánticamente incorrecto, ni siquiera un embedding perfecto salvará la situación.

Consideremos tres estrategias principales de chunking y cómo los artefactos de OCR arruinan cada una de ellas.

Estrategia 1: Chunking de tamaño fijo (por número de tokens)

La estrategia más simple: dividir el texto en fragmentos de N tokens con solapamiento. Problema: depende completamente de la tokenización correcta.

Estrategia 2: Chunking basado en oraciones

División por oraciones (divisores de oraciones spaCy, nltk). Requiere finales de oración correctos: puntos, signos de interrogación, exclamación con un espacio después.

Los artefactos de OCR rompen sistemáticamente la detección de límites de oraciones:

Estrategia 3: Chunking semántico / recursivo

Enfoques más avanzados (divisor recursivo de caracteres, chunking semántico con similitud de embedding) teóricamente deberían ser más resistentes a artefactos superficiales. En la práctica, no lo son.

El chunking semántico define los límites por el cambio de semántica entre oraciones adyacentes. Si las oraciones están distorsionadas por artefactos de OCR, el embedding de cada oración se desplaza, y el algoritmo "ve" una ruptura semántica donde no la hay, o no la ve donde sí la hay.

Resultado: los fragmentos se cortan en lugares "semánticamente correctos" para el texto distorsionado, pero no para el contenido original.

Cómo los errores de OCR se propagan por todo el pipeline de RAG

Escaneo PDF
   ↓
OCR (95%)
   ↓
Chunking
   ↓
Embeddings
   ↓
Recuperador
   ↓
LLM
   ↓
Respuesta

A menudo veo que muchos desarrolladores se centran en la elección de la LLM o el modelo de embedding, pero la calidad de la respuesta se determina mucho antes, en la etapa de OCR. Si el sistema reconoció incorrectamente el texto, este error entra en los fragmentos, luego en los embeddings, afecta la recuperación y finalmente se refleja en la respuesta final.

Por eso un error en la etapa de OCR puede propagarse por toda la cadena de procesamiento de documentos. Ni siquiera la LLM más moderna podrá encontrar información que se perdió o distorsionó durante el reconocimiento del texto.

En la práctica, la mejora de la calidad del OCR a menudo proporciona un mayor aumento en la precisión del sistema RAG que cambiar a una LLM más cara o utilizar un modelo de embedding más grande. Si la recuperación recibe datos incorrectos, ningún modelo generativo podrá compensar completamente este problema.

Conclusión práctica sobre chunking

Estoy convencido de que ninguna estrategia de chunking puede compensar sistémicamente un texto de entrada "contaminado". El postprocesamiento después del OCR es un paso obligatorio antes de cualquier chunking. Sin él, la diferencia entre el chunking de tamaño fijo y el semántico prácticamente desaparece: ambos enfoques comienzan a trabajar con fragmentos incorrectos, simplemente de manera diferente.

Влияние шума на качество embedding-векторов

Embedding-модель преобразует текстовый чанк в числовой вектор в n-мерном пространстве. Семантически похожие тексты имеют близкие векторы (высокая cosine similarity). Semantic search ищет именно такую близость.

OCR-шум влияет на вектор через два механизма:

Механизм 1: OOV-токены (out-of-vocabulary)

Если слово не встречалось в тренировочных данных модели — она кодирует его «по форме»: разбивает на subword-токены, каждый из которых имеет слабый или отсутствующий семантический сигнал. Вектор чанка смещается от правильной семантической позиции.

Механизм 2: Dilution эффект (разбавление сигнала)

Embedding-модель усредняет сигнал по всем токенам чанка (упрощенно). Если 15–20% токенов в чанке — мусор без семантической нагрузки, вектор «разбавляется»: он становится менее точным представлением истинного содержания.

Практический пример: чанк из 400 токенов, где 80 — артефакты (слипшиеся слова, символы шумов, ошибочные переносы). Эффективный семантический сигнал — не 100%, а ~80%. Cosine similarity с корректным запросом снизится пропорционально.

Снизится не до нуля — но может упасть ниже порога top-k retrieval. Если вы ищете top-5 чанков, смещенный чанк может оказаться на позиции 6 или 7 — и никогда не попасть в контекст LLM.

Наглядная иллюстрация: кейс юриста с AskYourDocs

Возвращаемся к кейсу из предыдущей статьи серии, но разбираем его на уровне векторов.

Клиент — юрист со специализацией в строительном праве — прислал 21 страницу из сканированного архива. Большинство страниц отсканированы под углом 90°, 180° или 270°. Стандартный OCR без коррекции ориентации читал их как:

аМЫМ "9a18 40 S¥3IAVT ONIHLY3HS N33ML3E NOILD¥¥LSNOO

Этот мусор попал в векторную базу как валидный текст. Что произошло с векторами:

Из 21 страницы нормально проиндексировалось 5–6. Остальные существовали в векторной базе как статистический шум — занимали место, но не давали полезного retrieval. При этом система не сообщала о проблеме: она возвращала результаты, просто с 5–6 страниц вместо 21.

Точность ответов на тестовые вопросы: 17%. После внедрения Vision OCR с автокоррекцией ориентации: 50% — на том же проблемном документе.

Почему семантически релевантный чанк не попадает в retrieval

Даже если чанк семантически правильный — он может не попасть в результаты retrieval по нескольким механизмам, связанным с OCR-шумом.

Сценарий 1: Ключевое слово искажено — поиск не матчит

Запрос: «какая ответственность за нарушение сроков»
Чанк в базе: «...відповідаль-ність за поруш-ення строків — штраф 0,1% за кожен день...»

Даже если embedding-модель частично «понимает» искаженные слова через subword-токены — cosine similarity между вектором запроса и вектором чанка будет ниже идеальной. Если в вашем индексе есть 50 других чанков об «ответственности» с чистым текстом — искаженный чанк окажется ниже threshold и не попадет в top-k.

Сценарий 2: Чанк «разбавлен» мусором до нерелевантности

Чанк B содержит ту же информацию, но: «ЗО» вместо «30» (кириллица вместо цифры), слипшийся перенос «змо-менту», мусор «..;;..» в конце. Его вектор отличается от вектора чанка A. Запрос «срок выполнения 30 дней» будет матчиться с A лучше чем с B — хотя оба несут одинаковый смысл.

Сценарий 3: Правильный документ есть, но не в top-k

Самый опасный сценарий. Релевантный чанк существует в индексе — но из-за смещенного вектора он на позиции 8 или 12, а не в top-5. LLM получает 5 менее релевантных чанков и либо отвечает на основе частичной информации, либо галлюцинирует.

При этом в логах все выглядит корректно: retrieval вернул k результатов, LLM сгенерировал ответ. Никакого сигнала о проблеме нет — только неправильный ответ.

Сценарий 4: False positive retrieval — мусор с высокой similarity

Противоположная ситуация: мусорный чанк с перевернутой страницы попадает в top-k из-за статистического совпадения токенов. LLM получает нечитабельный контекст и либо игнорирует его (хороший сценарий), либо пытается построить ответ на основе мусора (плохой сценарий).

Recall и Precision в RAG после плохого OCR: метрики и примеры

Для оценки качества retrieval используют две базовые метрики:

• Recall@k — доля релевантных документов, которые попали в top-k результатов. Если есть 3 релевантных чанка и все 3 в top-5 — Recall@5 = 1.0.
• Precision@k — доля релевантных среди возвращенных. Если в top-5 есть 2 релевантных и 3 нерелевантных — Precision@5 = 0.4.

Как OCR-шум влияет на эти метрики

Пример измерения: тест на реальных вопросах

Практический способ измерить влияние OCR на Recall — подготовить набор вопросов, ответы на которые вы знаете точно, и проверить попадают ли нужные чанки в retrieval.

20–30 таких вопросов на репрезентативной выборке архива дают гораздо более точную картину чем любой синтетический benchmark.

Métodos prácticos de mejora: preprocesamiento, postprocesamiento, selección del motor OCR

A continuación se presentan acciones concretas que producen un efecto medible. Dividido por niveles de impacto.

Nivel 1: Preprocesamiento de imágenes (antes de OCR)

Nivel 2: Postprocesamiento de texto (después de OCR, antes de chunking)

Este es el nivel más efectivo y subestimado. El postprocesamiento es más barato que reiniciar el OCR y tiene un efecto medible en la recuperación.

Detector de basura: implementación práctica

El detector de basura es un componente simple pero muy efectivo. Lógica:

Nivel 3: Selección del motor OCR

Estrategia de selección: árbol de decisiones

Cuándo el OCR no es suficiente y se necesita un enfoque de Visión

Incluso un pipeline de OCR perfectamente configurado tiene limitaciones sistémicas. Existe una clase de documentos en la que ninguna mejora de preprocesamiento dará un resultado satisfactorio para RAG.

Pipeline híbrido: arquitectura práctica

La estrategia óptima para la mayoría de los archivos reales no es "OCR o Visión", sino el enrutamiento:

Documento de entrada
  │
  ├─► ¿Capa de texto? ──► Sí ──► Analizador nativo (PyMuPDF) ──► Chunking
  │
  └─► No (escaneo)
        │
        ├─► Preprocesamiento (orientación, deskew, denoise)
        │
        ├─► OCR (Tesseract / PaddleOCR)
        │
        ├─► Detector de basura
        │        │
        │        ├─► Calidad OK ──► Postprocesamiento ──► Chunking
        │        │
        │        └─► Calidad baja ──► Vision OCR (GPT-4o-mini)
        │                                    │
        │                                    └─► Postprocesamiento ──► Chunking
        │
        └─► Registro: página, evaluación CER, ruta de procesamiento
  

Este enfoque permite procesar el 80-90% de los documentos a través de un OCR autoalojado económico y dirigir solo las páginas problemáticas a Vision OCR. El costo de Vision OCR con esta estrategia se reduce 5-10 veces en comparación con una transición completa.

Lo que Vision OCR no resuelve

El enfoque de Visión no es una solución universal. Limitaciones:

• Costo para grandes volúmenes: 100 000 páginas a través de GPT-4o-mini — ~$1 500–3 000.
• Latencia: la llamada a la API tarda de 2 a 10 segundos por página. Inaceptable para sistemas en tiempo real.
• Límites de tasa: sin acceso empresarial, el procesamiento paralelo de un archivo grande está restringido.
• GDPR: los documentos se envían a un proveedor externo. Requiere DPA y puede ser bloqueado por la política de cumplimiento.
• Alucinaciones de VLM: en documentos muy dañados, VLM puede "inventar" contenido ilegible. Requiere validación.

Una comparación detallada de arquitecturas OCR-first y Vision-first con análisis de trade-off se encuentra en el siguiente artículo de la serie: "Vision RAG vs OCR: comparación de enfoques para el procesamiento de documentos".

Conclusiones

La degradación de RAG debido a un OCR deficiente no es un problema del modelo. Es un problema de ingeniería de los datos de entrada que tiene puntos de corrección concretos.

¿Dónde exactamente se rompe el pipeline y qué hacer al respecto?

Orden de acción prioritario

Si actualmente está lanzando o ajustando RAG en documentos escaneados, esta es la secuencia con el mayor ROI:

1. Auditoría del archivo — ¿qué proporción son escaneos? ¿Hay páginas invertidas? ¿Cuál es la calidad típica?
2. Añadir corrección de orientación — incluso si la mayoría de las páginas son normales, una página invertida en un documento crítico cuesta caro.
3. Añadir postprocesamiento básico — normalización de espacios, unión de saltos de línea, eliminación de líneas basura. Se implementa en unas pocas horas, produce un efecto medible en la recuperación.
4. Construir un conjunto de preguntas de prueba — 20-30 preguntas con respuestas conocidas. Medir Recall@5 antes y después de cada cambio.
5. Añadir un detector de basura y enrutamiento a Vision OCR para páginas problemáticas.
6. Solo después de eso — ajustar parámetros de chunking, modelos de embedding, reranker.

Los pasos 1-3 dan más efecto que cambiar el modelo de embedding de 1536 a 3072 dimensiones. Pero la mayoría de los equipos comienzan con el paso 6, y se preguntan por qué el resultado no mejora.