RAG в 2024 году: почему все возвращаются к ретривелю и как это делать правильно

От скепсиса к ренессансу: почему RAG снова в моде

В 2023 году казалось, что RAG (Retrieval-Augmented Generation) превратился в модное слово, которое используют все, но толком не понимает никто. Началось с простых демок, где GPT отвечала на вопросы по PDF. Потом пришло разочарование: контекстные окна выросли до 128K токенов, зачем тогда ретривер? Загрузи весь документ в промпт и работай.

А потом все снова вернулись к ретривелю.

Причина проста: большие контекстные окна - это иллюзия. Да, вы можете засунуть туда целый роман Толстого. Но модель все равно будет искать ответ в первых и последних абзацах. Середина? Забудьте. Это как пытаться найти иголку в стоге сена, который постоянно подбрасывают в костер.

В 2024 все поняли: RAG - это не костыль для маленьких контекстов. Это архитектурный паттерн для управления вниманием модели. Вы не даете ей весь стог сена. Вы даете несколько самых релевантных иголок. И она наконец-то начинает шить.

Chunk size: цифра, которая решает все

Вот где большинство проектов проваливаются сразу после старта. Берут библиотеку LangChain, вызывают RecursiveCharacterTextSplitter с размером чанка 500 символов и думают, что задача решена.

А потом удивляются, почему система не понимает контекст.

Размер чанка - это не технический параметр. Это философский выбор. Что вы хотите найти?

• Факты (даты, имена, цифры)? Маленькие чанки (200-500 токенов)
• Концепции (объяснение теории, параграфы)? Средние чанки (500-1000 токенов)
• Сюжеты (истории, нарративы)? Большие чанки (1000-2000 токенов)

Проблема в том, что одна и та же система должна работать со всеми тремя типами. Решение? Иерархический chunking.

1 Иерархический chunking: как не резать вслепую

Представьте, что у вас техническая документация. Вы не можете резать ее на равные куски. Заголовок раздела должен остаться с его содержанием. Сноски должны остаться с текстом, к которому относятся.

# ПЛОХО: так делает 90% разработчиков
from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50
)
chunks = splitter.split_text(document)

# ХОРОШО: учитываем структуру документа
def hierarchical_chunking(document, max_chunk_size=1000):
    chunks = []
    current_chunk = []
    current_size = 0
    
    # Сначала делим на семантические блоки (разделы, параграфы)
    for paragraph in document.split('\n\n'):
        paragraph_size = len(paragraph.split())
        
        if current_size + paragraph_size > max_chunk_size:
            # Сохраняем текущий чанк
            if current_chunk:
                chunks.append('\n\n'.join(current_chunk))
                current_chunk = []
                current_size = 0
            
        current_chunk.append(paragraph)
        current_size += paragraph_size
    
    if current_chunk:
        chunks.append('\n\n'.join(current_chunk))
    
    return chunks

Это базовая идея. На практике нужно учитывать Markdown-заголовки, HTML-теги, LaTeX-окружения. Каждый тип документа требует своего алгоритма.

Ретривер для временных рядов: когда даты важнее слов

Стандартные эмбеддинги (OpenAI, Cohere) хороши для семантического поиска. Но они не понимают время. Запрос "продажи за последний квартал" и "продажи за 2020 год" будут иметь почти одинаковые эмбеддинги.

А это катастрофа для финансовых отчетов, логов, временных рядов.

Решение - гибридный поиск:

1. Временной фильтр: сначала отбираем документы по дате (например, за последние 30 дней)
2. Семантический поиск: в отфильтрованных документах ищем по смыслу
3. Ранжирование: комбинируем временную релевантность и семантическую

# Пример ретривера для временных рядов
import pandas as pd
from datetime import datetime, timedelta
from sentence_transformers import SentenceTransformer

class TimeSeriesRetriever:
    def __init__(self):
        self.model = SentenceTransformer('all-MiniLM-L6-v2')
        self.data = []  # Список словарей с полями: text, timestamp, embedding
    
    def add_document(self, text, timestamp):
        embedding = self.model.encode(text)
        self.data.append({
            'text': text,
            'timestamp': timestamp,
            'embedding': embedding
        })
    
    def retrieve(self, query, time_window_days=30, top_k=5):
        query_embedding = self.model.encode(query)
        
        # Фильтрация по времени
        cutoff_date = datetime.now() - timedelta(days=time_window_days)
        recent_data = [d for d in self.data if d['timestamp'] > cutoff_date]
        
        if not recent_data:
            # Если нет свежих данных, берем все
            recent_data = self.data
        
        # Семантический поиск
        similarities = []
        for doc in recent_data:
            similarity = cosine_similarity(query_embedding, doc['embedding'])
            
            # Усиление релевантности для свежих документов
            recency_score = 1.0 - (datetime.now() - doc['timestamp']).days / 365
            
            combined_score = 0.7 * similarity + 0.3 * recency_score
            similarities.append((combined_score, doc['text']))
        
        # Сортировка и возврат
        similarities.sort(reverse=True, key=lambda x: x[0])
        return [text for _, text in similarities[:top_k]]

Этот подход работает не только с датами. Любая числовая метаинформация (версия API, цена, рейтинг) может стать частью ранжирования.

Эксперименты с RAG: как не сойти с ума от метрик

Вы запустили RAG-систему. Как понять, что она работает хорошо? Точность? Полнота? Что это вообще значит в контексте генерации?

Большинство команд измеряют одно: "нравится ли ответ пользователю". Это субъективно и не масштабируется.

Вот метрики, которые имеют смысл:

Самая опасная метрика - "Answer Faithfulness". Модель может дать правильный ответ, но не из тех источников, которые вы ей предоставили. Она просто знала это заранее. И когда появится вопрос, на который она не знает ответа, она начнет галлюцинировать.

Forecasting с RAG: когда прошлое должно предсказывать будущее

Самое интересное применение RAG в 2024 - это не Q&A. Это прогнозирование.

Представьте: у вас есть исторические данные о продажах, новости компании, отчеты аналитиков. Пользователь спрашивает: "Какие будут продажи в следующем квартале?".

Обычный RAG даст исторические цифры. RAG с forecasting должен дать прогноз.

Как это работает:

1. Ретривер находит релевантные исторические данные
2. Система извлекает паттерны (сезонность, тренды)
3. Генератор создает не просто ответ, а прогноз с обоснованием

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

forecasting_prompt = """Ты финансовый аналитик. На основе предоставленных исторических данных:

{context}

Проанализируй тренды, сезонность и паттерны. Затем спрогнозируй значения на следующие {forecast_period}.

Твой ответ должен содержать:
1. Краткий анализ исторических данных
2. Прогноз с пояснением метода
3. Уровень уверенности в прогнозе (высокий/средний/низкий)
"""

Это работает удивительно хорошо для качественных прогнозов. Для количественных лучше комбинировать LLM с классическими статистическими моделями.

Ошибки, которые убьют ваш RAG

Я видел десятки провальных внедрений. Вот топ-5 ошибок:

1. Эмбеддинги по умолчанию
BERT-эмбеддинги хороши для общего языка. Для специфичных доменов (медицина, юриспруденция, код) нужны дообученные модели. Если ваша тема - эмбеддинги слепое пятно RAG, вы уже проиграли.

2. Игнорирование метаданных
Дата создания, автор, тип документа, версия - это не просто поля в базе. Это мощные фильтры для ретривера. Пользователь спрашивает "последнюю инструкцию" - фильтруйте по дате. "Официальный документ" - фильтруйте по автору.

3. Статический chunk size
Я уже говорил об этом, но повторю: один размер для всех документов - гарантия провала. Технические мануалы режьте по разделам. Новостные статьи - целиком. Код - по функциям.

4. Отсутствие реранжирования
Косинусная близость эмбеддингов - это только первый этап. Нужен реранкер (переранжировщик), который оценит, насколько чанк действительно отвечает на вопрос. ColBERT, Cross-Encoder - выбирайте любой, но не пропускайте этот шаг.

5. RAG как черный ящик
Самая опасная ошибка. Вы не понимаете, почему система выбрала именно эти чанки. Добавляйте логирование, визуализацию, отладку. Когда пользователь получает странный ответ, вы должны за 30 секунд понять, какие чанки были использованы и почему.

Что дальше? RAG в 2025 и дальше

Тренды, которые уже видны:

• Мультимодальность: поиск по картинкам, видео, аудио. Multi-modal RAG перестает быть экзотикой.
• Агентные архитектуры: RAG становится частью агента, который сам решает, когда и что искать.
• Локальность: с ростом моделей типа Llama 3.1 405B люди хотят все держать у себя. Без отправки данных в облако.
• Специализация: универсальные RAG-системы умирают. Появляются решения для медицины, юриспруденции, финансов.

Мой прогноз: через год мы будем смеяться над нашими текущими реализациями RAG. Так же, как сейчас смеемся над RAG 2022 года, который был просто "поиском по векторной базе".

Но фундаментальная идея останется: давать модели только нужную информацию в нужный момент. Это не временное решение. Это архитектурный паттерн на десятилетия.

Как RAG 2026 будет выглядеть? Как естественное расширение памяти модели. Не отдельный модуль, а вшитый механизм внимания к внешним данным.

А пока - начните с chunk size. Серьезно. Перестаньте использовать 500 токенов для всего. Посмотрите на ваши данные глазами пользователя. Что они ищут? Факты или нарративы? И режьте соответственно.

И да, добавьте временные фильтры. Прямо сейчас. Пока не забыли.