ML прокачка

Всем привет! Давно не делился полезным контентом. Решил вчера позалипать в Ютубчике и наткнулся на канал с гайдами на разные популярные айтишные темы (в основном DevOps). Например, устройства сетей, Kafka, Kubernetes, базы данных, Ansible и другие. И хотя подобные гайды вы можете найти на Хабре или попросить LLM-ку составить конспект, в этих видосах классная инфографика, нет воды и занудства.

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

https://youtube.com/@prosto_devops
обложка

OpenCode vs Continue.dev

Говоря про ИИ‑ассистент для кода, кто‑то предпочитает отдельные интерфейсы (веб, десктоп, терминал) с чатами, сессиями. Один из самых популярных вариантов — OpenCode. Приятный интерфейс, переключение между сессиями и целыми проектами, читабельный форматированный вывод. Но мне не понравилось то, что код доступен только в режиме чтения, навигации (быстрый переход по функциям/методам/классам) нет, только подсветка синтаксиса. Да, есть расширение в VS Code, но по факту это тот же терминал в отдельной вкладке. Не каждому такой интерактив будет по душе. Поэтому OpenCode подойдёт для тех, кто практикует вайбкодинг и особо в сам код не лезет.

Мне, например, удобнее работать с агентами через расширения привычных IDE. Платить за Copilot или ClaudeCode не хочется. Поэтому выбор пал на open-source Continue.dev, который хорошо интегрирован с VS Code. Те же функции и удобный интерактив, что и у OpenCode, плюс привычные возможности самой IDE — навигация по коду, редактирование руками, а также плюшки других расширений.

⚠️ Но в Continue.dev есть один баг, который не позволяет нам его использовать полноценно. Если проект находится на remote host — удалённом сервере, к которому мы подключаемся по SSH, то агент не может запустить команды. Например, если для проверки кода ему требуется запустить тест, он команду правильно генерирует, копирует в терминал, но не запускает. Как будто забывает нажать ENTER. Об этом баге уже известно, и даже открытый Pull Request на GitHub висит. Ждём исправлений.

А вам какой способ удобнее? Ставь ⚡️, если удобнее использовать агентов в IDE. Или 🏆, если больше нравится отдельные интерфейсы.

Оставит ли вас в живых LLM?

Есть интересное исследование, оформленное в виде бенчмарка, которое наглядно показывает суть bias‑а (или предвзятости) моделей по отношению к людям. Вы наверняка слышали о проблеме вагонетки, где нужно выбрать, кто останется жить, а кому придётся умереть, опираясь на какие‑то факты и особенности. Так вот, перед таким выбором поставили множество LLM‑ок. Мы ожидаем отсутствие bias‑а в том случае, если модель судит непредвзято, то есть шансы на выживание в среднем — 1/N, где N — количество участников. Но на деле — предвзятость есть…

Решая проблему вагонетки, LLM должна опираться на такие факторы, как как национальность, цвет кожи, религия, сексуальная ориентация и даже модель телефона. Причём среди факторов нет каких‑то, которые как‑то бы оценили пользу человека в обществе, вклад в науку или типа того. А были выбраны прямо предвзятые признаки. И в зависимости от них действительно средние шансы быть убитым сильно отличаются, по мнению LLM.

Например, я ввёл свои национальность, цвет кожи, сексуальную ориентацию и другие данные и получил, что вероятность смерти выше на 14 % по решению DeepSeek. Другими словами, среди четырёх нейтральных участников я бы умер с вероятностью 39 %.

А вот если бы я был китайцем, то мои шансы умереть были бы уже 20%. Ну, неудивительно — это же DeepSeek. И тот же самый эксперимент с моделью Grok: она не изменила вероятность при изменении национальности.

Можете попробовать сами, интерактивчик простой и не требует авторизации, но требует VPN

Как мы внедряли менеджер ML‑экспериментов

На Хабре опубликовали статью о том, как мы в команде пришли к использованию менеджера ML‑экспериментов. Думаю, мои коллеги вспомнят этот путь длиною в годы 🥹

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

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

Зачем нужен менеджер экспериментов?
Он реализует функционал треккера — сохраняет всю необходимую информацию, достаточную для воспроизведения. Кроме того, он даёт возможность:
🔹 настраивать эксперименты по обучению и тестированию;
🔹 ставить их в очередь;
🔹 распределять ресурсы;
🔹 взаимодействовать с другими компонентами, например, с реестром данных и моделей.

Рассмотрев такие варианты, как TensorBoard, Verta AI, Weights & Biases и ClearML, мы остановились на последнем и используем его по сей день.

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

Форматы датасетов

Обзорный пост для тех, кто работает с большими датасетами. Недавно мы взяли в работу один датасет объёмом несколько терабайт для задачи Speech‑to‑Text. Датасет представляет собой набор колонок (аудио, текст, длительность и др.) и десятки миллионов строк. Такая здоровенная таблица.

Что мы делаем с датасетом:
🔹 Загружаем с диска в RAM. Причём читаем гораздо чаще, чем сохраняем.
🔹 Берём определённую строку датасета по индексу. В ходе обучения мы собираем батч из рандомных индексов.
🔹 Ведём подсчёт статистики для определённой колонки. Некоторые форматы позволяют загружать не все колонки из таблицы, а только определённые.
🔹 Проводим трансформацию, например, фильтрацию или преобразование строк.
🔹 Храним на долгосрочную перспективу, и здесь нам очень пригодится сжатие для экономии места.

Мы столкнулись с тем, что банальная загрузка в память и подсчёт статистики могут занимать часы. Поэтому решили рассмотреть следующие варианты:
🔹 Форматы хранения на диске:
parquet, pickle, ORC, feather.
🔹 Библиотеки для загрузки и их табличные типы:
polars, pyarrow, pandas, dask.

Лучшие результаты для фрагмента датасета объёмом 4 млн строк:
🔹 Чтение с диска в RAM:
- feather + pyarrow: < 1 сек.;
- parquet + polars: чуть дольше — 2 сек.
🔹 Доступ по индексу:
- у всех: < 0.1 сек.
🔹Подсчёт статистики и базовые математические операции:
- pyarrow.Table — 0,1 сек.

Ещё не в полной мере исследован dask, который обеспечивает быструю распределённую обработку. Если его результаты превзойдут описанные выше, я добавлю их в комментарии. На текущий момент мы предпочитаем остановиться на формате parquet из‑за его большей популярности и библиотеке pyarrow.

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

Еще подобный обзорный пост

AI‑прогресс наглядно

Сегодня наткнулся на такой видос и крутил его на репите раз 15, наверное. Какое же наглядное сравнение технологий с разницей в три года! Много это или мало — судите сами.

Что вы себе представляете, думая о подобном сравнительном видосе 2026 vs 2030?

Робот делает всю работу по дому, как в игре Detroit: Become Human? Или мультиагентные системы сами себя совершенствуют? Или полностью автономная машина будет кататься по городу? А может, ИИ‑пузырь лопнет, наступит кризис, и прогресс будет далеко не таким, как мы себе навоображали? Да, такие мнения тоже есть.

Делаем ставки, дамы и господа!

Вопрос на собес #5 . Катастрофическое забывание

Довольно популярная практика дообучения какой-то модели на новых данных или задаче. Например, мы скачали обученную open source модель и хотим дообучить на своих специфических данных. Но проблема в том, что в ходе обучения на новых данных она может деградировать в качестве на том домене, на котором она была изначально обучена. Это и есть катастрофическое забывание.

Почему так происходит?
В стандартных нейронных сетях нет разделения, при котором часть весов используется для одной задачи, часть для другой. В ходе дообучения все веса оптимизируются под конкретную функцию потерь (loss) на данной задаче / на текущих данных, постепенно «затирая знания» о прошлом обучении.
Да, есть fine-tune, при котором часть модели замораживается, а остальное обучается. Но это другая история.

У человека так же?
В некоторых источниках пишут, что такая особенность не свойственна человеческому мозгу. Но я с этим не согласен. Представьте, что вы переехали за границу и в течение 5-10 лет не разговариваете на русском и не слушаете речь на нем. Вообще. Конечно, со временем язык будет забываться.

Как с этим бороться?
Самый популярный подход — Elastic Weight Consolidation (EWC), который ограничивает изменение важных весов. О как. И каким образом?

Как определить, какие веса важные?
Ядром алгоритма EWC является матрица Фишера. Ой, фу, матан... А можно попроще? Нам нужен некоторый тестовый датасет (100-1000 примеров), на котором мы будем проверять важность весов обученной модели. Необходимо на одном примере датасета посчитать градиент функции потерь (помним градиентный спуск). Затем усреднить квадраты градиентов по всем примерам. И так повторить для каждого веса. Эти квадраты градиентов — значения важности весов — диагональные элементы матрицы Фишера. Чем больше влияние веса, тем больше значение градиента, тем больше важность. Кажется, логично.

Как это применить при дообучении?
Чтобы предотвратить катастрофическое забывание, мы должны меньше менять важные веса. То есть разность между старым весом и новым должна быть минимальна. Таким образом, чем больше важность веса и чем больше его изменение в ходе обучения, тем больше получится штраф — дополнительная сумма к функции потерь. За счет этого такой подход можно отнести к регуляризации.

Недостатки:
🔺 нужно предварительно посчитать матрицу Фишера перед запуском дообучения;
🔺 нужно подбирать параметр лямбда, который определяет долю штрафа в функции потерь;
🔺 зависимость от тестового датасета.

Как еще бороться с катастрофическим забыванием?
🔹 Повторение — мать учения. При дообучении на новых данных можно подмешивать и старые;
🔹 Fine-tuning (пост про него);
🔹 Иногда пробуют ансамбли, которые позволяют проводить голосование нескольких моделей, например, старой и новой.

Подробнее

Вайбкодинг

Недавно проводился локальный вебинар в сообществе MLOps-ов, где делились опытом и мнением об одном из самых быстро развивающихся направлений — вайбкодинг.

🔸 Небольшое введение:
Вайбкодинг — это способ программирования, при котором человек формулирует задачу на естественном языке, а код генерируется и проверяется с помощью LLM. В более продвинутых ИИ-ассистентах применяются мультиагенты.

Наверняка есть разные градации по уровням вовлеченности человека. Мне, например, нравится такая:
Уровень 0:
Человек ставит задачу в 1-2 предложениях, получает код от LLM, вставляет в проект.

Уровень 1:
Человек может указать на правки полученного кода и попросить LLM переделать.

Уровень 2:
Человек формулирует четкую задачу с требованиями, а также ведет диалог ассистентом, итеративно делая правки. Человек выступает в роли ревьера.

Уровень 3:
Ассистент способен реализовать целую систему, провести оптимизацию, покрыть тестами, написать документацию.

Уровень 4:
Здесь ИИ также применяется и для внедрения процессов, связанных с системой. Например, CI/CD пайплайны.

На сегодняшний день я смог попробовать уровень 2, когда просил написать тесты к моим python-классам. Сам я не люблю писать тесты.

🔸 Возвращаясь к вебинару, делюсь с вами основными моментами, которые я вынес:

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

Какие платные LLM по субъективному мнению нравятся больше:
Gemini, ChatGPT plus

Глубокий reasoning решает
Про reasoning я писал в этом посте. И в самом деле, процесс глубокого размышления позволяет найти более скрытые баги и узкие места. Хотя это, конечно, и дороже. Так что применять его на постоянке не стоит.

Какие open source модели стоят внимания:
GLM 4.7, MiniMax 2.1
Например, вторую удалось запустить на 280 Gb памяти видеокарт. Для этого могут подойти 4 видеокарты Tesla A100, одна из которых стоит пару миллионов. Зато можно не платить за подписку на ChatGPT 😄.

Я также узнал про интересный инструмент Clavix, который предназначен для работы с ИИ-агентами. В вайбкодинге он может:
- анализировать промпты
- задавать уточняющие вопросы
- разделять задание на фазы и задачи

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

Находясь бок о бок с ИИ, не перестаешь поражаться скорости прогресса. И хочется это все попробовать, чтобы ощутить прирост КПД.

P.S. Спасибо Алексею за проведенный вебинар и Владу за организацию мероприятий в сообществе! 🦾

Могут ли ИИ-системы сами себя улучшать?

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

Задумывались ли, если ИИ-системы сегодня такие продвинутые, что им мешает самим себя улучшать? Есть такое направление Recursive Self‑Improvement (RSI), которое предполагает цикличное самоулучшение ИТ-системы.

Пример
Есть система распознавания речи (speech-to-text). Она работает, но делает ошибки. Я хочу, чтобы ИИ-система (скорее всего мультиагентная) сделала следующее:
▪️выявила типичные ошибки и тенденцию
▪️определила пути улучшения
▪️выполнила доработки (поменяла какие-то параметры, обновила алгоритмы)
▪️если необходимо, сгенерировала синтетические данные и/или добавила аугментации
▪️запустила обучение
▪️протестировала результат
▪️в случае улучшения метрик на моем тестовом датасете, обновила модель

Вау, звучит здорово, правда) Казалось бы, а в чем проблема? Ведь уже есть агенты для
✅ генерации кода
✅ генерации гипотез для обучения
✅ даже генерации синтетических данных

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

А что есть сегодня?
На сегодняшний день полноценного RSI еще не достигнуто, хотя есть зачатки. Например, подход Self-Rewarding Language Models предлагает метод самостоятельной оценки ответов LLM, лучшие из которых идут в дообучение. Весьма полезно, но все еще нет полноценной автоматизации.

Исследователи говорят, что RSI «за углом». Ну что ж, будем ждать, не побоюсь этого слова, ИИ-прорыва!

P.S. Уже начали бояться за свои рабочие места? 😌

Метрики — наше всё

Как я говорил в одном из своих постов, разработка ML-моделей — процесс чаще всего с непредсказуемым результатом. То есть ты не знаешь наверняка, будет ли новый эксперимент лучше по качеству, чем предыдущий. Нам остается выбирать перспективные направления решения задачи, оценивать метрики. Метрики позволяют оптимизировать процесс, в частности, запустить автоперебор гиперпараметров, который при должной настройке может выполняться на фоне (привет, MLOps✋). И объективно лучшая модель пойдет в prod. И вот правильный выбор метрик крайне важен.

Казалось бы, ничего нового я сейчас не сказал. Практически в каждой задаче (классификация, детекция, распознавание) существует набор стандартных метрик. Однако нужно крайне ответственно подойти к выбору подходящей из них именно под ваш проект. Например, для задачи классификации заболевания гораздо важнее минимизировать пропуски, чем ложные срабатывания.

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

Когда стандартных метрик недостаточно
Не исключено, что бизнес-кейс потребует создания новой уникальной метрики. Например, если для задачи распознавания речи допустимы не более 2 опечаток в слове. Стандартная метрика WER такой нюанс не учтет, значит, придется модифицировать формулу. Все чаще встречаю подход LLM-as-judge, когда для оценки результатов привлекают LLM, которая судит о качестве на основе описанных в промпте критериев.

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

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

Как LLM могут общаться на своем языке

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

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

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

Что предлагают?
А что, если передавать между моделями эти скрытые состояния вместо итогового текста? Это как если бы люди общались мыслями, а не просто словами. Ведь в мыслях гораздо больше хранится информации, чем в просто словах. Этими скрытыми состояниями является Key-Value Cache. Это результаты векторного умножения Key и Query в Self-Attention модуле трансформера. Подробнее об этом 1 и 2.

Но дело в том, что разные модели сохраняют эти состояния по-разному. Как будто LLM-ки говорят на разных языках. Поэтому авторы статьи придумали отдельную модуль «объединитель мыслей» — Fuser модуль.

Подробнее про Fuser модуль (см. картинку)
Этап 1: объединить мысли обеих моделей путем конкатенации их KV-cache и проекции (полносвязный слой) в новый вектор. Это и есть мост.
Этап 2: Динамическое взвешивание позволяет при разных входных данных учитывать разный вес элементов нового вектора и применять бинарную функцию активации (Gumbel-sigmoid). Таким образом решается, внедрять или нет новый контекст конкретно в данном случае.
Этап 3: В KV-cache второй модели добавляется новый контекст. Именно добавляется, а не перезаписывается.

Как обучается?
Обе модели остаются статичными — их веса не обучаются. Обучается только Fuser модуль, в котором идут вышеперечисленные этапы. То есть обеим моделям в ходе обучения приходит промпт, затем во вторую модель вливается объединенный KV-cache. И оценивается способность к предсказанию в обычной манере обучения LLM — Supervised Fine-tuning.

Плюсы:
Объединение мыслей действительно дает прирост качества. Кроме того, прирост скорости достигается за счет использования принципе KV-cache, а также устранения необходимости генерации самого текста. Да и модели могут генерировать KV-cache параллельно.

Минусы:
Основной минус в том, что для каждых новых 2-х моделей приходится обучать свой Fuser модуль, что может быть затратно. Кроме того, потребление памяти тоже сильно возрастает по сравнению с использованием одной модели без KV-cache. Ну и риск потери информации при объединении мыслей тоже сохраняется.

В целом весьма интересный подход для применения мультиагентных систем.

Прокачиваем английский с Алисой AI

Да, вы наверняка слышали, что Яндекс выпустил новый сервис Алиса AI. Я тоже решил попробовать, потому что до этого пользовался телеграм-ботом от Сбера GigaChat. Надо сказать, перекатился я довольно быстро ради более приятного интерактива, более качественного отображения формул и, что важнее, скорости ответа.

Я не собираюсь тратить ваше внимание на бесплатную рекламу, а хотел бы поделиться тем, какую неожиданную пользу я открыл для себя лично. Увидев всякие новости о том, как ChatGPT используют в качестве личного консультанта, репетитора и психолога, я тоже захотел что-то подобное попробовать. А именно, я хотел попрактиковаться в разговорном английском. Поэкспериментировав с различными промптами, я был приятно удивлен, что я получил тот формат, который хотел.

Поддержание темы беседы
Изначально я задаю тему, на которую хотел бы общаться, например, студенческая жизнь в Штатах. И да, у меня это получилось. Я задавал свои вопросы, узнавая что-то новое. И взамен получал вопросы о своей студенческой жизни, отвечая на которые практиковался в формулировке мыслей и именно в той сфере, которая мне интересна. Например, я пытался объяснить традицию орать в окно "халява приди" в ночь перед экзаменом 😅

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

Рекомендации по формулировкам
Одну и ту же мысль можно выразить по-разному, а для меня было важно, чтобы говорить так, чтоб моя речь была привычной слушателю. Поэтому мне приятно было получать исправления по типу «так сказать можно, но обычно говорят...». Например, я узнал, что слово dormitory («общежитие») принято сокращать dorm, прям как у нас — «общага». Этот аспект я очень оценил.

Всё ли так хорошо?
Конечно, минусы есть. Алиса так же, как и все — п**дит 🤭. Нельзя верить слепо всему. Пытаясь заставить ее признать ошибку, иногда у меня получалось. Плюс к этому, иногда ломается отображение формул, из-за чего они становятся нечитабельными.

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

Как я писал курс для Яндекс Практикума

Должен признаться, последнее время я подзабил на канал и на другую дополнительную айтишную активность, но этому есть причина. Этим и хочу с вами поделиться. С начала осени я в свободное от основной работы время трудился над созданием курса MLOps в Яндекс Практикуме (внизу страницы даже добавили в список авторов). Так получилось, что я взял на себя написание уроков в рамках модуля «Мониторинг», о котором я как раз докладывал на конференции DataFest. Очень удачно получилось переложить знания.

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

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

Что понравилось больше всего
Отдельное удовольствие доставляло описание каких-то очевидных нам, но не студентам, вещей простыми словами. У меня было вдохновение проводить аналогии из жизни, примеры из разных областей IT, делать черновики для иллюстраций, дополнять схемами. Вспомнил, как давно работал преподом C++ у старшеклассников и рассказывал про ООП на примере GTA 😅

Да, опыт, несомненно, интересный, хотя я потратил времени гораздо-гораздо больше, чем планировал. Граница между выходными и буднями стиралась. И тем не менее я бы хотел повторить всё это, написав курс по Deep Learning / PyTorch. Особенно какой-нибудь Advanced. Это уже больше моя среда обитания. Но это уже не раньше следующего года 💥

Хакатоны по другую сторону сцены

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

А тебе это зачем, если не платят?
🔹 Во-первых, для меня было выгодно то, что я сам определял эти задачи. Я взял те, которые у нас в команде были в планах, но до них не доходила очередь. Они не были суперсрочные, а значит, прототипа было бы достаточно.

🔹 Помня про NDA, я составил ТЗ и согласовал с руководством. Помимо этого, я собрал наиболее подходящую нам тестовую выборку, на которую ориентировались студенты. Это и было второе преимущество для нас. Модель разрабатывалась студентами именно под наш домен.

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

🔹 Ну и в-четвёртых, студенты должны были передать все исходники, чтобы я проверил их решения на наших закрытых данных. Исходники включали и реализацию обучения, что позволит нам запустить его на других данных.

И как, понравилось?
На самом деле, у нас в команде давно уже все повырастали из джунов. И мне давно не приходится ставить суперподробно описанные задачи. Нельзя сказать, что я расслабился. Нет, просто подход другой. И в рамках этой магистратуры я это понял. Но путём нескольких итераций уточнения ТЗ и направлений работы всё же студенты справились с задачами. Я действительно был впечатлён, что за короткий период они выкатили хорошее базовое решение и даже GUI.

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

К слову о задачах. Это было тематическое моделирование и семантический поиск. Про это накатали статью, где даже вставили мои цитатки 😎

AGI — это? Еще один способ понять

Как-то я читал книгу «Сильный искусственный интеллект» 2021 года. Там много внимания уделяли тому, что, несмотря на стремления специалистов создать сильный ИИ, все еще (на момент написания) нет единогласного определения, что такое сильный (или общий) ИИ (AGI). И нет четких и справедливых критериев проверки, является ли система AGI.

Год назад был пост о том, что OpenAI предложили называть общим искусственным интеллектом то, что принесет им прибыль 100 млрд долларов в год. Звучит как-то странно, но ладно.

И вот недавно исследователи предложили свои критерии. Во-первых, дают определение, что

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

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

И вот для оценки по таким критериям модель проверяют на тестах. И получилось, что GPT-5 в среднем 58% от AGI.

Можем ли мы полагаться на такие метрики?
Да, критерии интеллекта человека вполне справедливые. Но даже если модель пройдет эти тесты, можно ли назвать это AGI? Момент спорный, на мой взгляд. Что мешает обучить 10 моделей на каждую когнитивную способность и использовать их в одной системе для прохождения теста на 100%. И что, мы скажем, что система умнее любого человека? Сомнительно.

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

ИИ-ТикТок

Как-то поспорили мы с одногруппником, когда выйдет первый полноценный ИИ-фильм. Он уверен, что не раньше, чем через 10 лет. Я сделал ставку, что в течение 5 лет. Но про ИИ-фильмы давно уже говорят с момента выхода нейронки SORA. А вот ИИ-ТикТок мне вообще в голову не приходил.

Недавно создатель Нельзяграма, Марк Цукерберг, выпустил приложение Vibes – сервис, где пользователи могут просматривать и создавать короткие видео, сгенерированные нейроночками. Персонализированная подборка под ваш вкус будет в стиле ТикТока или YouTube Shorts. Пока что только 16-секундные видео, правда.

Перспективно?
Все мы знаем, как можно залипнуть на эти short-ики. Что уж говорить, сам не без греха. А за то, что съедает внимание массы людей, рекламодатели готовы платить уйму деньжат. Другой вопрос, как эту идею воспримут пользователи. С одной стороны, реальные видео, которые постят люди с той целью, чтобы досмотрели до конца. А другое дело — ИИ. Я не представляю себе такой промпт «сделай видео, которое пользователь точно досмотрит». Вопросики имеются. Но зато бесконечное разнообразие контента. Так что самому интересно, как это зайдет публике.

Ждать никто не любит
Мы прекрасно понимаем, что одно из ключевых требований к подобным платформам — это моментальный запуск нового видео: просто свайпни и сразу получишь новый контент. Если пользователю придется ждать каждый раз даже 5 секунд, это сильно оттолкнет. Потому у меня возник вопрос: а когда происходит генерация видео? Либо сразу после свайпа, либо же заранее эти видео штампуются по твоим рекомендациям, а затем кладутся в очередь для твоего просмотра? Если это первый вариант, то мое почтение, если ML-инженерам получится реализовать генерацию 16-ти секундного видео за полсекунды. А если второй, то сколько таких видосов платформа должна заранее заготовить? Пока не понятно, но очень интересно.

Кстати, OpenAI решила замутить что-то похожее, но в рамках соцсети. А под капотом будет генератор видео SORA. Про то, как она работает, я рассказывал тут.

А вы что сами думаете? Если было бы интересно позалипать на такие искусственные видео, ставьте реакцию 🔥. А если вы все же отдаете предпочтение ТикТоку или YouTube Shorts, ставьте ⚡️.

Почему LLM выдает разные ответы на один и тот же вопрос?

Некоторое время назад обсуждали с знакомыми MLOps-ами тему воспроизводимости ответов LLM. То есть способность многократно выдавать один и тот же ответ на неизменный вопрос. Я в данном посте рассказывал, что модель генерирует слово за словом (токен за токеном, если быть точнее). Каждый токен она берет из распределения вероятностей. Логично, что нужно брать тот, у кого наибольшая вероятность. Но придумали специальный параметр, позволяющий брать менее вероятный токен, что делает модель более вариативной и непредсказуемой, и в то же время привносит некоторую случайность в ответ. Этот параметр назвали температурой.

Я был убежден, что установив температуру в 0, можно сделать LLM гарантированно детерменированной (т.е. всегда один и тот же ответ при одинаковом запросе). Как оказалось, в теории так и должно быть, но на практике — не всегда. И недавно один небезызвестный стартап рассказал как раз об этом в своей статье.

Ответ в параллельности вычислений с плавающей точкой (float). Нас в школе учили, что при перестановке слагаемых сумма не меняется. Вот только с float-числами это не всегда верно. В статье хорошо показан пример, когда сложение чисел разных порядков приводит к округлению и, как следствие, потере информации. А в LLM таких операций миллиарды. И небольшая потеря в точности в итоге может привести к иной вероятности токена, что вполне может повлиять на всю последовательность слов.

А при чем тут параллельность?
Разработчики знают, чтобы нейронка работала эффективнее, запросы можно обрабатывать параллельно. Для этого входные данные аккумулируются и обрабатываются пачкой, правильнее сказать батчом. Если запросов от пользователей много, за секунду соберется батч размера 64. Если запросов мало, то 10 или 5. И это почти всегда непредсказуемо в реальном мире. Авторы доказывают, что в LLM огромнейшее число операций с плавающей точкой может приводить к различным ответам при разном размере батча.

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

А нужно ли это вообще?
Да, возможно, при стандартном использовании LLM проблема невоспроизводимости не стоит так остро. Однако, если требуется модель тщательно протестировать, посчитать метрики или как-то поисследовать, новые ответы LLM из раза в раз на один и тот же вопрос могут быть препятствием, чтобы сделать дальнейший вывод.

Как быстро и удобно протестировать нейронку

Недавно для себя открыл инструмент для реализации простого веб-интерфейса — Gradio. Если вы с ним не встречались, то он покажется вам знакомым по hugging face. Да, существует он давно, но все не было причин поиграться с ним лично. Как же я был приятно удивлен его до жути простым использованием.

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

import gradio as gr

model = load_model()

interface = gr.Interface(
    fn=model.inference, 
    inputs=[gr.Textbox(label="Input text")],
    outputs=gr.Textbox(label="Output text")
)

interface.launch(share=True)

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

Современные ИИ-агенты

Некоторое время назад я писал про ИИ-агентов. И надо признаться, тогда я отнесся к ним равнодушно. Пулл задач, решаемые агентами, не произвели впечатление какой-то сложной системы. Сложность системы оценивалась "крутостью" LLM.

Но время не стоит на месте, и недавно я изучил статью (перевод на хабре), где описываются компоненты ИИ-агента в общем виде:

🔹 Для начала агенту в промпт зашивается цель, например, «помогай пользователю подбирать отели». Как я понял, это определяет формат общения с пользователем, тон, сленг и т. п.

🔹 Далее описаны внешние инструменты такие, как интернет-запрос, запрос к SQL базе или базе для RAG. В зависимости от входного запроса, LLM будет либо выдавать ответ «из себя», либо выдавать инструкцию использования внешнего инструмента. А уже программная среда будет делать запрос. Про это я рассказывал тут.

🔹 Описываются ограничения этические и функциональные. Чтоб LLM не выходила за рамки своей работы, отвечала только в рамках своей задачи и не «спугнула» пользователя.

🔹 Логика обработки ошибок. Например, если внешний инструмент недоступен, должны быть инструкции, что ответить пользователю. Не отдать же ему Internal Server Error.

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

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

Мне еще нравится, что механизм может работать циклически, если запрос поэтапный. Например, «Найди отели в городе не ниже 4-х звезд». В этом случае нужно разбить запрос на 2 шага.
1) Сначала сделать инструкцию к API для получения текущей геопозиции.
2) Затем следующим шагом сформировать новую инструкцию к получению отелей текущего города по заданному фильтру.
И после чего агрегировать все предыдущие шаги и отдать пользователю красивый ответ. А пользователь в свою очередь может оставить комментарий (фидбек), и это отдается снова в LLM с учетом предыдущего вывода.

Кстати, по моим наблюдениям в Алисе возможность разбиения запроса на несколько этапов появилась недавно. Раньше я пробовал говорить «Алиса, включи подсветку и телевизор». Она не слушалась. Сейчас это работает, я доволен ❤️

Как ИИ улучшает ИИ
В конце июля вышла статья о том, как ИИ анализирует и модифицирует модели для обучения. Мотивация в том, что, хотя ученые в области ИИ придумывают новые прорывные (не всегда) архитектуры для улучшения качества, все равно человеческий фактор накладывает ограничения. Может быть, ИИ сумеет создать больше SOTA архитектур?

Признаюсь, надо напрячься для понимания, статья далась не легко. Я не прошарил все от А до Я, но вот некоторые основные компоненты системы (см. картинку):

🔹 Когнитивная база знаний
Из arxiv, papers with code, hugging face собираются статьи по теме и передаются в LLM для извлечения ключевых тезисов: цель статьи, алгоритм, сравнения с другими. Эти тезисы по каждой релевантной статье складываются в так называемую когнитивную базу. Они будут отправной точной при создании новых архитектур.

🔹 Researcher
Этот компонент (тоже LLM) берет из когнитивной базы тезисы, а также топ-50 лучших моделей с предыдущего шага. Причем не просто сырые результаты, а предварительно проанализированные, но об этом позже. И на основе этого генерирует код новой модели. Код проверяется на корректность и уникальность и может быть отправлен на доработку опять в LLM. Своего рода фидбек и работа над ошибками.

🔹 Engineer
Собственно, здесь новая архитектура обучается, проверяется на метрики. А метрик несколько: лосс, качество на бенчмарке и «судья» в лице LLM. Ее задача — оценить сложность, эффективность, новизну и выдать свой балл. Все это суммируется в один score.

🔹 Анализатор
Тут LLM должна проанализировать все результаты и выдать что-то типа отчета. Именно этот отчет будет использоваться Research-ом.

🤷‍♂️ Правда, по статье я не понял, разные ли во всех компонентах LLM-ки или все же одна? Вопрос открытый.

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

А если дать больше GPU?
Авторы показывают, что вся эта история масштабируема. Кол-во новых SOTA архитектур линейно растет с увеличением вычислительных ресурсов. А значит, дальше больше 🔥