Ответ простой, но под этим простым ответом стоят сложные и интересные концепции и личный опыт, которыми хотелось поделиться. Ничего не мешает взять текущий пайплайн и применить для генерации не одно токена (класса), а для целой последовательности. Задача классификации hatespeech была взята в качестве демонстрации.
В целом, дельное замечание, но с LLaMA есть некоторые сложности. На данный момент порог вхождения выше для того, чтобы начать использовать эту модель дома. Во-первых, модель пока не представлена на HuggingFace и официально веса недоступны (да, есть неофициальные способы скачать веса). Во-вторых, квантизованная модель также не представлена, поэтому нужно квантизовать самому для чего требуются ресурсы. В-третьих, как вы и сказали, весов Stanford Alpaca готовых пока нет. GPT-J отличный бейзлайн, точка старта для тех, кто начинает работать с трансформерами. Кроме того, описанный здесь пайплан может быть применен к LLaMA.
С ходу сложно сказать, что получится, но идея интересная, стоит поисследовать! В целом никаких проблем нет, если грамотно составить датасет для дообучения. Более того, предобученная GPT-J тренировалась в том числе на данных с гитхаба, значит, должна уметь работать с кодом.
По поводу того, что алгоритм рассчитан на традиционную архитектуру – тут Джеффри как раз указывает, что алгоритм был бы более эффективен на специализированном компьютере, который он называет «смертным».
Кажется, что идея очень похожая на Хебба, однако, в правилах Хебба нет порога для отделения положительных и негативных образцов, не говоря уже про остальные элементы современных нейросетей, которые перекочевали в алгоритм FF. Кроме того, в самой статье Хебб не упоминается.
> timestamp из названия файла нельзя парсером подтащить в виде значения в поле insertTime?
Нет, всё-таки insertTime отражает время фактической вставки в таблицу с "сырыми" данными. По этому полю потом таблица очищается по TTL. Может так выйти, что в обработку попадёт файл с timestamp в имени = неделя назад (а TTL = 3 суток) и данные из этого файла уйдут в молоко. К слову, парсер вставляет timestamp из имени файла в отдельное поле (скажем, field3) и потом "Очиститель" делает вот так при сборке чистой партиции: ORDER BY field1, field2, field3, ... LIMIT 1 BY field1, field2, field3, ...;
> Да и без аргумента replacing движок оставляет только самую последнюю вставленную строку.
Нам как раз нужно было оставлять не самую свежую строку, а ту, у которой timestamp в имени файла самый ранний. При этом файлы могут поступать в обработку в любом порядке, т.е. не привязанном к timestamp из имени ...
Для достижения данной цели могут применяться различные решения - многое зависит от того к каким инструментам и каким этапам процесса вы имеете доступ.
Можно, к примеру, увеличить период хранения сообщений в топике Kafka до нескольких суток и периодически делать бэкапы топика в БД (или ElasticSearch, если данные долго хранить не планируете). После этого уже выполнять вычисления на сохранённых данных в БД, если бизнес требования допускают отклонения от моментальной онлайн-потоковой обработки данных. Либо сперва обрабатывать данные как есть в потоке онлайн, а потом проводить пост обработку на уже большом наборе данных.
Если же есть проблема, что данные от источника периодически в принципе не доходят до Kafka, то стоит задуматься над механикой работы источника. В случае с кейсом "Интернет-рекламы" - можно добавить в JS-скрипты механизм бэкапа действий пользователя в "Local Storage" и раз в N часов повторно отправлять всё что накоплено. После, уже на стороне приёмника, выполнять повторную аналитику на выявление новых данных, которые не дошли сразу во время события.
Здравствуйте! Спасибо за ваш комментарий. Да, это идеальный мир, но мы советуем хотя бы стремиться к регулярным контролируемым ротациям. Иначе сотрудник долго работает на проекте и начинает скучать, выгорать.
Здравствуйте. Есть несколько разных определений понятий ООП. Это одно из них. Например, в статье по ссылке http://www.tonymarston.co.uk/php-mysql/abstraction.txt приведены несколько определений, причем сильно отличающихся друг от друга.
Ответ простой, но под этим простым ответом стоят сложные и интересные концепции и личный опыт, которыми хотелось поделиться. Ничего не мешает взять текущий пайплайн и применить для генерации не одно токена (класса), а для целой последовательности. Задача классификации hatespeech была взята в качестве демонстрации.
В целом, дельное замечание, но с LLaMA есть некоторые сложности. На данный момент порог вхождения выше для того, чтобы начать использовать эту модель дома. Во-первых, модель пока не представлена на HuggingFace и официально веса недоступны (да, есть неофициальные способы скачать веса). Во-вторых, квантизованная модель также не представлена, поэтому нужно квантизовать самому для чего требуются ресурсы. В-третьих, как вы и сказали, весов Stanford Alpaca готовых пока нет. GPT-J отличный бейзлайн, точка старта для тех, кто начинает работать с трансформерами. Кроме того, описанный здесь пайплан может быть применен к LLaMA.
С ходу сложно сказать, что получится, но идея интересная, стоит поисследовать! В целом никаких проблем нет, если грамотно составить датасет для дообучения. Более того, предобученная GPT-J тренировалась в том числе на данных с гитхаба, значит, должна уметь работать с кодом.
Хорошо и осмысленно отвечает на вопросы в домене, использованном при дообучении.
Добрый день! Fine-tuning на описанных данных длился 3 эпохи и занял примерно 52 минуты. Все использованные модели являются предобученными.
Добрый день! Ссылки в данный момент кликабельны.
Добрый день! Это опечатка при форматировании статьи, тесты проводились на корректном коде.
Спасибо за развернутое дополнение к статье!
По поводу того, что алгоритм рассчитан на традиционную архитектуру – тут Джеффри как раз указывает, что алгоритм был бы более эффективен на специализированном компьютере, который он называет «смертным».
Кажется, что идея очень похожая на Хебба, однако, в правилах Хебба нет порога для отделения положительных и негативных образцов, не говоря уже про остальные элементы современных нейросетей, которые перекочевали в алгоритм FF. Кроме того, в самой статье Хебб не упоминается.
На Хабр нашими экспертами не были найдены статьи по данной теме.
Отправили пример дашбоарда по указанному адресу
Cпасибо за отзыв! Да, конечно. Пришлите, пожалуйста, ваш мейл - поделимся.
Спасибо, идею поняли, поправили)
Подскажите, пожалуйста, в каком месте и для решения какого вопроса предлагаете использовать ReplicatedMergeTree?"
Благодарим за обратную связь!
> timestamp из названия файла нельзя парсером подтащить в виде значения в поле insertTime?
Нет, всё-таки insertTime отражает время фактической вставки в таблицу с "сырыми" данными. По этому полю потом таблица очищается по TTL. Может так выйти, что в обработку попадёт файл с timestamp в имени = неделя назад (а TTL = 3 суток) и данные из этого файла уйдут в молоко.
К слову, парсер вставляет timestamp из имени файла в отдельное поле (скажем, field3) и потом "Очиститель" делает вот так при сборке чистой партиции:
ORDER BY field1, field2, field3, ...
LIMIT 1 BY field1, field2, field3, ...;
> Да и без аргумента replacing движок оставляет только самую последнюю вставленную строку.
Нам как раз нужно было оставлять не самую свежую строку, а ту, у которой timestamp в имени файла самый ранний. При этом файлы могут поступать в обработку в любом порядке, т.е. не привязанном к timestamp из имени ...
Опечатку поправили, спасибо за внимательность)
Никаких проблем - делайте так же, как в PostreSQL.
Spark SQL поддерживает оконные функции, в том числе LAG и LEAD.
Ссылка на официальную документацию: https://spark.apache.org/docs/latest/sql-ref-syntax-qry-select-window.html
Для достижения данной цели могут применяться различные решения - многое зависит от того к каким инструментам и каким этапам процесса вы имеете доступ.
Можно, к примеру, увеличить период хранения сообщений в топике Kafka до нескольких суток и периодически делать бэкапы топика в БД (или ElasticSearch, если данные долго хранить не планируете). После этого уже выполнять вычисления на сохранённых данных в БД, если бизнес требования допускают отклонения от моментальной онлайн-потоковой обработки данных. Либо сперва обрабатывать данные как есть в потоке онлайн, а потом проводить пост обработку на уже большом наборе данных.
Если же есть проблема, что данные от источника периодически в принципе не доходят до Kafka, то стоит задуматься над механикой работы источника. В случае с кейсом "Интернет-рекламы" - можно добавить в JS-скрипты механизм бэкапа действий пользователя в "Local Storage" и раз в N часов повторно отправлять всё что накоплено. После, уже на стороне приёмника, выполнять повторную аналитику на выявление новых данных, которые не дошли сразу во время события.
Здравствуйте! Спасибо за ваш комментарий. Да, это идеальный мир, но мы советуем хотя бы стремиться к регулярным контролируемым ротациям. Иначе сотрудник долго работает на проекте и начинает скучать, выгорать.
Вот еще интересная статья на эту тему www.infoworld.com/article/2075271/encapsulation-is-not-information-hiding.html
Здравствуйте. Есть несколько разных определений понятий ООП. Это одно из них.
Например, в статье по ссылке http://www.tonymarston.co.uk/php-mysql/abstraction.txt приведены несколько определений, причем сильно отличающихся друг от друга.