Eval-first: спершу перевірки, потім код з ШІ

Що таке eval-first простими словами

Замов торт у дуже моторного, але трохи навіженого кондитера. Скажеш «зроби торт» - він зробить. Якийсь. Може, з грибами. І буде щиро гордий собою.

А тепер скажи інакше: «торт шоколадний, на 8 шматків, без горіхів - у гостя алергія, і свічка хай стоїть, а не падає». Бачиш різницю? У кондитера зʼявився чек-лист, за яким він перевірить сам себе. І ти перевіриш - не куштуючи на зуб увесь торт.

Ось це і є eval-first Eval-first (від англ. evaluation - оцінка, перевірка) - підхід, за якого ти спершу описуєш критерії успіху та спосіб їх перевірити, і лише потім запускаєш роботу. Перевірка зʼявляється раніше за код. : спершу придумай, як ти зрозумієш, що вийшло добре, а вже потім запускай ШІ-агента. Звучить занудно. Насправді це і є головний секрет, чому в одних ШІ видає робочий продукт, а в інших - гарне сміття.

Навіщо eval-first потрібен вайбкодеру

Ти вайбкодер. Код руками ти не пишеш - ти ставиш завдання агенту і приймаєш результат. І ось тут, на «приймаю результат», eval-first рятує тобі і нерви, і гроші:

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

Різниця між «ШІ зробив щось» і «ШІ зробив те, що треба» - це найчастіше одне запитання, поставлене до старту: «а як ми зрозуміємо, що вийшло?»

Як працює петля eval-first

У скілах ECC це звуть eval-first loop - петля «спершу перевірки». Кроків усього чотири, і вони прості:

1. Опиши перевірки - що має запрацювати (capability) і що не має зламатися (regression).
2. Зроби замір «до» - проганяй перевірки на поточній версії, зафіксуй, що зараз падає.
3. Дай агенту робити - тепер він пише код під зрозумілу мету, а не навмання.
4. Проганяй перевірки знову - порівняй «до» і «після». Стало краще? Нічого не відвалилося?

По суті перевірка - це тести для звичайного коду, тільки для роботи з ШІ. У світі ECC так і кажуть: евали - це «юніт-тести для розробки з ШІ».

Capability і regression: нове проти старого

Їх легко переплутати - тому розкладемо по поличках.

• Capability Capability eval - перевірка того, чи вміє агент зробити щось нове, чого раніше не було: нова кнопка, нова функція, нова фіча. (чи вміє нове). Перевіряєш, чи зʼявилося те, заради чого ти все затіяв. Наприклад: «користувач реєструється за email», «форма замовлення відправляється».
• Regression Regression eval - перевірка того, що нова зміна не зламала те, що вже працює. «Регресія» = відкат назад, коли щось робоче перестало працювати. (чи не зламав старе). Перевіряєш, що вчорашнє все ще працює сьогодні. Наприклад: «стара кнопка входу на місці», «решта сторінок відкривається».

Метрика pass@k: як виміряти надійність ШІ

ШІ - штука ймовірнісна: той самий запит то виходить ідеально, то мимо. Тому надійність міряють не «так/ні», а часткою вдач із кількох спроб. Це і є pass@k pass@k - метрика надійності: «вийшло хоча б один раз за k спроб». pass@1 - з першого разу. pass@3 - хоча б раз із трьох. pass^3 - усі три спроби поспіль успішні. .

• pass@1 - вийшло з першого разу.
• pass@3 - вийшло хоча б раз із трьох спроб.
• pass^3 - усі три спроби поспіль успішні (планка вища, для критичних речей).

У скілах ECC дають такі орієнтири: для нових фіч (capability) - pass@3 від 90% і вище, а для критичних регресій - pass^3 = 100%. Усе, що працювало, зобовʼязане працювати завжди. Без винятків.

Дроби завдання на шматки по 15 хвилин

Евали працюють, лише якщо завдання можна перевірити. Гігантське «зроби мені маркетплейс» одразу не перевіриш - там сто ризиків в одному клубку. Тому в скілі agentic-engineering є правило 15-хвилинного шматочка: дроби роботу на одиниці, де кожна:

• перевіряється сама по собі, окремо від решти;
• несе один головний ризик (а не «тут тобі і дизайн, і оплата, і база разом»);
• має зрозуміле «готово» - видно, коли завершено.

Eval-first на живому прикладі: форма бронювання

Ти просиш агента: «додай на сайт кавʼярні форму бронювання столика». Без eval-first агент бадьоро ліпить форму, ти дивишся - поля є, кнопка є, «ну ок». А за день зʼясовується: форма шле порожні заявки, не перевіряє телефон і заразом зламала меню по сусідству.

А як би це зробив тямущий вайбкодер? Спершу описав би перевірки - і лише потім дав робити:

Додай на сайт кавʼярні форму бронювання столика. Але спершу, ДО коду, випиши перевірки, за якими ми зрозуміємо, що готово.
Перевірки на нове (що має запрацювати):

Форма приймає імʼя, телефон і кількість гостей.
Порожню форму відправити не можна - показується зрозуміла помилка.
Телефон без цифр не приймається.
Після успішної відправки видно повідомлення «заявку прийнято».
Перевірки на старе (що не має зламатися):

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

Хто перевіряє результат: код, ШІ чи людина

Перевірку можна доручити різним «суддям» - у скілі eval-harness їх три:

• Код-суддя (найнадійніший). Точна перевірка без суперечок: тести пройшли / збірка зібралася / потрібний рядок на місці. Можеш перевірити кодом - перевіряй кодом.
• ШІ-суддя (LLM як оцінювач). Коли «добре» не виміряти лінійкою: «чи зручний текст», «чи зрозуміла помилка». Просиш іншу модель оцінити за шкалою від 1 до 5.
• Людина-суддя (ти). Для спірного і для всього, що про безпеку. Правило ECC жорстке: перевірки безпеки ніколи не віддаємо на повний автомат - останнє слово за людиною.

Як виглядає евал-звіт PASS/FAIL

Щоб стало геть наочно - ось короткий звіт по перевірках у стилі eval-harness:

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

Часті помилки в перевірках з ШІ

• Перевіряти лише «щасливий шлях». Ти переконався, що форма працює, коли все ввели правильно. А порожні поля? А кривий телефон? Реальні люди введуть усе, включно з емодзі в графі «вік».
• Забувати про регресії. Радієш новій фічі і не помічаєш, як розвалилося старе. Завжди тримай під рукою список «що не має зламатися».
• Описувати перевірки ПІСЛЯ коду. Так ти мимоволі підганяєш критерії під те, що вже вийшло. Перевірки придумуються суворо до.
• Гнати одне гігантське завдання. Його нічим перевірити цілком. Ріж на шматки по ~15 хвилин зі зрозумілим «готово».
• «Готово» без визначення. «Зроби красиво» - агент вгадує наосліп, а ти потім незадоволений. «Готово» = конкретний список галочок.
• Віддавати безпеку на автомат. Логіни, оплата, доступи - фінальну перевірку завжди робить людина.
• Гнатися за відсотками, забувши про ціну. Можна вилизувати pass@k до блиску і не помітити, що кожна спроба жере купу токенів і часу. Стеж і за надійністю, і за витратами.