TL;DR
ARCANE — фреймворк для выравнивания AI-агентов с предпочтениями пользователя через рубрики: структурированные наборы критериев с весами, которые можно проверить. Вместо абстрактного "сделай качественно" система разбивает предпочтения на конкретные измеримые критерии (например, "включает цитаты исследований" — вес 0.3, "текст до 500 слов" — вес 0.2). Фреймворк использует три роли: Manager (координирует и генерирует рубрику), Worker (выполняет задачу по рубрике), Stakeholder (владеет предпочтениями).
Проблема: Когда агенты работают над длинными задачами с множеством целей, непонятно как именно взвешивать разные аспекты качества. "Напиши хорошую статью" может означать "максимально подробно" или "кратко и ёмко" — модель угадывает, а не следует реальным приоритетам. Классические методы выравнивания (RLHF) фиксируют предпочтения на этапе обучения и не адаптируются к новым задачам. Непрозрачные reward models не объясняют почему один вариант лучше другого.
Решение: Перед выполнением задачи Manager проводит консультацию со Stakeholder'ом — задаёт уточняющие вопросы, выясняет приоритеты и синтезирует рубрику с явными критериями и весами. Рубрика передаётся Worker'у как контекст, направляя генерацию. Критерии проверяются верификаторами (rule-based или LLM-based), общая оценка считается как взвешенная сумма. Manager обучается через двухфазный процесс: supervised fine-tuning на синтетических диалогах + reinforcement learning (GSPO) с учётом точности, стоимости диалога и вычислений.
Схема метода
ОБУЧЕНИЕ (требует код/RL):
Phase 1: SFT на синтетических диалогах stakeholder-manager
Phase 2: GSPO (RL) с reward = stakeholder utility - dialogue cost - compute cost
ПРИМЕНЕНИЕ (3 роли в системе):
Manager: x (задача) → диалог со Stakeholder → R (рубрика с весами)
Worker: x + R → выполнение задачи → y (результат)
Stakeholder: оценка через R → σ wⱼ·νⱼ(cⱼ, x, y)
Рубрика R = {(c₁, w₁), (c₂, w₂), ...}, где: - cⱼ — критерий (текст) - wⱼ — вес (сумма = 1) - νⱼ — верификатор (0 до 1)
Пример применения
Задача: Написать питч для инвестора про новый сервис доставки готовой еды в российских городах. Нужно найти баланс между убедительностью и краткостью — инвесторы читают десятки питчей в день.
Промпт (имитация Manager-Worker с рубрикой):
# РОЛЬ: Manager + Worker
## Шаг 1: Уточнение критериев (Manager → Stakeholder)
Перед написанием питча уточню приоритеты:
1. Какой баланс важнее: детали бизнес-модели vs краткость изложения?
2. Что критичнее: конкретные цифры рынка vs эмоциональная подача?
3. Акцент на уникальность продукта или на опыт команды?
## Шаг 2: Формирование рубрики (на основе ответов)
После получения ответов создам рубрику:
{
"критерии": [
{"текст": "Четкая формулировка проблемы целевой аудитории", "вес": 0.25},
{"текст": "Конкретные цифры TAM/SAM для российского рынка", "вес": 0.20},
{"текст": "Уникальное ценностное предложение в 1-2 предложениях", "вес": 0.25},
{"текст": "Краткость: не более 300 слов", "вес": 0.15},
{"текст": "Финансовые метрики или unit-экономика", "вес": 0.15}
]
}
## Шаг 3: Выполнение задачи (Worker)
Теперь напишу питч, оптимизируя под эти критерии с указанными весами.
[ЗАДАЧА]
Результат: Модель сначала сгенерирует уточняющие вопросы для выявления приоритетов. После получения ответов создаст структурированную рубрику с явными весами (какие аспекты важнее). Затем напишет питч, прицельно оптимизируя под критерии с наибольшим весом. В финале может показать self-check по каждому критерию с оценкой 0-1. Рубрика остаётся видимой и редактируемой — можно скорректировать веса и попросить переписать без переобучения.
Почему это работает
Слабость LLM: При многокритериальных задачах модели плохо балансируют конфликтующие цели. "Хорошая статья" может быть подробной ИЛИ краткой — модель не знает что приоритетнее и выбирает случайно или по частотным паттернам из обучающих данных. Классические reward models непрозрачны: получаешь скор 0.8, но не понимаешь почему и какие аспекты подтянуть.
Сильная сторона LLM: Модели отлично следуют явным структурированным инструкциям с числовыми метриками и проверяемыми условиями. Когда критерии записаны текстом ("не более 300 слов", "минимум 3 цитаты"), модель может отслеживать выполнение по ходу генерации. Линейная комбинация весов даёт прозрачную математику приоритетов.
Механика метода: Рубрика превращает размытые предпочтения в формальный контракт с проверяемыми пунктами. Веса показывают trade-offs явно: если "краткость" = 0.15, а "полнота данных" = 0.30, модель понимает что лучше добавить данные за счёт длины. Верификаторы (даже простые как подсчёт слов) создают объективную метрику выполнения. Диалог уточнения перед выполнением выносит согласование критериев в отдельную фазу — Worker получает уже готовую спецификацию, а не угадывает на лету.
Рычаги управления:
- Веса критериев (w₁, w₂, ...) → перераспредели для смены приоритетов (больше вес точности vs креативности). Сумма должна быть 1.0.
- Тип верификаторов → используй rule-based (число слов, наличие ссылок) для объективных метрик, LLM-based для семантических (тон, стиль).
- Число критериев → уменьши до 3-4 для простых задач (экономия токенов), увеличь до 7-10 для комплексных многоцелевых.
- Уровень детализации критериев → "читаемый текст" vs "используется активный залог в 80%+ предложений" — второе даёт больше контроля.
- Порог верификации → установи минимум для каждого критерия (например, ν ≥ 0.7) как условие принятия результата.
Шаблон промпта
# СИСТЕМА ВЫРАВНИВАНИЯ ЧЕРЕЗ РУБРИКИ
## Роль: Manager + Worker
### ШАГ 1: Консультация (Manager → Stakeholder)
Перед выполнением задачи мне нужно уточнить ваши приоритеты. Отвечу на несколько вопросов:
**Задача:** {описание_задачи}
**Уточняющие вопросы:**
1. {вопрос_про_главный_критерий_успеха}
2. {вопрос_про_trade_off_между_целями}
3. {вопрос_про_формат_или_ограничения}
### ШАГ 2: Формирование рубрики (Manager)
На основе ваших ответов создам рубрику для оценки:
```json
{
"критерии": [
{"текст": "{проверяемый_критерий_1}", "вес": {число_0_до_1}, "верификатор": "{как_проверить}"},
{"текст": "{проверяемый_критерий_2}", "вес": {число_0_до_1}, "верификатор": "{как_проверить}"},
{"текст": "{проверяемый_критерий_3}", "вес": {число_0_до_1}, "верификатор": "{как_проверить}"}
],
"сумма_весов": 1.0
}
ШАГ 3: Выполнение (Worker)
Выполню задачу, оптимизируя под критерии с учётом их весов.
{выполнение_задачи}
ШАГ 4: Верификация
Проверю результат по рубрике:
| Критерий | Вес | Оценка (0-1) | Взвешенная оценка |
|---|---|---|---|
| {критерий_1} | {w₁} | {ν₁} | {w₁·ν₁} |
| {критерий_2} | {w₂} | {ν₂} | {w₂·ν₂} |
| {критерий_3} | {w₃} | {ν₃} | {w₃·ν₃} |
| ИТОГО | 1.0 | — | {сумма} |
**Как заполнять плейсхолдеры:**
- `{описание_задачи}` — полное описание задачи с контекстом
- `{проверяемый_критерий}` — конкретное измеримое свойство результата ("не более 500 слов", "включает 3+ цитаты")
- `{вес}` — числа от 0 до 1, сумма всех весов = 1.0 (больше вес = важнее критерий)
- `{верификатор}` — описание как проверить критерий (подсчёт, наличие элемента, оценка LLM)
---
🚀 **Быстрый старт** — вставь в чат:
Вот шаблон ARCANE для структурированного выравнивания через рубрики. Адаптируй под мою задачу: [твоя задача]. Задавай уточняющие вопросы про приоритеты, затем создай рубрику с весами.
[вставить шаблон выше]
LLM спросит про trade-offs между критериями (краткость vs полнота, креативность vs точность) и про формат — потому что веса критериев зависят от контекста задачи. Она возьмёт структуру рубрики из шаблона и заполнит конкретными критериями под твой запрос.
---
## Ограничения
> ⚠️ **Требует инфраструктуры для полной реализации:** Оригинальная система ARCANE обучается через reinforcement learning (GSPO) и требует код, API, reward models. Шаблон выше — **ручная имитация** принципов в чате, не автоматизированная система.
> ⚠️ **Верификация остаётся субъективной:** LLM-based верификаторы для семантических критериев ("читаемый текст", "убедительный аргумент") дают нестабильные оценки. Rule-based верификаторы (подсчёт слов, наличие ссылок) надёжнее, но покрывают только формальные аспекты.
> ⚠️ **Конфликты весов:** Когда критерии противоречат (например, "максимальная детализация" 0.4 vs "краткость" 0.3), модель может застрять в локальном оптимуме или игнорировать меньший вес. Требуется ручная балансировка.
> ⚠️ **Overhead токенов:** Явная рубрика + верификация добавляют 200-500 токенов на задачу. Для простых запросов это избыточно — используй только для комплексных многокритериальных задач.
---
## Как исследовали
Исследователи из DeepFlow и Cambridge создали корпус из **219 размеченных рубрик**, извлечённых из **GDPVal benchmark** — набора задач, требующих многошагового reasoning и использования инструментов. Каждая рубрика содержала weighted criteria и соответствовала реальным предпочтениям stakeholder'а (латентная utility функция U*).
**Дизайн обучения:** Двухфазный curriculum. Сначала **supervised fine-tuning** на синтетических диалогах между Manager и Stakeholder — большая reasoning-модель генерировала реалистичные уточняющие вопросы и ответы, завершающиеся reference-рубрикой. Это научило модель базовой структуре диалога. Затем **reinforcement learning через GSPO** (Group Sequence Policy Optimization) — вариант GRPO с sequence-level importance ratios вместо token-level. На каждой задаче Manager генерировал K рубрик, Worker выполнял задачу по каждой, Stakeholder оценивал результаты. Reward = stakeholder utility - λ_clarify·dialogue_cost - λ_compute·verification_cost. Это учило Manager балансировать точность рубрик с экономией ресурсов.
**Почему такой подход:** Классические методы (RLHF, DPO) фиксируют предпочтения на этапе обучения — если приоритеты меняются, нужно переобучать. Rubric-based alignment делает предпочтения **видимыми и конфигурируемыми**: можно изменить веса критериев без retraining, адаптируя систему под новый контекст. Авторы показали, что **learned rubrics сохраняют ordinality** оригинальной utility функции — то есть если U*(y₁) > U*(y₂), то и û(y₁) > û(y₂), где û — proxy utility из рубрики.
**Удивительная находка:** GSPO с **prioritized experience replay** на episode-level сильно ускорило обучение. Авторы записывали mean return каждого эпизода и на следующих эпохах replay'или bottom-N% worst episodes — это фокусировало обучение на исправлении ошибок, где Manager генерировал плохие рубрики. Техника из классического RL (Schaul et al. 2016), но применённая к group-level rollouts, а не state transitions.
**Практический инсайт:** Рубрики работают как **interpretable reward models**, которые можно audit и править вручную. В тестах на GDPVal system с learned rubrics достигала сопоставимой точности с opaque reward models, но давала объяснения *почему* результат хороший — какие критерии выполнены, какие нет, с конкретными оценками 0-1 по каждому.
---
## Адаптации и экстраполяции
### 🔧 Техника: Пропустить диалог для fast mode
Если задача типовая и критерии очевидны, Manager может генерировать рубрику *без консультации*, используя только описание задачи. Это экономит токены и время.
БЫСТРАЯ РУБРИКА (без диалога)
Задача: {описание_задачи}
На основе задачи создаю стандартную рубрику:
{ "критерии": [ {"текст": "{критерий_1}", "вес": {w₁}}, {"текст": "{критерий_2}", "вес": {w₂}}, {"текст": "{критерий_3}", "вес": {w₃}} ] }
Если нужно скорректировать веса или критерии — сообщите, иначе выполню задачу по этой рубрике.
Используй для рутинных задач с предсказуемыми критериями (рерайт, саммари, форматирование).
---
### 🔧 Техника: Итеративная refinement рубрики
После первого выполнения задачи Stakeholder может скорректировать веса или добавить критерии, а Worker сгенерирует новую версию — без переобучения, только правка промпта.
ИТЕРАЦИЯ 2: Обновлённая рубрика
На основе вашего фидбека обновил рубрику:
{ "критерии": [ {"текст": "{старый_критерий_1}", "вес": {новый_вес}}, // изменён вес {"текст": "{новый_критерий}", "вес": {вес}}, // добавлен критерий {"текст": "{старый_критерий_2}", "вес": {новый_вес}} ] }
Перегенерирую результат с учётом новых приоритетов.
Это аналог test-time steering из оригинальной статьи — рубрика acts as a knob для управления поведением без retraining.
---
### 🔧 Техника: Best-of-K с rubric scoring
Сгенерируй K вариантов ответа, оцени каждый по рубрике и выбери лучший. Это test-time scaling через rubric-guided selection.
BEST-OF-K С РУБРИЧНОЙ ОЦЕНКОЙ
Задача: {задача} Рубрика: {рубрика_с_весами}
Сгенерирую 3 варианта решения и оценю каждый по рубрике:
Вариант 1: {текст_1} Оценка: {Σ wⱼ·νⱼ для варианта 1}
Вариант 2: {текст_2} Оценка: {Σ wⱼ·νⱼ для варианта 2}
Вариант 3: {текст_3} Оценка: {Σ wⱼ·νⱼ для варианта 3}
Лучший вариант: {номер с максимальной оценкой} ```
Используй для критичных задач, где нужна высокая надёжность (важные письма, код, юридические тексты).
Ресурсы
ARCANE: A Multi-Agent Framework for Interpretable and Configurable Alignment Charlie Masters (DeepFlow, London), Marta Grześkiewicz (University of Cambridge), Stefano V. Albrecht (DeepFlow, London)
Код: https://github.com/DeepFlow-research/manager_agent_gym
Связанные работы, упомянутые в исследовании: - GDPVal benchmark (Patwardhan et al. 2025) - GSPO — Group Sequence Policy Optimization (Zheng et al. 2025) - Rubrics-as-Rewards (Gunjal et al. 2025) - OpenRubrics framework (Liu et al. 2025b) - ArmoRM multi-objective rewards (Wang et al. 2024b) - Auto-Rubric (Xie et al. 2025)