Одной из самых популярных и широко используемых технологий на основе LLM является RAG. При разработке RAG-системы, как и при обучении ML-моделей, необходимо производить оценку качества ее работы. Это необходимо для настройки и тестирования системы, выявления проблем, а также понимания, какие компоненты системы нуждаются в доработке. При этом стоит отметить, что оценка качества RAG имеет свои сложности.
Никита Кравчук, ML-инженер в Embedika, рассказал, как измерить качество работы RAG-систем.
Ниже приводим текст оригинальной публикации.
Почему интерфейс важнее алгоритма
Одной из самых популярных и широко используемых технологий на основе LLM является RAG. Как известно, RAG-система состоит из двух основных частей: информационного поиска по базе знаний на основе пользовательского запроса и генерации ответа на основе найденных текстовых фрагментов, которые называют чанками.
КАРТИНКА
При разработке RAG-системы, как и при обучении ML-моделей, необходимо производить оценку качества ее работы. Это необходимо для настройки и тестирования системы, выявления проблем, а также понимания, какие компоненты системы нуждаются в доработке. При этом стоит отметить, что оценка качества RAG имеет свои сложности.
Во-первых, при оценке необходимо учитывать, что нет единственно правильного ответа на заданный пользовательский запрос и ответ, сгенерированный RAG-системой, может быть оценен по различным критериям.
Во-вторых, как было сказано выше, RAG-пайплайн состоит из нескольких модулей, каждый из которых подвержен ошибкам, вследствие чего вычисляемые метрики должны отражать качество работы каждого модуля.
В-третьих, часто нет датасета, содержащего эталонные чанки и ответы, который можно было бы использовать при оценке RAG.
В этой статье будут рассмотрены некоторые из метрик, которые лежат в основе оценки RAG.
Классификация метрик для оценки RAG
Метрики для оценки RAG можно разделить на 2 большие группы: метрики, используемые для оценки качества поиска, и метрики, применяемые при оценке качества генерации. На схеме представлены метрики, которые будут затрагиваться в статье.
Оценка поиска
Для оценки поиска могут быть использованы классические метрики качества ранжирования, такие как:
- mean reciprocal rank (MRR);
- precision@k;
- average precision (AP@k);
- mean average precision (MAP@k);
- normalized discounted cumulative gain (nDCG@k);
- recall@k.
Основная сложность при использовании данных метрик заключается в том, что для их вычисления требуется эталонная разметка, отражающая релевантность чанков запросам из тестового датасета.
Рассмотрим подробнее каждую из метрик, для чего введем ряд обозначений. Пусть ri ∊ {0,1} – эталонная метка релевантности чанка, который после ранжирования поисковой системой в порядке убывания релевантности оказался на позиции i. Также обозначим за N общее количество чанков в базе знаний.
Для того чтобы найти значение метрики MRR необходимо усреднить обратные ранги RR по всем запросам. RR, в свою очередь, определяется позицией первого чанка, который релевантен запросу, и вычисляется согласно формуле:
КАРТИНКА
Недостаток MRR заключается в том, что в этой метрике не учитываются метки фрагментов, которые следуют за первым релевантным чанком. Для учета этих фрагментов может быть использована метрика precision@k, которая равна точности среди первых k чанков и может быть вычислена по формуле:
КАРТИНКА
Как видно из формулы, precision@k не учитывает порядок рассматриваемых чанков. Например, значение данной метрики будет одинаковым для случаев, когда среди k первых найденных чанков одно и то же количество релевантных запросу, но при этом в одном из случаев каждый из релевантных чанков расположен выше. Данный недостаток нивелирован в AP@k, которая вычисляется по формуле:
КАРТИНКА
Если усреднить AP@k по всем запросам в датасете, то будет получена метрика MAP@k.
Другим способом измерить качество поиска с учетом порядка релевантных чанков являются метрики DCG@k и nDCG@k. DCG@k вычисляется по формуле:
КАРТИНКА
Чем выше в поисковой выдаче расположены релевантные чанки, тем меньшее значение принимают логарифмы в знаменателях и тем большее значение имеет DCG@k. Стоит отметить, что DCG@k не нормирована, и ее максимальное значение зависит от запроса, так как разным запросам может соответствовать различное количество эталонных чанков. Если выполнить нормировку DCG@k с помощью максимального значения IDCG@k, которое соответствует идеальному ранжированию, будет получена метрика nDCG@k:
КАРТИНКА
Все рассмотренные выше метрики отражают точность поиска, но не показывают, насколько полной является поисковая выдача. Для этой цели служит метрика recall@k, которая представляет собой полноту и вычисляется согласно формуле:
КАРТИНКА
Оценка генерации
Вторая группа метрик применяется для измерения качества генерации. Метрики для этой цели выбираются исходя из того, может ли для решаемой задачи быть собран датасет эталонных ответов на запросы. Если такая возможность есть, в качестве простого варианта для измерения качества могут рассматриваться метрики BLEU и ROUGE. В их основе лежит сравнение n-грамм токенов, входящих в состав эталонного ответа и ответа, сгенерированного RAG-пайплайном. Рассмотрим, как вычисляются BLEU и ROUGE.
КАРТИНКА
Пусть ŷ – ответ, сгенерированный RAG-пайплайном, а y – эталонный ответ. Обозначим также за Ŝ=(ŷ1, ..., ŷM) датасет сгенерированных ответов, а за S=(y1, ..., yM) – соответствующие эталоны. Тогда BLEU можно определить с помощью точности на n-граммах pn и штрафа BP за краткость сгенерированных ответов следующим образом:
КАРТИНКА
где Gn(y) – множество уникальных n-грамм, сформированных из токенов текста y; C(s, y) – количество вхождений строки s в строку y; r – суммарная длина эталонных ответов; c – суммарная длина сгенерированных ответов; wn – веса, удовлетворяющие условиям:
КАРТИНКА
Как правило, рассматривают n-граммы при n от 1 до 4 и принимают веса равными 0,25.
Метрика ROUGE, в свою очередь, представляет собой точность, полноту и F-меру, которые вычисляются следующим образом:
КАРТИНКА
Также существует модификация ROUGE, в которой вместо сравнения n-грамм токенов находят наибольшую общую подпоследовательность токенизированных ответов ŷi и yi.
Стоит отметить, что BLEU и ROUGE плохо отрабатывают в случае, если RAG по входному запросу сформировал верный ответ, но в сравнении с эталонным ответом он сформулирован другими словами. Из-за этого эти метрики могут плохо отражать действительное качество RAG. Поэтому вместо BLEU и ROUGE могут применяться косинусная близость между сгенерированным и эталонным ответом и BERTScore, которые основаны на использовании эмбеддингов, получаемых с помощью модели-энкодера. Формулы для точности, полноты и F-меры BERTScore могут быть записаны в следующем виде:
КАРТИНКА
где |ŷ| и |y| – длины сгенерированного и эталонного ответа в токенах; ŷi– i-й токен сгенерированного ответа ŷ; yj – j-й токен эталонного ответа y; E(yj) и E(ŷi) – эмбеддинги токенов yj и ŷi.
Помимо вышеупомянутых метрик для оценки качества генерации может быть использован подход LLM-as-a-judge, при котором ответ, генерируемый RAG-системой, оценивается с помощью LLM. Для этого в промпте LLM указываются входные и выходные данные RAG-пайплайна, необходимые для оценки (например, пользовательский запрос и сгенерированный ответ), а также критерий оценивания и шкала. Шкала описывает баллы и случаи, при которых они присваиваются оцениваемым сэмплам. Далее, промпт подаётся на вход LLM, которая генерирует оценку и её обоснование.
КАРТИНКА
Подробнее о данном подходе будет рассказано в одной из наших следующих статей, где более детально рассмотрим механику работы LLM-as-a-judge.
Вывод
Оценка качества RAG является непростой задачей, которая требует применения нескольких метрик, позволяющих оценить RAG-пайплайн с разных сторон. Для оценки точности поиска с учетом порядка чанков могут быть использованы метрики MAP@k и nDCG@k, полноту же поиска отражает recall@k. Что касается оценки генерации, при наличии эталонных данных могут быть применены классические метрики, такие как BLEU, ROUGE и BERTScore, или более современный подход LLM-as-a-judge. При отсутствии эталонных ответов единственным вариантом из рассмотренных метрик остаётся LLM-as-a-judge.
