Вы просили — мы сделали. Повторяем вебинары про работу с данными в облаке: от развертывания платформы до ETL-процессов и полноценной BI-аналитики. Регистрируйтесь, чтобы спросить экспертов о важных деталях и получить ответ.
Как развернуть платформу данных в облаке и подготовить данные для аналитики Покажем, как быстро развернуть managed-сервисы Evolution Data Platform, подключить источники данных и построить пайплайны для подготовки данных к аналитике. Разберем интеграцию с PostgreSQL, ADB, S3 и настройку автоматического обновления — без долгого погружения в инфраструктуру. 🧑💻 Для кого: дата-инженеры, аналитики, архитекторы данных. 📅 Когда: 16 июля 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
ETL в облаке: от хаоса к управляемым процессам Покажем, как выстроить надежную ETL-платформу в облаке на базе Evolution Data Platform. Разберем интеграцию разрозненных источников, управление метаданными и оркестрацию — и покажем всё это в live-демо: от извлечения данных до готовой витрины. 🧑💻 Для кого: дата-инженеры, DevOps, руководители дата-команд. 📅 Когда: 23 июля 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
Evolution Managed BI: все возможности BI-сервиса в облаке Разберем, как получить максимум от Evolution Managed BI: подключить источники данных, настроить интерактивные дашборды, кеширование запросов и автоматические алерты. Покажем продвинутые возможности сервиса — от виртуальных датасетов до управления доступом. 🧑💻 Для кого: аналитики, BI-разработчики, руководители дата-отделов. 📅 Когда: 30 июля 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
Илон Маск отдал приоритет видеокамерам. Радар и ультразвуковые датчики были ошибкой, от них больше помех
Мы тоже часто спорим с коллегами о выборе средства распознавания объектов. С одной стороны, лидары и ультразвук лучше камер работают в темное время суток, что безусловный плюс. С другой, освещение в 21 веке – не экзотика или всегда можно применить ИК-прожекторы. Сегодняшние нейросети неплохо справляются и в ночных условиях. Тем более, что полной темноты в наше время не бывает, видеокамерам хватает света даже от сигареты.
Сегодняшние нейросети совершают революцию в видеонаблюдении, распознавая даже мелкие объекты и даже в темноте. Наверное, поэтому Илон Маск в интервью про свои беспилотники высказал буквально следующее:
«Честно говоря, радар и ультразвуковые датчики были ошибкой. Особенно радар. Потому что радар позволяет приблизиться к решению задачи и решать задачу в большинстве случаев, кроме тех моментов, когда невозможно соединить радар и нейросеть для визуального распознавания. То есть радар и “зрение” расходятся - кто прав? По сути, нужно избавляться от радара. И как только мы избавились от радара - и кстати команда автопилота была сильно против такого решения - теперь никто не хочет возвращать радар.
Мне пришлось настоять на своем. Радару тут не место. Радар был костылем, и, если тащить костыль за собой, бежать не получится. Радар - просто сигнал. В конечном счете от радара было больше помех, чем сигналов. Иногда это было очень полезно, но помех от него было больше. От него нужно было избавляться. Как только мы убрали радар, стало очевидно, что наши нейросети гораздо хуже, чем мы думали. Радар им слишком сильно помогал. Использование компьютерного зрения предполагает, что ни на что больше полагаться нельзя, оно должно работать. Нейросеть должна работать. Большим изменением стал переход от алгоритма «Bag of points» к его интерпретации нейросетью для определения центра полосы.
Раньше мы все это делали на «Си». Сейчас архитектура нейросети очень сложна, там много слоев. Какие-то слои удаляются, какие-то добавляются. Мы уже столько раз меняли архитектуру.”
Кстати, программисты Спецлаб тоже, в основном, всё разрабатывают на “C++”. И тоже предпочитают использование видеокамер для объяснения компьютеру окружающего мира.
Полгода назад про корпоративные хранилища данных спорили, чей движок быстрее обрабатывает запросы. Сейчас почти каждый крупный анонс - про то, как пустить к данным ИИ-агентов и не дать им наломать дров. Собрал главное человеческим языком.
Сначала про слово, которое будет дальше. Lakehouse - это подход, когда вся аналитика компании живёт в одном общем хранилище поверх дешёвых файлов, без отдельной дорогой базы под отчёты. Дальше речь о том, что с этим подходом случилось за полгода.
Databricks (их большая конференция прошла 16 июня). Показали новый движок Lakehouse//RT - он обещает выдавать аналитику почти мгновенно прямо из общего хранилища, без отдельной быстрой базы под витрины. Пока это ранняя версия и работает только на чтение, то есть данные через него можно читать, но не записывать. Второй анонс - способ держать «живые» рабочие данные и аналитику в одном месте, без постоянной перекачки между системами (обычно компании гоняют данные туда-сюда ночными выгрузками). Третий, и самый показательный - набор инструментов, чтобы пускать к данным ИИ-агентов: объяснять программе смысл данных и контролировать, куда ей можно лезть, а куда нет.
ClickHouse (своя конференция 27 мая). Это очень быстрая база для аналитики. Они запустили собственную управляемую версию Postgres - популярной базы, на которой работают тысячи приложений, - и научили её мгновенно отдавать все изменения в аналитику, без задержек. Плюс добавили ИИ-агентов поверх данных, построенных на Claude. По деньгам у них всё хорошо: годовая выручка за год утроилась и перевалила за 250 миллионов долларов.
Snowflake. Открыли свой каталог данных Polaris - это, грубо говоря, общее оглавление всех таблиц, по которому разные программы понимают, где что лежит. Раньше он был только их, теперь его передали в открытый фонд Apache, чтобы пользоваться им могли любые инструменты. А популярный открытый формат таблиц Iceberg дорос до новой версии и научился хранить более сложные данные.
SAP покупает компанию Dremio (сделка ещё не закрыта). Крупный вендор корпоративного софта докупает технологию, чтобы собрать собственное хранилище нового типа под ИИ. Это часть общего движения: рынок сходится вокруг одного открытого формата данных - того самого Iceberg.
DuckLake дорос до версии 1.0. Маленький и нарочно простой проект: он хранит оглавление данных в обычной знакомой базе (Postgres), а не в куче разрозненных служебных файлов, как делают старшие конкуренты. Меньше магии - проще обслуживать.
Если совсем коротко: скорость никуда не делась, её даже больше. Но она перестала быть главным козырем и стала фундаментом. Поверх неё все теперь строят слой управления ИИ-агентами - как объяснить программе смысл данных и как не пустить её туда, куда нельзя. По сути это ровно то, чем администраторы баз данных занимаются уже много лет, просто теперь у этого модные названия.
Дальше разберу каждый анонс по отдельности. Ждите продолжения.
Я сделал AlbumentationsX MCP — MCP-сервер для работы с аугментациями в computer vision.
Идея простая: когда ты собираешь augmentation pipeline, не хочется бесконечно вручную перебирать transforms, гадать с параметрами и проверять глазами десятки вариантов. Хотелось, чтобы MCP-host мог помочь: найти подходящие transforms, собрать консервативный baseline, провалидировать pipeline, отрендерить локальные previews, сравнить результаты, собрать feedback вроде too_noisy:high и экспортировать принятый вариант.
Проект работает поверх AlbumentationsX и не пытается делать магию вместо тебя. Он помогает быстрее пройти цикл: recommend → validate → preview → compare → adjust → export.
Особенно полезно, если ты делаешь classification, detection, segmentation, OCR или просто хочешь быстрее проверять качество аугментаций на локальных примерах.
GLM 5.2 в open source: модель уровня Claude Opus 4.7, которую негде запустить, пока негде.
Zhipu выложили веса GLM 5.2 под MIT лицензией. 744 миллиарда параметров, MoE, 40 миллиардов активных на токен, контекст на миллион. GLM-5.2 играет достойно на многих бенчмарках.
Дома не запустить. FP8 веса ~800 гигабайт, нужно минимум 8 карт H200 или 10 карт H100. Теперь про abliteration, потому что в этом вся суть.
Любая западная модель отказывает вам по десять раз на дню. Напиши эксплоит для пентеста: отказ. Проанализируй уязвимость по CVE: отказ. Разбери вредоносный код из лога: отказ. Безопасники и разработчики каждый день упираются в стену цензуры и делают руками то что нейросеть могла бы закрыть за секунды.
Abliteration это удаление цензурных слоёв из модели. Модель перестаёт решать за вас что можно а что нельзя. Для моделей поменьше энтузиасты делают это за дни. Для 744B монстра уйдёт пара недель, но результат появится на Hugging Face неизбежно. MIT лицензия, веса открыты, технически ничего не мешает. Вопрос кто первым поставит под эту версию железо и откроет API.
Считаем деньги.
Huawei Ascend, легальный путь. Чип 910B: ~110 тысяч юаней (~1.4 млн рублей), нужно 16 штук (два сервера Atlas 800, ~1 ТБ видеопамяти). Итого 55-90 млн рублей. Производительность 60-70% от NVIDIA, зато без санкционных рисков.
NVIDIA H100, серый путь. Карта ~3.3 млн рублей, 10 штук с обвязкой: 40-50 млн. Быстрее, но риски поставки и нет гарантии.
Операционка: ~1-1.5 млн рублей в месяц (локация, электричество, инженеры).
Кто заплатит. Корпорации, которым нельзя лить данные в западные API: выделенный сервер с abliterated моделью, договор с юрлицом, ответственность на клиенте. Разработчики и физлица: публичный доступ, базовый тариф с обычной версией, премиум с abliterated после верификации.
Для российского рынка это окно. Ни один провайдер в РФ пока не даёт доступ к abliterated модели такого уровня. Что думаете?
Подборка материалов, которые помогут снизить стоимость, стабилизировать прод и перестать гадать с ресурсами
Среди читателей Хабра много ML‑инженеров, дата‑сайентистов и дата‑инженеров — и мы, как команда провайдера облачных и ИИ-сервисов, догадываемся, где у вас чаще всего болит. Ниже подборка материалов, которые помогут в решении задач: чуть ускорить, чуть удешевить, чуть упростить жизнь в проде.
👨💻 ML/DS‑инженеры и бэкенд
Боль №1
Суть: вы крутите LLM в проде, токены стоят денег, контекст забивается громоздким JSON, а латентность растет. Что делать: прочитать статью — как практическое руководство по переходу с JSON на компактный TOON‑формат для структурированных ответов. Почему: в ряде кейсов можно сэкономить до ~40% токенов, но есть нюансы. Формат лучше работает при небольшой вложенности (3–4 уровня) и однородных массивах. Для плоских данных чаще выгоднее CSV. Плюс потребуется свой парсер/SDK — это усложняет дебаг и интеграцию.
Боль№2
Суть: нужно обогатить поисковую выдачу или интерфейс LLM‑функциональностью, но непонятно, как выдержать нагрузку и не превратить кластер в черную дыру для бюджета. Что делать: взять на вооружение материал от Avito Tech — эдакий «рентген» продакшен‑архитектуры с LLM/мультимоделями под серьезной нагрузкой. Почему: хороший слепок боевой системы с vLLM и LoRA, организацией GPU‑кластера, схемой запросов и мониторинга качества. Учитывая масштабы, команду и бюджеты Avito, «копировать-вставить» вряд ли получится, но по крайней мере есть опорная схема, как декомпозировать сервисы, и на какие метрики смотреть при проектировании.
👨💻 Data Science, MLOps, DevOps
Боль №3
Суть: модели живут в «ручных» скриптах, развертывание нестабильно, автоскейлинг либо отсутствует, либо работает хаотично. Не всегда получается договориться с коллегами о процессе вывода из ноутбуков в прод, который бы всех устроил. Что делать: читать нашу статью, где разбирается жизненный цикл ML‑модели в Kubernetes. Почему: показана связка контейнеризации, CI/CD и деплоя с учетом ML‑нагрузок. Это не универсальный рецепт (пример завязан на инфраструктуру Cloud.ru), но помогает синхронизировать ожидания между DS и MLOps, чтобы было от чего оттолкнуться.
👨💻 ML‑инженеры и исследователи
Боль №4
Суть: эксперименты падают из-за CUDA out-of-memory, приходится наугад крутить размер батча, длину контекста и конфигурацию кластера. Каждый запуск — лотерея и потерянные GPU‑часы. Что делать: читать перевод зарубежной статьи с разбором оценки потребления памяти на примере GRPO. Почему: объясняет, из чего складывается потребление памяти и как прикинуть конфигурацию до запуска. Это не калькулятор «до байта», поскольку значения зависят от стека, наличия обучения со смешанной точностью или распределенного обучения, — но как ориентир экономит время и нервы.
Суть: никаких «красивых» датасетов: данные разнородные — таблицы, тексты, временные ряды, сигналы. Поддерживать зоопарк моделей дорого, а терять качество нельзя. Что делать: читать свежие работы про TabPFN — первуюи вторую. Почему: обе работы показывают, что вокруг TabPFN можно выстроить единое табличное ядро. С одной стороны — подключать текст через адаптеры, не теряя информацию на грубом PCA. С другой — переводить в таблицу разнородные временные ряды и решать на одном ядре разнородные задачи. Может быть удобно, когда данных немного и не хочется поддерживать много отдельных моделей. При этом придется аккуратно проектировать фичи и контекст, а адаптеры обучать под свой домен, но это все равно дешевле и проще, чем полное переобучение.
Пишите в комментариях, где еще болит. В следующий заход попробуем принести что-то точечно под ваши задачи.
Всем привет! Коллеги из бизнес-практики BI GlowByte подготовили репортаж по следам прошедшей конференции Fine Day Online, где эксперты из Галамарта, Уралсиба, ОТП и FanRuan говорили о том, что реально происходит внутри больших BI-команд.
Если коротко: дата-каталог на DataHub своими руками, Shadow DWH как болезнь свободного self-service, пиксельный марафон для разработчиков и грабли при миграции FineBI 6.0 на 7.0.
Красная нить всех докладов: данные – есть, BI – внедрен, дашборды – сияют, но бизнес продолжает гадать на кофейной гуще работать на ощущениях.
Кстати, для тех, кто любит не только почитать, но и послушать, есть ссылочки на выступления.
ИИ-агент удаляет прод за 9 секунд: новости автоматизации.
Помните, как нас пугали, что ИИ отберёт работу? Пока что он скорее отбирает базы данных.
Свежий кейс. У американской PocketOS ИИ-агент за девять секунд удалил продакшен-базу вместе с бэкапами — без всякого разрешения. На вопрос «зачем» агент невозмутимо ответил, что чинил «несоответствие учётных данных».
Девять секунд на то что бы снести базу и найти оправдание - отличная работа!
88% компаний, гоняющих ИИ-агентов в работе, за год словили подтверждённый или подозрительный инцидент безопасности — при том что на защиту этих агентов уходит жалкие 6% бюджета. Причём чаще всего агент не ломается, а именно сливает данные: в 61% инцидентов была утечка. Он же не виноват — он просто делал свою работу. Ему забыли сказать, где у этой работы край.
Есть и другие случаи, более курьезные. Диллер Cevrolet, их бот под давлением юзеров согласился продать машину за $1 и заявил, что сделка «юридически обязывающая» — no take-backsies.
Разница в том, что раньше у ботов был только язык, а теперь — права доступа. И шутки подорожали на пару порядков. Вывод банальный: ИИ и правда работает. Просто его пускают в прод быстрее, чем успевают огородить забором. Минимальные привилегии, аудит и большая красная кнопка — это теперь не паранойя, а реальность работы с агентами.
Автоматизация разработки в RStudio с помощью gemini cli
Вновом видео делюсь тем, как у меня сейчас автоматизирован процесс разработки. Речь пойдет про интеграцию RStudio и Gemini CLI. Gemini CLI это аналог Claude Code, но с хорошим бесплатным тарифом, который способен в значительной части покрыть ваши повседневные потребности по разработке и автоматизации, позволяя не переплачивать там, где это не нужно.
В видео продемонстрирую пример решения одной из своих реальных задач, по переводу пакета на новую версию API.
Разбираем, как запустить этот стек в RStudio и использовать для реальных задач.
Что в видео: • Gemini CLI vs Claude Code: Почему я перешел на Gemini и как это экономит бюджет. • Настройка: Установка и получение API ключа. • Интеграция: Подключение CLI к RStudio. • Практика: Рефакторинг и перевод пакета rgoogleads на новую версию Google Ads API. • Паттерны: Как через GEMINI.md заставить модель писать код именно так, как вам нужно. • Расширение возможностей: Работа с MCP серверами.
Приходите на вебинар — покажем, как построить потоковый конвейер данных с латентностью в минуты
Батчевый ETL раз в сутки перестает справляться, когда бизнесу нужна аналитика в режиме, близком к реальному времени. Как перейти на потоковую обработку без лишней сложности в инфраструктуре?
Разберем это на вебинаре по Evolution Data Platform. Будет полезно дата-инженерам, которые проектируют конвейеры, аналитикам и BI-специалистам, которым важно работать с актуальными данными, а еще архитекторам и руководителям дата-отделов.
На вебинаре расскажем и покажем:
как проектировать архитектуру конвейера под near real-time: когда брать микробатчинг в Managed Spark Streaming, а когда хватит классического батча;
зачем нужен Managed Trino как единый слой запросов поверх «горячих» и «холодных» данных — и как это убирает дублирование логики;
как партиционировать данные по времени в Object Storage, чтобы запросы не тормозили;
как управлять схемой через Managed Metastore, когда структура потока меняется;
как настроить дашборд в Managed BI с автообновлением и алертами на отклонения;
как измерять латентность конвейера — от генерации события до появления на дашборде.
На практической части соберем реальный сценарий: оконная агрегация транзакций в Managed Spark Streaming, оркестрация через Managed Airflow, витрина в Object Storage, ad-hoc запросы через Managed Trino без копирования данных, дашборд с обновлением раз в две минуты.
📅 Когда? 21 мая в 11:00 мск.
📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикеру в прямом эфире.
Прибыль Samsung от производства чипов на фоне спроса на ИИ выросла в 48 раз
Аналитики ожидают, что подразделение Samsung увеличит свою рекордную прибыль в течение следующих нескольких кварталов, поскольку контрактные цены продолжают стремительно расти на фоне ограниченного предложения. Они указывают на рост экспорта полупроводниковых приборов из Кореи в 2,8 раза за первые 20 дней апреля.
Просто значение немного удивило: 48. Даже немногим лучше чем ответ на все вопросы Вселенной!😁
Радует (лично меня, как желающего увеличить память своего ПК) новость от производителя оборудования для литографии. Количество литографического оборудования, заказанного для производства чипов памяти, за последний год превысило число заказов для производства CPU.
2.1. Год назад литографы, в основном, заказывали для производства CPU.
2.2. Ссылку на новость про литографическое оборудование сходу не нашёл. Но это было примерно месяц назад, тут же на Habr.
IMHO сугубо, много желающих включиться/вложиться в производство памяти. Через сколько времени пойдет производство памяти на максимум, вот тут предположения высказывать не возьмусь. Но желающих заработать на этом (и не только этом) "железе" много!
Привет! Если мы еще не знакомы - я пишу в основном о том, как попытаться определить грейд разработчика не привлекая его на множество собеседований. Если Вы - .Net-разработчик, буду признательна, если пройдете этот опрос с небольшим заданием на кодинг. Ваши ответы позволят мне понять, правильно ли я двигаюсь и верные ли инструменты использую. Чем больше ваших ответов - тем проще будет мне) Заранее спасибо!
P. S. Прекращаю рассылку ответов, спасибо всем, кто участвовал! Но если хотите помочь исследованию - буду благодарна за новых респондентов) (можно написать в комментарии, если хотите получить результаты, но проверяйте, что доступ для сообщений открыт)
MCP - это было очень модно (где-то год назад). Но многие до сих пор не поняли простую вещь: агент с доступом к командной строке может пользоваться любыми CLI-интерфейсами ничуть не хуже.
При этом у классических CLI есть очевидные преимущества:
- Их банально легче разрабатывать
- Они прозрачнее и понятнее в работе
- Применяться они могут не только агентами, но и людьми
- Их уже существует огромное множество под любые задачи
В Google это тоже осознали и выкатили [свой инструмент](https://github.com/googleworkspace/cli). Сделан он явно для агентов (его выпустили только в этом месяце), но это именно CLI, а не очередной MCP-сервер.
Точных фактов по этой теме пока нет. Кто-то говорит, что [в простых задачах MCP требует больше контекста, а в сложных — меньше, чем CLI, если инструменты грамотно обернуты и хорошо обнаруживаются агентом](https://portofcontext.com/blog/cli-vs-mcp-vs-code-mode). Кто-то, что этой разницей можно пренебречь, да и вызвана она тем, что не все CLI адаптированы под экономию контекста. Но все согласны, что CLI может дать агенту доступ ко всем тем же инструментам и обеспечить одинаковый процент успеха при выполнении задач, при этом будучи куда понятнее для человека и значительно проще в написании и поддержке.
Терабайты данных из Teradata в Trino — эффективный способ передачи
В Data Ocean Nova был добавлен новый Trino Teradata Connector, который упрощает ad hoc-доступ к данным из Teradata и позволяет выгружать терабайты данных без кратного роста нагрузки на источник. Коллеги в новой статье объясняют, почему привычная параллельная выгрузка через несколько запросов плохо масштабируется, и показывают более правильный подход: распределять чтение по AMP’ам Teradata так, чтобы каждый из них читался только один раз.
Авторы разбирают архитектуру Teradata, типичные ошибки при многопоточном извлечении данных и принцип работы федеративного доступа через Trino. Отдельно показывают, как коннектор в Data Ocean Nova помогает организовать эффективную многопоточную передачу данных и использовать push-down для фильтрации, агрегаций и join’ов, когда это действительно уменьшает объем выборки.
Как всегда, в статье много полезных советов. Читайте и комментируйте!
Когда бизнес получил self-service BI и построил внутри него собственное хранилище данных
Знакомая ситуация: вы даёте бизнесу инструмент для самостоятельной аналитики, а через год обнаруживаете, что FineBI выполняет функции корпоративного хранилища. Данные загружаются из файлов, логика считается прямо в датасетах, одни и те же «велосипеды» пересобираются десятки раз. Документации нет, доверия к отчётам всё меньше.
В ОТП Банке за год с момента запуска FineBI выросли до 1 000 пользователей и 660 отчётов при приросте 50 пользователей в месяц. Масштаб впечатляет, но вместе с ним пришло и теневое хранилище.
Пётр Гордиенко, руководитель команды BI в ОТП Банке, расскажет, как они к этому пришли, почему осознанно выбрали «больше свободы» на старте и какой план из трёх шагов готовят, чтобы вернуть контроль, не убив при этом скорость.
Когда у тебя 50 отчётовв FineReport, 100+ дашбордов в FineBI, и никто не знает, откуда берутся данные
Знакомая история: дашборды живут своей жизнью, новый сотрудник открывает отчёт и не понимает, что значит «ТО 5 руб.», а когда что-то ломается, полдня уходит на то, чтобы пройти по цепочке ETL и найти, где именно.
В Галамарте решили это системно: подключили дата-каталог DataHub к продуктам FanRuan. Как именно это сделали, какие стены пришлось пробить и чего не нашлось ни в одной документации, расскажет Дмитрий Конюхов на FineDay Online.
Что получили на выходе:
— бизнес-глоссарий, где каждый термин привязан к формуле, источнику и конкретным дашбордам
— lineage от витрины до сырых данных — в одном окне, за пределами FanRuan
— возможность за секунды найти, в каких из 100+ дашбордов используется нужнаяметрика
— базу для self-service: аналитики переиспользуют существующие датасеты вместо создания новых
Spark SQL Scripting. Новые возможности для инженеров данных
Коллеги в новой статье «Spark SQL Scripting» представили добротный туториал с практическим разбором возможностей Spark SQL Scripting для инженеров данных.
Spark SQL Scripting, появившийся в 4-й версии, представляет собой процедурное расширение классического Spark SQL. Теперь разработчики могут писать полноценные многошаговые сценарии непосредственно на уровне SQL-артефактов, внедряя в них управляющую логику.
Spark SQL Scripting – это не просто синтаксический сахар, а эволюционный шаг в сторону сближения классического функционала аналитических СУБД (таких как Oracle PL/SQL, MS SQL Server T-SQL) с мощью распределенных вычислений Apache Spark. Использование Scripting позволяет инженерам данных собирать пайплайны обработки на «чистом SQL», не прибегая к сторонним компонентам и языкам разработки, тем самым сокращая кодовую базу и снижая барьер входа для дата-аналитиков.
Как это работает в типовых сценариях применения (пакетные DDL/DML-последовательности обработки, подготовка и расчет витрин данных, проверки качества данных, Runbook-операции), читайте по ссылке. Бонус для дочитавших статью до конца – свод практических рекомендаций и архитектурных паттернов при работе со Spark SQL Scripting.
Что будет на конференции GoCloud 2026: трек «Данные и аналитика»
GoCloud — ежегодная конференция Cloud.ru про ИИ и облака. В этом году она пройдет в кинотеатре «КАРО 11 Октябрь» на Новом Арбате в Москве. Формат смешанный — можно прийти офлайн или подключиться удаленно. Выступят больше 40 экспертов. Вас ждут 15 демозон, практические сессии, тематические круглые столы и, конечно, вечеринка после.
Один из треков будет посвящен данным и аналитике — разберем, какие инструменты позволяют сделать управление данными эффективным и не переплачивать, также расскажем, куда движутся тренды в 2026 году. Вот что запланировано:
Evolution Data Platform: эволюция платформы данных — куда движется дата-платформа Cloud.ru и что изменилось за год.
Как обрабатывать потоковые данные с помощью Evolution Managed Flink — архитектура, компоненты, сценарии использования.
Evolution Managed ArenadataDB в облаке: что изменилось с момента запуска — обновления, анонсы новых функций и клиентский кейс.
Управляемые базы данных и почему это тоже про машинное обучение — почему все начинается не с моделей, а с инфраструктуры для работы с данными.
Управление Evolution Managed Spark с AI: инновации и эффективность — как ИИ помогает оптимизировать Spark-задачи.
Завершит трек круглый стол «Тренды развития дата-сервисов в 2026 году» — про дата-стратегию, суверенные облака, управление данными и как дата-инженерия становится основой для ИИ в реальных проектах.
Переходим полностью к тестам датасета COCO. День 4.
Пока Альтман рассуждает о бороздящих кораблях Вселенную и о моделях, которые будут после трансформеров, мы делаем. Такое вступление я придумал для статьи, когда мы закончим с экспериментами и доделаем пилот, а пока продолжу дневник обучения TAPe-модели. Комуинтересно: начало тут, здесь и там, а немного про методы TAPe (Теории активного восприятия) в области обработки информации — здесь.
Сначала протестировали эту же модель с тем же числом параметров на большом датасете COCO. Без оптимизации получили решение с точностью 60.59%, что является очень высоким для такой модели (невозможно высоким даже, такая модель по идее не должна сходиться и находить общее решение из количества параметров, но данные TAPe позволяют). Пока сложно сравнить с конкретной метрикой других моделей, потому что мы не строим рамки вокруг предмета, но находим конкретно центр объекта. Это проведем позже.
Тренировка на процессоре как минимум не дольше, чем тренировка на видеокарте, поэтому мы ограничены только количеством данных на ОЗУ в TAPe‑формате — что не является ограничением в целом, можно весь датасет уместить одновременно там Пока существуют несколько проблем:
Количество ложных срабатываний (скорее симптом, но все же);
Не самая лучшая классификационная точность (тоже в большой степени симптом);
Неправильное центрирование объектов (немного ограничение детекции, но есть способы обойти);
Размерность COCO;
Начали экспериментировать, чтобы найти решения, при этом также экспериментируем с несколькими предметами, с которыми ранее уже хотели провести эксперимент.
Конкретно:
Работа матрицы преобразования на данный момент времени немного линейная. Зависимости по большей части линейные (то есть, независимые друг от друга). Это не хорошо, по понятным причинам, но в тоже самое время это помогло перейти к пониманию одного факта: в найденном нами подходе, о котором писали выше, есть как раз нелинейная зависимость коэффициентов друг от друга. Эту связь нужно выстраивать вручную, в зависимости от градиентного спуска и deep learning, но в нашем случае связи по TAPe известны заранее, Дополнительно начинаем вторую фазу создания решения, чтобы можно было захватывать объекты любого размера. Это должно привести к намного более точным ответам, при этом ускорив модель.
Ну и решаем еще одну проблему: модель учится определять бэкграунд, но имеет сложности определять объекты со стороны классификации. То есть — большая часть тренировки потери идет в сторону тренировки хорошей точности в бэкграунд, что приводит к ложным срабатываниям, потому что текстуры на заднем плане превращаются для модели в что‑то напоминающие объект, пусть и с низкой точностью.
Дальше планируем продолжить работу с полным датасетом (используя 2% из него для быстрых тестов — это около 2400 изображений).
Как мы ушли от всем известного способа градиентного спуска
Продолжаю дневник разработки «Суперраспознавалки» для демо/пилота. День третий. Основная задача: настроить TAPe‑модель на датасет типа COCO под задачу detection. Вторая — дать клиентам возможность добавлять собственные классы к уже существующим. Ну и далее, при необходимости, полная адаптация модели под конкретного заказчика. Поскольку у нас есть Теория активного восприятия с ее методами, на выходе заказчик должен получить кратную эффективность и кратную экономию ресурсов.
В первые два дня настраивали базовую струтуру сегментации, детекции и классификации. Модель решает задачи на обучении уже 115 тыс параметров — в отличии от YOLO, которой мало 2 млн + параметров.
Тут сравнение трех десятков кодировок в задаче сегментации видео в DBSCAN (включая ViT, DINO) с TAPe
День 3
Сегодня занимаемся исправлением количества ложных срабатываний. Проблема ложных срабатываний в целом в том, что мы смотрим в первую очередь на текстуру изображения (из‑за особенностей методов TAPe). Поэтому приходится прибегать к менее‑обычным способам для обучения разделения между текстурой заднего плана (в каком‑либо виде, будь это снег, или трава) и текстурой самого объекта.
Сейчас эта проблема решается условно через определенные движения области сбора данных для выявления текстур, которые, возможно, не были найдены в области, расположенной стандартным способом (то есть начальным разбиением изображения на патчи). Это позволяет сильно уменьшить количество ложных срабатываний.
На данный момент времени около 220 объектов срабатывают без ложных срабатываний в целом. Проблема происходит только в изображениях с большим количеством маленьких деталей по типу гравия, или же травы, при этом не уменьшая общее количество правильных нахождений.
В целом, здесь помогают стандартные ML‑подходы по типу увеличения батчей, чтобы сгладить ошибки. Были эксперименты с проведением аугментаций, которые не привели к улучшению результатов: большая часть аугментаций просто повторяют уже существующие данные.
Также начали эксперименты с добавлением цветовых каналов. Однако проведенные эксперименты с цветами в простой схеме объединения features по каналам не дало желаемых результатов: даже с greyscale мы забираем столько информации, что цветовая гамма по большей части их просто дублирует. Это приводит к тому, что модель опирается слишком сильно на общие черты, не «видя» при этом выдающиеся черты разницы цвета. Что в то же самое время может и являться хорошей фичей, а не багом, потому что через разницу в текстуре мы, по идее, должны найти разницу в любом случае (если это реальное изображение). Поэтому мы не полагаемся в решении на конкретную задачу, где цвет более релевантен, а полагаемся на общее решение детекции в целом.
Также на заднем плане были закончены эксперименты с разными архитектурами (эксперименты продолжались параллельно несколько дней). Нашли самую лучшую архитектуру на данный момент (самая логичная по её смыслу, как нам кажется). Тут без подробностей, но мы ушли от всем известного способа градиентного спуска, что позволяет нам после тренировки модели прийти к глобальному минимуму решения (или к чему‑то очень близкому к этому — всё равно есть зависимость от задачи).
Мы собираем данные из патчей определенным образом, объединяем их в общее описание, а затем уже классифицируем конкретно эти объединения по тому, есть там объект или его нет. Классификация происходит за счет общих описаний каждого класса, который модель видит — и не тренируется отдельно, потому что исходит натурально из первичной тренировки векторов, а затем сводится к одному описанию через k‑means.
В результате выходит модель с очень малым количеством ложных срабатываний — с которыми, впрочем, мы все равно боремся. Плюс есть некие проблемы центровки, так что скорее всего количество параметров увеличится. Но все равно, модель работает чрезвычайно быстро. Тренировка как таковая проходит на CPU (так проще).
