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

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

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

Эта статья — о том, как устроены модели и RAG-системы, и почему пора перестать очеловечивать ИИ и считать его магией.

Как всё начиналось

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

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

Способ обработки

RNN / LSTM: последовательный. Чтобы понять пятое слово, нужно обработать первые четыре.

Трансформер (LLM): параллельный для энкодера. Декодер при генерации последователен, но с параллелизацией вычислений внимания к уже сгенерированным токенам (через KV-кэш).

Память о прошлом

RNN / LSTM: фиксированный вектор h_t (скрытое состояние), который перезаписывается на каждом шаге.

Трансформер: динамически вычисляемые веса внимания. Они не хранятся между шагами, а пересчитываются.

Дальние связи

RNN / LSTM: расстояние = количество шагов. Чем дальше слова, тем сложнее установить связь (градиент затухает).

Трансформер: любое слово может «видеть» любое другое за один шаг внимания, но в декодере — с учётом авторегрессии.

Параллелизация

RNN / LSTM: плохо параллелится. GPU простаивает.

Трансформер: хорошо параллелится благодаря self-attention и отсутствию последовательных зависимостей внутри энкодера.

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

• окна контекста
• механизмы обработки сверхдлинных контекстов
• позиционные кодировки (RoPE, ALiBi)

Почему контекст ограничен

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

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

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

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

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

Главное ограничение — не вычисления, а память. Хранение полной матрицы 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 внешним поиском. Это главное практическое решение двух проблем: ограниченного контекста и устаревших знаний. RAG — не замена трансформеру, а надстройка над ним.

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

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

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

Что в итоге?

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

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

Анекдоты и абстракции

Идёт суслик по лесу. Навстречу лиса:
— Ты куда?
— На медведя посмотреть.
— Так он спит.
— Ну и пусть.
Идёт дальше. Волк:
— Суслик, ты куда?
— На медведя посмотреть.
— Он же спит!
— Ну и ладно.
Подходит к берлоге, а медведь сидит, газету читает.
— Ты почему не спишь?
— Да вот, суслик какой-то ходит, спать мешает.

Идёт бобёр по лесу. Навстречу лиса:
— Ты куда?
— На медведя посмотреть.
— Так он спит.
— Ну и пусть.
Идёт дальше. Волк:
— Бобёр, ты куда?
— На медведя посмотреть.
— Он же спит!
— Ну и ладно.
Подходит к берлоге, а медведь сидит, газету читает.
— Ты почему не спишь?
— Да вот, бобёр какой-то ходит, спать мешает.

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

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

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

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

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

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

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

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

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

• Эмбеддер: генерирует векторные представления текста
• Векторное хранилище: хранит и ищет похожие векторы
• Генератор: создаёт ответ на основе найденного контекста

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

Но есть важный этап: мышление. Это обработка задачи — начальная, промежуточная, завершающая. Циклы не ограничены.

На запрос «напиши сервис с чатиком» модель сначала определяет, что это такое. Умная RAG CLI включает режим планировщика и уточняет у пользователя детали. Например, Claude Code проходит этап «онбординга» проекта.

После уточнения (например, «браузерный мессенджер») RAG формирует контекст, ищет документацию SDK, фреймворков, сканирует GitHub и npm. На основе собранного контекста начинается планирование: как расположить файлы, что в них писать.

Затем модель пишет код, валидирует его, и цикл продолжается — до остановки по лимиту вызовов или другому критерию. Параллельно пополняется база эмбеддингов.

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

Function calling — ключевой механизм. LLM получает описание инструментов в формате JSON-схемы, анализирует запрос и генерирует структурированный вызов. В RAG CLI это встраивается в цикл: агент решает, нужен ли тул, извлекает контекст, вызывает функцию (git clone, npm search, web scrape), получает результат и продолжает.

Модель не исполняет код. Она генерирует JSON с описанием вызова. Исполнение — на внешнем рантайме (CLI, сервер).

Так LLM превращается из «болталки» в ядро принятия решений. Разработка становится сборкой «лоскутного одеяла» из готовых решений — как разработчики брали код со Stack Overflow, так RAG автоматизирует этот цикл.

Итог: модель — не исполнитель

В агентных системах с RAG и function calling модель не вызывает функции напрямую. Она генерирует JSON с описанием вызова. Исполнение — за пределами модели.

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

Новый этап

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

Теперь программист — это не столько исполнитель, сколько архитектор процессов. Прочная база знаний — computer science, логика, статистика, математика, умение применять абстракции — становится ключевым преимуществом.

Именно это позволяет превратить «болталку» в ядро технологий, невозможных ранее.

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

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

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

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

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

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

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

Характеристика

RNN / LSTM

Трансформер (LLM)

Способ обработки

Последовательный (слово за словом). Чтобы понять 5-е слово, нужно обработать 1,2,3,4-ое.

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

Память о прошлом

Фиксированный векторh_t(скрытое состояние), который перезаписывается на каждом шаге.

Динамически вычисляемые веса внимания — не хранятся между шагами, а пересчитываются

Дальние связи

Расстояние = количество шагов. Чем дальше слова, тем труднее (градиент тухнет).

Любое слово может «видеть» любое за один шаг внимания, но в декодере — с учётом авторегрессии

Плохо параллелится (GPU стоит).

Параллелится благодаря self-attention и отсутствию последовательных зависимостей внутри энкодера

Сегодняшние 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 и без прямого запроса опираться на, допустим хемотаксис бактерий. Модель знает, что градиентный спуск в шумной среде на ней основан, но самой вывести и подобрать с нуля без контекстной ограничивающей базы не сдюжит.Что нужно чтобы у модели получилось вывести алгоритм? Давайте спросим у самой модели, мне тут нечего добавить от себя:

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

Модель может "питаться" описанными идеями и концепциями, но при этом даже с 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 вида:

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

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

Новый этап

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

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

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