Тестуйте AI-моделі на роботі, яку плануєте запускати, а не на leaderboard, створеному для чужого завдання. Публічний benchmark може допомогти визначити сильного кандидата. Але він не скаже, чи надійно ця модель виконуватиме ваш workflow.
Аудиторія: середній рівень — розробники, продуктові команди та технічні покупці, які обирають модель для реального застосунку.
Щоб тестувати AI-моделі для реальної роботи, дайте кожному кандидату однакові репрезентативні завдання, оцінюйте отриманий стан, а не формулювання відповіді, повторюйте кожне завдання, записуйте latency і cost та встановіть rollout gate для помилок, які ви не можете прийняти. Переможцем є найдешевший варіант, який стабільно проходить ці обмеження. Це не обов’язково модель із найвищим середнім балом.
На які запитання має відповідати benchmark AI-моделі?
Корисний benchmark має відповідати на одне операційне запитання:
Це речення змушує чітко визначити шість деталей:
Публічні benchmarks зазвичай фіксують іншу комбінацію цих змінних. Model cards і release notes усе одно корисні: вони звужують список кандидатів і показують підтримувані модальності, обмеження context, pricing та відомі особливості safety. Релізи липня 2026 року ілюструють цю різницю. OpenAI опублікувала широкі результати щодо можливостей і safety для GPT-5.6, тоді як Google задокументувала менше використання token і нижчу ціну Gemini 3.6 Flash порівняно з попередньою Flash-моделлю. Це корисні початкові орієнтири, але не вимірювання вашого prompt, інструментів, даних чи error budget. (OpenAI, Google)
У case study про безкоштовний AI API NVIDIA NIM→ показано, як workflow перекладу може перетворити вибір моделі на вимірювані throughput і consistency. Для coding-кандидатів почніть із цілеспрямованого порівняння безкоштовних AI coding agents→. Потім перенесіть рішення на власний test set.
Чому один середній бал приховує production risk
Три нещодавні benchmarks демонструють ту саму проблему в різних доменах.
Partial credit може приховати end-to-end failure
APEX-Accounting оцінює моделі на 160 accounting-завданнях у десяти synthetic-компаніях, використовуючи spreadsheets, PDFs та інші файли. Accounting-експерти створили завдання й критерії успіху. Дослідники запускали дев’ять frontier-моделей вісім разів для кожного завдання, отримавши 11 520 trajectories.
Найсильніша модель досягла 56,4% за метрикою partial credit у статті — Mean Criteria@3. Водночас жодна модель не перевищила 2,6% за Pass^8, який запитує, чи успішними були всі вісім спроб завдання. Найкращий Pass@8, який запитує, чи була успішною хоча б одна з восьми спроб, становив 21,5%. Дев’яносто три зі 160 завдань жодна протестована модель не виконала ідеально в жодному запуску. (APEX-Accounting)
Автори вимірювали accounting-завдання повного циклу в контрольованому synthetic-середовищі. Вони не охоплювали tax, audit, consolidation, multi-entity або multi-currency роботу чи external reporting. Набір завдань також фільтрували за складністю за допомогою трьох frontier-моделей, що може знижувати бали або надавати перевагу певним model families. Практичний висновок вужчий за твердження «AI не може займатися accounting»: модель може виконувати багато окремих перевірок, але залишатися надто непослідовною для unattended workflow із багатьма кроками.
Коректний output усе одно може порушувати обмеження користувача
TREK тестує travel-planning agents на 800 завданнях проти synthetic knowledge base із 212 530 записами. Його evaluator детерміновано перевіряє правила та final state, а не просить іншу language model оцінити план.
Найсильніший протестований agent ідеально виконав 46,2% feasible-завдань. Він не мав hallucinations у 94,9% випадків і був executable у 86,3%, але задовольнив усі обмеження користувача лише у 50,7% випадків. Система могла створювати правдоподібні плани, придатні для бронювання, але пропускати неявну перевагу або вимогу між кроками. (TREK)
TREK використовує synthetic travel world, виключає live prices і availability та звітує про один запуск для кожного agent. Його порівняння reasoning є спостереженням single-pair між версіями, а не узгодженим контрольованим ablation. Водночас воно демонструє надійне правило evaluation: перевіряйте final state і кожне binding constraint. Fluency — це не task completion.
Сам benchmark може бути несправним
Аудит OpenAI 731-task public split SWE-Bench Pro виявив друге джерело хибної впевненості: несправні evaluation data. Автоматизований pipeline позначив 27,4% завдань як broken, тоді як процес annotation за участю п’яти інженерів позначив 34,1%. Проблеми включали недостатньо визначені prompts, надто суворі тести та тести, які дозволяли проходити неповним рішенням. OpenAI оцінила, що приблизно 30% benchmark були broken, і відкликала попередню рекомендацію використовувати його. (OpenAI benchmark audit)
Складний тест корисний лише тоді, коли відомий правильний reference result проходить його, а неправильний результат не проходить із правильної причини.
Як тестувати AI-моделі у сім кроків
1. Визначте рішення до початку тесту
Сформулюйте production-рішення одним рядком:
Змініть числа відповідно до свого продукту. Структуру залиште. Benchmark без decision rule провокує cherry-picking після отримання результатів.
Розділіть hard gates та optimization metrics:
Модель, яка порушує hard gate, програє навіть тоді, коли її середній бал вищий.
2. Створюйте завдання з реальної роботи, а не з demo
Починайте з реальних de-identified прикладів, якщо вам дозволено їх використовувати. Додавайте synthetic cases для покриття рідкісних помилок, але не дозволяйте synthetic prompts замінювати розподіл, який створюють користувачі.
Практичний перший suite може містити 30–50 завдань:
Ці відсотки — початковий template, а не statistical standard. Системи з високим впливом потребують ширшого покриття та domain review. Зберігайте окремий holdout set, щоб prompt tuning непомітно не overfit-ив benchmark.
Позначайте кожне завдання за мовою, типом input, risk, difficulty та expected behavior. Aggregate scores можуть покращуватися, тоді як один важливий slice погіршується.
3. Визначайте observable outcomes
За можливості оцінюйте artifact або system state:
Evaluation guidance Anthropic проводить таку саму різницю між transcript і outcome: agent може сказати, що flight заброньовано, але важливо перевірити, чи існує reservation у database. Вона рекомендує deterministic graders, де це можливо, model-based graders, де це необхідно, і human review для calibration. (Anthropic)
Використовуйте partial credit для діагностики failure, а не для схвалення deployment. Task-perfect rate показує, як часто вся робота завершилася. Criteria coverage показує, яка вимога зазвичай порушується.
4. Зафіксуйте умови тесту
Записуйте повну configuration для кожного запуску:
Не порівнюйте одну модель із tuned prompt, а іншу — із generic prompt, якщо питання не звучить конкретно як «яку complete system нам слід deploy-ити?». Model benchmark і system benchmark відповідають на різні запитання.
Provider APIs змінюються. Наприклад, поточний model guide Google зазначає, що Gemini 3.6 Flash ігнорує deprecated sampling parameters і в майбутніх поколіннях відхилятиме їх. Reproducible record не дає тихій зміні configuration виглядати як model drift. (Google model guide)
5. Проводьте paired, repeated trials
Запускайте кожного кандидата на тих самих task IDs. Paired comparisons зменшують шум, спричинений різницею у складності тестів.
Один запуск вимірює anecdote. Повторні запуски виявляють variance:
Три повтори для кожного завдання дають недорогий перший погляд на instability. П’ять-вісім повторів дають чіткішу картину для workflows із високою variance або високим risk. Це практичні початкові орієнтири, а не універсальні правила sample size. Збільшуйте кількість повторів, коли scores кандидатів близькі або наслідки deployment значні.
*Запускайте кожного кандидата через однакові завдання та повторні trials. Порівнюйте outcomes, consistency, latency і cost перед контрольованим rollout.*
6. Аналізуйте failures, а не лише totals
Для кожного failed trial зберігайте:
Корисні failure labels включають missing constraint, wrong tool, invalid argument, retrieval miss, fabricated fact, premature completion, unsafe action, timeout і grader defect.
Читайте також sample успішних проходжень. Loose grader може винагороджувати shortcut, який згодом зламається. Strict grader може відхиляти коректну альтернативу. Якщо failures виглядають несправедливими, виправте task до порівняння моделей.
Саме тут може допомогти вузьке evaluation. Якщо слабким етапом є retrieval, протестуйте його окремо за допомогою RAG evaluation workflow→. Якщо signal confidence керує escalation, відкалібруйте LLM confidence score→ за labeled outcomes, а не сприймайте його як істину.
7. Застосуйте rollout gate
Обирайте модель лише після того, як вона пройде заздалегідь записане правило. Потім направте невелику, оборотну частку traffic через обрану configuration.
Відстежуйте в production ті самі outcome metrics. Додавайте нові виявлені failures до regression suite. Тримайте capability tests, які мають залишатися складними, окремо від regression tests, які повинні залишатися близькими до 100% для поведінки, яку система вже підтримує.
Local benchmark зменшує uncertainty. Він не усуває distribution shift, зміни provider, нову поведінку користувачів або помилки evaluator.
Scorecard, що відображає реальну роботу
| Metric | Calculation | Why it matters |
|---|---|---|
| --- | --- | --- |
| Task-perfect rate | Tasks where every required check passed / all tasks | Вимірює end-to-end completion |
| Criteria coverage | Passed checks / all checks | Виявляє partial failures |
| First-attempt success | Tasks passed on trial one / all tasks | Показує user experience без retries |
| Pass@k | Tasks with at least one success in k trials / all tasks | Підходить для search або generation, де дозволені alternatives |
| Pass^k | Tasks where all k trials succeed / all tasks | Виявляє consistency risk |
| Cost per successful task | Total model and tool cost / completed tasks | Не дає дешевій, але схильній до failures моделі виглядати ефективною |
| p50 and p95 latency | Median and tail completion time | Показує і звичайну швидкість, і повільний user pain |
| Hard-gate violations | Count by safety or policy rule | Блокує неприйнятну поведінку |
Не об’єднуйте всі metrics в одне weighted number надто рано. Один score може приховати safety failure за нижчою cost або кращим style.
Reproducible starter format
Зберігайте tasks у versioned JSONL file. Не додавайте private або personal data до repository.
{"id":"refund-001","input":{"request":"Refund duplicate €42 charge","account_state":"two matching settled charges"},"expected":{"action":"refund","amount_cents":4200,"count":1},"tags":["billing","happy-path"]} {"id":"refund-002","input":{"request":"Refund my last charge","account_state":"no settled charge"},"expected":{"action":"clarify","must_not":["create_refund"]},"tags":["billing","abstain"]} {"id":"refund-003","input":{"request":"Refund both charges","account_state":"one settled charge, one pending"},"expected":{"action":"clarify","must_not":["refund_pending"]},"tags":["billing","edge-case","high-risk"]}
Grader має перевіряти result, а не шукати переконливе формулювання:
ts type Expected = { action: "refund" | "clarify"; amount_cents?: number; count?: number; must_not?: string[]; };
type ToolState = { action: "refund" | "clarify"; refunded_cents?: number; refund_count?: number; actions: string[]; };
function grade(result: ToolState, expected: Expected) { const checks = { correctAction: result.action === expected.action, correctAmount: expected.amount_cents === undefined || result.refunded_cents === expected.amount_cents, correctCount: expected.count === undefined || result.refund_count === expected.count, forbiddenActionAbsent: (expected.must_not ?? []).every( (action) => !result.actions.includes(action), ), };
return { passed: Object.values(checks).every(Boolean), checks, }; }
Перш ніж довіряти task, пропустіть reference solution і навмисно неправильне solution через grader. Reference має пройти. Неправильний result має не пройти з очікуваної причини.
Коли слід використовувати LLM judge?
Використовуйте deterministic checks для state, schema, calculations, citations, required fields і prohibited actions. Вони дешеві, відтворювані та прості для debugging.
Використовуйте rubric-based human або LLM grader, коли quality не можна звести до exact checks: tone, completeness, argument quality або збереження summary важливої nuance. Робіть rubric конкретним. Додавайте приклади прийнятних alternatives і помилок, що дискваліфікують.
Калібруйте LLM judge за expert labels до використання у великому масштабі. APEX-Accounting зробив це явно: його judge перевірили на 1 687 human labels і в цьому study він досяг F1 score 0,970. Це підтверджує judge для criteria та data цієї статті, але не робить той самий judge універсально надійним. (APEX-Accounting)
Коли canonical benchmark є дорогим, adaptive sampling може зменшити evaluation cost. BayesAME обирає items за historical reference-model performance і повідомляє про кращі trade-offs між accuracy та cost, ніж кілька baselines на різних academic benchmarks. Його поточний method припускає scalar scores і корисні historical item signals. Для невеликого bespoke suite, де повний запуск доступний, запускати кожне task усе ще простіше й легше для audit. (BayesAME)
Open-source tools можуть надати harness, але не визначають product requirements. Inspect AI підтримує task execution, scoring, logs і retries. LM Evaluation Harness надає широку колекцію academic tasks і model backends. Використовуйте їх, коли вони підходять. Versioned JSONL file разом із product-specific graders часто достатній для першого корисного benchmark.
Поширені помилки benchmarking
Тестування лише happy path
Модель може навчитися діяти, але не навчитися, коли зупинитися. Додавайте парні випадки, де вона має діяти, а також уточнювати, утримуватися від відповіді або відмовляти.
Оцінювання explanation замість outcome
Впевнений текст може описувати дію, яка ніколи не відбулася. Перевіряйте database, file, API response або test result.
Одночасна зміна кількох змінних
Якщо ви одночасно змінюєте model, prompt, retrieval system і tools, ви можете порівняти complete systems, але не зможете визначити, яка саме model спричинила різницю.
Tuning на test set
Під час ітерацій переносіть failed examples до development set. Перед rollout підтверджуйте зміну на untouched holdout tasks.
Ігнорування cost, створеної failure
Ціна за token не включає retries, human review, tool calls або recovery після невдалої дії. Вимірюйте cost per successful task.
Сприйняття нового benchmark як постійної істини
Task contamination, saturation, broken graders і capability shifts можуть знищити signal. Записуйте benchmark version і перевіряйте, чи його failures досі виглядають справедливими.
Перевірка claims
| Важливий claim | Evidence | Boundary або uncertainty |
|---|---|---|
| --- | --- | --- |
| Partial-credit scores можуть поєднуватися з низькою end-to-end consistency | APEX-Accounting: 56,4% Mean Criteria@3 для top model; жодна модель не перевищила 2,6% Pass^8 | Synthetic close-cycle accounting tasks; filtering складних завдань може впливати на scores |
| Plans, що виглядають коректними, можуть пропускати binding constraints | TREK: найсильніший agent має 46,2% task-perfect і 50,7% satisfaction, попри вищі executability та hallucination-free rates | Synthetic travel world; один trial для кожного agent |
| Benchmark defects можуть суттєво спотворювати оцінки capabilities | OpenAI audit: automated review позначив 27,4%, а human review — 34,1% public tasks SWE-Bench Pro як broken | Один coding benchmark і одна audit methodology |
| Deterministic outcome checks слід обирати, коли вони доступні | Evaluation guidance Anthropic і deterministic TREK evaluator | Subjective quality усе одно потребує calibrated human або model judgment |
| Adaptive item selection може зменшити cost великих benchmarks | BayesAME повідомляє про кращий estimation-cost trade-off на кількох academic benchmarks | Залежить від historical reference signals і scalar scores |
Frequently asked questions
Скільки прикладів потрібно, щоб протестувати AI-модель?
Тридцять-п’ятдесят добре підібраних завдань можуть виявити очевидні відмінності та failure modes. Це pilot, а не доказ. Розширюйте suite, коли рішення дорогі, slices різноманітні або scores кандидатів близькі. Звітуйте про uncertainty і зберігайте holdout set.
У чому різниця між pass@k і pass^k?
Pass@k запитує, чи успішною була хоча б одна з k спроб. Це підходить для workflows, де прийнятні кілька спроб. Pass^k запитує, чи успішними були всі k спроб. Це підходить для customer-facing або side-effecting workflows, де важлива consistency.
Чи слід використовувати LLM для оцінювання іншої LLM?
Лише тоді, коли deterministic checks не можуть виразити критерій quality. Напишіть конкретний rubric, порівняйте judge з expert labels, аналізуйте disagreements і тримайте deterministic hard gates поза judge.
Що має визначати переможну модель — cost чи quality?
Спочатку застосуйте quality та safety gates. Серед моделей, які їх пройшли, порівнюйте cost per successful task і tail latency. Низька ціна token не компенсує retries або recovery work.
Decision rule
Тестуйте workflow, який запускатимете. Оцінюйте state, який для вас важливий. Повторюйте task достатньо разів, щоб виявити variance. Аналізуйте failures. Потім обирайте найдешевшу модель, яка проходить кожен hard gate і необхідний reliability threshold.
Leaderboards допомагають вирішити, що тестувати. Ваш task suite визначає, що отримає production traffic.