Мое понимание LLM с точки зрения пользователя очень простое: есть сетка с весами (обученные параметры), токенизатор и декодер (преобразователи текста во входные и выходные токены), и трансформер (слои внимания), который перерабатывает входные токены и шаг за шагом предсказывает новые.
Я пробовал разные Модели (GPT, Gemini, Deepseek, Grok) — все они, на мой взгляд, работают примерно одинаково. На один и тот же запрос они дают очень похожие, а иногда и идентичные ответы. Это ожидаемо, ведь все современные LLM построены на одной и той же архитектуре — трансформерах.
Это значит, что у всех реализаций есть общий шаблон поведения, отражающий их природу. В этой публикации я опишу наиболее важные, с моей точки зрения, характеристики Моделей, на которых я строю своё с ними общение.
Текст - это основа
Я как‑то попробовал прицепить картинку к вопросу для Deepseek'а и получил в ответ что‑то типа «не могу извлечь текст из изображения». LLM — это прежде всего про текст. Все знания, которые у них есть — из текста. Видео и аудио для дальнейшей обработки превращаются в текст. Результат — текстовый. Да, Модели могут создавать другие медиа на основе текста (изображения, видео, аудио), но это вне моих интересов.
Поэтому в основе ADSM (Agent Driven Software Management) лежит обработка текстов — тексты на входе и тексты на выходе.
Архитектура LLM
Если очень грубо, вычислительная мощь нейронной сети определяется числом нейронов и связей между ними. Один нейрон может быть связан с тысячами других. Количество нейронов и организация их в слои влияют на точность модели и её способность оперировать сложными смыслами. «Знания» в нейросети распределены по весам этих связей, а также частично закодированы в механизмах токенизации и декодирования.
Одна и та же в архитектурном смысле сеть может по‑разному отвечать на один и тот же запрос в зависимости от того, на каких данных она обучалась. В результате мы получаем архитектурно идентичные модели, но с разными значениями параметров и схемой токенизации — разных «экспертов»
В целом архитектуру сети можно разложить по трём направлениям:
Ширина — количество условных «нейронов» в одном слое сети. Это размерность вектора, в котором модель хранит представление («смысл») каждого токена. Чем шире вектор, тем больше признаков и оттенков значений способна различать модель. Но вместе с этим растут и вычислительные затраты.
Глубина — количество слоёв сети. Каждый слой последовательно преобразует вектор токена, добавляя новые взаимосвязи и уровни абстракции. Чем глубже сеть, тем сложнее закономерности она способна улавливать и тем более связные ответы может строить. Но вместе с этим растут и вычислительные затраты.
Связи — количество весов, соединяющих нейроны между слоями. Именно они определяют, как информация передаётся от одного уровня сети к другому. Чем больше связей, тем богаче возможности для обучения и точнее модель улавливает сложные зависимости между отдельными токенами. Но число связей растёт гораздо быстрее, чем ширина: если увеличить слой вдвое, то весов станет примерно в четыре раза больше. Вычислительные затраты растут очень быстро.
Каждый новый токен вычисляется полным проходом через всю архитектуру сети: по всем слоям, по всей ширине векторов и с использованием всех связей. На каждый шаг генерации приходится отдельный прогон по модели. В классическом подходе это обеспечивает максимальное качество ответа, но делает процесс крайне ресурсоёмким. Современные оптимизации (разреженное внимание, выборочные «эксперты») позволяют уменьшить количество реально используемых параметров и обрабатывать больше текста, жертвуя частью точности ради экономии вычислений.
Контекстное окно
Каждая Модель обладает контекстным окном — пространством, в котором расположены токены текущего диалога. Размеры этого окна различны — от сотни тысяч токенов до миллиона. Важно понимать, что результат, который создаёт Модель, является частью контекстного окна так же, как и входные данные, которыми Модель оперирует, чтобы получить результат.
Вообще, в диалоге с Моделью каждый ответ Модели на ваш вопрос на следующем шаге становится входными данными в том же контекстном окне:
Каждая Модель имеет ограничения как на размер самого контекстного окона, так и на размер генерируемого результата (данные GPT‑чатика):
Модель | Общее окно | Макс. выход |
|---|---|---|
Claude 3.7 Sonnet | 200k | ~128k |
GPT-4o | 128k | ~64k |
GPT-4.1 | 1M | 32k |
Gemini 1.5 Pro | 1M (до 2M) | ~60–65k |
Gemini 2.5 Pro | 1M | н/д |
Grok 3 | 1M (заявлено) | ~128k |
Grok 4 | 128k–256k | н/д |
Важно очень чётко понимать два момента:
Какой максимальной размерности текстовый файл ваша Модель в принципе способна сгенерировать в результате.
Какой максимальной размерности текстовый файл ваша Модель в принципе способна принять в качестве входного контекста.
Разработчики различных Моделей заявляют о больших контекстных окнах, но нужно помнить об их архитектуре: вычислительные затраты растут с шириной и глубиной сети и особенно быстро — с увеличением числа связей, а также напрямую зависят от объёма входных и выходных данных. Понятно, что на больших заявленных контекстах Модели в целях экономии будут так или иначе оптимизировать свои вычисления. А это значит, что чем меньше заявленное контекстное окно, тем с меньшим количеством «оптимизаций» относительно базового уровня будет работать Модель.
Расширение и сужение контекста
В общем случае возможны две стратегии создания результата:
Расширение входного контекста.
Сужение входного контекста.
Пример первой стратегии:
Напиши сочинение на тему "Как я провёл лето" объёмом не менее 1К токенов.В это случае у нас в общем контекстном окне входные данные занимают меньшую часть, а выходные — большую.
Пример второй стратегии:
Вычисли значение выражения: (12+4)*2. Ответь одним числом.В этом случае наоборот — выходные данные занимают меньшую часть по сравнению со входными.
Первый пример использует творческие способности Модели и даёт разные результаты при повторных запусках. Второй пример даёт один и тот же результат в подавляющем большинстве случаев даже на разных Моделях.
Понятно, что с точки зрения воспроизводимости результата первый подход не может использоваться вообще.
Сужение контекста позволяет получать достаточно стабильный результат для заданного шаблона и набора переменных:
Создай минимальный файл package.json для npm-пакета со следующими характеристиками:
- имя пакета: ...
- описание: ...
- ...Для себя в ADSM я использую промпты второго типа — с сужением контекста. Когда для генерации фрагмента кода может использоваться контекст в разы превышающий по объёму результат. У «кожаных» такой контекст часто называется coding conventions.
Размывание контекста
Однако не всегда большой входной контекст будет давать повторяющийся результат при повторных прогонах. Если входной контекст неоднородный, содержит слишком много несвязанных, а то и противоречивых вводных, то результат может отличаться от генерации к генерации даже на одной Модели. В этом случае в игру вступает «творческая» составляющая Моделей — ГСЧ (генератор случайных чисел).
Понятно, что для сужения контекста входные данные должны быть подобраны таким образом, чтобы максимально нивелировать действие ГСЧ. Другими словами, для эффективного взаимодействия Человека и Модели в рамках ADSM их диалог должен строится по принципу one-shot: один вопрос — один ответ.
Если ответ Модели по какой‑то причине не может быть принят Человеком, то нужно не уточнять постановку задачи дополнительным запросом в рамках текущего диалога, а изменять первоначальный запрос и начинать новый диалог. Понятно, что такая стратегия возможно лишь в том случае, когда Человек очёнь чётко представляет желаемый результат, видит, что текущий ответ Модели ему не соответствует, и представляет, как нужно изменить первоначальный запрос.
Если же Человек находится в режиме «разведки» и исследует предметную область, то тут, конечно же, в диалоге (в контекстном окне) будет гораздо больше вопросов‑ответов. Но даже в таком случае нужно держать в фокусе основную тему беседы и прерывать текущий диалог и начинать новый, если фокус начал смещаться, а тема — расплываться (начали про рыбалку на поплавочную удочку, а потом перешли к основам металлообработки).
Заключение
Мой текущий практический опыт показывает, что отношения между Человеком и Моделью, с учётом конструктивных особенностей последних, должны строится исходя из следующих принципов:
Входные и выходные данные — это текст или приведение к тексту в подавляющем большинстве случаев.
Входные данные должны быть достаточно объёмны, непротиворечивы и связны, чтобы дать возможность Модели воспроизводимо генерировать желаемый результат.
Результат генерации не может быть большим по размеру в силу того, что Модель использует общее контекстное окно для входных и выходных данных. Чем больше разница в объёмах, тем сложнее обеспечить повторяемость результата (сильнее «творческая» составляющая Модели — ГСЧ).
Общение Человека и Модели в рабочем режиме (не «разведка») должно состоять из одного вопроса и одного ответа (one‑shot).
Язык общения особой роли не играет. Можно давать запрос на русском, а результат генерировать на JavaScript.
