Реализация AI агента на базе LLM с нуля – что включает цикл разработки

Разработка AI агента, использующего большие языковые модели (LLM) – это малоизвестный пока еще и потому интересный инженерный процесс, охватывающий весь цикл создания от идеи до финального развертывания. Технические стандарты разработки агентских систем пока еще формируются.  В данной статье я поделюсь своим опытом и рассмотрю ключевые этапы, технологии и практические нюансы, которые встречаются при разработке такой системы с нуля.

Начнем с подготовительного этапа постановки задач и сбора данных. Первым делом необходимо чётко определить цели и задачи будущего агента. Предположим, что в центре системы обычная LLM — в рамках этой статьи не будем рассматривать мультимодальные агенты или модели рассуждений. Важно понять, каким образом LLM будет интегрирована в общий процесс. В 99% центральным звеном интеграции будет Retrieval-Augmented Generation (RAG) пайплайн. Через него модель будет получать данные, релевантные тем задачам, которые агент должен решать. И на этапе построения пайплайна критически важен сбор и предварительная обработка данных. Собранные данные могут включать текстовые документы, логи общения пользователей, справочные материалы, которые потом помогут модели понимать контекст и давать релевантные ответы. Сложность этого этапа зависит от того, какие у вас источники данных, сколько их, насколько серьезной предварительной (перед загрузкой в индекс) обработки они требуют.

От поставленных на предыдущем этапе целей для MVP вашего агента и от собранных данных зависит решение, какую именно LLM использовать, и какой будет архитектура всей системы. Выбор сейчас очень широкий — есть модели с открытым исходным кодом и коммерческие решения, и выбор, очевидно, влияет на последующую инфраструктуру и масштабирование. Например, многие разработчики обращаются к моделям с открытыми весами наподобие LLaMA, учитывая их гибкость и возможность дальнейшего файнтюнинга. Однако вычислительные требования и довольно сложный программный стек накладывают определенные ограничения. Необходимо рассчитать заранее мощности, ваша инфраструктура в большинстве случаев должна поддерживать CUDA или один из немногочисленных альтернативных фреймворков для GPU-ускорения (можно посмотреть в сторону облачных платформ, где CUDA-стек поставляется из коробки), а также возможность интеграции с ML-библиотеками, такими как PyTorch или TensorFlow.

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

Самая замечательная часть — обучение и оптимизация модели. Чаще всего это файнтюнинг — если используется предобученная LLM, то её можно адаптировать под конкретные задачи с помощью дополнительного обучения на специализированных датасетах. Затем происходит настройка гиперпараметров, промпт-инжиниринг и оптимизация модели под конкретные сценарии использования. На этом этапе не обходится без множества evaluation-тестов. Можно взять очень общий пример — бенчмарк MT-bench для проверки на следование инструкциям. Но агенты чаще всего специализированы под конкретные случаи использования, так что полезно будет собрать свой кастомный evaluation датасет. Это позволит облегчить ручное тестирование.

Наконец, оптимизация производительности. Для ускорения инференса (да и файнтюнинга) применяются разнообразные техники квантизации. При инференсе — еще и распараллеливание запросов к модели (continuous batching), что особенно важно при работе с высокими нагрузками.

После того как модель готова, наступает этап её интеграции в существующую инфраструктуру. Об этом я достаточно подробно писал в другой статье.

Для успешной эксплуатации AI агента необходимо проводить регулярное (лучше автоматизированное) тестирование системы — были уже упомянуты evaluation-тесты самой LLM, но не стоит забывать и о других компонентах системы, будь то API, БД или другие модули, которые тоже нужно тестировать.

Наконец, пару слов о финальном этапе разработки – это развертывание системы в рабочей среде и её последующее обслуживание. Нужно быть готовым к частым обновлениям — в стремительно развивающейся ML-отрасли LLM приходится постоянно дообучать, а то и менять на совершенно новые, сегодня GPT-4o, а завтра DeepSeek. Вычислительные ресурсы при этом то и дело приходится масштабировать. Поэтому для поддержки агентской системы понадобится полноценная MLOps-команда. Это лишь некоторые из трудностей, поскольку, возвращаясь к первоначальной мысли этой статьи, разработка агентских систем — во многом неисследованная территория.