Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Управляющую LLM в системе из нескольких моделей заменили явным оператором, который собирает ответ из частей и направляет следующие вызовы на оставшиеся пробелы. В препринте AWS Generative AI Innovation Center, который не прошёл рецензирование и содержит замеры самих авторов, такая замена улучшила шесть составных систем на 0,013–0,182 балла. Для продукта это вариант отделить генерацию содержания от правил, которые принимают части ответа, меняют состояние системы и останавливают цикл.
Как оператор собирает ответ без управляющей модели
Обычный LLM-менеджер читает ответы рабочих моделей, пишет итог, решает, что запросить дальше, и определяет момент остановки. Один генеративный вызов тем самым управляет сразу тремя решениями, может добавить неподтверждённый текст и по-разному отреагировать на иной порядок тех же входов.
UnitBoost требует заранее разделить результат на именованные единицы. В вопросе со списком это отдельный ответ, в таблице — сущность и её атрибут, в классе программы — сигнатура метода и реализация. Каждая рабочая модель предлагает значения для таких позиций, а оператор выбирает лучшее значение отдельно для каждой.
Выбор опирается на оценку качества и проверку допустимости итоговой комбинации. В варианте для внедрения оценка учитывает согласие рабочих моделей, место значения в их ответах, наличие подтверждения в найденных материалах и дополнительную проверку по источнику. Правила разрешения ничьих фиксированы, поэтому перестановка одинакового набора предложений не меняет результат.
Для каждого принятого значения система сохраняет рабочую модель, раунд, оценку и результат проверки ограничений. Пустые, сомнительные или несовместимые позиции образуют остаток (residual), который получает следующий набор рабочих моделей. Новые ответы попадают в постоянную таблицу и конкурируют с уже принятыми значениями, а не переписывают весь результат заново.
Если позиции не зависят друг от друга, выбор лучшего значения в каждой из них не может уступить выбору одного готового ответа по той же оценке. Преимущество появляется только тогда, когда рабочие модели ошибаются или пропускают разные части: если одна модель лучшая во всех позициях, оператору нечего комбинировать.
Раздельный выбор частей оказался важнее нового генератора
На QAMPARI UnitBoost получил 0,4685 против 0,3967 у лучшего цельного ответа, выбранного с помощью правильных меток. Это показывает структурный эффект: оператор может взять разные правильные элементы у разных рабочих моделей, тогда как даже идеальный селектор ограничен одним кандидатом.
На FanOutQA первый проход дал 0,4778 по F1 для ячеек таблицы, а целевые раунды по остатку подняли результат до 0,5524. Обычное повторное чтение и случайный выбор целей дали меньший прирост; после раунда, который почти перестал приносить новые позиции, сигнал предложения остановил цикл, хотя сделал это с задержкой на один бесполезный проход.
Порядок входов здесь влияет не только на воспроизводимость. Перестановка тех же рабочих моделей в последовательной цепочке меняла итоговую оценку на 57,5% вопросов, тогда как оператор над фиксированным набором предложений по определению не зависит от порядка.
Проверка охватила QAMPARI, ASQA и FanOutQA, а воспроизводимость основного эффекта проверяли с рабочими моделями DeepSeek-V3.2 и Qwen3-32B. На ClassEval изучали связь между методами, на ELI5 — трудность объединения перефразированных утверждений, а на SWE-bench — случаи, где задача фактически не делится на независимые части. Поэтому работа подтверждает подход для структурированных ответов, но не универсальную замену любого LLM-оркестратора.
Когда UnitBoost меняет архитектурный план
Подход стоит учитывать, если продукт уже запускает несколько моделей или агентов и получает результат с механически определяемыми позициями: строки таблицы, поля карточки, найденные сущности, независимые проверки или методы класса. Тогда генеративную модель можно оставить поставщиком вариантов, а принятие, происхождение, повторные вызовы и остановку перенести в обычный код.
Практическая миграция начинается не с замены модели, а со схемы единиц. Команде нужно определить, как распознавать одинаковые позиции, чем оценивать предложенные значения, какие комбинации запрещены и какой сигнал означает, что дальнейшие вызовы перестали расширять результат. Сравнивать варианты следует при неизменных рабочих моделях, подсказках, источниках и числе вызовов — именно так работа изолирует вклад менеджера.
План не меняется для неделимого ответа или задачи, где одинаковый смысл нельзя надёжно распознать без ещё одной LLM. На ELI5 близкие по смыслу утверждения плохо объединялись механически, а идеальное знание их тождества заметно меняло результат. В тесно связанном коде выигрыш уменьшает ремонт несовместимых частей.
Метрика продукта тоже задаёт границу. Если она штрафует каждую лишнюю единицу через точность, объединение может уступить выбору одного цельного кандидата: в таком режиме UnitBoost отстал от идеального селектора на 0,065 балла. Оператор также не сокращает стоимость рабочих вызовов сам по себе, а проверка каждого значения добавляет вычисления; его выигрыш состоит в контроле и лучшем использовании уже полученных вариантов.
Главный архитектурный вывод — не удалять LLM из всей системы, а сузить область её полномочий. Там, где состояние можно представить таблицей проверяемых единиц, модель генерирует содержание, а код решает, что принять, что запросить повторно и когда остановиться.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
