В современной индустрии искусственного интеллекта происходит тихая революция, которую эксперты называют «DB-фикацией» (DBfication). Речь идет о масштабном процессе внедрения принципов и технологий из мира баз данных в рабочие процессы машинного обучения (ML). О том, почему ML-инженерам пора поучиться у архитекторов СУБД сорокалетней выдержки, рассказал Арун Кумар, доцент Калифорнийского университета в Сан-Диего, в рамках подкаста TWIML AI.
🔄 Что такое DB-фикация и почему она неизбежна 2:26
Термин «новая DB-фикация ML/AI» был предложен Аруном Кумаром для описания эволюции инструментов машинного обучения. По его мнению, сфера ML сейчас проходит тот же путь, который системы управления базами данных (СУБД) прошли в 80-е годы . Когда реляционная алгебра и SQL начали завоевывать рынок, возникла острая необходимость сделать их масштабируемыми, управляемыми и удобными для практического использования.
Арун Кумар утверждает, что за последние 40 лет индустрия баз данных превратилась в зрелую отрасль с оборотом более 100 миллиардов долларов в год, решив сложнейшие задачи эффективности . Сегодня мир ML сталкивается с теми же проблемами:
- Масштабируемость: как обучать модели на данных, объем которых превышает объем оперативной памяти? .
- Управляемость: как отслеживать происхождение данных (provenance) и версионность моделей? .
- Юзабилити: как сделать так, чтобы ML-инженерам не приходилось писать низкоуровневый системный код для каждой задачи? .
По мнению гостя, современное состояние ML в продакшене часто представляет собой «хаос» из Jupyter-ноутбуков, разрозненных Python-библиотек и сложных Airflow-скриптов . DB-фикация призвана превратить эти кустарные процессы в промышленный стандарт.
🏗 Три этапа жизненного цикла ML 10:13
Для системного анализа проблем Кумар разделяет жизненный цикл ML-приложений на три ключевые стадии, каждая из которых требует своих инструментов:
- Sourcing (Поиск и подготовка): превращение сырых данных из хранилищ (Data Warehouses) и «озер данных» (Data Lakes) в готовые для обучения наборы. Это включает очистку, разметку и трансформацию .
- Building (Сборка): процесс проектирования признаков (feature engineering), выбора архитектуры и настройки гиперпараметров .
- Deployment (Развертывание): интеграция модели в приложение, мониторинг и поддержка по мере изменения данных .
Кумар проводит параллель: этап Sourcing для машинного обучения — это то же самое, что ETL-процессы (Extract, Transform, Load) для баз данных . Долгое время исследователи ML недооценивали важность этого «чернового» труда, считая его второстепенным, однако именно здесь сегодня находятся главные узкие места индустрии .
🧠 Проект Cerebro: когда СУБД обучает нейросети 20:42
Одним из примеров практической реализации идей Кумара стал проект Cerebro — платформа для промышленного глубокого обучения (Deep Learning). Проблема, которую решает Cerebro, заключается в том, что популярные фреймворки (TensorFlow, PyTorh) ориентированы на обучение одной модели за раз . В реальности же специалисты проводят «модельный поиск», перебирая сотни комбинаций архитектур и гиперпараметров.
Ключевые особенности Cerebro:
- Разделение логического и физического уровней: как и в SQL, пользователь описывает «что» он хочет построить (архитектуру, диапазон параметров), а система сама решает «как» это эффективно выполнить на кластере .
- Оптимизация множественных запросов (Multi-query optimization): Cerebro анализирует сразу все запускаемые процессы обучения и находит общие операции (например, доступ к одним и тем же данным), чтобы сэкономить ресурсы .
- Масштабируемость данных: система позволяет обучать модели на терабайтах данных, не заставляя инженера вручную настраивать партиционирование или копирование файлов между узлами .
В качестве примера успеха Арун приводит кейс из сферы здравоохранения: использование Cerebro позволило повысить точность предсказания активности пациентов с 75% до 92%, обработав терабайт данных с акселерометров .
🎩 Sorting Hat: борьба с ошибками автоматизации 34:01
Второй проект Кумара, Sorting Hat («Распределяющая шляпа»), фокусируется на этапе подготовки данных. Сейчас многие коммерческие AutoML-инструменты (от Google, Amazon и др.) заявляют о полной автоматизации этого процесса, но, по словам Аруна, они часто ошибаются в фундаментальных вещах .
Кумар выделяет проблему «семантического разрыва» (semantic gap):
- Пример с почтовым индексом (Zip Code): системы часто видят целые числа и классифицируют индекс как числовой признак. Если скормить его логистической регрессии как число, результат будет «мусором», так как индекс — это категория .
- Дедупликация категорий: если в данных один и тот же штат записан как «California» и «CA», модель может переобучиться. Ручная очистка таких данных занимает колоссальное время у дата-сайентистов .
Проект Sorting Hat создал бенчмарк (набор тестов) из 10 000 колонок данных, чтобы проверить, насколько хорошо современные инструменты справляются с определением типов признаков . Оказалось, что простая модель Random Forest, обученная на метаданных, во многих случаях превосходит сложные проприетарные системы .
🤝 Будущее: сближение двух миров 41:50
Завершая дискуссию, Арун Кумар подчеркивает, что сообщества баз данных и ML слишком долго существовали изолированно. ML-специалисты отлично разбираются в алгоритмах, но недооценивают теорию очистки данных, в то время как «базисты» десятилетиями изучали ETL и интеграцию, но не применяли эти знания к задачам обучения нейросетей .
Для дальнейшего развития индустрии Арун считает необходимым:
- Создание стандартизированных бенчмарков, подобных ImageNet для зрения или TPC для баз данных .
- Обучение специалистов на стыке дисциплин.
- Участие крупных тех-гигантов в открытых академических дискуссиях .
По мнению Кумара, конечная цель — сделать так, чтобы ML-инженеры могли сосредоточиться на творческой части работы, полностью делегировав вопросы инфраструктуры и подготовки данных умным системам, построенным на проверенных временем принципах СУБД .
