Полная стек-архитектура агентного ИИ, уровень за уровнем: от фронтенда до возможностей мониторинга.
Десять уровней, скрывающихся за агентом для производства: фронтенд, загрузка данных, разбиение на части, генерация эмбеддингов, векторный поиск, извлечение информации, формулировка запросов, LLM, развертывание и оценка.
Источники: The Full Stack of Agentic AI: From User Interface to Production-Grade Intelligence
Искусственный интеллект уже давно вышел за рамки ситуации, когда кто-то вводит запрос и читает ответ. Современные продукты ИИ представляют собой полноценные программные системы. Они принимают документы, преобразуют хаотичный неструктурированный материал в пригодные для использования знания, генерируют эмбеддинги, извлекают контекст, взаимодействуют с большими языковыми моделями, запускают инструменты, работают внутри облачной инфраструктуры и контролируют собственную производительность. Это особенно верно для агентных систем ИИ. Агент — это не просто большая языковая модель, застрявшая в окне чата. Продуктовое приложение с агентным подходом требует целого набора технологий вокруг модели, причем сама модель является лишь одним из слоев в этой структуре.
Диаграмма референтной архитектуры такой стек-структуры служит удобной схемой, показывающей путь от фронтенда через процессы ввода данных, их извлечения и формулировки запросов к моделям, их развертыванию и мониторингу. В следующих разделах рассматривается каждый слой, его назначение, причины существования и то, как инструменты взаимодействуют между собой.
Уровни в одном взгляде
В следующем порядке работает вся стек-архитектура: фронтенд, обработка документов, разбиение на части и предварительная обработка, генерация эмбеддингов, векторная база данных, поиск информации, разработка промптов, использование больших языковых моделей, инфраструктура и развертывание, а также мониторинг и оценка.
Эта последовательность не является строгой цепочкой операций. В реальных агентных системах компоненты постоянно взаимодействуют друг с другом. Агент может несколько раз запрашивать информацию, вызывать внешние инструменты, использовать разные модели, оценивать собственные ответы и запускать дополнительные рабочие процессы перед тем, как получить окончательный результат. Стек лучше рассматривать как технологическую экосистему, обеспечивающую интеллектуальные функции, а не как простую цепочку запросов и ответов.
Уровень 1: фронтенд
Каждой системе ИИ необходимо место, где люди могут с ней взаимодействовать. Фронтенд обеспечивает пользовательский интерфейс — будь то чат-бот, корпоративный портал, панель аналитики, внутренний инструмент или рабочее пространство с поддержкой ИИ. К типичным технологиям относятся React, Next.js, Streamlit и Azure App Service. React используется для создания интерактивных интерфейсов, а Next.js представляет собой более полную платформу для разработки веб-приложений в производственных условиях. Streamlit удобен для быстрой разработки приложений на основе ИИ и обработки данных без использования традиционных инструментов фронтенда. Azure App Service предлагает управляемое хостинговое решение для веб-приложений и API.
В корпоративной схеме с использованием агентов фронтенд — это не просто чат-окно. Он может отображать прогресс работы агента, источники данных, полученные им, статус рабочего процесса, результаты работы инструментов, запросы на утверждение, сгенерированные документы и взаимодействие с человеком. Именно здесь ИИ становится доступным для бизнес-пользователей.
Уровень 2: загрузка документов
Для эффективной работы системе необходим доступ к соответствующей информации, однако корпоративные знания редко хранятся в упорядоченном формате. Они расположены в PDF-файлах, файлах Word, презентациях, сканах, веб-страницах, базах данных, электронных письмах и многом другом. Процесс загрузки предусматривает сбор и извлечение контента из всех этих источников.
Инструменты, предназначенные для этой задачи, включают Azure AI Content Understanding, Apache Tika, Microsoft Fabric, LangChain и движки OCR. OCR критически важен, когда информация находится внутри сканов или изображений. Apache Tika позволяет извлекать текст и метаданные из очень широкого спектра форматов. Microsoft Fabric способствует более широким корпоративным процессам обработки данных, а такие фреймворки, как LangChain, могут объединять компоненты загрузки с цепочками обработки на основе ИИ.
Цель проста: преобразовать разрозненную корпоративную информацию в контент, который может обработать машина. Без надежного слоя ввода даже самая совершенная модель будет испытывать трудности с предоставлением значимых ответов о вашей организации.
Слой 3: разбиение на части и предварительная обработка
Извлечение текста — это лишь начало. Документ объемом 200 страниц невозможно передавать целиком в каждый запрос к модели, поэтому большие документы необходимо разбивать на более мелкие, осмысленные единицы. Эти части могут быть абзацами, разделами, страницами или семантическими единицами, причем LangChain и подобные фреймворки предлагают несколько стратегий разбиения на части.
Эффективное разбиение текста — это не просто разделение на фрагменты каждые несколько сотен символов, поскольку некорректное разбиение разрушает контекст. Когда определение отделено от объяснения, придающего ему смысл, при поиске могут возвращаться неполные данные. Слишком большие фрагменты приводят к неточному поиску, а слишком маленькие теряют важные связи. Следовательно, этот подход напрямую влияет на качество всего последующего процесса обработки.
Предобработка включает очистку текста, удаление ненужного содержимого, нормализацию форматов, извлечение метаданных, определение структуры документа и дополнение фрагментов дополнительной информацией. На этом этапе часто определяется качество последующего поиска.
Уровень 4: эмбеддинги
После разбиения документов на фрагменты системе необходим способ передачи их смысла. Модель эмбеддингов преобразует текст в числовой вектор, при этом похожие понятия оказываются рядом друг от друга в пространстве эмбеддингов.
Сравните запрос на сброс пароля сотрудника с запросом о том, как изменить данные входа на работу. Формулировки различаются, но цель похожа, и хорошая модель встраивания это понимает. Среди поставщиков, представленных для этого слоя, — OpenAI, Cohere и сервисы ИИ на базе Azure. Полученные векторы лежат в основе семантического поиска и извлечения информации, что делает это одним из самых значимых сдвигов в стеке: человеческий язык превращается в математическое представление, которое обеспечивает семантическое сходство.
Слой 5: векторная база данных
Встраиваемые данные должны храниться там, где возможен быстрый поиск по сходству, и именно это и делает векторная база данных. В диаграмме перечислены Milvus, FAISS, Azure AI Search, Azure Cosmos DB и Azure Database for PostgreSQL. Они сильно отличаются по функциональным возможностям и моделям развертывания, но все они направлены на эффективное извлечение информации на основе семантического сходства.
Когда пользователь задаёт вопрос, сам запрос преобразуется в эмбеддинг, после чего система ищет наиболее близкие векторы. Найденные фрагменты затем передаются на более поздние слои. Именно это лежит в основе большинства систем генерации с усилением с помощью поиска.
Слой 6: слой поиска
База данных векторов хранит информацию, но именно слой поиска определяет, что именно будет показано модели. Это различие легко упустить из виду. Для поиска могут использоваться такие методы, как семантическое сходство, поиск по ключевым словам, фильтрация метаданных, гибридный поиск и переранжирование, а также такие инструменты, как Azure AI Search, LangChain и LlamaIndex.
Зрелая система объединяет в себе различные стратегии. Семантический поиск находит материалы, связанные по смыслу, в то время как поиск по ключевым словам гарантирует, что точные идентификаторы, названия продуктов, номера полисов или технические термины не пропадут. Это гибридный способ поиска, и в корпоративных решениях типа RAG всё чаще добавляются фильтры метаданных, механизмы переранжирования, знаниевые графы и другие элементы.
Цель не в том, чтобы получить как можно больше информации, а в том, чтобы получить правильную информацию.
Слой 7: инжиниринг промптов
После поиска системе необходимо сформировать подходящее указание для языковой модели. Промпт для производственного использования — это гораздо больше, чем просто вопрос пользователя; он может включать системные инструкции, полученный контекст, историю общения, бизнес-правила, требования к формату вывода, ограничения безопасности, примеры, определения инструментов и метаданные. LangChain, Promptify и DSPy — примеры инструментов, помогающих структурировать и настраивать промпты.
Инжиниринг промптов также выходит за рамки ручного формулирования умных текстов. Внимание смещается к инжинирингу контекста, который ставит более широкий вопрос: что должен получить модель, в какой структуре и на каком этапе рабочего процесса? Это имеет ещё большее значение для агентов, которые могут динамически формировать контекст на основе предыдущих действий, полученных материалов, результатов работы инструментов и промежуточных результатов.
Слой 8: большая языковая модель
В центре находится большая языковая модель, в которой происходит понимание языка, рассуждения, генерация текста и выполнение инструкций. Упоминаемые платформы и модели включают Azure, OpenAI, LLaMA и Mistral AI. Модель получает запрос вместе с тщательно подготовленным контекстом и инструкциями.
Есть принцип, который стоит повторить: LLM — это не вся приложение. Это лишь один компонент в гораздо более крупной системе, и для производственного приложения необходимы механизмы поиска информации, оркестрации действий, обеспечения безопасности, оценки результатов, мониторинга, инфраструктура и бизнес-логика. Это особенно заметно при переходе от прототипа к промышленному производственному решению.
От приложений на основе LLM к агентам
Полезно различать традиционные приложения на основе LLM и приложения с использованием агентов. В простом приложении последовательность действий: пользователь → запрос → LLM → ответ. В приложении типа RAG: пользователь → поиск информации → контекст → LLM → ответ. Система с агентами гораздо более динамична: пользователь → агент → планирование → поиск информации → инструменты → LLM → оценка → дальнейшие действия → окончательный ответ. Агент сам решает, что делать дальше, а не просто следует зафиксированной последовательности действий.
Предположим, кто-то спрашивает, почему вчера сбилась производственная инфраструктура и что с этим делать. Агент может извлечь историю выполнения, изучить журналы, выполнить запросы к базам данных, проанализировать сообщения об ошибках, ознакомиться с правилами эксплуатации, определить вероятную причину проблемы и, возможно, порекомендовать или применить одобренное решение. Это принципиально отличается от написания простого абзаца текста.
Уровень 9: инфраструктура и развертывание
Готовый прототип ещё не делает продукт готовым к использованию в производстве. Для запуска требуется масштабируемая инфраструктура, сетевое обеспечение, меры безопасности, автоматизация развертывания, управление ресурсами и способность к восстановлению. Архитектура включает Azure Container Apps, Azure Kubernetes Service, Docker и Kubernetes.
Docker упаковывает приложения в портативные контейнеры. Kubernetes координирует работу контейнеризированных задач в распределенных средах. Azure Kubernetes Service — это управляемая версия Kubernetes, а Azure Container Apps упрощает развертывание контейнеров, избавляя от необходимости управления всей средой Kubernetes.
Этот уровень имеет большое значение, когда системе необходимо справляться с высокой нагрузкой от пользователей, множеством одновременных рабочих процессов, нагрузкой на инференс моделей, фоновой обработкой, пайплайнами ввода документов, долгосрочными задачами, интеграцией с внешними инструментами и требованиями к корпоративной безопасности. Модель может быть отличной, но именно инфраструктура определяет, сможет ли ее потенциал быть реализован надежно в масштабах.
Уровень 10: наблюдаемость и оценка
Возможность наблюдения является одной из наиболее игнорируемых составляющих в инженерии ИИ. Традиционные приложения можно отслеживать с помощью показателей использования процессора, объема памяти, задержек, ошибок и частоты запросов. Приложениям ИИ требуется гораздо больше информации. Командам необходимо видеть, что получил модель, что было извлечено, какие инструменты использовались, какие решения были приняты, сколько времени занимал каждый шаг, количество токенов и помог ли окончательный ответ.
Здесь на сцену выходят Azure AI Foundry, OpenTelemetry и Grafana. OpenTelemetry собирает телеметрические данные из распределенных приложений, а Grafana визуализирует метрики операционного и прикладного уровней.
Оценка представляет собой еще один важный аспект. В производственных системах могут требоваться оценки по таким критериям, как релевантность, обоснованность, вероятность галлюцинаций, качество поиска, задержки, стоимость, безопасность и удовлетворенность пользователя. Агенты повышают стандарты, поскольку их действия также нуждаются в оценке наряду с окончательным ответом:
- Выбрал ли он правильный инструмент?
- Была ли получена правильная информация?
- Производились ли ненужные вызовы инструментов?
- Соблюдалась ли правильная процедура работы?
- Прекращалась ли работа по завершении задачи?
- Происходило ли соответствующее передачу задачи человеку при необходимости?
Эти вопросы делают возможность наблюдения и оценки неотъемлемой частью работы с ИИ в производственных условиях.
Почему важен весь комплекс компонентов
Существует распространённое заблуждение, согласно которому создание ИИ-приложения означает выбор мощной модели LLM и добавление пользовательского интерфейса. Это может сработать для демо-версии, но редко отражает реальные требования к корпоративной платформе ИИ.
Рассмотрим ситуацию, когда сотрудник обращается к ассистенту с вопросом о политике организации по решению определённой проблемы клиента. Система должна понять запрос, найти соответствующие документы с политиками, выделить из них релевантные разделы, передать их модели, сформировать обоснованный ответ, возможно, указав источник, соблюдать правила безопасности, отслеживать взаимодействие и оценить, был ли ответ полезным. Каждый слой играет свою роль: фронтенд обеспечивает взаимодействие, этап ввода данных предоставляет знания, предварительная обработка делает их пригодными для использования, эмбеддинги фиксируют смысл, векторные базы данных хранят поисковые представления, механизмы поиска находят контекст, инструменты формулировки вопросов структурируют информацию, большие языковые модели генерируют ответ, инфраструктура обеспечивает масштабируемость и надёжность, а инструменты наблюдаемости дают возможность контроля и отчётности. В этом смысле современный ИИ является полноценным решением «с нуля до конца».
Выбор инструментов
Технологии, описанные в этой архитектуре, не являются списком для полного внедрения. Каждая из них представляет собой один из вариантов для своего слоя. Компания может сначала выбрать React и Next.js, Azure AI Content Understanding для обработки документов, LangChain для координации процессов, хостинговую модель вжимания данных, Azure AI Search для поиска информации, модель, размещённую на платформе Azure, а также Azure Container Apps для её запуска. Другая компания может выбрать совершенно другой набор технологий.
Самый важный урок заключается в том, что архитектура существует раньше инструментов. Бизнес-требования формируют архитектуру, архитектура определяет функциональные возможности, необходимые каждому слою, и только после этого следует выбирать конкретные технологии.
Больше, чем просто LLM
Полный обзор архитектуры также объясняет, почему проекты с использованием агентов быстро становятся сложными. Агенту может потребоваться корпоративные знания через технологию RAG, структурированные данные из баз данных, внешняя информация через API, операционные возможности с помощью инструментов, а также выполнение рабочих процессов с использованием систем оркестрации. Ему также необходимы механизмы контроля: аутентификация и авторизация, меры защиты конфиденциальности данных, защита от внедрения вводимого текста, права доступа к инструментам, этапы человеческого утверждения, журналы аудита и системы оценки.
Таким образом, искусственный интеллект в роли агента находится на стыке нескольких дисциплин: инженерии программного обеспечения, инженерии данных, инженерии искусственного интеллекта, инженерии облачных технологий, безопасности и наблюдаемости. Создание агентов производственного уровня представляет собой инженерную задачу, а не просто упражнение в написании команд.
Как эволюционировала архитектура приложений
Индустрия прошла через несколько этапов развития. Первые приложения ИИ были ориентированы на модели. Затем технология RAG связала модели с внешними источниками знаний. Системы с дополнительными инструментами позволили моделям взаимодействовать с внешними ресурсами. Сейчас агентные системы ИИ объединяют модели, механизмы поиска информации, инструменты, память, функции планирования, оркестрации и оценки. Эволюция идет от простых больших языковых моделей к технологии RAG, затем к использованию инструментов, далее к агентам и многокомпонентным агентным системам; по мере развития все большее значение приобретает сопутствующая инфраструктура.
С чего начать
Не каждому приложению нужен весь набор технологий. Для простого инструмента для ответов на вопросы может хватить базовой нейросети большого размера. Если приложению требуется приватные данные или информация, которая часто меняется, следует использовать технологию RAG. Когда ключевую роль в решении задачи играют связи между объектами, стоит рассмотреть поиск на основе графов. Если системе необходимо планировать задачи, выбирать инструменты, выполнять несколько шагов и принимать решения в реальном времени, более подходящим решением становится агентное ИИ.
Целью не должна быть самая сложная архитектура — ею должна быть самая простая, которая надежно решает проблему.
Что дальше
Эта область продолжает развиваться. Графы знаний, векторные базы данных, фреймворки агентов, движки рабочих процессов, мультимодальные модели, инструменты оценки и облачные платформы, скорее всего, будут становиться более тесно связанными. Приложения будут принимать не только текст, но и изображения, аудио, видео, структурированные данные, корпоративные системы и реальные рабочие процессы. Наблюдение за системой и её оценка будут иметь такое же значение, как и выбор подходящей модели. В будущем речь будет идти не столько о более умных моделях, сколько о надежных системах, построенных на их основе.
Вывод
Агентные ИИ — это не одна технология, а целый набор компонентов. Начиная с фронтенда, через которого взаимодействуют пользователи, прохождение данных, их предварительную обработку, использование эмбеддингов и векторных баз данных, механизмы поиска и формулировки запросов, заканчивая большими языковыми моделями, их развертыванием и мониторингом — каждый слой влияет на уровень интеллектуальности, который в итоге демонстрирует система. Большая языковая модель — это лишь одна из составляющих. Для производственной агентной системы необходимы подходящие данные, стратегия поиска, механизмы оркестрации, инфраструктура и системы оценки. Способности моделей имеют меньшее значение, чем качество проектирования систем, окружающих их.
Связанные материалы
- Веб-фреймворк для стартапов в эпоху ИИ-агентов: Next.js, MUI и Firebase — Какие инструменты остаются эффективными, когда агенты пишут большую часть кода: Next.js, MUI, Firebase, Vercel, PostHog и минимальная настройка агента, с обоснованием выбора каждого из них.
- Что обнаруживает агент для сравнения моделей: изменения стиля затмевают незначительную настройку — Аудитор в формате «черного ящика» сравнил базовую модель с финансовым LoRA: в 82% случаев были обнаружены изменения длины и структуры, тогда как предполагаемые изменения в логике принятия решений остались незамеченными.