<style> .reveal { font-size: 22px; } </style> # Команда Hat Dog  <!-- Каждая команда должна подготовить рассказ о своем решении на 3-5 минут. Пример создания слайдов https://hackmd.io/s/slide-example --> [TOC] --- ## Предобработка текстов - Выкидывали email, цифры, знаки препинания, мусорные слова - Лемматизация WordNet - прикрутили после отборочного этапа - Использовали два корпуса с цитатами (для отгадывания) и без цитат (для объяснений) - Не получилось: - Попробовали объединять все предложения одного поста в одно большое и учиться на нем (не дало эффекта) - Не сделали тестирования корпусов после препроцессинга (пропустили ошибку в финальном корпусе) --- ## Обучение эмбеддингов - Модель для эмбедингов: FASTTEXT - выбрана экспериментальным путем еще до отборочного. Далее только параметры меняли - Эмбединги для EXPLAIN: CBOW dim=30 на корпусе без цитат - Эмбединги для GUESS: SKIPGRAM dim=30 на корпусе с цитатами (+30% объемы текста) - Подбор параметров: по соревновательным играм между моделями с разными параметрами обученными на разных корпусах - Мы учитывали частотность слов в словаре корпуса текста - Подтягивали наверх (меняли порядок) для более популярных слов и использовали параметр TEMPERATURE для регулировки силы подтягивания. - Для каждой из моделей использовался свой словарь частотности (т.к. входные тексты были разными для моделей EXPLAIN и GUESS). Для Explain частотное усиление **стоп-слов** не использовалось. --- ## Обучение эмбеддингов (не зашло) - Пробовали Gensim - незашел. Glove не смогли завести. - Не успели попробовать StarSpace - В FastText пробовали отключить ngramm посимвольный - ухудшало качество на валидации - Пробовали LSTM - на обученных эмбедигах от fasttext по последовательности предсказывать слово - модель не сходилась и не обощалась для моделей других участников. - Не хватило времени на GAN-архитектуру. Скорее всего получилось бы не очень хорошо в данной постановке зададчи. --- ## Принцип загадывания/отгадывания слова - 2 разных модели н объяснение и угадыввание - Объяснение: Взять модель попроще CBOW - дать ей ограниченный корпус (без цитат): - Слов из модели брали побольше, чистили то что не прошло бы проверки ведущего, использовали температуру частотности что бы скорректировать порядок выдачи по формуле: $$ L_n = {L_n(1 + T\times log({f_n}))} $$ $L$ - мера близости $n$ - номер слова, $T$ - коэффициенты температуры, $f$ - частота слова в корпусе. - Угадывание: Взять модель поумнее SKIPGRAMM - на расширенном корпусе (с цитатами): - Забирать из модели больше слов. Процессить. Убирать повторы из предыдущих раундов (здесь у нас была сложность из-за мультипроцессорного подхода - решали с помощью redis) - Узнали что в fasttext есть метод get_nearest_neighbors (он не ставится через pip только из GIT). Отдельная боль поставить его под Windows (Нужен VC C++ 15.0). Он существенно удобнее метода из baseline. --- ## Валидация созданного решения * Сравнивали модели между собой. Выбирали голосованием всей командой * Написали класс игры, который получал логи и мог проводить игры между реальными моделями других команд и новыми моделями обученными локально - это хорошо помогало настроить GUESS * Не сделали таку же штуку для тренировки объяснения слов (можно было учиться у лучших моделей) * Не сделали онлайновй парсер логов - что бы обрабатывать все игры онлайн * Не проанализировали логи своего сервера глубоко. Хотя и собирали их --- ## Деплой сервиса с моделью * GITLAB - репозиторий (3 бранча + merge) * Package repository на GITLAB - собираем образы локально и пушим в репозиторий. На прод. сервер их можно затащить через ```docker pull``` * В качестве сервера AWS t2.large 4cpu + 16Gb (сначал у нас текла память и t2.micro не справлялся) * Для управления докерами использовали ```docker-compose``` * У нас было 4 контейнера * uwsgi+flask - в 5 потоков (даже если один отваливался - остальные жили) * nginx - проксирование запросов в uwsgi * redis - Для обеспечения передачи словарей между потоками * mongo - записывали логи из всех потоков сразу в виде словарей * Разобрались c CI/CD gitlab (после комита решение само выносилось на прод сервер - по не обходимости собирались новые контейнеры см .gitlab-ci.yml) --- ## Организация работы * Доска с задачами (понятно что и кто делает. Туда же писали идеи)  * Созвон каждый день (hangout.google.com) --- ## Выводы - Лучше понимать конечную задачу, которую решаем (валидация на локалььных моделях не дает объективной картины). - Метрики оценки качества - сразу выстраивать процесс валидации на моделях конкурентов как по guess так и по explain на логах от ведущего. - Тестирование результата препроцессинга - нехватило времени настроить - в результате ошибки - Распределение работ между участниками команды (увы, не все задачи были интересные) - Регламент выкладки на прод (не надо делать в последнюю минуту). Лучше выложить за час и протестировать, что все работает как ожидалось. ---