Контекстное окно и токены. Часть 1

Ликбез

Бывало у вас, что модель выдавала что-то невнятное или даже ошибку в ответ на просьбу обработать длинный документ? Чтобы понять, что случилось и как это исправить, надо разобрать два ключевых понятия: токен и контекстное окно.

🔤 Токены

Модель не понимает текст — она работает только с числами. Превращение текста в числа происходит в три этапа:

1. Токенизация — разбивка на атомарные единицы

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

2. Векторизация — вложение смысла

Следующий слой модели — Embedding — преобразует каждый ID в вектор от сотен до тысяч координат. Например:
[-0.41,..., 0.5]

Этот вектор (эмбеддинг) кодирует семантику токена и его связи с другими понятиями в многомерном пространстве. Два близких по смыслу слова окажутся рядом в пространстве.

Подробнее про эмбеддинги

3. Подача на вход трансформеру

Именно эти эмбеддинги, а не исходный текст и не ID, поступают на вход механизму внимания (attention) трансформера для дальнейших вычислений.

Для русского языка:
• 1 токен ≈ 4 символа (включая пробелы и пунктуацию)
• Или 1 токен ≈ 0.75 слова

В английском токенизатор чаще выделяет целые слова (word-level), в русском — субслова (subword), т.к. больше окончаний, суффиксов.

📦 Контекстное окно

Контекстное окно (context window / n_ctx) — это максимальное количество токенов, которое трансформер-декодер может одновременно удерживать в своём механизме внимания (attention) при генерации одного ответа. По сути аналог оперативной памяти.

Сравнение моделей:
- Saiga Nemo 12B → 8 192 токена
- Llama 3.1 8B → 128 K
- GPT-4o / Claude 3.5 → 128 K – 200 K
- DeepSeek-V3 → 1M токенов (3 небольших книги!)

Что съедает место внутри окна:

• Системный промпт (инструкция для модели)
• Вопрос пользователя
• Найденные чанки из RAG (Top‑K фрагментов)
• История диалога (если она передаётся)
• Ответ модели (генерируется внутри этого же окна)

При привышении n_ctx модель либо:
• выдает ошибку (n_keep >= n_ctx)
• обрезает начало запроса (необратимая потеря данных)

🧠 Потеря в середине (lost in the middle)

Даже если документ целиком помещается в контекстное окно, это не гарантирует, что модель его усвоит. Исследования (например, Liu et al., 2024) показывают устойчивую закономерность распределения внимания модели:

✅ Начало контекста — запоминает лучше всего (привычный паттерн)
✅ Конец — запоминает хорошо (последние токены имеют высокий вес)
❌ Середина — часто «проваливается», получает меньше внимания

Что это означает для RAG-архитектуры:

Недостаточно просто увеличить размер контекстного окна. Критически важно правильно позиционировать релевантные чанки. Самые важные фрагменты должны оказаться либо в самом начале промпта, либо в его конце — перед вопросом. Open WebUI по умолчанию прикладывает чанки непосредственно перед вопросом — это хорошая практика.

🔗 Как контекстное окно провоцирует галлюцинации

Связь прямая и жёсткая. Рассмотрим цепочку:
• Документ не влезает в окно → модель видит только часть данных или обрезает запрос с начала → теряет критически важный контекст.
• Нужные данные оказались в середине → модель «забывает» их из-за lost in the middle → даже при формальном наличии факта в окне модель может его не использовать.
• Модель не нашла факт в контексте → и вынуждена опираться на свои внутренние веса, обученные на интернете. Включается априорное распределение P(токен | веса) вместо P(токен | контекст, веса).

Когда контекст не доминирует над «интернет-паттернами», модель выбирает наиболее статистически вероятный ответ из своего обучения — и как правило он противоречит вашему запросу (модель начинает галлюцинировать).

� Далее:
Как управлять контекстным окном, избегать ошибок и снижать риск галлюцинаций.