Привет, Хабр! Меня зовут Иван. Я работаю аналитиком в компании «Совкомбанк Технологии»: собираю требования, разбираю процессы с пользователями и помогаю доводить ИИ‑решения от этапа идеи до работающего сервиса. В этой статье расскажу, как мы с командой внедряли ИИ‑агента в работу медицинского пульта страховой компании.
Коротко о команде: над проектом работали аналитик, backend‑разработчики, специалист по интеграциям, ML/LLM‑инженеры, тестировщики и представители бизнеса.
Задача была не просто «поиграть с нейросетями», а реально встроить LLM в процесс, где цена ошибки очень высока: на линии находится клиент — застрахованный человек, который хочет быстро решить свою проблему, а мы стремимся оказать высокий уровень сервиса. Оператор должен быстро понять его проблему, корректно внести данные и не потерять важный медицинский контекст с помощью ИИ.
Главная идея: ИИ не заменяет оператора и не принимает медицинских решений. Он снимает рутинную нагрузку: готовит структурированный черновик, подсказывает возможный код МКБ (международная классификация болезней) и оставляет финальную проверку человеку.
Контекст: ИИ‑марафон и сжатые сроки
Проект родился внутри ИИ‑марафона Совкомбанка. Это формат, близкий к корпоративному хакатону: командам необходимо реализовать работающее бизнес‑решение, а не просто презентацию, в сжатые сроки.
ИТ‑специалисты Совкомбанк Технологий работали над проектом совместно с представителями Страховой Группы Совкомбанка. Первичная формулировка звучала просто: автоматизировать ввод данных из телефонных разговоров. Но после погружения в контекст, стало понятно, что это задача не уровня «распознать аудио и перенести результат в текстовое поле», а целый участок операционной работы.
Оператор медицинского пульта одновременно ведет диалог, успокаивает клиента, если это необходимо, ищет данные в системе, фиксирует симптомы, причину обращения, диагноз, необходимые услуги и затем переносит всё в CRM. В среднем звонок длится около трех минут, а постобработка занимает примерно столько же, при этом в пиковые часы звонки могут идти почти без пауз.
Мы пошли к пользователям, посмотрели на процесс вживую и выявили ключевую боль: «Я не успеваю печатать так же быстро, как говорит человек». Поэтому мы решили спроектировать «третью руку», которая будет писать черновик за оператора.
От первой версии к промышленному сценарию
Разработку наша команда разделила на два этапа: сначала нужно было быстро доказать жизнеспособность идеи, а потом превратить прототип в сервис, который можно будет подключать к реальному процессу.
Первая версия
Для первой версии нам были важны скорость и возможность проверить гипотезу. Мы собрали минимальный контур:
Streamlit для интерфейса. Он позволил быстро собрать экран для загрузки записи и просмотра результата без отдельной frontend‑команды.
FastAPI для backend‑слоя. Через него мы принимали аудиозапись, запускали обработку и возвращали структурированный ответ.
VoiceKey для распознавания речи. На старте это был самый быстрый путь получить текстовую расшифровку звонка и сфокусироваться на LLM‑части.
Qwen3-30B для извлечения данных. Модель использовали как инструмент структурирования текста, а не как самостоятельного эксперта.
На первой защите оператор загружал запись, а через несколько секунд видел заполненные поля: ФИО, причина обращения, диагноз, предполагаемый код МКБ. Это показало, что направление рабочее. Но мы прекрасно понимали: красивый прототип и сервис с реальной нагрузкой — это разные вещи.
Переход к рабочему контуру
Следующий этап был про архитектуру, интеграции и устойчивость. По целевому сценарию система должна была выдерживать до 57 одновременных звонков, не теряя контекст сессии и работая в закрытом контуре банка.
Интеграция с телефонией. Записи и служебные данные приходили из связки SmartLogger и Avaya. Для нас это был источник аудио, идентификаторов звонков и метаданных, необходимых для связывания результата с операторской сессией.
Очереди и состояние. Redis использовали как быстрый слой для хранения промежуточного состояния и управления обработкой. Это помогало не «ронять» сервис при параллельных обращениях.
Безопасность. Так как речь идет о медицинских данных, модель и обработка должны были оставаться внутри закрытого контура. Также потребовались авторизация, разграничение доступа и понятный аудит действий.
Промпты: почему температура 0.1 важнее красивого текста
Сердце решения — LLM Qwen3-30B. Выбрали её, потому что помимо скорости и способности стабильно извлекать суть из русскоязычной транскрибации нам было важно, чтобы LLM была безопасной и минимально загружена запросами от других команд.
В медицине нельзя «додумывать» диагнозы. Поэтому основной риск был не в том, что модель ответит некрасиво, а в том, что она уверенно заполнит поле данными, которых не было в разговоре.
Temperature 0.1. Креативность нам не нужна. Нужна повторяемость: на один и тот же текст модель должна давать максимально близкий результат.
Жесткий системный промпт. Мы явно описали роль, формат ответа и правило: если данных нет в транскрибации, нужно писать «Не указано», а не угадывать.
JSON‑подобная структура. Ответ модели сразу приводился к формату, который можно валидировать и передавать дальше.
Негативные примеры. В промптах отдельно описали, чего делать нельзя: выдумывать ФИО, подменять жалобу диагнозом, выбирать код МКБ только по одному слову без контекста.
Работа с МКБ‑кодами
Самым сложным участком стали коды МКБ. На первый взгляд кажется: пусть модель прочитает диагноз и выдаст код. Но на практике похожие формулировки легко ведут к разным кодам, а транскрибация может исказить медицинский термин.
Мы пришли к многоэтапной схеме. Сначала модель извлекает диагноз текстом и отделяет его от жалоб пациента. Затем отдельным шагом сопоставляет формулировку со справочником МКБ, который подается в контекст. После этого валидатор проверяет, не противоречит ли выбранный код исходному разговору.
Такой подход оказался лучше одного большого запроса по двум причинам. Во‑первых, ошибку проще локализовать: проблема в распознавании, в извлечении диагноза или в сопоставлении со справочником. Во‑вторых, каждый шаг можно тестировать на своем наборе кейсов и отдельно дорабатывать промпт.
Цепочка агентов: меньше магии, больше инженерии
Мы назвали это агентной логикой, но без лишнего мистицизма. Внутри это несколько специализированных запросов и проверок, где каждый блок отвечает за свою часть результата.
Агент‑транскрибатор. Собирает текст из двух каналов, разделяет реплики оператора и клиента, убирает явный шум и междометия.
Агент‑экстрактор. Ищет сущности: ФИО, причину обращения, жалобы, диагноз, услуги, важные ограничения.
Агент‑нормализатор. Приводит формулировки к виду, пригодному для CRM: без разговорных оборотов и лишнего текста.
Агент МКБ. Сопоставляет диагноз со справочником и возвращает не только код, но и объяснение выбора.
Агент‑валидатор. Проверяет, подтверждаются ли извлеченные поля исходной расшифровкой. Если видит противоречие, отправляет результат на повторную обработку с уточнением.
Важный плюс для команды: такую систему проще обсуждать с бизнесом. Вместо фразы «нейросеть ошиблась» можно сказать точнее: «распознавание исказило термин», «экстрактор перепутал жалобу с диагнозом» или «код МКБ выбран слишком широко».
Результаты и честные ограничения
Главный измеримый эффект — сокращение времени обработки примерно на 30%. Оператору больше не нужно запоминать все слова клиента во время разговора и потом судорожно переносить заметки в CRM. Он получает черновик и проверяет его.
При этом качество результата сильно зависело от качества расшифровки. Мы использовали транскрибацию от смежной команды, и в части звонков она ошибалась на медицинских терминах, фамилиях и шумных фрагментах. Часть проблем удалось сгладить постобработкой текста и проверками валидатора, но полностью решить это на уровне LLM нельзя: если на входе потерян смысл, модель не должна его придумывать.
Что планируем улучшать дальше: переходить на более точную онлайн‑транскрибацию, дообучать или настраивать распознавание на медицинскую лексику, расширять словари терминов и добавлять подсказки оператору прямо во время разговора.
Обратную связь собирали у сотрудников пульта и у представителей Страховой Группы после демонстраций и пилотного использования. Она была не только позитивной: пользователи справедливо указывали на ошибки распознавания и спорные поля. Общий вывод: сервис полезен, если воспринимать его как ассистента, работа которого обязательно требует проверки человеком, а не как полностью автономного оператора.
Что бы я посоветовал командам, которые идут похожим путем
Идите к пользователям. Ни одно ТЗ не заменит часа рядом с оператором, который реально работает в системе.
Не продавайте магию. Объясняйте, где LLM помогает, а где остается риск и нужна проверка человеком.
Храните версии промптов как код. Фиксируйте изменения и регрессии, тестируйте на наборах звонков.
Разделяйте цепочку на шаги. Монолитный промпт сложнее отлаживать, объяснять и валидировать.
Смотрите на входные данные. Если транскрибация плохая, LLM не должна героически угадывать. Лучше честно вернуть неопределенность.
Для меня главный вывод такой: ИИ‑агент становится полезным не тогда, когда его называют «агентом», а когда он встроен в процесс, имеет понятные границы ответственности и помогает человеку делать работу быстрее и спокойнее.
Есть вопросы по архитектуре, промптам или организации пилота? Буду рад обсудить в комментариях.
