45 vulnerabilities (15 moderate, 15 high, 15 critical)
To address all issues (including breaking changes), run:
  npm audit fix --force

Al ver palabras como Critical, Remote Code Execution (RCE) y Prototype Pollution, el instinto natural es escribir npm audit fix --force para eliminar las advertencias.

Sin embargo, en el mundo de los Generadores de Sitios Estáticos (SSG) como Docusaurus o Next.js alojados en GitHub Pages o AWS S3, hacer esto a ciegas es un error común que rompe la compilación de producción sin mejorar la seguridad real.

En este artículo, definimos el modelo de amenazas en sitios estáticos, explicamos por qué las vulnerabilidades en herramientas de construcción difieren radicalmente de las vulnerabilidades en tiempo de ejecución, y compartimos un plan práctico de seguridad en 4 capas.

1. Resumen Ejecutivo: El Criterio de Ingeniería​

1. Herramientas de Compilación != Tiempo de Ejecución en Producción: Paquetes señalados en npm audit (como tinypool o serialize-javascript) son dependencias que solo se ejecutan localmente al compilar con npm run build.
2. Cero Servidores Activos en la CDN: Tras la compilación, GitHub Pages solo aloja archivos estáticos (HTML, CSS, JS). No hay ningún proceso Node.js en ejecución, ni puertos abiertos, ni conexiones a bases de datos.
3. El Peligro de --force: Forzar la resolución degrada frameworks como @docusaurus/core a versiones antiguas (3.7.0), rompiendo la compatibilidad con React 19 y plugins modernos.
4. Las Amenazas Reales: Los verdaderos riesgos en blogs estáticos son la fuga de claves API en Git, la exposición de datos personales (PII) y la fuga de privacidad en el cliente.

2. La Realidad tras las 45 Vulnerabilidades​

A. Tinypool y la Polución de Prototipos (GHSA-5gmw-xhrv-c9v3 - Critical)​

• tinypool se utiliza internamente para paralelizar tareas de compilación entre los núcleos de tu CPU local. Las entradas provienen únicamente de tu archivo docusaurus.config.ts. Ningún visitante externo puede enviar cargas útiles HTTP a tu entorno local.

B. Serialize-JavaScript y RCE (GHSA-5c6j-r48x-rmvq - High)​

• Webpack utiliza este paquete para generar fragmentos de código estáticos. En el directorio build/, los archivos son activos pasivos distribuidos por HTTPS; no existe deserialización en servidor.

C. PostCSS Selector Parser (GHSA-rj75-hqrm-r3gf - Moderate)​

• El CSS analizado corresponde a las hojas de estilo del propio autor (custom.css). Salvo que alguien comprometa los permisos de tu repositorio Git, no se procesa CSS externo malicioso.

Degradar librerías con --force en este contexto equivale a introducir fallos reales en tu aplicación para solucionar exploits que físicamente no pueden ocurrir en tu arquitectura.

3. Seguridad Práctica en 4 Capas para Sitios Estáticos​

Capa 1: Escaneo Automatizado de Secretos Previo al Commit​

El mayor peligro es subir por error una clave de OpenAI (sk-...), un token de GitHub (ghp_...) o credenciales de AWS (AKIA...). Implementamos un script de auditoría (tools/audit_security.py) que analiza los archivos con expresiones regulares de alta entropía antes de cada despliegue.

Capa 2: Protección de Datos Personales (PII)​

En proyectos de IA y visión por computador, utilizamos datos sintéticos (synth_gen) generados con modelos de lenguaje para garantizar el cumplimiento ético y la privacidad médica y personal.

Capa 3: Configuración Blindada de .gitignore​

Ampliamos .gitignore para bloquear exhaustivamente archivos .env, certificados privados (*.pem, *.key) y volcados de métricas (*.csv).

Capa 4: Privacidad en Cliente y Sandboxing​

• Política de Referrer Estricta: Configuramos strict-origin-when-cross-origin para evitar que la ruta completa de navegación se transmita a dominios externos.
• Iframe de Giscus Aislado: Comentarios configurados con emitMetadata="0" y loading="lazy" para prevenir la fuga de metadatos entre orígenes.

4. Conclusiones para Desarrolladores​

• No entres en pánico con npm audit: Distingue siempre entre dependencias de compilación y dependencias en tiempo de ejecución.
• Evita el uso ciego de --force: Las degradaciones automáticas suelen introducir errores reales mientras mitigan riesgos teóricos inexistentes en una CDN.
• Protege lo que de verdad importa: Automatiza el escaneo de secretos, protege la privacidad de tus datos y asegura tu historial en Git.

📌 Key Takeaways (Puntos Clave)

• Problema: El OCR de fotograma único genera lecturas erróneas transitorias debido a reflejos y vibraciones.
• Solución: Validación de sintaxis regex (^\d{2,3}[가-힣]\d{4}$) combinada con un motor de votación por mayoría temporal en una ventana deslizante de 7 fotogramas.
• Resultado: Evolución a través de 11 iteraciones técnicas (v01 a v11) desde ruido inicial (ACCIIXOY...) hasta la confirmación determinista de 64가1511.

1. Sintaxis de Matrículas Coreanas y EasyOCR​

import easyocr
import re
from collections import deque, Counter

reader = easyocr.Reader(['ko', 'en'], gpu=True)

def parse_korean_plate(plate_img):
    results = reader.readtext(plate_img, detail=0)
    raw_text = "".join(results).replace(" ", "")
    pattern = r'(\d{2,3}[가-힣]\d{4})'
    match = re.search(pattern, raw_text)
    return match.group(1) if match else None

2. Motor de Votación por Mayoría Temporal​

plate_history = deque(maxlen=CONFIG["plate_history_size"])
confirmed_plate = None

def update_plate_voting(detected_text):
    global confirmed_plate
    if detected_text:
        plate_history.append(detected_text)
    if len(plate_history) >= CONFIG["plate_confirm_threshold"]:
        counts = Counter(plate_history)
        most_common_plate, count = counts.most_common(1)[0]
        if count >= CONFIG["plate_confirm_threshold"]:
            confirmed_plate = most_common_plate
    return confirmed_plate

3. La Evolución de v01 a v11​

4. Conclusión​

Concluimos una serie de 5 artículos integrando detección de carril, IoU de invasión, detección jerárquica YOLO, seguimiento CSRT, superresolución EDSR y votación OCR.

📌 Key Takeaways (Puntos Clave)

• Problema: Las matrículas recortadas suelen medir menos de 40x20 píxeles; la interpolación bicúbica estándar desenfoca los trazos impidiendo el OCR.
• Solución: Red residual profunda EDSR_x4 (EDSR_x4.pb) combinada con apilamiento de 3 a 5 fotogramas consecutivos.
• Resultado: Densidad de píxeles cuadruplicada y precisión de EasyOCR mejorada del 32% a más del 91%.

1. Motor de Superresolución EDSR_x4​

import cv2
from cv2 import dnn_superres

sr = dnn_superres.DnnSuperResImpl_create()
sr.readModel("EDSR_x4.pb")
sr.setModel("edsr", 4)
enhanced_plate = sr.upsample(plate_roi)

2. Apilamiento de Imágenes Multifotograma​

Promediar parches alineados a lo largo del tiempo cancela el ruido del sensor y mejora la nitidez de los caracteres.

3. Próxima Entrega​

En la Entrega #5, concluiremos con la optimización de EasyOCR, el filtrado regex y el motor de votación temporal mayoritaria (evolución v01 a v11).

📌 Key Takeaways (Puntos Clave)

• Problema: Detectar matrículas diminutas (30x15 píxeles) en todo el fotograma de 640x480 provoca falsos positivos con carteles viales y reduce el rendimiento a menos de 10 FPS.
• Solución: Diseñamos una arquitectura en dos etapas (YOLOv3 para vehículos -> YOLOv5 solo en el ROI del vehículo) combinada con el rastreador CSRT cada 15 fotogramas.
• Resultado: Eliminación del 98% de falsos positivos y reducción del 80% en carga de GPU, manteniendo más de 50 FPS.

1. Detección Jerárquica en Dos Etapas​

vehicle_boxes = detect_vehicles_yolov3(frame, net=vehicle_net, conf_thresh=0.5)

for box in vehicle_boxes:
    x1, y1, x2, y2 = box
    vehicle_roi = frame[y1:y2, x1:x2]
    plate_boxes = plate_model(vehicle_roi)
    for pbox in plate_boxes:
        px1, py1, px2, py2 = pbox
        global_plate_box = [x1 + px1, y1 + py1, x1 + px2, y1 + py2]

2. Seguimiento en Tiempo Real con CSRT​

3. Próxima Entrega​

En la Entrega #4, abordaremos la superresolución profunda EDSR_x4 y el apilamiento multifotograma para recuperar contornos alfanuméricos nítidos.

📌 Key Takeaways (Puntos Clave)

• Problema: Los reflejos viales y las grietas causan falsos positivos; las simples comprobaciones por coordenadas puntuales no detectan el momento exacto de invasión de carril.
• Solución: Máscara ROI trapezoidal, filtrado por pendiente (|slope| > 0.5) y cola temporal de media móvil de 7 fotogramas. Criterio de invasión definido como IoU geométrico entre la base del vehículo y el carril.
• Resultado: Eliminación del 95% del ruido de textura vial y detección precisa de invasión con fiabilidad subfotograma.

1. Detección Dinámica de Carriles con Canny y Hough​

def detect_lanes(frame):
    height, width = frame.shape[:2]
    gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)
    blur = cv2.GaussianBlur(gray, (5, 5), 0)
    edges = cv2.Canny(blur, 50, 150)
    
    mask = np.zeros_like(edges)
    roi_polygon = np.array([[
        (int(width * 0.1), height),
        (int(width * 0.45), int(height * 0.6)),
        (int(width * 0.55), int(height * 0.6)),
        (int(width * 0.9), height)
    ]], np.int32)
    cv2.fillPoly(mask, roi_polygon, 255)
    masked_edges = cv2.bitwise_and(edges, mask)
    
    return cv2.HoughLinesP(masked_edges, 1, np.pi/180, 20, minLineLength=20, maxLineGap=10)

2. Filtrado de Pendientes y Suavizado Temporal​

Cálculo de pendiente m = (y2 - y1) / (x2 - x1):

• Carril Izquierdo: m < -0.5
• Carril Derecho: m > 0.5
• Ruido Horizontal: |m| <= 0.5 se descarta.

3. Criterio de Invasión Basado en IoU​

Footprint = [x_min, y_min + 0.7*h, x_max, y_max]
IoU = Area(Footprint ∩ Lane_Polygon) / Area(Footprint)

Si IoU > 0.05, se dispara el evento de infracción y se inicia la localización de matrícula con YOLOv5.

4. Próxima Entrega​

En la Entrega #3, analizaremos la detección jerárquica con YOLOv5 (lp_det.pt) y el seguimiento en tiempo real con CSRT.

📌 Key Takeaways (Puntos Clave)

• Problema: Las grabaciones de baja resolución de cámaras de tablero sufren vibraciones, contraluces y desenfoque de movimiento, lo que hace que el reconocimiento de matrículas y el monitoreo de invasión de carril fallen con frecuencia.
• Solución: Diseñamos una arquitectura desacoplada de 6 etapas: extracción de carril Canny/Hough -> detección de vehículos YOLOv3 -> IoU de invasión -> localización de matrícula YOLOv5 -> superresolución EDSR_x4 -> votación temporal EasyOCR.
• Resultado: Construimos un pipeline en Python de alto rendimiento que mantiene más de 30 FPS identificando con precisión matrículas infractoras bajo condiciones ópticas severas.

1. Contexto del Proyecto: Por qué la Visión en Dashcams es Difícil​

En sistemas de transporte inteligente (ITS), la detección en tiempo real de invasión de carril y el reconocimiento automático de matrículas (ANPR) son desafíos esenciales. Las grabaciones reales presentan barreras ópticas críticas:

1. Baja Resolución Extrema: La matrícula del vehículo objetivo a menudo ocupa apenas 30x15 a 50x25 píxeles dentro de un fotograma de 640x480.
2. Vibración de Calzada y Distorsión de Perspectiva: Las irregularidades del asfalto deforman las líneas viales rectas.
3. Cuellos de Botella de Cómputo: Aplicar modelos masivos en cada fotograma completo colapsa la tasa de FPS.

2. Arquitectura Jerárquica de 6 Etapas​

flowchart TD
    Raw["Fotograma Dashcam 640x480"] --> L1["Etapa 1: Extracción Dinámica de Carril Canny + Hough"]
    Raw --> L2["Etapa 2: Detección Rápida de Vehículos YOLOv3-tiny"]
    L1 & L2 --> L3["Etapa 3: Métrica IoU entre Base del Vehículo y Polígono de Carril"]
    L3 -- Si Ocurre Invasión --> L4["Etapa 4: Detección Localizada de Matrícula YOLOv5"]
    L4 --> L5["Etapa 5: Superresolución Profunda 4x con EDSR_x4"]
    L5 --> L6["Etapa 6: EasyOCR + Regex + Votación Temporal por Mayoría"]
    L6 --> Result["Matrícula Final Confirmada: 64가1511"]

3. Parámetros Principales del Sistema (CONFIG)​

CONFIG = {
    "output_width": 640,
    "output_height": 480,
    "conf_threshold_vehicle": 0.5,
    "nms_threshold_vehicle": 0.4,
    "min_vehicle_w": 70,
    "min_vehicle_h": 70,
    "lane_iou_threshold": 0.05,
    "detection_interval": 15,
    "min_plate_area_for_ocr": 1200,
    "plate_history_size": 7,
    "plate_confirm_threshold": 3,
    "sr_model": "EDSR_x4.pb",
    "yolo_plate_model": "lp_det.pt"
}

4. Próxima Entrega​

En la Entrega #2, exploraremos a fondo las matemáticas de la transformada probabilística de Hough, el filtrado de pendientes y el criterio geométrico de invasión basado en IoU.

Al entrar en junio, el equipo completó los desarrollos principales del primer semestre y se enfocó en construir redes de seguridad y preparar la presentación final.

El Modelo 2:1 y el Safety Wrapper​

"Decidimos la proporción 2:1. Ahora diseña un safety_wrapper como bloqueo de seguridad."

Seleccionamos el modelo mezclado con una proporción de 2:1 de chat 'emocional' a 'cotidiano'. Sin embargo, para prevenir cualquier alucinación en nuestro chatbot de prevención del suicidio, introdujimos un Safety Wrapper. Este módulo verifica las entradas y salidas, cambiando instantáneamente a un protocolo de crisis si se detecta alto riesgo.

Presupuesto de Servidor (EC2) y Presentación Final​

"¿Cuál es el presupuesto para 5 meses de AWS EC2 g5.2xlarge?"

Calculamos el presupuesto del servidor AWS EC2 para ejecutar el chatbot. El 18 de junio, reunimos todos los logros del backend, frontend e IA para completar la Presentación Final del 1er Semestre (PPTX).

¡El primer semestre ha concluido con éxito! Regresaremos con un servicio más avanzado en el segundo semestre.

En la última semana de mayo, nos dedicamos a concluir los resultados del tan esperado 4to Fine-Tuning (fine_tuning_4) y solidificar la estructura del sistema.

Checkpoint Final 4400 y Análisis​

"Qwen35-9B_mixed_7_3/checkpoints/checkpoint-4400/adapter_config.json"

El cuarto modelo, entrenado con una mezcla de chat casual y datos de consejería emocional, finalmente terminó el entrenamiento y produjo el peso óptimo: checkpoint-4400.

Al experimentar con la proporción de mezcla de datos, el modelo finalmente renació como un chatbot perceptivo que distingue perfectamente entre conversaciones diarias y consejería de crisis seria.

Arquitectura del Sistema e Informe Final​

"Generación de chatbot_architecture.html completa"

Para servir el modelo verificado como una aplicación real, diseñamos la arquitectura de todo el sistema y el plan de integración de Gráficos de Conocimiento (Knowledge Graph) bajo el nombre chatbot_architecture.html.

Y el 30 de mayo generamos automáticamente el informe_fine_tuning_4.docx. El informe contiene comparaciones de respuestas reales entre el modelo original y el nuestro, ¡demostrando que nuestro arduo trabajo no fue en vano!

Con esto concluyen los registros de desarrollo de mayo.

El 21 y 22 de mayo, el equipo de Maeumjigi se embarcó en la generación masiva de datos y la preparación para el Cuarto Fine-Tuning (fine_tuning_4).

Conversaciones Emocionales vs. Cotidianas​

Mientras probaba el modelo del tercer fine-tuning, descubrí un problema crítico.

"Las respuestas están demasiado inclinadas hacia la consejería emocional. ¿Cómo mantenemos las habilidades de conversación cotidiana del modelo?"

Nuestro modelo mostraba signos de sobreajuste, dando respuestas excesivamente serias a preguntas mundanas. Para resolver esto, planeamos mezclar datos emocionales y cotidianos.

Generando 10,000 Datos Emocionales (v6)​

Utilicé el modo Batch de la Interfaz de Programación de Aplicaciones (API) de Anthropic (Haiku) para generar 10,000 entradas de datos de conversaciones emocionales. Completé las entradas faltantes con un script adicional para asegurar la calidad.

Buscando la Proporción Dorada​

"Genera un dataset de 7:3, otro de 2:1 y otro de 5:5." "Este cuarto fine-tuning se basará en la proporción de mezcla (mixed_2_1, mixed_5_5, mixed_7_3)."

El 4to fine-tuning ahora verifica qué proporción armoniza la 'casualidad diaria' con la 'consejería profesional'. ¡Comenzamos a inyectar estos 3 datasets en el modelo Qwen3.5-9B!

📌 Puntos Clave (TL;DR)

• Problema: Severas restricciones computacionales en microcontroladores (Arduino Uno ATmega328P con solo 2KB de SRAM), deslizamiento de ruedas, ruido ultrasónico y la brecha de la realidad (Reality Gap) entre la física de Webots y el hardware real.
• Solución: Arquitectura de E/S distribuida (HC-06 Bluetooth a 115,200 baudios) donde una PC procesa la visión OpenCV y la inferencia de Q-Table mientras Arduino controla los motores mediante PWM. Corrección de distorsión de lente y homografía con marcadores ArUco (vision.py) para seguimiento de pose (x, y, θ) en tiempo real.
• Resultado: Transferencia directa (zero-shot) de la Q-Table de 648 estados que alcanzó un 86.7% de tasa de éxito (26/30 pruebas) en una arena física de 1.2m × 1.2m, superando la brecha de realidad sin reentrenamiento in situ.

1. El desafío Sim-to-Real: Superando la brecha de la realidad​

En el simulador Webots, la fricción superficial es uniforme, los motores de las ruedas responden exactamente a la velocidad indicada y los sensores de proximidad no tienen reflexiones parásitas. Sin embargo, el hardware físico presenta serios desafíos:

1. Limitaciones extremas de memoria y cómputo: El Arduino Uno (ATmega328P) dispone de solo 32KB de memoria flash y 2KB de SRAM, imposibilitando redes neuronales o cálculos matriciales complejos en el chip.
2. Ruido sensorial y ángulos ciegos: Los sensores ultrasónicos económicos sufren de rebotes especulares cuando inciden en ángulos oblicuos contra paredes de acrílico, arrojando valores de 0 o lecturas falsas al máximo alcance.
3. Deslizamiento de ruedas y deriva odométrica: Variaciones mínimas de fricción y caída de voltaje de la batería causan diferencias de RPM en los motores, desviando al robot incluso al recibir comandos de línea recta.

2. Arquitectura de control distribuido: PC anfitrión (Cerebro) ↔ Arduino (Músculo)​

Para solventar estas limitaciones, separamos la toma de decisiones del control de bajo nivel: "La PC es el cerebro, Arduino es el músculo."

flowchart TD
    subgraph CeilingCam["Sistema de visión cenital (Cámara superior)"]
        Cam["Cámara Web FHD (30 FPS)"]
        Aruco["Detección ArUco (DICT_4X4_50)<br>Homografía de perspectiva (homography.npy)"]
        Cam --> Aruco
    end

    subgraph PC["PC Anfitrión (Motor Python)"]
        Pose["Estimación de pose del robot (x, y, θ)"]
        Disc["Discretizador de 648 estados"]
        QL["Q-Table entrenada (ε=0)"]
        BT_Host["HC-06 Bluetooth SPP (115200 baudios)"]
        
        Aruco --> Pose --> Disc --> QL --> BT_Host
    end

    subgraph Robot["Robot móvil físico (Hardware real)"]
        BT_Slave["Receptor Bluetooth HC-06"]
        MCU["Arduino Uno (Firmware)"]
        Motors["Controlador L298N + Motores DC con reducción"]
        
        BT_Host <-->|"Action Byte [0..3]<br>Ack/Status"| BT_Slave --> MCU --> Motors
    end

• Canalización en la PC: La cámara cenital observa toda la arena, rastreando a 30 FPS el marcador ArUco ubicado sobre el robot. Se calcula la pose planar (x, y, θ) y se discretiza en 648 estados para extraer la acción codiciosa óptima de la Q-Table.
• Comunicación serial HC-06: Para minimizar la latencia de ida y vuelta (RTT) sobre el perfil SPP de Bluetooth, se aumentó la velocidad de transmisión de 9,600 a 115,200 baudios, logrando un ciclo de control de 30~50Hz.
• Firmware de Arduino (arduino_firmware.ino): Al recibir un byte de acción (0: Avanzar, 1: Retroceder, 2: Giro izquierda, 3: Giro derecha), el microcontrolador aplica señales PWM a los pines del puente H L298N por ticks calibrados.

3. Homografía de cámara cenital y rastreo visual ArUco​

Para medir con precisión milimétrica la posición del robot y la distancia a los obstáculos en la arena real, implementamos una canalización de visión por computadora con OpenCV.

📐 Calibración de perspectiva y homografía (calib_auto.py)​

1. Corrección de distorsión con tablero de ajedrez: Para eliminar la distorsión de barril de la lente gran angular, se calibraron la matriz intrínseca (K) y los coeficientes de distorsión (D) con un patrón de 9×6.
2. Transformación homográfica (Perspective Transform): Para proyectar la vista inclinada de la cámara en una vista superior plana canónica de 1.2m × 1.2m, se generó la matriz de transformación 3×3 (homography.npy) basada en las 4 esquinas de la arena.

💻 Implementación del rastreo ArUco (vision.py)​

import cv2
import numpy as np

# Inicializar diccionario ArUco y parámetros de detección
aruco_dict = cv2.aruco.getPredefinedDictionary(cv2.aruco.DICT_4X4_50)
parameters = cv2.aruco.DetectorParameters()
detector = cv2.aruco.ArucoDetector(aruco_dict, parameters)

def get_robot_pose(frame, homography_matrix):
    """Calcula las coordenadas (x, y) y el ángulo de orientación (theta) desde la imagen rectificada."""
    warped = cv2.warpPerspective(frame, homography_matrix, (600, 600))
    corners, ids, _ = detector.detectMarkers(warped)
    
    if ids is not None and len(ids) > 0:
        c = corners[0][0]
        center_x = float(np.mean(c[:, 0]))
        center_y = float(np.mean(c[:, 1]))
        
        # Calcular ángulo de rumbo (theta) a partir del vector frontal del marcador
        front_x = (c[0][0] + c[1][0]) / 2.0
        front_y = (c[0][1] + c[1][1]) / 2.0
        theta = np.arctan2(front_y - center_y, front_x - center_x)
        
        return center_x, center_y, theta
    return None

4. Resolución de problemas en hardware y resultados de despliegue​

Durante la transición de la simulación al hardware real surgieron desafíos imprevistos que se resolvieron mediante ingeniería:

🏆 Rendimiento final en hardware real​

• Tasa de llegada al objetivo: Tras 30 pruebas completas en la arena con obstáculos de 1.2m × 1.2m, el robot alcanzó un 86.7% de éxito (26/30 llegadas satisfactorias).
• Utilizando únicamente 2,592 parámetros de la Q-Table (~2.5 KB) entrenada en simulación, el robot sorteó los obstáculos físicos sin requerir entrenamiento adicional en el mundo real.

5. Conclusión de la serie RL Q-Learning​

Con este hito de transferencia a hardware real concluye la serie de 5 artículos sobre el proyecto RL Q-Learning:

1. #1: Discretización del espacio de estados (648 bins) y arquitectura IPC con sockets TCP
2. #2: Tabular Q-Learning con decaimiento ε y diseño de recompensas multidimensionales
3. #3: Superación de mínimos locales en arenas de 12 paredes y aceleración en modo Headless
4. #4: Evaluación cuantitativa determinista con evaluate_qlearning vs. SARSA y DQN
5. #5: Sim-to-Real: Despliegue en Arduino Uno, Bluetooth HC-06 y visión ArUco

Desde el modelado en simulación y la fundamentación algorítmica, hasta la automatización headless y la transferencia a sistemas embebidos reales, esta serie documentó todo el ciclo de vida del aprendizaje por refuerzo aplicado a la robótica. ¡Nos vemos en los próximos proyectos de desarrollo!

Durante el 19 y 20 de mayo, la evaluación del tercer fine-tuning (fine_tuning_3) y la mejora de las características de backend y frontend procedieron en paralelo.

Concluyendo el 3er Fine-Tuning​

El entrenamiento para el 3er fine-tuning, configurado con conceptos de gráficos de conocimiento en mente, se completó.

"Selecciona el checkpoint con el mejor eval, reemplaza los archivos en la carpeta adapter."

En lugar de copiar checkpoints manualmente, le indiqué a la IA que escribiera un script que extrajera automáticamente los mejores pesos del modelo y los configurara. Luego, ejecuté el script de inferencia paralela en el servidor.

Backend y Frontend: Base de Datos y Foro​

Mientras los modelos trabajaban en el servidor, aceleré el trabajo de integración de la aplicación y la BD.

Para resolver el frustrante error 401 Unauthorized de la última vez, examiné seed_data.sql para verificar las contraseñas. Como resultado, logré un importante commit en Git: feat: Añadido guardado de chatbot en BD, paginación de foro y filtro de diario de emociones

¡Finalmente, los registros de conversación de nuestro chatbot comenzaron a guardarse oficialmente en la base de datos! Además, se añadieron la paginación para el foro comunitario y el filtro del diario de emociones.

Fue un momento emocionante cuando el modelo finalmente comenzó a servirse en una aplicación móvil.

📌 Puntos Clave (TL;DR)

• Objetivo: Medir el desempeño puro y determinista de la política voraz aprendida (ε=0) sin ruido exploratorio, validando su viabilidad de despliegue.
• Metodología: Implementación de evaluate_qlearning.py con 30 pruebas independientes distribuidas en 5 semillas de evaluación, monitoreando tasa de éxito, eficiencia de ruta frente a la distancia mínima teórica y conteo de aproximaciones críticas (near-miss).
• Resultado: Q-Learning tabular alcanzó un 93.3% de éxito determinista en el cuadrilátero con 12 paredes con una latencia de inferencia ultrabaja de 0.02 ms, superando a modelos más pesados como DQN y SARSA.

1. Canalización de Evaluación Cuantitativa (evaluate_qlearning.py)​

Para medir la capacidad real de navegación del robot cargamos la tabla Q entrenada (qlearning_qtable.npy) y evaluamos con $\epsilon = 0$ a través de 5 semillas de prueba.

flowchart LR
    Model["Tabla Q Entrenada<br>(qlearning_qtable.npy)"] --> Agent["Agente Voraz<br>(ε = 0 Fijo)"]
    EvalSeeds["5 Semillas de Prueba<br>(EVAL_SEEDS 0..4)"] --> Webots["Simulador Webots<br>(30 Pruebas)"]
    Agent <--> Webots
    Webots --> CSV["Registro de Datos<br>(eval_log.csv / traces)"]

2. Comparativa de Algoritmos: Q-Learning vs. SARSA vs. DQN​

Evaluación en el mismo escenario de 12 paredes en Webots:

3. Próximos Pasos​

En el episodio final #5, presentaremos la transferencia a hardware real (Sim-to-Real): integración en un robot Arduino Uno de 2 ruedas, comunicación Bluetooth HC-06, calibración de distorsión con tablero de ajedrez y seguimiento visual con marcadores ArUco.

📌 Puntos Clave (TL;DR)

• Problema: Cuando el objetivo está detrás de un obstáculo, la búsqueda codiciosa de recompensas por delta de distancia (+0.1 × Δdist) empuja al robot a colisionar frontalmente, atrapándolo en un mínimo local (Local Minima).
• Solución: Integración de percepción ultrasónica en 3 direcciones con barrido (frontal/izq/der) y propagación de valor a largo plazo (γ=0.99), junto con una canalización automatizada en PowerShell (headless_run.ps1) para entrenar en modo Headless con 3 semillas (0, 1, 2).
• Resultado: El robot aprendió políticas de desvío efectivas en el cuadrilátero con 12 paredes, superando el 90% de tasa de éxito tras 600 episodios.

1. El Desafío de los Obstáculos: La Trampa de los Mínimos Locales​

En un cuadrilátero despejado (no_obstacle), navegar consiste simplemente en alinearse hacia el objetivo. Sin embargo, al incorporar 12 paredes interiores (obstacle12), surgió un cuello de botella crítico:

flowchart TD
    Start["Inicio (Robot)"]
    Wall["Pared Obstáculo"]
    Goal["Objetivo"]
    
    Start -->|"Avance directo (recompensa voraz)"| Wall
    Wall -.->|"Colisión y bloqueo (Mínimo Local)"| Wall
    Start ==>|"Política de desvío (Detour)<br>Acepta alejarse temporalmente"| Goal

• Dilema: Si la meta está al otro lado de una pared, avanzar en línea recta resulta en colisión inevitable.
• Conflicto de recompensas: Rodear la pared requiere alejarse momentáneamente del objetivo (delta de distancia negativo), provocando que un agente ingenuo quede atrapado rotando sin fin ante el obstáculo.

2. Estrategia de Solución: Percepción Head-Scan y Retropropagación de Valor​

Superar esta trampa requirió combinar la percepción ultrasónica tridireccional con un alto factor de descuento (γ = 0.99):

1. Ampliación de estados: Ante un obstáculo frontal (front_distance = Danger), el barrido del sensor revela corredores libres (left_distance = Safe o right_distance = Safe), induciendo giros laterales.
2. Asignación temporal de crédito: Aunque alejarse reduce la recompensa inmediata, bordear el obstáculo y llegar a la meta otorga la recompensa terminal (+1.0). El factor γ = 0.99 propaga este retorno hacia atrás, consolidando la política de desvío.

3. Automatización Headless en Webots​

Para agilizar el entrenamiento repetido con múltiples semillas (Seeds 0, 1, 2), implementamos headless_run.ps1, ejecutando Webots sin renderizado visual a máxima velocidad (--mode=fast --no-rendering).

4. Análisis Comparativo de Curvas de Aprendizaje​

• Tasa de éxito final: Del 98.5% en no_obstacle a un sólido 91.4% ~ 94.8% en obstacle12.
• Pasos promedio: Adaptación de trayectorias directas (1522 pasos) a rutas de desvío (3852 pasos).

5. Próximos Pasos​

En el episodio #4, evaluaremos los modelos guardados (models/*.npy) mediante evaluate_qlearning.py para medir el rendimiento determinista y comparar métricas frente a DQN y SARSA.

📌 Puntos Clave (TL;DR)

• Problema: Las recompensas dispersas (+1.0 en la meta, -1.0 en colisión) generan grandes retrasos de exploración, provocando que el robot deambule durante miles de episodios antes de encontrar el objetivo.
• Solución: Diseño de un esquema de Recompensas Densas (Reward Shaping) que combina recompensas proporcionales a la reducción de distancia euclidiana (+0.1 × Δdist) con penalizaciones por paso (-0.01), giro (-0.01) y retroceso (-0.05), junto con decaimiento exponencial de epsilon (1.0 → 0.05).
• Resultado: La recompensa promedio móvil alcanzó valores positivos estables (0.7+) antes de los 500 episodios en el escenario no_obstacle, superando el 98% de tasa de éxito.

1. Fórmula de Actualización de Q-Learning Tabular​

Q-Learning tabular es un algoritmo fuera de política (Off-policy) de Diferencia Temporal (TD(0)) basado en la ecuación de optimalidad de Bellman.

El agente mantiene una tabla Q(s, a) de dimensiones $648 \times 4$, actualizando los valores $Q$ en tiempo real:

📐 Regla de Actualización TD(0)​

Target = r + γ * max_a' Q(s', a') * (1 - done)
TD Error = Target - Q(s, a)
Q(s, a) <- Q(s, a) + α * TD Error

• Tasa de aprendizaje (α = 0.1): Regula la incorporación de nueva experiencia.
• Factor de descuento (γ = 0.99): Pondera el valor de las recompensas futuras a largo plazo.
• Máscara de estado terminal (1 - done): Anula el valor futuro al alcanzar el objetivo o colisionar.

2. Estrategia de Decaimiento de Epsilon-Greedy​

Iniciamos con ε = 1.0 (100% exploración aleatoria) y aplicamos decaimiento exponencial al final de cada episodio:

ε_(ep+1) = max(ε_min, ε_ep × 0.995)

• Episodio 1: ε = 1.0 (Exploración completa)
• Episodio 300: ε ≈ 0.22 (Transición a explotación de valores Q)
• Episodio 600: ε = 0.05 (Tasa mínima ε_min, 95% de acciones voraces/greedy)

3. Ajuste de Recompensas Densas​

4. Evaluación de Curvas de Aprendizaje​

Tras 1,500 episodios de entrenamiento en el entorno no_obstacle:

La tasa de éxito promedio móvil a 100 episodios superó el 98.5%, y los pasos promedio por episodio se redujeron de 150 (tiempo límite) a solo 15 ~ 22 pasos.

5. Próximos Pasos​

En el episodio #3, abordaremos los escenarios con 12 obstáculos de pared (obstacle12 y obstacle_hard), analizando cómo el agente supera los mínimos locales mediante simulaciones paralelas con múltiples semillas.

¡Debo corregir mi suposición de que el 13 de mayo fue el último día! El 17 de mayo hubo una ola masiva de pruebas de backend y redacción de informes.

Automatizando el Informe con IA​

No había tiempo suficiente para analizar manualmente los gráficos masivos del segundo fine-tuning.

"Crea un prompt para escribir un informe comparando los resultados. Guárdalo y escribe el informe."

Intenté utilizar ingeniería de prompts para que la IA interpretara las métricas. La IA analizó los pros y contras de cada modelo, generando un excelente borrador en Word (.docx).

Integración de Base de Datos y el Error 401​

Comencé a insertar datos de backup.sql en la BD local de PostgreSQL para probar la estabilidad.

"Contraseña incorrecta... POST /auth/login 401 Unauthorized"

Caí en un infierno de errores de inicio de sesión. Creé scripts de depuración y reinicié el servidor uvicorn sin fin.

Gráficos de Conocimiento (Knowledge Graphs)​

A altas horas de la noche, para superar las limitaciones del simple Modelo de Lenguaje Grande (LLM), comencé a diseñar un plan para explorar la fusión de ontologías y Gráficos de Conocimiento. ¡El proyecto se está volviendo masivo!

📌 Puntos Clave (TL;DR)

• Problema: Las lecturas continuas de sensores (distancia y orientación) provocan una explosión del espacio de estados para el Q-Learning tabular, y la sincronización con el simulador Webots requiere una comunicación de baja latencia.
• Solución: Diseño de un mapeador de sensores continuos en 5 dimensiones que produce 3 × 8 × 3 × 3 × 3 = 648 estados discretos (discretizer.py) y una canalización IPC mediante sockets TCP (puerto 5000, JSON delimitado por líneas).
• Resultado: Indexación ultrarrápida de la tabla Q en tiempo O(1) y sincronización física estable en pasos de 32 ms entre el simulador y el agente Python.

1. Contexto del Proyecto: ¿Por qué Webots y Q-Learning?​

Permitir que un robot móvil con tracción diferencial navegue en un entorno interior desconocido y alcance un objetivo evitando obstáculos es un desafío clásico de la robótica. Aunque el aprendizaje por refuerzo profundo (DQN, PPO) maneja entradas complejas, demanda grandes recursos de cómputo y carece de interpretabilidad directa.

En este proyecto, aplicamos Q-Learning Tabular clásico (Off-policy TD(0)) a un robot móvil en el motor de física 3D Webots, con el objetivo de obtener una política de navegación y evasión de obstáculos verificable matemáticamente en un cuadrilátero interior de 1.2m × 1.2m.

2. Arquitectura del Sistema (Webots ↔ Python IPC)​

El sistema está dividido en dos niveles: el servidor de simulación Webots y el cliente de aprendizaje por refuerzo en Python.

flowchart LR
    subgraph Webots["Simulador 3D Webots (localhost:5000)"]
        Robot["Robot Supervisor<br>(Sensor ultrasónico + ruedas)"]
        HeadScan["Mecanismo Head-Scan<br>(Servo rotación izq/der 1.1 rad)"]
        Server["Servidor Socket TCP<br>(JSON delimitado por líneas)"]
        Robot -→ HeadScan -→ Server
    end

    subgraph Python["Motor RL en Python (Cliente)"]
        Env["WebotsEnv (estilo gym)<br>reset() / step()"]
        Disc["Discretizador<br>(Valores continuos → Bins 0~647)"]
        Agent["QLearningAgent<br>(Tabla Q 648x4)"]
        Env -→ Disc -→ Agent
    end

    Server <-→|"petición: {type: step, action: 0..3}<br>respuesta: {state: [...], reward, done}"| Env

• Controlador Webots (RL_controller.py): Ejecuta acciones durante 480 ms (15 pasos de simulación × 32 ms) y gira el sensor ultrasónico montado en la cabeza hacia la izquierda y la derecha en 1.1 rad ($\approx 63°$) para eliminar puntos ciegos.
• Protocolo de Sockets: JSON delimitado por líneas sobre TCP localhost:5000 para minimizar la sobrecarga.

3. Discretización de Sensores Continuos en 648 Estados​

Para aplicar Q-Learning tabular, las variables continuas se asignan a 5 factores clave:

Número total de estados: N_estados = 3 × 8 × 3 × 3 × 3 = 648

La tabla Q resultante contiene solo 648 × 4 = 2,592 parámetros, permitiendo actualizaciones en submilisegundos en memoria sin requerir GPU.

4. Mecanismo Head-Scan y Criterios de Finalización​

1. Ejecución del paso: Motores a 3.0 rad/s durante 480 ms.
2. Rotación de la cabeza: Barrido a +1.1 rad para medir distancia izquierda, luego -1.1 rad para distancia derecha.
3. Centrado: Regreso a 0 rad para refrescar distancia frontal.
4. Condiciones de fin de episodio:
   • Objetivo alcanzado: Distancia euclidiana ≤ 0.10m → Éxito (done = True, recompensa $+1.0$).
   • Colisión con pared: Cualquier distancia ≤ 0.08m → Fallo (done = True, recompensa $-1.0$).

5. Próximos Pasos​

Con el entorno de Webots, la interfaz IPC por sockets TCP y la discretización en 648 estados listos, el robot puede comenzar su aprendizaje.

En el episodio #2, abordaremos la implementación matemática de Tabular Q-Learning, la política de exploración ε-greedy con decaimiento y el ajuste de la función de recompensa!

El 13 de mayo, después de corregir los errores, reanudamos las pruebas de inferencia para los modelos del 2do fine-tuning.

Aumentar la Longitud del Token​

Revisando los resultados de inferencia, sentí que las respuestas de Llama33-70B_a8 seguían siendo extrañamente cortas.

"Siento que max_seq_length y max_new_tokens son muy pequeños. Mirando la VRAM, ¿cuánto puedo aumentarlos?"

Calculando la VRAM disponible con la IA, aumentamos audazmente max_new_tokens a 384. ¡El resultado fue un gran éxito!

Al simplemente aumentar la asignación de tokens, el modelo comenzó a generar oraciones de empatía mucho más profundas y cálidas. El modelo había estado limitando sus palabras porque estaba atrapado en un recuento de tokens limitado.

Análisis Comparativo del Valor Alfa​

También se obtuvieron los resultados de la diferencia de rendimiento según el hiperparámetro de LoRA alpha. Generamos gráficos como 05_alpha_comparison_daily.png. Con rank=16 fijo, visualizamos claramente cómo diferían los patrones y la calidad final al dar alpha=8 frente a alpha=16.

Los modelos con los parámetros correctos y suficiente longitud de token se estaban acercando al verdadero 'Maeumjigi' que planeamos.

¡El entrenamiento paralelo del 2do fine-tuning (fine_tuning_2), que comenzó para corregir el error de los hiperparámetros, finalmente terminó el 12 de mayo!

El Mejor Checkpoint y el Pipeline de Inferencia​

El fine-tuning de 3 modelos con 6 combinaciones de hiperparámetros se completó. Comparé el eval_loss para extraer los mejores checkpoints y los moví a las carpetas adapter.

"Los modelos HCX-Text-1p5B generaron 12 salidas en 15 minutos. Uso de GPU es de 1.6GB..."

Sin embargo, la velocidad de inferencia era desesperante. Hubo un cuello de botella porque el tamaño del lote se estableció en 1. Además, los problemas de almacenamiento del servidor nos obligaron a migrar la ruta del proyecto.

Cayendo en la Trampa del Hardcoding​

Después de ejecutar laboriosamente todos los códigos de evaluación, descubrí un hecho horrible.

"¿Por qué MODEL_ALIAS está codificado de forma rígida a 'Qwen35-9B_a16'?"

Accidentalmente codifiqué de forma rígida MODEL_ALIAS. El script copiaba archivos diligentemente para probar el modelo HCX, pero dentro del código, ¡seguía cargando solo el modelo Qwen35-9B y repitiendo la misma inferencia una y otra vez! Mañana tendré que arreglar este error y volver a ejecutar las inferencias.

El 8 de mayo preparábamos la presentación de los resultados. Sin embargo, descubrí un error masivo.

Error Fatal en los Hiperparámetros de LoRA​

"Las respuestas del modelo son más cortas. Creo que es porque establecer r de LoRA a 8 y alfa a 16 redujo demasiado las características..." "Espera, ¿era a/r? Pensé que era r/a...???"

Comprendí mal la ecuación, configurándola de una manera que suprimió severamente o amplificó excesivamente las actualizaciones de peso. Con razón las respuestas eran anormalmente cortas.

2da Ronda de Fine-Tuning (fine_tuning_2)​

No podíamos simplemente avanzar. Inmediatamente creé una carpeta fine_tuning_2 para una segunda ronda de fine-tuning.

"Entrenar con rank=16, alpha=16, y en MIG-1 con rank=16, a=8." "Extraiga las 2000 entradas más largas de Daily_train_dataset."

Para evitar respuestas cortas, extrajimos solo los 2000 conjuntos de datos más largos y dividimos nuestros recursos de GPU para ejecutar entrenamiento en paralelo.

Desarrollo Frontend (App)​

Mientras los modelos entrenaban, comencé a desarrollar la aplicación frontend.

"Necesito mostrar un código QR para ejecutar maeum-app... pero cuando escribo npx go start, solo obtengo un error."

Creé el proyecto usando React Native (Expo) y, después de algunos errores tipográficos, logré mostrar el código QR de Expo. Fue un día emocionante construyendo tanto el cerebro (IA) como la cara de la aplicación.

El 7 de mayo sintetizamos los resultados de los 5 modelos que habíamos entrenado (Llama3.3-70B, DSR1-70B, HCX-Omni-8B, Qwen35-9B, HCX-Text-1.5B) y procedimos con la visualización a gran escala.

Configuración Local para la Comparación de Modelos​

Para revisar cómodamente los resultados en mi computadora portátil, creé un nuevo cuaderno: 31_comparison_local.ipynb.

"¿No puede 30_comparison.ipynb ejecutarse también en mi computadora?"

Al configurar el kernel local de Jupyter en VSCode e instalar las bibliotecas, enfrenté bloqueos del kernel y errores como ModuleNotFoundError. Sin embargo, los resolví paso a paso arreglando las rutas.

Informe Completo y Gráficos​

La tarea más importante fue visualizar el rendimiento de estos 5 modelos para compararlos de un vistazo. Junto con la IA, establecimos un plan y comenzamos a organizar los datos sistemáticamente.

"¿Cuál es la diferencia entre la línea tenue y la línea gruesa? Visualice el training loss y el eval loss."

Eliminé las líneas de tendencia innecesarias de los gráficos generados por la IA, extrayendo finalmente 03_training_loss_all.png y 04_eval_loss_all.png que reunieron perfectamente las curvas de pérdida de todos los modelos en un solo lugar.

Ahora, basándonos en estos gráficos, podemos decorar maravillosamente nuestros materiales de presentación de la próxima semana.