Аннотация Разработчики часто ищут способы реализовать стандартную функциональность с помощью библиотечных функций (например, создать кнопку в UI или получить данные из формата JSON). Обычно источником такой информации является Интернет. Альтернатива - различные статистические инструменты, которые, обучившись на большом объеме кода, по текстовому запросу могут предоставлять пользователю набор вызовов функций, решающих задачу. Мы рассматриваем один из таких инструментов DeepAPI. Этот современный алгоритм основывается на глубоком обучении, и, согласно его авторам, работает лучше аналогов. Мы пытаемся воспроизвести этот результат, взяв целевым языком не Java, как оригинальный DeepAPI, а C#. В данной статье мы рассказываем о возникающих проблемах сбора данных для обучения, сложностях в построения и обучения модели, а также обсуждаем возможные модификации алгоритма.
Последние несколько десятков лет предпринимаются
попытки анализировать исходный код для разных
целей: генерация имени метода по его телу [
Обычно разработчики ищут способы реализовать
стандартную функциональность с помощью поисковых
движков в сети Интернет, для чего те не
оптимизированы [
MAPO[
SWIM[
Одним из самых свежих алгоритмов в этой области
является DeepAPI [
Результаты, представленные в статье об алгоритме
DeepAPI, привлекли наше внимание, и мы решили
повторить этот опыт и расширить его. В результате
работы оригинального алгоритма DeepAPI получается
линейная последовательность вызовов функций, код
с их применением программисту приходится писать
самостоятельно. Хотелось бы облегчить ему этот этап,
предлагая не список функций, а сниппет кода то есть
отрывок кода на языке программирования, в котором
нужно модифицировать минимальное количество
деталей для того, чтобы он заработал. Для реализации
этого может оказаться полезным алгоритм T2API [
На текущий момент мы пытаемся повторить эксперимент из статьи DeepAPI и реализовать алгоритм из неё на базе другого языка программирования. В оригинальной статье авторы работают с элементами API и кодовой базой языка Java и упоминают, что одна из угроз действительности эксперимента работа только с одним языком. Мы желаем нивелировать эту угрозу, а потому работаем с языком C#.
Наш текущий вклад в исследования можно описать
следующими тезисами:
cобран набор тренировочных данных, реализован
инструментарий для сбора данных; Для увеличения точности работы алгоритма
вводитпроведено исследование использования в качестве ся еще одно улучшения новая функция потерь,
вклютренировочных данных данные, отличные от рас- чающая в себя наказание за использование чересчур
смотренных в оригинальной статье; частых элементов API. Ведь если функция часто
испостроена аппроксимация алгоритма DeepAPI; пользуется, то скорее всего, она не связана с
реализаципоставлен частично успешный первичный экспери- ей конкретной функциональности, а потому считается
мент. шумом. Оценка важности элемента API основывается
на tf–idf [
II. DeepAPI
Модель DeepAPI основывается на современных
техниках глубокого обучения и машинного перевода.
Ключевая техника обучение Sequence-to-Sequence [
Техника Sequence-to-Sequence включает в себя две рекуррентные нейронные сети (рекуррентная нейронная сеть (RNN) один из подвидов моделей глубокого обучения). Кодер первая из этих сетей поэлементно считывает вход и обновляет свои параметры в текущем скрытом состоянии. После окончания считывания последнее состояние предполагается, что в нём заключена суть входного предложения берётся в качестве вектора контекста, и передаётся в качестве входа второй RNN декодеру. Декодер на каждом шаге, сверяясь с вектором контекста, генерирует очередной элемент выходной последовательности, и обновляет своё состояние. Работа декодера прекращается, когда он генерирует слово, означающее окончание строки <EOS>.
Пример работы модели представлен на рисунке 2. Входной поток “generate random number”, выходной “Random.new Random.nextInt”.
На рисунке для простоты понимания состояния расширены по времени: поскольку нейронная сеть рекуррентная, переход из состояния должен вести в него же. То есть здесь h1, h2, h3 одно и то же состояние в моменты времени 1, 2, 3.
В модели DeepAPI также используется улучшение техники Sequence-to-Sequence: механизм внимания. Вместо использования лишь последнего состояния кодера в качестве вектора контекста для генерации целого предложения, на каждом шаге работы декодера используется свой вектор контекста, получаемый как взвешенная сумма всех состояний кодера
T cj = X ajtht
t=1 где cj вектор контекста для шага j; ht исторические состояния кодера, ajt веса этих состояний для шага j (моделируются при помощи отдельной заранее натренированной нейронной сети). где N боре, nyt yt.
widf (yt) = log(N=nyt) общее число экземпляров в тренировочном на
число экземпляров, в которых встречается Так как DeepAPI должен переводить запросы на английском языке в цепочки вызовов функций, она должна тренироваться на примерах того, какие английские предложения каким цепочкам вызовов функций соответствуют. Такие примеры авторы оригинальной статьи извлекают из открытого исходного кода, а именно из методов с комментариями. Так как целевым языком программирования выбрана Java, имеющая зафиксированную структуру комментария для документации Javadoc, авторы пользуются этим, и берут первое предложение комментария в качестве описания метода на английском языке (по определению Javadoc, именно это написано в первом предложении). Чтобы получить список вызовов функций, код метода анализируется компилятором Eclipse JDT. Выводятся классы каждой переменной, вызовы методов записываются вместе с именем класса, которому этот метод принадлежит. Пример вычленения информации из кода представлен на рисунке 1.
Рис. 1: Пример получения данных из кода После обучения, во время генерации результата по запросу, авторами используется лучевой поиск вместо того, чтобы генерировать самое вероятное слово на каждом шаге, поддерживается список из n текущих самых вероятных слов, и генерация продолжается для Рис. 2: Пример работы RNN Кодер-Декодера Отдельное внимание стоит уделить процессу сбора данных для исследования и тренировки модели. Для получения большего количества данных, мы использовали не только скачивание кода открытых проектов с Github, но и обработку скомпилированных сборок проектов, полученных из репозитория NuGet. В следующих двух секциях мы рассматриваем эти способы подробнее.
A. NuGet
Первый подход заключался в извлечении нужных данных из скомпилированных библиотек, котоПомимо последовательностей вызовов необходимо было также собрать комментарии к методам. На этом этапе мы столкнулись с проблемой: количество методов с комментариями в скачанных нами пакетах составляет лишь 11.21% от числа всех методов. Были собраны все доступные комментарии из xml-файлов, а для оставшихся методов мы генерировали описания, используя имя данного метода и имя содержащего его класса.
Как показала практика, описанный метод сбора данных оказался достаточно эффективным. Было скачано 4,100 пакетов, содержащих в общей сложности 4,278 библиотек. Итоговое количество собранных методов составило 611,945, из них 68,585 с комментариями.
B. Github
GitHub [
По подобному запросу для языка C# выдаётся 121,672 репозитория (https://github.com/search?utf8= %E2%9C%93&q=language%3AC%23+stars%3A%3E0& type=Repositories&ref=searchresults).
Таким образом, по сравнению с Java, репозиториев, с которыми можно потенциально работать, примерно в 4 раза меньше. Однако судя по имеющимся у нас данным, кажется возможным собрать количество данных того же порядка. Авторы в итоге получили 7,519,907 пар “описание на естественном языке список вызовов API”. После обработки 48,789 репозиториев мы получаем 870,008 пар.
Помимо количества репозиториев, возникает проблема из-за выбранного целевого языка. В Java из исходного кода можно легко получить тип (или надтип) переменной из её объявления. Однако в языке C#, начиная с версии 3.0, переменные могут иметь неявный тип var, поэтому для выведения явного типа таких переменных требуется компиляция всего проекта. Это ограничивает количество репозиториев, которые мы можем обработать. Кроме этого, мы сталкиваемся и с другими сложностями со стороны языка, например, динамический тип данных dynamic, о котором во время компиляции мы ничего не знаем. Но такие проблемы по сравнению с проблемой неявных типов несущественны: мы провели небольшой эксперимент, запустив поиск в исходном коде 470 случайно выбранных репозиториев слова "dynamic"и "var и получив всего 4,856 результатов для первого, и 176,561 результатов для второго. Поэтому пока что мы не исследуем способы решения подобных неприоритетных проблем, оставляя это на будущее.
В качестве компилятора мы используем Roslyn компилятор C# с открытым исходным кодом, разработанный Microsoft. Чтобы собирать проекты в автоматическом режиме, необходимо, чтобы: 1) не надо было предпринимать никаких дополнительных действий (например, запускать индивидуальные для каждого проекта скрипты); 2) проект содержал файл с расширением .sln
именно с ним может работать Roslyn.
Из 100 самых популярных результатов поиска таким ограничениям удовлетворяет 51 проект, в среднем по всем результатам поиска 11.2%.
Код из подходящих репозиториев мы обрабатываем аналогично оригинальной статье.
IV. Эксперимент наказывающую генерацию слишком частых функций. Это изменение не было приоритетным, т.к. влияет на оценку BLEU не больше, чем на 2 очка, увеличивая её с 52.49 до 54.42, а для нас более интересно получить первичный результат примерно того же порядка, что и 52.49.
A. Первый эксперимент
В качестве функции потерь в модели DeepAPI
берётся условная логарифмическая функция
правдоподобия. Модель тренируется максимизировать её с
помощью стохастического градиентного спуска [
Надо упомянуть, что обучение рекуррентных нейронных сетей очень ресурсоёмко, а потому ведётся на видеокартах. В то время как авторы для тренировки пользовались видеокартой Nvidia K20, у нас имеется гораздо менее мощная Nvidia GTX 660. В связи с этим нам пришлось уменьшить параметры тренировки до менее оптимальных. Например, авторы обнаружили, что оптимальное количество нейронов в скрытом слое кодера и декодера 1000. Мы выставляем их количество в 700. Авторы не обсуждают влияние размера пакета (batch) на модель, выставляя его значение в 200. Мы делаем его размер равным 32.
Мы вводим дополнительное улучшение в виде bucketing разделения исходных предложений на классы по длине, и тренировки внутри этих классов. Дело в том, что для быстрого обучения нам нужны вектора фиксированной длины а предложения имеют длину разную. Можно их все дополнять до максимальной длины (с помощью специального слова), а можно разделить на категории вида длина < 10, длина < 20, и т.д., и дополнять до максимума в этой категории, тренируя категории отдельно. Чем меньше дополняем пустыми словами, тем меньше шума, и лучше (теоретически) результат.
Мы тренируем модель на 605,146 парах данных в течение 40,000 итераций, ограничив словарь самыми популярными 10,000 слов в исходном и выходном языках.
Итоговая модель умеет верно отвечать на некоторые запросы, например ’generate random number System.Random.new System.Random.Next’ или ’replace part of string with other string System.String.Replace’, но на большинстве входов выдаёт нерелевантный результат.
B. Второй эксперимент На текущий момент мы не занимались реализаци- Так как хороших результатов получить на модели ей упомянутой ранее модификации функции потерь, с урезанными параметрами не удалось, мы создаём Рис. 3: График изменения функции потерь во время обучения модель на основе нового фрэймворка от Google - tfseq2seq, специализирующегося на Sequence-to-Sequence моделях. С его помощью мы обучаем модель на тех же значениях параметров, что и в оригинальной статье, при этом для этого хватает производительности нашей не мощной видеокарты. Также во время декодирования мы используем лучевой поиск - улучшение, предложенное авторами оригинальной статьи и описанное в секции II; в предыдущей модели мы этот механизм не реализовывали.
Модель мы тренируем на 924,593 парах данных в течение 390,000 итераций, ограничивая словарь в исходном и выходном языках самыми популярными 10,000 слов.
Итоговая модель может не только отвечать на одиночные запросы, как старая, но и показывает ненулевые результаты на тестовом множестве из 14,000 пар данных. Надо упомянуть, что пары из тестового множества не используются во время тренировки, поэтому положительные результаты на них означают, что модель не просто запомнила данные ей в тренировочном множестве примеры, а действительно научилась обобщать знания. Оценка модели по метрике BLEU растёт от 0.48 после 158,000 итераций до 1.95 после 390,000 итераций. Помимо этого, искусственная функция потерь, которую модель минимизирует, стабильно уменьшается (см. рисунок 3).
Таким образом, из общей положительной динамики мы можем заключить, что техника имеет право на существование. Мы считаем, что тренировка на большем количестве данных позволит получить сравнимый с оригинальным результат.
V. Дальнейшая работа Мы планируем продолжать исследование данного подхода. В ближайшей перспективе перед нами стоят следующие цели: 1) собрать набор данных, сопоставимый по размеру
с набором данных в оригинальной статье; 2) поэкспериментировать с параметрами обучения,
и найти оптимальные; 3) исследовать возможность тренировки на не комментированных методах, используя имена и классы параметров, имя метода; 4) найти способы решения специфичных для целе
вого языка проблем; 5) реализовать алгоритм T2API; 6) объединить алгоритмы DeepAPI и T2API в один, проанализировать получившийся результат.
VI. Заключение В этой статье мы описали нашу частично успешную попытку повторить результат статьи DeepAPI. Используя современные методы глубокого обучения и машинного перевода, мы достигли небольших успехов в задаче генерации списка вызовов функций по текстовому запросу.
Мы считаем, что модель DeepAPI действительно может быть реализована на базе другого языка, а также улучшена, что мы и собираемся продемонстрировать по результатам дальнейшей работы.
Список литературы
DeepAPI#: CLR/C# call sequence synthesis
from text query Alexander Chebykin, Mikhail Kita, Iakov Kirilenko
Developers often search for an implementation of typical features via libraries (for example, how to create a UI button control, extract data from a JSON-formatted file, etc.). The Internet is the usual source of the information on the topic. However, various statistical tools provide an alternative: after processing large amounts of source code and learning common patterns, they can convert a user request to a set of relevant function calls.
We examine one of those tools DeepAPI. This fresh deep learning based algorithm outperforms all others (according to its authors). We attempt to reproduce this result using different target programming language C# instead of Java used in the original DeepAPI. In this paper we report arising problems in the data gathering for training, difficulties in the model construction and training, and finally discuss possible modifications of the algorithm.