ColPali: как работает поиск по страницам-картинкам без OCR

ColPali — это OCR-free retriever для документов, предложенный в работе Manuel Faysse и соавторов, поданной в arXiv 27 июня 2024 года и позже опубликованной в версии ICLR 2025. Вместо цепочки из OCR, layout detection, chunking и текстовых эмбеддингов модель индексирует сами страницы как изображения и ищет ответную страницу по текстовому запросу.

Для RAG это важно в тех случаях, где смысл живёт не только в тексте, но и в вёрстке: таблицах, графиках, формулах, подписях к рисункам и взаимном расположении блоков. Ниже — разбор именно исходного ColPali и чекпоинта vidore/colpali, без подмены его более поздними вариантами вроде ColPali v1.3 или ColQwen2.

Контекст: зачем вообще искать по страницам-картинкам

Обычный document retrieval для PDF редко сводится к «взяли текст и засунули в векторную базу». На практике пайплайн выглядит длиннее: PDF parser или OCR извлекает текст, затем отдельная модель находит layout, потом текст режут на чанки, иногда добавляют captioning для графиков и изображений, а уже после этого считают эмбеддинги.

Авторы ColPali исходят из простой мысли: в visually rich документах основная потеря качества часто происходит до эмбеддера. Если таблица разобралась криво, подпись отвалилась, а график превратился в шум, то даже сильная текстовая retrieval-модель уже не исправит исходную ошибку. Именно поэтому в статье сначала вводится собственный benchmark ViDoRe для page-level retrieval по нескольким доменам и языкам, а уже потом показывается новый подход.

Это важный сдвиг в постановке задачи. Единицей поиска становится не текстовый фрагмент, а страница как визуальный объект. Для RAG по отчётам, научным PDF, сканам, презентациям и формам это часто ближе к реальному использованию, чем passage retrieval по OCR-тексту.

Метод: как устроен ColPali

Бэкбон: PaliGemma как основа retrieval-модели

ColPali строится поверх google/paligemma-3b-mix-448. По техническому отчёту PaliGemma и его model card, это 3B vision-language model, собранная из vision encoder SigLIP-So400m и language model Gemma-2B. В официальном репозитории ColPali тот же base checkpoint указан явно.

Зачем нужен именно VLM, а не обычный image encoder? Потому что после multimodal training он уже умеет совместно представлять текстовые и визуальные признаки. Это удобно для retrieval: запрос остаётся текстом, а страница — изображением, но обе стороны можно приводить к совместимому пространству представлений.

Что добавляют авторы поверх PaliGemma

В peer-reviewed версии статьи авторы пишут, что поверх выходных токенов модели добавляют projection layer в пространство размерности D = 128. Ту же размерность подтверждает и актуальная документация Transformers для ColPali. Идея здесь прагматичная: сохранить детальность, но не раздувать хранилище ещё сильнее.

Дальше включается архитектурная идея ColBERT: документ и запрос представляются не одним вектором, а набором векторов. У ColPali это особенно естественно, потому что страница уже разбита на патчи изображения, а запрос — на текстовые токены.

LI(q, d) = Σ_i max_j ⟨E_q[i], E_d[j]⟩

То есть для каждого вектора запроса модель ищет наиболее похожий вектор страницы, а затем суммирует такие максимумы. Это и есть late interaction: документ можно закодировать заранее, а дорогое точное сопоставление выполнить в момент запроса.

Чем это отличается от OCR + embedding

• Сохраняется вёрстка. Таблица, подпись, график и заголовок остаются частью одной визуальной структуры.
• Не нужен brittle preprocessing. Не надо отдельно выбирать OCR, layout detector и схему chunking.
• Запрос сопоставляется с патчами страницы. Это ближе к поиску по реальному документу, чем по потерявшему контекст OCR-тексту.

Данные и обучение

Здесь есть полезный нюанс версий. В ICLR-версии статьи указан train set из 118,695 пар «запрос-страница», где 63% приходятся на открытые academic datasets, а 37% — на synthetic data из web-crawled PDF с pseudo-questions от Claude-3 Sonnet. В текущей model card на Hugging Face фигурирует 127,460 пар при той же пропорции 63/37. Скорее всего, артефакт обновлялся после исходной публикации; дальше я опираюсь на цифры peer-reviewed paper, а расхождение отмечаю как version drift.

Обе официальные версии сходятся в более важном: train set был полностью англоязычным по дизайну, а пересечение PDF между training и ViDoRe авторы отдельно запрещали, чтобы не загрязнять оценку.

Результаты

Основной результат статьи — не только в том, что ColPali «работает», а в том, что видно, откуда именно приходит выигрыш. Авторы строят лестницу из нескольких моделей: исходный SigLIP, затем дообученный BiSigLIP, затем BiPali как bi-encoder на базе PaliGemma, и только потом ColPali с late interaction.

Числа по baseline в таблице ниже приведены по данным Table 2 из peer-reviewed версии статьи. Для исходного чекпоинта ColPali значение 81.3 дополнительно совпадает с официальным репозиторием illuin-tech/colpali, где этот checkpoint помечен как used in the ColPali paper.

Метод	Средний nDCG@5 на ViDoRe	Комментарий
SigLIP (vanilla)	51.4	Базовый single-vector visual retriever по данным paper
BiSigLIP (+ fine-tuning)	58.6	Дообучение на document-oriented data помогает, но ограничение single-vector остаётся
BiPali (+ LLM)	58.8	Контекстуализация через PaliGemma полезна, но без late interaction прирост небольшой
Unstructured + OCR + BGE-M3	66.1	Сильный текстовый baseline с OCR, по данным paper
Unstructured + Captioning + BGE-M3	67.0	Лучший baseline авторского сравнения, по данным paper
ColPali (+ Late Interaction)	81.3	Исходный paper checkpoint; тот же score повторён в официальном репозитории

Если смотреть не только на качество, но и на стоимость индексации, картина тоже меняется. В appendix ICLR-версии авторы приводят среднюю latency на страницу для офлайновой индексации.

Пайплайн индексации	Средняя latency на страницу	Источник
Unstructured parser + OCR + captioning + page encoding	7.22 s	Appendix peer-reviewed paper
SigLIP page encoding	0.12 s	Appendix peer-reviewed paper
ColPali page encoding	0.39 s	Appendix peer-reviewed paper; та же величина согласуется с arXiv-версией

Важно не перепутать две разные latency. По данным paper, ColPali быстрее на офлайновой индексации, потому что вырезает целый preprocessing stack. Но online query encoding у него немного тяжелее текстового bi-encoder: около 30 ms для запроса из 15 токенов против примерно 22 ms у BGE-M3. Иными словами, ColPali выигрывает прежде всего на ingestion и на качестве поиска по сложным страницам, а не потому, что любой runtime становится дешевле.

Есть и ещё один practically useful результат. В статье и в официальном репозитории авторы показывают token pooling: при факторе 3 число векторов уменьшается на 66.7%, а сохраняется 97.8% исходной performance. Это не «бесплатная» оптимизация, но хороший сигнал, что storage overhead можно частично смягчить без полного отказа от late interaction.

Наконец, у ColPali есть интерпретируемость. Авторы накладывают similarity heatmap на страницу и показывают, какие патчи были важны для отдельных токенов запроса. По их примеру, модель фокусируется не только на тексте вроде hourly/hours, но и на элементах графика, например оси X. Для retrieval по документам это полезнее, чем просто знать итоговый score.

Интерпретация

Наш комментарий

На наш взгляд, ColPali важен не как «ещё один retriever», а как смена единицы индексации. В классическом RAG мы стараемся превратить документ в текст как можно раньше. ColPali, наоборот, откладывает это решение и сначала отвечает на вопрос: какая страница визуально и семантически подходит под запрос?

Это особенно разумно для финансовых отчётов, научных PDF, форм, policy-документов и презентаций. В таких корпусах таблица или рисунок — не украшение, а носитель смысла. Если retrieval ломается на этапе OCR или chunking, downstream LLM уже получает неверный контекст. ColPali уменьшает именно этот класс ошибок.

Но полезно держать границу: ColPali решает задачу retrieval страницы, а не финального answer extraction. После того как нужная страница найдена, вам всё равно может понадобиться reader, OCR, grounding по координатам или multimodal LLM для генерации ответа с цитатой.

Ограничения

• Storage overhead. В arXiv HTML фигурирует память порядка 256 KB на страницу, а в appendix ICLR-версии — 257.5 KB. Это немного для маленького корпуса, но заметно для миллионов страниц, если не применять compression.
• Инфраструктурная цена. Model card отдельно предупреждает: late interaction и multi-vector retrieval требуют дополнительной инженерии, потому что не все популярные vector DB умеют такой режим нативно.
• Не универсален по языкам и типам документов. В model card прямо сказано, что модель в первую очередь ориентирована на PDF-подобные документы и high-resource languages. Да, paper показывает zero-shot обобщение, но делать из этого общий вывод для всех языков не стоит.
• Benchmark не равен продакшену. ViDoRe полезен, но часть задач там получена из VQA-бенчмарков, а часть synthetic queries генерировалась с помощью Claude-3 Sonnet и проходила последующую фильтрацию. Это хороший исследовательский стенд, но не полная копия корпоративных архивов.
• Page-level retrieval не заменяет fine-grained grounding. Найти правильную страницу — не то же самое, что найти точную ячейку таблицы, абзац или bounding box.
• Есть version drift. Сегодня в экосистеме уже доступны более сильные потомки ColPali, но сравнивать их текущие leaderboard-оценки с исходной работой 2024 года без оговорок методологически неправильно.

Вывод

ColPali показал, что retrieval для документов можно строить не вокруг OCR и чанков, а вокруг визуального представления страницы. В исходной работе это дало сильный прирост на ViDoRe и более простой ingestion для visually rich PDF.

Практический вывод для RAG такой: если ваши документы теряют смысл после OCR, ColPali и похожие late-interaction visual retrievers стоят внимания. Если же вам нужен дешёвый passage retrieval по чистому тексту, классический OCR/text pipeline всё ещё может оказаться проще и дешевле в эксплуатации.

Источники

• ColPali: Efficient Document Retrieval with Vision Language Models
• ColPali: Efficient Document Retrieval with Vision Language Models (ICLR 2025 proceedings PDF)
• illuin-tech/colpali — GitHub repository
• vidore/colpali — Hugging Face model card
• ColPali — Hugging Face Transformers documentation
• PaliGemma: A versatile 3B VLM for transfer
• ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT

FAQ

Когда ColPali полезнее обычного OCR-пайплайна?

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

Нужен ли OCR после ColPali?

Часто да. ColPali хорошо решает retrieval страницы, но для точного извлечения фрагмента, цитаты или координат может понадобиться OCR или multimodal reader поверх найденной страницы.

Чем ColPali отличается от обычного image embedding?

Он не сжимает страницу в один вектор, а использует multi-vector representation и late interaction по схеме ColBERT. Это дороже по хранению, но лучше для точного сопоставления запроса с локальными патчами страницы.

Можно ли использовать ColPali в текущем стеке Python?

Да. Для модели есть официальный репозиторий, model card и документация в Transformers. Но продакшен-интеграция обычно требует инфраструктуры, понимающей multi-vector scoring.

Читайте также

• Self-RAG и Corrective RAG: как работает самопроверка в RAG
• «Lost in the middle»: почему модель теряет середину контекста
• Как делают окно в миллион токенов: RoPE, YaRN и ring-attention