Журнал · Rit.work

Synapse-Control убирает генеративную диагностику из контура агента

Synapse-Control выбирает советы для LLM-агента небольшим классификатором и примерно вдвое сокращает время на вспомогательный контроль без потери успешных завершений.

Rit.work
Студия разработки
11 ноября 2026 г.3 мин чтения

Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.

Агента научили применять прошлый опыт без нового текстового диагноза при каждом сбое. В препринте Zhiyuan Huang и соавторов, который не прошёл рецензирование и приводит замеры самих авторов, Synapse-Control дал больше успешных завершений, чем Base и Sentry, и примерно вдвое сократил время на вспомогательный контроль. Для систем со стабильными API это позволяет вынести память и проверку подсказок из основной модели в отдельную исполняющую среду.

Диагноз заменили оценкой готового совета

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

Sentry решает эту задачу через генеративный детектор: модель читает недавнюю историю, формулирует диагноз, выбирает связанные уроки, а затем передаёт их основной модели. Даже короткое исправление вроде «добавить обязательный аргумент» требует отдельной генерации текста.

Synapse-Control сначала извлекает из действий и ответов инструментов наблюдаемые признаки: отклонённый вызов, повторяющиеся чтения без изменения результата или несовпадение выбранного варианта с запросом. Правила по этим признакам отбирают до пяти подходящих советов.

Затем классификатор на 1,7 млрд параметров оценивает каждую пару «текущее состояние — готовый совет». Он выбирает одну из трёх категорий: совет полезен, уже не нужен или противоречит состоянию. Такая проверка заменяет генеративный детектор на 9 млрд параметров: модель больше не сочиняет промежуточное объяснение, а сравнивает состояние с конкретным вариантом действия.

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

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

Отдельная таблица ценности подсказок Prompt Value Table хранит историю их применения внутри задания. Она не повторяет совет, пока не получена обратная связь, состояние не изменилось или не закончилась заданная пауза. Лимит токенов и правило одной подсказки на шаг не дают памяти заполнить весь контекст.

Меньше управляющих вызовов, больше завершённых заданий

Synapse-Control успешно завершил 270 попыток. Sentry завершил 256, а агент без механизма восстановления Base — 208. Значит, экономия на диагностике не свелась к отключению полезной проверки: итоговая доля завершений выросла относительно обеих альтернатив.

Новая схема заменила 4 987 генеративных вызовов диагностики прямой оценкой готовых советов. Время на вспомогательный контроль сократилось примерно на 50% в обеих средах. Проверка результата, публикация подтверждённых уроков и исправление жёстких ошибок при этом остались в контуре.

Выигрыш возник не только внутри контроллера. Когда агент получал меньше повторных или конфликтующих указаний, он совершал меньше лишних действий, поэтому сокращалась и полная работа над заданием. Это отличает подход от обычной замены большой модели маленькой: Synapse-Control меняет сам тип вычисления с генерации диагноза на выбор среди ограниченного набора советов.

Когда отдельный контроллер меняет архитектурный план

Работу проверяли в AppWorld, где агент пишет вызовы API, и WebShop, где он ищет и выбирает товары. Для каждого метода выполнили 1 308 попыток с одинаковой основной моделью и одинаковым набором заданий. Основной сценарий статьи — локально развёрнутые агенты, которые многократно работают со стабильными API или веб-интерфейсами.

Для такой системы память стоит проектировать не как длинный текст, который всегда добавляется в запрос, а как набор локальных проверок с явными условиями применения. Тогда дешёвые правила отвечают за первичный поиск, небольшой классификатор — за уместность, а таблица истории — за частоту доставки. Основная LLM сохраняет планирование и формирует действия.

Цена этой схемы — отдельный слой предметной интеграции. Для нового окружения нужны адаптер наблюдений, сведения об интерфейсах, шаблоны микроконтрактов и калибровка контроллера под основную модель. Классификатор также обучали специально на состояниях целевого агента, поэтому результаты не означают, что готовую модель можно без настройки подключить к любому набору инструментов.

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

Источники

Пауза в чтении

Похоже на вашу задачу?

Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.

Rit.work

Студия разработки

Собираем мобильные приложения и помогаем командам получать от AI реальную пользу. Основатель и команда, работаем удалённо — с клиентами в России и за рубежом.

← Ко всем материалам
Понравилось? Обсудим вашу задачу