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

«На практике – модель, которая уверенно решает задачу в открытом инструменте, после интеграции во внутренние процессы может работать иначе: медленнее, дороже или менее стабильно», — сообщает «Код Дурова».

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

Первым рабочим решением стал веб-интерфейс с чат-режимом, где модели настраивались под разные профессиональные роли. Однако такой формат не решал задачу интеграции в полный жизненный цикл программного обеспечения, так как чат оставался отдельным окном.

Для внедрения агентов в процессы команда изучила несколько платформ и адаптировала одну из них под внутренние требования. Практика показала, что начинать с универсального агента неэффективно из-за высокого порога входа для сотрудников.

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

Следующий уровень — ассистент-оркестратор, который принимает запрос на естественном языке, определяет последовательность действий и вызывает специализированных агентов как инструменты. Если работа требует значительного времени, ассистент предлагает выполнить её асинхронно.

Чем сложнее задача агента, тем больше данных необходимо передать модели. Для повышения качества используются корпоративные вики и «банк памяти», которые дают модели необходимые сведения и снижают риск остановки из-за нехватки контекста. Небольшие задания могут занимать от 15 минут до часа.

Этот подход повышает автономность, но увеличивает расход токенов. По статистике реальных проектов, на 100 тысяч входящих токенов может приходиться около 50 токенов результата. Масштаб расходов стал виден после запуска внутреннего биллинга.

За несколько недель июля система зафиксировала около 5 миллиардов израсходованных токенов, из них почти 1,5 миллиарда пришлись на модель, развернутую на собственном сервере. За тот же период было выполнено порядка 200 тысяч запросов со средним объемом около 12–13 тысяч токенов.

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

Контролировать такую систему можно на уровне отдельных запросов и задач с помощью биллинга. Он показывает, какая модель обработала запрос, какой агент его сформировал, сколько токенов было передано и где возник перерасход. Эти данные помогают найти случаи, когда система многократно загружает один и тот же контекст, использует лишние инструменты или неправильно строит последовательность действий.

При небольшом числе пользователей такие ошибки можно обнаруживать вручную, но при 600 разработчиках они становятся финансовым риском. Один неверно настроенный процесс способен за короткий срок израсходовать значительный объем ресурсов.

Наблюдаемость позволяет управлять методологией работы агентов: сокращать лишний контекст, корректировать память, менять набор инструментов и выбирать подходящую конфигурацию инференса. Универсальной настройки для всех сценариев нет.

Собственный сервер снижает стоимость токена при высокой загрузке. Оставшиеся 16 часов можно использовать для асинхронной очереди. Разработчик ставит задачи, проверяет план и определяет ожидаемый результат. После завершения рабочего дня агент продолжает кодирование, запускает тесты и готовит изменения к проверке.

Такой подход может увеличить объем с пяти задач за рабочий день до 20 задач за сутки. Более полная загрузка собственного сервера распределяет стоимость инфраструктуры на большее число выполненных операций. Но для этого агент должен работать автономно и доводить задачу до завершения.

Корпоративная ИИ-платформа не сводится к модели, интерфейсу или набору агентов. Её результат зависит от того, как связаны между собой защищенная инфраструктура, специализация агентов, оркестрация, память, биллинг и загрузка вычислительных мощностей.

Количество внедренных агентов мало говорит о зрелости системы. Важнее, понимает ли компания стоимость конкретной задачи, может ли найти источник перерасхода и способна ли использовать инфраструктуру в те часы, когда сотрудники не работают с ней напрямую. ИИ-агенты становятся производственным инструментом, когда бизнес умеет управлять качеством, автономностью и стоимостью результата в одном процессе.

Подписывайтесь на наш Telegram-канал, чтобы быть в курсе всех новостей и событий Рунета.