Skip to content

Instantly share code, notes, and snippets.

@gusdelact

gusdelact/EjerciciosAvanzados_ConstruccionAplicaciones.md

Created April 20, 2026 06:38
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save gusdelact/7ffe399f54a8540bc2c10ef85c74461e to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save gusdelact/7ffe399f54a8540bc2c10ef85c74461e to your computer and use it in GitHub Desktop.
Download ZIP
Raw
EjerciciosAvanzados_ConstruccionAplicaciones.md

Ejercicios Avanzados — Kiro Power: Data Science Assistant

Ejercicios para que el alumno de la maestría use el Kiro Power Data Science Assistant como asistente integral en proyectos reales de ciencia de datos, desde la ingesta hasta el despliegue. El alumno NO escribe código desde cero: orquesta al Power desde Kiro en modo Vibe coding, revisa lo que produce, lo critica y lo mejora.

Objetivo global: que cada alumno ejecute un ciclo completo de ML supervisado sobre 5 datasets distintos de Kaggle usando el Power, valide su comportamiento, detecte bugs/limitaciones, y entregue retroalimentación para que futuras generaciones lo usen con mayor confianza.

¿Qué es un Kiro Power?

Un Kiro Power es un paquete reutilizable que empaca tres cosas en una sola unidad instalable en Kiro:

  1. Documentación (POWER.md) — Qué hace el Power, qué principios sigue, qué librerías cubre.
  2. Steering files — Guías de workflows específicos que Kiro carga en contexto solo cuando las necesita (EDA, entrenamiento, publicación a Kaggle, etc.).
  3. MCP Servers — Backends que exponen tools reales a Kiro (en este Power: Tavily, Kaggle, Hugging Face y Gradio Docs).

Cuando un Power está instalado, Kiro puede activarlo bajo demanda (action="activate") para cargar toda la documentación y el schema de las tools. Esto mantiene el contexto del chat limpio mientras se tiene acceso a capacidades completas cuando se requieren.

Qué aporta el Data Science Assistant

  • Arquitectura modular por etapas: cada fase del pipeline es un script independiente (01_ingest.py, 02_eda.py, ..., 08_deploy_hf.py). Permite intervención humana entre etapas.
  • Dos apps Gradio: app_training (UI local para orquestar el pipeline) y app_inference (UI pública desplegable a HF Spaces que consume el modelo desde Kaggle).
  • uv como gestor de entorno obligatorio. Nada de pip install directo.
  • Licenciamiento Apache 2.0 para todo dataset/modelo publicado, con la tabla de variantes de sintaxis por sistema (Kaggle CLI vs HF vs SPDX).
  • Dos credenciales distintas de Kaggle: token KGAT_ para el MCP y API Key (kaggle.json) para el CLI.

Instalación del Power

Antes de empezar los ejercicios, cada alumno debe instalar el Power en su Kiro:

# Clonar el Power en el directorio de powers de Kiro
git clone https://github.com/gusdelact/kiropowerdatascienceassistant.git ~/.kiro/powers/data-science-assistant

Luego configurar los placeholders en mcp.json del Power:

Y además configurar el CLI de Kaggle (necesario para publicar):

# Descargar kaggle.json desde https://www.kaggle.com/settings → API → Create New API Token
cp ~/Downloads/kaggle.json ~/.kaggle/kaggle.json
chmod 600 ~/.kaggle/kaggle.json
uv run kaggle datasets list -s "iris" --max-size 1  # Verificación

Validar en el chat de Kiro que el Power aparece listado y que activate devuelve los 4 MCP servers esperados.

Datasets asignados

Cada alumno trabaja los 5 datasets. La diversidad cubre clasificación binaria, multiclase y regresión, con diferentes tipos de "suciedad" en los datos.

# Dataset Kaggle Problema Target Modelo sklearn sugerido
1 uciml/pima-indians-diabetes-database Clasificación binaria Outcome LogisticRegression + RandomForestClassifier
2 yasserh/titanic-dataset Clasificación binaria Survived HistGradientBoostingClassifier
3 uciml/red-wine-quality-cortez-et-al-2009 Clasificación multiclase quality RandomForestClassifier con class_weight="balanced"
4 camnugent/california-housing-prices Regresión median_house_value HistGradientBoostingRegressor
5 blastchar/telco-customer-churn Clasificación binaria Churn LogisticRegression en pipeline + XGBClassifier

Parte 1 — Ciclo completo por dataset

Para cada uno de los 5 datasets, el alumno ejecuta el mismo flujo orquestado por el Power. La idea es repetirlo 5 veces para tener señal estadística sobre qué tan bien funciona el Power en escenarios distintos.

Flujo estándar por dataset

Partiendo de un prompt inicial en el chat de Kiro del estilo:

"Usando el Data Science Assistant, crea un proyecto ML supervisado desde el dataset uciml/pima-indians-diabetes-database de Kaggle. El problema es clasificación binaria con target Outcome. El modelo a entrenar es LogisticRegression como baseline y RandomForestClassifier para comparar."

El alumno debe verificar que el Power:

  1. Preguntó explícitamente por la fuente de datos antes de empezar (regla obligatoria del Power).
  2. Inicializó el proyecto con uv init y agregó dependencias con uv add (jamás pip).
  3. Generó config.yaml con los parámetros correctos (kaggle_ref, features, target, modelo, licencia Apache-2.0).
  4. Creó la estructura modular (scripts/01_ingest.py ... scripts/08_deploy_hf.py, data/raw, data/processed, models/, outputs/, cards/, app_training/, app_inference/, lib/).
  5. Ejecutó cada etapa como script independiente con uv run python scripts/XX_*.py.
  6. Respetó los puntos de intervención humana entre etapas (no se saltó EDA, no entrenó antes de feature engineering).

Checklist mínimo de entregables por dataset

Por cada dataset, el alumno entrega en una carpeta propia:

  • config.yaml completo y coherente con el problema.
  • outputs/figures/ con mínimo 4 gráficas de EDA (distribución del target, correlación, nulos, outliers).
  • models/model.joblib serializado.
  • outputs/metrics/metrics.json con métricas apropiadas al tipo de problema:
    • Clasificación binaria → accuracy, precision, recall, F1, ROC-AUC, matriz de confusión.
    • Clasificación multiclase → accuracy, F1 macro, matriz de confusión.
    • Regresión → MAE, RMSE, R², gráfica predicho vs real.
  • cards/DATA_CARD.md y cards/MODEL_CARD.md completos.
  • Dataset curado publicado a Kaggle bajo licencia Apache 2.0.
  • Modelo publicado a Kaggle bajo licencia Apache 2.0.
  • app_inference/ desplegable a HF Spaces (aunque el despliegue real solo sea obligatorio para 2 de los 5 datasets — ver Parte 2).

Ejercicios 1.1 a 1.5

Ejercicio Dataset Énfasis especial que debe cubrir el Power
1.1 Pima Diabetes Detectar que los ceros en Glucose, BloodPressure, SkinThickness, Insulin, BMI son en realidad nulos y aplicar imputación. Reportar ROC-AUC y usar estratificación en el split.
1.2 Titanic Manejar nulos heterogéneos (Age numérico, Cabin categórico con >70% nulos). Usar ColumnTransformer en pipeline. Feature engineering de Title desde Name y FamilySize desde SibSp+Parch.
1.3 Wine Quality Manejar clases desbalanceadas (calidades 3 y 8 muy raras). Usar class_weight="balanced" o SMOTE. Reportar F1 macro, no accuracy.
1.4 California Housing Feature engineering geográfico (clusters de latitude/longitude, distancia a ciudades). Imputación de total_bedrooms. One-hot de ocean_proximity. Transformación logarítmica del target si ayuda.
1.5 Telco Churn Limpiar TotalCharges (espacios en blanco que rompen float). Pipeline con ColumnTransformer (muchas categóricas). Evaluar costo de falsos negativos (cliente que se va y no lo detectamos).

Parte 2 — Despliegue real a HF Spaces

De los 5 datasets, el alumno elige 2 y los lleva hasta producción siguiendo el workflow mlops-deployment del Power.

Requisitos:

  • El app_inference/ debe descargar el modelo desde Kaggle en caliente al iniciar el Space (el modelo en Kaggle es la fuente de verdad).
  • Secretos en HF Spaces: KAGGLE_USERNAME y KAGGLE_KEY (no el token KGAT).
  • sdk_version en el README.md del Space debe coincidir con la versión real de Gradio instalada (uv run python -c "import gradio; print(gradio.__version__)").
  • El Space debe quedar público y funcionando.

Entregable: 2 URLs de HF Spaces funcionando, con capturas de prueba.

Parte 3 — Validación del Kiro Power

Esta es la parte crítica del trabajo. El alumno no solo usa el Power, lo audita. Las futuras generaciones dependen de esta retroalimentación.

Cada alumno entrega un reporte validacion_power.md con las siguientes secciones.

3.1 Validación de principios fundamentales

Marcar con ✅ / ⚠️ / ❌ y justificar con evidencia:

  • ¿El Power preguntó explícitamente por la fuente de datos en cada uno de los 5 proyectos?
  • ¿Usó siempre uv y nunca pip install directo?
  • ¿Generó config.yaml centralizado y lo respetó (sin parámetros hardcodeados)?
  • ¿Mantuvo la arquitectura modular por etapas (8 scripts separados)?
  • ¿Generó siempre DATA_CARD y MODEL_CARD antes de publicar?
  • ¿Usó el nombre correcto de licencia según el contexto ("Apache 2.0" con espacio en JSON de Kaggle, apache-2.0 en YAML de HF, Apache-2.0 en config.yaml)?

3.2 Validación de los 4 MCP Servers

Para cada MCP del Power, reportar:

  • Tavily — ¿Las búsquedas de documentación fueron relevantes? ¿El parámetro library acotó correctamente? Casos donde falló.
  • Kaggle — ¿Qué operaciones funcionaron vía MCP y cuáles requirieron el CLI? Confirmar o desmentir la tabla de limitaciones del POWER.md.
  • Hugging Face — ¿Las búsquedas del Hub fueron útiles? ¿El despliegue de Spaces funcionó solo con el MCP o requirió CLI/git manual?
  • Gradio Docs — ¿Los schemas devueltos eran actuales y coincidían con la versión instalada?

3.3 Validación de steering files

Para cada uno de los 5 steering files, indicar en cuáles de los 5 datasets se activó y si aportó valor real:

Steering Dataset 1 Dataset 2 Dataset 3 Dataset 4 Dataset 5 Comentario
eda-feature-engineering
model-training-validation
kaggle-workflows
gradio-interfaces
mlops-deployment

3.4 Bugs y limitaciones encontradas

Listar problemas concretos con:

  • Descripción del bug o limitación.
  • Paso del workflow donde ocurrió.
  • Dataset(s) donde se presentó.
  • Si lo resolviste: cómo. Si no: workaround aplicado.
  • Propuesta de mejora concreta para el POWER.md o un steering file.

3.5 Propuestas para futuras generaciones

Sección libre donde el alumno responde:

  • ¿Qué agregarías al Power? (tools, steering, docs, ejemplos)
  • ¿Qué quitarías o simplificarías?
  • ¿Qué prompts iniciales funcionaron mejor para arrancar un proyecto?
  • ¿Qué dataset recomendarías como "hola mundo" del Power y por qué?
  • ¿Qué habilidades de Kiro (hooks, specs, steering propio) complementan bien al Power?

Parte 4 — Contribución opcional (puntos extra)

El alumno puede abrir un Pull Request al repositorio del Power (https://github.com/gusdelact/kiropowerdatascienceassistant.git) con:

  • Correcciones de bugs detectados en la Parte 3.4.
  • Nuevos steering files para casos no cubiertos (por ejemplo: series temporales, NLP, clustering).
  • Mejoras de documentación con ejemplos reales extraídos de los 5 proyectos.
  • Un nuevo dataset de referencia agregado al POWER.md.

Convenciones del curso

  • Usar siempre uv (uv init, uv add, uv run). Jamás pip install directo ni python -m venv.
  • Licencia Apache 2.0 para todo dataset/modelo publicado, respetando la variante de sintaxis por sistema.
  • Nunca subir credenciales reales al repo: usar placeholders (YOUR_KAGGLE_TOKEN, YOUR_HF_TOKEN, YOUR_TAVILY_API_KEY).
  • Cada proyecto en una carpeta propia con su README.md, siguiendo la estructura del POWER.md.
  • El reporte de validación (validacion_power.md) se entrega en un repo público del alumno para que futuras generaciones lo consulten.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment