TL;DR
SolveEdit-Plan — двухэтапный приём для редактирования изображений. На первом этапе (Inspect, «осмотр») нейросеть-помощник по картинке выписывает всё, что цель оставляет неопределённым, и ищет на картинке доказательства. На втором (Resolve, «решение») сравнивает варианты правки, выбирает один и превращает его в точную инструкцию: что должно получиться и что нельзя трогать. Генератор изображений получает эту инструкцию и вызывается один раз, без правок и дообучения.
Главная находка: когда модели редактирования проваливают задачу вроде «поставь машину в свободное место» или «разложи по легенде», дело обычно не в качестве рисования. Модель не поняла, что именно нужно сделать: выбрала занятое место, не прочитала правило на картинке. Картинка при этом может выглядеть аккуратно. Ошибки в смысле («что за объект», «куда», «сколько») и в расположении («внутри, рядом, соединено») были заметно серьёзнее, чем дефекты картинки. Короткий запрос вроде «расставь по зонам» заставляет модель решать задачу и рисовать одновременно, и первое она делает хуже.
Метод разделяет эти два дела. Сначала текстом определяется итоговое состояние сцены, а редактору достаётся только исполнение. Это дало заметный рост качества на самой сильной модели, а контрольный вариант (модель просто переписывает запрос с тем же числом вызовов) дал меньше. Значит, дело в структуре планирования, а не просто в «ещё одном проходе».
Схема метода
ШАГ 1 (Inspect): найти переменные, которые цель оставила открытыми
(объект, действие, место, итоговое состояние, что сохранить)
→ список переменных + доказательства с крупных планов картинки
ШАГ 2 (Resolve): сравнить 2–3 правдоподобных варианта правки с доказательствами,
выбрать один → итоговая инструкция:
«Выполнить: …» (проверяемые условия) + «Сохранить: …»
ШАГ 3: инструкция + исходная картинка → генератор изображений, один вызов
Шаги 1–2 делаются в одном запросе к мультимодальной модели. Шаг 3 — отдельный запрос в генератор.
Пример применения
Задача: Мерчандайзер сети «Пятёрочка» хочет быстро показать поставщику, как должна выглядеть выкладка. Есть фото полки с йогуртами, перемешанными вперемешку. Рядом на фото листок с планограммой: «верх — безлактозные, середина — классика, низ — детские». Нужно получить картинку с правильно разложенными товарами.
Промпт (этап 1, в мультимодальную LLM, с приложенным фото):
Ты — планировщик правок изображения. Саму картинку ты не редактируешь.
Твоя задача — решить, какая именно правка нужна, и написать
инструкцию для редактора изображений.
Исходное изображение: приложено.
Цель: «Разложи йогурты на полке в соответствии с планограммой на листке».
ЭТАП 1 — INSPECT
1. Выпиши, что цель оставляет неопределённым: какие именно объекты
двигаем, куда, каким должно быть итоговое состояние полки,
что должно остаться нетронутым.
2. Для каждой переменной найди доказательство на картинке: назови
участок (например, «листок слева», «верхняя полка») и опиши,
что на нём видно. Если не видно — так и напиши, не угадывай.
3. Если на картинке есть легенда, схема или надпись с правилом —
выпиши правило дословно.
ЭТАП 2 — RESOLVE
4. Предложи 2–3 правдоподобных варианта итоговой раскладки.
5. Сравни каждый с доказательствами. Отбрось те, что нарушают правило
или ставят товар на занятое место.
6. Выбери один вариант.
7. Составь итоговую инструкцию для редактора в формате:
Выполнить: [проверяемые условия — что именно и где должно быть]
Сохранить: [что нельзя менять: упаковки, ценники, фон, листок]
Дальше вторым сообщением: картинка + блок «Выполнить / Сохранить» из ответа идут в генератор изображений.
Результат: В ответе будет список открытых переменных, привязанный к участкам фото, затем 2–3 варианта раскладки с кратким отбором. В конце придёт готовый блок «Выполнить / Сохранить» с конкретными условиями. Его вы отправляете в генератор вместо исходной короткой фразы. Идеальную раскладку это не гарантирует. Но вероятность выбрать не то место и не прочитать листок снижается: решение принято до рисования.
Почему это работает
Слабость. Короткий запрос вроде «разложи по планограмме» требует от генератора сразу двух дел: решить задачу (что куда) и нарисовать результат. Модели редактирования хорошо исполняют заранее названное изменение, например «убери маркер». А вот определить само изменение по сцене они умеют хуже. Поэтому картинка выходит чистой, но не решает задачу.
Сильная сторона. Мультимодальная языковая модель хорошо читает сцену: находит свободное место, читает легенду, сверяет варианты с правилом. Если ей позволить сделать это текстом, шаги проверяются.
Как метод связывает одно с другим. Решение выносится в текст, а генератор получает готовое итоговое состояние. Отдельный блок «Сохранить» защищает всё остальное от случайных правок: в статье уход за незатронутым содержимым оценивается отдельно, потому что ошибка «перерисовал лишнее» не то же самое, что «не сделал нужное».
Рычаги управления: - Число вариантов на этапе Resolve (2–3) → для простых правок уменьши до одного, для задач с несколькими допустимыми решениями оставь больше. - Требование «доказательство с участка картинки» → убери для очевидных сцен, оставь, когда есть легенды и мелкие надписи. - Блок «Сохранить» → перечисляй конкретные объекты, а не «всё остальное»: чем точнее, тем меньше побочных изменений. - Формулировки в «Выполнить» → пиши как проверяемые утверждения («красная машина целиком внутри клетки 7»), а не пожелания («красиво поставь»).
Шаблон промпта
В доступной части статьи готовых промптов нет (они, по-видимому, в приложении). Шаблон ниже восстановлен по описанию метода: этапы Inspect и Resolve, переменные, сравнение вариантов, обязательства по выполнению и сохранению.
Ты — планировщик правок изображения. Саму картинку ты не редактируешь.
Твоя задача — решить, какая именно правка нужна, и написать
инструкцию для редактора изображений.
Исходное изображение: приложено.
Цель: {цель}
ЭТАП 1 — INSPECT
1. Выпиши, что цель оставляет неопределённым: объект, действие,
место назначения, итоговое состояние, область, которую нельзя трогать.
2. Для каждой переменной найди доказательство на картинке:
назови участок ({где_смотреть}) и опиши, что на нём видно.
Если не видно — напиши «не видно», не угадывай.
3. Если на картинке есть легенда, схема, надпись или повторяющийся
узор — выпиши правило дословно.
ЭТАП 2 — RESOLVE
4. Предложи {число_вариантов} правдоподобных варианта правки.
5. Сравни каждый с доказательствами. Отбрось те, что нарушают
правило или противоречат увиденному.
6. Выбери один вариант и в одной строке объясни выбор.
7. Составь итоговую инструкцию для редактора:
Выполнить: [проверяемые условия — что и где должно быть на результате]
Сохранить: [перечень того, что нельзя менять]
Что подставлять:
- {цель} — цель так, как вы сказали бы коллеге: «поставь машину в свободное место».
- {где_смотреть} — подсказка по зонам: «листок слева», «правый нижний угол». Если не знаете — удалите.
- {число_вариантов} — обычно 2–3.
🚀 Быстрый старт — вставь в чат вместе с фото:
Вот шаблон двухэтапного планирования правки изображения (Inspect → Resolve).
Адаптируй под мою задачу: [твоя задача с картинкой].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какая цель правки, что на картинке должно остаться нетронутым и есть ли на ней правила (легенда, схема). Эти вопросы нужны, потому что метод держится на трёх вещах: открытые переменные, правило из картинки и защищаемое содержимое. Остальное она возьмёт из шаблона.
Ограничения
⚠️ Потолок качества: даже с планированием лучшая модель набрала меньше трёх четвертей баллов. Это снижает число ошибок, но не убирает их. Результат нужно проверять глазами.
⚠️ Выигрыш от структуры меньше, чем от самого планирования: простое переписывание запроса уже даёт часть прироста. Строгая схема Inspect/Resolve добавляет сверху заметно меньше.
⚠️ Нет готовых промптов: в доступной части статьи нет оригинальных текстов инструкций. Шаблон выше — реконструкция по описанию метода, а не копия авторского.
⚠️ Крупные планы в чате делаются вручную: в оригинале планировщик сам запрашивает кропы нужных участков. В обычном чате вы вырезаете и прикладываете их сами или просите модель описать участок по координатам.
⚠️ Ошибки исполнения остаются: планирование не лечит дефекты рисования: размытие, искажения, «призраки» на месте убранных объектов. Оно лечит только неверное решение задачи.
⚠️ Неподходящие задачи: метод нужен там, где у правки есть проверяемо верное или неверное решение. Для «сделай красивее» и других вкусовых правок он мало что даёт.
Как исследовали
Авторы заметили, что бенчмарки редактирования изображений смешивают два умения: выполнить заданную правку и понять, какая правка вообще нужна. Они собрали SolveEdit: 2 728 кейсов в 10 областях (быт, наука, карты, спорт, игры и др.) и 54 подобластях. Кейсы разделены на три режима по тому, откуда берётся информация для решения. В первом всё сказано в запросе. Во втором ответ определяется состоянием сцены, например единственное свободное место. В третьем нужно прочитать правило, нарисованное на картинке, например легенду.
Оценка тоже нетипичная. Правильных ответов может быть несколько, поэтому единого эталонного изображения нет. У каждого кейса есть «контракт» из мелких проверяемых критериев. Одни описывают, что должно получиться, другие — что должно остаться нетронутым. Проверяет в основном мультимодальная модель-судья, а для части критериев ей помогают детекторы объектов (SAM, YOLO).
На этом тесте проверили девять моделей редактирования изображений и две видеомодели (оценивался финальный кадр). Лучшая получила всего 57 баллов из 100. Разбор по критериям показал: провалы сильнее в смысле и расположении, чем в качестве изображения. Отсюда простая гипотеза: нужно определить правку до генерации. Её проверили планировщиком SolveEdit-Plan, и на лучшей модели результат вырос с 57,0 до 71,6. Метод перенёсся на открытый редактор и видеогенератор. Решающий контроль: переписывание запроса с тем же числом вызовов дало на 6,3 пункта меньше, чем структурный планировщик.
Неожиданность в том, что картинки в целом выглядели нормально, а задача оставалась нерешённой. Для практики отсюда вывод: если результат «красивый, но не то», чините постановку задачи, а не просите «улучшить качество».
Адаптации и экстраполяции
🔧 Техника: контракт проверки → быстрый аудит результата
В статье оценка строится на мелких проверяемых утверждениях с тремя исходами: выполнено, частично, не выполнено. Их делят на «обязательно» и «нельзя трогать». Это можно применить к готовой картинке без всякой генерации:
Вот исходное фото, итоговое фото и цель правки: {цель}.
Проверь результат по критериям. Каждый критерий — одно наблюдаемое
утверждение. Ответ по каждому: выполнено / частично / не выполнено
с короткой причиной.
Обязательные: {что_должно_получиться}
Защищённые: {что_не_должно_измениться}
Если по картинке невозможно судить — напиши «не видно».
Защищённый критерий имеет смысл, только если он может провалиться при полностью выполненных обязательных. Тогда одна ошибка не считается дважды. Так вы быстро отличите «не сделал нужное» от «испортил лишнее».
Ресурсы
- SolveEdit: Benchmarking Visual Problem Solving in Generative Models — статья, SolveEdit-Plan, SolveScore. Авторы и университеты в доступной части текста не указаны.
- В статье упомянуты SAM и YOLO (детекторы для проверки критериев) и контрольный метод Generic Vision Rewrite.