Оценка приложения на основе большой языковой модели (LLM), это систематическое тестирование до и после каждого изменения. В руководстве подробно описано, как выбрать методы оценки, создать надежного судью LLM, а затем оценивать системы RAG и агентов на протяжении всего цикла публикации.
Прочитать несколько ответов и найти их удовлетворительными недостаточно. Изменение промпта, смена модели или поиска документации может нарушить поведение незаметно, и потом сложно определить, какое изменение стало причиной. Оценка сводится к созданию тестовых случаев, оценке каждого ответа по письменным критериям и сравнению баллов до и после каждого изменения, по аналогии с регрессионным тестированием классического кода.
Ответы LLM варьируются от запуска к запуску, и понятие « правильного ответа » зависит от контекста. Модульный тест проверяет равенство, тогда как « Вы можете вернуть обувь в течение 30 дней » и « Возвраты принимаются в течение месяца после доставки », оба верны. Руководство различает оценку, которая измеряет относительное качество по нечетким критериям, и тесты, которые проверяют готовность к продакшену бинарными проверками, например, валидный JSON или отсутствие запрещенной формулировки. Блокировать развертывание из-за оценки точности в 0,7 было бы, по мнению автора, равносильно еженедельным спорам об произвольном пороге.
Три способа оценить ответ
Оценщик получает тестовый случай, состоящий из входных данных, ответа и иногда контекста или эталона, а затем возвращает вердикт или число. Оценщики кода применяют детерминированные правила для проверки формата, длины или наличия определенных строк. Оценщики на основе эталона сравнивают ответ с известным ответом. Метрики перекрытия, такие как BLEU и ROUGE, например, не распознают правильный перефраз. Наконец, судья LLM, это модель, задача которой применять сетку критериев к ответу другой модели, что полезно для оценки тона, опоры на источники или полезности.
Руководство рекомендует начинать с кода везде, где достаточно правила, поскольку такие оценщики ничего не стоят и всегда дают одинаковый результат. Описаны три конфигурации судьи: поточечная, когда он присваивает метку или оценку изолированному ответу; попарная, когда он выбирает лучший из двух ответов, что является распространенным методом сравнения двух промптов или двух моделей; и управляемая эталоном, когда у него есть эталонный ответ.
Как сделать судью надежным
Хорошо составленная сетка критериев определяет качество судьи. Руководство описывает ее в четырех частях: определение критерия, данные, которые судья может использовать, процедура, которой нужно следовать, и строгий формат вывода, предпочтительно JSON. Рассуждение должно предшествовать вердикту, а температура устанавливается на 0, чтобы уменьшить шум выборки, но не устранить его. Для чувствительных критериев руководство предлагает нечетное количество запусков и принятие вердикта большинства.
Метод QAG (генерация вопросов-ответов) требует от судьи отвечать на закрытые вопросы « да » или « нет », после чего расчет выполняется кодом. Таким образом, точность ответа из четырех утверждений, три из которых подтверждены, составляет 0,75. Для субъективных критериев метод G-Eval вычисляет средневзвешенное значение по вероятностям возможных оценок, так что модель, разделенная в соотношении 60/40 между 4 и 5, получает 4,4. В исследованиях по оценке выходных данных LLM задокументированы смещения: позиционное смещение, смещение в пользу многословия и смещение в пользу собственной модели для моделей одного семейства. Руководство предлагает менять порядок ответов, тестировать случаи сопоставимой длины и использовать судью из другого семейства моделей.
Калибровка остается самым важным этапом. Руководство советует самостоятельно разметить от 30 до 50 ответов, а затем сравнить эти метки с метками судьи с помощью коэффициента каппа Коэна, который корректирует согласие, обусловленное случайностью. Оценка 0 соответствует согласию на уровне случайности, а 1, идеальному согласию. При значении примерно выше 0,6 согласие обычно считается существенным.
RAG, агенты и цикл публикации
Система RAG (генерация с извлечением) объединяет два компонента, которые могут давать сбой по отдельности: поисковую систему, которая извлекает контекст, и генератор, который формулирует ответ. Руководство предлагает измерять точность контекста, его полноту, точность ответа относительно извлеченных документов и его релевантность вопросу. Высокая точность в сочетании с низкой полнотой, например, указывает на недостаточный поиск.
Для агентов руководство начинается с выполнения задачи, затем рассматривает корректность выбранного инструмента, корректность его аргументов и пройденную траекторию, без избыточных вызовов или циклов. Офлайн-оценки проводятся перед развертыванием в продакшен на версионированном наборе из 25-50 случаев с заранее установленными критериями публикации. Онлайн-оценки проводятся на выборке реального трафика. Каждый обнаруженный в продакшене сбой может затем стать эталонным тестовым случаем.
