Перейти к содержанию

00. Обзор платформы

1. Цели

Создать мультитенантную оркестрационную платформу, которая позволяет бизнесу:

  1. Создавать ИИ-агентов под ключ под свою нишу — быстро, из коробки, «в пару кликов».
  2. Кастомизировать агента без кода — через вынесенные за пределы кода конфиги (персона, база знаний, инструменты, бизнес-правила, каналы, интеграции).
  3. Внедрять агента куда угодно — на сайт, портал, в приложение — через API, WebSocket, встраиваемый виджет или вебхуки.
  4. Автоматизировать первичную обработку лида — агент перехватывает лид, квалифицирует, ведёт диалог в удобном канале, назначает целевое действие (показ) и передаёт менеджеру.

Первая прорабатываемая вертикаль — строительные компании, но платформа проектируется как vertical-agnostic: агента можно собрать под любую отрасль.

2. Скоуп (границы проекта)

Входит в скоуп: - Ядро платформы: Control Plane (управление) и Data Plane (рантайм). - Мультитенантность с изоляцией данных. - Агент-как-конфиг + библиотека шаблонов (blueprints). - Оркестрация диалога, ярусная система LLM, инференс на GPU + облачный фолбэк. - RAG (база знаний под тенанта). - Сервис интеграций (CRM и любые внешние системы) и сервис каналов (мессенджеры, email, телефония, web-виджет). - Назначение показа (scheduling) и «голевая передача» менеджеру. - Аналитика/метрики, безопасность, 152-ФЗ. - Расчёт инфраструктуры и стоимости (РФ, 2026).

Вне скоупа (на этом этапе): - Дообучение/fine-tuning собственных моделей (используем готовый Qwen на инференс). - Готовые мобильные приложения для конечных клиентов бизнеса. - Юридические шаблоны договоров с клиентами платформы.

3. Глоссарий

Термин Значение
Оркестрационная платформа Единое мультитенантное приложение на наших серверах: клиенты по подписке создают и запускают ИИ-агентов, а платформа оркеструет диалоги, модели, каналы и интеграции.
Multi-tenant Одна инсталляция обслуживает много клиентов с изоляцией данных.
Tenant (тенант) Один бизнес-клиент платформы как логическая единица (агенты, данные, настройки, биллинг).
Control Plane Плоскость управления: админка, конструктор агентов, биллинг, квоты. Не участвует в живых диалогах.
Data Plane Плоскость рантайма: ведёт диалоги в реальном времени (каналы, оркестрация, инференс, интеграции).
Инференс Получение ответа от уже обученной модели (её «работа в бою»), в отличие от обучения.
LLM Большая языковая модель (у нас — Qwen).
Model tiering Каскад из нескольких моделей разного размера под задачи разной сложности.
RAG Retrieval-Augmented Generation: ответ модели с опорой на найденные в базе знаний документы.
Bounded context Ограниченная смысловая область домена; по ним проводятся границы микросервисов.
Сага Цепочка локальных транзакций с компенсациями вместо распределённой транзакции.
IaC Infrastructure as Code: инфраструктура описана кодом (Terraform), а не настраивается руками.
Observability Наблюдаемость: логи + метрики + распределённая трассировка.
HA High Availability: работа системы при отказе отдельных компонентов.
Guardrails Ограничители поведения модели (запрет тем, фактов «из головы», критичных обещаний).
Blueprint Шаблон агента под вертикаль, преднастраивающий конфиг.
Голевая передача Передача квалифицированного лида с назначенным показом от агента живому менеджеру.

4. Сценарий 2.2 — первичная обработка лида («голевая передача»)

Как есть (проблема): лид с сайта падает в воронку продаж, его подхватывает менеджер вручную — с задержкой, неравномерно, теряя часть лидов.

Как будет (с платформой): входящий лид перехватывает ИИ-агент, мгновенно вступает в диалог, квалифицирует, ведёт клиента в удобном канале и назначает показ, затем передаёт менеджеру с полным контекстом.

sequenceDiagram
    participant L as Лид (сайт)
    participant W as Виджет / API
    participant A as Агент (оркестратор)
    participant K as База знаний (RAG)
    participant S as Планировщик показа
    participant C as CRM (через интеграции)
    participant M as Менеджер

    L->>W: Оставляет заявку / пишет сообщение
    W->>A: Новый лид + контекст
    A->>A: Квалификация (бюджет, район, сроки, потребность)
    A->>K: Уточнение по объектам/ценам
    K-->>A: Факты из базы знаний
    A->>L: Диалог в удобном канале (WhatsApp/Telegram/...)
    A->>S: Подбор слота и назначение показа
    S-->>A: Слот подтверждён
    A->>C: Создание сделки + запись показа + передача контекста
    C-->>M: Уведомление: горячий лид + назначенный показ
    A->>L: Напоминание о показе, продолжение коммуникации
    Note over A,M: Эскалация на менеджера в любой момент по правилам

Результат работы агента: назначенный показ + сделка в CRM с полной историей диалога; далее агент продолжает коммуникацию (напоминания, ответы на вопросы) до/после показа.

5. Ключевые архитектурные решения (сводка)

6. Допущения

  • Пример вертикали — стройка, но платформа отраслевно-нейтральна.
  • «Показ» = целевое конверсионное действие вертикали (для стройки — просмотр объекта); в других нишах заменяется своим целевым действием (запись на приём, замер, консультация).
  • Интеграции с CRM и каналы — через абстрактные сервисы; конкретные системы подключаются плагинами.
  • Цены на инфраструктуру — ориентир на июль 2026, рынок РФ, с оговоркой о волатильности (см. 06-infrastructure-cost-ru-2026.md).
  • LLM используем на инференс (готовый Qwen), собственное обучение моделей не ведём.

7. Риски

Риск Суть Митигация
Ответственность агента Неверная цена/срок/обещание от лица бизнеса Guardrails, ответы только из базы знаний, подтверждение критичных заявлений
Недооценка не-GPU затрат TCO шире, чем GPU (команда, каналы, HA, observability) Полный расчёт TCO в 06
Сложность enterprise-first Микросервисы дороги и медленны на старте Осознанный выбор; строгие контракты, IaC, шаблоны сервисов
«Платформа для всех» Распыление фокуса между вертикалями Глубоко проработать стройку, универсальность — архитектурно
Актуальность данных Устаревшие цены/наличие в базе знаний Синхронизация базы знаний с каталогом/CRM, TTL и переиндексация
Согласие на коммуникацию Outbound в мессенджеры/звонки без согласия Consent-management, юридическое основание перед outbound
Стоимость GPU на старте Self-host дорог до подтверждения спроса Развилка managed vs self-host с точкой окупаемости

8. Открытые вопросы (развилки)

  1. Managed LLM vs self-hosted GPU на пилоте — решение: старт на облачном Qwen API (plus/flash, max в фолбэк) с маскированием ПДн; LLM-слой провайдер-агностичный (перенос на GigaChat/YandexGPT/self-host конфигом за ~час). Self-host включаем по требованиям 152-ФЗ / контроля, а не по цене (Qwen дёшев до ~3-5 тыс. лидов/день). Открытым остаётся платёжный контур для оплаты Alibaba Cloud из РФ (см. 05, §8, 06, §4).
  2. Модель монетизации — за агента / за диалог / за лид / за назначенный показ? Влияет на то, что оптимизировать в стоимости.
  3. Глубина автономности агента — где граница между «агент сам назначает показ» и «обязательное подтверждение менеджером».
  4. Голос/телефония на старте — включать real-time STT+TTS в MVP или добавить позже (отдельная инженерная сложность).