Big Data *

Привет, Хабр! Одной из важных функций-модификаторов в DAX является REMOVEFILTERS, он позволяет, например, убрать фильтр для расчета знаменателя в доле. Однако логика REMOVEFILTERS для столбцов может выглядеть неочевидной, например, REMOVEFILTERS только для одного поля, по которому есть условие в FILTER, не влияет на результат DAX запроса. Так, REMOVEFILTERS(customer[customer_id]) не влияет на FILTER в SUMMARIZECOLUMNS вида FILTER(customer, customer[customer_id] > 2) и для сброса фильтра нужен REMOVEFILTERS(customer) по всей таблице. В связи с этим удобно представить принципы работы REMOVEFILTERS более формально, например, в виде ER диаграммы с подписанными связями. Для построения ER диаграммы был выбран Mermaid и генерация кода диаграммы реализована на C#. Интересующимся особенностями REMOVEFILTERS — добро пожаловать под кат :)

TL;DR: Мы провели бенчмаркинг семи методов, направленных на предотвращение эмерджентного рассогласования и других форм некорректного обобщения с использованием ограниченного объёма alignment-данных. Мы демонстрируем устойчивый трейдофф между способностями модели и согласованием, подчеркивая необходимость более эффективных методов для снижения этого конфликта. Простое включение alignment-данных в микс обучающих данных оказывается недостаточным для предотвращения рассогласования, однако простое наложение KL Divergence penalty на alignment-данные показывает лучшие результаты, чем более сложные подходы.

Привет! Меня зовут Владимир Суворов, я Senior Data Scientist в Страховом Доме ВСК и core-разработчик нашей библиотеки машинного обучения OutBoxML.

В статье сегодня мы поговорим не о выборе алгоритмов, а о том, как автоматизировать весь процесс ML — от данных до деплоя и мониторинга, сократив время на подготовку с дней до часов. Мы разберем это на примере классической задачи с Titanic, реализованной на нашем фреймворке.

Приятного прочтения!

Привет, Хабр! С вами команда Russtech. Сегодня мы хотим рассказать о работе Russ Programmatic, нашего подразделения, разработавшего систему продажи рекламного инвентаря с помощью аукционов в реальном времени. Программатик в DOOH имеет ряд отличий от традиционного digital-программатика. В этой статье мы обсудим эти ключевые особенности и поделимся нашим опытом внедрения программатических продаж.

Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. Apache Spark давно и прочно занял место одного из ключевых инструментов в арсенале инженеров и дата-сайентистов, работающих с большими данными. Его способность быстро обрабатывать огромные объёмы информации, гибкость за счёт поддержки множества языков (Python, Scala, Java, SQL) и возможность решать самые разнообразные задачи — от сложных ETL до машинного обучения и стриминга — делают его незаменимым инструментом в мире анализа данных.

Несколько лет назад наш корпоративный слой данных жил на проприетарных технологиях. Данных было много, а основная СУБД — MPP-система Sybase IQ — долго не обновлялась. Мы регулярно сталкивались с тем, что у кластера «падали» ноды, каталог базы повреждался, порой даже терялись данные, а вендор не спешил выпускать исправления или даже признавать проблему. ETL-процессы работали через IBM DataStage, который также перестал развиваться. Все решения были закрыты, и мы не могли влиять на их улучшение. Vendor lock-in означает, что вы зависите от поставщика: если вендор не поддерживает нужные возможности, развитие замедляется, а долгоживущие ошибки остаются нерешенными. Такое положение становилось критичным.

Мы поняли, что для устойчивого развития платформы нужно срочно искать альтернативу: переходить на стек, которым мы можем управлять сами. При этом важно было сохранить команду: десятки разработчиков и аналитиков уже работали с существующей моделью. Новому решению следовало быть удобным для аналитиков, прозрачным для бизнеса и гибким для инженеров. 

В этой статье рассказываем о том, как мы перешли с проприетарных ETL-инструментов на open-source на базе dbt, какие проблемы решали по ходу внедрения, и как построили экосистему вокруг dbt для автоматизации рутинных задач.

Каждый день одно и то же. Открываешь клиент базы данных, чтобы что-то проверить, посчитать или найти. И снова пишешь почти тот же SELECT, что и вчера, с тем же WHERE и JOIN. Знакомо?

SQL в большинстве случаях не требует сложные 100-строчные запросы с вложенными подзапросами на три уровня глубины. Чаще всего нам нужны простые, отточенные и, главное, эффективные конструкции.

В этой статье я собрал 7 таких запросов-«рабочих лошадок». Это не какой-то там справочник, а готовая шпаргалка для реальных задач.

Футбол больше не сводится лишь к интуиции и традициям. Теперь это соревнование за то, кто сможет эффективнее использовать данные. От продуманной трансферной стратегии «Брайтона» до работы Луиша Кампуша в ПСЖ — клубы всё активнее обращаются к продвинутой аналитике, чтобы опередить соперников. Это означает использование инструментов на базе искусственного интеллекта, машинного обучения и футбольных данных для более раннего поиска талантов, снижения рисков при трансферах и получения конкурентных преимуществ.

Всем привет! Меня зовут Александр Андреев, я инженер данных. Сегодня я хочу рассказать вам о библиотеке Polars - потенциальной замене Pandas, любимой у большинства дата-инженеров и дата-саентистов библиотеки для работы с данными.

В своей статье я последовательно пройдусь от истории библиотеки Polars до примеров кода, технических аспектов ее производительности и в конце дам ссылки на все бенчмарки, обучающие материалы и дополнительные статьи, которые использовались для написания данного обзора-туториала по этой замечательной библиотеке.

Pipes Counting — технический разбор (мобильная разработка + ML)

Приветствуем вас, дорогие читатели! В этой статье мы, ученики 10 класса из школы "Летово", хотим поделиться своим опытом разработки мобильного приложения PipesCounting, созданного для автоматизированного подсчета труб в пачке. За 6 месяцев мы прошли путь от идеи и до публикации приложения, в том числе сбор и расширение датасета, обучение моделей и сборки приложения. Здесь мы хотим поделиться нашим опытом и трудностями с которыми мы столкнулись, чтобы облегчить процесс для тех, кто будет заниматься чем-то похожим, рассказать о возможных подходах и предупредить о сложностях.

С приложением PipesCounting мы заняли второе место в престижном международном конкурсе AI Challenge в категории “Металлургия”, а также постели с ним международную конференцию AI Journey. 

Одним из самых распространенных инструментов для внедрения аналитики является BI инструменты – Tableau, Superset, Datalens и многие другие, десятки их. Это отличные инструменты, но какие бы крутые и сложные визуализации традиционно у каждого из таких инструментов одной из важнейших фич является «Экспорт в Excel» - пользователям нужны выгрузки, детальные данные и т.д. На одном из проектов я обсуждал с заказчиком перспективы развития BI в компании – что уже сделано, что делаем дальше и менеджер задал коварный вопрос: «Артём, дашборды это конечно здорово, но можно ли сделать так, чтобы данные загружались к нам сразу в Excel, причем автоматически». И вот что вы придумали...

Привет, Хабр! Я Илья Назаров, старший инженер в разработке сервисов направления эксплуатации инфраструктуры данных DataPlatform Т-Банка. В работе я часто соприкасаюсь с движками баз данных. Первым и основным движком волею судеб стал Greenplum. Расскажу о своем длинном пути взаимодействия с «Зеленой сливой», как из хаоса и невежества я дошел до истины и гармонии.

В начале карьеры меня много чего удивляло. Тогда я еще не знал, что такое Greenplum,и плохо понимал, что такое MPP. Позднее коллеги на пальцах объяснили мне, что это «постгрес курильщика» и «постгрес поверх кучи постгресов». 

Не менее удивительны для меня процессы. Например, процесс деплоя. Именно тогда я узнал, что в большом продакшене может быть деплой через правку SSH-скриптов на серверах. 

В целом ситуация выглядела страшно интересно: скрипты, процессы деплоя и работы над задачами — все было в новинку. С одной стороны, большой багаж исторически сформированных до меня решений, с другой — большой уровень свободы и минимум ограничений, что как раз и способствовало постоянному росту энтропии и хаоса. Практически сразу я ощутил желание навести во всем порядок. А что из этого получилось — читайте в статье 😉

Данные для ритейла жизненно необходимы: продажи, промо, возвраты, остатки, оборачиваемость. Классическая схема работы такова: бизнес-подразделение формулирует вопрос → аналитики превращают его в задачу → инженеры делают выгрузки → кто-то собирает отчет → отчет попадает на стол к ответственному лицу → через время появляется ответ.

Проблема в том, что скорость бизнеса и скорость проведения анализа не совпадают.

Руководителю дивизиона, директору магазина или маркетологу часто нужен ответ в моменте, а не через неделю. Но BI-процессы инерционны. Поэтому сегодня нужны другие инструменты, позволяющие получить свежие данные, проанализировать, задать вопрос – и получить не просто диаграмму, но выводы, рекомендации или даже конкретное выполненное действие.

Конструкторы отчетов устарели. В век GPT пользователь хочет общаться с данными. 

Что с этим делать?

Компании активно внедряют у себя решения на основе больших языковых моделей: боты техподдержки, умный поиск по базе знаний, выявление мошенников в диалоге или HR-ассистенты.

Но самостоятельно вывести модель в полноценное продакшн-использование не так просто. К тому же для разных сценариев нужно тестировать разные модели. Это требует больших усилий. Чтобы уменьшить порог входа в эту технологию, мы создали собственную платформу — MWS GPT. Под капотом — наша инфраструктура с GPU.

О том, как тестировать разные LLM в MWS GPT и запускать ИИ-агентов без кода скоро расскажем на вебинаре — присоединяйтесь.

Для обучения LLM требуются огромные и разнообразные датасеты. Однако качество данных часто важнее простого объёма: хорошие данные позволяют модели лучше обобщать и снижать ошибки.  К счастью, есть открытые решения, способные помочь с их обработкой.

Сегодня делимся подборкой систем контроля качества ML-датасетов, проектом для автоматической категоризации и системой контроля версий для наборов данных.

Большие языковые модели (LLM) всё чаще адаптируются к downstream-задачам с помощью методов RL, таких как Group Relative Policy Optimization (GRPO), которые нередко требуют тысячи прогонов для освоения новых задач. Мы утверждаем, что интерпретируемая природа языка может предоставлять LLM куда более богатую обучающую среду по сравнению с policy gradient’ами, основанными на разреженных скалярных наградах.

Чтобы проверить эту гипотезу, мы представляем GEPA (Genetic-Pareto) — оптимизатор промптов, который системно использует natural language reflection для извлечения высокоуровневых правил из trial-and-error процесса. Для любой AI-системы, содержащей один или несколько промптов LLM, GEPA сэмплирует траектории на уровне системы (например, рассуждения, вызовы инструментов и их выводы) и анализирует их на естественном языке, чтобы диагностировать проблемы, предлагать и тестировать обновления промптов, а также объединять комплементарные инсайты с границы Парето собственных попыток.

Благодаря такому дизайну GEPA нередко превращает даже несколько прогонов в существенный прирост качества. На четырёх задачах GEPA в среднем превосходит GRPO на 10% и до 20% максимум, при этом используя до 35× меньше прогонов. GEPA также опережает ведущий оптимизатор промптов MIPROv2 более чем на 10% на двух LLM и демонстрирует обнадёживающие результаты как стратегия поиска на этапе инференса для задач оптимизации кода.

Короткий гуглинг по теме показывает, что все рекомендации по внедрению ИИ в бизнесе сводятся к общим фразам. «Выделите одно приоритетное направление», «найдите рутинные операции», «проанализируйте доступные данные». Спасибо, кэп. А делать-то что?

Привет, меня зовут Виталий. Автор телеграмм канала «Детектив данных» про смену профессии и мой вкат в «аналитику» после 30 лет. И да, я уже наверное года полтора использую помощь нейросети при написании кода на Питоне.

Следствие установило, что для получения качественного ответа часто приходится потратить довольно много времени на описание таблицы, где какой тип данных, примеры, формат, количество nan значений, диапазон дат и прочие нюансы.

Будто при допросе вместо описания преступника, следователь внимательно изучает все родинки у допрашиваемого лица. И у адвоката.

В качестве жертвы у нас рабочее время, которое можно потратить на описание задачи.

В какой то момент я подумал, а почему бы не сделать универсальную функцию которая будет собирать эту информацию за меня, и сразу писать какой нибудь универсальный промт, потому что, до кучи мне и его лень писать.

В общем вашему вниманию предлагаю эту функцию. Всё что нужно, это вставить код в ячейку, и в следующей команде указать ваш датафрейм. Принт выведет вам готовый промт с описанием вашей таблицы, расскажет тип данных каждого столбца, покажет примеры значений, диапазоны и количество пропусков, а заодно проверит датафрейм на дубликаты.

Закупки в строительстве — это тысячи заявок, десятки поставщиков и миллионы в сметах, что делает их уязвимым процессом для коррупции. Воруют не только на стройплощадке, но и гораздо раньше — на этапе тендеров, выбора и согласования счетов.

Мы в «Синтеке» решили посмотреть на эту проблему через BI-аналитику. Рассказываем, как данные помогают находить узкие места в закупках и почему без прозрачности здесь не обойтись.

Scale зарабатывает более $750 млн в год на продаже данных для RLHF. Кто собирается их потеснить?

Scale AI — стартап, ранее известный своими контрактами на разметку данных для беспилотных автомобилей и военных проектов, приближается к годовому обороту в $1 млрд благодаря своим дата-сервисам, используемым в техниках вроде reinforcement learning from human feedback (RLHF). Я давно слышал слухи об их масштабах, о том, что они работают буквально со всеми крупными AI-лабораториями — от Meta до OpenAI, но увидеть подтверждение этого в публичных отчетах ощущается совсем иначе.

Ранее мы с вами развернули кластер Kafka. Что дальше?

В этой статье, как всегда, переходим от теории к практике: разработаем собственные продюсер и консьюмер на Python. Это будет не просто демонстрация кода — мы погрузимся в детали работы с Kafka.

Подробно разберем структуру сообщений Kafka,

Углубимся в основы проектирования: от топиков до настройки клиентов,

На практике изучим ключевые процессы: сериализацию, партиционирование, батчинг и сжатие данных.