Как оценить инфраструктуру для ИИ-агента: считать одну завершённую операцию
Агентная система — это не только модель. Между вопросом пользователя и принятым результатом обычно стоят поиск, база данных, вызов инструмента, проверка разрешений, повтор после ошибки и запись в журнал. Если оценивать лишь время генерации, инфраструктура будет выглядеть готовой ещё до первого рабочего дня. Реальная единица измерения — завершённая операция, которую человек может принять.
Например, агент должен найти заказ, проверить условие возврата и подготовить ответ оператору. Для этого нужны доступ к карточке заказа, поиск по инструкции, модель, сетевые вызовы и понятный экран подтверждения. Ошибка в любом слое меняет стоимость и риск. Поэтому пилот начинайте с карты одной операции, а не с выбора самого большого сервера.
Нарисуйте путь запроса
Запишите последовательность: входное событие, проверка пользователя, поиск данных, обращение к модели, вызов инструмента, проверка результата и решение человека. Рядом укажите, какие данные переходят между узлами, сколько времени занимает шаг и может ли он изменить внешнее состояние. Если агент только читает документ, последствия ограничены. Если он отправляет письмо или меняет заказ, требуется отдельное подтверждение.
Карта помогает найти настоящий узкий участок. Медленный ответ может быть следствием не модели, а лишнего поиска, большой картинки в контексте или повторного запроса после невалидного JSON. Не ускоряйте весь граф сразу: измерьте каждый переход на нескольких обычных примерах и одном заведомо сложном.
Сначала определите бюджет ошибки
До нагрузки решите, что система не имеет права делать. Примеры: возвращать клиенту непроверенный срок, читать чужой каталог, выполнять команду без владельца или повторять платный вызов бесконечно. Эти ограничения превращаются в тесты и настройки, а не остаются фразой в инструкции.
Разделите ошибки на обратимые и необратимые. Неверный черновик можно вернуть оператору. Отправленное письмо, удалённая запись или изменённый платёж — уже внешнее событие. Для второй группы добавьте двухступенчатое подтверждение, журнал аргументов и кнопку отмены, если она технически возможна. Агент должен уметь остановиться, а не искать обходной путь.
Сопоставьте варианты размещения
Облако обычно проще масштабировать и обновлять. Локальный сервер даёт больше контроля над закрытыми данными, но требует обслуживания памяти, диска, драйверов и резервных копий. Edge-контур оправдан, когда критична задержка или нестабилен канал связи. Смешанная схема тоже возможна: очистка и фильтрация остаются внутри сети, сложное рассуждение выполняется удалённо на обезличенном контексте.
Не переносите общий рейтинг в свой сценарий. Для каждой схемы посчитайте полный путь: время загрузки, ожидание, повтор, ручную проверку и поддержку. Небольшой локальный сервер может выиграть на приватности, но проиграть по очереди запросов. Облачный API может отвечать быстро, но зависеть от тарифа, лимита и условий хранения. Методика такого сравнения разобрана в материале как выбрать облачную или локальную ИИ-модель.
Проверьте память и параллельность
Укажите, сколько запросов приходит одновременно, а не только среднее число за день. Пиковая очередь показывает, хватит ли видеопамяти, оперативной памяти и соединений с базой. Считайте отдельные лимиты для модели, поиска и инструментов: увеличение контекста может оставить меньше памяти для параллельных задач.
Запустите тест с одним запросом, затем с двумя, четырьмя и ожидаемым пиком. Измеряйте медиану и медленный хвост задержки, а также количество отказов и повторов. Если система становится непредсказуемой уже на третьем запросе, не маскируйте это увеличением тайм-аута. Ограничьте очередь, сообщите оператору о задержке и определите безопасный отказ.
Проведите тест на плохих входах
В контрольный набор включите неполные данные, неверный формат, большой файл, недоступный инструмент, противоречивые инструкции и попытку спрятать команду в тексте документа. Для каждого случая ожидаемый результат может быть не ответ, а уточняющий вопрос или остановка. Сохраняйте исходный вход, решение policy-слоя, вызовы инструментов и финальный статус.
Попросите отдельного проверяющего посмотреть, не раскрывает ли журнал секреты и персональные данные. Полные запросы редко нужны для метрики; часто достаточно обезличенного идентификатора, размера контекста, версии и кода ошибки. Правила ведения истории изменений описаны в материале как вести журнал работы с ИИ.
Посчитайте стоимость принятого результата
В бюджет входят не только токены и аренда сервера. Добавьте индексацию, хранение, сетевые вызовы, повторные попытки, время инженера и минуты оператора. Сравните эту сумму с ручным процессом на той же выборке. Быстрый черновик, который каждый раз перечитывают и переписывают десять минут, не является дешёвым.
Отдельно считайте неудачные вызовы инструментов. Они могут не вернуть полезный текст, но всё равно потребить лимит и создать запись в системе. Поставьте верхнюю границу шагов на одну операцию и остановите цепочку после нескольких одинаковых ошибок. Повтор без новой информации редко исправляет причину сбоя.
Настройте наблюдаемость до запуска
Для каждой операции сохраняйте идентификатор, версию модели и инструментов, длительность шагов, причину остановки и решение проверяющего. Настройте предупреждения по медленному хвосту, резкому росту повторов и стоимости. Не записывайте секреты в общий лог и ограничьте доступ к диагностике по ролям.
Проверьте, можно ли восстановить ход конкретной операции через день. Если видно только финальное «ошибка», инфраструктуру невозможно улучшать: команда будет спорить о впечатлениях. Если журнал хранит весь клиентский текст без защиты, он сам становится источником риска. Баланс между диагностикой и минимизацией данных — часть архитектуры, а не задача после релиза.
Условия расширения и отката
Начинайте с read-only режима и небольшой группы пользователей. Разрешайте один инструмент за раз, держите ручное подтверждение внешнего действия и заранее назначьте владельца инцидента. Пилот можно расширять, когда качество сохраняется на новых примерах, задержка укладывается в договорённость, а стоп-условия действительно срабатывают.
Откат должен быть конкретным: отключить маршрут агента, вернуть предыдущую версию промпта, закрыть ключ интеграции и восстановить ручную форму. Проверьте это упражнением, а не записью в документе. Если откат требует ночной миграции, система уже получила слишком широкую власть для экспериментального режима.
Соберите паспорт одной операции
Перед запуском оформите для выбранного сценария короткий паспорт. В нём достаточно указать вход, допустимый размер контекста, список разрешённых инструментов, предельное число повторов, владельца ручного подтверждения и условия остановки. Рядом запишите три числа: медианную задержку, медленный хвост и полную стоимость принятого результата. Такой лист позволяет сравнивать версии инфраструктуры на одной и той же задаче, а не спорить о впечатлении от демо.
Проведите два прогона: обычный рабочий день и искусственный пик. Во втором постепенно увеличивайте параллельность, пока не появится безопасный отказ — очередь, сообщение оператору или переход в read-only. Не пытайтесь любой ценой сохранить автоматический ответ. Зафиксируйте, на каком шаге система остановилась, сколько ресурсов уже потратила и удалось ли восстановить операцию по журналу без чтения лишних персональных данных.
После каждого изменения обновляйте только одну строку паспорта и повторяйте тот же набор входов. Если выросла скорость, но увеличились повторы или время ручной проверки, считайте это регрессом. Если снизилась стоимость, но пропала возможность объяснить решение, сначала восстановите наблюдаемость. Паспорт не заменяет мониторинг, но не даёт команде потерять связь между техническими метриками и результатом, который принимает человек.
Инфраструктура агента готова не тогда, когда модель отвечает быстро. Она готова, когда команда понимает путь одной операции, знает цену ошибки, видит каждый вызов и может безопасно остановить цепочку. Такой подход сначала кажется медленнее, зато превращает демонстрацию в управляемый рабочий процесс.