Cómo indexar imágenes para RAG en producción

Si tu equipo está construyendo un buscador o un asistente con RAG, probablemente ya resolviste la parte obvia: indexar texto. Pero cuando el conocimiento vive en capturas de pantalla, diagramas, fotos de producto, tickets con imágenes o documentación técnica con gráficos, el problema cambia. Ya no basta con guardar un embedding del texto alrededor de la imagen. Necesitas decidir qué representa esa imagen, cómo la partes, cómo la recuperas y cómo la evalúas en producción.

Ese es el punto de este artículo: aterrizar cómo indexar imágenes para RAG sin caer en una solución bonita en demo y frágil en tráfico real. Vamos a ver una arquitectura práctica, qué señales sí conviene guardar, cómo combinar OCR, captions y metadatos, y cómo medir si tu índice realmente ayuda a responder mejor.

Qué significa indexar imágenes para RAG

Cuando hablamos de indexar imágenes para RAG, no estamos hablando solo de “subir una imagen” a una base vectorial. El objetivo es que una consulta del usuario encuentre la imagen correcta, o la información visual correcta, y que esa evidencia termine en el contexto del modelo con suficiente precisión para responder bien.

En producción, una imagen rara vez es útil sola. Una captura de pantalla de un dashboard, por ejemplo, puede requerir el título del panel, los valores visibles, el rango temporal y el texto que aparece en la interfaz. Una foto de un producto puede necesitar categoría, color, modelo, SKU y la descripción del catálogo. Una imagen de un diagrama puede requerir OCR, captioning y el texto de los nodos.

Por eso, indexar imágenes para RAG suele ser una combinación de cuatro cosas: representación visual, texto extraído, metadatos estructurados y un puntero al asset original. Si solo guardas una de esas capas, tu recall baja o tu precisión se vuelve inconsistente.

El problema real no es la imagen, es la evidencia

Piensa en una consulta como: “¿Dónde aparece el error de timeout en la consola?”. El usuario no quiere una imagen bonita, quiere la captura exacta donde se ve el error, o una respuesta que cite el texto visible. Si tu sistema solo usa embeddings de la imagen completa, puede recuperar algo visualmente parecido pero semánticamente inútil.

En cambio, si guardas OCR, caption y metadatos, puedes recuperar por texto, por similitud visual o por ambos. Esa combinación suele ser mucho más robusta en documentos técnicos, soporte, e-commerce y producto.

También cambia el tipo de chunk. En texto, chunking suele ser por párrafos o tokens. En imágenes, el chunk puede ser la imagen completa, una región, una página, una diapositiva o una captura con un área delimitada. No hay una única respuesta correcta; depende del tipo de contenido y del patrón de consulta.

Qué señales conviene extraer de cada imagen

La mejor forma de pensar este problema es como un pipeline de enriquecimiento. Antes de indexar, conviertes cada imagen en varios artefactos recuperables. No todas las imágenes necesitan las mismas señales, pero hay un mínimo bastante útil para producción.

Estas son las señales que normalmente sí vale la pena considerar:

• OCR: texto visible dentro de la imagen.
• Caption: una descripción corta de lo que muestra.
• Tags o labels: conceptos detectados, como “gráfico”, “pantalla”, “persona”, “interfaz”.
• Metadatos: fecha, fuente, tipo de documento, producto, idioma, tenant, permisos.
• Embedding visual: representación vectorial de la imagen o de un recorte.
• Enlace al original: URL, storage key o asset ID para mostrar la evidencia.

No todas las señales pesan igual. OCR suele ser clave en capturas y documentos. Caption ayuda cuando la imagen no tiene mucho texto. Los metadatos son los que te permiten filtrar por contexto de negocio. El embedding visual ayuda a encontrar similitudes que el texto no captura, como layouts parecidos o productos visualmente similares.

OCR primero cuando la imagen tiene texto

Si la imagen contiene texto legible, OCR debería ser una de las primeras capas del pipeline. En capturas de pantalla, PDFs renderizados, slides y tickets, el texto visible suele ser la señal más útil para recuperar el asset correcto.

No necesitas OCR perfecto para que sea útil. Incluso con errores, te ayuda a acercarte al documento correcto. Lo importante es guardar el resultado con contexto: idioma detectado, confianza por bloque si tu motor lo da, y la posición del texto cuando quieras resaltar una región concreta.

Un punto práctico: si el OCR devuelve mucho ruido, no lo metas tal cual al chunk principal. Puedes guardarlo como campo separado y usarlo para búsqueda híbrida, o crear un resumen limpio con reglas simples antes de indexarlo.

Caption y etiquetas para cubrir el vacío semántico

Hay imágenes donde el OCR aporta poco: fotos de productos, diagramas sin mucho texto, capturas con iconografía o imágenes de interfaz donde la semántica está en la estructura. Ahí un caption bien hecho ayuda mucho.

Un caption útil no tiene que ser literario. Tiene que decir qué hay y por qué podría importar. Por ejemplo: “Captura de un panel de facturación con gráfico de barras, selector de fecha y alerta roja en la esquina superior derecha”. Esa frase ya orienta la recuperación mejor que un embedding visual solo.

Las etiquetas también sirven, pero mejor si son consistentes. Si una imagen está etiquetada como “dashboard”, otra como “analytics” y otra como “reporting” sin un vocabulario controlado, tu recall se fragmenta. En producción conviene normalizar taxonomías.

Cómo diseñar el índice para producción

El error más común es pensar que una imagen debe convertirse en un único vector. En la práctica, suele funcionar mejor un índice compuesto. Guardas varios campos y combinas recuperación textual, vectorial y por filtros.

Una estructura típica podría verse así:

Esta tabla no es un estándar universal, pero sí una base útil. Si tu producto tiene control de acceso por tenant, permisos o región, esos campos tienen que vivir en el índice desde el día uno. Si los agregas después, terminas reindexando todo.

El diseño también debería separar dos cosas: el índice de recuperación y el almacenamiento del asset. El vector store no tiene por qué ser el lugar donde guardas la imagen original. Mejor guarda un puntero estable al objeto en storage y deja el vector store para las señales de búsqueda.

Chunking visual: imagen completa, región o página

No todas las imágenes deben indexarse como una sola unidad. Si trabajas con documentos escaneados, una página completa puede ser demasiado grande y poco precisa. Si trabajas con UI, quizá te conviene dividir por regiones: encabezado, panel lateral, tabla, error banner.

La regla práctica es simple: indexa la unidad mínima que un usuario pueda querer recuperar. Si la consulta suele ser “la tabla donde aparece el SKU” o “el panel con la alerta”, un chunk por región puede funcionar mejor que una página completa.

Si no tienes un detector de regiones, puedes empezar con la imagen completa y un caption limpio, y luego ir refinando. Lo importante es no asumir que más granularidad siempre mejora. Más chunks también significa más ruido, más costos y más trabajo de evaluación.

Índice híbrido, no solo vectorial

Para imágenes con texto o metadatos, una búsqueda híbrida suele superar a una búsqueda puramente vectorial. La combinación típica es BM25 o full-text para OCR y captions, más vector search para similitud semántica y visual.

En la práctica, eso te permite consultas como:

1. Buscar por texto exacto dentro del OCR.
2. Buscar por intención, aunque el texto no coincida literal.
3. Filtrar por producto, fecha, idioma o tenant.
4. Re-rankear los candidatos con señales adicionales.

Si tu stack soporta scoring combinado, úsalo. Si no, puedes hacer una primera pasada textual y una segunda visual, o al revés, según el tipo de contenido. Para documentación técnica, texto primero suele funcionar mejor. Para e-commerce o catálogos, la similitud visual pesa más.

Pipeline recomendado de indexación

La parte operativa importa más que la teoría. Si no defines un pipeline claro, terminas con imágenes indexadas de formas distintas según quién subió el asset, qué servicio lo procesó o qué versión del modelo estaba corriendo ese día.

Un pipeline razonable para producción puede verse así:

1. Ingesta del asset desde storage, CMS, ticketing o base documental.
2. Extracción de metadatos básicos: fuente, fecha, permisos, idioma, tipo de archivo.
3. OCR si la imagen contiene texto o si el documento parece escaneado.
4. Captioning con un modelo multimodal o una regla basada en contexto.
5. Generación de embeddings visuales y, si aplica, embeddings del OCR y caption.
6. Normalización de tags y limpieza de texto.
7. Escritura al índice con versionado del pipeline.
8. Validación con muestras y monitoreo de calidad.

Lo más útil aquí es el versionado. Si cambias el OCR, el captioner o el modelo de embedding, deberías poder saber qué versión generó cada registro. Sin eso, cuando la calidad cae, no sabes si fue el modelo, el dato o el ranking.

Ejemplo de esquema de documento indexado

Un documento indexado puede tener un shape parecido a este:

{
  "asset_id": "img_98321",
  "source_type": "support_ticket",
  "title": "Error de facturación en dashboard",
  "ocr_text": "Payment failed after 30 seconds. Retry later.",
  "caption": "Captura de un dashboard con una alerta de pago fallido en rojo",
  "tags": ["billing", "error", "dashboard"],
  "language": "en",
  "permissions": {
    "tenant_id": "tenant_12",
    "roles": ["admin", "support"]
  },
  "created_at": "2026-05-18T14:22:00Z",
  "embedding_model": "clip-vit-l14",
  "ocr_model": "tesseract-5",
  "asset_url": "s3://bucket/assets/img_98321.png"
}

Ese documento no pretende ser universal. La idea es que puedas rastrear qué señales entraron al índice y con qué modelo se generaron. En producción, esa trazabilidad ahorra tiempo.

Cómo decidir qué modelo usar

No necesitas el modelo más grande para empezar. Lo que sí necesitas es consistencia. Si usas un modelo multimodal para captioning y otro para embeddings, documenta qué hace cada uno y qué costo tiene por imagen.

Si tu caso es soporte o documentación, muchas veces el mayor salto viene de buen OCR y buenos metadatos, no de perseguir el mejor embedding visual disponible. Si tu caso es catálogo o búsqueda de productos, la calidad del embedding visual y la normalización de atributos pueden pesar más.

Una referencia útil para entender embeddings multimodales es la documentación de OpenAI sobre embeddings y visión, y la de CLIP de OpenAI, que explica la idea de alinear texto e imagen en un espacio compartido: https://platform.openai.com/docs/guides/embeddings y https://openai.com/index/clip/

Cómo recuperar imágenes dentro de un flujo RAG

Indexar bien no sirve si la recuperación falla. En RAG con imágenes, el retrieval suele ser una mezcla de búsqueda textual, vectorial y filtros de negocio. Después viene el re-ranking y, por último, la construcción del contexto para el modelo.

Una estrategia práctica es esta: primero recuperas candidatos con OCR, caption y metadatos; luego agregas resultados por similitud visual; finalmente ordenas por relevancia, frescura y permisos. Si el usuario preguntó por un error específico, el OCR puede pesar más. Si preguntó por una interfaz similar, el embedding visual puede pesar más.

También conviene devolver no solo la imagen, sino el texto que la acompaña. En muchos casos, el modelo responde mejor si recibe la captura, el caption y el OCR relevante en el mismo contexto. Eso reduce alucinaciones y hace que la explicación sea más verificable.

Re-ranking con contexto de negocio

El re-ranking es donde tu producto empieza a parecer realmente útil. Dos imágenes pueden ser parecidas visualmente, pero una puede venir de un tenant distinto, de una versión vieja del producto o de un documento sin permisos para el usuario actual.

El re-ranker puede usar señales como:

• coincidencia exacta en OCR,
• score semántico del caption,
• similitud visual,
• fecha de creación,
• popularidad o frecuencia de acceso,
• permisos del usuario.

No hace falta complicarlo desde el primer día. Incluso una fórmula simple con pesos fijos puede darte bastante valor. Lo importante es poder explicar por qué una imagen quedó arriba de otra.

Ejemplo de decisión de ranking

Supón que recuperaste tres candidatos para la consulta “captura con error de pago”. Si uno tiene OCR exacto con “payment failed”, otro tiene un caption muy parecido pero sin texto visible, y el tercero es visualmente similar pero pertenece a otro producto, tu sistema debería priorizar el primero.

En soporte, eso suele ser más útil que una similitud visual pura. En catálogos, el orden puede invertirse. El punto es que el ranking debe reflejar el caso de uso, no solo la matemática del embedding.

Cómo evaluar si tu índice realmente funciona

Aquí es donde muchos equipos se quedan cortos. Tener imágenes indexadas no significa que el sistema responda bien. Necesitas evaluación con queries reales, no solo con intuición.

Lo primero es construir un set pequeño pero representativo. Puedes tomar 50 a 200 consultas reales y anotar qué imagen o qué región debería recuperarse. Luego mides recall@k, precision@k y, si tienes un flujo end-to-end, la calidad de la respuesta final.

También conviene medir por tipo de contenido. No mezcles en la misma métrica capturas de pantalla, fotos de producto y gráficos. Cada uno falla por razones distintas.

Métricas útiles para empezar

• Recall@5: cuántas consultas recuperan la imagen correcta entre los primeros 5 resultados.
• Precision@5: cuántos de esos 5 resultados son realmente útiles.
• MRR: qué tan arriba aparece la respuesta correcta.
• Coverage de OCR: porcentaje de imágenes con texto que sí tienen OCR usable.
• Latencia p95: tiempo de recuperación en producción.

Si tu sistema tarda demasiado, el usuario lo siente aunque la calidad sea buena. Si la calidad es alta pero la latencia es mala, el producto igual se resiente. En muchos equipos, un p95 de recuperación por debajo de 300 ms para la fase de búsqueda es una referencia razonable, aunque el número final depende de tu infraestructura y del tamaño del índice.

Cómo hacer una evaluación manual que sí sirva

Una evaluación manual útil no necesita ser enorme. Puedes seguir este proceso:

1. Toma 100 consultas reales de soporte, producto o documentación.
2. Para cada consulta, etiqueta 1 a 3 imágenes relevantes.
3. Repite la búsqueda con tu pipeline actual.
4. Revisa dónde falla: OCR, caption, filtros o ranking.
5. Ajusta una sola cosa por iteración.

Ese último paso es clave. Si cambias OCR, caption y embeddings al mismo tiempo, no sabrás qué mejoró. En producción, los cambios pequeños y medibles suelen ser más sostenibles.

Errores comunes al indexar imágenes para RAG

El primer error es confiar demasiado en la imagen cruda. Una imagen sola casi nunca alcanza para una buena recuperación en casos de uso reales. Necesitas texto, metadatos y contexto.

El segundo error es no versionar el pipeline. Si cambias el modelo o el OCR sin registrar la versión, cualquier regresión se vuelve difícil de diagnosticar. También pasa mucho que los equipos indexan sin normalizar permisos, y luego el sistema recupera assets que el usuario no debería ver.

El tercer error es no separar tipos de contenido. Una captura de pantalla no se comporta igual que una foto de producto o una diapositiva. Si mezclas todo en el mismo ranking sin filtros, tu precisión cae.

Señales de que tu diseño necesita ajustes

• El usuario encuentra la imagen correcta, pero el modelo responde mal porque no recibió OCR limpio.
• Recuperas imágenes visualmente parecidas, pero de otro producto o tenant.
• Las consultas con texto exacto funcionan, pero las consultas semánticas no.
• El índice crece, pero la calidad no mejora.
• El equipo no puede explicar por qué una imagen aparece arriba de otra.

Si ves dos o más de estas señales, normalmente el problema no es “más embeddings”. Suele ser diseño de esquema, recuperación híbrida o evaluación insuficiente.

Tabla resumen

Indexar imágenes para RAG no es un problema de una sola herramienta. Es un problema de diseño de datos, recuperación y evaluación. Si lo resuelves bien, tu buscador o asistente deja de depender solo del texto y empieza a responder con evidencia visual útil.

La forma más segura de avanzar es empezar con un pipeline simple: OCR, caption, metadatos, embeddings y filtros. Después mide, corrige y repite. Ese orden te da una base sólida sin sobreingeniería.