RLHF не является оптимальным способом научить машины думать, но пока это самый яркий пример из того, что у нас есть. Люди постепенно собираются и делают вместе разные открытые инициативы вроде BLOOM и Open Assistant, но опыта у сообществ меньше, чем у компаний, и пока не всё работает хорошо (но я верю в людей).
Важно понимать, что выравнивание в RLHF нужно не только для того, чтобы писать пользователям “As an AI language model ...”, а чтобы уточнить, как лучше общаться с пользователем. Одновременно обеспечить и безопасность, и полезность ответов довольно трудно, и это открытое направление исследований.
Я думаю, что никто из AWS, Azure и GCP не будет дешёвым в данном случае. Возможно, Cloudflare R2 оказался бы сильно дешевле. Отдельный VPS с таким профилем нагрузки, на мой взгляд, будет сильно отличаться от других машин у хостинга и вызовет вопросы. В любом случае, сложно найти решение выгоднее, чем текущее — оно бесплатно и довольно удобно в обслуживании.
Мы реализовали несколько популярных методов, в том числе универсальный и надёжный метод ROVER, а также метод на основе автореферирования при помощи языковой модели, победивший в нашем соревновании методов агрегации текстов (см. статью).
Из статьи мне показалось, что вам важнее удобно и эффективно запускать модели, обученные при помощи других библиотек, таких как PyTorch и TensorFlow, чем использовать собственный код для обучения. Уверены ли вы в целесообразности разработки и поддержки ещё одной полнофункциональной библиотеки для машинного обучения, если можно сосредоточиться на развёртывании моделей? На мой взгляд, довольно тяжело соревноваться с ресурсами и сообществом вокруг проектов Facebook и Google.
Насколько понимаю, в вашей задаче можно обойтись и приближённым алгоритмом поиска ближайших соседей, что работает значительно быстрее. Рассматривали ли вы другие готовые решения — Faiss, Annoy, и им подобные? (В Faiss имеется реализация точного поиска, если без него обойтись никак нельзя.)
Легко ли найти специалистов со знанием именно Dlib, а не TensorFlow и PyTorch? Как вы выбирали модель и настраивали её параметры?
Главная трудность в обработке естественного языка — многозначность, которая проявляется чаще, чем мы способны формализовать. Синтаксический анализ сейчас обычно делается при помощи машинного обучения, см. старый обзор от Choi et al. (2015).
Что, если вместо того, чтобы вручную описывать грамматику всего русского языка, сосредоточиться на задаче извлечения фактов? Она несколько проще в решении, но всё равно требует использования более сложного GLR-парсера, см. Томита-парсер и python-glr-parser. Попробуйте улучшить их результаты, например, с помощью вероятностных моделей — это должно быть весело!
Будет здорово. Сейчас зарегистрировалось больше пятидесяти участников, но мы не закрываем форму регистрации. Если возникнут вопросы, не стесняйтесь задавать их в Google-группе, на Facebook, или на NLPub Q&A.
Разрешение лексической многозначности — важная открытая научная задача. Данное соревнование призвано объединить усилия людей по её решению и количественно оценить, насколько хорошо в данный момент автоматические методы решают эту задачу для русского языка.
Да, это было бы слишком быстро. Мы изначально планировали переместить срок приёма результатов до первого февраля. Информация на сайте дорожки RUSSE 2018 и в материалах участника уже обновлена.
Стоит добавить ссылку на оригинальное сообщение “A small post about the v40 interpreter” из списка рассылки freetype-devel, адаптацией которого является данная запись.
Увы, я не имею к этому сервису совсем никакого отношения и не располагаю набором данных, по которому обучалась модель. Держать в руках эту демонстрацию нужно правильно: сначала указывается имя, затем фамилия. Пример показан перед формой, «Мария Иванко» отлично распознаётся.
Не совсем так, см. выше. Применение машинного обучения полезно в задаче определения пола. Правда, в упомянутом примере используются не нейронные сети, а логистическая регрессия: http://research.digsolab.com/gender.
Библиотека разрабатывалась для решения задачи склонения имён в случаях, когда пол известен. Например, в личных кабинетах и индивидуальных рассылках. Задача автоматического определения пола напрямую не относится к задаче склонения имён, но тоже обсуждается в контексте библиотеки. Среди несложных подходов обратите внимание на анализ окончаний и машинное обучение.
Основная работа в Petrovich велась над открытой базой правил и её репрезентативностью. Правила переносимы и централизованно используются всеми портами. Это же позволяет довольно быстро реагировать на возможные неточности по отчётам и правкам.
Сравнение в данной статье покрывает большое количество существующих инструментов, но является качественным сопоставлением. Очень интересно увидеть и количественный анализ. Например, сравнить аккуратность инструментов на основе набора данных, который используется для автоматического тестирования каждого изменения в правилах Petrovich, или любом другом.
Сейчас «Толока» предоставляет только список полученных ответов на каждое задание, при этом вопрос их агрегации остаётся на усмотрение заказчика. Для обработки данных мы с коллегами используем Mechanical Tsar, в котором реализованы вероятностные методы оценки доверия к участникам: ZenCrowd, Dawid-Skene, и др. Применение таких методов обеспечивает более надёжный результат на тех же самых данных по сравнению с простыми эвристиками вроде «голос большинства» или «половина голосов».
На мой взгляд, при использовании «Толоки» очень важно создавать тестовые («золотые») задания. Это неприятно и скучно, но позволяет обучить участников и за счёт этого существенно повысить качество разметки.
Представленная задача не является новой, и в этой области всё упирается в две проблемы: 1) доступность размеченного графического материала и 2) технологии обработки текста. Если вы планируете визуализировать более-менее связные тексты на русском языке, то вас ждёт много интересных открытий.
Обратите внимание на две замечательные работы на эту тему:
Очень приятно, что появилась двухфакторная аутентификация: с ней спокойнее. Неужели предложенный подход оказался проще и удобнее, чем привычные SMS с паролями? Этот вопрос заслуживает отдельного поста.
RLHF не является оптимальным способом научить машины думать, но пока это самый яркий пример из того, что у нас есть. Люди постепенно собираются и делают вместе разные открытые инициативы вроде BLOOM и Open Assistant, но опыта у сообществ меньше, чем у компаний, и пока не всё работает хорошо (но я верю в людей).
Важно понимать, что выравнивание в RLHF нужно не только для того, чтобы писать пользователям “As an AI language model ...”, а чтобы уточнить, как лучше общаться с пользователем. Одновременно обеспечить и безопасность, и полезность ответов довольно трудно, и это открытое направление исследований.
Поздравляю! Можете, пожалуйста, рассказать, как размечали данные для модели-оценщика в RLHF?
Я думаю, что никто из AWS, Azure и GCP не будет дешёвым в данном случае. Возможно, Cloudflare R2 оказался бы сильно дешевле. Отдельный VPS с таким профилем нагрузки, на мой взгляд, будет сильно отличаться от других машин у хостинга и вызовет вопросы. В любом случае, сложно найти решение выгоднее, чем текущее — оно бесплатно и довольно удобно в обслуживании.
Да, конечно.
Мы реализовали несколько популярных методов, в том числе универсальный и надёжный метод ROVER, а также метод на основе автореферирования при помощи языковой модели, победивший в нашем соревновании методов агрегации текстов (см. статью).
В качестве отправной точки рекомендую нашу документацию: ROVER и TextSummarization.
Поздравляю с релизом!
Из статьи мне показалось, что вам важнее удобно и эффективно запускать модели, обученные при помощи других библиотек, таких как PyTorch и TensorFlow, чем использовать собственный код для обучения. Уверены ли вы в целесообразности разработки и поддержки ещё одной полнофункциональной библиотеки для машинного обучения, если можно сосредоточиться на развёртывании моделей? На мой взгляд, довольно тяжело соревноваться с ресурсами и сообществом вокруг проектов Facebook и Google.
Насколько понимаю, в вашей задаче можно обойтись и приближённым алгоритмом поиска ближайших соседей, что работает значительно быстрее. Рассматривали ли вы другие готовые решения — Faiss, Annoy, и им подобные? (В Faiss имеется реализация точного поиска, если без него обойтись никак нельзя.)
Легко ли найти специалистов со знанием именно Dlib, а не TensorFlow и PyTorch? Как вы выбирали модель и настраивали её параметры?
Главная трудность в обработке естественного языка — многозначность, которая проявляется чаще, чем мы способны формализовать. Синтаксический анализ сейчас обычно делается при помощи машинного обучения, см. старый обзор от Choi et al. (2015).
Что, если вместо того, чтобы вручную описывать грамматику всего русского языка, сосредоточиться на задаче извлечения фактов? Она несколько проще в решении, но всё равно требует использования более сложного GLR-парсера, см. Томита-парсер и python-glr-parser. Попробуйте улучшить их результаты, например, с помощью вероятностных моделей — это должно быть весело!
Будет здорово. Сейчас зарегистрировалось больше пятидесяти участников, но мы не закрываем форму регистрации. Если возникнут вопросы, не стесняйтесь задавать их в Google-группе, на Facebook, или на NLPub Q&A.
Разрешение лексической многозначности — важная открытая научная задача. Данное соревнование призвано объединить усилия людей по её решению и количественно оценить, насколько хорошо в данный момент автоматические методы решают эту задачу для русского языка.
Да, это было бы слишком быстро. Мы изначально планировали переместить срок приёма результатов до первого февраля. Информация на сайте дорожки RUSSE 2018 и в материалах участника уже обновлена.
Стоит добавить ссылку на оригинальное сообщение “A small post about the v40 interpreter” из списка рассылки
freetype-devel, адаптацией которого является данная запись.Было бы здорово добавить ссылку на мой комментарий, чтобы у пользователей пока не возникало лишних иллюзий по поводу функциональности библиотеки.
Возможно, при наборе имени в Petrovich сбросился выбор пола. Насколько вижу, данное ФИО склоняется корректно.
Увы, я не имею к этому сервису совсем никакого отношения и не располагаю набором данных, по которому обучалась модель. Держать в руках эту демонстрацию нужно правильно: сначала указывается имя, затем фамилия. Пример показан перед формой, «Мария Иванко» отлично распознаётся.
Не совсем так, см. выше. Применение машинного обучения полезно в задаче определения пола. Правда, в упомянутом примере используются не нейронные сети, а логистическая регрессия: http://research.digsolab.com/gender.
Добавлю пару слов по поводу Petrovich.
Библиотека разрабатывалась для решения задачи склонения имён в случаях, когда пол известен. Например, в личных кабинетах и индивидуальных рассылках. Задача автоматического определения пола напрямую не относится к задаче склонения имён, но тоже обсуждается в контексте библиотеки. Среди несложных подходов обратите внимание на анализ окончаний и машинное обучение.
Основная работа в Petrovich велась над открытой базой правил и её репрезентативностью. Правила переносимы и централизованно используются всеми портами. Это же позволяет довольно быстро реагировать на возможные неточности по отчётам и правкам.
Сравнение в данной статье покрывает большое количество существующих инструментов, но является качественным сопоставлением. Очень интересно увидеть и количественный анализ. Например, сравнить аккуратность инструментов на основе набора данных, который используется для автоматического тестирования каждого изменения в правилах Petrovich, или любом другом.
Сейчас «Толока» предоставляет только список полученных ответов на каждое задание, при этом вопрос их агрегации остаётся на усмотрение заказчика. Для обработки данных мы с коллегами используем Mechanical Tsar, в котором реализованы вероятностные методы оценки доверия к участникам: ZenCrowd, Dawid-Skene, и др. Применение таких методов обеспечивает более надёжный результат на тех же самых данных по сравнению с простыми эвристиками вроде «голос большинства» или «половина голосов».
На мой взгляд, при использовании «Толоки» очень важно создавать тестовые («золотые») задания. Это неприятно и скучно, но позволяет обучить участников и за счёт этого существенно повысить качество разметки.
Представленная задача не является новой, и в этой области всё упирается в две проблемы: 1) доступность размеченного графического материала и 2) технологии обработки текста. Если вы планируете визуализировать более-менее связные тексты на русском языке, то вас ждёт много интересных открытий.
Обратите внимание на две замечательные работы на эту тему: