Проблема: 87% пациентов не могут дозвониться, а операторы устали от рутины
Clarus Care – сеть клиник в Калифорнии. К февралю 2026 года они столкнулись с классической, но критической проблемой: их кол-центр задыхался. Пиковые часы (утро после праздников, сезон гриппа) превращались в кошмар. Пациенты ждали на линии по 20-25 минут. Операторы, перегруженные простыми запросами вроде «Перенесите мой прием» или «Какие анализы нужны?», выгорали за полгода. Текучесть кадров достигла 40%.
Но главное – страдало качество обслуживания. Человек в стрессе, ждущий полчаса, чтобы спросить про время работы лаборатории, – это гарантированная негативная оценка в соцсетях и потеря лояльности. Автоматизировать нужно было не для красоты, а чтобы выжить. При этом в медицине – особые требования: конфиденциальность (HIPAA), точность информации, эмпатия в общении. Обычный IVR-автоответчик («Нажмите 1 для…») тут не катит. Пациенты его ненавидят.
Ключевой вызов: Нужен был не просто скриптовый бот, а интеллектуальный агент, понимающий естественную речь, контекст разговора и способный безопасно работать с медицинскими данными. И все это – без построения своей ML-команды с нуля.
Решение: Amazon Bedrock как фабрика для медицинского голосового агента
Clarus Care выбрали AWS и, в частности, Amazon Bedrock. Почему? Не потому что это модно. По трем практическим причинам.
- Готовая инфраструктура под HIPAA. Bedrock, как часть AWS, уже имеет compliance-сертификаты для здравоохранения. Не нужно отдельно сертифицировать хранение и обработку данных – все уже сделано.
- Выбор моделей, а не привязка к одной. Bedrock – это шведский стол из LLM. Можно тестировать Claude 3.5 Sonnet, GPT-4o, Command R+ и выбирать лучшую для конкретной задачи без миграции всего пайплайна.
- Интеграция в экосистему AWS. Голосовой бот – это не только модель. Это прием звонка (Amazon Connect), преобразование речи в текст (Transcribe), синтез речи (Polly), оркестрация логики (Lambda), хранение истории (DynamoDB). В AWS все эти сервисы «склеиваются» за часы, а не недели.
Их цель: бот, который обрабатывает 70% рутинных запросов первого уровня. Перенос/отмена записи, справки о часах работы, инструкции перед анализами, статус страхового возмещения. Сложные или эмоциональные случаи – плавный переход к живому оператору с полной историей диалога.
Архитектура: что скрывается за «приветственным голосом»
Вот как выглядит система в разрезе. Запоминайте, это шаблон для десятка подобных кейсов.
| Компонент AWS | Роль в системе Clarus Care | Ключевая настройка |
|---|---|---|
| Amazon Connect | Виртуальная АТС. Принимает звонок, управляет потоком вызова. | Настроен контакт-флоу, который при входящем звонке триггерит AWS Lambda. |
| AWS Lambda (Python) | «Мозг» оркестрации. Координирует все шаги: STT → LLM → TTS. | Использует Boto3 для вызовов Bedrock, Transcribe, Polly. Хранит сессию в DynamoDB. |
| Amazon Transcribe | Преобразует речь пациента в текст (Real-time или Call Analytics). | Включена идентификация говорящего (Speaker Diarization), чтобы отделить речь бота от пациента. |
| Amazon Bedrock | Ядро интеллекта. Модель обрабатывает запрос, определяет интент, генерирует ответ. | Используется Claude 3.5 Sonnet (на 02.02.2026 – самая сбалансированная по цена/качество для диалога). Промпт-инжиниринг с системным промптом на 1500 токенов. |
| Amazon Polly | Преобразует текстовый ответ от LLM в естественную речь. | Выбран голос «Joanna» (Neural). Настроены SSML-теги для пауз, ударений в медицинских терминах. |
| Amazon DynamoDB | Хранит полную историю диалога: аудио, текст, метаданные, интенты. | TTL установлен на 7 лет (требование хранения медицинских записей). Все данные шифруются на стороне AWS (KMS). |
| AWS KMS + IAM | Безопасность. Шифрование данных в покое и транзите, fine-grained доступ к Bedrock. | Настроены IAM-роли с минимальными привилегиями. Bedrock настроен на блокировку нежелательного контента (Guardrails). |
Поток данных выглядит так: Звонок → Connect → Lambda запускает Transcribe (real-time) → Текст отправляется в Bedrock → Bedrock возвращает ответ и метаданные (интент, уверенность) → Lambda форматирует ответ, отправляет в Polly → Polly возвращает аудио → Connect проигрывает его пациенту. Все это – за 1.5-2 секунды.
1Секрет промпт-инжиниринга: не диалог, а структурированный workflow
Самая частая ошибка при создании таких ботов – дать LLM свободу. «Ты – дружелюбный помощник, отвечай на вопросы». В медицине это приведет к катастрофе. Бот начнет импровизировать с диагнозами или давать противоречивые инструкции.
Clarus Care пошли другим путем. Их системный промпт в Bedrock – это жесткий сценарий с четкими правилами.
- Идентификация интента в первую очередь. Промпт заставляет модель классифицировать запрос по списку из 12 предопределенных интентов (reschedule_appointment, lab_hours, pre_test_instructions, billing_inquiry и т.д.). Если интент не определен или уверенность низкая – немедленная эскалация к оператору.
- Строгие границы знаний. Промпт включает точные, верифицированные врачом данные: часы работы каждого отделения, список подготовительных действий для 20 видов анализов, политику отмены за 24 часа. Если вопрос выходит за эти рамки – бот не гадает, а говорит: «Этот вопрос лучше обсудить с вашим лечащим врачом или оператором».
- Эмпатия по шаблону. Вместо «будь эмпатичным» – конкретные инструкции: «Если пациент упоминает боль или срочность, вырази сочувствие и предложи соединить с отделением неотложной помощи». Это предсказуемо и безопасно.
Они использовали Guardrails for Amazon Bedrock (актуальная функция на 2026 год) для блокировки контента. Настроили фильтры на запрещенные темы: бот не должен давать медицинские рекомендации, интерпретировать результаты анализов, обсуждать лекарства без рецепта. Если пользователь запрашивает такое – Guardrails перехватывает запрос и возвращает стандартный ответ об эскалации.
2Голос, который не раздражает: почему Polly и тонкая настройка SSML
Голос – это 50% восприятия. Роботизированный голос разрушит все усилия по промпт-инжинирингу. Clarus Care потратили неделю на выбор и настройку.
Они выбрали Amazon Polly по двум причинам: низкая задержка (критично для диалога) и глубокая интеграция. Используют нейронные голоса (Neural TTS). «Joanna» показала лучшие результаты в тестах на естественность, особенно для женской аудитории (основной контингент клиник).
Но главный лайфхак – в SSML (Speech Synthesis Markup Language). Они не просто скармливают Polly текст от LLM. Lambda-функция пост-обрабатывает его, добавляя SSML-теги.
- <break time="700ms"/> – пауза после важной информации (например, после названия анализа). Дает пациенту время осознать.
- <prosody rate="slow">...</prosody> – замедление при произнесении сложных медицинских терминов (например, «маммография»).
- <emphasis level="strong">...</emphasis> – ударение на ключевых инструкциях («не принимайте пищу за 12 часов ДО»).
Это превращает монотонное озвучивание в осмысленную речь. Пациенты отмечали, что бот «говорит четко и спокойно, как медсестра». Для сравнения, ElevenLabs дает больше эмоциональной окраски, но для медицинского контекста предсказуемость и ясность Polly оказались важнее.
3Безопасность данных: HIPAA не как бюрократия, а как архитектурный принцип
Вся архитектура строилась от требования HIPAA. Это не просто галочка.
- Шифрование везде. Данные в DynamoDB – шифрование на стороне AWS (KMS). Транзит между сервисами – TLS 1.3. Аудиозаписи в S3 – шифрование AES-256.
- Минимальные права. IAM-роль для Lambda имеет доступ ТОЛЬКО к конкретным ресурсам: конкретному потоку в Connect, конкретной таблице DynamoDB, конкретной модели в Bedrock. Принцип least privilege.
- Логирование и аудит. Все вызовы Bedrock, расшифровки Transcribe, действия Lambda пишутся в CloudTrail. Можно отследить, кто, когда и какой запрос обрабатывал. Обязательно для расследования инцидентов.
- Защита от PII. Amazon Transcribe Call Analytics автоматически обнаруживает и маскирует персональные данные (номера телефонов, имена) в расшифровках перед отправкой в Bedrock. Дополнительный слой безопасности.
Они также реализовали механизм, похожий на подход Flo Health: вторая, более консервативная LLM (например, Amazon Titan Text) в фоновом режиме анализирует ответы основной модели перед отправкой пациенту, ища потенциально рискованные формулировки.
Результаты: цифры, которые заставили совет директоров улыбнуться
Через 3 месяца после запуска (к февралю 2026) метрики изменились кардинально.
| Метрика | До внедрения | После внедрения |
|---|---|---|
| Среднее время ожидания в очереди | 22 мин | 4 мин (для звонков к оператору) |
| Автоматизация запросов 1-го уровня | 0% | 68% |
| CSAT (удовлетворенность) | 3.8/5 | 4.5/5 (бот получил 4.2) |
| Текучесть операторов | 40% в год | 15% (операторы теперь решают сложные кейсы) |
| Ошибки в переносе записей | 12% | 1% (бот интегрирован с системой записи через API) |
Но самое интересное – непредвиденный эффект. Бот, работающий 24/7, стал обрабатывать запросы в нерабочее время (переносы, справки). Это дало 15% рост заполняемости расписания в утренние часы, так как пациенты могли решить вопросы с вечера.
Ошибки, которые чуть не загубили проект (учитесь на них)
- Первая версия промпта была слишком открытой. Бот начал давать советы по снятию головной боли. Выловили в тестировании. Исправление: Внедрили строгую классификацию интентов и Guardrails до запуска.
- Не учли фоновый шум. Первые тесты в реальных условиях – пациенты звонили из машин, с улицы. Transcribe делал ошибки. Исправление: Активировали в Transcribe опцию шумоподавления (Noise Reduction) и научили бота переспрашивать при низкой confidence score распознавания.
- Задержка в 4 секунды. Первая архитектура вызывала Bedrock синхронно в основном потоке. При высокой нагрузке задержка росла. Исправление: Перешли на асинхронную модель с кэшированием частых ответов (например, часов работы) в памяти Lambda.
- Монотонный голос. Первые отзывы: «робот». Исправление: Внедрили SSML-разметку и потратили бюджет на тонкую настройку Polly.
Что дальше? План Clarus Care на 2026-2027
Система работает, но это не конец. Дорожная карта:
- Мультимодальность. Интеграция с Alexa+ для пациентов, предпочитающих умные колонки. Отправка визуальных инструкций (схемы проезда, бланки) через SMS или мессенджеры после голосового подтверждения.
- Прогностика. Анализ тона голоса и частоты запросов для выявления пациентов, нуждающихся в срочной помощи или психологической поддержке (с передачей сигнала медсестре).
- Персонализация. После идентификации по номеру телефона (с согласия) – доступ к истории обращений и персональным рекомендациям («Джон, напоминаем, ваш прием у кардиолога через неделю, не забудьте взять результаты ЭКГ»).
