Современные LLM – это больше, чем просто предсказание слов

«Эта модель лучше шутит, а та лучше пишет код» — отличный критерий выбора, если вы просто переписываетесь с чатиком. Но как только LLM оказывается внутри продукта, нас перестаёт интересовать юмор и начинает волновать архитектура: encoder–decoder против decoder‑only, мультимодальные энкодеры, test‑time reasoning, скрытые цепочки рассуждений. В этом посте попробуем перестать выбирать между логотипами и посмотреть на языковые модели как на инженерные конструкции с понятными trade‑off’ами.

В первоначальной архитектуре трансформера кодировщик (encoder) и декодировщик (decoder) были равноправны. Кодировщик формировал контекстное представление входных данных, а декодировщик последовательно генерировал выходные данные на основе этого представления. Сейчас в языковых моделях преобладают чистые декодировщики, но с 2024–2025 годов наблюдается тенденция к возврату гибридных архитектур и моделей рассуждений, где логический вывод выделяется в отдельный этап.

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

Сравнение архитектур encoder–decoder и decoder-only: что меняется?

Классическая архитектура encoder–decoder

В архитектуре encoder–decoder входной текст обрабатывается стеком кодировщиков:

• Кодировщик создает двунаправленное контекстное представление, где каждый токен учитывает весь входной текст.

• Декодировщик генерирует выходные данные авторегрессионно, опираясь на предыдущие выходные данные и перекрестное внимание к выходу кодировщика.

Эта схема широко применялась в машинном переводе (T5, BART и их производные) из-за:

• улучшенной эффективности использования данных: проще выучить соответствие “вход → выход” как две подзадачи – “понять” и “сказать”;

• естественного создания узкого места в виде скрытого представления, к которому можно подключать дополнительные задачи (классификация, разметка и т.п.).

Архитектура Decoder-only: классика GPT

Decoder-only архитектура отбрасывает кодировщик и обучает один большой авторегрессионный блок для предсказания следующего токена. Это упрощает:

• процесс обучения (одна модель, одна функция потерь);

• масштабирование по параметрам и данным;

• решение задач по продолжению текста.

Но это приводит к тому, что:

• вход и выход находятся в одном пространстве;

• модель понимает и генерирует в одном и том же блоке, из-за чего сложнее контролировать понимание входных данных.

• На практике большинство популярных LLM для кода и чатов – это семейства decoder-only (GPT, Claude, Gemini, DeepSeek-V, LLaMA, Mistral и т.п.).

Зачем возвращаться к кодировщикам?

В настоящее время кодировщик возвращается, но не в классической форме seq2seq, а как отдельные компоненты:

• специализированные текстовые кодировщики для эмбеддингов и поиска;

• визуальные и мультимодальные кодировщики, предоставляющие вектор, с которым работает текстовый декодировщик;

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

Современная LLM-система – это конвейер: кодировщик → индекс/поиск → модуль рассуждений → декодировщик.

От генерации к рассуждению: что такое модели рассуждений?

Классические LLM обучались как модели распределения текста: максимизировать вероятность следующего токена на основе истории. В 2022–2023 это дополнили подходом chain-of-thought (CoT): модель должна проговаривать шаги рассуждения перед ответом. В 2024–2025 появился отдельный класс моделей рассуждений (DeepSeek-R1, модели o-серии и их производные), где процесс мышления становится отдельным этапом вычислений.

Chain-of-thought как способ взаимодействия

CoT подход прост: вместо ответь мы просим объясни шаги, затем дай ответ. Это:

• повышает точность в задачах с несколькими логическими шагами;

• предоставляет читаемый ход мыслей для человека.

Минусы:

• использование токенов увеличивает время и стоимость;

• модель остаётся той же, изменяется только способ взаимодействия.

Test-time search и скрытое мышление

Модели рассуждений нового поколения выполняют CoT внутри, не показывая его пользователю.

Основные идеи:

• модель генерирует множество внутренних цепочек рассуждений;

• оценивает их с помощью вспомогательных сетей и эвристик;

• выбирает или объединяет лучшую цепочку и преобразует её в финальный ответ.

DeepSeek-R1 комбинирует обучение на размеченных reasoning-трейсах и механизмы выбора ветки, чтобы поощрять цепочки, приводящие к правильному ответу. OpenAI использует похожие идеи test-time search и скрытого CoT.

На практике это приводит к:

• повышению точности в задачах с многошаговой логикой, математикой, кодом;

• возможности делать ответы короче, исключая длинные рассуждения.

Влияние архитектуры на реальные сценарии

1. Код и архитектура приложений Для кода и системного проектирования важны:

• способность удерживать длинный контекст (монорепозитории, многомодульные системы);

• многошаговое рассуждение (не просто дописать функцию, а спланировать изменения);

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

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

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

С точки зрения encoder/decoder:

• отдельные кодировщики кода (CodeBERT) используются для поиска по репозиторию и навигации;

• LLM-декодировщик решает задачу редизайна/рефакторинга, имея релевантный контекст.

На практике стек выглядит так: кодировщик для поиска контекста → модель рассуждений → декодировщик для отображения кода.

2. Аналитика и бизнес-решения Для бизнес-аналитики и маркетинга важно объединять разнородные источники (таблицы, текст, события), сохранять причинно-следственные связи и объяснять вывод так, чтобы его можно было проверить.

В этих случаях подходят гибридные системы:

• кодировщики для табличных данных и данных о событиях;

• LLM-декодировщик для интерпретации и перевода на понятный язык;

• слой рассуждений для многошаговых сценариев (если изменить X, что будет с Y).

Чистые decoder-only LLM без механизмов рассуждений часто выдают красивую аналитику без логики, что вызывает опасения у специалистов по анализу данных.

3. Поиск, RAG и корпоративные ассистенты Фактический стандарт корпоративных ассистентов – это RAG:

• кодировщик создает эмбеддинги документов;

• векторный поиск выбирает релевантные фрагменты;

• LLM-декодирвщик отвечает на вопрос на основе найденного контекста.

Дополнительно используется модуль рассуждений (работает на теории вероятности):

• выбор нескольких гипотез ответа на основе разных документов;

• внутренняя перекрестная проверка между ними;

• формирование финальной версии с указанием источников.

Архитектурно это каскад из encoder → retriever → reasoning-LLM → decoder.

Где encoder–decoder всё ещё полезен
Несмотря на преобладание decoder-only LLM, у классической архитектуры encoder–decoder есть свои области применения:

1. Машинный перевод и задачи input → output с четкой структурой.

2. Мультимодальные системы, где несколько кодировщиков (текст, изображение, аудио) объединяются с одним декодировщиком.

3. Сценарии, где важно разделить понимание и говорение из соображений безопасности (можно добавить фильтры между ними).

Кроме того, encoder часто используется как универсальный инструмент для извлечения признаков: обученный кодировщик можно использовать для поиска, кластеризации и выявления аномалий.

Вывод: выбор модели = выбор архитектурного стека

Сейчас выбор LLM – это не просто выбор конкретной модели, а выбор архитектурного решения:

Нужен ли отдельный кодировщик для данных, кода или документов?
Нужен ли слой рассуждений с test-time search или достаточно классического декодировщика?
Какая часть конвейера наиболее критична по стоимости и задержке?

Чаще всего используется следующий стек:
Encoder – мультимодальные или текстовые кодировщики для поиска и семантики.
Reasoning – современные LLM для сложных задач, требующих рассуждений.
Decoder – модели для массовой генерации и взаимодействия с пользователем.

Вместо обсуждения какая модель лучше шутит, можно перейти к обсуждению конкретных архитектурных решений: где выгоден encoder–decoder, где достаточно decoder-only, а где без модели рассуждений невозможно избежать галлюцинаций. Но это будет в отдельной статье, а сейчас систематизируем понимание все-таки…

…Какие LLM наиболее подходят для различных задач.

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

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

Важное замечание: любая модель, используемая без необходимого окружения (инструментов, промптов, конвейеров данных), может выдать лишь около 60% от потенциально возможного результата. Остальное зависит от инженерной составляющей.

Критерии сравнения моделей.

Вместо субъективной оценки лучше использовать следующий чек-лист:
[ ] – Качество рассуждений.
Насколько успешно модель решает задачи, требующие нескольких шагов (проектирование архитектуры, анализ данных, сложные бизнес-запросы), не допускает ли галлюцинаций и способна ли поддерживать логическую цепочку аргументов.

[ ] – Качество текста.
Насколько хорошо модель пишет на нужном языке, придерживается заданного стиля, избегает канцеляризмов и однообразных выражений.

[ ] – Код.
Не просто генерирует отдельные функции, а понимает контекст всего репозитория, умеет выполнять рефакторинг, объяснять код и предлагать архитектурные решения.

[ ] – Контекст и память.
Не только формальный лимит на количество токенов, но и то, как модель обрабатывает большие объемы информации: не теряет ли важные детали после 50 сообщений и насколько хорошо отбрасывает ненужную информацию.

[ ] – Стоимость и скорость ответа.
Для личного использования высокая стоимость может быть приемлема. Но в рабочих условиях важна цена каждого запроса и скорость получения ответа.

[ ] – Правовые вопросы и инфраструктура.
Где можно размещать модель, какие есть SDK, как организована оплата, есть ли варианты установки на собственной инфраструктуре, как решаются вопросы защиты данных (PII, NDA).

Далее рассмотрим различные семейства моделей и их применение в реальных сценариях.

Claude: Мощный анализ и код.

Sonnet часто хвалят за его стабильность в трех областях:

Создание длинного связного контента.
Написание статей, документации, описаний продуктов, объяснений. Sonnet поддерживает стиль и структуру текста, не теряя логику на протяжении десятков абзацев.

Разработка и рефакторинг кода.
Sonnet хорошо подходит для рефакторинга сложного кода, объяснения чужого кода и анализа архитектуры сервисов. Особенно, если предоставить ему достаточно контекста (часть репозитория, архитектурные схемы, требования).

Человечность.
Sonnet умеет использовать шутки, метафоры и неформальный стиль, что делает его приятным в общении и полезным для решения творческих задач.

Opus имеет схожий подход, но его стоимость оправдана только для очень специфических задач: сложные исследования, юридические вопросы, due diligence. Для типичных задач в инженерии и бизнесе Sonnet дает почти такой же результат за меньшие деньги.

Когда стоит выбрать Claude:
Если нужен надежный помощник в проектировании архитектуры и разработке кода.
Если требуется писать длинные тексты, которые должны быть понятны человеку.
Если важна структура и связность больших объемов информации.

Когда не стоит выбирать:
Если нужна максимальная скорость и низкая стоимость обработки запросов.
Если основной язык не английский и не планируется выход на глобальный рынок (есть более простые и дешевые альтернативы).

Gemini: Когда нужно обрабатывать много данных.

Gemini хорошо работает с большим объемом разнородных данных:

Большой объем обрабатываемого текста.
Благодаря большим лимитам на контекст можно загружать большие документы, отчеты, спецификации, код и таблицы. Модель не сразу забывает, о чем шла речь.

Анализ таблиц.
Gemini уверенно справляется задачами, такими как проанализируй выгрузку из рекламного кабинета и найди ошибки или найди закономерности в CSV‑файле с данными о продажах. Особенно, если использовать предварительную обработку данных.

Интеграция с сервисами Google.
Gemini хорошо работает с GDrive, Sheets, документами и поиском Google.

Мнения о Gemini в отношении создания креативного контента и текстов расходятся. Кому‑то этого достаточно, но по стилю и живости он часто уступает Claude или GPT. Однако, он отлично подходит для задач, связанных с обработкой данных.

Когда стоит выбрать Gemini:
Если нужно работать с таблицами, отчетами и метриками.
Если нужно объединять текст, код и данные в одном сценарии.
Если вы уже используете продукты Google.

Когда не стоит выбирать:
Если основная задача — создание креативных текстов, написание историй и точная передача тональности.
Если важен точный контроль над формулировками (маркетинг, PR, общение с клиентами).

GPT: Универсальный инструмент.

GPT стал стандартом, поскольку охватывает широкий спектр задач.

Тексты.
Модели GPT хорошо справляются с:

• Маркетинговыми текстами

• Созданием структуры статей

• Адаптацией под разный стиль

Важное отличие — более аккуратная работа с формулировками: меньше повторений, лучшее чувство структуры, умение перефразировать мысль, сохранив смысл.

Модели GPT хорошо показывают себя в:

• Построении планов, дорожных карт, архитектурных решений

• Многошаговом анализе (от бизнес‑требований до схем и API)

• Проверке гипотез (что произойдет с экономикой, если мы увеличим цену?)

Код.
GPT хорошо справляется с типичными задачами разработки, генерацией шаблонов кода и может быть использован в качестве второго разработчика на простых задачах.
Мини‑версии GPT можно использовать в чат‑ботах: это дешево, быстро и достаточно эффективно для задач, таких как выделить объекты, сделать краткое изложение, определить намерение.

Когда стоит выбрать GPT:
Если нужен универсальный инструмент для всего с хорошим качеством.
Если нужен баланс между текстом, кодом и логикой.
Если важна экосистема: плагины, интеграции.

Когда стоит дополнить другими моделями:
Если есть специфическая задача, где другая модель работает лучше (например, Sonnet для сложного кода или Gemini для анализа таблиц).
Если требуется полный контроль и открытый исходный код.
DeepSeek, Qwen, LLaMA, Mistral: Открытый исходный код.
Модели с открытым исходным кодом — это не столько конкуренты GPT, сколько материал для создания собственных решений.

DeepSeek, Qwen:

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

Плюсы:

• Можно размещать на своей инфраструктуре

• Можно дообучать.

Минусы:

• Требуют инфраструктуры

• Качество зависит от сборки.

LLaMA, Mistral:

Имеет смысл создавать своих помощников, ботов и аналитиков.
Можно оптимизировать под конкретное оборудование.
Есть форки и дообученные варианты.

Использовать такие модели для конечного пользователя – не лучшая идея. Но в качестве основы собственного продукта или внутреннего инструмента – это хороший вариант.

Локальные модели: Когда важны данные.

Локальные модели – это ответ на вопросы:
У нас NDA, мы не можем передавать данные в облако.
Нам нужен ассистент, который знает только нашу область.

Что можно делать локально:

• Внутренний анализ логов, документации

• Поиск по внутренним знаниям

• Простые боты для поддержки.

Чего не стоит ожидать:

• Высокого качества без дообучения

• Работы со сложной логикой на слабом оборудовании.

Локальные LLM – это отдельный проект. Но там, где к данным есть жесткие требования, это единственный разумный путь.

Национальные модели: Gigachat, YandexGPT.

У национальных моделей есть несколько преимуществ:

Поддержка языка

• Юридическое удобство

• Интеграция с местной инфраструктурой.

Gigachat, YandexGPT можно рассматривать как:

• Инструмент для анализа данных

• Fallback-вариант.

По качеству они догоняют модели, но для многих задач достаточно хорошо оказывается важнее, чем максимум.

Какой набор моделей стоит использовать в будущем

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

Один из вариантов:
Для сложного анализа, кода и текстов: Claude + GPT, Sonnet.
Sonnet подходит для рассуждений и кода, GPT – для текстов и логики.

Для работы с таблицами: Gemini.
Можно использовать его в паре с чем-то другим: один извлекает закономерности, второй – упаковывает выводы.

Для автоматизации:
Недорогая модель + хорошо настроенные промпты.

Для приватных сценариев:
Open-source (DeepSeek, Qwen, LLaMA, Mistral).

Для локального рынка:
Национальная модель.

Что не стоит делать:

1. Выбирать модель по совету

2. Ожидать, что одна модель спасет продукт.

Реальный успех зависит от умения комбинировать.