Recentemente, em uma acolhedora sala de bate-papo, a data dos satanistas levantou a questão de como "vender" adequadamente projetos internos de aprendizado de máquina. Descobriu-se que muitos de nós somos muito sensíveis à viabilidade econômica de nossas atividades. Enquanto isso, para realizar uma avaliação mínima da lucratividade do projeto, não é necessário um MBA - em um pequeno artigo (10 páginas de texto, ke-ke-ke) vou lhe dizer o que é o ROI, como avaliá-lo para um projeto interno, qual o seu papel. Prova de conceito e por que na vida real tudo pode dar errado. Faremos tudo isso em torno de um projeto fictício para automatizar a programação de um call center. Bem-vindo ao gato!
Nosso projeto fictício
O call center possui 100 operadoras. Eles trabalham em um horário flutuante, indo trabalhar em turnos de 8 ou 12 horas. Os turnos começam em horários diferentes e são organizados de forma a garantir a vigilância de muitas pessoas nos horários de pico e um pequeno número de pessoas nas horas frias à noite e nos finais de semana. A programação é planejada pelo supervisor de plantão do call center nas noites escuras de sexta-feira, planejando a carga para a próxima semana.
Um dia de 8 horas do operador de call center custa à empresa 2.000 rublos. Se assumirmos que existem 250 dias úteis em um ano, o call center custa à empresa 100 2.000 250 = 50 por ano. Se automatizarmos o agendamento, podemos prever a carga horária e organizar turnos para variar o número de operadores de serviço, dependendo da carga prevista. Se nossa previsão e disposição dos turnos for pelo menos 10% melhor que a previsão e disposição do supervisor, economizaremos até 5 milhões de rublos. por ano. Se realmente conseguirmos melhorar 10% de melhoria, o projeto definitivamente será recompensado. Ou não? .. Vamos pensar em como tomar essas decisões.
De acordo com o ROI
Antes de iniciar um grande projeto, seria bom avaliar sua viabilidade econômica. Uma maneira de fazer isso é calcular o retorno do investimento, ROI.
ROI (Return on Investment) é um indicador de rentabilidade do projeto igual à razão entre a receita e o investimento gasto. ROI <100% significa que o projeto não será recompensado.
As primeiras despesas do projeto ocorrem imediatamente, no início - para a compra de ferro e licenças, o desenvolvimento do sistema e sua implementação. Isso é chamado de gasto de capital. Durante a vida útil do projeto, ele também deve arcar com os custos - pelo aluguel do mesmo hardware e licenças, suportando a operacionalidade do sistema e, às vezes, o trabalho dos operadores. Isso é chamado de despesas operacionais.
Projetos de ML, como regra, não possuem “receita instantânea”. As receitas do projeto estão operando apenas, ou seja, a tempo. Por exemplo, no caso de nosso call center, a receita é formada como uma economia de custos para as operadoras. Se os custos operacionais do projeto excederem as receitas, o projeto nunca será recompensado.
Devido às despesas de capital "instantâneas" no início do projeto, o ROI dependerá do tempo em que avaliarmos a lucratividade. Normalmente, o ano, o horizonte de planejamento ou a vida útil do sistema são usados para calcular o ROI. Tudo fica claro com o ano - é uma maneira fácil de entender se o projeto será recompensado em um ano ou não. O horizonte de planejamento é o intervalo de tempo durante o qual a estratégia da empresa é planejada e os orçamentos são elaborados. Nas pequenas e dinâmicas empresas, o horizonte raramente ultrapassa um ano; nas grandes e estáveis, pode ser de três a dez anos.
No horizonte distante do planejamento, você pode recuperar qualquer lixo, mas a vida comum é protegida pelo tempo de vida do sistema. Geralmente, depois de alguns anos, o sistema deixa de atender aos requisitos dos negócios e é substituído por um novo, descartado ou (na maioria das vezes) deixado para apodrecer com o eterno suporte. Com o rápido crescimento dos negócios, o sistema nem sempre pode viver por seis meses, em um mercado estável, o sistema se torna obsoleto em 3-5 anos sem modificações, e apenas uma caixa muito conservadora em um ambiente muito conservador pode sobreviver mais de 10. Taxas de desconto, depreciação e outras mágicas contábeis serão deixadas para financiadores profissionais.
Assim, o cálculo do ROI é feito de acordo com a seguinte fórmula:
Prova de conceito
Como podemos saber que uma nova implementação aumentará o número em 10%?
Primeiramente, podemos escolher esse número aleatoriamente, agitá-lo do augur mais próximo. Isso geralmente funciona, mas não menos frequentemente leva ao desastre. Tal variação não é incentivada publicamente; no entanto, os mais velhos reconhecem que muitas decisões bem-sucedidas foram, de fato, tomadas “à mão”.
Em segundo lugar, podemos confiar na experiência de implementações anteriores. Por exemplo, introduzimos a automação no quinto call center consecutivo, antes de vermos resultados de 7 a 10%, sabemos e podemos resolver todos os problemas comuns, e parece que nada deve nos decepcionar. Quanto mais implementações executamos, mais precisa é a nossa previsão e melhor entendemos o efeito de vários desvios do ideal no resultado.
Mesmo com a experiência de uma única implementação, uma previsão muito mais significativa pode ser feita do que com o Chuyka. Uma conseqüência ousada disso - parece que mesmo uma única implementação inacabada nos dará uma grande vantagem em frente ao Chuyka. Então chegamos à idéia de Prova de Conceito, ou PoC.
O PoC é necessário para confirmar ou refutar o desempenho de uma hipótese, bem como avaliar sua eficácia. O PoC não implica uma implementação completa, o que significa que ele pode ser realizado de forma rápida e barata. Quais são as maneiras de acelerar nos projetos de ciência de dados?
- Para levar os dados manualmente, de maneira suja, diretamente dos locais onde é mais fácil analisar. Mesmo que essa fonte não seja aceitável para produção, isso não é importante.
- Use as heurísticas mais burras como linha de base. Por exemplo, a linha de base para prever a carga do dia seguinte é a carga de hoje. Ainda mais frio - a carga média nos últimos 5-7-30 dias. Você ficará surpreso, mas essa heurística nem sempre pode ser superada.
- Avalie a qualidade com o teste de retorno - não realize novos experimentos de longa duração. Todos os dados já estão no histórico, avaliaremos o efeito sobre eles.
- Não tente criar código reutilizável. Todo o código após PoC será lançado no balde. Repetimos isso todas as manhãs antes de nos sentarmos para codificar.
- Não tente fazer um modelo legal. Defina prazos rígidos - de um a três a cinco dias por modelo. Por esses períodos, não funcionará para "cavar" uma implementação complexa, mas passará por muitas opções simples. Para essas opções, é obtida uma estimativa mais baixa confiável.
- Agressivamente, procure um ancinho, pise em todos os lugares ridículos, teste idéias perigosas. Quanto mais rake coletarmos no estágio de PoC, menor será o risco durante o desenvolvimento da produção.
Etapas do PoC
A duração do PoC geralmente varia de uma semana a alguns meses. A tarefa será executada por uma pessoa liderando a data do satanista. A condução de um PoC também requer muita atenção do cliente comercial - conversando no início do PoC e compreendendo os resultados no final. No total, o PoC nos custará até dois meses de trabalho do DS principal e vários dias de trabalho de clientes corporativos. Aqui está o primeiro indicador - se o cliente não encontrou tempo para o PoC, o resultado de um grande projeto não estará realmente em demanda.
Então, os passos.
- Vá de Lista de desejos e Palavras do Google Buzz a requisitos comerciais específicos. Essa é uma tarefa tradicional de análise de negócios, mas é altamente recomendável que o DS faça isso sozinho. Para que ele possa entender com mais precisão as necessidades do cliente e concluir a segunda etapa ...
- Formule um experimento. A redação correta é a chave para o sucesso de um projeto. O DS deve determinar onde, no processo de negócios, é tomada uma decisão automatizada, quais informações estão disponíveis na entrada, o que é esperado na saída, a que tipo de tarefa de aprendizado de máquina ela pode ser reduzida, a quais dados serão necessários durante o treinamento e a produção, quais métricas técnicas e de negócios usar para avaliação de sucesso.
- Lide com os dados. O DS deve entender quais dados geralmente estão disponíveis para nós. Avaliar sua composição atributiva, integridade, profundidade da história, consistência. Monte rapidamente um conjunto de dados manualmente, o suficiente para construir um modelo e testar uma hipótese. Seria bom perceber imediatamente se os dados em produção diferem do que está disponível no trem e do que coletamos aqui.
- Projete recursos e construa um modelo. Jovens satanistas de unhas jovens pensam apenas em modelos (EUROPA), então os comentários são supérfluos.
- Classifique a qualidade do modelo. Realize corretamente a validação cruzada, calcule métricas técnicas e comerciais, bem como avalie os limites para os quais eles podem flutuar na produção. Tudo isso deve fazer o DS também.
- Avalie o ROI resultante - isso é tudo por causa disso. Para avaliação, você pode atrair representantes do cliente e alguém que saiba negociar. modelos.
Vamos fazer um PoC fictício baseado em nosso projeto fictício.
Etapa 1. Transferir "Lista de desejos" para a tarefa
Aqui está o texto da lista de desejos:
Parece que, se automatizarmos o agendamento, não apenas economizaremos tempo no planejamento, mas também aprenderemos a variar o número de turnos, dependendo da carga.
O que isso realmente significa?
É necessário criar um sistema que, de acordo com o histórico de turnos e chamadas, preveja a carga para o próximo período, bem como organize turnos de forma a utilizar efetivamente a carga.
A métrica de previsão de previsão de carga é o erro no número de ocorrências por intervalo de tempo.
Métrica de eficiência de utilização de carga - percentil 95 do tempo de espera.
Métrica econômica - o número de turnos do período contábil.
A tarefa se dividiu em duas - como prever a carga e como organizar turnos.
Em primeiro lugar, queremos prever o número de chamadas com duas semanas de antecedência, para que a previsão não caia abaixo dos valores reais em mais de uma determinada porcentagem.
Em segundo lugar, queremos minimizar o número de turnos por período, a fim de manter o percentil 95 do tempo de espera dentro de limites aceitáveis, enquanto a carga será a prevista.
Tarefa 1. Previsão de carga
Na sexta-feira da semana 1, queremos prever o número de chamadas a cada hora da semana 3. O resultado da previsão será de 168 números - um número para cada hora da próxima semana.
Será necessário um intervalo de uma semana para que os operadores tenham tempo para se ajustar ao cronograma.
Faremos uma previsão na sexta-feira à tarde - por um lado, é o mais próximo possível das datas previstas, por outro lado, ainda há meio dia para acertar a programação manualmente. Teremos acesso a dados históricos sobre solicitações para todo o histórico, bem como um calendário. Vamos construir muitos recursos com isso. Seria bom vincular a carga aos nossos lançamentos, mas não teremos esses dados no estágio de PoC.
Reduzimos o problema à regressão. Para cada hora do histórico, criaremos um vetor de recurso e preveremos a carga nele nessa hora. Deixe a métrica de sucesso ser MAPE (ou WAPE, descobriremos isso ao longo do caminho). A validação cruzada "testa" em dados temporários não é possível - veremos o futuro. A saída usual é dividir a história em dobras que se cruzam com um turno semanal (quatro semanas?), E considere a última semana como um controle. O critério de sucesso é se nossa WAPE (ou quem mais?) Pode ser mantida dentro de limites razoáveis. Mais uma vez, pense sobre limites razoáveis à medida que o experimento progride.
Tarefa 2. Arranjo de turnos
De acordo com a carga prevista, queremos cobri-la com turnos, para que o número de turnos seja mínimo e os indicadores de qualidade permaneçam em um nível aceitável.
No momento, não organizamos operadores no calendário, apenas determinamos quantos turnos em que dia colocar e com que sobreposição.
O cálculo será realizado imediatamente após a conclusão da previsão de carga. Acontece que todos os mesmos dados estão disponíveis, além de uma previsão para a carga.
Parece que o problema pode ser reduzido ao problema inverso de uma mochila, o chamado Problema na embalagem do escaninho . Esse é um problema NP-completo, mas existem algoritmos para sua solução subótima. A tarefa do experimento é confirmar ou refutar sua aplicabilidade. A métrica de destino será o número de turnos na combinação. As condições de contorno são a duração média ou máxima da espera (ou algum tipo de percentil). Seremos forçados a modelar a duração da espera em função do número de chamadas e do número de operadores no trabalho.
Etapa 3. Estudamos os dados disponíveis
Vamos aos administradores do nosso CRM. Vamos chutá-los um pouco e eles nos descarregam uma lista de todas as chamadas para a central de atendimento nos últimos anos. De fato, estamos interessados principalmente no fato do recurso e na hora do recebimento. Com alguma sorte, poderemos coletar dados sobre a duração da chamada, identificadores de operadoras e clientes. Em call centers mais avançados, pode até haver algum tipo de classificação de chamadas por tópicos e resultados, mas ainda não precisamos disso.
Agora vamos ao supervisor do call center e pedimos para aumentar a programação de todos os operadores por vários anos. O supervisor nos pedirá algumas vezes, empalidecerá, beberá um validolchik - e em alguns dias centenas de cartas com excelentes anexos serão encaminhadas para nossa caixa de correio. Teremos que passar mais três dias para trazer tudo isso para uma grande mesa com turnos. Para alterar, saberemos a data, hora de início, duração e ID do operador.
Pense imediatamente que quanto mais clientes tivermos, mais eles nos chamarão. Informações históricas sobre o número de clientes ou o volume de saída serão úteis - para que possamos levar em consideração as tendências macro. Vamos novamente aos administradores do CRM ou ERP e pedimos que eles descarregem por volume de vendas, número de clientes ou algo assim. Digamos que você conseguiu obter dados de inscrição. Agora podemos criar uma tabela onde, para cada data, o número de clientes ativos é visível.
No total, temos três entidades convenientemente dispostas em três tablets:
- Ligue para o call center - número, data e hora, duração, identificadores de clientes e operadoras.
- Turno do operador - número, data, hora de início, duração, identificador do operador.
- Tendência macro da carga - data, número de clientes ativos
Etapa 4. Gere sinais e treine o modelo
Como você se lembra, a tarefa após a decomposição caiu em duas. A segunda parte, sobre o arranjo de turnos, não tocaremos agora - não há necessidade de aprendizado de máquina. Vamos falar sobre a primeira parte - previsão de carga.
Formulamos o experimento como uma tarefa de regressão - "para cada hora da história, construiremos um vetor de recurso e preveremos a carga nele a essa hora". Vamos coletar a amostra de treinamento. A linha na amostra será a hora do calendário. Cada hora corresponde a um alvo - o número de ocorrências para essa hora.
Agora vamos pensar em quais sinais podemos usar.
- Para iniciantes, vamos aproveitar a natureza do calendário de nossos dados. Adicione os sinais do dia da semana, hora, dia do mês. Eles podem ser trancados em anéis .
- Adicione o número de chamadas por hora nesses dias e horas. Você pode obter o número de acessos na última semana, bem como a média do mês e do ano.
- Adicionamos de maneira semelhante o número de hits exatamente na mesma hora e dia da semana.
- Amplie a janela de agregação - adicione o número médio de ocorrências neste dia da semana e nessa hora do dia.
- Vamos tentar normalizar imediatamente o número de chamadas para a tendência de carregamento. Testaremos os valores normalizados e brutos.
- Adicionar sazonalidade - o número de ocorrências por mês no ano passado, normalizado de acordo com a tendência da carga.
- Apenas no caso, também adicionamos dados brutos sobre a tendência da carga. E pegaremos o valor no momento atual e os valores "deslocados" - uma semana atrás, um mês atrás.
Vamos tentar não apenas a função de erro RMSE "normal", mas também o WAPE - ela é mais adequada para a finalidade do problema. Para a validação, não poderemos usar a validação cruzada usual com dobras K - haverá uma chance de olhar para o futuro. Portanto, usaremos a partição Nested Folds e fixaremos o tamanho da dobra de teste igual a, digamos, exatamente 4 semanas. E os limites das dobras serão definidos exatamente à meia-noite de segunda-feira.
Para o PoC, tentaremos dois modelos - um linear com regularização L1 e o pedaço de madeira mais amado. Para um modelo linear, não se esqueça de padronizar (e logaritmo quando necessário) os sinais e, para um pedaço de madeira, desaparafuse os parâmetros de regularização mais agressivamente.
Etapas 5 e 6. Avaliaremos a qualidade do modelo e o efeito econômico.
Assim, todos os preparativos foram concluídos e, finalmente, podemos passar para a parte mais interessante do PoC - analisando os resultados e tomando decisões.
Infelizmente, o exemplo inteiro foi especulativo, sem dados reais, portanto os resultados serão sugados para fora do dedo. Para não ficar com vergonha, peguei números em ordem do livro "Otimização de Call Center" de Ger Koole (acidentalmente o encontrei enquanto escrevia este artigo ¯\_(ツ)_/¯ ). A figura a seguir mostra um exemplo de previsão de carga.
Para começar, conseguimos prever a carga horária com WAPE = 14%. Foi possível obter erros inferiores a 10% a 43% das horas, inferiores a 20% a 70% das horas.
Em geral, isso é muito bom - captamos com precisão as flutuações diárias, ciclos semanais e tendências de médio prazo. Nós queimamos apenas em flutuações aleatórias e, muito provavelmente, não seremos capazes de evitá-las.
De acordo com a carga, podemos calcular facilmente o número de operadores que devem estar no turno em um determinado momento. Escrevemos um algoritmo ganancioso e não otimizado para agendador de turnos e calculamos que conseguimos economizar 10% dos turnos na carga de previsão. Descobriu-se que, além dos turnos de 12 horas, apresentamos turnos de 8 horas e organizá-los com inteligência diariamente, podemos economizar mais 5%.
Nós traduzimos indicadores em dinheiro. O custo atual da manutenção anual do call center é de 50 milhões de rublos por ano. Nosso experimento mostrou que podemos reduzir esse valor em 15%, o que levará a uma economia de até 7,5 milhões de rublos por ano e, durante toda a vida útil, até 22,5 milhões de rublos.
Esse é um efeito muito bom, e eu só quero reconhecer o PoC como bem-sucedido. Vamos, no entanto, demorar e analisar o que pode dar errado.
Riscos que afetam benefícios econômicos
Tivemos um efeito positivo devido à redução no número de funcionários. Conseguimos reduzir o número de funcionários, reduzindo o número de turnos. Conseguimos reduzir o número de turnos devido à sua redistribuição de acordo com a carga prevista. Conseguimos prever a carga usando simulação com base em dados históricos.
Em primeiro lugar, se os padrões de uso dos produtos atendidos pelo nosso call center mudarem, os dados históricos perderão relevância. A chance de que os padrões não mudem nos próximos três anos é pequena o suficiente. É necessário estabelecer os custos de treinamento adicional e correção do modelo ao longo de sua vida.
Em segundo lugar, previmos a carga com muita precisão, mas, no entanto, em 30% dos casos cometemos mais de 20% de erros. , . .
-, 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 .
.
-, . - - . .
-, . , . .
— .
Conclusões
- WFM -. , - . WFM — .
- — .
- , ,
? , PoC'. - PoC' , ?
- — - .