Data Engineering *

Когда новичок пытается построить свою первую вопросно-ответную LLM систему, он быстро узнаёт, что базовый RAG - это для малышей и его нужно "прокачивать" модными техниками: Hybrid Search, Parent Document Retrieval, Reranking и десятки других непонятных терминов.
Глаза разбегаются, наступает паралич выбора, ладошки потеют.

А что, если попробовать их все?
Я решил потратить на подготовку к соревнованию 200+ часов и собственноручно проверить каждую из этих методик.
Получилось настолько удачно, что я выиграл конкурс во всех номинациях.

Теперь рассказываю, какие техники оказались полезными, а какие нет, и как повторить мой результат.

Я сам работал преподавателем бауманки до 2019 г., потом по совету Медведева ушел в бизнес. Знаю, что среди пользователей Хабра много студентов и преподавателей МГТУ им. Баумана, возможно пост окажется интересным и для контингента других вузов. Пост про анализ данных, но при его создании использовались лишь базовые навыки Data Science. Подобный анализ по своему вузу любой пользователь Excel может провести самостоятельно, в конце статьи есть инструкция.

Изучил Python за короткий срок. Личная история. Взяли без знаний, но я смог до всяческих дедлайнов, пройдя огромное количество стресса, изучить язык программирования и даже этим спасти проект.

В этой статье мы не только установим локальный (и бесплатный) аналог ChatGPT, но и сделаем обзор нескольких открытых LLM, разберёмся в продвинутых настройках LM Studio, подключим чатбота к Visual Studio Code и научим его помогать нам в программировании. А ещё мы посмотрим, как можно тонко настраивать поведение модели с помощью системных промптов.

Привет, Хабр!

Меня зовут Петр. Я работаю инженером по данным в Okko и обожаю ClickHouse. 

Примерно в середине прошлого года мы начали переезжать с PostgreSQL на ClickHouse. Одной из главных причин переезда была низкая производительность: среднее время аналитического запроса составляло около минуты. Сейчас, после переезда, среднее время запроса в аналитическом кластере — около 2 с. И это не предел.

Я расскажу, как мы пришли к текущему состоянию хранилища данных, какие ошибки совершили, какие шишки набили, и о каких фишках кликхауса предпочли бы знать заранее.

Статья в основном для тех, кто только начинает свой путь работы с кликхаусом: мы посмотрим, как делать не надо, и как можно сделать лучше.

В этой статье не будет объяснений почему для переезда мы выбрали именно этот инструмент. Не будет и глубокой теории о его внутреннем устройстве. Отметим лишь: в правильных руках ClickHouse — одна из самых быстрых колоночных СУБД для OLAP запросов.

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

Расскажу, как платформа данных развивалась, и к чему мы пришли на конец 2024 года. Эта статья — ретроспектива моей почти шестилетней работы и текущих реалий нашей платформы данных.

Привет! Меня зовут Игорь Кальченко, я ML‑разработчик в МТС AdTech. Больше полугода назад я окончил Школу аналитиков данных МТС. Это были насыщенные и интересные 10 месяцев, о которых я расскажу в этом тексте. Дисклеймер: это опыт одного выпускника программы, и он может расходиться с другими оценками, я не претендую на истину в последней инстанции.

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

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

В нашем семантическом слое данных больше  20 000 метрик, и есть десятки разрезов для каждой из них. Под катом рассказываю, как мы храним терабайты данных и автоматизируем добавление новых разрезов в отчёт M42.

Netflix сделал ставку на то, чтобы у каждого нового зрителя в списке просмотров было минимум три фильма или сериала «на потом». Для этого они упрощают интерфейс, мотивируют добавлять контент в очередь и персонализируют всё, что вы видите. Они постоянно экспериментируют с разными версиями интерфейса, тестируют расположение кнопок и оформление. Для одного и того же фильма создаются десятки вариантов обложек, чтобы показать вам именно то, что вас зацепит. Сразу после регистрации вы получаете трейлер оригинального контента, подобранного под ваши предпочтения, а настройки профиля встроены в сам процесс адаптации.

Как Netflix научился читать мысли пользователей? Зачем собирает и анализирует сотни терабайт данных? Какой подход помогает обгонять конкурентов?

Привет, Хабр! Меня зовут Алексей Жиряков. Я руководитель направления в KION и член программного комитета конференции Data Internals. Давайте поговорим о том, зачем нужен Data-driven (и как он устроен в KION), его проблемах и том, нужен ли он вам.

За счёт правильных, даже необязательно новых, а просто верно выбранных архитектурных подходов можно заставить работать не один конкретный запрос, а тысячу или даже  миллион. Это становится краеугольным камнем, потому что объёмы данных растут с такой скоростью, которую мы даже представить себе не могли ещё пять лет назад.

Привет, Хабр! Именно так считает наш сегодняшний гость – Дмитрий Немчин, руководитель направления эксплуатации инфраструктуры данных в Т-банке и по совместительству член программного комитета Data Internals, профессиональной конференции
по инженерии, базам и системам хранения и обработки данных.

В беседе Дмитрий рассказал о своём пути в данные и программный комитет конференции, поделился интересными кейсами и проблемами, связанными с ростом объёмов данных и необходимостью управления ресурсами. А также объяснил, как дата-инженеру остаться востребованным в будущем, где ИИ может проникнуть абсолютно во все сферы жизни.

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

Привет, Хабр! Меня зовут Александр Маркачев и я — Data Engineer команды Голосовой Антифрод в билайн. Расскажу, как борьба с мошенниками может обернуться личным вызовом.

Все техники сопровождаются объяснениями, примерами и рекомендациями для самостоятельного повторения.

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

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

Всем привет! Меня зовут Алексей Николаев, я работаю дата-инженером в команде ETL-платформы MWS Data (ex DataOps). Часто сталкиваюсь с тем, что в сложной инфраструктуре и больших проектах простые, на первый взгляд, задачи по работе с данными очень сильно усложняются. В результате возникают ситуации, когда хорошие практики превращаются в плохие решения, а плохие практики как раз могут дать хороший результат.

Мои коллеги уже рассказывали про нашу платформу, ее внедрение внутри экосистемы и наши инструменты для работы с данными. В процессе развития продукта перед нами встала проблема массовых регламентных загрузок данных из реляционных источников. Для этого мы создали внутренний инструмент — библиотеку d-van. В качестве движка в ней используется Apache Spark, с которым она взаимодействует через библиотеку onETL. На примере d-van я покажу нестандартный подход к использованию возможностей Apache Spark. Расскажу, какие задачи можно решить с помощью режима master=local и как свой инструмент может стать альтернативой Apache Nifi или Debezium.

Привет! Меня зовут Наталия Вареник, я DS-инженер в Авито, занимаюсь моделями распознавания изображений. Расскажу про один из наших проектов — пайплайн для распознавания номеров с фотографии свидетельства транспортного средства (СТС). В статье описала особенности задачи и рассказала, как мы решали её с помощью декомпозиции. 

Материал будет полезен начинающим и мидл-DS-инженерам, которые хотят узнать больше про декомпозицию задачи на этапах разметки и построения моделей. 

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

Привет! Я Сергей Кляхандлер, senior DS-инженер в команде LLM Авито. 

В статье рассказываю, как мы разработали ML-модель, которая автоматически генерирует описания для объявлений из категории Одежда и Обувь. Подробно расписываю, откуда мы брали данные для обучения, какую архитектуру использовали и как тренировали модель. А в конце говорю про важную часть работы — фейлы.

Статья будет полезна DS-инженерам, которые работают с мультимодальными LLM-моделями.

Привет! Меня зовут Руслан Гилязев, я работаю в подразделении DS SWAT в Авито, руковожу командой платформы Item2param. В этой статье рассказываю, с помощью каких технологий мы решаем задачу классификации объявлений и почему это важно для бизнеса. Материал будет полезен DS-инженерам любого грейда и backend-инженерам, которые интересуются темой data science. 

В этой статье — без воды, трюизмов, академизмов и формул — разберёмся, в чём принципиальное отличие машинного обучения (ML) от до-ИИ программирования, а затем генеративного ИИ от классических моделей машинного обучения (ML). Поговорим о типах генеративных моделей, их архитектуре и областях применения.
Заодно затронем важный вопрос: где проходит граница между классическим программированием и вероятностным творчеством, на котором построены современные нейросети.
Статья ориентирована прежде всего на тех, кто делает первые шаги в ИИ, но если ты начинающий ML-инженер, архитектор ИИ-приложений, основатель стартапа или просто хочешь разобраться, что на самом деле происходит под капотом у ChatGPT и Midjourney — ты, скорее всего, найдёшь здесь для себя что-то полезное.

Привет, дорогой друг. Меня зовут Максим и я data-инженер в одной из прекрасных команд AI area компании Домклик. Правильно перевозить байтики с места на место нам помогает огромный зоопарк инструментов. И, кажется, мы приручили ещё одного питомца.

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

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

Всем привет! Меня зовут Саттар Гюльмамедов и я работаю в команде ETL платформы DataOps в МТС. Марк Твен как-то написал «Слухи о моей смерти сильно преувеличены» — про Big Data сейчас можно сказать то же самое. Волна хайпа, которую многие пытались оседлать, прошла. Но, как и значительная часть инженерных достижений, работа с большими данными стала рутиной, помогающей развиваться другим направлениям в ИТ. 

В экосистеме МТС мы строим для Big Data отдельную платформу, где есть инструменты для хранения и оценки данных, анализа и построения отчетов. Но все начинается с их загрузки и обработки. Получение и преобразование данных — как раз задача библиотек и сервисов, которые делает моя команда. Многие знают мем о перекладывании JSON. А мы как раз делаем инструменты для тех случаев, когда такие задачи уже не столь тривиальны и нужно разобраться с разными типами данных, разными структурам, хранящимися к тому же в разных форматах, и все это нужно сделать в рамках одного процесса.

В этом материале я расскажу про наши решения и условия, лежащие в их основе. Одним наш опыт поможет спланировать эволюцию своих инструментов, другим снимет страх перед сложным стеком технологий Big Data, а третьи просто развлекутся. 

Дисклеймер:
чтобы не отклоняться от темы, я не буду подробно описывать концепции ETL и ELT (они хорошо разобраны тут, тут и тут). Наши инструменты следуют парадигме «E[TL]+», т. е. позволяют выполнять трансформации данных как в процессе переноса, так и в целевом хранилище.

Про нашу платформу в общих чертах писал мой коллега Дмитрий Бодин в своей публикации «Customer Happiness: как не только разработать, но и внедрить новый продукт внутри крупной компании». Я продолжу начатый им рассказ и добавлю подробностей о компоненте ETL, его составляющих и нашей команде.