Машинное обучение в продуктовой разработке, где его не ожидают

Базовые подходы и подводные камни

Меня зовут Яхья Ибрагимов. С 2017 года я занимаюсь машинным обучением — успел поработать дата-сайентистом и уже несколько лет как ушёл в управление. Сейчас я Product owner  «Атом.Око» в компании Гринатом. «Атом.Око» – это IDP система для извлечения текстовых/рукописных/табличных полей из документа,  использующая ML и предназначенная для развертывания внутри контура заказчика, не требуя обязательного наличия GPU.  В моей командой более 40 человек: бэкендеры, фронты, ML-инженеры, дизайнеры, QA и много кто ещё. Сегодня я расскажу, как применять ML в продукте с пользой, не тратя на это вагон золота и сотни GPU. Ну а еще хочу попросить вас принять участие в опросе, если ваша сфера деятельности связана с машинным обучением (опрос в конце статьи).

Проблема вычислительных мощностей

Начнем со статистики. Ниже приведу графики сложности обучения из 2024 AI Index Report:

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

Представьте, что вы решаете арифметическую задачу (График  А на картинке). По условиям есть одна видеокарта уровня Nvidia А100 за ~5-10 миллионов рублей. Чтобы получить первые реальные результаты решения этой задачи с помощью больших языковых моделей, придётся подождать “всего лишь” 10 лет! Возможно, потомки и поблагодарят вас за неё, но более вероятно, что к тому времени она уже никому не будет нужна. И если вам это не подходит, то придётся докупить ещё несколько видеокарт по пять-десять миллионов. Или ещё дороже.

Как нетрудно догадаться, в ЦОДах у не IT-компаний видеокарт зачастую нет. И даже если вы разработаете хоть сколько-нибудь серьёзную модель (>5B параметров), то скорее всего, запускать её придётся у заказчика на CPU. Именно поэтому соотношение «сложность инференса / точность» — основополагающее.

Проблема стоимости обучения

В стоимость обучения больших языковых моделей входит аренда ускорителей (если, конечно, вы не хотите потратиться ещё и на закупку) на время обучения модели, аренда площадей и времени на разработку. GPT-4, например, обучалась «всего лишь» за 78 миллионов долларов, а Gemini Ultra — за 190 миллионов.

Более того, при обучении затрачивается очень много энергии. Например, на ChatGPT-3 потратили более 1200 МВт/ч энергии (а сколько было затрачено на Grok3?). Это равносильно часу работы всей Курской АЭС. Представьте, что 0,5% всей электрогенерации в стране выделили для обучения одной нейросети. А если перед таким запуском допустить ошибку и взять валидационные данные из тренировочной выборки?

Достаточно сложно представить отдельный продукт или проект, особенно standalone, который в таком случае окупится и принесёт пользу (особенно на нашем рынке). А бизнес хочет именно standalone! Бизнес не хочет, чтобы его данные обрабатывались «где-то там», но арендовать дорогостоящие сервера с GPU под подобные продукты тоже не хочет. Сумма выйдет такой, что дешевле будет нанять людей на удалёнку из регионов, чтобы они решали задачу “по-старинке”. Стандартный потолок — кластер лишь из CPU машин.

Когда ML стоит того

Несмотря на все описанные выше пугающие факторы, прелесть машинного обучения в том, что собрать прототип, выполняющий базовые функции и задачи, практически ничего не стоит. Вы просто скачиваете Open Source библиотеку и запускаете обучение на своих данных. При этом можно использовать базовую GPU или даже CPU. Тестируете — и MVP готов. Затраты только на зарплату разработчику. Я называю это «первый раз — бесплатно».

Тогда к чему был весь раздел, спросите вы? Да к тому, что вокруг LLM свет клином не сошёлся. Если вы ранее не внедряли у себя машинное обучение, то с вероятностью 99,9%, часть ваших проблем получится решить с помощью более простых, «классических» алгоритмов машинного обучения, для запуска которых не нужно собирать отдельный кластер видеокарт.

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

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

Самостоятельное обучение или Open Source

Первое, с чем стоит разобраться при внедрении ИИ в продукт — будете ли вы обучать модель сами или возьмёте Open Source-решение.

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

Если же вы решили использовать собственную модель, то вам понадобятся деньги и время. Не так много денег и времени, как приведено выше, но вложиться придётся. Поэтому лучше всего выбрать золотую середину. То есть использовать pre-trained Open Source, чтобы дообучить её с учётом своей специфики и уникальных данных. Так вы сэкономите деньги и получите более конкурентоспособный продукт.

Важно!

●      Используя Open Source, обязательно смотрите на лицензии. Бывает, что они запрещают зарабатывать деньги на Open Source-based решении.

●      Если вы тренируете модель самостоятельно, вам понадобятся данные. При обучении нейросети, до 95% успеха зависит от качества и количества данных, на которых вы её обучаете.

●      А ещё внимательно следите за историей изменений новых библиотек и моделей, чтобы туда не проскочило то, чего вы не хотите.

Разметка

Чтобы обучать нейросеть или другой алгоритм машинного обучения, нужна обучающая выборка.

В интернете много открытых датасетов, но они обычно покрывают лишь часть ваших задач. А вот специфических датасетов, которые нужны под вашу конкретную цель, скорее всего, нет. Если вы не занимаетесь поиском заболеваний на рентгеновских снимках лёгких, не пытаетесь предсказать цену домов или не делаете ещё что-то «классическое» то у вас, скорее всего, возникнут проблемы с поиском данных для обучения.

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

Всё это означает, что датасет придётся создавать самостоятельно: с помощью армии нанятых разметчиков или синтетики. У продукта Атом.ОКО 20 разметчиков, что составляет примерно 50% от общего размера команды. Почему так много? — из-за учёта субъективности человеческой оценки.

Вот пример из другой нашей системы «Мой голос»: она группирует текстовые ответы пользователей по смыслу. Допустим, группе людей задали вопрос: «Как прошел ваш день?». Часть людей ответила «хорошо», а другая часть — «отлично». Для кого-то эти ответы будут синонимами, а для кого-то — нет. Именно поэтому и нужно «много глаз»: ваши датасеты будут лишены фактора субъективности, иначе есть риск переноса в модель образа мышления одного человека.

Естественно, сама разметка данных — достаточно длительный процесс, который может занять, без шуток, месяцы и годы. Поэтому, в идеале, ещё до найма дата-сайентистов у вас должен быть запущен процесс разметки данных. В рамках Атом.ОКО мы разрабатываем систему, которая при обращении к скану документа позволяет пользователям задавать вопрос на русском языке. Например, «Кто отправитель?» или «Кто получатель данного письма?». Система должна найти ответ в документе и вернуть его пользователю. У нас большой объем документооборота, и даже несмотря на то, что 15 из 20 разметчиков были заняты на этой задаче, разметка датасета заняла более трёх месяцев.

Если вы решились размечать данные самостоятельно, то мы рекомендуем labelme. Это Open Source продукт, который можно развернуть на своих серверах и в интерактивном формате размечать данные. Разметчики не всегда разбираются в технике, поэтому удобный веб-интерфейс поможет ускорить процесс и улучшить качество результата.

Метрики

Представим ситуацию, что вы создали OCR-сервис по оцифровке документации. Чтобы понимать, о чём говорить с заказчиком, вы замерили скорость и получили 8 секунд на один лист, содержащий в себе 5 объектов (допустим, абзацев). Это хороший результат, но на сервере заказчика это может занять, например, 12 секунд для тех же 5 объектов. А если объектов 50, то разница получится ещё больше. А это уже срыв контракта и судебные издержки.

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

В нашей системе «Мой голос» два контура для обработки ответов. Один сервер на нашем внутреннем ЦОДе — для внутренних клиентов, чтобы ничего не улетало за пределы. А другой сервер — снаружи — для внешних клиентов. Разница по времени группировки ответов по смыслу (см. выше) в таблице — примерно в три раза. Причина довольно проста — CPU на наших серверах оказался на три года моложе.

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

Поэтому, перед выводом продукта с ИИ на внешний рынок, обязательно стоит собрать метрики. Это тестирование на разных конфигурациях CPU, возможно, даже на разных платформах и операционных системах, если у вас кроссплатформенный продукт. Но самое главное — тестировать нужно на железе вашего клиента. Также важно учитывать фактор разных контуров. Например, системы безопасности тормозят общий процесс, чтобы проверять трафик и расчёты, производимые на ядрах. Это тоже может внести большой вклад в уменьшение скорости. Если у вас есть хотя бы демо-образец продукта, который даже не полностью удовлетворяет клиента, то с его помощью вы сможете понять скорость работы на стороне заказчика. И лучше бы, чтобы эти метрики скорости были собраны раньше, чем вы пожмёте руки.

Тиражирование моделей

У нас есть два продукта:

1. Атом.ОКО, про который я уже рассказал — оцифровка документов, OCR.

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

И у нас есть две модели, которые делают следующее:

1. Оцифровка документации для Атом.ОКО.

2. Составление краткого содержания, которое разрабатывалось для Атом.Поиска.

Единожды разработав суммаризатор для составления краткого содержания, мы можем использовать его и в Атом.Поиске и в Атом.ОКО. Если общий пайплайн разработки продуктов идентичен: у них один стек, языки, процессы и сборка на одном GitLab, то интеграция модели, разработанной для одного продукта, в другом будет практически бесплатной. Вы просто напишите import… и всё. Это также позволит равномерно распределить затраты на обучение модели. Ну или для второго продукта модель будет просто бесплатной.

Версионирование моделей

Давайте представим, что собираемся обучаться на своих исходных данных. Проводим MVP эксперимент и получаем на выходе модель. Заказчик просит доработать её с помощью дополнительных данных, которые помогут модели решать его задачу более эффективно. Так у вас уже есть два датасета. На основе датасета заказчика вы получаете новую модель и дополнительные идеи, как её улучшить. Показываете заказчику, а он снова даёт датасет и просит доработать. А ведь у нас всё ещё проходят эксперименты на первом датасете, и там тоже получаются результаты и появляются другие заказчики! В итоге всё превращается в кашу.

Чтобы избежать этой мешанины из моделей и датасетов, мы используем версионирование моделей. Open-source инструмент DVC (Data Version Control) позволяет хранить результаты экспериментов в структурированном виде: версии моделей, целевые метрики, показатели, ссылки на данные и так далее.

Вывод

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

Самое главное — не ждать, что ИИ выполнит всю работу за вас. Он лишь помощник, который будет работать так, как вы ему сказали.

P.S: Я провожу исследование, связанное с анализом сложности решения различных ML-задач. Если вы связаны с машинным обучением (менеджер, team lead, разработчик) — буду очень благодарен, если вы его пройдете. Там 1 раздел с общими вопросами и 11 профильных. Вот ссылка. Большое спасибо!