Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Контекст для систем, которые отвечают по найденным документам, удалось сократить до небольшой подсказки для языковой модели. В препринте Renmin University of China, ComindX и Claremont McKenna College, который не рецензирован и содержит замеры самих авторов, OpticalRAG показал лучший баланс точности и длины контекста на трёх наборах задач, передавая модели 16 токенов. Подход добавляет к вариантам архитектуры RAG визуальное сжатие вместо сокращения исходного текста.
Как страница превращается в подсказку для модели
Обычная система RAG находит подходящие фрагменты текста и добавляет их к запросу. Чем больше фрагментов, тем больше вычислений требует языковая модель. Если заранее удалить предложения или пересказать документ, система может потерять имя, условие или число, которое понадобится для ответа.
OpticalRAG сначала разбивает документ на окна и отрисовывает их как страницы. Замороженный визуальный кодировщик DeepEncoder превращает каждую страницу в набор векторов — визуальных токенов. Они сохраняют не только содержание текста, но и его расположение на странице.
Система индексирует каждый визуальный токен отдельно. Когда приходит текстовый запрос, Qwen2.5-7B-Instruct строит его внутреннее представление, а обучаемая проекция переводит его в пространство визуального кодировщика. Затем поиск выбирает токены, которые ближе всего к запросу, и возвращает им исходный порядок.
Для такого поиска не нужно отдельно обучать модель сопоставлять пары запросов и страниц. Проекция входит в общий модуль сжатия и учится вместе с ним, тогда как визуальный кодировщик и языковая модель остаются замороженными.
Найденные токены ещё не передают в Qwen напрямую. Модуль перекрёстного внимания учитывает вопрос и сжимает 256 визуальных токенов в короткий префикс. Этот префикс добавляют перед текстом запроса так же, как обычные входные токены, хотя он не содержит читаемых слов.
Почему короткий префикс оказался выгоднее текста
Авторы оценивали не только точность, но и цену контекста в токенах. Их показатель CAP повышает результат за более короткий вход, но только если система отвечает не хуже базовой модели без документа. Поэтому метод не может получить высокий итоговый балл одной лишь агрессивной компрессией.
На LongBench-v2 OpticalRAG набрал 35,79 балла против 30,62 у Qwen2.5-7B-Instruct без документов — разница составила 5,17 пункта. На LooGLE-v2 метод также дал лучший обычный результат. На BAMBOO он уступил по точности RECOMP и LLMLingua-v2, которые сохраняли гораздо больше текста, но занял первое место по CAP благодаря короткому входу.
Эксперимент с разным объёмом префикса показал, что простое увеличение бюджета не гарантирует улучшения. Более длинные варианты иногда добавляли шум, хотя на длинных примерах дополнительная ёмкость помогала. Отдельная проверка также показала, что сжатие с учётом вопроса работает лучше усреднения визуальных токенов и случайной проекции.
Метод проверяли на LongBench-v2, BAMBOO и LooGLE-v2, причём во всех случаях использовали только задачи с выбором ответа. Во всех сравнениях работала одна базовая модель — Qwen2.5-7B-Instruct; среди соперников были стандартный текстовый RAG, xRAG, RECOMP, Selective Context и LLMLingua-v2. Эти условия позволяют сравнить способы сжатия, но не показывают качество свободных ответов или работу с другой LLM.
Когда OpticalRAG меняет план разработки
Работа пока не даёт основания заменять действующий текстовый RAG. Она меняет список прототипов для команд, у которых найденные документы занимают основную часть контекста: наряду с удалением токенов, пересказом и одним вектором на документ теперь стоит проверить визуальный индекс и префикс, зависящий от вопроса.
Архитектура разделяет тяжёлые и обучаемые части. Страницы можно отрисовать, закодировать и проиндексировать заранее. При запросе система выполняет поиск по готовым визуальным токенам, сжимает найденное и запускает замороженную LLM. Обучать приходится компактный модуль проекции, внимания и перехода в пространство языковой модели, а не обе большие модели целиком.
Практический тест стоит строить вокруг собственных вопросов, а не только вокруг степени сжатия. Нужны случаи, где ответ зависит от точного числа, имени, фрагмента кода или связи между удалёнными частями документа. Именно на таких запросах станет видно, сохраняет ли визуальное представление полезные детали лучше текстового компрессора.
В статье нет замеров задержки и стоимости отрисовки, индексации и поиска, поэтому короткий префикс нельзя напрямую считать пропорциональным снижением полной стоимости системы. Ближайшее решение для команды — не перенос архитектуры в промышленную среду, а сравнительный прототип против текущего RAG на одинаковой модели и собственном наборе запросов.
Источники
Иллюстрация: рисунок из статьи «OpticalRAG: Pixel-Space Compression for Token-Efficient Retrieval-Augmented Generation», Senhao Liu, Yuheng Zhang, Chunyu Wei и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
