Кластеризация трейсов выявляет частые проблемы недетерминированных агентов для создания патчей

Кластеризация трейсов выявляет частые проблемы недетерминированных агентов для создания патчей

Связка 1

Начальное состояние: Недетерминированные агенты в продакшне генерируют многообразие сеансов отладки, в которых трудно выявить повторяющиеся проблемы при просмотре отдельных логов
Преобразование: Кластеризация всех трейсов с добавлением семантического слоя для группировки похожих паттернов поведения агентов
Конечное состояние: Частые проблемы, такие как деградация длинного хвоста из-за преждевременной готовности агента до полной настройки среды выполнения, стали видимыми и позволили немедленно создать патч-исправление

Технология, которую мы создали внутри компании, называется Telescope. Это довольно простой цикл, надеюсь, после моих объяснений. Во-первых, мы начинаем с выявления проблем. Это основано на кластеризации трейсов, о которой я говорил ранее. Затем на основе этого мы создаем изменения в коде. То есть это полностью автоматизировано. Мы по сути создаем PR с помощью кодинг-агента на основе информации, полученной из трейса, из логов, из всех различных дашбордов, которые у нас есть. Затем мы оцениваем, является ли сгенерированное изменение ломающим. То есть мы перезапускаем Bytebench. Bytebench — это своего рода лакмусовая бумажка. Если оценка падает на 10 баллов, мы решаем, что это изменение плохое. Если это спорное изменение, которое, как мы считаем, может негативно повлиять на нашего агента, мы проводим A/B-тест.

То есть мы показываем его пользователям и пытаемся выяснить, каковы компромиссы. Если это явный короткий выстрел, то мы просто отправляем его в продакшн. И несколько раз, когда мы считаем, что гипотеза была верна, а PR, возможно, был не идеален, мы продолжаем итерации по проблеме. Возможно, мы проводим еще один A/B-тест, пока не получим хорошую конфигурацию, и затем отправляем ее в продакшн. Если подумать, это очень похоже на работу, которую вы как AI-инженер делаете постоянно, но 90% ее теперь выполняется агентом в цикле, а вам не нужно беспокоиться о каждом шаге процесса.

Позвольте мне привести пример того, с чем мы однажды столкнулись в продакшне. RapidAgent сразу же запускает среду выполнения при первом отправке запроса. И, конечно, для настройки всего, особенно с учетом уровня сложности, который мы создали, требуется несколько секунд. У нас была деградация в длинном хвосте, когда время настройки было больше ожидаемого. И наш агент был готов к работе до того, как среда была полностью настроена. Как вы знаете, агенты стали очень нетерпеливыми в исправлении проблем. Поэтому RapidAgent пошел по касательной и начал пытаться исправить среду на месте.

Оказалось, что из-за недетерминированности агентов каждый сеанс отладки выглядел немного по-разному. Поэтому если бы мы попытались найти эту проблему длинного хвоста, просто просматривая логи, она бы почти не проявилась. Но как только мы кластеризовали все трейсы — по сути, добавили семантический слой — мы начали понимать, что эта проблема возникает довольно часто. И мы смогли сразу же создать патч и исправить проблему.

В этом случае нам не пришлось проводить A/B-тест, потому что это был чистый случай регрессии.

Но если бы это была проблема, требующая тестирования, мы, конечно, добавили бы дополнительный шаг между ними. И хотя я большой сторонник максимальной оптимизации жизни AI-инженера с помощью агентов, я считаю, что в том цикле, который я вам представил, людям всё ещё предстоит выполнять много интеллектуальной работы.

Например, каждый раз, когда мы находим один из таких кластеров, о которых я говорил ранее, мы как команда всегда сосредотачиваемся на формулировании гипотезы о том, что могло пойти не так. Потому что правда в том, что при работе в продакшене вы получаете огромное количество кандидатов на исправление. Поэтому вам нужно расставлять приоритеты, куда вкладывать усилия и ресурсы.

Если гипотеза достаточно интригующая, мы двигаемся дальше и не позволяем агенту просто запустить PR без какого-либо контроля. Мы пытаемся глубже понять, что не так. Мы даём ему больше указаний. И в конечном счёте, если подумать, каждый раз, когда мы решаем работать над PR и проводить A/B-тест, мы как бы формируем ту метрику, которую пытаемся оптимизировать.

[...]

Спикер 1. Что ж, мне очень интересно посмотреть, что люди будут с этим делать. Я также хочу спросить вас о втором столпе, телескопе. Это довольно сложная система, которую вы построили. Звучит невероятно полезно. Похоже, вы много раз её настраивали.

Для людей в зале, которые, возможно, пытаются построить что-то подобное, какие уроки вы извлекли на этом пути? Какие советы вы могли бы дать им о том, как построить что-то полезное, подобное этому?

Спикер 0. Прежде всего, если вы пытались сделать это, скажем, шесть месяцев назад и разочаровались, потому что не получили отдачи от инвестиций, обязательно попробуйте снова. Та же точка перегиба, которую вы испытали с кодинг-агентами, скажем, в ноябре с Office 4.5 и аналогичными передовыми технологиями, также отражается на том, о чём я только что говорил. То есть тот факт, что длинный контекст и модели, действительно способные рассуждать над большим объёмом контента, означает, что вы можете практически вставить весь трейс вашего агента в OPUS и получить довольно сложную обратную связь о нём. Поэтому в то же время вам действительно стоит инвестировать в сбор всех возможных сигналов от вашего агента, а также в знание среды, в которой он выполняется. Я знаю, что мне пришлось быстро говорить во время доклада, но я мог бы подробно рассказать о всех различных сигналах, которые мы привносим в Telescope.

Это не только то, что поступает из трейса, это также обратная связь, которую мы собираем в продукте. Например, у нас есть форма обратной связи, каждый раз, когда агент ведёт себя неправильно и пользователь жалуется, у нас есть точка зрения пользователя, у нас есть трейс агента, у нас есть всё, что мы инструментируем на платформе в Datadog. Неудивительно, что всё это вместе, помещённое в контекст, помогает ещё точнее определить, в чём проблема.

Спикер 1. Да. Я думаю, что идея построения кластеров, как вы говорили, что один трейс очень трудно отладить, чтобы понять, что может идти не так. Но когда вы можете сгруппировать их все вместе и получить эти дополнительные сигналы, это действительно раскрывает гораздо больше информации и даёт что-то, с чем можно работать. Это имеет огромный смысл.

Спикер 0. Да. Не так ли? Думаю, это также делает Live Home Agent Builder менее подавляющим, потому что, когда вы начинаете получать много использования, объём обратной связи, которую вы получаете, на самом деле подавляет. И это хороший сигнал. Это означает, что людям небезразлично то, что вы делаете.

Но в то же время трудно расставить приоритеты: что действительно важно, а что не влияет на результат. То, что я показал сегодня, также является для нас способом попытаться понять: хорошо, этот кластер появляется ежедневно, он довольно большой, и там много объёма, поэтому мы должны сначала исправить именно его. А длинный хвост проблем, которые нужно исправить, всегда будет с агентами, учитывая, что они недетерминированы.