Введение в настройку LLM
В последние годы быстрый прогресс в области искусственного интеллекта привел к разработке больших языковых моделей (LLMs), революционизировав область обработки естественного языка (NLP). Эти мощные модели, такие как ChatGPT, Llama, Mistral, Zephyr и другие, продемонстрировали превосходные возможности в понимании и генерации человекоподобного языка.
Однако у этих LLM есть ограничения. Они обучаются на большом объеме данных с определенной датой отсечения, а это означает, что если мы используем их для генерации ответов, требующих знаний, более новых, чем их обучающие данные, мы рискуем получить неточные ответы. Поэтому крайне важно адаптировать эти модели к нашим конкретным задачам и предметным областям, чтобы раскрыть их полный потенциал. Именно здесь в игру вступает настройка LLM.
На недавнем Zilliz Unstructured Data Meetup в Сиэтле CEO OSS4AI и бывший Senior Developer Advocate в Zilliz Yujian Tang обсудил несколько вариантов настройки LLM для повышения их производительности в конкретных задачах. Прежде чем обсуждать различные варианты настройки LLM, давайте кратко рассмотрим историю LLM.
Посмотрите запись выступления Yujian
Краткая история LLM
Исследования, приведшие к появлению LLM, прошли долгий путь, начиная с базовой архитектуры нейронной сети. Базовый слой нейронной сети состоит из входного слоя, одного или нескольких скрытых слоев и выходного слоя, как показано на графике ниже.
Архитектура нейронной сети
Базовая архитектура нейронной сети оказалась очень мощной для задач классификации и может обрабатывать неструктурированные данные, такие как тексты и изображения. Однако она неэффективна для задач, требующих долгосрочных зависимостей или последовательной обработки, что важно для задач естественного языка. В базовых нейронных сетях каждый вход обрабатывается независимо, а выход генерируется исключительно на основе текущего входа. Это означает, что нейронные сети не учитывают порядок или контекст входных данных относительно всей последовательности.
Без способности обрабатывать долгосрочные зависимости нейронная сеть не может вывести семантический смысл всей входной последовательности или текста — появление рекуррентных нейронных сетей (RNNs) было направлено на решение этой проблемы.
RNN решают эту проблему, вводя скрытое состояние, которое действует как память, фиксирующая информацию о том, что сеть видела ранее. Это скрытое состояние передается от одного временного шага к следующему, позволяя сети поддерживать представление последовательности. Добавление скрытого состояния позволяет RNN избирательно запоминать или забывать информацию из входной последовательности, делая их более эффективными для зависимостей входных последовательностей, чем базовые нейронные сети.
Архитектура RNN
Однако у RNN также есть несколько ограничений, таких как:
Проблема исчезающего градиента: RNN страдают от проблемы исчезающего градиента, когда градиенты, используемые для обновления параметров модели во время обучения, становятся меньше по мере их обратного распространения во времени. Эта проблема затрудняет для RNN обучение долгосрочным зависимостям в последовательностях.
Последовательная обработка: RNN обрабатывают последовательности последовательно, что ограничивает их способность распараллеливать вычисления и делает их менее вычислительно эффективными.
Эти ограничения RNN привели к разработке Transformer, который использует механизм self-attention для параллельной обработки входных последовательностей и предотвращения проблемы исчезающего градиента.
Архитектура Transformer
Архитектура Transformer состоит из нескольких блоков encoder и decoder. Каждый блок encoder и decoder содержит специальный слой, называемый слоем внимания. Этот слой играет ключевую роль в определении семантического значения каждого токена относительно всей входной последовательности. Например, рассмотрим следующие три предложения:
Apple получила прибыль в размере $97 миллиардов в 2023 году
Мне нравится есть яблочный пирог ради прибыли в 2023 году
Итоговая прибыль Apple увеличилась на рекордные значения в 2023 году
Если мы используем только традиционный подход, например подход на основе ключевых слов, первые два предложения будут самой похожей парой. Мы нашли три похожих ключевых слова в этих двух предложениях: Apple, 2023 и profit.
Однако мы знаем, что первое и третье предложения являются наиболее семантически похожей парой. Слой внимания внутри архитектуры Transformer может уловить этот контекст и вернуть первое и третье предложения как наиболее семантически похожую пару.
Мощная производительность и универсальность моделей Transformers привели к быстрому развитию AI в разных областях — от Computer Vision до NLP и мультимодальных задач.
Одной из моделей, представленных после большого успеха Transformers, является модель Generative Pretrained Transformers (GPT). Эта модель использует часть decoder архитектуры Transformer для предсказания следующего токена во входной последовательности и применяется как основа многих LLM, которые нам известны на данный момент, таких как ChatGPT и Llama.
Архитектура GPT
Эти LLM очень мощны в генерации ответов, похожих на человеческие, поскольку они были обучены на огромных объемах данных. Однако, как вы, возможно, уже знаете, обучающие данные имеют дату отсечения, а это означает, что мы не получим точный ответ от наших LLM, если спросим об информации, более новой, чем их обучающие данные. Именно здесь нам нужно настраивать наши LLM.
Retrieval Augmented Generation (RAG)
Первый способ настроить нашу LLM — через RAG, и его концепция довольно проста. Мы предоставляем LLM и запрос, и релевантные контексты в качестве входных данных, позволяя им генерировать контекстные и точные ответы, используя предоставленные контексты.
Архитектура RAG
Чтобы использовать LLM для RAG, нам нужны два основных компонента:
Модель векторных эмбеддингов: модель, которая преобразует наш запрос и контексты в векторные эмбеддинги.
Векторная база данных: база данных для хранения всех эмбеддингов контекстов и выполнения векторного поиска, чтобы предоставить нашим LLM наиболее релевантные и семантически похожие контексты на основе запроса.
Для генерации векторных эмбеддингов можно использовать несколько моделей, включая модели глубокого обучения от OpenAI или sentence transformers. В качестве альтернативы также можно применять традиционные модели на основе bag-of-words, такие как TF-IDF или BM25.
Milvus — популярная векторная база данных с открытым исходным кодом. Она хранит необходимые данные, состоящие из двух типов: векторные эмбеддинги, сгенерированные моделью, и их метаданные. Например, рассмотрим фрагмент текста из статьи, опубликованной Towards Data Science в первый день июня 2023 года. Данные, хранящиеся в векторной базе данных Milvus, могут выглядеть так:
Пример данных векторного эмбеддинга и его метаданных
Метаданные полезны для выполнения различных фильтров во время операций векторного поиска, чтобы предоставлять нашим LLM более точные контексты. Например, вы можете захотеть получить контексты из определенной публикации или те, что были опубликованы после определенной даты (например, 2020).
Как только у нас есть запрос и мы знаем конкретные метаданные, по которым хотим выполнить фильтрацию, векторная база данных, такая как Milvus, выполнит свою работу. Она выполнит векторный поиск, чтобы найти наиболее семантически похожие на наш запрос контексты, которые удовлетворяют условиям фильтрации по метаданным.
Тонкая настройка
Еще один подход к кастомизации LLM — тонкая настройка. Концепция проста: мы обучаем предварительно обученную LLM на собственных данных, в результате получая модели с новыми весами, адаптированными для выполнения задач, специфичных для нашей предметной области данных.
Существует несколько способов тонкой настройки LLM:
Полная тонкая настройка: Этот подход изменяет веса всех параметров в исходной LLM. Однако он требует дорогостоящего вычислительного процесса.
LORA: Этот подход вводит низкоранговые адаптеры в архитектуру LLM. Исходные веса замораживаются во время тонкой настройки, и обновляются только веса адаптеров.
QLORA: Этот подход вводит квантизацию в исходный метод LORA, снижая вычислительные затраты и потребление ресурсов при сохранении приемлемой производительности.
Полная тонкая настройка против LORA
Теперь, когда мы знаем различные методы тонкой настройки, давайте обсудим различные техники тонкой настройки:
Контролируемая тонкая настройка: В этом методе мы предоставляем нашим LLM собственные обучающие данные и соответствующие метки. Затем мы обучаем наши LLM так же, как любую контролируемую модель машинного обучения.
Обучение с подкреплением на основе обратной связи от человека (RLHF): Этот метод включает теорию обучения с подкреплением. Мы собираем различные ответы от LLM на основе запроса, а затем оцениваем качество каждого ответа. Со временем наши LLM выдают ответы, соответствующие нашим предпочтениям.
Контролируемая тонкая настройка против обучения с подкреплением на основе обратной связи от человека
Поскольку контролируемая тонкая настройка проста, давайте обсудим RLHF подробнее. Один из недостатков нативного RLHF — необходимость участия людей для оценки качества ответов, сгенерированных LLM. Этот подход дорогой и требует много времени.
Специалисты по данным представили Proximal Policy Optimization (PPO), чтобы смягчить эту проблему.PPO вводит модель вознаграждения, чтобы заменить человеческую оценку. Однако эту модель вознаграждения необходимо обучать отдельно, что делает применение PPO громоздким. Кроме того, модель вознаграждения нужно переобучать каждый раз при добавлении новых данных.
Для решения этих проблем была предложена Direct Preference Optimization (DPO). DPO оптимизирует политику LLM с использованием функции потерь отрицательного логарифмического правдоподобия на данных человеческих предпочтений. Набор данных для тонкой настройки с DPO состоит из промптов, предпочтительных ответов и непредпочтительных ответов:
Пример формата данных, используемого для тонкой настройки LLM с DPO
Однако DPO склонна быстро переобучаться на наборе данных предпочтений. Чтобы смягчить эту проблему, была разработана Identity Preference Optimization (IPO).
IPO вводит регуляризационный член в функцию потерь DPO, чтобы избежать переобучения. Он также использует член логарифма отношения шансов, добавленный к функции потерь отрицательного логарифмического правдоподобия (NLL), что позволяет донастраивать LLM под желаемый стиль, одновременно штрафуя нежелательные ответы.
Заключение
В своем выступлении Yujian Tang обсудил различные способы настройки LLM для оптимального использования в наших конкретных сценариях. Презентация началась с краткой истории достижений в области ИИ, которые привели к разработке LLM. Затем последовало объяснение двух методов настройки LLM: RAG и донастройки.
RAG повышает качество ответов, генерируемых LLM, путем добавления релевантных контекстов вместе с запросом в качестве входных данных. Векторные базы данных, такие как Milvus, хранят контекстные эмбеддинги и выполняют векторный поиск для реализации RAG. Затем LLM используют эти контексты для генерации подходящих ответов.
Второй подход — донастройка, и существует два метода донастройки:
Контролируемая донастройка: Этот метод предполагает предоставление нашим LLM собственных обучающих данных и соответствующих меток, а затем их обучение, как и любой контролируемой модели машинного обучения.
Обучение с подкреплением на основе обратной связи от человека (RLHF): Этот метод включает теорию обучения с подкреплением, при которой мы собираем различные ответы LLM на основе запроса и оцениваем качество каждого ответа. Со временем наши LLM начинают выдавать ответы, соответствующие нашим предпочтениям.
Для получения более подробной информации о настройке LLM посмотрите запись выступления Yujian.
Читать далее
Zilliz Cloud Now Available in AWS Europe (Ireland)
Zilliz Cloud launches in AWS eu-west-1 (Ireland) — bringing low-latency vector search, EU data residency, and full GDPR-ready infrastructure to European AI teams. Now live across 30 regions on five cloud providers.
Zilliz Cloud Launches in AWS Australia, Expanding Global Reach to Australia and Neighboring Markets
We're thrilled to announce that Zilliz Cloud is now available in the AWS Sydney, Australia region (ap-southeast-2).
Our Journey to 35K+ GitHub Stars: The Real Story of Building Milvus from Scratch
Join us in celebrating Milvus, the vector database that hit 35.5K stars on GitHub. Discover our story and how we’re making AI solutions easier for developers.