Best practices для LLM-as-a-Judge
В своей крайней статье я рассказывал о метриках BLEU, ROUGE, METEOR. Это простые и быстрые в подсчете метрики. У них есть существенный недостаток: при оценке схожести двух текстов они опираются на точное совпадение слов или их частей. Если тексты написаны правильно, но другими словами, оценка будет низкой. Хотелось бы такого избежать.
На помощь приходит LLM-as-a-Judge, при котором сама языковая модель (LLM) выступает в роли оценщика. Такой подход делает оценку более близкой к человеческой, а также позволяет производить оценку в более широком классе задач (например, сравнивать ответы на разных языках).
Давайте рассмотрим некоторые практики, которые позволят сделать применение LLM-as-a-Judge более эффективным.
1. Четкие и атомарные критерии оценки
Во время написания системного промпта нужно стараться более четко описывать критерии, по которым вы хотите оценить свои примеры. Эти критерии стоит декомпозировать на более атомарные, чтобы LLM было проще в них разобраться и выдать оценку.
Например:
2. Structured Output и Schema-Guided Reasoning
Эти "заклинания" позволят ограничить LLM в выдаче результата и получать более предсказуемый формат выходных данных. Задайте строгую схему, по которой модель должна сгенерировать ответ. Помимо ожидаемого результата это позволит проще реализовать алгоритм оценки в коде.
Также стоит добавить в системный промпт описания ожидаемой выходной структуры.
Часто пользуюсь такой практикой: ограничиваю результат баллами (например от 1 до 5) или категориями ("хорошо", "нормально", "плохо"). Это задается в схеме выходных данных (например, через pydantic). Также на этапе описания критериев необходимо описывать, за что давать тот или иной балл или присваивать категорию (как в примере выше).
3. Просить LLM аргументировать оценку
Во-первых, не всегда с первого раза получается задать качественный системный промпт и формат оценки. На ранних этапах такие пояснения помогают провести отладку и понять, почему в том или ином примере LLM дала неправильную оценку и в каких местах у нее есть предрассудки. Во-вторых, заставляя модель объяснять свое решение (и тем самым глубже вникать в задачу), мы получаем более правильную оценку.
Особенно хорошо это работает вместе с Chain-of-Thought (просить модель рассуждать "шаг за шагом"), который заставит модель шаг за шагом разбирать пример, вникать в детали, а после выдавать оценку.
Этот подход хорошо комбинировать со вторым: заставлять LLM через SGR сначала в схеме выдавать аргументацию, а потом оценку.
4. Примеры оценки
И конечно метод Few-shot, куда без него. Если добавить в системный промпт несколько примеров, мы дадим модели более правильное понимание того, как работать с критериями. Здесь нужно быть очень аккуратным, потому что неправильно заданные примеры могут сильно исказить результаты.
Если, например, вы оцениваете данные по 3х бальной шкале, можно привести пример оценки на каждый балл, чтобы LLM лучше уловила суть.
Максим Максимов // IT, AI
В своей крайней статье я рассказывал о метриках BLEU, ROUGE, METEOR. Это простые и быстрые в подсчете метрики. У них есть существенный недостаток: при оценке схожести двух текстов они опираются на точное совпадение слов или их частей. Если тексты написаны правильно, но другими словами, оценка будет низкой. Хотелось бы такого избежать.
На помощь приходит LLM-as-a-Judge, при котором сама языковая модель (LLM) выступает в роли оценщика. Такой подход делает оценку более близкой к человеческой, а также позволяет производить оценку в более широком классе задач (например, сравнивать ответы на разных языках).
Давайте рассмотрим некоторые практики, которые позволят сделать применение LLM-as-a-Judge более эффективным.
1. Четкие и атомарные критерии оценки
Во время написания системного промпта нужно стараться более четко описывать критерии, по которым вы хотите оценить свои примеры. Эти критерии стоит декомпозировать на более атомарные, чтобы LLM было проще в них разобраться и выдать оценку.
Например:
"Оцени качество текста баллами от 1 до 3" - плохая инструкция.
"Оцени текст по 3х бальной шкале:
1 балл - текст содержит более 5 орфографических ошибок.
2 балла - текст содержит не более 5 орфографических ошибок.
3 балла - ошибки в тексте отсутствуют." - хорошая инструкция.
2. Structured Output и Schema-Guided Reasoning
Эти "заклинания" позволят ограничить LLM в выдаче результата и получать более предсказуемый формат выходных данных. Задайте строгую схему, по которой модель должна сгенерировать ответ. Помимо ожидаемого результата это позволит проще реализовать алгоритм оценки в коде.
Также стоит добавить в системный промпт описания ожидаемой выходной структуры.
Часто пользуюсь такой практикой: ограничиваю результат баллами (например от 1 до 5) или категориями ("хорошо", "нормально", "плохо"). Это задается в схеме выходных данных (например, через pydantic). Также на этапе описания критериев необходимо описывать, за что давать тот или иной балл или присваивать категорию (как в примере выше).
3. Просить LLM аргументировать оценку
Во-первых, не всегда с первого раза получается задать качественный системный промпт и формат оценки. На ранних этапах такие пояснения помогают провести отладку и понять, почему в том или ином примере LLM дала неправильную оценку и в каких местах у нее есть предрассудки. Во-вторых, заставляя модель объяснять свое решение (и тем самым глубже вникать в задачу), мы получаем более правильную оценку.
Особенно хорошо это работает вместе с Chain-of-Thought (просить модель рассуждать "шаг за шагом"), который заставит модель шаг за шагом разбирать пример, вникать в детали, а после выдавать оценку.
Этот подход хорошо комбинировать со вторым: заставлять LLM через SGR сначала в схеме выдавать аргументацию, а потом оценку.
4. Примеры оценки
И конечно метод Few-shot, куда без него. Если добавить в системный промпт несколько примеров, мы дадим модели более правильное понимание того, как работать с критериями. Здесь нужно быть очень аккуратным, потому что неправильно заданные примеры могут сильно исказить результаты.
Если, например, вы оцениваете данные по 3х бальной шкале, можно привести пример оценки на каждый балл, чтобы LLM лучше уловила суть.
Максим Максимов // IT, AI