Алиса 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 будет использовать в этих доменах выгоднее.

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

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

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

WO

Буквально вот-вот я отвёл свою последнюю техническую секцию в рамках Weekend Offer ML (WO). Я проходил много собеседований в разные компании, в том числе по подобным программам и мне всегда было интересно: а как по ту сторону 👨‍🦳.

Обычно у меня 1 секция в 1-2 недели, т.к. много коммуникации и без этого. А тут сразу несколько и в один день с небольшим перерывом. Эмоционально это истощает: нужно стараться помочь каждому человеку раскрыться по полной. Но, в целом, всё хорошо, надеюсь и ребята остались довольны после собеседований 😍.

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

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

Когда я собеседовался 3 года назад, у меня было 5 технических секций. И это ни на какого-то "синьор принципал стаффа", а просто по дефолту. Были дублирующие секции на алгосики, сам процесс был растянут адски долго. Вот сейчас (на моей памяти полгода точно) как будто бы стало сильно лучше: максимум 3 технических секций, никакого дублирования, есть материалы для подготовки. Помню, как сам ходил на несколько встреч, где пытался аргументировать, что много секций — ну это так себе история, особенно как это было. WO для меня стал каким-то откровением, каким-то еще одним шагом к тому, как можно упрощать найм (и не только себе, но и кандидатам) 😍.

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