Обзор олимпиады AIIJC 2021 и разбор задачи трека NLP

МЕНЮ


Главная страница
Поиск
Регистрация на сайте
Помощь проекту
Архив новостей

ТЕМЫ


Новости ИИРазработка ИИВнедрение ИИРабота разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика

Авторизация



RSS


RSS новости


Сегодня я хочу рассказать о своем опыте участия в соревновании Artificial Intelligence International Junior Contest и о решении моей команды, которое заняло первое место в треке NLP.

Немного про AIIJC

AIIJC - это, пожалуй, крупнейшее соревнование в сфере искусственного интеллекта в России (а то и в мире) среди молодежи, а точнее - среди несовершеннолетних. Именно это (помимо весьма солидного призового фонда в 13 миллионов рублей) является отличительной чертой данного мероприятия. ИИ, на мой взгляд, является самой передовой технологией на текущий момент, однако ее популяризации уделяется слишком мало внимания, учитывая ее сложность, на более-менее масштабную популяризацию среди несовершеннолетних даже и рассчитывать не стоило, если бы не Сбер. При поддержке Сбера ежегодно организуется трек по ИИ олимпиады НТО, а в 2021 году впервые была организована олимпиада AIIJC в качестве детского трека соревнований в рамках международной конференции AIJ. Итак, в чем же особенности соревнования:

  • Олимпиада длилась весьма долго и включала в себя 3 этапа: квалификационный, командный и финальный;

  • Пройти квалификационный этап можно было с весны вплоть до начала октября (в общем, пройти его хватило бы времени даже у самого загруженного человека на Земле, было бы желание), он состоял из двух задач: бинарной классификации изображений на сделанные человеком и сгенерированные ИИ и бинарной классификации пар текстов на разных языках на пары с причинно-следственной связью и без нее. Для успешного прохождения этапа достаточно было сдать решение хотя бы одной задачи на определенный балл, я выбрал задачу с парами текстов, в итоге мой результат оказался лучшим среди 245 других участников, сдавших решение к этой задаче. Задача с картинками оказалась более популярной, ее пробовали сдать 526 человек;

  • Командный этап состоял из 10 треков, необходимо было выбрать один трек (сменить потом его нельзя), собрать команду 3-5 человек и, собственно, решить задачу (времени давалось тоже предостаточно: с начала лета до начала октября). Треки на выбор: ИИ в робототехнике, ИИ в транспорте, ИИ в геосервисах, ИИ в медицине, инклюзивная среда, подбор персонала, обработка естественного языка (NLP), ИИ в нейромаркетинге, ИИ в образовании и креативные индустрии. Последний из треков был одним из самых нестандартных и сложных (было необходимо создать алгоритм, который генерирует мультфильм с озвучкой и музыкой по текстовой строке и заданному жанру), мы же участвовали в треке NLP, о котором подробнее расскажу ниже;

  • В финальный этап проходили топ-5 команд из каждого трека, сам финал длился неделю, необходимо было усовершенствовать свое решение, в помощь командам выделялись эксперты в соответствующих задачам областях;

  • Награждение победителей проходило в рамках конференции AIJ, самые ценные призы в виде денег, сертификатов на обучение и даже стажировки в Сбере получали топ-1 каждого трека. Помимо различных нетворкингов для финалистов была проведена экскурсия в новом головном офисе Сбера, а также все абсолютные победители приняли участие в пленарном заседании с личным участием Владимира Владимировича Путина;

  • 118 команд принимало участие в командном этапе;

  • 45 команд вышло в финал из России, Беларуси, Украины, Индии, Азербайджана, Вьетнама, Казахстана, Кыргызстана, Пакистана и Таиланда.

Теперь некоторый бекграунд представлен, все несколько удивились молодежной политике Сбера, можно перейти к разбору нашей задачи.

Обзор задачи трека NLP

1. Суть проблемы

Проблема заключается в отсутствии в открытом доступе каких-либо качественных доступных инструментов для решения задачи ODQA (Open Domain Question Answering), проще говоря, ответы на вопросы без заданного контекста.

Схема работы ODQA-систем в общем виде. Ranker отвечает за поиск необходимого количества релевантных документов в базе знаний, Reader выполняет поиск ответа среди найденных документов.
Схема работы ODQA-систем в общем виде. Ranker отвечает за поиск необходимого количества релевантных документов в базе знаний, Reader выполняет поиск ответа среди найденных документов.

2. Обзор готовых решений

Из абзаца выше может сложиться впечатление, что открытых решений вообще нет, но нет, все же есть:

Сравнение качества и производительности ODAQ-решений на тестовом наборе вопросов от AIIJC. Результаты нашей модели и модели ORQA представлены с учетом дообучения отдельных частей решения.
Сравнение качества и производительности ODAQ-решений на тестовом наборе вопросов от AIIJC. Результаты нашей модели и модели ORQA представлены с учетом дообучения отдельных частей решения.
  1. DrQA от Facebook. В 2017 году разрабатывалась Facebook в качестве модели, способной обрабатывать длинные тексты в рамках QA-систем. Работа с библиотекой не дала удовлетворяющие нас результаты

  2. ODQA от DeepPavlov. Ranker этой модели основан на DrQA. Имеет достоточно туториалов, но вот на ее тренировку под определенную задачу понадобится 24 гигабайта RAM. На наших тестах показала невысокую точность без дообучения, но самую большую производительность.

  3. ORQA от Google. Туториалов по ней нет (по крайней мере так просто не найдешь), точность на наших данных также невысока.

3. Анализ датасета

Тренировочный датасет содержал 4000 пар сгенерированных вопросов и ответов на основе англоязычной википедии, большая часть вопросов начиналась с Who/What/Where/When, т.е. это были фактологические вопросы с определенным лаконичным ответом. Но и в этом датасете не без выбросов (вопросы наподобие "Какая улица названа в честь?" или вопросы, на которые даже вручную ответа не найти), но выбросы в итоге нам не сильно помешали.

4. Разработка архитектуры

Учитывая, что все ответы на вопросы можно было найти на Википедии, то изначально мы хотели сделать Ranker на основе библиотеки wikipedia, но эксперимент оказался не очень удачным: вероятность нахождения сета из 5 статей, где хотя бы в одной будет содержаться дословный ответ, была около 0.4. Наша первая версия Reader'а выделяла из найденных статей фрагмент с медианной длиной 394, где содержался верный ответ, с вероятностью 0.6654, и QA-модель верно отвечала на вопрос (при условии, что верный ответ есть во фрагменте) с вероятностью более 0.95.

5. Ranker

Очевидным был факт, что поиск статей через библиотеку wikipedia - не лучший вариант (потому что алгоритмы википедии плохо ищут статьи самой же себя), и у нас было два других пути: или скачать dump Википедии и попробовать реализовать свой reader/дообучить существующий на основе свежих данных, или использовать сторонние поисковые решения. Из-за трудозатратности и ресурсоемкости первого варианта (хотя он предпочтительнее) мы перешли ко второму, а именно: написали свою библиотеку на основе библиотеки wikipedia и google search engine, где искали топ-2 самых релевантных статей (в менее релевантных статьях вероятность существования верного ответа крайне мала). Единственный, но существенный минус данного решения - ограничения на количество бесплатных запросов в день. Итоговая вероятность найти статью с дословным ответом - 0.5, но все на самом деле лучше, учитывая наличие выбросов в датасете и тот факт, что ответ модели мог не совпадать с эталонным, однако все еще являться верным.

6. Reader

Reader у нас состоит из двух частей: выделение небольшого фрагмента из найденных статей, в котором с наибольшей вероятностью лежит верный ответ, и поиск ответа во фрагменте с помощью дообученной модели bert-large-cased-whole-word-masking-finetuned-squad. Алгоритм выделения фрагмента у нас линейный (к сожалению, опять же по причине трудозатратности реализации ML-модели) с использованием токенов, выделенных из текста. Итоговая точность верного выделения фрагмента - 0.734, точность работы qa-модели - 0.9912.

7. Итоговое описание архитектуры решения

Команда

Шакал quality, но нам было не до хороших фотографий
Шакал quality, но нам было не до хороших фотографий

Команда состояла из 3 человек:

  • Владимир Воробьев, г. Москва (github, ВК);

  • Максим Кузнецов, г. Москва (github, ВК);

  • Данил Астафуров, г. Саратов (github, ВК).

Итог

Визуализация нашего решения
Визуализация нашего решения

Получившееся решение можно использовать, например, для создания бота или для автоматизации службы поддержки каких-нибудь ресурсов, у которых уже есть база знаний, на ее основе можно несколько доработать Ranker и при необходимости Reader. Лучший результат на лидерборде: F1 - 0.3548.

В настоящее время я прохожу обучение на курсе Machine Learning. Professional от OTUS и хочу порекомендовать всем бесплатный урок по теме: "Natural language processing: как компьютер общается с людьми", который пройдет 16 февраля. А тем, кто только начинает свой путь в машинном обучении рекомендую рассмотреть специализацию ML.


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

Комментарии: