Ваш конспект

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

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

• Масштабирование агента (по пользователям, команде разработки или количеству агентов) неизбежно сталкивает с рядом проблем.
• Критически важны observability (наблюдаемость), качество, экономия ресурсов и безопасность.
• Решение о построении платформы принимается на основе частоты повторяющихся задач, а не на старте.

Семь проблем масштабирования

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

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

Без системы наблюдаемости невозможно управлять агентом, которым пользуются тысячи людей.

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

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

Логирование и трассировка

• Логировать нужно: каждый вызов LLM и инструмента, входные параметры агента, его ответы пользователю, все ошибки.
• Связывать логи в цепочки помогает концепция трейсов (traces) и спанов (spans):
  • Спан — низкоуровневая операция (вызов инструмента, запрос к LLM).
  • Трейс — объединяет все спаны в рамках одного запроса пользователя.
  • Сессия — объединяет несколько трейсов в рамках одного диалога (чата) с агентом.
• Инструменты: Langfuse (для трейсов и логов), Grafana + Prometheus (для дашбордов и метрик).

Алертинг

• На основе собранных метрик необходимо настроить систему оповещений (например, в Slack/Telegram).
• Начальные пороги для алертов можно установить по бейзлайну — текущим значениям метрик после первого запуска в продакшн. Главная цель — не деградировать от этого уровня.

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

Цель — уйти от "слепых" экспериментов и автоматизировать улучшение промптов.

Подходы к улучшению качества

1. Ручные паттерны: Структурированный вывод (structured output), few-shot примеры в промпте, chain-of-thought reasoning. Дают быстрый прирост.
2. Автоматическая оптимизация промптов: Инструмент DSPy (от Stanford).
   • Задаётся задача, модель, паттерн рассуждений, метрика качества и датасет.
   • Алгоритм автоматически подбирает оптимальный набор токенов в промпте, чтобы максимизировать метрику на датасете.
   • Позволяет автоматизировать пайплайн: изменение промпта → оценка → сохранение лучшей версии.

Рекомендации

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

Оптимизация стоимости и пользовательского опыта

Куда уходят деньги и как их экономить?

Когда нужна LLM?

• Код: Простые, детерминированные задачи.
• Классические ML-модели: Классификация, где не нужна гибкость LLM.
• LLM: Сложные, недетерминированные задачи, требующие рассуждений и гибкости.

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

1. Model Router: Маршрутизация запросов к разным моделям в зависимости от сложности.
   • Например, 70% простых FAQ — в дешёвую/быструю модель, 30% сложных — в мощную.
   • Начинать можно с ключевых слов или классических классификаторов.
   • Обязательно нужен фолбэк на сильную модель.
2. Оптимизация скорости: Ускорение цикла агента напрямую экономит ресурсы.
   • Параллельные вызовы инструментов.
   • Оптимизация промптов для сокращения шагов reasoning.
   • Стриминг ответов для улучшения UX и хитрой приоритизации задач.
3. Лимиты: Защита от чрезмерного потребления ресурсов.
   • Жёсткие лимиты на количество шагов reasoning.
   • Таймауты на выполнение запроса.
   • Контроль за циклическими вызовами в рантайме.
4. Масштабирование и кэширование:
   • Очереди и воркеры для управления нагрузкой и соблюдения SLA.
   • Семантический кэш ответов агента на похожие запросы.
   • Кэширование вызовов инструментов и LLM (особенно эффективно на больших объёмах).

Борьба с галлюцинациями

• Гардрейлы в промптах (запрет на выдумывание).
• Structured output для принуждения к формату.
• Честное отключение сломанных инструментов с сообщением пользователю.

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

Основной принцип: рассматривайте LLM как потенциального злоумышленника.

Ключевые правила

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

Защита на уровне инструментов

• Инструменты должны иметь строго определённый и ограниченный набор аргументов.
• Аргументы должны быть очищены от чувствительных данных.
• Инструмент должен фильтровать свои ответы, не возвращая опасные данные в LLM.

Канареечные релизы

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

Платформа: когда и зачем строить?

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

Три стадии развития

1. Прототип: Собрать первого агента и решить задачу.
2. Масштабирование и стабилизация: Столкнуться с проблемами продакшена и построить вокруг агента observability, безопасность, оптимизацию.
3. Платформа: Когда типовые задачи (логирование, авторизация, обёртки над инструментами, оценка качества) повторяются при создании третьего и последующих агентов.

Принцип "правила трёх"

Если одну и ту же инфраструктурную задачу нужно решить в трёх и более местах, выделение платформенной команды (или хотя бы разработчика) оправдано.

Разделение ответственности

• Инфраструктурный слой (платформа): Логирование, трейсы, метрики, CICD, общие обёртки, система оценки. Делается один раз и хорошо.
• Бизнес-логика (продуктовые команды): Промпты, графы выполнения (например, в LangGraph), уникальная последовательность шагов агента. Остаётся гибкой и изменяемой для каждого агента.

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