# 3. Архитектура диалоговых систем

Диалоговые системы предоставляют пользователям интерфейс естественного языка к бизнес-функциям компании. В отличие от классических API они должны поддерживать состояние диалога, учитывать контекст и обрабатывать неоднозначные формулировки. Архитектура таких систем строится вокруг связки из распознавания намерений, управления диалогом и интеграции с бэкендами.

## Общая архитектурная схема

На логическом уровне диалоговую систему можно представить как цепочку компонентов.

1. **Клиентские каналы**. Веб-интерфейс, мобильное приложение, мессенджеры, голосовые интерфейсы. Они отвечают за захват пользовательского ввода (текст или голос) и отображение ответов.
2. **Шлюз и маршрутизатор**. Концентрирует входящие сообщения, нормализует формат, аутентифицирует пользователей, привязывает запросы к сессиям диалога.
3. **Диалоговый движок**. Ядро системы, которое управляет состоянием диалога, вызывает компоненты распознавания намерений и генерации ответов, принимает решения о переходах между шагами сценариев.
4. **Интеграционный слой**. Обеспечивает доступ к доменным микросервисам, базам данных, платёжным системам, CRM и другим системам предприятия.

Физическая реализация может варьироваться: от монолитного сервиса до набора специализированных микросервисов, однако логические роли компонентов остаются теми же.

## Распознавание намерений и сущностей

Компонент распознавания намерений (intent recognition) преобразует свободный пользовательский ввод в структуру, пригодную для дальнейшей обработки.

- **Намерение** отражает цель пользователя (например, «узнать баланс», «сменить тариф»).
- **Сущности** (entities) представляют собой конкретизированные параметры намерения (сумма, дата, идентификатор продукта).

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

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

## Управление диалогом

Управление диалогом (dialog management) отвечает за то, как система реагирует на текущий ввод пользователя с учётом истории взаимодействия.

Ключевые обязанности этого компонента:

- хранение состояния диалога (этап сценария, заполненные слоты, контекстные параметры);
- выбор следующего шага сценария на основе намерения, сущностей и бизнес-правил;
- разрешение неоднозначностей (уточняющие вопросы, подтверждения);
- поддержка нелинейных сценариев (смена темы, возврат к предыдущему шагу).

Архитектурно управление диалогом может базироваться на явных сценариях (графы состояний, деревья решений) или на обучаемых политиках. В обоих случаях важно отделять описание бизнес-логики от инфраструктурного кода, чтобы доменные эксперты могли влиять на сценарии без вмешательства в низкоуровневую реализацию.

## Генерация ответов

Даже при наличии распознанных намерений и устойчивого управления диалогом критическим остаётся вопрос того, что именно система скажет пользователю.

Подходы к генерации ответов можно условно разделить на:

- **Шаблонные ответы**. Жёстко заданные фразы с подстановкой переменных (имя клиента, сумма, дата). Обеспечивают полный контроль формулировок и просты для аудита.
- **Сценарные реплики**. Для сложных диалогов может использоваться библиотека заранее подготовленных реплик, сгруппированных по сценариям и состояниям.
- **Генеративные компоненты**. Используют обученные модели для построения вариативных фраз с учётом контекста. В архитектуре они обычно обёрнуты дополнительными фильтрами и ограничителями.

Важное архитектурное требование — возможность трассировать, из каких данных и правил сформирован конкретный ответ, особенно в регуляторно значимых сценариях.

## Интеграция с бэкенд-системами

Диалоговая система редко является самоцелью: она выступает фасадом к существующим бизнес-сервисам.

Интеграционный слой должен:

- обеспечивать унифицированный интерфейс к доменным сервисам независимо от канала общения;
- инкапсулировать протоколы и форматы, специфичные для внутренних систем;
- реализовывать кросс-функциональные требования (аутентификация, авторизация, аудит, лимитирование запросов).

Часто диалоговый движок не обращается напрямую к доменным сервисам, а использует промежуточный слой оркестрации бизнес-процессов. Это позволяет переиспользовать сценарии в нефронтовых каналах и точнее управлять транзакционными границами.

## Нефункциональные требования и эксплуатация

Для диалоговых систем особенно важны следующие нефункциональные аспекты.

- **Масштабируемость**. Нагрузка зависит от сезонности и событийных пиков (маркетинговые кампании, инциденты). Архитектура должна поддерживать горизонтальное масштабирование как диалогового движка, так и ML-компонентов.
- **Надёжность и деградация**. При недоступности моделей или отдельных интеграций система должна переходить в режим деградированной функциональности: упрощённые сценарии, хардкоженные ответы, переключение на оператора.
- **Наблюдаемость**. Необходимо собирать логи диалогов, агрегировать метрики (успешность сценариев, время до решения, эскалации), поддерживать инструменты анализа качества диалогов для продуктовых команд.

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