Средний

9 мин

1

Создать 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.

Чтобы перейти от мнений к воспроизводимой оценке, нужны рубрики.

Внедряем рубрики

Проверяемая рубрика — это конкретный критерий качества результата. Но рубрики нельзя проектировать в отрыве от продукта. Сначала нужно понять, какую ценность даёт решение, зачем им пользуются и какие ошибки эту ценность разрушают. Только после этого можно формулировать правила оценки.

Последовательность такая:

1. Сформулировать продуктовую ценность.

2. Понять, какие ошибки для неё наиболее опасны.

3. Перевести эти ошибки в проверяемые рубрики.

Например, для оценки кандидата критична галлюцинация фактов. Если ИИ-помощник выдумывает информацию о резюме, рекрутеру приходится перепроверять и исправлять работу модели. Это снижает ценность продукта. Поэтому «модель не выдумывает факты о кандидате» — валидная рубрика. Так мы переходим от абстрактного «ответ хороший» к конкретным проверкам качества.

Проектирование рубрик

Понять, какая рубрика нужна, недостаточно. Её ещё нужно сформулировать так, чтобы LLM могла стабильно по ней оценивать. Люди часто используют абстрактные понятия и опираются на профессиональный контекст, который кажется очевидным. Для модели такие формулировки могут быть субъективными, неполными или противоречивыми. Задача разработчика рубрики — закрыть этот разрыв контекста.

Рассмотрим пример.

Задача: написать кандидату сообщение с предложением откликнуться на вакансию.

Плохая рубрика:

Сообщение написано в профессиональном тоне и звучит вежливо.

Почему плохо: «профессиональный» и «вежливо» — оценочные слова без якоря. Разные судьи могут интерпретировать их по-разному.

Хорошая рубрика раскладывает качество на бинарные проверки:

• есть приветствие с именем кандидата;

• ассистент представился как ИИ-помощник;

• обозначена цель обращения — предложить откликнуться;

• указаны название вакансии и работодатель;

• используется обращение на «вы», без сленга и эмодзи.

Это пример субъективизма в рубрике, но бывают и другие дефекты: неатомарность, пропущенные требования, дублирование проверок, неясные пороги. Чтобы находить такие проблемы, мы используем подход RIFT — таксономию типичных ошибок в критериях оценки. Она помогает проверять рубрики не через абстрактный вопрос «хорошая она или плохая», а через конкретные дефекты формулировки.

Обычно качественная рубрика не получается с первого раза. Мы пропускаем каждую версию через RIFT, находим слабые места и дорабатываем формулировки. Чем точнее рубрики, тем устойчивее работает LLM-судья и тем больше пользы приносит оценка.

Рубрики для нашего LLM-судьи

Для навыка «нейроразбор» мы пришли к десяти рубрикам. Часть из них описывает классические ошибки модели: precision — когда модель придумывает факты, и recall — когда пропускает важную информацию.

Другие рубрики появились из анализа реальных кейсов. Например, cutoff — ошибка на пороговых требованиях. В вакансии указано: «опыт работы от 3 лет», а ассистент видит кандидата с опытом 2,5 года и пишет: «в целом подходит». Но если бизнес задал конкретный порог, его нужно соблюдать. Такие пограничные случаи регулярно встречаются на практике, поэтому мы выделили их в отдельную рубрику.

Давайте разберем на примере, как работают все указанные рубрики вместе.

Критерий оценки кандидата: кандидат имеет не менее 3 лет опыта управления командой от 5 человек и опыт найма сотрудников, но не работал в кадровом агентстве.

Резюме:

• С 2021 по 2024 год руководил командой из 7 разработчиков

• Участвовал в проведении технических интервью и принятии решений по найму

• С 2018 по 2020 год работал консультантом в кадровом агентстве N

Ответ оцениваемой модели

• Кандидат соответствует критерию.

• У него более 5 лет опыта управления людьми.

• Он самостоятельно нанимал сотрудников и формировал команду.

• Опыт работы в кадровом агентстве не обнаружен.

• Кандидат обладает сильными лидерскими качествами и хорошо подходит для позиции.

• Итоговый вердикт: не подходит

Разберем ответ модели по рубрикам:

Таким образом, мы получили оценку ответа 3/10, что нельзя считать приемлемым результатом.

Четырёхэтапный судья

LLM-судья не обязан быть одним промптом. Часто его представляют как один запрос к модели, но на практике это может быть полноценный пайплайн.

У нас судья состоит из четырёх этапов:

1. Первый — валидация входных данных. Если модель вернула ответ в неправильном формате, нет смысла оценивать его дальше: он уже нарушает требования.

2. Второй — извлечение доказательств. На этом этапе судья работает с исходными данными и собирает факты, на которых потом будет строиться оценка.

3. Третий — вердикты по рубрикам. Модель проходит по всем рубрикам и определяет, какие из них нарушены.

4. Четвёртый — расчёт итогового скора. Этот этап мы вынесли в код: финальную оценку даёт не модель. Так надёжнее, потому что даже современные LLM ошибаются в вычислениях. Кроме того, в коде проще задавать веса и штрафы: одни ошибки критичнее других, а разные рубрики должны по-разному влиять на итоговый скор.

Отдельный продукт

В процессе разработки LLM-судей для «нейроразбора» мы пришли к выводу: судья — это отдельный GenAI-продукт со своим жизненным циклом и собственной эволюцией.

Начинается всё с небольшого калибровочного датасета. Мы стартовали примерно со ста явно корректных и ста явно некорректных примеров оценки кандидата по каждой рубрике. Этого достаточно, чтобы собрать первую версию судьи, откалибровать его на базовых случаях и начать использовать.

Дальше судья развивается вместе с продуктом. Появляются новые данные, edge-кейсы из продакшена и ошибки, которые раньше никто не видел. Всё это попадает в калибровочный датасет, делает его репрезентативнее, а судью — устойчивее.

Поэтому LLM-судью нельзя «сделать за один раз». По мере развития основного GenAI-навыка должен развиваться и судья, который его оценивает.

Сколько стоит LLM-судья

Я много раз слышал, что LLM-судьи дёшевы: один вызов модели стоит меньше ручной разметки. Это правда, но стоимость судьи не ограничивается одним вызовом LLM.

Чтобы судья приносил пользу, нужны калибровочный датасет с человеческой разметкой, качественные рубрики, инфраструктура, мониторинг прода, сбор edge-кейсов и постоянное развитие вместе с оцениваемым GenAI-продуктом.

Если учитывать всё это, картина меняется. Например, при использовании судьи для продакшен-мониторинга поверх существующего AI-сервиса расходы на токены могут вырасти в 2–3 раза. Это всё ещё дешевле, чем размечать весь прод вручную, но уже достаточно дорого, чтобы серьёзно думать о стоимости разработки, эксплуатации и сопровождения.

Как удешевить судью

LLM-судью можно сделать доступнее, если сознательно идти на компромиссы.

Во-первых, не обязательно проверять всё. Лучше сфокусироваться на нескольких рубриках, которые ловят ошибки с критичным влиянием на продукт.

Во-вторых, не всегда нужна самая сильная модель. Если рубрики хорошо сформулированы, атомарны и легко проверяются, то с задачей может справиться и небольшая модель — при условии хорошей калибровки.

В-третьих, не нужно оценивать весь прод. Часто достаточно статистически обоснованной выборки, чтобы контролировать качество без проверки каждого кейса.

В-четвёртых, не стоит пытаться поймать все edge-кейсы. Если ошибка системная, она проявится снова. Погоня за стопроцентным покрытием обычно только раздувает бюджет.

И главное: идеального LLM-судьи не существует. Соблазнительно добиться 100% совпадения с человеческой разметкой, но на неоднозначных задачах даже эксперты не всегда приходят к одному ответу. Поэтому важнее определить достаточный уровень качества. Для себя мы выбрали ориентир 80%+.

Такой подход помогает контролировать расходы и не терять в качестве оценки.

Наш результат: что сработало, а что нет

В разработке LLM-судьи у нас были и удачные решения, и неработающие гипотезы.

Что сработало хорошо:

1. Продуктовый подход. Мы начали не с выбора модели и промптинга, а с понимания ценности продукта и ошибок, которые эту ценность разрушают.

2. Переход от «оцени ответ» к рубрикам. После этого стало возможно собирать датасеты, калибровать судью и постепенно улучшать качество оценки.

3. Разделение этапов внутри судьи. Отдельно: поиск подтверждений, проверка по рубрикам и расчёт финального скора.

4. Итерации через ручную валидацию. Мы регулярно проверяли оценки судьи руками и дорабатывали его на найденных ошибках.

5. Structure Guided Reasoning. Этот подход помог задать логику рассуждения и формат ответа судьи.

6. LangGraph-пайплайн. Мы начинали с DeepEval, но в итоге пришли к LangGraph. При этом сам фреймворк вторичен: если вы умеете валидировать судью и понимаете, как его оценки коррелируют с человеческой разметкой, технологический стек становится менее важен.

Что не сработало:

1. Наивные судьи в формате «оцени ответ». Без рубрик модель выдаёт не устойчивую оценку, а ещё одно мнение.

2. Шкала от 1 до 10. На практике трудно объяснить, чем 6 отличается от 7, а модели часто выбирают средние значения как безопасный вариант. Мы отказались от таких шкал и перешли к бинарной оценке: критерий либо выполнен, либо нет.

3. Ставка на более сильную модель без методологии. Модель посильнее не спасает, если непонятно, что именно и по каким правилам она должна оценивать.

4. Попытка идеально синхронизироваться с экспертами. На неоднозначных задачах это невозможно и быстро превращается в сжигание времени и бюджета.

5. Рубрики без проверки по таксономии ошибок. Если не проверять формулировки, в них легко остаются субъективность, неатомарность, пропущенные требования и другие дефекты.

6. Слепая вера в экспертную разметку. Эксперты тоже ошибаются и не всегда согласны друг с другом, поэтому разметку нужно проверять и калибровать.

7. Разработка без контроля стоимости. Судья может стать дорогим уже на этапе продакшен-мониторинга, поэтому стоимость нужно учитывать с самого начала.

Вывод — три опоры

Хороший LLM-судья держится на трёх опорах.

Первая — продуктовая. Нужно понимать, какую ценность создаёт продукт и какие ошибки эту ценность разрушают. Без этого невозможно сформулировать хорошие критерии оценки.

Вторая — инженерная. Это архитектура судьи, выбор моделей, фреймворков, промптинга, каскадов и других технических решений.

Третья — финансовая. О ней легко забыть. Можно повысить корреляцию судьи с человеческой оценкой, запуская несколько дорогих моделей на каждый кейс. Но если стоимость растёт быстрее качества, решение становится непрактичным. Поэтому хороший судья — это всегда баланс между качеством оценки и стоимостью эксплуатации.

А как вы проектируете LLM-судей? Делитесь в комментариях, буду рад обсудить!

Больше интересного про разработку ИИ-помощника для работодателей и GenAI-команду hh можно найти в телеграм-канале «Охэхэнные новости». Подписывайтесь!