Метрики оценки LLM: полное руководство по оценке LLM

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

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

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

Вот наиболее важные и общие метрики, которые вам, скорее всего, понадобятся перед запуском вашей системы LLM в производство:

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

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

Отличными метриками оценки являются:

Таким образом, возникает вопрос, как метрики оценки LLM могут обеспечивать одновременно надежные и точные показатели?

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

В конце этого раздела мы рассмотрим каждый метод и поговорим о наилучшем подходе.

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

Вкратце:

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

Статистические методы оценки надежны, но недостаточно точны, так как не учитывают семантику. В этой категории всё наоборот — методы, полностью зависящие от NLP-моделей, более точны, но менее надежны из-за своей вероятностной природы.

Это неудивительно, но методы оценки, не основанные на LLM, показывают худшие результаты по сравнению с LLM-as-a-judge, по тем же причинам, что и статистические методы. Среди них:

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

Теперь перейдем к LLM-судьям.

G-Eval — это недавно разработанная структура из статьи под названием «Оценка NLG с использованием GPT-4 с улучшенным человеческим соответствием», которая использует LLM для оценки выходных данных других LLM, и является одним из лучших способов создания метрик, специфичных для задач.

Как было описано в одной из моих предыдущих статей, G-Eval сначала генерирует последовательность шагов оценки с использованием метода цепочки рассуждений (Chain of Thoughts, CoTs), а затем применяет сгенерированные шаги для определения итоговой оценки через парадигму заполнения формы (проще говоря, G-Eval требует нескольких компонентов информации для выполнения своей работы). Например, для оценки связности вывода LLM с помощью G-Eval необходимо составить запрос, включающий критерии и текст для оценки, чтобы сначала сгенерировать шаги оценки, а затем с помощью LLM вывести итоговый балл по шкале от 1 до 5, опираясь на эти шаги.

Рассмотрим алгоритм G-Eval на следующем примере. Чтобы сгенерировать шаги оценки:

Шаг 5 является необязательным, поскольку для получения вероятностей выходных токенов необходим доступ к эмбеддингам модели, который не всегда доступен во всех интерфейсах LLM. Однако этот шаг был введен в статье, так как он позволяет получить более точные оценки и минимизировать предвзятость при оценке с помощью LLM (в статье отмечено, что токен "3" имеет более высокую вероятность на шкале от 1 до 5).

Вот результаты из статьи, показывающие, как G-Eval превосходит все традиционные оценки, не основанные на LLM, упомянутые ранее:

G-Eval хорош тем, что являясь LLM-Eval, он способен учитывать полную семантику выводов, генерируемых LLM, что делает его значительно более точным. И это вполне логично — подумайте сами: как методы оценки, не основанные на LLM, которые используют значительно менее мощные инструменты, чем сами LLM, могут в полной мере понимать весь объем текста, созданного языковыми моделями?

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

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

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

Prometheus — это полностью открытый исходный код LLM, который сопоставим с возможностями оценки GPT-4, при условии предоставления соответствующих справочных материалов (эталонный ответ, шкала оценки). Как и G-Eval, Prometheus является независимой от конкретных задач системой. Эта языковая модель построена на базе Llama-2-Chat и дообучена на основе 100 тысяч отзывов, сгенерированных GPT-4 в рамках сбора обратной связи.

Вот краткие результаты исследовательской работы Prometheus.

Prometheus следует тем же принципам, что и G-Eval. Однако есть несколько отличий:

Prometheus доступен на Hugging Face.

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

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

Обе метрики — BERTScore и MoverScore — уязвимы к контекстуальной осведомленности и предвзятости из-за их зависимости от контекстуальных встраиваний, полученных из предварительно обученных моделей, таких как BERT. Но что насчет LLM-оценок?

В отличие от G-Eval, который напрямую выполняет задачу оценки с парадигмой заполнения форм, GPTScore использует условную вероятность генерации целевого текста в качестве метрики оценки.

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

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

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

QAG (Question Answer Generation) Score — это оценщик, который использует высокие возможноссти рассуждений LLM для надежной оценки выходных данных LLM. Он использует ответы (обычно «да» или «нет») на закрытые вопросы (которые могут быть сгенерированы или заранее заданы), чтобы вычислить итоговый балл метрики. Он надежен, потому что не использует LLM для прямой генерации оценок. Например, если вы хотите вычислить оценку за точность (что измеряет, был ли вывод LLM галлюцинированным или нет), вы бы:

Давайте разберем следующий пример выходных данных LLM:

Мартин Лютер Кинг-младший, известный лидер движения за гражданские права, был убит 4 апреля 1968 года в мотеле Lorraine в Мемфисе, штат Теннесси. Он был в Мемфисе, чтобы поддержать бастующих работников санитарной службы, и был смертельно ранен сбежавшим заключенным Джеймсом Эрлом Рэем, стоя на балконе второго этажа мотеля.

Утверждение будет выглядеть следующим образом:

Мартин Лютер Кинг-младший был убит 4 апреля 1968 года

А соответствующий закрытый вопрос будет следующим:

Был ли Мартин Лютер Кинг-младший убит 4 апреля 1968 года?

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

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

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

Например, если вы создаете чат-бота поддержки клиентов на основе RAG, а также на основе моделей GPT OpenAI, вам нужно будет использовать несколько метрик RAG (например, верность, релевантность ответа, контекстная точность), а если вы настраиваете свой собственный Mistral 7B, вам понадобятся такие метрики, как предвзятость, чтобы гарантировать беспристрастные решения LLM.

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

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

Вот как обычно выглядит рабочий процесс RAG:

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

Достоверность — это метрика RAG, которая оценивает, генерирует ли LLM/генератор в вашем RAG-пайплайне результаты, которые фактически соответствуют информации, представленной в контексте извлечения. Но какой оценщик нам следует использовать для метрики достоверности?

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

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

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

DeepEval рассматривает оценку как тестовые случаи. Здесь actual_output — это просто выходные данные LLM. Кроме того, поскольку достоверность — это оценка LLM, вы можете получить обоснование для окончательного рассчитанного балла.

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

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

(Помните, что мы используем QAG для всех метрик RAG)

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

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

Это, вероятно, самая простая для понимания метрика. Контекстная релевантность — это доля предложений в контексте извлечения, которые релевантны заданным входным данным.

Когда я говорю о метриках для дообучения (fine-tuning metrics), я имею в виду метрики, оценивающие саму LLM, а не всю систему. Если оставить в стороне стоимость и преимущества в производительности, LLM часто дообучают для того, чтобы:

Некоторые из вас могут заметить сходство этой метрики с метрикой достоверности. Хотя они действительно схожи, галлюцинации в контексте дообучения более сложны, так как часто сложно определить точную эталонную истину для конкретного вывода. Чтобы обойти эту проблему, можно воспользоваться подходом SelfCheckGPT, который в режиме zero-shot оценивает долю галлюцинированных предложений в выводе LLM.

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

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

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

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

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

Аналогично метрике токсичности, предвзятость можно оценивать с использованием G-Eval.

Предвзятость — это крайне субъективная категория, которая существенно варьируется в зависимости от географических, геополитических и геосоциальных условий. Например, язык или выражения, считающиеся нейтральными в одной культуре, могут иметь совсем другие коннотации в другой. (Именно поэтому методы оценки с использованием небольшого количества примеров (few-shot evaluation) плохо работают для анализа предвзятости.)

Одним из возможных решений может быть дообучение пользовательской языковой модели (LLM) для оценки или предоставление исключительно чётких критериев для обучения в контексте (in-context learning). По этой причине я считаю, что предвзятость — это самая сложная метрика для реализации.

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

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

Документацию по этой метрике можно найти здесь.

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

Вкратце, все хорошие резюме:

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

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

Поздравляю вас с тем, что вы дочитали статью до конца! Я надеюсь, что теперь вы знаете все различные факторы, которые вам необходимо учитывать, а также как выбрать метрики для оценки LLM.

Основная цель метрики оценки LLM — количественно оценить производительность вашего LLM (приложения), и для этого у нас есть различные оценщики, некоторые из которых лучше других. Для оценки LLM наиболее точными являются оценщики, использующие LLM (G-Eval, Prometheus, SelfCheckGPT и QAG), благодаря их высоким способностям к рассуждению, но необходимо принимать дополнительные меры предосторожности, чтобы убедиться в надежности этих оценок.

В конце концов, выбор метрик зависит от вашего случая использования и реализации вашего LLM-приложения, где метрики RAG и fine-tuning являются отличной отправной точкой для оценки выводов LLM. Для более специфичных метрик в зависимости от случая использования вы можете использовать G-Eval с few-shot prompting для наиболее точных результатов.

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

#llm #rag #bleu #rouge #meteor #g_eval #gptopenai #bertscore #moverscore #prometheus #deepeval #BLEURT #NLI #GPTScore #SelfCheckGPT #QAG