OsviDev | Blog de IA y Datos

Wed, 10 Sep 2025 00:00:00 GMT

En el mundo actual, los datos son el activo más valioso de una empresa. Pero tener datos no es suficiente; la clave está en la capacidad de recolectarlos, procesarlos y analizarlos de manera eficiente para tomar decisiones de negocio inteligentes. Aquí es donde entra en juego un pipeline de datos bien diseñado.

Como arquitecto, a menudo me enfrento al desafío de construir estos pipelines. La pregunta no es solo "cómo lo hacemos", sino "¿cuál es la forma más escalable, rentable y mantenible de hacerlo?". Hoy quiero compartir mi arquitectura en AWS, una plantilla que he refinado a través de varios proyectos para construir sistemas de datos robustos.

El problema: del caos de datos a la claridad

Imagina un escenario común: una empresa tiene datos generándose constantemente desde múltiples fuentes: clics en su aplicación web, transacciones de su e-commerce, eventos de sus dispositivos IoT, etc. Necesitan un sistema centralizado que no solo almacene esta información, sino que la transforme en insights accionables para sus equipos de negocio.

Un enfoque ad-hoc con scripts manuales y bases de datos sobrecargadas rápidamente se vuelve un caos. Necesitamos una autopista de datos, no un camino de terracería.

Mi solución: una arquitectura de pipeline moderna en AWS

Para resolver este problema, mi arquitectura preferida combina varios servicios gestionados de AWS, cada uno especializado en una etapa del proceso. Esto nos permite enfocarnos en la lógica de negocio y no en la gestión de infraestructura.

1. Ingesta en tiempo real con Amazon Kinesis

Kinesis es la puerta de entrada a nuestro pipeline. Es un servicio diseñado para capturar y procesar grandes volúmenes de datos en streaming en tiempo real.

Por qué Kinesis: Su integración nativa con el ecosistema de AWS y su capacidad para manejar picos de datos masivos lo hacen ideal. Es la solución perfecta para no perder ni un solo evento.

2. Almacenamiento crudo en Amazon S3 (nuestro data lake)

Todos los datos que llegan a través de Kinesis se almacenan primero, en su formato crudo, en un bucket de S3.

Por qué S3: Es increíblemente barato, duradero y escalable. Tener una copia de los datos sin procesar en nuestro "lago de datos" (Data Lake) es crucial. Nos permite reprocesar la información en el futuro si nuestras reglas de negocio o nuestros modelos cambian, sin tener que volver a capturarla desde la fuente.

3. Transformación serverless con AWS Lambda o AWS Glue

Una vez que los datos están en S3, una función Lambda o un job de AWS Glue se activa automáticamente. Su trabajo es leer los datos crudos, limpiarlos, enriquecerlos y transformarlos a un formato estructurado y optimizado (como Parquet).

Por qué Lambda/Glue: Usar un enfoque serverless aquí es clave. Pagamos solo por el tiempo de computación que usamos para la transformación, y se escala automáticamente sin que tengamos que gestionar servidores.

4. Carga en el data warehouse con Amazon Redshift

Los datos ya limpios y estructurados se cargan en Amazon Redshift, nuestro Data Warehouse.

Por qué Redshift: Está optimizado para realizar consultas analíticas complejas sobre grandes volúmenes de datos a una velocidad impresionante. Es aquí donde los analistas de negocio y científicos de datos pueden conectar sus herramientas (como Power BI o Tableau) para explorar los datos y generar reportes.

Conclusión: una base para decisiones inteligentes

Construir un pipeline de datos no tiene por qué ser una tarea titánica. Al apoyarnos en los servicios gestionados de AWS, podemos diseñar sistemas que son a la vez potentes y flexibles.

Esta arquitectura no es solo un diagrama técnico; es una base que habilita a una organización a moverse más rápido, a entender mejor a sus clientes y a tomar decisiones basadas en datos, no en intuición. Es la infraestructura que convierte el potencial de los datos en valor real de negocio.

]]>

Fri, 05 Jul 2024 00:00:00 GMT

El mundo de los Modelos de Lenguaje Grandes (LLMs) está lleno de opciones. Una vez que superas la fase de experimentar con ChatGPT, la siguiente pregunta lógica es: ¿cómo hago que estos modelos respondan usando mi propia información?

Ahí es donde entran dos de las técnicas más potentes que tenemos hoy en día: el Fine-tuning y RAG (Retrieval-Augmented Generation). A primera vista pueden parecer similares, ya que ambas buscan personalizar las respuestas de un LLM. Sin embargo, no son intercambiables. Elegir la incorrecta puede llevarte a gastar mucho tiempo y dinero con resultados mediocres.

En este artículo, te explico de forma directa las diferencias clave, en qué escenarios brilla cada una y cómo he tomado esta decisión en proyectos reales para optimizar tanto los costos como el rendimiento.

Entendiendo las Bases: ¿Qué es Cada Cosa?

Vamos a desglosarlo sin tecnicismos innecesarios.

Fine-tuning (Ajuste Fino)

Imagina que un LLM como GPT-4 es un chef experto que sabe cocinar de todo. El fine-tuning sería como darle a ese chef un curso intensivo sobre la cocina de tu abuela. No le enseñas a cocinar desde cero, sino que ajustas su estilo y "sazón" para que sus platos tengan ese toque familiar.

Técnicamente, implica re-entrenar ligeramente el modelo con un set de datos de ejemplos (preguntas y respuestas) para que aprenda un nuevo estilo, un formato específico o un conocimiento muy especializado que no se puede obtener solo con contexto.

Cuándo usarlo: Cuando necesitas que el modelo cambie su comportamiento, hable en un tono muy específico (ej. jerga legal) o aprenda una habilidad nueva y muy concreta.

RAG (Generación Aumentada por Recuperación)

Siguiendo con la analogía del chef, RAG es como darle un libro de recetas justo antes de que empiece a cocinar. En lugar de cambiar su estilo, le das acceso a la información precisa que necesita en el momento.

Técnicamente, RAG es un sistema que, ante una pregunta, primero busca información relevante en una base de datos de documentos (usando embeddings y búsqueda vectorial) y luego le pasa esa información al LLM como parte del contexto para que formule la respuesta.

Cuándo usarlo: Cuando necesitas que el modelo responda basándose en información específica y actualizada que puede cambiar con el tiempo (documentación interna, catálogos de productos, noticias recientes).

El Criterio de Decisión: Fine-tuning vs. RAG

Aquí está mi mapa mental para decidir cuál usar:

Criterio	Elige Fine-tuning si...	Elige RAG si...
Objetivo	Quieres cambiar el estilo, tono o formato del modelo.	Quieres que responda con datos específicos y verificables.
Fuente de Datos	Tus datos son un conjunto de ejemplos de conversación.	Tus datos son una colección de documentos (PDFs, webs, etc.).
Actualización	El conocimiento que enseñas es estático y no cambia a menudo.	La información cambia constantemente y necesitas respuestas actualizadas.
Alucinaciones	Es menos efectivo para reducirlas. El modelo aún puede "inventar".	Es muy efectivo. La respuesta se basa en la información recuperada.
Costo y Complejidad	Más caro y complejo. Requiere preparación de datos y re-entrenamiento.	Más barato y rápido de implementar. Solo necesitas indexar tus documentos.

Un Ejemplo Práctico

Proyecto A: Un chatbot que responde dudas sobre nuestra base de conocimiento interna.
- La base de conocimiento se actualiza cada semana.
- Necesitamos respuestas precisas y evitar que el bot invente cosas.
- Elección clara: RAG.
Proyecto B: Un asistente que convierte el lenguaje natural en consultas SQL complejas.
- No necesita datos externos, sino aprender una habilidad muy específica (traducir de español a SQL).
- Necesitamos que el comportamiento del modelo cambie para que genere código en lugar de texto.
- Elección clara: Fine-tuning.

Conclusión: No es uno u otro, a veces son ambos

La belleza de esto es que RAG y Fine-tuning no son mutuamente excluyentes. En arquitecturas avanzadas, puedes tener un modelo que ha sido fine-tuned para entender mejor la jerga de tu industria y que, además, utiliza un sistema RAG para acceder a los datos más recientes.

Mi recomendación es siempre empezar con RAG. Es más rápido, más barato y suele resolver el 80% de los casos de uso de negocio. Si después de implementar RAG notas que el modelo aún no tiene el tono o el estilo de respuesta que necesitas, entonces y solo entonces, considera añadir una capa de fine-tuning.

Espero que esta guía te aclare el panorama y te ayude a tomar la mejor decisión para tu próximo proyecto de IA Generativa.

]]>

Mon, 19 Sep 2022 00:00:00 GMT

La palabra "serverless" suena a magia, pero en realidad es una de las formas más prácticas y eficientes de construir aplicaciones hoy en día sin tener que preocuparse por la gestión de la infraestructura subyacente. Como arquitecto, mi objetivo es siempre encontrar la solución más simple y escalable para un problema, y muy a menudo, la respuesta está en el ecosistema serverless de AWS.

En este artículo, quiero enfocarme en el trío de servicios que se ha convertido en la base de muchos de mis proyectos de backend: AWS Lambda, API Gateway y DynamoDB. Te explicaré qué es cada uno, cómo se conectan y por qué esta combinación es mi favorita para lanzar APIs y microservicios de forma increíblemente rápida.

Los Tres Mosqueteros del Backend Serverless

Pensemos en estos servicios como un equipo especializado donde cada uno tiene una misión muy clara.

1. AWS Lambda: El cerebro

Lambda es el corazón de la operación. Es un servicio de computación que te permite ejecutar código sin aprovisionar o administrar servidores. Simplemente subes tu código (en Python, Node.js, etc.) en forma de "función" y Lambda se encarga de todo lo demás: ejecutarlo, escalarlo y solo cobrarte por el tiempo de computación que consumes, hasta el milisegundo.

Su trabajo: Contener la lógica de negocio. ¿Necesitas procesar un pago, registrar un usuario o analizar una imagen? Escribes una función Lambda para ello.

2. API Gateway: La puerta de entrada

Tu función Lambda vive aislada en la nube. Para que el mundo exterior (una aplicación web, una app móvil) pueda comunicarse con ella, necesitas una puerta de entrada segura y gestionada. Ese es el trabajo de API Gateway.

Su trabajo: Crear un endpoint HTTP (una URL) que, cuando se invoca, ejecuta tu función Lambda. Se encarga de la seguridad, el manejo de tráfico (throttling), el cacheo de respuestas y la validación de peticiones. Es el portero robusto de tu backend.

3. DynamoDB: La memoria instantánea

Tus funciones Lambda son "sin estado" (stateless), lo que significa que no recuerdan nada entre ejecuciones. Para guardar información de forma persistente (datos de usuarios, logs, estados de pedidos), necesitas una base de datos. DynamoDB es la base de datos NoSQL nativa de AWS, diseñada para una latencia de milisegundos a cualquier escala.

Su trabajo: Almacenar y recuperar datos con una velocidad y escalabilidad masivas. Su integración nativa con Lambda es perfecta, permitiendo que tus funciones lean y escriban información de forma casi instantánea.

¿Cómo funciona todo junto? un flujo típico

Imagina que un usuario se registra en tu aplicación:

El Frontend (tu app web o móvil) envía una petición POST a la URL gestionada por API Gateway.
API Gateway recibe la petición, la valida y la reenvía para invocar a tu función Lambda de "registro de usuario".
La función Lambda se ejecuta, procesa los datos del usuario (hashea la contraseña, valida el email) y escribe el nuevo registro en una tabla de DynamoDB.
La función Lambda devuelve una respuesta de éxito a API Gateway, que a su vez la reenvía al frontend.

Todo este proceso ocurre en milisegundos, sin que hayas tenido que configurar un solo servidor, parchear un sistema operativo o preocuparte por si necesitas más capacidad si de repente se registran miles de usuarios.

Conclusión

Construir backends de esta manera no solo es eficiente desde el punto de vista del desarrollo, sino también de los costos. Al pagar solo por lo que usas, es una forma increíblemente económica de empezar un proyecto y tienes la tranquilidad de saber que puede escalar para manejar una demanda masiva sin que tengas que intervenir manualmente.

Si estás pensando en tu próximo proyecto de backend, te recomiendo encarecidamente que explores este trío de servicios. Es probable que descubras, como yo, que es la forma más directa y robusta de llevar tus ideas a producción.

]]>

Wed, 20 Aug 2025 00:00:00 GMT

¿Qué tienen en común Pokémon y un proyecto de Machine Learning de nivel profesional? Más de lo que te imaginas. Detrás de la nostalgia y las batallas, el universo Pokémon es un ecosistema de datos increíblemente rico, el campo de juego perfecto para construir y demostrar un ciclo de vida completo de MLOps.

En este artículo, te llevaré en un viaje a través de mi proyecto "Ciencia Pokémon". El objetivo no es la precisión de un modelo, sino implementar una arquitectura robusta, reproducible y automatizada para resolver un problema divertido: predecir el tipo de un Pokémon basándonos únicamente en el color dominante de su sprite. Todo esto, empaquetado y servido a través de una API RESTful lista para producción.

La Chispa: Descubriendo los Secretos de la Pokédex

Todo gran proyecto de datos empieza con una pregunta. La mía era: más allá de lo que nos dicen los juegos, ¿qué patrones ocultos existen en los stats de más de 1000 Pokémon? Antes de escribir una sola línea de código para un modelo, me sumergí en un profundo Análisis Exploratorio de Datos (EDA). Los hallazgos fueron la verdadera chispa que encendió este proyecto.

Arquetipos de Combate Ocultos

Decidí ignorar las etiquetas y dejar que los datos hablaran por sí mismos. Usando un algoritmo de clustering K-Means sobre las estadísticas base (HP, Ataque, Defensa, etc.), los Pokémon se agruparon de forma natural en 5 "roles" o arquetipos de combate distintos. La visualización con PCA fue reveladora: un eje representaba el "Poder General", mientras que el otro definía un espectro entre "Agilidad vs. Robustez".

El "Power Creep" es Real

También confirmé una sospecha de muchos fans: el "power creep" existe. Hay una tendencia estadísticamente clara que muestra cómo las estadísticas totales promedio de los Pokémon han ido aumentando en las generaciones más recientes.

Con estos insights, y viendo que había una estructura coherente en los datos, me sentí con la confianza para abordar el objetivo principal: si el color de un Pokémon está tan ligado a su tipo, ¿podríamos predecirlo?

La Arquitectura: Un Enfoque MLOps Profesional

Un notebook de Jupyter es genial para explorar, pero para crear un producto de software real, se necesita una estructura. Diseñé un flujo de trabajo que asegura la calidad y la reproducibilidad en cada etapa.

🧪 Seguimiento con MLflow: Cada experimento, cada ajuste de hiperparámetros, fue registrado meticulosamente con MLflow. Esto me permite tener una trazabilidad completa, comparar resultados y saber exactamente qué versión del modelo es la que mejor funciona, evitando el caos de tener docenas de notebooks llamados modelo_final_final_v2.ipynb.
📦 Versionamiento con DVC: Los modelos entrenados y los datasets pueden ser pesados. En lugar de subirlos a Git, usé DVC (Data Version Control) para versionarlos. Esto mantiene el repositorio ligero mientras asegura que cualquiera pueda reproducir mis resultados descargando la versión exacta de los datos y el modelo que usé.

🚀 Despliegue con FastAPI y Docker: El modelo final se envolvió en una API RESTful con FastAPI. ¿Por qué? Porque es increíblemente rápido, moderno y genera documentación interactiva de la API de forma automática (¡hola, Swagger UI!). Toda esta aplicación fue encapsulada en un contenedor de Docker, garantizando que funcione de la misma manera en cualquier entorno, desde mi laptop hasta un servidor en la nube.

El código para un endpoint de predicción en FastAPI es un gran ejemplo de simplicidad y poder:

# fragmento de src/api/main.py
@app.post("/predict")
def predict(pokemon_name: str):
    """
    Predice el tipo de un Pokémon basándose en su nombre.
    """
    try:
        # Lógica para obtener el sprite, extraer el color y predecir
        color_hex = get_dominant_color_from_sprite(pokemon_name)
        prediction = model.predict([color_hex])[0]
        
        return {"pokemon": pokemon_name, "predicted_type": prediction}
    except Exception as e:
        raise HTTPException(status_code=404, detail=str(e))

🤖 Automatización con GitHub Actions: Para cerrar el ciclo, configuré un pipeline de Integración Continua (CI) con GitHub Actions. Cada vez que hago un push, se ejecutan automáticamente las pruebas unitarias (pytest), asegurando que ningún cambio nuevo rompa la funcionalidad existente.

Conclusión: Más Allá del Modelo

Este proyecto fue un ejercicio práctico para demostrar que los principios de MLOps no están reservados para las grandes empresas. Herramientas de código abierto como MLflow, DVC y Docker son accesibles y transforman un simple script de machine learning en un producto de software robusto, versionado y desplegable.

La historia que nos cuentan los datos de Pokémon es fascinante, revelando una complejidad inesperada. Pero la historia más importante aquí es cómo podemos tomar esa curiosidad inicial, validarla con un análisis de datos sólido y, finalmente, construir sistemas de IA de manera profesional y escalable.

Si te interesa explorar el código, las pruebas automatizadas o incluso ejecutar la API en tu propia máquina, te invito a visitar el repositorio completo en mi perfil de GitHub.

]]>

Sun, 17 Dec 2023 00:00:00 GMT

Cuando necesito lanzar un backend rápido para un proyecto personal o una Prueba de Concepto (PoC), no pierdo tiempo configurando servidores, balanceadores de carga o gestionando conexiones a bases de datos. Tengo una arquitectura "Go-To" en AWS que me permite tener una API funcionando en minutos, no en días.

En este artículo, quiero compartir esta plantilla serverless que he refinado con el tiempo. Es una combinación de tres servicios clave de AWS que, juntos, ofrecen una velocidad de desarrollo, una escalabilidad automática y una eficiencia en costos que son difíciles de superar. Es la base que uso para validar ideas rápidamente y construir cimientos sólidos para aplicaciones más grandes.

El Trío Serverless: API Gateway, Lambda y DynamoDB

Mi stack se basa en tres servicios que se integran a la perfección:

API Gateway: El Recepcionista. Es la puerta de entrada pública y segura a nuestra lógica de negocio. Se encarga de recibir las peticiones HTTP, gestionar la seguridad (API Keys, autenticación), controlar el tráfico y dirigir cada petición a la función correcta.
AWS Lambda: El Trabajador. Aquí es donde vive nuestro código (en mi caso, generalmente Python). Son funciones que se ejecutan bajo demanda, sin que tengamos que preocuparnos por el servidor subyacente. Si llegan 10 peticiones, AWS ejecuta 10 instancias; si llegan 10,000, escala automáticamente. Pagas solo por los milisegundos que tu código se está ejecutando.
DynamoDB: El Archivador. Como las funciones Lambda no tienen estado, necesitamos un lugar para guardar los datos. DynamoDB es una base de datos NoSQL ultra-rápida, con latencia de un solo dígito de milisegundo, ideal para el acceso rápido que requieren las funciones serverless.

Viéndolo en Acción: Un Flujo Típico

La belleza de esta arquitectura es su simplicidad. Un flujo de datos para una petición común, como crear un nuevo usuario, se vería así:

Un cliente (una app web o móvil) envía una petición POST a api.misitio.com/usuarios.
API Gateway recibe la petición en esa ruta y la dirige a la función Lambda crearUsuario.
La función Lambda se ejecuta, valida los datos del cuerpo de la petición (nombre, email, etc.) y los escribe en la tabla Usuarios de DynamoDB.
La función devuelve un 201 Created, que API Gateway transforma en una respuesta HTTP y la envía de vuelta al cliente.

Un ejemplo conceptual de cómo se vería la función Lambda en Python es sorprendentemente simple:

# fragmento de una función Lambda para crear un usuario
import boto3
import json

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('Usuarios')

def handler(event, context):
    try:
        # 1. Obtener los datos del cuerpo de la petición
        body = json.loads(event['body'])
        user_id = body['user_id']
        email = body['email']

        # 2. Escribir en DynamoDB
        table.put_item(
            Item={
                'user_id': user_id,
                'email': email,
                'status': 'activo'
            }
        )
        
        # 3. Devolver una respuesta de éxito
        return {
            'statusCode': 201,
            'body': json.dumps({'message': 'Usuario creado con éxito'})
        }

    except Exception as e:
        # Manejo de errores
        return {
            'statusCode': 500,
            'body': json.dumps({'error': str(e)})
        }

Bonus: Infraestructura como Código (IaC)

Lo mejor de todo es que esta arquitectura completa (la API, la función, la tabla y los permisos entre ellos) se puede definir en un único archivo de configuración usando herramientas como Terraform o AWS SAM. Esto significa que puedes desplegar todo el backend con un solo comando, de forma repetible y segura.

Conclusión

Este stack serverless es mi receta para la velocidad y la escalabilidad. Me permite concentrarme en la lógica de negocio en lugar de en la gestión de infraestructura, reduce drásticamente los costos iniciales y me da la tranquilidad de que la aplicación puede crecer sin problemas.

Si buscas una forma eficiente de construir tus próximos proyectos, te recomiendo encarecidamente que pruebes esta combinación.

]]>

Mon, 15 Sep 2025 00:00:00 GMT

El abismo entre el prototipo y la producción

Como arquitecto de IA, he visto un patrón repetirse en muchos equipos: después de semanas de trabajo, el equipo de ciencia de datos presenta un modelo de Machine Learning con resultados impresionantes. Funciona a la perfección en su Jupyter Notebook, predice con una precisión asombrosa y promete revolucionar una parte del negocio. Todos están emocionados.

Pero entonces llega la pregunta clave: "Excelente, ¿cómo lo ponemos en producción?"

Y es ahí donde a menudo aparece un gran abismo. El código que funciona en la laptop de un analista es un mundo aparte de un servicio robusto, escalable y seguro que pueda ser consumido por aplicaciones reales y que soporte miles de peticiones. El camino para cruzar ese abismo se conoce como MLOps (Machine Learning Operations), y es una de las disciplinas más críticas y complejas en el mundo de la IA hoy en día.

Afortunadamente, no tenemos que construir ese puente desde cero. AWS nos ofrece un ecosistema completo diseñado específicamente para cerrar esa brecha: Amazon SageMaker. En este artículo, no vamos a ver a SageMaker como una simple herramienta, sino como la solución estratégica que nos permite llevar nuestros modelos del laboratorio al mundo real.

¿Qué es realmente Amazon SageMaker?

Cuando escuchamos "SageMaker", es fácil pensar que es una única herramienta o un simple servicio para desplegar modelos. Pero esa visión se queda corta. La mejor forma de entender Amazon SageMaker es verlo como una suite de herramientas integradas que te acompaña durante todo el ciclo de vida del Machine Learning, desde la exploración inicial de los datos hasta el monitoreo del modelo en producción.

Imagina que en lugar de comprar herramientas de diferentes marcas para cada etapa de un proyecto (una para la preparación de datos, otra para el entrenamiento, otra para el despliegue), tuvieras un taller completo y unificado donde cada herramienta está diseñada para funcionar a la perfección con las demás. Eso es SageMaker.

Aunque su ecosistema es muy amplio, incluyendo funcionalidades como SageMaker Studio para la experimentación o SageMaker Training Jobs para entrenamientos a gran escala, en este artículo nos vamos a centrar en el componente que resuelve el problema del "abismo" que mencionamos: el despliegue de modelos como servicios consumibles.

El corazón del despliegue: SageMaker Endpoints

Una vez que tenemos un modelo entrenado, ¿cómo hacemos para que nuestras aplicaciones puedan "hablar" con él? La respuesta en el ecosistema de SageMaker es a través de un Endpoint.

Un endpoint es, en esencia, una API HTTPS segura y totalmente gestionada que "envuelve" a tu modelo de Machine Learning. Su trabajo es recibir datos nuevos (por ejemplo, las características de un nuevo cliente), pasárselos a tu modelo, y devolver la predicción que este genera. Al exponer el modelo a través de una API estándar, cualquier aplicación, sin importar en qué lenguaje esté escrita, puede integrarse con él de forma sencilla y segura.

SageMaker se encarga de toda la complejidad por debajo: provisiona los servidores, instala el software necesario, configura el balanceo de carga para alta disponibilidad y asegura la comunicación. Como arquitectos, nuestro trabajo se centra en elegir el tipo de endpoint adecuado para el problema de negocio que estamos resolviendo. Principalmente, existen tres modalidades:

1. Inferencia en Tiempo Real (Real-Time Inference)

Esta es la opción clásica y la más utilizada. Se provisiona una o más instancias de cómputo que están activas 24/7, listas para recibir peticiones y devolver una predicción en milisegundos.

Caso de uso ideal: Aplicaciones que necesitan una respuesta instantánea para el usuario final, como sistemas de recomendación de productos, detección de fraude en transacciones o chatbots.

2. Inferencia Serverless (Serverless Inference)

Esta modalidad es perfecta para cargas de trabajo impredecibles o intermitentes. En lugar de tener un servidor siempre encendido, SageMaker provisiona la infraestructura automáticamente cuando llega una petición y la apaga cuando no hay tráfico.

Caso de uso ideal: Funcionalidades que no se usan constantemente, como el procesamiento de un formulario de contacto con IA o un análisis de imagen que se ejecuta solo unas pocas veces al día. El modelo de costos es de pago por uso, lo que puede ser extremadamente eficiente.

3. Transformación por Lotes (Batch Transform)

No todas las predicciones necesitan ser instantáneas. A veces, lo que necesitamos es procesar un gran volumen de datos de una sola vez. Batch Transform está diseñado para esto. Le das un set de datos completo (por ejemplo, un archivo CSV con miles de clientes) y SageMaker se encarga de obtener las predicciones para cada uno de ellos, guardando los resultados en un bucket de S3.

Caso de uso ideal: Procesos que se ejecutan de forma periódica, como la segmentación de toda tu base de clientes durante la noche o el análisis de sentimiento de todos los comentarios de un día.

Ejemplo práctico: los pasos para desplegar un modelo

Para hacer esto más tangible, vamos a repasar los pasos conceptuales que seguiríamos para desplegar un modelo de clasificación simple (por ejemplo, uno entrenado con Scikit-learn) y exponerlo a través de un endpoint en tiempo real. No nos sumergiremos en cientos de líneas de código, sino que nos enfocaremos en el "qué" y el "porqué" de cada paso.

Paso 1: Empaquetar y subir el modelo

Lo primero es tomar nuestro modelo ya entrenado, que usualmente es un archivo (como model.joblib o model.pkl), y subirlo a un lugar centralizado y seguro en la nube. El servicio ideal para esto en AWS es Amazon S3 (Simple Storage Service). S3 actúa como nuestro almacén de artefactos, un repositorio donde SageMaker podrá encontrar el modelo cuando lo necesite.

Paso 2: Crear una "definición de modelo" en SageMaker

Una vez que nuestro modelo está en S3, necesitamos decirle a SageMaker cómo usarlo. Esto se hace creando una "Definición de Modelo". Aquí especificamos dos cosas clave:

La ubicación del modelo: Le damos la ruta al archivo que subimos a S3.
El contenedor de inferencia: Le indicamos qué entorno de software necesita el modelo para ejecutarse. SageMaker ofrece contenedores pre-construidos para los frameworks más populares (Scikit-learn, TensorFlow, PyTorch), por lo que en la mayoría de los casos, solo tenemos que elegir el correcto.

Paso 3: Configurar el endpoint

Aquí es donde definimos las características de la infraestructura que servirá nuestro modelo. Creamos una "Configuración de Endpoint" donde especificamos:

El tipo de instancia: ¿Necesitamos una máquina potente con GPU o una más modesta y económica? La elección depende de la complejidad del modelo y la latencia que necesitemos.
El número de instancias: Podemos empezar con una sola y configurar el auto-scaling para que SageMaker añada más si el tráfico aumenta.

Paso 4: Crear el endpoint

Con todo lo anterior definido, el último paso es ejecutar el comando para crear el endpoint. En este momento, SageMaker toma el control y automatiza todo el proceso de MLOps: provisiona las instancias, descarga el modelo desde S3, despliega el contenedor, configura la red y expone una URL segura. En cuestión de minutos, lo que eran solo archivos en una laptop se ha convertido en un servicio de inferencia robusto y escalable.

Paso 5: Invocar y obtener predicciones

Una vez que el endpoint está activo, podemos invocarlo desde cualquier aplicación usando el SDK de AWS. El código para hacerlo es sorprendentemente simple. En Python, por ejemplo, se vería algo así:

import boto3
import json

# Cliente de SageMaker
sagemaker_runtime = boto3.client('sagemaker-runtime')

# Datos del nuevo cliente a predecir
datos_nuevos = [[10.2, 5.1, 2.3, 1.4]] 

# Nombre de nuestro endpoint
endpoint_name = 'mi-endpoint-de-clasificacion'

# Invocamos el endpoint
response = sagemaker_runtime.invoke_endpoint(
    EndpointName=endpoint_name,
    ContentType='application/json',
    Body=json.dumps(datos_nuevos)
)

# Leemos la predicción
resultado = json.loads(response['Body'].read().decode())
print(f"La predicción del modelo es: {resultado}")

Y así, hemos cruzado el abismo. Hemos transformado un modelo estático en un servicio dinámico y productivo.

Conclusión: El valor de negocio no está en el modelo, sino en su despliegue

Tener un modelo de Machine Learning con una alta precisión es un logro técnico impresionante, pero en el contexto de negocio, un modelo que no está en producción tiene un valor real de cero. Su potencial solo se materializa cuando empieza a recibir datos del mundo real y a devolver predicciones que impactan en las operaciones de la empresa.

Herramientas como Amazon SageMaker son una decisión estratégica porque abstraen la complejidad inmensa del MLOps (Machine Learning Operations). Liberan a los equipos de ciencia de datos y de ingeniería de la pesada carga de gestionar infraestructura, configurar redes, balancear cargas y monitorear servidores.

Al adoptar una plataforma gestionada, permitimos que nuestros equipos más talentosos se enfoquen en lo que realmente aporta valor: experimentar, mejorar los modelos y resolver problemas de negocio. La verdadera ventaja competitiva no viene de construir la infraestructura más compleja, sino de la velocidad con la que podemos poner la inteligencia artificial en manos de quienes la necesitan.

En resumen, SageMaker nos permite cruzar el abismo entre el prototipo y la producción de una forma rápida, escalable y segura, transformando nuestros modelos de un ejercicio académico a un activo estratégico para el negocio.

]]>

Sat, 31 Aug 2024 00:00:00 GMT

Como analista de datos y aficionado al fútbol, siempre me ha fascinado la historia que los números pueden contar sobre un partido. Sitios como understat.com son una auténtica mina de oro, con estadísticas detalladas de tiros, pases y métricas avanzadas como los Goles Esperados (xG). El único problema: no tienen una API pública.

Si quería analizar estos datos a escala, enfrentaba el mismo desafío que muchos: escribir scripts de web scraping una y otra vez. Era un proceso repetitivo y poco eficiente. Así que decidí resolver el problema de raíz y, en el proceso, crear algo útil para la comunidad.

Así nació UnderData, mi propia librería de Python diseñada para una sola cosa: hacer que obtener datos de understat.com sea increíblemente simple. En este post, te cuento la historia detrás de la herramienta y te muestro cómo puedes usarla para empezar tus propios análisis.

El Problema: Datos valiosos, acceso complicado

La web está llena de datos valiosos, pero a menudo no están en un formato fácil de consumir. El web scraping es la solución clásica, pero tiene sus desventajas:

Es frágil: Un pequeño cambio en el HTML del sitio puede romper tu script.
Es repetitivo: Escribir la misma lógica para encontrar y extraer tablas es tedioso.
No es escalable: Mantener scripts individuales para diferentes tipos de datos (jugadores, partidos, ligas) se vuelve un caos.

Yo quería una solución que me permitiera pedir los datos de forma tan simple como: "dame todas las estadísticas de pases de Lionel Messi en la temporada 2018/2019".

La Solución: Construyendo `UnderData`

Decidí encapsular toda la lógica de scraping en una librería de Python robusta y fácil de usar. Los principios de diseño fueron claros:

Interfaz Sencilla: Métodos intuitivos para cada tipo de dato (get_player_stats, get_match_shots, etc.).
Salida en DataFrame de Pandas: La librería debía devolver los datos en el formato que cualquier analista de datos en Python espera y ama.
Mantenibilidad: Una estructura de código limpia que me permitiera actualizarla fácilmente si understat.com cambia su estructura.

¿Cómo Usar `UnderData`?

Después de instalarla con pip (pip install underdata), obtener los datos de un jugador es tan simple como esto:

import pandas as pd
from underdata import Understat

# Creamos una instancia del scraper
understat = Understat()

# Obtenemos los datos de un jugador por su ID en Understat
player_data = understat.get_player_stats(player_id=834)

# ¡Y listo! Tenemos un DataFrame de Pandas listo para analizar
print(player_data.head())

Con solo tres líneas de código, hemos resuelto todo el complejo proceso de scraping y ahora podemos concentrarnos en lo que realmente importa: el análisis.

Un Ejemplo de Análisis Rápido

Una vez que UnderData nos da los datos, las posibilidades son infinitas. Por ejemplo, podríamos obtener los datos de tiros de un partido y visualizar las zonas de mayor peligro con un mapa de calor.

import seaborn as sns
import matplotlib.pyplot as plt
from FCPython import createPitch # Usando una librería para dibujar la cancha

# Obtenemos los datos de tiros de un partido específico
match_shots = understat.get_match_shots(match_id=12345)

# Creamos la cancha
pitch, ax = createPitch()

# Filtramos los tiros del equipo local
home_shots = match_shots[match_shots['h_a'] == 'h']

# Creamos un mapa de calor con la ubicación de los tiros
sns.kdeplot(
    x=home_shots['X'] * 100, # Understat usa una escala de 0-1
    y=home_shots['Y'] * 100,
    shade=True,
    cmap='Reds',
    ax=ax
)

plt.title('Mapa de Calor de Tiros del Equipo Local')
plt.show()

Conclusión

Construir UnderData fue un proyecto increíblemente gratificante. No solo resolvió un problema personal, sino que me permitió crear una herramienta que otros en la comunidad de análisis de datos deportivos pueden usar. Demuestra que, a veces, el primer paso para un gran análisis es construir la puerta de acceso a los datos.

Si te interesa el análisis de fútbol o quieres ver cómo está construida la librería por dentro, te invito a visitar el repositorio en GitHub.

]]>

Fri, 30 Jun 2023 00:00:00 GMT

Seguro te ha pasado: necesitas un diagrama de la arquitectura de tu sistema para una presentación o para documentar un proyecto. Abres una herramienta online, pasas un buen rato arrastrando cajas, conectando flechas, alineando todo... y a las dos semanas, la arquitectura cambia y tu diagrama queda obsoleto. Un clásico.

Durante mucho tiempo, ese fue mi flujo de trabajo, hasta que descubrí el concepto de "Diagramas como Código" (Diagrams as Code). La idea es simple pero poderosa: definir la infraestructura y los flujos de un sistema usando un lenguaje de programación. Mi herramienta favorita para esto es, sin duda, la librería diagrams de Python.

En este post te quiero contar por qué he adoptado esta práctica y cómo puedes empezar a crear diagramas complejos que se actualizan tan fácil como cambiar un par de líneas de código.

¿Por qué "Diagramas como Código"?

Adoptar este enfoque tiene ventajas que van mucho más allá de simplemente "dibujar" con código:

Versionamiento: Tus diagramas viven en tu repositorio de Git. Puedes ver su historial, revertir cambios y saber exactamente cuándo y por qué se modificó la arquitectura.
Consistencia: Al definir los componentes con código, te aseguras de que todos los diagramas de la empresa usen los mismos íconos y convenciones.
Rapidez: Una vez que tienes la base, añadir o quitar un servicio es cuestión de añadir o borrar una línea de código, no de pasar minutos reacomodando cajas y flechas.
Fuente Única de Verdad: El código no miente. El diagrama representa lo que el código dice, eliminando ambigüedades.

Manos a la obra: la librería `diagrams`

La librería diagrams te permite describir arquitecturas de nube con proveedores como AWS, Azure, GCP, Kubernetes, entre otros, sin necesidad de herramientas de diseño.

Primero, la instalación es tan sencilla como cualquier otro paquete de Python:

pip install diagrams

Además, necesitas tener instalado Graphviz, que es el motor que diagrams usa por debajo para renderizar los gráficos. Puedes instalarlo con el gestor de paquetes de tu sistema (ej. brew install graphviz en macOS o sudo apt-get install graphviz en Debian/Ubuntu).

Ejemplo 1: Una API serverless sencilla

Imaginemos que queremos diagramar una API simple en AWS. El flujo es: un usuario se conecta a un API Gateway, que invoca una función Lambda, y esta a su vez lee datos de una tabla en DynamoDB.

El código en Python se vería así:

# api_simple.py
from diagrams import Diagram
from diagrams.aws.compute import Lambda
from diagrams.aws.database import DynamoDB
from diagrams.aws.network import APIGateway

with Diagram("API Serverless Sencilla", show=False):
    api_gateway = APIGateway("API Gateway")
    mi_funcion_lambda = Lambda("Procesador de Datos")
    tabla_dynamo = DynamoDB("Tabla de Usuarios")

    api_gateway >> mi_funcion_lambda >> tabla_dynamo

Al ejecutar python api_simple.py, se generará una imagen como esta:

Ejemplo 2: Arquitectura Web Más Completa

Ahora, vamos a un caso un poco más realista: una aplicación web dentro de una VPC con una base de datos RDS.

# web_app.py
from diagrams import Diagram, Cluster
from diagrams.aws.compute import EC2
from diagrams.aws.database import RDS
from diagrams.aws.network import ELB, Route53

with Diagram("Aplicación Web con Base de Datos", show=False):
    dns = Route53("DNS")
    load_balancer = ELB("Load Balancer")

    with Cluster("Servidores Web"):
        servidores_web = [EC2("Worker 1"),
                          EC2("Worker 2"),
                          EC2("Worker 3")]

    with Cluster("Base de Datos"):
        db_primaria = RDS("DB Primaria")
        db_primaria - [RDS("Réplica 1"),
                     RDS("Réplica 2")]

    dns >> load_balancer >> servidores_web
    servidores_web >> db_primaria

Este código introduce el concepto de Cluster para agrupar componentes, haciendo el diagrama mucho más legible.

Conclusión

Crear diagramas como código ha cambiado por completo la forma en que documento y comparto la arquitectura de mis proyectos. Me da una agilidad que ninguna herramienta visual puede ofrecer y mantiene mi documentación sincronizada con la realidad de mi código.

Si aún no lo has probado, te animo a darle una oportunidad a la librería diagrams. Es una de esas herramientas que, una vez que la usas, te preguntas cómo pudiste vivir sin ella.

]]>

Sun, 17 Aug 2025 00:00:00 GMT

En el mundo de los datos, a menudo nos obsesionamos con los modelos de Machine Learning y los dashboards impresionantes. Pero hay un héroe silencioso que sostiene todo ese ecosistema: la integridad de los datos. Si tus datos no son confiables, tus análisis y predicciones tampoco lo serán.

Trabajando en varios proyectos, me encontré repetidamente con el mismo desafío: verificar que los datos en nuestras bases de datos (PostgreSQL, MySQL) cumplieran con las reglas de negocio. ¿Hay valores nulos donde no debería? ¿Existen duplicados en claves primarias? ¿Los tipos de datos son los correctos? Hacer estas validaciones manualmente es tedioso y propenso a errores.

Cansado de escribir scripts repetitivos para cada nuevo proyecto, decidí construir una solución unificada. Así nació PyntegrityDB, mi herramienta de línea de comandos (CLI) de código abierto, desarrollada en Python para automatizar la validación de la integridad de los datos.

¿Qué es PyntegrityDB?

PyntegrityDB es una utilidad que se conecta a tu base de datos y ejecuta una serie de pruebas de validación que defines en un simple archivo de configuración YAML. Su objetivo es simple: darte un reporte claro y rápido sobre la salud de tus tablas, permitiéndote detectar problemas antes de que impacten tus aplicaciones o análisis.

Las validaciones que puedes realizar incluyen:

Verificar que una columna no contenga valores nulos (not_null).
Asegurar que todos los valores en una columna sean únicos (unique).
Confirmar que los valores de una columna se encuentren dentro de un conjunto predefinido (in_values).
Y muchas más.

¿Cómo Funciona? El Poder de un YAML Simple

En lugar de escribir código complejo, defines tus pruebas en un archivo config.yaml. Esto desacopla las reglas de validación de la lógica de la aplicación, haciendo que sea muy fácil de mantener.

Imagina que quieres validar una tabla de usuarios:

# config.yaml
tables:
  users:
    columns:
      user_id:
        not_null: true
        unique: true
      email:
        not_null: true
        unique: true
      status:
        in_values:
          - active
          - inactive
          - pending

Luego, desde tu terminal, simplemente ejecutas la herramienta:

pyntegritydb --config config.yaml --db-uri "postgresql://user:pass@host/db"

La herramienta se conecta, ejecuta cada una de las 9 validaciones definidas y te entrega un resumen claro. Si encuentra un error, como un email duplicado, te lo informará al instante.

¿Cómo llevas una herramienta de calidad de datos al límite?

Quise probar la potencia de pyntegritydb, así que simulé un escenario adverso para cualquier equipo de datos:

Creé una base de datos TPC-H de +1 GB con millones de registros de pedidos, clientes y productos.
Luego, la corrompí intencionadamente: borré miles de clientes para dejar pedidos huérfanos y actualicé claves foráneas para que apuntaran a la nada.

El resultado: una base de datos masiva con más de 150,000 errores de integridad referencial escondidos.

El momento de la verdad. Ejecuté un solo comando:

pyntegritydb "postgresql:[ruta]" --config config.yml --visualize

En menos de 60 segundos, la herramienta no solo procesó los millones de registros, sino que:

✅ Identificó cada uno de los +150,000 errores de completitud y consistencia.
🚦 Generó alertas porque los errores violaban los umbrales de calidad que definí.
🎨 Creó un mapa visual del esquema, destacando en rojo las relaciones rotas.

Esto no se trata solo de encontrar errores; se trata de cuantificar el riesgo en tus datos y obtener una hoja de ruta clara para restaurar la confianza en tus pipelines.

La Historia Detrás de la Herramienta

Como mencioné en una de mis publicaciones en LinkedIn, mi objetivo era tener "confianza total en que nuestros datos cumplen con las reglas de negocio". PyntegrityDB nació de esa necesidad. Quería una forma de "darle superpoderes a mis validaciones", permitiéndome ejecutar docenas de pruebas en segundos con un solo comando.

El desarrollo no se detiene. Estoy trabajando en expandir las capacidades de la herramienta, incluyendo la posibilidad de generar automáticamente pruebas de integridad a partir de un schema.yml.

Conclusión

La integridad de los datos no es un tema glamoroso, pero es la base sobre la que se construyen los grandes productos de datos. Construir PyntegrityDB fue mi forma de abordar este desafío de una manera sistemática y reutilizable.

Si trabajas con bases de datos relacionales, te invito a probar la herramienta. Está disponible en PyPI (pip install pyntegritydb) y el código es completamente abierto en GitHub. Todo el feedback, ideas o contribuciones son más que bienvenidos.

]]>

OsviDev | Blog de IA y Datos

El problema: del caos de datos a la claridad

Mi solución: una arquitectura de pipeline moderna en AWS

1. Ingesta en tiempo real con Amazon Kinesis

2. Almacenamiento crudo en Amazon S3 (nuestro data lake)

3. Transformación serverless con AWS Lambda o AWS Glue

4. Carga en el data warehouse con Amazon Redshift

Conclusión: una base para decisiones inteligentes

Entendiendo las Bases: ¿Qué es Cada Cosa?

Fine-tuning (Ajuste Fino)

RAG (Generación Aumentada por Recuperación)

El Criterio de Decisión: Fine-tuning vs. RAG

Un Ejemplo Práctico

Conclusión: No es uno u otro, a veces son ambos

Los Tres Mosqueteros del Backend Serverless

1. AWS Lambda: El cerebro

2. API Gateway: La puerta de entrada

3. DynamoDB: La memoria instantánea

¿Cómo funciona todo junto? un flujo típico

Conclusión

La Chispa: Descubriendo los Secretos de la Pokédex

Arquetipos de Combate Ocultos

El "Power Creep" es Real

La Arquitectura: Un Enfoque MLOps Profesional

Conclusión: Más Allá del Modelo

El Trío Serverless: API Gateway, Lambda y DynamoDB

Viéndolo en Acción: Un Flujo Típico

Conclusión

¿Qué es realmente Amazon SageMaker?

El corazón del despliegue: SageMaker Endpoints

1. Inferencia en Tiempo Real (Real-Time Inference)

2. Inferencia Serverless (Serverless Inference)

3. Transformación por Lotes (Batch Transform)

Ejemplo práctico: los pasos para desplegar un modelo

Paso 1: Empaquetar y subir el modelo

Paso 2: Crear una "definición de modelo" en SageMaker

Paso 3: Configurar el endpoint

Paso 4: Crear el endpoint

Paso 5: Invocar y obtener predicciones

Conclusión: El valor de negocio no está en el modelo, sino en su despliegue

El Problema: Datos valiosos, acceso complicado

La Solución: Construyendo UnderData

¿Cómo Usar UnderData?

Un Ejemplo de Análisis Rápido

Conclusión

¿Por qué "Diagramas como Código"?

Manos a la obra: la librería diagrams

Ejemplo 1: Una API serverless sencilla

Ejemplo 2: Arquitectura Web Más Completa

Conclusión

¿Qué es PyntegrityDB?

¿Cómo Funciona? El Poder de un YAML Simple

¿Cómo llevas una herramienta de calidad de datos al límite?

La Historia Detrás de la Herramienta

Conclusión

La Solución: Construyendo `UnderData`

¿Cómo Usar `UnderData`?

Manos a la obra: la librería `diagrams`