Observability в агентах. Почему прозрачность важнее технологичности.
LLM не славятся надежностью. Галлюцинации — топ-1 барьер для внедрения их в бизнес. Еще мы дали LLM кучу инструментов, разрешили ей планировать, добавили мультиагентность для души. Можно ли этот коктейль спроектировать так, чтобы всё это работало без сбоев? Нет. Обязательно что-то сломается.
Но что мы должны спроектировать — так это механизмы быстрого анализа того, где и что сломалось. Для этого есть инструменты, которые называются observability. Сегодня обсудим, что это и почему без этого невозможно использовать агентов в продакшене.
Что такое observability
В обычной разработке всё прозрачно: код — источник правды. При любой ошибке можно разобраться, что пошло не так.
В AI-разработке код ничего не объяснит. Источник правды — только история: какие были входные данные и какие действия совершила модель. Набор методов для эффективного анализа этой истории и есть observability. Это:
1. Сбор трейсов. Каждый новый запуск агента получает уникальный идентификатор, к которому привязываются все действия агента в рамках этого запуска. В итоге получается цепочка действий, которая называется трейс. Его дальше и анализируют.
2. Логирование. Все инструменты (тулы) должны логировать входные данные, промежуточные состояния, ошибки и финальный ответ. Тогда тулы в трейсе можно отдебажить.
3. Метрики качества (подробнее тут). В рамках одного трейса нужно обязательно оценить финальный ответ агента и, желательно, все его промежуточные действия. Разметить всё это вручную нереально, чаще используется LLM-as-a-judge (гайд по теме)
4. Дашборды. Помимо метрик качества, там должны быть технические метрики: скорость ответа, среднее число токенов и т. д.
Самые известные observability-библиотеки — это Langfuse и Arize Phoenix.
Как это работает вместе
- Вы мониторите состояние агентов на дашборде по техническим метрикам и метрикам качества.
- Если произошло падение метрик, выбираете трейсы, где аномально плохое качество, и дебажите: в какой момент времени и что именно сломалось.
- Во время дебага смотрите на прокси-метрики действий агента (через LLM-as-a-judge), проверяете все тулы. Благо для этого мы заранее настроили логирование.
Без этого пайплайна разбор любой ошибки агента будет занимать вечность. И ваш проект так и останется на слайдах пилоте.
Резюме
Черные технологичные ящики — это прикольно на презентации. Для инвесторов и начальников. Об этом прикольно рассказывать коллегам и друзьям. Но их очень не прикольно масштабировать и держать в продакшене. Любая поломка черного ящика — всю ночь будете разбирать причину. Лучше сделайте эти ящики прозрачными и спите спокойно.
Друзья, если у вас есть вопрос, как сделать AI более прозрачным, пишите мне @seva_batareika. Разберем его отдельно.
LLM не славятся надежностью. Галлюцинации — топ-1 барьер для внедрения их в бизнес. Еще мы дали LLM кучу инструментов, разрешили ей планировать, добавили мультиагентность для души. Можно ли этот коктейль спроектировать так, чтобы всё это работало без сбоев? Нет. Обязательно что-то сломается.
Но что мы должны спроектировать — так это механизмы быстрого анализа того, где и что сломалось. Для этого есть инструменты, которые называются observability. Сегодня обсудим, что это и почему без этого невозможно использовать агентов в продакшене.
Что такое observability
В обычной разработке всё прозрачно: код — источник правды. При любой ошибке можно разобраться, что пошло не так.
В AI-разработке код ничего не объяснит. Источник правды — только история: какие были входные данные и какие действия совершила модель. Набор методов для эффективного анализа этой истории и есть observability. Это:
1. Сбор трейсов. Каждый новый запуск агента получает уникальный идентификатор, к которому привязываются все действия агента в рамках этого запуска. В итоге получается цепочка действий, которая называется трейс. Его дальше и анализируют.
2. Логирование. Все инструменты (тулы) должны логировать входные данные, промежуточные состояния, ошибки и финальный ответ. Тогда тулы в трейсе можно отдебажить.
3. Метрики качества (подробнее тут). В рамках одного трейса нужно обязательно оценить финальный ответ агента и, желательно, все его промежуточные действия. Разметить всё это вручную нереально, чаще используется LLM-as-a-judge (гайд по теме)
4. Дашборды. Помимо метрик качества, там должны быть технические метрики: скорость ответа, среднее число токенов и т. д.
Самые известные observability-библиотеки — это Langfuse и Arize Phoenix.
Как это работает вместе
- Вы мониторите состояние агентов на дашборде по техническим метрикам и метрикам качества.
- Если произошло падение метрик, выбираете трейсы, где аномально плохое качество, и дебажите: в какой момент времени и что именно сломалось.
- Во время дебага смотрите на прокси-метрики действий агента (через LLM-as-a-judge), проверяете все тулы. Благо для этого мы заранее настроили логирование.
Без этого пайплайна разбор любой ошибки агента будет занимать вечность. И ваш проект так и останется на слайдах пилоте.
Резюме
Черные технологичные ящики — это прикольно на презентации. Для инвесторов и начальников. Об этом прикольно рассказывать коллегам и друзьям. Но их очень не прикольно масштабировать и держать в продакшене. Любая поломка черного ящика — всю ночь будете разбирать причину. Лучше сделайте эти ящики прозрачными и спите спокойно.
Друзья, если у вас есть вопрос, как сделать AI более прозрачным, пишите мне @seva_batareika. Разберем его отдельно.