Data Engineering *

Начало всех начальных начал 

Добрый день, уважаемые хабропоселенцы ;)) Сегодня мы будем говорить, снова о хакатонах и разработке RAG-моделей, вернее моделей с RAG-подходами и наших попытках выйти за рамки простого векторного поиска. Не так давно мы участвовали на всероссийском хакатоне “Альфа-Будущее”, организованным Альфа-Банком и посвящённому настройке RAG для вопросно-ответных систем. 

Нам необходимо было создать интеллектуальный pipeline RAG-системы, которая по пользовательскому запросу находит релевантные фрагменты в корпусе данных. Вообще, было на выбор две задачи, вторая звучала как “Разработка copilot приложения для клиентов микробизнеса”, но нам ближе оказалась вторая задача. И, конечно же, мы “запилили” своё “модное” решение, о котором вам спешим рассказать в этой статье. Мы проиллюстрируем, как выстраивали архитектуру, какие модели тестировали, на чём остановились и почему, именно такой подход оказался для нас наиболее удачным. Покажем, как работает весь пайплайн — от чанкования документов до гибридного поиска и поделимся результатами бенчмарков и планами развития системы в дальнейшем. Всех заинтересованных лиц приглашаю по традиции под кат ;))

Рассказ о нашем опыте использования Iceberg + Spark. О том, что такое delete-файлы, конфликты транзакций и как с ними справляется операция compaction. Какие проблемы у нас возникли и как мы их решали.

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

«Данные закончились». «Архитектура исчерпана». «LLM упёрлись в потолок».

Звучит умно. Проблема? Это одномерное мышление.

Когда говорят «данные закончились» — имеют в виду текстовые данные для supervised pre-training. Это правда. Но это одна ось из шести, по которым модели становятся умнее.

Inference-time compute (o1/o3), algorithmic efficiency (Mamba, MoE), мультимодальность, tool use, RL и self-play — пять осей, о которых забывают, когда хоронят AI.

В 2020 году консенсус был: GPT-3 — потолок. В 2022: нужны триллионы токенов для каждого улучшения. В 2023: reasoning невозможен без symbolic AI.

Все эти «потолки» были пробиты.

Даю ментальную модель, которая позволит не попадаться на ложные прогнозы о «смерти AI» — и задавать правильные вопросы, когда кто-то уверенно предсказывает будущее.

Двуэнкодерные нейросети, контрастивное обучение, десять датасетов и late fusion. Как мы строили ML-систему ретривала, понимающую человеческий язык вместо фильтров

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

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

— Мне кажется, пользователям понравится.
— Я уверен, что система выдержит.
— Ну сейчас же всё работает.

Проблема в том, что «кажется» и «уверен» плохо масштабируются. А числа — масштабируются отлично.

Привет! Это Данила Ляпин, наставник курса «Специалист по Data Science». Собрал подборку материалов по обработке естественного языка — она охватывает путь от базовых концепций NLP до трансформеров и BERT. Все материалы бесплатны и проверены на практике. Главное — двигаться последовательно, не пропускать основы и обязательно практиковаться на реальных задачах.

- AI, есть задача. Наши смежники скоро выкатят новое поле в исходной системе в Контрагентах, надо отследить и, когда оно появится, пробросить его по потоку данных. Далее протестируй эту новую разработку и загрузку, и если все ок – напиши мне письмо.

- Буду проверять появление поля ежедневно в 9-00, после его появления приступлю к работе!

Использование AI при построении DWH встречает ряд трудностей, основная из которых – галлюцинации. Если в языках программирования можно легко откатить изменения, то если в таблице ошибочно удален столбец  с данными – восстановление его - это еще те танцы с бубном. Ручная работа, штучная задача. А еще перед этим – обязательный бэкап, и чтобы этот бэкап не стал бэкапом Шредингера!

 А если можно создавать отдельную песочницу на каждую задачу разработчику, в том числе и для AI? Тогда если результат генерации не понравится – можно уточнить задачу с учетом сделанного, выделить новую песочницу, а старую – безболезненно удалить.

 Песочница – это отдельная база данных, куда копируются объекты из базы разработки. Если из таблицы необходимы лишь данные, а она сама меняться не будет, то в песочнице достаточно сделать view на основную таблицу. Таких отдельных песочниц у каждого разработчика может быть много.

 Плюсы использования песочницы:

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

2.    Использование AI – он не разрушит основную базу, а будет ураганить только в песочнице.

Привет, Хабр! Меня зовут Лев. Я работаю в поиске Ozon. Сегодня я буду рассказывать про одну из составляющих поиска, а именно про ранжирование.

В этой статье расскажу:
- Что такое ранжирование и факторы ранжирования.
- Как работает поисковое ранжирование в Ozon.
- Как мы работаем с факторами ранжирования.

Я буду переходить от простых примеров к сложным — от орехов и белок к товарам и сервисам.

Существуют множество готовых решений, позволяющих запускать модели «из коробки», и YOLO не исключение. Встроенные механизмы автоматически подбирают параметры обучения модели, что удобно для быстрых экспериментов и прототипов. Но инженерный интерес рано или поздно берёт своё. Хочется попробовать разные версии, разобраться в тонкостях работы модели и понять, почему модель ведёт себя именно так, а не иначе.

С одной стороны, кажется, зачем что-то менять, если уже есть «оптимальное решение»? А с другой исследовательский азарт: «А что, если попробовать так?» или «Почему это работает именно так?».

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

В статье я делюсь собственным опытом экспериментов с разными версиями YOLO на личном датасете.

Сказ о том, как после долгого перерыва я "взял в руки шашки" (поучаствовал в ML-соревновании) и дотащил задачу на "таблички" до первого места на финальном "приватном" лидерборде с помощью простейшей подготовки фич и классической линейной регрессии с регуляризацией, внезапно обогнав при этом всех модных катбустеров, банально переобучившихся на "паблике".

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

Генетический алгоритм как инструмент инженера: практический кейс раскроя полотен

Генетический алгоритм — это «умный» инструмент для автоматизации раскроя материалов (металл, ткань, пластик). Вместо ручного подбора или полного перебора он по принципам естественного отбора ищет компактное размещение деталей, минимизируя отходы. В статье показан практический кейс на Python: как без сложной математики создать алгоритм, который экономит материал, время. Этот подход можно адаптировать под ваши производственные задачи.

В статье рассказывается, как команда интегрировала Qlik с OpenMetadata, создав собственный коннектор вместо использования коробочного решения. Авторы объясняют, почему стандартный подход не обеспечивал нужного lineage и привязки к глоссарию, и как они решили проблему с помощью парсера скриптов Qlik, поддержки include-файлов и доменной модели Business Views. В результате удалось связать дашборды с источниками данных и бизнес-терминами, сократив время поиска отчётов с 2 часов до 2 минут и обеспечив покрытие lineage более чем для 85% приложений. Статья будет полезна тем, кто сталкивается с управлением метаданными в крупных BI-инфраструктурах.

Генерация, понимание и редактирование реалистичных изображений – всё ещё сложнейшая задача для ИИ. Потому качественные данные сегодня на вес золота, а компании готовы тратить миллионы на труд разметчиков и API мастодонтов вроде Gemini Pro Image. Такой подход не только предельно дорог и ресурсозатратен – но и полон ошибок, которых не лишены даже “генеративные ИИ-гиганты”. 

Я хочу рассказать вам о другом, менее популярном сегодня методе сбора визуальных данных – автоматической сборке 3D-сцен и рендере их изображений. Конечно, и этот подход не лишен своих недостатков – но он быстр, дёшев и не так затратен, при этом он покрывает очень тяжёлые для современных моделей ниши. Такой метод позволяет детерминировано понимать и контролировать содержимое генерируемых данных с точностью до миллиметра. В этой статье мы с нуля построим полностью автоматический пайплайн формирования и генерации изображений и метаданных к ним в Blender – для задач генерации, понимания и редактирования изображений. А запускаться и работать он может на чём угодно – от GPU-серверов, до обычного домашнего ПК.

Аналитике редко учат напрямую: как выстраивать аналитическое мышление, находить реальные причины изменений в метриках и выбирать KPI, которые ведут к решениям, а не к «красивым отчётам». Эта статья — о навыках аналитика, которые формируются на практике и чаще всего через ошибки.

Пятничный вечер, бар, шумные разговоры. Мы - компания из нескольких ML-инженеров, DE и DA из Сбера, Магнита, Озона и Альфа-Банка собрались не ради обсуждения задачек в JIRA. Разговор зашел о наболевшем: как найти своих людей и команду мечты? Обсудили зарплату и плюшки, удалёнку и офис, стартапы и зрелые продукты, переработки, карьерный рост и рабочую культуру. В статье - цитаты из обсуждения и обобщённые выводы. А в конце - список вопросов, которые стоит задать на собеседовании, чтобы не ошибиться с выбором и найти тех людей, с кем не страшно будет выкатить релиз в пятницу вечером.

Хочу рассказать о своей разработке и поделиться ей с сообществом habr в виде готового модуля для Python.

Этот модуль решает задачу обновления данных в базе данных. Он выполняет insert/update/delete в одном действии.

Модуль DBMerge проектировался для упрощения ETL процессов по загрузке данных из множества внешних источников в SQL базу.

Для взаимодействия с базой данных используется SQLAlchemy и ее универсальные механизмы, таким образом, разработка не имеет привязки к конкретной БД. (На момент написания статьи, детальные тесты проводились для PostgreSQL, MariaDB, SQLite, MS SQL)

Принцип действия

Принцип действия следующий: модуль создает временную таблицу в базе и записывает в нее весь входящий датасет через операцию массового insert. Далее он выполняет инструкции UPDATE, INSERT, DELETE для целевой таблицы.

Привет, Хабр. Меня зовут Василий Мельник, я product owner решения для потоковой обработки данных Data Ocean SDI в компании Data Sapience. Наша команда приобрела большой практический опыт работы с Apache Iceberg в задачах на стыке традиционной пакетной обработки и near real-time и конкретно с использованием технологий на базе Flink, поэтому мы не могли пройти мимо нового открытого табличного формата (OTF) Paimon от разработчиков Apache Flink. В этой статье я опишу наш опыт и те практические выводы, которые мы сделали на промышленных средах, в виде репрезентативного тестирования, на котором проиллюстрирую ключевые практические сценарии.

Представьте: вы работаете в крупной компании с федеральной сетью. У вас более 300 баз данных Microsoft SQL Server, сотни тысяч объектов — таблиц, процедур, функций, триггеров. Значительная часть бизнес-логики реализована с использованием cross-database references и распределённых запросов через linked servers, что создаёт сложные зависимости между объектами на разных базах и даже серверах.

А теперь представьте, что все изменения в схему вносятся напрямую в production — через SSMS, без версионирования, без ревью, без возможности отката.

Звучит как кошмар? Но именно так работала наша команда более 10 лет.
«Так исторически сложилось» — и это было нормой. Такой подход неизбежно порождал инциденты: от локальных нарушений целостности данных до масштабных простоев, напрямую влияющих на выручку и репутацию компании.

Мы поняли: нужно внедрять CI/CD. Но главная проблема оказалась не в технологиях — а в людях.

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