Оценка систем LLM: основные метрики, бенчмарки и лучшие практики

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

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

На повестке дня:

Давайте начнем.

Давайте разберемся: в то время как LLM (большая языковая модель) относится конкретно к модели (например, GPT-4), обученной понимать и генерировать человеческий язык. LLM-система, в свою очередь, представляет собой полную инфраструктуру, которая включает не только саму LLM, но и дополнительные компоненты, такие как вызовы функций (для агентов), системы поиска (в RAG), кэширование ответов и т.д., что делает LLM полезными для реальных приложений, таких как чат-боты поддержки клиентов, автономные агенты продаж и генераторы Text-to-SQL.

Однако важно отметить, что система LLM иногда может состоять из одной LLM, как в случае с ChatGPT. Вот пример системы LLM на основе RAG, которая выполняет задачу Text-to-SQL:

Основной целью Text-to-SQL является генерация правильного и эффективного SQL для заданного пользовательского запроса, поэтому пользовательский запрос обычно сначала используется для извлечения соответствующих таблиц в схеме базы данных через конвейер извлечения, прежде чем использовать его в качестве контекста для генерации правильного SQL через конвейер генерации SQL. Вместе они составляют систему LLM (основанную на RAG).

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

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

Например, вы можете применить метрику контекстной полноты для оценки конвейера извлечения в примере Text-to-SQL выше, чтобы оценить, может ли он извлечь все необходимые таблицы, необходимые для ответа на конкретный запрос пользователя.

Аналогичным образом вы можете применить пользовательскую метрику корректности SQL, реализованную через G-Eval, для оценки того, генерирует ли конвейер генерации правильный SQL на основе извлеченных таблиц данных top-K.

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

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

Офлайн-оценки относятся к оценке или тестированию вашей системы LLM в локальной среде разработки. Представьте себе выполнение оценок в вашей локальной среде разработки, которая может быть чем угодно: от скрипта Python, Colab/Jupyter Notebooks до конвейеров CI/CD в Github Actions перед развертыванием в продакшн. Это позволяет количественно улучшить архитектуру вашей LLM-системы или даже подобрать идеальный набор гиперпараметров (например, используемую LLM, шаблоны промптов, модель эмбеддингов и т.д. для каждого компонента).

Некоторые инженеры называют этот процесс "бенчмаркингом" LLM-систем, и это абсолютно верно. Бенчмаркинг LLM-систем — это процесс количественного измерения их производительности на основе набора пользовательских критериев, используя метрики оценки LLM и стандартизированный набор данных для оценки. Именно так проводится оффлайн-оценка. Исходя из примера Text-to-SQL в предыдущем разделе, метрики, используемые для сравнительного анализа нашей системы LLM, будут контекстной полнотой и пользовательской метрикой корректности SQL. Эти метрики оценивают, насколько хорошо LLM-система Text-to-SQL справляется с набором пользовательских запросов и выводами SQL, которые мы называем тестовыми кейсами.

Что касается терминологии, вот что вам нужно знать:

Вы можете запускать эти бенчмарки системы LLM в локальной среде разработки каждый раз, когда вносите изменения в свою систему LLM (например, переключаетесь на другую архитектуру извлечения или поставщика LLM), чтобы обнаружить любые критические изменения в производительности, или вы можете даже интегрировать эти бенчмарки в конвейер CI/CD для регрессионного тестирования системы LLM.

Прежде чем перейти к следующему разделу, вот спойлер о том, как вы можете настроить все в коде с помощью DeepEval, фреймворка оценки LLM с открытым исходным кодом:

И для тех, кто хочет начать оценку немедленно, ознакомьтесь с кратким руководством DeepEval.

Набор данных для оценки — это набор тестовых кейсов.

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

Вот в чем подвох: разные метрики требуют заполнения разных параметров в тестовом кейсе LLM. Например, метрика релевантности ответа без эталона (reference-less answer relevancy metric, о которой вы узнаете позже) требует только входных данных и фактического вывода. В то же время метрика релевантности ответа с эталоном (reference-based answer relevancy metric) потребует входных данных, фактического вывода и ожидаемого результата.

Другой пример вы можете найти в исходной метрике контекстной полноты, использованной ранее в примере Text-to-SQL. Поскольку контекстная полнота оценивает, способна ли ваша система извлечения извлекать все соответствующие фрагменты текста для ответа на определенный запрос, вам понадобятся входные данные (т. е. запрос) и контекст извлечения (т. е. соответствующие фрагменты текста, которые были извлечены).

Вот несколько правил, которым необходимо следовать при подготовке набора данных оценки:

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

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

Например, в случае использования Text-to-SQL хороший генератор синтетических данных будет:

Однако необходимо развивать ввод тестовых кейсов, чтобы сделать его более реалистичным и неотличимым от данных, подготовленных вручную. Этот процесс называется эволюцией, и он был изначально представлен в статье Evol-Instruct от Microsoft.

Вот быстрый способ сгенерировать синтетические данные с использованием LLM через DeepEval:

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

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

В одной из моих предыдущих статей я подробно рассказал обо всем, что вам нужно знать о метриках оценки LLM, но вкратце повторю - традиционные метрики, такие как BERT, ROUGE и n-gram, не работают, потому что выходные данные LLM слишком сложны для оценки статистическими методами или моделями, не основанных на LLM. Решение — использовать подход LLM-as-a-judge («LLM в роли судьи»).

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

Более того, такие подходы, как G-Eval, использование промптов для уменьшения объема текста, который нужно оценить в тестовом кейсе, или применение метода QAG (Question Answer Generation) для математически более точного вычисления оценки метрики для каждого тестового кейса, помогают LLM генерировать результаты, гораздо лучше соответствующие ожиданиям человека. (Я настоятельно рекомендую прочитать эту статью, если у вас есть какие-либо вопросы или вы хотите узнать больше о том, как использовать LLM для оценки других LLM.)

Ниже приведен список наиболее часто используемых метрик для оценки LLM-систем, каждая из которых оценивает различные аспекты системы:

(DeepEval поддерживает каждую из этих метрик «из коробки», и вы можете ознакомиться с документацией, чтобы узнать больше о каждой метрике и ситуациях, в которых ее следует использовать.)

Например, вот как можно реализовать пользовательскую метрику корректности с подходом «LLM в роли судьи» на практике:

Когда вы проводите оценки на стадии разработки, следует стремиться использовать метрики на основе эталонов (reference-based metrics). Эталонные метрики сравнивают результат модели с заранее подготовленным «золотым» стандартом или идеальным ожидаемым выводом в тестовом кейсе.

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

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

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

Бенчмарки состоят из наборов данных для оценки и метрик LLM, и в отличие от типичных бенчмарков для LLM, все бенчмарки систем LLM являются кастомными. Это связано с тем, что:

И пока я не забыл, вот как вы можете протестировать свою систему LLM в коде, используя метрику релевантности ответа:

Самая большая ошибка, которую можно совершить, — это предположить, что ваш набор данных для бенчмарка «достаточно хорош», чтобы его никогда не улучшать. Улучшение набора данных для бенчмарка имеет решающее значение, поскольку для того, чтобы ваш бенчмарк имел смысл, он всегда должен отражать самые последние уязвимости в вашем приложении LLM.

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

(Если ваша система LLM ещё не в продакшене, этот раздел может быть вам не актуален.)

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

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

Представьте, что ваше приложение LLM генерирует 50 000 ответов в месяц. Скорее всего, вы не сможете просмотреть их все, не потеряв рассудок. Вы можете случайным образом выбрать 10% ответов для проверки вручную, но даже это останется крайне трудозатратной задачей. Именно поэтому оценка в реальном времени столь ценна.

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

В предыдущем разделе о метриках LLM мы подчёркивали, что на этапе разработки следует использовать метрики, основанные на эталонных данных (reference-based metrics), так как они делают результаты более надёжными благодаря строгим критериям оценки.

Однако метрики, основанные на эталонных данных, невозможно применять в продакшене, так как у вас нет ожидаемых результатов для каждого сгенерированного ответа. Поэтому в продакшене применяются метрики, не основанные на эталонных данных. Ниже приведён пример метрики релевантности ответа без эталонных данных (хотя ранее мы вводили её как метрику на основе эталонов):

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

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

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

(Примечание: эта диаграмма и схема Text-to-SQL выглядят почти одинаково, поскольку оба варианта использования представляют собой упрощенную систему LLM на основе RAG)

Шаг 1: Предполагая, что у нас уже есть несколько PDF-документов, представляющих нашу базу знаний, под названием knowledge_1.pdf, knowledge_2.pdf и т. д., мы можем сгенерировать синтетические тестовые кейсы из этих документов для нашего чат-бота QA:

Шаг 2: Теперь, когда у нас есть некоторые сгенерированные синтетические данные, мы можем определить наши метрики. Для этого примера мы будем использовать только две метрики: корректность и контекстную полноту.

(Ссылка на документацию по метрикам здесь)

Метрика корректности G-Eval сравнивает фактическую правильность фактических выходных данных с ожидаемыми выходными данными, в то время как контекстная полнота оценивает, содержит ли контекст поиска всю информацию, необходимую для генерации ожидаемых выходных данных для заданных входных данных. Также обратите внимание, что мы установили порог прохождения для каждой метрики на 0,6; это означает, что тестовый кейс будет пройден, если обе метрики наберут оценку выше или равную 0,6.

(PS: Прокрутите вверх и снова посмотрите диаграмму Chatbot QA, чтобы понять, какую часть системы LLM оценивает каждая метрика.)

Шаг 3: Имея готовый набор данных оценки и метрики, мы можем запустить бенчмарк. Мы не собираемся внедрять систему чат-бота QA, но предположим, что у нас есть гипотетическая функция run_chatbot_qa(), которая возвращает сгенерированный ответ и извлеченные узлы, используемые для генерации ответа:

Мы можем запустить бенчмарк, сначала преобразовав голдены, сгенерированные на шаге 1, в тестовые кейсы, готовые к оценке:

(Ссылка на документацию по датасету здесь)

И наконец, запустите свой бенчмарк, применяя к нашему набору данных две выбранные метрики:

Это было не так уж и сложно, верно?

Text-SQL — это сценарий использования, в котором система LLM генерирует соответствующий SQL-запрос для ответа на аналитический вопрос о данных, например, «Сколько пользователей зарегистрировалось на прошлой неделе»?

Мы собираемся повторно использовать ту же диаграмму архитектуры Text-SQL, что и в начале этой статьи:

Шаг 1: На этом этапе генерации данных мы будем создавать синтетические эталонные данные (goldens) с использованием таблиц данных в схеме базы данных.

Шаг 2: Мы будем использовать пользовательскую метрику корректности SQL и метрику контекстной полноты:

(Ссылка на документацию по метрикам здесь)

Подобно метрикам, используемым в чат-боте QA, метрика корректности SQL и контекстной полноты оценивает генератор запросов и конвейер извлечения соответственно.

Шаг 3: Предположим, что у нас есть еще одна гипотетическая функция run_text_2_sql(), которая возвращает сгенерированный SQL-запрос и извлеченную таблицу, использованные для его генерации:

Мы можем запустить бенчмарк, сначала преобразовав голдены, сгенерированные в шаге 1, в тестовые кейсы, готовые к оценке:

(Ссылка на документацию по датасету здесь)

И наконец, запустите свой бенчмарк, применяя к нашему набору данных две выбранные метрики:

Поздравляем вас с тем, что вы дошли до этого момента! В этой статье мы узнали разницу между LLM и системами LLM и как мы можем оценивать их разными методами.

Мы познакомились с методами оффлайн-оценки, включая концепцию бенчмаркинга с использованием пользовательских наборов данных и метрик для регрессионного тестирования систем LLM, и рассмотрели, как инструмент DeepEval поддерживает весь цикл оценки. Мы также подчеркнули важность регулярного обновления наборов данных для бенчмаркинга и рассмотрели, как оценки в реальном времени в продакшене могут способствовать этому процессу. И наконец, мы подробно разобрали два распространённых сценария применения систем LLM — чат-бот для вопросов и ответов (Chatbot QA) и генерацию SQL-запросов (Text-to-SQL) — и изучили подходы к их оценке.

Автор оригинала: Jeffrey Ip

#llm #text_to_sql #deepeval #бенчмарки #бенчмаркинг #g_eval #rag #text_sql #chatbotQA