Arquitectura RAG: lo que aprendimos construyendo Eugenia

Este artículo se publicó originalmente en septiembre de 2023. Lo he reescrito en marzo de 2026 porque, aunque los fundamentos siguen vigentes, la versión anterior no reflejaba lo que realmente aprendimos construyendo sobre esta arquitectura. Si te interesa cómo ha evolucionado el panorama desde entonces, echa un vistazo a la serie sobre memoria agéntica.

En Éutika llevábamos tiempo dándole vueltas a un problema concreto: los profesores e investigadores trabajan con decenas de fuentes simultáneamente — documentos, vídeos, presentaciones, webs — y necesitan sintetizar todo ese material para preparar contenido. Las herramientas de IA generativa del momento eran útiles para preguntas genéricas, pero no podían operar sobre el conocimiento específico en diferentes formatos de cada profesor o institución.

Eso nos llevó a construir Eugenia, un servicio de IA generativa diseñado para el sector educativo. La idea era sencilla: el usuario agrupa sus fuentes en colecciones, y Eugenia puede responder, resumir y organizar a partir de ese contexto específico. Y lo más importante incluyendo referencias a las fuentes originales. Hasta nos permitimos el lujo de incluir el efecto WoW de incluir referencias a momentos exactos de videos. Ahora parece trivial, pero en 2024 no era nada común. Conceptualmente era un producto claro. Técnicamente, significaba implementar RAG.

Lo que viene a continuación es lo que aprendimos haciéndolo.

El problema que RAG resuelve

Los LLMs tienen un conocimiento limitado a los datos con los que fueron entrenados. No conocen la documentación interna de tu empresa, los apuntes de tu asignatura ni las actas de tu última reunión. Si les preguntas sobre algo que no está en sus datos de entrenamiento, o inventan una respuesta (lo que llamamos alucinaciones) o te dicen que no saben.

La arquitectura RAG (Retrieval-Augmented Generation) resuelve esto combinando dos capacidades: recuperar información relevante de una base de conocimiento propia y usarla como contexto para que el LLM genere una respuesta. En lugar de esperar que el modelo sepa la respuesta, le das la información que necesita para responder bien.

Es una idea elegante. La implementación, bastante menos.

Cómo funciona RAG

La parte de recuperación

Antes de que el LLM genere nada, necesitas encontrar los fragmentos de tu base de conocimiento que son relevantes para la pregunta del usuario. Aquí es donde entran los embeddings y las bases de datos vectoriales.

Los embeddings son representaciones numéricas de texto (o imágenes, audio, vídeo) en un espacio matemático multidimensional. La propiedad clave es que conceptos similares quedan “cerca” en ese espacio. Esto permite buscar por significado, no por coincidencia literal de palabras.

Las bases de datos vectoriales almacenan estos embeddings y permiten hacer búsquedas de similitud: dada la pregunta del usuario convertida a vector, encuentran los fragmentos más cercanos semánticamente.

La parte de generación

Con los fragmentos relevantes recuperados, construyes un prompt que incluye la pregunta del usuario más ese contexto adicional. El LLM genera su respuesta a partir de ese prompt enriquecido. No es magia: le estás dando la información que necesita antes de pedirle que responda.

El flujo completo

1. Vectorización de la consulta: la pregunta del usuario se convierte en un embedding.
2. Búsqueda semántica: se buscan los fragmentos más cercanos por similitud coseno en la base de datos vectorial.
3. Construcción del contexto: los fragmentos recuperados se incorporan al prompt con una estructura que el LLM pueda interpretar.
4. Generación de respuesta: el LLM procesa el prompt enriquecido y genera la respuesta.

Sobre el papel, cuatro pasos limpios. En la práctica, un caos que en 2024 era difícil de gestionar.

Donde RAG aporta valor real

Trazabilidad. Para nosotros, en un contexto educativo, esto era innegociable. Un profesor necesita saber de dónde viene una respuesta. RAG permite implementar sistemas de citación que vinculan cada afirmación con el fragmento concreto de la base de conocimiento que la respalda. El chatbot deja de ser una caja negra porque podemos justificar sus respuestas con referencias verificables.

Actualización sin reentrenamiento. Comparado con el fine-tuning, RAG es órdenes de magnitud más barato y flexible. Actualizar la base de conocimiento es añadir o modificar documentos. No necesitas reentrenar el modelo, ni mantener versiones personalizadas, ni gestionar infraestructura para el entrenamiento. En 2026 existen técnicas mucho más eficientes de finetunning pero incluso actualmente la mayoría de las veces RAG en combinación con otras técnicas será la mejor opción.

Conocimiento de dominio específico. El LLM base no sabe nada sobre los materiales de un curso de biología marina en la Universidad de A Coruña. Con RAG, sí puede operar sobre ellos.

Los dolores del RAG

El chunking es más arte que ciencia

Antes de vectorizar tus documentos, necesitas segmentarlos (chunks). Y aquí empieza el dolor. ¿Fragmentos de 500 tokens? ¿De 1000? ¿Por párrafos? ¿Solapados? ¿Por secciones semánticas? ¿Con resúmenes generales vinculados a cada segmento? La respuesta depende de tu contenido, de tu modelo de embeddings y de las preguntas que esperas recibir.

Fragmentos demasiado pequeños pierden contexto. Fragmentos demasiado grandes diluyen la relevancia. Y no hay una regla universal: lo que funciona para documentación técnica no funciona para transcripciones de vídeo.

La elección del modelo de embeddings importa más de lo que crees

Esta es probablemente la lección más cara que aprendimos en Éutika. Durante meses tuvimos problemas de calidad en las respuestas de Eugenia. Las búsquedas semánticas devolvían fragmentos que parecían relevantes pero no lo eran realmente, o se perdían fragmentos que deberían haber aparecido.

En un principio atacamos el chunking, luego el prompt, luego la arquitectura, pero el problema seguía allí.

Finalmente, el problema resultó ser el modelo de embeddings. Usábamos Cohere Embed Multilingual v3 a través de AWS Bedrock. Sobre el papel, un modelo multilingüe solvente. En la práctica, la calidad de la representación semántica en español — que era el idioma principal de nuestra base de conocimiento — no era suficiente para nuestro caso de uso. Las búsquedas en español devolvían resultados notablemente peores que las equivalentes en inglés. Esto lo descubrimos incluyendo un paso de traducción al inglés de los contenidos y las preguntas del usuario. Algo que nos permitió detectar el problema pero que no era la solución más óptima.

Migramos a Voyage-multilingual-2 y la diferencia fue inmediata. No cambió la arquitectura, no cambió el chunking, no cambió el prompt. Cambió el modelo de embeddings y la calidad de recuperación mejoró de forma drástica.

La lección: en una arquitectura RAG, el modelo de embeddings es tan importante como el LLM que genera la respuesta. Y “multilingüe” no significa “igual de bueno en todos los idiomas”.

El contexto no es gratis

Cada fragmento que inyectas en el prompt consume tokens. Más contexto implica más coste y más latencia. Pero también implica más ruido: si le das al LLM diez fragmentos cuando solo tres son realmente relevantes, la calidad de la respuesta puede empeorar. El modelo se distrae con información que no aporta.

Esto nos llevó a invertir tiempo en técnicas de reranking — un paso adicional que reordena los fragmentos recuperados por relevancia antes de inyectarlos en el prompt — y en ajustar cuidadosamente cuántos fragmentos incluir en cada consulta.

Este paso mejoró notablemente la calidad de los resultados pero también aumentó bastante la latencia de las respuestas.

Costes operativos que debes anticipar

RAG no es costoso comparado con fine-tuning, pero tiene sus propios costes que escalan con el uso:

• Computación de embeddings: cada documento nuevo y cada consulta requieren vectorización.
• Almacenamiento vectorial: las bases de datos vectoriales tienen costes de infraestructura que crecen con el volumen.
• Tokens de contexto: prompts más largos significan más coste por llamada al LLM.

Se pueden optimizar con caché de embeddings, compresión de vectores y estrategias de reranking inteligentes. Pero hay que presupuestarlos desde el principio, no descubrirlos en producción.

Lo que RAG no resuelve

Después de más de dos años trabajando con esta arquitectura sigo con una sensación agridulce.

RAG no resuelve el razonamiento complejo. Si el usuario hace una pregunta que requiere conectar información dispersa en múltiples documentos y razonar sobre ella, la simple recuperación de fragmentos similares no es suficiente. Necesitas estrategias más sofisticadas: grafos de conocimiento, recuperación en múltiples saltos, o arquitecturas híbridas que combinen búsqueda semántica con búsqueda estructurada.

RAG tampoco resuelve las actualizaciones automáticas sobre la información almacenada. Si tu base de conocimiento no está actualizada, la respuesta será precisa respecto a información obsoleta. El pipeline de ingesta de datos es tan importante como el pipeline de recuperación, y requiere mantenimiento continuo. El sistema de metadatado es clave para gestionar las actualizaciones de los embeddings de documentos.

Y RAG no elimina las alucinaciones — las reduce. El LLM sigue siendo un modelo probabilístico que puede generar información incorrecta incluso con buen contexto. La trazabilidad ayuda a detectarlo, pero no lo resuelve completamente.

Conclusión

RAG sigue siendo, en 2026, la arquitectura de referencia para dotar a un LLM de conocimiento de dominio específico. Los fundamentos no han cambiado: recuperas contexto relevante y lo inyectas en el prompt. Lo que sí ha evolucionado enormemente es la sofisticación de cada paso del pipeline y la comprensión colectiva de dónde están los puntos de fallo.

Si estás evaluando implementar RAG, mi consejo después de haberlo hecho en producción: invierte tiempo en tres cosas. Primera, la calidad del modelo de embeddings para tu idioma y dominio concreto. La mayoría de modelos publican el volumen de datos que han utilizado en cada idioma durante su entrenamiento — consúltalo antes de elegir. Segunda, la estrategia de chunking y recuperación: cómo segmentas los documentos y cómo reordenas los resultados antes de inyectarlos en el prompt condicionan directamente la calidad de las respuestas. Tercera, el pipeline de ingesta: si los documentos entran mal procesados o con metadatos pobres, da igual lo bueno que sea el resto. Esas tres decisiones definen el techo de calidad de todo el sistema. Todo lo demás se puede iterar.