Модель на 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 варто спробувати. Але це не доводить, що така маленька модель здатна сама вести весь ланцюжок міркувань без перевіряльника за спиною.