Cómo diseñar un sistema RAG listo para producción

Las ofertas de AI Engineering crecieron un 60% el último año en empresas como Apple, Amazon, IBM o Google, frente a un 7% en ingeniería de software tradicional. En el percentil 80 de EEUU, ya es normal ver salarios base de 300.000$+ para ingenieros senior de IA. Y estos datos confirman algo que en LIDR llevamos meses viendo de cerca: la demanda es real.

Pero hay un ligero matiz, un Head of Engineering en Reino Unido lo resume así: cada vez ve más currículums que se autoetiquetan como “Senior AI Engineer», llenos de palabras clave como RAG, evals, inference, pidiendo sueldo de senior, que luego en la entrevista técnica demuestran un conocimiento de nivel medio. Saber decir «RAG» no es lo mismo que decir sé cómo diseñar un sistema RAG listo para producción.

Este artículo te explica cómo se diseña un sistema RAG, capa por capa. Las mismas decisiones de arquitectura que tomó Antonio Pérez, Director Técnico del Máster AI Engineering de LIDR, construyendo en directo un sistema que convierte una conversación con un cliente en una estimación de proyecto, con horas por tarea y margen de confianza. 

Resultado de una ejecución real: 148 horas, 14 tareas, 7.400€.

La mayoría de contenidos de IA te hablan del modelo (la capa 1), pero que un producto de IA aguante en producción exige dominar las cinco capas. Eso es exactamente lo que vas a ver cómo diseñar un sistema RAG capa por capa, con las decisiones de arquitectura reales detrás de cada una.

Por si llegas de fuera del ecosistema: RAG (Retrieval-Augmented Generation) es la técnica de buscar información relevante en una base de datos propia antes de que el modelo genere una respuesta, en vez de confiar solo en lo que el modelo ya sabe de su entrenamiento. La promesa pinta bien. La ejecución, no tanto y ahí es donde se nota quién sabe diseñar uno.

Las 5 capas para diseñar un sistema RAG listo para producción

Capa 1. Qué modelo usar

Es la parte más visible y, paradójicamente, la que menos decides. Eliges proveedor, ajustas parámetros de temperatura y longitud, pero el modelo no es tuyo, ni tu ventaja competitiva. En el simulador de estimaciones, el modelo redacta el informe final a partir de los datos que ya han pasado por las otras cuatro capas, su trabajo empieza cuando el resto del sistema ya ha hecho el suyo. Si tu sistema falla y la única palanca que tocas es «cambiar de modelo», es señal de que el problema vive en otra capa.

Capa 2. Los datos: chunking y embeddings en un sistema RAG

Aquí están la mayoría de los problemas de calidad de cualquier sistema RAG. Si el chunking corta un documento en fragmentos que no tienen sentido por sí solos, o los embeddings no capturan bien el significado, el modelo no puede compensarlo después, por bueno que sea. 

En el simulador, esta capa indexa el histórico de proyectos anteriores: presupuestos previos, horas reales por tarea, features similares ya estimadas. 

En el Máster AI Engineering trabajamos con PostgreSQL con soporte vectorial (pgvector) para esto; la misma base de datos relacional que ya conoces, con búsqueda semántica añadida, sin sumar una pieza de infraestructura nueva al stack.

Una decisión concreta que se toma aquí: chunking de tamaño fijo (rápido, pero puede cortar una idea a la mitad) frente a chunking semántico (respeta los límites naturales del texto, pero cuesta más calcular). 

En el simulador, cada presupuesto histórico se trocea por tarea, no por número de caracteres porque la unidad de sentido que se necesita recuperar después es «la tarea», no «un párrafo cualquiera».

Capa 3. Retrieval Augmented Generation: encontrar la información correcta

Con los datos ya indexados, el reto es traer la información correcta para cada consulta concreta. 

Búsqueda semántica pura, búsqueda híbrida (semántica + palabra clave), reranking para reordenar resultados por relevancia, expansión de consultas cuando la pregunta original es ambigua. 

En el simulador, esta capa busca proyectos comparables al que el cliente describe en la conversación, la diferencia entre traer «algo parecido» y traer el proyecto que de verdad predice bien las horas de la nueva tarea.

El reranking suele ser el paso que más se salta en un prototipo y más se nota en producción: la búsqueda inicial trae, digamos, 20 candidatos razonablemente parecidos; un segundo modelo (cross-encoder) los reordena comparando cada uno directamente contra la consulta, no contra el resto del índice. 

Es más lento que la búsqueda inicial, así que se aplica solo sobre esos 20, no sobre todo el histórico; precisión donde importa, sin pagar el coste en todo el sistema.

Capa 4. Generación y guardrails: evitar alucinaciones en producción

Aquí es donde el sistema decide qué puede salir a producción y qué no: gestión de la ventana de contexto, prompts de sistema, validaciones de output. 

En el simulador, el guardrail más visible es el algoritmo de intervalo de confianza: en vez de devolver una cifra única de horas (fácil de alucinar), el sistema devuelve un rango con margen de confianza, y estructura toda la salida en JSON validado antes de generar el PDF final. Un output sin estructura ni intervalo es una alucinación con buena redacción.

Capa 5. Observabilidad y evaluación RAGAS: saber si tu sistema degrada

Sin métricas, trazas y evaluación continua, no sabes si tu sistema empeora hasta que un cliente se queja. Y esto ya no es opcional: el informe Engineering 2028 de Damilah y CTO Craft, con 89 líderes de ingeniería encuestados, encontró que solo el 8% reporta que la IA mejoró la calidad de su software; el tiempo que se ahorra generando se reinvierte casi entero en verificar. 

En el Máster AI Engineering se trabaja con RAGAS como framework de evaluación: detección de alucinaciones, atribución de fuentes y métricas de calidad que corren en cada cambio, no solo antes de lanzar.

Dos métricas concretas que RAGAS calcula y que conviene conocer: 

• faithfulness (si la respuesta generada se sostiene en lo que realmente se recuperó, o el modelo se inventó algo por encima) 
• y answer relevancy (si la respuesta contesta lo que se preguntó, no algo adyacente).

Ninguna de las dos se puede revisar a ojo de forma sostenible cuando el sistema procesa cientos de estimaciones a la semana, por eso esta capa deja de ser opcional en cuanto el prototipo pasa a producción.

RAG no es una técnica, es una arquitectura de 5 capas

La diferencia entre un prototipo de demo y un sistema en producción está casi siempre en las capas 2 a 5, no en la 1. Si vienes del lado developer y ya conoces Context Engineering, ahí RAG aparece como una técnica más dentro de la gestión de contexto. Aquí lo tratamos como lo que es cuando la IA es el producto: un sistema completo que hay que diseñar, no solo invocar.

En el Máster AI Engineering construimos este tipo de sistemas sesión a sesión, con código propio y arquitectura, nada de automatizaciones low-code disfrazadas de producto. 

Si quieres entender primero el rol antes de entrar en el detalle técnico, tienes el contexto completo en nuestro artículo sobre AI Engineer.

Si eres developer, la capa que probablemente ya dominas es la 1 y la que más rédito te da aprender ahora es la 2 y la 3. Y si lideras un equipo que ya tiene un piloto de RAG en marcha, la pregunta que vale la pena hacer esta semana no es «qué modelo usamos», es «quién revisa la capa 5 cuando el sistema empiece a degradar sin que nadie se dé cuenta».