Как тестировать AI-приложения: рубрики
Если вы используете одни LLM для оценки других, использование прилагательных в промптах — плохая идея. Вместо них лучше использовать рубрики. Давайте разберем это на примере из предыдущего поста.
Сценарий прежний: Клиент просит возврат денег, так как кроссовки пришли не того цвета.
Ответ бота: «Мне очень жаль! Обычно мы не возвращаем деньги, если вам не подошел цвет, но вот вам скидка 10%!»
Реальность: По правилам компании положен полный возврат.
Как составить рубрику для LLM-судьи:
Допустим, мы используем шкалу от 1 до 5, где 1 — максимально неподходящий ответ, а 5 — самый точный и вежливый. Вы должны четко прописать, как выглядят эти «1» и «5».
| Оценка | ❌ Плохо (размыто) | ✅ Хорошо (на основе метрик) |
| 1 | Ответ плохой. | Ответ содержит отказ в законном возврате или игнорирует ошибку доставки. |
| 3 | Ответ нормальный. | Ответ признает ошибку, но предлагает скидку вместо возврата средств. |
| 5 | Идеальный ответ. | Ответ четко идентифицирует ошибку доставки и инициирует 100% возврат согласно политике. |
Без четкой рубрики судья будет использовать свои внутренние «данные обучения» в качестве эталона. Если модель-судью учили быть вежливой, она поставит высокий балл боту, который «вежливо, но бесполезно» отказал клиенту.
Используйте Chain-of-Thought (CoT)
Заставляйте модель сначала обработать данные, прежде чем выносить вердикт. Это критически важно.
❌ Плохо: «Прочитай текст и поставь оценку».
✅ Хорошо: «1. Определи основную жалобу клиента. 2. Найди соответствующий раздел в Политике компании. 3. Сравни предложение бота с требованиями Политики. 4. Выставь оценку, основываясь ТОЛЬКО на этом сравнении».
В чем смысл? Это борется с предвзятостью поспешных выводов. Если вы просите оценку сразу, модель выбирает число, опираясь на «вайб» (ощущения), а затем галлюцинирует обоснование, чтобы подтянуть его под результат. Требование «показать ход решения» первым делом ведет к гораздо более высокой точности.
