Что именно изменилось: вопрос перед контекстом вместо контекста перед вопросом
Перестановка двух блоков промпта подняла точность локальной модели Qwen3.6-35B-A3B с 89% до 100% на английском, с 89% до 97% на немецком и снизила медианную задержку примерно с 400 мс до 80 мс. Модель работала в 4-битном квантовании на M2 Max, набор данных - 38 коротких ситуаций. Код и бенчмарк автор выложил на GitHub в репозитории snapjudge, а сам кейс описал в посте на r/LocalLLaMA.
Задача, на которой всё проверялось, выглядит так: на вход идёт состояние (короткое описание ситуации) и вопрос с фиксированным списком допустимых ответов. Модель не пишет текст. Она получает вероятность каждого варианта из логитов одного прямого прохода, и ответ выбирается по максимальной вероятности. Исходный порядок был «состояние, затем вопрос и варианты». Новый порядок: «вопрос и варианты, затем состояние». Больше в промпте ничего не менялось.
У результата есть жёсткие рамки. 38 коротких ситуаций с короткими состояниями - небольшая выборка, а причину прироста точности автор не установил, о чём говорит прямо. Это данные одного человека на одном наборе, а не универсальное правило промптинга. Дальше разберём, что именно измерялось, почему порядок вообще влияет на качество и где подход начинает вредить.
Цифры бенчмарка: 38 ситуаций, два языка, две метрики
Условия эксперимента: Qwen3.6-35B-A3B, 4-битное квантование, Apple M2 Max, 38 коротких ситуаций, короткие состояния, два языка. Замерялись две метрики: точность выбора ответа и медианная задержка.
| Метрика | Состояние первым (исходный порядок) | Вопрос первым |
|---|---|---|
| Точность, английский | 89% | 100% |
| Точность, немецкий | 89% | 97% |
| Медианная задержка | около 400 мс | около 80 мс |
| Длинные документы | точность ниже | точность выше, обработка в 6-8 раз медленнее |
Что видно из таблицы. На английском перестановка убрала все ошибки: 89% превратились в 100%. На немецком она исправила примерно две ошибки из 38. Скорость на коротких состояниях выросла в пять раз. На длинных документах картина другая: точность по-прежнему улучшалась, а обработка замедлялась в 6-8 раз. О числе прогонов и seed автор в описании не сообщает, поэтому стабильность результата между запусками оценить не получится.
Как читать эти проценты. 38 ситуаций - выборка, где каждый пример весит около 2,6 процентных пункта. Один исправившийся ответ уже даёт заметный скачок. Поэтому 100% на английском означают «все 38 раз модель ответила верно», а не «подход гарантирует безошибочный результат на любых данных».
Почему это не про генерацию текста, а про чтение логитов
Логиты - это сырые оценки модели по каждому токену словаря до нормализации в вероятности. На выходе прямого прохода модель выдаёт вектор чисел, и уже softmax превращает эти оценки в распределение вероятностей. Если набор допустимых ответов известен заранее, генерировать текст не нужно: достаточно посмотреть оценки на токенах, соответствующих вариантам ответа, и взять максимум. Вопросу «A», «B» или «C» в таком сценарии соответствует один прямой проход вместо последовательной генерации токенов.
Практическая разница ощутимая. Генерация тратит время на каждый сгенерированный токен, а декодирование с температурой вносит случайность. Чтение логитов по фиксированному списку ответов даёт один проход, предсказуемый результат и никакой зависимости от параметров сэмплинга. Такой подход давно применяют для классификации, определения намерения и маршрутизации запросов между инструментами, где ответ укладывается в короткий список меток.
Почему порядок промпта вообще влияет на точность
Точную причину автор не знает и не скрывает этого. Его собственная формулировка звучит так:
«Прирост точности я могу только предполагать: вероятно, модель читает состояние иначе, когда уже знает, что именно ищет».
Отсюда и осторожность в выводах. Эффект зафиксирован и воспроизводится на этом бенчмарке, но объяснения у него нет, и это важно, если вы планируете строить на нём продакшен-пайплайн.
Гипотеза автора: модель читает состояние иначе, когда знает, что ищет
Механика attention делает такую трактовку правдоподобной. Каждый токен на входе формирует представление с учётом всех предыдущих токенов. Когда вопрос и допустимые ответы идут первыми, состояние обрабатывается уже в контексте конкретного запроса: модель «знает», какие различия между вариантами важны, и выстраивает представление состояния под них. Когда состояние идёт первым, модель сначала обрабатывает данные, не зная, что именно нужно из них извлечь, и вопрос ложится поверх готового представления.
Прямого доказательства у гипотезы нет. Ни ablation, ни сравнения внутренних представлений автор не приводит, а независимых проверок на момент публикации не появилось. Человеческая аналогия помогает понять идею, но не заменяет эксперимент: если сначала прочитать вопрос теста, а потом текст, отвечать обычно проще.
Что это значит для проектирования промптов
Практический вывод простой. Если у вас фиксированный набор допустимых ответов и вы читаете вероятности из логитов, ставьте вопрос и варианты первыми, а состояние - последним. Проверьте это на своих данных: перенос результата с 38 коротких ситуаций на другой домен никем не подтверждён.
Для обычной генерации текста эффект не проверен. Нет данных, что тот же порядок даст прирост при извлечении JSON или планировании вызовов инструментов, хотя именно эти сценарии автор предлагает протестировать.
Откуда взялось ускорение: кэширование одинакового префикса
Со скоростью всё прозрачнее, чем с точностью. Блок вопроса стал одинаковым префиксом между вызовами: он вычисляется один раз и дальше переиспользуется из кэша. Это классическое кэширование префикса на уровне KV-кэша: рантайм хранит состояния attention для уже обработанных токенов и не считает их повторно, если начало промпта не изменилось. Отсюда падение медианной задержки примерно с 400 мс до 80 мс.
Почему context-first ломает кэш
При исходном порядке промпт начинается с состояния, а состояние меняется от вызова к вызову. Меняется первый токен, значит меняется весь префикс, и кэшировать нечего. Каждый вызов обрабатывает вход с нуля. Переставьте блоки, и первым пойдёт неизменный блок вопроса с вариантами ответа, а переменная часть переедет в конец. Префикс совпадёт между вызовами, кэш заработает, лишние вычисления исчезнут.
Такой выигрыш ничего не говорит об «умнее» модели или о её настройках. Он целиком про структуру промпта и про то, поддерживает ли рантайм переиспользование префикса. В окружении без кэширования префикса перестановка даст точность, но не даст скорости.
Когда кэш перестаёт помогать: длинные документы
На длинных документах логика переворачивается. Если документ идёт первым, его можно посчитать один раз и переиспользовать для десятков вопросов по нему. При question-first первым оказывается вопрос, документ переезжает в конец и меняется вместе с вопросом: кэшировать уже нечего. В бенчмарке автора это дало замедление в 6-8 раз на длинных входах, при том что точность всё равно улучшалась.
Компромисс получается прямой. Один длинный документ и много вопросов к нему - document-first выгоднее по времени. Короткие состояния и повторяющийся вопрос - question-first выигрывает по обеим метрикам.
Где подход question-first выигрывает, а где нет
Короткие состояния и фиксированные ответы: идеальный случай
Признаки задачи, под которую находка подходит без оговорок: набор допустимых ответов фиксирован, состояние короткое, сам вопрос повторяется между вызовами, ответ считывается из логитов, а не генерируется. Типичные примеры: классификация обращений по категориям, выбор инструмента для следующего шага, определение намерения пользователя, оценка короткого события по шкале. В таких сценариях выигрыш идёт по точности и по задержке одновременно.
Похожая логика встречалась в разборах того, как обвязка вокруг модели меняет её точность на десятки пунктов: одна и та же замороженная модель показывала разброс от 60% до 82% в зависимости от решений в harness. Разбор design harness на 4B-модели и задачах Kubernetes SIG triage показывает, что промпт и код вокруг модели влияют на результат не меньше, чем сама модель.
Длинные документы: точность растёт, скорость падает
Если на входе длинный документ и много вопросов к нему, question-first бьёт по скорости в 6-8 раз. Варианты действий: оставить document-first и мириться с меньшей точностью; разбить документ на короткие фрагменты, которые кэшируются; применять question-first точечно, только там, где цена ошибки выше цены времени. Универсально правильного выбора нет, решение зависит от того, какой ресурс у вас в дефиците.
Обычная генерация: что ещё не проверено
Эффект на генерации текста не измерялся. Автор прямо приглашает проверить его на извлечении JSON и маршрутизации инструментов, то есть там, где модели нужно не выбрать метку, а выдать структуру. До появления таких замеров порядок промпта в генеративных задачах остаётся открытым вопросом.
- Вопрос повторяется между вызовами, состояние короткое - пробуйте question-first.
- Один длинный документ, много вопросов - скорее document-first.
- Генерация текста, извлечение JSON, вызовы инструментов - сначала замерьте оба порядка на своём наборе.
- Рантайм не кэширует префикс - ждите прироста точности, но не скорости.
Ограничения, о которых автор говорит прямо
Оговорки у бенчмарка перечислены честно, и их лучше держать перед глазами:
- выборка небольшая: 38 коротких ситуаций;
- состояния короткие, эффект на длинных входах ведёт себя иначе;
- причина прироста точности не установлена, есть только гипотеза;
- на длинных документах обработка замедлялась в 6-8 раз;
- проверки на обычной генерации нет.
Почему 100% - это не универсальный результат
На выборке из 38 ситуаций один неверный ответ опускает точность до 97,4%. И 100%, и 89% - числа с крупной ценой одного примера. Причина прироста не доказана, перенос на другой домен не проверен, независимого воспроизведения не было. Воспринимать результат лучше как повод поставить собственный эксперимент, а не как готовую настройку, которую можно включать вслепую. Описание бенчмарка и оговорки автора опубликованы вместе с результатами.
Компромисс точность/скорость на длинных входах
Замедление в 6-8 раз на длинных документах - не баг и не случайность. Это прямое следствие того, что документ перестаёт быть общим префиксом и больше не кэшируется между разными вопросами. Если для вашего пайплайна важна пропускная способность, придётся либо оставить document-first, либо перестроить схему так, чтобы кэшируемая часть оставалась первой, а переменная - последней.
Как проверить эффект на своей модели и задаче
Мини-бенчмарк: что измерять и как не обмануться
Схема проверки повторяет авторскую и не требует больших ресурсов:
- Соберите набор коротких ситуаций и зафиксируйте для каждой полный список допустимых ответов.
- Прогоните оба порядка промпта на одних и тех же состояниях, меняя только порядок блоков.
- Считайте точность выбора ответа и медианную задержку: средняя задержка маскирует редкие длинные вызовы, медиана показывает типичный случай.
- Добавьте отдельный набор с длинными документами, чтобы увидеть цену question-first на больших входах.
- Не меняйте между прогонами другие параметры: квантование, длину контекста, настройки сэмплинга.
- Повторите прогоны несколько раз, если рантайм позволяет, чтобы отделить устойчивый эффект от разовой флуктуации.
Что смотреть в коде: логиты и кэш префикса
В репозитории snapjudge (ссылка на код и бенчмарк есть в посте автора) разберите три места. Первое: как из логитов вытаскиваются оценки допустимых ответов и как выбирается максимум. Второе: как собирается промпт, действительно ли блок вопроса и вариантов неизменен и стоит первым. Третье: включено ли кэширование префикса в вашем рантайме. Без работающего кэша вы получите только прирост точности, а задержка останется прежней.
Что это меняет для практики локальных LLM
Порядок промпта - рычаг, который чаще всего не трогают: вопрос и данные ставят так, как удобно читать человеку, и на этом останавливаются. Кейс с Qwen3.6-35B-A3B показывает, что на типизированных решениях перестановка двух блоков может изменить и точность, и задержку, причём задержку - в разы, а не в проценты.
Обобщать это на все задачи нельзя. Выборка из 38 коротких ситуаций, неустановленная причина прироста точности и замедление в 6-8 раз на длинных документах оставляют много места для исключений. Возьмите свой набор коротких ситуаций с фиксированными ответами, прогоните оба порядка промпта, сравните точность и медианную задержку и только после этого решайте, какой вариант оставить в пайплайне.