LLM-as-a-Judge (модель-судья) и QA-терминология

Если вы задумываетесь о переходе из QA в инженеры оценки качества ML, стоит начать с изучения основных концепций больших языковых моделей (LLM) и способов оценки их результатов.

Одна из ключевых идей здесь - оценка работы «младшей» модели с помощью «старшей» (вместо или вместе с проверкой человеком). Эту «старшую» модель называют LLM-as-a-Judge. Проще говоря, вы используете более мощную LLM в качестве автоматизированного асессора.

Традиционные ассерты из автотестов здесь не работают по двум причинам:

• Выходные данные недетерминированы, поэтому каждый тест априори будет «мигающим» (flaky).
• Крайне сложно прописать четкие критерии pass/fail, если мы имеем дело, например, с текстовой схожестью (text similarity).

КАК ЭТО ВЫГЛЯДИТ НА ПРАКТИКЕ

Сначала определяется рубрика - строгие критерии оценки («Является ли ответ фактологически верным? Есть ли галлюцинации?»). Это ваша спецификация теста. Далее пишется промпт для «модели-судьи», включающий рубрику, ответ целевой модели и исходный промпт. Судья прогоняет датасет несколько раз (из-за недетерминированности) и возвращает структурированный JSON с оценкой и обоснованием.

В полной версии поста я разобрала, как концепции LLM-as-a-Judge напрямую проецируются на привычную QA-терминологию - от Test Oracle до Acceptance Criteria: читать далее