Apple LensVLM сжимает длинный контекст агента в картинки и учит модель «зумить»

Apple предложила LensVLM — схему, в которой накопленный контекст агента хранится как набор изображений, а визуально-языковая модель по ходу работы «приближает» нужные фрагменты. Идея опирается на DeepSeek-OCR: там текст рендерили в картинки и получали сжатие примерно в 10 раз при точности распознавания около 97%. Apple переносит этот принцип с распознавания документов на длинные агентские задачи, где контекст растёт с каждым шагом. В доступном фрагменте материала собственных бенчмарков LensVLM нет, поэтому оценивать результаты рано.

Проблема: резюме стирает улики

Агент, который долго работает над задачей, накапливает всё подряд: куски кода, ответы инструментов, логи команд, историю собственных действий. Окно контекста при этом ограничено, а стоимость и задержка растут вместе с длиной входа. Стандартный выход — суммаризация: старые записи заменяют короткой выжимкой.

У этого приёма есть слабое место. Запись, которая на шаге 20 выглядела мусором, на шаге 80 может оказаться ключевой: строка из трассировки, значение параметра, имя файла. Если в памяти осталась только выжимка, вернуть утраченную деталь нечем. Сжатие здесь необратимо.

Как устроен LensVLM

LensVLM меняет сам формат хранения. Вместо того чтобы переписывать историю короче, систему превращают в изображения, где исходный текст сохраняется целиком. Модель сначала видит сжатое представление всего контекста, а затем может «навести линзу» на конкретную область и рассмотреть её в большем разрешении. Это похоже на то, как человек пролистывает длинный документ, а потом возвращается к нужной странице.

По описанию подхода, ключевые элементы такие:

• Формат контекста: код, вывод инструментов и записи взаимодействий рендерятся в изображения.
• Механизм доступа: модель выбирает область и увеличивает её, а не читает всё с одинаковой детализацией.
• Целевой сценарий: долгие задачи агентов, где контекст непрерывно растёт.
• Опорная работа: DeepSeek-OCR с визуальным сжатием текста.
• Опубликованные метрики точности, степень сжатия и задержка в доступном тексте не приведены.

Главное отличие от суммаризации в обратимости. Детали не выброшены, они лишь представлены грубее и доступны по запросу.

Что остаётся под вопросом

У визуального хранения текста есть известные ограничения. Мелкий шрифт, плотный код и таблицы при сильном сжатии читаются хуже, а ошибка распознавания в идентификаторе или числе может стоить дороже, чем потеря целой фразы. Кроме того, шаг «приблизить» требует от модели понимать, что именно ей нужно, ещё до того как она это увидела. Если выбор области окажется неудачным, агент пропустит нужную строку так же, как пропустил бы её после суммаризации.

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

Что проверить на практике

Командам, которые строят долгоживущих агентов, стоит посмотреть на LensVLM как на гипотезу для собственных тестов, а не как на готовое решение. Разумный план такой:

• Собрать набор задач, где ответ зависит от детали из начала сессии, и сравнить визуальное хранение с суммаризацией и с обычным длинным контекстом.
• Отдельно измерять ошибки на идентификаторах, путях файлов, числах и фрагментах кода.
• Учитывать суммарную стоимость: токены, число дополнительных обращений и задержку, а не только длину исходного контекста.
• Дождаться публикации статьи и открытых результатов, прежде чем менять архитектуру памяти в продакшене.

Если подход подтвердится на независимых замерах, он даст агентам память, из которой детали можно достать обратно. Пока это остаётся заявкой от Apple, к которой нужны цифры.