Когда разработчик получает задачу, он её сначала декомпозирует: разбивает на части, ищет зависимости, проектирует решение. Потом уже пишет код.

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

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

Данная статья — об устройстве моделей и RAG-надстроек. А ещё о том, что пора перестать очеловечивать инструмент и считать его магией.

Как это вообще появилось?

До трансформеров языковые модели строились на RNN/LSTM и обрабатывали текст строго последовательно — слово за словом. Это делало их медленными на обучении и неспособными удерживать дальние связи в тексте. Архитектура «внимание» решила обе проблемы, и сегодня индустрия почти полностью ушла в трансформеры, оставив RNN для узких задач вроде временных рядов.

Чем RNN отличались от трансформеров

Сегодняшние LLM на практике это декодерные трансформеры без отдельного кодировщика. Они решают проблему фиксированной длины несколькими способами:

1. Окна контекста

2. Механизмы обработки для сверхдлинных контекстов

3. Positional Encoding (RoPE, ALiBi)

А вот теперь вопрос со звездочкой: что это сейчас был за фокус и где языковые генеративные модели свернули на ветку сюжета с плохой концовкой?

Что значит O(n²) для внимания?

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

Self-attention требует вычислить попарные взаимодействия между всеми токенами последовательности. Для длины  это:

•  операций

•  памяти для хранения матрицы внимания (или её разреженных аналогов)

Главное ограничение — не вычисления, а память. Хранить полную матрицу 1M×1M в формате float32 — это около 4 ТБ. Современный GPU осилит триллион операций, но не терабайты.

На практике используют ухищрения:

• разреженное внимание (sparse attention)

• скользящее окно

• FlashAttention (линейная память)

• линейные аппроксимации (Linformer, Performer)

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

Мыслящие (нет) машины

Давайте разберемся с thinking и instruct моделями. Главное различие — как и когда модель «думает» над ответом. Правильный ответ - никогда не думает, но может делать вид.

• Instruct-модель: Получает задачу → сразу генерирует ответ. Весь процесс «мышления» скрыт внутри нейронной сети.

• Thinking-модель: Получает задачу → сначала генерирует внутреннюю цепочку рассуждений (chain-of-thought), проверяет логику, пробует разные подходы → затем на основе этого выдает финальный ответ.

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

Практический вывод: thinking-модели не лучше instruct «в целом». Они имеют смысл для сложных многошаговых задач, где нужен развёрнутый промежуточный вывод. Для тривиальных вопросов они только замедляют ответ и переусложняют генерацию.

Про движки

Когда мы обращаемся к модели, надо держать в голове что там на самом деле не одна модель, а масса разных специализированных модулей, например перевод: модель не понимает сама, что статью о пчелках на испанском можно перевести на немецкий и это абсолютно та же статья, поэтому выдача на разных языках иногда структурно отличается. Она не "знает", что статья о пчелах — это один объект. Она видит последовательности токенов на испанском и училась предсказывать последовательности на немецком. Если распределение в обучающих данных на испанском и немецком структурно разное (например, в немецких текстах чаще используют пассивный залог в научных статьях), модель это повторит. Семантическая эквивалентность ей не гарантирована — только статистическая.

RAG - а что это?

RAG (Retrieval-Augmented Generation) — это способ дополнить LLM внешним поиском информации. Он стал главным практическим решением двух проблем: ограниченного контекста и устаревших знаний модели. Это не замена трансформеру, а надстройка над ним.

В CLI-инструментах вроде Cursor или Claude Code этот цикл многократно повторяется: модель не просто ищет документы, а планирует действия, вызывает внешние инструменты (function calling) и валидирует результат.

Что в итоге?

Анекдоты про лесных зверят в контексте абстрактного мышления

Допустим у нас есть анекдот про суслика (автор - DeepSeek API):

Идёт суслик по лесу. Навстречу лиса:
— Ты куда?
— На медведя посмотреть.
— Так он спит.
— Ну и пусть.

Идёт дальше. Волк:
— Суслик, ты куда?
— На медведя посмотреть.
— Он же спит!
— Ну и ладно.

Подходит к берлоге, а медведь сидит, газету читает.
— Ты почему не спишь?
— Да вот, суслик какой-то ходит, спать мешает.

И еще анекдот про бобра:

Идёт бобёр по лесу. Навстречу лиса:
— Ты куда?
— На медведя посмотреть.
— Так он спит.
— Ну и пусть.

Идёт дальше. Волк:
— Бобёр, ты куда?
— На медведя посмотреть.
— Он же спит!
— Ну и ладно.

Подходит к берлоге, а медведь сидит, газету читает.
— Ты почему не спишь?
— Да вот, бобёр какой-то ходит, спать мешает.

Современная модель уже поймет что это один анекдот - пример слишком прост: для более сложных абстракций, где замена суслика на бобра меняет неявные смысловые связи (например, в многоходовых логических конструкциях или культурно-зависимых шутках), модель может ошибиться. Так что этот пример мы используем как отправную точку для дальнейших разъяснений.

Сейчас модель при запросе «выведи алгоритм транспортировки данных из поведения бактерий» делает вот что:

1. Извлекает известные паттерны: «бактерии» → хемотаксис → градиентный спуск → известная аналогия.

2. Выдаёт стандартный ответ: про стохастический градиентный спуск, локальные минимумы, адаптивный шаг.

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

• Выделить инвариант процесса бактерий (не «движение к еде», а «асимметричный случайный поиск с памятью о прошлом направлении»)

• Оторвать этот инвариант от биологического контекста

• Применить к задаче с другой метрикой (не градиент, а, скажем, частота успешной доставки пакета)

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

Модель с RAG всё ещё не способна к истинно креативному, дедуктивному мышлению. Она не выведет новый алгоритм, опираясь на поведение бактерий, если об этом нет статей в обучающей выборке. Она может пересказать известную аналогию (хемотаксис → градиентный спуск), но не сделает следующий шаг.

Человек же умеет заимствовать абстрактные паттерны из природы, культуры или смежных дисциплин, даже если прямой связи в литературе нет. Это не делает человека «креативнее» в мистическом смысле — просто у него другой способ получения знаний, включающий случайные побочные процессы и телесный опыт, недоступный модели.

Устройство кодген CLI на RAG рельсах

RAG‑система (Retrieval‑Augmented Generation) сочетает поиск релевантных документов с генерацией ответов LLM, что идеально для CLI‑приложений, обрабатывающих код или документы. Время перейти от теории к практике имплементаций.

Компоненты RAG CLI:

• Эмбеддер: Генерирует векторные представления текста

• Векторное хранилище для хранения и поиска похожих векторов по запросу.

• Генератор для создания ответа на основе retrieved контекста.

Как это применяется? Эмбеддер превращает запрос в эмбеддинг-вектор, ищет схожие чанки в базе, затем формирует запрос в LLM, затем получает обработанный результат и обновляет базу векторов и кодовую базу. Все просто?

{"name": "search_github", "arguments": {"query": "typescript chat service"}}

Как мы видим, LLM из "болталки" превращается в инструмент ядра принятия решений, добавляющий динамичности. То есть разработка превращается в сбор лоскутного одеялка из готовых решений: так же как разработчики ходили таскать код со stackoverflow, так и RAG система проходит схожий цикл, по сути автоматизировав принятие решений в локальном в рамках разработки проекта процессе.

Итог: в агентных системах с RAG и инструментами (function calling) модель не вызывает функции напрямую — она генерирует JSON со структурным описанием вызова. За исполнение отвечает внешний рантайм (CLI, сервер). Это важное различие: модель остаётся генератором текста, а не активным исполнителем. Такой подход автоматизирует принятие решений в рамках разработки, но требует чёткого разделения ответственности.

Новый этап

Понимание устройства RAG приводит нас к тому, что мы прошли еще один чекпоинт развития технологий, но пока не поняли, что c ним делать.

С приходом LLM ценность «чистого кодера» — того, кто быстро пишет циклы и сортировки, — снизилась. Но ценность системного мыслителя выросла.

Теперь программист — это не столько исполнитель, сколько архитектор процессов. Мы вернулись к ситуации, где прочный фундамент знаний — не только computer science, но и логика, статистика, прочные знания математики и умение применять абстракции в решении практических задач — становятся конкурентным преимуществом. Именно это позволяет превратить «болталку» в мощное ядро невозможных ранее технологий.