Конспект

Масштабирование AI-агентов: от прототипа до продакшена

Ключевые тезисы

• Масштабирование агента сталкивает с 7 ключевыми проблемами: производительность, стоимость, предсказуемость, воспроизводимость, observability, безопасность и повторяемость разработки.
• Без качественной системы observability (логи, трейсы, метрики) запускать агента в продакшн нельзя.
• Оптимизация стоимости и скорости работы — критически важна для экономики продукта.
• Безопасность строится на принципе минимальных привилегий и авторизации на уровне инструментов, а не только на промптах.
• Платформенный подход к разработке агентов имеет смысл только при необходимости создания трёх и более похожих агентов.

Проблемы масштабирования агентов

При переходе от прототипа к продакшну возникают семь основных проблем:

1. Медленная работа (Latency): Пользователи привыкли к мгновенным ответам (200 мс), а агенты с LLM могут работать 20-30 секунд.
2. Непредсказуемая стоимость: Сложные запросы с цепочками размышлений требуют множества вызовов LLM, что быстро делает продукт убыточным.
3. Галлюцинации и непредсказуемость: LLM, обученная помогать, может выдумать ответ (например, несуществующий рейс), если инструмент вернул ошибку.
4. Невоспроизводимость результатов: Из-за стохастичной природы LLM нельзя гарантировать одинаковый ответ на один и тот же запрос.
5. Отсутствие observability: Невозможно понять, что происходит "под капотом" на проде без логов, трейсов и метрик. Единственный источник правды — жалобы пользователей.
6. Проблемы безопасности: Если агенту доступен инструмент, злоумышленник обязательно попытается им воспользоваться, обойдя ограничения в промпте.
7. Повторяемость разработки: Создание второго, третьего агента требует повторения всех шагов (качество, паттерны, observability), что не масштабируется.

Observability: видимость в продакшене

Без системы observability работать с агентом в продакшене нельзя. Цена ошибки на большом количестве пользователей слишком высока.

Правильное логирование

Логи должны позволять отслеживать цепочку событий для конкретного запроса пользователя. Обязательно нужно логировать:

• Каждый вызов LLM (успешный/неуспешный).
• Каждый вызов инструмента (tool).
• Все входящие параметры агента и его ответы пользователю.
• Все ошибки и исключения.

Трейсы и спаны

Для связывания логов в единую картину используются две абстракции:

• Спан (Span): Низкоуровневая операция (вызов LLM, вызов инструмента, ответ пользователю).
• Трейс (Trace): Объединяет все спаны, относящиеся к одному запросу пользователя.
• Сессия (Session): Объединяет все трейсы в рамках одного диалога (чата) пользователя с агентом.

Ключевые метрики для мониторинга

1. Время ожидания ответа пользователем.
2. Количество шагов агента до финального ответа.
3. Количество израсходованных токенов на запрос.
4. Success-rate вызовов внешних инструментов.
5. Success-rate вызовов внешних моделей (LLM).
6. Общий success-rate обработки запроса (можно начать с простого: "все шаги завершились без исключений").
7. Error rate (отдельно для оперативного реагирования на инциденты).

Алертинг

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

Инструменты

• Langfuse: для просмотра трейсов и логов агентов.
• Grafana + Prometheus: для дашбордов и сбора метрик.

Автоматизация работы с качеством

После настройки метрик возникает проблема "белого листа": как улучшать качество, если оно, например, 62%?

Подход к улучшению

1. Категоризация проблем: Проблема в промпте, инструментах или архитектуре агента?
2. Эксперименты с базовыми паттернами (из предыдущих лекций):
   • Качественное описание инструментов.
   • Structured Output.
   • Few-shot примеры в промпте.
   • Chain-of-Thought / Reasoning.
3. Автоматическая прокачка промптов (когда ручные методы исчерпаны).

DSPy: автоматический промипт-инжиниринг

DSPy — фреймворк, который рассматривает подбор промпта как задачу оптимизации.
Как работает:

1. Задаём задачу (например, "поиск авиабилетов по запросу").
2. Определяем модель и паттерн reasoning (например, Chain-of-Thought).
3. Готовим датасет (input-output пары) и метрику для оценки.
4. Алгоритм DSPy в цикле подбирает оптимальный набор токенов (промпт), который максимизирует метрику на датасете.

Результат: Автоматически подобранный промпт, который может дать прирост качества до 30%. Позволяет уйти от "слепых" экспериментов.

Пайплайн автоматизации

Можно построить CI/CD пайплайн (например, в GitLab), который:

1. При изменении промпта в коде автоматически запускает цикл оценки.
2. С помощью DSPy прокачивает промпт.
3. Сохраняет новую, улучшенную версию промпта обратно в код.
   Фокус смещается с правки промптов на улучшение обучающей выборки (датасета).

Оптимизация стоимости и скорости

Когда действительно нужна LLM?

• Простая задача → решайте кодом.
• Задача средней сложности (классификация) → используйте классические ML-модели.
• Сложная, гибкая задача, требующая рассуждений → только тогда стоит применять тяжелые LLM.

Паттерны оптимизации

1. Model Router: Маршрутизация запросов к разным моделям в зависимости от сложности.
   • Как начать: парсинг regex, поиск по ключевым словам (для FAQ).
   • Для сложных случаев: классификация запросов на кластеры (простой/средний/сложный) с помощью классических моделей или LLM.
   • Важно: предусмотреть fallback на более сильную модель.
2. Ускорение обработки:
   • Параллельные вызовы инструментов.
   • Оптимизация промптов для reasoning (меньше шагов).
   • Стриминг (Streaming) ответов: улучшает UX и позволяет гибче управлять приоритизацией обработки.
3. Лимиты (Guardrails):
   • Жёсткий лимит на количество шагов reasoning.
   • Таймауты на ответ.
   • Отслеживание и прерывание циклических вызовов.
4. Масштабирование архитектуры:
   • Очередь (Queue) + Воркеры (Workers): Позволяет выдерживать пиковые нагрузки и управлять временем ответа (SLA).
   • Кэширование:
     • Семантический кэш ответов агента (похожие запросы → один ответ).
     • Кэш вызовов инструментов (снижает нагрузку на внешние системы).
     • Кэш запросов к LLM (если тот же запрос был недавно).

За чем следить?

• Стоимость обработки одного запроса (особенно в высоких перцентилях).
• Дневное и месячное потребление квот (чтобы видеть и пики, и тренды).

Безопасность агентов

Главный принцип: Агент — это прокси ко всем сервисам, к которым у него есть доступ. Если что-то можно сделать, это обязательно кто-то попробует сделать.

Чего нельзя делать

• Доверять промптам как единственному средству защиты.
• Передавать в LLM секреты, персональные данные, идентификаторы.

Принципы безопасного дизайна

1. Контроль на уровне инструментов:
   • Агент видит строго ограниченный список инструментов.
   • Инструменты имеют строго определённые аргументы (без лишних данных).
   • Каждый инструмент проверяет и фильтрует то, что возвращает в модель.
2. Авторизация на уровне пользователя:
   • Рассматривайте LLM как потенциального злоумышленника.
   • Авторизуйте запросы так, будто их делает сам пользователь (например, с помощью OAuth-токенов).
   • Инструмент должен проверять права пользователя, а не LLM.

Пример уязвимости: Инструмент принимает user_id как параметр. Злоумышленник может заставить модель подбирать ID других пользователей. Решение: убрать user_id из параметров, получать его из защищённого контекста сессии.

Безопасный деплой

Используйте канареечные релизы (canary releases): выкатывайте новую функциональность на небольшой процент пользователей,