Коли компанії запускають перші пілоти з генеративним AI, усе часто починається з простого скрипта й таблиці. Але саме на етапі переходу від «воно працює в демо» до «воно стабільно працює в продакшені» більшість команд застрягає. Про цю прірву між proof‑of‑concept і реальними продуктами говорить Філ Гецел, керівник напрямку solutions engineering у Braintrust — платформі, що позиціонує себе як «agent quality platform» з фокусом на evals та observability. До Braintrust він 12 років працював у консалтингу в KPMG та Slalom, де очолював глобальний підрозділ Databricks.
Його досвід з десятками клієнтів показує: побудувати ефектний прототип на LLM сьогодні вміють багато хто, а от довести агентів до надійного продакшену — одиниці. Ключова причина — відсутність зрілих підходів до оцінювання (evals) та спільних визначень якості. Історія еволюції eval‑воркфлоу — від for‑loop і Google Sheets до колаборативних платформ — добре показує, чому без цього ланцюжка інфраструктури AI‑проєкти так часто «застигають» на стадії експериментів.
Чому простий for‑loop і таблиця працюють… лише на старті
Початковий сценарій знайомий майже кожній команді, що пробує LLM‑агентів. Є якийсь сервіс або агент, є набір вхідних прикладів, є простий скрипт — зазвичай це банальний for‑loop, який проганяє всі інпути через модель. Результати потрапляють у Google Sheets чи Excel, де команда руками виставляє оцінки, залишає коментарі, фіксує помилки.
На цьому етапі є три базові компоненти:
- спосіб виконати агента (скрипт або невеликий сервіс),
- UI для перегляду відповідей (таблиця),
- спосіб зібрати «input examples» — запити чи контексти, які запускають агента.
Для раннього дослідження це справді працює. Поріг входу нульовий: таблиці є в усіх, а написати цикл, що викликає API моделі, — завдання на кілька годин. Команда отримує перше відчуття, як поводиться агент, як змінюються відповіді після правок у промпті чи конфігурації.
Але дуже швидко виявляється, що такий підхід радше фіксує стан, ніж допомагає його покращувати. Це не експерименти, а документування. Кожна нова ітерація — це ще один аркуш, ще одна вкладка, ще один ручний процес, який важко відтворити й майже неможливо масштабувати.
Обмеження таблиць: коли людський скоринг перестає витягувати
Проблеми «табличного» етапу стають очевидними, щойно команда намагається працювати системніше.
По‑перше, порівнювати експерименти в часі майже неможливо. Кожна зміна промпта, моделі чи параметрів агента тягне за собою новий набір результатів. Вони розкидані по різних файлах і вкладках, структури колонок змінюються, хтось додає нові метрики, хтось забуває їх заповнити. Побудувати цілісну картину еволюції агента стає складно навіть для невеликої команди, не кажучи вже про великі продукти з кількома моделями.
По‑друге, аналітика в такому середовищі практично відсутня. Максимум — фільтри, умовне форматування, пара зведених таблиць. Але це не дає відповіді на питання, які критичні для продакшену: як змінюється якість на різних сегментах користувачів, як поводиться агент на рідкісних, але ризикованих кейсах, як корелюють зміни в системному промпті з частотою помилок певного типу.
По‑третє, усе тримається на людському скорингу. Люди читають відповіді, ставлять бали, пишуть коментарі. На старті це цінно: доменні експерти формують інтуїцію, що таке «добре» в конкретному бізнес‑контексті. Але як тільки зростає кількість тестових прикладів, моделей, варіантів промптів і учасників процесу, ручна оцінка стає вузьким горлечком. Вона дорога, повільна й нестабільна: різні люди по‑різному трактують критерії, втома впливає на оцінки, а узгодити стандарти якості між командами стає дедалі важче.
Нарешті, таблиці погано підтримують колаборацію. Eval‑робота — це командний вид спорту, де мають взаємодіяти інженери, продуктові менеджери, системні інженери й доменні експерти. Частина з них некомфортно почувається в «сирих» таблицях, інші взагалі не мають до них доступу. У результаті ключові знання про якість агента концентруються в кількох людях, а решта команди працює наосліп.
Власний UI та база даних: перша спроба навести лад
Наступний логічний крок для багатьох команд — вийти за межі Google Sheets і побудувати внутрішній інструмент. Типовий сценарій виглядає так: продуктова чи AI‑команда «на коліні» збирає веб‑інтерфейс, підключає базу даних (часто щось на кшталт Neon чи іншого керованого Postgres), переносить туди логіку for‑loop і починає зберігати результати eval‑запусків централізовано.
Це вже суттєвий прогрес. З’являється:
– постійне сховище результатів,
– більш дружній UI, який можна адаптувати під потреби різних ролей,
– можливість залучити більше людей до перегляду й оцінки відповідей агента.
Команда перестає жити в хаосі файлів і вкладок, отримує єдине джерело правди про те, як поводиться агент на різних наборах даних. Для багатьох інженерів це привід для гордості: внутрішній інструмент виглядає солідніше за таблицю, а процес — більш «продуктовим».
Однак на цьому етапі виявляється інша пастка: більшість таких внутрішніх UI насправді є не платформами для експериментів, а звітними панелями. Вони чудово показують, що сталося, але майже не допомагають швидко змінювати агента й перевіряти гіпотези.
Іншими словами, команда все ще більше документує, ніж експериментує. Зміна системного промпта, підбір іншої моделі, налаштування параметрів генерації — усе це вимагає залучення інженера, правок у коді, нового деплою. Ні продуктові менеджери, ні доменні експерти не можуть самостійно «погратися» з агентом і побачити, як це вплине на метрики якості.
У результаті цикл зворотного зв’язку залишається повільним, а потенціал колаборації — нереалізованим. Внутрішній інструмент вирішує проблему збереження даних, але не проблему швидкого навчання команди на цих даних.
Eval як командна гра: чому платформа має бути спільною мовою
Щоб зрозуміти, чому внутрішні UI часто «застигають» на рівні звітності, варто подивитися на те, хто взагалі бере участь у роботі з агентами.
По‑перше, це інженери — як продуктові, так і AI‑інженери, які будують логіку агента, інтегрують моделі, налаштовують інфраструктуру. По‑друге, системні інженери, які відповідають за надійність, масштабування, витрати. По‑третє, доменні експерти — люди, які глибоко розуміють предметну область: юристи, лікарі, фінансові аналітики, сапорт‑фахівці. Нарешті, продуктові менеджери, які формулюють вимоги до досвіду користувача й бізнес‑метрик.
Усі вони по‑різному дивляться на питання якості. Для інженера важливі latency, стабільність, відсутність крешів. Для доменного експерта — точність термінології, відповідність регуляціям, коректність висновків. Для PM — задоволеність користувача, зменшення навантаження на сапорт, конверсія. Якщо кожна група працює у своєму інструменті й зі своїми артефактами, спільного визначення «що таке добре» не виникає.
Тому eval‑платформа в зрілому вигляді — це не просто «тест‑раннер», а місце, де ці різні перспективи зводяться разом. Вона має:
– робити результати зрозумілими для нетехнічних користувачів,
– дозволяти доменним експертам безпосередньо впливати на критерії оцінки,
– давати інженерам достатньо гнучкості для інтеграції й автоматизації,
– створювати єдину мову для обговорення якості між усіма ролями.
Саме тому Гецел описує eval як «командний вид спорту». Якщо платформа не підтримує цю багатоперсональність, вона неминуче перетворюється на ще один технічний дашборд, який читають лише кілька людей, тоді як ключові рішення про продукт ухвалюються деінде — часто на основі інтуїції, а не даних.
Від звітності до експериментів: чому потрібен «пісочний майданчик» для всіх
Наступний етап еволюції — перетворити eval‑систему з репозиторію результатів на справжню експериментальну платформу. Ключова зміна тут — дати можливість як технічним, так і нетехнічним користувачам безпосередньо експериментувати з агентом у контрольованому середовищі.
У практиці Braintrust це виглядає як «playground‑стиль» інтерфейсу. Користувач отримує доступ до конкретної конфігурації агента й може в UI змінювати певні параметри — наприклад, системні інструкції (system prompt). Поруч — можливість запустити eval на двох різних конфігураціях і побачити, як змінюються оцінки.
Такий підхід змінює динаміку роботи:
По‑перше, доменні експерти й PM отримують реальний важіль впливу. Вони можуть формулювати або коригувати системні інструкції, одразу бачити, як це позначається на відповідях агента на типові для їхньої сфери запити, і не чекати, поки інженер внесе зміни в код. Це скорочує цикл «гіпотеза — зміна — перевірка» з днів до годин або навіть хвилин.
По‑друге, експерименти стають відтворюваними. Кожна конфігурація агента, кожен набір вхідних прикладів, кожен запуск eval фіксуються й версіонуються. Це дозволяє не лише сказати «цей промпт працює краще», а й показати, на яких саме сценаріях, за якими метриками й у порівнянні з чим.
По‑третє, з’являється простір для поєднання людського й автоматизованого скорингу. Люди можуть зосередитися на складних, неоднозначних кейсах, де потрібне глибоке доменне розуміння, тоді як рутинні перевірки делегуються автоматизованим метрикам. Це знімає навантаження з експертів і робить процес масштабованим.
Нарешті, платформа стає місцем, де формується й закріплюється спільне визначення якості. Коли різні ролі бачать одні й ті самі результати, працюють з одними й тими самими наборами даних і метриками, дискусія переходить із площини «мені здається» в площину «дані показують». Це критично для того, щоб агенти не лише проходили демо, а й витримували реальний продакшен із живими користувачами, регуляторними вимогами й бізнес‑ризиками.
Як еволюція eval‑воркфлоу допомагає дійти до продакшену
Усе це повертає до вихідної проблеми, яку Гецел спостерігав ще в консалтингу: компанії вміють будувати вражаючі прототипи, але не вміють системно доводити їх до продакшену. Генеративні моделі й агенти привабливі саме своєю варіативністю — здатністю розв’язувати широкий спектр завдань, міркувати в складних контекстах, адаптуватися до користувача. Але ця ж варіативність робить їх непередбачуваними.
Без зрілої eval‑інфраструктури кожен реліз агента — це стрибок віри. Команда сподівається, що зміни в промпті чи моделі покращать досвід користувача, але не має системних доказів. Ризики — від репутаційних до комплаєнс‑ризиків і витрат на підтримку — залишаються високими.
Еволюція від for‑loop і таблиці до колаборативної платформи з експериментальним «пісочним майданчиком» змінює цю картину. Вона дозволяє:
– будувати спільні, формалізовані визначення якості між різними командами,
– робити експерименти відтворюваними й порівнюваними в часі,
– масштабувати людський скоринг за рахунок автоматизації,
– залучати доменних експертів і PM до безпосередньої роботи з агентами,
– зменшувати розрив між тим, як агент поводиться в лабораторії, і тим, як він працює з реальними користувачами.
Для Braintrust eval — це те, що відбувається з агентом до продакшену, а observability — те, що відбувається після, коли агент уже взаємодіє з живим трафіком. Але навіть не заходячи в тему продакшен‑спостережуваності, стає зрозуміло: без зрілої eval‑платформи шлях до продакшену буде довгим, дорогим і сповненим сюрпризів.
Висновок: якість агентів починається з інфраструктури для розмови про якість
Генеративний AI змушує компанії переосмислювати не лише те, які продукти вони будують, а й те, як вони вимірюють і обговорюють якість. Спочатку здається, що достатньо скрипта й таблиці. Потім — що проблему вирішить внутрішній UI та база даних. Але справжній прорив відбувається тоді, коли eval‑платформа стає спільною мовою між інженерами, продуктом і доменними експертами, а експерименти — щоденною практикою для всіх цих ролей.
У цьому сенсі еволюція eval‑воркфлоу — не просто технічна історія. Це історія про те, як організації вчаться колективно визначати, що для них означає «добрий» агент, і будувати інфраструктуру, яка робить це визначення живим, перевірюваним і таким, що постійно вдосконалюється. Без цього навіть найвражаючіші демо залишаться демо.
Джерело
YouTube: Why building eval platforms is hard — Phil Hetzel, Braintrust