Создать LLM-судью легко. Гораздо сложнее сделать так, чтобы его оценкам можно было доверять.
Мы убедились в этом на практике при разработке нейроразбора резюме для ИИ-помощника hh.ru. Быстро выяснилось, что хороший LLM-судья — это отдельный продукт со своими рубриками, датасетами, метриками качества и стоимостью эксплуатации.
Меня зовут Женя Орлов, я LLM Eval Lead. В этой статье расскажу, как мы проектировали систему оценки для нейроразбора резюме, почему отказались от наивных подходов и какие выводы сделали по ходу разработки.
Зачем нам понадобился LLM-судья
Для начала немного контекста. Нейроразбор резюме — это один из навыков ИИ-помощника hh.ru, который помогает работодателям искать и приглашать на собеседование подходящих кандидатов. Нейроразбор оценивает мэтч резюме с вакансией — и если он есть, ИИ-помощник с помощью другого навыка соединяет работодателя с соискателем.
Как оценить резюме?
Представим, что у нас есть вакансия и резюме кандидата. Как понять, подходит кандидат или нет?
Один из вариантов — обучить ML-модель на разметке HR-специалистов. Но с появлением LLM стало возможно двигаться иначе: автоматизировать оценку на основе бизнес-правил, которыми пользуются эксперты. Такой подход прозрачнее — можно прочитать рассуждение модели — и проще в настройке за счет промптинга. Но у него есть цена: правила нужно формализовывать очень точно, а галлюцинации и ошибки интерпретации приходится отдельно контролировать.
Мы пошли по пути оценки кандидата через соответствие критериям, важным для конкретной позиции. Часть критериев может извлекаться из вакансии автоматически, часть — задаваться работодателем вручную.
Сложность оценки кандидата по критериям
Возьмём простой критерий: «Уверенное знание Excel». ИИ-помощник должен оценить, соответствует ли ему кандидат: полностью, частично или не соответствует вообще.
На первый взгляд задача простая. Но в резюме и вакансиях один и тот же навык описывают по-разному: разными словами, с разной детализацией и в разном контексте. Из-за этого возникает неопределённость. Мы не раз сталкивались с ситуацией, когда даже эксперты не могли прийти к единому мнению по оценке резюме. А если неоднозначность возникает у людей, то у LLM она тем более неизбежна.
Что значит «уверенное знание Excel»? Для одного это ВПР, для другого — формулы, сводные таблицы и макросы, для третьего — базовые операции с ячейками. Рекрутеры тоже могут вкладывать в этот критерий разный смысл в зависимости от позиции. Я называю это разрывом контекста: один и тот же факт может означать разные вещи для разных людей.
Возникает вопрос: как проверять качество такой оценки со всеми её неопределенностями? Самый простой ответ — человеческая разметка. Однако она полезна, но плохо масштабируется. Профессий много, нюансов еще больше, а критериев оценки — практически бесконечно много. Чтобы репрезентативно проверить работу навыка, нужно много экспертной разметки. Причём это разовая проверка состояния «здесь и сейчас»: после доработок навык придется размечать снова, а для мониторинга в продакшене такой подход становится слишком дорогим. Поэтому нам понадобились LLM-судьи.
От наивного LLM-судьи к отдельному продукту
Наивный LLM-судья обычно выглядит так: берём одну LLM и просим её оценить ответ другой LLM, например по шкале от 1 до 10. Проблема в том, что без чётких правил модель сама решает, что считать хорошим ответом, а что плохим. Чем отличается 7 от 6? Какие ошибки критичны? Что важнее: полнота, точность или стиль? Если это не задано явно, мы получаем не оценку, а ещё одно мнение. Только теперь не человеческое, а мнение LLM.
Чтобы перейти от мнений к воспроизводимой оценке, нужны рубрики.
Внедряем рубрики
Проверяемая рубрика — это конкретный критерий качества результата. Но рубрики нельзя проектировать в отрыве от продукта. Сначала нужно понять, какую ценность даёт решение, зачем им пользуются и какие ошибки эту ценность разрушают. Только после этого можно формулировать правила оценки.
Последовательность такая:
Сформулировать продуктовую ценность.
Понять, какие ошибки для неё наиболее опасны.
Перевести эти ошибки в проверяемые рубрики.
Например, для оценки кандидата критична галлюцинация фактов. Если ИИ-помощник выдумывает информацию о резюме, рекрутеру приходится перепроверять и исправлять работу модели. Это снижает ценность продукта. Поэтому «модель не выдумывает факты о кандидате» — валидная рубрика. Так мы переходим от абстрактного «ответ хороший» к конкретным проверкам качества.
Проектирование рубрик
Понять, какая рубрика нужна, недостаточно. Её ещё нужно сформулировать так, чтобы LLM могла стабильно по ней оценивать. Люди часто используют абстрактные понятия и опираются на профессиональный контекст, который кажется очевидным. Для модели такие формулировки могут быть субъективными, неполными или противоречивыми. Задача разработчика рубрики — закрыть этот разрыв контекста.
Рассмотрим пример.
Задача: написать кандидату сообщение с предложением откликнуться на вакансию.
Плохая рубрика:
Сообщение написано в профессиональном тоне и звучит вежливо.
Почему плохо: «профессиональный» и «вежливо» — оценочные слова без якоря. Разные судьи могут интерпретировать их по-разному.
Хорошая рубрика раскладывает качество на бинарные проверки:
есть приветствие с именем кандидата;
ассистент представился как ИИ-помощник;
обозначена цель обращения — предложить откликнуться;
указаны название вакансии и работодатель;
используется обращение на «вы», без сленга и эмодзи.
Это пример субъективизма в рубрике, но бывают и другие дефекты: неатомарность, пропущенные требования, дублирование проверок, неясные пороги. Чтобы находить такие проблемы, мы используем подход RIFT — таксономию типичных ошибок в критериях оценки. Она помогает проверять рубрики не через абстрактный вопрос «хорошая она или плохая», а через конкретные дефекты формулировки.
Обычно качественная рубрика не получается с первого раза. Мы пропускаем каждую версию через RIFT, находим слабые места и дорабатываем формулировки. Чем точнее рубрики, тем устойчивее работает LLM-судья и тем больше пользы приносит оценка.
Рубрики для нашего LLM-судьи
Для навыка «нейроразбор» мы пришли к десяти рубрикам. Часть из них описывает классические ошибки модели: precision — когда модель придумывает факты, и recall — когда пропускает важную информацию.
Другие рубрики появились из анализа реальных кейсов. Например, cutoff — ошибка на пороговых требованиях. В вакансии указано: «опыт работы от 3 лет», а ассистент видит кандидата с опытом 2,5 года и пишет: «в целом подходит». Но если бизнес задал конкретный порог, его нужно соблюдать. Такие пограничные случаи регулярно встречаются на практике, поэтому мы выделили их в отдельную рубрику.
Давайте разберем на примере, как работают все указанные рубрики вместе.
Критерий оценки кандидата: кандидат имеет не менее 3 лет опыта управления командой от 5 человек и опыт найма сотрудников, но не работал в кадровом агентстве.
Скрытый текст
Внимательный читатель может заметить: ваш критерий оценки кандидата содержит в себе аж целых три критерия! И будет прав. Реальность такова, что работодатели часто совмещают несколько критериев в одном, поэтому мы должны уметь обрабатывать и такие случаи.
Резюме:
С 2021 по 2024 год руководил командой из 7 разработчиков
Участвовал в проведении технических интервью и принятии решений по найму
С 2018 по 2020 год работал консультантом в кадровом агентстве N
Ответ оцениваемой модели
Кандидат соответствует критерию.
У него более 5 лет опыта управления людьми.
Он самостоятельно нанимал сотрудников и формировал команду.
Опыт работы в кадровом агентстве не обнаружен.
Кандидат обладает сильными лидерскими качествами и хорошо подходит для позиции.
Итоговый вердикт: не подходит
Разберем ответ модели по рубрикам:
Рубрика | Вердикт | Причина |
Precision | ❌ | в резюме нет информации, что кандидат самостоятельно формировал команду и обладает лидерскими качествами |
Recall | ✅ | все значимые факты для критерия были замечены |
Accuracy | ❌ | «более 5 лет опыта управления» не подтверждается резюме |
Classification | ❌ | участие в интервью классифицировано как полноценный опыт найма сотрудников |
Cutoff | ✅ | требование «от 3 лет» выполнено |
Attribution | ❌ | формирование команды приписано лично кандидату без подтверждения |
Logic | ✅ | для составного критерия (логическое условие И) выполнена корректная проверка всех входящих условий и сделан правильный вывод |
Negation | ❌ | модель утверждает отсутствие опыта в кадровом агентстве, хотя он явно указан в резюме |
Consistency | ❌ | модель утверждает, что кандидат подходит, а потом ставит вердикт «не подходит» |
Relevance | ❌ | «сильные лидерские качества» не относятся к проверяемому критерию |
Таким образом, мы получили оценку ответа 3/10, что нельзя считать приемлемым результатом.
Четырёхэтапный судья
LLM-судья не обязан быть одним промптом. Часто его представляют как один запрос к модели, но на практике это может быть полноценный пайплайн.
У нас судья состоит из четырёх этапов:
Первый — валидация входных данных. Если модель вернула ответ в неправильном формате, нет смысла оценивать его дальше: он уже нарушает требования.
Второй — извлечение доказательств. На этом этапе судья работает с исходными данными и собирает факты, на которых потом будет строиться оценка.
Третий — вердикты по рубрикам. Модель проходит по всем рубрикам и определяет, какие из них нарушены.
Четвёртый — расчёт итогового скора. Этот этап мы вынесли в код: финальную оценку даёт не модель. Так надёжнее, потому что даже современные LLM ошибаются в вычислениях. Кроме того, в коде проще задавать веса и штрафы: одни ошибки критичнее других, а разные рубрики должны по-разному влиять на итоговый скор.
Отдельный продукт
В процессе разработки LLM-судей для «нейроразбора» мы пришли к выводу: судья — это отдельный GenAI-продукт со своим жизненным циклом и собственной эволюцией.
Начинается всё с небольшого калибровочного датасета. Мы стартовали примерно со ста явно корректных и ста явно некорректных примеров оценки кандидата по каждой рубрике. Этого достаточно, чтобы собрать первую версию судьи, откалибровать его на базовых случаях и начать использовать.
Дальше судья развивается вместе с продуктом. Появляются новые данные, edge-кейсы из продакшена и ошибки, которые раньше никто не видел. Всё это попадает в калибровочный датасет, делает его репрезентативнее, а судью — устойчивее.
Поэтому LLM-судью нельзя «сделать за один раз». По мере развития основного GenAI-навыка должен развиваться и судья, который его оценивает.
Сколько стоит LLM-судья
Я много раз слышал, что LLM-судьи дёшевы: один вызов модели стоит меньше ручной разметки. Это правда, но стоимость судьи не ограничивается одним вызовом LLM.
Чтобы судья приносил пользу, нужны калибровочный датасет с человеческой разметкой, качественные рубрики, инфраструктура, мониторинг прода, сбор edge-кейсов и постоянное развитие вместе с оцениваемым GenAI-продуктом.
Если учитывать всё это, картина меняется. Например, при использовании судьи для продакшен-мониторинга поверх существующего AI-сервиса расходы на токены могут вырасти в 2–3 раза. Это всё ещё дешевле, чем размечать весь прод вручную, но уже достаточно дорого, чтобы серьёзно думать о стоимости разработки, эксплуатации и сопровождения.
Как удешевить судью
LLM-судью можно сделать доступнее, если сознательно идти на компромиссы.
Во-первых, не обязательно проверять всё. Лучше сфокусироваться на нескольких рубриках, которые ловят ошибки с критичным влиянием на продукт.
Во-вторых, не всегда нужна самая сильная модель. Если рубрики хорошо сформулированы, атомарны и легко проверяются, то с задачей может справиться и небольшая модель — при условии хорошей калибровки.
В-третьих, не нужно оценивать весь прод. Часто достаточно статистически обоснованной выборки, чтобы контролировать качество без проверки каждого кейса.
В-четвёртых, не стоит пытаться поймать все edge-кейсы. Если ошибка системная, она проявится снова. Погоня за стопроцентным покрытием обычно только раздувает бюджет.
И главное: идеального LLM-судьи не существует. Соблазнительно добиться 100% совпадения с человеческой разметкой, но на неоднозначных задачах даже эксперты не всегда приходят к одному ответу. Поэтому важнее определить достаточный уровень качества. Для себя мы выбрали ориентир 80%+.
Такой подход помогает контролировать расходы и не терять в качестве оценки.
Наш результат: что сработало, а что нет
В разработке LLM-судьи у нас были и удачные решения, и неработающие гипотезы.
Что сработало хорошо:
Продуктовый подход. Мы начали не с выбора модели и промптинга, а с понимания ценности продукта и ошибок, которые эту ценность разрушают.
Переход от «оцени ответ» к рубрикам. После этого стало возможно собирать датасеты, калибровать судью и постепенно улучшать качество оценки.
Разделение этапов внутри судьи. Отдельно: поиск подтверждений, проверка по рубрикам и расчёт финального скора.
Итерации через ручную валидацию. Мы регулярно проверяли оценки судьи руками и дорабатывали его на найденных ошибках.
Structure Guided Reasoning. Этот подход помог задать логику рассуждения и формат ответа судьи.
LangGraph-пайплайн. Мы начинали с DeepEval, но в итоге пришли к LangGraph. При этом сам фреймворк вторичен: если вы умеете валидировать судью и понимаете, как его оценки коррелируют с человеческой разметкой, технологический стек становится менее важен.
Что не сработало:
Наивные судьи в формате «оцени ответ». Без рубрик модель выдаёт не устойчивую оценку, а ещё одно мнение.
Шкала от 1 до 10. На практике трудно объяснить, чем 6 отличается от 7, а модели часто выбирают средние значения как безопасный вариант. Мы отказались от таких шкал и перешли к бинарной оценке: критерий либо выполнен, либо нет.
Ставка на более сильную модель без методологии. Модель посильнее не спасает, если непонятно, что именно и по каким правилам она должна оценивать.
Попытка идеально синхронизироваться с экспертами. На неоднозначных задачах это невозможно и быстро превращается в сжигание времени и бюджета.
Рубрики без проверки по таксономии ошибок. Если не проверять формулировки, в них легко остаются субъективность, неатомарность, пропущенные требования и другие дефекты.
Слепая вера в экспертную разметку. Эксперты тоже ошибаются и не всегда согласны друг с другом, поэтому разметку нужно проверять и калибровать.
Разработка без контроля стоимости. Судья может стать дорогим уже на этапе продакшен-мониторинга, поэтому стоимость нужно учитывать с самого начала.
Вывод — три опоры
Хороший LLM-судья держится на трёх опорах.
Первая — продуктовая. Нужно понимать, какую ценность создаёт продукт и какие ошибки эту ценность разрушают. Без этого невозможно сформулировать хорошие критерии оценки.
Вторая — инженерная. Это архитектура судьи, выбор моделей, фреймворков, промптинга, каскадов и других технических решений.
Третья — финансовая. О ней легко забыть. Можно повысить корреляцию судьи с человеческой оценкой, запуская несколько дорогих моделей на каждый кейс. Но если стоимость растёт быстрее качества, решение становится непрактичным. Поэтому хороший судья — это всегда баланс между качеством оценки и стоимостью эксплуатации.
А как вы проектируете LLM-судей? Делитесь в комментариях, буду рад обсудить!
Больше интересного про разработку ИИ-помощника для работодателей и GenAI-команду hh можно найти в телеграм-канале «Охэхэнные новости». Подписывайтесь!
