vegman.dev
Все статьи

IBM Granite 4.2: Детальный взгляд на то, как строятся агентные LLM

2026-09-08новость

IBM обновила свои модели Granite до версии 4.2, сосредоточившись на способности к рассуждению и агентной работе. Дело не в росте числа параметров, а в дообучении (SFT и многоэтапное RL поверх базовых моделей Granite 4.1) для создания моделей, которые могут использовать инструменты, работать в терминале и даже заниматься веб-серфингом. Обновление показывает, как создаются LLM, которые кроме текста умеют действовать в цифровом мире.

Агентность как основа архитектуры

Главное отличие Granite 4.2 в том, что модели (особенно версии 8B и 30B) проходят дополнительное обучение с подкреплением (agentic RL). Это обучение позволяет им действовать как агенты, а не выполнять инструкции по шагам: вызывать инструменты, редактировать и выполнять код, управлять терминалами, искать в интернете. Эта парадигма переводит LLM из роли пассивного собеседника в активного решателя задач, способного к автономной работе.

graph TD
  A[Запрос пользователя] --> B{"LLM (Thinking Mode)"}
  B --> C{Tool Calling / Planning}
  C --> D[Инструменты: Terminal, API, Web Search]
  D --> E[Наблюдение и результат]
  E --> B
Общая схема работы агентной LLM: от запроса до выполнения действия через инструменты.

Практика: режимы мышления и tool calling

Granite 4.2 поддерживает различные режимы «мышления»: `thinking`, `non-thinking` и `low-effort`. Эти режимы позволяют модели адаптировать свой подход к рассуждению в зависимости от задачи, оптимизируя ресурсы и скорость. Более того, модели нативно поддерживают вызов инструментов в формате OpenAI Function Calling, что значительно упрощает интеграцию с внешними системами и API. Модель может «думать», планировать действия, а также взаимодействовать со внешней средой.

Архитектура и обучение

Модели Granite 4.2 построены на архитектуре decoder-only dense transformer с рядом оптимизаций:

  • Внимание: Grouped Query Attention (GQA): у 8B и 30B 32 головы внимания, у 3B 40, KV-голов 8.
  • Позиционное эмбеддинг: Rotary Position Embedding (RoPE) с θ = 10,000,000.
  • Feed-Forward: MLP с активацией SwiGLU.
  • Нормализация: RMSNorm (ε = 1e-5).
  • Эмбеддинги: Раздельные входные/выходные эмбеддинги (не связанные).
  • Точность: bfloat16.
graph LR
  subgraph G["Модели IBM Granite 4.2"]
    A["3B dense<br/>embedding 2560, 40 слоев<br/>контекст 131072"]
    B["8B dense<br/>embedding 4096, 40 слоев<br/>контекст 131072"]
    C["30B dense<br/>embedding 4096, 64 слоя<br/>контекст 131072"]
    A --- B --- C
  end
Сравнение ключевых параметров моделей IBM Granite 4.2.

Pre-training и Fine-tuning

Базовые модели Granite 4.1, на которых построена 4.2, обучены с нуля на примерно 15 триллионах токенов с использованием пятифазной стратегии. Этот подход постепенно расширяет окно контекста до 512K токенов и переключается с широких веб-данных на курируемые высококачественные источники.

Supervised fine-tuning (SFT) трансформирует базовую модель в помощника, способного следовать инструкциям, рассуждать и использовать инструменты. Смесь данных для SFT включает 7.2 миллиона семплов (~100B токенов), из которых 31.6% составляют агентные данные, охватывающие разработку ПО (69%), вызов инструментов (12.1%), использование терминала (8.0%), математику (3.5%), поиск (0.8%) и действия (0.2%). Отдельная фаза SFT для 30B модели дополнительно усиливает агентное кодирование.

pie title SFT Data Mixture
    "Agentic Corpus (31.6%)" : 31.6
    "Non-Agentic Corpus (68.4%)" : 68.4
Распределение данных для Supervised Fine-Tuning (SFT) в Granite 4.2.

Почему это важно бизнесу

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

Мой угол

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

Применить у себя

Что проверить на практике

  • Как режимы `thinking`/`non-thinking` влияют на latency и точность в реальных агентных пайплайнах. Важно понять, когда стоит давать модели «думать» дольше, а когда достаточно быстрого ответа.
  • Насколько эффективно `agentic RL` проявляется в сложных задачах, требующих множества вызовов инструментов и итераций (например, в многошаговом решении проблем или автоматизации бизнес-процессов).
  • Сравнить способность к «саморефлексии» и коррекции ошибок в 8B и 30B моделях при столкновении с неожиданными результатами или отказами инструментов.
  • Протестировать `tool calling` с различными API, имитирующими взаимодействие с внутренними системами учета или внешними сервисами, чтобы оценить гибкость и надежность интеграции.

Как понять, что получилось

Успех будет измеряться качеством выдачи, а еще снижением количества человеческого вмешательства в работу агентов, уменьшением ошибок при использовании внешних инструментов и способностью модели адаптироваться к новым задачам без переобучения. Мой критерий успеха: агент стабильно справляется с задачей, требующей 3+ вызовов инструментов, и делает это с минимальными «галлюцинациями» в последовательности действий, требующих вмешательства человека. Это означает выполнение задачи без постоянного надзора.

Источники