Сравнение RAG и Long Context: Когда векторная база не нужна
Введение: Смена парадигмы в работе с большими данными
Добро пожаловать на один из самых важных уроков этого модуля. Сегодня мы затронем тему, которая вызывает самые жаркие споры среди AI-инженеров: действительно ли нам всё ещё нужен RAG (Retrieval-Augmented Generation)?
Ещё год назад ответ был однозначным: «Да, конечно». Если у вас была книга, документация или база знаний, вы не могли просто «скормить» её модели. Контекстные окна были маленькими (4k, 8k, 32k токенов). Единственным выходом было нарезать текст на кусочки (чанки), превратить их в векторы и искать похожие фрагменты по запросу.
Но с появлением Gemini 1.5 Pro и теперь Gemini 3, обладающих контекстным окном в 1-2 миллиона токенов и более, правила игры изменились. Мы переходим от архитектуры «Найди похожий кусочек» к архитектуре «Прочитай всё и ответь».
В этом уроке мы разберем физику этого процесса, экономику (что дешевле?) и качество (что умнее?).
Анатомия проблемы: RAG против Long Context
Давайте честно посмотрим на то, как работают оба подхода. Это поможет понять, почему векторные базы данных иногда становятся «костылем», а не решением.
Классический RAG (Retrieval-Augmented Generation)
RAG работает по принципу поисковика. Вы задаете вопрос, система ищет 3-5 фрагментов текста, которые кажутся релевантными, и передает их модели.
- Плюс: Работает с данными любого объема (хоть весь интернет). Дешево за один запрос (мало токенов на вход).
- Минус (Проблема «Потери контекста»): Если ответ на ваш вопрос требует понимания всей книги целиком (например, «Как менялся характер героя с 1 по 10 главу?»), RAG провалится. Он найдет лишь отдельные упоминания героя, но не увидит арку развития. RAG страдает от фрагментации.
Long Context (Полный контекст)
Вы загружаете в Gemini 3 всю книгу, все контракты или часовое видео целиком.
- Плюс (Global Reasoning): Модель видит всё. Она может находить связи между страницей 5 и страницей 500. Она понимает неявные паттерны. Это называется «Глобальным рассуждением».
- Минус (в прошлом): Это было дорого и медленно. Обрабатывать 1 миллион токенов для каждого вопроса — безумие.
- Решение от Gemini: Context Caching.
Именно кэширование контекста делает подход Long Context не просто возможным, а часто предпочтительным.
# Сравнение подходов в коде (псевдокод и реальный API)
import google.generativeai as genai
# --- ПОДХОД 1: RAG (Упрощенно) ---
# Требует настройки Vector DB, Embeddings Model, Retriver
# 1. Chunking: разбиваем текст на куски по 500 токенов
# 2. Embedding: vector_db.add(chunks)
# 3. Retrieval: relevant_chunks = vector_db.search(query)
# 4. Generation:
# prompt = f"Context: {relevant_chunks}\nQuestion: {query}"
# response = model.generate_content(prompt)
# --- ПОДХОД 2: Long Context с Caching (Gemini Way) ---
# Гораздо меньше инфраструктурного кода.
# Загружаем огромный файл (например, финотчет за год, 500 страниц)
file_path = 'annual_report_full.pdf'
file_ref = genai.upload_file(file_path)
# Создаем кэш, так как будем задавать много вопросов этому документу
cache = genai.caching.CachedContent.create(
model='models/gemini-1.5-pro-002', # или gemini-3-pro
display_name='annual_report_cache',
system_instruction='Ты финансовый аналитик. Отвечай точно по документу.',
contents=[file_ref],
ttl='3600s' # Живет 1 час
)
# Теперь модель имеет доступ ко ВСЕМУ документу мгновенно
model = genai.GenerativeModel.from_cached_content(cached_content=cache)
response = model.generate_content("Проанализируй риски, упомянутые в начале отчета, и сопоставь их с итогами в конце.")
print(response.text)Когда RAG проигрывает: Тест «Иголка в стоге сена»
Существует стандартный бенчмарк NIAH (Needle In A Haystack). В огромный текст (стог сена) вставляется случайный факт (иголка). Например, в «Войну и мир» вставляют фразу: «Секретный код для запуска — 4815162342».
Результаты тестов Gemini 1.5/3:
Модели показывают >99% recall (воспроизведение) даже на окне в 2M токенов. Они находят факт, где бы он ни находился.
Почему RAG здесь может ошибиться?
Если вопрос пользователя не содержит ключевых слов, идеально совпадающих с «иголкой» (семантически или лексически), векторный поиск может выдать не тот кусок текста. Векторный поиск — это вероятностный процесс. Long Context — это детерминированный процесс внимания (Attention mechanism) ко всему массиву данных.
Сценарии, где Long Context убивает RAG:
- Summarization (Суммаризация): «Составь краткое содержание всей книги». RAG физически не может это сделать, так как не видит книгу целиком.
- Q&A по видео/аудио: RAG требует транскрибации, потери интонации и визуального ряда. Gemini в Long Context принимает видео нативно.
- Сложная аналитика: «Найди противоречия между показаниями свидетеля А (в начале дела) и свидетеля Б (в конце дела)».
Экономика: Математика токенов
Вы можете спросить: «Но разве подавать 1 миллион токенов не дорого?». Да, если делать это каждый раз заново.
Здесь в игру вступает Context Caching, который мы разбирали в начале модуля. Давайте посчитаем экономику для типичной задачи: у вас есть документация проекта (500,000 токенов) и вы хотите задать 100 вопросов по ней.
Без кэширования (Native Long Context):
- Вход: 500k токенов * 100 запросов = 50 миллионов токенов на обработку.
- Вердикт: Безумно дорого.
С RAG:
- Вход: ~2k токенов (найденные чанки) * 100 запросов = 200 тысяч токенов.
- Плюс стоимость векторной базы и эмбеддингов.
- Вердикт: Дешево, но теряем качество.
С Context Caching (Gemini):
- Вход (Загрузка в кэш): 500k токенов (платим 1 раз, дешевле обычного входа).
- Хранение: Плата за час хранения (копейки).
- Запросы: Платим только за текст вопроса и ответ модели. Сами 500k токенов в кэше не тарифицируются как полный ввод при каждом запросе!
- Вердикт: Стоимость сравнима с RAG, но качество как у Long Context.
Золотое правило: Если контекст статичен (документ, видео, кодовая база) и вы планируете задать к нему много вопросов — Long Context + Caching выигрывает по соотношению цена/качество.
Вы разрабатываете бота-помощника для HR-департамента. У вас есть 'Положение о персонале' и 'Трудовой кодекс' общим объемом 300,000 токенов. Сотрудники задают около 500 вопросов в день. Документы меняются раз в год.<br><br>Задание: Выберите оптимальную архитектуру (RAG или Long Context + Cache) и обоснуйте выбор по двум критериям: 1) Точность ответов на сложные вопросы (например, 'Можно ли мне в отпуск, если я проработал 5 месяцев, но являюсь льготником?'). 2) Сложность поддержки кода.
Когда векторная база (RAG) всё ещё необходима?
Я не хочу, чтобы у вас сложилось впечатление, что векторные базы умерли. Они просто сменили сферу применения. Есть зоны, куда Long Context (даже с окном в 10М токенов) не дотянется.
Используйте RAG, если:
- Объем данных превышает 2-10 миллионов токенов. Если у вас архив за 10 лет, петабайты данных — ни один контекст это не вместит. Здесь RAG используется как первый этап фильтрации.
- Высокая динамика данных. Если данные меняются каждую минуту (например, лента новостей или биржевые сводки), пересоздавать кэш будет слишком дорого и медленно. Векторную базу обновлять проще (добавил один вектор, удалил старый).
- Latency (Задержка) критически важна. Поиск по векторам (миллисекунды) + генерация по малому контексту всё ещё быстрее, чем обработка огромного кэша, хотя разрыв стремительно сокращается.
- Многопользовательская изоляция. Если у каждого юзера свой уникальный контекст (личные заметки), кэшировать всё подряд может быть неэффективно.
Гибридный подход (RAG + Long Context)
Самый мощный паттерн современной разработки — это гибрид. Вы используете RAG (или даже обычный SQL поиск), чтобы сузить выборку с 1 миллиарда документов до 50-100 документов (объемом, скажем, 500к токенов). А затем вы загружаете эти 50 документов в Long Context Gemini для финального анализа.
Это дает лучшее из двух миров: масштабируемость поиска и глубину понимания LLM.
В каком из перечисленных случаев использование Long Context (с кэшированием) будет ЯВНОЙ ошибкой по сравнению с RAG?