Для медицинской базы вопрос-ответ, юридической документации или финансовой отчётности цена ошибки RAG-системы не «неловко получилось», а неверная дозировка, пропущенное противопоказание или судебный риск. Общая архитектура из статьи про создание RAG-системы — это необходимый минимум, но для таких доменов нужны ещё три вещи: эмбеддинги, которые понимают профессиональную терминологию, механизм, который умеет сказать «не знаю» до того, как начал отвечать, и процесс проверки качества, который ловит ошибки до продакшена. Разбираем все три на примере базы вопрос-ответ для врачей.
Специфичные эмбеддинги: почему общей модели не хватает
Универсальные эмбеддинги (OpenAI text-embedding-3, аналоги) обучены на широком срезе интернета и неплохо понимают общий смысл фраз. Проблема — в тонких различиях, которые в медицине решают всё:
- «Гипергликемия» и «гипогликемия» — противоположные состояния, но отличаются на одну букву и лежат близко в общем векторном пространстве, если модель не видела достаточно медицинских текстов, чтобы научиться разводить их уверенно.
- Синонимия лекарств: «ацетилсалициловая кислота» и «аспирин» для универсальной модели — это два разных объекта, если в обучающей выборке недостаточно медицинской литературы, где они систематически встречаются рядом.
Специализированные эмбеддинги — модели, дообученные на медицинских корпусах (PubMedBERT, BioBERT, S-PubMedBert и аналогичные для русскоязычных медицинских текстов) — держат такие различия увереннее, потому что видели миллионы пар «термин — контекст» именно из клинической литературы, а не из смеси новостей, форумов и художественных текстов.
Практический вывод для построения RAG-системы в узком домене: universal-модель — нормальная отправная точка на этапе прототипа, но перед продакшеном стоит сравнить её с доменной моделью на своём тестовом наборе вопросов — разница в recall (нашла ли система вообще нужный документ) на терминологически плотных запросах может быть существенной.
Self-RAG: модель, которая сначала думает, потом ищет
Обычный RAG работает по жёсткой схеме: пришёл вопрос → всегда идём в поиск → всегда отвечаем по тому, что нашли. Проблема в двух крайних случаях:
- Вопрос вообще не требует поиска в базе («как рассчитывается доза по весу пациента» — это общая формула, не специфичный факт из конкретного протокола) — но система всё равно тратит время и токены на поиск.
- Поиск нашёл что-то, но это «что-то» слабо релевантно — а RAG всё равно отвечает по нему, потому что не умеет оценить, что найденное не подходит.
Self-RAG — подход, где модель дообучена (или направлена промптом с рассуждением) сама принимать два решения до генерации финального ответа:
Шаг 1 — Retrieve?
Нужен ли для ответа на этот вопрос поиск по базе знаний,
или это общий вопрос, на который можно ответить и так?
Шаг 2 — Relevant?
Для каждого найденного чанка: отвечает ли он на заданный
вопрос напрямую, косвенно или не отвечает вовсе?
Шаг 3 — Supported?
Подтверждает ли отобранный контекст каждое утверждение
в черновике ответа, или часть ответа выходит за рамки контекста?Для медицинской базы это выглядит так: на вопрос «какая нормальная температура тела у взрослого» модель может честно ответить сама, без похода в базу протоколов. А на вопрос «какая стартовая доза варфарина при мерцательной аритмии у пациента 70 лет» — обязана искать, и если найденный протокол не покрывает именно эту комбинацию (возраст + диагноз), явно сообщить об этом, а не экстраполировать по общей логике.
Чтобы RAG понимал документ целиком, а не только чанк
Один из самых частых источников плохих ответов — не отсутствие нужного факта в базе, а то, что чанк, который нашёл поиск, вырван из контекста документа. Классический пример: протокол лечения начинается с раздела «Исключения», где написано «схема ниже не применяется при почечной недостаточности» — а поиск находит только чанк с самой схемой, потому что по запросу «доза препарата X» именно он получил наивысший score. Модель отвечает дозой, не зная про исключение из соседнего раздела.
Два рабочих способа так не делать при построении RAG-системы:
Parent-document retrieval. Индексируем для поиска маленькие чанки (точный retrieval), но в контекст модели передаём более крупный родительский блок — например, весь раздел документа, к которому принадлежит найденный чанк, а не только сам чанк. Поиск остаётся точным, а модель видит соседние оговорки, исключения и условия.
Индекс (для поиска): чанк 200-400 токенов
Контекст (для генерации): вся секция документа (родитель чанка),
включая заголовок раздела и примечанияКонтекстные резюме документа. Перед каждым чанком в индексе храним короткое сгенерированное заранее резюме всего документа («Протокол ведения пациентов с ХСН, версия от 2025 года, раздел о дозировании диуретиков») — так при поиске система видит не только сам чанк, но и его место в общей структуре, даже без похода за родительским блоком. Это тот же принцип, что лежит в основе техники contextual retrieval: короткая контекстная подпись к чанку резко снижает число ошибок поиска, вызванных потерей общего контекста документа.
Оба способа решают одну и ту же проблему с разных сторон: чанк остаётся маленьким и точным для поиска, но модель на выходе видит структуру и контекст, а не изолированный обрывок.
Валидация качества ответов RAG
Прежде чем выкатывать медицинскую RAG-систему в продакшен, нужен тестовый прогон на заранее собранном наборе вопросов с эталонными ответами и источниками. Стандартный набор автоматических метрик (в духе RAGAS):
| Метрика | Что проверяет | Пример проблемы, которую ловит |
|---|---|---|
| Faithfulness | Не противоречит ли ответ найденному контексту | Модель «додумала» дозировку, которой не было в тексте |
| Context precision | Не замусорен ли контекст нерелевантными чанками | Поиск притащил документ не по теме, но с похожими словами |
| Context recall | Нашёл ли поиск вообще все нужные для полного ответа документы | Ответ по дозировке есть, но упущено противопоказание из другого раздела |
| Answer relevancy | Отвечает ли ответ на заданный вопрос, а не на смежный | Вопрос про детскую дозу, ответ — про взрослую |
Автоматические метрики хорошо ловят системные ошибки на больших наборах вопросов, но для медицины (и любого домена с высокой ценой ошибки) их не заменяет, а дополняет ручная проверка: врач-эксперт должен вслепую пройти по выборке реальных ответов системы и явно промаркировать каждый как «безопасно/небезопасно», прежде чем систему допустят до реальных пользователей. Автоматические метрики — фильтр для регрессионного тестирования при каждом изменении промпта или модели, а не финальная приёмка.
Что дальше
Специфичные эмбеддинги, Self-RAG и работа со структурой документа — это доменная надстройка над базовой архитектурой. Если ещё не сделан первый проход по основам — начните со статьи «Как создать эффективную RAG-систему»: там гибридный поиск, сегментация, ранжирование и промпты. А если ваш случай — не документы-протоколы, а каталог товаров, специфика другая: смотрите «RAG для каталога товаров: продукты и оборудование».
Коротко
Зачем медицинской RAG-системе отдельные эмбеддинги?
Универсальные эмбеддинги хуже различают близкие по форме, но разные по смыслу медицинские термины — разница проявляется на редких терминах и синонимах лекарств, которых мало в общей обучающей выборке.
Что такое Self-RAG простыми словами?
Модель сама решает, нужен ли вообще поиск, и сама оценивает, достаточно ли релевантен найденный контекст, прежде чем отвечать — вместо того чтобы всегда искать и всегда отвечать по найденному.
Как проверить качество ответов RAG-системы до запуска?
Тестовый набор вопросов с эталонами, метрики faithfulness и context precision/recall, плюс обязательная ручная проверка экспертом для критичных доменов.
Почему RAG возвращает вырванный из контекста кусок вместо полного ответа?
Потому что поиск ищет по чанкам независимо от документа целиком. Решение — parent-document retrieval и контекстные резюме чанков.
Нужна RAG-система для профессиональной базы знаний с высокой ценой ошибки — пишите нам через форму на сайте, обсудим архитектуру и валидацию.