Как подключить LLM к SMPP для обработки входящих SMS

LLM можно подключить к SMPP как отдельный слой обработки: шлюз принимает входящее MO-сообщение, передаёт его в приложение, а модель определяет намерение клиента и формирует черновик ответа. Затем бизнес-логика проверяет результат и отправляет SMS через SMPP. В статье разберём архитектуру, формат обмена, защиту от ошибочных ответов, обработку статусов доставки и порядок запуска такого сценария для малого бизнеса в Беларуси.

Как связать входящее SMS, LLM и SMPP-шлюз?

SMPP отвечает за транспорт сообщений между приложением и SMS-центром. Нейросеть не подключают к SMPP напрямую: между ними нужен небольшой сервис-посредник. Он принимает MO-сообщение от шлюза, передаёт текст в LLM и после проверки отправляет ответ как MT-сообщение.

Типовая схема выглядит так:

1. Клиент отправляет SMS на номер компании.
2. SMPP-шлюз передаёт приложению PDU с MO-сообщением.
3. Приложение извлекает номер отправителя, текст, идентификатор сообщения и время получения.
4. Маршрутизатор выбирает сценарий: заявка, вопрос, отмена записи или неизвестная команда.
5. LLM получает только необходимый контекст и предлагает классификацию либо текст ответа.
6. Правила приложения проверяют результат.
7. Шлюз отправляет ответ клиенту через submit_sm.
8. Система сохраняет технический результат и связывает его с исходным сообщением.

Для приёма SMS пригодится отдельная настройка MO-трафика. В SMPP это обычно означает корректный bind, обработку deliver_sm и разбор полей source_addr, destination_addr, short_message или message_payload. Практический разбор такого сценария есть в материале как принимать ответы на SMS через SMPP.

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

Какие данные передавать языковой модели?

Запрос к модели стоит собирать из коротких частей: текст входящего SMS, название сценария, допустимые действия и формат результата. Например, для магазина можно задать категории «статус заказа», «изменить время доставки», «отменить заявку» и «непонятный запрос». В ответ приложение получает структурированный результат, а не свободный текст.

Пример формата ответа LLM:

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

Если сообщение короткое и неоднозначное, приложение может ответить уточняющим вопросом. Например: «Напишите 1, чтобы узнать статус заказа, или 2, чтобы отменить заявку». Такой сценарий легче тестировать, чем длинный ответ, созданный моделью с нуля.

Как настроить обработку MO-сообщений в приложении?

Сначала определите формат события, которое шлюз передаёт приложению. В нём нужны технические поля: идентификатор сообщения, адрес отправителя, адрес получателя, текст, кодировка и время приёма. Если шлюз передаёт длинные SMS частями, приложение должно собрать их до передачи в LLM.

Затем добавьте очередь входящих событий. Она отделяет приём SMS от обращения к модели и от отправки ответа. Если LLM временно не отвечает, SMPP-соединение продолжает принимать сообщения, а очередь повторяет обработку по заданному правилу.

Для каждого сообщения полезно хранить отдельный технический статус:

• received — шлюз принял MO-сообщение;
• queued — событие поставлено в очередь;
• classified — модель определила сценарий;
• approved — ответ прошёл правила приложения;
• submitted — запрос на отправку передан в SMPP;
• delivered или failed — получен финальный статус доставки.

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

После submit_sm не следует считать SMS доставленной. SMPP возвращает подтверждение приёма запроса шлюзом, а окончательный результат приходит через delivery receipt. Для диагностики недоставленных сообщений полезно разобрать DLR и коды ошибок по инструкции о том, почему SMS не доходит до клиента в SMPP.

Какие правила ограничивают ответы LLM?

Перед отправкой ответа приложение проверяет длину, язык, запрещённые конструкции и наличие обязательного шаблона. Если модель вернула пустой текст, лишние инструкции или неизвестный reply_key, сообщение не отправляется. Вместо него система выбирает нейтральный шаблон или передаёт обращение сотруднику.

Набор правил можно оформить так:

• отправлять ответ только при известном intent;
• использовать только зарегистрированные шаблоны;
• ограничить число ответов на одно входящее сообщение;
• не повторять отправку без проверки submit_sm_resp;
• отдельно обрабатывать STOP, HELP и другие служебные команды;
• переводить диалог оператору после нескольких неудачных классификаций.

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

Для заявок удобно разделить автоматические и ручные ответы. Модель распознаёт сообщение «нужен замер в субботу», создаёт карточку обращения и отправляет короткое подтверждение: «Заявка принята. Сотрудник уточнит время». Детали сотрудник обрабатывает в рабочем интерфейсе, а SMPP используется для обмена короткими уведомлениями.

Как тестировать связку LLM и SMPP до запуска?

Тестирование нужно проводить по слоям. Сначала проверяется сам SMPP-канал: bind, приём deliver_sm, submit_sm и delivery receipt. Затем тестируется очередь. После этого подключается модель, чтобы ошибка в LLM не маскировалась под проблему доставки SMS.

Для проверки берите реальные типы фраз, но не ограничивайтесь идеальными примерами. Добавьте опечатки, сокращения, смешение русского и белорусского языков, повторные SMS и сообщения без понятного вопроса. Отдельно проверьте, что ответ не превышает допустимый размер SMS и корректно учитывает кодировку.

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

Типичные ошибки при подключении LLM к SMPP

• Модель подключают прямо к SMPP без очереди и получают потерю событий при временном сбое.
• Приложение считает submit_sm_resp подтверждением доставки клиенту и не анализирует DLR.
• В запрос к LLM передают весь диалог, хотя для классификации достаточно последнего сообщения и короткого контекста.
• Свободный ответ модели отправляют без проверки длины, кодировки и допустимых шаблонов.
• Не обрабатывают составные SMS и получают обрезанный текст.
• Не связывают MO, MT и DLR по идентификаторам, поэтому сотрудник не может восстановить историю заявки.

Если текущая система уже отправляет SMS через HTTP API, переход на SMPP лучше планировать отдельно от подключения LLM. Сначала проверьте приём, отправку и статусы в новом канале, а затем добавьте классификацию входящих сообщений. Такой порядок описан в материале как перейти с HTTP API на SMPP без потери SMS.