В медицинской организации одновременно накапливаются электронные медицинские карты, результаты исследований, врачебные заключения, клинические рекомендации, внутренние регламенты, отчётность и аналитические витрины. Проблема заключается не только в объёме информации, но и в её неоднородности: данные имеют разную структуру, обновляются с разной скоростью и доступны различным группам пользователей. BI-система способна показать показатель и его динамику, однако обычно не отвечает на вопросы, какие документы связаны с отклонением, что происходило с конкретным процессом и на какие источники опирается объяснение. Большая языковая модель умеет формулировать связный ответ, но без контролируемого контекста она может использовать устаревшие сведения, смешивать факты и правдоподобные предположения. Именно здесь появляется Retrieval-Augmented Generation (RAG), который в медицинской среде целесообразно рассматривать не как автономного советника, а как управляемый слой между данными, документами, аналитическими системами и пользователями.

Обычная LLM формирует ответ на основе параметров, полученных во время обучения, и контекста текущего запроса. RAG перед генерацией выполняет дополнительный шаг: ищет релевантные фрагменты во внешнем корпусе и передаёт их модели вместе с вопросом. Упрощённый процесс включает определение смысла запроса, роли пользователя и допустимой области поиска, затем поисковый слой находит связанные документы, которые фильтруются по доступу, актуальности и другим метаданным, после чего LLM формирует ответ на основе найденного контекста, а пользователь получает ссылки на источники. Подход был сформулирован в работе Патрика Льюиса и соавторов, опубликованной на NeurIPS 2020, как объединение параметрической памяти модели с внешней непараметрической памятью, доступной через поиск. Однако важно не переоценивать этот механизм: RAG не гарантирует истинность ответа и не исключает галлюцинации, поскольку система может найти нерелевантный документ, потерять важный фрагмент при разбиении текста, неверно связать утверждение с источником или предоставить модели слишком большой контекст. Качество зависит от всего контура, а не только от выбранной LLM.

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

В статье предложена архитектура RAG-контура, состоящая из шести слоёв, которая не привязана к конкретному вендору, модели или векторной базе. Первый слой — источники: нельзя без разбора загружать все доступные документы, необходимо определить владельца каждого источника, его назначение, период обновления и допустимые роли пользователей. Клиническая рекомендация, внутренний регламент, запись в ЭМК и агрегированная BI-витрина имеют разный статус, поэтому не должны попадать в общий корпус без метаданных, поскольку одинаковый текстовый поиск не учитывает юридическую силу, дату действия и принадлежность данных конкретному пациенту. Для каждого объекта следует сохранять тип источника, владельца, дату создания и обновления, период действия, идентификатор пациента или процесса, уровень конфиденциальности, разрешённые роли, версию документа и ссылку на исходную запись. Второй слой — подготовка корпуса, которая влияет на качество не меньше, чем модель: слишком маленькие части теряют контекст, слишком большие создают информационный шум, а таблицы, списки, заголовки и приложения требуют отдельной обработки. В медицинском контуре добавляются нормализация терминов, работа с сокращениями, контроль кодировок, дедупликация и обезличивание, при этом сведения о состоянии здоровья относятся к специальной категории персональных данных по статье 10 российского Федерального закона № 152-ФЗ, поэтому правила доступа и обработки должны проектироваться до загрузки корпуса.

Третий слой — поиск: полнотекстовый поиск хорошо работает с точными терминами, кодами и названиями, а векторный поиск полезен, когда вопрос и документ описывают одну мысль разными словами. В реальном контуре часто нужен гибридный подход, объединяющий оба сигнала, но релевантность текста является только одним условием — до передачи контекста модели необходимо применить фильтры доступа, пациента, подразделения и периода действия. Четвёртый слой — контекст: собранные фрагменты должны быть отсортированы по значимости, объединены с учётом ограничений по длине и дополнены метаданными, такими как дата, тип документа и уровень достоверности. Пятый слой — генерация: LLM получает запрос и отобранный контекст, но важно ограничить её свободу, например, указать, что ответ должен опираться только на предоставленные источники, а при отсутствии данных — явно сообщить об этом. Шестой слой — контроль и оценка: необходимо вести журнал запросов, ответов и источников, а также регулярно оценивать качество по таким критериям, как полнота, точность, релевантность и отсутствие галлюцинаций. Для оценки можно использовать автоматические метрики и экспертную проверку, но важно помнить, что RAG делает ответ потенциально более проверяемым, а не гарантированно точным.

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

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