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

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

В этом посте мы демонстрируем несколько показателей для онлайн-мониторинга LLM и соответствующую архитектуру для масштабирования с использованием таких сервисов AWS, как Amazon CloudWatch и AWS Lambda. Это предлагает настраиваемое решение, выходящее за рамки того, что возможно при выполнении заданий по оценке моделей с помощью Amazon Bedrock.

Обзор решения

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

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

Рис. 1. Модуль вычисления метрик – обзор решения

Рабочий процесс включает в себя следующие этапы:

1. Пользователь отправляет запрос в Amazon Bedrock как часть приложения или пользовательского интерфейса.
2. Amazon Bedrock сохраняет запрос и завершение (ответ) в Amazon Simple Storage Service (Amazon S3) в соответствии с конфигурацией ведения журнала вызовов.
3. Файл, сохраненный на Amazon S3, создает событие, которое запускает функцию Lambda. Функция вызывает модули.
4. Модули публикуют свои соответствующие показатели в метриках CloudWatch.
5. Сигналы тревоги могут уведомлять команду разработчиков о неожиданных значениях метрик.

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

В следующих разделах мы выделим некоторые соответствующие метрики модулей и соответствующую им архитектуру модуля вычисления метрик.

Семантическое сходство между подсказкой и завершением (ответом)

При запуске LLM вы можете перехватывать приглашение и завершение (ответ) для каждого запроса и преобразовывать их во внедрения с помощью модели внедрения. Вложения — это многомерные векторы, которые представляют семантическое значение текста. Amazon Titan предоставляет такие модели через Titan Embeddings. Установив расстояние, например косинус, между этими двумя векторами, вы можете количественно оценить, насколько семантически схожи подсказка и завершение (ответ). Вы можете использовать SciPy или scikit-learn для вычисления косинусного расстояния между векторами. На следующей диаграмме показана архитектура этого модуля вычисления метрик.

Рис. 2. Модуль вычисления метрик – семантическое сходство

Этот рабочий процесс включает в себя следующие ключевые этапы:

1. Функция Lambda получает потоковое сообщение через Amazon Kinesis, содержащее пару приглашения и завершения (ответа).
2. Функция получает встраивание как для приглашения, так и для завершения (ответа) и вычисляет косинусное расстояние между двумя векторами.
3. Функция отправляет эту информацию в метрики CloudWatch.

Чувства и токсичность

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

Рис. 3. Модуль вычисления показателей – настроения и токсичность

Рабочий процесс включает в себя следующие этапы:

1. Функция Lambda получает пару приглашения и завершения (ответа) через Amazon Kinesis.
2. Благодаря оркестрации AWS Step Functions функция вызывает Amazon Comprehend для обнаружения настроение и токсичность.
3. Функция сохраняет информацию в метриках CloudWatch.

Дополнительную информацию об обнаружении настроений и токсичности с помощью Amazon Comprehend см. в разделах «Создание надежного текстового средства прогнозирования токсичности» и «Пометка вредоносного контента с помощью обнаружения токсичности Amazon Comprehend».

Коэффициент отказов

Увеличение количества отказов, например, когда LLM отказывает в завершении из-за отсутствия информации, может означать, что либо злонамеренные пользователи пытаются использовать LLM способами, предназначенными для его взлома, либо что ожидания пользователей не оправдываются, и они получают малоценные ответы. Один из способов оценить, насколько часто это происходит, — сравнить стандартные отказы от используемой модели LLM с фактическими ответами от LLM. Например, ниже приведены некоторые распространенные фразы отказа в программе Claude v2 LLM от Anthropic:

“Unfortunately, I do not have enough context to provide a substantive response. However, I am an AI assistant created by Anthropic to be helpful, harmless, and honest.”

“I apologize, but I cannot recommend ways to…”

“I'm an AI assistant created by Anthropic to be helpful, harmless, and honest.”

При фиксированном наборе подсказок увеличение числа таких отказов может быть сигналом того, что модель стала чрезмерно осторожной или чувствительной. Обратный случай также следует оценить. Это может быть сигналом о том, что модель теперь более склонна к токсичным или вредным разговорам.

Чтобы помочь смоделировать целостность и коэффициент отказов, мы можем сравнить ответ с набором известных фраз отказа из LLM. Это может быть настоящий классификатор, который может объяснить, почему модель отклонила запрос. Вы можете взять косинусное расстояние между ответом и известными ответами об отказе из отслеживаемой модели. На следующей диаграмме показан этот модуль вычисления метрик.

Рис. 4. Модуль вычисления метрик – соотношение отказов

Рабочий процесс состоит из следующих шагов:

1. Лямбда-функция получает приглашение и завершение (ответ) и встраивает ответ с помощью Amazon Titan.
2. Функция вычисляет косинусное или евклидово расстояние между ответом и существующими запросами об отказе, кэшированными в памяти.
3. Функция отправляет это среднее значение в метрики CloudWatch.

Другой вариант — использовать нечеткое соответствие для простого, но менее мощного подхода для сравнения известных отказов с результатами LLM. Обратитесь к Документация Python для примера.

Краткое содержание

Наблюдение за LLM является важной практикой для обеспечения надежного и заслуживающего доверия использования LLM. Мониторинг, понимание и обеспечение точности и надежности LLM могут помочь вам снизить риски, связанные с этими моделями ИИ. Отслеживая галлюцинации, неверные ответы (ответы) и подсказки, вы можете быть уверены, что ваш LLM идет по правильному пути и приносит ту пользу, которую ищете вы и ваши пользователи. В этом посте мы обсудили несколько показателей для демонстрации примеров.

Дополнительную информацию об оценке моделей фундамента см. в разделе «Использование SageMaker Clarify для оценки моделей фундамента» и просмотрите дополнительные сведения. примеры блокнотов доступен в нашем репозитории GitHub. Вы также можете изучить способы внедрения оценок LLM в большом масштабе в разделе «Эксплуатация оценки LLM в масштабе» с использованием сервисов Amazon SageMaker Clarify и MLOps. Наконец, мы рекомендуем обратиться к разделу «Оценка больших языковых моделей на предмет качества и ответственности», чтобы узнать больше об оценке LLM.

Об авторах

Бруно Кляйн — старший инженер по машинному обучению в аналитической практике AWS Professional Services. Он помогает клиентам внедрять решения для больших данных и аналитики. Вне работы он любит проводить время с семьей, путешествовать и пробовать новую еду.

Рушаб Локханде — старший инженер по данным и машинному обучению в аналитической практике AWS Professional Services. Он помогает клиентам внедрять решения для больших данных, машинного обучения и аналитики. Вне работы он любит проводить время с семьей, читать, бегать и играть в гольф.