Часть 1: Краткий обзор больших языковых моделей

За сравнительно небольшое время генеративный искусственный интеллект (Gen AI) превратился в одну из ключевых технических парадигм и уже породил отдельное направление в программной инженерии. Это происходит аналогично тому, как сначала это сделали СУБД, потом интернет с поиском и мобильными платформами. Gen AI несет в себе не меньший потенциал для решения и автоматизации ключевых бизнес-проблем.

Верхнеуровнево LLM классифицируются по следующим трем категориям.

Основные характеристики LLM:

В качестве входных данных, в LLM их называют промтами, можно использовать текст или медиа. Например — "Кто выиграл последний чемпионат мира по футболу?"
Модель генерирует ответы в текстовом и другом медиа формате, например — "Франция".
Часть текста, переданного в prompt, преобразуется в токены.

Краткая история больших языковых моделей

Декабрь 2015: OpenAI основана как некоммерческая организация с подтверженным финансированием в размере 1 миллиарда долларов.

Конец 2016: Исследователь из OpenAI добивается успешных результатов, обучая нейронные сети на корпусе отзывов Amazon. Исследователи поражены, обнаружив, что за кулисами нейронная сеть проводит анализ тональности отзывов, не будучи для этого явно запрограммированной. Они хотят провести обучение на данных интернет-масштаба, но технологии для этого еще не существует.

2017: Google Brain публикует статью под названием "Attention Is All You Need", в которой описывается новая архитектура нейронных сетей, называемая Transformer. Эта архитектура позволяет делать параллельную токенизацию и использование мягких весов. Благодаря этой алгоритмической инновации теперь становится возможным более быстрое обучение нейронных сетей на огромных объемах данных.

2018: OpenAI выпускает модель Generative Pre-Trained Transformer (GPT), которая обучена на более чем 7000 книгах. Google выпускает BERT. Гонка началась.

2019: OpenAI выпускает GPT-2, обученный на более чем 8 миллионах веб-страниц (отфильтрованных на основе ссылок с Reddit) и имеющий размер в 1.5 миллиарда параметров. Исследователи вновь поражены, обнаружив, что модель обладает способностью к переводу, не будучи для этого специально обученной.

2020-е: OpenAI выпускает GPT-3 в июне 2020 года, которая обучена на полном корпусе интернет-краулинга, книг и Википедии. За этим следует выпуск GPT-4 в марте 2023 года.

Краткое сравнение между GPT-4 и GPT-3

Как используются LLM-модели

Основных способа использования LLM три. Они представлены ниже, в порядке возрастания сложности и точности:

Прямые запросы к LLM (промты): отправка контекста LLM в виде вопроса или инструкций через API или через интерфейс чата. Это самый популярный способ использования LLM. Пример:

Дополнение LLM собственными данными: используется метод, называемый векторизацией, при котором собственные данные преобразуются в многомерные числовые векторы.
Тонкая настройка LLM: можно тонко настроить базовую модель LLM под определенную область и нативно обучить модель на наборах из нее. Это требует больших вычислительных ресурсов и довольно дорого. Этим путем лучше идти только тогда, когда есть конкретная бизнес-потребность. Вот список открытых моделей с тонкой настройкой на huggingface.

Краткое введение в векторизацию

Есть несколько причин почему нужно понимать и использовать LLM-векторизацию:

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

Как векторизация решает вышеуказанные проблемы? В три простых шага:

она преобразует собственные корпоративные данные в векторные вложения, которые являются многомерным числовым представлением текстовых данных. Эти вложения обычно хранятся в векторной базе данных. Вот отличное введение для глубокого погружения в векторные вложения.
Вопрос пользователя также преобразуется в векторные вложения, и с помощью векторного поиска вопрос сравнивается с данными, хранящимися в векторной БД.
Затем наиболее подходящее совпадение данных передается в качестве входных данных модели LLM, которая теперь будет иметь достаточно контекста для генерации ответа на ваш собственный вопрос.

Этот процесс также известен как RAG (Retrieval Augmentation & Generation - извлечение, дополнение и генерация). Вот упрощенный пример этого процесса:

Часть 2: Use Case для автоматизации инженерии данных

В типичную экосистему данных входят базы данных, пайплайны, ETL-процессы, экспорты в даунстрим-системы, контроль качества данных и множество других взаимодействий с данными. В среде с большим объемом данных создание пайплайнов и поддержка этой системы становится постоянной и очень трудоемкой задачей.

Некоторые проблемы можно решить с помощью комбинации генеративного ИИ и инженерных дизайн-фреймворков.

Высокоуровневая архитектура LLM

Дизайн:

Предоставление контекста LLM с использованием техники Zero Shot Prompting, которая включает детализированные промты-инструкции, описывающие требования к пайплайну.

Инструкции:

LLM получает инструкции только о схеме и метаданных используемых таблиц.

Использование:

Разработчики и архитекторы используют LLM для автоматизации создания пайплайнов.

Цель:

Генерация кода пайплайна (SQL-запросов и другого необходимого кода) с точностью 80–90%.

Дизайн пайплайна:

Большая часть кода пайплайна может быть выражена в форме SQL, обернутого в код платформенного фреймворка .

Стратегия выполнения

LLM используется как движок генерации кода.
Полученный код проверяется как автоматически, так и вручную разработчиками.
Требования написаны таким образом, чтобы их можно было легко перевести в промты.
На основе Python развернут фреймворк для перевода и оптимизации пользовательских требований в промты.
Получаемый от модели код выполняется платформенным фреймворком на проде.
Промт-инжиниринг
Python-фреймворк считывает документ сопоставления и метаданные таблиц базы данных и генерирует промт для LLM. Отдельные промты создаются для:
- список используемых таблиц — это помогает формировать ‘from’ часть SQL.
- DDL-запросы для создания таблиц и примеров данных - это помогает LLM понять структуру таблиц и данных.
- Ограничения целостности - это помогает формировать ‘join’ часть SQL-запросов.
- Правила на уровне таблиц - например, читать только активные записи на основе флага валидности. Это помогает формировать ‘where’ часть SQL.
- Правила на уровне столбцов — включает основные преобразования данных, бизнес-правила и синтаксис. Это помогает формировать ‘select’ часть SQL.
LLM обрабатывает указанный выше промт и генерирует SQL-запрос, который затем можно подключить к фреймворку платформы данных для запуска пайплайна. Несколько ключевых моментов:
- Даже написание 80% кода с помощью LLM дает 5-10-кратное ускорение разработки.
- Несколько ошибок, которые LLM модель так или иначе допускает в ходе кодогенерации, не обнуляют эффект, получаемый от нее.
- Нужна проверка кода перед выпуском в прод.
- Решение дополняет рабочие процессы человека, а не заменяет их (по крайней мере, вначале).
- Качество данных в промте более важно, чем объем данных.
- Нерелевантные данные могут негативно повлиять на результат.
- Уточнение промта улучшает производительность по сравнению со стандартным промтом.

Часть 3: Выведение LLM-фреймворка в прод

Отлично, прототип создан. Проделан большой путь, теперь о том, как эффективно запустить это в продакшн.

Основные проблемы при внедрении LLM-фреймворков в продакшн

Лимит токенов

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

Стоимость

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

Производительность

Средняя скорость обработки запросов LLM составляет около 2 запросов в секунду (QPS). Это очень низкий показатель по сравнению с RESTful-сервисам, чей QPS может исчисляться тысячами. Понимание ограничений производительности и проектирование приложения с учетом этого также является критически важной частью успешного развертывания.

Безопасность

Если в проекте есть конфиденциальные данные, нужна их защита. Для этого применяется маскирование или шифрование. Также процесс LLM должен быть идемпотентным, т.е. многократные повторные запуски с одинаковым вводом должны давать один и тот же результат.

Способы управления затратами LLM в продакшн

Мониторинг

Можно приобрести готовые решения (например, LangSmith), которые показывают количество используемых токенов на запрос и другие аналогичные метрики использования. Как только станут понятны некие тренды по нужному количеству запросов к LLM, можно будет принять решение насчет объема необходимых затрат.

Промт-инжиниринг

Для контроля и управления количеством токенов, передаваемых модели важно правильно создавать промты. Для этого используются техники промт-инжиниринга.

Кэширование

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

Самостоятельный хостинг модели

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

Способы обхода лимита токенов LLM

Разделение на части (chunking)

данные, которые нужно передать в модель, делятся на части (чанки)
когда пользователь задает вопрос, каждая из этих частей (чанков) (< лимита токенов) анализируется.
если анализ показывает, что в чанке есть релевантные токены, он включается в промт
объединенный текст направляется в модель как промт, и модель может вернуть нужный ответ

Резюмирование/Адаптация

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

Векторизация

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

Лучшие практики

Обеспечение конфиденциальности

Использование stateless API, которые по умолчанию не запоминают и не сохраняют вводимые данные.

Обертки для LLM

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

Измерение точности модели

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

Векторные хранилища

Существует множество вариантов хранения данных векторных эмбеддингов в зависимости от потребностей - векторные базы данных (Pinecone), реляционные СУБД (например, Postgres с векторным расширением), NoSQL базы данных (MongoDB, Elasticsearch с векторными расширениями), API (Facebook или Hugging Face).

Дизайн платформы данных играет большую роль

Генеративный ИИ может помочь сократить объем работы, автоматизируя пайплайны. Однако все равно нужна хорошая дата-платформа. На ней должна быть возможность автоматизации промт-инжиниринга, инфраструктура для запуска пайплайнов, создание схем и хранение и т.д. Без хорошей архитектуры платформы данных поддержка LLM даст лишь небольшое улучшение.

Качество данных

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

Использование генеративного ИИ для автоматизации дата инжиниринга