Анализ эффективности рекламных источников – это не единственная задача интернет-аналитики. Сюда входит и оценка работы сотрудников, которые обрабатывают полученные лиды.
Очень часто бывает, когда конверсий много, их цена приемлема, а продажи не растут и даже падают. Здесь аналитики «до прибыли с клика» уже не хватает, чтобы выяснить причину. И тогда на помощь приходит анализ «до прибыли с менеджера». Потому что как бы идеально не была настроена реклама, клиенты сначала взаимодействуют с менеджерами, а уже потом принимают решение. Именно от качества работы сотрудников зависит успешность вашего бизнеса.

Традиционные системы аналитики используют CRM, чтобы зафиксировать факт продажи/обращения с менеджером. Однако такой подход лишь частично решает задачу: оценивает эффективность сотрудника «в сухом остатке». То есть показывает продажи и конверсию, но оставляет «за бортом» само общение с клиентом. А ведь от уровня коммуникаций и зависит результат.

Чтобы заполнить «пробел» мы разработали инструмент, который автоматически свяжет каждый звонок с обработавшим его менеджером. Не придется привлекать CRM и сторонние сервисы. По сути, наша система ставит тег «имя менеджера» на каждый входящий звонок.

Так руководители отдела продаж/клиентского сервиса проконтролируют качество работы, найдут проблемные участки и построят аналитику. В этом поможет быстрое сегментирование звонков на тех менеджеров, которые их принимают.

Постановка задачи

Задача, которую мы поставили себе, звучит следующим образом: пусть системе известны образцы речи всех менеджеров, которые могут принимать звонки. Тогда для нового звонка нужно поставить тег менеджера, голос которого наиболее «похож» в разговоре из списка известных.

При этом априори считается, что новый телефонный звонок успешен. То есть разговор между менеджером и клиентом фактически состоялся. Если говорить неформально, эту задачу можно отнести к классу задач «обучения с учителем», то есть классификации.

В качестве объектов – некоторым образом векторизованные (оцифрованные) аудиозаписи, где звучит только голос менеджера. В роли ответов – метки классов (имена менеджеров). Тогда задача алгоритма тегирования состоит в:

1. Извлечении значимых признаков из аудиофайлов
2. Выборе наиболее подходящего алгоритма классификации
3. Обучении алгоритма и сохранении моделей менеджеров
4. Оценке качества работы алгоритма и модификации его параметров
5. Тегировании (классификации) новых звонков

Некоторые из этих задач распадаются на отдельные подзадачи. Это связано со спецификой тех условий, в которых должен работать алгоритм. Телефонные звонки, как правило, зашумлены. Клиент в рамках одного разговора может общаться с несколькими менеджерами. Также вообще не состояться, а еще звонки часто включают в себя IVR и т. д.

Например, задача тегирования новых звонков может быть разделена на:

1. Проверку звонка на успешность (факт наличия разговора)
2. Разделение стерео на моно-дорожки
3. Фильтрацию шумов
4. Выявление участков с речью (фильтрация музыки и других посторонних звуков)

В дальнейшем мы поговорим о каждой такой подзадаче отдельно. А пока сформулируем технические ограничения, которые мы накладываем на входные данные, полученное решение, а также на сам алгоритм классификации.

Ограничения на решение

Необходимость ограничений отчасти продиктованы техникой и требованиями сложности реализации, а еще – балансом между универсальностью алгоритма и точностью его работы.

Ограничения на входной файл и файлы обучающей выборки:

1. Формат – wav или wave (можно далее перекодировать в mp3)
2. Стерео необходимо впоследствии делить на 2 дорожки – оператора и клиента
3. Частота дискретизации – 16 000 Гц и выше
4. Разрядность – от 16 бит и выше
5. Файл для обучения модели должен иметь длительность от 30 секунд и содержать только голос конкретного менеджера
6. Файл, который тегируется моделью, должен содержать разговор, то есть должен быть успешным

Все указанные выше требования кроме последнего были сформулированы в результате серии экспериментов, которые проводились на этапе настройки алгоритмов. Эта комбинация показала себя самой эффективной с точки зрения минимизации вероятности ошибки, а именно неправильной классификации при необременительных условиях настройки.

Например, очевидно, что чем длиннее файл в обучающей выборке, тем точнее будет классификатор. Но тем сложнее найти такой файл в журнале звонков (нашей обучающей выборке). Поэтому длительность 30 секунд – компромисс между точностью и сложностью настроек. Последнее требование (успешности) необходимо. Система не должна ставить тег менеджера звонку, где фактически не было разговора.

Ограничения алгоритма привели к следующему решению:

• Система всегда ставит тег менеджера в предположении, что звонок успешный. В модели недопустим «неизвестный менеджер». Такой тег не появится. Если в обучающей выборке не был размечен кто-то из менеджеров, то система всегда будет ошибаться.
• Система всегда ставит только один тег для каждого звонка. Если с клиентом общалось несколько менеджеров, то будет выбран тот, кто вел коммуникацию дольше.

Первое требование появилось в результате экспериментов. Тогда выяснилось, что «неизвестный» менеджер усложняет архитектуру решения. Для этого надо подбирать пороги, после которых сотрудник будет классифицирован как «нераспознанный». Также «неизвестный» менеджер уменьшает точность на 10 процентных пунктов.

Кроме того, появляется ошибка второго рода, когда известный менеджер классифицируется как неизвестный. Вероятность такой ошибки – 7-10% в зависимости от числа известных. Это требование можно назвать существенным. Оно обязывает настройщика алгоритма указать в обучающей выборке всех менеджеров. А также вносить туда модели новых сотрудников и удалять уволившихся.

Второе требование проистекает из практических соображений и архитектуры алгоритма, который мы используем. Если кратко, алгоритм разбивает исследуемое аудио на фрагменты с речью и «сравнивает» каждый со всеми обученными моделями менеджеров поочередно.

В итоге «мини-тег» ставится каждому из мини-фрагментов. При таком подходе велика вероятность, что часть фрагментов распознается неверно. Например, если они остались зашумленными или их длина слишком коротка.

Тогда, если в итоговом решении отображать все «мини-теги», то помимо тега реального менеджера, будет отображаться множество «мусорных». Поэтому выводится лишь наиболее «частый» тег.

Описание входных/выходных данных

Входные данные мы разделим на 2 типа:

Данные на входе алгоритма формирования моделей менеджеров (данные для обучения):

• Аудиофайл + метка класса

Данные на входе алгоритма тегирования (данные для тестирования/штатного режима работы):

• Внешние данные (аудиофайл)
• Внутренние данные (сохраненные модели)

Выходные данные также разделяются на 2 типа:

1. Выходные данные алгоритма формирования моделей
2. Обученные модели менеджеров
3. Выходные данные алгоритма тегирования
4. Тег менеджера

На вход алгоритму при любом режиме его работы поступает аудиофайл, которые удовлетворяют требованиям. Они есть в разделе «ограничения».

На входе алгоритма формирования моделей допускается, чтобы одному классу (менеджеру) соответствовало несколько входных файлов. Но один файл не может соответствовать нескольким менеджерам. Имя метки класса можно поместить в название файла. Или просто создать отдельный каталог под каждого сотрудника.

Алгоритм обучения моделей на основе входных данных формирует множество моделей, которые можно загружать при обучении. Их количество соответствует числу различных тегов во множестве аудиофайлов.

Таким образом, если имеется M файлов, которые размечены n различными метками классов, то алгоритм на этапе обучения создает n моделей менеджеров:

1. Model_manager_1.pkl
2. Model_manager_2.pkl
3. …
4. Model_manager_n.pkl

где вместо «manager_…» указывается имя класса.

На вход алгоритму тегирования поступает неразмеченный аудиофайл, в котором априори присутствует разговор между менеджером и клиентом, а также n моделей сотрудника. В результате алгоритм возвращает тег – имя класса наиболее «правдоподобного» менеджера.

Предобработка данных

Предобработке подвергаются аудиофайлы. Она последовательна и проходит как в режиме тегирования, так и в режиме обучения моделей:

• Проверка успешности звонка – только на этапе тегирования
• Разделение стерео на 2 моно-дорожки и дальнейшая работа только с дорожкой оператора
• Оцифровка – выделение параметров звукового сигнала
• Фильтрация шумов
• Удаление «длинных» пауз – выявление фрагментов со звуком
• Фильтрация фрагментов не с речью – удаление музыки, фона и т. д.
• Склейка фрагментов с речью (только на этапе обучения)

Мы не будем подробно останавливаться на этапе проверки успешности. Это предмет для отдельной статьи. Если кратко, суть этапа состоит в том, что звонок классифицируется согласно тому, есть ли в нем разговор «живых людей». Под «живыми людьми» имеется в виду клиент и менеджер, а не голосовой помощник, музыка и т. д.

Успешность звонка проверяется при помощи специально обученного классификатора с внешним порогом – «минимальная длительность разговора, после которого звонок считается успешным».

На втором этапе происходит разделение стерео-файла на 2 дорожки: менеджера и клиента. В дальнейшем обработка осуществляется только для дорожки сотрудника.

На этапе оцифровки из операторской дорожки извлекаются параметры «фичи», которые представляют из себя цифровое представление сигнала. Мы в Calltouch использовали мел-кепстральные компоненты. Кроме того, извлечение параметров происходит на очень маленьком по длительности фрагменте, которое называется шириной окна (0.025 секунды). Все фичи при этом нормализуются.

nfft=2048 // длина преобразования Фурье appendEnergy = False    def get_MFCC(sr,audio): //функция извлечения фич из аудио, sr=16000 - частота features = mfcc.mfcc(audio, sr, 0.025, 0.01, 13, 26, nfft, 0, 1000,  appendEnergy)     features = preprocessing.scale(features)     return features    count = 1 features = np.asarray(()) //пустой вектор признаков for path in file_paths: //цикл по всем файлам модели path = path.strip() sr,audio = read(source + path) // считываем аудио vector = get_MFCC (sr, audio) #извлекаем признаки из файла if features.size == 0:      features = vector else:      features = np.vstack((features, vector))

На выходе каждый аудиофайл превращается в массив, в котором построчно записаны мел-кепстральные характеристики каждого фрагмента длительностью 0.025 секунды.

Дальнейшая обработка файла состоит в фильтрации шумов, удалении длинных пауз (а не пауз между звуками), поиске речи. Эти задачи можно решать при использовании различных инструментов. В своем решении мы использовали методы из библиотеки pyaudioanalysis:

clear_noise(fname,outname,ch_n) # для очистки шума.

1. fname – входной файл
2. outname – выходной файл
3. ch_n – число каналов

На выходе получаем файл outname, в который записан очищенный от шумов звук из файла fname.

silenceRemoval(x, Fs, stWin, stStep) # для удаления «длинных пауз»

1. x – входной массив (оцифрованный сигнал)
2. Fs – частота дискретизации
3. stWin – ширина окна извлечения признаков
4. stStep – величина шага смещения

На выходе получаем массив вида:

[l_1,r_1]
[l_2,r_2]
[l_3,r_3]
…
[l_N,r_N]

где l_i — время начала i-ого сегмента (сек), r_i — время окончания i-ого сегмента (сек).

detect_audio_segment(x,thrs) # извлечение речи.

1. x – входной массив (оцифрованный сигнал)
2. hrs – минимальная длина (в секундах) детектируемого фрагмента с речью

На выходе получаем те фрагменты [l_i,r_i], которые содержат речь длительностью от thrs секунд.

В результате предобработки входной аудиофайл преобразуется к виду массива:

[l_1,r_1]
[l_2,r_2]
[l_3,r_3]
…
[l_N,r_N],

где каждый фрагмент представляет из себя временной интервал очищенного файла с речью.

Таким образом, мы можем каждому такому фрагменту сопоставить матрицу признаков (мел-кепстральных характеристик), которая будет использоваться для обучения модели и на этапе тегирования.

Используемые методы / алгоритмы

Как уже было отмечено выше, наше решение базируется на библиотеке pyaudioanalysis.py, написанной на Python 2.7. Ввиду того, что наше общее решение реализовано на версии Python 3.7, то некоторые функции библиотеки были модифицированы и адаптированы для данной версии языка.

В целом алгоритм инструмента по тегированию менеджеров можно разделить на 2 части:

1. Обучение моделей менеджеров
2. Тегирование

Более детальное описание каждой части выглядит так.

Обучение моделей менеджеров:

1. Загрузка обучающей выборки
2. Предобработка данных
3. Подсчет числа классов
4. Создание модели менеджера для каждого из классов
5. Сохранение модели

Тегирование:

1. Загрузка звонка
2. Проверка звонка на успешность
3. Предобработка успешного звонка
4. Загрузка всех обученных моделей менеджеров
5. Классификация каждого фрагмента обработанного звонка
6. Поиск наиболее вероятной модели менеджера
7. Проставление тега

Мы уже подробно останавливались на задачах предобработки данных. Теперь рассмотрим методы создания моделей менеджеров.

В качестве модели мы использовали алгоритм GMM (Gaussian Mixture Model). Он моделирует наши данные при предположении о том, что они являются реализациями случайной величины с распределением, которое описывается смесью гауссиан – каждая со своей дисперсией и своим математическим ожиданием.

Известно, что наиболее распространенным алгоритмом поиска оптимальных параметров такой смеси – EM-алгоритм (Expectation Maximization). Он разделяет сложную задачу максимизации правдоподобия многомерной случайной величины на серию задач максимизации меньшей размерности.

В результате серии экспериментов мы пришли к следующим параметрам алгоритма GMM:

gmm = GMM(n_components = 16, n_iter = 200, covariance_type='diag',n_init = 3)

Такая модель создается под каждого менеджера, и затем она обучается – ее параметры настраиваются на конкретные данные.

 gmm.fit(features)

Далее модель сохраняется, чтобы ее использовать на этапе тегирования:

picklefile = path[path.find('/')+1:path.find('.')]+".gmm" pickle.dump(gmm,open(dest + picklefile,'wb'))

На этапе тегирования мы загружаем сохраненные ранее модели:

gmm_files = [os.path.join(modelpath,fname) for fname in                   os.listdir(modelpath) if fname.endswith('.gmm')]

modelpath – директория, куда мы сохранили модели.

models        = [pickle.load(open(fname,'rb'),encoding='latin1') for fname in gmm_files]

А также загружаем имена моделей (это наши теги):

speakers   = [fname.split("/")[-1].split(".gmm")[0] for fname                   in gmm_files]

Загруженный аудиофайл, для которого нужно поставить тег, векторизуется и предобрабатывается. Далее каждый фрагмент с речью в нем сравнивается с обученными моделями и определяется победитель c точки зрения максимума логарифма правдоподобия:

log_likelihood = np.zeros(len(models)) #начальный пустой вектор правдоподобий          for i in range(len(models)):             gmm    = models[i]  #сравнение с каждой моделью             scores = np.array(gmm.score(vector))             log_likelihood[i] = scores.sum() #итоговое правдоподобие i модели – сумма правдоподобий          winner = np.argmax(log_likelihood) # определяем победителя print("\tdetected as - ", speakers[winner])

В итоге наш алгоритм имеет примерно следующий вывод:

starts in: 1.92 ends in: 8.72
[-10400.93604115 -12111.38278205]
detected as — Olga
starts in: 9.22 ends in: 15.72
[-10193.80504138 -11911.11095894]
detected as — Olga
starts in: 26.7 ends in: 29.82
[-4867.97641331 -5506.44233563]
detected as — Ivan
starts in: 33.34 ends in: 47.14
[-21143.02629011 -24796.44582627]
detected as — Ivan
starts in: 52.56 ends in: 59.24
[-10916.83282132 -12124.26855538]
detected as — Olga
starts in: 116.32 ends in: 134.56
[-36764.94876054 -34810.38959083]
detected as — Olga
starts in: 151.18 ends in: 154.86
[-8041.33666572 -6859.14253903]
detected as — Olga
starts in: 159.7 ends in: 162.92
[-6421.72235531 -5983.90538059]
detected as — Olga
starts in: 185.02 ends in: 208.7
…
starts in: 442.04 ends in: 445.5
[-7451.0289772 -6286.66194982]
detected as – Olga
*******
WINNER — Olga

В данном примере предполагается, что есть по крайней мере 2 класса – [ Olga, Ivan]. Аудиофайл разрезан на сегменты [1.92, 8.72], [9.22, 15.72], …, [442.04, 445.5] и для каждого из сегментов определяется наиболее подходящая модель.

Суммарный логарифм правдоподобия указан в скобках рядом с каждым фрагментом: [-10400.93604115 -12111.38278205], первый элемент – правдоподобие Olga, а второй – Ivan. Так как первый аргумент больше второго, то данный сегмент классифицирован как Olga. Итоговый победитель определяется по большинству «голосов» фрагментов.

Результаты

Изначально мы проектировали алгоритм из предположения, что во входящих звонках может присутствовать «неизвестный» менеджер – то есть такой, что его модель не присутствует обучающей выборке.

Чтобы детектировать такого пользователя, нам требуется ввести некоторую метрику на векторе log_likelihood. Такую, что определенные ее значения будут указывать на то, что скорее всего этот фрагмент не описывается адекватно ни одной из существующих моделей. В качестве теста мы предложили следующую метрику:

Leukl=(log_likelihood-np.min(log_likelihood))/(np.max(log_likelihood)-np.min(log_likelihood)) -sorted(-np.array(Leukl))[1]<T

Данная величина указывает, насколько «равномерно» распределены оценки в векторе log_likelihood. Равномерность оценок (их близость друг к другу) обозначает, что все модели ведут себя одинаково и явного лидера нет.

Это говорит о том, что скорее всего все модели ошибаются и перед нами менеджер, который не был на этапе обучения. Зависимость между T и качеством классификации представлено на рисунках.

Рис. 1.
а) Точность бинарной классификации известных и неизвестных менеджеров.
б) Точность классификация известных менеджеров.

Рис. 2.
а) Доля известных менеджеров, определенных к классу известных.
б) Доля неизвестных менеджеров, определенных к классу известных.

Рис. 3.
а) Доля неизвестных менеджеров, определенных к классу неизвестных.
б) Доля известных менеджеров, определенных к классу неизвестных.

Рис. 4.
а) Полнота бинарной классификации (recall).
б) Точность бинарной классификации (precision).

Зависимость между величиной порога T и качеством классификации (тегирования) очевидна. Чем больше T (более строгие условия на отнесение менеджера к классу неизвестных), тем меньше вероятность отнести известного менеджера к классу неизвестных. Но при этом больше вероятность «пропустить» неизвестного менеджера.

Оптимальным значением порога является величина 0.8. Потому что мы классифицируем известных менеджеров с точностью около 90% и определяем «неизвестных» с точностью 81%. Если же допустить, что все менеджеры нам «знакомы», то точность будет порядка 98%.

Выводы

В статье мы описали общие идеи функционирования нашего инструмента по определению менеджеров в звонках. Конечно, мы не претендуем на то, что наш алгоритм оптимален и не способен улучшаться.

Он основан на ряде предположений, которые не всегда выполняются на практике. Например, можем столкнуться с неизвестным менеджером в том случае, если данные о нем нет. Или же два и более менеджеров могут вести беседу с клиентом «в равных долях». С точки зрения алгоритма, можно предложить следующие направления для дальнейших улучшений:

• Выбор другой модели алгоритма, отличной от GMM
• Оптимизация параметров GMM
• Выбор другой метрики детектирования нового менеджера
• Поиск наиболее значимых фич речевого сигнала
• Комбинация различных средств предварительной обработки аудио и оптимизация параметров этих методов

Перевод статьи подготовлен в преддверии старта курса «Промышленный ML на больших данных»

---

Amazon SageMaker дает не просто возможность управлять notebook-ами в Jupyter, а предоставляет конфигурируемый сервис, который позволяет создавать, обучать, оптимизировать и разворачивать модели машинного обучения. Распространённое заблуждение особенно в начале работы с SageMaker заключается в том, что для использование этих сервисов вам нужен SageMaker Notebook Instance или SageMaker (Studio) Notebook. На самом деле вы можете запустить все сервисы непосредственно с вашего локального компьютера или даже вашей любимой IDE.

Прежде чем мы пойдем дальше, давайте разберемся как взаимодействовать с сервисами Amazon SageMaker. У вас есть два API:

SageMaker Python SDK – высокоуровневый API на Python, который абстрагирует код для построения, обучения и развертывания моделей машинного обучения. В частности, он предоставляет оценщиков для алгоритмов первого класса или встроенных алгоритмов, а также поддерживает фреймворки, такие как TensorFlow, MXNET и т.д. В большинстве случаев вы будете использовать его для взаимодействия с интерактивными задачами машинного обучения.

AWS SDK – это низкоуровневый API, который используется для взаимодействия со всеми поддерживаемыми сервисами AWS не обязательно для SageMaker. AWS SDK доступен для большинства популярных языков, таких как Java, Javascript, Python (boto) и т.д. В большинстве случаев вы будете использовать этот API для таких вещей, как создание ресурсов для автоматизации или взаимодействия с другими сервисами AWS, которые не поддерживаются SageMaker Python SDK.

Почему локальная среда?

Стоимость – это первое, что приходит в голову, но также немаловажную роль играет гибкость использования вашей родной IDE и возможность работать в автономном режиме и запускать задачи в облаке AWS по готовности.

Как работает локальная среда

Вы пишите код для построения модели, но вместо экземпляра SageMake Notebook или SageMaker Studio Notebook вы делаете это на своей локальной машине в Jupyter или из своей IDE. Затем, когда все готово, вы начнете обучение на экземплярах SageMaker на AWS. После обучения модель будет храниться в AWS. Затем можно запустить развертывание или пакетное преобразование с локальной машины.

Настройка среды с помощью conda

Рекомендуется настроить виртуальную среду Python. В нашем случае мы будем использовать conda для управления виртуальными средами, но вы можете воспользоваться virtualenv. Опять же Amazon SageMaker использует conda для управления средами и пакетами. Предполагается, что у вас уже установлена conda, если нет – то вам сюда.

Создаем новую среду conda

conda create -n sagemaker python=3

Активируем и верифицируем среду

Устанавливаем необходимые пакеты

Чтобы установить пакеты, воспользуйтесь командами conda или pip. Выберем вариант с conda.

conda install -y pandas numpy matplotlib

Устанавливаем пакеты AWS

Установим AWS SDK для Python (boto), awscli и SageMaker Python SDK. SageMaker Python SDK недоступен в качестве пакета conda, поэтому тут просто воспользуемся pip.

pip install boto3 awscli sagemaker

Если вы впервые используете awscli, вам нужно его настроить. Здесь вы можете посмотреть, как это сделать.

По умолчанию будет установлена вторая версия SageMaker Python SDK. Обязательно проверьте наличие критических изменений во второй версии SDK.

Устанавливаем Jupyter и создаем ядро

conda install -c conda-forge jupyterlab python -m ipykernel install --user --name sagemaker

Верифицируем среду и проверяем версии

Запустите Jupyter через jupyter lab и выберите ядро sagemaker, которое мы создали выше.

Затем проверьте версии в notebook и убедитесь, что это именно те, которые нужны.

Создаем и обучаем

Теперь вы можете начать создавать свою модель локально и начать обучение на AWS, когда будете готовы.

Импортируем пакеты

Импортируйте необходимые пакеты и укажите роль. Ключевое отличие здесь заключается в том, что нужно указать напрямую arn роли, а не get_execution_role(). Поскольку вы запускаете все с локального компьютера с учетными данными AWS, а не экземпляр notebook с ролью, функция get_execution_role() работать не будет.

from sagemaker import image_uris # Use image_uris instead of get_image_uri from sagemaker import TrainingInput  # Use instead of sagemaker.session.s3_input region = boto3.Session().region_name container = image_uris.retrieve('image-classification',region) bucket= 'your-bucket-name' prefix = 'output' SageMakerRole='arn:aws:iam::xxxxxxxxxx:role/service-role/AmazonSageMaker-ExecutionRole-20191208T093742'

Создаем оценщик

Создайте оценщик и установите гиперпараметры как вы делаете это обычно. В приведенном ниже примере мы обучаем классификатор изображений с использованием встроенного алгоритма классификации изображений. Также вы указываете тип экземпляра Stagemaker и количество экземпляров, которые вы хотите использовать для обучения.

s3_output_location = 's3://{}/output'.format(bucket, prefix) classifier = sagemaker.estimator.Estimator(container,                                           role=SageMakerRole,                                          instance_count=1,                                           instance_type='ml.p2.xlarge',                                          volume_size = 50,                                          max_run = 360000,                                          input_mode= 'File',                                          output_path=s3_output_location)  classifier.set_hyperparameters(num_layers=152,                              use_pretrained_model=0,                              image_shape = "3,224,224",                              num_classes=2,                              mini_batch_size=32,                              epochs=30,                              learning_rate=0.01,                              num_training_samples=963,                              precision_dtype='float32') 

Каналы обучения

Укажите каналы обучения так, как вы делаете это всегда, тут тоже нет никаких изменений по сравнению с тем, как вы сделали бы это на своем экземпляре notebook.

train_data = TrainingInput(s3train, distribution='FullyReplicated',                          content_type='application/x-image', s3_data_type='S3Prefix') validation_data = TrainingInput(s3validation, distribution='FullyReplicated',                               content_type='application/x-image', s3_data_type='S3Prefix') train_data_lst = TrainingInput(s3train_lst, distribution='FullyReplicated',                          content_type='application/x-image', s3_data_type='S3Prefix') validation_data_lst = TrainingInput(s3validation_lst, distribution='FullyReplicated',                               content_type='application/x-image', s3_data_type='S3Prefix')  data_channels = {'train': train_data, 'validation': validation_data,                   'train_lst': train_data_lst, 'validation_lst': validation_data_lst}

Начинаем обучение

Начните задачу по обучению на SageMaker, вызвав метод fit, который начнет обучение на экземплярах SageMaker AWS.

classifier.fit(inputs=data_channels, logs=True)

Вы можете проверить статус задач обучения с помощью list-training-jobs.

Вот и все. Сегодня мы разобрались с тем, как локально настроить среду SageMaker и собрать модели машинного обучения на локальной машине с помощью Jupyter. Помимо Jupyter вы можете сделать то же самое из собственной IDE.
Удачного обучения!

Идея использовать дрон для обеспечения безопасности вашего дома может показаться клёвой – но перевешивают ли преимущества все недостатки?

На этой неделе подразделение Amazon, компания Ring, занимающаяся товарами для «умного дома», объявила о выпуске Always Home Cam – системы «домашней безопасности следующего уровня», представляющей собой небольшой автономный дрон. Он будет стоить $250 и интегрироваться с остальными решениями Ring для домашней безопасности – оборудованием и программным обеспечением. Технологически это впечатляющая штука, однако, вам она почти наверняка не понадобится.

Я честно не понимаю, почему этот ненастоящий вор разволновался из-за наличия дрона Ring сильнее, чем если бы он увидел в доме камеры. Дрон-то ничего не может сделать, а его можно просто сбить ударом. Ну, это всё же реклама для запуска продукта.

Пока Ring не сообщила подробности о дроне, но кое-что мы можем понять и сами. Думаю, что сверху у дрона находится планарный лидар, который он использует для ориентирования, а также снизу есть камера, смотрящая вниз. В Ring говорят, что в приложении нужно будет предварительно разметить те территории, по которым должен летать дрон, и это рабочий подход, поскольку ваш дом по большей части не меняется. Также приятно, что не нужно беспокоиться о погоде, а минимальное время работы от аккумулятора не имеет особого значения, потому что летать очень далеко не надо, и док-станция для перезарядки всегда находится поблизости. Мне нравится, что пользователь может направлять дрон только на определённые точки по пути, и ему не надо управлять дроном непосредственно – в зависимости от того, как ведёт себя дрон в воздухе, это может помочь избежать аварий. В Ring также пишут, что дрон «разработан с учётом заботы о конфиденциальности, поэтому его моторы гудят во время полёта» – заявление смехотворное, поскольку моторы и так гудят во время полёта, это же дрон.

Реалистичный ли это продукт? Да, не вижу проблем. Судя по всему, он справится с объявленными задачами, с учётом некоторых, пока не разглашаемых ограничений. Идея хорошая, но надо ли вам покупать этот продукт? Лично я бы не рекомендовал. Мой скептицизм основан на нескольких факторах. Первый вопрос к потребительскому роботу, который должен приносить пользу – не делает ли он просто более модным и прикольным способом то, что можно сделать проще, надёжнее и дешевле при помощи более распространённых систем. В данном случае мы можем сравнить этот дрон с сетью камер внутреннего наблюдения.

Сегодня можно купить неплохую камеру наблюдения всего за $25, а подключить их и настроить – задача обычно простая. Поэтому по цене одного дрона от Ring можно купить десяток камер. Камеры статичные (хотя можно доплатить, и получить подвижные), что означает, что дрон может обозревать больший процент дома, чем камеры. Однако на самом деле, спросить стоит вот что: могут ли несколько камер покрыть все те части вашего дома, которые имеют значение для вас? В моей (признаюсь, маленькой) квартире одна статическая камера покрывает большую часть гостиной, входную дверь и лестницу, ведущую в офис. Одна моя камера не может сразу заглядывать на кухню, в спальню или в офис так, как это мог бы сделать дрон Ring, но если мне очень захотелось бы отслеживать эти помещения, я купил бы ещё три камеры, и у меня ещё осталось бы $150. Конечно, остались бы какие-то уголки, куда дрон может заглянуть лучше, однако не могу себе представить, зачем бы мне понадобилось срочно заглядывать в них удалённо.

Для более крупных домов масштабы будут другими, и в какой-то момент по стоимости камер вы, возможно, сравняетесь с дроном. Однако я утверждаю, что с точки зрения безопасности (а этот дрон, судя по всему, нужен только для безопасности), по полезности дрон и близко не дотягивает до статичных камер. Камеры дают непрерывное наблюдение, дрон лишь обеспечивает реактивное. Если камера обнаружит движение, она может сразу дать вам знать и отправить вам кадры этого события, а также кадры, сделанные незадолго до его наступление и после того, как оно произошло. Дрон вовсе не так эффективен – ему придётся запуститься, долететь до места назначения, он должен перезаряжаться, и может быть только в одном месте одновременно.

Второй важный вопрос, который стоит задать по поводу любого робота, особенно с камерой – перевешивают ли преимущества этой системы её недостатки. Далее мы разберём аргументы в пользу того, почему автономная камера безопасности, подключённая к интернету – это кошмар с точки зрения конфиденциальности. Но сперва необходимо указать на, возможно, значительное преимущество дрона от Ring перед привычными статическими камерами в области конфиденциальности. В случае с дроном вы всегда знаете, когда и где он ведёт запись – поскольку он шумит и мешается. Большинство же статических камер обычно включены постоянно, и сложно быть уверенным в том, что то, что они видят, остаётся конфиденциальным. Если дрон не летает и не шумит, вряд ли его можно использовать для того, чтобы подглядывать за вами без вашего ведома. И если вы не хотели бы устанавливать постоянную камеру, например, в спальне, но хотели бы иметь возможность присматривать за ней в отъезде, то подобная мобильная система дала бы вам такую возможность – главное, не забыть оставить дверь в спальню открытой.

Но это потенциальное преимущество в конфиденциальности несёт в себе и возможные риски, говорит Райан Кало, адъюнкт-профессор из Юридической школы вашингтонского университета в Сиэтле. «Неподвижных камер можно избежать, а мобильных – не получится, поэтому ребёнок, супруг или сосед могут и не суметь избавиться от такой камеры», — поясняет он. Это не особенность одного лишь дрона от Ring – однако, так или иначе, всё же Ring одной из первых начала предлагать специального мобильного робота для слежки. «Если мобильное наблюдение станет нормой, — добавляет он, — меня беспокоит, что эта технология облегчит любителям вторгаться в личную жизнь слежку за своим партнёром где угодно, устранит слепые пятна камер и обесценит отговорку о том, что тот, за кем наблюдали, просто не попал на камеры. Иначе говоря, Ring предлагает возможность подсматривать без ограничений. Но подсматривание, как известно – это часть домашнего насилия».

В некотором смысле дрон от Ring похож на робота удалённого присутствия – некто может попасть в ваше личное пространство, находясь где угодно, на уровне физической активности, уникальном для роботов. Потенциал для приставаний в данном случае гораздо выше, чем у систем, способных видеть, но не двигаться. От дрона можно избавиться, накрыв его одеялком или чем-то ещё, а также просто закрыть дверь – но вы не должны попадать в такую ситуацию в собственном доме.

У компании Ring и её родительской Amazon также отсутствует большой опыт в области безопасности и конфиденциальности. При этом ваши данные могут попасть не только к хакерам – Ring особенно подчёркивала тесные связи с органами правопорядка. Как написано в июльской статье в EFF, «имея ордер, полиция может обойти владельца устройства и получить записи прямо от компании Amazon, даже если владелец этого не хочет». В статье говорится о записях с видеозвонка от Ring, однако непонятно, почему дрон Ring может стать исключением из этих правил.

Также дрон может дать Amazon ещё больше возможностей по сбору данных о его владельце – но теперь уже с мобильной платформы, способной летать по дому и даже выглядывать из окон. «Он помогает Amazon создать вашего цифрового двойника», — говорит Джули Карпентер, научный сотрудник по этике и новым наукам Калифорнийского политехнического государственного университета. «Они используют подобные данные о пользователях, чтобы создавать их цифровые версии в базах данных, а потом использовать для продажи им разных товаров. Собираемые данные всё сильнее нарушают конфиденциальность пользователей, а с возможностями дрона от Ring появляются такие способы сбора, как построение плана вашего дома, запись поведения владельца и членов его семьи на аудио и видео в спальнях, ванных комнатах – везде, где вы живёте».

Открывая доступ подключённым к интернету камерам безопасности в свой дом, вы уже рискуете конфиденциальностью. Многие люди считают, что этот риск стоит той безопасности и спокойствия, которую они получают. Однако если изучить преимущества дрона от Ring перед камерами безопасности, то дополнительные риски для конфиденциальности, порождаемые автономной мобильной камерой, оправдать уже очень трудно. Технология, конечно, впечатляющая, и идея автономного домашнего дрона получилась очень крутой. Но стоит ли он $250, стоит ли того непонятное увеличение безопасности по сравнению со статичными камерами и явное увеличение возможностей неправомерного использования? Что-то я не уверен.

Представьте себе картину: утро, контакт-центр, удаленка. Несколько тысяч сотрудников открыли ноутбуки за чашечкой кофе и не смогли авторизоваться в рабочей системе. Кто-то увидел в профиле девичью фамилию, кто-то – предыдущую должность, а по спинам некоторых руководителей пробежал холодок.

В обычной ситуации, волна осознания проблемы шла бы по офису быстрее чувства тревоги. Но в условиях изоляции сотрудникам в голову лезли невеселые мысли. Не потерял ли я работу из-за подкравшегося кризиса? Могли ли меня понизить в должности без моего согласия? В общем, многое из нажитого непосильном трудом вдруг пропало.

Я занимаюсь сервисным обслуживанием контакт-центров клиентов в КРОК. И подобных историй за время карантина (да и без него) случалось немало. Чем все закончилось и как мы перевели на удаленку несколько десятков контактных центров, расскажу под катом.

К счастью для многих, то была не полярная лисица, а только сурок.

Получив сигнал от заказчика, наша сервисная команда, останавливающая и не таких «зверей» и «призраков прошлого», поспешила на помощь. В течение часа мы выяснили, что произошел откат на четыре года назад: отобразились пользовательские данные за 2016 год. Скорее всего, кто-то из админов заказчика промахнулся кнопкой, когда хотел проверить экспорт пользовательской иерархии, и нажал импорт. Как итог:

— часть пользователей не могли авторизоваться,
— появились сотрудники «призраки», давно не работающие в компании,
— часть авторизовались под девичьей фамилией,
— часть с более низкими ролями (прошлые должности),
— добавочные номера неверно определялись у пользователей

Повезло, что в день X перед инцидентом был создан бэкап. Это к слову, зачем выполнять рекомендации вендора и сервисного партнера по настройке автоматического бэкапа. Не настроили бы, остались бы жить в 2016-м.

Всё проверив и сказав «поехали», мы «выдали обратно замуж» несколько сотен операторов, вернули на место «уволенных», восстановили порядок в рядах руководителей. Так, оставшись один на один с цифровой экосистемой, труженики контакт-центра отправились на 4 года в прошлое и вернулись обратно за один час.

Перевод операторов на удаленку. Начало

На самом деле, в жизни системного инженера не так уж много романтики. Он владеет всем известными техниками ведения боя, постоянно комбинируя их во время схватки с сетевыми инцидентами. И, как оказалось, может возвращать людей к жизни в матрице.

Но люди, которые оказались в изоляции подключенными к офису, не чувствовали себя под тотальным контролем восставшей машины времени, подчиняющей людей своей воле. Каждый день они вникают в проблемы клиентов, их работа про человеческое общение, эмпатию и эмоции. Нашей же задачей было создать для них ответную атмосферу, решая их технические проблемы и принимая технологические вызовы на себя.

Конечно, в начале всей этой истории с пандемией самым главным было максимально быстро (aka пара дней) и без потерь рассадить всех по домам и дать возможность работать основному персоналу.

Благо, технологии были готовы к переходу на удаленку.

В современных ИТ-системах контактных центров, которые мы десятками перевели на хоум-офис, почти всегда была заложена необходимая гибкость, масштабируемость и возможность работать в мире без границ. IP-телефония, как никак.

Сам переезд – процесс понятный. Пользователь оставляет свой хардфон в офисе, а business casual одежду вешает в шкаф. На смену им приходят софтфон, VPN-мост в локальную сеть офиса, VDI и домашние тапочки.

Инженер перелопачивает пул сетей, делает настройки, переключает записи голоса и экрана на обновленную логику. Конечно, не всё тут всегда гладко. Бывает, что количество сыплющихся инцидентов на единицу времени зашкаливает за все разумные пределы. Но N лет опыта позволяют останавливать тикет на лету, даже если начинается шквальный огонь.

Да, конечно, мы будем очень осторожными.

После бури. Тюнинг системы записи экрана

Когда все выдохнули и уютно устроились в своих домашних коворкингах, мы спокойно занялись тюнингом. Что донастраивали? Если вы когда-либо погружались в бэк-энд колл-центра, то знаете, что у операторов во время звонка происходит запись голоса и запись экрана специальным рекордером. Записи сохраняются для аналитики и менеджмента качества. Когда операторы работают в офисе, аппаратная среда унифицирована. При работе из дома возможны самые необычные варианты устройств. Одни работают с лэптопа, другие с двух мониторов, кто-то расслабился немножко и не хочет работать – всех по-прежнему нужно записать.

Если запись голоса не нуждается в тюнинге (мы просто добавили пул подсетей VPN в мониторинг рекордера), то с экранами всё было интереснее. Не каждый заказчик использовал VDI, поэтому, отделаться обновлением адресов устройств было невозможно. И мы внедрили профили записи экрана «на каждый день». Например, в случае медленного интернета или слабого ПК, мы записывали оператора в чёрно-белой палитре и с высоким уровнем компрессии. Для двух мониторов был отдельный профиль, который захватывал изображение с двух устройств. А если хочешь, чтобы супервизор видел в тебе не только агента, но и видеоблогера, пожалуйста – мы запишем тебя в Full-HD, mpeg-4 и с высокой частотой генерации ключевых кадров (нет, это не 60 fps, что – спрашивайте в комментах). И все эти настройки профилей можно комбинировать и модифицировать – пространство вариантов действительно обширное.

Что дальше?

Весь процесс перевода на удаленку можно обрисовать с помощью тройной схемы «было – стало – стало после тюнинга».

Было

Стало

Стало после тюнинга

В итоге получилась универсальная система записи, которая работает как для удаленки, так и для доковидного офиса. Вернуться в офисные будни такая система может за день. Произошедшее подтвердило мысль о том, что домашний контакт-центр имеет право на существование: это ценная альтернатива традиционному офисному формату. С точки зрения технологий проблем нет, с социальной точки зрения называть это панацеей не стану. Человеку нужно чувствовать. Не стану предсказывать, чем всё кончится. Но скажу, что не стоит бояться перемен: делаем бэкапы и вперёд!