Редакционный отдел The Heart of the Machine, Чи Леджун.
Недавно AllenNLP поделился темой на EMNLP2018 под названием «Написание кода для исследований НЛП» (Writing Code for NLP Research). Выступление познакомило с тем, как копировать чужой код, тестировать блоки собственного кода, записывать и делиться исследованиями в области НЛП с точки зрения написания прототипов и написания модулей, практическим опытом.
В этом содержании полно галантереи. Просто взглянув на слайд, я знаю, что это очень интересная речь. Всего на слайде 254 страницы.На основе контента, опубликованного в колонке Чжиху «Чи Лецзюнь», сердце машины представляет собой руководство по программированию для исследователей НЛП и глубокого обучения.
Читатели могут напрямую загрузить PPT, чтобы узнать больше о деталях.На каждой странице PPT есть краткие примечания, согласно которым все PPT и все выступление могут быть связаны вместе.
ссылка для скачивания:disk.baidu.com/is/1G4RY JZ9J…
Чи Леджун знает колонку:zhuanlan.zhihu.com/p/48504619
Ниже приведен план всего обмена. Благодаря этому выступлению вы узнаете, как писать код, облегчающий ваши исследования, а также проводить воспроизводимые эксперименты. Конечно, читателям лучше немного узнать о НЛП, потому что в этом разделе в качестве примера будет использоваться проблема НЛП в глубоком обучении. Кроме того, умение приблизительно читать код Python также является хорошим фоном.В этой статье в качестве примера используется интерфейс Python для вызова среды DL.
Существует два шаблона написания исследовательского кода: один — написание прототипов, а другой — написание компонентов. Как исследователь, большую часть времени мы хотим писать прототипы, но мы не можем создавать хорошие прототипы без написания компонентов. А благодаря прототипированию иногда создается компонент, который вы хотите повторно использовать в следующий раз. Итак, это два режима написания кода, они не являются независимыми.
Начнем с того, как написать прототип.
написать прототип
Когда мы начинаем писать код прототипа, нам нужно сделать следующие три вещи.
1. Пишите код быстро
2. Отслеживайте результаты экспериментов
3. Анализ результатов модели
быстрое развитие
Чтобы быстро программировать, не пишите все с нуля, а используйте фреймворк. Фреймворк здесь не только относится к таким фреймворкам, как tensorflow или pytorch, но также может пониматься как шаблоны. Например, если вы напишите часть тренировочного цикла на приведенном выше рисунке, значит, кто-то уже написал ее. Пока мы его понимаем, мы можем использовать его напрямую, нет необходимости писать все части с нуля.
Некоторый контент, упомянутый выше, можно найти в готовых фреймворках для применения. Часто проблема, с которой мы сталкиваемся при программировании, заключается не в построении модели, а в таких частях, как чтение данных, предварительная обработка и запись обучающих циклов. Если кто-то разбивает на модули что-то, что вы хотите использовать, чего вы ждете, используйте это напрямую!
Конечно, есть шаги для его использования.Во-первых, мы должны получить производительность базовой модели, что также является хорошей исследовательской практикой. Базовая модель может быть чужим кодом, и лучше, если вы сможете ее модифицировать. Во-вторых, воспроизведение базовых результатов SOTA очень полезно для понимания модели и проведения дополнительных исследований.
Еще одно предложение для быстрой разработки — сначала копировать, а затем рефакторить. Помните, что мы создаем прототип, не заботьтесь об удобстве использования, просто сначала напишите код, который будет работать. Если реализация работает хорошо, вернитесь и проведите рефакторинг.
Кроме того, у нас должны быть хорошие привычки программирования. Например, делайте осмысленные имена переменных и пишите комментарии, чтобы облегчить понимание. Помните, мы пишем для людей, а не для машин! Кроме того, при экспериментировании с базовой моделью теперь мы можем протестировать ее на небольшом наборе данных и убедиться, что модель может точно считывать данные.
Если мы жестко кодируем LSTM при прототипировании, нам нужно перекодировать, когда мы хотим использовать такие модули, как Transformer. Таким образом, использование полиморфизма может расширить код с более высокой абстракцией, так что при смене модулей можно будет изменить только небольшой объем кода.
Отслеживание результатов эксперимента
При прототипировании вам нужно запускать много вещей, что затрудняет отслеживание того, что происходит, и соответствующих частей кода.
Таблица Excel может быть подготовлена для записи экспериментальных результатов.
Сравнение методом «черного ящика» полезно для контекстуального понимания, но не дает понимания взаимосвязи между двумя результатами, потому что слишком много переменных изменяется одновременно. Нам нужно изменить только одну переменную за раз, мы можем установить «переключатели» в коде, чтобы настроить переключатели с некоторой глобальной инъекцией состояния/зависимости.
Изменяйте только одну деталь за раз, что упрощает отслеживание причин изменений результатов эксперимента.
Вот просто встраивайте, у нас много вариантов.
Используйте файл настроек для записи изменений в модели, чтобы мы могли запросить текущие настройки позже.
Анализ результатов модели
Во время обучения визуализация очень важна для анализа производительности модели. Это умение необходимо освоить.
Tensorboard может предоставить множество результатов анализа.
Tensorboard может помочь нам найти ошибки оптимизации. Например, градиент встраивания на приведенном выше рисунке отличается на два порядка.
Причина в том, что градиент встраивания является разреженным градиентом, то есть будет обновляться только часть. Но импульсный коэффициент в ADAM рассчитывается для всего встраивания, поэтому решение состоит в том, чтобы напрямую ввести конкретный оптимизатор: DenseSparseAdam.
При интерпретации прогнозируемых результатов вашей модели хорошее представление — это статический прогноз, лучшее представление — это интерактивный взгляд на прогнозы, лучшая презентация — это интерактивный взгляд на внутренний процесс.
Для результатов прогнозирования лучше всего, если вы можете просматривать их в интерактивном режиме.
компоненты разработки
В отличие от написания прототипов, при разработке повторно используемых компонентов существует множество предостережений. Наш код должен быть написан ясно, чтобы мы могли сосредоточиться на моделировании решений, не думая о том, что делает код.
Проверка кода необходима. При рецензировании можно не только найти ошибки, но и улучшить читаемость кода.
Если мы не разработчики программного обеспечения, термины непрерывная интеграция и автоматизация сборки могут быть вам незнакомы. Обычно, когда мы говорим только о непрерывной интеграции, мы также имеем в виду автоматизацию сборки. Для этого нужно написать больше тестов.
Конечно, в этих шагах не было бы необходимости, если бы мы не разрабатывали библиотеку, которой могли бы пользоваться многие люди. Тем не менее, тестирование очень важно, и если это прототипирование, необходимо также провести некоторые базовые тесты.
Проверьте считанные данные, как указано выше, чтобы убедиться, что они верны. Оператор assert обычно используется в модульном тестировании здесь.Если есть проблема с программой, она, естественно, сообщит об ошибке при запуске здесь, чтобы мы могли найти ошибку как можно скорее.
Как показано выше, конечно, мы также можем использовать оператор assert для проверки согласованности размеров. Это часто используется в части работы с моделью, например, для оценки размера и глубины выходных данных каждого сверточного слоя. Вы можете видеть, что кода для обоих тестов не так много. Так что не ленитесь и пишите свои тесты хорошо.
Некоторые введения в библиотеку AllenNLP здесь обсуждаться не будут.Если вам интересно, вы можете прочитать части p141~p205 на слайде. Перейдите непосредственно к разделу обмена ниже.
поделиться исследованием
Упростите процесс установки, позвольте коду работать на любой платформе и используйте изолированную среду.
Ниже приведены некоторые преимущества использования Docker.
Излишне говорить, что преимущества разработки с помощью docker уже всем известны. Конечно, есть и недостатки.
Что касается системы управления пакетами Python, AllenNLP использует ANACONDA.
Докер хорош, но он не подходит для локальной разработки, поэтому удобнее использовать какую-нибудь локальную систему управления пакетами.
Наконец сделайте вывод.
Быстрое прототипирование (будьте в безопасности)
Напишите безопасный код продукта (будьте быстрыми)
Хорошие процессы способствуют хорошему исследованию
Используйте правильную абстракцию
Посмотреть AllenNLP (Реклама)
Я несколько раз читал слайд, которым поделились на этот раз, и вижу, как мое лицо становится горячим во многих местах, и я упомянул о проблеме, не написав тестов. В настоящее время требования к инженерам-алгоритмистам в области искусственного интеллекта уже не являются мешком, это так же просто, как говорить об исследованиях, и все более важными становятся навыки инженерной практики. Написание хорошего кода и хорошее исследование — взаимодополняющие процессы.