У міру того як AI‑агенти виходять із лабораторій у реальні продукти, питання «що з ними відбувається в продакшені» стає критичним. Старі підходи з тестовими наборами й офлайн‑eval‑ами більше не рятують, коли багатокрокові агенти годинами викликають інструменти, спілкуються з користувачами й приймають рішення в невизначених середовищах.
Саме на цю проблему працює Raindrop — платформа, яку розвивають співзасновник і CEO Зубен та інженер Денні Голлапаллі. Вона допомагає AI‑інженерам знаходити, відстежувати й виправляти проблеми в продакшн‑агентах, насамперед багатотурових, але її підхід до сигналів так само працює й для одноходових сценаріїв. Ключова ідея Raindrop — побудувати навколо агентів щільний шар сигналів: від «жорстких» метрик на кшталт помилок інструментів до «м’яких» класифікаторів на кшталт фрустрації користувача чи відмов моделі.
Від «агент зламався» до «ось конкретний сигнал»
У класичному софті збій часто виглядає як виняток, падіння сервісу або очевидна логічна помилка. З агентами все інакше: вони недетерміновані, працюють з майже нескінченним простором вхідних і вихідних даних, викликають інструменти, іноді — інші агенти, і можуть годинами взаємодіяти з користувачем без прямого контролю розробника.
У такому середовищі «збій» рідко проявляється як один яскравий краш. Частіше це повільне накопичення симптомів: зростає кількість регенерацій відповідей, користувачі починають грубіше формулювати запити, агент частіше відмовляється відповідати або не доводить задачі до кінця.
Raindrop пропонує дивитися на це як на систему сигналів. У їхній моделі є два великі класи:
- Явні (explicit) сигнали — те, що можна об’єктивно виміряти й перевірити.
- Неявні (implicit) сигнали — семантичні, пов’язані зі змістом діалогу та поведінкою користувача й агента.
Явні сигнали — це фундамент. Платформа дозволяє відстежувати помилки інструментів, загальний error rate, затримки, кількість регенерацій відповідей і вартість. Якщо раптом різко зростає частка невдалих викликів API або латентність, це прямий індикатор технічної проблеми. Якщо стрибає кількість регенерацій, це вже натяк на якість відповідей.
Але справжня складність починається там, де об’єктивні метрики ще не дають повної картини. Саме тут Raindrop розгортає свою систему неявних сигналів — від regex‑патернів до власних класифікаторів.
Класифікатори замість «LLM як суддя» на кожен вихід
Один із ключових елементів Raindrop — набір готових класифікаційних сигналів, які платформа надає «з коробки». Вони не оцінюють «якість відповіді за шкалою від 1 до 10», а фокусуються на конкретних типах проблем і подій.
Серед таких сигналів:
- відмови (refusals), коли асистент каже «я не можу це зробити» або ухиляється від відповіді;
- провал завдання (task failure), коли агент не доводить задачу до завершення;
- фрустрація користувача (user frustration);
- сигнали модерації контенту, включно з NSFW;
- спроби джейлбрейку (jailbreaking);
- позитивні «перемоги» (wins), коли взаємодія проходить особливо вдало.
Ці класифікатори працюють як бінарні детектори: подія відбулася чи ні. Такий підхід принципово відрізняється від популярної ідеї «LLM як суддя», коли для кожної відповіді запускають велику модель, щоб вона оцінила іншу модель.
Raindrop свідомо уникає цього шляху в продакшені. Запускати повноцінну LLM на кожен вихід агента означало б практично подвоїти витрати на inference, що для великих обсягів трафіку просто неокупно. Натомість команда тренує власні легковагові моделі, які:
- спеціально заточені під конкретні сигнали — фрустрація, відмова, провал завдання;
- працюють на різних мовах, не обмежуючись англійською;
- достатньо дешеві, щоб їх можна було запускати на кожному запиті й відповіді в масштабі мільйонів подій.
Це дозволяє Raindrop робити те, що для багатьох команд виглядає недосяжним: мати постійний, детальний шар семантичного моніторингу поверх усіх агентських сесій, не роздуваючи бюджет на inference до абсурдних величин.
Regex як грубий, але надзвичайно корисний інструмент
Другий важливий тип неявних сигналів у Raindrop — regex‑патерни. На перший погляд це звучить майже архаїчно: регулярні вирази проти багатомовних LLM‑агентів. Але в реальному продакшені regex виявляється напрочуд ефективним.
Raindrop дозволяє визначати regex‑сигнали, які шукають у транскриптах або логах характерні фрази, що вказують на фрустрацію, помилки або інші проблеми. Це можуть бути грубі вислови, саркастичні ремарки на кшталт «це жахливо», «що за маячня», «ти помиляєшся» — усе те, що користувачі пишуть, коли щось іде не так.
Окремий приклад, який обговорювали під час воркшопу, — витік коду одного з великих AI‑продуктів, де виявився файл з довжелезним regex‑рядком, що шукав маркери негативних емоцій у промптах користувачів. Коли знаходився збіг, внутрішній прапорець «is_negative» виставлявся в true, а далі команда могла відстежувати динаміку фрустрації день за днем і після кожного релізу.
Raindrop фактично стандартизує цей підхід. Regex‑сигнали:
- надзвичайно дешеві в обчисленні;
- легко розширювані — додати нову фразу чи патерн можна за хвилини;
- добре працюють в агрегаті, навіть якщо окремі кейси промахуються.
Так, регулярні вирази не покриють усі мови й усі способи висловити невдоволення. Але якщо у вас мільйони взаємодій, і частка збігів по набору фраз «це жахливо», «ти мариш», «повна нісенітниця» раптом зростає на 10%, це вже потужний сигнал, що щось зламалося — можливо, в конкретному інструменті чи новій версії промпта.
У поєднанні з класифікаторами regex‑сигнали створюють багатошаровий радар: легкі, грубі патерни ловлять очевидні спалахи, а легковагові моделі добирають усе, що не вкладається в прості шаблони.
Повні трейси агентів і бекфілл нових сигналів
Щоб сигнали були корисними, їх потрібно прив’язати до реальних подій у роботі агента. Raindrop для цього вміє інжестити повні трейси агентів: діалоги, проміжні думки, виклики інструментів, відповіді API.
Інтеграції з інструментами на кшталт LangChain‑подібних стеків дозволяють передавати в Raindrop не лише «запит–відповідь», а й повну послідовність кроків, які агент виконував. Це критично, коли потрібно зрозуміти, чому саме класифікатор позначив подію як провал завдання або чому regex‑сигнал фрустрації раптом стрибнув для певного типу сесій.
Окремо вартий уваги механізм бекфіллу. Коли команда створює новий сигнал — наприклад, вирішує відстежувати специфічний тип провалу або новий патерн фрустрації — Raindrop не починає рахувати його «з нуля». Платформа проганяє цей сигнал по недавній історичній вибірці даних і відразу показує, де й коли в минулому він уже спрацьовував.
Це дає кілька важливих переваг:
- можна миттєво побачити, чи є новий сигнал рідкісним винятком чи системною проблемою;
- легше співвіднести появу патерна з конкретними релізами, змінами в промптах або додаванням інструментів;
- не потрібно чекати тижні, щоб накопичити достатньо нових подій для аналізу.
Фактично бекфілл перетворює будь‑який новий сигнал на «ретроспективну лінзу», через яку можна подивитися на вже зібрані трейси й побачити, що команда раніше просто не вміла назвати й виміряти.
Як явні й неявні сигнали працюють разом
Справжня сила підходу Raindrop проявляється тоді, коли всі типи сигналів — явні, regex‑базовані й класифікаторні — працюють у зв’язці.
Уявімо, що команда запускає нову версію промпта або додає інструмент до агента. У Raindrop це можна позначити через метадані: наприклад, додати прапорець «experiment_id» або змінити назву інструменту. Після цього платформа бачить, які сесії належать до якої версії, і може порівнювати сигнали між ними.
Якщо після релізу:
- зростає частка помилок інструментів;
- збільшується середня латентність;
- частішають регенерації відповідей;
- паралельно стрибає частка класифікованої фрустрації або відмов,
це вже не абстрактне «щось пішло не так», а конкретна картина: новий інструмент часто падає, користувачі зляться, агент частіше відмовляється виконувати запити, а сесії стають дорожчими.
Навпаки, якщо після зміни промпта Raindrop показує, що фрустрація впала, скажімо, з 37% до 9%, а скарги на естетику або деплоймент зменшилися, це сильний аргумент на користь нового варіанту. При цьому платформа може паралельно показати, що, наприклад, середня кількість використаних інструментів зросла. Це не обов’язково проблема, але важливий контекст: агент став активніше користуватися інструментами, можливо, це впливає на вартість або латентність.
Raindrop дозволяє дивитися на всі ці сигнали в динаміці — день за днем, реліз за релізом. Якщо певний показник різко стрибає, команда може налаштувати алерти й оперативно реагувати. Але фундаментом для будь‑яких алертів і експериментів залишається саме шар сигналів: без нього ні моніторинг, ні порівняння варіантів агента неможливі.
Масштаб і економіка: чому «дешеві» сигнали вирішують
Ключова інженерна проблема в моніторингу агентів — масштаб. Як тільки кількість подій переходить за кілька сотень, людина фізично не може прочитати всі діалоги й вручну оцінити, що відбувається. Саме з цього моменту, як зазначають у Raindrop, сигнали починають приносити реальну користь, навіть якщо статистична значущість ще далека від академічних стандартів.
Але щоб працювати на рівні сотень тисяч або мільйонів подій, будь‑який сигнал має бути дешевим. Саме тому Raindrop:
- не запускає повноцінні LLM як суддів на кожен вихід;
- покладається на легковагові, спеціально навчені моделі для класифікації фрустрації, відмов і провалів завдань;
- активно використовує regex‑патерни там, де вони дають достатньо інформації;
- будує систему так, щоб кожен новий сигнал можна було масштабувати без вибуху витрат.
У результаті платформа може дозволити собі те, що для багатьох команд виглядає надмірністю: маркувати практично кожну взаємодію набором бінарних ознак — була фрустрація чи ні, була відмова чи ні, був провал завдання чи ні, чи спрацював regex‑патерн, якою була латентність, чи була помилка інструменту.
Ця «щільність» даних і робить можливими подальші кроки — від алертингу до експериментів і глибокого дебагу. Але саме шар сигналів, їхня економіка й технічна реалізація — те, що відрізняє Raindrop від спроб будувати моніторинг агентів «на коліні» через поодинокі eval‑и або ручний перегляд логів.
Висновок: сигнали як нова мова для розмови про агентів
У міру того як агенти проникають у сфери з високими ставками — від фінансів до медицини, — питання «чи працює наш агент добре» перестає бути суб’єктивним враженням команди. Потрібна мова, якою можна формально описати й виміряти поведінку системи.
Raindrop пропонує таку мову у вигляді системи сигналів. Явні метрики на кшталт помилок інструментів, латентності, регенерацій і вартості дають технічний фундамент. Regex‑сигнали додають грубий, але дуже дешевий шар семантичного моніторингу. Легковагові класифікатори фрустрації, відмов, провалів завдань і модерації закривають багатомовний, контекстний вимір.
Разом із можливістю інжестити повні трейси агентів і бекфілити нові сигнали по історичних даних це перетворюється на повноцінний інструмент спостереження за агентами в реальному світі. Не як за «чорною скринькою», а як за системою, де кожен збій, кожна зміна й кожен реліз залишають вимірюваний слід у просторі сигналів.
У світі, де агенти стають дедалі складнішими й автономнішими, саме така інфраструктура може виявитися тим, що відділяє керований розвиток від хаотичного експерименту.
Джерело
Everything You Need To Know About Agent Observability — Danny Gollapalli and Ben Hylak, Raindrop