For DS developers

Owned by Mikhail Bulgakov (Unlicensed)
Last updated: Oct 18, 2022 by Anonymous
3 min read

Main repository - https://github.com/jdi-testing/jdi-qasp-ml (All needed info about working with model placed in README)

 

Краткое описание проекта с точки зрения дата саентиста: создание сервиса для автоматизации тестирования веб-приложений; соотвественно дата саентист на проекте разрабатывает модели для определения класса элемента на веб-странице для каждой из библиотек для написания веб-приложений. После однозначного определения, что за элемент перед нами, и из какой он библиотеки, уже можно понимать, какие методы тестирования к нему применимы и тд.

 

Библиотеки, для которых происходит распознавание:

  • HTML – используемая модель на данный момент – это “дерево решений”, так как библиотека представляет элементы достаточно однозначно, в целом можно было даже обойтись без моделей. 23 класса, accuracy = 93%. Есть элементы, которые все равно распознаются плохо, пока после предсказания модели используется правило, что если модель не уверена в классе элемента на 100% или предсказывается элемент textfield, то этот элемент распознается просто как “UIElement”;

  • Material UI – используется нейронная сеть, состоящая из полносвязных блоков с некоторыми вариациями для разных библиотек (LayerNorm, LeakyReLU, Linear). 28 классов, accuracy = 90+%;

  • Angular – аналогичная нейронная сеть. 34 класса, accuracy = 90+%;

  • Vuetify - модель в процессе создания на момент написания этого текста. 50 классов, использование аналогичной архитектуры показало точность 83%, требуются улучшения;

  • Bootstrap – модель планируется к созданию.

Структура директорий проекта:

  • generators - директории с генераторами сайтов для каждой библиотеки. Чтобы сгенерировать сайты, необходимо запустить файл generate-html.py или generate-data.sh

  • data - директория со сгенерированными данными по каждой из бибилотек, в каждой директории внутри в папке build находятся html сгенерованных сайтов, в папке df уже эти же сайты, конвертированные в pickle; также есть файл classes.txt, где прописаны все классы, которые могут предсказываться моделью (все уникальные элементы на странице);

  • model - директория, в которой находятся файлы для обучения соотвествующих моделей. Чтобы построить датасет из сгенерированных данных, необходимо запустить файл build_datasets_for_sites.py; далее чтобы обучить модель, необходимо запустить файл train.py;

  • notebooks - в директории находятся ноутбуки с экпериментами;

  • vars - в директории лежат файлы, в которых указаны данные для обучения моделей (размер тренировочного и тестового датасетов, количество эпох для обучения и тд).

Во всех моделях при обучении используются датафреймы, где одна строчка – это признаки, относящиеся к одному элементу на сайте (не к одному сайту!)

Признаки, которые используются при создании моделей (верхнеуровневое описание):

  • информация по детям и родителям у различных тегов;

  • TFIDF, CountVectorizer и OneHotEncoding для некоторых фич;

  • Бинарные фичи типа “is checkbox in childs”, “is radio in childs” и тд.

Предложения по улучшению моделей:

  • Улучшить генераторы. В целом модели обучаются только на синтетических данных, хорошо было бы добавить реальные данные. Сейчас есть проблемы с подбором инструмента для разметки. Но в любом случае модель, обученная только на синтетических данных, даст хорошую точность только на синтетических данных. Чтобы хорошо работало и на реальных, нужно переобучать на реальных.
    Предложение по улучшению генератор такое: добавить больше элементов классов, которые плохо распознаются; сделать их более явными; разнообразить места их появления (например, autocomplete в генераторе для Vuetify явно появляется только по одному разу на каждом из сгенерированных сайтов, сюда можно добавить какой-то элемент вероятности; а combobox, overflow-btn и autocomplete в том же Vuetify скорее всего всегда появляются где-то рядом, если такая связка действительно есть, ее нужно попробовать разбить);

  • Концептуально поменять суть моделей. Код для веб-приложений – это последовательности токенов, которые относятся к определенным классам. Можно попробовать представить задачу как Named Entity Recognition. Но для этого придется корректировать генераторы, чтобы он возвращали именно последовательности, представить страницу сплошным текстом как в NLP.

Еще некоторые моменты, которые стоит также осветить:

  • В моделях на данный момент проиcходит обучение на выборках размером 120 и 30 (train и test) везде, кроме html модели, там сайты более легковесные. Выборки именно такого размера, потому что на генерируемых сайтах очень много элементов, на каждый элемент создается большой числовой вектор, и использование большего количества сайтов невозможно по причине ограниченности вычислительных мощностей (32 ГБ оперативной памяти недостаточно);

  • В целом, нужно понимать, что довести точность распознавания элементов именно до 100% - это не вполне реальная задача. В data science же есть такое достаточно абстрактное понятие “Емкость модели”. Даже в решающем дереве в любом случае есть класс, в который сваливаются все элементы, по которым у модели возникает сомнение. Соответственно, чтобы увеличить емкость модели и у нее возникало меньше сомнений, нужно пробовать, во-первых, улучшать данные, а не дописывать еще правила после получения решения от модели, во-вторых, как-то менять, а не усложнять модель, пытаться заменять в архитектуре полносвязные слои на рекурентные, например, скорее всего нет смысла, так как в итоге получится слишком сложная модель для достаточно простых данных.

 

Useful links: