Как правило, устранение пропусков — обязательный этап предварительной обработки временных рядов. Эта небольшая работа — попытка создания инструмента оперативного подбора модели для импутации (вменения) пропущенных последовательностей.
В данной статье речь пойдёт о том, как используя разные архитектуры нейронных сетей классифицировать данные полученные со сверхширокополосного радара " XETHRU by NOVELDA X4M02 290056-010 ". Моя работа основана на публикации " UWB-gestures, a public dataset of dynamic hand gestures acquired using impulse radar sensors " в которой подробно рассмотрена задача классификации человеческих жестов заснятых на сверхширокополосный радар при помощи свёрточной нейронной сети. Авторы оригинальной статьи выложили весь датасет собранный ими в открытый доступ, благодаря чему у меня появилась возможность воспроизвести их результат, а так же превзойти его применив архитектуры рекуррентных нейронных сетей и трансформеров.
Оригинальная статья:
https://www.researchgate.net/publication/350811193_UWB-gestures_a_public_dataset_of_dynamic_hand_gestures_acquired_using_impulse_radar_sensors https://www.nature.com/articles/s41597-021-00876-0
Данные:
https://figshare.com/articles/dataset/A_Public_Dataset_of_Dynamic_Hand-gestures_Acquired_using_Impulse-radar_sensors_/12652592
Мой GitHub с кодом:
https://github.com/DenissStepanjuk/UWB-Gestures-classification-with-Neural-Networks
Zero-shot Learning (ZSL) - это способность модели выполнять задачи без каких-либо примеров обучения. Она делает это за счёт обобщённых знаний, полученных во время предобучения.
Few-shot Learning (FSL) - это метод, при котором модели предоставляется всего несколько примеров (обычно от 1 до 5), чтобы лучше понять структуру задачи.
Всем привет! Меня зовут Павел, я главный аналитик данных управления подготовки данных Банка.
В этой статье я расскажу, как мы создали самописный инструмент и библиотеку для проверок качества данных, используя только Python и Airflow, и какую пользу это принесло команде.
Хочу рассказать, как спроектированы распределённые вычисления в ClickHouse. Вы узнаете, на что влияет схема кластера (и на что не влияет). Расскажу, как можно на ровном месте создать себе проблему при помощи всего одной таблицы Kafka и нескольких матвьюх. Поделюсь опытом про дебаг и оптимизацию SELECT-запросов к Distributed таблицам: поизучаем планы выполнения и поэксперементируем с настройками в блоке SETTINGS.
Как я отказался от оверинжиниринга и переместился с 30 места на 7 в Enterprise RAG Challenge. И чего не хватило до 1 места.
Сейчас облась ИИ – дикий запад. Никто не знает, как правильно решать задачи, а результаты экспериментов лежат приватными под NDA. Тем ценнее, когда кто-то делится реальным опытом с разбором деталей и подводных камней. Так что делюсь с хабром своей мартовской статьей про участие в Enterprise RAG Challenge от Рината LLM под капотом
Если вы интересуетесь разработкой продуктов поверх LLM, то
Больше техническая заметка, чем статья, поэтому постараюсь изложить мысли как можно кратче.
Приходя из JS/TS мира, когда я впервые написал на Dart, самой прекрасной вещью, помимо многих было использование функций isEmpty или isNotEmpty для String, List, Map, и так далее. Это было невероятно просто и прекрасно не писать каждый раз .length == 0.
Также, очень полезным паттерном были empty/zero значения как Duration.zero, Offset.zero, и другие.
Спустя время, я нашел привычку использовать похожий принцип для работы с различными случаями, а также пришел к мысли - что если мы используем такие значения для большей части объектов, избавляясь от null (не для всех случаев, но тем не менее)? Немного поискав, нашел похожий паттерн в Go и других языках, и продолжил думать.
Меня зовут Андрей Кучеров, и я Lead Data Engineer. Часть моей работы включает обучение команды. Я люблю делиться своим опытом, потому что в работе с данными мелочей не бывает - часто кажущиеся незначительными детали могут кардинально влиять на производительность всего пайплайна. Многие недооценивают важность правильного выбора форматов данных и тонкой настройки процессов чтения, а потом удивляются, почему их Spark-джобы работают медленно и потребляют слишком много ресурсов. Читаем далее что бы разобраться в теме ->
Речь пойдет о моем пет‑проекте — SSDF (super SQL data flow)
Когда‑то я работал в одной компании, у нас было ХД на MSSQL и самописный велосипед для организации ETL/data flow; так и назывался — dataflow.
Выглядел он следующим образом (если описывать вкратце).
Пункт загрузки описывался как одна строка в таблице, основные поля — источник и назначение, например, источник — это view, назначение всегда таблица, ещё давайте упомянем поле горизонта загрузки. Dataflow генерировала и выполняла (для типа view) код удаления из назначения по горизонту и код вставки из вью. Были, конечно, и другие типы — процедура, скрипт, более сложные.
Таблица этих пунктов и являла собой поток данных, и, порядок прописывался жестко, так же был параллелизм (два и более под одним номером n выполняются одновременно).
Главное, что я из этого вынес — что так можно работать и работать вполне неплохо.
Запускайте PostgreSQL, ClickHouse, Airflow, Superset и другие инструменты одним кликом: учите, экспериментируйте, осваивайте новое!
Вопрос, чем заменить Power BI, стал актуален для многих пользователей одной из самых популярных BI-платформ. С точки зрения синтаксиса DAX и удобства работы с моделью данных наиболее очевидной альтернативой является Visiology. Но у этой платформы до недавнего времени не было своего ETL-инструментария. Недавно вендор представил свой Self-Service ETL, и у меня возник логичный профессиональный интерес к его тестированию. В этой статье я делюсь своими исследованиями возможностей SS ETL от Visiology по сравнению с Power Query.
Привет, Хабр! Я Павел Куницын, главный специалист по анализу данных и машинному обучению в ПГК Диджитал. Мы занимаемся разработкой цифровых продуктов в сфере железнодорожных грузоперевозок: интерактивной карты вагонного парка, оптимизатора ремонтов и других решений. В большинстве из них мы применяем машинное обучение.
О том, как мы подходим к этому, я и мои коллеги рассказываем в нашем блоге на Хабре. Например, мы работаем с MLflow, который помогает анализировать результаты и вести учет экспериментов. Но несмотря на доступную автоматизацию, на этапе экспериментов могут возникать определённые сложности. Расскажу о наиболее частых проблемах.
Давайте представим стратегию, зародившуюся в военной сфере, где команды притворяются врагами друг друга, чтобы проверить оборонительные механизмы. Этот подход, известный как red teaming, оказался чрезвычайно ценным и теперь нашёл новое применение. Сегодня, когда искусственный интеллект занимает всё больше места в нашей повседневной жизни, использование метода red teaming для тестирования этих систем становится необходимым. Red teaming для моделей-LLM помогает убедиться, что они не только эффективны в работе, но и безопасны и надежны.
Всем привет! Меня зовут Саттар Гюльмамедов и я работаю в команде ETL платформы DataOps в МТС. Марк Твен как-то написал «Слухи о моей смерти сильно преувеличены» — про Big Data сейчас можно сказать то же самое. Волна хайпа, которую многие пытались оседлать, прошла. Но, как и значительная часть инженерных достижений, работа с большими данными стала рутиной, помогающей развиваться другим направлениям в ИТ.
В экосистеме МТС мы строим для Big Data отдельную платформу, где есть инструменты для хранения и оценки данных, анализа и построения отчетов. Но все начинается с их загрузки и обработки. Получение и преобразование данных — как раз задача библиотек и сервисов, которые делает моя команда. Многие знают мем о перекладывании JSON. А мы как раз делаем инструменты для тех случаев, когда такие задачи уже не столь тривиальны и нужно разобраться с разными типами данных, разными структурам, хранящимися к тому же в разных форматах, и все это нужно сделать в рамках одного процесса.
В этом материале я расскажу про наши решения и условия, лежащие в их основе. Одним наш опыт поможет спланировать эволюцию своих инструментов, другим снимет страх перед сложным стеком технологий Big Data, а третьи просто развлекутся.
Дисклеймер:
чтобы не отклоняться от темы, я не буду подробно описывать концепции ETL и ELT (они хорошо разобраны тут, тут и тут). Наши инструменты следуют парадигме «E[TL]+», т. е. позволяют выполнять трансформации данных как в процессе переноса, так и в целевом хранилище.
Про нашу платформу в общих чертах писал мой коллега Дмитрий Бодин в своей публикации «Customer Happiness: как не только разработать, но и внедрить новый продукт внутри крупной компании». Я продолжу начатый им рассказ и добавлю подробностей о компоненте ETL, его составляющих и нашей команде.
Поделюсь с коллегами практикой создания Docker-сборок на базе Spark разных версий, которые могут запускаться как Spark Kubernetes Executors для параллельного выполнения Spark-задач в кластере.
В нашем конкретном случае сборки включают Pyspark и Cassandra Connector, однако вы можете использовать этот материал как набор практических примеров, чтобы сконструировать собственные Docker-сборки для Spark на другом стеке или с другими приложениями.
В рамках поставленной задачи мне понадобилось подготовить, как минимум, пару Docker-сборок: одну для поддержки легаси кода и другую вполне современную для последующей миграции. Ниже я расскажу об этапах создания таких Docker-сборок, погружаясь в детали по ходу дела.
Когда новичок пытается построить свою первую вопросно-ответную LLM систему, он быстро узнаёт, что базовый RAG - это для малышей и его нужно "прокачивать" модными техниками: Hybrid Search, Parent Document Retrieval, Reranking и десятки других непонятных терминов.
Глаза разбегаются, наступает паралич выбора, ладошки потеют.
А что, если попробовать их все?
Я решил потратить на подготовку к соревнованию 200+ часов и собственноручно проверить каждую из этих методик.
Получилось настолько удачно, что я выиграл конкурс во всех номинациях.
Теперь рассказываю, какие техники оказались полезными, а какие нет, и как повторить мой результат.
Итак, у нас есть данные, и есть требования к ним. От кого? От тех, кто будет ими пользоваться. Если те, кто ставит задачу говорят что "данные плохие" и не могут сформулировать критерии к качеству данных, им можно их подсказать, подсмотрев в предыдущей статье. Таким образом, управление качеством данных - это, в первую очередь, методология, которая обеспечивает некий уровень качества в отношении выбранных данных.
Управление качеством данных - это постоянный процесс. Да, для начала неплохо разобраться с уже имеющимися данными, но наша задача сделать так, чтобы все новые данные, попадающие в систему, проверялись, валидировались, насыщались и, в итоге, соответствовали предъявляемым к ним требованиям. Управление качеством, кстати, является важной частью управления Нормативно-Справочной информацией, MDM (Master Data Management).
Как же сделать так, чтобы данные попадали в системы уже "чистыми"? Думаю, что самый оптимальный способ - это правильно настроить поля ввода, не допуская ввод заведомо некорректный значений, а также предлагать автозаполнение по возможности: например, выбор адреса доставки предлагать из КЛАДР, а данные о компании автоматически заполнять используя специальные сервисы. Таким образом, и людям надо будет вводить меньше информации, и вероятность ошибки будет гораздо меньше.
При подготовке статьи что главное? Источники! А что может быть источником надежнее, чем стандарты ISO? Давайте посмотрим, есть ли стандарты "качества данных"? Есть! ISO/TS 8000 и даже соответствующий ГОСТ 56214. Что ж, читаем определения:
3.1.3 качество (quality): Степень соответствия совокупности присущих характеристик объекта требованиям (3.1.2).
Примечания: 1 Термин "качество" может применяться с прилагательными, такими как "плохое", "хорошее" или "превосходное".
Так. Хватит ГОСТов на сегодня. Итак, есть данные, у них есть качество - характеристика, показывающая степень пригодности данных к использованию, и которое может быть "плохим", "хорошим" или "превосходным". На самом деле, есть 7 основных качественных характеристики: точность, полнота, непротиворечивость, достоверность, своевременность, уникальность и доступность.
В статье описан алгоритм обсчета когортного анализа по датасету транзакций платежей пользователей с реализацией на Python.
Привет! Меня зовут Кирилл Сергеев, я ML-инженер в Циане. В этой статье я расскажу, как мы решили задачу дедупликации объявлений о недвижимости, разработав систему на основе трёх моделей. Эта система автоматически находит и объединяет дублирующиеся объявления, помогая пользователям видеть только актуальную и уникальную информацию.
Материал будет полезен ML-инженерам и специалистам по обработке данных, которым интересно, как мы подошли к решению этой задачи: какие методы использовали, какие проблемы возникли и как мы их преодолели.
