Как оценить качество LLM-системы: тестовый набор и метрики

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

Всё это можно сделать самим за несколько недель, без подрядчика и без специальных платформ: хватит таблицы, нескольких часов экспертов и скрипта, который прогоняет вопросы через систему. Ниже порядок работы, пример условной системы и список способов обмануть самого себя. Услуга по построению такой оценки описана на странице «Оценка качества LLM-систем».

Что считать качеством: три вопроса до набора

Оценка без ответов на эти вопросы превращается в подсчёт «нравится или нет».

1. Что в вашей работе считается ошибкой. Неверный факт, неверное действие, отсутствие ответа там, где он есть, ответ там, где его быть не должно.
2. Сколько стоит каждая ошибка. Неточность в справочной подсказке сотрудника и неверная сумма в документе для оплаты не равны по цене.
3. Кто решает, что ответ верен. У каждой категории вопросов должен быть эксперт, чьё слово окончательно.

Ответы удобно записать таблицей. Она задаёт и категории набора, и пороги приёмки.

Пример условный и показывает приём: ассистент отвечает сотрудникам по внутренним регламентам. Для вашей системы строки будут другими.

Шаг 1. Соберите случаи для набора

Главный источник вопросов — журнал реальных обращений: почта к методологам, чат с поддержкой, заявки. Обезличьте его и возьмите вопросы так, как их задают, с опечатками и обрывками. Если журнала нет, начните с вопросов, которые экспертам задают чаще всего, но заменяйте их настоящими, как только они появятся.

В набор обязательно включите четыре группы:

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

Одна строка набора — один случай со следующими полями:

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

Шаг 2. Опишите, что такое хороший ответ

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

Условный пример для вопроса «За сколько дней нужно подать заявление на отпуск»:

• названо правило из действующего регламента, а не из старой версии;
• срок назван так, как он указан в документе;
• если правило зависит от вида отпуска, система спросила уточнение или перечислила варианты;
• есть ссылка на пункт регламента;
• нет сведений, которых в документе нет.

Каждый критерий проверяется ответом «да» или «нет». Шкала «от одного до пяти» без описания уровней даёт у разных экспертов разные оценки. Итог ответа складывается из критериев: верно, если выполнены все обязательные; частично, если не выполнен необязательный; неверно, если нарушен обязательный.

Шаг 3. Выберите, кто оценивает ответы

Способы дополняют друг друга. Дешёвые проверки отсеивают очевидное, дорогие смотрят то, что остальные не умеют.

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

Шаг 4. Посчитайте так, чтобы цифры что-то значили

Базовый результат — таблица по категориям: доля верных, частичных, неверных ответов и отказов. Дальше несколько правил чтения.

• Не усредняйте категории. Среднее по набору скрывает слабую категорию. Дорогие ошибки учитываются в отдельных строках.
• Поиск и ответ считайте раздельно, если система ищет по документам. Иначе непонятно, чинить поиск или шаблон запроса.
• Отказы считайте отдельно в обе стороны. Доля вопросов без ответа в базе, на которые система честно отказала, и доля вопросов с ответом, на которые она отказала зря.
• Обязательные нули. Чужие данные, выдуманная ссылка, действие без подтверждения: один случай означает «не принято», как бы ни выглядело среднее.
• Смотрите на разницу попарно. При сравнении двух версий важны случаи, где одна стала лучше, а другая хуже, а не только итоговая сумма.

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

Порог уверенности модели, который отправляет сомнительные ответы человеку, настраивается по тому же набору, подробнее в статье «Порог уверенности модели».

Шаг 5. Разберите ошибки и найдите, что менять

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

Каждая разобранная ошибка превращается в строку набора с пометкой «из эксплуатации». Так набор растёт там, где система слабее всего.

Шаг 6. Сделайте оценку повторяемой

Единичный замер устаревает в день первого изменения. Чтобы оценка работала, прогон должен запускаться сам при смене модели, шаблона запроса, индекса, порога или зависимостей, а результат сравниваться с предыдущим по тем же случаям. Для этого нужны версии всего перечисленного в журнале и скрипт, который выдаёт таблицу по категориям.

После запуска добавьте две вещи. Первая: выборочный просмотр реальных ответов человеком, раз в согласованный срок. Вторая: правки операторов и жалобы пользователей идут в набор. Слежение за самой моделью в работе (дрейф, версии, откат) описано в статье «Как следить за моделью в продакшене».

Пять способов обмануть самого себя

• Настраивать по контрольному набору. Цифры растут, а качество на живом потоке нет. Контрольную часть открывают один раз, для финального замера.
• Брать вопросы из документов. Они повторяют язык документа и слишком лёгкие. Живые вопросы формулируются иначе.
• Оценивать моделью той же семьи без сверки с людьми. Судья одобряет собственный стиль.
• Считать одну цифру. Средняя точность выглядит приемлемо, пока не посмотришь на категорию с дорогой ошибкой.
• Оценивать один раз. После первой правки шаблона замер перестаёт описывать систему.

Если система критична, обязательно проверьте и безопасность, не только качество: этому посвящён чек-лист безопасности LLM-системы перед запуском.

Что делаем мы и с чего начать

Начинаем с обследования: 200 000 ₽ и 2–3 недели за одну систему, 350 000 ₽ и 3–4 недели при нескольких системах. На выходе образец набора, критерии приёмки, схема оценщиков и вилка бюджета. Сумма вычитается из первого этапа, если продолжаете с нами; документом можно пользоваться и без нас. Затем при необходимости лёгкий пилот: рабочий и контрольный наборы, замер по категориям и разбор ошибок.

Мы строим набор из ваших вопросов, считаем в вашем контуре и оставляем вам код прогона с первого коммита; можем оценить и систему, сделанную не нами. Мы не обещаем безошибочности и не проводим аттестацию, лицензии ФСТЭК у нас нет. Цены и сроки по всем ступеням — на странице «Тарифы», описание услуги — на странице «Оценка качества LLM-систем».