Я понимаю, в чем отличие токена от символа, и в статье проверялась не длина строк в символах, а именно количество слов (токенов в строке)
str(i).SPLIT()
А можете привести пример воспроизводимого кода, в котором показано, что padding=True, truncation=True будет достаточно, для обрезания и с той и с другой стороны предложения. Способом, описанным в статье мы и правда ограничиваем кол-во токенов в предложении. Если вы считаете, что “колхозный” метод, то поделитесь правильным, думаю всем будет интересно.
Обновляя веса в Bert и расширяя его изначальный словарь мы как раз-таки и добиваемся отличной работы модели для конкретной задачи. В чем смысл навешивать лишний слой нейронки поверх Bert, если сам Bert не меняет свои предобученные веса. С тем же успехом можно достать из Bert эмбеддинги и обучить на них небольшую нейронку для их классификации.
Алгоритм Хаффмана эффективен, когда частоты появления символов пропорциональны 1/2n (где n – натуральное положительное число). Это утверждение становится очевидным, если вспомнить, что коды Хаффмана для каждого символа всегда состоят из целого числа бит. Рассмотрим ситуацию, когда частота появление символа равна 0,2, тогда оптимальный код для кодирования это символа должен иметь длину –log2(0,2)=2,3 бита. Понятно, что префиксный код Хаффмана не может иметь такую длину, т.е. в конечном итоге это приводит к ухудшению сжатия данных.
Арифметическое кодирование предназначено для того, чтобы решить эту проблему. Основная идея заключается в том, чтобы присваивать коды не отдельным символам, а их последовательностям.
Благодарю за внимательность, ссылку на статью добавила.
Однако добавлены дополнения, которые, на мой взгляд, улучшают понимание в использовании данных библиотек, так же была добавлена полезная метрика для оценки полученных синтетических данных, рассмотрен модуль Batch из пакета Gretel, который работает с датафреймами и представлено описание API интерфейса Gretel, который позволяет быстро и эффективно сгенерировать синтетические данные.
Датасет был выбран нестандартный, для того, чтобы можно было показать, на каких данных и в каком их представлении можно решать эту задачу. Размышления об этом также есть в статье.
При приближении графика я не вижу описанной вами тенденции. График предсказаний повторяет динамику графика настоящего с некоторыми отклонениями и отличается от предыдущей цены практически на всей дистанции.
С нормальной аугментацией после 20 000 эпох получались достаточно качественные и адекватные изображения, которые в УрНИИ приняли. Насколько полученные изображения помогли, я не могу ответить, т.к. это не моя часть проекта и финальный результат мероприятия для меня неизвестен
Добрый день! Действительно, в данной статье мы описывали отладку собственных приложений (если Вы сами являетесь разработчиком). Возможность и описание отладки сторонних приложений выходит за рамки данной статьи
Насчет использования новых классов – да, они были использованы в качестве замены [Authorize].
Касательно описания примеров использования – изначально я, когда готовил статью, думал, что описания «на словах» будет достаточно, но по прошествии некоторого времени всё-таким соглашусь, лучше было бы описать их кодом. Спасибо за замечание, исправлюсь :)
Относительно использования WindowsTokenRoleProvider – изначально мы его и хотели использовать при доработке механизма авторизации, и на мой взгляд, решение более правильное, но:
1. Мы столкнулись с тем, что существующие группы никак не позволяют одной или несколькими охватить перечень пользователей, которым мы бы хотели давать доступ к ресурсу.
2. Список групп никто не стал бы редактировать под нужды одного нашего ресурса.
Список пользователей с доступом к ресурсу постоянно меняется – скорее всего при этих обстоятельствах пришлось бы хардкодом прописывать пользователей, а не описать красиво <<DOMAIN>>\\<<GROUP>>. Поэтому мы и приняли решение оставить EF, и подтянуть к нему УЗ Windows, чего мы, в принципе, и достигли.
По поводу таблицы Procedures – это отдельная история. Вкратце, на схеме в статье есть две таблицы с ролями:
1. AspNetRoles (к ней цепляется EF и [Authorize] и через неё в принципе регулируется доступ к ресурсу и админке)
2. Roles (группы пользователей внутри ресурса, через которые регулируется доступ к выполняемым отчетам и процедурам).
Две таблицы с ролями – это конечно сильно, но это дает нам легко настраиваемую ролевую модель, которой нам не хватает в группах. Хотя, мы уже потихоньку думаем над тем, как понятно отрефакторить их так, чтобы получить вместо двух таблиц одну.
Вот честно прочитал статью дважды. Как-то уж больно вязко написано. Понял практически только одно - конечная формула, позволяющая посчитать коэффициенты, такая же (что в общем неудивительно). А вот всё остальное так и не понял.
А можно как-то более детально описать те места, которые сложны для восприятия?
К слову. Помню, что результат сильно зависит от правильного выбора уравнения аппроксимации.
Безусловно, выбор вида уравнения является основной сложностью при использовании этого метода на практике. Фактически вид уравнения - это гиперпараметр модели. И его можно определять перебором возможных к использованию видов уравнений. Хотя есть возможности в какой-то мере упростить процедуру подбора вида уравнения. Так, например, в некоторых случаях при аппроксимации исходных данных полиноминальной функцией, применение регуляризации позволяет использовать полиномиальную функцию с избыточно большой степенью полинома. Что несколько снимает сложность точного подбора степени полинома. Но все эти приёмы несколько выходят за рамки данной статьи.
Достаточно "перевернуть" зависимость и рассматривать её как зависимость времени от температуры - и результат аппроксимации будет немного иным. На показанных данных - почти таким же, ибо средняя ошибка отдельного измерения достаточно мала, но чем больше ошибки, тем больше разница.
Верно, при анализе данных к самим этим данным можно подходить различно. И можно не только оси менять местами, но и использовать спрямляющие пространства и (или) кросс-валидацию в самых различных её проявлениях. Тут у аналитика данных широкий набор инструментов, которым надо пользоваться аккуратно и выбирать те инструменты, которые наилучшим образом соответствую условиям задачи.
Кстати, а откуда такая убеждённость, что время измеряется абсолютно точно, а?
Никакой убежденности у меня по этому поводу нет, а есть только набор допущений, которые используются в данном «игрушечном» примере. Ведь если переходить к анализу технической системы, измеряющей температуру, то помимо нестабильности, например, тактового генератора аналого-цифрового преобразователя можно добавить ещё множество других элементов системы, учёт которых явно не добавит ясности изложения самого МНК.
Спасибо за замечания, возможность загрузки ядра на 100% действительно существует при большом количестве задач, но так как количество обрабатываемых страниц тоже ограничено, этого не происходит
Статистический анализ данных на этапе формирования фичей, а также анализ полученных кластеров даст ответ на вопрос в каких интервалах находятся экстремальные значения признаков. Кроме того, общение со специалистом по fraud анализу может прояснить ситуацию
Соглашусь, asyncio действительно актуален, threading рассматривается как один из подходов, позволяющий снизить время выполнения программ, решающих задачи, связанные с вводом-выводом
В приведенном примере производится обработка видео разрешением 1920x1080. Все три промежуточных изображения (im_src, fg_mask, filtered) имеют то же разрешение. Подскажите, пожалуйста, в какой части кода встречается resize?
Алгоритм рассчитан на такие условия. Критерий вертикальности задается параметром max_angle. Если угол отклонения контура от вертикали меньше, чем значение этого параметра (к примеру, 30 градусов), то принимается, что контур связан с осадками. Таким образом, чем больше значение этого параметра, тем более косые дожди алгоритм будет выявлять.
Пример, приведенный вами, отлично показывает, что Bert работает именно с токенами, а не с символами.
@Nehc Спасибо за интерес к публикации.
Я понимаю, в чем отличие токена от символа, и в статье проверялась не длина строк в символах, а именно количество слов (токенов в строке)
str(i).SPLIT()А можете привести пример воспроизводимого кода, в котором показано, что padding=True, truncation=True будет достаточно, для обрезания и с той и с другой стороны предложения. Способом, описанным в статье мы и правда ограничиваем кол-во токенов в предложении. Если вы считаете, что “колхозный” метод, то поделитесь правильным, думаю всем будет интересно.
Обновляя веса в Bert и расширяя его изначальный словарь мы как раз-таки и добиваемся отличной работы модели для конкретной задачи. В чем смысл навешивать лишний слой нейронки поверх Bert, если сам Bert не меняет свои предобученные веса. С тем же успехом можно достать из Bert эмбеддинги и обучить на них небольшую нейронку для их классификации.
Алгоритм Хаффмана эффективен, когда частоты появления символов пропорциональны 1/2n (где n – натуральное положительное число). Это утверждение становится очевидным, если вспомнить, что коды Хаффмана для каждого символа всегда состоят из целого числа бит. Рассмотрим ситуацию, когда частота появление символа равна 0,2, тогда оптимальный код для кодирования это символа должен иметь длину –log2(0,2)=2,3 бита. Понятно, что префиксный код Хаффмана не может иметь такую длину, т.е. в конечном итоге это приводит к ухудшению сжатия данных.
Арифметическое кодирование предназначено для того, чтобы решить эту проблему. Основная идея заключается в том, чтобы присваивать коды не отдельным символам, а их последовательностям.
https://github.com/kolovratgas/PredictStockPrice/blob/a1/final%20cut.ipynb
Добрый день!
Благодарю за внимательность, ссылку на статью добавила.
Однако добавлены дополнения, которые, на мой взгляд, улучшают понимание в использовании данных библиотек, так же была добавлена полезная метрика для оценки полученных синтетических данных, рассмотрен модуль Batch из пакета Gretel, который работает с датафреймами и представлено описание API интерфейса Gretel, который позволяет быстро и эффективно сгенерировать синтетические данные.
Добрый день!
По п.1. согласен.
Датасет был выбран нестандартный, для того, чтобы можно было показать, на каких данных и в каком их представлении можно решать эту задачу. Размышления об этом также есть в статье.
При приближении графика я не вижу описанной вами тенденции. График предсказаний повторяет динамику графика настоящего с некоторыми отклонениями и отличается от предыдущей цены практически на всей дистанции.
Добрый день!
С нормальной аугментацией после 20 000 эпох получались достаточно качественные и адекватные изображения, которые в УрНИИ приняли. Насколько полученные изображения помогли, я не могу ответить, т.к. это не моя часть проекта и финальный результат мероприятия для меня неизвестен
Добрый день! Действительно, в данной статье мы описывали отладку собственных приложений (если Вы сами являетесь разработчиком). Возможность и описание отладки сторонних приложений выходит за рамки данной статьи
Добрый день!
Насчет использования новых классов – да, они были использованы в качестве замены [Authorize].
Касательно описания примеров использования – изначально я, когда готовил статью, думал, что описания «на словах» будет достаточно, но по прошествии некоторого времени всё-таким соглашусь, лучше было бы описать их кодом. Спасибо за замечание, исправлюсь :)
Относительно использования WindowsTokenRoleProvider – изначально мы его и хотели использовать при доработке механизма авторизации, и на мой взгляд, решение более правильное, но:
1. Мы столкнулись с тем, что существующие группы никак не позволяют одной или несколькими охватить перечень пользователей, которым мы бы хотели давать доступ к ресурсу.
2. Список групп никто не стал бы редактировать под нужды одного нашего ресурса.
Список пользователей с доступом к ресурсу постоянно меняется – скорее всего при этих обстоятельствах пришлось бы хардкодом прописывать пользователей, а не описать красиво <<DOMAIN>>\\<<GROUP>>. Поэтому мы и приняли решение оставить EF, и подтянуть к нему УЗ Windows, чего мы, в принципе, и достигли.
По поводу таблицы Procedures – это отдельная история. Вкратце, на схеме в статье есть две таблицы с ролями:
1. AspNetRoles (к ней цепляется EF и [Authorize] и через неё в принципе регулируется доступ к ресурсу и админке)
2. Roles (группы пользователей внутри ресурса, через которые регулируется доступ к выполняемым отчетам и процедурам).
Две таблицы с ролями – это конечно сильно, но это дает нам легко настраиваемую ролевую модель, которой нам не хватает в группах. Хотя, мы уже потихоньку думаем над тем, как понятно отрефакторить их так, чтобы получить вместо двух таблиц одну.
@Akina
А можно как-то более детально описать те места, которые сложны для восприятия?
Безусловно, выбор вида уравнения является основной сложностью при использовании этого метода на практике. Фактически вид уравнения - это гиперпараметр модели. И его можно определять перебором возможных к использованию видов уравнений. Хотя есть возможности в какой-то мере упростить процедуру подбора вида уравнения. Так, например, в некоторых случаях при аппроксимации исходных данных полиноминальной функцией, применение регуляризации позволяет использовать полиномиальную функцию с избыточно большой степенью полинома. Что несколько снимает сложность точного подбора степени полинома. Но все эти приёмы несколько выходят за рамки данной статьи.
Верно, при анализе данных к самим этим данным можно подходить различно. И можно не только оси менять местами, но и использовать спрямляющие пространства и (или) кросс-валидацию в самых различных её проявлениях. Тут у аналитика данных широкий набор инструментов, которым надо пользоваться аккуратно и выбирать те инструменты, которые наилучшим образом соответствую условиям задачи.
Никакой убежденности у меня по этому поводу нет, а есть только набор допущений, которые используются в данном «игрушечном» примере. Ведь если переходить к анализу технической системы, измеряющей температуру, то помимо нестабильности, например, тактового генератора аналого-цифрового преобразователя можно добавить ещё множество других элементов системы, учёт которых явно не добавит ясности изложения самого МНК.
Kmeans вполне рабочий алгоритм для текущей аналитики, простой и понятный. У DBSCAN свои недостатки, например, computational cost
Спасибо за замечания, возможность загрузки ядра на 100% действительно существует при большом количестве задач, но так как количество обрабатываемых страниц тоже ограничено, этого не происходит
Статистический анализ данных на этапе формирования фичей, а также анализ полученных кластеров даст ответ на вопрос в каких интервалах находятся экстремальные значения признаков. Кроме того, общение со специалистом по fraud анализу может прояснить ситуацию
Здесь threading рассматривается как один из подходов, позволяющий снизить время выполнения программ, решающих задачи, связанные с вводом-выводом
Количество потоков не обязательно равно количеству задач
Соглашусь, asyncio действительно актуален, threading рассматривается как один из подходов, позволяющий снизить время выполнения программ, решающих задачи, связанные с вводом-выводом
Здесь речь идёт о том, что все создаваемые потоки работают в рамках одного процесса – исполняемого файла
Спасибо
В приведенном примере производится обработка видео разрешением 1920x1080. Все три промежуточных изображения (im_src, fg_mask, filtered) имеют то же разрешение. Подскажите, пожалуйста, в какой части кода встречается resize?
Алгоритм рассчитан на такие условия. Критерий вертикальности задается параметром max_angle. Если угол отклонения контура от вертикали меньше, чем значение этого параметра (к примеру, 30 градусов), то принимается, что контур связан с осадками. Таким образом, чем больше значение этого параметра, тем более косые дожди алгоритм будет выявлять.