Приложение на машинно обучение в Mail.ru

По мотиви на моите изяви на Highload++ и DataFest Минск 2019 г.

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

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

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дървета

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

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

Очевидно е, че с времето броят на дърветата значително се увеличава и те трябва периодично да се съкращават, за да се вписват в тайминга. За това използваме широко разпространената вече Дестилация на знание (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 получаваме ембеддинги. След това върху ембеддингите се прилагат класификатори, които издават оценки за различни класове (типове писма, спам, наличие на лого). Оценките и признаците попадат в гора от дървета за вземане на финалното решение. Отделните класификатори в тази схема позволяват по-добра интерпретация на резултатите от работата на системата и по-целенасочено дообучаване на компонентите при възникване на проблеми, вместо да подаваме всички данни в дърветата за решения в суров вид.

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

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

Деплой

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

A/B тестване

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

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

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

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

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

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

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

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

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

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

Резюме

Нека отново преминем през ключовите мисли на статията.

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

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

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