Ciencia de datos en tu producto: guía práctica

La mayoría de las empresas tiene muchos más datos de los que usa. Se acumulan en la base de datos, terminan en una gráfica en un dashboard que nadie abre y, fuera de eso, no hacen nada. La pregunta interesante no es “cómo analizamos nuestros datos” sino “cómo hacen nuestros datos que el producto mismo sea mejor para la persona que lo usa ahora”. Ese cambio, de reportar a construir funciones, es donde la ciencia de datos se gana su lugar, y también es donde los dueños de producto se pierden, porque “agreguen ciencia de datos” es una petición sin forma. Este artículo le da una: qué significa la frase en realidad, las decisiones que determinan costo y riesgo, cómo saber si funcionó, y los casos en que una regla que cabe en una servilleta le gana a cualquier modelo.

Qué significa “agregar ciencia de datos” para un dueño de producto

Quítale el vocabulario y toda función de datos es el mismo objeto: una decisión que el producto hoy toma con una regla fija, con un humano, o no toma en absoluto, y que quieres tomar mejor usando la historia. “Qué le mostramos a este usuario ahora”, “cuántas unidades pedimos”, “esta transacción es sospechosa”, “qué ticket de soporte va al frente de la fila”. Un dashboard te dice algo a ti; una función hace algo por el usuario. El mismo historial de compras que llena una gráfica de ingresos puede en cambio alimentar una fila de “quizá te guste” que sube las ventas. Los mismos registros de uso que muestran abandono pueden disparar un empujón oportuno que lo evita.

Plantearlo como una decisión hace tres cosas útiles. Nombra la métrica (qué significa “mejor”: más conversiones, menos quiebres de inventario, menos fraude). Nombra la entrada (qué sabemos en el momento en que se toma la decisión). Y expone la línea base, que es lo que el producto hace hoy. Un modelo que no le gana a la línea base no es una función, es un costo.

La prueba para cualquier función de datos: ¿cambia lo que el usuario ve o hace, en el momento, para bien, y puedes medirlo contra lo que pasaba antes?

Los patrones que mueven métricas

Casi toda función de datos en un producto tiene una de cinco formas, y saber cuál estás construyendo te dice casi todo lo que va a costar.

• Recomendación y ranking: qué artículos, productos o acciones mostrar, y en qué orden. La ganancia de ingresos clásica; también la más sensible a los bucles de retroalimentación, porque el modelo solo ve lo que eligió mostrar.
• Pronóstico: convertir la historia en un número sobre el futuro. La demanda del mes que viene, el tiempo de entrega, cuándo se acaba el inventario. Útil, y el más fácil de evaluar, porque el futuro llega y te califica.
• Clasificación y puntuación: esto es fraude, este prospecto merece una llamada, este usuario va a abandonar. Casi siempre se despliega como un umbral sobre una probabilidad, y el umbral es una decisión de negocio, no de ciencia de datos.
• Detección de anomalías: vigilar un flujo y marcar lo que no encaja. Un sensor que falla, una métrica que se desploma, un inicio de sesión desde ningún lugar. Muchas veces el mayor valor por línea de código, y el más ruidoso si se calibra mal.
• Segmentación: agrupar usuarios por comportamiento real en lugar de suposiciones, para que los mensajes y las funciones se adapten a cada grupo. La menos glamorosa y con frecuencia la más rápida de lanzar.

Fíjate en lo que no está en la lista: los modelos de lenguaje. La IA generativa es su propia categoría con su propia economía, y la cubrimos aparte en cómo agregar IA a tu app. Los patrones de arriba son más viejos, más baratos y, para datos de negocio estructurados, normalmente más precisos.

Cuándo una regla le gana a un modelo

Esta es la sección que los dueños de producto más necesitan y que los proveedores menos quieren escribir. Un modelo vale la pena cuando la relación entre las entradas y la respuesta correcta es real, estable y demasiado compleja para escribirla. Cuando es simple, una regla gana en todos los ejes: es explicable, se puede probar, cuesta cero ejecutarla y no se degrada. “Marca cualquier pedido que supere cinco veces el promedio del cliente” atrapa buena parte de lo que atraparía un modelo de fraude, se lanza en una tarde y un agente de soporte puede explicárselo a un cliente enojado. Varias señales honestas de que deberías empezar con una regla:

• Un experto del dominio puede describir la decisión en pocas oraciones. Codifica las oraciones primero; el modelo, si algún día llega, aprende las excepciones.
• Tienes menos de unos pocos miles de ejemplos etiquetados del resultado. Por debajo de eso, la mayoría de los modelos sobre todo memoriza.
• La decisión debe explicarse a un regulador, un auditor o un cliente. Una regla es su propia explicación.
• El costo de una respuesta equivocada es asimétrico y alto. Una regla falla de forma predecible; un modelo falla con creatividad.
• Los datos cambian de forma seguido. Una regla se edita; un modelo se reentrena, se revalida y se redespliega.

La ruta pragmática es una escalera: regla, luego un modelo simple que solo tiene que ganarle a la regla, luego uno más capaz que solo tiene que ganarle a ese. Cada peldaño se puede lanzar, y te detienes en el primero cuya ganancia ya no paga su mantenimiento. Los equipos que saltan a la cima de la escalera construyen modelos impresionantes sobre una base frágil y no pueden explicar por qué las predicciones salen mal.

Inferencia offline frente a online

La segunda decisión que define el costo es cuándo se calcula la predicción. Dos opciones, y la mayoría de los productos debería empezar con la primera.

La inferencia por lotes está subestimada porque parece menos impresionante, pero una columna de “probable abandono” recalculada cada noche y leída por una consulta común entrega casi todo el valor de un puntaje en tiempo real por una fracción pequeña de la carga operativa. Pasa a online solo cuando la decisión dependa de verdad de lo que ocurrió en los últimos segundos, y cuando lo hagas, define primero el plan B: qué muestra el producto si el modelo no responde dentro de su presupuesto de latencia. El plan B suele ser la regla de la sección anterior, una razón más para haberla construido.

Evaluación: cómo sabes que funcionó

Hay dos evaluaciones y los equipos las confunden de forma rutinaria. La evaluación offline pregunta si el modelo predice bien la historia que se le ocultó: exactitud, precisión y exhaustividad en clasificadores, magnitud del error en pronósticos, calidad del orden en recomendadores. Es necesaria, y ahí viven los errores clásicos: entrenar y probar con datos que se traslapan, o dejar que una característica filtre la respuesta (una columna de “días desde la cancelación” predice el abandono a la perfección y no sirve para nada). Divide por tiempo, no al azar, porque el producto siempre va a predecir el futuro a partir del pasado.

La evaluación online hace la única pregunta que le importa al negocio: ¿se movió la métrica? Un modelo puede puntuar de maravilla offline y no cambiar nada en producción, porque los usuarios no se comportan como un conjunto de prueba. La herramienta estándar es una prueba A/B de la nueva decisión contra la línea base, sostenida lo suficiente para cubrir un ciclo semanal completo, y medida con la métrica que nombraste al principio. Si no puedes correr un experimento, como mínimo lanza a una porción de usuarios y compara. Una función que no se puede medir no se puede defender en la próxima revisión de presupuesto, y no debería construirse.

# La evaluación que importa es contra la línea base, con división por tiempo
train = events[events.date <  "2026-06-01"]
test  = events[events.date >= "2026-06-01"]     # nunca mezclar; el futuro es la prueba

rule_precision  = precision(rule(test), test.label)     # la regla de la servilleta
model_precision = precision(model.predict(test), test.label)

# Lanzar solo si el modelo le gana a la regla por más de lo que cuesta operarlo y mantenerlo

Basura entra, basura sale, en serio

Un modelo es tan bueno como los datos que tiene detrás, y la mayoría de los datos reales son un desorden: campos faltantes, duplicados, formatos inconsistentes, eventos registrados mal o no registrados. Antes de cualquier modelado necesitas recolección confiable, almacenamiento sensato y limpieza, y eso es la mayor parte del trabajo. Si una decisión depende de una señal que hoy no registras, el primer entregable no es un modelo, es instrumentación más unos meses de espera. Dos hábitos se pagan solos: registra la decisión que tomó el producto y lo que pasó después, para que cada función genere sus propios datos de entrenamiento, y conserva los eventos crudos, no solo los agregados, porque la pregunta que querrás responder el año que viene es una que todavía no se te ha ocurrido. Es la misma disciplina que hace confiable una base de datos multiinquilino: primero la corrección aburrida.

Cuánto cuesta, con honestidad

La construcción es el número pequeño. Un primer modelo por lotes sobre datos limpios son unas semanas de trabajo; una regla son días. Los costos que duran están en otro lado: la instrumentación para obtener los datos, la tubería que los mantiene limpios, el monitoreo que nota cuando el modelo deja de acertar en silencio, y el reentrenamiento cuando eso pasa. Los modelos se degradan: el comportamiento de los usuarios cambia, una campaña de marketing cambia quién se registra, un proveedor cambia sus tiempos de entrega, y un modelo entrenado en el mundo viejo lo predice con toda confianza. Presupuesta a alguien que mire los números de exactitud cada mes y un reentrenamiento cada uno o dos trimestres, y para el servicio en tiempo real suma la partida de infraestructura. Si esos costos recurrentes superan la ganancia que midió el experimento, la regla era la respuesta correcta desde el principio, y descubrirlo barato es un éxito, no un fracaso.

Un marco de decisión que corres en una tarde

• ¿Qué decisión, y cuál es la línea base? Nombra la decisión del producto y cómo se toma hoy.
• ¿Qué métrica se mueve si mejora? Si no puedes nombrar una, detente aquí.
• ¿Un experto puede escribir la regla? Lanza eso primero; de todos modos es el plan B del modelo.
• ¿Tenemos los datos, etiquetados, en el momento de la decisión? Si no, instrumenta y espera.
• ¿Por lotes o en tiempo real? Por lotes, a menos que los últimos segundos cambien la respuesta.
• ¿Cómo lo probaremos contra la línea base? Offline con división por tiempo, después un experimento online.
• ¿Quién lo vigila el próximo trimestre? La degradación es segura; asigna al responsable antes del lanzamiento.

Por dónde empezar

Elige una decisión de tu producto que hoy sea una suposición, haz que los datos la informen, mantén simple la primera versión, conéctala a la experiencia real, mide si la métrica se movió e itera. Así es como los datos dejan de ser residuo y empiezan a ser una ventaja. Las funciones de datos son parte del trabajo de IA y datos que hacemos, y normalmente empiezan como un componente de una plataforma más grande. Si quieres ayuda para convertir los datos que ya tienes en funciones de producto, y una opinión honesta sobre si necesitas un modelo siquiera, hablemos, o mira lo que hemos construido.