El día que el béisbol destruyó mi modelo de Machine Learning (y cómo limpiar el ruido real)

Si ustedes han intentado entrenar un modelo predictivo con datos de búsqueda reales, ya conocen el dolor. El cliente llega con una idea brillante: "Queremos anticipar la demanda de servicios de ML en el mercado hispanohablante". Suena fácil. Configuras un scraper, te conectas a las APIs de tendencias, descargas el histórico de búsquedas y preparas el algoritmo. Todo marcha bien en tu entorno local. Presentas el plan, el cliente sonríe y te da luz verde.

Luego, el sistema explota en producción.

Me pasó en octubre de 2022. Estaba en mi oficina con dos tazas de café encima, revisando las métricas de un modelo de forecasting que habíamos diseñado para una consultora tecnológica en Bogotá. De repente, la gráfica mostró un pico absurdo de anomalía. Un incremento del 340% en el interés por "ML" en apenas cuatro días. ¿La revolución de la inteligencia artificial había llegado de golpe? ¿Un nuevo framework open-source? No. Era la Serie Mundial de la mlb.

El algoritmo, en su infinita y matemática inocencia, había agrupado todo bajo la misma etiqueta. Para mi código, un ingeniero buscando infraestructura en la nube y un fanático buscando mlb hoy para ver el partido de los Yankees eran exactamente la misma persona.

La pesadilla de la colisión de acrónimos

Ese día aprendí que el término "ML" es la peor trampa de datos del mundo. Es un agujero negro de ruido semántico. Si ustedes lanzan una consulta limpia para rastrear tendencias tecnológicas, lo que reciben de vuelta no es innovación. Es una sopa de letras caótica donde conviven el deporte, la repostería y la burocracia académica.

Déjenme darles un baño de realidad con los datos que tuvimos que limpiar esa semana. Primero, el deporte estadounidense domina la atención del continente. Millones de personas entran a diario a revisar la tabla de mlb posiciones o a buscar estadísticas de los mlb lideres de bateo de la temporada. Si hay un juego importante, tu modelo de Machine Learning registrará un supuesto "interés tecnológico" masivo que en realidad es solo gente queriendo ver un home run. Y ni hablar de la fiebre de compras en mlb shop durante el Black Friday. Eso arruina cualquier curva de estacionalidad.

Pero el problema no termina en el diamante de béisbol. Cruzas la calle y te encuentras con la mls, la liga de fútbol norteamericana, que confunde a los parseadores de texto más débiles. Luego te vas al sector financiero europeo y salta el término mlp banking, arrastrando búsquedas de servicios bancarios alemanes hacia tu base de datos de tecnología latinoamericana.

¿Quieren más? El usuario común no piensa en vectores de soporte ni en redes neuronales. La persona promedio que escribe "ml" en su computadora por la tarde está cocinando y necesita saber cómo pasar de ml a gramos para no arruinar un pastel de chocolate. O es un estudiante universitario desesperado redactando su tesis bajo las estrictas normas de formato mla. Incluso nos topamos con picos de tráfico causados por el universo de My Little Pony, abreviado en internet como mlp.

Si meten esa basura en su modelo de regresión, el resultado será pura fantasía.

Cómo sobrevivir al ruido sin perder la cabeza

La solución no es comprar una API más cara. Tampoco es meterle más capas densas a tu red neuronal. El problema no es el modelo; es la calidad del agua con la que llenas la piscina.

Lo primero que tuvimos que implementar fue una capa de filtrado semántico negativo estricto. Si la consulta de origen contiene términos como "conversión", "receta", "liga", "partido", "béisbol" o "formato", se desecha antes de que toque el pipeline de preparación. Parece obvio, pero cuando estás apurado por entregar un MVP, estos detalles se te escapan.

Lo segundo es la validación de contexto por co-ocurrencia. Una búsqueda de "ML" solo es relevante para nuestro análisis si en la misma sesión o en el mismo bloque de texto aparecen palabras clave secundarias como "Python", "dataset", "algoritmo" o "cloud". Si aparece sola, asumimos que es ruido. Es mejor perder un 5% de datos válidos que contaminar tu base con un 40% de datos basura de fanáticos deportivos.

Nos costó tres semanas de trabajo extra y varias discusiones tensas con el cliente limpiar ese desastre. Al final, logramos estabilizar las predicciones y el cliente pudo tomar decisiones estratégicas reales, no basadas en quién ganó el partido de anoche.

Hagan las cosas bien desde el principio

Construir herramientas de datos es un trabajo sucio. La mayoría de la gente cree que nos la pasamos diseñando arquitecturas complejas de inteligencia artificial, pero la realidad es que pasamos el 80% del tiempo limpiando archivos CSV y maldiciendo la falta de estandarización de los datos en la web. Es un proceso tedioso que requiere paciencia, experiencia y, sobre todo, haber cometido muchos errores en el pasado.

Si ustedes están cansados de pelear con datos sucios, reportes incomprensibles y modelos de pronóstico que confunden el fútbol con la tecnología, podemos ayudarles. En GuardLabs nos dedicamos a resolver este tipo de dolores de cabeza para dueños de negocios que necesitan respuestas claras, no tecnicismos. Desarrollamos un Инструмент анализа данных с ML-прогнозом que les permite subir sus conjuntos de datos, procesarlos con algoritmos de predicción reales y obtener reportes limpios, visuales y libres de ruido que cualquier persona en su equipo puede entender sin necesidad de un doctorado en matemáticas.