RAG-чат-бот в клинике перепутал данные пациентов: как это исправить

Управляемый RAG-контур в медицинской аналитике — это связка проверенных источников данных, прав доступа и обязательного цитирования, которая не даёт модели домысливать факты о пациентах. В отличие от обычного чат-бота, отвечающего по вероятности похожих слов, контур ищет документ, показывает его номер и молчит, если источник не найден.

Почему RAG-бот в клинике путает данные пациентов и диагнозы

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

Эмбеддинг находит текст по смысловой близости, а не по номеру пациента, поэтому карта одного человека и выписка другого звучат почти одинаково — те же формулировки диагноза, тот же протокол приёма, тот же врач. Без метаданных, которые жёстко привязывают кусок текста к конкретному пациенту и филиалу, поиск подтягивает похожее, а не то самое. В этой клинике данные годами вели в 1С, но в RAG их отгружали файлом раз в сутки без ключей — записи разных пациентов лежали в одном документе, разделённые пустой строкой.

Похожая история случается не только с текстом истории болезни. RAG в медицинской аналитике часто подключают и к таблицам: показатели давления, результаты анализов, назначения по датам. Табличные данные без явной привязки к пациенту и дате визита эмбеддинг сравнивает так же — по похожести чисел и формулировок, а не по связи «пациент → визит → показатель». Отсюда типичная ошибка: бот показывает тренд давления одного человека, подписав его именем другого — цифры оказались рядом в индексе, а не в жизни пациента.

Ставка здесь не в неловкости. Ответ с чужим диагнозом — это утечка персональных медицинских данных по 152-ФЗ: обязанность уведомить регулятора, разбирательство и звонок от пациента, который узнал детали чужой истории болезни. После такого случая администраторы перестают доверять боту и возвращаются к телефону — а деньги на внедрение оказываются потрачены зря.

Пациент, получивший чужие данные, чаще уходит в другую клинику. Ошибка бота бьёт не только по репутации, но и по потоку записи на приём — ради которого чат-бота изначально и подключали.

Как исправить путаницу: источники, права доступа и цитирование

Первый шаг — не модель, а разметка данных на входе. Каждый фрагмент текста при индексации получает метки: ID пациента, филиал, тип документа, дата актуальности. Поиск сначала фильтрует по правам доступа сотрудника и нужному филиалу, и только потом ищет смысловое совпадение внутри отфильтрованного набора — а не по всей базе сразу.

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

Второй шаг — обязательное цитирование. Ответ бота должен содержать номер документа-источника, а если подходящего документа не нашлось — контур обязан ответить «не нашёл в базе», а не достраивать правдоподобный текст. Это меняет саму задачу модели: не сочинить хороший ответ, а найти и процитировать конкретную запись.

Источник данных для медицинской аналитики почти всегда — учётная система клиники. Если карточки пациентов, записи на приём и счета ведутся в 1С, для RAG нужен не выгрузка раз в сутки файлом, а API с идентификаторами и правами доступа на уровне записи — это отдельная доработка 1С, а не настройка самого чат-бота. Иногда проблема глубже: часть учёта в клинике ведётся в разрозненных таблицах вне единой базы, и тогда сначала нужно нормальное внедрение 1С как единого источника данных, и только потом — RAG поверх него.

Что делать, если ошибка повторяется после исправления

Метаданные разметили, права доступа настроили, а через месяц бот снова путает записи — знакомая история. Дело обычно не в самом RAG, а в том, что источник данных снова разъехался с индексом.

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

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

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

Как предотвратить утечку персональных данных пациентов через RAG

Три вещи держат контур в рамках закона и здравого смысла. Доступ проверяется на этапе поиска, а не только на этапе показа ответа — сотрудник регистратуры не должен получать в контекст истории болезни пациентов другого профиля, даже если модель потом «сама разберётся», что показывать. Персональные данные маскируются до того, как текст попадает в векторную базу: ФИО и диагноз в сыром виде хранить в индексе без контроля доступа — уязвимость сама по себе, независимо от того, что отвечает бот.

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

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

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

Обычный чат-бот на LLM или управляемый RAG-контур: в чём разница

Разница между обычным чат-ботом на LLM и управляемым RAG-контуром не в том, что второй «умнее» — она в том, что второй проверяем.

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

Сколько стоит и как быстро выстраивается управляемый контур

Подключение начинается не с выбора модели, а с ревизии структуры данных: какие справочники в 1С продублированы, где номера пациентов не совпадают между филиалами, какие документы вообще можно отдавать в контур без риска. По итогам ревизии понятно, хватит ли доработки выгрузки или нужно пересобирать учёт заново.

Для сети из нескольких точек, где записи на приём, склад препаратов и расчёты с пациентами разбросаны по разным базам, разумнее сначала свести их в единый контур на 1С:ERP — тогда RAG строится поверх одной согласованной базы, а не поверх трёх, которые противоречат друг другу. Для одной клиники с уже настроенным учётом обычно достаточно точечной доработки API и правил доступа.

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

Сопровождение после запуска — это по сути системное администрирование данных: следить, чтобы индекс не расходился с базой, чтобы права доступа обновлялись вместе со штатным расписанием, чтобы логи разбирались после инцидентов. У нас такая работа тарифицируется как сопровождение 1С и сисадмин — от 3800 руб/час специалиста, без абонентской платы за то время, когда контур просто работает штатно.

❓ Частые вопросы

Чем управляемый RAG-контур отличается от обычного чат-бота на сайте клиники?

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

Можно ли подключить RAG к данным, которые ведутся в 1С, без доработок?

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

Как RAG-контур соблюдает 152-ФЗ при работе с медицинскими данными?

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

Сколько времени занимает подключение RAG-контура к базе клиники?

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

Что отвечает бот, если в базе нет данных для ответа на вопрос?

Управляемый контур честно сообщает, что не нашёл подходящего документа, вместо того чтобы достраивать правдоподобный, но выдуманный ответ. Это ключевое отличие от обычного чат-бота на LLM: задача модели — найти и процитировать запись, а не сочинить убедительный текст при отсутствии данных.