Използване на машинно обучение в Почта Mail.ru

Вдъхновена от моите изказвания на Highload++ и DataFest Минск 2019 г.

За много хора днес електронната поща е неотменима част от живота в мрежата. С нея извършваме бизнес кореспонденция, съхраняваме всякаква важна информация, свързана с финанси, резервации на хотели, обработка на поръчки и много други. През средата на 2018 г. формулирахме продуктовата стратегия за развитие на пощата. Каква трябва да бъде съвременната поща?

Пощата трябва да бъде умна, тоест да помага на потребителите да се ориентират в увеличаващия се обем информация: да филтрират, структурират и предоставят информацията по най-удобния начин. Тя трябва да бъде полезна, позволявайки в самата поща да решаваме различни задачи, например да плащаме глоби (функция, която, за мое съжаление, използвам). И разбира се, пощата трябва да осигурява информационна защита, да блокира спам и да защитава от хакерски атаки, тоест да бъде сигурна.

Тези направления определят редица ключови задачи, много от които могат да бъдат ефективно решени с помощта на машинно обучение. Ето примери за вече работещи функционалности, разработени в рамките на стратегията — по един на всяко направление.

• Умен отговор. В пощата има функция за умен отговор. Невронната мрежа анализира текста на писмото, разбира неговия смисъл и цел и в резултат предлага три най-подходящи варианта на отговор: положителен, отрицателен и неутрален. Това помага значително да спестим време при отговорите на писма, а също така често да отговаряме нестандартно и забавно за себе си.
• Групиране на писма, относими към поръчки в онлайн магазини. Често пазаруваме онлайн и, като правило, магазините могат да изпратят по няколко писма за всяка поръчка. Например, от АлиЕкспрес, най-голямата услуга, получаваме много писма за една поръчка, и изчислихме, че в терминалния случай тяхното количество може да достигне до 29. Затова с помощта на модела за Разпознаване на именувани обекти изваждаме номера на поръчката и друга информация от текста и групираме всички писма в една нишка. Също така показваме основната информация за поръчката в отделен блок, което улеснява работата с този тип писма.

  

• Антифишинг. Фишингът е особено опасен вид измама, при която извършителите се опитват да получат финансова информация (включително информация за банкови карти на потребителите) и данни за вход. Такива съобщения имитират истински, изпратени от услуги, включително визуално. Затова чрез компютърно зрение разпознаваме логотипите и стила на оформление на писмата от големи компании (например, Mail.ru, Сбер, Алфа) и ги взимаме предвид, заедно с текста и други признаци, в нашите класifikатори за спам и фишинг.

Машинно обучение

Няколко думи за машинното обучение в електронната поща като цяло. Пощата е силно натоварена система: през нашите сървъри преминават средно по 1,5 милиарда писма на ден за 30 милиона активни потребители. За всички необходими функции и функции отговарят около 30 системи за машинно обучение.

Всяко писмо преминава през цял конвейер за класификация. Първо отсичаме спама и оставяме добрите писма. Потребителите често не забелязват работата на антиспам системата, тъй като 95—99 % от спама дори не попада в съответната папка. Разпознаването на спама е много важна и най-сложна част от нашата система, тъй като в сферата на антиспама непрекъснато протича адаптация между системите за защита и атака, което предоставя непрекъснат инженеринг екип за нашия екип.

След това разделяме писмата от хора и от роботи. Писмата от хора са най-важни, затова за тях предоставяме функции като Smart Reply. Писмата от роботи се делят на две части: транзакционни — това са важни писма от услуги, например, потвърждения за покупки или резервации на хотели, финанси, и информационни — бизнес реклама, отстъпки.

Смятаме, че транзакционните писма по важност се равняват на личната кореспонденция. Те трябва да бъдат под ръка, тъй като често е необходимо бързо да намерим информация за поръчка или самолетен билет, а ние губим време в търсене на тези писма. Затова, за удобство, автоматично ги делим на шест основни категории: пътувания, поръчки, финанси, билети, регистрации и накрая, глоби.

Информационните писма са най-многобройната и вероятно по-малко важна група, която не изисква незабавна реакция, тъй като нищо съществено не би се променило в живота на потребителя, ако не прочете такова писмо. В нашия нов интерфейс ги сгъва в два потока: социални мрежи и разпространения, по този начин визуално почистваме пощенската кутия и оставяме на показ само важните писма.

Експлоатация

Голямото количество системи създава немалко трудности при експлоатацията. Моделите с времето деградират, както и всеки софтуер: признаците се повреждат, машините отказват, натрупва се некоректен код. Освен това постоянно се променят данните: добавят се нови, трансформира се патернът на поведение на потребителите и т.н., затова модел без подходяща подкрепа с времето ще работи все по-лошо.

Не бива да забравяме, че колкото по-дълбоко машинното обучение прониква в живота на потребителите, толкова по-голямо влияние оказват върху екосистемата и, в следствие на това, толкова повече финансови загуби или печалби могат да получат играчите на пазара. Ето защо все повече области се адаптират към работата с ML алгоритми (класически примери — реклама, търсене и вече споменатият антиспам).

Също така задачите на машинното обучение притежават особеност: всяка, дори и незначителна промяна в системата може да породи много работа с модела: работа с данни, пренаправяне, внедряване, което може да приключи след седмици или месеци. Затова колкото по-бързо се променя средата, в която оперират вашите модели, толкова повече усилия изисква тяхната поддръжка. Екипът може да създаде множество системи и да се радва на това, а след това да изразходва почти всичките си ресурси за тяхното поддържане, без възможност да направи нещо ново. С такава ситуация веднъж се сблъскахме в екипа по антиспам. И направихме очевидно заключение, че поддръжката трябва да се автоматизира.

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

Какво може да бъде автоматизирано? Всъщност почти всичко. Аз откроих четири направления, които определят инфраструктурата на машинното обучение:

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

Ако средата е нестабилна и постоянно се променя, цялата инфраструктура около модела се оказва много по-важна от самия модел. Това може да е старият добър линейен класификатор, но ако правилно подадем признаците и организираме добра обратна връзка от потребителите, то той ще работи много по-добре от State-Of-The-Art модели с всички надстройки.

Цикъл на обратна връзка

Този цикъл обединява събиране на данни, дообучение и деплой — по същество, целия цикъл на обновление на модела. Защо е важно? Погледнете графика на регистрациите в пощата:

Разработчикът на машинно обучение внедри модел на антибот, който не позволява на ботове да се регистрират в пощата. Графикът пада до стойност, в която остават само реални потребители. Всичко е прекрасно! Но минават четири часа, ботодниците настройват скриптовете си и всичко се връща на кръг. В това внедряване разработчикът е похарчил месец, добавяйки признаци и дообучавайки модела, но спамен успя да се адаптира за четири часа.

За да не е толкова болезнено и да не се налага после всичко да се преработва, трябва отначало да мислим за това как ще изглежда цикълът на обратна връзка и какво ще правим, ако средата се промени. Нека започнем със събиране на данни — това е горивото за нашите алгоритми.

Събиране на данни

Ясно е, че на съвременните невронни мрежи колкото повече данни, толкова по-добре, а те, по същество, се генерират от потребителите на продукта. Потребителите могат да ни помогнат, маркирайки данни, но не бива да се злоупотребява с това, тъй като в даден момент на потребителите им омръзва да обучават вашите модели и те ще преминат на друг продукт.

Една от най-честите грешки (тук правя референция на Andrew Ng) — прекомерна ориентация към метриките на тестовия датасет, а не към обратната връзка от потребителя, което в действителност е основната мярка за качество на работата, тъй като създаваме продукт за потребителя. Ако на потребителя не му е ясно или не му харесва работата на модела, значи всичко е напразно.

Затова потребителят винаги трябва да има възможност да гласува, трябва да му се предостави инструмент за обратна връзка. Ако смятаме, че в пощенската кутия е постъпило писмо, свързано с финансите, трябва да го маркираме като 'финанси' и да нарисуваме бутон, който потребителят може да натисне и да каже, че това не е финанси.

Качество на обратната връзка

Нека поговорим за качеството на потребителските отзиви. Първо, вие и потребителят може да влагате различен смисъл в едно и също понятие. Например, вие и продуктовите мениджъри смятате, че "финанси" означава писма от банката, докато потребителят вярва, че писмо от баба му за пенсия също се отнася до финанси. На второ място, има потребители, които безразсъдно обичат да натискат бутони без никаква логика. На трето място, потребителят може да бъде дълбоко заблуден в изводите си. Ясен пример от нашата практика е внедряването на класификатор на нигерийски спам, доста забавен тип спам, при който на потребителите се предлага да вземат няколко милиона долара от внезапно открит отдалечен роднина в Африка. След внедряването на този класификатор проверихме кликванията "Не е спам" на тези писма и се оказа, че 80 % от тях са сочен нигерийски спам, което показва, че потребителите могат да бъдат изключително доверчиви.

И да не забравяме, че не само хората могат да натискат бутоните, но и различни ботове, които се преструват на браузър. Така че суровите отзиви не са подходящи за обучение. Какво можем да направим с тази информация?

Прилагаме два подхода:

• Обратна връзка от свързан ML. Например, имаме онлайн система за антиботове, която, както вече споменах, взема бързо решение на основата на ограничен брой признаци. И има втора, бавна система, която работи постфактум. Тя притежава повече данни за потребителя, за неговото поведение и т.н. В резултат на това, тя взема най-обоснованото решение и следователно има по-висока точност и пълнота. Разликата в работата на тези системи може да бъде насочена към първата като данни за обучение. Така по-простата система винаги ще се опитва да се доближи до изпълнението на по-сложната.
• Класификация на кликванията. Можете просто да класифицирате все кликове на потребителите, да оценявате тяхната валидност и приложимост. Правим това в антиспам системите на пощата, като използваме данни за потребителя, неговата история, признаци на подателя, самия текст и резултати от работата на класификаторите. В крайна сметка получаваме автоматизирана система, която валидира обратната връзка от потребителя. И тъй като тя трябва да бъде дообучавана значително по-рядко, работата й може да се превърне в основна за всички останали системи. Основният приоритет в този модел е точността, защото обучаването на модел с неточни данни носи сериозни последствия.

Докато чистим данните и дообучаваме нашите ML системи, не трябва да забравяме потребителите, защото за нас хиляди, милиони грешки на графиката — това е статистика, а за потребителя всяка грешка е трагедия. Освен че потребителят трябва да живее с вашата грешка в продукта, след обратната връзка той очаква подобни ситуации да не се повтарят в бъдеще. Затова винаги трябва да давате на потребителите не само възможност да гласуват, но и да коригират поведението на ML системите, като създават, например, персонализирани хевристики за всеки клик на обратната връзка; в случая с пощата, това може да бъде възможността да филтрират подобни имейли по подател и заглавие за този потребител.

Също така е необходимо на базата на някакви репорти или обаждания в техническата поддръжка полуавтоматично или ръчно да tweak-нем модела, за да не страдат и другите потребители от подобни проблеми.

Хевристики за обучение

С тези хевристики и решения има два проблема. Първият е, че постоянно нарастващото количество решения е трудно за поддържане, да не говорим за тяхното качество и работа в дългосрочен план. Вторият проблем е, че грешката може да не е честа и няколко клика за дообучаване на модела може да не са достатъчни. На пръв поглед изглежда, че тези два несвързани ефекта могат значително да бъдат неутрализирани, ако приложим следния подход.

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

Следователно армията от корекции е много полезна. Най-важното е службата им да бъде спешна, а не постоянна.

Допълнително обучение

Допълнителното обучение е процес на добавяне на нови данни, получени в резултат на обратна връзка от потребители или други системи, и обучение на съществуващия модел на тях. Могат да възникнат няколко проблема с допълнителното обучение:

1. Моделът може просто да не поддържа допълнително обучение и да учи само от нулата.
2. Никъде в книгата на природата не е записано, че допълнителното обучение непременно ще подобри качеството на работа в производствена среда. Често става обратното, тоест възможно е само влошаване.
3. Промените може да бъдат непредсказуеми. Това е достатъчно деликатен момент, който ние сами установихме. Дори ако новият модел в A/B теста показва сходни резултати с текущия, това съвсем не означава, че ще работи идентично. Тяхното представяне може да се различава в някой процент, който може да доведе до нови грешки или да възстанови вече коригирани стари грешки. С текущите грешки както ние, така и потребителите, вече знаем как да живеем, и когато се появят голямо количество нови грешки, потребителят също може да не разбира какво се случва, тъй като очаква предсказуемо поведение.

Следователно най-важното в допълнителното обучение е гарантирано да подобряваме модела, или поне да не го влошаваме.

Първото, което идва на ум, когато говорим за допълнително обучение, е подходът Active Learning. Какво означава това? Например, класификаторът определя дали писмото е свързано с финанси и около границата на неговото решение добавяме набор от етикетирани примери. Това работи добре, например, в рекламата, където има много обратна връзка и може да се обучава моделът в онлайн режим. А ако обратната връзка е малко, то получаваме силно изкривен набор спрямо производственото разпределение на данните, на база на който не можем да оценим поведението на модела в процеса на експлоатация.

Наистина, целта ни е да запазим старите модели, вече известните схеми, и да придобием нови. Тук е важна приемствеността. Моделът, който често с големи усилия разработихме, вече функционира, така че можем да се ориентираме по неговото представяне.

В пощата се прилагат различни модели: дървета, линейни, невронни мрежи. За всеки от тях правим свой алгоритъм за дообучение. В процеса на дообучение получаваме не само нови данни, но и често нови характеристики, които ще вземем предвид във всички по-долу изброени алгоритми.

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

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

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

Тъй като всеки компонент на загубата има коефициенти, можем да намерим оптималните стойности за нашата задача на крос валидация или в зависимост от продуктовите изисквания.

Дървета

Да преминем към дървета за решения. Разработихме следния алгоритъм за дообучение на дърветата:

1. В продукция работи горски ансамбъл от 100–300 дървета, обучен на стария датасет.
2. В края премахваме M = 5 дървета и добавяме 2M = 10 нови, обучени на целия датасет, но с високи тегла на новите данни, което естествено гарантира инкрементално изменение на модела.

Очевидно е, че с времето броят на дърветата значително се увеличава и е необходимо периодично да ги намаляваме, за да отговорим на времевите ограничения. За това използваме вездесъщото в момента Knowledge Distillation (KD). Накратко за принципа на неговата работа.

1. Имаме текущия "сложен" модел. Стартираме го на тренировъчния датасет и получаваме разпределение на вероятностите за класовете на изхода.
2. След това обучаваме модел-ученик (модел с по-малко дървета в този случай) да повтори резултатите на модела, използвайки разпределението на класовете като целева променлива.
3. Важно да се отбележи, че ние не използваме разметката на дата-сета, така че можем да използваме произволни данни. Разбира се, използваме сэмпл данни от производствения поток като обучаваща извадка за модела на ученика. По този начин, тренировъчната извадка ни позволява да осигурим точност на модела, а сэмпл потокът гарантира подобна производителност на продукционното разпределение, компенсирайки отклоненията на обучаващата извадка.

Комбинацията от тези две техники (добавяне на дървета и периодично намаляване на тяхното количество чрез Knowledge Distillation) осигурява въвеждане на нови модели и пълна приемственост.

С помощта на KD ние също така извършваме различия в операциите с характеристиките на модела, например, премахване на характеристики и работа с пропуски. В нашия случай имаме редица важни статистически характеристики (по изпращачи, текстови хешове, URL адреси и т.н.), които се съхраняват в база данни, която има свойство да отказва. Моделът, разбира се, не е готов за такова развитие на събития, тъй като в тренировъчната извадка не се срещат ситуации на отказ. В подобни случаи комбинираме техниките KD и аугментация: при обучението за част от данните премахваме или нулираме необходимите характеристики, а етикетите (изходите на текущия модел) взимаме оригиналните, моделът ученик учи да повтаря това разпределение.

Забелязахме, че колкото по-сериозна манипулация на моделите настъпва, толкова повече процентно съотношение е необходимо за сэмла потока.

За премахване на характеристики, най-простата операция, е достатъчна само малка част от потока, тъй като се променят само няколко характеристики, а текущият модел е учил на същия сет — разликата е минимална. За опростяване на модела (намаляване на броя на дърветата няколко пъти) вече е необходимо 50 на 50. А за пропуски на важни статистически характеристики, които сериозно влияят на производителността на модела, е необходимо още повече поток, за да се изравни работата на новия устойчив на пропуски модел на всички типове писма.

FastText

Давайте да се заемем с FastText. Напомням, че представянето (Embedding) на думата се състои от сумата на embedding-а на самата дума и всички нейни буквени N-грамове, обикновено триграмове. Понеже триграмите могат да бъдат доста много, се използва Bucket Hashing, т.е. преобразуването на цялото пространство в определен хеш-карта. В резултат матрицата на теглата придобива размерност, съответстваща на вътрешния слой по брой думи + буфера.

При дообучаването се появяват нови характеристики: думи и триграми. В стандартното дообучаване от Facebook не се случва нищо съществено. Обучават се само старите тегла с крос-ентропия на нови данни. Следователно, новите характеристики не се използват, разбира се, този подход притежава всички по-горе описани недостатъци, свързани с непредсказуемостта на модела в продукцията. Затова направихме малки подобрения в FastText. Добавяме всички нови тегла (думи и триграми), дообучаваме цялата матрица с крос-ентропия и добавяме хармонична регуляризация аналогично на линейния модел, който гарантира, че старите тегла променят незначително.

CNN

С конволюционните мрежи е малко по-сложно. Ако в CNN се дообучават последните слоеве, то разбира се, може да се приложи хармонична регуляризация и да се гарантира приемственост. Но в случая, когато е необходимо дообучаване на цялата мрежа, такава регуляризация вече не може да бъде приложена на всички слоеве. Въпреки това, съществува вариант с обучение на комплементарни ембеддинги чрез Triplet Loss (оригинална статия).

Triplet Loss

На примера на задачата за антифишинг ще разгледаме в общи линии Triplet Loss. Взимаме нашето лого, както и позитивни и негативни примери на логата на други компании. Минимизираме разстоянието между първите и максимизираме разстоянието между вторите, като го правим с малък зазор, за да осигурим по-голяма компактност на класовете.

Ако дообучаваме мрежата, то метричното пространство изцяло се променя и става абсолютно несъвместимо с предишното. Това е сериозен проблем в задачите, използващи вектори. За да заобиколим този проблем, ще смесваме по време на обучението старите ембеддинги.

Добавихме нови данни в тренировъчния сет и обучаваме втората версия на модела от нулата. На втория етап дообучаваме нашата мрежа (Finetuning): първо се обучава последният слой, а след това се освобождава цялата мрежа. В процеса на съставяне на триплети, само част от ембеддингите се изчисляват с помощта на обучаемия модел, а останалите - с помощта на стария. По този начин, в процеса на дообучение, осигуряваме съвместимост между метричните пространства v1 и v2. Своеобразна форма на гармонична регуляризация.

Архитектура на цялата система

Ако разглеждаме цялата система на примера на антиспам, моделите не са изолирани, а са вложени един в друг. Вземаме изображения, текст и други признаци и с помощта на CNN и Fast Text получаваме ембеддинги. След това над ембеддингите се прилагат класificatори, които дават оценки за различни класове (типове писма, спам, наличие на логотип). Оценките и признаците вече попада в гора от дървета за вземане на финално решение. Отделните класificatори в тази схема позволяват по-добра интерпретация на резултатите от работата на системата и по-точно дообучаване на компонентите при възникване на проблеми, отколкото да се подават всички данни в суров вид в дърветата за решения.

В крайна сметка гарантираме приемственост на всеки етап. На долния етап в CNN и Fast Text използваме гармонична регуляризация, за класификаторите в средата - също гармонична регуляризация и калибриране на оценката за съвместимост на разпределението на вероятността. А бустингът на дървета се обучава инкрементално или чрез Knowledge Distillation.

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

Деплой

Разгледахме събирането на данни и дообучението на различни типове модели, затова преминаваме към тяхното внедряване в продукционна среда.

А/Б тестване

Както казахме по-рано, по време на събиране на данни, обикновено получаваме изкривена извадка, чрез която е невъзможно да се оцени продуктивността на модела. Следователно, при разгръщането е задължително да се сравнява модела с предишната версия, за да се разбере как наистина стоят нещата, тоест, да се провеждат A/B тестове. Всъщност процесът на пускане и анализ на графиките е доста рутинен и идеално се поддава на автоматизация. Ние постепенно пускаме нашите модели на 5%, на 30%, на 50% и на 100% от потребителите, като в същото време събираме всички налични метрики по отговорите на модела и обратната информация от потребителите. В случай на сериозни изкривявания, автоматично откатваме модела, а в другите случаи, след като сме събрали достатъчно количество кликвания от потребителите, вземаме решение за увеличаване на процента. В крайна сметка, новият модел достигаме до 50% от потребителите напълно автоматично, а одобрението за разгръщането на цялата аудитория се дава от човек, въпреки че и тази стъпка може да бъде автоматизирана.

Въпреки това, процесът на A/B тестове представя пространство за оптимизация. Факт е, че всеки A/B тест е доста дълъг (в нашия случай отнема от 6 до 24 часа в зависимост от количеството обратна информация), което го прави доста скъп и с ограничени ресурси. Освен това е необходим достатъчно висок процент поток за теста, за да се ускори общото време на A/B теста (събиране на статистически значима извадка на малък процент може да отнеме много време), което прави броя на A/B слотовете крайно ограничен. Очевидно е, че трябва да извеждаме в тест само най-перспективните модели, които в процеса на дообучение получаваме доста.

За решаването на този проблем обучихме отделен класификатор, предсказващ успешността на A/B теста. За това като признаци използваме статистиката на взетите решения, Precision, Recall и други метрики на обучаващото множество, на отложеното и на sample от потока. Също така сравняваме модела с текущия в продукцията, с хевристиките и вземаме предвид сложността (Complexity) на модела. Използвайки всички тези признаци, обучен на историята на тестовете класификатор оценява моделите-кандидати, в нашия случай това са гора от дървета, и взема решение кой от тях да пусне в A/B теста.

При внедряване този подход значително увеличава броя на успешните A/B тестове.

Тестиране & мониторинг

Тестироването и мониторингът, както странно да звучи, не вредят на нашето здраве, а по-скоро точно обратното — подобряват го и ни спасяват от излишен стрес. Тестът предотвратява срив, а мониторингът — открива проблемите навреме, за да намали влиянието им върху потребителите.

Тук е важно да разберем, че рано или късно вашата система винаги ще сбърка — това е свързано с цикъла на разработка на софтуер. В началото на разработката на системата обикновено има много грешки, докато всичко не се стабилизира и не завърши основният етап на иновациите. Но с времето ентропията си взема своето и отново се появяват грешки — поради деградация на компонентите около нас и промяна на данните, за които говорех в началото.

Искам да подчертая, че всяка система за машинно обучение трябва да бъде разглеждана от гледна точка на печалбата ѝ през целия жизнен цикъл. По-долу на графиката е показан пример за работа на система за ловене на рядък вид спам (на графиката линията е около нулата). Веднъж поради неправилно кеширано свойство, тя се повреди. За съжаление, нямаше мониторинг за аномално поведение, в резултат на което системата започна да запазва имейли в папката „спам“ в голямо количество на границата на вземане на решение. Въпреки коригирането на последствията, системата вече беше сбъркала толкова много пъти, че нямаше да се изплати и за пет години. А това е пълен провал от гледна точка на жизнения цикъл на модела.

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

В повечето случаи стартираме първите версии на системите си с помощта на прости хевристики или модели, които в бъдеще използваме за мониторинг. Например, наблюдаваме NER модел в сравнение с регулярни изрази за конкретни интернет магазини, и ако покритие на класификатора намалява в сравнение с тях, се интересуваме от причините. Още едно полезно приложение на хевристиките!

Итог

Нека още веднъж да прегледаме основните мисли от статията.

• Fibdeck. Винаги мислим за потребителя: как ще живее с нашите грешки, как ще може да ги докладва. Не забравяме, че потребителите не са източник на чиста обратна връзка за обучаване на модели, и тя трябва да се очиства с помощта на спомагателни ML системи. Ако няма възможност да съберем сигнал от потребителя, търсим алтернативни източници на обратна връзка, например свързани системи.
• Допълнително обучение. Основното тук е наследствеността, затова се опираме на текущата продукционна модел. Новите модели обучаваме така, че да не се различават значително от предишния, чрез хормонална регуляризация и подобни трикове.
• Деплой. Авторазполагането по метрики значително съкращава времето за внедряване на моделите. Наблюдаването на статистиката и разпределението на взетите решения, количеството на фалшивите сигнали от потребителите е задължително за вашия спокоен сън и продуктивни уикенди.

Надявам се, че прочетеното ще ви помогне да подобрите вашите ML системи по-бързо, да ускорите тяхното излизане на пазара и да ги направите по-надеждни, намалявайки стреса от работата.

Източник: habr.com