Представьте модели LLM размером до более чем 100 миллиардов параметров, каждая из которых мощнее предыдущей. Среди них есть гиганты: Mistral (7 миллиардов), Mixtral (8x7 миллиардов), Llama (70 миллиардов) и колоссальная Falcon (180 миллиардов). Однако существуют и модели наподобие Phi1, Phi1.5 и Falcon 1B, стремящиеся к сравнимому уровню мощности, имея всего от 1 до 4 миллиардов параметров. У каждой модели, и большой, и маленькой, есть одна цель: стать мастером в искусстве языка, превосходно справляться с такими задачами, как резюмирование текстов, ответы на вопросы и распознавание именованных сущностей.

Но во всех этих задачах у всех больших языковых моделей (Large Language Model, LLM) проявляются сильные изъяны:

Некоторые промты заставляют LLM создавать мусорные результаты; они называются «промтами джейлбрейкинга».
LLM не всегда правильно излагают факты; это явление называется «галлюцинациями».
LLM могут вести себя неожиданно, из-за чего потребителям бывает небезопасно ими пользоваться.

Очевидно, что простого обучения LLM недостаточно. Поэтому возникает вопрос: как нам обеспечить уверенность в том, что LLM А (с n параметров) лучше LLM Б (с m параметров)? Или сделать вывод, что LLM А надёжнее, чем LLM Б, на основании исчисляемых, обоснованных наблюдений?

Необходим стандарт для бенчмаркинга LLM, гарантирующий их этическую надёжность и фактическую точность. Хотя было проведено множество исследований бенчмаркинга (например, MMLU, HellaSwag, BBH и так далее), одних лишь исследований недостаточно для надёжного специализированного бенчмаркинга продакшен-систем.

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

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

Сценарий, задача, датасет бенчмарка и метрика

Все эти термины часто используются в сфере оценки LLM, поэтому крайне важно понять, что они значат.

Сценарий

Сценарий (scenario) — это широкий спектр контекстов/условий, при которых оцениваются или тестируются показатели LLM. Например:

Ответы на вопросы
Рассуждения
Машинный перевод
Генерация текста и обработка естественного языка

В различных областях LLM существует множество популярных бенчмарков, в том числе, например, MMLU, HellaSwag и BIG-Bench Hard.

Задача

Задачу (task) можно воспринимать как более мелкий вид сценария. Это более конкретная основа оценки LLM. Задача может быть сочетанием (или группой) множества подзадач.

Например, задачей можно считать арифметику. Тогда чётко заявляется, что LLM оценивается в ответах на арифметические задачи. Внутри этой задачи может быть множество подзадач, например, уровни 1, 2, 3 арифметики. В этом примере все арифметические подзадачи (уровней с 1 по 5) составляют задачу «Арифметика».

Аналогичным образом может существовать задача «Вопросы с несколькими вариантами ответа». Внутри могут быть подзадачи в виде вопросов по истории, алгебре и так далее. На самом деле, MMLU целиком основана на вопросах с несколькими вариантами ответов.

Метрика

Метрика (metric) — это количественная мера, используемая для оценки точности языковой модели при выполнении определённых задач/сценариев. Метрика может быть простой:

Детерминированной статистической/математической функцией (например, Accuracy)
Оценкой, создаваемой нейросетью или моделью ML (например, BERT Score)
Оценкой, сгенерированной с помощью самой LLM (например, G-Eval)

Рисунок 1: Упрощённая таксономия различных метрик, используемых при оценке LLM

Кроме того, метрика может быть сочетанием нескольких атомарных/мелких метрик. Очень простой пример — это F1-score, являющаяся гармоническим средним precision и recall.

Например, оценка BLEU (Bilingual Evaluation Understudy) из сферы NLP — это сочетание precision, brevity penalty и N-gram matching. При желании можно скомбинировать различные метрики, чтобы создать новую.

Датасет бенчмарка

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

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

Современные исследовательские фреймворки для бенчмаркинга LLM

Рисунок 2: Популярные фреймворки бенчмаркинга LLM

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

Language Model Evaluation Harness (компании EleutherAI)

Language Model Evaluation Harness — это унифицированный фреймворк для бенчмаркинга LLM на большом количестве задач оценки. Я намеренно выделил слово «задач», потому что в сценариях Harness НЕТ такой концепции.

Внутри Harness есть множество задач, содержащих различные подзадачи. Каждая задача или множество подзадач оценивает LLM в различных областях, например, генеративные способности, рассуждения в разных областях и так далее.

Каждая подзадача внутри задачи (а иногда и сама задача) имеет датасет бенчмарка, и задачи в целом связаны с какими-то серьёзными исследованиями в области оценок. Разработчики Harness приложили большие усилия к унифицированию и структурированию этих датасетов, конфигураций и стратегий оценки (например, метрик, ассоциированных с датасетами бенчмарков).

Кроме того, Harness поддерживает различные виды бэкендов LLM (например, VLLM, GGUF и так далее). Это обеспечивает высокую степень гибкости настройки в изменении промтов и экспериментах с ними.

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

lm_eval --model hf \
    --model_args pretrained=mistralai/Mistral-7B-v0.1 \
    --tasks hellaswag \
    --device cuda:0 \
    --batch_size 8

Взяв за основу LM Evaluation Harness, разработчики BigCode Evaluation Harness из проекта BigCode стремились создать схожие методы API и CLI для оценки LLM в задачах генерации кода.

Stanford HELM

HELM, или Holistic Evaluation of Language Model использует «сценарии» для определения того, где могут применяться языковые модели, и «метрики» для указания того, что должны делать LLM в условиях бенчмаркинга. Сценарий состоит из:

задачи (согласованной со сценарием)
предметной области (состоящей из жанра текста, автора и времени написания)
языка (то есть естественного языка задачи)

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

Рисунок 3: Структура таксономии оценок HELM

Но и это ещё не всё: HELM стремится вычислить почти для всех сценариев набор из семи метрик (accuracy, калибровка, надёжность, справедливость, предубеждения, токсичность и эффективность), потому что простая accuracy не может полностью отразить надёжность работы LLM.

PromptBench (Microsoft)

Рисунок 4: Microsoft Prompt Bench

PromptBench — это ещё одна унифицированная библиотека для бенчмаркинга LLM. Она очень похожа на HELM и Harness, поддерживает различные фреймворки LLM (например, Hugging Face, VLLM и так далее). Выделяет её на фоне остальных фреймворков то, что кроме простой оценки задач она также поддерживает оценку различных методик промт-инжиниринга и оценивает LLM на различных состязательных атаках уровня промтов. Также при помощи этой библиотеки можно создавать конвейеры различных оценок, что упрощает проверку сценариев использования для продакшена.

ChatArena (LMSys)

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

Рисунок 5: Chabot Arena компании LMSys.

Как вы видите на рисунке, можно начать с собственного промта и двух анонимных LLM (Model A и B). Обе модели дают какой-то ответ, после чего вы решаете, какая справилась лучше. Очень просто и понятно, ничего необычного. Однако это позволяет замечательно количественно оценивать точность LLM. Перевод в количественные значения сравнения выполняется при помощи рейтингов Maximum Likelihood Estimation Elo (MLE-Elo) (они же модель Брэдли-Терри).

Также LmSys ведёт таблицу рекордов, в которой приведены результаты различных крупных LLM на основании рейтингов MLE-Elo. Таблицу можно посмотреть здесь.

Но у нас всё равно остаются проблемы с бенчмаркингом LLM

Пока мы изучали только самые важные для этой сферы исследования и различные их реализации. Мы узнали:

Как во фреймворках (наподобие Harness и HELM) были придуманы различные таксономии для структурирования задач оценки.
Как разные опенсорсные платформы наподобие Chatbot Arena позволяют легко выполнять бенчмаркинг LLM.
Как в реализациях наподобие PromptBench упор сделан на сценарии продакшена (например, на атаки с инъецированием промтов или на состязательные атаки).

Однако эти системы состоят из множества отдельных компонентов: векторных баз данных, оркестрирования различных рабочих нагрузок (агентов) LLM, промт-инжиниринга, данных для fine-tuning и так далее, управлять которыми очень сложно.

Ещё одна проблема заключается в различиях между оценкой в исследованиях и в продакшене. Быстрая разработка и fine-tuning LLM с последующим выводом в продакшен — это непростая задача, поэтому ещё одним важным узким местом становится инфраструктура оценки системы для продакшена.

Все мы знаем, что тестирование — это важная и неотъемлемая часть классической быстрой разработки ПО (например, в Python фреймворк PyTest играет важную роль в тестировании); оно также используется в конвейерах CI/CD перед выпуском обновлений ПО, благодаря чему процесс разработки упрощается и становится надёжнее.

Однако для LLM у нас нет инфраструктуры тестирования наподобие Pytest. Но даже если бы она у нас была, LLM — это вероятностные механизмы, из-за чего применение детерминированных тестов не дало бы адекватных результатов. Кроме того, важно тестирование в реальном времени и нагрузочное тестирование (испытания «красной командой»). Но всё это пока практически отсутствует, что замедляет процесс разработки продуктов генеративного ИИ уровня продакшена.

Так как требуется постоянно выполнять fine-tuning LLM, что позже используется для разработки систем LLM (например, систем на основе RAG), то необходима архитектура, которая:

Выполняет одновременную оценку во время fine-tuning
Оценивает тестовые случаи для пред-/пост-продакшена
Включает в себя «краснокомандные» проверки/нагрузочное тестирование и A/B-тестирование LLM и систем LLM в крупных масштабах.
Выполняет оценку и коррекцию данных, которые будут использоваться для LLM.

Если вы сейчас думаете, что здесь бы был очень полезен Harness или HELM, то вы и правы, и неправы одновременно. Хотя HELM и Harness позволяют своим пользователям сделать большой шаг к реализации оценки LLM, все эти библиотеки имеют теневые интерфейсы (интерфейсы API, недостаточно описанные в документации) и в основном запускаются через CLI, что не совсем подходит для быстрого прототипирования моделей.

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

Рекомендации по бенчмаркингу LLM

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

Типичный жизненный цикл разработки:

Начинаем с уже имеющейся опенсорсной LLM или LLM с закрытыми исходниками.
Адаптируем LLM к нужному сценарию применения. Это можно сделать или при помощи промт-инжиниринга (например, Chain of Thoughts или In-Context Learning), или при помощи векторных баз данных в RAG для предоставления дополнительного контекста. Можно выполнить fine-tuning LLM и использовать наряду с ним другие методики, чтобы добиться максимальной точности LLM.
Выводим в продакшен с дополнительными мерами защиты LLM, соединяя с бэкенд-сервером для получения входящих данных.

Перечисленные выше процессы можно разделить на две фазы.

Оценка перед продакшеном.
Оценка после вывода в продакшен.

Оценка перед продакшеном

В этой фазе первоначальных исследований мы можем экспериментировать с каждой из следующих комбинаций:

LLM + промт-инжиниринг (например, CoT или In-Context Learning).
LLM + промт-инжиниринг + RAG.
Fine-tuning LLM + промт-инжиниринг + RAG и так далее, что лучше подойдёт.

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

может оценивать LLM на разных промтах и имеет пространство для ранжирования тех комбинаций промтов, которые работают лучше всего.
может оценивать движки извлечения данных (состоящие из моделей извлечения данных) в сценариях использования на основе RAG, чтобы понимать, как извлекаются фактически корректные контексты перед их передачей LLM.
может оценивать различные контрольные точки fine-tuning (которые создаются во время fine-tuning LLM) и определять, какие контрольные точки подходят лучше всего.
может иметь стандартизованные численные оценки из HELM или Harness (например, из их стандартизированного датасета бенчмарков, относящегося к нужной предметной области). Это важно, ведь таким образом мы можем получить карту оценок (похожую на карты моделей или карты датасетов), которая универсальна и становится стандартизированной.
может оценивать уникальный приватный датасет бенчмарков для предметной области. чтобы мы могли быть полностью уверены в том, как LLM ведёт себя с данными, которые похожи на данные в продакшене.
может оценивать степень надёжности LLM (например, LLM не должны быть токсичными или несправедливыми, быть защищены от похищения промтов и так далее) и величину их accuracy (то есть степень фактической корректности LLM).
может оценивать различные конвейеры (как в приведённых выше комбинациях), чтобы понимать, какая комбинация конвейеров подходит лучше всего.
кроме того, перед выпуском в продакшен крайне важна тщательная «краснокомандная» проверка LLM (особенно для чат-моделей).

Оценка после вывода в продакшен

После вывода в продакшен конвейеров LLM очень важно использовать следующие практики:

Непрерывный мониторинг LLM. Очень важно поддерживать системы алертов на случай неудовлетворительных результатов работы LLM-приложений практически в реальном времени. Кроме того, это поможет нам легко понять, что пошло не так, и устранить проблемы.
Явные способы обратной связи, например, индикаторы (рейтинги пользователей с голосованием пальцем вверх/вниз и так далее), чтобы дать обратную связь генерации LLM.
Поддержка непрерывного fine-tuning LLM (вместе с моделями эмбеддингов, используемыми в приложениями на основе RAG) и непрерывное развёртывание для обеспечения нацеленной на потребителей генерации; в противном случае приложение может столкнуться с дрейфом данных.

Внедрение рекомендаций бенчмаркинга LLM

Если вам хочется попрактиковаться в создании фреймворка тестирования для LLM, то лучше всего попробовать реализовать всё с нуля. Однако если вы желаете использовать готовый фреймворк оценки LLM, то рекомендуем изучить DeepEval.

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

Интеграция с PyTest, благодаря чему она имеет очень схожий с ним интерфейс и декораторы в Pytest, так что вы можете писать тестовые случаи в своей предметной области для оценки LLM в сценариях использования, пока ещё не охваченных современными фреймворками бенчмаркинга.
14 готовых метрик для оценки систем LLM/систем на основе RAG, работающих и локально на машине, и при помощи моделей GPT. Пользователи также могут писать собственные метрики оценки, автоматически интегрируемые с экосистемой DeepEval.
Передача результатов оценки в Confident AI (платформе DeepEval), позволяющему отслеживать результаты экспериментов, отлаживать результаты оценок, централизованно управлять датасетами бенчмаркинга и отслеживать события в продакшене для непрерывной оценки LLM при помощи различных произвольных метрик.

Заключение

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

Ссылки

Понравилась статья? Еще больше информации на тему данных, AI, ML, LLM вы можете найти в моем Telegram канале.

Как подготовиться к сбору данных, чтобы не провалиться в процессе?
Как работать с синтетическими данными в 2024 году?
В чем специфика работы с ML проектами? И какие бенчмарки сравнения LLM есть на российском рынке?

Обо всем этом читайте в “Роман с данными”

Как оценить качество LLM модели