Recientemente, en una acogedora sala de chat, la fecha de los satanistas planteó la cuestión de cómo "vender" adecuadamente los proyectos internos de aprendizaje automático. Resultó que muchos de nosotros somos muy aprensivos acerca de la viabilidad económica de nuestras actividades. Mientras tanto, para llevar a cabo una evaluación mínima de la rentabilidad del proyecto, no se necesita un MBA: en un breve artículo (10 páginas de texto, ke-ke-ke), le diré qué es el ROI, cómo evaluarlo para un proyecto interno, qué papel desempeña Prueba de concepto y por qué en la vida real todo puede salir mal. Haremos todo esto en torno a un proyecto ficticio para automatizar la programación de un centro de llamadas. ¡Bienvenido a cat!
Nuestro proyecto ficticio
El centro de llamadas tiene 100 operadores. Trabajan en un horario flotante, yendo a trabajar en turnos de 8 o 12 horas. Los turnos comienzan en diferentes momentos y se organizan de tal manera que se garantice la vigilancia de muchas personas en las horas pico y de un pequeño número de personas en horas frías durante la noche y los fines de semana. El supervisor de guardia del centro de atención telefónica planifica el horario los viernes por la noche, al planear la carga para la próxima semana.
Un día de 8 horas del operador del centro de llamadas le cuesta a la compañía 2,000 rublos. Si suponemos que hay 250 días hábiles en un año, el centro de llamadas le cuesta a la empresa 100 2.000 250 = 50 por año. Si automatizamos la programación, podemos predecir la carga por hora y organizar turnos para variar el número de operadores de servicio dependiendo de la carga prevista. Si nuestro pronóstico y disposición de turnos es al menos 10% mejor que el pronóstico y disposición del supervisor, ahorraremos hasta 5 millones de rublos. por año Si realmente logramos exprimir una mejora del 10%, el proyecto definitivamente dará sus frutos. ¿O no? .. Pensemos cómo tomar esas decisiones.
De acuerdo con el ROI
Antes de comenzar un gran proyecto, sería bueno evaluar su viabilidad económica. Una forma de libro de texto para hacer esto es calcular el retorno de la inversión, ROI.
El ROI (Retorno de la Inversión) es un indicador de rentabilidad del proyecto igual a la relación entre el ingreso y la inversión gastada. ROI <100% significa que el proyecto no dará sus frutos.
Los primeros gastos del proyecto suceden de inmediato, al comienzo, para la compra de hierro y licencias, el desarrollo del sistema y su implementación. Esto se llama gasto de capital. Durante la vida del proyecto, también tiene que asumir los costos: alquilar el mismo hardware y licencias, respaldar la operatividad del sistema y, a veces, el trabajo de los operadores. Esto se llama gastos operativos.
Los proyectos de ML, por regla general, no tienen "ingresos instantáneos". Los ingresos del proyecto solo funcionan, es decir a tiempo Por ejemplo, en el caso de nuestro centro de llamadas, los ingresos se forman como un ahorro de costos para los operadores. Si los costos operativos del proyecto exceden los ingresos, el proyecto nunca dará sus frutos.
Debido a los gastos de capital "instantáneos" al comienzo del proyecto, el retorno de la inversión dependerá del momento en que evaluamos la rentabilidad. Por lo general, se utiliza el año, el horizonte de planificación o la vida útil del sistema para calcular el ROI. Todo está claro con el año: esta es una manera fácil de entender si el proyecto dará sus frutos en un año o no. El horizonte de planificación es el intervalo de tiempo durante el cual se planifica la estrategia de la empresa y se elaboran los presupuestos. En empresas pequeñas y dinámicas, el horizonte rara vez excede un año, en grandes y estables puede ser de tres a diez años.
En el horizonte lejano de la planificación, puede recuperar cualquier basura, pero la vida en común está protegida por el tiempo de vida del sistema. Por lo general, después de unos años, el sistema deja de cumplir con los requisitos del negocio y se reemplaza por uno nuevo, se descarta o (con mayor frecuencia) se pudre con el soporte eterno. Con el rápido crecimiento de los negocios, el sistema no siempre puede vivir durante seis meses, en un mercado estable, el sistema se vuelve obsoleto en 3-5 años sin modificaciones, y solo una caja muy conservadora en un entorno muy conservador puede sobrevivir más de 10. Las tasas de descuento, la depreciación y otra magia contable se dejarán a los financieros profesionales.
Por lo tanto, el cálculo del ROI se realiza de acuerdo con la siguiente fórmula:
Prueba de concepto
¿Cómo podemos saber que una nueva implementación aumentará la cifra en un 10%?
En primer lugar, podemos elegir este número al azar, sacudirlo del augur más cercano. Esto a menudo funciona, pero no menos a menudo conduce al desastre. Tal cambio no se fomenta públicamente; sin embargo, los ancianos reconocen que muchas decisiones exitosas fueron, de hecho, tomadas "a mano".
En segundo lugar, podemos confiar en la experiencia de implementaciones pasadas. Por ejemplo, introducimos la automatización en el quinto centro de llamadas en una fila, antes de eso vimos resultados del 7-10%, sabemos y podemos resolver todos los problemas comunes, y parece que nada debería decepcionarnos. Cuantas más implementaciones realicemos, más preciso será nuestro pronóstico y mejor entenderemos el efecto de varias desviaciones del ideal en el resultado.
Incluso con la experiencia de una sola implementación, se puede hacer un pronóstico mucho más significativo que con el Chuyka. Una consecuencia audaz de esto: parece que incluso una sola implementación inacabada nos dará una gran ventaja frente al Chuyka. Entonces llegamos a la idea de Prueba de concepto, o PoC.
Se necesita PoC para confirmar o refutar el desempeño de una hipótesis, así como evaluar su efectividad. PoC no implica una implementación completa, lo que significa que puede llevarse a cabo de forma rápida y económica. ¿Cuáles son las formas de acelerar en los proyectos de Data Science?
- Para tomar datos manualmente, sucios, directamente desde los lugares donde es más fácil analizarlos. Incluso si esta fuente no es aceptable para la producción, esto no es importante.
- Use la heurística más tonta como línea de base. Por ejemplo, la línea base para pronosticar la carga del día siguiente es la carga de hoy. Aún más frío: la carga promedio en los últimos 5-7-30 días. Te sorprenderás, pero esa heurística no siempre puede ser superada.
- Evalúe la calidad con las pruebas de respaldo: no realice nuevos experimentos de larga duración. Todos los datos ya están en el historial, evaluaremos su efecto.
- No intente hacer código reutilizable. Todo el código después de PoC será arrojado al cubo. Repetimos esto todas las mañanas antes de sentarnos a codificar.
- No intentes hacer un modelo genial. Establezca plazos estrictos: de uno a tres o cinco días por modelo. Para tales períodos, no funcionará "profundizar" en una implementación compleja, pero resultará pasar por muchas opciones simples. Para estas opciones, se obtiene una estimación inferior confiable.
- Busque agresivamente un rastrillo, pise todos los lugares ridículos, pruebe ideas peligrosas. Mientras más rake recolectemos en la etapa de PoC, menor será el riesgo durante el desarrollo de la producción.
Etapas de PoC
La duración de la PoC generalmente varía de una semana a un par de meses. La tarea será realizada por una persona que lidere la fecha del Satanista. La realización de un PoC también requiere mucha atención del cliente comercial: hablar al principio del PoC y comprender los resultados al final. En total, PoC nos costará hasta dos meses de trabajo del DS líder y varios días de trabajo de clientes comerciales. Aquí está el primer indicador: si el cliente no encontró el tiempo para PoC, entonces el resultado de un gran proyecto no tendrá mucha demanda.
Entonces, los pasos.
- Pase de Lista de deseos y Palabras de moda a requisitos comerciales específicos. Esta es una tarea de análisis empresarial tradicional, pero es muy recomendable que DS lo haga él mismo. Para que pueda comprender con mayor precisión las necesidades del cliente y completar la segunda etapa ...
- Formula un experimento. La redacción correcta es la clave del éxito de un proyecto. DS debe determinar en qué parte del proceso comercial se toma una decisión automatizada, qué información está disponible en la entrada, qué se espera en la salida, a qué tipo de tarea de aprendizaje automático se puede reducir, qué datos se necesitarán durante la capacitación y la producción, qué métricas técnicas y comerciales se utilizarán para evaluación del éxito.
- Tratar con los datos. DS debe comprender qué datos están generalmente disponibles para nosotros. Evaluar su composición atributiva, integridad, profundidad de la historia, consistencia. Ensamble rápidamente manualmente un conjunto de datos suficiente para construir un modelo y probar una hipótesis. Sería bueno darse cuenta de inmediato si los datos en producción diferirán de lo que está disponible en el tren y de lo que hemos recopilado aquí.
- El ingeniero presenta y construye un modelo. Los jóvenes satanistas de uñas jóvenes solo piensan en modelos (EUROPA), por lo que los comentarios son superfluos.
- Califica la calidad del modelo. Realice correctamente la validación cruzada, calcule métricas técnicas y comerciales, y evalúe los límites a los que pueden fluctuar en la producción. Todo esto debería hacer DS también.
- Evalúe el ROI resultante, eso es todo por el bien. Para la evaluación, puede atraer representantes del cliente y alguien que sepa cómo multar. modelos.
Hagamos un PoC ficticio basado en nuestro proyecto ficticio.
Etapa 1. Transferir "Lista de deseos" a la tarea
Aquí está la redacción de la lista de deseos:
Parece que si automatizamos la programación, no solo ahorraremos tiempo en la planificación, sino que también aprenderemos a variar la cantidad de turnos dependiendo de la carga.
¿Qué significa esto realmente?
Es necesario crear un sistema que, de acuerdo con el historial de turnos y llamadas, prediga la carga para el próximo período, y organice los turnos de tal manera que se pueda utilizar la carga de manera efectiva.
La métrica del pronóstico de carga es el error en el número de visitas por segmento de tiempo.
Métrica de eficiencia de utilización de carga: percentil 95 del tiempo de espera.
Métrica económica: el número de turnos para el período contable.
La tarea se dividió en dos: cómo predecir la carga y cómo organizar los turnos.
En primer lugar, queremos predecir el número de llamadas con dos semanas de anticipación para que el pronóstico no caiga por debajo de los valores reales en más de un cierto porcentaje.
En segundo lugar, queremos minimizar el número de turnos por período para mantener el percentil 95 del tiempo de espera dentro de límites aceptables, mientras que la carga será la prevista.
Tarea 1. Predicción de carga
El viernes de la semana 1, queremos predecir el número de llamadas en cada hora de la semana 3. El resultado del pronóstico será 168 números, un número por cada hora de la próxima semana.
Deberá hacerse un intervalo de una semana para que los operadores tengan tiempo de adaptarse al horario.
Haremos un pronóstico el viernes por la tarde: por un lado, está lo más cerca posible de las fechas objetivo, por otro lado, todavía hay medio día para resolver el cronograma manualmente. Tendremos acceso a datos históricos sobre solicitudes de todo el historial, así como a un calendario. Construiremos muchas características a partir de esto. Sería bueno vincular la carga a nuestros lanzamientos, pero no tendremos tales datos en la etapa de PoC.
Reducimos el problema a la regresión. Para cada hora en la historia, construiremos un vector de características y predeciremos la carga en esa hora. Deje que la métrica de éxito sea MAPE (o WAPE, lo resolveremos en el camino). La "frente" de validación cruzada en datos temporales no es posible; miraremos hacia el futuro. La salida habitual es dividir la historia en pliegues entrecruzados con un turno semanal (¿cuatro semanas?), Y considerar la última semana como un control. El criterio de éxito es si nuestra WAPE (¿o quién más?) Puede mantenerse dentro de límites razonables. Nuevamente, piense en límites razonables a medida que avanza el experimento.
Tarea 2. Disposición de turnos
De acuerdo con la carga prevista, queremos cubrirlo con turnos para que el número de turnos sea mínimo y los indicadores de calidad se mantengan en un nivel aceptable.
Por el momento, no organizamos operadores en el calendario, solo determinamos cuántos turnos en qué día poner y con qué superposición.
El cálculo se realizará inmediatamente después de completar el pronóstico de carga. Resulta que todos los mismos datos están disponibles, más un pronóstico para la carga.
Parece que el problema puede reducirse al problema inverso de una mochila, el llamado Problema de embalaje del contenedor . Este es un problema NP-completo, pero existen algoritmos para su solución subóptima. La tarea del experimento es confirmar o refutar su aplicabilidad. La métrica objetivo será el número de cambios en la combinación, las condiciones de contorno son la duración promedio o máxima de la espera (o algún tipo de percentil). Nos veremos obligados a modelar la duración de la espera en función del número de llamadas y el número de operadores en el trabajo.
Etapa 3. Estudiamos los datos disponibles.
Acudimos a los administradores de nuestro CRM. Los patearemos un poco y nos descargarán una lista de todas las llamadas al centro de llamadas en los últimos años. De hecho, estamos interesados principalmente en el hecho de la apelación y el momento de la recepción. Con suerte, podremos recopilar datos sobre la duración de la llamada, identificadores de operadores y clientes. En los centros de llamadas más avanzados, incluso puede haber algún tipo de clasificación de llamadas por temas y resultados, pero aún no la necesitamos.
Ahora vamos al supervisor del centro de llamadas y le pedimos que aumente los horarios de todos los operadores durante varios años. El supervisor nos preguntará un par de veces, palidecerá, tomará una bebida válida, y en un par de días se enviarán a nuestro buzón cientos de cartas con sobres adjuntos. Tendremos que pasar otros tres días para poner todo esto en una gran mesa con turnos. Para cambiar, sabremos la fecha, la hora de inicio, la duración y la identificación del operador.
Inmediatamente piense que cuantos más clientes tengamos, más nos llamarán. La información histórica sobre el número de clientes o el volumen de producción será útil, por lo que podemos tener en cuenta las tendencias macro. Volvemos a los administradores de CRM o ERP y les pedimos que descarguen por volumen de ventas, número de clientes o algo así. Digamos que logró obtener datos de suscripción. Ahora podemos construir una tabla donde para cada fecha sea visible el número de clientes activos.
En total, tenemos tres entidades convenientemente distribuidas en tres tabletas:
- Llame al centro de llamadas: número, fecha y hora, duración, identificadores de clientes y operadores.
- Turno de operador: número, fecha, hora de inicio, duración, identificador del operador.
- Macro tendencia de la carga - fecha, número de clientes activos
Etapa 4. Genere señales y entrene al modelo.
Como recordarán, la tarea después de la descomposición se dividió en dos. La segunda parte, sobre la disposición de los turnos, no la tocaremos ahora: no hay necesidad de aprendizaje automático. Hablemos de la primera parte: el pronóstico de carga.
Formulamos el experimento como una tarea de regresión: "para cada hora en la historia construiremos un vector de características y predeciremos la carga en esta hora". Recojamos la muestra de entrenamiento. La fila de la muestra será la hora del calendario. Cada hora corresponde a un objetivo: la cantidad de golpes para esa hora.
Ahora pensemos en qué signos podemos usar.
- Para empezar, aprovechemos la naturaleza del calendario de nuestros datos. Agregue los signos del día de la semana, hora, día del mes. Se pueden encerrar en anillos .
- Agregue el número de llamadas por hora en esos días y a esas horas. Puede tomar el número de visitas en la última semana, así como el promedio del mes y año.
- Agregamos de manera similar el número de visitas exactamente a la misma hora y día de la semana.
- Amplíe la ventana de agregación: agregue el número promedio de visitas en este día de la semana y en este momento del día.
- Intentemos normalizar de inmediato la cantidad de llamadas a la tendencia de carga. Probaremos tanto en valores normalizados como en valores brutos.
- Agregue estacionalidad: el número de visitas por mes del año pasado, normalizado a la tendencia de la carga.
- Por si acaso, también agregamos datos sin procesar sobre la tendencia de la carga. Y tomaremos tanto el valor en el momento actual como los valores "desplazados", hace una semana, hace un mes.
Intentaremos no solo la función de error RMSE "normal", sino también WAPE : es más adecuada para el propósito del problema. Para la validación, no podremos usar la validación cruzada K-fold habitual: habrá una oportunidad de mirar hacia el futuro. Por lo tanto, utilizaremos la partición Nested Folds y fijaremos el tamaño del pliegue de prueba igual a, digamos, exactamente 4 semanas. Y los límites de los pliegues se establecerán exactamente a la medianoche del lunes.
Para PoC, probaremos dos modelos: uno lineal con regularización L1 y la pieza de madera más querida. Para un modelo lineal, no olvide estandarizar (y logaritmo cuando sea necesario) los signos, y para un trozo de madera, desenrosque los parámetros de regularización de forma más agresiva.
Pasos 5 y 6. Evaluaremos la calidad del modelo y el efecto económico.
Entonces, todos los preparativos se han completado, y finalmente podemos pasar a la parte más interesante de PoC: analizar los resultados y tomar decisiones.
Desafortunadamente, todo el ejemplo fue especulativo, sin datos reales, por lo que los resultados serán extraídos del dedo. Para no estar tan avergonzado, tomé las cifras en orden del libro "Call Center Optimization" de Ger Koole (accidentalmente lo encontré al escribir este artículo ¯\_(ツ)_/¯ ). La imagen de allí es un ejemplo de un pronóstico de carga.
Para empezar, pudimos predecir la carga por hora con WAPE = 14%. Fue posible lograr errores de menos del 10% al 43% de las horas, menos del 20% al 70% de las horas.
En general, esto es muy bueno: captamos con bastante precisión las fluctuaciones diarias, los ciclos semanales y las tendencias a mediano plazo. Quemamos solo en fluctuaciones aleatorias y, muy probablemente, no podremos evitarlas.
Según la carga, podemos calcular fácilmente el número de operadores que deberían estar en el turno en un momento dado. Escribimos un algoritmo codicioso de programación de turnos no óptimo y calculamos que pudimos ahorrar el 10% de los turnos en la carga de pronóstico. Resultó que si, además de los turnos de 12 horas, presentamos turnos de 8 horas y los organizamos de manera inteligente todos los días, podemos ahorrar otro 5%.
Traducimos indicadores en dinero. El costo actual del mantenimiento anual del centro de llamadas es de 50 millones de rublos por año. Nuestro experimento demostró que podemos reducir esta cantidad en un 15%, lo que conducirá a ahorros de hasta 7.5 millones de rublos por año, y para toda la vida útil: hasta 22.5 millones de rublos.
Este es un efecto muy bueno, y quiero reconocer que PoC es exitoso. Sin embargo, detengámonos y analicemos qué puede salir mal.
Riesgos que afectan los beneficios económicos
Tuvimos un efecto positivo debido a la reducción en el número de empleados. Pudimos reducir la cantidad de empleados al reducir la cantidad de turnos. Pudimos reducir el número de turnos debido a su redistribución de acuerdo con la carga prevista. Pudimos predecir la carga mediante simulación basada en datos históricos.
En primer lugar, si los patrones de uso de productos a los que sirve nuestro centro de llamadas cambian, los datos históricos perderán relevancia. La posibilidad de que los patrones no cambien en los próximos tres años es lo suficientemente pequeña. Es necesario establecer los costos de una mayor capacitación y corrección del modelo en el transcurso de su vida.
En segundo lugar, predijimos la carga con bastante precisión, pero, sin embargo, en el 30% de los casos cometemos más del 20% de errores. , . .
-, PoC' , , . - , , . - , .
, "" . , .
, .
,
PoC , .
-, . , CRM. , . , . , . , CRM -. , , .
-, , , , . , , — , . , , . - — .
-, — , , . , , - . , . - - , !.. , . , — 2-5 , 3-5 .
, .
20 . . .
— 5 CRM, 40 , 5 , 10 , 5 , 3120,5 , 23 . 65 , 24 . — 1,3 + 0,48 3 .
— 10 + 60 + 10 + 20 + 10 + 3121 + 53 = 110 51 , 2,2 + 1,02 .
— . 20 + 80 + 20 + 40 + 10 + 3122 + 55 = 170 97 , 3,4 + 1,94 .
, 40% , .
ROI
15% , 22,5 , 7,5 . 1,3 + 0,48 , +6,2 (+377% ROI) +21 (+1160% ROI) . .
, , . , 50% , 10%- , 5% . 2,5% — 7,5% 15% . 3,75 , 11,25 . .
— 2,2 1,02 . +55% ROI , +252% . , .
20%- . 5% , 2,5% , 1,25 , 3,75 . , . , 3 +17% ROI. , . , 20%- .
3,4 . ROI +121% . 3 +108% ROI "" .
, , ROI +55% +252% , , . , .
| | Income | Dev | Support | ROI 1 | ROI 3 |
|---|
| Optim | Optim | 7,5 | 1,3 | 0,5 | +4x | +11x |
| Optim | Real | 7,5 | 2,2 | 1,0 | +2x | +6x |
| Optim | Pessim | 7,5 | 3,4 | 1,9 | +85% | +3x |
| Real | Optim | 3,75 | 1,3 | 0,5 | +155% | +5 |
| Real | Real | 3,75 | 2,2 | 1,0 | +48% | +2,5 |
| Real | Pessim | 3,75 | 3,4 | 1,9 | -7% | +112% |
| Pessim | Optim | 1,25 | 1,3 | 0,5 | -14% | +108% |
| Pessim | Real | 1,25 | 2,2 | 1,0 | -50% | +17% |
| Pessim | Pessim | 1,25 | 3,4 | 1,9 | -69% | -29% |
PS
PoC, , ? , ...
-, , WFM, WorkForce Management. , — , . - , , . $1000 $2500. WFM , . , WFM -. , ?
, — , . DS', . . , . , . .
, . "" 7,5%, 37,5 . . . — ROI. — . ROI 26,66 , 53 . ROI 27 .
.
-, . - - . .
-, . , . .
— .
Conclusiones
- WFM -. , - . WFM — .
- — .
- , ,
? , PoC'. - PoC' , ?
- — - .