Утиліта інженерії функцій: навіщо створювати нові функції на основі наявних функцій?


30

Я часто бачу, як люди створюють нові функції на основі існуючих функцій з проблеми машинного навчання. Наприклад, ось: https://triangleinequality.wordpress.com/2013/09/08/basic-feature-engineering-with-the-titanic-data/ люди розглядали розмір сім'ї людини як нову особливість, засновану на про кількість братів, сестер та батьків, які були наявними ознаками.

Але який сенс у цьому? Я не розумію, чому створення корисних нових функцій корисно. Чи не завдання алгоритму робити це самостійно?


Відповіді:


30

Найпростіший приклад, який використовується для ілюстрації, - це проблема XOR (див. Зображення нижче). Уявіть, що вам дано дані, що містять координати і y та двійковий клас для прогнозування. Ви можете очікувати, що ваш алгоритм машинного навчання сам з’ясує правильну межу рішення, але якщо ви створили додаткову функцію z = x y , проблема стає тривіальною, оскільки z > 0 дає вам майже ідеальний критерій рішення для класифікації, і ви використовували просто простий арифметичні!xyz=xyz>0

Проблема XOR

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

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

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

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


Дякую, це дуже добре пояснено і дуже цікаво!
Матьє Верон

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

@PoeteMaudit Це правда, що дерево рішень (і так РФ) моделює одну велику взаємодію, але це певний вид взаємодій, а не кожна можлива взаємодія. Більше того, функціональна інженерія стосується не лише взаємодій.
Тім

Звичайно, я згоден з вашими пунктами. По-перше, що РЧ моделює певний вид взаємодій (ви маєте на увазі переважно x * y?). По-друге, інженерія функцій, безумовно, не стосується лише взаємодій.
Poete Maudit

14

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

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

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


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

2
Що ж, це знання, яке стосується домену. Наприклад, якщо ви розробляєте систему медичної діагностики, ви можете поговорити з лікарями і запитати їх, яку інформацію вони використовують для діагностики пацієнта. Наприклад, якщо один лікар каже "Якщо у пацієнта є і температура, і головні болі, він, швидше за все, захворів на грип". Це речення може означати, що включення нової функції прапорця, яка вказує на наявність гарячки та головного болю, може бути хорошою ідеєю (особливо, якщо ви використовуєте лінійний класифікатор, який не може сам "бачити" функції поліноміальної взаємодії).
Даніель Лопес

1
Тим не менш, це більше мистецтво, ніж наука. Врешті-решт, вам потрібно перевірити ефективність ваших рукотворних функцій, протестувавши свої моделі на тестовому наборі з неупередженим експериментальним протоколом ...
Даніель Лопес,

3

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

  1. Y=1

Circle Boundary

x1x2y=x0+c1x1+c2x2y=x0+c1x12+c2x22

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

  2. У реальному світі ви не отримаєте жодного набору даних, як надає Kaggle. Натомість ви отримуєте інформацію з усіх куточків світу. Наприклад, якщо ви хочете передбачити втрату клієнтів для такої мережі роздрібної компанії, як Amazon, ви маєте інформацію про демографію клієнтів, інформацію про транзакції щодо покупки. Вам потрібно створити багато функцій з різних джерел, в цьому випадку ви знайдете багато корисних функцій, які можна отримати / агрегувати на рівні транзакцій. Як стверджує Ендрю Нг: Часто часи здатність займатися інженерною діяльністю визначає успіх або провал проекту машинного навчання.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.