Проблема: почему ваша LLM тупит в сложных задачах
Представьте: вы настроили RAG-агента для HR-задач, как в одном из наших кейсов. Он хорошо отвечает на вопросы по базе знаний. Но стоит дать сложную задачу — «проанализируй этот трудовой спор и предложи три стратегии защиты» — и всё. Агент либо выдает поверхностный ответ, либо начинает галлюцинировать, либо просто сдается.
Классическое тонкое обучение (fine-tuning) и RAG здесь не работают. Они улучшают знания, но не улучшают рассуждения. Модель по-прежнему пытается решить многошаговую проблему одним прыжком. Это как попросить шахматиста сделать один ход, который сразу ведет к мату. Не работает.
Вот главное заблуждение: мы думаем, что LLM «рассуждают». На самом деле, они предсказывают следующий токен. Агентное обучение с подкреплением меняет эту парадигму — оно учит модель планировать последовательность действий для достижения цели.
Решение LinkedIn: превратить LLM в стратега, а не в энциклопедию
Команда LinkedIn столкнулась с той же проблемой в своих внутренних системах. Им нужны были агенты, которые могли бы не просто искать информацию, а выполнять сложные рабочие процессы: анализ профилей кандидатов, планирование коммуникаций, оценку рисков в контрактах.
Их подход — Agentic Reinforcement Learning. Суть в том, чтобы представить взаимодействие LLM с миром как марковский процесс принятия решений (MDP).
- Состояние (State): Текущий контекст диалога, история действий, результаты предыдущих шагов, внешние данные.
- Действие (Action): Что может сделать агент? Вызвать инструмент (поиск в базе, калькулятор, API), сгенерировать промежуточный вывод, задать уточняющий вопрос.
- Награда (Reward): Числовая оценка качества итогового результата. Не за каждый токен, а за финальный исход.
- Политика (Policy): Сама LLM, которая научилась выбирать действия, максимизирующие долгосрочную награду.
Это фундаментально отличается от обучения «правильным ответам». Мы учим модель процессу достижения правильного ответа. И это именно то, о чем мы говорили в статье про понимание цели LLM — теперь у модели появляется механизм, чтобы эту цель реально преследовать.
Архитектура тренировочного цикла: как заставить это работать на практике
В теории звучит красиво. На практике — ад с гиперпараметрами, нестабильностью обучения и дикими вычислительными затратами. LinkedIn разработала прагматичный цикл, который можно воспроизвести.
1Подготовка симулятора среды
Первое и самое сложное. Вам нужна среда, где агент может совершать действия и получать обратную связь. В реальном мире это пользователи — дорого и медленно. Значит, строим симулятор.
Для LinkedIn это была симулированная платформа с пользовательскими профилями, вакансиями, историей переписки. Симулятор умел оценивать действия агента (например, релевантность подобранного кандидата) по заранее заданным правилам и выставлять промежуточные и финальные награды.
2Выбор алгоритма RL: GRPO против PPO
Здесь начинается самое интересное. Классический выбор для RL с языковыми моделями — PPO (Proximal Policy Optimization). Но у PPO есть огромная проблема: он требует двух копий модели (актера и критика), что для LLM размером в десятки миллиардов параметров убийственно дорого.
LinkedIn в своих последних работах (на начало 2026 года) активно экспериментирует с GRPO (Group Relative Policy Optimization) — более новым и эффективным алгоритмом.
| Алгоритм | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| PPO | Стабильность, много готовых реализаций (trl, DeepSpeed Chat) | Огромные требования к памяти (2 модели), медленный | Для относительно небольших моделей (<7B) или когда стабильность критична |
| GRPO | Эффективнее использует память, быстрее сходится, лучше для больших моделей | Менее изучен, может быть чувствителен к гиперпараметрам | Для моделей от 13B и выше, когда нужно экономить ресурсы |
GRPO работает по принципу сравнения результатов внутри «группы» (batch) примеров, а не абсолютной оценки каждого действия. Это снижает variance и ускоряет обучение. Если вы выбираете между фреймворками, посмотрите наш разбор KEF vs OpenAI o3 — там тоже затронуты современные подходы к оптимизации.
3Дизайн функции награды (Reward Function)
Самая творческая и критическая часть. Награда — это то, что направляет обучение. Сделаете слишком простую — агент найдет глупый способ её максимизировать. Слишком сложную — обучение не сойдется.
LinkedIn использует композитные (составные) награды:
- Промежуточные награды: За корректное использование инструмента, за релевантный запрос к поиску. Небольшие положительные сигналы.
- Финальная награда: Основной вес. Оценивает итоговый ответ по нескольким осям: корректность, полнота, полезность, стиль.
- Штрафы: За нарушение правил (например, попытка вызвать несуществующий API), за излишнюю многословность, за отклонение от темы.
Часто для оценки финального ответа используют другую LLM (reward model), которую предварительно обучили на человеческих предпочтениях. Это отдельная большая задача.
4Сбор данных и итеративное обучение
Цикл выглядит так:
- Запуск: Текущая версия агента (политики) взаимодействует с симулятором, генерируя траектории (state-action-reward sequences).
- Оценка: Траектории оцениваются reward model и/или правилами симулятора.
- Обновление: Данные (траектории + награды) используются для обновления политики с помощью выбранного алгоритма RL (GRPO/PPO).
- Валидация: Новая политика тестируется на валидационном наборе сценариев. Если качество упало — откат, анализ, корректировка функции награды или гиперпараметров.
- Повтор: Цикл повторяется до достижения плато качества или исчерпания бюджета.
Этот замкнутый цикл — сердце системы. Без него вы просто потратите кучу денег на GPU впустую.
Где спотыкаются все: типичные ошибки при внедрении
Я видел десятки попыток внедрить RL для LLM. 90% проваливаются на одних и тех же граблях.
Ошибка 1: Слишком сложная функция награды с первого дня. Начинайте с простого бинарного сигнала (хорошо/плохо). Добавляйте сложность постепенно, только когда обучение стабилизируется.
Ошибка 2: Игнорирование катастрофического забывания. Модель, обучаясь новому поведению, забывает базовые навыки (например, грамматику). Решение: использовать регуляризацию (например, KL-дивергенцию относительно исходной модели) и постоянно тестировать на базовых задачах.
Ошибка 3: Прямой перенос в продакшн без A/B тестов. Агент, идеально работающий в симуляторе, может вести себя странно с реальными пользователями. Всегда нужен поэтапный rollout и человеческий мониторинг.
Ещё одна скрытая проблема — эпистемическая асимметрия, когда агент не знает, что он чего-то не знает. Подробнее об этой фундаментальной ловушке мы писали в статье про «Молчаливого ученого». В RL-цикле это может проявляться в том, что агент избегает сложных, но необходимых действий, потому что не уверен в их результате.
Что в итоге? RL — это новый этап, а не просто опция
Агентное обучение с подкреплением — это не «еще один трюк для LLM». Это переход от статических моделей, которые пассивно реагируют на запросы, к активным агентам, которые планируют, действуют и учатся на своих ошибках в многошаговых процессах.
Опыт LinkedIn показывает, что это работоспособно в промышленном масштабе. Но требует дисциплины: тщательный дизайн среды, прагматичный выбор алгоритмов (взгляните на GRPO), итеративный подход к построению функции награды и, самое главное, понимания, что вы учите не «правильным ответам», а стратегии их достижения.
Пока большинство команда бьются над улучшением RAG и тонкой настройкой, те, кто освоил RL-цикл, получают агентов принципиально другого уровня. Агентов, которые не просто ищут факты, а решают проблемы. И это, пожалуй, единственный путь к созданию по-настоящему полезного ИИ-ассистента, а не просто умного поисковика.
Если ваш RAG-агент уперся в потолок — возможно, пора смотреть в сторону RL. Начните с простого симулятора и бинарных наград. Первые результаты могут вас удивить.
