Розуміння природної мови застосовується в широкому діапазоні випадків використання, від чат-ботів і віртуальних помічників до машинного перекладу й узагальнення тексту. Щоб переконатися, що ці програми працюють із очікуваним рівнем продуктивності, важливо, щоб дані в навчальному та виробничому середовищах надходили з одного розподілу. Коли дані, які використовуються для висновку (виробничі дані), відрізняються від даних, які використовуються під час навчання моделі, ми стикаємося з явищем, відомим як дрейф даних. Коли відбувається дрейф даних, модель більше не відповідає даним у виробництві та, швидше за все, працює гірше, ніж очікувалося. Важливо постійно контролювати дані висновків і порівнювати їх із даними, які використовувалися під час навчання.
Ви можете використовувати Amazon SageMaker для швидкого створення, навчання та розгортання моделей машинного навчання (ML) у будь-якому масштабі. Як профілактичний захід проти деградації моделі можна використовувати Монітор моделі Amazon SageMaker щоб постійно контролювати якість ваших моделей ML у реальному часі. За допомогою монітора моделей ви також можете налаштувати сповіщення для сповіщень і ініціювання дій, якщо спостерігається будь-який дрейф у продуктивності моделі. Раннє та проактивне виявлення цих відхилень дає змогу вживати коригувальних дій, таких як збір нових даних для наземного навчання істинності, перенавчання моделей і аудит систем, що працюють над потоком, без необхідності вручну контролювати моделі чи створювати додаткові інструменти.
Model Monitor пропонує чотири різні типи можливостей моніторингу для виявлення та пом’якшення зсуву моделі в режимі реального часу:
- Якість даних – Допомагає виявляти зміни в схемах даних і статистичних властивостях незалежних змінних і попереджає, коли виявлено дрейф.
- Якість моделі – Для моніторингу характеристик продуктивності моделі, таких як точність або точність у режимі реального часу, Model Monitor дозволяє вживати базові мітки істинності, зібрані з ваших програм. Model Monitor автоматично об’єднує наземну правдиву інформацію з прогнозованими даними для обчислення показників ефективності моделі.
- Упередження моделі – Модель Монітор інтегровано з Роз'яснити Amazon SageMaker щоб покращити видимість потенційної упередженості. Хоча ваші початкові дані чи модель можуть бути неупередженими, зміни в світі можуть з часом спричинити упередженість у моделі, яку вже навчили.
- Пояснення моделі – Виявлення дрейфу попереджає, коли відбувається зміна відносної важливості атрибутів функцій.
У цій публікації ми обговорюємо типи дрейфу якості даних, які застосовуються до текстових даних. Ми також представляємо підхід до виявлення дрейфу даних у текстових даних за допомогою монітора моделі.
Дрейф даних в НЛП
Дрейф даних можна класифікувати за трьома категоріями залежно від того, чи відбувається зрушення розподілу на вході чи на виході, чи змінилося співвідношення між входом і виходом.
Коваріативний зсув
В коваріатний зсув, розподіл входів змінюється з часом, але розподіл умовний P(y|x) не змінюється. Цей тип дрейфу називається зсувом коваріат, оскільки проблема виникає через зсув у розподілі коваріат (ознак). Наприклад, у моделі класифікації спаму електронною поштою розподіл навчальних даних (корпусів електронної пошти) може відрізнятися від розподілу даних під час оцінювання.
Зсув етикетки
У той час як коваріативний зсув фокусується на змінах у розподілі ознак, зсув мітки фокусується на змінах у розподілі змінної класу. Цей тип зсуву є, по суті, зворотним зсуву коваріат. Інтуїтивно зрозумілим способом подумати про це може бути розгляд незбалансованого набору даних. Якщо співвідношення спаму та не спаму в електронних листах у нашому навчальному наборі становить 50%, але насправді 10% наших електронних листів не є спамом, тоді розподіл цільових міток змінився.
Зміна концепції
Зміна концепції відрізняється від зсуву коваріат і міток тим, що він не пов’язаний із розподілом даних чи розподілом класів, а натомість пов’язаний зі зв’язком між двома змінними. Наприклад, спамери електронної пошти часто використовують різноманітні концепції для проходження моделей спам-фільтра, і концепція електронних листів, які використовуються під час навчання, може змінюватися з часом.
Тепер, коли ми розуміємо різні типи дрейфу даних, давайте подивимося, як ми можемо використовувати монітор моделі для виявлення коваріатного зсуву в текстових даних.
Огляд рішення
На відміну від табличних даних, які є структурованими та обмеженими, текстові дані мають складну, багатовимірну та вільну форму. Для ефективного виявлення дрейфу в НЛП ми працюємо з вбудовування, які є маловимірними представленнями тексту. Ви можете отримати вбудовування за допомогою різних мовних моделей, таких як Word2Vec, і трансформаторних моделей БЕРТ. Ці моделі проектують багатовимірні дані в низьковимірні простори, зберігаючи при цьому семантичну інформацію тексту. Результати є щільними та контекстно значущими векторами, які можна використовувати для різноманітних подальших завдань, включаючи моніторинг дрейфу даних.
У нашому рішенні ми використовуємо вбудовування, щоб виявити коваріативний зсув англійських речень. Ми використовуємо Model Monitor, щоб полегшити постійний моніторинг текстового класифікатора, який розгортається у виробничому середовищі. Наш підхід складається з наступних кроків:
- Тонке налаштування моделі BERT за допомогою SageMaker.
- Розгорніть налаштований класифікатор BERT як кінцеву точку реального часу за допомогою захоплення даних включений.
- Створіть базовий набір даних, який складається із зразків речень, які використовуються для навчання класифікатора BERT.
- Створити спеціальне завдання моніторингу SageMaker щоб обчислити косинусну подібність між даними, отриманими під час виробництва, і базовим набором даних.
Наступна схема ілюструє робочий процес рішення:
Тонке налаштування моделі BERT
У цій публікації ми використовуємо Корпус лінгвістичної прийнятності (CoLA), набір даних із 10,657 XNUMX англійських речень, позначених як граматичні чи неграматичні з опублікованої лінгвістичної літератури. Ми використовуємо навчання SageMaker для точного налаштування моделі BERT за допомогою набору даних CoLa шляхом визначення класу оцінювача PyTorch. Додаткову інформацію про те, як використовувати цей SDK із PyTorch, див Використовуйте PyTorch разом із SageMaker Python SDK. Виклик fit()
метод оцінювача запускає навчальну роботу:
Розгортання моделі
Після навчання нашої моделі ми розміщуємо її на кінцевій точці SageMaker. Щоб змусити кінцеву точку завантажувати модель і обслуговувати прогнози, ми реалізуємо кілька методів train_deploy.py:
- model_fn () - Завантажує збережену модель і повертає об’єкт моделі, який можна використовувати для обслуговування моделі. Сервер моделі SageMaker PyTorch завантажує нашу модель шляхом виклику
model_fn
. - input_fn () - Десериалізує та готує дані для прогнозування. У цьому прикладі наше тіло запиту спочатку серіалізується до JSON, а потім надсилається кінцевій точці, що обслуговує модель. Тому в
input_fn()
, ми спочатку десеріалізуємо тіло запиту у форматі JSON і повертаємо вхід як atorch.tensor
, як вимагається для BERT. - predict_fn () – Виконує прогноз і повертає результат.
Увімкнути збір даних монітора моделі
Ми вмикаємо Збір даних монітора моделі щоб записати вхідні дані в Служба простого зберігання Amazon (Amazon S3), щоб посилатися на нього пізніше:
Потім ми створюємо кінцеву точку SageMaker у реальному часі за допомогою моделі, створеної на попередньому кроці:
Висновок
Ми виконуємо прогнозування за допомогою об’єкта предиктора, створеного на попередньому кроці. Ми встановлюємо серіалізатор і десеріалізатор JSON, який використовується кінцевою точкою висновку:
Кінцева точка в реальному часі налаштована на отримання даних із запиту, а відповідь і дані зберігаються в Amazon S3. Ви можете переглянути дані, зібрані в попередньому розкладі моніторингу.
Створіть базову лінію
Ми використовуємо точно налаштовану модель BERT, щоб витягти функції вбудовування речень із навчальних даних. Ми використовуємо ці вектори як високоякісні вхідні дані для порівняння косинусної відстані, оскільки BERT створює динамічне представлення слів із семантичним контекстом. Виконайте наступні дії, щоб отримати вбудовування речення:
- Використовуйте токенизатор BERT, щоб отримати ідентифікатори маркерів для кожного маркера (
input_id
) у вхідному реченні та масці, щоб вказати, які елементи у вхідній послідовності є токенами, а не елементами заповнення (attention_mask_id
). Ми використовуємо BERTtokenizer.encode_plus
функція для отримання цих значень для кожного вхідного речення:
input_ids
та attention_mask_ids
передаються в модель і отримують приховані стани мережі. The hidden_states
має чотири виміри в такому порядку:
- Номер шару (BERT має 12 шарів)
- Номер партії (1 речення)
- Індекси токенів Word
- Приховані підрозділи (768 функцій)
- Використовуйте останні два прихованих шари, щоб отримати єдиний вектор (вбудовування речень), обчислюючи середнє значення всіх вхідних токенів у реченні:
- Перетворіть вбудоване речення як масив NumPy і збережіть його в розташуванні Amazon S3 як базову лінію, яку використовує Model Monitor:
Сценарій оцінювання
Model Monitor надає попередньо зібраний контейнер із можливістю аналізу даних, отриманих із кінцевих точок для табличних наборів даних. Якщо ви хочете привезти власний контейнер, Model Monitor надає точки розширення, якими ви можете скористатися. Коли ви створюєте a MonitoringSchedule
, монітор моделі врешті-решт починає обробку завдань. Таким чином, контейнер повинен бути в курсі контракту на обробку. Нам потрібно створити оціночний сценарій, сумісний із контейнером контрактні входи та виходи.
Model Monitor використовує код оцінки для всіх зразків, які фіксуються під час розкладу моніторингу. Для кожної точки даних висновку ми обчислюємо вбудовування речень, використовуючи ту саму логіку, що описана раніше. Косинусна подібність використовується як метрика відстані для вимірювання подібності точки даних висновку та вбудовування речень у базову лінію. Математично він вимірює косинусний кут між двома векторами вбудовування речень. Висока оцінка косинусної подібності вказує на подібні вкладення речень. Нижчий показник косинусної подібності вказує на дрейф даних. Ми обчислюємо середнє значення всіх балів косинусної подібності, і якщо воно менше за порогове значення, це фіксується у звіті про порушення. Залежно від варіанту використання ви можете використовувати інші показники відстані, наприклад manhattan
or euclidean
для вимірювання подібності вкладень речень.
На наступній діаграмі показано, як ми використовуємо моніторинг моделі SageMaker для встановлення базової лінії та виявлення дрейфу даних за допомогою косинусної подібності відстані.
Нижче наведено код для розрахунку порушень; повний сценарій оцінки доступний на GitHub:
Вимірюйте дрейф даних за допомогою Model Monitor
У цьому розділі ми зосередимося на вимірюванні дрейфу даних за допомогою Model Monitor. Model Monitor Попередньо побудовані монітори працюють від Deequ, яка є бібліотекою, створеною на основі Apache Spark для визначення модульних тестів для даних, які вимірюють якість даних у великих наборах даних. Вам не потрібно кодувати, щоб використовувати ці попередньо створені можливості моніторингу. Ви також маєте гнучкість моніторингу моделей за допомогою кодування, щоб надати індивідуальний аналіз. Ви можете збирати та переглядати всі показники, які видає Model Monitor у Студія Amazon SageMaker, щоб ви могли візуально аналізувати продуктивність своєї моделі без написання додаткового коду.
У певних сценаріях, наприклад, коли дані не є табличними, завдання обробки за замовчуванням (на основі Deequ) недостатньо, оскільки він підтримує лише табличні набори даних. Попередньо створених моніторів може бути недостатньо для генерації складних показників для виявлення дрейфів, і може виникнути потреба в застосуванні власних показників. У наступних розділах ми опишемо налаштування, щоб отримати ваші показники шляхом створення спеціального контейнера.
Створіть спеціальний контейнер Model Monitor
Ми використовуємо сценарій оцінки з попереднього розділу, щоб створити контейнер Docker і надіслати його Реєстр контейнерів Amazon Elastic (Amazon ECR):
Коли клієнтський контейнер Docker знаходиться в Amazon ECR, ми можемо запланувати завдання моніторингу моделі та створити звіт про порушення, як показано в наступних розділах.
Заплануйте завдання моніторингу моделі
Щоб запланувати завдання моніторингу моделі, ми створюємо екземпляр Model Monitor і в image_uri
, ми звертаємося до контейнера Docker, який ми створили в попередньому розділі:
Ми плануємо завдання моніторингу за допомогою create_monitoring_schedule
API. Ви можете запланувати завдання моніторингу на погодинній або щоденній основі. Ви налаштовуєте завдання за допомогою destination
параметр, як показано в наступному коді:
Для опису та списку розкладу моніторингу та його запусків ви можете використовувати наступні команди:
Звіт про порушення дрейфу даних
Коли завдання моніторингу моделі завершено, ви можете перейти до цільового шляху S3, щоб отримати доступ до звітів про порушення. Цей звіт містить усі вхідні дані, середній косинусний бал (avg_cosine_score
) нижче порогового значення, налаштованого як змінна середовища THRESHOLD:0.5
в МодельМонітор екземпляр. Це вказує на те, що дані, отримані під час висновку, виходять за межі встановленої базової лінії.
Наступний код показує згенерований звіт про порушення:
Нарешті, на основі цього спостереження ви можете налаштувати свою модель для перенавчання. Ви також можете включити Служба простих сповіщень Amazon (Amazon SNS) для надсилання сповіщень про порушення.
Висновок
Model Monitor дозволяє підтримувати високу якість ваших моделей у виробництві. У цій публікації ми висвітлили труднощі, пов’язані з моніторингом дрейфу даних у неструктурованих даних, як-от текст, і запропонували інтуїтивно зрозумілий підхід для виявлення дрейфу даних за допомогою спеціального сценарію моніторингу. Нижче наведено код, пов’язаний із публікацією GitHub сховище. Крім того, ви можете налаштувати рішення для використання інших показників відстані, наприклад максимальне середнє розбіжність (MMD), непараметрична метрика відстані для обчислення граничного розподілу між вихідним і цільовим розподілом у вбудованому просторі.
Про авторів
Вікрам Еланго є архітектором AI/ML Specialist Solutions в Amazon Web Services, що базується у Вірджинії, США. Vikram допомагає клієнтам фінансової та страхової галузі за допомогою дизайну та інтелектуального лідерства для створення та розгортання програм машинного навчання в масштабі. Зараз він зосереджений на обробці природної мови, відповідальному штучному інтелекті, оптимізації висновків і масштабуванні ML на підприємстві. У вільний час він любить подорожувати, піти в походи, готувати їжу та кемпінг зі своєю сім’єю.
Рагу Рамеша є архітектором рішень ML у команді Amazon SageMaker Service. Він зосереджується на тому, щоб допомогти клієнтам масштабно перенести робочі навантаження ML на SageMaker. Він спеціалізується на машинному навчанні, штучному інтелекті та комп’ютерному зорі, а також має ступінь магістра комп’ютерних наук в UT Dallas. У вільний час захоплюється подорожами та фотографією.
Тоні Чен є архітектором рішень машинного навчання в Amazon Web Services, який допомагає клієнтам розробляти масштабовані та надійні можливості машинного навчання в хмарі. Як колишній фахівець із обробки даних та інженер з даних, він використовує свій досвід, щоб допомогти вирішити деякі з найскладніших проблем, з якими стикаються організації під час впровадження машинного навчання.
- '
- "
- 100
- 11
- 7
- МЕНЮ
- доступ
- рахунки
- через
- дії
- Додатковий
- AI
- ВСІ
- вже
- хоча
- Amazon
- Amazon SageMaker
- Amazon Web Services
- аналіз
- Apache
- Apache Spark
- застосовно
- застосування
- доступний
- середній
- AWS
- Базова лінія
- тіло
- будувати
- Створюємо
- кемпінг
- випадків
- Викликати
- проблеми
- зміна
- chatbots
- класифікація
- хмара
- код
- Кодування
- Збір
- комплекс
- обчислення
- Інформатика
- Комп'ютерне бачення
- Контейнер
- містить
- безперервний
- контракт
- приготування
- створення
- Клієнти
- Даллас
- дані
- якість даних
- вчений даних
- дизайн
- Виявлення
- розвивати
- різний
- обговорювати
- відстань
- Docker
- Докер-контейнер
- Ні
- домени
- водіння
- під час
- динамічний
- Рано
- зіткнення
- Кінцева точка
- інженер
- англійська
- підприємство
- Навколишнє середовище
- встановлений
- приклад
- досвід
- Face
- сім'я
- особливість
- риси
- фінансовий
- Перший
- Гнучкість
- Сфокусувати
- увагу
- форма
- Вперед
- Безкоштовна
- функція
- породжувати
- GitHub
- має
- допомога
- допомагає
- Високий
- Виділено
- піший туризм
- Головна
- Як
- How To
- HTTPS
- зображення
- здійснювати
- важливо
- У тому числі
- промисловість
- інформація
- страхування
- галузь страхування
- IT
- робота
- Джобс
- етикетки
- мова
- великий
- останній
- запуски
- Керівництво
- вивчення
- рівень
- важелі
- бібліотека
- лінгвістика
- список
- літератури
- загрузка
- розташування
- навчання за допомогою машини
- машинний переклад
- маска
- вимір
- Метрика
- ML
- модель
- Моделі
- моніторинг
- більше
- Природна мова
- Обробка природних мов
- мережу
- nlp
- сповіщення
- Пропозиції
- порядок
- організації
- Інше
- продуктивність
- малюнок
- Точність
- прогноз
- Прогнози
- представити
- Проблема
- Production
- проект
- забезпечувати
- забезпечує
- Python
- піторх
- якість
- діапазон
- реального часу
- Реальність
- запис
- звітом
- Звіти
- відповідь
- результати
- перепідготовка
- Умови повернення
- зворотний
- огляд
- прогін
- біг
- мудрець
- шкала
- Масштабування
- наука
- Sdk
- Послуги
- виступаючої
- комплект
- зсув
- аналогічний
- простий
- So
- Рішення
- Простір
- пробіли
- спам
- спеціалізується
- Штати
- зберігання
- зберігати
- Опори
- Systems
- Мета
- тест
- Тестування
- Тести
- світ
- думка
- думка лідерства
- час
- знак
- Жетони
- топ
- факел
- трафік
- Навчання
- Переклад
- USA
- вид
- Віргінія
- Віртуальний
- видимість
- бачення
- чекати
- Web
- веб-сервіси
- Вікіпедія
- без
- Work
- робочий
- світ
- лист