/)
Когда вы просите Grafana Assistant создать дашборд или исследовать инцидент, вы делаете это потому, что нужно решить определенную задачу. Для эффективного выполнения этой работы вам нужны правильные данные, изменения, которые можно проверить, и выводы, подкрепленные доказательствами. Вы также хотите, чтобы Assistant избегал ошибок и действовал быстро.
За последние шесть месяцев наша команда проделала большую работу по улучшению того, что делает эти результаты возможными. Мы изменили то, как агенты находят контекст, обнаруживают возможности, редактируют дашборды и восстанавливаются после ошибок. В то же время мы создали лучшие способы определения того, действительно ли улучшение помогает.
Эти проекты тесно связаны между собой. Более качественная оценка показывает, где агент испытывает трудности. Эти выводы определяют изменения в его инструментах и контексте. Телеметрия из рабочей среды подсказывает нам, сработали ли эти изменения и куда двигаться дальше.
Мы документируем эту работу в нашем инженерном блоге, Unprompted, подробно разбирая решения и реализации, которые стояли за этими усилиями. Сегодня я хочу поделиться тем, как эти изменения привели к улучшению результатов для наших пользователей.
Работа с дашбордами: быстрее, красивее, меньше ошибок
К середине 2026 года режим создания дашбордов составлял 27% разговоров с Assistant. Пользователи также точно указывали нам, где его работу нужно улучшить: некоторые операции выполнялись медленно, потребляли слишком много токенов или изменяли то, чего трогать не следовало.
Команда начала с установления базовых показателей с помощью Agent Observability и создания воспроизводимых тестов. Примерно за 10 недель зарегистрированный уровень ошибок при создании дашбордов упал с 2,47% до 0,65%. 95-й перцентиль задержки для отдельных операций снизился с 63 секунд до 28,8 секунды, в то время как стоимость одного запроса сократилась на 18%.
Как описывает Доминик Брой в своей статье о дашбордах, эти результаты были достигнуты благодаря повторяющимся, конкретным улучшениям. Инженеры находили сбои в рабочей среде, воспроизводили их в виде тестовых сценариев, исправляли первопричины и проверяли результаты после развертывания. Каталог тестов дашбордов вырос с 78 сценариев почти до 200.
Узнайте больше: читайте статью Доминика «Наш путь к улучшению режима создания дашбордов в Grafana Assistant»
Другие создают циклы агентов, мы создаем циклы оценки для достижения наилучших результатов
Этот процесс важен не только для работы с дашбордами. Он дает нам возможность превратить отдельные отчеты в улучшения, которые можно повторно тестировать при каждом изменении системы.
ИИ-агент может выдать убедительный ответ, даже если его основная работа выполнена неверно. Панель может успешно отрендериться, показывая при этом неверную агрегацию. Расследование может выявить правдоподобную причину без достаточных доказательств. Оценка только финального ответа упускает многое из того, что определяет успех задачи.
В своем блоге о создании цикла оценки для Assistant Ясир Экинчи объясняет, как мы отделяем желаемое поведение от промптов и кода, которые его реализуют. Сценарии определяют реалистичные задачи и критерии успеха. Оценщики изучают запросы, вызовы инструментов, сохраненное состояние и выводы. Повторные прогонки выявляют несогласованное поведение, а сравнения отслеживают качество наряду со стоимостью и задержкой.
Это разделение дает нам простор для экспериментов. Мы можем изменить промпт, инструмент или модель, сверяясь с теми же ожиданиями. Агенты кодирования также помогают исследовать сбои и предлагают изменения, которые возвращаются в цикл оценки для верификации и проверки человеком.
Узнайте больше: читайте статью Ясира «Создание цикла оценки для Grafana Assistant»
gcx: обучение вашего локального агента проектированию интерфейса командной строки (CLI), созданного для агентов
Этот же принцип проявляется в рассказе Уорда Беккера о проектировании gcx. Наблюдение за тем, как агенты используют наш CLI, выявило повторяющиеся сбои: угадывание флагов, повторные попытки выполнения неуспешных команд и запросы гораздо большего объема вывода, чем им было нужно.
Исправления появились вместе с gcx, нашим CLI, разработанным специально для агентов, что сделал интерфейс более информативным. Команды описывают свои возможности. Ошибки объясняют, как восстановиться. Агенты могут просматривать доступные поля и фильтровать результаты, прежде чем переносить их в контекст. Знания, которые раньше требовали отдельного руководства, все больше живут в самом инструменте, где они могут оставаться синхронизированными с реализацией.
По своей сути gcx задает один практический вопрос: что интерфейс должен сообщить агенту, чтобы тот мог сделать следующий шаг правильно?
Снижение нагрузки на контекст
Этот вопрос становится все более важным по мере роста числа возможностей. В своей статье об опережающем обнаружении инструментов Сирил Товена описывает, как Assistant находит подробные инструкции к инструментам, когда они ему нужны. Вместо загрузки каждой схемы целиком он начинает с компактных точек входа и извлекает нужное руководство.
По всей площади зарегистрированных инструментов, измеренной в статье, первоначальные определения инструментов сократились примерно с 54 500 предполагаемых токенов до 504. Это сокращение накладных расходов в конкретном контексте на 99,1%; реальная экономия за сеанс зависит от доступных и используемых возможностей.
Более широкое преимущество заключается в том, что Assistant может получать новые возможности без того, чтобы каждый разговор нес в себе все инструкции к ним, а ваше использование становится дешевле: меньше токенов в системном промпте, меньше предварительных затрат. Мы по-прежнему измеряем рабочий процесс целиком: меньшие по размеру промпты полезны только в том случае, если обнаружение не приводит к избыточным шагам или задержкам.
Узнайте больше: читайте статью Уорда «CLIs in the age of agents: how we designed gcx,» и статью Сирила «Progressive tool discovery: battling tool overload in AI agents»
Поиск вещей не должен быть сложным
Ваши дашборды, алерты и история инцидентов содержат знания о том, как работают ваши системы. Сделать эти знания доступными — значит нечто большее, чем просто разместить документы в поисковом индексе.
История Иоанны Армути об улучшении поисковых возможностей Assistant описывает решения, лежащие в основе его поисковой системы. Для дашбордов встраивание исходного JSON панели привлекало внимание к деталям рендеринга. Представление панели через ее папку, дашборд, строку, описание и запросы сделало ее назначение более понятным. Сводки инцидентов требовали иного подхода, чем зашумленные ленты активности. При извлечении результатов необходимо было проверять права доступа, поскольку доступ может измениться после индексации.
Здесь прослеживается связь с обнаружением инструментов и редактированием дашбордов: все три функции облегчают доступ к релевантной информации, одновременно контролируя объем попадающего в контекст агента. Больший объем доступной информации помогает только тогда, когда агент может найти и использовать нужную ее часть.
Команда расследований увидела это напрямую при тестировании на реальных инцидентах.
Узнайте больше: читайте статью Иоанны «Search, but deeper: how Grafana Assistant finds the right context»
Более быстрые и точные первопричины с помощью расследований
Ранее в этом году мы поняли, что успешных тестов на синтетической телеметрии недостаточно. Реальные инциденты принесли неполные данные, противоречивые объяснения и отвлекающие сигналы.
В своей статье Уильям Дюмон описывает, как мы позаимствовали концепцию из мира спортивного программирования для сравнения различных вариантов агентов на решенных инцидентах и как это обнажило конкретные проблемы.
Один агент сделал слишком много выводов на основе названия оповещения; получение фактического определения оповещения дало ему лучшую отправную точку. Другой избегал полезного инструмента, потому что в его инструкциях был описан неверный язык запросов; фильтрация полученной справочной информации позволила сократить объем нерелевантного контекста.
Оценки во внутреннем наборе сложных инцидентов выросли с 52% до 69% за неделю итераций. Этот показатель измеряет эффективность работы с данными контрольными примерами. Долгосрочная ценность заключается в способности определить, почему одно расследование проходит успешно, а другое сталкивается с трудностями, а также в продолжении тестирования сложного поведения, связанного с признанием недостаточности доказательств. В конечном итоге эта работа, которая продолжается, приводит к более надежным рекомендациям, что укрепляет доверие и ведет к лучшим результатам.
Узнайте больше: прочитайте публикацию Уильяма в блоге «Enter the arena: evaluating and improving Grafana Assistant Investigations against real incidents»
Масштабируемая оценка не обязательно должна быть дорогой
По мере того как агенты начали выполнять более длинные последовательности задач, наш первоначальный производственный оценщик стал чаще пропускать сбои, поскольку слишком сильно фокусировался на тексте ответа. Ясир Экинджи и Свен Гроссманн описывают процесс переработки: показать оценщику больше результатов работы агента, позволить ему распознавать частичное выполнение и проверять его суждения с помощью более сильного рецензента.
Затем они протестировали Jev, модель, предназначенную для принятия структурированных решений. Она работала значительно быстрее и дешевле, но гораздо реже соглашалась с рецензентом, чем самый сильный генеративный судья. Мы сохранили более сильного судью для получения основного показателя качества и представили Jev в качестве дополнительного провайдера с шаблоном для сортировки трассировок. Его пригодность для этой другой задачи все еще требует репрезентативной проверки.
Это важная часть экспериментирования: понимание того, где уместен новый подход, включая случаи, когда данные говорят о необходимости сохранить то, что уже работает.
Эти проекты также объясняют взаимосвязь между Grafana Assistant и Agent Observability. Создание и эксплуатация Assistant ставит перед нами сложные практические вопросы о поведении агентов. Agent Observability помогает нам отвечать на них с помощью трассировок, оценок и сравнений, а также делает эти возможности доступными для клиентов, создающих собственных агентов.
Узнайте больше: прочитайте публикацию Свена и Ясира в блоге «Judge Jev: Can a typed-decision model grade your agent?»
Переосмысление того, как мы работаем, чтобы быстрее выпускать лучшие продукты
В своей публикации о том, как мы создаем ИИ в Grafana Labs, я описал наш подход как небольшие, значимые итерации, основанные на проблемах клиентов. Мы берем проблемы клиентов и пытаемся их решить. По пути что-то работает (это та публикация в блоге, которую вы можете прочитать!), а что-то нет — и это нормально. Мы хотим двигаться быстро, а это значит, что мы даем каждому возможность быстро экспериментировать в любом направлении.
Узнайте больше: прочитайте мою публикацию в блоге «How we build AI at Grafana Labs: small steps that add up to actually useful AI»
На этой неделе на конференции ObservabilityCon 2026 мы сделаем еще один шаг вперед, осветив наши постоянные усилия по предоставлению возможностей ИИ, которые помогут вам работать умнее и быстрее. Обязательно зарегистрируйтесь на очное мероприятие или посмотрите прямую трансляцию нашего основного доклада.
/)
/)
/)