PixelRAG: RAG по скриншотам вместо HTML-парсинга
Новый подход предлагает индексировать не очищенный текст страницы, а ее визуальное представление: скриншоты, разрезанные на фрагменты. Для бизнеса это важный сигнал: часть ошибок RAG возникает не в модели, а в том, как мы превращаем сложные документы и веб-страницы в плоский текст.
Почему это важно для RAG
Классический RAG обычно выглядит просто: берем HTML или PDF, извлекаем текст, режем на чанки, строим embedding-индекс и подаем найденные фрагменты в LLM. На практике самая хрупкая часть часто находится до модели - в парсинге.
Веб-страницы, технические регламенты, каталоги, инструкции и корпоративные порталы редко являются чистым линейным текстом. Ответ может быть в таблице, рядом с изображением, в боковом инфобоксе, в заголовке раздела, в мелкой подписи или в структуре страницы. Когда парсер превращает это в поток символов, он может потерять строки таблицы, перепутать иерархию, выбросить визуальные подсказки или поднять нерелевантный блок выше нужного абзаца.
PixelRAG проверяет радикальную альтернативу: не пытаться восстановить идеальный текст из HTML, а работать с тем, что видит человек - с отрендеренной страницей.
Как устроен PixelRAG
Подход переносит retrieval и reading в визуальное пространство, но оставляет привычную логику RAG: индекс, поиск top-k и генерацию ответа на найденном контексте.
Страница сначала рендерится
HTML, CSS и изображения собираются в локальное зеркало, затем страница открывается в headless Chromium через Playwright. Так система получает не сырой HTML, а внешний вид страницы.
Скриншот режется на tiles
Полная страница нарезается на фиксированные фрагменты. В эксперименте для Wikipedia использовалась ширина 875 px и tiles высотой 1024 px.
Индекс строится по картинкам
Каждый tile кодируется visual embedding-моделью. Авторы использовали Qwen3-VL-Embedding и FAISS для приближенного поиска.
Reader получает изображения
После retrieval найденные скриншоты передаются в vision-language model. Промежуточного OCR или HTML-to-text шага в основном pipeline нет.
Retriever дообучается на скриншотах
Авторы усилили visual retriever contrastive fine-tuning, синтетическими QA-парами и dynamic hard-negative mining.
Стоимость регулируется разрешением
В отличие от text RAG, у pixel-подхода появляется новый рычаг: сжимать изображение и уменьшать число visual tokens без перестройки индекса.
Что показали эксперименты
Авторы построили pixel-native datastore на масштабе полной Wikipedia: около 7 млн статей и примерно 30 млн screenshot tiles. Отдельно подход проверялся на новостном корпусе из CNN, AP News и BBC: около 668 тыс. статей и 3.6 млн tiles.
На end-to-end QA PixelRAG обошел text-based RAG baselines на всех шести бенчмарках из paper. Самый показательный результат - улучшение не только на мультимодальных задачах, где это ожидаемо, но и на текстовых NQ и SimpleQA. Это означает, что визуальная структура помогает даже там, где ответ формально можно прочитать как текст.
Особенно интересен разбор SimpleQA по типам evidence. Для вопросов, где ответ лежал в таблице, PixelRAG показал accuracy 75.8% против 66.7% у Trafilatura и 48.2% у mwparserfromhell. Для paragraph evidence преимущество тоже заметное: 79.4% против 71.5% и 64.1%. Здесь проблема text RAG не только в потере текста, но и в ранжировании: линейный инфобокс может быть keyword-dense и вытеснять нужный абзац из top-k.
PixelRAG против text-based RAG
Сравнение end-to-end QA accuracy. В качестве сильной текстовой baseline здесь взята Trafilatura, так как она лучше сохраняет веб-текст среди проверенных парсеров.
| Benchmark | Text RAG, Trafilatura | PixelRAG | Комментарий |
|---|---|---|---|
| NQ | 55.9% | 58.7% | Небольшой, но стабильный выигрыш на текстовом QA |
| NQ-Tables | 42.5% | 48.8% | Табличная структура лучше сохраняется в пикселях |
| SimpleQA | 71.6% | 78.8% | Плюс 7.2 п.п. на широко изученном text-centric benchmark |
| MMSearch | 24.7% | 28.3% | Мультимодальный open-domain QA |
| EVQA | 29.6% | 45.1% | Сильный рост там, где важны изображения и визуальный контекст |
| LiveVQA | 59.0% | 70.0% | Обобщение на шумный новостной корпус |
Главный инженерный вывод
PixelRAG не отменяет text RAG. Он показывает, что качество RAG зависит не только от LLM и embedding-модели, но и от представления источника. Если источник изначально визуальный или структурный, принудительное превращение в плоский текст может быть самым дорогим местом ошибки.
Где такой подход полезен в бизнесе
Мы бы рассматривали pixel-space retrieval не как замену всех RAG-систем, а как отдельный режим для источников, где верстка несет смысл.
-
01
Корпоративные порталы и web-интерфейсы
Базы знаний, внутренние wiki, каталоги, страницы 1С-Битрикс, Confluence-подобные разделы и HTML-отчеты часто содержат таблицы, карточки, вкладки и боковые блоки.
-
02
Техническая документация и инструкции
В регламентах, паспортах оборудования, руководствах и схемах ответ часто зависит от таблицы, подписи, списка параметров или визуального соседства блоков.
-
03
Коммерческие каталоги и прайс-листы
Для закупок и продаж важно не просто извлечь текст, а правильно связать артикул, характеристику, цену, наличие и примечание в одной визуальной строке.
-
04
Агентный поиск по вебу
Для ReAct-агентов и deep research систем screenshot retrieval может давать более плотный контекст за один retrieval step, особенно когда страница плохо парсится.
Как мы бы проектировали пилот
Для корпоративного внедрения мы не стали бы сразу переносить весь RAG в пиксели. Разумнее начать с гибридной архитектуры:
- Text index для обычных документов, писем, статей и материалов с чистой структурой.
- Visual index для HTML-страниц, таблиц, PDF со сложной версткой, сканов, каталогов и отчетов.
- Router перед retrieval, который выбирает режим по типу источника и вопроса.
- Reranker поверх найденных text chunks и screenshot tiles, чтобы не отдавать reader лишний контекст.
- VLM reader для визуальных фрагментов и обычная LLM для чистого текста.
- Оценка качества через RAGAS, evidence recall, human review и набор бизнес-вопросов от пользователей.
В закрытом контуре это можно собрать без передачи документов во внешние API: локальное зеркало источников, Playwright-рендеринг, visual embedding, Qdrant или FAISS, inference через vLLM или SGLang для LLM/VLM, журналирование и разграничение доступа через RBAC/SSO.
Цифры PixelRAG
Ограничения и здравый смысл
У pixel-space RAG есть цена. Нужно рендерить страницы, хранить изображения или их embeddings, обслуживать VLM reader и контролировать качество OCR-подобного чтения внутри модели. Маленькие или старые VLM могут проигрывать text RAG: в paper заметный перелом начинается с более сильных Qwen3-VL классов, а не с ранних vision-моделей.
Еще один риск - динамические интерфейсы. Если страница зависит от авторизации, фильтров, состояния UI или JavaScript, pipeline должен воспроизводимо получать именно тот вид, который нужен пользователю. Для корпоративного контура это решается инженерно: снапшоты, сервисные учетные записи, расписание переиндексации, контроль версий и аудит доступа.
Поэтому практический вывод спокойный: text RAG остается базовым вариантом, но для источников со сложной визуальной структурой стоит добавлять visual retrieval как отдельный слой. Это особенно актуально для компаний, где знания живут не в аккуратных markdown-файлах, а в порталах, таблицах, PDF, отчетах и интерфейсах.
Хотите проверить RAG на ваших документах?
Мы можем взять небольшой набор реальных источников, сравнить text RAG, hybrid RAG и visual retrieval, посчитать evidence recall и показать, где именно теряется качество.