Как измерить успех вашей системы базирующейся на RAG LLM

Как оценить эффективность вашей системы на основе метода RAG LLM

Используйте машины для оценки машин

Включая новый романический метод оценки ответов с качественными баллами и подробным объяснением.

Изображение, созданное Stable Diffusion XL

Исследование усовершенствованный генерации, или RAG, является, безусловно, самым распространенным случаем использования крупных языковых моделей (LLMs), которые появились в этом году. Хотя краткое содержание и генерация текста часто являются основной задачей отдельных пользователей, бизнесы понимают, что им нужна возможность использовать свои данные для использования этой технологии. Отражаясь на том, как я все еще использую LLM, генерация текста занимает одно из ведущих мест в списке. Я хочу задавать вопросы Барду и пусть он ищет информацию в Интернете; Я хочу, чтобы Клод переписывал почту или блоги для улучшения моего контента. Но самое захватывающее, что мне пришлось встретить, – это подача собственных данных в LLM. Я хочу искать свои заметки, письма, календарь и сообщения в Slack и позволить Лламе функционировать как я (но как я, который может помнить детали того, что произошло до сегодня).

Это не статья о том, как создать RAG (подобных уже много… и я работаю над статьей на эту тему на другой день). То, что мы будем рассматривать сегодня, – это как оценивать системы RAG.

Как мы получаем данные из RAG?

Давайте начнем с уровня, прежде чем мы углубимся в детали. Когда мы говорим о RAG, мы имеем в виду две части системы.

Источник знаний

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

LLM

После того, как у нас есть наши данные, мы их передаем в LLM. Это происходит через контекстное окно. Итак, в конечном итоге мы ищем, получаем некоторый текст, помещаем этот текст в подсказку и передаем вопрос в LLM. Модель затем берет все из этого контекстного окна и дает ответ.

Почему это важно?

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

Эти источники знаний имеют некоторые встроенные ограничения. Например, при использовании векторных баз данных для хранения больших текстовых файлов, вы должны “расчленить” входящие данные. Что это означает? Предположим, у вас есть документ в 100 страниц, но база данных может сохранять только по 1 странице за раз. Когда вы загружаете свои документы и делаете поиск, база данных может рассматривать только одну страницу за раз (хорошо, это немного упрощено, но давайте простимся; это достаточно уместно для государственных работ). Когда мы находим данные, которые соответствуют нашему запросу, есть реальная возможность того, что полный ответ на наш вопрос не находится на одной странице. К сожалению! Мы получаем только одну страницу! Это хороший пример того, почему нужно исследовать эту часть системы, прежде чем беспокоиться об выводе из LLM.

Что нам нужно оценить?

Это не будет ответом, который большинство технологов хотят услышать. Для оценки результатов из вашего источника знаний потребуется определенный уровень человеческой оценки. Почему? Хорошо, если бизнес использует свои данные и они являются конфиденциальными, будет сложно автоматизировать тесты, чтобы проверить, что результаты поиска абсолютно точны. Не паникуйте, это не обязательно должно быть 100% ручным; мы можем автоматизировать часть этого процесса. Давайте углубимся немного.

Я вижу два подхода к этой первоначальной проверке и оценке.

Первый вариант – иметь набор общих и ожидаемых вопросов для набора данных и позволить команде QA проверить результаты поиска. Например, если вашей команде поручено создать бота с вопросами и ответами для обслуживания клиентов банка, некоторые общие вопросы могут быть такими, как “Какая минимальная сумма требуется хранить на моем счету?”, “Как я могу сделать платеж по кредиту?”, “Во сколько открыто мое отделение?”. Идеально, если ваша команда QA может предоставить как вопросы, так и ожидаемые ответы, например, в файлах CSV, которые можно прочитать программно; затем мы можем использовать некоторые из наших автоматических тестов, о которых мы подробнее расскажем в этом посте.

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

Оценка ответов LLM

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

Оценка этого шага аналогична оценке поиска перед ним. Если команды QA могут предоставить вопросы и ожидаемые ответы, мы можем попытаться программно оценить эти ответы.

Давайте теперь рассмотрим некоторые из этих вариантов.

Фреймворки оценки

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

Мы не будем рассматривать способы оценки базового LLM. Есть такие вещи, как ARC, MMLU, HellaSwag и другие, которые нацелены на базовую языковую модель. Вам не нужно запускать эти измерения самостоятельно; вы можете проверить такие сайты, как https://llm-leaderboard.streamlit.app/ и https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderboard, чтобы увидеть, какая модель куда лучше справляется. Нас интересует только измерение результатов, которые мы получаем с систем RAG.

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

!pip install evaluate --quiet!pip install rouge_score --quiet!pip install importlib-metadata --quiet!pip install datasets==2.10.1 --quiet !pip install git+https://github.com/google-research/bleurt.git --quiet!pip install sacrebleu --quiet!pip --no-cache-dir install bert_score==0.3.9 --quiet!pip install sacremoses --quiet!pip install jiwer==2.5.1 --quiet!pip install Cython import evaluate# Если у вас есть корпус переводов и корпус эталонов:predictions = ["В Dungeons & Dragons металлические драконы находятся в латунной, бронзовой, медной, золотой и серебряной разновидностях. У каждого из них чешуйки соответствуют их названию - у латунных драконов латунные чешуйки, у бронзовых - бронзовые и т. д. Металлические драконы в целом нейтральнее по отношению к хроматическим драконам в мифологии D&D."]references =["""В пятой редакции Monster Manual (2014) появились пять основных хроматических драконов (красный, синий, зеленый, черный и белый) и металлические драконы (медный, латунный, серебряный, золотой и бронзовый) в возрасте малыша, молодого, взрослого и древнего. Драгоценные драконы и другие новые драконы для пятой редакции появились в Fizban's Treasury of Dragons (2021)"""]

ROUGE (Recall-Oriented Understudy for Gisting Evaluation)

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

#predictions (список): список предсказаний для оценки. Каждое предсказание должно быть строкой с токенами, разделенными пробелами.
#references (список или список [список]): список рефератов для каждого предсказания или список нескольких рефератов для каждого предсказания. Каждый реферат должен быть строкой с токенами, разделенными пробелами.
#rouge_types (список): Список типов ROUGE для вычисления. По умолчанию ['rouge1', 'rouge2', 'rougeL', 'rougeLsum'].
#Доступные типы ROUGE:
##"rouge1": оценка на основе униграмм (1-граммов)
##"rouge2": оценка на основе биграмм (2-граммов)
##"rougeL": оценка на основе наибольшей общей подпоследовательности
##"rougeLSum": разделение текста с использованием "\n"
#use_aggregator (логическое значение): Если True, возвращает агрегированные результаты. По умолчанию True.
#use_stemmer (логическое значение): Если True, использует стеммер Porter для удаления суффиксов слов. По умолчанию False.
rouge = evaluate.load('rouge')
results = rouge.compute(predictions=predictions, references=references, use_aggregator=False)
print(results)

{'rouge1': [0.3636363636363636], 'rouge2': [0.06185567010309278], 'rougeL': [0.22222222222222224], 'rougeLsum': [0.22222222222222224]}

BLEU (Bilingual Evaluation Understudy)

BLEU – это метрика для автоматической оценки вывода машинного перевода. Она основана на точности n-грамм кандидатского перевода по отношению к набору рефератов.

#predictions (список строк): Переводы для оценки.
#references (список списков строк): рефераты для каждого перевода.
#max_order (целое число): Максимальный порядок n-грамм для вычисления оценки BLEU. По умолчанию 4.
#smooth (логическое значение): Применять ли сглаживание Lin et al. 2004. По умолчанию False.
#bleu (число): оценка BLEU
#precisions (список чисел): геометрическое среднее точности n-грамм
#brevity_penalty (число): штраф за краткость
#length_ratio (число): соотношение длин
#translation_length (целое число): длина перевода
#reference_length (целое число): длина реферата
bleu = evaluate.load("bleu")
results = bleu.compute(predictions=predictions, references=references, max_order=4)
print(results)

{'bleu': 0.07342349837092484, 'precisions': [0.4262295081967213, 0.11666666666666667, 0.03389830508474576, 0.017241379310344827], 'brevity_penalty': 1.0, 'length_ratio': 20.333333333333332, 'translation_length': 61, 'reference_length': 3}

BLEURT (BLEU Regression with Transformers)

BLEURT – это метрика оценки генерации естественного языка (NLG). Она основана на использовании BERT, что позволяет BLEURT изучать статистические взаимосвязи между словами и фразами и идентифицировать узоры в выводе NLG.

BLEURT показал более высокую эффективность по сравнению с другими метриками оценки NLG, такими как BLEU и ROUGE, на различных задачах, включая машинный перевод, резюмирование и вопросно-ответную систему.

#output всегда является числом от 0 до (приблизительно 1). Это значение показывает, насколько сгенерированный текст похож на рефераты, с более близкими к 1 значениями, обозначающими более схожие тексты.
bleurt = evaluate.load("bleurt", module_type="metric")
results = bleurt.compute(predictions=predictions, references=references)
print(results)

{'scores': [0.6028875708580017]}

METEOR (Metric for Evaluation of Translation with Explicit ORdering)

METEOR – это автоматическая метрика оценки вывода машинного перевода. Она также имеет функции, которых нет в других метриках, такие как выделение основы слов, синонимичное сопоставление и точное сопоставление слов. Метрика была разработана для исправления некоторых проблем, с которыми сталкиваются более популярные метрики, такие как BLEU, и обеспечивает хорошую корреляцию с суждениями человека на уровне предложения или сегмента.

#прогнозы: список прогнозов для оценки. Каждый прогноз должен быть строкой с токенами, разделенными пробелами.#ссылки: список ссылок (в случае одной ссылки на прогноз) или список списков ссылок (в случае нескольких ссылок на прогноз). Каждая ссылка должна быть строкой с токенами, разделенными пробелами.#альфа: параметр для управления относительным весом точности и полноты. Значение по умолчанию - 0.9.#бета: параметр для управления формой штрафа в зависимости от фрагментации. Значение по умолчанию - 3.#гамма: относительный вес, назначенный штрафу за фрагментацию. Значение по умолчанию - 0.5.#выводы 0-1 - .317 это приемлемый scoremeteor = evaluate.load('meteor')results = meteor.compute(predictions=прогнозы, references=ссылки)print(results)

{'meteor': 0.19316493313521543}

Мне обещали что-то новое!

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

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

Во-вторых, это не говорит вам, почему оценка низкая. Это может быть из-за штрафа за повторение слов? Или из-за отсутствия некоторых слов? Или резюме вообще упустило важную часть ответа? Нет способа сказать.

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

Оценка LLM по LLM

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

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

prompt_data = """Человек: Вам нужно оценить резюмирование по шкале от 0 до 10, при этом 0 означает полное неверное и 10 - идеальное краткое изложение данного текста. Объясните, почему вы даете такую оценку. Дайте список основных различий между ссылкой и резюме. Я предоставлю текст ссылки, пометив REF:, и резюмирование для сравнения с SUMMARY:.REF:Базовые пять хроматических драконов (красный, синий, зеленый, черный и белый) и металлические драконы (медный, латунный, серебряный, золотой и бронзовый) появились в Монстр-руководстве пятого издания (2014 год) в щенковом, молодом, взрослом и древнем возрасте. Драконы-драгоценности и другие новые для пятого издания драконы появились в Кладовом сокровище Физбена (2021 год)SUMMARY:В Dungeons & Dragons металлические драконы представлены разновидностями: латунными, бронзовыми, медными, золотыми и серебряными. Каждый имеет чешуйки, соответствующие своему названию: латунные драконы имеют латунные чешуйки, бронзовые - бронзовые и т.д. Металлические драконы, как правило, природы более благоприятны, чем хроматические драконы в D&D.Assistant:"""

Оценка: 5/10Объяснение:Резюме содержит некоторую точную информацию о металлических драконах в D&D, например, перечисление основных видов и отметку о их более благоприятной природе по сравнению с хроматическими драконами. Однако оно не содержит множество ключевых деталей из ссылочного текста:- Не упоминает хроматических драконов (красный, синий, зеленый, черный, белый), описанных в тексте.- Не упоминает различные возрастные категории драконов (щенковый, молодой, взрослый, древний).- Не упоминает Монстр-руководство или Кладовое сокровище Физбена.- Только сфокусирован на металлических драконах, в то время как ссылочный текст содержал информацию о металлических и хроматических драконах.Основные различия:- Нет упоминания хроматических драконов- Нет упоминания возрастных категорий драконов- Нет упоминания Монстр-руководства или Кладового сокровища Физбена- Обсуждаются только металлические драконы, не полный охват ссылочного текста- Не передается информация о временной последовательности введения драконов в книгах 5-го издания.

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

Этот метод также дает нам отличное объяснение того, что было не так. В этом примере у меня был вопрос о том, какие виды драконов существуют во вселенной DND. Судейский LLM правильно определил, что в ответе не упоминаются хроматические драконы. Однако он также штрафовал ответ за отсутствие упоминания возрастов драконов, книги DND Monster Manual или приключенческого расширения. Эти пропуски не имели значения для вопроса, который я задал, но это позволяет командам по контролю качества принимать решение самостоятельно.

Куда мы идем дальше?

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

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

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