TL;DR
Исследование показывает, как правильно резать большое изображение на фрагменты, чтобы модель с «глазами» (VLM, vision-language model) находила мелкие объекты и не теряла ничего по пути. Правило простое. Каждый фрагмент показывай не мельче, чем объект виден на целой картинке. Соседние фрагменты перекрывай хотя бы на размер одного объекта. Тогда нарезка в среднем не ухудшает результат, а чаще заметно улучшает.
Главная боль: вы отправляете чертёж, скриншот или фото полки целиком, а модель находит то 15 объектов из 23, то 9. Причина в устройстве входа. Модель сжимает картинку до фиксированного бюджета «визуальных токенов» (кусочков-плиток). Объект на большом листе получает меньше одной плитки на сторону и превращается в пятно. Удвоение бюджета почти не спасает, а на самом деле растёт только корень из него. Если запихнуть в один вызов ещё и много объектов сразу, точность падает и от количества. Хуже того, у некоторых моделей «режим высокого разрешения» сработал хуже обычного.
Метод в три хода. Сначала режь картинку на фрагменты с перекрытием. Потом смотри каждый фрагмент отдельным запросом. В конце собери ответы и убери дубли на стыках. «Безопасно» здесь значит: нет фрагмента, который показывает объект мельче, чем целая картинка, и нет объекта, который не лежит целиком хотя бы в одном фрагменте.
Схема метода
ШАГ 1: Оцени размер объекта (в пикселях) и лимит модели на картинку
ШАГ 2: Выбери размер фрагмента ≈ лимит модели БЕЗ ужатия (чтобы модель не уменьшала его сама)
ШАГ 3: Режь с шагом = размер фрагмента − размер объекта (перекрытие ≥ 1 объект)
ШАГ 4: Каждый фрагмент → отдельный запрос → список объектов с координатами во фрагменте
ШАГ 5: Переведи координаты в общие, убери дубли на стыках → итоговый список
Шаги 1–3 — подготовка (вручную или скриптом). Шаг 4 — отдельные запросы. Шаг 5 — один запрос или таблица.
Пример применения
Задача: Сметчик строительной компании получил чертёж электрики на этаж ЖК. Лист примерно 11000×7700 пикселей. Нужно пересчитать розетки и выключатели по легенде для сметы в рублях. Если отправить лист целиком, значок становится точкой, и считают модели с ошибкой.
Промпт (на каждый фрагмент; фрагмент вырезан с перекрытием в один значок):
Это фрагмент {N} из {всего} большого чертежа электрики. Фрагмент вырезан из листа без уменьшения масштаба.
Перекрытие с соседними фрагментами — около 60 пикселей.
Эталон символа «двойная розетка» — на приложенной картинке-легенде.
Задача: найди ВСЕ двойные розетки в этом фрагменте.
Для каждой выдай центр символа в пикселях фрагмента (x, y).
Если символ обрезан краем фрагмента — всё равно перечисли его и пометь «на границе».
Ничего не выдумывай: если не уверен — пометь «сомнение».
Формат: таблица | № | x | y | статус (чётко / на границе / сомнение) |
В конце: общее число найденных во фрагменте.
Результат: по каждому фрагменту придёт таблица с координатами и статусами и итоговое число. Фрагментов будет около двух десятков, и в каждом найдётся несколько значков. На последнем шаге вы (или отдельный запрос) переведёте координаты в общие и удалите дубли на стыках: точки ближе размера значка считаются одним объектом. Сумма даст цифру для сметы. Список «на границе» и «сомнение» вы проверите глазами.
Почему это работает
Слабость: у модели бюджет на изображение: она режет картинку на плитки, и всего их ограниченное число. Большой лист сжимается, и объект получает долю плитки. Удвоение бюджета поднимает «видимость» только на 41%. Кроме того, чем больше содержимого в вызове, тем хуже модель перечисляет всё подряд. Поэтому у большой картинки две проблемы сразу: объекты мелкие и их слишком много за один раз.
Сильная сторона: модель хорошо находит объекты, если они крупные и их мало. Нарезка даёт обе вещи одновременно: масштаб растёт, содержимое на вызов падает. Перекрытие в один объект гарантирует, что ни один объект не окажется разрезанным по границе без «целой» копии где-то ещё.
Рычаги управления: - Размер фрагмента → меньше фрагмент = крупнее объект, но больше вызовов. Максимум — то, что модель не ужимает сама. - Перекрытие → минимум один объект. Меньше — потеряешь объекты на швах. Больше — больше дублей и токенов. - Масштаб относительно целого → не уменьшай. Типичный вред: «приведу объекты к одинаковому размеру в пикселях и порежу». Если объект уже крупный, фрагменты окажутся мельче целого, и результат хуже. - Режим высокого разрешения → не включай по умолчанию. У части моделей он давал катастрофу. Проверь на 2–3 примерах. - Рисование сетки, меток, стрелок поверх → не добавляет информации. Помогает кроп, а не оверлей.
Шаблон промпта
В статье готовых промптов нет. Исследование даёт правило нарезки. Шаблон ниже — обвязка вокруг него для запроса к модели на одном фрагменте.
Это фрагмент {номер} из {всего} изображения «{название_изображения}».
Фрагмент вырезан без уменьшения масштаба. Соседние фрагменты перекрываются на {перекрытие_px} пикселей.
Задача: найди ВСЕ объекты типа «{тип_объекта}» в этом фрагменте.
Как выглядит объект: {описание_или_эталон}.
Для каждого объекта выдай центр (x, y) в пикселях фрагмента.
Если объект обрезан краем — включи его и пометь «на границе».
Если не уверен — пометь «сомнение». Не выдумывай объекты.
Формат: таблица | № | x | y | статус |
В конце одной строкой: «Найдено во фрагменте: {число}».
Что подставлять:
- {номер} и {всего} — порядковый номер фрагмента и общее число.
- {перекрытие_px} — размер вашего объекта в пикселях (не меньше).
- {тип_объекта} и {описание_или_эталон} — что ищем; по возможности приложите картинку-эталон.
Для шага сборки (отдельный запрос):
Вот {всего} таблиц с найденными объектами по фрагментам и смещения каждого фрагмента:
{таблицы_и_смещения}
Переведи координаты в общие (прибавь смещение фрагмента).
Объединяй точки ближе {порог_px} пикселей как один объект.
Выдай итоговую таблицу и общее число. Отдельно перечисли объекты со статусом «сомнение» и «на границе».
🚀 Быстрый старт — вставь в чат:
Вот шаблон безопасной нарезки изображения для поиска мелких объектов. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля. Напиши также скрипт на Python, который режет картинку с перекрытием
и сохраняет смещения каждого фрагмента.
[вставить шаблон выше]
LLM спросит размер изображения в пикселях, размер искомого объекта и лимит выбранной модели на картинку. Эти три числа нужны, чтобы посчитать размер фрагмента и шаг нарезки по правилу из исследования. Остальное она возьмёт из шаблона.
Ограничения
⚠️ Теория держится на двух допущениях: в среднем больше токенов на объект и меньше содержимого в вызове не вредят. Авторы это проверяли, но не везде оно выполняется одинаково.
⚠️ Режим высокого разрешения может навредить: у моделей OpenAI подача большего числа пикселей, чем по умолчанию, в ряде случаев ухудшала результат. Не считай «больше пикселей» автоматически лучше.
⚠️ Перемасштабирование «под размер объекта» вредит: если объекты и так крупные, фрагменты после выравнивания оказываются мельче целого, и качество падает в большинстве проверенных случаев.
⚠️ Нарезка не творит информацию: если на исходной картинке объект не разрешается в пикселях, увеличение не поможет. Это уже предел данных, а не токенов.
⚠️ Дубли и швы: перекрытие создаёт повторные находки. Без шага сборки и проверки итоговое число завысится.
⚠️ Много ручной работы: для листа в 20 фрагментов нужен скрипт (его может написать LLM) или терпение. Расход токенов в разы выше, чем у одного вызова.
⚠️ Область проверки: главное поле эксперимента — чертежи и планы, плюс природные и синтетические картинки. Для скриншотов, фото полок и слайдов вывод логичен, но проверялся меньше.
Как исследовали
Идея была в том, чтобы вместо очередного «трюка с зумом» описать две величины на входе: сколько плиток приходится на сторону объекта (S) и сколько содержимого модель должна охватить за вызов (L). Любой метод (тайлинг, режим высокого разрешения, зум-агент) просто двигает эти два рычага. Авторы вывели из этого теорию, а потом проверили её примерно в 177 тысячах запросов на 797 изображениях, на 11 моделях из пяти семейств. Данные: новый набор из 40 строительных чертежей, ещё 10 отложенных чертежей, планы FloorPlanCAD, природные изображения и синтетика. Гипотезы они зарегистрировали до запусков.
На контролируемых картинках ни одно из 40 предсказанных соотношений не нарушилось. В проверке постфактум на других данных подтвердилось 61 из 89, а четыре провала пришлись на модели OpenAI, которым давали больше пикселей, чем по умолчанию. Показательный провал: один из режимов высокого разрешения дал F1 0,33 на полных листах против 0,89 при стандартном. Популярный рецепт «масштабируй до фиксированного размера объекта и режь» (с плитками 44 px) снижал recall в 19 из 21 случаев. Правило с перекрытием и без уменьшения масштаба на чертежах ни разу значимо не ухудшало результат и улучшало его до +0,28. На примере листа 11236×7698 пикселей символ получил S=0,40 при целой отправке и S=1,5 при нарезке на 20 фрагментов. Это стоило 49 тысяч токенов против 2,5 тысячи, но позволило надёжно найти все 23 символа. Ещё один результат: с ростом числа блоков в одном вызове F1 первого блока падал на 0,22. Значит, объём содержимого сам по себе портит качество. Для практика отсюда вывод: резать надо не «как придётся», а по правилу, и проверять на паре примеров, не навредил ли масштаб.
Адаптации и экстраполяции
🔧 Техника: убрать сетку и метки с картинки → не терять время
Исследование показывает, что рисование сеток, меток и точек поверх уже отправленного изображения не добавляет информации: это та же картинка с другой раскраской. Вместо «нарисуй сетку и ищи в клетках» лучше вырезать клетки отдельными фрагментами и прогнать по правилу выше.
Экстраполяция (в статье не проверялась, но совпадает с её логикой про зум-агентов): правило нарезки как инструкция агенту, например в файле инструкций Claude Code.
## Работа с большими изображениями
Если нужно найти или посчитать мелкие объекты на изображении больше {лимит_px}:
1. Не отправляй изображение целиком и не включай режим высокого разрешения без проверки.
2. Нарежь на фрагменты размером не больше {лимит_px} (без ужатия), перекрытие не меньше размера объекта.
3. Не уменьшай масштаб относительно оригинала.
4. По каждому фрагменту составь список с координатами, переведи в общие, убери дубли.
5. Объекты на границе и сомнительные покажи отдельным списком для проверки человеком.
Ресурсы
- Работа: Why VLMs Miss Small Objects, and When Zooming In Is Safe.
- Авторы: Junzhe Shi, Shida Jiang (Systems Engineering, University of California, Berkeley), Yuan Gan (Quotr AI).
- Код, бенчмарк REDP-X40, инструмент планирования безопасной нарезки и сырые ответы моделей: https://github.com/shijunzhe/vlm-small-objects