Продвинутые техники RAG: как достичь максимальной точности

От базового поиска к экспертным системам: оптимизация RAG для продакшена.
Продвинутые техники оптимизации RAG: от базового поиска к экспертным системам
Базовый RAG работает по принципу "найти похожие документы и сгенерировать ответ". Для простых сценариев этого достаточно, но в продакшене возникают проблемы: нерелевантные результаты, потеря контекста, неточное ранжирование. Продвинутые техники решают эти ограничения, превращая RAG в высокоточную экспертную систему.
Ограничения базового семантического поиска
Семантический поиск анализирует смысл запроса, но может пропускать важные детали. Рассмотрим запрос: "Что случилось с инцидентом INC-2023-Q4-011?"
Проблема: Система может вернуть документ о кибербезопасности (концептуально релевантный), но пропустить конкретный отчет об инциденте с точным номером.
Причина: Модели эмбеддингов фокусируются на общем смысле, а не на специфических идентификаторах.
Гибридный поиск: комбинация семантического и лексического подходов
Принцип работы
Гибридный поиск запускает параллельно два алгоритма:
Семантический поиск (Dense Retrieval)
- Использует векторные эмбеддинги для понимания смысла
- Эффективен для синонимов и парафраз
- Находит концептуально похожие документы
Лексический поиск (Sparse Retrieval)
- Алгоритм BM25 ищет точные совпадения терминов
- Учитывает частотность слов (редкие термины получают больший вес)
- Отлично работает с идентификаторами, номерами, специфической терминологией
Алгоритм BM25
BM25 (Best Matching 25) оценивает документы по формуле:
Score = IDF(qi) × f(qi,D) × (k1 + 1) / (f(qi,D) + k1 × (1 - b + b × |D| / avgdl))
Где: IDF(qi) — обратная частота документа для термина qi, f(qi,D) — частота термина в документе D, k1, b — параметры настройки (обычно k1=1.2, b=0.75), |D| — длина документа, avgdl — средняя длина документа.
Ключевой принцип: Редкие термины получают высокий вес, частые (предлоги, союзы) — низкий.
Объединение результатов: Reciprocal Rank Fusion (RRF)
Проблема комбинирования заключается в разных системах оценки релевантности. Семантический поиск возвращает косинусное сходство (0-1), BM25 — собственную метрику. Прямое сравнение некорректно.
Решение RRF: Используем позиции документов в ранжированных списках.
Формула RRF: RRF(d) = Σ 1 / (k + rank_i(d))
Где k — константа сглаживания (обычно 60), rank_i(d) — позиция документа d в i-том результате.
Пример расчета:
Запрос: "статус проекта Phoenix"
Семантический поиск:
1. Документ A (отчет о проекте Phoenix)
2. Документ B (планы разработки)
3. Документ C (бюджет проекта)
BM25 поиск:
1. Документ C (содержит "Phoenix" в заголовке)
2. Документ A (содержит "статус", "проект")
3. Документ D (другой контекст)
RRF баллы:
• Документ A: 1/61 + 1/62 = 0.0328
• Документ C: 1/63 + 1/61 = 0.0323
• Документ B: 1/62 + 0 = 0.0161
Финальное ранжирование: A, C, B, D
Переранжирование результатов (Re-ranking)
Гибридный поиск улучшает полноту результатов, но не всегда правильно расставляет приоритеты. Переранжирование добавляет слой интеллектуального анализа.
Cross-encoder модели
В отличие от bi-encoder (раздельное кодирование запроса и документа), cross-encoder анализирует пары "запрос-документ" совместно. Это дает более точную оценку релевантности, но требует больше вычислений.
Популярные модели:
- ms-marco-MiniLM-L-12-v2: Обучена на датасете MS MARCO
- bge-reranker-large: Multilingual модель с хорошей производительностью
- cohere-rerank-multilingual: Commercial API с поддержкой русского языка
LLM-based переранжирование
Использование языковой модели для переоценки релевантности:
Задача: Переранжируй документы по релевантности запросу пользователя.
Запрос: "Какие изменения внесли в политику отпусков для IT отдела?"
Документы:
1. [ID: doc_1] "Политика отпусков компании - общие положения..."
2. [ID: doc_2] "Изменения в HR политике IT отдела от 15.01.2024..."
3. [ID: doc_3] "Календарь отпусков на 2024 год..."
Верни только ID документов в порядке убывания релевантности: ["doc_2", "doc_1", "doc_3"]
Преимущества LLM-переранжирования:
- Понимание контекста и нюансов запроса
- Способность различать специфику ("IT отдел" vs общая политика)
- Гибкость в критериях ранжирования
Недостатки:
- Дополнительные затраты на API
- Увеличение латентности
- Зависимость от качества промпта
Контекстуальный поиск (Contextual Retrieval)
Проблема потери контекста при чанкинге
При разбиении документа каждый чанк теряет связь с общим контекстом:
Исходный чанк: "Проект был завершен в декабре с превышением бюджета на 15%"
Проблема: Какой проект? Из какого отчета? Какого года декабрь?
Процесс контекстуализации
Шаг 1: Анализ окружающего контекста. Для каждого чанка анализируются предыдущие 2-3 чанка из того же документа, заголовки и подзаголовки, метаданные документа (название, дата, автор).
Шаг 2: Генерация контекстного описания. LLM создает краткое описание, помещающее чанк в контекст документа.
Документ: "Годовой отчет IT департамента за 2023 год"
Раздел: "Проект Phoenix - модернизация инфраструктуры"
Чанк: "Проект был завершен в декабре с превышением бюджета на 15%"
Добавь 1-2 предложения контекста для улучшения поиска:
Результат: "Из годового отчета IT департамента: проект Phoenix по модернизации инфраструктуры был завершен в декабре с превышением бюджета на 15%"
Шаг 3: Индексация контекстуализированного чанка. В векторную базу сохраняется чанк с добавленным контекстом, что улучшает качество поиска.


