Експлуатація машинного навчання в Mail.ru

За мотивами моїх виступів на Highload++ та DataFest Minsk 2019 р.

Для багатьох сьогодні пошта є невід'ємною частиною життя у мережі. З її допомогою ми ведемо бізнес-листування, зберігаємо різноманітну важливу інформацію, пов'язану з фінансами, бронюванням готелів, оформленням замовлень та багатьом іншим. У середині 2018 року ми сформулювали продуктову стратегію розвитку пошти. Якою ж має бути сучасна пошта?

Пошта має бути розумний, тобто допомагати користувачам орієнтуватися в обсязі інформації, що збільшується: фільтрувати, структурувати і надавати її найбільш зручним способом. Вона повинна бути корисний, дозволяючи прямо в поштовій скриньці вирішувати різні завдання, наприклад, оплачувати штрафи (функція, якою я, на жаль, користуюся). І при цьому, зрозуміло, пошта має забезпечувати інформаційний захист, відсікаючи спам та захищаючи від зломів, тобто бути безпечної.

Ці напрями визначають ряд ключових завдань, багато з яких може бути ефективно вирішено за допомогою машинного навчання. Ось приклади фіч, що вже діють, розроблених у рамках стратегії — по одному на кожен напрям.

• Смарт Відповідь. У пошті є функція розумної відповіді. Нейросеть аналізує текст листа, розуміє його зміст і ціль, і в результаті пропонує три найбільш відповідні варіанти відповіді: позитивний, негативний і нейтральний. Це допомагає суттєво економити час при відповідях на листи, а також часто відповідати нестандартно та кумедно для себе.
• Угруповання листів, що стосуються замовлень в інтернет-магазинах. Ми часто робимо покупки в інтернеті, і, як правило, магазини можуть надсилати по кілька листів на кожне замовлення. Наприклад, від АліЕкспреса, найбільшого сервісу, надходить дуже багато листів за одним замовленням, і ми порахували, що в термінальному випадку їх кількість може сягати 29. Тому за допомогою моделі Named Entity Recognition ми виділяємо номер замовлення та іншу інформацію з тексту та групуємо всі листи за одну тред. Також показуємо основну інформацію про замовлення в окремій плашці, що полегшує роботу з цим типом листів.

  

• Антифішинг. Фішинг - особливо небезпечний шахрайський тип листів, за допомогою якого зловмисники намагаються заволодіти фінансовою інформацією (у тому числі про банківські картки користувача) та логінами. Такі листи мімікрують під справжні, розіслані сервісом, зокрема візуально. Тому за допомогою Computer Vision ми розпізнаємо логотипи та стиль оформлення листів великих компаній (наприклад, Mail.ru, Сбер, Альфа) та враховуємо це поряд із текстом та іншими ознаками у наших класифікаторах спаму та фішингу.

машинне навчання

Трохи про машинне навчання поштою в цілому. Пошта – високонавантажена система: через наші сервери проходить в середньому по 1,5 млрд листів на добу для 30 млн користувачів DAU. Обслуговують усі необхідні функції та фічі близько 30 систем машинного навчання.

Кожен лист проходить цілий конвеєр класифікації. Спочатку ми відсікаємо спам і залишаємо гарні листи. Користувачі часто не помічають роботу антиспаму, тому що 95-99% спаму не потрапляють навіть у відповідну папку. Розпізнавання спаму - дуже важлива частина нашої системи, і найскладніша, оскільки у сфері антиспаму йде постійна адаптація між системами захисту та атаки, що постачає безперервний інженерний челенж для нашої команди.

Далі поділяємо листи від людей та роботів. Листи від людей найбільш важливі, тому ми надаємо функції типу Smart Reply. Листи від роботів поділяються на дві частини: транзакційні — це важливі листи від сервісів, наприклад, підтвердження покупок або броні готелю, фінанси та інформаційні — це бізнес-реклама, знижки.

Ми вважаємо, що транзакційні листи за значимістю дорівнюють особистому листуванню. Вони повинні бути під рукою, оскільки часто буває потрібно швидко знайти інформацію про замовлення або броню авіаквитка, а ми витрачаємо час на пошук цих листів. Тому ми для зручності автоматично ділимо їх на шість основних категорій: подорожі, замовлення, фінанси, квитки, реєстрацію та, нарешті, штрафи.

Інформаційні листи — найчисленніша і, мабуть, менш важлива група, яка не вимагає миттєвої реакції, оскільки нічого істотного не зміниться в житті користувача, якщо він не прочитає такого листа. У нашому новому інтерфейсі ми згортаємо їх у два треди: соцмережі та розсилки, таким чином візуально очищуючи ящик і залишаючи на увазі лише важливі листи.

Експлуатація

Велика кількість систем завдає чимало труднощів в експлуатації. Адже моделі згодом деградують, як і будь-який софт: ламаються ознаки, відмовляють машини, накочується кривий код. До того ж постійно змінюються дані: додаються нові, трансформується патерн поведінки користувачів тощо, тому модель без належної підтримки з часом працюватиме все гірше та гірше.

Не можна забувати і про те, що чим глибше машинне навчання проникає в життя користувачів, тим більше впливають вони на екосистему, і, як наслідок, тим більше фінансових втрат або профіту можуть отримати гравці ринку. Тому в дедалі більшій кількості областей гравці адаптуються до роботи ML-алгоритмів (класичні приклади - реклама, пошук і вже згаданий антиспам).

Також завдання машинного навчання мають особливість: будь-яка, хай і незначна, зміна в системі може породити багато роботи з моделлю: робота з даними, перенавчання, деплой, що може затягтися на тижні або місяці. Тому чим швидше змінюється середовище, в якому оперують ваші моделі, тим більше зусиль вимагає їхньої підтримки. Команда може створити безліч систем і радіти з цього, а потім витрачати майже всі ресурси на їх підтримку, без можливості зробити щось нове. З такою ситуацією ми одного разу якось зіткнулися в команді антиспаму. І зробили очевидний висновок, що супровід треба автоматизувати.

Автоматизація

Що можна автоматизувати? Насправді майже все. Я виділив чотири напрямки, що визначають інфраструктуру машинного навчання:

• збір даних;
• донавчання;
• деплою;
• тестування & моніторингу.

Якщо середовище нестійке і постійно змінюється, то вся інфраструктура навколо моделі виявляється набагато важливішою за саму модель. Це може бути старий добрий лінійний класифікатор, але якщо в нього правильно подати ознаки і налагодити хороший зворотний зв'язок від користувачів, він буде працювати набагато краще, ніж State-Of-The-Art-моделі з усіма наворотами.

Цикл зворотного зв'язку

Цей цикл поєднує в собі збір даних, донавчання та деплою — по суті весь цикл оновлення моделі. Чому це важливо? Подивіться на графік реєстрації в пошті:

Розробник машинного навчання впровадив модель антибота, яка дозволяє ботам реєструватися в пошті. Графік падає до значення, де залишаються лише реальні користувачі. Все чудово! Але минає чотири години, ботоводи підкручують свої скрипти, і все повертається на свої кола. У цьому впровадженні розробник витратив місяць, додаючи ознаки та донавчаючи модель, але спамер за чотири години зміг адаптуватися.

Щоб не було так болісно і не довелося потім все переробляти, треба спочатку думати про те, як виглядатиме цикл зворотного зв'язку, і що ми робитимемо, якщо середа зміниться. Почнемо зі збору даних – це паливо для наших алгоритмів.

Збір даних

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

Одна з найчастіших помилок (тут я роблю референс на Andrew Ng) — надто сильна орієнтація на метрики на тестовому датасеті, а не зворотний від користувача, що насправді є головним мірилом якості роботи, оскільки ми створюємо продукт для користувача. Якщо користувачеві незрозуміла або не подобається робота моделі, значить все тлін.

Тому користувач завжди повинен мати можливість проголосувати, слід дати йому інструмент зворотного зв'язку. Якщо ми вважаємо, що в ящик прийшов лист, що стосується фінансів, треба його позначити «фінанси», і намалювати кнопку, яку користувач може натиснути і сказати, що це не фінанси.

Якість зворотнього зв'язку

Поговоримо про якість фідбека користувача. По-перше, ви з користувачем можете вкладати різне значення в одне поняття. Наприклад, ви з продакт-менеджерами вважаєте, що «фінанси» — це листи з банку, а користувач вважає, що лист від бабусі про пенсію також належить до фінансів. По-друге, є користувачі, які бездумно люблять натискати на кнопки без жодної логіки. По-третє, користувач може глибоко помилятися у своїх висновках. Яскравий приклад нашої практики — впровадження класифікатора нігерійського спаму, дуже смішного типу спаму, коли користувачеві пропонується забрати кілька мільйонів доларів у раптово знайденого далекого родича в Африці. Після впровадження даного класифікатора ми перевірили кліки «Не спам» на ці листи, і виявилося, що 80% із них — соковитий нігерійський спам, що говорить про те, що користувачі можуть бути довірливими.

І не забуватимемо, що по кнопках можуть тикати не тільки люди, але й всякі боти, які прикидаються браузером. Отже, сирий зворотний зв'язок не годиться для навчання. Що можна зробити із цією інформацією?

Ми застосовуємо два підходи:

• Фідбек від зв'язаного ML. Наприклад, у нас є онлайн-система антибота, яка, як я вже згадував, ухвалює швидке рішення на основі обмеженої кількості ознак. І є друга, повільна система, яка постфактум працює. Вона має більше даних про користувача, його поведінку і т.д. Як наслідок, приймається найбільш виважене рішення, відповідно вона має вищу точність та повноту. Можна спрямувати різницю роботи цих систем у першу дані для навчання. Таким чином, простіша система завжди намагатиметься наблизитися до перформансу складнішою.
• Класифікація кліків. Можна просто класифікувати кожен клік користувача, оцінювати його валідність та можливість використання. Ми так робимо в антиспамі пошти, використовуючи ознаки користувача, його історію, ознаки відправника, сам текст та результат роботи класифікаторів. У результаті отримуємо автоматичну систему, яка валідує фідбек користувача. І оскільки її треба донавчати істотно рідше, її робота може стати основною для всіх інших систем. Основний пріоритет у цій моделі має precision, тому що навчати модель на неточних даних загрожує наслідками.

Поки ми чистимо дані та донавчаємо наші ML-системи, не можна забувати про користувачів, адже для нас тисячі, мільйони помилок на графіку – це статистика, а для користувача кожен баг – трагедія. Крім того, що користувачеві треба якось жити з вашою помилкою в продукті, він після зворотного зв'язку чекає на виключення подібної ситуації в майбутньому. Тому варто завжди давати користувачам не тільки можливість голосувати, але й виправляти поведінку ML-систем, створюючи, наприклад, персональні евристики на кожен клік зворотного зв'язку, у разі пошти це може бути можливість фільтрувати подібні листи по відправнику і заголовку для цього користувача.

Також потрібно на основі яких-небудь звітів або звернень у саппорт в напівавтоматичному або ручному режимі мити модель, щоб інші користувачі теж не страждали від схожих проблем.

Евристики для навчання

З цими евристиками та милицями є дві проблеми. Перша полягає в тому, що кількість милиць, що постійно зростає, важко підтримувати, не кажучи вже про їх якість і роботу на довгій дистанції. Друга проблема полягає в тому, що помилка може бути не частотною, і кількох кліків для донавчання моделі буде недостатньо. Здавалося б, ці два не пов'язані ефекти можна суттєво нівелювати, якщо застосувати наступний підхід.

1. Створюємо тимчасову милицю.
2. Надсилаємо дані з нього в модель, вона регулярно доучується, у тому числі на отримані дані. Тут, зрозуміло, важливо, щоб евристика мала високу точність, щоб не знижувати якість даних у тренувальному сеті.
3. Потім вішаємо моніторинг на спрацьовування милиці, і якщо через якийсь час милиця більше не спрацює і повністю покривається моделлю, можна його сміливо видаляти. Тепер ця проблема навряд чи повториться.

Тож армія милиць дуже корисна. Головне, щоб їхня служба була терміновою, а не постійною.

Донавчання

Донавчання - це процес додавання нових даних, отриманих в результаті зворотного зв'язку від користувачів або інших систем, та навчання існуючої моделі на них. З донавчанням може бути кілька проблем:

1. Модель може просто не підтримувати навчання, а вчитися тільки з нуля.
2. Ніде у книзі природи не написано, що навчання неодмінно покращить якість роботи на продакшені. Часто трапляється якраз навпаки, тобто можливе лише погіршення.
3. Зміни можуть бути непередбачуваними. Це досить тонкий момент, який ми виявили собі. Навіть якщо нова модель в А/В-тесті показує схожі результати в порівнянні з поточною, це зовсім не означає, що вона працюватиме ідентично. Їхня робота може відрізнятися в якомусь одному відсотку, який може принести нові помилки або повернути вже виправлені старі. З поточними помилками як ми, так і користувачі вже вміємо жити, і коли виникає велика кількість нових помилок, користувач теж може не розуміти, що відбувається, адже він очікує передбачуваної поведінки.

Тому найголовніше у донавченні — це гарантовано покращувати модель, чи хоча б не погіршувати її.

Перше, що спадає на думку, коли ми говоримо про донавчання, це підхід Active Learning. Що це означає? Наприклад, класифікатор визначає, чи належить лист до фінансів, і навколо його межі ухвалення рішення ми додаємо вибірку із розмічених прикладів. Це добре працює, наприклад, у рекламі, де зворотного зв'язку дуже багато і можна навчати модель в онлайн-режимі. А якщо зворотного зв'язку мало, то ми отримуємо сильно зміщену вибірку щодо продакшень розподілу даних, на основі якої не можна оцінити поведінку моделі в процесі експлуатації.

Насправді наша мета – зберегти старі патерни, вже відомі моделі, та придбати нові. Тут важлива наступність. Модель, яку ми часто насилу викотили, вже працює, тому можемо орієнтуватися на її продуктивність.

У пошті використовуються різні моделі: дерева, лінійні, нейромережі. Для кожної робимо свій алгоритм донавчання. У процесі донавчання у нас з'являються не лише нові дані, а й часто нові ознаки, які ми враховуватимемо у всіх алгоритмах нижче.

Лінійні моделі

Допустимо, у нас логістична регресія. Складаємо лос моделі з наступних компонентів:

• LogLoss на нових даних;
• регуляризуємо ваги нових ознак (старі не чіпаємо);
• вчимося і на старих даних, щоб зберегти старі патерни;
• і, мабуть, найважливіше: навішуємо Harmonic Regularization, яка гарантує не сильну зміну ваг щодо старої моделі за нормою.

Оскільки кожен компонент Loss має коефіцієнти, ми можемо підібрати оптимальні для нашого завдання значення на крос-валідації або виходячи з продуктових вимог.

Дерева

Перейдемо до дерев рішень. Ми запилили наступний алгоритм донавчання дерев:

1. На проді працює ліс із 100—300 дерев, який навчено на старому дата-сеті.
2. Видаляємо наприкінці M = 5 штук і додаємо 2M = 10 нових, навчені на всьому дата-сеті, але з високою вагою нових даних, що натурально гарантує інкрементальну зміну моделі.

Очевидно, що згодом кількість дерев сильно збільшується, і їх треба періодично скорочувати, щоб вкладатись у таймінги. Для цього використовуємо всюдисущий нині Knowledge Distillation (KD). Коротко про принцип роботи.

1. Ми маємо поточну «складну» модель. Запускаємо її на тренувальному дата-сеті та отримуємо розподіл ймовірностей класів на виході.
2. Далі вчимо модель-учня (модель з меншою кількістю дерев у даному випадку) повторювати результати роботи моделі, використовуючи розподіл класів як цільову змінну.
3. Тут важливо зазначити, що ми не використовуємо розмітку дата-сета, і тому можемо використовувати довільні дані. Зрозуміло, ми використовуємо семпл даних з бойового потоку як навчальну вибірку для моделі учня. Таким чином, тренувальний сет дозволяє нам забезпечувати точність моделі, а семпл потоку гарантує схожий перформанс на продакшен-розподілі, компенсуючи усунення навчальної вибірки.

Поєднання цих двох методик (додавання дерев та періодичне скорочення їх кількості за допомогою Knowledge Distillation) забезпечує введення нових патернів та повну наступність.

За допомогою KD ми також виконуємо різницю операції з ознаками моделі, наприклад, видалення ознак і роботу на пропусках. У нашому випадку ми маємо низку важливих статистичних ознак (за відправниками, текстовими хешами, урлами тощо), які зберігаються в базі даних, що мають властивість відмовляти. До такого розвитку подій модель, зрозуміло, не готова, тому що в трейнінг-мережі не зустрічається ситуацій відмови. У подібних випадках ми поєднуємо техніки KD та аугментації: під час навчання для частини даних ми видаляємо або обнуляємо необхідні ознаки, а мітки (виходи поточної моделі) беремо початкові, модель-учень вчить повторювати цей розподіл.

Ми помітили, що чим серйозніша маніпуляція моделей відбувається, тим більше у відсотковому співвідношенні потрібна семла потоку.

Для видалення ознак, найпростішої операції, потрібно лише невелика частина потоку, оскільки змінюється лише пара ознак, а поточна модель навчалася тому ж сеті — різниця мінімальна. Для спрощення моделі (зниження кількості дерев у кілька разів) потрібно вже 50 на 50. А на перепустки важливих статистичних ознак, які серйозно афектять перфоманс моделі, потрібно ще більше потоку, щоб вирівняти роботу нової стійкої до перепусток моделі на всіх типах листів.

FastText

Перейдемо до FastText. Нагадаю, що уявлення (Embedding) слова складається із суми embedding'а самого слова та всіх його літерних N-gram, зазвичай триграм. Так як триграми може бути досить багато, використовується Bucket Hashing, тобто перетворення всього простору в якийсь фіксований хеш-меп. У результаті матриця ваг виходить розмірністю внутрішнього шару кількість слів + бакетів.

При донавчання виникають нові ознаки: слова та триграми. У стандартному донавченні від Facebook нічого суттєвого не відбувається. Довчаються лише старі ваги з крос-ентропією на нових даних. Таким чином, нові ознаки не використовуються, зрозуміло, цей підхід має всі вищеописані недоліки, пов'язані з непередбачуваністю моделі на продакшені. Тому ми трохи доопрацювали FastText. Додаємо все нові ваги (слова та триграми), доучуємо всю матрицю з крос-ентропією та додаємо гармонійну регуляризацію за аналогією з лінійною моделлю, яка гарантує несуттєву зміну старих ваг.

CNN

Із згортковими мережами дещо складніше. Якщо CNN доучуються останні верстви, то, зрозуміло, можна застосовувати гармонійну регуляризацию і гарантувати наступність. Але в тому випадку, якщо потрібно донавчання всієї мережі, то таку регуляризацію вже не навіси на всі шари. Однак є варіант із навчанням компліментарних ембеддингів через Triplet Loss (оригінальна стаття).

Втрата триплету

На прикладі завдання антифішингу розберемо загалом Triplet Loss. Беремо наш логотип, а також позитивні та негативні приклади логотипів інших компаній. Мінімізуємо відстань між першими та максимізуємо відстань між іншими, робимо це з невеликим зазором, щоб забезпечити більшу компактність класів.

Якщо ми донавчаємо мережу, то у нас повністю змінюється метричний простір, і він стає абсолютно несумісним із попереднім. Це серйозна проблема у завданнях, які використовують вектори. Щоб оминути цю проблему, підмішуватимемо під час навчання старі ембеддінги.

Ми додали нові дані до трейнінг-сету і з нуля навчаємо другу версію моделі. На другому етапі ми донавчаємо нашу мережу (Finetuning): спочатку доучується останній шар, а потім розморожується вся мережа. У процесі складання триплетів лише частину ембеддингів обчислюємо за допомогою моделі, що навчається, інші — за допомогою старої. Таким чином, у процесі навчання ми забезпечуємо сумісність метричних просторів v1 і v2. Своєрідний варіант гармонійної регуляризації.

Архітектура цілком

Якщо розглядати всю систему цілком на прикладі антиспаму, то моделі не ізольовані, а вкладені одна в одну. Беремо картинки, текст та інші ознаки, за допомогою CNN та Fast Text отримуємо ембеддінги. Далі поверх ембедінгів застосовуються класифікатори, які видають скори для різних класів (типи листів, спаму, наявність логотипу). Скори та ознаки вже потрапляють у ліс дерев на ухвалення фінального рішення. Окремі класифікатори в цій схемі дозволяють краще інтерпретувати результати роботи системи і більш прицільно донавчати компоненти у разі виникнення проблем, ніж у сирому вигляді подавати всі дані в дерева рішень.

У результаті гарантуємо наступність кожному рівні. На нижньому рівні CNN і Fast Text ми використовуємо гармонійну регуляризацию, для класифікаторів у середині — також гармонійну регуляризацию і калібрування швидка для сумісності розподілу ймовірності. Ну а бустинг дерев навчається інкрементально або за допомогою Knowledge Distillation.

В цілому підтримка такої вкладеної системи машинного навчання зазвичай становить біль, оскільки будь-який компонент на нижньому рівні веде до оновлення всієї системи вище. Але так як у нашому сетапі кожен компонент змінюється незначно і він сумісний з попереднім, то вся система може оновлюється по шматочках без потреби перенавчати всю структуру, що і дозволяє підтримувати її без серйозного верхівки.

Деплой

Ми розібрали збір даних та донавчання різних типів моделей, тому переходимо до їхнього деплою в продакшен середовище.

А/B-тестування

Як я говорив раніше, в процесі збору даних ми зазвичай отримуємо зміщену вибірку, за якою неможливо оцінити продакшен-перфоманс моделі. Тому при розгортанні модель обов'язково потрібно порівнювати з попередньою версією, щоб розуміти, як насправді йдуть справи, тобто проводити A/B тести. Насправді процес викочування та аналіз графіків досить рутинний і чудово піддається автоматизації. Ми викочуємо наші моделі поступово на 5%, на 30%, на 50% і на 100% користувачів, при цьому збираючи всі доступні метрики за відповідями моделі та фідбеку користувачів. У разі серйозних викидів ми автоматично відкочуємо модель, а для решти випадків, набравши достатню кількість кліків користувачів, приймаємо рішення про підвищення відсотка. У результаті доводимо нову модель до 50% користувачів повністю автоматично, а викочування на всю аудиторію аппрувіт людина, хоча і цей крок можна автоматизувати.

Проте процес A/B-тестів представляє простір оптимізації. Справа в тому, що будь-який A/B-тест досить тривалий (у нашому випадку він займає від 6 до 24 годин в залежності від кількості фідбеку), що робить його досить дорогим та з обмеженими ресурсами. Крім цього, потрібно досить високий відсоток потоку для тесту, щоб по суті прискорити загальний час А/B-тесту (набирати статистично значиму вибірку для оцінки метрик на малому відсотку можна дуже довго), що робить кількість A/B-слотів вкрай обмеженим. Очевидно, що нам потрібно виводити в тест тільки найперспективніші моделі, яких у процесі навчання ми отримуємо дуже багато.

Для вирішення цього завдання ми навчили окремий класифікатор, що передбачає успішність A/B-тесту. Для цього як ознаки беремо статистику прийняття рішень, Precision, Recall та інші метрики на навчальній множині, на відкладеному і на семпле з потоку. Також порівнюємо модель з поточною на продакшені, з евристиками, і беремо до уваги складність (Complexity) моделі. Використовуючи всі ці ознаки, навчений на історії тестів класифікатор скорить моделі-кандидати, у нашому випадку це ліси дерев, і приймає рішення, який із них пустити в A/B-тест.

У момент впровадження цей підхід дозволив кілька разів збільшити кількість успішних A/B-тестів.

Тестування & моніторинг

Тестування та моніторинг, як не дивно, не шкодять нашому здоров'ю, швидше, навпаки, покращують та позбавляють зайвих стресів. Тестування дозволяє запобігти збою, а моніторинг – вчасно виявити його, щоб зменшити вплив на користувачів.

Тут важливо розуміти, що рано чи пізно ваша система завжди помилятиметься — це пов'язано з циклом розробки будь-якого софту. На початку розробки системи завжди багато багів доти, доки все не встаканиться і не завершиться основний етап нововведень. Але з часом ентропія бере своє, і знову з'являються помилки через деградацію компонентів навколо і зміни даних, про що я говорив спочатку.

Тут хотів би відзначити, що будь-яку систему машинного навчання треба розглядати з погляду її профіту протягом усього життєвого циклу. Нижче на графіку показаний приклад роботи системи з вилову рідкісного виду спаму (на графіку лінія в районі нуля). Якось через неправильно закешовану ознаку вона збожеволіла. Як на зло, не було моніторингу на аномальне спрацювання, в результаті система почала зберігати листи до папки «спам» на межі ухвалення рішення у великій кількості. Незважаючи на виправлення наслідків, система вже стільки разів помилилася, що не окупить себе за п'ять років. І це повний провал з погляду життєвого циклу моделі.

Тому така проста річ, як моніторинг, може стати ключовою в житті моделі. Окрім стандартних та очевидних метрик, ми вважаємо розподіл відповідей та швидков моделі, а також розподіл значень ключових ознак. За допомогою KL-дивергенції ми можемо порівняти поточний розподіл з історичним чи значення на A/B-тесті з рештою потоку, що дозволяє помічати аномалії в моделі та вчасно відкочувати зміни.

У більшості випадків ми запускаємо наші перші версії систем за допомогою простих евристик або моделей, які в майбутньому використовуємо як моніторинг. Наприклад, моніторимо NER-модель порівняно з регулярками для конкретних інтернет-магазинів, і якщо покриття класифікатора просаджується порівняно з ними, то розуміємо причини. Ще одне корисне застосування евристик!

Підсумки

Пройдемося ще раз за ключовими думками статті.

• Фібдек. Завжди думаємо про користувача: як він житиме з нашими помилками, як зможе повідомити про них. Не забуваємо, що користувачі не є джерелом чистого фідбека для навчання моделей, і його необхідно прочищати за допомогою допоміжних ML-систем. Якщо немає можливості зібрати сигнал від користувача, шукаємо альтернативні джерела фідбека, наприклад, пов'язані системи.
• Донавчання. Тут основне – це спадкоємність, тому спираємось на поточну продакшен-модель. Нові моделі навчаємо так, щоб вони не сильно відрізнялися від попередньої за рахунок гармонійної регуляризації та подібних трюків.
• Деплой. Автодеплой за метриками сильно скорочує час на впровадження моделей. Моніторинг статистики та розподілу прийняття рішень, кількості фолзів від користувачів є обов'язковим для вашого спокійного сну та продуктивних вихідних.

Що ж, сподіваюся, що прочитане допоможе вам швидше покращувати ваші ML-системи, прискорювати їхній вивід на ринок і робити їх надійнішими, знижуючи кількість стресу від роботи.

Джерело: habr.com