Архитектура

Real-time decisioning архитектура: как оператор принимает решение за 200ms

NBA, retention-trigger, fraud-block — каждое решение требует быстрого профиля, политик, моделей и audit trail. Архитектура слоя real-time decisioning.

Обсудить задачу

Что такое real-time decisioning слой

Когда клиент пополнил счёт, открыл приложение, набрал номер службы поддержки — оператор имеет окно в 1-3 секунды, чтобы принять контекстное решение: показать какой offer, направить в какую очередь, заблокировать ли транзакцию, отправить ли push.

Real-time decisioning — слой, который принимает это решение. На входе: trigger event + контекст клиента. На выходе: решение + audit trail.

Без отдельного слоя решения растягиваются по системам: что-то в campaign tool, что-то в IVR, что-то в app, что-то в fraud engine. Несогласованность гарантирована.

Из чего состоит

Trigger ingress. Каналы и source-системы шлют события через event bus. Decisioning подписан на events своего scope.

Context fetch. Lookup профиля из CDP, проверка текущего состояния (балланс, последняя транзакция, активный case), обогащение features для модели.

Policy engine. Декларативные правила (rules), которые работают первыми: regulatory blocks, customer preferences (do-not-contact), business policies (нельзя предлагать кредит просроченному клиенту).

Model serving. ML-модели (churn risk, propensity, fraud score) дают вероятностную оценку. Подаются в decision как features.

Decision logic. Комбинация policies + model scores + business rules выдаёт решение. Многоруковые bandit могут выбирать между вариантами.

Audit trail. Каждое решение логируется с входными data, моделью, версией политик, выходом. Без этого нет ни governance, ни продуктовой итерации.

Где обычно ломается

Latency budget не определён. Команда строит «общий decisioning», который потом не успевает за SLA каналов (IVR требует <300ms, app <500ms). Выливается в работу заново.

Policies спрятаны в коде. Чтобы изменить «не предлагать tariff X клиентам с долгом» нужно делать релиз. Бизнес теряет агility, decisioning превращается в bottleneck.

Модели не обновляются. Churn model, обученная год назад, продолжает работать на сегодняшних данных. Точность падает, никто не замечает.

Audit неполный. При расследовании инцидента (почему clienту был отправлен offer, который он не должен был получить) команда не может восстановить логику.

A/B testing невозможен. Decisioning отдает один ответ, нет варианта сравнить альтернативу. Продукт не учится.

Latency budget

Типичный budget на decisioning: 100-300ms end-to-end, включая context fetch и audit. Из этого:

20-50ms — trigger ingress + queue
30-80ms — context fetch (профиль из CDP, recent state)
20-60ms — model serving
10-30ms — policy + decision logic
10-30ms — response + async audit

Если real budget не считается, latency расползается, каналы начинают timeout-ить.

Operating model

Owner — Head of Decisioning или Customer Experience platform lead. Близко к маркетингу, но с инжиниринговой строгостью.

Команды:

Platform engineering (latency, availability, deployment)
Decision science (модели, эксперименты)
Policy management (бизнес-правила, regulatory)
Channel integration (контракты с consumers)

Routine — еженедельный обзор decisions: какие сработали, где политики conflict, какие модели нуждаются в retraining.

Как SamaraliSoft подключается

Decisioning Blueprint — 6-8 недель. Map текущих decisions по каналам, latency budget, дизайн policy/model layer, governance, choice between build/buy для decisioning engine, pilot scope (обычно 1-2 канала).