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

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

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

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

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

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

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

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

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

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

3. Positional Encoding (RoPE, ALiBi)

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

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

Миллион токенов контекста - это много? Смотря для чего. Для чата с моделью, простых запросов или написания небольшого сервиса - этого достаточно. Если не ожидать от моделей большего, то можно их дальше и не развивать, честно говоря. Для сложных задач, собирающих внутри себя множество аспектов и нюансов - 1M токенов это катастрофически мало.

Что значит 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) и валидирует результат.

Предположу что большинство моих читателей - программисты или люди аффилированные с IT сферой. Когда программист идет делать задачу? Когда ее сначала спроектировал архитектор, потом ее нарезал на таски тимлид на груминге. И когда задачу взяли в работу, происходит тот же цикл - программист думает куда и что подключить, а только потом берется за печатную машинку.

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

Что в итоге?

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

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

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

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

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

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

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

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

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

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

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

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

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

Что нужно чтобы у модели получилось вывести алгоритм? Давайте спросим у самой модели, мне тут нечего добавить от себя:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я пропустил важный этап. Давайте разделим начинку RAG: мышление и кодген. Мышление - этап обработки задачи. Начальный, промежуточный и завершающий. Циклы, в общем-то, не ограничены. Решая задачу "напиши мне сервис с чатиком" мыслительный процесс модели начинается с определения базиса - что такое пресловутый "сервис с чатиком" и идет искать в сети сервисы с чатиками. Если это умная RAG CLI, то она включает режим планировщика и идет уточнять у нерадивого пользователя что он под "сервисом с чатиком" понимает. Например Claude Code имеет этап "онбординга" нового проекта.

Когда мы определились что мы делаем браузерный мессенджер, RAG формирует новый контекст и идет загружать приглянувшиеся ей документации SDK и фреймворков, читает их и берется за поиск в сети через скрэтчер похожие проекты на гитхабе, в npm registry или куда дотянется механическая загребущая рука. На основе собранного контекста начинается этап планирования второго уровня: определение плана того, как будут расположены файлы, что в них будет написано и как это будет применено. Наконец, начинает писать код и валидировать написанное, пока цикл обработки запроса не остановится. Как правило, у CLI стоит ограничение цикла вызовов движка обработки по количеству обращений к моделям или иному критерию. По ходу дела в background заполняется база эмбеддингов.

А как это все превращается в код в репозитории, как модель ходит в сеть, как ищет нужные файлы? Модель - никак, она текст генерирует, классифицирует задачи и распознает.

Tools/function calling — ключевой механизм в RAG-агентах и CLI-системах для кодогенерации, позволяющий LLM динамически вызывать внешние функции (tools) на основе контекста запроса. Модель получает описание доступных инструментов в формате JSON-схемы, анализирует запрос и генерирует структурированный вызов вместо прямого текста. В RAG CLI это интегрируется в цикл: агент решает "нужен ли тул?", извлекает релевантный контекст из векторной базы, вызывает функцию (git clone, npm search, web scrape), получает результат и продолжает мышление/генерацию кода. Записывает код в репозиторий, валидирует, эмбеддит документацию — всё с лимитом вызовов и fallback на чистый RAG для простых задач.

То есть модель работает, инициируя вызов через JSON в своем цикле ядра функции, отдавая JSON вида:

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

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

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

Новый этап

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

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

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