Розробка

Переклад книги Ендрю Ина «Пристрасть до машинного навчання» Глави 1 — 14

Деякий час тому в моїй стрічці в фейсбуці спливла посилання на книгу Ендрю Ина (Andrew Ng) “Machine Learning Yearning”, яку можна перекласти, як “Пристрасть до машинного навчання” або “Жага машинного навчання”.

Людям, які цікавляться машинним навчанням або працюють у цій сфері представляти Ендрю не потрібно. Для непосвячених досить сказати, що він є зіркою світової величини в області штучного інтелекту. Вчений, інженер, підприємець, один із засновників Coursera. Автор відмінного курсу по введенню в машинне навчання і курсів, які становлять спеціалізацію “Глибоке навчання” (Deep Learning).

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

На момент написання цих рядків автор опублікував 52 глави із задуманих 56 (повідомлення про готовність 52 голови прийшло мені на пошту 4 липня). Всі доступні на даний момент глави можна скачати тут ну або самостійно знайти в інтернеті.

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

Свій переклад публікую без вичитки, “з печі”, до деяких місцях планую повернутися і виправити (особливо це відноситься до плутанини з train / dev / test датасетами). Буду вдячний, якщо в коментарях буде надано зауваження як за стилістикою, помилок і т. п., так і змістовні, що стосуються тексту автора.

Всі картинки оригінальні (від Ендрю Ин), без них книга була б більш нудною.

Отже, до книги:

Розділ 1. Навіщо потрібна стратегія по машинного навчання

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

Приклад: Створення стартапу по розпізнаванню котячих картинок

Припустимо, ви працюєте в стартапі, який обробляє нескінченний потік котячих фотографій для любителів кішок.

Ви використовуєте нейронну мережу для побудови системи комп’ютерного зору для розпізнавання кішок на фотографіях.

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

У вашої команди багато ідей, таких як:

  • Добути більше даних: зібрати більше фотографій кішок.
  • Зібрати більш різнорідний датасета. Наприклад, фотографії, на яких кішки знаходяться в незвичайних положеннях; фотографії кішок з незвичайною забарвленням; знімки з різноманітними налаштуваннями камери;…
  • Довше тренувати алгоритм, збільшивши кількість ітерацій градієнтного спуску
  • Спробувати збільшити нейронну мережу з великою кількістю шарів /прихованих нейронів / параметрів.
  • Спробувати зменшити нейронну мережу.
  • Спробувати додати регуляризацию (таку, як L2 регуляризацию)
  • Змінити архітектуру нейронної мережі (функцію активації, кількість прихованих нейронів, тощо)

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

Ця книга розповість вам, як.

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

2. Як використовувати цю книгу для допомоги в роботі вашої команди

Після закінчення читання цієї книги, у вас буде глибоке розуміння, як вибрати технічний напрямок робіт для проекту з машинного навчання.

Але вашим товаришам по команді може бути не ясно, чому ви рекомендуєте певний напрямок. Можливо, ви хочете, щоб ваша команда використовувала одне параметричну метрику при оцінці якості роботи алгоритму, але колеги не впевнені в тому, що це хороша ідея. Як вам переконати їх?

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

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

3. Передумови та зауваження

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

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

Я буду часто звертатися до нейронних мереж (до «глибокого навчання»). Вам потрібно тільки базові уявлення про те, що вони з себе представляють для розуміння цього тексту.

Якщо ви не знайомі з концепціями, згаданими тут, подивіться відео перших трьох тижнів з курсу Машинного навчання на Coursera http://ml-class.org/

4. Шкала прогресу в машинного навчання

Багато ідеї глибокого навчання (нейронних мереж) існували десятиліття. Чому ці ідеї злетіли тільки сьогодні?

Двома найбільшими драйверами недавнього прогресу стали:

  • Доступність даних Сьогодні люди проводять багато часу з обчислювальними приладами (ноутбуки, мобільні пристрої). Їх цифрова активність генерує величезні обсяги даних, які ми можемо згодовувати нашим які навчаються алгоритмами.
  • Обчислювальні потужності Лише кілька років тому стало можливим тренувати нейронні мережі досить великих розмірів, що дозволяють отримувати переваги використання величезних датасетов, які у нас з’явилися.

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

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

Якщо ви тренуєте маленьку нейронну мережу (NN) для тієї ж самої задачі «навчання з учителем», ви можете отримати результат трохи кращий, ніж у «старих алгоритмів».

Тут під «Малою NN» ми розуміємо нейронну мережу з невеликою кількістю прихованих нейронів / верств населення / параметрів. Нарешті, якщо ви починаєте тренувати всі великі і великі нейронні мережі, ви можете отримати все більш високу якість.

Примітка автора: Ця діаграма показує, що нейронні мережі працюють краще в режимі малих датасетов. Цей ефект менш стійкий, ніж ефект нейронних мереж, які добре працюють в режимі величезних датасетов. У режимі малих даних, в залежності від того, як ознаки були оброблені (в залежності від якості ижниниринга ознак), традиційні алгоритми можуть працювати як кращі, так і гірші, ніж нейронні мережі. Наприклад, якщо ви маєте 20 прикладів для навчання, не має великого значення, чи використовуєте ви логістичну регресію або нейронну мережу; підготовка ознак має більший ефект, ніж вибір алгоритму. Однак, якщо ви маєте 1 мільйон навчальних прикладів, я б вважав за краще нейронну мережу

Таким чином, ви отримуєте кращу якість роботи алгоритму, коли ви (i) тренуєте дуже велику нейронну мережу, в цьому випадку ви знаходитесь на зеленої кривої на картинці вгорі; (ii) у вашому розпорядженні величезну кількість даних.

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

Процес спільного виконання умов (i) і (ii) на практиці виявляється напрочуд складним. У цій книзі будуть детально обговорені деталі. Ми почнемо з загальних стратегій, які однаково корисні як для традиційних алгоритмів, так і для нейронних мереж, і потім вивчимо найбільш сучасні стратегії, використовувані при проектуванні і розробці систем глибинного навчання.

5. Створення вибірок для навчання і тестування алгоритмів

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

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

Проте, коли ви впровадили цей класифікатор в мобільний додаток, ви виявили, що якість його роботи дуже низька!

Що сталося?

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

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

Зазвичай використовуються такі визначення:

  • Навчальна вибірка (Training set) — вибірка з даних, яка використовується для навчання алгоритму
  • Валидационная вибірка (Вибірка для розробки Dev (development) set) — вибірка даних, яка використовується для підбору параметрів, вибору ознак та прийняття інших рішень, що стосуються навчання алгоритму. Її іноді називають утримуваної вибіркою для крос-валідації (hold-out cross validation set)
  • Тестова вибірка — вибірка, яка використовується для оцінки якості роботи алгоритму, при цьому ніяк не використовується для навчання алгоритму або використовуваним при цьому навчанні параметрами.

Примітка перекладача: Андрю Ин використовує поняття development set або dev set, в російській мові та російськомовній термінології машинного навчання такого термін не зустрічається. «Вибірка для розробки» або «Разработческая вибірка» (прямий переклад англійських слів) звучить громіздко. Тому я буду надалі використовувати словосполучення «валидационная вибірка» як синонім dev set.

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

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

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

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

6. Валидационная та тестову вибірки повинні мати однакову розподіл

Припустимо дані вашого програми для котячих фотографій сегментовані по чотирьох регіонах, які відповідають вашим найбільшим ринків: (i) США, (ii) Китай, (iii) Індія (iv) Інші.

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

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

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

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

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

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

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

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

7. Наскільки великі повинні бути валидационные і тестові вибірки?

Валидационная вибірка повинна бути достатньою для визначення відмінностей між алгоритмами, які ви відчуваєте. Наприклад, якщо класифікатор А має точність 90.0% і класифікатор має точність 90.1%, в цьому випадку, на валідаційної вибірці, що складається з 100 прикладів, неможливо виявити цю різницю в 0.1%.
Зауваження автора: В теорії можна перевірити має статистичну значимість зміна якості роботи алгоритму при зміні розміру валідаційної вибірки. На практиці більшість команд про це не турбуються про це (якщо мова йде не про опублікування результатів академічних досліджень), і я зазвичай не вважаю корисним використання тестів на статистичну значимість для оцінки проміжного прогресу при роботі над алгоритмом.

Для зрілих і важливих додатків — наприклад, рекламних, інтернет-пошуку, і рекомендаційних сервісів, я зустрічав команди, які були високо мотивовані битися навіть за 0.01% поліпшення, так як це безпосередньо впливає на прибуток компанії. У цьому випадку, валидационная вибірка повинна бути багато більше ніж 10000, для того, щоб виявити ще менші поліпшення.

Що можна сказати про розмір тестової вибірки? Вона повинна бути достатньо великою для отримання високої впевненості в якості роботи вашої системи. Однією популярною евристикою є використання 30% доступних для навчання даних для тестової вибірки. Це добре працює, якщо у вашому розпорядженні невелику кількість прикладів, скажімо від 100 до 10000 прикладів. Але в сьогоднішню епоху великих даних, коли перед машинним навчанням стоять завдання, іноді мають більше мільярда прикладів, частка даних, що використовуються для тестової та валідаційної вибірок скорочується, навіть якщо зростає абсолютна кількість прикладів у цих вибірках. Немає ніякої необхідності використовувати надмірно великі валидационные/тестові вибірки, понад того, що необхідно для оцінки якості роботи ваших алгоритмів.

8. Встановіть своїй команді для оптимізації однопараметрическую метрику якості

Точність класифікації є прикладом однопараметричної метрики якості: ви запускаєте свій класифікатор на валідаційної вибірці (або на тестовій), і отримуєте одну цифру, яка говорить про те, яка кількість прикладів классифицированны правильно. Згідно цій метриці, якщо класифікатор А показує 97% точність, а В класифікатор показує 90%, ми вважаємо класифікатор А кращим.

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

Classifier
Precision
Recall
А 95% 90%
В 98% 85%

В даному прикладі жоден з класифікаторів з очевидністю не перевершує інший, тому неможливо відразу вибрати один з них.

Classifier
Precision
Recall
F1 score
А 95% 90% 92.4%

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

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

Якщо вам дійсно необхідно оцінювати якість точністю і повнотою, я рекомендую використовувати один із стандартних способів їх комбінації, перетворюючи їх в одну цифру. Наприклад, можна взяти середню точності і повноти і в кінцевому рахунку працювати з одним параметром. В якості альтернативи можна розраховувати F1 метрику, яка є більш досконалим способом їх розрахунку середньозваженого і працює краще, ніж просто середнє.
Зауваження автора: Якщо ви хочете дізнатися більше про F1 метриці, див. https://en.wikipedia.org/wiki/F1_score Вона є «гармонійним середнім» між Точністю і Повнотою і розраховується, як 2/((1/Precision)+(1/Recall)).

Classifier
Precision
Recall
F1 score
А 95% 90% 92.4%
B 98% 85% 91.0%

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

В якості останнього прикладу, припустимо, що ви окремо відстежуєте точність вашого котячого класифікатора на ваших ключових ринках: (i) США, (ii) Китай, (iii) Індія (iv) Інші. Таким чином ви маєте чотири метрики. Взявши середньозважену цих чотирьох цифр, врешті-решт у вас буде однопараметрична метрика оцінки якості. Використання середньозваженого є одним з найбільш поширених шляхів перетворення декількох показників в один.

9. Оптимизируемые і обмежують метрики

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

Класифікатор
Точність
Швидкість
А 90% 80 мсек
B 92% 95 мсек
З 95% 1500 мсек

Отримання однопараметричної метрики, зв’язуванням швидкості і точності через формулу, таку як [Точність] — 0.5*[Швидкість], виглядає природним.

Ось що ви можете зробити замість цього: По-перше, визначте, яке час виконання алгоритму є «прийнятним». Давайте припустимо, що виконання протягом 100 милі секунд є прийнятним. Потім виберемо максимальну точність, відповідну критерієм швидкості виконання. Тут швидкість виконання є обмежує (satisficing) метрикою — ваш класифікатор повинен задовольняти обмежують значенням цієї метрики, в тому сенсі, що його максимальне значення не може перевищувати 100 мсек. Точність при цьому стає оптимізаційної метрикою.

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

В якості останнього прикладу, уявіть що ви розробляєте прилад, що використовує мікрофон для уловлювання певного «ініціюючого слова», вимовного користувачем для включення системи (після виголошення якого, система прокидається). Наприклад, Amazon Echo вловлює «Alexa»; Apple Siri вловлює «Hey Siri»; Android вловлює «Okay, Google»; додатки Baidu вловлюють «Hello Baidu». Вашою турботою є обидва false positive співвідношення — як частота включення системи, коли ніхто не вимовляв ключового слова, так і false negative — як часто система не включається при проголошенні ключового слова. Доцільною метою при розробці такої системи є мінімізація false negative метрики (це буде оптимізаційним параметром) при наявності не більше ніж один випадок false positive кожні 24 години роботи (обмежувальна метрика).

Вибір показників для оптимізації дозволяє командам прискорити прогрес у розробці моделей.

10 Наявність валідаційної вибірки та метрик збільшують швидкість ітерацій

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

  1. Починаю з деякої ідеї, як побудувати цю систему
  2. Реалізую цю ідею в коді (програмують ідею)
  3. Проводжу експеримент, який показує мені, наскільки добре працює ця ідея. (Зазвичай мої перші кілька ідей не працюють!) Відштовхуючись від набутих знань, повертаюся до генерації нових ідей і далі по колу.

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

Для контрасту, уявіть, що у вас немає спеціальної валідаційної вибірки і метрики. Таким чином кожен раз ваша команда розробляє новий котячий класифікатор, ви повинні інтегрувати цей класифікатор в ваш додаток і грати з додатком якусь кількість годин для того, щоб відчути, чи дійсно новий класифікатор є поліпшенням. Це може тягнутися неймовірно повільно! Крім того, якщо ваша команда покращила точність класифікатора з 95.0% до 95.1%, ви можете виявитися не здатними помітити ці 0.1% поліпшення при маніпуляціях (грі) з додатком. Але великий прогрес у вашій системі може бути досягнутий поступовим накопиченням дюжин таких 0.1%-них поліпшень. Наявність валідаційної вибірки та метрик, дозволяє дуже швидко помічати та оцінювати які ідеї є успішними, що дають вам маленькі (або великі) поліпшення, і тому дають вам швидке рішення, які ідеї потрібно вдосконалювати і які відкинути.

11 Коли потрібно змінювати валидационные і тестові (dev/test sets) вибірки і метрики

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

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

Якщо згодом ви вирішите, що ваші початкові dev/test вибірки або первісна метрика обрані невдало, киньте всі сили на те, щоб швидко їх поміняти. Наприклад, якщо ваш вибірка для розробки + метрика ранжирують класифікатор A вище, ніж класифікатор B, при цьому ви і ваша команда думаєте, що В класифікатор об’єктивно краще підходить для вашого продукту, то це може бути знаком, що ви маєте потребу в зміні dev/test датасетов або в зміні метрики оцінки якості.

Існує три основні можливі причини, за яких валидационная вибірка або метрика оцінки якості неправильно ранжирують класифікатор А вище класифікатора:

1. Реальний розподіл, яке потрібно покращувати, відрізняється від dev/test вибірок

Уявіть, що ваші початкові dev/test датасеты містять в основному картинки дорослих кішок. Ви починаєте розповсюджувати ваше котяче додаток, і виявляєте, що користувачі завантажують істотно більше зображень кошенят, ніж ви очікували. Таким чином dev/test розподіл не репрезентативно, воно не відображає реального розподілу об’єктів, якість розпізнавання яких вам необхідно покращувати. У цьому випадку оновіть ваші dev/test вибірки, зробивши їх більш репрезентативними.

2. Ви переобучаетесь на валідаційної вибірці (dev set)

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

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

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

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

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

Це досить загальні підходи до зміни dev/test вибірок або зміни метрики оцінки якості в процесі роботи над проектом. Наявність первинних dev/test вибірок і метрики дозволяють вам швидко почати ітерації роботи над проектом. Навіть якщо ви виявите, що вибрані dev/test вибірки або метрика більше не орієнтують вашу команду в правильному напрямку, це не має великого значення! Просто змініть їх і переконайтеся, що ваша команда знає про новий напрямок.

12 Рекомендації: Готуємо валидационную (development) та тестову вибірки

  • Вибирайте dev і test вибірки з розподілу, що відображає ті дані, які ви очікуєте отримати в майбутньому ви хочете, щоб ваш алгоритм добре працював. Ці вибірки можуть не збігатися з розподілом вашого навчального дата сету.
  • Вибирайте вибірки для розробки і тестування (dev test sets) з одного і того ж розподілу, якщо це можливо
  • Вибирайте для своєї команди однопараметрическую метрику оцінки якості алгоритмів для оптимізації. Якщо у вас кілька цілей, яких потрібно досягти одночасно, розгляньте можливість об’єднати їх в одну формулу (таку як метрика усередненої багатопараметричної помилки) або визначте обмежують і оптимізаційну метрики.
  • Машинне навчання є вищою мірою ітеративним процесом: ви можете пробувати безліч ідей перш ніж знайдете ту, яка вас задовольнить.
  • Наявність dev/test вибірок і однопараметричної метрики оцінки якості допоможуть вам швидко оцінювати алгоритми, і таким чином, проходити ітерації швидше.
  • Коли стартує розробка нового додатка, спробуйте швидко встановити dev/test вибірки і метрику оцінки якості, скажімо, витратьте на це не більше тижня. Для зрілих додатків нормально, якщо цей процес займає значно більше часу.
  • Стара добра евристика розбиття тренувальної та тестової вибірки як 70% на 30% не застосовна до проблем, в яких є велика кількість даних; dev / test вибірки можуть бути істотно менше, ніж 30% від усіх наявних даних.
  • Якщо ваша вибірка для розробки і метрика більше не вказує вашій команді правильний напрямок руху, швидко поміняйте їх: (i) якщо ваш алгоритм перенавчається на валідаційної вибірці (dev set), додайте в неї (в ваш dev set) більше даних. (ii) Якщо розподіл реальних даних, якість роботи алгоритму на якому вам необхідно покращувати, відрізняється від розподілу даних в валідаційної і (або) тестовій вибірках (dev / test sets), сформуйте нові вибірки для тестування і розробки (dev / test sets), використовуючи інші дані. (iii) Якщо ваша метрика для оцінки якості більше не вимірює те, що найбільш важливо для вашого проекту, змініть цю метрику.

13 Побудуйте вашу першу систему швидко, а потім ітераційно покращуйте

Ви хочете побудувати побудувати нову систему антиспаму для електронної пошти. У вашої команди є кілька ідей:

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

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

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

14 Аналіз помилок: Дивіться на приклади з валідаційної вибірки (dev set examples) для оцінки ідей

Коли ви гралися з вашим котячим додатком, ви помітили кілька прикладів в яких додаток помилково приймав собак, за кішок. Деякі собаки виглядають, як кішки!

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

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

Конкретно, що можна зробити в цьому випадку:

  1. Зберіть вибірку в 100 прикладів з валідаційної вибірки (dev set), які ваша система неправильно класифікований. Тобто прикладів, на яких ваша система зробила помилку.
  2. Вивчіть ці приклади і порахуйте, яку частку від них складають зображення собак.

Процес вивчення прикладів на яких класифікатор помилився, називається «аналіз помилок». У наведеному прикладі, припустимо, ви знайдете, що тільки 5% від неправильно класифікованих зображень є собаками, тоді не важливо, наскільки сильно ви поліпшите роботу вашого алгоритму на собачих зображеннях, ви не зможете отримати поліпшення якості вище, ніж 5% від частки ваших помилок. Іншими словами, 5% це «стеля» (передбачає максимально можливе число) наскільки вірогідне поліпшення може допомогти. Таким чином, якщо ваша загальна система зараз має точність 90% (10% помилок), це поліпшення можливо, в кращому випадку поліпшить результат до 90.5% точності (або частка помилок буде становити 9.5%, що на 5% менше, ніж початкові 10% помилок)

Навпаки, якщо ви виявите, що 50% помилок є собаками, тоді ви можете бути більш впевненими, що передбачуваний проект по покращенню системи буде мати великий ефект. Він міг би збільшити точність з 90% до 95% (50% відносне зменшення помилки з 10% до 5%)

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

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

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

Related Articles

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Close