Привет, Хабр!
Сегодня рассмотрим то, что чаще всего ломает даже круто выглядящие модели при работе с временными рядами — неправильная кросс‑валидация. Разберем, почему KFold тут не работает, как легко словить утечку будущего, какие сплиттеры реально честны по отношению ко времени, как валидировать фичи с лагами и агрегатами.
Привет, Хабр! Это тимлид DS группы ранжирования и поиска Дана Злочевская и тимлид группы разработки Михаил Нестеров из Lamoda Tech.
Как и у любой крупной e-commerce платформы, данные — наш главный актив. Они помогают бизнесу принимать обоснованные решения, а пользователям — получать персонализированный, качественный опыт во всех продуктах Lamoda.
Поэтому в продакшене ежедневно работают десятки ML-пайплайнов, а в Airflow запускаются сотни DAG-воркфлоу. Данные готовят и используют более 100 специалистов из самых разных команд: аналитики, дата-сайентисты, ML-инженеры, маркетологи — у каждой свои задачи и логика работы с ними.
Однако с ростом команд, задач и инфраструктуры мы начали сталкиваться с рядом системных проблем:
• Разрозненные подходы к подготовке данных. Каждая команда собирала данные «под себя», по своим правилам и в своем формате, что приводило к дублированию информации и нерациональному использованию вычислительных ресурсов.
• Дублирование логики. Одни и те же преобразования выполнялись в разных пайплайнах с минимальными отличиями — это не только неэффективно, но и увеличивает риск ошибок.
• Сложности с переиспользованием. Найти нужные данные, понять, как они были получены, и интегрировать их свой пайплайн — становилось нетривиальной задачей.
• Рост time-to-market. На каждый новый ML-продукт или эксперимент у команд уходило всё больше времени просто на «разогрев»: сбор данных, выравнивание форматов, отладка пайплайна.
Тогда мы поняли, что пора систематизировать наш подход к хранению и работе с датасетами, и реализовали собственный фреймворк на основе Apache Spark — Feature Storage, который сейчас является стандартом в компании. А позже мы выделили отдельное решение для специфичных кликстрим-данных — Action Storage.
В этой статье мы хотим поделиться нашим опытом построения этих инструментов и рассказать, как со временем эволюционировал наш подход к хранению данных в Lamoda Tech. Надеемся, он будет вам полезен и подарит парочку интересных идей.
Привет, Хабр! На связи Антон Прыгин, аналитик данных в Garage Eight. Расскажу, как с помощью простых SQL-запросов и базовых математических методов получилось построить систему ежедневного мониторинга и алертинга маркетинговых метрик, которая работает в связке с таск-трекером.
Ловушка для бизнеса: почему LLM иногда 'угадывает' математику, а потом подводит? Часто вижу, как на моих ИИ-интенсивах пытаются автоматизировать нейросетями то, что легко делается без них – например, финансовый анализ из PDF. И поначалу LLM даже выдает верные цифры! Это создает опасную иллюзию, что им можно доверять расчеты.
Поэтому решил получить конкретные значения: когда именно LLM начинает ошибаться в элементарных операциях – сложении, вычитании, умножении?
Протестировал 12 моделей на числах разной длины. Результаты – внутри и почему калькулятор все еще ваш лучший друг, когда речь идет о числах больше 4 знаков.
Привет, Хабр! Меня зовут Денис, я один из лидеров направления ВкусВилл Бизнес. Вместе с командой продактов занимаюсь развитием клиентского пути бизнес-клиентов.
Эта статья о том, как мы нашли для себя ещё один способ услышать реальные голоса наших клиентов, чтобы понять, как работает наш продукт в реальной жизни, не опираясь исключительно на метрики. Расскажу, как ИИ помог нам самостоятельно, без разработки увидеть то, что скрывают дашборды.
Это мой вольный перевод статьи "Data Engineering is Not Software Engineering", с рядом моих правок, дополнений, а так же сокращений (так как автор склонен повторять одно и то же, но иными словами или излишне "разжевывать" очевидные вещи). Мне кажется, автор действительно поднял очень важную тему, которую я "чувствовал" по своей практике, но не мог сформулировать так точно, как это сделал он.
Мало кто задумывается, что дата-инженерия и разработка ПО имеют значительные различия. Поэтому распространено мнение, что некое отставание дата-инженерии в части внедрения современных методов разработки, таких как Agile, Test Driving Development и т.д. обусловлено лишь отставанием в освоении этих передовых практик.
На самом деле этот взгляд ошибочен. Хотя дата-инженерия и разработка ПО действительно имеют много общего, между ними существуют значительные различия. Игнорирование этих различий и управление командой дата-инженеров по тем же принципам, что и командой разработчиков ПО, является ошибкой. Особенно этим грешат относительно молодые менеджеры, или те, кто никогда не работал с "датой". Собственно, этим зачастую и вызваны ошибки в пименении "в лоб" соврмененых методой разработки. Дата-инженерия — как томат: технически это фрукт, но это не значит, что его стоит добавлять в фруктовый салат.
Всем привет! Меня зовут Константин Некрасов, я работаю дата-сайентистом в Газпромбанке. Хочу рассказать про инструмент, который серьезно упростил мою повседневную работу с данными, и поделиться им.
Если вы когда-нибудь занимались машинным обучением, то знаете — перед тем как строить модель, нужно как следует изучить свои данные. Этот этап называется EDA (Exploratory Data Analysis), или разведочный анализ данных (РАД). Он критически важен — именно здесь мы находим скрытые закономерности, выдвигаем первые гипотезы и понимаем, как лучше обработать данные для будущей модели.
Но EDA отнимает у дата-сайентистов кучу времени, которое можно потратить на что-то другое и не менее важное: придумать новые признаки, поэкспериментировать с разными алгоритмами или настроить гиперпараметры для более высокой точности модели.
Чтобы облегчить задачу, я разработал класс EDAProcessor, который автоматизирует ключевые этапы EDA: от базовой статистики и визуализации распределений до углубленного анализа корреляций, выбросов и временных зависимостей. Результаты анализа сохраняются в виде наглядных графиков и подробной excel-таблицы, где на разных листах представлены все важные статистические показатели и закономерности в данных.
Сразу оговорюсь — я не изобретаю здесь новых статистических методов, не претендую на научную новизну в области математической статистики, а мое решение не универсально. Каждый набор данных уникален, и полностью автоматизировать его анализ невозможно — всегда нужен опытный взгляд аналитика. Но базовые, наиболее часто используемые методы EDA этот инструмент берет на себя, ускоряя начальный этап работы с данными. Я попытался собрать в скрипт наиболее общие концепции EDA, которые используются в подавляющем большинстве случаев на первоначальной стадии разработки ML-модели.
Сам скрипт вот тут, а под катом я расскажу, как он работает и что делает.
Добрый день. Меня зовут Иван Клименко, я архитектор в департаменте поддержки продаж компании Arenadata. Основное направление моей работы — продукт Arenadata Streaming (ADS), масштабируемая и отказоустойчивая система для потоковой обработки данных в режиме реального времени, предназначенная для корпоративного использования и построенная на базе Apache Kafka и Apache NiFi.
Сегодня я хотел бы обсудить концепцию потокового программирования, уделить внимание FlowFile и рассмотреть подходы к разработке потоков обработки данных в NiFi. Эта статья в первую очередь адресована новичкам, интересующимся NiFi, а от опытных разработчиков я буду рад услышать дополнения и конструктивную критику.
Когда хайп захватывает умы, кажется, что любое техническое решение должно строиться вокруг новой модной технологии и что теперь-то мы ух заживем! Сегодня у нас на хайпе RAG (Retrieval-Augmented Generation), вчера — NFT, позавчера — блокчейн везде и всюду.
Давайте попробуем разобраться, нужен ли RAG на самом деле, или это просто «новый блокчейн» и через год все набьют шишки и забудут о нем.
Дорогие друзья, порадуемся тому факту, что даже в мире IDE есть свои пауки. Не те, что заползают в ваш код, добавляя баги, а настоящие спасатели программного хаоса. Сегодня речь пойдет о SpyderIDE, любимице научного сообщества и тех, кто слишком увлечен pandas и numpy, чтобы замечать окружающий мир.
Привет!
Кажется, первая статья нашла своего благодарного читателя.Снова мысли от CDO трудящегося вместе с одной небольшой компанией ру-сегмента.
Продолжу о том, что "наболело".
Эта статья может быть Вам полезна, если консалтинг/интегратор/CTO/CIO/сын маминой подруги настойчиво хочет решить все Ваши "проблемы" в аналитике классным корпоративным хранилищем, далее - DWH.
Привет! Меня зовут Антон Моргунов, я инженер МО в «Базис.Центре» и программный эксперт курса «Инженер машинного обучения» в Яндекс Практикуме. В этой статье я расскажу, что такое машинное обучение, чем занимается инженер МО, какие навыки и компетенции ему пригодятся, а также в каких компаниях востребован этот специалист. А в конце дам пару советов для начинающих инженеров МО.
Системы дополненной генерации (RAG) были разработаны для улучшения качества ответа крупной языковой модели (LLM). Когда пользователь отправляет запрос, система RAG извлекает релевантную информацию из векторной базы данных и передает ее в LLM в качестве контекста. Затем LLM использует этот контекст для генерации ответа для пользователя. Этот процесс значительно улучшает качество ответов LLM с меньшим количеством «галлюцинаций».
Краткая цель статьи — сделать потоки данных проще, более тестируемыми и управляемыми с DTO и Runtime Model структурой.
Эта статья — набор мыслей и экспрессии опыта моего текущего видения этой проблемы, как комбинации опыта от работы над проектами и может быть, переизобретение колеса:) Но, в то же время, я хотел бы поделиться этими мыслями — и, надеюсь, вдохновить и посмотреть на структуры данных.
Концепт использует немного функционала Entities, описанных Robert C. Martin (Uncle Bob) в Clean Architecture, также Model‑Driven engineering вместе с концептом immutability.
Эта статья:
— разделена на секцию теории и применения, чтобы статью можно было понять разработчикам не знающим язык используемый в примерах (Dart).
— в основном фокусируется на client‑side (frontend, app, server‑side рендеринг) разработчиках, но думаю что может быть интересна и другим разработчикам..
— для примеров используется абстрактное финансовое приложение и язык Dart.
Представьте себе, что от точности разметки изображений зависит успех вашего проекта: будь то способность нейросети распознавать сложные объекты или автоматизация рутинных задач. Но в чем ее специфика, какие виды разметки изображений существуют и какой тип аннотации лучше подходит под ваш проект?
В этой статье мы раскрываем все тонкости процесса, делимся проверенными методами и реальными кейсами от команды Data Light, чтобы помочь вам вывести проекты на новый уровень. Если вы хотите разобраться в разметке изображений и узнать, как избежать подводных камней, эта статья точно будет вам полезна.
Всем привет! Меня зовут Илья Черников, я аналитик больших данных в X5 Tech, сейчас занимаюсь аналитикой и оценкой активностей CVM маркетинга экспресс-доставки “Пятёрочки”.
В статье я расскажу о том, как мы решали вопрос автоматизации оценки эффективности большого количества маркетинговых кампаний с помощью бутстрапа в PySpark. Я опишу различные подходы к реализации бутстрапа с их плюсами и минусами, а также расскажу об итоговом варианте, который мы выбрали для себя.
Привет, Хабр! Меня зовут Дмитрий, я инженер данных, и это моя первая статья. В ней я хочу поделиться своим пет-проектом, который посвящен созданию ETL-процесса — важного элемента в работе любого Data Engineer. Мой проект направлен на извлечение данных из электронной почты и их загрузку в базу данных Greenplum для анализа.
Идея возникла из личной потребности контролировать расходы в продуктовых сетях, таких как "ВкусВилл". Существуют готовые решения, но я хотел создать свою систему, где данные из разных магазинов собираются в одном месте для более детального анализа и визуализации.
Готовые приложения часто ограничены в настройке, поэтому я решил использовать Python для автоматизации обработки данных, а Greenplum для их хранения и аналитики. В статье я расскажу, как мне удалось автоматизировать процесс извлечения данных из писем "ВкусВилл", структурировать их и загрузить в базу для дальнейшего анализа.
Принцип «тестируй все» не повышает, а разрушает качество данных. Сотни бесполезных алертов создают шум, в котором тонут действительно важные сигналы, а команда перестает на них реагировать. В Google и Monzo от этого уже отказались. Рассказываем, как перейти от тотального тестирования к точечным проверкам узлов с максимальным радиусом влияния и почему один правильный тест на источник важнее сотни проверок в витринах.
Рассказываем, какие задачи решают оркестраторы в проектах внедрения корпоративных хранилищ данных. Выясняем, в чем разница между инструментами, и почему Dagster становится все популярнее в DWH-проектах, чем Airflow.
Я Евгений Прочан, в платформенной команде Magnit OMNI развиваю инфраструктуру DWH. Расскажу здесь, почему нам понадобилось перейти от батчинга к CDC и как мы это делали. Причин перехода было две: потребность бизнеса в расширении возможностей инфраструктуры и нестабильность нашего старого процесса репликации.
Мы используем в основном базы данных PostgreSQL. Оттуда пакетами раз в час передаём данные в S3, ClickHouse и таблицы Iceberg. Наша потоковая нагрузка достигает примерно полутора терабайта данных, 6000 операций в секунду (около 1500 в самой нагруженной базе данных).
