Дата: 13 февраля 2026 | Версия: Stage 8 — Production Readiness
SmartSupport Platform — event-driven платформа для управления бизнес-процессами, инициируемыми входящими событиями (обращения граждан, инциденты, запросы), с управляемым искусственным интеллектом и обязательным контролем оператора (Human-in-the-Loop).
Ключевая идея: Платформа не «отвечает на сообщения» — она оркестрирует бизнес-процессы. Входящее событие (обращение, инцидент, запрос) маршрутизируется к соответствующему процессу через граф решений. Процесс определяет, какие AI-capabilities задействовать, какие решения принять, когда привлечь оператора и куда эскалировать. Процессы описываются декларативно (JSON), управляются политиками и не требуют изменения кода для модификации.
Применимость: техническая поддержка, государственные услуги, incident management, обработка жалоб, SLA-контроль — любой домен, где входящие события запускают формализованные процессы принятия решений.
LLM-провайдер: GigaChat (российский, совместимый с требованиями локализации данных).
| Слой | Технология | Назначение |
|---|---|---|
| Backend API | Node.js 20 + Express + TypeScript | REST API + WebSocket |
| AI Workers | Python 3.11 + Celery | Классификация, генерация ответов, оценка качества |
| Frontend | React + TypeScript (4 приложения) | UI для пользователей, операторов, администраторов, база знаний |
| БД | PostgreSQL 16 | Хранение данных, партиционирование, миграции |
| Кэш | Redis 7 | Кэширование, состояние circuit breaker |
| Очереди | RabbitMQ 3.13 | Асинхронная обработка, Dead-Letter Queues |
| Мониторинг | Prometheus + Grafana | Метрики, дашборды, алертинг |
| CI/CD | GitLab CI | Автоматическая сборка, тесты, деплой |
| Контейнеризация | Docker Compose | 13 сервисов, 3 изолированные сети |
~85 000
~385
280 backend + 18 workers + 87 frontend482
73
~155
1400
107 тестовых файловЯдро платформы — оркестрация бизнес-процессов через граф решений. Каждое входящее событие проходит через цепочку узлов принятия решений:
Сырое событие → D1: Приём + AI-анализ → D2: Маршрутизация к процессу → D3: Выполнение capabilities → D4: Оценка → D5: HITL → Исход
| Узел | Назначение | Кто решает | Роль AI |
|---|---|---|---|
| D1 | Приём и регистрация события | Система (детерминированно) | Не участвует |
| D2 | Классификация и маршрутизация | Оркестратор (policy gates + правила) | Предоставляет сигнал классификации |
| D3 | Обработка: поиск, генерация, контекстуализация | Оркестратор (координирует capabilities) | Предоставляет анализ и черновики |
| D4 | Оценка качества | Оркестратор (policy + пороги) | Предоставляет оценку качества |
| D5 | Контроль оператора: подтверждение, корректировка, override или эскалация | Оператор (HITL) | Не участвует |
Во всех узлах решает оркестратор (детерминированный код) или человек — никогда AI. AI используется как вспомогательный инструмент интерпретации и анализа.
Процессы описываются в JSON и управляются без изменения кода:
on_track → at_risk → breachedИнтеграции с внешними системами через декларативные intents: Jira, ServiceNow, webhook, CRM
Полная изоляция клиентов, Platform Admin видит только агрегированные метрики без доступа к данным клиента
Управление автономностью AI через политики, динамическое изменение правил без передеплоя
Активная база знаний с версионированием, семантическим поиском, автоматическим обнаружением пробелов
| Приложение | Назначение |
|---|---|
| User App | Создание и отслеживание обращений, многоканальность |
| Operator App | HITL-очередь, обработка обращений, обратная связь по AI |
| Admin App | Управление процессами, политиками, canary-деплойменты |
| Knowledge App | Управление базой знаний, аналитика пробелов |
| Landing | Публичная страница платформы |
| Этап | Описание | Статус |
|---|---|---|
| Stage 0–5 | Базовая платформа, обращения, HITL, AI оркестрация | ✓ Завершён |
| Stage 6 | Multi-tenancy и Control Plane | ✓ Завершён |
| Stage 7 | Техническое совершенствование | ✓ Завершён |
| Stage-AI | Controlled AI контур, operator feedback loop | ✓ Завершён |
| Stage 8, Phase 1 | Полный аудит проекта (8 направлений) | ✓ Завершён |
| Stage 8, Phase 1.5 | Устранение недостатков аудита | ⟳ Активная (16/30 задач) |
| Направление | Оценка до | Текущая оценка | Цель |
|---|---|---|---|
| Безопасность | 6.5/10 | ~8.5/10 | ≥ 9/10 |
| Архитектура | 7/10 | ~8/10 | ≥ 8/10 |
| БД и схема | 7/10 | ~8.5/10 | ≥ 9/10 |
| Инфраструктура | 6.5/10 | ~8.5/10 | ≥ 9/10 |
| API контракты | 4/10 | ~6/10 | ≥ 8/10 |
| Производительность | 6/10 | ~7/10 | ≥ 8/10 |
| Тестовое покрытие | 5/10 | ~5.5/10 | ≥ 7/10 |
| Качество кода | 6/10 | ~6.5/10 | ≥ 8/10 |
| Общая | 5.8/10 | ~7.3/10 | ≥ 8.5/10 |
| Категория | Было | Закрыто | Осталось |
|---|---|---|---|
| CRITICAL | 9 | 7 | 2 |
| HIGH | 15 | 13 | 2 |
| Итого | 24 | 20 | 4 |
| Волна | Задачи | Трудозатраты | Статус |
|---|---|---|---|
| Wave 1: Security Hotfixes | F01–F06 | 23ч | ✓ Завершена |
| Wave 2: Database Fixes | F07–F09 | 10ч | ✓ Завершена |
| Wave 3: Infrastructure | F10–F13 | 12ч | ✓ Завершена |
| Wave 4: API Quality | F14–F15 | 15ч | ✓ Завершена |
| Wave 5–10: Остальные | F16–F30 | ~115ч | Запланированы |
Выполнено: 60ч из ~175ч запланированных (34% трудозатрат, 53% задач).
| Фаза | Описание | Трудозатраты | Статус |
|---|---|---|---|
| Phase 1.5 | Исправление всех багов аудита | ~115ч осталось | ⟳ Активная |
| Phase 2 | Наполнение тестовыми данными | 6–8ч | Запланирована |
| Phase 3 | Подключение и тестирование GigaChat | 4–6ч | Запланирована |
| Phase 4 | E2E тесты (Playwright, 12 сценариев) | 10–15ч | Запланирована |
| Phase 5 | Дополнительные unit/integration тесты | 8–12ч | Запланирована |
| Phase 6 | Production конфигурация и runbooks | 4–6ч | Запланирована |
Оценка до production-ready: ~150–160 часов (~4 недели при полной загрузке).
97.2%
141/145100%
13/131400
122 suites73
50+
16