Мое понимание LLM с точки зрения пользователя очень простое: есть сетка с весами (обученные параметры), токенизатор и декодер (преобразователи текста во входные и выходные токены), и трансформер (слои внимания), который перерабатывает входные токены и шаг за шагом предсказывает новые.

Я пробовал разные Модели (GPT, Gemini, Deepseek, Grok) — все они, на мой взгляд, работают примерно одинаково. На один и тот же запрос они дают очень похожие, а иногда и идентичные ответы. Это ожидаемо, ведь все современные LLM построены на одной и той же архитектуре — трансформерах.

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

Текст - это основа

Я как‑то попробовал прицепить картинку к вопросу для Deepseek'а и получил в ответ что‑то типа «не могу извлечь текст из изображения». LLM — это прежде всего про текст. Все знания, которые у них есть — из текста. Видео и аудио для дальнейшей обработки превращаются в текст. Результат — текстовый. Да, Модели могут создавать другие медиа на основе текста (изображения, видео, аудио), но это вне моих интересов.

Поэтому в основе ADSM (Agent Driven Software Management) лежит обработка текстов — тексты на входе и тексты на выходе.

Архитектура LLM

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

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

В целом архитектуру сети можно разложить по трём направлениям:

• Ширина — количество условных «нейронов» в одном слое сети. Это размерность вектора, в котором модель хранит представление («смысл») каждого токена. Чем шире вектор, тем больше признаков и оттенков значений способна различать модель. Но вместе с этим растут и вычислительные затраты.

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

• Связи — количество весов, соединяющих нейроны между слоями. Именно они определяют, как информация передаётся от одного уровня сети к другому. Чем больше связей, тем богаче возможности для обучения и точнее модель улавливает сложные зависимости между отдельными токенами. Но число связей растёт гораздо быстрее, чем ширина: если увеличить слой вдвое, то весов станет примерно в четыре раза больше. Вычислительные затраты растут очень быстро.

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

Контекстное окно

Каждая Модель обладает контекстным окном — пространством, в котором расположены токены текущего диалога. Размеры этого окна различны — от сотни тысяч токенов до миллиона. Важно понимать, что результат, который создаёт Модель, является частью контекстного окна так же, как и входные данные, которыми Модель оперирует, чтобы получить результат.

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

Каждая Модель имеет ограничения как на размер самого контекстного окона, так и на размер генерируемого результата (данные GPT‑чатика):

Важно очень чётко понимать два момента:

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

2. Какой максимальной размерности текстовый файл ваша Модель в принципе способна принять в качестве входного контекста.

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

Расширение и сужение контекста

В общем случае возможны две стратегии создания результата:

1. Расширение входного контекста.

2. Сужение входного контекста.

Пример первой стратегии:

Напиши сочинение на тему "Как я провёл лето" объёмом не менее 1К токенов.

В это случае у нас в общем контекстном окне входные данные занимают меньшую часть, а выходные — большую.

Пример второй стратегии:

Вычисли значение выражения: (12+4)*2. Ответь одним числом.

В этом случае наоборот — выходные данные занимают меньшую часть по сравнению со входными.

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

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

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

Создай минимальный файл package.json для npm-пакета со следующими характеристиками:

- имя пакета: ...
- описание: ...
- ...

Для себя в ADSM я использую промпты второго типа — с сужением контекста. Когда для генерации фрагмента кода может использоваться контекст в разы превышающий по объёму результат. У «кожаных» такой контекст часто называется coding conventions.

Размывание контекста

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

Понятно, что для сужения контекста входные данные должны быть подобраны таким образом, чтобы максимально нивелировать действие ГСЧ. Другими словами, для эффективного взаимодействия Человека и Модели в рамках ADSM их диалог должен строится по принципу one-shot: один вопрос — один ответ.

Если ответ Модели по какой‑то причине не может быть принят Человеком, то нужно не уточнять постановку задачи дополнительным запросом в рамках текущего диалога, а изменять первоначальный запрос и начинать новый диалог. Понятно, что такая стратегия возможно лишь в том случае, когда Человек очёнь чётко представляет желаемый результат, видит, что текущий ответ Модели ему не соответствует, и представляет, как нужно изменить первоначальный запрос.

Если же Человек находится в режиме «разведки» и исследует предметную область, то тут, конечно же, в диалоге (в контекстном окне) будет гораздо больше вопросов‑ответов. Но даже в таком случае нужно держать в фокусе основную тему беседы и прерывать текущий диалог и начинать новый, если фокус начал смещаться, а тема — расплываться (начали про рыбалку на поплавочную удочку, а потом перешли к основам металлообработки).

Заключение

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

• Входные и выходные данные — это текст или приведение к тексту в подавляющем большинстве случаев.

• Входные данные должны быть достаточно объёмны, непротиворечивы и связны, чтобы дать возможность Модели воспроизводимо генерировать желаемый результат.

• Результат генерации не может быть большим по размеру в силу того, что Модель использует общее контекстное окно для входных и выходных данных. Чем больше разница в объёмах, тем сложнее обеспечить повторяемость результата (сильнее «творческая» составляющая Модели — ГСЧ).

• Общение Человека и Модели в рабочем режиме (не «разведка») должно состоять из одного вопроса и одного ответа (one‑shot).

• Язык общения особой роли не играет. Можно давать запрос на русском, а результат генерировать на JavaScript.