Data Engineering *

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.
Почему: объясняет, из чего складывается потребление памяти и как прикинуть конфигурацию до запуска. Это не калькулятор «до байта», поскольку значения зависят от стека, наличия обучения со смешанной точностью или распределенного обучения, — но как ориентир экономит время и нервы.

👨‍💻 Enterprise DS (ритейл, финтех, телеком, индустрия)

Боль №5

Суть: никаких «красивых» датасетов: данные разнородные — таблицы, тексты, временные ряды, сигналы. Поддерживать зоопарк моделей дорого, а терять качество нельзя.
Что делать: читать свежие работы про 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.

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

Источники: PocketOS, кейс с удалением базы — Information Age (ACS): https://ia.acs.org.au/article/2026/gone-in-9-seconds--ai-agent-deletes-company-database.html

Тот же кейс глазами ServiceNow — Fortune: https://fortune.com/2026/05/06/servicenow-kill-switch-ai-agents-bill-mcdermott/

Статистика по инцидентам с ИИ-агентами — beam.ai: https://beam.ai/agentic-insights/ai-agent-security-breaches-2026-lessons

Автоматизация разработки в 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 мск.

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

P.S. А еще мы тут подготовили чек-лист, как создать качественное хранилище данных за 15 шагов — забирайте, нам не жалко. 

Прибыль Samsung от производства чипов на фоне спроса на ИИ выросла в 48 раз

Аналитики ожидают, что подразделение Samsung увеличит свою рекордную прибыль в течение следующих нескольких кварталов, поскольку контрактные цены продолжают стремительно расти на фоне ограниченного предложения. Они указывают на рост экспорта полупроводниковых приборов из Кореи в 2,8 раза за первые 20 дней апреля.

Полный текст новости по ссылке: https://www.kommersant.ru/doc/8633092

1. Просто значение немного удивило: 48. Даже немногим лучше чем ответ на все вопросы Вселенной!😁

2. Радует (лично меня, как желающего увеличить память своего ПК) новость от производителя оборудования для литографии. Количество литографического оборудования, заказанного для производства чипов памяти, за последний год превысило число заказов для производства CPU.

   2.1. Год назад литографы, в основном, заказывали для производства CPU.

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

3. 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 может дать агенту доступ ко всем тем же инструментам и обеспечить одинаковый процент успеха при выполнении задач, при этом будучи куда понятнее для человека и значительно проще в написании и поддержке.

В моих проектах я буду использовать 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 в ОТП Банке, расскажет, как они к этому пришли, почему осознанно выбрали «больше свободы» на старте и какой план из трёх шагов готовят, чтобы вернуть контроль, не убив при этом скорость.

📅 22 апреля | 15:00 МСК | FineDay Online 2026

Бесплатно, онлайн, ~3 часа

→ Регистрация

Когда у тебя 50 отчётов в FineReport, 100+ дашбордов в FineBI, и никто не знает, откуда берутся данные 

Знакомая история: дашборды живут своей жизнью, новый сотрудник открывает отчёт и не понимает, что значит «ТО 5 руб.», а когда что-то ломается, полдня уходит на то, чтобы пройти по цепочке ETL и найти, где именно.

В Галамарте решили это системно: подключили дата-каталог DataHub к продуктам FanRuan. Как именно это сделали, какие стены пришлось пробить и чего не нашлось ни в одной документации, расскажет Дмитрий Конюхов на FineDay Online.

Что получили на выходе:

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

— lineage от витрины до сырых данных — в одном окне, за пределами FanRuan

— возможность за секунды найти, в каких из 100+ дашбордов используется нужнаяметрика

— базу для self-service: аналитики переиспользуют существующие датасеты вместо создания новых

📅 22 апреля | 15:00 МСК | FineDay Online 2026

Бесплатно, онлайн, ~3 часа

→ Регистрация

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 году» — про дата-стратегию, суверенные облака, управление данными и как дата-инженерия становится основой для ИИ в реальных проектах.

​Встречаемся уже 9 апреля, успейте зарегистрироваться на сайте. 

Переходим полностью к тестам датасета COCO. День 4.

Пока Альтман рассуждает о бороздящих кораблях Вселенную и о моделях, которые будут после трансформеров, мы делаем. Такое вступление я придумал для статьи, когда мы закончим с экспериментами и доделаем пилот, а пока продолжу дневник обучения TAPe-модели. Комуинтересно: начало тут, здесь и там, а немного про методы TAPe (Теории активного восприятия) в области обработки информации — здесь.

Сначала протестировали эту же модель с тем же числом параметров на большом датасете COCO. Без оптимизации получили решение с точностью 60.59%, что является очень высоким для такой модели (невозможно высоким даже, такая модель по идее не должна сходиться и находить общее решение из количества параметров, но данные TAPe позволяют). Пока сложно сравнить с конкретной метрикой других моделей, потому что мы не строим рамки вокруг предмета, но находим конкретно центр объекта. Это проведем позже. 

Тренировка на процессоре как минимум не дольше, чем тренировка на видеокарте, поэтому мы ограничены только количеством данных на ОЗУ в TAPe‑формате — что не является ограничением в целом, можно весь датасет уместить одновременно там
Пока существуют несколько проблем:

• Количество ложных срабатываний (скорее симптом, но все же);

• Не самая лучшая классификационная точность (тоже в большой степени симптом);

• Неправильное центрирование объектов (немного ограничение детекции, но есть способы обойти);

• Размерность COCO;

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

Конкретно:

Работа матрицы преобразования на данный момент времени немного линейная. Зависимости по большей части линейные (то есть, независимые друг от друга). Это не хорошо, по понятным причинам, но в тоже самое время это помогло перейти к пониманию одного факта: в найденном нами подходе, о котором писали выше, есть как раз нелинейная зависимость коэффициентов друг от друга. Эту связь нужно выстраивать вручную, в зависимости от градиентного спуска и deep learning, но в нашем случае связи по TAPe известны заранее,
Дополнительно начинаем вторую фазу создания решения, чтобы можно было захватывать объекты любого размера. Это должно привести к намного более точным ответам, при этом ускорив модель. 

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

Дальше планируем продолжить работу с полным датасетом (используя 2% из него для быстрых тестов — это около 2400 изображений).

Как мы ушли от всем известного способа градиентного спуска

Продолжаю дневник разработки «Суперраспознавалки» для демо/пилота. День третий. Основная задача: настроить TAPe‑модель на датасет типа COCO под задачу detection. Вторая — дать клиентам возможность добавлять собственные классы к уже существующим. Ну и далее, при необходимости, полная адаптация модели под конкретного заказчика. Поскольку у нас есть Теория активного восприятия с ее методами, на выходе заказчик должен получить кратную эффективность и кратную экономию ресурсов.

В первые два дня настраивали базовую струтуру сегментации, детекции и классификации. Модель решает задачи на обучении уже 115 тыс параметров — в отличии от YOLO, которой мало 2 млн + параметров.

Начало здесь

Второй день здесь

Про архитектуру TAPe+ML здесь

Тут сравнение трех десятков кодировок в задаче сегментации видео в DBSCAN (включая ViT, DINO) с TAPe

День 3

Сегодня занимаемся исправлением количества ложных срабатываний. Проблема ложных срабатываний в целом в том, что мы смотрим в первую очередь на текстуру изображения (из‑за особенностей методов TAPe). Поэтому приходится прибегать к менее‑обычным способам для обучения разделения между текстурой заднего плана (в каком‑либо виде, будь это снег, или трава) и текстурой самого объекта.

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

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

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

Также начали эксперименты с добавлением цветовых каналов. Однако проведенные эксперименты с цветами в простой схеме объединения features по каналам не дало желаемых результатов: даже с greyscale мы забираем столько информации, что цветовая гамма по большей части их просто дублирует. Это приводит к тому, что модель опирается слишком сильно на общие черты, не «видя» при этом выдающиеся черты разницы цвета. Что в то же самое время может и являться хорошей фичей, а не багом, потому что через разницу в текстуре мы, по идее, должны найти разницу в любом случае (если это реальное изображение). Поэтому мы не полагаемся в решении на конкретную задачу, где цвет более релевантен, а полагаемся на общее решение детекции в целом.

Также на заднем плане были закончены эксперименты с разными архитектурами (эксперименты продолжались параллельно несколько дней). Нашли самую лучшую архитектуру на данный момент (самая логичная по её смыслу, как нам кажется). Тут без подробностей, но мы ушли от всем известного способа градиентного спуска, что позволяет нам после тренировки модели прийти к глобальному минимуму решения (или к чему‑то очень близкому к этому — всё равно есть зависимость от задачи).

Мы собираем данные из патчей определенным образом, объединяем их в общее описание, а затем уже классифицируем конкретно эти объединения по тому, есть там объект или его нет. Классификация происходит за счет общих описаний каждого класса, который модель видит — и не тренируется отдельно, потому что исходит натурально из первичной тренировки векторов, а затем сводится к одному описанию через k‑means.

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

День 2. 115 тыс параметров вместо 2 млн+ у YOLO

Продолжаю дневник разработки «Суперраспознавалки» для демо/пилота. Начало здесь.

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

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

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

Разбиение происходит за 100+ кадров в секунду, без оптимизации, с обработкой каждого кадра отдельно (то есть есть также overhead выгрузки изображения на GPU).

Также пришло понимание, что нужно переходить к этапу дополнительных действий, чтобы отбирать интересные места. В целом по результату вышло, что количество ложных срабатываний в разы уменьшилось, но при этом количество правильных ответов тоже немного снизилось (на пару процентов, но заметно в любом случае, тем более у нас цель получить условные 100% на тестовых данных). Это происходит как раз таки из‑за того, что нет правильной последовательности действий (что, впрочем, нами ожидалось, просто не думали, что это так быстро произойдет).

Перешли к более адаптированной под TAPe логике. Пока очень топорным способом (так легче тренировать и проверять работу), но выходят очень хорошие результаты. По поводу данных немного скажу для контекста:

Разбиение следующее:

Classes: 4; labeled: 1256, train: 879, test: 377, miss images: 559

То есть, 4 класса, общее количество изображений объектов — 1256, из них в тренировку уходит 879, в тестирование — 377. Miss images — это изображения просто заднего фона, а также случайных объектов, не являющихся нужными объектами.

Для YOLO необходимо около 1500 изображений на один класс. Мы же успешно используем около 220 на класс + какие‑то изображения фона (которые есть только для травы и снега, например).

Результаты имеют точность определения того, где находится нужный объект (не её вид — это отдельный шаг) с точностью 98.94% (то есть правильно для 373 из 377 изображений). Ложные срабатывания ещё существуют, но их стремительно меньше.

Интересно, что модель «самостоятельно» находит правильно нужные объекты, даже если в тренировочных данных они не были обозначены (то есть тренировочные данные неправильные). Модели всё равно удаётся определить оба объекта, что показывает, что модель обучилась формам объектов успешно.

Чтобы добавить контекста — размер модели 115 тысяч параметров. Самая маленькая из современных YOLO же имеет 2+ млн параметров, и при этом не справляется с задачей.

Сейчас делаем пилот сразу для нескольких заказчиков. Рабочее название — «Суперраспознавалка» :))

Основная задача: настроить TAPe-модель на датасет типа COCO под задачу detection. Вторая — дать клиентам возможность добавлять собственные классы к уже существующим. Ну и далее, при необходимости, полная адаптация модели под конкретного заказчика. Поскольку у нас есть Теория активного восприятия с ее методами, на выходе заказчик должен получить кратную эффективность и кратную экономию ресурсов.

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

Некоторые проекты — NDA, когда буквально нельзя указывать точное название объектов, которые нужно детектировать. Поэтому не обессудьте. Ноу‑хау по‑прежнему не собираемся раскрывать. Только результаты и часть пути к этим результатам.

День 1. TAPe и YOLO

Закончили с базовой структурой для сегментации, то есть с тем, как за один «ход» получать необходимый набор патчей, чтобы дальше расчёты шли параллельно (и оттуда же быстро), что также немного подводит ближе к самой логике действий здесь. Сейчас за одно действие получается определить все точно‑неинтересные места, а также все возможно‑интересные места (то есть, где есть детали в целом).

Что интересно сейчас в самом подходе — это то, что благодаря TAPe получается избежать проблемы других сегментационных моделей — а именно:

• Необходимость классификации буквально каждого пикселя (как поступают стандартные современные модели семантической сегментации);

Стандартные модели буквально классифицируют каждый пиксель (или каждый N‑ный пиксель, если сжимают разрешение) на отношение к тому или иному классу. 

• Необходимость проверять каждый шаг в какой‑то ограниченной сетке размером N на N (так делает конкретно YOLO)

YOLO обходит это использованием сил CNN, классифицируя только конечное количество патчей (зависит от версии YOLO, в первой их было 6400, что всё равно много). Методы TAPe же нам позволяют этого не делать, потому что единицы информации в TAPe (которые мы назвали T‑bit) несут в себе гораздо больше информации, чем бит. В данном случае — несут в себе нужную структуру для нахождения похожести — а значит для нахождения сегментов, в которых нужно что‑то классифицировать в целом. И даже здесь благодаря TAPe у нас есть преимущество: мы можем проводить классификацию на условном нулевом уровне, не уходя в глубину.

Используя даже простую версию такого подхода, мы уже можем приходить к такой сегментации на простых примерах (разные цвета показывают разные сегменты). Лавочка — один сегмент, урна — другой, всё остальное — разные неровности, которые также можем буквально отфильтровать, если не хотим проводить их классификацию их. То есть — объект находится условно одномоментно.

Новая страшилка от Citrini Research: Кризис Интеллекта

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

Мнения людей после прочтения статьи разделились на оптимистичные и пессимистичные:

• Оптимисты апеллируют к закону Сэя, который в сущности своей говорит следующее: спрос может подстроиться под любое количество предложения. В таком случае сэкономленные бизнесом деньги перетекут в другие и/или новые сектора экономики.

• Пессимисты утверждают, что в случае с ИИ базовый механизм закона Сэя ломается. Роботы и алгоритмы производят товары и услуги, но не формируют потребительский спрос. Разрывается цикл "произвёл → получил деньги → потратил", потому что из него исключается человек. И кризис, описанный в статье, очень близок.

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

Самое "важное", что пытаются нам сказать авторы статьи и другие медийные личности индустрии: произойдёт переоценка человеческого интеллекта и его влияния на формирование цены продукта или услуги. И далее эта мысль подкрепляется предсказаниями об увольнении офисных клерков, джунов и других начальных и средних позиций.

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

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

Остаётся ответить только на 1 вопрос: Куда человечество в целом хочет прийти
через N лет?

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

Случайно можно наткнуться на мысль, что никто никуда идти и не хочет. Только заработать побольше денег и надуть пузыри до предела. Грустная мысль и, можно сказать, "глупая".

Спасибо, что почитали. Надеюсь, смог натолкнуть вас на интересные мысли. Буду рад вашим вопросам / дополнениям / комментариям.

Недавно вышла новая версия dplyr 1.2.0, и она принесла несколько важных обновлений, которые делают работу с данными в R ещё проще и удобнее. Опубликовал видео обзор в котором я рассказываю про самые интересные новинки: новые функции фильтрации filter_out(), when_any() и when_all(), обновлённую систему перекодировки с recode_values(), replace_values() и replace_when(), а также о важных оптимизациях старых функций.

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

Видео снято по статье "dplyr 1.2.0".