Кто доводит ML-систему до продакшена, в какой-то момент делает одно и то же открытие:

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

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

🥩 Не случайно в инженерной практике закрепился термин «сырые данные» — их действительно приходится сначала готовить.

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

Отсюда вытекает много сложных вопросов и типичных ошибок в архитектуре ML-систем. Мы разберем их в следующих постах серии.

Ставьте 🔥, если тема полезна для вас

Поставить PostgreSQL можно за день работы :)

👆 Такую оценку делают инженеры на старте — и часто ошибаются.

Станислав Погоржельский, технологический евангелист VK Cloud, решил разобраться, сколько времени на самом деле уходит на подъем PostgreSQL до Production-ready-состояния.

Установка мультизонального PostgreSQL действительно занимает несколько часов, но это примерно 10–15% пути до состояния, в котором базу не страшно пускать под боевую нагрузку.

⚙️ В системе, которая выдерживает реальные инциденты:

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

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

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

➜ Читайте статью на Хабре

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

Здесь возникает один из типичных архитектурных перекосов 👇

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

Универсального решения нет: выбор хранилища и структуры данных всегда контекстный и зависит от ожидаемой динамики, опыта конкретной команды, разрешения на использование определенного open source и возможности его поддерживать.

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

• аккуратный мир обучения
• реальный мир эксплуатации

❌ Почти всегда такие системы ломаются со временем.

Вопросы, с которых начинается ML-система:

1. Как именно данные попадают в систему?
2. Можем ли мы повторить этот процесс завтра, через месяц и через год?

💡 Поделитесь постом с командой и попробуйте честно ответить на эти вопросы

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

Теперь обсудим фильтрацию данных 🚧

Фильтрация данных — это инженерное решение, которое определяет, какие данные считаются допустимыми, а какие — нет.

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

Если:

• фильтрации недостаточно → модель начинает обучаться на случайностях
• фильтрация слишком жесткая → распределение данных искажается

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

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

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

Фильтрация отвечает на вопрос:

С какими данными система готова работать и какие случаи считаются исключениями?

Если эти решения не зафиксированы осознанно, система будет ломаться из-за расхождения с реальностью.

Полезно? Ставьте 🔥
Скоро опубликуем последний пост из серии про ML :)

📌 25 февраля в 17:00 (мск)

Серверы Bare Metal часто используются для работы с большими данными и высокими нагрузками, поэтому мы решили показать, как оптимально построить процесс запуска виртуальных машин в таком типе ИТ-инфраструктуры.

О чем будем говорить:

• сценарии применения, преимущества и особенности Bare Metal в контексте высоких нагрузок и оптимизации бюджета
• как настроить сеть: полный контроль и сохранение гибкости
• популярные ошибки развертывания, и как их избежать

Приходите на практикум, чтобы узнать больше о настройках и спецификации Bare Metal.

➜ Зарегистрируйтесь на вебинар

Предвыходное состояние достигнуто ✅

Делитесь своими любимыми мемами про работу в комментариях.

Наш вот 👇

🏁 В финальном посте серии про ML обсудим разметку и метаданные. Именно здесь ML-система либо становится продуктом, либо навсегда застревает в демо.

Разметка отвечает на простой, но критичный вопрос:

Что именно модель должна уметь различать в реальности?

На этапе экспериментов мы можем позволить себе гибкость в требованиях к данным. Допустимо использовать «сырые» или неполные данные, чтобы проверить гипотезу.

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

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

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

Со временем к разметке неизбежно добавляется второй слой — метаданные. Они отвечают на вопросы, которые появляются не сразу:

Откуда пришли данные? Какой версией пайплайна они обработаны? Какие условия повлияли на результат?

Когда поведение модели меняется, именно метаданные позволяют понять почему. С ними проблема превращается в обычную инженерную задачу с понятными точками анализа.

💙 Этой серией постов мы хотели показать простую вещь: ML-системы редко ломаются из-за моделей. Чаще — из-за решений о данных: о разметке, фильтрации и допущениях, которые не были зафиксированы вовремя.

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

Сохраняйте публикацию и делитесь ею с командой :)

Наш сервис VK Object Storage вошел в тройку лидеров рейтинга российских S3-провайдеров по версии CNewsMarket — среди сильнейших игроков рынка.

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

Продолжаем развивать платформу и усиливать возможности для бизнеса. Спасибо за доверие 💙

➜ Смотрите полный рейтинг на сайте CNews

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

Настройте резервное копирование «для всех виртуальных машин» при создании плана бэкапирования. Так мы минимизируем риски, связанные с пропуском ВМ и потерей данных.

➜ Защитите данные

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

На вебинаре 19 марта в 17:00 ✍️ расскажем про ключевые принципы использования VDI и про оптимизацию затрат на корпоративную инфраструктуру. На примере Cloud Desktop поговорим про важность IAM и особенности настройки сетей. Разберем кейсы и посмотрим на практике, что отличает решение от обычного удаленного ПК.

Спикер: Алексей Лыков, руководитель продуктового направления VK Cloud Desktop, VK Tech

➜ Зарегистрируйтесь

Искусственный интеллект — это не какое-то волшебство, а математика, методы и алгоритмы, которые не будут работать без качественных данных.

Анна Фенюшина, ведущий архитектор направления «Дата-сервисы» в VK Tech, разобрала в статье, как меняются требования к данным и инфраструктуре по мере развития моделей.

Классическому ML часто достаточно структурированных таблиц и сравнительно небольших объемов данных. Нейросетям уже нужны терабайты изображений, текста и аудио. А обучение собственной LLM требует уникальных датасетов, мощной GPU-инфраструктуры и бюджета в миллионы долларов.

👆 Поэтому для большинства компаний практичнее адаптация существующих Open-Source-моделей, использование API, дистилляция знаний из больших моделей и коллаборативное обучение с другими организациями.

➜ Читайте статью, чтобы подробней узнать про жизненный цикл ML-модели и как он выстраивается на практике

Как получить защиту и отказоустойчивость корпоративного уровня без Enterprise-бюджетов

Мы представляем ПАК S3 Лайт — специальный пакет для малого и среднего бизнеса, который позволяет экономить до 50% на ИТ-инфраструктуре хранения данных. Решение помогает надежно хранить данные и работать с данными в своем контуре для соблюдения требований ИБ.

Что получает бизнес:

• возможность быстро развернуть надежное S3-хранилище в собственной инфраструктуре
• защиту данных от случайного или умышленного удаления благодаря Object Lock
• гибкое масштабирование по мере роста бизнеса
• эффективную работу с массивами данных от 50 до 300 Тб

Поставляется как ПАК и включает в себя: 

1. Оборудование Hardware: серверы и сеть с гарантией.
2. Лицензии на программное обеспечение и ОС.
3. Пуско-наладочные работы и техническая поддержка с единой точкой входа. 

Решение входит в Реестр отечественного ПО.

➜ Читайте подробнее об S3 Лайт