Модель на 270M для многошаговых вопросов: проигрыш в точности и локальные выигрыши

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

Задача звучит скромно. Приходит многошаговый вопрос, и модель должна назвать первый поиск для системы извлечения. Из 95 вопросов, отложенных для теста, крошечная Gemma-3-270M справилась 81 раз — это 85,3%. Обе более крупные соперницы набрали больше. И всё же она помещается на ноутбуке, ничего не стоит за вызов и работает без подключения. В ходе работы нашлось и кое-что ещё: фиксированный системный промпт помогает модели такого размера гораздо сильнее, чем ожидалось, и этот выигрыш можно выразить в цифрах.

Постановка

Многошаговым вопросам нужно больше одного факта. Возьмём «Were Scott Derrickson and Ed Wood of the same nationality?» («Одной ли национальности Скотт Дерриксон и Эд Вуд?»). Чтобы ответить, нужно найти национальность одного человека, затем другого, а потом сравнить. HotpotQA — использованный здесь датасет — состоит из таких вопросов, и каждому нужно минимум два факта, обычно из двух разных статей Википедии.

Целью был только первый шаг, Hop-1: первый поиск, который система должна выполнить, прежде чем искать что-то ещё. Для заданного вопроса модель пишет короткий YAML-объект из трёх частей. thought объясняет, что искать первым, action всегда равно фиксированному значению Lookup, а target_entity называет точно то, что нужно искать. Правильный вывод для вопроса про Дерриксона выглядит так:

thought: "I need to find the nationality of Scott Derrickson first to eventually compare it to Ed Wood."
action: "Lookup"
target_entity: "Scott Derrickson"

Модель не извлекает документы, не делает второй шаг и не даёт итогового ответа. Она только решает, что искать первым.

Для вопросов-сравнений модель могла бы выдать обе сущности и сравнение одним выводом. Дизайн намеренно этого избегает. Каждый шаг получает одно атомарное действие, поэтому вопрос-сравнение превращается в три отдельных шага. Найти первую сущность, найти вторую, и только потом сравнить результаты. Когда что-то идёт не так, сломавшийся шаг легко найти. Это стоит точности, потому что ошибки накапливаются по длинной цепочке. При 90% на шаг цепочка из трёх шагов даёт около 73% от начала до конца. Компромисс приемлем: система, которая падает и говорит, где именно, ценнее той, что падает молча.

Для обучения нужны были размеченные примеры правильных разбиений Hop-1, и учителем стал GPT-4o. Его промпт содержал пять разобранных примеров и строгие правила: цель должна браться прямо из формулировки вопроса и никогда не быть именем, которое модель вывела сама, а всё неизвестное идёт в thought, а не в target_entity. Этот промпт прогнали по вопросам HotpotQA, а второй вызов GPT-4o оценил каждый вывод по эталонным названиям статей из самого HotpotQA. Проверку прошли 474 метки.

Правила учителя важнее, чем кажутся. Требование повторять слова самого вопроса избавляет маленькую модель от необходимости разрешать имена по памяти — а именно там модель на 270M начала бы галлюцинировать. Неопределённость в thought держит target_entity достаточно чистым, чтобы сразу подставлять его в поисковый вызов.

Метки разделили 80/20: 379 на обучение и 95 отложенных для всех оценок ниже. Затем Gemma-3-270M дообучили на 379 примерах методом supervised fine-tuning — то есть напрямую на парах «вопрос — ответ», без какого-либо сигнала награды.

Как считается результат

Все цифры ниже получены на тех же 95 отложенных вопросах по двум отдельным метрикам.

• Правильность цели. Выбрала ли модель то, что нужно искать? Попадание — это когда target_entity совпадает с одним из эталонных названий HotpotQA для этого вопроса (без учёта регистра) или когда судья GPT-4o решает, что обе строки ведут к одному и тому же поиску. Это главная метрика.

Девяносто пять вопросов означают, что каждый сдвигает результат примерно на 1,05 пункта. Поэтому рядом с процентами указаны сырые количества. У судьи тоже есть свой разброс: когда он переоценил 75 уже принятых строк при temperature 0, два вердикта поменялись. Поэтому разница меньше примерно 3 пунктов считается шумом.

Одна строка промпта, которая сыграла роль

Сначала был побочный эксперимент. Две копии модели обучили на одинаковых данных (те же 379 примеров, разбиение и гиперпараметры), и отличались они одним абзацем. Копия A видела перед каждым примером фиксированное системное сообщение, которое простыми словами описывало задачу и формат YAML. Копия B видела только вопрос и ответ.

Изначально ставка была против системного сообщения. При assistant_only_loss=True loss считается только по токенам собственного ответа модели — именно этот сигнал двигает обучение. Системное сообщение и вопрос своего loss не получают, так что казалось, что научить они ничему не могут.

Ставка проиграла. Копия A оказалась впереди по обеим метрикам, на пять вопросов в каждой.

Результат оправдал сохранение сообщения, но переоценивать его не стоит. Прирост в 5,3 пункта (правильность цели) и 5,2 пункта (точное совпадение) превышает 3-пунктовый разброс судьи. Однако другой шум остаётся: всего 95 тестовых вопросов и по одному прогону обучения на копию. Когда позже конфигурацию с системным сообщением обучили с нуля заново для другого бенчмарка, получилось 81/95, а в первый раз было 83/95. Колебание в два пункта просто от нового прогона значит, что истинный размер выигрыша между прогонами неизвестен.

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

Практический вывод: текст инструкции — часть входа модели и при инференсе, поэтому то же короткое сообщение должно присутствовать при использовании модели. Если убрать его при развёртывании, модель окажется в ситуации, которой не видела на обучении.

Бенчмарк против моделей покрупнее

После обучения модель сравнили с тремя ориентирами на тех же 95 вопросах: её собственной нетронутой базовой моделью, Llama-3.1-8B-Instruct через Groq и учителем GPT-4o, чьи выводы стали метками.

Первые два столбца рядом показывают, что даёт дообучение при фиксированном промпте. Сравнение дообученной модели с двумя другими показывает, как маленький специалист выглядит на фоне больших моделей, каждая из которых получила полный промпт. Эти два промпта действительно разные вещи. Короткий — это системное сообщение, на котором маленькая модель обучалась и тестировалась: задача и три имени полей, больше ничего. Длинный промпт на пять примеров — тот, которым получали обучающие метки. В нём пять разобранных примеров плюс правила форматирования, которых нет в коротком, вроде буквальной строки "Lookup" и требования, чтобы вывод был плоским отображением, а не списком. Большим моделям длинный промпт дали намеренно. Цель была увидеть их результат с нормальными инструкциями, а не проверить, угадают ли они неназванный формат. С коротким промптом обе оказались около нуля, и причина была не в слабом рассуждении, а в отсутствии правил формата. Длинный промпт исправил это для обеих.

По точности маленькая модель отстаёт от Llama-3.1-8B и ещё сильнее — от GPT-4o. По скорости она тоже уступает GPT-4o, даже без сетевого круга. Причина в том, что GPT-4o работает на стеке, настроенном на быстрый трафик в больших масштабах, а маленькая модель обрабатывает вызовы один за другим на общей GPU в Colab, где батчинг и кеширование весов никто не контролирует.

У Llama-3.1-8B примерно в 30 раз больше параметров. OpenAI не раскрывает размер GPT-4o, поэтому соотношения нет, но маленькой её никто не назовёт. Ни одну из больших моделей здесь не обыграли. Зато бенчмарк отвечает на другой вопрос: справится ли модель такого размера с этой узкой задачей? Справится — 81 из 95. Но если единственный критерий — таблица точности, маленькая модель не выигрывает.

Чего бенчмарк не уловил

Настоящий довод в пользу этой модели не из той таблицы. Он из трёх вещей, которые таблица не измеряла.

Стоимость. Измерена, а не прикинута. Количество токенов взято из реальных промптов и ответов в прогонах GPT-4o, посчитано через tiktoken (токенизатор моделей OpenAI) и оценено по опубликованным тарифам OpenAI. Типичный вызов GPT-4o потреблял 606,6 токена промпта и 39,4 токена ответа — около $0,0019 за вызов, или почти $1,91 за каждую 1000 вызовов. У дообученной модели нет платы за вызов. Железо и электричество всё равно чего-то стоят, так что «бесплатно» не совсем верно, но нет ни счёта за запрос, ни лимита запросов.

Приватность. Две функции локального инференса не делают никаких сетевых запросов. Вопрос идёт в токенизатор, затем в модель и остаётся на устройстве. Это свойство кода, а не число из бенчмарка, так что для проверки достаточно его прочитать. Одна оговорка касается хостинг-демо: оно работает на серверах Hugging Face, поэтому введённый там текст покидает машину посетителя. Утверждение о приватности относится только к самостоятельному запуску.

Работа офлайн. Проверено дважды, а не предположено. Сначала были выставлены HF_HUB_OFFLINE=1 и TRANSFORMERS_OFFLINE=1. Эти флаги заставляют библиотеки Hugging Face выдавать ошибку при любой попытке выйти в сеть, вместо того чтобы молча брать кеш. Затем Wi-Fi полностью отключили и запустили собственный код демо для загрузки и генерации, не снимая оба флага. Совершенно новый вопрос, которого не было ни в обучающих, ни в тестовых данных, всё равно получил правильное разбиение без подключения.

Ни одна таблица точности не показывает эти три свойства. Они и есть настоящие причины запускать маленькую модель локально, а не обращаться к гигантской по сети, и довод звучит честнее, когда рядом показаны нелестные цифры точности.

Что доступно

Модель, датасет и рабочее демо выложены на Hugging Face:

• дообученная модель
• датасет разбиений
• живое демо в Space

Демо использует общий бесплатный пул GPU, поэтому первый запрос после простоя медленный, пока грузятся веса. В нём есть два встроенных вопроса — типа «мост» и типа «сравнение», — так что посетители видят обе формы разбиения, ничего не вводя.

Проверки шли и дальше этих двух примеров. Действительно новый вопрос, которого нет ни в обучающих, ни в тестовых данных («The author of The Hobbit was born in which country?» — «В какой стране родился автор „Хоббита“?»), получил чистое правильное разбиение. Не каждая попытка была безупречной: на вопрос о том, где находится штаб-квартира SpaceX, модель выдала правильную целевую сущность, но бессмысленную строку thought. Сейчас выбор поиска стабильнее, чем прилагаемое к нему объяснение, особенно когда формулировки уходят от типичных для HotpotQA.

Что в итоге

Возьмите один чётко определённый шаг большой цепочки рассуждений. Модель на 270 миллионов параметров правильно справляется с ним в 81 случае из 95, уступает куда более крупным моделям в точности и при этом работает на ноутбуке без счёта и без сети. Для сценариев, где вопросы не могут покидать устройство и где неверный первый поиск можно поймать или повторить дальше в пайплайне, Hop-1 стоит попробовать. Но это не доказывает, что такая маленькая модель способна сама вести всю цепочку рассуждений без проверяющего за спиной.