RAG в медицинской аналитике: как построить управляемый контур вместо очередного чат‑бота

Эта публикация подготовлена на основе моей ВАК‑статьи «Методологический подход к применению Retrieval‑Augmented Generation в медицинской аналитике для развития интеллектуальной поддержки деятельности медицинской организации». Для Хабра я убрал академическое оформление, сократил обзор литературы и подробнее объяснил практическую архитектуру, ограничения и способ оценки такого решения.

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

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

Здесь появляется RAG, или Retrieval‑Augmented Generation. Но в медицинской среде я бы рассматривал его не как чат‑бота и тем более не как автономного медицинского советника. Более полезная модель — управляемый слой между данными, документами, аналитическими системами и пользователями.

Что именно добавляет RAG

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

Упрощённый процесс выглядит так:

1. Пользователь задаёт вопрос.

2. Система определяет его смысл, роль пользователя и допустимую область поиска.

3. Поисковый слой находит связанные документы или записи.

4. Результаты фильтруются по доступу, актуальности и другим метаданным.

5. LLM формирует ответ на основе найденного контекста.

6. Пользователь получает ответ вместе со ссылками на источники.

Сам подход был сформулирован в работе Патрика Льюиса и соавторов как объединение параметрической памяти модели с внешней непараметрической памятью, доступной через поиск. Оригинальная работа опубликована в NeurIPS 2020.

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

Почему это не должен быть просто медицинский чат‑бот

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

В реальной организации сразу появляются дополнительные вопросы:

• кто имеет право искать по данным конкретного пациента;

• какие документы считаются актуальными;

• что делать с противоречащими друг другу источниками;

• должен ли ответ попадать в медицинскую информационную систему;

• кто проверяет результат;

• как найти все обращения к конкретному документу;

• можно ли воспроизвести ответ после обновления индекса;

• что произойдёт, если поиск ничего надёжного не нашёл.

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

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

Архитектура RAG‑контура

В ВАК‑статье я предложил архитектуру из шести слоёв. Она не привязана к конкретному вендору, модели или векторной базе.

1. Источники

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

Клиническая рекомендация, внутренний регламент, запись в ЭМК и агрегированная BI‑витрина имеют разный статус. Они не должны попадать в общий корпус без метаданных, потому что одинаковый текстовый поиск не учитывает юридическую силу, дату действия и принадлежность данных конкретному пациенту.

Для каждого объекта я бы сохранял как минимум:

• тип источника;

• владельца;

• дату создания и обновления;

• период действия;

• идентификатор пациента или процесса, если применимо;

• уровень конфиденциальности;

• разрешённые роли;

• версию документа;

• ссылку на исходную запись.

2. Подготовка

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

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

Сведения о состоянии здоровья относятся к специальной категории персональных данных по статье 10 российского Федерального закона № 152-ФЗ. Поэтому правила доступа и обработки должны проектироваться до загрузки корпуса, а не после готовности прототипа.

3. Поиск

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

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

Поисковый слой также должен уметь признать отсутствие результата. Ответ «достаточных источников не найдено» в медицине полезнее, чем уверенный текст, построенный на слабом совпадении.

4. Генерация

На этом уровне выбираются модель, системные инструкции, формат ответа и правила цитирования. Для разных сценариев не обязательно использовать один шаблон.

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

Полезно разделять три части результата:

1. Факты, непосредственно найденные в источниках.

2. Сформированное моделью объяснение.

3. Предупреждения об ограничениях и недостатке данных.

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

5. Контроль

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

• ролевая и объектная авторизация;

• журналирование запросов, найденных фрагментов и ответов;

• контроль версий источников;

• проверка корректности ссылок;

• тестовые наборы для разных ролей и сценариев;

• мониторинг времени ответа и отказов;

• экспертная приёмка результатов;

• процедура разбора ошибок.

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

6. Обратная связь

Оценка «полезно или нет» сама по себе почти ничего не объясняет. Обратную связь лучше разделять на несколько причин:

• найден неверный документ;

• пропущен важный источник;

• источник правильный, но вывод модели неверен;

• ответ слишком общий;

• использована устаревшая версия;

• нарушен формат;

• в корпусе отсутствуют нужные данные.

Каждый тип ошибки ведёт к своей доработке. Проблему поиска нельзя стабильно исправить новым промптом, а отсутствие документа не решается заменой модели.

Где такой контур может использоваться

В исходной статье я разделил эффекты по пяти уровням.

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

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

Как оценивать эффект, а не только качество модели

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

В ВАК‑статье я предложил интегральный показатель:

$$I_{RAG} = w_T K_T + w_S K_S + w_E K_E + w_N K_N,$$

где:

• $K_T$ — нормированный показатель сокращения времени поиска;

• $K_S$ — доля ответов с корректно указанными источниками;

• $K_E$ — доля ответов, принятых экспертом без существенной правки;

• $K_N$ — нормированный показатель снижения информационного шума;

• $w_T$, $w_S$, $w_E$, $w_N$ — веса критериев, сумма которых равна 1.

Все компоненты должны быть приведены к диапазону от 0 до 1. Например, сокращение времени можно считать так:

$$K_T = 1 — frac{T_{RAG}}{T_{base}},$$

где $T_{base}$ — медианное время выполнения сценария без RAG, а $T_{RAG}$ — медианное время с системой. Если RAG не ускорил работу, значение не должно искусственно улучшать итоговый показатель.

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

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

Что показывают исследования

RAG в медицинском домене уже не ограничивается отдельными экспериментами. В scoping review 2025 года авторы отобрали 67 исследований из 917 найденных публикаций. При этом только 12 из 67 работ затрагивали этические вопросы, а немногие решения были связаны с реальными клиническими процессами. Это одновременно показывает рост интереса и недостаточную зрелость внедрения. Результаты опубликованы в Journal of Medical Internet Research.

Авторы MedRAG создали тестовый набор MIRAGE из 7663 вопросов и проверили 41 комбинацию корпусов, поисковых механизмов и LLM. В их экспериментах MedRAG повысил точность шести моделей до 18% относительно chain‑of‑thought prompting. Здесь важно слово «до»: это результат конкретного бенчмарка, а не гарантия такого же прироста в информационной системе медицинской организации. Работа доступна в ACL Anthology.

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

Управление рисками должно быть частью архитектуры

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

В качестве общей рамки можно использовать четыре функции NIST AI RMF: Govern, Map, Measure и Manage. NIST описывает этот документ как добровольную, межотраслевую основу для управления рисками AI‑систем, а отдельный профиль NIST AI 600–1 расширяет рекомендации для генеративного ИИ. Официальные материалы доступны на странице NIST AI RMF.

Для медицинской организации практический минимум выглядит так:

1. Зафиксировать назначение системы и запрещённые сценарии.

2. Назначить владельцев данных, модели и процесса.

3. Разграничить доступ до этапа поиска.

4. Вести версии корпуса, индекса, модели и инструкций.

5. Создать тестовые наборы с экспертной разметкой.

6. Определить случаи обязательной проверки человеком.

7. Журналировать запрос, найденный контекст и итоговый ответ.

8. Отслеживать деградацию после обновления источников и компонентов.

9. Подготовить процедуру остановки системы и разбора инцидента.

Руководство Всемирной организации здравоохранения по большим мультимодальным моделям отдельно рассматривает участие заинтересованных сторон, прозрачность, надзор и оценку после внедрения. Европейская комиссия также указывает, что AI‑системы высокого риска, включая программное обеспечение на основе ИИ медицинского назначения, должны соответствовать требованиям по управлению рисками, качеству данных, информированию пользователей и человеческому контролю. Это описано на официальной странице Artificial Intelligence in healthcare и в тексте EU AI Act.

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

Чего RAG не исправит

RAG не решает проблемы исходных данных. Если документы устарели, противоречат друг другу или не имеют владельцев, система только быстрее доставит эту неопределённость пользователю.

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

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

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

С чего начать пилот

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

Минимальный план пилота:

1. Выбрать одну роль и один тип вопроса.

2. Сформировать контролируемый корпус с владельцами и версиями.

3. Определить права доступа и запрещённые данные.

4. Подготовить набор реальных вопросов и эталонных источников.

5. Сравнить полнотекстовый, векторный и гибридный поиск.

6. Проверить ответы и ссылки экспертами.

7. Измерить время выполнения сценария до и после внедрения.

8. Разобрать ошибки по слоям: данные, поиск, генерация или процесс.

9. Только после этого расширять корпус и количество ролей.

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

Итог

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

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

LLM в такой системе является важным, но не единственным компонентом. Если корпус, права и критерии качества не определены, замена модели редко исправляет проект. Если же весь контур управляем и измерим, RAG может стать связующим слоем между BI, DWH, документами и пользователями медицинской организации.