LLM-as-judge и согласие (κ)

Ловушка согласия

LLM-as-judge — модель, которая оценивает transcripts (журналы разговоров агента) по rubric (списку критериев). Прежде чем ему доверять, его сравнивают с людьми. Самое простое число — agreement (согласие): в какой доле случаев judge и люди сказали одно и то же.

Пусть 200 transcripts, в 8 из них нарушение политики (4%). Judge, который на всё отвечает «чисто», совпадает с людьми в 192 случаях из 200 — 96% согласия, не поймав ни одного нарушения. Простое согласие врёт, когда один из ответов редок. А нарушения в хорошей системе редки всегда.

Cohen's κ шаг за шагом

κ вычитает согласие, которое получилось бы случайно:

κ = (p_o − p_e) / (1 − p_e),

где p_o — наблюдаемое согласие (observed agreement), а p_e — согласие, ожидаемое случайно (expected agreement), если бы judge и люди отвечали независимо, каждый со своей частотой «нарушение».

Настоящий judge на тех же 200 transcripts поймал 6 из 8 нарушений и дал 4 ложные тревоги:

1. p_o = (6 + 188) / 200 = 0,97. Всего на один пункт выше бесполезного judge.
2. Частоты «нарушение»: у людей 8/200 = 0,04, у judge 10/200 = 0,05.
3. p_e = 0,04 × 0,05 + 0,96 × 0,95 = 0,002 + 0,912 = 0,914. Это шанс совпасть, если оба отвечают наугад со своими частотами.
4. κ = (0,97 − 0,914) / (1 − 0,914) = 0,056 / 0,086 ≈ 0,65.

Для judge «всегда чисто»: p_o = 0,96, p_e = 0,04 × 0 + 0,96 × 1 = 0,96, κ = 0. Разница видна сразу: 96% против 97% согласия, но κ 0 против 0,65.

Ещё два числа по нарушениям: recall (полнота) = 6/8 = 75% — сколько нарушений поймано; precision (точность) = 6/10 = 60% — сколько тревог настоящие.

def kappa(tp, fp, fn, tn):
    n = tp + fp + fn + tn
    po = (tp + tn) / n
    h, j = (tp + fn) / n, (tp + fp) / n   # доля «нарушение» у людей и у judge
    pe = h * j + (1 - h) * (1 - j)
    return (po - pe) / (1 - pe)

print(kappa(6, 4, 2, 188))   # 0.651
print(kappa(0, 0, 8, 192))   # 0.0

Грубое прочтение κ: ниже 0,4 — слабо, 0,6–0,8 — прилично, выше 0,8 — сильно. Это условность, разные авторы рисуют границы по-разному. Для оценок по шкале 1–5 берут weighted κ (взвешенную каппу) или Krippendorff's α (альфу Криппендорфа): они штрафуют расхождение 1 против 5 сильнее, чем 3 против 4, а α работает и с тремя и более разметчиками.

Когда нарушения очень редки, κ становится нестабильным: одна пропущенная строка двигает его на десятые. Тогда главное число — recall judge на нарушениях с его неопределённостью, потому что пропущенное нарушение стоит намного дороже ложной тревоги. Hamel Husain советует то же другими словами: считать человеческие метки истиной и отдельно сообщать true positive rate и true negative rate judge (долю пойманных нарушений и долю верно пропущенных чистых).

Потолок: согласие людей

Два человека, размечающие один и тот же поднабор, тоже расходятся. Их согласие — потолок для любого judge: модель не может совпадать с «истиной» лучше, чем сама истина совпадает сама с собой. Если люди согласны с κ = 0,7, требовать от judge 0,9 бессмысленно — сначала уточняют критерии. В классической работе Zheng и соавторов (2023) сильный judge того времени совпадал с людьми более чем в 80% случаев — на том же уровне, что люди между собой.

Ещё один источник ошибок — искажения самого judge: position bias (любит первый показанный вариант), verbosity bias (любит длинный), self-enhancement (любит своё семейство моделей). Лечится порядком в обе стороны, отдельным бинарным вопросом на каждый критерий и judge из другого семейства.

Формат judge — тоже решение инженера. Один judge на один вид провала, а не «оцени разговор в целом». Вывод структурированный: сначала critique, потом вердикт pass или fail, чтобы код мог разобрать ответ, а человек — понять, за что поставлен fail. Judge — такая же версия системы, как prompt агента: смена модели judge или его prompt требует повторной проверки по людям.

Как построить и проверить judge

1. Эксперт размечает pass/fail с critique (письменным объяснением). Husain против шкал 1–5: «3» и «4» не говорят, что делать. Он начинает примерно с 30 примеров и продолжает, пока не перестанут появляться новые виды провалов.
2. Хватает нарушений для замера. Естественная выборка их почти не содержит: собирают прошлые отмеченные случаи и подкладывают синтетические. Husain ориентируется примерно на 100 примеров на каждый вид провала; ниже 60 интервалы слишком широки для вывода.
3. Двое людей размечают общий поднабор — это потолок.
4. Планку ставят до запуска. Например: recall на нарушениях не ниже 90% на каждом языке и κ не ниже 0,7.
5. Запускают judge, считают recall, precision и κ по каждому языку и типу нарушения, правят prompt. Critiques эксперта становятся few-shot примерами (образцами внутри prompt). У Husain хватило трёх итераций до согласия выше 90% с экспертом.
6. В production люди продолжают смотреть всё, что judge отметил, плюс случайную выборку того, что он пропустил. Только так видно, что judge начал промахиваться: модель обновилась, клиенты пишут иначе, появился новый вид нарушения.