/)
В Grafana Labs наблюдаемость — это наша специализация. Поэтому, когда мы начали создавать AI-агентов, мы естественным образом применили те же инстинкты, что используем для любой другой системы: измерять, устанавливать целевые показатели и делать надежность чем-то, что можно обосновать, а не просто на что надеяться.
Этот инстинкт привел нас к неожиданно полезному результату. Оказывается, одна из старейших идей в инженерии надежности — бюджет ошибок (error budget) — идеально ложится на одну из новейших проблем в разработке ПО: как понять, действительно ли AI-агент хорош?
Именно это мы обнаружили, когда направили наш инструментарий наблюдаемости на поведение агента. Мы считаем, что это по-настоящему прозрачный способ оценки качества агента, и хотим поделиться им с вами.
Та часть агента, которую вы не видите
У вас могут быть настроены все стандартные сигналы: задержка (latency), количество токенов, частота ошибок, трассировки каждого вызова инструментов. Но ни один из них не отвечает на самый важный для агента вопрос: «Он хорош?»
Ответ может прийти за 800 миллисекунд, стоить почти ничего, не выдать ни одной ошибки и при этом быть уверенно и бегло неверным.
Этот разрыв важен, потому что каждое изменение в агенте — это небольшой риск, если вы не можете измерить качество. Подправить промпт и надеяться; заменить модель и скрестить пальцы; выпустить обновление и ждать, пока кто-нибудь пожалуется. Это именно те «слепые зоны», для устранения которых и существует наблюдаемость.
Превращаем поведение в число с помощью оценок
Поэтому мы измеряем поведение напрямую с помощью оценок (evaluations) — точно так же, как когда-то превратили вопрос «Работает ли сайт?» в простой процент.
В конечном счете, оценка — это именно то, чем она является. Вы просите судью — часто другую языковую модель — прочитать диалог, отдельное сообщение или один вызов инструмента и выставить оценку.
Основывался ли он на предоставленном контексте или выдумал факты? Действительно ли он сделал то, о чем просил пользователь? Был ли он токсичен? Допустил ли утечку личной информации? Поддался ли на инъекцию промпта? Судья выносит вердикт — «пройдено» или «не пройдено», или оценку по шкале — и внезапно то, что вы не могли увидеть, обретает значение, которое можно оценить.
Для некоторых проверок даже не нужна модель. Обычное регулярное выражение отлично справится с задачей, если нужно понять, не допустил ли ответ утечку API-ключа или не упомянул ли конкурента. В Grafana Cloud Agent Observability простые детерминированные проверки и более сложные модели-судьи прекрасно сосуществуют.
Важно сразу отметить: качество — это не одно число. «Хорошо» — это на самом деле набор отдельных типов поведения, и они могут давать сбои независимо друг от друга. Агент может быть идеально точным, но при этом медленным. Он может быть полезным, но иногда токсичным. Он может дать идеальный ответ, но при этом стоить в три раза дороже, чем должен.
Поэтому вместо того, чтобы гнаться за одним усредненным показателем точности, полезнее выбрать несколько типов поведения, которые действительно важны для вашего агента, и дать каждому свою метрику. Обоснованность. Выполнение задачи. Токсичность. Задержка. Стоимость. Каждое из них становится самостоятельным числом, и для каждого можно установить свой бюджет.
Вы можете откалибровать судью так, чтобы он выставлял оценки на основе желаемого поведения. Иногда достаточно простого «пройдено/не пройдено». В других случаях более информативной будет шкала, и это совершенно нормально. Например, если вы оцениваете обоснованность по шкале от одного до пяти, просто проведите черту, чтобы превратить это в цель: скажем, четыре балла и выше считаются успехом. В любом случае, в итоге вы получаете показатель, по которому можно установить целевое значение — долю диалогов, прошедших проверку.
Суть в том, что поведение, которое казалось слишком размытым, чтобы его определить, теперь стало метрикой. Вы сделали качество агента измеримым, и как только это произошло, оно наконец стало наглядным и готовым к управлению.
И в Grafana Cloud начать путь к этому можно с простого запроса: попросите Grafana Assistant создать оценку для поведения, которое вас беспокоит.
По мере того как она будет работать на реальных диалогах, вы начнете видеть, как часто ваш агент проходит проверку.
После этого Assistant создает и активирует правила оценки, специфичные для каждого агента.
Одного числа недостаточно
Вот здесь опыт работы с наблюдаемостью окупается, потому что мы уже видели эту ловушку.
Одинокий показатель качества на дашборде приводит к предсказуемой проблеме. Возможно, вы начнете реагировать на каждое небольшое колебание или слишком часто поднимать ложную тревогу. Прежде чем вы это заметите, все научатся игнорировать график. У всех нас есть тот самый Slack-канал, полный предупреждений, которые никто не читает. Новая блестящая метрика агента легко может стать еще одной такой.
Чего не хватает числу, так это решения. Именно это добавляет SLO (целевой уровень обслуживания).
Идея проще, чем аббревиатура. Вы берете свое измерение и устанавливаете для него целевой показатель. В данном случае, допустим, вы хотите измерить долю диалогов, которые судья пометил как успешно выполненные, и устанавливаете цель 95% за 30 дней. Самое интересное — это то, что остается. Если вы стремитесь к 95%, остальные 5% — это не провал. Это бюджет.
Этот небольшой сдвиг меняет восприятие всей системы. Ненадежность до определенного предела перестает быть тем, что нужно искоренять, и становится тем, что можно «тратить».
Бюджет — это разрешение, а не давление
Лучшая часть этой идеи — не математика, а разрешение.
Когда у вас есть остаток бюджета, сигнал ясен: действуйте. Пробуйте амбициозный промпт, тестируйте новую модель или рискуйте, потому что вы заложили возможность небольших неудач. Когда бюджет заканчивается, сигнал столь же ясен: притормозите с новыми функциями, качество требует внимания. Красный свет, зеленый свет — только вместо интуиции на совещании вы ориентируетесь на собственные данные.
Есть замечательный момент в одном из эпизодов подкаста «Grafana's Big Tent», где SRE называет бюджет ошибок «аварийным выключателем». Никто не думает о нем весь день, говорит он, но он возвращает вас к реальности, когда вы совершаете ошибку. Именно такая атмосфера нам нужна в команде агентов: не страх, не нажатие на тормоза при малейшем колебании оценки судьи, а спокойное «все в порядке, продолжайте строить», подкрепленное числом, которое похлопает вас по плечу, когда придет время замедлиться.
И бюджет работает в обе стороны. Прежде чем выпустить новый промпт или модель, вы можете прогнать их через уже известные диалоги и убедиться, что они все еще укладываются в ваши цели, чтобы изменения, которые незаметно нарушают одно из правил поведения, никогда не дошли до пользователей. Агентам этот страховочный трос нужен больше, чем большинству программ, потому что давление из-за необходимости двигаться быстро огромно, и так велик соблазн просто выпустить обновление, полагаясь на «вайб».
Тихий дрейф — вот о чем стоит беспокоиться
Как только вы начинаете думать о бюджетах, ваше внимание смещается. Вы перестаете фиксироваться на форме любого отдельного графика и начинаете следить за тем, как быстро вы тратите бюджет. Этот сдвиг очень важен именно для агентов.
Резкий скачок после неудачного дня диалогов — это громко, и его обычно замечают. Но на фоне 30-дневного бюджета он может едва оставить след, и это действительно полезно знать, потому что это спасает вас от паники из-за того, что вы в любом случае переживете.
На самом деле стоит следить за противоположным явлением: медленным, незаметным угасанием. Это крошечное, постоянное снижение качества, где ни один отдельный разговор не выглядит тревожным, но с каждым днем качество понемногу падает. Возможно, промпт постепенно устарел. Возможно, обновление модели оказалось чуть менее эффективным для вашего сценария использования. Возможно, ваши пользователи постепенно начинают просить о другом. Агенты практически созданы для того, чтобы скрывать это, поскольку их ответы остаются связными и правдоподобными, даже когда они отклоняются от нормы, и никакой простой порог не позволит это отследить. Но бюджет позволит, потому что он измеряет накопленный эффект, а не какой-то один момент.
Именно поэтому стоит доверять оповещениям, основанным на бюджете. Когда они срабатывают, обычно действительно что-то не так, и на это стоит обратить внимание. В мире, который уже устал от шумных оповещений, такое спокойствие дорогого стоит.
Но какую цель вообще выбрать?
Это обычно следующий закономерный вопрос: на какое число ориентироваться? Хорошо ли иметь 85% выполнения? Являются ли 95% нереалистичными? Это действительно сложнее, чем выбор целевого показателя времени безотказной работы (uptime), потому что меньше интуитивного понимания того, чего можно достичь с помощью агента.
Вам не нужно брать цифру с потолка. Как только ваши оценки проработают достаточно долго, чтобы собрать полезную выборку, попросите Assistant порекомендовать целевые показатели SLO на основе их результатов. В вашей собственной среде Grafana Cloud это даст вам отправную точку, основанную на том, как на самом деле ведет себя ваш агент. Затем вы можете попросить Assistant создать SLO, превратив эти измерения в цели и бюджеты.
Дальше решение за вами. Поднимите планку, если можете позволить себе быть строже, или опустите ее, если нужно больше свободы. Молодой агент, осваивающий новую область, может спокойно принять вероятность промаха 50/50, в то время как агент, работающий с платными клиентами, возможно, должен допускать ошибку лишь в 5% случаев. Суть в том, чтобы делать выбор осознанно.
Нам не нужно изобретать эту часть заново
Самое поразительное, если посмотреть на ситуацию в целом, заключается в том, насколько мало здесь на самом деле нового. Команды, работающие с агентами, сталкиваются с вопросом, над которым специалисты по надежности ломали голову годами: как двигаться быстро, идти на реальный риск и при этом сохранять доверие людей? Ответ всегда заключался в том, чтобы сделать то, что вас волнует, измеримым, выбрать цель и рассматривать разрыв как бюджет, который можно потратить. И этот же ответ удивительно хорошо подходит для сегодняшнего дня. Единственная новая часть — это измерение, и оценки дают нам его.
Таким образом, все части логично связываются воедино. Оценки превращают поведение в число, для числа устанавливается цель, а разрыв становится бюджетом: это разрешение на эксперименты, раннее предупреждение о регрессиях и общий язык, на котором могут говорить менеджер продукта и инженер дежурной смены. Ничто из этого не требует от вас изобретения новой философии программного обеспечения, нужно лишь применить то, что наблюдаемость уже дала нам для вашего агента.
Так что присвойте поведению вашего агента число, выделите этому числу бюджет, а затем, в рамках этого бюджета, экспериментируйте чуть свободнее. Мы будем искренне рады узнать, как у вас идут дела.
От поведения к бюджетам с небольшой помощью
Все, что мы описали, звучит полезно, но также звучит как работа. Решите, какое поведение важно. Создайте для него оценки. Следите за результатами. Выберите разумные цели. Превратите эти цели в SLO.
Как мы убедились, Assistant может помочь вам собрать эти части воедино. Вы можете просто попросить его создать оценки для одного из ваших агентов или для всех сразу. Дайте этим оценкам поработать некоторое время и собрать полезную выборку реальных данных. Затем попросите Assistant порекомендовать цели и создать SLO на основе того, что он видит.
Вы выбираете то, что важно для ваших агентов, а Assistant помогает с настройкой. От вашей первой оценки до целей и бюджетов, основанных на реальных диалогах, — вы можете начать, просто задав вопрос.
Оказывается, даже вашим агентам может пригодиться небольшая помощь от другого агента.
Grafana Assistant — это самый простой способ начать работу с метриками, логами, трассировками, дашбордами и многим другим в Grafana Cloud. У нас есть щедрый бесплатный тарифный план и варианты для любых задач. Зарегистрируйтесь бесплатно прямо сейчас!
Теги