Глава 16. Что дальше?

Названия моделей устаревают быстрее, чем боль, которая их породила.

Если книга сработала, вы уже не ждёте от финальной главы списка «выучи эти 15 архитектур».
Вы ждёте карты следующих болей.

16.1. После трансформеров: память и длинный контекст

Self-attention купил параллелизм и гибкость ценой квадрата по длине.
Пока N рос умеренно, рынок платил.
Как только понадобились очень длинные контексты (документы, аудио, геномика, длинное видео), счёт стал главным сюжетом.

Отсюда волна идей:

• эффективные attention (window, sparse, linearized);
• IO-осознанные реализации вроде FlashAttention — та же математика, другая работа с памятью;
• state space models / SSM, Mamba и родственники — попытка вернуть почти линейный скан с длинной памятью и хорошим железом (глава 16a).

Боль:     N² и память активаций
Гипотезы: приблизить attention / изменить базис последовательности
Критерий: качество на длинном контексте × tokens/s × память

Заметьте рифму с RNN-главой: рынок снова ищет последовательные или рекуррентно-подобные вычислительные структуры — но уже не ценой наивной необучаемости 2015 года.

16.2. Мультимодальность как стык маршрутов информации

Текст, картинка, аудио, действие робота — разные токены, одна проблема:

Как согласовать представления и маршруты информации между модальностями
без комбинаторного взрыва костылей?

Здесь снова работают привычные рычаги книги: prior против данных, attention против локальных операторов, латентные пространства как сжатые договоры между частями системы.

16.3. Край железа: когда архитектура = компиляция

На edge и в камере архитектура всё чаще не отделена от:

• квантизации;
• fusion ядер;
• форматов памяти;
• batch=1 реальности;
• постпроцессинга, который внезапно ест 30% кадра.

Будущее здесь не всегда «новая статья с +0.3 mAP».
Часто — co-design модели и рантайма.
FlashAttention-подобные истории показывают: иногда прорыв — это не новая формула, а новая реализация старой.

16.4. Навык, который не устареет

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

1. Какая боль была невыносима?
2. Какое ограничение железа/данных/latency давило?
3. Какая гипотеза предложена?
4. Какой эксперимент/абляции убеждают?
5. Чем заплатили?
6. Где гипотеза умрёт вне бенчмарка авторов?

Если отвечаете на эти шесть пунктов — вы читаете (и проектируете) архитектуры взросло.

flowchart LR
    P[Проблема] --> C[Ограничения]
    C --> H[Гипотеза]
    H --> E[Эксперимент]
    E --> T[Компромисс]
    T --> N[Новое решение]
    N --> P2[Новая проблема]

Именно поэтому книга называется не «Энциклопедия YOLO и трансформеров».
А про логику архитектур.

16.5. Закрытие

Мы прошли путь:

• от краха brute force на пикселях;
• через свёртку и частотный взгляд;
• через кризис глубины и его стабилизаторы;
• через детекцию как инженерию времени;
• через внимание и спор prior vs data;
• через генерацию конфликтом и шумом;
• к выбору под железо и к следующему витку болей.

Если после этого вы откроете YAML современной модели и вместо капитуляции перед аббревиатурами увидите цепочку обменов — задача книги выполнена.

А если ещё и сформулируете собственную гипотезу вида
«а что, если в шее заменить такое-то слияние на …»
и придумаете абляцию, которая может вас опровергнуть —
тогда вы уже не только читатель.

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

Если бы вы были автором следующей статьи…

1. Выберите одну боль из вашего продукта (мелочь в детекции, длинный контекст, нестабильный train, edge latency).
2. Запишите три гипотезы, из которых минимум одна должна быть скучной (данные/аугментации/реализация).
3. Заранее объявите критерий отказа: при каком результате вы выбросите любимую идею.

На этом книга заканчивается.
Работа инженера — нет.