Как мы заменили устаревший бот-движок на масштабируемую систему на базе GPT и кастомной логики маршрутизации запросов
Медицинский центр обратился к нам с задачей полной переработки и модернизации цифрового ассистента, который был реализован на устаревшем бот-конструкторе с жёстко заданными сценариями (ветвление по кнопкам, без понимания естественного языка).
Существующее решение обладало рядом критических ограничений:
Отсутствие NLU (Natural Language Understanding) — система не понимала свободный текст, требовала точных команд.
Ограниченный масштаб логики: сложные сценарии с условиями, перебором симптомов и исключениями были невозможны без ручной прошивки.
Отсутствие динамической маршрутизации на основе медицинских данных (врачи, специализация, приёмы).
Невозможность интеграции с внутренними API (EMR, расписание, SMS/email).
Отсутствие механизмов логирования, аналитики, fallback-перехода к оператору.
Разработать многофункционального AI-ассистента нового поколения, способного:
Обрабатывать свободные текстовые обращения пациентов (на естественном языке);
Проводить предварительную фильтрацию по симптоматике и классифицировать обращение;
Маршрутизировать пациента к соответствующему врачу;
Выполнять реальную запись на приём через API;
Работать в нескольких каналах (веб-виджет, Telegram);
Поддерживать масштабируемую архитектуру для будущих модулей (страховые кейсы, чат с врачом, интеграции с внешними LLM).
Node.js (NestJS) — основной фреймворк для реализации логики, управления диалогами и API-интеграций.
TypeScript — для строгой типизации и масштабируемой архитектуры.
PostgreSQL — хранилище медицинской базы симптомов, врачей, расписаний и связей.
Redis — управление сессиями диалога, кеширование запросов к расписанию и внешним источникам.
OpenAI GPT-4 API — NLU-ядро, используемое для анализа симптомов и генерации уточняющих вопросов (в рамках строго заданного контролируемого окна).
Vue.js + TailwindCSS — адаптивный виджет на сайт.
Telegram Bot API — нативный интерфейс с логикой, синхронизированной с backend-ядром.
EMR/CRM API — запись на приём, проверка доступности специалистов.
SMS-шлюз (SMS.ru) и SMTP — уведомления, подтверждения, напоминания.
Fallback-интеграция с администратором через webhook-переадресацию в CRM.
NLU-обработка текста:
Входящее сообщение пациента передаётся в обработчик gptSymptomInterpreter(), который возвращает JSON-структуру: symptom_category, confidence_score, recommended_specialist.
При недостаточной уверенности запускается цепочка уточняющих вопросов с auto-prompting.
Сопоставление специалиста:
Используется symptom-to-specialist-mapper, связанный с БД врачей, графиками и специализациями. Маршрутизация возможна по множеству правил (включая перекрёстные специализации и возрастные исключения).
Проверка доступности и запись:
Через API осуществляется проверка доступных слотов. Сессия блокирует слот на 5 минут до подтверждения.
При подтверждении — запись и отправка уведомлений в два канала.
Fallback и переход к оператору:
При любом сбое маршрутизации (ошибки API, непонимание, отказ пользователя) — soft-fallback в виде передачи контакта оператору через webhook.
Разработка проекта заняла 9 недель с момента утверждения технического задания до запуска в прод. На этапе Discovery был проведён аудит текущих систем и построена архитектура нового решения.
Работы включали:
проектирование бизнес-логики,
интеграции с EMR,
разработку backend-ядра,
кастомный GPT-модуль,
UI-виджет,
Telegram-бот,
систему уведомлений,
тестирование и развёртывание.
Итоговая стоимость проекта составила 1,2 млн ₽, включая сопровождение MVP в течение первого месяца. Возможности масштабирования (добавление voice-бота, мультиклиники, интеграции со страховыми API) изначально заложены в архитектуру и могут быть реализованы на следующем этапе без полной переработки ядра.
До 80% всех первичных обращений стали обрабатываться автоматически без участия администратора.
Время записи пациента сократилось с в среднем 6–10 минут до менее чем 2 минут.
Повышена конверсия с лендинга клиники: +38% записей через виджет.
Существенное снижение нагрузки на операторов в часы пик: до –65% входящих звонков.
Упрощена аналитика по обращениям и симптоматике — теперь данные можно агрегировать и использовать для принятия решений.
Разработка интеллектуального помощника для медицинского центра — это не просто чат-бот, а интеграция логики triage, автоматизации записи и AI-обработки обращений в единую цифровую систему. В данном кейсе мы показали, как при помощи GPT-архитектуры и модульной back-end логики можно превзойти ограничения старых ботов и построить устойчивое решение, готовое к масштабированию и будущим интеграциям.
