Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Мультимодальную модель научились исправлять факт за фактом, не записывая каждую новую правку поверх прежних областей параметров. Команда Northwestern Polytechnical University описала ROSE в препринте, который не прошёл рецензирование и содержит замеры самих авторов: после 1 000 обновлений средняя оценка по надёжности, переносу правки и сохранности исходных знаний составила 92,18%. Для продукта с часто меняющимися фактами это возможная альтернатива регулярному переобучению модели.
Как ROSE разделяет последовательные правки
Обычное редактирование знаний меняет параметры модели так, чтобы она давала новый ответ на конкретный вопрос. При последовательных правках возникает конфликт: очередное обновление может испортить предыдущие или изменить ответы на запросы, которые вообще не относились к редактируемому факту.
ROSE оставляет основную модель замороженной и записывает изменения во вспомогательную ветвь. Для каждой правки метод отдельно извлекает признаки изображения и текста, а затем добавляет их направления в накопленное пространство уже отредактированных знаний.
Перед следующим шагом градиент очищают от компонентов, направленных вдоль прежних правок. Иными словами, обновление уводят в математически независимое направление, где оно с меньшей вероятностью перезапишет уже добавленный факт.
Одной геометрии недостаточно: свободное направление всё ещё может задеть исходные способности модели. Поэтому ROSE сравнивает вспомогательные параметры с замороженной основой, выделяет координаты с наибольшими изменениями и через динамическую маску ограничивает область обновления. Маску пересчитывают на каждом шаге оптимизации.
Во время ответа обе ветви не смешиваются целиком. Для каждой правки сохраняются текстовый и визуальный прототипы — компактные представления её смысла. Маршрутизатор сравнивает новый запрос с этим банком и включает отредактированную ветвь только при достаточном совпадении.
Даже после включения ROSE переносит не весь результат вспомогательной ветви. Метод выбирает компоненты, где расхождение с исходной моделью достаточно велико, и подмешивает только их. Первый фильтр решает, относится ли запрос к правке, второй — какую часть правки применить.
Где проверяли устойчивость правок
Метод испытывали на двух мультимодальных бенчмарках. MMEdit сочетает ответы на вопросы по изображениям и создание подписей, а VLKEB проверяет исправление фактов через вопросы по реальным изображениям. Оценка учитывала точность нового ответа, перенос правки на переформулированный текст и изменённое изображение, а также сохранность ответов на посторонние запросы.
Разбор компонентов показал, что проекция и маска решают разные задачи. Без разделения направлений сильнее конфликтуют последовательные правки, а без семантического маршрутизатора изменённые знания чаще включаются на нерелевантных запросах. Слишком строгий маршрутизатор, напротив, пропускает переформулировки нужного вопроса.
Затраты измеряли на LLaVA-v1.5-7B с одной RTX 4090. После длинной серии среднее время ответа держалось около 1,1 секунды, а пиковое потребление видеопамяти выросло на 224 МБ относительно одиночной правки. Это показывает, что банк направлений и прототипов в таком масштабе не создаёт быстро растущих накладных расходов.
Стенд состоит из заранее подготовленных замен фактов и связанных с ними проверочных примеров. Поэтому результаты описывают контролируемое редактирование мультимодальных знаний, а не весь поток неоднозначных исправлений, который возникает в рабочем продукте.
Меняет ли ROSE планы продуктовых команд
Работа не требует немедленно менять выбранную архитектуру, но добавляет практичный вариант в план экспериментов. ROSE имеет смысл проверять, если факты нужно закреплять именно в поведении модели, обновления приходят последовательно, а полное переобучение после каждой правки слишком тяжело.
Для внедрения понадобится хранить замороженную основу, вспомогательную ветвь и прототипы всех правок. Порог маршрутизатора придётся настраивать на собственных запросах: низкий порог чаще затрагивает посторонние ответы, высокий перестаёт узнавать близкие формулировки. Средняя оценка бенчмарка здесь менее полезна, чем отдельные тесты на ложное включение правки.
Особенно важны пограничные примеры: похожие изображения с другим фактом, перефразированные вопросы и запросы, где совпадает только одна модальность. Именно на них решается, станет ли изоляция подпространств защитой от забывания или просто перенесёт ошибку в маршрутизатор.
Если изменчивые сведения уже поступают из внешней базы или поиска, ROSE не отменяет такую схему. Метод отвечает на другую задачу: как последовательно менять внутренние ассоциации модели, когда приложение должно воспроизводить исправленный факт без добавления контекста к каждому запросу.
Практический следующий шаг — небольшой пилот на истории реальных исправлений продукта. Сравнивать стоит не только долю успешно внесённых фактов, но и ответы на соседние темы до и после всей последовательности. Работа показывает, что такие правки можно геометрически разделять; перенос на конкретный поток данных всё ещё нужно подтвердить отдельно.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
