Продолжаем серию о создании надежных LLM-продуктов. Сегодня наконец говорим про метрики качества.

Тема 7. Оцениваем качество LLM

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

Хорошие метрики качества == быстрые итерации. В ИИ-разработке, как и в обычной продуктовой разработке, успех зависит от того, как быстро вы умеете итерироваться. В разработке есть тестирование. А у нас есть метрики качества.

Понятно, что вас скорее всего волнуют пользовательские онлайн метрики. Желательно, деньги. Ну или retention пользователей. К сожалению, их долго мерить. Для быстрых итераций нам нужны оффлайн метрики качества, которые как-то аппроксимируют ваш целевой онлайн. Мы верим, что улучшая оффлайн метрики, в итоге наши пользователи будут нам благодарны.

Почему LLM сложно оценивать?

В ИИ есть 3 класса задач. В них по-разному делаются метрики качества.

1) Задачи, в которых есть точный ответ.
Тогда все ваши метрики качества это сравнение ответа модели с эталоном. Например, классификация, где вы сравниваете с правильным классом. Сравнивать можно не обязательно точным совпадением с эталоном. Можно, например, текстовыми метриками (BLEU, WER) или пускай сравнивает отдельная модель, например BERT (bert_score). В этом классе обычно проблем нет.

2) Задачи, в которых ответ можно проверить.
Ну тогда возьмите и проверьте :) Это, в первую очередь, код, который можно прогнать на тестах. Это математика, в которой можно проверить формальное доказательство. В этом классе раньше были проблемы, сейчас современный RL тут всех унижает. Посмотрите сколько компаний выигрывают одну и ту же олимпиаду по математике. Я уже сбился со счета.

3) Задачи, в которых правильный ответ хрен пойми какой.
С этим обычно самые трудности (интересно, блин, почему?)
Делаем RAG-ассистента, человек задает вопрос, мы что-то ответили. Ответить можно миллионом способов, верифицировать нельзя. Здесь обычно делают так:

а) Вырабатывают продуктовые критерии "а что такое хороший ответ"? Наш RAG-ответ должен быть релевантный, достоверный, актуальный.... Записывают эти критерии в виде инструкции.

б) Учат кого-то размечать ответы по этим критерии. Кого можно учить?

Размечаем людьми

Кто-то называет их ИИ-тренерами или асессорами. Популярно объясняете им ваши продуктовые критерии. Это объяснение может быть немного длинным: посмотрите пример 180-страничной инструкции оценки качества поиска Гугла. Дальше показываете им (запрос, ответ) и пускай пробуют разметить.

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

LLM-as-a-judge

У нас нет денег/времени работать с людьми. Делаем LLM, которая оценивает ответы другой LLM. Критиковать чужой труд всегда проще :)

Обычно делается в несколько этапов

1) Собираем датасет правильных оценок. Это когда у разных ответов LLM проставлены метки: релевантный ли там ответ, достоверный ли ответ и тд. Здесь важно получить не очень большой, (можно 100 примеров) но чистый набор данных.

2) Записываем все наши продуктовые критерии в виде промпта. Он может быть очень длинным, нестрашно.

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

Для несложных разметок завести LLM-as-a-judge обычно получается. Для чего-то супер сложного/экспертного, лучше обращаться за помощью к людям.

Литература для обязательного изучения

- Подробный гайд методи оценки качества в LLM

- Наглядная статья с примерами кода для LLM-as-a-judge

- Туториал, как делать LLM-as-a-judge


Правильные метрики — залог вашей счастливой и активной LLM-разработки. Отнеситесь очень внимательно. А если в чем-то сомневаетесь — пишите в комментарии или в личные сообщения @seva_batareika

#llm_system_design