Почему промпты для VLM работают наоборот: как это исправить

Недавно я пытался выжать максимум из корпоративной OCR-модели, перебирая промпты и гиперпараметры, когда наткнулся на issue в репозитории Qwen-3-VL. Автор утверждал, что точность задачи выросла просто от изменения порядка: сначала изображение, потом текст. Просто перестановка блоков.

Звучало странно. Трансформеры используют позиционное кодирование, но модель видит те же пиксели и те же слова. Порядок не должен так сильно влиять. Я проверил, оказалось, автор был прав.

| Если вам интересна тема AI‑агентов и внедрения нейросетей, заглядывайте в мой Telegram‑канал ДругОпенсурса. Там я публикую свежие новости и разборы инструментов в числе первых. |

Результаты в двух словах

Простая перестановка входных данных изображение перед текстом вместо текста перед изображением — даёт прирост точности 13–18%. Без изменений в модели, без дополнительных вычислений. Только другой порядок.

Вот что получилось на 89 образцах OCR:

• Qwen3-VL-2B-instruct: 0.378 → 0.429 ANLS (+13.4%)

• Gemma-3-4B-instruct: 0.151 → 0.179 ANLS (+18.5%)

Оба результата статистически значимы p < 0.01. Одна и та же модель и данные, разный порядок и внезапно теряешь двузначный прирост, если следуешь «стандартному» подходу.

Что меняется

Когда вызываешь vision-language модель через OpenAI-совместимый API, отправляешь массив messages. В каждом сообщении можно передать и текст, и изображения, но порядок этих блоков выбираешь сам.

Это те же данные. Модель получает те же пиксели и те же слова. Меняется только последовательность: какие токены попадают в трансформер первыми.

Я думал, что разница будет минимальной, однако нет.

Эксперимент: OCRBench v2

Нужен был датасет, который действительно проверяет модель на прочность, а не просто подтверждает, что она умеет читать чистый текст. Для этого подошёл OCRBench v2 — набор тестов от идеальных документов до кошмаров вроде ASCII-арта, капч и неразборчивого почерка.

Вот с чем приходится работать моделям:

Если модель будет ошибаться или ломаться, то именно на таких образцах. Это идеальный полигон для проверки, влияет ли порядок входных данных на результат.

Я ограничился 100 образцами (89 после фильтрации неудачных запусков). Использовал взвешенную выборку, чтобы подмножество отражало сложность всего бенчмарка. Цель была не гонка за лидербордом, а проверка, влияет ли структура промпта на результат.

Тестировал две небольшие модели, которые удобно запускать в продакшене:

• Qwen3-VL-2B-Instruct (от Alibaba)

• Gemma-3-4B-Instruct (от Google)

Почему именно они? Во-первых, достаточно малы, чтобы запускать локально на M3 MacBook Pro 32GB RAM через llama.cpp без облака и GPU. Во-вторых, из разных семейств. Если эффект проявляется в обеих, значит, дело не в архитектуре. Все запуски шли в квантизации Q8_0 с форматированием ChatML. Никакого ручного ресайза или нормализации. Просто отправлял картинки в llama-server и полагался на его дефолтную обработку. Так проверял, что получит обычный разработчик.

Для генерации использовал рекомендованные Qwen параметры декодирования с одним изменением: temperature = 0.0, чтобы исключить случайность выборки. Когда проверяешь влияние порядка, не хочется, чтобы шум от сэмплинга мешал.

temperature: float = 0.0,top_p: float = 0.8,top_k: int = 20,repetition_penalty: float = 1.0,presence_penalty: float = 1.5

(При temperature = 0.0 параметры top_p и top_k не влияют, но оставил их для единообразия запусков.)

Как измеряем улучшение: ANLS и точность

Основная метрика — ANLS. Стандарт для OCR-бенчмарков. Отвечает на вопрос: насколько близко предсказание модели к правильному ответу?

Формула:

ANLS(p,a) = 1 − (edit_distance(p,a) / max(|p|,|a|))

То есть, если предсказание совпадает с эталоном ANLS = 1.0, если стремится к 0, если почти правильно, например, «Итого: 1234» вместо «Итого: 1235», даёт частичный балл за количество правок.

Важные детали реализации:

• Сравнение без учёта регистра

• Если у вопроса несколько правильных ответов, берём максимальный ANLS

• Для разных типов задач разная обработка: multiple-choice вытаскивает букву, счётные задачи — число, математические выражения сначала проверяются на точное совпадение, потом на ANLS

Также считаю простую точность: если ANLS ≥ 0.5, засчитываю как правильный ответ. Порог условный, но даёт быстрое представление: «в целом справилась или нет», поэтому ANLS и точность могут расходиться. ANLS учитывает близкие ответы, а точность по порогу может меняться от небольших колебаний вокруг 0.5.

Как проходил эксперимент

Для каждого из 89 образцов создавал два идентичных входа с одной разницей: порядок.

• Prompt-First: сначала текст, потом изображение

• Image-First: сначала изображение, потом текст

Каждую версию прогонял через обе модели с одинаковыми параметрами декодирования. Сохранял предсказания и метаданные в JSON, затем считал ANLS и точность.

Простой A/B-тест: меняем порядок, всё остальное фиксируем, сравниваем результаты.

Всего должно было быть 400 запусков — 100 образцов × 2 модели × 2 порядка. На практике 11 образцов упали хотя бы раз. Для чистоты сравнения взял 89 образцов, которые успешно прошли во всех четырёх вариантах. Каждая модель видела одни и те же данные, только в разном порядке. Если порядок не важен, результаты должны быть похожи, если важен — данные это покажут.

Результаты: Image-First выигрывает с большим отрывом

Если бы порядок не влиял, точки расположились бы симметрично вокруг диагонали, а разница была бы около нуля. Этого не произошло.

В обеих моделях Image-First выигрывает чаще, и разница в пользу этого порядка.

Qwen3-VL-2B-Instruct (n = 89)

• Image-First выигрывает: 46/89 (51.7%)

• Prompt-First выигрывает: 12/89 (13.5%)

• Ничья: 31/89 (34.8%)

• Средняя разница ANLS: +0.051

• p-value: 0.0019

Gemma-3-4B-Instruct (n = 89)

• Image-First выигрывает: 53/89 (59.6%)

• Prompt-First выигрывает: 27/89 (30.3%)

• Ничья: 9/89 (10.1%)

• Средняя разница ANLS: +0.028

• p-value: 0.0148

p-value показывает вероятность получить такие результаты случайно, если бы порядок не влиял. Для Qwen p = 0.0019 крайне маловероятно. Для Gemma p = 0.0148 тоже ниже стандартного порога 0.05.

Вывод: порядок входных данных влияет на результат, и Image-First чаще даёт лучшие показатели.

Не все задачи одинаково чувствительны к порядку

Эффект проявляется неравномерно. В некоторых задачах Image-First даёт сильный прирост, в других почти не влияет.

Разбил по типам задач с помощью простого показателя чувствительности: (ANLS Image-First − ANLS Prompt-First). Положительное значение — Image-First лучше, отрицательное — Prompt-First.

Самые большие приросты там, где модель должна понимать структуру и пространственные отношения:

• Diagram QA: +0.254 ANLS (самый сильный эффект)

• Formula recognition: +0.103

• ASCII art classification: +0.095

• Table parsing: +0.069

• Chart parsing: +0.065

Это логично. В Diagram QA часто нужно сопоставить текст и символы на сложной схеме. Если модель «смотрит» первой, ей проще зафиксировать визуальный контекст перед ответом. Формулы и ASCII-арт — задачи, где важны мелкие детали формы и расположения. Для стандартных OCR-задач : распознавание текста, извлечение ключевой информации, парсинг документов эффект тоже есть, но меньше: +0.039–0.041 ANLS. Небольшой, но стабильный прирост.

Есть и исключение: Full-page OCR стал хуже с Image-First −0.052 ANLS. Возможно, длинные тексты работают, как режим чтения, где инструкция в начале помогает модели настроиться перед обработкой плотной страницы, но это гипотеза такова, что в этой категории мало образцов, так что выводы предварительные.

Практический вывод: если работаешь с формами, счетами, таблицами, графиками или схемами — Image-First безопаснее. Для полностраничного распознавания стоит протестировать оба варианта.

Короткие промпты усиливают эффект

Чем короче промпт, тем сильнее влияет порядок.

Разбил образцы по длине промпта:

• Очень короткие (<50 символов): +0.034 ANLS

• Короткие (50–100 символов): +0.068 ANLS — пик чувствительности

• Средние (100–200 символов): +0.026

• Длинные (200–500 символов): +0.024

• Очень длинные (>500 символов): +0.044

Объяснение: длинные промпты дают модели больше контекста, чтобы исправиться, даже если порядок неоптимален. С коротким промптом вроде «Извлеки итог» или «Что это?» мало информации. Если промпт идёт первым, модели приходится удерживать инструкцию через большой блок токенов изображения, и она может потеряться. Если изображение идёт первым, модель сначала формирует визуальное представление, а потом сразу применяет к нему простой запрос.

Проблема в том, что короткие промпты — это как раз то, что обычно используют в продакшене. Именно они больше всего зависят от порядка. Длинные, тщательно составленные промпты тоже выигрывают от Image-First, но эффект слабее, потому что у модели больше возможностей перестроиться по ходу.

Когда порядок решает всё

В большинстве случаев порядок промпта даёт небольшой прирост или ухудшение на пару процентов. Но иногда это разница между модель не справляется и модель решает задачу.

Разбил 89 парных запусков на категории:

• 66 образцов (74%): проваливаются в обоих порядках. Обычно это просто слишком сложные задачи для моделей такого размера.

• 11 образцов (12%): проваливаются в обоих, но с разными ошибками. Нестабильность — тот же вход, разные сбои.

• 7 образцов (8%): справляются в обоих порядках. Лёгкие случаи, где порядок не важен.

• 5 образцов (6%): один порядок справляется, другой — нет. Вот эти случаи и важны.

Модель явно способна решить задачу, но делает это стабильно только при правильном порядке.

Примеры:

• Образец 1062 (Key Information Extraction): Prompt-First — 0.193, Image-First — 0.636. Прирост в 3.3 раза.

• Образец 959 (Key Information Extraction): 0.115 → 0.461. Почти в 4 раза лучше.

• Образец 463 (ASCII Art Classification): 0.043 → 0.333. В 7.8 раза.

Бывают и обратные случаи. Например, Образец 5842 (Full-page OCR) выигрывает с Prompt-First: 0.827 против 0.526. Это подтверждает, что длинные тексты могут вести себя иначе.

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

Не все образцы одинаково чувствительны

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

Хорошая новость: большинство образцов устойчивы. 73 из 89 попадают в категорию высокой согласованности >0.9, где модель ведёт себя одинаково при любом порядке. Ещё 13 — средняя согласованность 0.7–0.9, где результаты немного отличаются. И только 3 образца — низкая согласованность <0.7, где порядок кардинально меняет предсказание.

Есть опасная зона: высокая средняя оценка, но низкая согласованность. Это случаи, где модель в принципе справляется, но результат зависит от порядка. В моём наборе данных только один образец попал в эту категорию, но он хорошо иллюстрирует риск. Риск в том, что модель может показывать 80% качества, но если использовать неоптимальный порядок, то получишь 50%. И сделаешь вывод, что модель недостаточно хороша. А на самом деле она способна на большее, просто не всегда получает доступ к этой способности. Виноват интерфейс, а не модель.

Поэтому важно тестировать на своих данных. Общая статистика говорит, что Image-First лучше, но на конкретных документах и промптах эффект может быть от незначительного до критического.

Почему так происходит: Гипотезы

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

Гипотеза 1: Смещение внимания по позиции, эффект первичности

Трансформеры кодируют позицию, но это не значит, что все позиции обрабатываются одинаково. Ранние токены могут получать чуть больше внимания, особенно на этапе формирования контекста. Если это так, то Image-First ставит визуальные токены в более выгодные позиции и Prompt-First заставляет изображение конкурировать с уже установленным контекстом. Это объясняет, почему короткие промпты показывают большую чувствительность. Чем меньше текстовых токенов в начале, тем раньше попадает изображение и тем меньше конкуренции. Есть похожие обсуждения эффектов, связанных с порядком, в мультимодальном промптинге, например, в статье «Order Matters».

Гипотеза 2: Соответствие обучающему распределению

Модели лучше работают с форматами, похожими на те, что видели во время обучения. Много данных для vision-language моделей — это Image-First: изображение к подписи, изображение к описанию, изображение к вопросу-ответу. Если обучение чаще использовало Image-First, то это родной порядок для модели. Prompt-First становится слегка нестандартным форматом, и производительность падает, пусть и незначительно.

Гипотеза 3: Ограничение заземления и рабочей памяти

Самое интуитивное объяснение: если модель видит изображение первой, она может сформировать визуальное представление до того, как получит запрос. С Image-First модель строит внутреннее представление из пикселей, а потом применяет инструкцию к нему. С Prompt-First модель сначала читает инструкцию, а потом должна удержать её через сотни токенов изображения и инструкция может потеряться по пути.

Это совпадает с наблюдениями: самые большие приросты были на визуально сложных задачах, где нужно глубокое понимание структуры перед ответом.

Практический вывод: код для исправления

Вот что это значит для твоих API-запросов:

#  Как обычно учат (неоптимально)messages = [    {"role": "user", "content": [        {"type": "text", "text": "Извлеки итог счета"},        {"type": "image", "image": invoice_img}    ]}]#  Что работает лучше (+13-18% точности)messages = [    {"role": "user", "content": [        {"type": "image", "image": invoice_img},        {"type": "text", "text": "Извлеки итог счета"}    ]}]

Поменяй две строки местами и протестируй на своём наборе данных. Используй выигрывающий порядок.

Не воспринимай это как универсальное правило. Общий тренд в пользу Image-First, но есть исключения, например, full-page OCR. Самый надёжный подход — A/B-тестирование на своих данных с теми же промптами, изображениями и параметрами декодирования.

Ограничения

Несколько оговорок, прежде чем переписывать весь продакшен:

1. Воспроизводимость: Первый запуск шёл с дефолтным сэмплингом temperature > 0, то есть одинаковые входы могли давать немного разные выходы. Чтобы подтвердить, что дело не в шуме, перезапустил с temperature = 0.0 — эффект сохранился. Цифры в статье отражают оригинальный запуск с сэмплингом, так как это ближе к реальному использованию. Детерминированные результаты есть в репозитории.

2. Охват: Тестировал только две open-source модели, потому что они хорошо запускаются локально и поддерживаются llama.cpp. Это всего две точки в огромном пространстве архитектур. Не проверял проприетарные модели: GPT-4V, Gemini, Claude, они могут вести себя иначе из-за других обучающих данных или архитектур.

3. Задачи: Всё основано на OCRBench v2, который заточен под документы и OCR. Не оценивал общий VQA, генерацию подписей, мультимодальное рассуждение, несколько изображений или чередующиеся текст-изображение-текст форматы. Это сильное доказательство эффекта порядка для OCR-задач, но не доказательство, что все VLM одинаково чувствительны к порядку.

4. Размер выборки: 89 образцов достаточно для статистической значимости, но мало для детального анализа по типам задач или длине промпта. Следующий шаг — репликация на 500+ образцах для конкретных задач.