Как стать автором
Обновить

Библиотека машинного обучения Google TensorFlow – первые впечатления и сравнение с собственной реализацией

Время на прочтение10 мин
Количество просмотров30K
Всего голосов 24: ↑22 и ↓2+20
Комментарии11

Комментарии 11

Для проверки, что бы не получались аналоги «няня для резки крыши» я использовал NLTK, в ней есть инструмент получения триграмм. Я скармливал тексты в NLTK, результат — триграммы сохранял и с ним сравнивал предложения генерируемые моей программой. Для нормальных результатов нужен был большой объём триграмм на основе текстов определённой предметной области. Таким образом улучшал качество генерируемого текста на выходе.
Да, такое можно сделать, я тоже про это думал. Это должно помочь против выражений типа “цена на система”. Но в данном случае ситуация не исправиться сильно, возможно будет вместо “няня для резки крыши”, скажем, “няня для ребенка под крышей”. Более правильно, но к сливной системе для крыши все равно не имеет отношения. И потом, если есть много текстов для генерации триграмм, их можно скормить и нейросети, что тоже улучшит качество (хотя триграммы конечно быстрее делаются)
Спасибо, очень интересная статья. Cовпала с моими текущими интересами. Я планирую заняться похожими вещами — попробовать реализовать синтаксический анализатор текста с нейронной сетью под капотом. Для начала начну работать с полносвязными сетями. Ускорять, наверное, буду через BLAS для CUDA.
Если не секрет, как вы обучали сеть? Обратным распространением?
Рекуррентная сеть обучалась обратным распространением ошибки через время (backpropagation through time).
Аж мурашки по коже когда читаешь о том, что сеть обучалась
Будет ли лучше если сказать, что сеть обучали? В любом случае мы даем системе данные и она учится (как без этого слова?) решать определенную задачу. После этого процесса нейросеть решает задачу, причем мы не знаем точно каким образом.
Не знаю по теме ли, но позволю себе спросить.
Представьте, что есть большая форма с полями для поиска информации. Каждый раз заполнять ее долго и муторно. В качестве альтернативы было выбрано одно поле, куда пользователь может вводить произвольный текст. Задача была распознать в этом тексте поисковые параметры и смапить на запрос. Сейчас пошел в лоб, обычные регулярки на стоп слова. Но я уже сто раз успел пожалеть об этом, вечно попадаются исключения из правил, слишком много вариантов написания поискового запроса.

В какую сторону смотреть для более качественного вычленения поисковых параметров из произвольно фразы? Нейронные сети? С чего начать, если да?
Вы правильно начали с регулярок и написанных вручную правил. Если они не помогают, следующим по тяжести методом является скорее всего машинное обучение. В данном случае мы имеем задачу извлечения информации из последовательности слов. Можно использовать CRF или нейронные сети, или другие классификаторы работающие с последовательностями.

Мы про это писали ранее здесь, здесь и еще тут поэтому можете начать с чтения этих статей. Там описано как сделать на нашем API, но общая идея одинаковая при работе с любыми средствами. Если никогда не делали такого раньше, начинать надо с изучения основ и практиковаться на классических примерах, и только потом переходить к вашей задаче, потому что вы должны почувствовать, что средство работатет, и при каких условиях.

Ну и еще мы делаем готовые решения таких проблем, но это уже за деньги.
Оттюнингованное на конкретную задачу решение показало лучший результат, чем универсальное «из коробки». Это закономерный результат. Полагаю, после пары месяцев тюнинга гугло-либы результаты будут близки до идентичности. А скорость и прочие плюшки останутся.

Библиотека расширяемая? Можно оформить эту авторскую идею с двумя перекодировками и вставить в виде плагина или обработчика?
Это одно из возможных объяснений. Но нет уверенности, что оно правильное. Для чат-бота специально никаких адаптаций не было сделано, использована архитектура сети, сделанной для другой задачи. По второй проблеме, я показываю результаты по новой синтетической задачи, которая похожа на ту, для которой архитектура разрабатывалась, но все равно это разные задачи. Задача реконструкции текста достаточно общая сама по себе, ее можно даже рассматривать как упрощенную модельную систему для машинного перевода. Поэтому, на основании поставленных опытов нельзя уверенно утверждать, что указанные архитектурные улучшения работают лучше, потому что они настроены на конкретную задачу, а не потому, что они вообще работают лучше. Но и обратного утверждать нельзя. Показательным было бы, например, применить мои архитектурные решения для других задач, того же перевода. К сожалению, у меня нет времени этим заниматься.

На TensorFlow как я написал в статье можно перенести другие архитектуры, хотя это будет не просто «тюнинг параметров», а достаточно серъезная работа. Поставленными опытами я пытался выяснить в том числе и стоит ли это делать, и пока не получил убедительных к тому аргументов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий