# ГЛАВА 1. ТОКЕНЫ, ВЕКТОРЫ И СЕМАНТИЧЕСКОЕ ПРОСТРАНСТВО

---

## 1.1. Модель читает не слова, а токены — и это меняет всё

Представьте, что вы договорились с коллегой общаться записками, но у вас нет общего языка — только общий разговорник на 200 000 фраз. Каждую вашу мысль вы обязаны выразить комбинацией фраз из этого разговорника. Если нужного слова нет — разбиваете его на кусочки, которые в разговорнике есть. Именно так работает LLM: модель читает не ваш текст, а его «перевод» в последовательность фрагментов из фиксированного словаря.

Когда вы отправляете текст в LLM, первое, что происходит — текст разбивается на **токены**. Не на слова. Не на символы. На фрагменты, определённые алгоритмом **субсловной токенизации**. Это фундаментальный факт, из которого следует всё остальное: стоимость запроса, длина контекста, качество ответа, поведение модели на разных языках.

### Что такое токен

Токен — это атомарная единица текста для модели. Один токен может быть:

- Целым словом: `the` → 1 токен
- Частью слова: `tokenization` → `token` + `ization` (2 токена)
- Одним символом: `@` → 1 токен
- Пробелом или переносом строки: ` ` → 1 токен, `\n` → 1 токен
- Последовательностью цифр: `2024` может быть 1 токеном или `20` + `24`
- Байтовой последовательностью: в byte-level BPE каждый байт — потенциальный базовый токен

Модель не видит «слов» в нашем понимании. Она видит последовательность целых чисел — индексов в словаре токенизатора.

### Как работает BPE (Byte Pair Encoding)

Прежде чем погружаться в алгоритм — зачем он вообще нужен?

Проблема проста: если сделать каждое слово отдельным токеном, словарь станет гигантским (миллионы словоформ только для русского), а редкие слова модель почти не увидит при обучении. Если сделать каждую букву токеном — словарь крошечный, но предложение растянется в десятки токенов, и модели будет трудно уловить смысл. BPE — это компромисс: алгоритм автоматически находит оптимальные «кусочки» текста. Частые слова (`the`, `что`) остаются целыми, а редкие (`бессмысленностей`) разбиваются на знакомые части.

По сути BPE — это сжатие текста, как ZIP, но вместо экономии байтов он экономит «внимание» модели. Чем чаще встречается фрагмент, тем вероятнее он станет отдельным токеном.

BPE (Sennrich et al., 2016) — основной алгоритм токенизации в современных LLM. Он работает так:

**Обучение токенизатора:**

1. Начните с алфавита: каждый символ (или байт) — отдельный токен.
2. Подсчитайте частоту всех соседних пар токенов в корпусе.
3. Объедините самую частую пару в один новый токен.
4. Повторяйте шаг 2–3, пока словарь не достигнет заданного размера.

**Пример:** Допустим, в корпусе часто встречается пара `t` + `h`. Она объединяется в `th`. Затем `th` + `e` → `the`. Затем `the` + ` ` → `the ` (с пробелом). Так формируются всё более крупные токены для частых паттернов.

**Токенизация нового текста:**

Жадный алгоритм: ищите самый длинный токен из словаря, совпадающий с началом строки, затем повторяйте для остатка.

### Основные реализации (2025–2026)

| Токенизатор | Модели | Размер словаря | Особенности |
|-------------|--------|-----------------|-------------|
| **tiktoken** (OpenAI) | GPT-4o, GPT-5, o3 | `o200k_base`: ~200K токенов | Byte-level BPE. Rust-бэкенд, быстрый подсчёт токенов |
| **SentencePiece** | T5, Gemma и часть open-weight моделей | Варьируется | Unigram или BPE. Обучается на сыром тексте без предтокенизации |
| **HuggingFace tokenizers** | Open-source модели | Варьируется | Rust-бэкенд, 1 ГБ текста < 20 сек. Поддерживает BPE, WordPiece, Unigram |
| **Byte-level BPE** | Llama 4, Qwen3, Mistral, DeepSeek-V3 | 128K–200K+ | Byte-fallback: если токен не найден, fallback на байтовый уровень → **нет `[UNK]` токенов** |
| **Совместимые экосистемы** | DeepSeek-V3, Qwen3, Llama 4 | Варьируется | Практически важно не название алгоритма, а доступность токенизатора в SDK и open-source tooling |

**Ключевые тренды к 2026 году:**

- **Большие словари встречаются всё чаще.** Словари порядка 128K-200K+ токенов стали типичными для части новых моделей, особенно там, где важны код, мультиязычность и длинные редкие термины.
- **Byte-fallback стал распространённым паттерном, но не единственным.** Многие современные open-weight модели используют схемы без `[UNK]`, однако конкретный токенизатор по-прежнему зависит от семейства модели.
- **Мультимодальная токенизация** набирает обороты: модели вроде GPT-4o, GPT-5 и Gemini 3.x/2.5 принимают не только текст, но и изображения/аудио, разбивая их на «визуальные токены» (подробнее — в разделе 1.5).
- **SLM (Small Language Models)** на мобильных устройствах и edge-серверах (Phi-4-mini, Gemma 4, Qwen3-0.6B) используют ровно те же принципы токенизации — разница только в размерности эмбеддингов и глубине сети.

### Почему это важно инженеру

Три прямых следствия токенизации:

1. **Бюджет контекста считается в токенах, не в словах.** Модель с окном 128K токенов — это не 128K слов. Для английского: ~75 слов на 100 токенов. Для русского: ~50–60 слов на 100 токенов.

2. **Стоимость API считается в токенах.** Один и тот же текст на русском стоит на 40–70% дороже, чем его английский эквивалент.

3. **Граница токена ≠ граница понятия.** `PostgreSQL` может разбиться на `Post` + `gre` + `SQL`. Модель видит три фрагмента, а не один термин. Это влияет на то, как attention распределяет «внимание» между частями.

---

## 1.2. Как токены превращаются в векторы: от индекса к смыслу

После токенизации каждый токен — это целое число (индекс). Но номер сам по себе ничего не говорит о смысле слова. Как перейти от номера к «пониманию»?

Вот интуиция. Представьте, что вы описываете каждый город мира координатами на карте — двумя числами (широта, долгота). Близкие города получают близкие координаты. Эмбеддинги работают так же, только вместо двух координат — тысячи, и вместо географической близости — смысловая. Слова, которые используются в похожих контекстах, оказываются рядом в этом пространстве, как Москва и Петербург на карте.

### Слой эмбеддингов

Слой эмбеддингов — это большая таблица размера `V × d`, где:
- `V` — размер словаря (количество уникальных токенов, обычно 32K–200K)
- `d` — размерность эмбеддинга (`d_model`)

Чтобы получить вектор токена, модель просто берёт соответствующую строку из этой таблицы. Это lookup в чистом виде: индекс → вектор фиксированной размерности.

### Размерности в современных моделях

| Модель | `d_model` | Параметры | Примечание |
|--------|---------------------|-----------|------------|
| GPT-5 / GPT-4o | не раскрывается | не раскрывается | OpenAI не публикует точную внутреннюю размерность |
| Claude Opus 4.6 | не раскрывается | не раскрывается | Anthropic не публикует точные внутренние размеры |
| Llama 4 Maverick | 5120 | 17B active, 400B total (MoE, 128 экспертов) | Open-weight; config: HuggingFace meta-llama/Llama-4-Maverick-17B-128E-Instruct |
| Llama 3 70B | 8192 | 70B | Открытая архитектура |
| Qwen3-235B-A22B | 4096 | 235B total, 22B active | MoE, открытая модель |
| DeepSeek-V3 | 7168 | 671B total, 37B active | MoE: 256 экспертов |
| Mistral Large | 8192 | ~123B | Dense-архитектура |
| Gemini 3.x / 2.5 | не раскрывается | не раскрывается | Google публикует capability docs, но не полные внутренние размеры |

### Что означают эти числа

Каждый токен представлен вектором из 4096–12288 чисел с плавающей точкой. Эти числа **не имеют интерпретируемого значения по отдельности** — нельзя сказать «координата #712 отвечает за эмоциональность». Смысл возникает из отношений между векторами — как координаты на карте обретают смысл только в сравнении с другими точками.

### Почему размерность имеет значение: интуиция

Зачем нужны тысячи координат? Почему не 100 и не миллион? Представьте себе задачу: расположить все слова языка в пространстве так, чтобы близкие по смыслу были рядом.

- **Слишком мало измерений (d=2–32):** это как пытаться рассадить 200 000 гостей в комнате 2×2 метра. Люди будут «слипаться», и модель не сможет различить тонкие оттенки смысла. Слова «быстрый» и «скорый» окажутся в той же точке, что и «молниеносный», «мгновенный», «проворный».
- **Оптимально (d=4096–12288):** достаточно пространства, чтобы каждый токен имел свою «нишу», где он отличается от соседей по нужным признакам. Модель может одновременно кодировать синтаксис, семантику, тональность и доменную принадлежность.
- **Слишком много измерений (d=100 000+):** это как описывать каждого человека анкетой из 100 000 вопросов — большинство избыточны, обучение замедляется, памяти не хватает, а модель начинает «запоминать шум» (overfitting) вместо закономерностей.

Практическое правило: размерность растёт вместе с количеством параметров модели, потому что большие модели учатся на большем объёме данных и могут осмысленно заполнить больше координат.

### Косинусное сходство: почему именно оно

Как измерить, насколько два слова «похожи» по смыслу? Можно сравнить расстояние между их векторами, но есть проблема: длина вектора мешает. Одно и то же слово, встречающееся чаще, может иметь «длиннее» вектор — но направление его остаётся тем же.

Представьте две стрелки, выходящие из одной точки. Если они указывают почти в одном направлении (0°) — слова похожи по смыслу. Перпендикулярны (90°) — не связаны. Направлены в противоположные стороны (180°) — противоположны (например, «хороший» и «ужасный»). И неважно, насколько стрелки длинные — важен только угол между ними. Именно это и считает косинусное сходство.

Результат — число от -1 до 1: близко к 1 для похожих векторов, около 0 для несвязанных и ниже 0 для противоположных. Почему не обычное эвклидово расстояние? Потому что косинус игнорирует «масштаб» вектора и сравнивает чистое направление — а именно направление кодирует смысл.

Токены, встречающиеся в похожих контекстах, имеют близкие векторы. `king` и `queen` будут ближе друг к другу, чем `king` и `bicycle`.

- **Арифметика векторов** (приблизительно) отражает семантические отношения: если сдвиг между `man` и `woman` похож на гендерный сдвиг в пространстве, то такой же сдвиг от `king` приводит модель в область `queen`.

### Обучение эмбеддингов

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

**Важный нюанс:** начальный эмбеддинг — это «статическое» представление. Оно одинаково для одного и того же токена вне зависимости от контекста. **Контекстное** представление — результат прохождения через слои attention и MLP, которые модифицируют вектор на основе окружения. Именно поэтому полисемия (многозначность) разрешается не на уровне эмбеддинга, а на уровне attention: слово `bank` получит разное контекстное представление в `river bank` и `central bank`.

---

## 1.3. Почему близость векторов важнее «человеческой формулировки»

Знакомая ситуация: вы переписываете промпт в третий раз, надеясь, что «более точная» формулировка наконец даст нужный результат. Иногда это помогает. Чаще — нет. И вот почему: модель реагирует не на ваш замысел, а на **положение токенов в семантическом пространстве**.

Аналогия: вы набираете GPS-координаты в навигаторе. Навигатору всё равно, называете вы это место «дом», «квартира» или «база» — важны только координаты. Так же и с LLM: важны не слова, а то, куда они попадают в пространстве модели.

Инженер, работающий с LLM, часто перефразирует промпт, надеясь на лучший результат. Причина неудач в том, что модель реагирует не на формулировку, а на **положение токенов в семантическом пространстве**.

### Семантическое пространство — не словарь

Запрос `напиши код сортировки` и `реализуй алгоритм упорядочивания массива` семантически похожи для человека. Но для модели это разные последовательности токенов, которые:

1. Проходят через разные эмбеддинги.
2. Активируют разные паттерны в attention-слоях.
3. Пробуждают разные ассоциации в MLP-слоях.

Если в тренировочных данных `сортировка` ассоциировалась с простыми примерами на Python, а `алгоритм упорядочивания` — с академическими статьями, выходы будут разными не из-за «понимания», а из-за разных статистических траекторий.

### Что работает лучше перефразирования

**Семантические якоря** — конкретные термины, имена, примеры, которые однозначно активируют нужные ассоциации:

| Стратегия | Пример | Почему работает |
|-----------|--------|-----------------|
| **Имя функции** | `def quicksort(arr: list[int]) -> list[int]:` | Активирует конкретные код-ассоциации |
| **Пример ввода-вывода** | `Input: [3,1,2] → Output: [1,2,3]` | Фиксирует формат и семантику |
| **Типы данных** | `arr: list[int], key: Callable` | Сужает пространство возможных ответов |
| **Имя библиотеки** | `используя numpy.sort` | Привязывает к конкретной реализации |
| **Шаблон кода** | Пустая функция с сигнатурой и docstring | Задаёт структурный контекст |

**Антипаттерн:** синонимичное перефразирование без конкретики. `Сделай красивый код` → `Напиши элегантный код` → `Реализуй чистый код` — все три дают разные (и непредсказуемые) результаты, потому что «красивый», «элегантный» и «чистый» имеют разные контексты в тренировочных данных.

### Практическое следствие

Вместо того чтобы искать «идеальную формулировку», предоставьте модели:
- Конкретные имена, типы, примеры
- Структурный контекст (шаблоны, схемы)
- Явные ограничения (`не используй рекурсию`, `максимум 20 строк`)

Это работает, потому что конкретные якоря имеют узкое распределение в семантическом пространстве и активируют предсказуемые ассоциации.

---

## 1.4. Русский vs английский: не просто дороже, а иначе разбивается

Если вы работаете с русским языком — вы платите «налог на кириллицу». И дело не только в деньгах: русский текст занимает больше токенов, значит, в контекстное окно влезает меньше смысла, а модель видит каждое слово менее цельно.

Русский язык создаёт уникальные вызовы для токенизации. Это не просто вопрос стоимости — это вопрос качества и предсказуемости.

### Морфологическая сложность

Русский язык — **флективный фузионный язык** с:
- **6 падежами** (именительный, родительный, дательный, винительный, творительный, предложный)
- **3 рода** (мужской, женский, средний) для существительных, прилагательных, глаголов (в прошедшем времени)
- **2 вида глагола** (совершенный и несовершенный): `делать` / `сделать`
- **Богатой деривацией**: приставки, суффиксы, постфиксы изменяют смысл: `ходить` → `выходить` → `выходящий` → `перевыходящий`
- **Свободным порядком слов**: `Иван любит Марию` = `Марию любит Иван` = `Любит Иван Марию` (семантически)

### Как это влияет на токенизацию

Каждая словоформа — потенциально отдельный токен или набор субтокенов. Слово `предопределённость` может разбиться на 3–5 токенов в зависимости от токенизатора:

```
пред|определ|ённ|ость
```

В то время как английское `predetermination` разбивается на:

```
pre|determin|ation
```

Количество морфем в русском слове обычно выше, и многие из них — редкие комбинации, попадающие в long-tail словаря.

### Практический пример: одно предложение — разные токенизаторы

Возьмём фразу: **«Модель предсказывает следующий токен»** и посмотрим, как её видят разные модели:

| Токенизатор | Разбиение | Токенов |
|--------------|----------|----------|
| **tiktoken** (`o200k_base`, GPT-4o) | `Модель` `предсказывает` `следующий` `токен` | 4 |
| **Llama 4** (byte-level BPE, ~202K) | `Модель` ` пред` `сказ` `ывает` ` следующий` ` токен` | 6 |
| **Qwen3** (byte-level BPE, ~152K) | `Модель` ` предсказ` `ывает` ` следующий` ` токен` | 5 |
| **DeepSeek-V3** (128K) | `Модель` ` пред` `сказывает` ` следующий` ` токен` | 5 |

Обратите внимание: одно и то же предложение даёт от 4 до 6 токенов в зависимости от токенизатора, потому что русские слова по-разному представлены в словарях. Модели с большими словарями (200K) обычно эффективнее для русского языка.

> Вы можете проверить это сами — промпт для генерации сравнительного скрипта приведён в конце главы.

### Token-to-word ratio

Эмпирические измерения на сопоставимых текстах:

| Язык | Среднее token/word | Токены на 1000 слов | Коэффициент |
|------|---------------------|---------------------|-------------|
| Английский | ~1.3 | ~1300 | 1.0× |
| Русский | ~1.8–2.2 | ~1800–2200 | 1.4–1.7× |

Это значит, что **русский контекст «дороже» английского в 1.4–1.7 раз** — как в деньгах (API billing), так и в бюджете контекстного окна.

### Особенности поведения модели на русском

1. **Редкие словоформы**: падежные формы редких слов (например, `бессмысленностей`, `перефразировавшегося`) могут разбиваться на 5–7 токенов. Модель менее уверена в таких токенах — выше вероятность ошибок.

2. **Пунктуация и окончания**: русская пунктуация (тире, кавычки-«ёлочки», запятые в сложноподчинённых предложениях) и падежные окончания «съедают» attention, если не выделены структурой.

3. **Кодосмешение (code-switching)**: промпты, содержащие русский текст с английскими терминами (`Реализуй REST API с middleware для authentication`), создают дополнительную нагрузку на токенизатор — переключение между кириллицей и латиницей.

4. **Переводные артефакты**: модели, обученные преимущественно на английских данных, могут генерировать русский текст с калькированным синтаксисом и неестественной лексикой.

### Что делать

1. **Измеряйте token-to-word ratio** на ваших реальных данных. Не полагайтесь на средние значения — они сильно зависят от домена и стиля.

> **Промпт для ИИ:** «Напиши Python-скрипт, который принимает текст и имя модели (tiktoken или HuggingFace AutoTokenizer), токенизирует текст, подсчитывает количество токенов и слов, выводит token/word ratio. Покажи пример на русском тексте из 2–3 предложений.»

2. **Используйте модели с оптимизированным русским токенизатором.** Проверяйте: какой процент вашего текста попадает в `[UNK]` или распадается на single-byte токены? У Mistral с byte-fallback BPE — ноль UNK-токенов, но byte-level дробление может быть избыточным.

3. **Закладывайте +40–60% к контекстному бюджету** по сравнению с английским аналогом. Если для английской задачи достаточно 4K токенов, для русской планируйте 5.6–6.4K.

4. **Предпочитайте английские термины** в технических промптах, где русский эквивалент многозначен или дробится: `sort` вместо `упорядочивание`, `database` вместо `база данных` (хотя последнее зависит от токенизатора).

---

## 1.5. Мультимодальная токенизация: когда токены — это не только текст

До сих пор мы говорили о токенизации текста. Но к 2026 году большинство флагманских моделей (GPT-4o, GPT-5, Gemini 3.x/2.5, Llama 4, Qwen2.5-VL) принимают не только текст, но и изображения, аудио и видео. Как же картинка превращается в токены?

### Изображения → патчи → токены

Представьте, что вы разрезали фотографию на сетку маленьких квадратиков (например, 14×14 пикселей каждый). Каждый квадратик — **патч** (patch). Это визуальный аналог токена. Каждый патч проходит через визуальный энкодер (Vision Transformer, ViT) и превращается в вектор той же размерности `d_model`, что и текстовые эмбеддинги.

```
Изображение 224×224 px
    ↓ разбиение на патчи 14×14
256 патчей (16×16 сетка)
    ↓ визуальный энкодер (ViT)
256 векторов ∈ ℝ^d_model
    ↓ подаются в transformer вместе с текстовыми токенами
```

Аналогично работает аудио: звуковая дорожка разбивается на короткие фрагменты (~25мс), каждый становится «аудио-токеном».

### Почему это важно для инженера

1. **Бюджет контекста теперь делится между модальностями.** Одно изображение 768×768 px может «стоить» 1000–2000 токенов — только на визуальную часть. Это напрямую влияет на стоимость и доступный объём текстового контекста.
2. **Текстовые и визуальные токены живут в одном пространстве.** Модель может «связать» слово «кошка» с патчами изображения, на котором изображена кошка, потому что их векторы оказываются близки.
3. **Все принципы текстовой токенизации применимы.** Бюджет, стоимость, attention — всё работает по тому же принципу, только «слова» теперь включают и кусочки изображений.

---

## 1.6. Как устроен словарь токенизатора: практические последствия

### Что входит в словарь

Словарь токенизатора — это фиксированная таблица, созданная на этапе обучения. Она не меняется после обучения модели. Это значит:

- Новые слова, появившиеся после обучения, будут разбиты на субтокены, даже если стали популярными.
- Специальные символы и разметка (XML-теги, Markdown-заголовки, JSON-скобки) имеют свои токены — и модель «знает» их особый статус.
- Числа токенизируются непоследовательно: `100` может быть одним токеном, `1000` — двумя (`100` + `0` или `10` + `00`), `10000` — тремя.

### Специальные токены

Каждый токенизатор включает специальные токены, невидимые в обычном тексте:

| Токен | Назначение |
|-------|------------|
| `<BOS>` / `<s>` | Начало последовательности |
| `<EOS>` / `</s>` | Конец последовательности |
| `<PAD>` | Заполнение при батчинге |
| `<UNK>` | Неизвестный токен (в byte-fallback BPE не используется) |
| `<|im_start|>`, `<|im_end|>` | Границы сообщений (ChatML) |
| `<tool_call>`, `<tool_result>` | Маркеры tool-calling |

Эти токены критически важны: модель обучена реагировать на них особым образом. `<|im_start|>system` переключает модель в режим «системных инструкций», и вес этих токенов в attention непропорционально высок.

### Числа и арифметика

Токенизация чисел — источник систематических ошибок. Пример (tiktoken, `cl100k_base`):

```
"123456789" → [123, 456, 789]  (3 токена)
"1234"      → [1234]            (1 токен)
"12345"     → [123, 45]         (2 токена)
```

Модель не «видит» число как единое целое — она видит набор фрагментов. Это объясняет, почему LLM плохо считают: `247 × 13` требует «от модели» мультипликации субтокенов, для которой у неё нет явного арифметического блока. Подробнее — в [Главе 11](11_tools.md).

---

## Практический вывод

### Чек-лист по токенизации

| # | Действие | Критерий |
|---|----------|----------|
| 1 | **Считайте бюджет в токенах**, не в словах/символах | Используйте `tiktoken` или `tokenizers` для точного подсчёта |
| 2 | **Тестируйте токенизацию** на ваших реальных данных | token/word ratio, доля unknown-токенов, дробление ключевых терминов |
| 3 | **Для русского закладывайте +40–60%** к контекстному бюджету | Измеренный ratio, не теоретический |
| 4 | **Используйте семантические якоря** вместо синонимичных перефразирований | Имена функций, типы, примеры I/O вместо «сделай хорошо» |
| 5 | **Проверяйте дробление ключевых терминов** | Если ваш домен-специфичный термин дробится на 4+ токена, рассмотрите альтернативные обозначения |
| 6 | **Не доверяйте модели в арифметике** | Числа дробятся на токены — используйте инструменты ([Глава 11](11_tools.md)) |

### Промпт для работы с токенами

> **Промпт для ИИ:** «Напиши Python-скрипт, который сравнивает токенизацию русского текста через tiktoken (o200k_base) и HuggingFace tokenizers (Llama 4, Qwen3, DeepSeek-V3). Для каждого токенизатора выведи: количество токенов, список субтокенов, token/word ratio. Входной текст — аргумент командной строки. Результат — сводная таблица в терминале. Используй библиотеки tiktoken и transformers.»

### Задания

1. **Измерьте token/word ratio на ваших данных.** Возьмите 5–10 реальных промптов или документов из вашего проекта. Сгенерируйте скрипт по промпту выше, запустите его на ваших данных. Сравните ratio для русского и английского текста. Ожидаемый результат: таблица с ratio по каждому токенизатору, понимание реальной «стоимости» вашего контента.

2. **Проверьте дробление доменных терминов.** Составьте список из 10–15 ключевых терминов вашего домена (названия продуктов, технических понятий, специфической лексики). Проверьте, как каждый токенизатор их разбивает. Если термин дробится на 4+ субтокена — найдите альтернативное обозначение, которое дробится меньше. Ожидаемый результат: таблица «термин → разбиение → альтернатива» для вашего проекта.

3. **Оцените влияние токенизации на бюджет контекста.** Возьмите типичный системный промпт + пользовательский запрос из вашего приложения. Подсчитайте токены для русской и английской версий. Рассчитайте, сколько контекста остаётся для ответа модели при окне 128K. Ожидаемый результат: понимание реального бюджета и решение, нужен ли перевод части промпта на английский.

### Резюме главы

> **Модель видит не текст, а токены. Бюджет, стоимость, качество и поведение — всё определяется токенизацией. Считайте в токенах. Тестируйте токенизацию. Используйте конкретные якоря вместо синонимов.**

---

## Источники
- Sennrich, R., Haddow, B., & Birch, A. (2016). "Neural Machine Translation of Rare Words with Subword Units." ACL.
- Kudo, T. & Richardson, J. (2018). "SentencePiece: A simple and language independent subword tokenizer and detokenizer for Neural Text Processing."
- OpenAI. tiktoken: https://github.com/openai/tiktoken
- HuggingFace tokenizers: https://huggingface.co/docs/tokenizers/

---

**Навигация:**
- Назад: [Введение](00_introduction.md)
- Далее: [Глава 2. Где в модели «живут» знания](02_where_knowledge_lives_in_the_model.md)
