Архитектура AI SaaS-продуктов на LLM: паттерны, которые работают

Эта статья — об архитектурных паттернах AI SaaS-платформы. Если ваш вопрос — путь от демо до продукта (оценка первой, модель стоимости, guardrails, слой данных), этот путь описан в статье «Как превратить AI-прототип в production SaaS».

У SaaS-продукта строгие ожидания: предсказуемая задержка, изоляция данных по тенантам, контролируемая стоимость, тестируемое поведение. LLM-фичи нарушают каждое из них по умолчанию: генерация медленная, недетерминированная, тарифицируется по токенам и плохо тестируется.

Большинство провалов AI SaaS — это не провалы моделей. Это провалы архитектуры: промпт-логика вперемешку с UI-кодом, отсутствие изоляции тенантов, нет кэша, нет потолков стоимости и нет quality gate между изменением промпта и пользователями.

В AI SaaS промпт — это пользовательский код. Ему нужны версионирование, оценка и откат — ровно как любому другому коду.

Ядро цикла здорового AI SaaS:

• Каждое изменение промпта и модели проходит набор оценки до релиза — та же дисциплина, что unit-тесты для обычного кода.
• Production-трафик семплируется и скорится, а сбои возвращаются в набор оценки.
• Качество и стоимость отслеживаются по фиче, по тарифному плану и по тенанту, а не по вызову.
• При дрейфе качества восстанавливается последняя стабильная версия промпта — откат это первоклассная операция.

Команды, которые пропускают этот цикл, выпускают фичи, работающие на демо и деградирующие в продакшене — медленно и незаметно.

• Интерфейсный слой — веб-приложение (Next.js), где пользователи настраивают, запускают и проверяют AI-работу; стриминг ответов держит UI отзывчивым.
• Слой оркестрации — AI-логика: пайплайны для предсказуемых потоков, агенты, когда воркфлоу ветвится; у обоих типизированные входы и выходы.
• Retrieval-слой — RAG-пайплайны обосновывают ответы данными конкретного тенанта; поиск скоупится тенантом, поэтому один пайплайн безопасно обслуживает многих клиентов.
• Слой данных — PostgreSQL для состояния, логов и векторов; изоляция тенантов enforced на уровне базы, а не по договоренности.
• Слой исполнения — фоновые джобы с очередями и ретраями для длинных генераций; API возвращает состояние джобы, а не блокирующий ответ.
• Слой стоимости и контроля — маршрутизация моделей, кэширование, токен-бюджеты и лимиты на тенанта и тарифный план.
• Observability-слой — каждый LLM-вызов логируется с моделью, токенами, задержкой, стоимостью и оценкой качества; алерты на дрейф.

• Пайплайн vs агенты — начинайте с детерминированных пайплайнов; добавляйте агентов только когда воркфлоу действительно ветвится. Агенты гибче и значительно сложнее в оценке.
• Маршрутизация моделей — OpenRouter или аналоги позволяют менять провайдеров под задачу и тариф; провайдер никогда не хардкодится в бизнес-логику.
• Стриминг vs пакет — стриминг для интерактивных фич, фоновые джобы для тяжелого анализа; один и тот же промпт обслуживает оба режима разными интерфейсами.
• Одна база — PostgreSQL с pgvector держит состояние, логи и векторы вместе: меньше компонентов, проще бэкапы, легче изоляция тенантов.
• Версионирование промптов — промпты хранятся как код с версиями, выходят через evaluation gate и откатываются как любой деплой.

Наши собственные продукты работают на этой архитектуре:

• LeadForge AI — мультиагентный пайплайн за SaaS-интерфейсом: типизированный вывод агентов, состояние в PostgreSQL, векторный retrieval для контекста аутрича, review-воркфлоу в UI и логирование каждого шага агента.
• SEOFlow AI — пользовательские джобы (воркфлоу, отчеты) исполняются как фоновые пайплайны с типизированным выводом и аналитикой, а не блокирующие одиночные промпты.
• LaunchFlow AI — вертикальный AI SaaS для fashion-брендов на маркетплейсах, организованный вокруг бизнес-воркфлоу, а не чата, с AI, встроенным в операционный поток.

Паттерн консистентен: модель — взаимозаменяемый компонент, а продукт — это оркестрация, данные и review-loop вокруг нее.

Полный паттерн — слои оркестрации, retrieval, фоновые джобы, observability — правильная форма для платформы. Для MVP или внутреннего инструмента он избыточен, и цена реальна: каждый слой добавляет стоимость поддержки и оценки.

• Single-feature MVP — один узкий поток, без тенантов: один эндпоинт, одна модель, стриминг. Очереди, кэш и лимиты тарифов — когда появится трафик.
• Внутренний инструмент на 5-20 пользователей — достаточно auth, базового логирования и quality gate; изоляция тенантов и биллинг подождут.
• Эксперимент или proof of concept — валидируйте поведение AI, а не платформу. Инвестируйте в оценку, а не в инфраструктуру.

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