/ Proyectos / Negocio / Predicción de venta de boletos
Predicción de venta de boletos por punto de venta: por qué el contexto le gana a la sugerencia automática de un LLM
Estimar cuántos boletos liberar a cada punto de venta externo antes de un evento, y por qué la decisión de codificación más importante del proyecto no la tomó un modelo de lenguaje sin contexto.
El objetivo era estimar cuántos boletos se venderían por punto de venta externo antes de cada evento, para liberar la cantidad correcta de códigos a cada uno. Si un punto de venta no recibe código, simplemente no puede vender ese boleto, así que quedarse corto significa ventas perdidas y pasarse significa códigos sin usar en un punto mientras otro se queda sin inventario.
El reto de fondo no fue solo de modelado. Fue de criterio: entender el problema y los datos lo suficiente para decidir bien cómo representar cada variable, en vez de aceptar la primera sugerencia razonable que cualquier herramienta, incluido un modelo de lenguaje, pudiera ofrecer sin conocer el contexto completo.
Mapa del casoContenido
- Diagrama de la solución. Los bloques del pipeline, de la venta histórica a la predicción por punto de venta
- Construcción de la solución. Por qué la codificación de una sola variable pesó más que elegir el modelo
- Condiciones del proyecto. Restricciones reales y opciones descartadas antes de construir
- Pasos. Qué sugirió un modelo de lenguaje sin contexto y qué criterio se aplicó en su lugar
- Proceso de iteración. Qué tan lejos llega el sistema con un dataset pequeño
- Descargables. Notebook, diagrama y repositorio del proyecto
- Lecciones importantes. La lección concreta que deja este caso
Estructura de alto nivelDiagrama de la solución
Pasa el cursor sobre cada bloque para ver qué hace ese paso.
El paso de codificación del evento no es un detalle de preprocesamiento menor, es el que más señal aporta al resto del pipeline, y por eso aparece como una rama propia en el diagrama, separada del resto de la ingeniería de calendario.
Cómo se construyóConstrucción de la solución
Condiciones del proyecto
| Restricción | Dato |
|---|---|
| Objetivo operativo | Decidir cuántos códigos de boleto liberar a cada punto de venta externo antes del evento, no solo estimar un total agregado |
| Tamaño del dataset agregado | Pequeño, del orden de decenas de filas tras agrupar por evento y zona de venta |
| Variable de evento | Alta cardinalidad relativa al tamaño del dataset, sin una escala de popularidad explícita en los datos crudos |
| Naturaleza del calendario | Día de la semana y mes son variables cíclicas, no simplemente ordinales lineales |
| Opción | Por qué se descartó |
|---|---|
| Modelar como serie de tiempo (ARIMA/SARIMA) sobre la venta agregada | No hay continuidad temporal densa por punto de venta, y no permite predecir eventos hipotéticos futuros con características propias |
| One-hot encoding para la variable de evento | Con un dataset de decenas de filas, expandir una categórica de alta cardinalidad en columnas binarias genera más columnas que registros, y no captura que unos eventos venden sistemáticamente más que otros |
| Día y mes como enteros simples | No refleja que diciembre y enero son consecutivos en el calendario, ni la naturaleza cíclica del fin de semana |
| Codificación ordinal del evento según su volumen histórico de ventas + codificación cíclica seno-coseno para día y mes | Comprime la señal de popularidad del evento en una sola variable numérica y preserva la naturaleza cíclica del calendario, ambas cosas con muy pocos datos disponibles |
Pasos
Definir la pregunta correcta antes que el modelo
Agente: al pedir ayuda con un problema que tenía fechas, un modelo de lenguaje sugirió tratarlo como forecasting de series de tiempo por defecto.
Criterio aplicado: replantear el problema como un dataset tabular, una fila por evento y zona, porque el objetivo real era predecir la venta de un evento futuro hipotético con sus propias características, no continuar una serie histórica.
Codificación del evento: la decisión que más importó
Agente: con el contexto mínimo, una columna categórica con nombres de eventos, un modelo de lenguaje sugirió one-hot encoding, la recomendación por defecto para categóricas sin orden aparente.
Criterio aplicado: usar codificación ordinal según el volumen histórico de ventas de cada evento, porque algunos eventos son sistemáticamente más populares que otros y esa relación de orden se pierde con one-hot, además de multiplicar columnas en un dataset ya pequeño. Esta decisión solo fue posible porque quien dirigía el proyecto entendía la dinámica de asistencia a los eventos, no porque el modelo de lenguaje lo dedujera solo con una columna de nombres.
Codificación cíclica para día y mes
Agente: propuso codificar día y mes como enteros consecutivos.
Criterio aplicado: aplicar transformación seno-coseno, para que el modelo entienda que diciembre y enero están tan cerca entre sí como cualquier otro par de meses consecutivos.
Comparar familias de modelos muy distintas, no solo ajustar una
Agente: sugería quedarse con el primer modelo razonable, una LSTM, justificado por la presencia de fechas en los datos.
Criterio aplicado: comparar árboles de decisión, varios ensambles, una LSTM y modelos clásicos de series de tiempo, para confirmar con evidencia qué familia se ajustaba mejor a un problema tabular pequeño y sin estructura temporal densa.
Proceso de iteración
Ajuste documentado, no forzado
Los modelos de ensamble basados en árboles (Gradient Boosting y variantes similares) tuvieron consistentemente mejor error porcentual que la LSTM y que los modelos clásicos de series de tiempo, lo que confirma que replantear el problema como tabular fue la decisión correcta. Al mismo tiempo, hay que ser honestos con el tamaño del dataset: con solo decenas de filas tras la agregación, el riesgo de sobreajuste es real incluso cuando las métricas de prueba se ven bien, y el sistema no debería usarse para extrapolar a un tipo de evento completamente distinto a los ya observados.
CierreLecciones importantes
Un modelo de lenguaje es tan bueno como el contexto que recibe. Pedirle ayuda con una columna categórica sin explicar que algunas categorías son sistemáticamente más relevantes que otras es una pregunta incompleta, y una pregunta incompleta casi siempre recibe la respuesta genérica, no la correcta para tu problema. La codificación ordinal por popularidad, en vez de one-hot, no salió de una sugerencia automática, salió de entender el negocio detrás de los datos.
Esa es la razón por la que quien dirige el proyecto tiene que seguir siendo dueño de las decisiones de diseño, incluso cuando delega buena parte del código a un modelo de lenguaje. La herramienta puede escribir rápido, pero no puede saber lo que tú no le dijiste.
Si quieres ver un enfoque publicado con una idea similar, comparación de métodos de machine learning para predecir demanda de eventos deportivos, este paper es una buena referencia del nivel de la contribución: Prediction of sports attendance: A comparative analysis.
Termina ya tu proyecto
¿Tienes un proyecto similar y no sabes por dónde empezar? Yo te ayudo a diseñarlo.
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro. Acceso inmediato