VeriLoop E2 - это 27B-модель, дообученная на базе Qwen3.8-27B и выпущенная с весами под лицензией Apache-2.0. Авторы решают конкретный вопрос: получает ли LLM право самой фиксировать новое состояние агента после того, как состояние уже прошло проверку. Вердикт модели: нет. Она предлагает, фиксирует внешний верификатор.
Правило называется VeriLoop-Governed Recurrence (VGR). Кандидат r'_t коммитится только при двух условиях одновременно: ни одна защищённая координата не ухудшилась и хотя бы одна улучшилась. Скалярная оценка «вроде бы стало лучше» такой власти не имеет.
Практический смысл для тех, кто гоняет агентов локально: VGR задаёт формальный каркас, в котором модель может искать улучшения, но не может молча сломать уже работающее. Веса, токенизатор, конфиг, утилиты инференса для vLLM и официальные GGUF-кванты открыты. Продакшн-харнесс верификатора - нет, и это главное ограничение для воспроизведения результатов.
Что такое VeriLoop E2 и зачем нужен VGR
VeriLoop E2 - 27B-модель, дообученная от Qwen3.8-27B, с весами под Apache-2.0. Об этом написал один из авторов в релизном посте на r/LocalLLaMA: We released VeriLoop E2 (27B, Apache-2.0). Помимо весов открыты токенизатор, конфиг, утилиты инференса для vLLM и официальные GGUF-кванты.
В текущей системе E2 работает как модельный reasoner/proposer: генерирует предложения, строит абстракции, ставит диагноз, выбирает маршрут, перепланирует. Исполнение, защищённое сравнение, откат и сертификацию забирает внешний Harness вместе с верификатором. Верификатор при этом остаётся вне градиентного пути.
Ключевое правило VGR: предложение vs фиксация
Разделение полномочий выглядит так: модель получает proposal authority, верификатор и контроллер - persistence authority. Модель предлагает новое состояние. Подписать переход своим же выходом она не может.
Отклонённый кандидат не становится новым incumbent state и не может частично протечь в сохранённое состояние: retained bundle остаётся неизменным. В схеме со скалярной наградой промежуточное ухудшение обычно проходит незамеченным, потому что итоговое число всё равно выросло.
Обучение меняет то, какие предложения модель склонна делать. Право самостоятельно авторизовывать переходы состояния оно не даёт. Градиент не идёт через верификатор, поэтому подстроиться под проверку и обойти её модель не сможет.
Защищённые координаты и частичный порядок
Состояние описывается вектором ранга r_t. Защищённые координаты - позиции этого вектора, которые нельзя ухудшать; значение 0 означает, что координата выполнена. Правило коммита формулируется так:
commit r'_t only if for every j: r'_t[j] <= r_t[j]
and for at least one j: r'_t[j] < r_t[j]
Это свойство protected non-regression: закоммиченное состояние не может ухудшить ни одну защищённую координату. Сравнение получается частичным порядком. Два кандидата могут оказаться несравнимыми, и тогда ни один из них не заменяет incumbent.
Пример на векторе из трёх координат: incumbent r_t = (0, 1, 1), то есть одна координата выполнена, две нет, суммарное число невыполненных обязательств равно 2. Дальше три кандидата с разной судьбой.
| Кандидат | Вектор | Решение | Почему |
|---|---|---|---|
| incumbent r_t | (0, 1, 1) | - | текущее проверенное состояние |
| A | (0, 0, 1) | коммит | все координаты не хуже, одна строго лучше |
| B | (1, 0, 0) | отказ | сумма ошибок падает с 2 до 1, но нарушена уже выполненная первая координата |
| C | (0, 1, 1) | отказ | нет строгого улучшения ни по одной координате |
Кандидат B - самый показательный случай. Он уменьшает число ошибок с 2 до 1, то есть по скалярной метрике выглядит выгоднее incumbent. Коммита не будет: первая координата уже была выполнена, а кандидат её нарушает. Так VGR запрещает обменивать выполненное обязательство на общий выигрыш в сумме.
Как VGR даёт более богатый сигнал для дообучения
Каждый кандидат проходит внешнюю проверку, и её результат раскладывается на пять категорий:
- strict progress - все защищённые координаты не хуже, хотя бы одна строго лучше;
- no progress - кандидат не отличается от incumbent по рангу;
- protected regression - хотя бы одна защищённая координата ухудшилась;
- incomparable - часть координат лучше, часть хуже, строгого порядка нет;
- zero-rank completion - все координаты равны нулю, задача закрыта.
Этот набор и есть обучающий сигнал. Строгий прогресс годится как correction supervision: по нему видно, какие предложения вели к правильному переходу. Артефакт с нулевым рангом становится целью финальной генерации. Регрессирующий или несравнимый кандидат работает негативным примером. Скалярная награда сжала бы всё это в одно число и потеряла разницу между «стало хуже в сумме, но лучше по приоритету» и «стало лучше в сумме, но сломан один инвариант».
Верификатор остаётся вне градиентного пути, поэтому сигнал приходит из внешней проверки, а не из самооценки модели. Это trajectory-supervised вариант VGR. Классический RLHF со скалярной наградой устроен иначе: модель оптимизирует число, а не структуру переходов, и промежуточные нарушения инвариантов внутри эпизода там не отделяются автоматически. Если сравнивать с пост-трейнингом обычных open-weights моделей, где качество подтверждается в первую очередь заявлениями авторов, механика VGR проверяема по построению: каждый переход состояния либо прошёл правило коммита, либо нет. Как оценивать громкие заявления о пост-трейнинге, мы разбирали в материале про GLM-5.3.
Что открыто и что можно запустить локально
Публичный набор артефактов:
- веса модели под Apache-2.0;
- токенизатор;
- конфиг;
- утилиты инференса для vLLM;
- официальные GGUF-кванты.
Apache-2.0 разрешает коммерческое использование и дообучение, требуя сохранять уведомления об авторстве и текст лицензии. Для команд, которые не могут брать модели с исследовательскими лицензиями, это заметный плюс.
Закрытой остаётся одна существенная часть: продакшн-харнесс, в котором модель оценивается. Авторы прямо указывают, что он не open source. Значит, воспроизвести бенчмарки модели в одиночку может не получиться, даже имея веса на руках.
Запуск через vLLM и GGUF
Для vLLM подойдёт стандартный пайплайн: скачиваете веса, поднимаете сервер, обращаетесь к нему через OpenAI-совместимый API. Для GGUF есть llama.cpp-совместимые раннеры, включая официальные кванты. Квантованные веса снижают требования к VRAM, а конкретный объём памяти зависит от выбранного кванта, длины контекста и размера батча.
Ключевое ограничение: без внешнего верификатора модель не работает в режиме VGR. Она просто генерирует предложения. Правило коммита живёт в харнессе, а не в весах, поэтому загруженный в vLLM чекпойнт сам по себе не будет защищать координаты. Проверить это просто: дайте модели задачу, где кандидат нарушает уже выполненное условие, и посмотрите на выход. Без контроллера ничто не помешает принять такое предложение.
Ограничения и границы заявлений авторов
Авторы сами очерчивают, что именно подтверждено. Формулировка из релиза: текущие свидетельства E2 поддерживают работу VGR в режиме trajectory supervision, но не полное встраивание латентного оператора внутрь бэкбона Qwen. Разница принципиальная. В первом случае правило живёт во внешнем харнессе и в траекториях обучения, во втором - оператор встроен в саму модель.
Для латентного варианта нужны отдельные доказательства: контролируемое расположение активаций, согласованность декодера и кэша, градиентный путь, трассировки инференса. Пока таких данных нет.
Второе ограничение - закрытый харнесс. Третье - природа источника: пост на r/LocalLLaMA вышел из-под пера одного из авторов. Это релизное объявление, не независимая оценка и не отчёт с бенчмарками. Числа и сравнения оттуда стоит читать как заявления команды, а не как подтверждённый сторонний результат.
Кому и зачем это нужно: практические сценарии
VGR имеет смысл там, где ограничения формулируются проверяемо и обменивать их нельзя. Типичные примеры:
- агент правит конфигурацию инфраструктуры, и набор уже работающих сервисов обязан остаться в строю;
- агент оптимизирует код, и все тесты, которые проходили до правки, обязаны проходить после;
- агент планирует маршрут или расписание с жёсткими сроками и лимитами по ресурсам;
- RAG-пайплайн ищет ответ, а покрытие уже найденных обязательных сущностей падать не должно.
Схема работы одинаковая. Вы задаёте вектор защищённых координат, пишете функцию проверки, верификатор сравнивает кандидата с incumbent по правилу VGR и либо коммитит переход, либо откатывает его. Модель получает обратную связь в виде категории кандидата, а не одного числа.
Отдельная выгода в отладке. Когда переход отклонён, у вас есть точная причина: ухудшилась конкретная координата, не было строгого улучшения или кандидаты несравнимы. Логи категорий дают материал и для дообучения, и для разбора инцидентов.
Формализация выхода здесь критична. Если модель возвращает свободный текст, верификатору нечего сравнивать. Пример того, как модель отдаёт машинно-проверяемый сигнал вместо текста, разобран в статье про Jev от TypeSafe AI с примитивами Choice, Noulli и Score: та же логика применима к предложениям состояния, которые дальше проверяет контроллер.
Итог: стоит ли пробовать VeriLoop E2
VeriLoop E2 - аккуратный эксперимент по разделению полномочий: модель предлагает, верификатор фиксирует, коммит возможен только при неухудшении всех защищённых координат и строгом улучшении хотя бы одной. Открытые веса под Apache-2.0, токенизатор, конфиг, утилиты для vLLM и GGUF-кванты позволяют запустить модель локально и посмотреть на её предложения.
Дальше начинается работа, которую придётся делать самому. Харнесс закрыт, бенчмарки воспроизвести в одиночку может не получиться, поэтому рассчитывайте на свой верификатор, свои защищённые координаты и свои тесты. Для команды с задачей, где есть проверяемые инварианты, это несколько дней на прототип и понятный критерий успеха. Тем, кому нужна система из коробки, готового решения сейчас предложить нечего.
Практический шаг: возьмите одну реальную операцию вашего агента, опишите её состояние как вектор координат, отметьте те, которые нельзя ухудшать, и реализуйте правило коммита из этой статьи. Если модель начнёт предлагать переходы, которые проходят проверку чаще отклонённых, VGR в вашем сценарии работает. Сама следовать VGR модель не станет: правило живёт вне весов.