Архитектура корпоративной GenAI-платформы: проектирование до выбора технологий
Создание корпоративной генеративной платформы часто начинает со спешного выбора стека: LangChain, векторные базы данных или Kubernetes. Однако по-настоящему надежная архитектура рождается из анализа требований, границ безопасности и нефункциональных характеристик до того, как будет написана первая строчка кода.
# Не начинать со стека: как спроектировать корпоративную GenAI-платформу до реализации
В мире разработки искусственного интеллекта существует искушение начать проект с выбора конкретных инструментов. Выбор между LangChain и LlamaIndex, Kafka или RabbitMQ, локальными или облачными моделями часто становится первым шагом обсуждения. Но для корпоративной среды, где вопросы безопасности и соответствия регламентам стоят во главе угла, этот подход является критической ошибкой.
До того как обсуждать технологии, необходимо зафиксировать условия эксплуатации. Цель платформы, права пользователей, требования к доступности и аудит должны стать фундаментом архитектуры. Только после определения «где» и «как» система должна работать, появляется смысл выбирать «на чем» она будет работать.
От требований к нефункциональным характеристикам
Главная ошибка проектов — путать требование с архитектурным решением. Фраза «система должна переживать отказ компонента» — это требование. Выбор Kubernetes с тремя репликами и балансировщиком нагрузки — это лишь один из способов удовлетворить это требование.
Проектирование начинается с фиксации нефункциональных требований (NFR). В контексте корпоративной платформы к ним относятся: - Доступность и надежность: время восстановления после сбоев (RTO) и допустимая потеря данных (RPO). - Производительность: задержка ответов (latency) в режиме реального времени и при массовых запросах. - Безопасность: строгая авторизация до передачи данных в модель, аудит всех действий. - Масштабируемость: прогнозируемая нагрузка на пользователей и объем хранимых документов.
Фиксация этих параметров позволяет определить границы применимости технологий. Например, требование высокой доступности не обязывает включать Kubernetes в первую версию (MVP). Горизонтальное масштабирование может быть заложено в планировании, но реализация автомасштабирования откладывается до появления реальной нагрузки.
Контекст и границы ответственности (C4)
При описании архитектуры на высоком уровне (уровень C4 Context) следует отвлечься от конкретных языков программирования и баз данных. Важнее понять, кто взаимодействует с платформой и какие внешние системы находятся за её границами.
Разделение на внутренние и внешние компоненты основывается на жизненном цикле и ответственности, а не на физическом расположении. Если внешняя система идентификации (Identity Provider) управляется другой командой, даже если она размещена в одном дата-центре, для платформы она остается внешней сущностью. Это упрощает моделирование потоков данных и точек контроля.
На уровне контейнеров (C4 Container) определяется реальный стек технологий. Типичная конфигурация может включать веб-приложение (React/TypeScript), бэкенд на .NET для бизнес-логики и корпоративных задач, а также Python-оркестратор для обработки AI/ML процессов. Важно разделять только там, где есть техническая причина: отличная модель нагрузки, специфика среды выполнения или разные требования к ресурсам.
Выбор инструментов: PostgreSQL и RabbitMQ
Одним из самых частых вопросов является выбор векторной базы данных. Использование специализированных движков вроде Qdrant или Weaviate кажется естественным выбором для RAG (Retrieval-Augmented Generation). Однако интеграция второй базы данных требует решения сложных проблем синхронизации метаданных, ACL (контроля доступа) и обеспечения консистентности данных.
Если на этапе старта нет измеримых ограничений производительности, которые не покрывает PostgreSQL + pgvector, вводить отдельный хранилище смысла нет. Этот подход позволяет хранить метаданные и векторы в единой системе, сохраняя простоту управления и упрощая проверку прав доступа до отправки контекста в языковую модель.
Аналогичная логика применима к выбору мессенджеров. Kafka часто рассматривается как «стандарт индустрии» для всех задач обработки событий. Однако для начального этапа платформы, где требуется простая очередь задач с повторами и подтверждением доставки, Kafka избыточна. RabbitMQ предоставляет необходимый функционал без избыточной инфраструктуры. Переход на потоковую обработку событий и хранение истории воспроизведения (replay) становится оправданным только при появлении соответствующих требований.
Безопасность и границы доверия
В корпоративной среде архитектура должна явно определять границы доверия. Браузер клиента — не доверенная среда, поэтому авторизация всегда происходит на стороне бэкенда. Но особенно важно понимать, что возвращаемые LLM данные и найденный контекст также не являются полностью доверенными.
Контент, извлеченный из документов, может содержать инструкции атаки (prompt injection). Следовательно, система должна фильтровать и проверять данные на клиенте. Кроме того, генеративная модель может предложить выполнить действие, но окончательное разрешение на его выполнение должен давать серверный компонент, контролирующий безопасность.
Для централизованного управления подключениями к провайдерам LLM используется отдельный шлюз (Gateway). Даже при использовании одного провайдера в MVP этот компонент абстрагирует логику работы с SDK, таймауты, учет токенов и политики фильтрации данных. Это позволяет в будущем легко масштабировать систему за счет добавления маршрутизации и резервных провайдеров без переписывания логики оркестратора.
Документирование решений (ADR)
С течением времени архитектура может устареть, если решения принимались интуитивно. Ключевым инструментом сохранения знаний является ведение записей архитектурных решений (ADR). Каждый значимый выбор — от стека технологий до взаимодействия сервисов — должен быть задокументирован с указанием контекста, рассмотренных альтернатив и ожидаемых последствий.
Такой подход позволяет в будущем пересматривать решения осознанно. Если требования к производительности pgvector больше не удовлетворяются, команда поймет, что это изменение условий, а не ошибка первоначального планирования.
От планирования к MVP
Проектирование не означает бесконечную разработку. Важно четко различать целевую архитектуру (Target Architecture) и архитектуру минимально жизнеспособного продукта (MVP). MVP должен быть достаточно функциональным, чтобы продемонстрировать ценность и проверить ключевые гипотезы, но не должен включать все планируемые на будущее возможности, такие как агенты, локальные модели на GPU или сложное масштабирование.
Определение готовности MVP должно опираться на сценарии поведения системы, а не на наличие определенных технологий. Система считается готовой, если пользователь получает правильный ответ с источниками, если неавторизованный пользователь не может получить доступ к документам через векторный поиск и если система корректно обрабатывает ошибки.
Итог
Успешная разработка GenAI-платформы начинается не с выбора фреймворков, а с глубокого понимания бизнес-процессов и ограничений. Чистый подход к архитектуре, основанный на требованиях и поэтапной реализации, позволяет создавать масштабируемые и безопасные системы, которые эволюционируют вместе с потребностями компании.