INCEpTION (https://inception-project.github.io/). Бесплатный. Много возможностей, активно развивается. Использую уже 2 года и за это время он из относительно дубового продукта (но и тогда уже была куча нужных мне особенностей) превратился в уже юзабельную штуку.
К чему в опросе эта ложная дихотомия? Ведь есть еще много промежуточных вариантов. По моему опыту, они сочетают преимущества удаленки и офисной работы. Конечно, зависит от проекта, позиции, но в общем, 2-3 дня в офисе и 3-2, соответственно, из дома, как для разработчика часто оказывались идеальными. Конечно, если дома есть удобное оборудованное место для работы - в противном случае, коллеги приезжали в офис именно за рабочим местом, но был уговор - никаких митингов и отвлечений. Как будто их нет.
Правильно ли я понял, что к BERT прицепили ЧЯ и обучили его повторять за BERT и получили Distilbert?
Там чуть сложнее, но принцип такой, да. Ученика учат максимально точно повторять вероятности, которые учитель отдает на последних слоях модели. При этом середина может быть произвольной (для дистилляции её делают проще).
А BERT в это время был в специальном режиме для обучения ЧЯ, или в рабочем режиме, выполнял свои стандартные функции? (Я думаю, в режиме обучения).
Учитель в этот момент заморожен (в режиме вывода — inference). Обучается только ученик.
В машинном обучении это называется дистилляцией модели. Таким образом, из известной и тяжелой NLP модели (трансформера) BERT, получили Distilbert, который гораздо легче, но показывает ненамного хуже результаты на аналогичных задачах.
Можете ли описать входные данные более подробно? Из Fig.5 в https://dl.acm.org/doi/pdf/10.1145/3292500.3330699 я понял, что AST-дерево раскладывается линейно, но как и что здесь является токеном — непонятно. Если бы получилось на небольшом примере показать — было бы классно.
На первый взгляд, выглядит прикольно.
Но, как и у всех подобных оберток над другими библиотеками, есть много зависимостей. Что нехорошо, что часть из них с точными версиями (https://github.com/pycaret/pycaret/blob/master/requirements.txt). Из практики понимаю, что такие вещи желательно держать в отдельном environment и может быть затруднена интеграция с какой-то из библиотек. Особенно, если авторы забросят поддержку своей.
Т.е., как средство сделать автоматом какой-то прототип — ок. Но дальше нужно быть готовым делать свой пайплайн, выкинув этот комбайн.
Согласен, что здесь можно сделать лучше. Почему не сделано:
— На практике оказалось, что случаев, когда такое склеивание что-то ломает — не так уж и много. Например, при верстке есть правила, когда стараются не ставить дефис в конце слова, где непонятно, перенос ли это. Если же это телефон, то дефис тут играет вспомогательную роль и его потеря не особо мешает (и при правильной верстке, его тоже стараются поместить полностью на одной строке).
— Не хотелось завязываться на определенный язык. А смотреть в словаре — это именно такой, языкозависимый подход.
Если дадите большое количество примеров, где существующий код плохо срабатывает (желательно только реальные — как я писал, на практике их встречается гораздо меньше, чем могло бы показаться), можно посмотреть, как стоит модифицировать эту часть кода.
Лучше всего — открытием ишью на гитхабе проекта. Если же сделаете пул-риквест, вообще будет идеально.
Несколько десятков правил — мне такое уже сложно поддерживать. Именно поэтому сейчас, когда освоил азы (как минимум) sklearn, пошел именно этим путем. У каждого свой порог, когда лучше отходить от логики жесткого алгоритма в ML. Например, подзадача восстановления разбитых жесткими переносами слов решалась без ML. Хотя, не исключено, что когда все процессоры будут квантовыми, и тут станет проще научить, чем запрограммировать. Просто удивительно, что творят нейросети с последовательностями символов — вот тут недавно скрещивал базу от гугла и пример переводчика для кераса: github.com/serge-sotnyk/seq2seq-compress. После такого начинаешь верить, что если есть достаточно данных и времени, то нейросеть можно обучить чему угодно…
Мне кажется, что задачка детектирования кодировки или даже языка выглядела бы гораздо нагляднее для демонстрации пользы от применения ML.
Это действительно актуальная для многих задача. Но в общем виде она практически решена. Вот хороший список библиотек для Питона: stackoverflow.com/a/47106810/4884761
А задача постобработки PDF мне понравилась тем, что она пошла практически по классическому сюжету:
1. Посмотрели — не видно публичных готовых библиотек.
2. Собрали данные для обучения.
3. Проаннотировали.
4. Выбрали метрики качества.
5. Обучили бэйзлайн-решение. Так получилось, что оно удовлетворило по качеству. Это просто приятный бонус. Иначе нужен был бы этап 6.
6. Улучшаем качество.
Так получилось, что все необходимые компоненты уже есть и в .NET — поэтому была возможность еще и сравнить особенности решения и там, и там.
Где применение ML оправдано — каждый решает для себя сам. В данном случае, решая задачу уже не первый раз, я получил большее удовольствие от работы и большую уверенность в легкости поддержки. Поэтому мне показалось оправданным. Раньше, до того, как на практике закрепил навыки по ML, тоже часто предпочитал все сделать и настроить своими руками.
Т.е. если предложение тянется до правой границы, то переноса абзаца не будет? Есть ли в таком случае смысл переходить от логики к статистике?
Смысл есть как раз потому, что тексты бывают разные. Для данной задачи — с разной типичной длиной строки (разные шрифты, разное количество колонок). И как только окажется, что какой-то текст плохо обрабатывается — логические правила нужно подправлять. Когда их количество превышает определенное число — их поддержание становится очень трудозатратным. ML же сильно упрощает адаптацию к новым условиям.
И я бы не формулировал, что ML=статистика. Те же деревья решений (их тоже можно применить с минимальным изменением программы) — это уже больше похоже на логические правила. Очень большой набор правил.
Вот в другой встречающейся задаче по определению кодировки текста без статистики тяжело.
Не поверите, но эту (точнее, очень похожую — определение языка) задачу также решал без машинного обучения. Основа — подсчет количества уникальных для языка фрагментов (1..4 буквы и целых слов). Это если очень упрощенно. Но ML-подход опять-таки, позволяет решить её более качественно именно для тех текстов, которых у вас больше. Статистика текстов очень отличается в зависимости от вашей предметной области. Твиты и статьи из журналов имеют существенно отличающиеся языковые модели.
Вы имеете в виду, на основании чего делает такой вывод алгоритм? Или аннотатор (т.е., я)? Я, в данном случае, смотрю на «геометрию» строк. В предыдущей строке только одно слово, заканчивается знаком препинания. Следующая строка достаточно длинная, начинается с заглавного символа. Это характерно для абзаца. В реальности, конечно же, я так не взвешиваю, а быстро вставляю символ "*" в начало строки и перевожу курсор к следующей.
Думаю, алгоритм базируется на комбинации этих же признаков, которая кодируется в весах логистической регрессии.
Если же пруф, что абзац тут есть — то вот оригинальный фрагмент. Это фрагмент книги «Глубокое обучение на Python»
Код я не смотрел, а в статье я такого почему-то не вижу.
В коде этой фичи сейчас и нет, а в статье — как раз в пункте о скорости:
В коде на Питоне пришлось отказаться от фич, которые были завязаны на то, какое решение по склейке было принято в прошлых предложениях — если подавать классификатору предложения по-одному, то общая скорость получится ниже плинтуса.
Насчет numba — какие преимущества и недостатки по сравнению с Cython на практике?
В основном соглашусь — Pandas/Numpy позволяют многое легко и элегантно векторизовать. При этом код получается простой и производительный. Но такими кейсами все не ограничивается. По крайней мере у меня. Нередко, приходится фичи выводить на деревьях. Или тот момент, который я приводил в статье — когда в качестве фичи передается то, что классификатор выдал для предыдущих сэмплах. В таких случаях и векторизация ломается, и со списками приходится работать, и еще много чего нестандартного. Вот в таких случаях большая производительность чистого C#-кода заметна. Просто рабочий момент, на который обращается внимание, когда один и тот же код пишешь там и здесь.
Оригинальное издание 2020-го года. Для данной предметной области это уже давно.
INCEpTION (https://inception-project.github.io/). Бесплатный. Много возможностей, активно развивается. Использую уже 2 года и за это время он из относительно дубового продукта (но и тогда уже была куча нужных мне особенностей) превратился в уже юзабельную штуку.
BPEmb (https://bpemb.h-its.org/) для меня оказался гораздо удобнее.
Блок-схемы хороши, когда нужно показать небольшую структуру. Но они становятся обузой, когда:
Структура становится очень большой.
Много раз используется один блок, сложные циклы.
Нужно показать наследование, врапперы и т.п.
В результате, на реальных проектах обычно приходишь к тому, что какая-то разновидность кода обычно легче в понимании и поддержке.
К чему в опросе эта ложная дихотомия? Ведь есть еще много промежуточных вариантов. По моему опыту, они сочетают преимущества удаленки и офисной работы. Конечно, зависит от проекта, позиции, но в общем, 2-3 дня в офисе и 3-2, соответственно, из дома, как для разработчика часто оказывались идеальными. Конечно, если дома есть удобное оборудованное место для работы - в противном случае, коллеги приезжали в офис именно за рабочим местом, но был уговор - никаких митингов и отвлечений. Как будто их нет.
Там чуть сложнее, но принцип такой, да. Ученика учат максимально точно повторять вероятности, которые учитель отдает на последних слоях модели. При этом середина может быть произвольной (для дистилляции её делают проще).
Учитель в этот момент заморожен (в режиме вывода — inference). Обучается только ученик.
В машинном обучении это называется дистилляцией модели. Таким образом, из известной и тяжелой NLP модели (трансформера) BERT, получили Distilbert, который гораздо легче, но показывает ненамного хуже результаты на аналогичных задачах.
Можете ли описать входные данные более подробно? Из Fig.5 в https://dl.acm.org/doi/pdf/10.1145/3292500.3330699 я понял, что AST-дерево раскладывается линейно, но как и что здесь является токеном — непонятно. Если бы получилось на небольшом примере показать — было бы классно.
Позабавила картинка — и монобровь, и еще вырез под камеру в экране ))
Хоть бы такое не взяли на вооружение.
А так, в ожидании следующих публикаций.
На первый взгляд, выглядит прикольно.
Но, как и у всех подобных оберток над другими библиотеками, есть много зависимостей. Что нехорошо, что часть из них с точными версиями (https://github.com/pycaret/pycaret/blob/master/requirements.txt). Из практики понимаю, что такие вещи желательно держать в отдельном environment и может быть затруднена интеграция с какой-то из библиотек. Особенно, если авторы забросят поддержку своей.
Т.е., как средство сделать автоматом какой-то прототип — ок. Но дальше нужно быть готовым делать свой пайплайн, выкинув этот комбайн.
Купил. Хотел между делом подтянуть пайторч (обычно использую Керас). Ощущение, что переводил человек, незнакомый с темой. Просто пара моментов:
И таких перлов полно.
— На практике оказалось, что случаев, когда такое склеивание что-то ломает — не так уж и много. Например, при верстке есть правила, когда стараются не ставить дефис в конце слова, где непонятно, перенос ли это. Если же это телефон, то дефис тут играет вспомогательную роль и его потеря не особо мешает (и при правильной верстке, его тоже стараются поместить полностью на одной строке).
— Не хотелось завязываться на определенный язык. А смотреть в словаре — это именно такой, языкозависимый подход.
Если дадите большое количество примеров, где существующий код плохо срабатывает (желательно только реальные — как я писал, на практике их встречается гораздо меньше, чем могло бы показаться), можно посмотреть, как стоит модифицировать эту часть кода.
Лучше всего — открытием ишью на гитхабе проекта. Если же сделаете пул-риквест, вообще будет идеально.
Это действительно актуальная для многих задача. Но в общем виде она практически решена. Вот хороший список библиотек для Питона: stackoverflow.com/a/47106810/4884761
А задача постобработки PDF мне понравилась тем, что она пошла практически по классическому сюжету:
1. Посмотрели — не видно публичных готовых библиотек.
2. Собрали данные для обучения.
3. Проаннотировали.
4. Выбрали метрики качества.
5. Обучили бэйзлайн-решение. Так получилось, что оно удовлетворило по качеству. Это просто приятный бонус. Иначе нужен был бы этап 6.
6. Улучшаем качество.
Так получилось, что все необходимые компоненты уже есть и в .NET — поэтому была возможность еще и сравнить особенности решения и там, и там.
Где применение ML оправдано — каждый решает для себя сам. В данном случае, решая задачу уже не первый раз, я получил большее удовольствие от работы и большую уверенность в легкости поддержки. Поэтому мне показалось оправданным. Раньше, до того, как на практике закрепил навыки по ML, тоже часто предпочитал все сделать и настроить своими руками.
Смысл есть как раз потому, что тексты бывают разные. Для данной задачи — с разной типичной длиной строки (разные шрифты, разное количество колонок). И как только окажется, что какой-то текст плохо обрабатывается — логические правила нужно подправлять. Когда их количество превышает определенное число — их поддержание становится очень трудозатратным. ML же сильно упрощает адаптацию к новым условиям.
И я бы не формулировал, что ML=статистика. Те же деревья решений (их тоже можно применить с минимальным изменением программы) — это уже больше похоже на логические правила. Очень большой набор правил.
Не поверите, но эту (точнее, очень похожую — определение языка) задачу также решал без машинного обучения. Основа — подсчет количества уникальных для языка фрагментов (1..4 буквы и целых слов). Это если очень упрощенно. Но ML-подход опять-таки, позволяет решить её более качественно именно для тех текстов, которых у вас больше. Статистика текстов очень отличается в зависимости от вашей предметной области. Твиты и статьи из журналов имеют существенно отличающиеся языковые модели.
Думаю, алгоритм базируется на комбинации этих же признаков, которая кодируется в весах логистической регрессии.
Если же пруф, что абзац тут есть — то вот оригинальный фрагмент. Это фрагмент книги «Глубокое обучение на Python»
В коде этой фичи сейчас и нет, а в статье — как раз в пункте о скорости:
Насчет numba — какие преимущества и недостатки по сравнению с Cython на практике?
В основном соглашусь — Pandas/Numpy позволяют многое легко и элегантно векторизовать. При этом код получается простой и производительный. Но такими кейсами все не ограничивается. По крайней мере у меня. Нередко, приходится фичи выводить на деревьях. Или тот момент, который я приводил в статье — когда в качестве фичи передается то, что классификатор выдал для предыдущих сэмплах. В таких случаях и векторизация ломается, и со списками приходится работать, и еще много чего нестандартного. Вот в таких случаях большая производительность чистого C#-кода заметна. Просто рабочий момент, на который обращается внимание, когда один и тот же код пишешь там и здесь.
Это технический ресурс. Логично было бы в Кельвинах измерять.