Indexación de imágenes RAG: el método barato de Kapa

Kapa.ai resolvió la indexación de imágenes RAG describiendo cada imagen una sola vez, en la indexación, con un modelo de visión barato y guardando esas descripciones como texto. El overhead por consulta queda entre 1% y 6% sobre texto puro, y las respuestas mejoran de forma estadísticamente significativa, según el posteo técnico que publicaron en junio de 2026.

Qué es la indexación de imágenes en RAG

Ponele que tenés un asistente que responde preguntas sobre la documentación de tu producto. Un usuario pregunta “¿dónde activo las notificaciones?” y el sistema le contesta con el texto correcto. Pero al lado, en el manual original, había un screenshot que mostraba exactamente qué ícono tocar y dónde. Sin esa imagen, la respuesta es correcta pero el usuario igual tiene que salir a buscar.

RAG (Retrieval-Augmented Generation) es la técnica de recuperar fragmentos relevantes de una base de conocimiento y pasárselos al modelo de lenguaje como contexto antes de que responda. La indexación de imágenes RAG es el proceso de hacer que esas imágenes (screenshots, diagramas, tablas) sean recuperables igual que el texto.

Acá viene lo interesante. Kapa, que arma asistentes sobre documentación técnica, revisó miles de preguntas reales de clientes de hardware, semiconductores y herramientas de desarrollo. Las imágenes se dividen en dos grupos bien distintos.

Las ilustrativas son la mayoría. Muestran lo que el texto ya dice, pero más claro: la guía dice “tocá el ícono de configuración” y el screenshot al lado te muestra cuál, dónde y cómo se ve. El texto comunica qué hacer, la imagen muestra exactamente cómo.

Las load-bearing son otra cosa. Un diagrama de cableado, una tabla de especificaciones, un esquema de circuito. Ahí el dato vive en la imagen y en ningún otro lado. Si no la indexás, esa información directamente no existe para tu asistente. (Y son justo las que más duele perder.)

El dilema: procesar en indexación o en query time

Hay dos momentos posibles para que un modelo “lea” una imagen, y elegir mal te sale caro. Ya lo cubrimos antes en en nuestro análisis de seguridad.

El primer enfoque es mandar las imágenes al modelo en cada consulta. Es flexible: el modelo ve la imagen original con la pregunta puntual delante, así que puede mirar el detalle que importa en ese momento. ¿El problema? Pagás visión en cada query. Y a escala, eso se nota en la factura y en la latencia.

El segundo enfoque es el que eligió Kapa: procesar la imagen una sola vez, en la indexación. Describís cada imagen con un modelo de visión barato, guardás esa descripción como texto, generás su embedding y la metés en el vector store al lado de los chunks de texto normales.

La cuenta es simple. La indexación es un costo único. Después de eso, el overhead por consulta es de 1% a 6% sobre un pipeline de solo texto. Subís el modelo, describís el millón de imágenes una vez, lo dejás cocinado, y a partir de ahí cada usuario que pregunta paga centavos de más sobre lo que ya pagaba por el texto.

¿Y la calidad de las respuestas baja por trabajar con descripciones en vez de la imagen viva? No: Kapa reporta que mejora de forma estadísticamente significativa contra el baseline de solo texto.

La técnica de descripción con modelos de visión

El flujo de Kapa es directo. Imagen, modelo de visión, descripción textual, embedding, vector store. Cinco pasos y listo.

La clave está en el “modelo de visión barato”. No necesitás el modelo más caro para describir un screenshot de un menú de configuración. Modelos como GPT-4o, Llama 3.2 Vision o Phi-3.5-vision alcanzan para generar una descripción que después se busca por similitud semántica como cualquier otro texto. Relacionado: cómo funciona ChatGPT internamente.

Eso sí: la descripción tiene que capturar lo que la imagen aporta de verdad. Si es una tabla de specs, la descripción debería incluir los valores. Si es un diagrama de arquitectura, los componentes y cómo se conectan. Una descripción genérica tipo “captura de pantalla de una interfaz” no sirve para nada, porque no se va a recuperar cuando alguien pregunte por el dato concreto que estaba en esa imagen.

Cuando el usuario hace una pregunta, el sistema recupera la descripción textual junto con los chunks de texto. Y, según el caso, puede mostrarle la imagen original en la respuesta. La respuesta que incluye el screenshot es la que el usuario puede ejecutar sin salir a cazar el botón.

Enfoques multimodales: compartidos, descripción o patches

El camino de Kapa no es el único. Hay tres estrategias principales para indexar imágenes en RAG, y cada una tiene su precio.

Espacio vectorial compartido

Modelos como CLIP, ImageBind o Cohere Embed v4 generan embeddings de imagen y de texto en el mismo espacio. Buscás con texto y recuperás imágenes directamente, sin describir nada. Es elegante y rápido en query, pero la calidad depende mucho de qué tan bien ese modelo entiende tu dominio puntual.

Descripción textual con visión

El enfoque de Kapa. Convertís la imagen a texto una vez y todo el resto del pipeline trata esa descripción como un chunk más. La ventaja: reutilizás toda tu infraestructura de búsqueda de texto sin tocarla.

Late-interaction con patch embeddings

Acá entran ColPali y ColQwen. En vez de un solo vector por imagen, generan muchos embeddings por “parches” de la página y comparan a nivel fino con la consulta. La recuperación es muy precisa, sobre todo en PDFs densos. El costo: comen mucha más memoria, porque guardás decenas de vectores por documento en vez de uno. Cubrimos ese tema en detalle en los modelos de lenguaje modernos.

Enfoque	Cómo funciona	Costo en query	Memoria	Cuándo conviene
Espacio compartido (CLIP, Cohere Embed v4)	Imagen y texto en el mismo espacio vectorial	Bajo	Baja (1 vector/imagen)	Búsqueda visual general, catálogos
Descripción textual (Kapa)	Visión describe una vez, se indexa como texto	1% a 6% sobre texto	Baja	Documentación técnica con mucho texto e imágenes mixtas
Late-interaction (ColPali, ColQwen)	Muchos embeddings por parches de página	Medio	Alta (decenas de vectores/doc)	PDFs densos, layouts complejos, máxima precisión

Implementación práctica con herramientas disponibles

Nada de esto requiere construir todo desde cero. El stack ya existe.

Para orquestar el pipeline, LlamaIndex tiene soporte multimodal directo. Para el vector store, tenés Pinecone, Elasticsearch (que documentó su propio armado de RAG multimodal en Search Labs) o Azure AI Search, que explica el enfoque general en su guía de RAG. NVIDIA, por su lado, publicó una introducción al RAG multimodal que sirve para entender el panorama de modelos.

Para la parte de visión, la decisión es de presupuesto y volumen. Si vas a describir millones de imágenes, conviene un modelo barato y rápido (Llama 3.2 Vision o Phi-3.5-vision corriendo en tu propia infra). Si querés probar late-interaction, los repos de ColPali y ColQwen en Hugging Face ya tienen los pesos listos.

Todo esto vive en algún lado, claro. Si la indexación de millones de imágenes te exige levantar GPU para correr el modelo de visión, ahí entra la infraestructura de verdad: un VPS o servidor con buen ancho de banda y almacenamiento, como los que tenés en donweb.com, te evita el dolor de cabeza de mover terabytes de documentación.

Qué significa para empresas y equipos en Latinoamérica

Para un equipo que arma soporte automatizado o documentación interna en español, la lección de Kapa es concreta: no hace falta el pipeline más caro para sumar imágenes. El enfoque de describir una vez es accesible y barato en operación.

El caso típico acá es soporte técnico de productos con manuales largos, dashboards financieros con gráficos, o documentación de hardware industrial. Si tu asistente actual ignora las imágenes, le estás escondiendo justo los datos load-bearing que muchas veces resuelven la consulta. Y eso se traduce en tickets que vuelven a tu equipo humano.

Qué está confirmado y qué no

Confirmado (según el posteo de Kapa):

• El overhead por consulta es de 1% a 6% sobre solo texto.
• La mejora en calidad de respuesta es estadísticamente significativa.
• Procesan bases con millones de imágenes (screenshots, diagramas, esquemas de circuito).
• No mandan imágenes al modelo en query time: las describen en la indexación.

Pendiente o no aclarado:

• Qué modelo de visión exacto usan para describir (dicen “barato”, no nombran cuál).
• El costo absoluto de indexar el millón de imágenes en términos de tiempo o dólares.
• Cómo se compara su número de mejora contra un enfoque late-interaction sobre la misma base.

Errores comunes y cómo evitarlos

Generar descripciones genéricas. Si tu prompt al modelo de visión devuelve “imagen de una interfaz”, perdiste. La descripción tiene que contener el dato recuperable: valores de la tabla, nombres de los componentes, el texto del error en pantalla. Pedile al modelo que transcriba lo que importa, no que resuma vagamente.

Tratar todas las imágenes igual. Una imagen decorativa de stock no merece el mismo esfuerzo que un diagrama load-bearing. Si describís todo con la misma intensidad, llenás el índice de ruido. Filtrá lo ilustrativo de lo que carga datos.

Irse a late-interaction sin necesitarlo. ColPali es preciso, pero te multiplica la memoria por documento. Si tu caso es documentación con texto e imágenes mixtas, la descripción textual probablemente te alcance a una fracción del costo. No pagues precisión que no vas a usar. Sobre eso hablamos en la indexación de Google.

No deduplicar. Las bases de documentación repiten el mismo screenshot en veinte páginas. Si indexás cada copia, inflás el índice y degradás la recuperación. Limpiá duplicados antes de describir.

Preguntas Frecuentes

¿Cómo se indexan las imágenes en un sistema RAG?

El enfoque más eficiente es describir cada imagen una sola vez en la indexación con un modelo de visión, guardar esa descripción como texto y generar su embedding para el vector store. Después se recupera junto con los chunks de texto normales. Kapa reporta un overhead por consulta de apenas 1% a 6%.

¿Cuál es la diferencia entre indexar con visión y con texto puro?

El texto puro ignora todo lo que vive en imágenes: diagramas, tablas de specs, esquemas. Indexar con visión recupera ese contenido load-bearing que no está escrito en ningún lado. Según Kapa, sumar imágenes mejora la calidad de respuesta de forma estadísticamente significativa frente a solo texto.

¿Qué costo tiene procesar imágenes en RAG?

El costo grande es único y ocurre en la indexación, cuando describís cada imagen. Después, el sobrecosto por consulta es de 1% a 6% sobre un pipeline de solo texto. Usar un modelo de visión barato para las descripciones mantiene la indexación accesible incluso con millones de imágenes.

¿Cómo se describen automáticamente imágenes de documentación técnica?

Pasás cada imagen por un modelo de visión (GPT-4o, Llama 3.2 Vision o Phi-3.5-vision) con un prompt que pide transcribir los datos relevantes, no resumir. Para una tabla, los valores; para un diagrama, los componentes y conexiones. Esa descripción se indexa como texto buscable.

¿Qué tipos de imágenes se indexan en RAG multimodal?

Se dividen en ilustrativas (screenshots que refuerzan lo que el texto ya dice) y load-bearing (diagramas, tablas de specs, esquemas de circuito donde el dato solo vive en la imagen). Las load-bearing son las críticas: si no las indexás, esa información desaparece para el asistente.

Conclusión

Lo que cambió es la cuenta de costos. Kapa demostró que sumar imágenes a un RAG no exige el pipeline más caro ni mandar visión en cada consulta: describir una vez en la indexación deja el overhead en 1% a 6% y mejora las respuestas de forma medible.

Si tenés un asistente sobre documentación técnica que hoy ignora las imágenes, estás escondiendo los datos que más resuelven. El próximo paso concreto: identificá tus imágenes load-bearing, escribí un prompt de descripción que transcriba el dato real, y empezá con el enfoque textual antes de saltar a late-interaction. Probá con una porción de tu base, medí contra el baseline de texto, y recién ahí decidí si necesitás algo más pesado.

Fuentes

• How we index images for RAG – kapa.ai (posteo técnico original)
• Building a multimodal RAG system – Elastic Search Labs
• An Easy Introduction to Multimodal RAG – NVIDIA Developer Blog
• Información general sobre RAG – Azure AI Search (Microsoft)
• LLM Vision RAG: recuperación de contenido visual en PDFs – Winder.ai