Так как Metabase - это разработка с открытым исходным кодом, есть возможность скачать исходники с официального сайта бесплатно, там же инструкция по установке. В данном случае у вас уже будет:
∙ Неограниченные трафики
∙ Неограниченное количество информационных панелей
∙ Подключение более чем к 20 баз данных
∙ Использование 15+ визуализаций
∙ Планирование через электронную почту или в Slack
Также есть возможность использовать платную Pro версию, которая включает в себя расширенное встраивание, разрешения на уровне строк, журналы аудита доступа к данным на уровне пользователя, панели мониторинга и таблицы, а также поддержка от создателей через email в течении 3-х дней.
Большинство же платных пакетов относится именно к работе в облаке, в данном случае дополнительно поддерживаются:
∙ Полностью управляемое облако
∙ Автоматическое обновление и резервное копирование
Не знаю, как это происходит в Гугл, но вообще-то почему бы им не пользоваться услугами российских специалистов русской лингвистики? Так же как логично было бы привлечь испанского лингвиста для формирования языковой модели испанского языка. Даже если нет, у них могут быть лингвисты русского языка другой национальности - у нас же существуют углубленные специалисты по английскому, китайскому или немецкому. Если у вас есть в этом потребность, наверное, можно обратиться в поддержку Гугл. Или поискать какие-нибудь конференции, где Гугл, может быть выступал - может быть, касательно русского языка - может быть, там были какие-нибудь адреса почтовых ящиков. Но вообще-то это всё - зыбкие предположения. Меня вполне устраивает и вариант "флешка")
"Качество обработки готовых текстов не так хорошо работает, как в рантайме, но иногда это всё чем мы располагаем. Иногда просто говорят — вот у нас там есть база за десять лет — и спеллчек, будет он вам нужен, в рантайм уже не поставить.
Вообще проблема интерпретации в комментариях и кодах — это интересная тема. Все вот эти тонкости анализа на низком уровне: стили написания переменных, специальные машинные и обычные человечьи комментарии, куски кода. Но мне она в основном приходила в голову во времена, когда у меня была активная переписка кусками кода в перемешку с текстом, либо когда была необходимость, собственно настроить, спеллчек в IDE — на практике,чтобы надо было решать, не встречалось. Вообще-то мне казалось, в PyCharm это как-то интересно работает... И как-то он игнорирует конструкции кода. Но это ж IDE, она видит весь проект, либы, вычленяет функции и так далее.
Собственно, и с фамилиями, мне кажется, самый интересный путь — их оттуда выковыривать NER-ом, примерно как вы говорите о вашей задаче и о вычленении кода из комментариев. И попытаться специальную понималку сделать, отдельную. Её, технически, можно дополнять с каких-нибудь баз, если таковые для задачи имеются. Можно попытаться строить предположения по датам в контексте, по каким-то таким факторам…
А с переводом и комментариями, кстати, наверное, совсем весело — комментарий-то может быть написан на двух языках пополам (притом один из них может существовать только в голове автора). Но, возможно, это не кейс для больших и качественных проектов, которые станут проверять орфографию автоматически.
Но вообще-то, да, проблем действительно куча. Будем думать) Когда возьмёмся за что-нибудь интересненькое — постараемся рассказать."
Интересное замечание. Во-первых, не все алгоритмы анализа близости работают в стохастическом предположении - те же расстояние Левенштейна или алгоритм шинглов. Они отлично работают вне вероятностного подхода.
Анализ с контекстом - это принципиально другой путь, который труднее, и даёт определённые преимущества, однако в контексте рассматриваемой задачи - эти преимущества не особо помогают, а, наоборот могут помешать. Да, "барье" и "Дарье" вы отличите, но с контекстуальным подходом легко возможен следующий сценарий. Например, фамилии Барьев и Дарьев (никак не связанные, кроме похожести написания) встречаются в корпусе в разных контекстах, например Барьев встречается в контексте спорта, а Дарьев в контексте кульинарии и выпечки. Означает ли это, что все их однофамильцы поголовно (или, иначе - в строгом соответствии пропорции, которая отражена в выбранном корпусе) заняты исключительно соответствующей тематикой? Ну, нет. Сможем ли мы избежать этого эффекта "примагничивания тёзок и однофамильцев", пользуясь исключительно средствами контекстуальной вероятности? Без дополнительных телодвижений - очень вряд ли. Напомню, что контекст задачи в основном правописание фамилий.
Во-вторых, я не настаиваю на каком-то из подходов как на единственном. Фактически, я просто даю подспорье тем, кто ищет статистические данные для аналогичных задач. Jumspell, который я тестирую здесь, построен на работе с корпусом и контекстом, Pyenchant, который я также рассмаотриваю, работает на основе полностью прописанного экспертами словаря, без частот. Они интересны в применении к нетривиальной проблеме правки фамилий, которая на практике возникает довольно часто.
BTW, как-то раз мне попадался прекрасный сайт, на котором были представлены чьи-то результаты - просто англоязычный текст "Гордости и Предубеждения", к которому была применена контекстуальная замена. Всё не могу его найти, жалко - очень меня этот текст впечатлил в своё время. Там прямо с первых слов понимаешь, что у контекстуального представления о слове есть и свои минусы - "man" было заменено на "woman", "wife", кажется, на "bride" - и пословно всё выглядит ещё куда ни шло, но от прагматического смысла оригинальных строчек просто следа не остаётся.
Касательно внесения правок - да, я тестирую на рандомных правках - не то чтобы я как-то держу это в тайне. И я не обучаю эти алгоритмы на данной выборке (вот это действительно было бы вредно). Для начала мне интересно было получить эти результаты, на выборке, абстрагированной от механики ошибки. Чтобы специфицировать ошибку, нужно было бы выбрать конкретный характер текстов - рукописный сканируемый (это одни соответствия), вводимый голос (совсем другие), неаккуратная печать на клавиатуре (уже третьи) и т.д. Можно придумать, как прикрутить туда симуляцию более натуральной ошибки (и посмотреть, даст ли соединение классического расстояния Левенштейна и нечёткой матрицы соответствий букв что-то интересное по точности).
Здравая мысль) так будет, конечно, гораздо-гораздо лучше - человек сможет видеть опечатку, и чаще её не допустит. Однако спелчек в рантайме, во-первых, штука не принудительная (если вы хотите получать выборку текстов для алгоритма, то вас могут не устроить опечатки, сделанные по приколу или потому что пофиг), а во-вторых, это всё-таки решение на уровне архитектуры, не всегда это можно реализовать. Когда мы имеем дело с выборкой, вытащенной со стороннего источника (а это, имхо, частый случай в практике обработки текстов) - условно, с сайта социальной сети - мы никак не прикрутим туда спелчекер в рантайм, если его там нет (ну, если только это не наша собственная соцсеть, но тогда это не сторонний источник).
Здравствуйте! Спасибо за комментарий и внимательность! На практике в задачах у меня сложилось такое представление – при значительном уменьшении параметра lr увеличивалась вероятность переобучения. Представление, возможно, ошибочное. Сомнительный момент исправлю.
Lightning И Ignite выполняют примерно одни и те же задачи, одно из ключевых отличий, у Lightning есть возможность вызывать некоторые функции из коробки, которых нет в Ignite. Например обучение на нескольких графических процессорах. А у Fast.ai нет некоторых функций например преждевременной остановки обучения или сохранения контрольных точек.
Celery отлично подходит под данную задачу. Разработка была на Flask потому, что он а) был на слуху б) прост в плане разработки, но теперь видимо такие задачи буду делать на Celery, благодарю за подсказку
Спасибо большое за идею про сравнение разных методов. В данной статье ставилась цель улучшить качество классификатора, построенного методом логистической регрессии.
Цель данных анализаторов, найти явные и вероятные ошибки в программном коде и соответствие стиля кода стандарту PEP8. Как по мне, данные анализаторы прекрасно справились с поставленными задачами.
К сожалению вы не правы, данная проблема является ошибкой. Конечно, она не влияет на функционал и на работоспособность конечного продукта, но ухудшает читабельность кода и может раздражать других разработчиков) Особенно это заметно в больших коллективах программистов.
Спасибо за наглядный пример со split, учту в будущем
Данную статью я писал как новичок для новичков, поэтому не спорю с тем, что я мог быть неточен в формулировках или не совсем верно интерпретировать работу Bert, но если у вас есть замечания к статье, прошу быть конструктивным и предоставлять больше наглядных примеров, как было с примером split, это поможет поднять уровень знаний как читателей, так и автора статьи
Добрый день, жизненно)
Благодарим за комментарий. Да, в настоящий момент эта проблема также актуальна.
Большое спасибо за ваше дополнение, данная информация действительно будет полезна.
Добрый день!
Так как Metabase - это разработка с открытым исходным кодом, есть возможность скачать исходники с официального сайта бесплатно, там же инструкция по установке. В данном случае у вас уже будет:
∙ Неограниченные трафики
∙ Неограниченное количество информационных панелей
∙ Подключение более чем к 20 баз данных
∙ Использование 15+ визуализаций
∙ Планирование через электронную почту или в Slack
Также есть возможность использовать платную Pro версию, которая включает в себя расширенное встраивание, разрешения на уровне строк, журналы аудита доступа к данным на уровне пользователя, панели мониторинга и таблицы, а также поддержка от создателей через email в течении 3-х дней.
Большинство же платных пакетов относится именно к работе в облаке, в данном случае дополнительно поддерживаются:
∙ Полностью управляемое облако
∙ Автоматическое обновление и резервное копирование
∙ Готовый SMPT сервер
∙ Миграция с открытого исходного кода
Добрый день, спасибо за вашу внимательность. Поправим :)
Не знаю, как это происходит в Гугл, но вообще-то почему бы им не пользоваться услугами российских специалистов русской лингвистики? Так же как логично было бы привлечь испанского лингвиста для формирования языковой модели испанского языка. Даже если нет, у них могут быть лингвисты русского языка другой национальности - у нас же существуют углубленные специалисты по английскому, китайскому или немецкому. Если у вас есть в этом потребность, наверное, можно обратиться в поддержку Гугл. Или поискать какие-нибудь конференции, где Гугл, может быть выступал - может быть, касательно русского языка - может быть, там были какие-нибудь адреса почтовых ящиков. Но вообще-то это всё - зыбкие предположения. Меня вполне устраивает и вариант "флешка")
"Качество обработки готовых текстов не так хорошо работает, как в рантайме, но иногда это всё чем мы располагаем. Иногда просто говорят — вот у нас там есть база за десять лет — и спеллчек, будет он вам нужен, в рантайм уже не поставить.
Вообще проблема интерпретации в комментариях и кодах — это интересная тема. Все вот эти тонкости анализа на низком уровне: стили написания переменных, специальные машинные и обычные человечьи комментарии, куски кода. Но мне она в основном приходила в голову во времена, когда у меня была активная переписка кусками кода в перемешку с текстом, либо когда была необходимость, собственно настроить, спеллчек в IDE — на практике,чтобы надо было решать, не встречалось. Вообще-то мне казалось, в PyCharm это как-то интересно работает... И как-то он игнорирует конструкции кода. Но это ж IDE, она видит весь проект, либы, вычленяет функции и так далее.
Собственно, и с фамилиями, мне кажется, самый интересный путь — их оттуда выковыривать NER-ом, примерно как вы говорите о вашей задаче и о вычленении кода из комментариев. И попытаться специальную понималку сделать, отдельную. Её, технически, можно дополнять с каких-нибудь баз, если таковые для задачи имеются. Можно попытаться строить предположения по датам в контексте, по каким-то таким факторам…
А с переводом и комментариями, кстати, наверное, совсем весело — комментарий-то может быть написан на двух языках пополам (притом один из них может существовать только в голове автора). Но, возможно, это не кейс для больших и качественных проектов, которые станут проверять орфографию автоматически.
Но вообще-то, да, проблем действительно куча. Будем думать) Когда возьмёмся за что-нибудь интересненькое — постараемся рассказать."
Интересное замечание. Во-первых, не все алгоритмы анализа близости работают в стохастическом предположении - те же расстояние Левенштейна или алгоритм шинглов. Они отлично работают вне вероятностного подхода.
Анализ с контекстом - это принципиально другой путь, который труднее, и даёт определённые преимущества, однако в контексте рассматриваемой задачи - эти преимущества не особо помогают, а, наоборот могут помешать. Да, "барье" и "Дарье" вы отличите, но с контекстуальным подходом легко возможен следующий сценарий. Например, фамилии Барьев и Дарьев (никак не связанные, кроме похожести написания) встречаются в корпусе в разных контекстах, например Барьев встречается в контексте спорта, а Дарьев в контексте кульинарии и выпечки. Означает ли это, что все их однофамильцы поголовно (или, иначе - в строгом соответствии пропорции, которая отражена в выбранном корпусе) заняты исключительно соответствующей тематикой? Ну, нет. Сможем ли мы избежать этого эффекта "примагничивания тёзок и однофамильцев", пользуясь исключительно средствами контекстуальной вероятности? Без дополнительных телодвижений - очень вряд ли. Напомню, что контекст задачи в основном правописание фамилий.
Во-вторых, я не настаиваю на каком-то из подходов как на единственном. Фактически, я просто даю подспорье тем, кто ищет статистические данные для аналогичных задач. Jumspell, который я тестирую здесь, построен на работе с корпусом и контекстом, Pyenchant, который я также рассмаотриваю, работает на основе полностью прописанного экспертами словаря, без частот. Они интересны в применении к нетривиальной проблеме правки фамилий, которая на практике возникает довольно часто.
BTW, как-то раз мне попадался прекрасный сайт, на котором были представлены чьи-то результаты - просто англоязычный текст "Гордости и Предубеждения", к которому была применена контекстуальная замена. Всё не могу его найти, жалко - очень меня этот текст впечатлил в своё время. Там прямо с первых слов понимаешь, что у контекстуального представления о слове есть и свои минусы - "man" было заменено на "woman", "wife", кажется, на "bride" - и пословно всё выглядит ещё куда ни шло, но от прагматического смысла оригинальных строчек просто следа не остаётся.
Касательно внесения правок - да, я тестирую на рандомных правках - не то чтобы я как-то держу это в тайне. И я не обучаю эти алгоритмы на данной выборке (вот это действительно было бы вредно). Для начала мне интересно было получить эти результаты, на выборке, абстрагированной от механики ошибки. Чтобы специфицировать ошибку, нужно было бы выбрать конкретный характер текстов - рукописный сканируемый (это одни соответствия), вводимый голос (совсем другие), неаккуратная печать на клавиатуре (уже третьи) и т.д. Можно придумать, как прикрутить туда симуляцию более натуральной ошибки (и посмотреть, даст ли соединение классического расстояния Левенштейна и нечёткой матрицы соответствий букв что-то интересное по точности).
Здравая мысль) так будет, конечно, гораздо-гораздо лучше - человек сможет видеть опечатку, и чаще её не допустит. Однако спелчек в рантайме, во-первых, штука не принудительная (если вы хотите получать выборку текстов для алгоритма, то вас могут не устроить опечатки, сделанные по приколу или потому что пофиг), а во-вторых, это всё-таки решение на уровне архитектуры, не всегда это можно реализовать. Когда мы имеем дело с выборкой, вытащенной со стороннего источника (а это, имхо, частый случай в практике обработки текстов) - условно, с сайта социальной сети - мы никак не прикрутим туда спелчекер в рантайм, если его там нет (ну, если только это не наша собственная соцсеть, но тогда это не сторонний источник).
Здравствуйте! Спасибо за комментарий и внимательность! На практике в задачах у меня сложилось такое представление – при значительном уменьшении параметра lr увеличивалась вероятность переобучения. Представление, возможно, ошибочное. Сомнительный момент исправлю.
Lightning И Ignite выполняют примерно одни и те же задачи, одно из ключевых отличий, у Lightning есть возможность вызывать некоторые функции из коробки, которых нет в Ignite. Например обучение на нескольких графических процессорах. А у Fast.ai нет некоторых функций например преждевременной остановки обучения или сохранения контрольных точек.
Спасибо за интерес к публикации :)
Celery отлично подходит под данную задачу. Разработка была на Flask потому, что он а) был на слуху б) прост в плане разработки, но теперь видимо такие задачи буду делать на Celery, благодарю за подсказку
Спасибо большое за идею про сравнение разных методов. В данной статье ставилась цель улучшить качество классификатора, построенного методом логистической регрессии.
Благодарю за интерес к статье. По поводу ссылки... что-то пошло не так, сейчас поправлю.... Спасибо.
Цель данных анализаторов, найти явные и вероятные ошибки в программном коде и соответствие стиля кода стандарту PEP8. Как по мне, данные анализаторы прекрасно справились с поставленными задачами.
Да, именно это я и имел ввиду. Учту в последующих публикациях)
К сожалению вы не правы, данная проблема является ошибкой. Конечно, она не влияет на функционал и на работоспособность конечного продукта, но ухудшает читабельность кода и может раздражать других разработчиков) Особенно это заметно в больших коллективах программистов.
Спасибо за наглядный пример со split, учту в будущем
Данную статью я писал как новичок для новичков, поэтому не спорю с тем, что я мог быть неточен в формулировках или не совсем верно интерпретировать работу Bert, но если у вас есть замечания к статье, прошу быть конструктивным и предоставлять больше наглядных примеров, как было с примером split, это поможет поднять уровень знаний как читателей, так и автора статьи
Спасибо за интерес к статье.
Более подробно с теоретической точки зрения об обучении и дообучении Bert можно познакомиться здесь https://sysblok.ru/knowhow/kak-ustroena-nejroset-bert-ot-google/