Привет, Хабр! Меня зовут Ирина Николаева и я — руководитель R’n’D отдела машинного обучения в компании Raft Digital Solution. Я внедряла различные ML-модели: от анализа временных рядов и Computer Vision до высоконагруженных дата-инженерных сервисов.
Эта статья написана по мотивам моего доклада на Highload ++ 2023.
В статье вас ждёт: обзор LLM-моделей, техники работы с ними через призму MLOps, разбор лицензий и требований к железу. А так же трюки с квантизацией и файн-тюнингом «на сладкое».
Главный дисклеймер статьи в том, что данные лидербордов и технических требований актуальны на момент выступления на Highload, то есть ноябрь 2023, но не всё из них актуально до сих пор. Но если бы я обновила всю статью, была ли бы это та же самая статья — вопрос риторический, поэтому было принято решение оставить всё как есть.
Как вы помните, после первого релиза ChatGPT мир вокруг начал медленно, но верно меняться. IT сфера и здесь была быстрее и выше остальных.
Изменения коснулись и компании Raft, да таким образом, что мы сменили вектор развития с заказной разработки на внедрение искусственного интеллекта и машинного обучения. Общая популярность СhatGPT и других больших языковых моделей привнесла множество новых идей для продуктов, увеличила интерес к сфере искусственного интеллекта и привлекла много тысяч AI энтузиастов по всему миру.
Мы в компании начали путешествие в мир LLM с использования ChatGPT в наших продуктах, кроме прочих продуктов и моделей. Эту ветку продуктов мы также апдейтим и развиваем и по сей день. Кроме ChatGPt, мы также используем и open source LLM и даже сделали для этого целый R’n’D отдел.
Правда, качество на уровне GPT- 3.5 открытые модели научились покорять только в начале 24-го.
Давайте поподробнее взглянем на наши основные продукты, которые под капотом работают как на моделях OpenAI, так и на OpenSource решениях.
Первый продукт, о котором я расскажу — AudioInsights. Он помогает бизнесу повышать качество обслуживания клиентов и увеличивать конверсию продаж. В нём реализованы методы мониторинга и продвинутого анализа разговоров представителей компании (call center/линии поддержки) с клиентом, что помогает быстрее, дешевле и точнее проводить оценку качества работы с клиентами.
Преимущество AudioInsights в том, что он позволяет загружать в сервис записи call центра в формате MP-3 и не только. Это полезно для бизнеса, у которого уже есть голосовая поддержка или отдел прослушивания и контроля. С помощью AudioInsights вы сможете проверять качество работы call центра, собирать метрики и рассчитывать KPI быстрее и дешевле. Записей может быть много, как и метрик, и критериев для анализа. Согласитесь, что прослушивать весь этот массив «вручную» — долго, дорого и нудно. Под капотом это устроено так: используя модель и загружая в неё аудиозапись мы получим транскрибацию звонка с помощью voice-to-text модели. После чего, с помощью лучшего оптимального промпмта мы преобразовываем бизнес критерии в критерии для LLM и анализируем запись по описанным критериям.
В теории всеё выглядит просто и понятно, но есть и особенности, которые мы успели постингуть за время разработки оптимального решения. Одна из особенностей — это бинарные критерии для LLM — так проще, понятнее, детерминированее поэтому и результаты получаются лучше.
У нас есть версия, которая базируется на API ChatGPT. Это решение отлично работает и даёт нам лучшую точность из всех моделей. Но, если вам хочется работать с чувствительными данными или у вас большая нагрзука на сервис, то ChatGPT либо вообще не стоит использовать, либо использование этой модели становится достаточно дорогим. В этом мы можем убедиться на графике зависимости цены от количества запросов.
В этом случае и приходит на помощь Open Source — LLama и её альтернативы.
Следующим продуктом является LLM Data Protector. Он мне особенно нравится, так как позволяет обезопасить бизнес от потенциальных атак пользователя и от выдачи нежелательной чувствительной информации (такой, как персональные данные, например). Если есть большие языковые модели, то есть и люди, которые их взламывают.
Им нужно, например, чтобы большая языковая модель отдавала секретные данные, заложенные в неё бизнесом и/ или разработчиками или случайно из-за засорения больших данных, на которых она обучалась — такое часто бывает с LLM. Обезопаситься можно разными способами — более подробно о них можно узнать в телеграм канале нашего Head of AI Евгения Кокуйкина — https://t.me/kokuykin, и в его статье на Хабр.
Если возвращаться к примерам, то некоторое время назад на рынок LLM выходила сетка Bloom, которая выдавала непотребства, которые даже послужили причиной временного закрытия модели. Так вот, главная фича LLM Data Protector — это защита бизнеса, применяющего различные LLM (ChatGPT в том числе) в своих решениях от казусов слива данных и получения доступа к модели.
В этой статье мы с вами смотрим на текущее положение LLM через призму MlOps — нам нужна некоторая система сравнения, поскольку иначе мы утонем в море информации и обилии моделей.
Но перед тем как перейти непосредственно к LLM, давайте вспомним базовую схему жизненного цикла любой ML модели и порефлексируем над тем, как она изменилась (и изменилась ли вообще) с приходом Large Language Models.
Более подробно схема описана в данной статье, я же остановлюсь только на нескольких интересующих нас шагах. А именно — на инференсе модели. На этапе инференса мы предполагаем, что у нас уже есть архитектура модели, файлы весов, и мы можем её захостить и использовать как запрогал её ваш DS душа пожелает. Инференсов на схеме много, хотя главный пайплайн — один. Преимущество в том, что мы можем инференсить сразу на разных устройствах и в параллель.
Важная тема о которой бы хотелось поговорить — это использование LLM. Давайте попробуем определить пулл задач, где использование столь больших моделей (при условии оплаты за инференс и получении хороших результатов) оправдано, а где лучше пойти в классические подходы и модели.
Сейчас LLM на волне хайпа, что привлекает большое количество людей в Data Science — это круто! Но, если вы решаете одну или две классические задачи, то использовать для этого ChatGPT возможно не очень оптимально (но кто же вам запретит).
Смотрите, если мы идём по пути стандартной классической old but gold модели классификатора, например, и собственноручно её дизайним и обучаем — платим за часы DS, если идём с решением LLM — тоже платим, но уже за хостинг LLM. Из плюсов классики — возможность работать с выходом модели, видоизменять его и дообучать саму модель пока не станет хорошо.
Отдельная история — это воспроизводимость результата. Если это мегаважно в текущей задаче, тут у LLM из коробки (без дообучения) тоже встречаются проблемы. И спасет либо дообучение, либо добавление в пайплайн классической модели, либо полное следование классическому подходу.
Использовать LLM стоит в задачах генерации, саммаризации и анализа текстов — поскольку в этом их главная килл фича. Используем API based LLM, когда необходим быстрый результат без длительного дообучения.
Общение с пользователями однозначно стоит переложить на плечи LLM. Это могут быть различные чат-боты, голосовые боты и др. Можно также вести блог, в котором текст будет генерироваться большой языковой моделью. Ведь при обучении использовали human feedback, поэтому писать текст она будет вполне «по-человечески». А ещё можно сделать дополнительные настройки — например, попросить использовать деловой стиль или, наоборот, ставить смайлики в конце каждого предложения.
Все модели делятся на открытые и закрытые.
Проприетарные модели: Antropic, Yandex Gpt-2, Gigachat, Grok от X.
Открытые модели: LLama 2, ruGPT, Mistral, Falcon.
Как понять какую модель вам нужно использовать: открытую или закрытую? Для этого нужно определить, насколько вам важна безопасность, хотите ли вы хостить решение в своем ЦОДе, ну и насколько модель хороша в решении именно вашей задачи в вашей доменной области.
Модели отличаются дата-сетами, на которых обучались, методиками обучения, архитектурой и другими параметрами. Чтобы подхватиь общее видение последних лидеров рынка LLM для вашего домена, можно воспользоваться открытыми бенчмарками и лидербордами.
Например:
1. huggingface_open_llm_leaderboard
2. Chatbot Arena Leaderboard
Но важно помнить, что не все бенчмарки можно воспроизвести. Поэтому слепо полагаться только на бенчмарк нельзя. Я советую выделить несколько LLM — например, минимум три или четыре, и посмотреть на практике, поставив эксперимент и получив результаты.
Про выбор модели и бенчи узнали — самое время узнать про хостинг моделей, но до хостинга есть важный юридический аспект лицензирования LLM.
На данный момент для open source существует несколько типов лицензий, которые различаются политиками использования. Стоит как минимум знать про существование оных, поскольку это может сильно сберечь энергию, время и, скорее всего, деньги вашему стартапу c LLM.
Вернёмся к модели с открытой лицензией Llama. У Llama 2 есть три версии: 7В, 13В и самая большая 70В. Циферка рядом с буквой говорит о том, насколько большая модель, на дата-сете какого размера была обучена, и как много знает. Таким образом, Llama 2 70B знает больше всех. Но чем больше модель, тем больше ресурсов нужно, чтобы её захостить. Обычно мы используем для этого сервер с четырьмя видео-картами Nvidia А100.
На картинке выше вы также можете увидеть сколько часов эти модели обучались, и примерно просчитать стоимость дообучения каждой из них.
Чтобы использовать полную версию Llama 2 70B, нам, например, не хватило четырёх видеокарт А100 по 40 гигабайт. Для этой модели нужно очень много памяти, ведь почти 80% уходит на то, чтобы просто загрузить веса, содержащие градиенты и другие артефакты, которые модель приобрела в процессе обучения. Поэтому, если мы хотим загрузить контекст больше 2000 токенов, то модель выходит за пределы памяти.
Из-за текущей стоимости видеокарт стоимость дообучения и инференса ‘ванильных’ полных моделей высокая, но всегда и везде приходят методы оптимизация и всяческого сжатия моделей до обучения, после обучения, фильтрации слоев и прочего. Посмотрим, что же применяют к LLM.
Запятую предлагаю каждому поставить самостоятельно — так как методы оптимизации чаще подают под соусом ‘мы не теряем качество’ или ‘теряем очень мало информации — она все равно была не нужна’, но так ли это на самом деле?
Давайте взглянем на святая святых — квантизацию весов. Она относится к методу оптимизации весов уже после обучения, и это прекрасно подходит LLM поскольку финальные веса и архитектура — часто всё, что нам доступно.
Это достаточно простой, но интересный трюк. Работа всех сеток базируется на матрицах и операциях свёртки либо перемножении и сложении матриц.
По умолчанию используется тип float-32, который покрывает около 4 миллиардов чисел в интервале [-3.4e38, 3.40e38]. Но нужно ли нам так много? Предлагаю рассмотреть стандартный вариант квантизации — квантоваться в int-8. Это значит, что мы берём и сжимаем весь наш четырехмиллионный диапазон float-32 в 256 значений int-8.
Без маппинга значений здесь не обойтись, но как сделать хорошее отображение из множества весов в float-32 в множество весов в Int-8, с минимальной потерей информации?
На самом деле, веса моделей имеют нормальное распределение (почему). Поэтому уровни в желаемом множестве Int-8 мы будем выделять исходя из нормального распределения: чем больше значений в диапазоне, тем больше уровней мы выделяем.
На картинке ниже можно наглядно взглянуть на разные алгоритмы квантизации и те самые уровни:
Квантизация пришла к нам из Computer Vision, но с приходом LLM и их больших размеров появились новые алгоритмы, например double quantization, а Microsoft вообще квантанули модель в int 1.
Вспомним опять же про парадигму MlOps — в случае LLM на смену обычному обучению from scratch приходит повсеместное доообучение модели, в простонародье, fine-tuning. State of the art (SOTA) файн-тюнинга, на данный момент, — это PEFT (Parameter-Efficient Fine-Tuning).
Это множество методов дообучения, некоторые из которых мы давно используем и они максимально просты для понимания — например, Prompt-tuning. Какие-то из них безумно популярны сейчас — LoRA, какие-то используют далеко не все — привет, AttentionFusion. Скорее всего, если вы сталкивались с файнтюнингом в статьях или репозиториях, то это была LoRA или QLoRA. А снискали они своё частое использование в связи с тем, что позволяют достаточно быстро дообучить модели, используя подход с адаптерами и уменьшением ранга. Давайте смотреть!
Итак, LoRA расшифровывается как low rank adaptation. На вход подается W — матрица наших изначальных весов и замораживается — в ней мы пока ничего не обновляем. Затем во время дообучения мы хотим докидывать новую информацию, то есть матрицу новых весов W и суммировать её со старой. Суть метода в том, чтобы снизить размерность матрицы W путём перехода к матрице меньшего ранга (почему так можно), и работать впоследствии уже только с ней. То есть самые ресурсозатратные операции во время дообучения мы будем производить снизив размерность, а потом сделав обратное преобразование перейдём назад к размерности матрицы W, сложим значения матриц W + W (старая и новая информация), и получим новый красивый output.
Q-LoRA — это LoRA только с квантизацией в int-4. Это классная фича, которая позволяет запускать LLM на MAC или компьютере с CPU. Только вот время ответа и контекст во время диалога на практике сильно падает. Поэтому я бы советовала не квантоваться в int-4, а начать с больших размерностей.
После выбора модели, её возможной квантизации и дообучения встаёт вопрос о разворачивании самой модели и envirpment’а вокруг неё. На данный момент существует несколько проверенных связок, которые дают хорошие результаты и зарекомендовали себя на продакшн уровне.
Первое, что хочется отметить здесь — это векторные базы данных. Они оперируют эмбедингами или векторными представлениями слов, что ускоряет поиск по базе и оптимизирует хранение большого датасета.
Векторное представление слов — это трансформация текста, картинки или аудио в вектор. Размерность вектора зависит от вашей задачи и модели для эмбединга.
Если вас не устраивает размерность получившейся базы, можно посмотреть про снижение размерности и PCA. Если ваши эмбединги плохо различаются и путаются, советую присмотреться к использованию Triplet Loss’a в вашей эмбединг модели.
Существующие векторные БД:
Pinecone, Weaviate, Qdrant, Milvus, Vespa
MongoDB, Cassandra, PostgreSQL и SingleStore
LangChain – это фреймворк для разработки AI решений. Он содержит в себе всё, что нужно: модели, которые можно выбрать под свой запрос, шаблоны для промптов, индексацию по документам. В LangChain также есть реализация памяти и чейны, что делает его хорошим инструментом для беглой разработки прототипа.
Подытожив всю новую информацию пришёл черёд взглянуть на неё с позиции жизненного цикла модели. Можно заметить, как некоторые из его шагов, немного видоизменились: вместо обучения модели с нуля в случае LLM у нас выступает файн-тюнинг, которого на данный момент более, чем достаточно, тестирование моделей сейчас не обходится с помощью human evaluation, что раньше не всегда было нужно, ну а инференс стал требовать бОльших ресурсов и обязательной оптимизации.
Давайте смотреть вместе, что же ещё изменят LLM в привычных процессах машинного обучения!