02. Архитектура системы

Версия 1.0 от 2026-10-02. Ключевая архитектурная развилка уже решена самим входным форматом: стерео с разделением каналов → спикеры известны физически, нейросетевая диаризация не нужна. Это дешевле, точнее и быстрее любых решений «диаризация + ASR» для моно-записей.

1. Общая схема

flowchart LR
    subgraph SRC["Контур заказчика"]
        A["АТС / система записи<br/>стерео-файлы + метаданные"]
    end

    subgraph ING["Слой приёма"]
        B["Ingest-адаптер<br/>REST / S3 / SFTP / вебхук"]
        C["Планировщик задач<br/>Redis Streams → Kafka*"]
        D["Оригиналы<br/>S3 / MinIO"]
    end

    subgraph PREP["Предобработка — CPU"]
        E["ffmpeg: разделение каналов,<br/>16 кГц моно, нормализация громкости"]
        F["VAD Silero + аудио-фичи:<br/>тишина, бипы, DTMF, музыка"]
    end

    subgraph ASR["Распознавание — GPU"]
        G["ASR-воркеры<br/>faster-whisper / WhisperX<br/>батчинг, int8_float16"]
    end

    subgraph POST["Постобработка"]
        H["Слияние каналов по таймкодам<br/>реплики клиент/оператор"]
        I["Метрики: talk ratio,<br/>перебивания, паузы"]
        J["Правила: стоп-слова, фразы скрипта,<br/>regex, нечёткий поиск"]
        K["LLM-классификатор<br/>vLLM + Qwen, JSON-schema"]
    end

    subgraph STORE["Хранение"]
        L[("S3/MinIO: аудио, транскрипты JSON")]
        M[("PostgreSQL: звонки, таксономия, пользователи")]
        N[("ClickHouse: метрики, сегменты, теги")]
    end

    subgraph BI["Аналитика и доступ"]
        O["Дашборды Superset"]
        P["Карточка звонка:<br/>плеер + транскрипт + теги"]
        Q["Экспорт и рассылка отчётов"]
        R["API для систем заказчика"]
    end

    S["Очередь ручного контроля<br/>human-in-the-loop"]
    T["Prometheus + Grafana<br/>алерты, SLA-мониторинг"]

    A --> B --> C
    B --> D
    C --> E --> F --> G --> H --> I
    H --> J --> K
    K -->|низкая уверенность| S
    I --> L & M & N
    K --> L & M & N
    N & M --> O & P & Q & R
    C & E & G & K -.телеметрия.-> T

\* Redis Streams достаточно до ~50 тыс. задач/час; миграция на Kafka — если объёмы/ретеншн очередей потребуют (решение зафиксируем после замеров в PoC).

2. Поток обработки одного звонка

1. Обнаружение. Ingest-адаптер по расписанию (каждые 1–5 мин) опрашивает API заказчика о новых

записях либо принимает вебхук. Задача (call_id, пути, метаданные) — в очередь с приоритетом live; бэклог-выгрузка кладётся в очередь backfill с низким приоритетом.

1. Предобработка (CPU, ffmpeg). Разделение каналов → ресемпл 16 кГц моно → нормализация громкости

(loudnorm) → VAD (Silero): выкидываем тишину, считаем долю речи по каналам, детектируем бипы/DTMF. Звонки, где второй канал пуст (типично для автоответчиков), распознаются только по «говорящему» каналу.

1. ASR (GPU). Каждый канал независимо, батчами (faster-whisper/CTranslate2, int8_float16).

Выравнивание до слов — forced alignment (WhisperX / wav2vec2). Пунктуация — из самой Whisper; для альтернативных моделей добавляется отдельная модель пунктуации.

1. Слияние. Сегменты двух каналов сортируются по start → единая хронология реплик с меткой

спикера. Пересечения сегментов = перебивания; паузы = промежутки без речи.

1. Классификация. Каскад: (а) детерминированные правила и аудио-фичи (доля речи по каналам,

длительность, наличие бипов/музыки, словари «оставьте сообщение», стоп-слова, фразы скрипта через нечёткий поиск); (б) LLM со строгой JSON-схемой — финальные метки: тип соединения, результат, соблюдение скрипта, конфликтность, теги; (в) низкая уверенность → очередь ручного контроля.

1. Индексация. Транскрипт — S3 (JSON + текст), метаданные и вердикты — PostgreSQL, метрики и

сегменты — ClickHouse. Звонок виден в дашбордах и карточке.

1. Идемпотентность. Все стадии пишет результат по ключу call_id + stage; повторный запуск

стадии не создаёт дубликатов; перезапуск возможен с любой стадии (ASR не повторяется при смене таксономии — только классификация, FR-41).

3. Компоненты и стек

4. Режимы работы

• Live: новые звонки, приоритетная очередь. SLA ≤ 24 ч с огромным запасом (ожидаемое E2E — минуты).

При пиковом поступлении воркеры backfill временно переключаются на live.

• Backfill: 450 тыс. часов, низкий приоритет, пакетами; устойчивость к прерываниям и перезапускам

(чекпоинт по call_id). Прогресс и ETA бэклога — отдельный дашборд.

• Переклассификация: при изменении таксономии/промптов — повторный прогон стадии классификации

по транскриптам из S3 без ASR (дёшево; SLA переклассификации всего архива — часы, не дни).

5. Безопасность

• Всё внутри контура РФ; TLS на всех передачах; шифрование СХД (опция); оригиналы не размножаются —

кэш с TTL, основное хранение транскриптов.

• Маскирование номеров телефонов/сумм в транскриптах — флаг обработки (анкета E2); de-маскирование

только через RBAC.

• Доступ к карточкам/выгрузкам — по ролям; аудит выгрузок; водяные знаки в PDF-отчётах (опция).
• Развертываемо on-prem у заказчика без изменений архитектуры (k8s/docker-compose).

6. Развёртывание

• Docker Compose для PoC; Kubernetes (или Nomad) для прода.
• GPU-ноды: ASR-воркеры по количеству карт (по 1 процессу на GPU, батчинг внутри), LLM — vLLM

с отдельными картами.

• CPU-ноды: ingest, предобработка, слияние, правила, индексация.
• СУБД и S3 — на CPU-нодах/СХД с бэкапами; стенд 1:1 воспроизводится IaC (ansible/terraform).

7. Риски и как они закрыты