Ключові висновки

Якість моделі — кілька незалежних властивостей. Можливості («чи може розв’язати задачу»), надійність («чи розв’язує її стабільно»), безпека («чи не робить забороненого»), відповідність продукту («чи допомагає в нашому сценарії») і вартість («чи вкладається в бюджет токенів і затримки») змінюються окремо. Високий бал на відкритому наборі знань не гарантує безпечну відмову у вашій довідці.

Тест перевіряє твердження, а не «розум». Набір на кшталт іспиту з варіантами відповіді перевіряє вибір із закритого списку. Виконання згенерованого коду перевіряє, чи проходить програма приховані випадки. Порівняння двох відповідей людьми перевіряє вподобання стилю й корисності, а не істинність. Поки твердження не назване, цифра зі звіту неінтерпретована.

Публічний рейтинг — чужа вибірка з чужою ціною помилки. Він корисний як грубий фільтр кандидатів. Для випуску потрібен власний набір: ваші формулювання, ваші заборони, ваші еталони і ваш збиток від хибної згоди.

Автоматичний суддя — прискорювач, не істина. Модель, яка оцінює іншу модель, успадковує її сліпі зони і змінюється разом із версією. Її калібрують на людській розмітці і не ставлять єдиним бар’єром там, де ціна помилки висока.

Регресія продукту важливіша за полювання за публічним рейтингом. Падіння на п’яти ваших критичних сценаріях важливіше за приріст на тисячі чужих питань. Прихована контрольна вибірка і версіонування набору захищають від підгонки промпту під відомий тест.

Що називають якістю мовної моделі

Для функції з фіксованим входом і виходом «тест» зазвичай означає: за цими аргументами виходить цей результат. У мовної моделі вхід — вільний текст, вихід — розподіл наступних токенів, а «правильний» результат часто не єдиний. Тому якість доводиться розкладати на шари.

Можливості — верхня межа того, що модель узагалі вміє на класі задач: математика, код, витяг полів, дотримання довгої інструкції. Їх вимірюють на відкритих і закритих наборах, часто без прикладів у контексті або з кількома демонстраціями.

Надійність — наскільки стабільний цей рівень. Та сама задача за температури вище нуля, після перефразування питання або після зміни системної інструкції може дати іншу відповідь. Команда, яка проганяє набір один раз за температури нуль, вимірює стелю, а не поведінку в чаті.

Фактичність і обґрунтованість — чи не вигадує модель факти і чи спирається на поданий контекст. Це різні властивості. Модель може чесно відмовитися і бути фактичною, але непотрібною. Може гарно відповісти за корпусом і все одно спотворити цифру в таблиці.

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

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

Продуктова придатність — чи розв’язує модель ваші задачі за ваших прав доступу, затримки й ціни. Цей шар не можна купити чужим рейтингом.

Публічні набори задач: знання, математика, код, міркування

Відкриті набори — це стандартизовані іспити. Їхня сила в порівнюваності між лабораторіями. Їхня слабкість — у тому, що вони вимірюють чужий іспит, частина якого могла потрапити в дані навчання.

Класичні набори знань на кшталт MMLU перевіряють вибір відповіді з кількох варіантів зі шкільних і університетських предметів. Це зручно рахувати: є ключ, є частка правильних. Це погано переноситься на вільну відповідь у продукті: модель може вгадати літеру і не вміти пояснити, або навпаки — дати правильне міркування і спіткнутися об формат бланка. Багатопредметність маскує провал в одному домені, якщо дивитися лише середнє.

Математичні набори на кшталт GSM8K і олімпіадних вибірок перевіряють багатокроковий рахунок і іноді формалізований вивід. Тут еталон часто однозначний, тому автоматична перевірка сильніша, ніж на есе. Але шкільний сюжет «у Каті п’ять яблук» слабко передбачає помилку моделі на вашій формулі тарифу з винятками і курсами валют.

Кодові набори — від синтезу функції за описом (HumanEval і родичі) до правок у репозиторії (SWE-bench і похідні). Вони ближчі до інженерії: приховані тести виконуються, «майже правильний» код не проходить. Навіть тут твердження вузьке: модель уміє закрити цей клас задач у цій обв’язці (доступ до файлів, кілька спроб, конкретний суддя). Зміна обв’язки змінює бал сильніше, ніж зміна «інтелекту».

Набори на «міркування» намагаються впіймати ланцюжок кроків, а не лише фінальне число. Їх легко зіпсувати підказкою «думай покроково» в системній інструкції, яку в продукті ви якраз заборонили через довжину і вартість. Порівнюйте моделі в тому режимі, в якому їх викликатимете: з інструментами чи без, з короткою чи довгою відповіддю.

Зараження тестової вибірки — окремий ризик. Якщо формулювання задач зустрічалися в навчальному корпусі, бал відображає пам’ять, а не узагальнення. Практично це означає: не ставте публічний набір єдиним критерієм закупівлі і тримайте власну приховану вибірку, яку не публікуєте в промптах і тікетах.

Уподобання людей і арени парних порівнянь

Люди погано ставлять абсолютний бал «наскільки хороша відповідь», але порівняно впевнено обирають із двох. Звідси арени на кшталт чату з парним голосуванням: дві моделі відповідають на один запит, людина позначає переможця, з тисяч таких дуелей рахують рейтинг.

Що перевіряє арена. Уподобання як відповіді в діалозі: ясність, тон, готовність допомогти, відсутність відмови, іноді стилістичну близькість до очікувань аудиторії. Сильна модель на арені часто та, що охочіше відповідає і звучить упевнено. Це може бути саме та поведінка, яку ви хочете придушити в юридичному чи медичному контурі.

Чого арена не перевіряє. Істинність без експертизи. Дотримання вашої політики. Поведінку на ваших внутрішніх документах. Вартість і хвіст затримки. Стійкість до ворожого вводу. Зміщення вибірки запитів: волонтери арени питають не те, що питає бухгалтер у системі обліку.

Парне порівняння всередині команди — інший інструмент. Експерти предметної області порівнюють кандидата з поточною версією на ваших випадках. Рубрика має бути явною: фактичність, повнота, відмова, тон, формат. Інакше переможе «ввічливіший абзац».

Модель-суддя і автоматичні текстові метрики

Коли відповідей тисячі, людей не вистачає. Два обхідні шляхи: порівняти текст з еталоном поверхневими метриками і попросити іншу модель винести вердикт.

Перекриття токенів (ROUGE, подібні схеми) і близькість векторних представлень (BERTScore і аналоги) дешеві й відтворювані. Вони добре ловлять «схоже на еталон». Вони погано ловлять заперечення і пряму суперечність: відповідь «заборонено» і «дозволено» можуть виявитися близькими за словами або за вектором. Дослідження метрики MATCHA якраз показує, що класичні схеми ставлять високий бал тексту, який спростовує еталон; розбір — у замітці про цю метрику.

Модель-суддя читає завдання, відповідь і іноді еталон, потім ставить оцінку або обирає переможця. На багатьох задачах вільної відповіді вона краще збігається з людьми, ніж перекриття токенів. Ціна відома: суддя упереджений до довжини, до свого «сімейства» моделей, до порядку варіантів, до формулювання рубрики. Зміна версії судді змінює історію графіків, як зміна компілятора змінює попередження.

Практичні правила. Фіксуйте ідентифікатор судді, температуру, системну інструкцію і рубрику як частину версії оцінки. Калібруйте на прихованій людській вибірці: частка згоди, систематичні помилки за стратами. Для критичних класів (безпека, гроші, здоров’я, доступ) не робіть суддю єдиним бар’єром. Для масового сортування чернеток — робіть, але залишайте хвіст на експерта.

Окремо стоїть схема «модель перевіряє модель на вигадках» без еталона. Це слабкий сигнал: модель може впевнено підтвердити власну вигадку. Сильніше — перевірити твердження проти поданого контексту або проти структурованого факту.

Точний збіг, виконання і трасування інструментів

Найчесніші тести — ті, де вердикт не читає прозу.

Витяг полів: модель має повернути JSON за схемою. Перевірка — валідатор схеми плюс порівняння значень з еталоном. Тут ловлять зайві поля, зміну типів, «майже правильні» дати. Для шлюзів і агентів це базовий шар: якщо формат плаває, далі конвеєр не має права працювати.

Виконання коду: згенерована функція або патч проганяються проти прихованих тестів. Твердження: програма задовольняє специфікацію тестів, а не «виглядає як Python». Слабке місце — тести, які написала та сама модель, і обв’язка, що дає підказки зі стека викликів.

Виклик інструментів: еталон — не текст відповіді, а послідовність і аргументи викликів. Перевіряють, що модель викликала потрібний інструмент, не викликала заборонений, передала коректний ідентифікатор, зупинилася після успіху. Це ближче до інтеграційного тесту агента, ніж до іспиту зі знань. Без такої перевірки «розумний чат» може розповідати, що надіслав листа, не надіславши його.

Детерміновані оракули (калькулятор, база, компілятор, контракт API) варто викликати з перевірки, а не просити модель переказувати їхній результат. Інакше ви знову оцінюєте прозу.

Фактичність, обґрунтованість і межа з RAG

Два різні питання плутають найчастіше.

«Чи правильне твердження про світ?» — фактичність. Для неї потрібен еталон поза моделлю: база знань, документ, експерт, виконання. Без опори це оцінка «звучить правдоподібно».

«Чи випливає твердження з поданого контексту?» — обґрунтованість. Тут еталон — фрагменти, які ви самі поклали у вікно. Модель може бути обґрунтованою і фактично застарілою, якщо контекст застарів. Може бути фактично правильною «з параметрів» і при цьому порушувати правило «відповідай лише за документами».

Для помічників із пошуком ці шари розводять спеціально: спочатку вимірюють, чи потрапив потрібний фрагмент у видачу, потім — чи використано його у відповіді, потім — чи не додала модель зайвого. Подробиці ланцюжка — в промисловій інженерії RAG, збір еталонів — у золотому наборі для RAG. Цей матеріал фіксує лише принцип: не оцінюйте генерацію однією цифрою, якщо помилка могла статися на пошуку.

Перевірки без пошуку теж потребують політики відмови. Набір, де на кожне питання є відповідь, вчить модель ніколи не казати «не знаю». Додайте випадки без відповіді і вимірюйте хибні відповіді окремо від корисних.

Безпека, політики і ворожі перевірки

Звичайний іспит зі знань майже не бачить шкоди. Безпеку перевіряють окремими наборами.

Політичні тести задають заборонені класи: інструкції щодо шкоди, обхід модерації, запити чужих секретів, дії поза роллю асистента. Еталон тут часто «відмовити / ескалювати / відповісти в межах політики», а не «дати найкращу відповідь». Метрика — частка порушень і частка хибних відмов на безпечних запитах. Затиснути відмову — легко покращити «безпеку» ціною непотрібності.

Впровадження інструкцій перевіряє, чи підкориться модель тексту в документі, на вебсторінці або в повідомленні користувача на кшталт «ігноруй попередні правила». Контур продукту, який підмішує ненадійний контекст, зобов’язаний мати такі випадки в регресії. Розбір класу атак — у захисті від впровадження інструкцій і в обмеженнях ШІ.

Витік системної інструкції і секретів із контексту — окремий набір: прямі прохання «повтори свої правила», непрямі («які інструменти тобі доступні?»), спроби витягти ключі з історії. Тут еталон — відсутність секрету у виводі, а не ввічлива відмова.

Ворожа перевірка (червона команда) не замінює регресію. Це дослідження: люди й автоматичні генератори шукають нові діри. Знайдене підвищують до постійного випадку. Плутати разове дослідження з бар’єром випуску — лишати діру відкритою до наступного сеансу.

Мультимодальність і інструменти розширюють поверхню: модель може відмовити в тексті і водночас викликати небезпечний інструмент. Тест зобов’язаний дивитися на дію, а не лише на абзац.

Регресія продукту проти полювання за публічним рейтингом

Команда обирає модель за таблицею лідерів, вбудовує її, потім змінює системну інструкцію, інструменти і маршрутизацію — і дивується, що «якість плаває». Публічний бал описував іншу збірку.

Регресійний набір продукту — це не зменшений MMLU. Це ваші критичні діалоги: типовий успішний запит, точний ідентифікатор, відмова, конфлікт політик, межа орендаря, довгий контекст, виклик інструмента, ворожа фраза в документі. Кожен випадок має власника, рівень ризику і правило: блокувати випуск чи лише спостерігати. Як улаштувати бар’єри в CI — у контурі оцінки.

Три популяції, які варто тримати окремо. Набір коміту — десятки детермінованих випадків, секунди, без дорогого судді. Набір релізу — ширший, може включати модель-суддю і людську вибірку. Прихований контроль — випадки, яких немає в тікетах налаштування промпту, щоб не вивчити тест напам’ять.

Зміна моделі, промпту, температури, маршруту шлюзу і версії судді — різні експерименти. Якщо змінюєте два одразу, ви не знаєте, що покращило графік. Фіксуйте базову версію і порівнюйте пари на тих самих входах.

Економіка тут та сама, що в звичайному ПЗ: перевіряйте пропорційно до шкоди, а не «покриттю питань». Рамка — в економіці вартості помилок. Один пропущений сценарій списання важливіший за сотню зелених жартівливих запитів.

Онлайн-перевірка: тіньовий трафік, порівняння і сліди

Офлайн-набір старіє. Користувачі ставлять нові формулювання, корпус документів рухається, мода на промпти обходу обмежень змінюється. Онлайн-шар не скасовує офлайн, а ловить дрейф.

Тіньовий прогін ганяє нову версію на живих запитах без показу користувачеві. Порівнюють відмови, довжину, виклики інструментів, спрацювання політик, розходження з поточною відповіддю. Це дешевше за інцидент і дорожче за офлайн-набір: потрібні маскування, строки зберігання і заборона на потрапляння секретів у журнали оцінки.

Контрольоване порівняння двох версій на живому трафіку показує вплив на продукт: конверсія, повторні питання, ескалація до людини, оцінка користувачем. Хвіст «не сподобалось» змішує погану відповідь, повільну відповідь і хибний сценарій. Без розмітки причини порівняння вчить оптимізувати ввічливість.

Явні сигнали користувача (палець угору, «перефразуй», зміна теми) — слабкі й зміщені. Їх використовують як джерело кандидатів у золотий набір після розбору, а не як єдину метрику якості моделі.

Трасування зобов’язане зберігати достатньо, щоб відтворити випадок: версія моделі, системна інструкція, інструменти, фрагменти контексту за політикою даних. Інакше онлайн-оцінка перетворюється на анекдоти з чату підтримки.

Як зібрати набір видів перевірок під продукт

Почніть зі шкоди, не з каталогу абревіатур. Для довідки за внутрішніми регламентами критичні обґрунтованість, відмова і права доступу. Для агента, який викликає оплату, — схема виклику, ідемпотентність, заборона зайвих інструментів. Для публічного чату — безпека і тон. Для помічника в середовищі розробки — виконання тестів і різниця змін, а не ерудиція.

Мінімальний каркас, який закриває більшість сервісів із мовною моделлю:

Не копіюйте всі відкриті іспити «для повноти». Кожен набір коштує супроводу: хто оновлює, як потрапляє новий інцидент, коли випадок видаляють. Мертвий каталог із десяти тисяч чужих питань гірший за живих вісімдесят ваших.

Зв’яжіть види перевірок із маршрутизацією. Дешева модель на типових питаннях може проходити лише формат, відмову і маленький регресійний набір. Дорога модель на спірних тікетах — ще й людську вибірку. Як бюджети стикуються зі шлюзом — у матеріалі про шлюз мовних моделей і операційну дисципліну витрат.

Типові помилки

Один бал на всіх слайдах. Усереднення знань, безпеки й уподобань дає зручну презентацію і непотрібне рішення про випуск.

Оцінка прози там, де є оракул. Питати суддю, чи правильна сума, замість того щоб додати числа.

Тести, які бачив промпт. Вивчили набір — покращили графік — зламалися на першому новому формулюванні.

Зміна моделі і судді в одному релізі. Історія якості непоясненна.

Арена як приймання. Користувачам арени подобається балакучість; вашому юристу — відмова.

Безпека як частка відмов. Модель, яка відмовляє завжди, «безпечна» і непотрібна. Потрібні і заборонені, і дозволені випадки.

Ігнорувати обв’язку. Бал SWE-bench з агентом і без агента — різні продукти. Ваш сервер протоколу контексту моделей — частина системи, яку теж тестують.

Плутати пілот із десяти діалогів із набором. Пілот знаходить діри. Набір фіксує їх і не дає повернутися.

Часті питання

Чим тест мовної моделі відрізняється від модульного тесту?

Модульний тест фіксує детермінований результат функції. Тест моделі фіксує твердження про поведінку на розподілі входів: частка порушень, стійкість до перефразування, якість відносно базової версії. Де вивід можна перевірити машиною (схема, код, виклик інструмента), варто писати майже звичайний автотест.

Чи потрібно ганяти MMLU, якщо продукт — внутрішній помічник?

Ні як бар’єр випуску. Так як грубий фільтр при виборі сімейства моделей. Рішення про ввімкнення приймають ваші регресія, безпека й обґрунтованість.

Чи можна обійтися однією моделлю-суддею?

Для чорнового сортування — так. Для грошей, доступу, здоров’я і регуляторики — ні. Суддю калібрують людьми і доповнюють детермінованими перевірками.

Що важливіше: офлайн-набір чи відгуки користувачів?

Офлайн дає відтворювану заборону на випуск. Відгуки показують нові формулювання і дрейф. Одне без іншого сліпне: набір старіє, відгуки зміщені й невимірні.

Як зрозуміти, що публічний набір заражений навчанням?

Прямого доказу в споживача API зазвичай немає. Практичний захист — власна прихована вибірка, перефразування, свіжі випадки з продакшену і недовіра до стрибка бала без зростання на ваших задачах.

Скільки випадків достатньо?

Стільки, щоб покрити страти шкоди, а не «кругле число». Для бар’єра коміту часто вистачає десятків критичних сценаріїв. Для релізу — сотень із розбивкою за типами помилок. Тисячі чужих питань не замінюють двадцять ваших інцидентів.

Температура нуль робить оцінку чесною?

Вона робить її стабільнішою і ближчою до стелі. У чаті температура й перефразування інші. Ганяйте релізний набір у тому режимі, який бачить користувач, і окремо — детермінований набір коміту.

Як тестувати агента, а не «голу» модель?

Еталоном стає траса: які інструменти викликано, з якими аргументами, чим закінчився цикл, чи дотримано права. Текстова відповідь — вторинна. Обв’язка входить у версію системи так само, як вага моделі. Практична рамка — в агентній інженерії.

Коли людська розмітка обов’язкова?

Коли автоматичний оракул слабкий: тон, спірна повнота, нові класи шкоди, розбіжності політик. Людей використовують точково і дорого: калібрування судді, прихований контроль, розбір інцидентів — не розмітка кожної відповіді в проді.

Як зв’язати тести моделі з тестами RAG?

Розведіть шари. Пошук вимірюють повнотою потрібних фрагментів. Генерацію — обґрунтованістю і відмовою. Наскрізна відповідь потрібна, але без розкладання ви змінюватимете модель, коли винний індекс. Див. контур оцінки і золотий набір RAG.

Подальше читання

• Контур оцінки ШІ у 2026 — як перетворити види перевірок на CI, тіньовий трафік і критерії релізу.
• Як оцінювати корпоративний ШІ — зв’язок якості з процесом і безпекою на рівні архітектури підприємства.
• Золотий набір для оцінки RAG — еталони пошуку й відповіді, а не іспит «голої» моделі.
• Промислова інженерія RAG — де в ланцюжку народжується помилка, якої тест генерації не побачить.
• Економіка вартості помилок — скільки перевірки купувати відносно шкоди.
• Метрика, що ловить суперечність еталону — чому поверхневі текстові метрики пропускають спростування.
• Агентна інженерія — якість циклу інструментів, а не лише абзацу.

Зовнішні орієнтири (не заміна своєму набору): документація відкритих наборів задач і арен, статті про зараження тестів навчанням, практики червоних команд постачальників моделей.

Висновок

Перевірка якості мовної моделі починається з фрази, яку ви готові захищати: «на цих входах система дотримується цього контракту». Контракт буває про знання, про формат, про обґрунтованість, про дію інструмента, про заборону. Під кожен контракт — свій оракул. Чужий іспит, арена і модель-суддя — корисні прилади з відомою похибкою. Рішення про випуск приймають ваші страти шкоди, прихований контроль і здатність пояснити відкат.

Зберіть за одну ітерацію не «повний чужий іспит», а коротку матрицю: які твердження критичні, чим їх перевіряти, що блокує реліз. Потім нарощуйте набір випадками з інцидентів, а не рядками з чужої таблиці лідерів. Лабораторний принцип тут простий: вимірюють те, що не можна підмінити враженням від вдалого чату.