Оценивание LLM в RAG на клиентских и синтетических датасетах: методология и результаты

Меня зовут Таня, я аналитик качества в команде Базы Знаний Just AI. Наша команда занимается разработкой продукта для клиентских баз знаний на основе RAG и созданием таких баз под ключ.

Одной из ключевых задач POC для наших заказчиков является оценка качества и точности ответов системы, а также выбор модели, которая обеспечит эти показатели. Чем точнее ответы, тем больше доверия к системе со стороны сотрудников/клиентов и меньше ручного труда по поиску доп.информации. 90% точности ответов — одно из основных требований большинства наших клиентов при выборе Базы Знаний. В этой статье я расскажу о том, как мы проводим оценку точности и выбираем правильную модель.

Статья получилась довольно объемной, поэтому оставлю навигацию по тексту:

1. Создание датасета для оценки качества

2. Общие правила по составлению синтетического и ручного датасета

3. Кейс «КНАУФ» (гибридный подход)

4. Промптинг для генерации

5. Выбор независимого LLM-судьи

6. Метрики для оценивания генерации LLM

7. Шкала оценивания

8. Модели-участники и результаты оценивания

Ну что, поехали?

Создание датасета для оценки качества

Для оценки качества генерации в RAG часто берется синтетика – то есть вопросно-ответные пары по документам, сгенерированные с помощью LLM. Например, классический промпт для генерации вопросов и ответов может выглядеть так:

Преимущество синтетического датасета – простота и скорость создания, возможность почти мгновенного формирования N-ного количества вопросов по каждому документу. Такие вопросы хороши для базовой проверки настроек RAG, но высокое качество ответов на них не гарантирует, что система также хорошо справится с вопросами от реальных пользователей. Причина кроется в очевидном недостатке синтетического датасета – его излишней стерильности: вопросы в нем слишком точные и правильные, как по билетам на экзамене.

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

Итоговый выбор между синтетическим и клиентским датасетом остается за разработчиком базы знаний и зависит от ресурсов и возможностей как команды разработки, так и заказчика. 

Общие правила по составлению как синтетического, так и ручного датасета

• Тематики вопросов должны быть максимально разнообразными;

• Если в документации есть аббревиатуры, сокращения или названия продуктов, в датасет нужно добавлять вопросы с ними (например, на объяснение сокращения, расшифровку названия, написание транслитом);

• Можно включать вопросы с ошибочными написаниями и опечатками (например, «настроить Фейс Ауди» вместо «настроить Фейс Айди»);

• Использовать как простые вопросы типа «Что такое кредит?», так и более сложные: описательные, на ризонинг, на сравнение;

• Добавлять неформально сформулированные вопросы. Пример от клиента: «Не могу найти, можете написать биг (бин) банка?»;

• Добавлять вопросы с подвопросами. Пример от клиента: «Мне перевели деньги 1000 где они. Как снять арест. Где мои деньги?»;

• Вопросы с поддержкой диалога: «Здравствуйте как взять кредит на 200к? а на 300?».

По нашей оценке оптимальное количество вопросов в датасете – от 100-200 до 500. Если требуется более детальная проверка качества, то рекомендуемое количество задается формулой ‘3-5 * число документов’ или же ‘2-3 вопроса * число чанков в базе знаний’. Важно отметить, что оптимальное число также может зависеть от размера документа/чанка, объема и содержания текста. Число вопросов на документ/чанк можно увеличить, если в документ много пунктов, которые хотелось бы проверить. Так один из наших клиентов предоставил датасет размером в 2000 вопросов. Процент качества на нем был примерно равен тому, что мы получили на сэмпле 200 вопросов, но с помощью такого объема мы смогли точнее оценить, на каких тематиках и продуктах наше решение «проседало». Кстати, вот и сам кейс.

Кейс «КНАУФ»

Чтобы оценить и продемонстрировать качество генерации ответов LLM на нашем пайплайне, мы выбрали базу знаний и датасет с вопросами от нашего клиента «КНАУФ». 

Первые тесты Базы Знаний показали существенное улучшение показателей знаний бота, поэтому в рамках оптимизации проекта «КНАУФ» мы предложили перевести классического FAQ-бота на паттернах на новую архитектуру – с RAG и LLM.

В первой итерации проекта в базе было 125 документов итоговым объемом 491 Мб, 2.9 млн символов или 400к слов. Во второй итерации к изначальной базе добавилось 40 документов (140к символов) по 8 новым продуктам. Для первичной проверки качества с нашей стороны был сгенерирован датасет на 320 вопросов, а от заказчика бы предоставлен тестовый датасет на 456 вопросов, который затрагивал две основные тематики: продукты и системы. 

Особенность базы знаний КНАУФа – это профессиональная строительная терминология и названия продуктов с включениями из немецкого языка, например: КНАУФ Гольдбанд, КНАУФ-Фуген Гидро, КНАУФ-Сатенгипс, КНАУФ-Перлфикс. Задача базы знаний – предоставить детальную информацию о характеристиках материалов, их применении и соответствующих стандартах, чтобы помочь клиентам принимать решения о выборе продукта.

Наш процесс тестирования качества ответов на датасете КНАУФ выглядел следующим образом:

1. Выбор LLM для генерации ответа на запрос;

2. Прогон вопроса через RAG с выбранной LLM, фиксация ответа;

3. Оценка качества ответа согласно выбранным метрикам.

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

Промптинг для генерации

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

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

Сам промпт состоит из шагов по генерации ответа. Помимо базовых правил формирования ответа, в промпты к LLM мы также включали: 

• Комментарии, пожелания клиента по стилю коммуникации;

• Дополнительные подсказки и комментарии, например, по ассортименту продуктов клиента;

• Особенности ответа, связанные с каналами публикации базы знаний: например, указание про отсутствие разметки ответа из-за особенностей канала публикации.

Выбор судьи

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

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

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

В качестве модели-судьи для всех кейсов мы использовали GPT-4o с единственным исключением в виде оценки самой GPT-4o и GPT-4o-mini. Модель-судью не желательно использовать для оценки самой себя, так как в таком случае со стороны судьи в сторону самой себя возможны предвзятость и завышенные оценки. Поэтому для оценки семейства моделей OpenAI мы использовали модель, которая по текущим бенчмаркам считается более «умной» – claude-sonnet-3.7.

Метрики для оценивания генерации LLM

В качестве метрик оценки качества генерации мы использовали:

• Answer correctness (корректность ответа): насколько корректен полученный ответ в сравнении с референсным, переданы ли основные факты и искажены ли они.

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

• Answer Relevance (соответствие ответа вопросу): насколько хорошо ответ соответствует заданному вопросу, содержит ли ответ нерелевантную или избыточную информацию.

• Response Time (время ответа): время, за которое модель обработала запрос. 

Шкала оценивания

Так как оценка качества через LLM часто является субъективной, для гарантии воспроизводимости результатов и одинаковой интерпретации оценки со стороны модели мы тестировали две шкалы – от 1 до 10 и от 1 до 5. 

В рамках эксперимента мы 3 раза повторили оценку на одинаковых 100 вопросно-ответных парах, используя две шкалы. Цветом на гистограмме выделены 3 попытки оценки. На оси X отображена сама оценка, а на оси Y – количество раз, которое модель-судья использовала эту оценку. Таким образом, график показывает, как варьируется частота одной и той же оценки между оцениваниями. Сильная вариация в частоте одной оценки между тремя тестами указывает на нестабильность оценщика. 

Визуализация результатов для шкалы от 1 до 10:

При такой шкале разница в средних значениях между попытками достигает всего 0.06, но при этом на графике хорошо видно, что наибольшая разница в частоте оценки наблюдается у значений 6, 8 и 9. Интерпретация результатов как для модели, так и для человека усложнена: как корректно и точно объяснить разницу между близкими значениями 6 и 7, 8 и 9? При такой детализированной шкале также возникает риск, что модель-оценщик будет слишком «размывать» свои оценки, выбирая промежуточные значения, которые не отражают реального качества модели.

Визуализация результатов для шкалы от 1 до 5:

При шкале от 1 до 5 результаты также отличаются, но количественно разница выражена слабее, то есть такая шкала воспринимается моделью-судьей более однозначно, чем шкала от 1 до 10.

Получается, что чем больше вариантов оценивания, тем выше вероятность того, что модель будет по-разному интерпретировать градации шкалы и оценивать по-разному даже одни и те же данные. По этой причине мы решили остановиться на выборе шкалы 1-5, а не 1-10.

Результаты оценивания

Модели-участники

В нашем оценивании участвовали 19 моделей из 7 различных семейств: OpenAI, Qwen, LLama, Claude, DeepSeek, Gigachat, YandexGPT и T-tech. Полный список моделей можно увидеть ниже:

• GPT-4o mini;

• GPT-4o;

• vllm-Qwen2.5-32B-Instruct-fp8-dynamic-proto;

• vllm-qwen2.5-72b-awq;

• t-tech-T-lite-it-1.0;

• t-tech-T-pro-it-1.0;

• vllm-llama3.1-70b-4q;

• DeepSeek-R1-Distill-Qwen-32B-prototype;

• Claude 3.5 Sonnet;

• Claude 3.7 Sonnet;

• GigaChat Lite;

• GigaChat 2 Lite;

• GigaChat Pro;

• GigaChat 2 Pro;

• GigaChat MAX;

• GigaChat 2 MAX;

• YandexGPT 4 Lite;

• YandexGPT 4 Pro;

• YandexGPT 5 Pro.

Интеграция с моделями обеспечивалась с помощью нашей MLOps-платформы Caila, которая, может обращаться к моделям напрямую по внутреннему API, если они хостились на серверах нашей компании или же вызывать и использовать стороннее решение – OpenRouter.

Описание результатов

Для демонстрации результатов оценки мы выбрали два варианта визуализации:

1. Box-plot

По «ящикам с усами» мы можем видеть распределение оценок – квартильные, средние и медианные значения. В цветном прямоугольнике находятся данные между 2-и и 3-м квартилями, зеленым треугольником отмечено среднее, красная линия – это медиана, а круги внизу или вверху – выбросы, то есть статистически более редкие значения. Если медианы внутри прямоугольника нет, значит, она совпала с одним из квартилей.

При интерпретации метрик Answer Correctness, Faithfulness и Answer Relevance можно сказать, что чем уже прямоугольник, тем чаще модель получала одинаковые оценки – в нашем контексте это значит, что тем более однородные по качеству ответы. И наоборот – чем прямоугольник шире, тем более значения разбросаны (=разные оценки ответов). Если прямоугольник небольшой площади и расположен ближе к вершине графика, значит, испытуемая модель стабильно качественно отвечает на вопросы из датасета. Полное отсутствие прямоугольника и медиана напротив значения ‘5’ означает, что оценки между 1-м и 3-м квартилями оказались одинаковыми – только ‘5’. 

Что касается метрики Response Time, то чем ниже прямоугольник, а также его среднее и медианное значения, тем меньше время ответа и тем лучше для клиента. По графику хорошо видно, что наибольшие задержки наблюдались у модели DeepSeek-R1, а наивысшая скорость ответа – у GPT-4o, GigaChat Lite и GigaChat 2 Lite.

2. Столбчатая диаграмма

При визуализации результатов по 5-бальной шкале у многих моделей межквартильный размах был очень низкий, так как большинство оценок оказались ‘5’. Многие «ящики с усами» оказались представлены в виде одной линии с множеством выбросов. В таком случае сравнить оценки моделей оказывается довольно трудно.

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

Оценки от 1 до 5 выделены цветами и отмечены справа на легенде.

Answer Correctness

Диаграмма показывает, что наибольшее число полностью правильных ответов у модели Claude-sonnet-3.7, а наибольшее число полностью ошибочных – у YandexGPT5-Pro и YandexGPT4-Pro. 

Здесь стоит отметить, что большое число низких оценок (51 и 49 соответственно) у обеих моделей YandexGPT связано с внутренним цензором модели, из-за которого модель отказывалась отвечать на вопрос.

Faithfulness 

Наиболее достоверные модели – Claude-3.7-sonnet, Claude-3.5-sonnet, T-pro, GPT-4o, GPT-4o-mini и Gigachat 2 MAX, а наибольшее число галлюцинаций или ответов не по документации можно отметить у YandexGPT 4 Pro, YandexGPT 4 Lite, YandexGPT 5 Pro и Gigachat Lite.

Answer Relevance

Наиболее релевантные ответы – у GigaChat 2 MAX, а вот неожиданный анти-лидер по количеству ответов с высшей оценкой ‘5’ – claude-sonnet-3.7. При анализе оценок мы заметили, что сниженные оценки эта модель получила из-за большого объема деталей в своих вопросах: она отвечает по тематике вопроса пользователя, но при этом старается рассказать как можно больше об альтернативных продуктах или, например, рассказать подробнее о материале продукта, хотя в вопросе нет такого требования. Модели YandexGPT получили большое число низких оценок по той же причине, что и выше – из-за цензуры некоторых вопросов.

Вместо заключения

Итоговым выбором LLM для проекта оказалась GPT-4o-mini: она показала достаточно хорошие результаты по всем трём метрикам качества, а её среднее и медианное время ответа не превышало 10 секунд. Качество ответов этой LLM сравнимо с GPT-4o, но стоимость использования этой модели при этом гораздо ниже.

Будет здорово, если в комментариях вы поделитесь своим опытом. Какие метрики вы используете для оценки точности RAG-пайплайнов в ваших проектах? Какие модели вы считаете наиболее подходящими для RAG-архитектур и почему? С какими проблемами вы сталкивались при их использовании?