Почему и что
Нашим самым большим источником замешательства была «письменность» семоногих. Похоже, что он вообще не писал; это больше походило на набор замысловатых графических дизайнов. Логограммы не были расположены рядами, спиралью или каким-либо линейным образом. Вместо этого Flapper или Raspberry писали предложение, склеивая столько логограмм, сколько нужно, в гигантское скопление.
Эти строки из новеллы Теда Чанга «История вашей жизни», возможно, дают хорошее представление о том, что отличает архитектуры, основанные на внимании, от последовательной природы ванильных RNN.
Давайте кратко рассмотрим стандартные RNN и варианты кодировщика-декодера, используемые в последовательности для упорядочивания задач, разберемся, какие недостатки имеют эти конструкции, и посмотрим, как механизмы внимания устраняют их.
Основная предпосылка стандартной RNN состоит в том, чтобы анализировать каждый элемент входной серии один за другим и постоянно обновлять его вектор «скрытого состояния» на каждом этапе пути, как показано на рисунке 1. Считается, что этот скрытый вектор в конце каждого шага представляет контекст всех предыдущих входных данных. Другими словами, последнее скрытое состояние представляет собой контекст всей последовательности.
В соответствии с задачами трансляции последовательности эта RNN, представляющая скрытое состояние, считается кодировщиком, а конечный вектор скрытого состояния, называемый «контекстом» на рисунке 2, передается в другую последовательность. создание RNN называется декодером.
Но важен ли такой последовательный характер обработки или он ставит нас в невыгодное положение? Есть языки, в которых порядок слов не имеет особого значения, как в польском и венгерском. Или даже в английском, где мы можем изменить порядок слов в зависимости от того, что мы хотим подчеркнуть. Иногда даже в практических приложениях, например, при обработке истории болезни пациента в моделях прогнозирования диагноза, взаимосвязи между событиями не менее, если не более важны, чем сама последовательность событий.
Интуитивно говоря, этот строгий порядок обработки, возможно, сродни сглаживанию двумерного изображения, то есть преобразованию из матрицы в вектор и использованию стандартной сети с прямой связью для его обработки. Он намного менее эффективен по сравнению с архитектурами CNN, которые сохраняют естественные пространственные отношения в матричном представлении (конечно, в отличие от изображения, мы не знаем, существует ли правильный порядок и что это за порядок. Вот и все!). строгая последовательная природа обработки, возможно, является первым недостатком.
Именно здесь LSTM и GRU сильно помогли, предоставив способ передачи только актуальной информации от одного шага к следующему с помощью различных нововведений на уровне ячеек, таких как забыть шлюз, сбросить шлюз, обновить шлюз и т. Д. Двунаправленные RNN предоставили механизм для просмотра не только предыдущие, но и последующие входные данные перед генерацией выходных данных на временном шаге. Такие разработки направлены на решение «строго последовательной» проблемы, но не совсем решают следующую задачу.
Чем больше длина входной последовательности (то есть длина предложения в НЛП), тем труднее скрытому вектору уловить контекст (пояснительные гипотезы, предложенные Чо и др. Здесь, экспериментальная демонстрация деградации производительности может быть найдена в статье Коэн и Ноулз здесь). Этот недостаток интуитивно понятен; чем больше обновлений выполняется для одного и того же вектора, тем выше вероятность того, что более ранние входные данные и обновления будут потеряны (как показано на рисунке 3).
Как мы могли это решить? Возможно, если мы избавимся от использования только последнего скрытого состояния в качестве прокси для всего предложения и вместо этого построим архитектуру, которая потребляет все скрытые состояния, тогда нам не придется иметь дело с ослабляющим контекстом. Что ж, это то, что делают механизмы внимания. Он был представлен в этой статье Бахданова и др..
В предложенной модели каждое сгенерированное выходное слово является не просто функцией только окончательного скрытого состояния, а функцией ВСЕХ скрытых состояний. И это не просто простая операция, объединяющая все скрытые состояния - если это так, то мы по-прежнему даем один и тот же контекст каждому шагу вывода, поэтому он должен быть другим! Это не простая конкатенация или скалярное произведение, а операция «внимания», которая для каждого шага вывода декодера создает отдельный вектор, представляющий все скрытые состояния кодировщика, но придающий разные веса различным скрытым состояниям кодировщика.
Отдельный вектор контекста для шага вывода - это сумма весов внимания и всех скрытых состояний ввода. Веса внимания для каждого отдельного вывода будут разными, поэтому сумма взвешенных скрытых векторов различна для каждого шага вывода.
Имейте в виду, что дух «внимания» больше связан со способностью уделять внимание различным входам для каждого шага вывода и меньше касается других аспектов, таких как используемая функция выравнивания, характер задействованной RNN и т. Д. Таким образом, вы можете встретить другие варианты для что описано выше.
В этой связи, хотя это решение, похоже, решило проблему единого вектора контекста, оно сделало модель действительно большой. Когда вы пытаетесь подготовить отдельный вектор контекста для каждого шага вывода, требуется много вычислений.
Кроме того, существует другая проблема, связанная с вычислительной сложностью, которая не была введена этим решением, но существовала даже в базовой RNN. Учитывая последовательный характер операций, если входная последовательность имеет длину «n», для достижения окончательного скрытого состояния требуется «n» последовательных операций (т.е. вычислить h1, h2 и т. Д. До hn). Мы не можем выполнять эти операции параллельно, так как h1 является необходимым условием для вычисления h2. Этот недостаток распараллеливания в последовательности нельзя компенсировать добавлением большего количества выборок в обучающий пакет, так как загрузка и оптимизация весов для разных выборок увеличивает потребности в памяти, что ограничивает количество выборок, которые можно использовать в пакете.
Решение некоторых из этих проблем требует от нас взглянуть на несколько других вариантов внимания, и впоследствии это приведет нас к изучению модели Transformer. Я собираюсь написать об этом в другом посте, надеюсь, когда-нибудь в ближайшее время.
