RAG для медицинской клиники: как автоматизировать 400+ вопросов в день о ценах и ДМС

Частные клиники тонут в однотипных вопросах: «Сколько стоит МРТ?», «Покрывает ли мой полис ДМС эту процедуру?», «Есть ли окно к неврологу на среду?». Операторы тратят 60–70% времени на справочные ответы, которые можно найти в прайсе или договоре ДМС. В VibeLab мы разобрали архитектуру RAG-системы для этого сценария, протестировали подход на реальных данных клиники и готовы поделиться результатами — включая подводные камни, о которых не пишут в туториалах.

---

Проблема: почему клиникам не хватает обычного чат-бота

Типичная частная клиника с 15–20 специалистами получает 300–500 обращений в день через мессенджеры и телефонию. По нашей оценке, 60–70% из них — справочные:

• Стоимость конкретной услуги или комплекса
• Покрытие процедуры по полису ДМС конкретной страховой
• Наличие свободных слотов у врача
• Подготовка к процедуре (анализы натощак, ограничения)

Классические чат-боты на кнопках и деревьях решений здесь буксуют. Прайс клиники — это 200–800 позиций с вариациями по категориям пациентов. Условия ДМС отличаются у каждой страховой, а иногда — у каждого корпоративного договора. Кнопочный бот не справляется с вопросом «Мне нужно УЗИ щитовидки, у меня РЕСО от Газпрома — покроют?».

RAG (Retrieval-Augmented Generation) решает эту задачу иначе: вместо жёстких сценариев система ищет релевантные фрагменты в базе знаний клиники и генерирует ответ на естественном языке. Пациент спрашивает как хочет — система находит нужное.

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

---

Архитектура: из чего состоит RAG для клиники

Мы протестировали архитектуру, заточенную под специфику медицинских данных. Вот ключевые компоненты.

1. База знаний: работа с неоднородными источниками

Данные клиники неоднородны — и это первая сложность. Вот типы документов, которые нужно индексировать:

Тип данных	Формат	Частота обновления	Сложность индексации
Прайс-лист	Excel / CSV / выгрузка из МИС	Еженедельно	Средняя
Условия ДМС	PDF-договоры, таблицы покрытия	Ежегодно + допсоглашения	Высокая
Расписание врачей	API МИС (ЕМИАС, Инфоклиника, МедиАлог)	В реальном времени	Высокая
Подготовка к процедурам	Текстовые инструкции	Редко	Низкая
FAQ	Накопленные ответы операторов	Ежемесячно	Низкая

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

Для IT-менеджеров и архитекторов: для прайсов и расписания необходима интеграция через API с МИС (медицинской информационной системой), а не периодическая выгрузка файлов. Периодическая выгрузка создаёт окно расхождения данных — и именно туда попадают конфликтные ситуации с пациентами.

2. Индексация и чанкинг: медицинская специфика важна

Медицинские документы плохо ложатся на стандартный чанкинг по 500–1000 токенов. Договор ДМС — это юридический текст с перекрёстными ссылками: «Услуги из Приложения 2 покрываются в объёме, указанном в п. 4.3.1». Если разрезать такой документ посередине, контекст теряется, и модель либо галлюцинирует, либо отвечает уклончиво.

Подход, который показал лучшие результаты при тестировании:

Прайс-лист: каждая строка — отдельный чанк с метаданными (категория, подкатегория, тип пациента). Overlap не нужен — строки самодостаточны. Структура чанка:

Договоры ДМС: чанкинг по логическим секциям (раздел, подраздел), а не по количеству токенов. Overlap 15–20% между секциями — чтобы граничные условия не терялись при разрезе.

FAQ и инструкции: стандартный чанкинг по 400–600 токенов с overlap 100 токенов.

3. Эмбеддинги: бенчмарк на реальных данных

Для эмбеддингов мы сравнивали text-embedding-3-small от OpenAI и multilingual-e5-large-instruct. Тестировали на выборке из 200 реальных вопросов из чата клиники, где ground truth — ответы операторов, размеченные вручную.

text-embedding-3-small показал recall выше на ~7–9 п.п. на русскоязычных медицинских запросах. Вероятная причина — лучшая обработка смешанных запросов: русский текст + латинские медицинские термины + числа. «Гастроскопия ФГДС цена» — типичный запрос, где модель должна понимать, что ФГДС и фиброгастродуоденоскопия — одно и то же.

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

4. Retrieval-пайплайн: пять слоёв точности

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

Шаг 1: Query rewriting

Пациент пишет «скока стоит мрт колена» — нужно нормализовать в «стоимость МРТ коленного сустава». GPT-4o-mini справляется за 50–80 мс и ~100 токенов. Промпт для rewriting:

Шаг 2: Гибридный поиск (векторный + BM25)

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

Мы используем RRF (Reciprocal Rank Fusion) для объединения результатов двух методов:

Шаг 3: Metadata filtering

Перед поиском определяем тип запроса (цена / ДМС / расписание / подготовка) и фильтруем по соответствующей категории документов. Это сокращает шум в выдаче на 30–40% и ускоряет поиск, так как индекс меньше.

Шаг 4: Порог релевантности

Если similarity score ниже 0.75, система не пытается сгенерировать ответ, а переводит на оператора. Этот порог подобран эмпирически для text-embedding-3-small на нашей выборке.

Для разработчиков: при смене модели эмбеддингов порог нужно калибровать заново — распределение косинусных расстояний у разных моделей отличается. Не переносите пороговые значения между моделями без повторной калибровки.

Шаг 5: Reranker

Для top-20 результатов поиска применяем cross-encoder (bge-reranker-v2-m3) для переранжирования до top-5 перед передачей в LLM. Cross-encoder читает запрос и документ совместно (в отличие от bi-encoder в эмбеддингах) и даёт более точную оценку релевантности, но работает медленнее — поэтому применяем только к узкому топу.

---

Что это даёт бизнесу

Для IT-менеджеров и владельцев клиник — конкретные цифры и эффекты:

• Снижение нагрузки на операторов на 55–65% по справочным вопросам (цены, ДМС, подготовка к процедурам)
• Время ответа: от нескольких минут ожидания оператора — до 3–5 секунд для системы
• Покрытие 24/7 без доп. найма: ночные и выходные обращения обрабатываются автоматически
• Операторы переключаются на запросы, требующие эмпатии и принятия решений: запись к нескольким врачам, сложные клинические вопросы, конфликтные ситуации

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

---

Подводные камни, о которых не пишут в туториалах

1. Медицинские данные — не просто текст

Договор ДМС содержит юридические ссылки, таблицы с исключениями, приложения. Стандартный PDF-парсер часто ломает структуру таблиц. Нужен предобработчик, который восстанавливает табличные данные в структурированный формат перед индексацией.

2. Цены живут отдельно от расписания

Вопрос «Можно ли попасть к кардиологу в среду и сколько это стоит?» требует данных из двух источников с разной частотой обновления. Если расписание из МИС, а цена из прайса, нужна логика объединения ответов. Это сложнее, чем кажется на старте.

3. Галлюцинации опаснее в медицине

Если языковая модель «придумает» цену или условие покрытия ДМС — это не просто UX-проблема, это потенциальный конфликт с пациентом. Поэтому порог релевантности и fallback на оператора — не опция, а обязательный компонент архитектуры.

4. Актуальность данных — операционная задача, не техническая

Техническую интеграцию с МИС сделать проще, чем выстроить процесс своевременного обновления данных в клинике. Кто отвечает за загрузку нового прайса? Кто проверяет, что загрузка прошла успешно? Без ответа на эти вопросы система деградирует за несколько месяцев.

---

Стек, который мы использовали

Компонент	Решение	Альтернативы
Векторное хранилище	Qdrant	Weaviate, Pinecone, pgvector
Эмбеддинги	text-embedding-3-small (OpenAI)	multilingual-e5-large-instruct
BM25	Elasticsearch	OpenSearch, Typesense
Reranker	bge-reranker-v2-m3	Cohere Rerank
LLM (генерация)	GPT-4o	Claude 3.5 Sonnet
Query rewriting	GPT-4o-mini	Локальная модель
Оркестрация	LangChain	LlamaIndex, кастомный пайплайн

---

Выводы

RAG для медицинской клиники — это не «поставил и забыл». Архитектура требует продуманной работы с неоднородными данными, правильного чанкинга под специфику медицинских документов, гибридного поиска и обязательного fallback-механизма.

Ключевые решения, которые отличают рабочую систему от туториального прототипа:

1. API-интеграция с МИС для прайса и расписания — не файловая выгрузка
2. Документо-специфичный чанкинг — не universal chunking
3. Гибридный поиск (vector + BM25 + reranker) — не просто cosine similarity
4. Порог релевантности и fallback — не попытка ответить на всё
5. Операционный процесс обновления данных — не только техническое решение

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

---

Поделимся опытом

hello@vibelab.ru

8 800 201 85 68

Написать в Telegram