Это вторая статья из серии о построении корпоративной платформы генеративного ИИ (GenAI). В первой части мы обсудили, зачем вообще нужен архитектурный подход при внедрении GenAI-решений и как правильная архитектура помогает пройти путь от идеи до бизнес-ценности. Теперь перейдем к самой архитектуре платформы.
Общая архитектура решения
Любое серьезное GenAI-решение в корпоративной среде строится многоуровневым. Общая архитектура платформы включает несколько слоев, каждый из которых отвечает за свою функцию и взаимодействует с остальными. Сверху находятся пользовательские приложения и интерфейсы, через которые сотрудники или клиенты взаимодействуют с ИИ (чат-боты, виртуальные ассистенты, интеграции в существующие системы). Далее слой интеграции, обеспечивающий связь этих приложений с ядром платформы через понятные API и протоколы.
После этого следует ядро GenAI-платформы, состоящее из двух основных частей: шлюз генеративной модели (назовем его LLM Gateway) и механизм извлечения знаний. LLM Gateway управляет всеми запросами к языковой модели: принимает вопросы, обогащает их контекстом, отправляет модели и получает от нее ответы. Механизм Retrieval отвечает за поиск и предоставление актуальных данных из корпоративных источников знаний, чтобы дополнить ответы модели фактами (паттерн Retrieval-Augmented Generation, RAG). Наконец, внизу архитектуры расположен инфраструктурно-сервисный слой, включающий вычислительные ресурсы (GPU-сервера, облачные сервисы) и общие сервисы платформы (оркестрация, хранение данных, мониторинг и др.). Все эти слои вместе образуют целостную систему: от пользователя на верхнем уровне до «железа» в дата-центре снизу.
Поток запроса и компоненты
Рассмотрим, как поток запроса проходит через компоненты. Представим, пользователь задает вопрос корпоративному чат-боту. Что происходит «под капотом»?
Пользовательское приложение/интерфейс получает ввод от пользователя (например, текст вопроса). Интерфейс может быть любым: веб-чат, мессенджер, голосовой помощник, — но он не содержит логики ответа, а лишь передает запрос дальше.
Слой интеграции принимает этот запрос от приложения. Здесь могут выполняться первоначальные технические задачи: проверка аутентификации пользователя, валидация формата запроса, маршрутизация к нужному сервису платформы. Этот слой служит своеобразным входным API для всех запросов к GenAI-платформе.
Шлюз LLM (генеративной модели) получает пользовательский запрос через интеграционный слой. Шлюз решает, как обработать запрос: нужно ли добавить контекст, какую модель вызвать, требуется ли дополнительная обработка. Перед обращением к модели шлюз может обратиться к слою Retrieval, если вопрос требует данных из корпоративной базы знаний. Например, для запроса «В чем заключаются последние изменения в политике отпусков?» шлюз инициирует поиск релевантных документов (политика отпусков) через Retrieval.
Слой Retrieval выполняет поиск по внутренним данным компании. Он может работать через векторную базу данных, полнотекстовый поиск или их комбинацию. На этом этапе извлекаются фрагменты документов, которые наиболее соответствуют запросу, и передаются обратно в шлюз LLM.
Вызов модели (LLM). Шлюз формирует финальный промпт для модели, сочетая исходный вопрос пользователя и найденный контекст (если он был получен из Retrieval). Затем происходит обращение к выбранной языковой модели (локальной или внешней). Модель генерирует ответ на основе промпта.
Обработка ответа и возвращение пользователю. Ответ модели возвращается в шлюз LLM, который может применить постобработку, например, модерацию контента, форматирование под нужный вид или добавление ссылок на источники. После этого ответ через интеграционный слой отправляется обратно в пользовательское приложение, где отображается спрашивавшему.
Таким образом, запрос последовательно проходит через несколько компонентов, каждый из которых добавляет ценность: интерфейс — удобство ввода, интеграция — маршрутизацию, шлюз — «интеллектуальную» обработку, Retrieval — фактические данные, модель — генерацию текста, а инфраструктура обеспечивает быстроту и надежность всех этих шагов.
Шлюзы: единая точка входа и контроля
Отдельного внимания заслуживают шлюзы в архитектуре — специальные компоненты, через которые проходят все обращения к модели и данным. В нашей платформе их два, каждый со своей задачей.
Шлюз LLM (модельный шлюз) — центральный узел, отвечающий за взаимодействие с языковыми моделями.
Он нужен для решения нескольких задач. Во-первых, для унификации доступа к разным моделям. Сегодня у вас может быть подключен OpenAI GPT-4, завтра — своя внутренняя модель на базе LLaMA или модель от другого вендора. Шлюз абстрагирует эти различия: внешние приложения шлют запросы не напрямую модели, а в шлюз, а уж он решает, к какой конкретно модели обратиться.
Во-вторых, шлюз позволяет встроить guardrails — ограничения и фильтры. Например, можно перед каждым запросом проводить проверку на недопустимый контент или на слишком большой объем входных данных, а после получения ответа — вычищать потенциально конфиденциальную информацию или нежелательные высказывания.
В-третьих, через шлюз реализуется логирование и мониторинг запросов. С архитектурной точки зрения, LLM-шлюз — обязательный компонент, поскольку он дает контроль над потенциально непредсказуемой моделью: можно настроить таймауты, повторные попытки (retries) при ошибках, кеширование частых запросов для экономии токенов и т. д.
Шлюз данных (Data Gateway) — второй важный компонент. Его роль — стандартизировать доступ модели к корпоративным данным. Вместо того, чтобы модель или шлюз LLM напрямую ходили в каждую базу знаний, вводится прослойка, которая знает, где и как найти нужную информацию. Data Gateway может обращаться к разным хранилищам: внутренней базе документов, системе электронного архива, базам данных, поисковым движкам, векторным базам для эмбеддингов и т. д. Архитектор закладывает этот компонент, чтобы изолировать логику поиска данных от остальной части системы. Представьте, если изменится источник данных (скажем, компания мигрирует с одной СЭД на другую), достаточно поправить модуль шлюза данных, не трогая модельный шлюз и приложения. Кроме того, через Data Gateway проще внедрить политику безопасности и контроля доступа: он проверяет права пользователя на запрашиваемые данные, фильтрует результаты поиска по уровням доступа и гарантирует, что модель получит только ту информацию, которую можно использовать.
В итоге связка из LLM Gateway и Data Gateway образует сердцевину интеллектуальной части платформы — первый отвечает за генерацию текста, второй - за подкрепление этого текста знаниями.
Приложения и слой интеграции
Самый верхний уровень — это приложения и интеграционный слой. Здесь архитектура встречается с конечными пользователями и существующими бизнес-системами. Зачем выносить этот уровень отдельно? Дело в том, что у корпоративной GenAI-платформы обычно много точек использования: от чат-бота в портале сотрудника до встроенной подсказки в CRM-системе или голосового помощника на телефоне руководителя. Вместо того, чтобы каждому такому приложению напрямую вшивать логику работы с моделью, мы строим единый интеграционный слой — набор API, SDK и коннекторов, — через которые все приложения взаимодействуют с платформой.
Например, для веб-чат-бота это может быть REST API запросов: приложение передает вопрос и получает ответ. Для внутренней базы знаний — плагин, который дергает платформу при поиске ответа для клиента. Для RPA-скриптов — возможно, готовый SDK или шина данных, куда они посылают запросы.
Интеграционный слой обеспечивает единообразие: все используют одни и те же интерфейсы обращения к GenAI-сервисам. Это снижает порог подключения новых случаев использования — архитектура заранее готова интегрироваться куда угодно, будь то Slack, корпоративный портал или мобильное приложение. С точки зрения архитектора, этот слой критичен для масштабируемости применения платформы: бизнес-подразделения могут независимо создавать новые интерфейсы и продукты, зная, что «под капотом» всегда есть стандартизированный доступ к возможностям GenAI.
Кроме того, интеграционный слой часто включает адаптеры к устаревшим системам (если нужно тянуть данные или контекст из старых ИТ-систем) и слой презентации, отвечающий за форматирование ответа под конкретный канал (например, разметка для чата, отчет в PDF или голосовая озвучка).
Слой Retrieval: обогащение модели знаниями
Отдельно стоит слой Retrieval — компонент, отвечающий за поиск и извлечение знаний для модели. В первой части мы отмечали, что без подключения к данным большие языковые модели подобны энциклопедии без интернета. Retrieval решает эту проблему, подключая модель к актуальной информации компании.
Рассмотрим, как это работает в общих чертах. Обычно платформа индексирует корпоративные данные: документы, базы знаний, wiki, тикеты службы поддержки и пр. — через создание эмбеддингов (векторное представление текста) или через полнотекстовый индекс. Когда приходит вопрос пользователя, перед вызовом модели происходит поиск по этим индексам, чтобы найти релевантные кусочки текста. Затем они вставляются в промпт модели (RAG). С архитектурной точки зрения, мы выделяем retrieval-слой, чтобы отделить работу с данными от работы с генерацией текста. Это дает гибкость: можно улучшать алгоритмы поиска или менять хранилища (например, внедрить новую векторную БД) независимо от остальных частей системы.
Более того, retrieval-слой позволяет решать разные задачи помимо простого поиска: например, агрегация данных из разных источников, ранжирование найденных фрагментов по значимости, кеширование часто запрашиваемых фактов и даже обогащение запросов (query expansion) альтернативными формулировками.
В этой статье мы не будем глубоко погружаться в устройство retrieval — это тема отдельной (третьей) части. Здесь важно понимать, что retrieval-слой — ключевой элемент корпоративной GenAI-архитектуры, который обеспечивает достоверность и актуальность ответов. Без него платформа либо ограничена знанием модели из обучающих данных, либо требует трудоемкого дообучения модели на внутренних данных. Поэтому почти во всех сценариях GenAI для бизнеса retrieval присутствует как обязательная часть системы.
Инфраструктурный и сервисный слой
Нижний уровень архитектуры — инфраструктура и сервисы, то, на чем все вышележащие компоненты работают. Часто об этом слое вспоминают в последнюю очередь, но у архитекторов он продуман с самого начала, потому что определяет, насколько надежной и производительной будет платформа.
Инфраструктурный слой включает оборудование и облачные ресурсы, необходимые для работы GenAI. В первую очередь это, конечно, GPU-сервера или облачные GPU-инстансы — языковые модели требуют серьезных вычислительных мощностей. Архитектура должна предусматривать, будет ли платформа использовать локальный GPU-кластер, развернутый в корпоративном дата-центре, или ресурсы облачного провайдера (AWS, Azure, GCP) по запросу. Возможно, сочетание (гибридный вариант): чувствительные данные обрабатываются на своих серверах, а пиковые нагрузки покрываются облаком.
Масштабируемость как ключевое требование: нам нужно уметь добавлять мощности по мере роста числа пользователей и сложности запросов. Здесь на помощь приходят технологии оркестрации (Docker/Kubernetes для контейнеров с модельными сервисами), балансировщики нагрузки между несколькими экземплярами модели, очереди для выравнивания наплыва запросов.
Сервисный слой дополняет инфраструктуру и обеспечивает общие функциональные возможности платформы. Сюда можно отнести, например, сервис мониторинга и логирования. Он собирает телеметрию: сколько запросов, какие задержки, сколько токенов потрачено, сколько успешных/неуспешных ответов. Эти данные критически важны, чтобы поддерживать SLA работы платформы и оптимизировать затраты (например, заметить, что какая-то команда гоняет тысячами бесполезные запросы, и вовремя их обучить или ограничить).
Другой компонент сервисного слоя — управление моделями и версиями. В корпоративной среде вы не будете бесконтрольно обновлять модель; вместо этого архитектура предусматривает репозиторий моделей или настройку CI/CD, где новые версии модели или новые промпт-шаблоны проходят тестирование перед деплоем в прод. Похожим образом управляются и данные для retrieval: обновление индексов, добавление новых источников через ETL-процессы — все это часть сервисного уровня.
Наконец, нельзя забывать про безопасность на уровне инфраструктуры: шифрование хранилищ, разграничение доступа к данным, audit trail (след действий) для критичных операций. Архитектура включает эти невидимые, но значимые сервисы, чтобы платформа соответствовала корпоративным требованиям надежности, безопасности и compliance.
Связность компонентов: как архитектура решает задачи и снижает риски
Мы рассмотрели основные блоки системы, теперь взглянем на архитектуру как на единое целое. Все связи между слоями спроектированы так, чтобы платформа справлялась с типовыми задачами GenAI и нивелировала риски внедрения.
Связность и взаимодействие. Каждый слой четко знает свою роль и общается с соседними через понятные интерфейсы. Благодаря этому достигается слабая связанность компонентов: приложения не зависят от внутреннего устройства LLM или retrieval, а модельный слой не зависит от конкретной базы данных. Такая модульность позволяет дорабатывать или менять отдельные части без остановки всей платформы. Например, можно заменить модель (перейти с одной LLM на другую): достаточно внести изменения в LLM Gateway, для приложений же ничего не изменится. Или добавить новый источник данных — настраиваем его в Data Gateway, не трогая остальное. Это снижает риски технологической неустойчивости: платформа переживет смену технологий, сохранив общую структуру.
Решаемые задачи и риски. Архитектура изначально отвечает на ряд проблем, с которыми сталкиваются проекты GenAI:
Неуправляемость модели. Большие модели — мощные, но непредсказуемые. Шлюз LLM с контролями и логированием решает эту проблему: мы всегда знаем, что модель получила на вход и что сгенерировала на выходе, можем пресечь нежелательные ответы (например, матерную лексику или утечку конфиденциальных данных) и измерять качество работы.
Галлюцинации и недостоверность. Встроенный retrieval-слой снижает риск галлюцинаций, предоставляя модели факты и свежие данные. Вместо того, чтобы полагаться лишь на «память» модели, платформа проверяет себя: ответ обоснован информацией из проверенных источников. Это критично в бизнес-сценариях, где цена ошибки очень велика.
Разрозненность решений. Без архитектурного подхода разные команды могли бы делать свои локальные GenAI-проекты, которые не умеют говорить друг с другом. Наша же платформа предлагает единый «центр генеративного ИИ» в компании. Это решает задачу дублирования: нет необходимости строить десятки отдельных ботов — можно подключить все к одной системе. Кроме того, такой подход облегчает поддержку и развитие: команда платформы развивает общие возможности (модели, данные, интерфейсы), которыми пользуются все проекты.
Масштаб и производительность. Архитектура предусматривает масштабируемую инфраструктуру, что снижает риск падения сервиса при росте нагрузки. А за счет раздельного масштабирования слоев можно оптимизировать ресурсы: например, при наплыве сложных вопросов масштабировать отдельно слой модели (добавив GPU), а если растет объем данных — масштабировать хранилище для retrieval. Это эффективно и экономично, что в итоге влияет на ROI платформы.
Безопасность и соответствие регуляторке. Централизованные шлюзы и сервисный слой позволяют внедрять политику безопасности единообразно. Все запросы проходят через контролируемые точки, где можно анонимизировать персональные данные перед отправкой в модель, или, наоборот, убедиться, что пользователь имеет право видеть сгенерированный ответ. Логирование на каждом шаге дает материал для аудита: кто что спрашивал, какие данные выдавались. Это важно для отраслей с жесткими требованиями (финансы, медицина), и архитектура учитывает эти риски с самого начала.
Таким образом, предложенная архитектура не только объединяет технические компоненты, но и решает организационные и бизнес-вызовы: от поддержания качества ответов до управляемости и экономической эффективности GenAI-инициативы.
Вариативность архитектуры: что обязательно, а что настраивается под бизнес
Несмотря на то что мы описали «референсную» архитектуру GenAI-платформы, в реальных проектах она не высечена в камне. Важная задача архитектора — понять, какие элементы должны быть неизменными, а какие подлежат адаптации под контекст бизнеса.
Обязательные элементы практически всегда включаются в платформу:
LLM-шлюз с контролем и унификацией доступа к моделям — без него корпоративное решение быстро превратится в непонятный комбайн из разрозненных вызовов ИИ без общего управления.
Модель(и) генеративного ИИ — сердце платформы. Будь то GPT-4, Llama 2 или специализированная модель для кодогенерации — без самой модели смысл платформы теряется.
Механизм Retrieval (поисковый модуль) — как правило, обязателен, если платформа должна работать с внутренними данными и давать достоверные ответы. Есть узкие случаи, где можно обойтись без него (например, генерирование текста с нуля без фактической опоры), но в большинстве бизнес-приложений retrieval присутствует.
Интеграционный слой — необходим, чтобы платформа действительно стала корпоративным решением, а не осталась технодемо. Без продуманного API и точек подключения остальные системы компании попросту не смогут широко использовать возможности GenAI.
Адаптируемые элементы зависят от потребностей и ограничений конкретной организации:
Выбор моделей и провайдеров: архитектура позволяет подменять модельные движки. Одни компании пойдут в облако, другие выберут open-source LLM on-premise из-за требований безопасности. Каркас платформы остается тем же, меняется «начинка» LLM Gateway — и это спроектировано заранее.
Реализация retrieval: в зависимости от данных можно использовать разные технологии. Где-то хватит и полнотекстового поиска по БД знаний, а где-то нужен сложный векторный поиск по embeddings с гибридным ранжированием. Важно, что для внешних потребителей (LLM-шлюза) интерфейс retrieval единый, а реализацию можно настроить под масштаб и тип данных бизнеса.
Инфраструктура: одни предприятия развернут платформу целиком у себя, в закрытом контуре. Другие — в облаке, чтобы не покупать железо. Третьи выберут гибрид. Архитектура это учитывает: например, компонент Data Gateway может быть тонким слоем поверх существующей корпоративной шины данных, а LLM Gateway — оберткой над внешним API в облаке. Главное, что логика разделения на компоненты сохраняется, просто где физически они выполняются — на своих серверах или у провайдера — вариативно.
Дополнительные сервисы: например, fine-tuning моделей под свою специфику или ML-пайплайны для подготовки данных. В базовой архитектуре их может не быть (если ставка сделана на zero-shot и RAG), но при необходимости их легко встроить. Платформа может обрести модуль тонкой донастройки модели или тренировочный конвейер — архитектура позволит добавить его бок о бок с существующими слоями.
Идея в том, что архитектура задает принципы и каркас, а наполнение конкретными технологиями и параметрами — дело конкретного проекта. Это похоже на план здания: несущие стены и этажность определены, а планировку внутренних комнат можно менять под нужды жильцов. Для нас несущие стены — это выделенные уровни платформы (интерфейсы, шлюзы, модель, данные, инфраструктура), а вот планировка (какие именно инструменты использовать и как именно их комбинировать) решается гибко. Такой баланс обязательного и настраиваемого обеспечивает, с одной стороны, надежность проверенных паттернов, с другой — адаптацию под бизнес-задачи, чтобы платформа не была чем-то чужеродным, а органично вписалась в ландшафт компании.
Что дальше
В этой статье мы разобрали архитектуру корпоративной GenAI-платформы: из каких слоев она состоит, как данные и запросы текут внутри, какую роль играют шлюзы и почему все это важно для успеха проекта. Надеюсь, у вас сложилась целостная картина скелета платформы.
В следующей, третьей части мы углубимся в один из самых важных элементов — retrieval-слой. Поговорим подробно, как платформа добывает знания из данных: какие бывают подходы, инструменты и подводные камни при реализации Retrieval-Augmented Generation в энтерпрайзе. Это позволит еще лучше понять, как связать мир данных и мир больших языковых моделей на благо вашего бизнеса.
Автор: Денис Прилепский — специалист по архитектуре ИТ-систем и трансформации ИТ-ландшафта, приглашенный эксперт онлайн-магистратур Центра «Пуск» МФТИ.