LLM-as-a-judge - индустриальный антипаттерн
Есть в AI индустрии две инженерные идеи, которые с распространением ллм-технологий на мой вкус стали антипаттернами. Это LLM-as-a-judge и векторный поиск. Их объединяет то, что они не требуют ментальной нагрузки при внедрении (easy), но при этом непрозрачно прячут под капотом огромную сложность (not simple). Про эмбеддинги поговорим потом, а вот с llm-as-a-judge давайте разбираться.
Казалось бы ну кайф. Вот сделали вы систему (агентскую, разумеется). Надо ее качество замерять на каждом эксперименте. Раньше надо было нанимать разметчиков, обучать их, ждать днями каждую разметку. А тут написал промпт проверки ответа и LLM сама быстро все размечает. Эксперименты ускоряются, ту зэ мун.
Но вот проблема: этот промпт надо написать. А для сложных сценариев надо еще и подложить в этот промпт какие то данные о внешнем состоянии системы в тесткейсе. Уже выглядит как задачка на context engineering. А как из всех возможных промптов выбрать тот, который реально работает? Видимо руками размечать. Кажется, что и ок, руками разметили один раз, а потом у нас автоматический оценщик. Ну так то тоже мимо: дрифт ответов системы (а это буквально задача R&D - сдрифтить ответы системы в сторону правильных), и все, по хорошему надо переразмечать качество джаджа.
Ну ладно, есть задачки где промпты-инструкции простые. Там то все хорошо? Ну вот нет: модели же еще и игнорируют эти инструкции. Опять же в разном проценте случаев на разных распределениях аутпутов системы. Один раз посчитать и забыть не получится.
Че-то нифига не просто да? И без живых разметчиков не обойтись. Вот и получается, что вроде внедрять очень просто, но заставить это стабильно и хорошо работать - очень трудно.
Когда же llm-as-a-judge полезен?
1. Команда относится к джаджу, как к отдельному продукту. Со своими метриками, своим беклогом. И все равно дополняет разметочными метриками.
2. Джадж - это часть композитного реворда для алаймента. Тут все ясно: даже неидеальный рекорд может накинуть метрик.
3. Джадж удешевляет человеческие разметки. Например схема с перекрытиями, где один из размерчиков - это ллм. А лучше ансамбль разных ллм.
4. Вы учитесь строить продукты. Тогда действительно пофиг на финальное качество, главное, чтоб сложилась культура работы с хоть какими то метриками.
В остальных случаях я убежден, что llm-as-a-judge - это бомба замедленного действия, которая дает ложное чувство контроля.
Есть в AI индустрии две инженерные идеи, которые с распространением ллм-технологий на мой вкус стали антипаттернами. Это LLM-as-a-judge и векторный поиск. Их объединяет то, что они не требуют ментальной нагрузки при внедрении (easy), но при этом непрозрачно прячут под капотом огромную сложность (not simple). Про эмбеддинги поговорим потом, а вот с llm-as-a-judge давайте разбираться.
Казалось бы ну кайф. Вот сделали вы систему (агентскую, разумеется). Надо ее качество замерять на каждом эксперименте. Раньше надо было нанимать разметчиков, обучать их, ждать днями каждую разметку. А тут написал промпт проверки ответа и LLM сама быстро все размечает. Эксперименты ускоряются, ту зэ мун.
Но вот проблема: этот промпт надо написать. А для сложных сценариев надо еще и подложить в этот промпт какие то данные о внешнем состоянии системы в тесткейсе. Уже выглядит как задачка на context engineering. А как из всех возможных промптов выбрать тот, который реально работает? Видимо руками размечать. Кажется, что и ок, руками разметили один раз, а потом у нас автоматический оценщик. Ну так то тоже мимо: дрифт ответов системы (а это буквально задача R&D - сдрифтить ответы системы в сторону правильных), и все, по хорошему надо переразмечать качество джаджа.
Ну ладно, есть задачки где промпты-инструкции простые. Там то все хорошо? Ну вот нет: модели же еще и игнорируют эти инструкции. Опять же в разном проценте случаев на разных распределениях аутпутов системы. Один раз посчитать и забыть не получится.
Че-то нифига не просто да? И без живых разметчиков не обойтись. Вот и получается, что вроде внедрять очень просто, но заставить это стабильно и хорошо работать - очень трудно.
Когда же llm-as-a-judge полезен?
1. Команда относится к джаджу, как к отдельному продукту. Со своими метриками, своим беклогом. И все равно дополняет разметочными метриками.
2. Джадж - это часть композитного реворда для алаймента. Тут все ясно: даже неидеальный рекорд может накинуть метрик.
3. Джадж удешевляет человеческие разметки. Например схема с перекрытиями, где один из размерчиков - это ллм. А лучше ансамбль разных ллм.
4. Вы учитесь строить продукты. Тогда действительно пофиг на финальное качество, главное, чтоб сложилась культура работы с хоть какими то метриками.
В остальных случаях я убежден, что llm-as-a-judge - это бомба замедленного действия, которая дает ложное чувство контроля.