Управление длинным контекстом: Стратегии окна в 1М+ токенов

Введение: Сдвиг парадигмы или «Смерть RAG»?

Добро пожаловать в урок, который меняет правила игры. Долгое время в разработке ИИ-приложений мы жили в условиях жесткой экономии: контекстное окно в 4k, 8k или даже 32k токенов заставляло нас «нарезать» данные на мелкие кусочки, использовать векторные базы данных и молиться, чтобы алгоритм поиска (retrieval) нашел именно тот фрагмент, который нужен для ответа.

С приходом Gemini и окна в 1 миллион (и даже 2 миллиона) токенов, мы переходим от эпохи Retrieval (поиска) к эпохе Processing (обработки). Представьте, что 1 миллион токенов — это примерно:

• 700 000 слов;
• 50-60 часов аудиозаписей;
• 1 час видео высокого разрешения;
• 30 000 строк кода.

Это не просто увеличение буфера. Это возможность загрузить в модель всю документацию проекта, весь юридический кодекс или полную историю переписки с клиентом за 5 лет. Однако, «большая сила — это большая ответственность» (и большие задержки, если делать это неправильно).

В этом уроке мы разберем, как работать с таким объемом данных, не разориться на токенах, минимизировать галлюцинации и понять, когда классический RAG всё ещё нужен.

Феномен «Иголки в стоге сена» (NIAH) и внимание модели

Главный страх при работе с длинным контекстом — это проблема Lost in the Middle (потеря середины). Ранние модели хорошо помнили начало и конец промпта, но «забывали» информацию в середине. Gemini демонстрирует феноменальные результаты в тесте Needle In A Haystack (NIAH), достигая точности выше 99% даже при полной загрузке контекста.

Как это работает архитектурно?
В отличие от простого внимания (attention), Gemini использует оптимизированные механизмы (такие как Ring Attention), которые позволяют модели удерживать глобальные связи между удаленными частями текста. Это значит, что модель может найти связь между требованием на странице 10 и исключением на странице 950 технической документации.

1. Холистическое понимание: Модель «видит» весь документ сразу, что позволяет ей делать обобщения, которые невозможны при фрагментарном RAG-подходе.
2. Мультимодальность как стандарт: Длинный контекст — это не только текст. Вы можете загрузить видео семинара и спросить: «На какой минуте спикер упомянул архитектуру микросервисов?».
3. Инструкции имеют вес: В огромном море данных ваши инструкции (системный промпт) должны быть якорем.

import google.generativeai as genai
import os

# Настройка API
genai.configure(api_key=os.environ["GEMINI_API_KEY"])

# Выбор модели с поддержкой длинного контекста
model = genai.GenerativeModel('gemini-1.5-pro-latest')

# Функция для подсчета токенов перед отправкой
# Это критически важно для оценки стоимости и лимитов
def check_token_count(text_content, file_content=None):
    contents = [text_content]
    if file_content:
        contents.append(file_content)
        
    response = model.count_tokens(contents)
    print(f"Количество токенов: {response.total_tokens}")
    
    # Примерная оценка стоимости (условные цифры для примера)
    # В реальности цены меняются, всегда сверяйте с прайсом
    cost_per_million = 3.50  # $ за 1М входных токенов (Input)
    estimated_cost = (response.total_tokens / 1_000_000) * cost_per_million
    print(f"Примерная стоимость запроса: ${estimated_cost:.4f}")

# Пример использования
large_text = "Текст огромного документа... " * 5000
check_token_count(large_text)

Context Caching: Экономика больших данных

Главная проблема длинного контекста — это цена и латентность (задержка). Если вы каждый раз отправляете в модель книгу «Война и мир» (около 600к токенов), чтобы задать один вопрос, вы каждый раз платите за обработку этих 600к токенов. Это медленно и дорого.

Решение: Context Caching (Кэширование контекста).

Gemini позволяет вам загрузить контекст один раз, получить уникальный идентификатор кэша и ссылаться на него в последующих запросах. Это работает как «оперативная память» для вашей сессии.

• Как это работает: Вы загружаете файлы или текст в кэш. Кэш живет определенное время (TTL - Time To Live).
• Ценообразование: Вы платите за хранение кэша (дешево) и за ввод данных один раз. Последующие запросы к кэшу стоят значительно дешевле, чем повторная отправка данных.
• Когда использовать: Если вы планируете сделать к одному и тому же набору данных более 2-3 запросов, кэширование уже становится выгодным.

import google.generativeai as genai
from google.generativeai import caching
import datetime
import time

# Предположим, у нас есть большой файл 'manual.pdf' (загруженный через File API)
# В реальном коде сначала используется genai.upload_file(...)

# Создание кэша
cache = caching.CachedContent.create(
    model='models/gemini-1.5-pro-001',
    display_name='technical_manual_cache',
    system_instruction='Ты эксперт по технической поддержке. Используй данный мануал для ответов.',
    contents=[document_file_object], # объект файла после загрузки
    ttl=datetime.timedelta(minutes=60) # Кэш живет 60 минут
)

print(f"Кэш создан: {cache.name}")

# Использование кэша
# Обратите внимание: мы создаем модель, привязанную к кэшу
model_with_cache = genai.GenerativeModel.from_cached_content(cached_content=cache)

response = model_with_cache.generate_content("Как сбросить настройки устройства до заводских?")
print(response.text)

# Обновление времени жизни (если сессия затянулась)
cache.update(ttl=datetime.timedelta(minutes=120))

Стратегии промптинга для 1М+ токенов

Даже с идеальной памятью модели, то, как вы формулируете запрос, влияет на качество ответа. При работе с экстремально длинным контекстом обычные правила меняются.

1. Позиционирование инструкций

В коротком контексте мы привыкли ставить инструкцию в начало («Ты полезный ассистент...»). В длинном контексте это всё ещё работает, но для сложных задач, требующих анализа всего массива данных, эффективна стратегия «Сэндвич» или «Напоминание в конце».

Пример:
[СИСТЕМНАЯ ИНСТРУКЦИЯ]
[ОГРОМНЫЙ КОНТЕКСТ ДАННЫХ]
[ПОВТОРЕНИЕ КЛЮЧЕВОГО ЗАДАНИЯ: Исходя из всех данных выше, найди...]

Повторение вопроса в конце помогает модели «сфокусироваться» после обработки миллионов токенов.

2. Chain-of-Thought (CoT) с цитированием

При таком объеме данных риск «галлюцинаций» (смешивания фактов) возрастает. Требуйте от модели цитировать источники.

Плохой промпт: «Сделай резюме финансовых показателей.»
Хороший промпт: «Проанализируй финансовые отчеты. Для каждого утверждения о прибыли или убытках укажи точную страницу и название документа, из которого взята цифра. Сначала выпиши все найденные цифры, а затем составь резюме.»

3. RAG vs Long Context: Где граница?

Это самый частый архитектурный вопрос. Когда переключаться?

Вердикт: Используйте Long Context для глубокого анализа конкретных наборов документов (книг, дел, проектов). Используйте RAG для поиска по всей базе знаний компании.

РЕШЕНИЕ:

1. Выбор архитектуры: Long Context + Caching.

Обоснование:
- Объем (800к) помещается в контекстное окно Gemini 1.5/3.
- Задача требует cross-reference (сопоставления) фактов между разными документами, что RAG делает плохо (он может найти куски про свидетеля и куски про договор, но потерять логическую связь, если они не попали в top-k).
- Юристы будут задавать много вопросов к одному делу -> Кэширование снизит стоимость и задержку.

2. Реализация:
- Шаг 1: Загрузить все 50 PDF через File API.
- Шаг 2: Создать кэш (ttl=24 часа) с системным промптом: "Ты опытный юридический аналитик. Твоя задача — находить противоречия и связи в документах. Всегда ссылайся на название файла и страницу."
- Шаг 3: Чат-бот подключается к кэшу.

3. Структура промпта (Псевдокод):
user_query = "Противоречат ли показания..."
full_prompt = f"""
Контекст уже загружен в кэш.

Запрос пользователя: {user_query}

Инструкция:
1. Найди документ с показаниями свидетеля А.
2. Найди договор от 10 января.
3. Сравни утверждения по пунктам.
4. Если есть противоречие, процитируй оба фрагмента.
"""