Amazon Comprehend оголошує про нижчі обмеження анотацій для розпізнавання власних об’єктів

«Амазонка» це служба обробки природної мови (NLP), яку можна використовувати для автоматичного вилучення сутностей, ключових фраз, мови, настроїв та інших відомостей із документів. Наприклад, ви можете негайно почати виявляти такі сутності, як люди, місця, комерційні товари, дати та кількість за допомогою Консоль Amazon Comprehend, Інтерфейс командного рядка AWSабо API Amazon Comprehend. Крім того, якщо вам потрібно витягти сутності, які не є частиною Вбудовані типи сутностей Amazon Comprehend, ви можете створити спеціальну модель розпізнавання сутності (також відому як настроювана сутність розпізнавальник), щоб отримати терміни, які більше відповідають вашому конкретному випадку використання, як-от назви елементів із каталогу продуктів, ідентифікатори домену тощо. Самостійне створення точного розпізнавача сутностей за допомогою бібліотек і фреймворків машинного навчання може бути складним і трудомістким процесом. Amazon Comprehend значно спрощує роботу з навчання моделі. Все, що вам потрібно зробити, це завантажити свій набір даних документів і анотацій і використовувати консоль Amazon Comprehend, AWS CLI або API для створення моделі.

Щоб навчити користувацький засіб розпізнавання сутностей, ви можете надати навчальні дані в Amazon Comprehend as анотації або списки об’єктів. У першому випадку ви надаєте колекцію документів і файл із анотаціями, які вказують розташування сутностей у наборі документів. Крім того, за допомогою списків сутностей ви надаєте список сутностей із відповідними мітками типу сутності та набір документів без анотацій, у яких ви очікуєте присутність ваших сутностей. Обидва підходи можуть бути використані для навчання успішної спеціальної моделі розпізнавання сутності; однак є ситуації, коли один метод може бути кращим вибором. Наприклад, якщо значення певних сутностей може бути неоднозначним і залежати від контексту, рекомендується надавати анотації, оскільки це може допомогти вам створити модель Amazon Comprehend, яка здатна краще використовувати контекст під час вилучення сутностей.

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

До сьогодні, щоб розпочати навчання користувацького розпізнавання сутностей Amazon Comprehend, вам потрібно було надати колекцію щонайменше 250 документів і мінімум 100 анотацій для кожного типу сутності. Сьогодні ми оголошуємо, що завдяки нещодавнім удосконаленням моделей, які лежать в основі Amazon Comprehend, ми зменшили мінімальні вимоги до навчання розпізнавача за допомогою файлів анотацій CSV із простим текстом. Тепер ви можете створити спеціальну модель розпізнавання сутності лише з трьома документами та 25 анотаціями для кожного типу сутності. Додаткову інформацію про нові ліміти послуг можна знайти в Інструкції та квоти.

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

Підготовка набору даних

У цій публікації ми пояснюємо, як ми навчили спеціальний розпізнавач сутностей Amazon Comprehend за допомогою анотованих документів. Загалом, анотації можна надавати як a Файл CSV, доповнений файл маніфесту, створений Ground TruthАбо PDF файл. Наша увага зосереджена на анотаціях із звичайним текстом CSV, оскільки саме на цей тип анотацій впливають нові мінімальні вимоги. Файли CSV повинні мати таку структуру:

File, Line, Begin Offset, End Offset, Type
documents.txt, 0, 0, 13, ENTITY_TYPE_1
documents.txt, 1, 0, 7, ENTITY_TYPE_2

Відповідні поля:

• філе – Ім’я файлу, що містить документи
• Лінія – Номер рядка, що містить сутність, починаючи з рядка 0
• Починати Зсув – Зсув символу у вхідному тексті (відносно початку рядка), який показує, де починається сутність, враховуючи, що перший символ знаходиться в позиції 0
• Кінцевий зсув – Зсув символу у вхідному тексті, який показує, де закінчується сутність
• тип – Ім’я типу об’єкта, який потрібно визначити

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

Для наших тестів ми використовували Еталонний тест розуміння природної мови SNIPS, набір даних краудсорсингових висловлювань, розподілених серед семи намірів користувачів (AddToPlaylist, BookRestaurant, GetWeather, PlayMusic, RateBook, SearchCreativeWork, SearchScreeningEvent). Набір даних був опублікований у 2018 році в контексті статті Голосова платформа Snips: вбудована система розуміння розмовної мови для індивідуальних голосових інтерфейсів Coucke та ін.

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

{
   "annotations":{
      "named_entity":[
         {
            "start":16,
            "end":36,
            "extent":"within the same area",
            "tag":"spatial_relation"
         },
         {
            "start":40,
            "end":51,
            "extent":"Lawrence St",
            "tag":"poi"
         },
         {
            "start":67,
            "end":70,
            "extent":"one",
            "tag":"party_size_number"
         }
      ],
      "intent":"BookRestaurant"
   },
   "raw_text":"I'd like to eat within the same area of Lawrence St for a party of one"
}

Перш ніж створити наш засіб розпізнавання сутностей, ми перетворили анотації SNIPS і необроблені текстові файли у файл анотацій CSV і файл документів .txt.

Нижче наведено уривок із нашого annotations.csv Файл:

File, Line, Begin Offset, End Offset, Type
documents.txt, 0, 16, 36, spatial_relation
documents.txt, 0, 40, 51, poi
documents.txt, 0, 67, 70, party_size_number

Нижче наведено уривок із нашого documents.txt Файл:

I'd like to eat within the same area of Lawrence St for a party of one
Please book me a table for three at an american gastropub 
I would like to book a restaurant in Niagara Falls for 8 on June nineteenth
Can you book a table for a party of 6 close to DeKalb Av

Конфігурація вибірки та процес порівняльного аналізу

У наших експериментах ми зосередилися на підмножині типів об’єктів із набору даних SNIPS:

• BookRestaurant – Типи об’єктів: spatial_relation, poi, party_size_number, restaurant_name, city, timeRange, restaurant_type, served_dish, party_size_description, country, facility, state, sort, cuisine
• Отримати погоду – Типи об’єктів: condition_temperature, current_location, geographic_poi, timeRange, state, spatial_relation, condition_description, city, country
• Грати музику – Типи об’єктів: track, artist, music_item, service, genre, sort, playlist, album, year

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

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

Щоб виміряти точність наших моделей, ми зібрали оціночні показники, які Amazon Comprehend автоматично обчислює під час навчання засобу розпізнавання об’єктів:

• Точність – Це вказує на частку об’єктів, виявлених розпізнавачем, які правильно ідентифіковано та позначено. З іншої точки зору точність можна визначити як tp / (tp + fp), Де tp це кількість справжніх позитивних результатів (правильних ідентифікацій) і fp це кількість помилкових спрацьовувань (невірних ідентифікацій).
• Згадувати – Це вказує на частку об’єктів, присутніх у документах, які правильно ідентифіковано та позначено. Розраховується як tp / (tp + fn), Де tp є число істинних позитивних і fn це кількість помилкових негативів (пропущених ідентифікацій).
• F1 бал – Це комбінація показників точності та запам’ятовування, яка вимірює загальну точність моделі. Оцінка F1 — це гармонійне середнє показників точності та запам’ятовування, яке розраховується як 2 * Точність * Відкликання / (Точність + Відкликання).

Для порівняння продуктивності наших засобів розпізнавання сутностей ми зосереджуємося на показниках F1.

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

результати

У наведеній нижче таблиці показано мікроусереднені показники F1, обчислені на основі показників продуктивності, отриманих Amazon Comprehend після навчання кожного засобу розпізнавання сутностей.

Наступна стовпчаста діаграма показує розподіл балів F1 для дев’яти конфігурацій, які ми навчили, як описано в попередньому розділі.

Ми можемо помітити, що нам вдалося успішно навчити користувальницькі моделі розпізнавання сутностей навіть із лише 25 анотаціями на тип сутності. Якщо ми зосередимося на трьох найменших підвибіркових наборах даних (snips-BookRestaurant-subsample-A, snips-GetWeather-subsample-A та snips-PlayMusic-subsample-A), ми бачимо, що в середньому нам вдалося досягти показника F1 у 84%, що є досить хорошим результатом, враховуючи обмежену кількість документів і анотацій, які ми використовували. Якщо ми хочемо покращити продуктивність нашої моделі, ми можемо зібрати додаткові документи та анотації та навчити нову модель з більшою кількістю даних. Наприклад, з підвибірками середнього розміру (snips-BookRestaurant-subsample-B, snips-GetWeather-subsample-B та snips-PlayMusic-subsample-B), які містять вдвічі більше документів і анотацій, ми отримали в середньому оцінку F1 88% (5% покращення щодо subsample-A набори даних). Нарешті, більші набори даних підвибірки (snips-BookRestaurant-subsample-C, snips-GetWeather-subsample-C та snips-PlayMusic-subsample-C), які містять навіть більше анотованих даних (приблизно в чотири рази більше, ніж кількість документів і анотацій, використовуваних для subsample-A набори даних), забезпечили подальше покращення на 2%, підвищивши середній бал F1 до 90%.

Висновок

У цій публікації ми оголосили про зниження мінімальних вимог для навчання користувацьких засобів розпізнавання сутностей за допомогою Amazon Comprehend і провели деякі контрольні тести на наборах даних з відкритим кодом, щоб показати, як це зниження може допомогти вам розпочати роботу. Відсьогодні ви можете створити модель розпізнавання сутності лише з 25 анотаціями на тип сутності (замість 100) і принаймні з трьома документами (замість 250). Завдяки цьому оголошенню ми знижуємо бар’єр доступу для користувачів, зацікавлених у використанні спеціальної технології розпізнавання об’єктів Amazon Comprehend. Тепер ви можете розпочати експерименти з дуже невеликою колекцією анотованих документів, проаналізувати попередні результати та повторити, включивши додаткові анотації та документи, якщо вам потрібна більш точна модель розпізнавання сутностей для вашого випадку використання.

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

Особлива подяка моїм колегам Джоті Бансалу та Джі Ма за їхню безцінну допомогу в підготовці даних і порівняльному аналізі.

Про автора

Лука Гіда є архітектором рішень в AWS; він живе в Мілані та підтримує італійських незалежних постачальників програмного забезпечення в їхній хмарній подорожі. Маючи академічну освіту в області інформатики та інженерії, він почав розвивати свою пристрасть до ШІ/ML ​​в університеті. Як член спільноти обробки природної мови (NLP) в AWS, Luca допомагає клієнтам досягти успіху під час впровадження послуг AI/ML.