ИИ-ассистент для клиники: как использовать RAG и базу знаний — и где бот должен звать человека

На itc.media уже работает ИИ-ассистент.

Он встречает посетителей, помогает с типовыми вопросами и отвечает по базе знаний.

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

Для клиники — недостаточно.

Самая опасная ошибка здесь — решить, что достаточно загрузить в того же бота медицинский FAQ.

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

Наш реальный продуктовый опыт здесь — с ассистентом itc.media, а не с пациентами клиники.

Поэтому я разбираю архитектуру переноса, а не придумываю «30 дней медицинского теста».

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

Внутри мы называем его Эйти.

Он встречает пользователя не просто пустым полем «напишите вопрос».

Виджет предлагает несколько готовых вариантов.

И это уже первый ограничитель.

Пока человек выбирает одну из заранее понятных тем, модели проще понять контекст.

Свободный ввод остаётся, но это уже второй сценарий.

Для корпоративного сайта это UX.

Для клиники такой подход становится ещё и способом уменьшить неопределённость.

Ассистент использует базу знаний и RAG.

Сначала система ищет релевантные фрагменты в подготовленном контенте.

После этого модель формирует ответ.

Это намного лучше, чем просто попросить LLM отвечать из общих знаний.

Но есть важная оговорка:

RAG снижает риск выдумки, но не делает ответ автоматически истинным.

Если в базе есть неоднозначность или прямого ответа нет, модель всё равно способна достроить логическую связку.

В медицине именно это становится критично.

У ассистента есть явная пометка, что первым отвечает бот.

Это не декоративная деталь.

Чем естественнее звучит нейросеть, тем легче человеку забыть, что перед ним не сотрудник и тем более не врач.

Для ИИ-ассистента клиники такая прозрачность должна быть базовым требованием.

Модель естественно стремится сделать текст убедительнее.

А медицинская реклама — как раз та зона, где «убедительнее» может означать «слишком сильное обещание».

Поэтому офферы и сильные маркетинговые формулировки лучше брать из заранее утверждённого набора, а не создавать свободно в каждом диалоге.

Потому что медицинская коммуникация добавляет новый класс вопросов.

Расписание, адрес и стоимость — организационные данные.

Симптомы, интерпретация состояния и выбор лечения — уже клиническое суждение.

Нужна не просто хорошая база знаний.

Нужна граница.

Если вопрос про запись и ответ подтверждён в базе — бот может ответить.

Если пользователь просит оценить симптомы — сценарий должен измениться.

Не нужно ждать, пока сама модель решит:

«кажется, здесь мне лучше остановиться».

Эта граница должна быть определена продуктом.

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

Откуда это взято?

Кто проверил?

Когда обновлялось?

Можно ли сообщать это пациенту без врача?

Что делать, если ответа нет?

Последний вопрос особенно важен.

Если данных нет, хороший медицинский бот не должен быть «изобретательным».

Он должен быть скучным:

«информации недостаточно, передаю вопрос человеку».

Фраза:

«если не уверен — позови оператора»

слишком слабая защита.

Уверенность модели вообще плохой критерий.

Модель может быть очень уверенной и очень неправильной.

Поэтому категории вопросов для передачи человеку должны определяться явными правилами.

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

Поэтому проектировать медицинский чат только как интерфейс нельзя.

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

Есть интересный парадокс.

Чем лучше модель разговаривает, тем больше риск, что пользователь воспринимает её как специалиста.

Поэтому хороший медицинский ассистент не обязан казаться максимально умным.

Он обязан надёжно понимать предел своей роли.

Я бы строил её так:

вопрос → классификация → поиск в проверенной базе → ответ только в разрешённой зоне → эскалация при выходе за границу.

Организационный вопрос и подтверждённый ответ — отвечаем.

Организационный вопрос без данных — человек.

Симптомы или просьба о медицинском совете — человек.

Чувствительные данные — отдельный безопасный сценарий.

Маркетинговый оффер — только утверждённая формулировка.

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

Забрать схему →

Что измерять после запуска чат-бота клиники

Не только скорость.

Бот всё равно отвечает быстрее человека.

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

И только потом считать экономию.

Потому что дешёвый ответ, которому нельзя доверять, — плохая автоматизация.

У нас уже есть работающий ИИ-ассистент на корпоративном сайте.

Но это не означает, что у нас есть готовый медицинский бот.

Именно это важно.

Для чувствительной ниши нельзя просто заменить FAQ и сохранить прежнюю свободу модели.

Нужно уменьшать пространство, в котором ИИ имеет право импровизировать.

Чем чувствительнее тема — тем меньше надежды на «умность модели» и тем больше явных правил вокруг неё.

Я регулярно разбираю AI-ассистентов, RAG, базы знаний и другие сценарии автоматизации — без подхода «подключим модель и разрешим ей отвечать на всё». Больше таких разборов — в Telegram-канале «Александров про диджитал».

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

Хороший ИИ-ассистент для клиники — не тот, который отвечает на максимальное количество вопросов.

А тот, который надёжно понимает границу своей роли.

Если вы думаете об ИИ-ассистенте для клиники и хотите разобрать, какие вопросы можно оставить ему, а где сразу нужна передача человеку, напишите в Telegram-бот

Разобрать сценарий ИИ-ассистента →