Самые сложные баги в продакшене — не технические, а организационные. Я создал агента, который наконец-то наблюдает за обеими сторонами.
Существует категория багов в AI-системах, которые я нахожу по-настоящему захватывающими, потому что сложность почти никак не связана с самим багом. Баг часто прост. То, что делает его практически неотлаживаемым, — это то, как мы организовали наши инструменты. Я хочу подробно разобрать это, потому что, когда становится ясна форма проблемы, решение становится почти неизбежным, и это решение превратилось в проект, который я покажу вам в конце.
Два мира, которые никогда не встречаются
Когда вы выводите модель в продакшен, вы быстро обнаруживаете, что наблюдаете за двумя разными вещами.
Первая — это инфраструктура. Мир памяти, CPU, подов, сети, задержек — механизмов, на которых работает модель. У нас есть отличные инструменты для этого; Dynatrace — тот, что использовал я.
Вторая — это собственное поведение модели. Галлюцинирует ли она? Релевантны ли её ответы? Как меняется показатель eval, сколько токенов она потребляет? Это совершенно другой вид наблюдаемости, и для него у нас тоже есть хорошие инструменты; я использовал Arize Phoenix.
Вот важный момент, и он настолько обычен, что его легко упустить: эти два мира отслеживаются двумя разными продуктами, и эти продукты ничего не знают друг о друге. Хуже того, за ними обычно следят две разные команды. У инфраструктуры своя смена дежурства; у модели — своя. Каждая группа свободно владеет своей панелью управления и практически слепа к другой.
Отказ, живущий в стыке
Теперь рассмотрим конкретный инцидент. На одном из ваших подов начинается утечка памяти. Под давлением нехватки памяти система делает нечто разумное в изоляции: она урезает буфер, который собирает промпты перед отправкой модели, чтобы освободить место. Следствие — модель начинает получать промпты с частью их контекста, молча удалённой. А модель, работающая с половиной контекста, делает единственное, что может, — заполняет недостающие части догадками. Уровень галлюцинаций растёт.
Получайте истории от nidhithiside на почту
Присоединяйтесь к Medium бесплатно, чтобы получать обновления от этого автора.
Запомнить меня для быстрого входа
Посмотрим, что видит каждый наблюдатель. Инженер инфраструктуры видит всплеск использования памяти. Это знакомый, почти скучный сигнал — перезапусти под, освободи память, двигайся дальше. ML-инженер видит, что качество ответов модели резко падает, и начинает долгое расследование, изучая промпты, поиск, веса. Каждый из них смотрит ровно на одно звено единственной причинной цепочки, и ничто в их инструментах не даёт им повода заподозрить, что другое звено существует, не говоря уже о том, что оно принадлежит той же истории.
Это мысль, к которой я постоянно возвращался: баг не технический, а организационный. Каждая часть информации, необходимая для его решения, уже собирается. Отказ заключается исключительно в том, что две половины цепочки никогда не попадают в одно место, в один ум, в одно время.
Вынужденное решение
Как только вы формулируете это таким образом, исправление почти не оставляет выбора. Если проблема в том, что ни один наблюдатель не видит оба слоя, вы создаёте наблюдателя, который это делает. Вы помещаете одного агента перед обеими панелями управления.
Это ARIA. Она подключается и к Dynatrace, и к Arize Phoenix через их MCP-серверы, извлекает соответствующие сигналы из каждого и передаёт объединённую картину Gemini, оркестрированную с помощью Google Agent Development Kit как конвейер планировщик → рассуждатель → исполнитель, чтобы рассуждать об этом как об одной проблеме, а не о двух.
Нажмите Enter или кликните, чтобы просмотреть изображение в полном размере
Единственное решение, которое действительно имело значение
Я поделюсь ошибкой, потому что это самая полезная часть. Моей первой конструкцией были два агента: один, понимающий Dynatrace, другой — Arize, общающиеся друг с другом. Это казалось естественным — отразить организационную структуру в программном обеспечении. Это не работает. Всё, что она делает, — это точно воспроизводит слепое пятно двух команд внутри вашего кода. Каждый агент по-прежнему является экспертом в одной половине и чужим для другой.
Корреляция возникает только тогда, когда один агент удерживает оба набора инструментов в одном контексте рассуждения. Когда один ум может вызвать инструмент Dynatrace и инструмент Arize за один раз и держать оба результата в поле зрения, он наконец может увидеть цепочку от начала до конца. В этом вся суть продукта, сжатая в одну фразу: один ум, обе половины.
Попробуйте
- Живая версия: aria-three-lac.vercel.app
- Код: github.com/Nidhicodes/aria