Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Небольшую обучаемую модель научили точнее направлять закрытую LLM через API, не меняя веса основной модели. В нерецензированном препринте все числа получили сами авторы: AdviSD обошёл обучение только по итоговой награде на двух бенчмарках. Для команд с закрытой моделью-исполнителем это делает внешний обучаемый слой практичнее: дополнительные сигналы получают из уже записанных взаимодействий, без новых запусков исполнителя.
Почему полезное исправление может мешать обучению
В этой архитектуре модель-советник читает историю взаимодействия и перед каждым ответом предлагает исполнителю инструкцию либо воздерживается. Исполнитель остаётся замороженным: совет попадает только в текущий запрос и не меняет его веса или постоянную историю.
Обычное обучение с подкреплением сообщает советнику, завершилась ли задача успешно, но плохо показывает, какой именно совет следовало изменить. Самодистилляция даёт более точный сигнал: копия советника видит завершённую сессию, результаты инструментов и проверки, а затем учит рабочую модель, которой доступен только исходный контекст.
Проблема возникает, когда исправление звучит разумно, но не меняет поведение исполнителя. Например, исполнитель и без подсказки правильно ищет рейс, но ошибается при выборе идентификатора пассажира. Развёрнутая инструкция по поиску будет корректной, однако учиться на ней незачем: общие параметры советника изменятся и могут ухудшить советы в других состояниях.
Теоретическая модель в работе показывает, как такие исправления задают предел обучения. По мере улучшения советника устранимые ошибки встречаются реже, а ошибки, на которые совет не влияет, остаются. Если сохранять все исправления, бесполезные постепенно занимают большую долю обучающего сигнала и тянут общие параметры в сторону менее полезных советов.
Как AdviSD выбирает решения для самодистилляции
AdviSD разделяет создание исправления и решение учиться на нём. После неидеальной сессии отдельная модель анализирует ответы исполнителя, результаты инструментов и проверки, а затем отмечает решения советника, которые стоило пересмотреть.
Для каждого отмеченного решения советник оценивает один и тот же уже записанный ответ исполнителя дважды: в контексте с выданным советом и без него. Разница показывает, насколько совет меняет предсказание ответа. Метод использует модуль этой разницы как признак влияния, поэтому ему не нужны вероятности токенов от закрытого исполнителя или повторный прогон всей сессии.
Порог отбора калибруют до обучения. В контекст подставляют советы из других задач и измеряют, насколько они меняют оценку записанного ответа. Затем порог остаётся фиксированным. Если советник первоначально воздержался, сравнить два контекста нельзя: они совпадают, поэтому отмеченные пропуски проходят фильтр напрямую.
На выбранных решениях замороженная копия советника видит итоговую обратную связь и выступает учителем. Обучаемая копия получает только контекст, который будет доступен в реальной работе, и приближает своё распределение ответов к учительскому. Этот сигнал дополняет GRPO — обучение с подкреплением по итоговой награде, которое продолжает использовать все сессии.
В экспериментах советником служил Qwen3-8B, а исполнителями — Gemini и Claude. На BFCL-v3 AdviSD превысил GRPO на 4,2–6,4 процентного пункта, на EnvScaler — на 3,9–5,1 балла. По сравнению со случайным отбором того же объёма преимущество составило 2,5–4,9 балла; обратный фильтр, который предпочитал слабое влияние совета, оказался хуже GRPO.
Когда результат меняет архитектурный план
Работа поддерживает схему, в которой продукт использует закрытую LLM как исполнителя, а собственную меньшую модель — как управляемый слой адаптации. Если команда уже сохраняет полные сессии, вызовы инструментов и результаты проверок, AdviSD позволяет превратить эти записи в адресный обучающий сигнал, не запрашивая у поставщика внутренние вероятности и не оплачивая дополнительные прогоны исполнителя ради отбора исправлений.
Это не просто способ сократить число обучающих примеров. Контрольный опыт со случайным отбором сохранял столько же решений, но уступил целевому фильтру. Значит, в плане обучения стоит отдельно проектировать критерий полезности исправления, а не передавать модели-учителю все замечания после неудачной сессии.
Проверка охватывает советники Qwen3-8B, двух закрытых исполнителей и два основных бенчмарка; отдельно обученные советники также переносили поведение на ACEBench, ToolHop, τ2-bench и RoTBench, а также между версиями и семействами исполнителей. При этом перенос уступал обучению под конкретного исполнителя, поэтому слой советника пока разумнее считать адаптером для выбранной модели, а не универсальным посредником для любого API.
В рабочей системе цена метода — более сложный учебный контур: нужны полные записи взаимодействий, модель для разбора ошибок, парная оценка ответов и отдельная самодистилляция. Во время применения эти этапы не запускаются: перед каждым ответом работает только советник, который выдаёт инструкцию или воздерживается.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
