Что такое Self-RAG и когда его использовать?

Краткий тезис

Self-RAG (Self-Reflective Retrieval-Augmented Generation — это архитектура, где LLM сама решает, когда и как использовать retrieval. В отличие от обычного RAG, где поиск документов происходит всегда (или по простому правилу), Self-RAG использует рефлексию — модель оценивает необходимость поиска, качество найденных документов и корректность своего ответа. Self-RAG генерирует цитаты (ссылки на источники) и может отказаться от ответа, если информация недостоверна.

Ключевая идея Один LLM выполняет три роли: решает, нужно ли искать, ищет, генерирует ответ, проверяет себя.


1. Термин: Self-RAG (Self-Reflective RAG)

Что это Фреймворк от исследователей из UIUC и Microsoft (2023), где LLM обучается генерировать специальные рефлексивные токены (reflection tokens), управляющие процессом retrieval.

Термин «Рефлексивные токены» (Reflection tokens Специальные служебные токены, которые модель генерирует, чтобы сигнализировать о своих действиях:

ТокенЗначение
[Retrieve]Нужно выполнить поиск документов
[NoRetrieve]Поиск не нужен (ответ из знаний модели)
[Relevant]Найденные документы релевантны
[Irrelevant]Документы не релевантны
[Useful]Документы полезны для ответа
[NotUseful]Документы бесполезны
[Support]Ответ подтверждается документами
[Contradict]Документы противоречат ответу

Пример генерации Self-RAG

Вопрос: "Кто написал 'Войну и мир'?"

[Retrieve] → поиск документов → [Relevant] → генерация ответа с цитатой:
"Лев Толстой [Support]"

[NoRetrieve] → вопрос о погоде → ответ без поиска:
"Не знаю, я не обучен на погодных данных"

2. Как работает Self-RAG (архитектура)

2.1 Обучение Self-RAG

Self-RAG требует специального обучения (fine-tuning) модели на данных с рефлексивными токенами.

Этапы обучения

ЭтапЧто делаетсяИсточник данных
1. Сбор данныхГенерация примеров с рефлексивными токенамиGPT-4 генерирует размеченные примеры
2. Supervised fine-tuningМодель учится предсказывать рефлексивные токеныПары (инструкция, ответ с токенами)
3. Оценка (critic)Обучение модели оценивать релевантность и полезностьПромпты: "Релевантен ли этот документ?"

Важно Self-RAG — это не просто промпт-инжиниринг, а дообученная модель.


2.2 Инференс Self-RAG (как работает во время использования)

Пользовательский запрос
         │
         ▼
┌─────────────────────────────────────────────────────────────┐
│  Шаг 1: Decision (Retrieve или NotRetrieve?)                │
│  LLM решает: нужен ли поиск?                                │
│  • [Retrieve] → идём на шаг 2                               │
│  • [NoRetrieve] → генерируем ответ из знаний модели (шаг 5) │
└─────────────────────────────────────────────────────────────┘
         │ [Retrieve]
         ▼
┌─────────────────────────────────────────────────────────────┐
│  Шаг 2: Parallel Retrieval (параллельный поиск)             │
│  Retrieval находит K документов (например, 10)              │
└─────────────────────────────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────────────────────────────┐
│  Шаг 3: Critique (оценка документов)                        │
│  Для каждого документа D_i:                                 │
│  • LLM оценивает: [Relevant] или [Irrelevant]               │
│  • LLM оценивает: [Useful] или [NotUseful]                  │
│  Оставляем только документы с [Relevant] и [Useful]         │
└─────────────────────────────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────────────────────────────┐
│  Шаг 4: Generation (генерация ответа с цитатами)            │
│  Для каждого документа D_i (или для всех вместе):           │
│  • LLM генерирует часть ответа                              │
│  • Добавляет [Support] или [Contradict] после фактов        │
│  • Добавляет цитату (source_id)                             │
└─────────────────────────────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────────────────────────────┐
│  Шаг 5: Final ответ с ранжированием                         │
│  Выбираем лучший ответ (по score) или объединяем            │
└─────────────────────────────────────────────────────────────┘

3. Self-RAG vs обычный RAG: сравнение

ХарактеристикаОбычный RAGSelf-RAG
Когда выполняется retrievalВсегда (или по порогу)LLM решает
Оценка релевантности документовОтдельная модель (cross-encoder) или никакLLM сама оценивает
Проверка ответаНет (или отдельный шаг)LLM проверяет [Support]/[Contradict]
ЦитатыДобавляются принудительно (через промпт)LLM учится добавлять цитаты
Отказ от ответаПо порогу confidenceLLM может сказать [NoRetrieve]
Количество LLM вызовов1 (генерация)3-10 (решения + генерация)
LatencyНизкаяВысокая (в 3-5 раз дольше)
Сложность отладкиНизкаяВысокая (много решений)
Требует fine-tuningНет (можно с промптами)Да (обязательно)

Термин «Latency» Время ответа. Self-RAG дольше, потому что LLM вызывается несколько раз.


4. Когда использовать Self-RAG?

4.1 Идеальные сценарии

СценарийПочему подходит Self-RAG
Вопросы с разной потребностью в фактахОдни вопросы требуют поиска ("сколько стоит?"), другие — нет ("привет, как дела?"). Self-RAG сам решает
Диалоговые системы (multi-turnВ начале диалога — приветствие (без поиска), потом — фактологические вопросы (с поиском)
Высокие требования к достоверностиSelf-RAG проверяет ответ [Support] и может отказаться
Требование цитированияЮридические, медицинские системы (каждый факт должен иметь источник)
Динамические знанияДокументы часто меняются, нужно всегда проверять актуальность

Пример диалога

User: Привет!                    → [NoRetrieve] → "Здравствуйте!"
User: Что нового в последней версии продукта? → [Retrieve] → ответ с цитатами
User: Спасибо!                   → [NoRetrieve] → "Пожалуйста!"

4.2 Когда НЕ стоит использовать Self-RAG

СценарийПочему не подходит
Низкая latency (быстрые ответыSelf-RAG в 3-5 раз медленнее обычного RAG
Дешёвое решение (low costМного LLM вызовов → дорого
Нет возможности fine-tuneSelf-RAG требует дообучения модели
Простой use case (всегда нужен поискОбычный RAG проще и быстрее
Мало вычислительных ресурсовSelf-RAG требует мощного GPU для нескольких LLM вызовов

5. Альтернативы Self-RAG (что проще)

5.1 Adaptive-RAG

Что это Более простая альтернатива, где классификатор (не LLM) решает, нужен ли retrieval.

Архитектура

Запрос → Классификатор (BERT) → 
          ├── "need_search" → RAG
          └── "no_search" → LLM без RAG
ХарактеристикаSelf-RAGAdaptive-RAG
Кто решаетLLM (рефлексия)Классификатор (BERT/RoBERTa)
Требует fine-tune LLMДаНет (классификатор отдельно)
LatencyВысокаяНизкая
СложностьВысокаяНизкая
Качество решенийЛучше (LLM понимает контекст)Хуже (бинарный классификатор)

Когда Adaptive-RAG лучше Когда нужна простота, низкая latency и нет ресурсов на fine-tune LLM.


5.2 Обычный RAG с порогом (threshold)

Что это Самое простое решение — всегда делать поиск, но можно добавить порог confidence.

# Простейший "adaptive" подход
results = vector_search(query)
max_score = max(r.score for r in results)

if max_score > 0.7:
    # Есть релевантные документы → RAG
    return generate_with_context(query, results)
else:
    # Нет релевантных → общая LLM
    return generate_without_context(query)

Плюсы Очень просто, не требует дообучения. Минусы Классификатор по порогу хуже понимает сложные запросы.


6. Сравнительная таблица: RAG → Adaptive-RAGSelf-RAG

ХарактеристикаОбычный RAGAdaptive-RAGSelf-RAG
Retrieval решениеВсегдаКлассификаторLLM рефлексия
Оценка документовНет/отдельнаяНет/отдельнаяLLM (Relevant/Useful)
Проверка ответаНетНетLLM (Support/Contradict)
ЦитатыПо промптуПо промптуОбучена генерировать
Fine-tune LLMНетНетДа
Latency1x1x (классификатор быстрый)3-5x
СтоимостьНизкаяНизкаяВысокая
Качество (сложные запросыСреднееХорошееЛучшее

7. Практический кейс (пример для собеседования)

«В проекте медицинского чат-бота мы сначала использовали обычный RAG — всегда искали документы. Проблема: на приветствия и общие вопросы ("Спасибо", "Что вы умеете?") система всё равно искала документы (бесполезно, дорого, медленно).

Мы попробовали Adaptive-RAG с классификатором DistilBERT (легковесный). Классификатор определял "разговорные" запросы (30% трафика) и отправлял их напрямую в LLM без поиска. Это снизило среднюю latency на 25% и стоимость на 20%.

Затем для сложных запросов (медицинские диагнозы) мы добавили элементы Self-RAG: модель оценивала, действительно ли найденные документы релевантны, и генерировала цитаты. Галлюцинации снизились с 8% до 3% ценой увеличения latency в 1.5 раза.»


8. Пет-проект для закрепления

Задача Реализовать Adaptive-RAG (упрощённую версию Self-RAG) и сравнить с обычным RAG.

Инструменты Python, Hugging Face (DistilBERT для классификатора), Qdrant, Llama-3

Шаги

  1. Создать датасет из 500 запросов:
    • 250 "разговорные" (приветствия, благодарности, small talk)
    • 250 "фактологические" (вопросы по документам)
  2. Обучить классификатор DistilBERT различать два типа запросов
  3. Реализовать Adaptive-RAG:
    • Запрос → классификатор
    • Если "фактологический" → RAG (поиск + генерация)
    • Если "разговорный" → LLM без поиска
  4. Сравнить с обычным RAG (всегда поиск) по метрикам:
  5. (Опционально, сложно) Попробовать Self-RAG с fine-tuning Llama-3 на рефлексивных токенах

Ожидаемый результат Adaptive-RAG быстрее и дешевле обычного RAG на 20-30% без потери качества.


Связь с другими вопросами

ВопросТема
1Обычный RAG (основа для сравнения)
5Оценка качества (faithfulness, галлюцинации)
8Обработка запросов без ответа (часть Self-RAG)
16Метрики качества генерации
41-60Оркестрация (агенты, Self-RAG как агент)
141-150Agentic RAG (где агент решает, когда искать)

10. Что такое Self-RAG и когда его использовать|10. Что такое Self-RAG и когда его использовать|10. Что такое Self-RAG и когда его использовать|10 полностью разобран. Переходим к вопросу 11, когда будете готовы|Вопрос 10 полностью разобран. Переходим к вопросу 11, когда будете готовы]]


Навигация