Phil Hetzel, керівник напрямку solutions engineering у Braintrust і колишній лідер глобального підрозділу Databricks у Slalom Consulting, останні роки працює на стику enterprise‑аналітики та генеративного AI. Braintrust позиціонує себе як платформу якості агентів, що зосереджена на двох стовпах — evals та observability. У центрі їхнього підходу — доволі радикальна теза: вимірювання якості агентів до й після продакшену — це не про красивий інтерфейс, а про важку інженерію даних для гігантських, напівструктурованих трейсів.
Цей погляд змушує по‑новому подивитися на те, як мають виглядати платформи для роботи з AI‑агентами, і чому багато «простих» рішень на кшталт Postgres‑таблиці чи кастомного DSL швидко впираються в стелю.
Evals до релізу, observability після: одна й та сама задача під капотом
Braintrust формулює свою місію максимально вузько: це не загальна MLOps‑платформа і не ще один «playground» для LLM, а саме платформа якості агентів. У цій рамці evals і observability — два боки однієї медалі.
Evals у їхній термінології — це все, що відбувається з агентом до продакшену. Команда експериментує з промптами, ланцюжками викликів, інструментами, моделями, збирає приклади вхідних даних, запускає серії прогонів і вимірює якість. Мета — досягти рівня впевненості, за якого агент можна безпечно показати реальним користувачам.
Observability — це продовження тієї ж роботи, але вже після релізу. Агент живе у продакшені, обробляє реальний трафік, і завдання команди — зберегти й перевіряти ту саму впевненість: чи поводиться система так, як очікували під час розробки, чи не деградує якість, чи не з’являються нові класи помилок.
Ключовий момент у тому, що Braintrust не розділяє ці два світи на рівні інфраструктури. З їхнього погляду, і evals, і observability — це одна й та сама системна задача: збір, зберігання, індексація й аналіз великих трейсів агентів.
Саме так з’явилася їхня нинішня архітектура. Три роки тому Braintrust стартував як платформа лише для evals. Observability з’явилося пізніше — не як окремий продукт, а як еволюція. Один із клієнтів просто почав прокачувати весь продакшен‑трафік через систему evals і безперервно ганяти оцінки поверх реальних запитів. Це фактично перетворило eval‑платформу на систему спостереження за агентом у бойових умовах.
Звідси й стратегічний висновок: якщо клієнти все одно намагаються звести evals і observability в один контур, платформа має бути спроєктована як єдина дата‑система, а не як два різні продукти, зшиті API.
Внутрішній flywheel: як продакшен‑трафік підживлює офлайн‑evals
У Braintrust для цього є власний термін — «flywheel». Йдеться про замкнений цикл, у якому дані з продакшен‑observability безперервно підживлюють офлайн‑evals, а результати evals, у свою чергу, впливають на поведінку агента в продакшені.
У спрощеному вигляді цей цикл виглядає так. Агент працює з реальними користувачами, кожна взаємодія породжує трейс: промпти, відповіді, виклики інструментів, проміжні стани. Ці трейси потрапляють у спільне сховище. Далі команда може:
- вибирати з продакшен‑трафіку репрезентативні приклади для нових наборів тестів;
- запускати офлайн‑evals на історичних даних, порівнюючи різні конфігурації агента;
- виявляти патерни помилок і формувати таргетовані сценарії для регресійного тестування.
У результаті observability перестає бути лише «панеллю моніторингу», а evals — лише «тест‑раннером». Обидва стають частинами одного конвеєра, який постійно перетравлює напівструктуровані трейси й повертає команді сигнали про якість.
Щоб цей flywheel працював, потрібна не стільки вишукана UI‑оболонка, скільки потужний бекенд, здатний витримувати обсяги та характер даних, притаманних агентам.
Чому трейси агентів ламають звичні інструменти спостереження
У класичному світі observability — це метрики, логи, трейси. Багато команд звикли до APM‑інструментів, де трейс — це набір відносно невеликих спанів: HTTP‑запити, виклики БД, внутрішні сервіси. Дані структуровані, обсяги кожного спану — кілобайти, у гіршому разі сотні кілобайт.
З агентами картина інша. Hetzel описує кілька ключових відмінностей:
По‑перше, трейси напівструктуровані або взагалі неструктуровані. Усередині — довгі текстові промпти, відповіді моделей, JSON‑фрагменти, результати викликів інструментів, іноді вкладені один в один. Структура може змінюватися від релізу до релізу, від агента до агента.
По‑друге, вони текстоцентричні. На відміну від класичних трейсів, де головне — часові мітки, статус‑коди й лейбли, тут основна цінність — у самих текстах. Командам потрібно шукати по вмісту промптів, аналізувати відповіді, будувати евристики поверх природної мови.
По‑третє, вони великі. Hetzel говорить про спани розміром 10–20 мегабайт — і це не виняток. Якщо агент працює з довгими документами, складними ланцюжками інструментів або багатокроковими діалогами, один трейс легко роздувається до сотень мегабайт. У крайніх випадках окремі трейси можуть сягати гігабайта.
По‑четверте, це високошвидкісний потік. У продакшені агент може обробляти тисячі запитів на хвилину, кожен із яких породжує такий важкий трейс. Система має не лише прийняти ці дані, а й зробити їх придатними для запитів у реальному часі та аналітики.
У такій реальності спокуса «просто скласти все в Postgres» швидко обертається проблемами. Hetzel прямо попереджає: якщо зберігати гігантські трейси, скажімо, обсягом у гігабайт, безпосередньо в рядках Postgres, продуктивність неминуче просідає. База, розрахована на типові OLTP‑навантаження, погано поводиться, коли окремі записи перетворюються на монолітні блоби тексту.
Це підштовхує платформи до спеціалізованих стратегій зберігання та індексації: розділення «гарячих» і «холодних» даних, окремі сховища для великих payload‑ів, індекси для повнотекстового пошуку, шардинґ, компресія. І все це має працювати прозоро для користувача, який очікує, що зможе за секунди знайти потрібний трейс або побудувати агрегацію по мільйонах взаємодій.
Від BTQL до «нормального SQL»: еволюція дата‑шару Braintrust
Історія самої платформи Braintrust добре ілюструє, наскільки непросто знайти правильну архітектуру для таких даних. На ранньому етапі команда пішла шляхом, який виглядав логічно: поєднати швидке сховище для оперативних запитів з аналітичним дата‑вейрхаусом.
Під капотом це виглядало так. Для низької затримки використовувалося окреме low‑latency‑сховище, поверх якого можна було швидко діставати окремі трейси чи останні взаємодії. Паралельно всі дані прокачувалися в open‑source‑сховище даних, оптимізоване під аналітичні запити й агрегації.
Щоб зшити ці два світи, Braintrust створив власну мову запитів — BTQL. Вона мала абстрагувати користувача від деталей того, де саме лежать дані, і дозволяти писати єдині запити, які під капотом розподіляються між low‑latency‑шаром і дата‑вейрхаусом. Для додаткових агрегацій прямо в браузері використовувався DuckDB, який забирав на себе частину обчислень на стороні клієнта.
На папері це виглядало елегантно. На практиці — ні користувачам, ні самій команді Braintrust BTQL не сподобалася. Власний DSL означає, що кожному інженеру, який приходить у продукт, доводиться вчити ще одну мову запитів. Інструменти BI, аналітики, інтеграції — усе це «з коробки» розуміє SQL, але не розуміє BTQL. Навіть для внутрішньої розробки це створює тертя: будь‑який аналіз даних вимагає контекст‑перемикання між звичним SQL і кастомним синтаксисом.
Цей досвід став для Braintrust аргументом на користь іншого підходу: замість того, щоб будувати складні абстракції поверх двох різних сховищ і власної мови, краще інвестувати в дата‑шар, який із самого початку добре підтримує «серйозний» SQL і різноманітні патерни читання.
Нова архітектура, до якої рухається команда, має відповідати кільком вимогам одночасно.
По‑перше, підтримка суттєвої підмножини SQL. Це відкриває двері до стандартних інструментів аналітики, дозволяє інженерам використовувати знайомі підходи до побудови запитів, спрощує інтеграції.
По‑друге, різні режими читання. Потрібні як низьколатентні lookup‑и для конкретних трейсів чи користувацьких сесій, так і важкі аналітичні запити по великих масивах даних: агрегації, фільтрації, порівняння експериментів.
По‑третє, повнотекстовий пошук по великих трейсах. Для клієнтів на кшталт Notion критично важливо мати змогу шукати по вмісту промптів і відповідей: знаходити всі випадки певного типу помилки, відстежувати, як агент поводиться з конкретними формулюваннями запитів, виявляти небажані патерни.
По‑четверте, підтримка headless‑сценаріїв. Частина клієнтів взаємодіє з Braintrust переважно через код — агенти, що самі викликають evals, CI/CD‑пайплайни, автоматизовані регресійні тести. Для них UI — другорядний, а іноді й взагалі необов’язковий. Платформа має поводитися як «головний мозок» для evals та observability, доступний через API й SDK, а не як суто візуальний інструмент.
Усі ці вимоги знову повертають до вихідної тези: головна складність побудови платформи якості агентів — у дата‑системі, а не в інтерфейсі.
Чому це не про UI: бекенд для напівструктурованих трейсів
Hetzel прямо формулює це: вимірювання якості агентів через evals і observability — це насамперед задача системи даних, а не UI. Інтерфейс важливий для залучення різних ролей — від інженерів до доменних експертів, — але він не вирішує головної проблеми: як ефективно працювати з величезними, текстоцентричними, напівструктурованими трейсами у високошвидкісному потоці.
Щоб така система була життєздатною, бекенд має одночасно:
- приймати й зберігати великі об’єми даних без деградації продуктивності;
- дозволяти гнучко індексувати й шукати по тексту;
- підтримувати як точкові запити, так і масові аналітичні обчислення;
- бути достатньо відкритим, щоб клієнти могли будувати власні пайплайни поверх нього.
У цьому сенсі досвід Braintrust показує, що спокуса «швидко зробити UI поверх Postgres» або «написати свій DSL, який усе сховає» працює лише на ранніх стадіях. Щойно агенти виходять у продакшен і починають генерувати реальні трейси, платформа неминуче перетворюється на повноцінну дата‑систему з усіма притаманними їй викликами: вибір сховищ, компроміс між latency і вартістю, індексація, шардінг, оптимізація запитів.
І саме в цій точці стає очевидно, чому Braintrust об’єднує evals і observability в один продукт. Розділяти їх означало б дублювати всю цю складну інфраструктуру двічі — для «дотестових» і «післярелізних» даних. Натомість єдиний дата‑шар дозволяє будувати безперервний цикл покращення якості, де кожен новий трейс — це водночас сигнал для моніторингу й потенційний приклад для наступних експериментів.
Висновок: якість агентів як інженерія даних
Коли говорять про якість AI‑агентів, дискусія часто зводиться до метрик, промпт‑інжинірингу чи UX‑патернів. Досвід Braintrust додає до цієї картини ще один, менш помітний, але критичний шар: інженерію даних для трейсів.
Якщо сприймати evals як «те, що робимо до продакшену», а observability як «те, що робимо після», легко опинитися з двома розрізненими системами, які дублюють одна одну й не діляться даними. Якщо ж подивитися на них як на єдину задачу — збір, зберігання й аналіз напівструктурованих, текстових, великих і швидких трейсів — стає зрозуміло, чому платформи на кшталт Braintrust інвестують саме в дата‑шар, а не в ще один playground.
У міру того як агенти стають «обличчям» компаній у взаємодії з користувачами, питання їхньої якості перестає бути суто дослідницьким. Це вже не тільки про те, як написати кращий промпт, а про те, як побудувати інфраструктуру, здатну перетворювати хаотичний потік трейсів на систематичні сигнали для прийняття рішень. І в цій грі перемагають не ті, хто має найяскравіший UI, а ті, хто найкраще розв’язує базову задачу дата‑систем.
Джерело
Why building eval platforms is hard — Phil Hetzel, Braintrust