Коли команда запитує нас, як перевірити, чи покращує їхній асистент AI відповіді після кожного перебудування промпту, найпоширеніша ідея звучить: «попросимо GPT-4 оцінити». Це має сенс на рівні інтуїції. Проблема виникає, коли суддя починає віддавати перевагу довшим відповідям незалежно від їхньої точності, або коли та сама рубрика з іншим формулюванням дає результати, що відрізняються на 20 процентних пунктів. Ми в Cashcrown перевіряємо LLM-as-a-judge на кожному новому проекті й бачимо ті самі патерни помилок незалежно від того, яка модель виступає суддею. Нижче описуємо, що насправді працює, а що підводить.
У чому полягає LLM-as-a-judge і коли це має сенс
#Принцип простий: замість того, щоб просити людину оцінити сто відповідей моделі, пишеш промпт з рубрикою (вірність, стислість, фактична правильність) і доручаєш цю оцінку іншій моделі. Суддя повертає результат або етикетку, яку можна агрегувати в метрику.
Підхід має реальні переваги. Оцінка сотень відповідей на день людиною — дорога і повільна. Суддя LLM працює миттєво, коштує частку ціни й є послідовним у межах однієї сесії: якщо відповідь A краща за B згідно з рубрикою, він стверджуватиме це щоразу при тому самому промпті. Цього достатньо, щоб порівнювати варіанти системи між собою. Саме для цього LLM-as-a-judge підходить найбільше: для A/B варіантів промпту, для регресії після зміни базової моделі, для щоденного моніторингу тренду якості. Не для видачі сертифіката якості конкретної відповіді.
| Застосування | Чи підходить LLM-as-a-judge? | Примітка |
|---|---|---|
| Порівняння варіанту A vs B промпту | Так | Pairwise, а не абсолютний scoring |
| Щоденне відстеження тренду якості | Так | Калібрування на людських етикетках раз на місяць |
| Оцінка faithfulness у RAG онлайн | Так (з обережністю) | Логуй контекст, щоб верифікувати флаги |
| Сертифікація якості конкретної відповіді | Ні | Потребує людини |
| Юридичні, медичні, кадрові рішення | Ні | Виключно людина |
Чотири систематичні помилки, які псують результат
Дослідження щодо LLM-as-a-judge (Meta/Stanford, 2023-2024) задокументували чотири повторювані помилки. Кожна з них змінює оцінку незалежно від реальної якості відповіді.
Verbosity bias (упередженість до довжини). Судді LLM схильні вище оцінювати довші, більш розгорнуті відповіді, навіть коли коротша й точніша відповідь об’єктивно краща. На практиці: система, яка генерує «воду» замість точної відповіді, отримує вищі оцінки. Мітгація: рубрика має прямо штрафувати за зайву розтягнутість або суддя оцінює пару відповідь+запитання замість самої відповіді.
Self-preference (упередженість до власних виходів). Модель, використана як суддя, віддає перевагу відповідям, подібним до тих, які вона сама б згенерувала. GPT-4 як суддя ставить вищі бали виходам GPT-4, ніж іншим моделям. Claude як суддя діє аналогічно. Мітгація: використовуй суддю з іншої родини, ніж оцінювана модель, або верифікуй оцінки pairwise кросово.
Position bias (ефект порядку). Коли суддя оцінює пару (A, B), він схильний віддавати перевагу тій, яку бачить першою або останньою. Експеримент із перевертанням порядку на тому самому наборі даних дає інші результати. Мітгація: оцінюй кожну пару в обох порядках і усереднюй, або застосовуй абсолютну оцінку per відповідь замість pairwise.
Prompt sensitivity (чутливість до формулювання). Дрібна зміна рубрики, наприклад, заміна «оціни від 1 до 10» на «оціни від 1 до 5», або додавання слова «коротко» до інструкції, змінює розподіл оцінок на 15-25 процентних пунктів. Це означає, що результати з різних версій рубрики непорівнювані. Мітгація: версіонуй промпт судді як код і ніколи не порівнюй результати з різних версій без рекалібрування.
Як побудувати суддю, якому можна довіряти
Калібрування на людських етикетках — єдиний надійний якір. Перед впровадженням судді збережи 100-200 пар запитання-відповідь з ручною оцінкою експертів предметної області. Потім перевір кореляцію Пірсона між оцінкою судді та оцінкою людини. Кореляція нижче 0,70 означає, що суддя вимірює щось інше, ніж те, що ти планував вимірювати. Перекалібруй рубрику або зміни суддю.
Парні порівняння (pairwise) надійніші за абсолютний scoring. Замість того, щоб питати «оціни цю відповідь від 1 до 10», запитуєш «яка з цих двох відповідей краще відповідає нижченаведеним критеріям». Pairwise менш чутливий до формулювання рубрики й дає стабільніші відносні рейтинги, хоча не скаже тобі, наскільки хороша відповідь у абсолютних значеннях.
Структурована рубрика перемагає відкрите запитання. Замість «оціни якість цієї відповіді» визнач конкретні виміри: вірна фактам, наведеним у контексті (так/ні), відповідає на запитання (так/ні), зайво довга (так/ні). Кожен вимір окремо, кожен з визначенням позитивного й негативного випадку. Суддя, налаштований через structured output, змушує дотримуватися цього формату й запобігає розмиванню оцінки в довільний текст.
Калібрування та підтримка в часі
Суддя — не статичний компонент. Зі зміною розподілу запитів користувачів його узгодженість з людськими етикетками знижується. Стався до рекалібрування як до регулярного техогляду: раз на 4-6 тижнів бери вибірку з 50 випадкових оцінок з продакшену, оцінюй її вручну й перераховуй кореляцію заново. Якщо вона падає нижче прийнятного порогу, перебудуй рубрику або візьми нову калібрувальну вибірку.
Зберігай постійний контрольний набір з ручними етикетками. Це 50-100 пар, які не змінюєш і не показуєш судді як приклади в промпті. Служать виключно для виміру дрейфу. Коли результат на контрольному наборі падає — це сигнал до дії, а не для ігнорування. Як це вписується в ширшу систему observability асистента, розгортаємо в статті про моніторинг якості агента AI.
Логуй обґрунтування судді разом з оцінками. Текстове обґрунтування — єдиний спосіб зрозуміти, що суддя насправді вимірює, коли результат дивує. Кількадесят обґрунтувань, прочитаних раз на тиждень, часто виявляють систематичну помилку швидше, ніж сама кореляція. До речі, перевіряй, чи не галюцинує суддя обґрунтування, тобто чи не посилається на те, чого не було в оцінюваній відповіді.
Де людина залишається обов’язковою
LLM-as-a-judge — інструмент масштабу, а не інструмент остаточного вердикту. Кілька меж, які не перетинаємо:
Рішення з високими ставками (звільнення працівника, відмова в кредиті, медичний діагноз, юридична думка) потребують ручної оцінки незалежно від того, наскільки хороший суддя. Guardrails у системі мають автоматично виключати такі випадки з автоматичного шляху й перенаправляти до людини. Як архітектурно визначати ці межі, описуємо в тексті про валідацію виходів LLM.
Нові домени без калібрувальних даних. Якщо немає набору людських етикеток для нової категорії контенту, не знаєш, чи суддя вимірює те, що планував. Впровадження судді без калібрування — це прийняття невідомої систематичної помилки.
Оцінка самого судді. Суддя LLM не повинен оцінювати варіанти власного промпту чи власної конфігурації. Це самовиконуваний цикл, який виграє варіант, стилістично найближчий до судді, а не той, що фактично кращий.
Як виглядають ці межі на практиці цілісної оцінки асистента, детально розглядаємо в статті про оцінку агента AI, тести й бенчмарки.
Поєднання з ширшим пайплайном оцінки
LLM-as-a-judge — один шар у пайплайні оцінки, а не вся система. У системах RAG, які ми будуємо, працює поряд з метриками пошуку (recall@k, MRR) і спеціалізованою оцінкою faithfulness. Як ці шари складаються разом, описуємо в статті про оцінку якості RAG. Суддя LLM підходить особливо для оцінки вимірів, які детерміновані метрики не охоплюють: тону, стилю, повноти пояснення, адекватності для бізнес-контексту.
Результат від судді сприймаємо як один із кількох сигналів, а не як єдиний. Якщо суддя флагує відповідь як слабку, але користувачі не ескалують і CSAT високий, людські сигнали перемагають. І навпаки: висока оцінка судді при низькому CSAT означає, що суддя вимірює невідповідний вимір. Тоді повертаємося до рубрики.
FAQ
#Чи замінює LLM-as-a-judge ручний рев’ю?
#Ні. Замінює ручне етикетування у масштабі при порівнянні варіантів і моніторингу трендів. Для рішень з високими ставками, нових доменів без калібрування та оцінок з юридичними чи етичними наслідками людина залишається обов’язковою. Автоматичний суддя доповнює, а не усуває ручний огляд.
Яка модель найкраще підходить як суддя?
Однозначної відповіді немає, бо залежить від домену й оцінюваних моделей. Загальне правило: суддя має бути з іншої родини, ніж оцінювана модель, щоб уникнути self-preference. Сильніша модель як суддя не завжди означає краща, бо чутливість до рубрики — це риса архітектури, а не розміру. Калібрування на людських етикетках важливіше за вибір моделі.
Як часто рекалібрувати суддю?
З нашої практики рекалібрування раз на 4-6 тижнів достатньо при стабільному розподілі запитів. При впровадженні нових функцій, зміні бази знань або додаванні нової категорії контенту рекалібрування має відбутися одразу, перш ніж суддя повернеться до роботи в продакшені.
Чи завжди pairwise краще за абсолютний scoring?
#Pairwise стабільніший при порівнянні двох варіантів системи й менш чутливий до формулювання рубрики. Абсолютний scoring потрібен, коли хочеш вимірювати абсолютну якість у часі (тренд за тиждень) або флагувати відповіді нижче порогу незалежно від порівняння з чимось. На практиці використовуємо обидва: pairwise для A/B, абсолютний scoring для безперервного моніторингу.
Що означає кореляція Пірсона нижче 0,70 при калібруванні?
#Означає, що суддя вимірює інший вимір, ніж людський експерт. Не завжди це помилка судді: може означати, що рубрика погано описує те, що важливе для команди. Нижче 0,70 не впроваджуємо суддю в продакшен. Між 0,70 і 0,80 впроваджуємо з обмеженим охопленням і щотижневим аудитом обґрунтувань. Вище 0,80 суддя може працювати як основний сигнал якості з місячним рекалібруванням.