Привет, Хабр! Меня зовут Таня, я аналитик качества в команде Базы Знаний Just AI. Наша команда занимается разработкой продукта для клиентских баз знаний на основе RAG и созданием таких баз под ключ.
Одной из ключевых задач POC для наших заказчиков является оценка качества и точности ответов системы, а также выбор модели, которая обеспечит эти показатели. Чем точнее ответы, тем больше доверия к системе со стороны сотрудников/клиентов и меньше ручного труда по поиску доп.информации. 90% точности ответов — одно из основных требований большинства наших клиентов при выборе Базы Знаний. В этой статье я расскажу о том, как мы проводим оценку точности и выбираем правильную модель.
Статья получилась довольно объемной, поэтому оставлю навигацию по тексту:
Создание датасета для оценки качества
Общие правила по составлению синтетического и ручного датасета
Кейс «КНАУФ» (гибридный подход)
Промптинг для генерации
Выбор независимого LLM-судьи
Метрики для оценивания генерации LLM
Шкала оценивания
Модели-участники и результаты оценивания
Ну что, поехали?
Создание датасета для оценки качества
Для оценки качества генерации в 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 вопросов, который затрагивал две основные тематики: продукты и системы.
Особенность базы знаний КНАУФа — это профессиональная строительная терминология и названия продуктов с включениями из немецкого языка, например: КНАУФ Гольдбанд, КНАУФ‑Фуген Гидро, КНАУФ‑Сатенгипс, КНАУФ‑Перлфикс. Задача базы знаний — предоставить детальную информацию о характеристиках материалов, их применении и соответствующих стандартах, чтобы помочь клиентам принимать решения о выборе продукта.
Наш процесс тестирования качества ответов на датасете КНАУФ выглядел следующим образом:
Выбор LLM для генерации ответа на запрос;
Прогон вопроса через RAG с выбранной LLM, фиксация ответа;
Оценка качества ответа согласно выбранным метрикам.
Ниже я подробно расскажу о выборе метрик, судьи для оценивания и результатах нашего оценивания 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-архитектур и почему? С какими проблемами вы сталкивались при их использовании?
