5-9 трёхдневки в Стратоплане

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

Для тех, кто не в курсе или подзабыл: я учусь быть руководителем лучше в школе Стратоплан. Прошлые серии можете почитать здесь: первая, вторая, третья, четвёртая.

5ый модуль
Здесь мы говорили про инструменты управления командой. Смотрели на разные модели категоризации людей (Ленсиони, Адизеса, Белбина). Модель Адизеса мне была уже известна очень давно, Белбин показался интересным с точки зрения формирование климата в команде. А также рассаматривали, как сохранять вовлечённость, как работать с разным перфоманосом, как делать PIP, давать обратную связь по перфомансу.

6ой модуль
Классный модель про то, как именно ставить задачи и рулить процессами. Разговаривали про то, как нужно погружать людей в задачи, какой тип контороля нужно использовать исходя из понимания человеком области. Много говорили про методологии ведения проектов. Если в методологиях следить за метриками — и правда может быть толково их использовать в зависимости от ситуаиции.

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

8ой модуль
Один из сложных модулей всего курса. Разговаривали про то, как дистрибуцировать изменения в командах и по всей компании. Разбирали модель Коттера и ADKAR. Говорили про майндсет, и что оказывается он бывает очень разный и каждый нужно развивать.

9ый модуль
Закончился буквально вот-вот. Учились принимать решения: самостоятельные, с помощью команды. Смотрели на такие инструменты, как мозговой штурм, Pre-Mortem (очень топ, рекомендую). Разговаривали про зоны отвественности на примере RACI, а также про самоиндетичность. Вышел очень душевный модуль, с большим количеством рефлексии.

Итог: кратко — это 🌿. И даже для тех, кто управляет командами уже много-много лет.

Подробнее: уверен, что 80% я уже если не забыл, то плохо помню. Это и не проблема: явно не каждый день ты смотришь на модель Такмана, внедряешь крупные изменения по Коттеру, пытаешься расписать DISC. Главное, что ты помнишь, что это можно использовать.

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

Как же я заебался

Знакомо? Часто такое бывает? Расскажу, что я делаю в таких случаях. Не инструкция, просто то, что мне помогает 😍.

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

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

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

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

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

А что вам помогает справиться с тяжелыми буднями? Буду рад почитать ваши истории 😍!

Утро понедельника начинается с неожиданного пакета мерча от Y&&Y.

Это что, я теперь снова стажёр?😀

llm-as-a-judge

Ни для кого не секрет, что LLM достаточно часто использую в качестве судьи. Это очень удобно: можно оценивать произвольный вход, делать бинарные или численные оценки, просить LLMку объяснить своё решение. Но есть и нюансики 👨‍🦳. 

Зачастую, когда мы только начинаем разрабатывать бенчмарки, то судьи выдают качество 60-70%. Это крайне низкое качество, с которым замеряться нет смысла. Это ни плохо, ни хорошо — просто факт. 

Из опыта хороший судья — дообученная LLMка на задачу оценки 🤓. Да, конечно, можно запромптить модель, и если у неё OOD +- ок, то вероятно, промпт поможет выжать качество до 90%+. Но ни разу не видел качество выше 95%, что может быть критично для маленьких бенчей (где доверительный интервал супер широкий). 

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

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

Потому я предпочитают рядом с llm-as-a-judge держать какую-то dummy метрику, которая является градусником 🤨. Она не не показывает действительную картину, но является неплохой апроксимацией. Например, когда нужно в тексте что-то проверить, то можно написать dummy парсер и сравнивать ANLS. Будет работать криво/косо, но работать. Главное чтобы метрика корреллировала с судьёй.

В этом случае появляется отличный градусник, который показывает, что судья-то ненастоящий 🏥!

А что вы думаете про LLM-оценщиков?

Алиса AI

У нас сегодня мега крупный запуск 🤔. Мы представили нашего обновлённого ассистента и семейство моделей, сидящих под капотом!

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

Все новшества и улучшения сложно описать в посте, да и не нужно.

Всё есть на лендосе здесь — https://alice.yandex.ru/about!

Ну и давайте накидаем тут 🔥, мы все очень сильно старались!

LaTeX и ентот ваш produnction

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

Давеча я просматривал ML Party в Белграде, и наткнулся на упоминания себя примерно здесь: https://www.youtube.com/watch?v=b4p38qdguis&t=2141s (таймкод важен). И могло показаться, что я разломал прод 👨‍🦳! И да, и нет — давайте разбираться. Спойлер — меня ещё не уволили 😀

Важная ремарка: хоть и в ролике говорится про "меня", но на самом деле идёт речь про нашу команду. Я, конечно, ещё достаточно много чего делаю своими руками, но куда больше и значительнее делают ребята!

В действительности, в определённый момент мы готовы были выкатить модельку в прод. Как и полагается, покатили на тестовый стенд и получили безумие! И это подтверждает некоторые байки о кровавом produnction (олды помнят).

Дело обстояло так: мы всё отлаживали в одной поверхности (и тестировали, и людьми смотрели) — всё было хорошо. Какого было наше удивление, когда всё разломалось в другой поверхности. И сначала, конечно же, гнали на то, что с моделью как-то не так, и она вообще какая-то не такая. Но на самом деле, всё немного на так 😊.

Представим себе, что у вас есть множество фронтендов: пару приложений (а на самом деле больше), несколько веб-поверхностей, ещё что-нибудь в придачу. Вы, конечно, можете с помощью системного промпта придумать, как удовлетворять формату каждого фронтенда, но в реальности — это безумие! Я просто даже не хочу писать про то, какой ад с тестированием начнётся, сколько всего вам нужно будет перепроверять, каждый раз переобучая модель 🔥.

Другой разговор, когда у вас всё же модель отдаёт единый формат. И каждый фронтенд разбирает по-своему то, что ему прислал бекенд (в нашем случае модель), исходя из своих правил. У вас есть большой плюс с точки зрения обучения модели: нужно тестировать только один формат, а не большое множество. В нашем случае так и оказалось — нужно было сделать некоторые правки в парсинге и всё встало на свои места 🤨.

"Кровавость" produnction'а в большей части состоит из таких моментов. Ты приходишь со своим ноу-хау в большую систему и нужно учесть иногда то, что ты даже не знаешь 🏥. И вот сколько вещей получится узнать — большую роль имеет опыт, насмотренность на системы, когда на уровне интуиции имеешь представление, что может пойти не так.

Think in Math. Write in Code.

Совершенно случайно наткнулся на классную статью про стиль мышления: https://www.jmeiners.com/think-in-math/

О чём там речь?

Автор рассуждает про то, что мы часто, как программисты 🤓, мыслим "абстракциями кода", что ограничивает нас. Дело в том, что абстракции в разработке — это какого-то рода сокрытие внутрянки, предоставление каких-то интерфейсов, а-ля black box. И это правда нам нужно, иначе мы не сможем проектировать сложные системы.

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

Лучше же думать в терминах "математических абстракций", т.к. там эта сущность не про сокрытие, а про "взгляд на". Как пример, функцию мы можем записать в виде уравнения, отобразить графиком, представить в виде списка/таблицы точек. Мы выбираем взгляд на одно и тоже под разными углами, чтобы найти решение самой задачи 🌿.

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

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

А как у меня?

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

Сейчас я часто стараюсь думать именно абстракциями в математическом смысле. Например, если взять картинки для VLM, я часто думаю про:
— то, что должно быть на таких картинках (домены, подзадачи);
— распределения по таргетам, источникам, размерам;
— какие есть инварианты и т.д.

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

А что вы думаете про это? Какое мышление у вас?

Побубню за OCR

Тут у нас в CVTime вышел обзор DeepSeek-OCR в двух частях (раз, два), где задали интересный вопрос, на который я хочу попробовать развёрнуто подискутировать:

Нужно полный а4 лист текста прочитать за 1 секунду. Справится ? И чтобы не арендовать для этого суперкомпьютер, а например видюху уровня TESLAV100. Сомневаюсь. Даже обычные OCR работают очень долго - десятки или сотни миллисекунд. А LLM ки в продакшене для высоконагруженных систем, такое себе, если конечно вы не амазон или не гугл с бесконечными ресурсами

За последнее время понимание OCR сильно изменилось 😊: если раньше мы воспринимали этот процесс как извлечение текста и метаинформации о нём, то сейчас в основном это Image -> Markdown или KIE (Key Information Extraction). И конечно от тех, кто не погружен в область, достаточно часто можно услышать: а зачем нам ваш Paddle OCR или Yandex OCR, когда у меня есть замечательный Alice AI VLM/QWEN-VL/DeepSeek-OCR/Mistral OCR. Особенно это актуально в тех случаях, когда open-source классические системы проигрывают по качеству VLM.

Другой лагерь не про качество, а про скорость: "Да ентот ваш VLM жрёт знаете сколько? А работает долго! Пользователи не привыкли ждать! Особенно в такой простой задаче. А еще и мету отдавать не умеет." Обычно этот лагерь состоит из ребят, которые уже применяли OCR и что-то про него знают.

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

Что у вас на выходе?
Выписать текст в виде markdown будет проще с помощью VLM — этот формат "нативнее" на мультимодальных сеток, нежели чем для OCR-системы. Post-processing результатов OCR для вывода в MD — это достаточно непростая инженерная задача.

Но если вам вдруг нужны координаты, например, для задачи фотоперевода, где важно на картинке поверх текущего текста наложить рендер переведенного текста, то здесь перспективнее использовать OCR. Хоть и куча бенчей, где VLM хороши в Grounding, но я пока еще не видел хорошей текстовой локализации в мультимодальности.

Что у вас на входе?
Одно дело PDF-странички классических arxiv-like статей, другое дело — всевозможно по-разному расположенный текст на картинке. В этом случае вывод в MD для OCR становится очень тяжелой задачей , тогда как для VLM это вопрос максимум небольшого тюна.

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

Что с качеством?
В проприетарной среде не всё так однозначно, но если говорим про open-source, то VLM однозначно по качеству извелечения текста будут в среднем выше. Думаю, тут не стоит объяснять, что на мультимодальные модели тратится существенно больше компьюта, нежели чем на OCR.

Если говорить про пример выше?
Если говорим про домен из примера выше, что на A4 (условно статья arxiv) качество у VLM и OCR будет +- одинаковым, при этом OCR будет кратно быстрее и дешевле. Но если это будут A4 странички каких-будь буклетов, менюшек, постеров, то вероятно VLM будет использовать в этих доменах выгоднее.

Когда к нам внутри приходят ребята из разных команд, как раз наша задача проконсультировать их, как решать им задачу эффективнее: с точки зрения денег (стоимость разработки, стоимость компьюта), с точки зрения качества (смотрим на домены, оцениваем качество). И не всегда всё упирается в стоимость компьюта... Как-то так.

Расскажите, как у вас на практике с распознаванием текста? Для чего используете? Чего используете?

В одном публичном канале недавно как раз наблюдал 😀