DocSeeker: як навчити візуальну модель посилатися на сторінки в довгих документах

Кожен, хто ставив моделі питання про довгий звіт і отримував упевнену відповідь, яку неможливо перевірити, знає, як це дратує. Робота з довгими документами — це не просто читання більшої кількості сторінок. Складніше інше: щоб відповідь лишалася надійною від першої сторінки до останньої. DocSeeker, нова стаття (arXiv 2604.12812), розв'язує саме цю задачу: модель має показати, на які сторінки вона спиралася.

Де ламаються моделі для довгих документів

Наявні підходи до відповідей на питання за довгими документами поділяються на три табори, і кожен помиляється по-своєму.

Конвеєри з OCR і парсингом. Вони витягають текст і розмітку за допомогою OCR або PDF-парсерів і передають результат мовній моделі. Сюди належать LongFormer, LayTokenLLM, HiVT5, DocLLM і DocVLM. Вони спотикаються об помилки OCR і дорогою можуть втрачати розмітку та візуальні підказки.

Візуальний RAG. Візуальний ретривер вибирає top-K найрелевантніших сторінок, і лише вони потрапляють до мультимодальної LLM. Типові ретривери — ColPali і DSE, типові готові системи — VisRAG, SV-RAG, VDocRAG і M3DocRAG. Камінь спотикання — K. Замале значення — і ключові докази губляться. Завелике — і додається шум.

Наскрізні мультимодальні моделі. Вони подають усі зображення сторінок просто в модель. Приклади — mPLUG-DocOwl2, Qwen2.5-VL і InternVL3. Величезна кількість візуальних токенів у довгому файлі дає погане співвідношення сигналу й шуму: ключові докази тонуть у масі нерелевантного вмісту, а це б'є і по швидкості, і по якості.

Є й проблема з даними. Більшість датасетів містять лише коротку підсумкову відповідь. Навчання на таких мітках заохочує крихкі обхідні шляхи й трюки під конкретний датасет і ніколи не вчить модель знаходити докази чи міркувати прозоро.

Триетапний підхід DocSeeker

Основна ідея проста: розбити роботу на три явні кроки. Спершу проаналізувати питання, потім знайти докази, а тоді міркувати на їхній основі. У результаті лишаються сліди на рівні сторінок, які людина справді може перевірити.

За основу взято Qwen2.5-VL-7B-Instruct без жодних додаткових модулів. Усі зусилля спрямовано на те, щоб навчити саму модель орієнтуватися в довгому документі й міркувати за ним.

Можливим це робить один прийом на вході. Перед обробкою візуальні токени кожної сторінки отримують текстовий ідентифікатор на кшталт «Page 1» — якір, що дає моделі змогу прив'язати міркування до конкретних сторінок.

Фреймворк називається ALR — Analysis, Localization і Reasoning:

1. Аналіз: модель переформульовує питання користувача й з'ясовує, що саме запитують.
2. Локалізація: вона називає сторінки, де містяться докази.
3. Міркування: вона робить висновки з цих доказів і видає і сторінки, і підсумкову відповідь.

Тож модель не стрибає одразу до відповіді. Її навчають видавати структурований слід ALR. Спрощений приклад із промпту для дистиляції виглядає так:

<think>
\boxed{Question Analysis}
The user asks for bracketed text in paragraph 2 on page 5 that is
also bolded.
\boxed{Evidence Localization}
Page 5 contains bracketed text but no bolded text.
\boxed{Reasoning Process}
No text meets all required conditions; therefore the question cannot
be answered.
</think>
<answer>
{"evidence_pages": [5], "answer": "Not answerable"}
</answer>

Навчання: спершу дистиляція, потім винагорода

Етап перший: навчання з учителем

Роль учителя виконувала Gemini-2.5-Flash. Вона бачила мінімальний контекст: еталонні сторінки з доказами, кілька сторінок-відволікачів, ідентифікатори сторінок і питання, — і на його основі генерувала сліди у форматі ALR. Учня ж донавчали на повному документі з усіма сторінками та їхніми ідентифікаторами. Якщо давати вчителеві менше, дистиляція виходить дешевшою й чистішою, а учень при цьому тренується на реалістичних вхідних даних.

Сліди фільтрували точним порівнянням відповідей і сторінок із доказами, а також семантичною перевіркою через GPT-4o. Лишилося 13 986 прикладів ALR: 8 676 з MP-DocVQA і ще 5 310 з DUDE.

Етап другий: EviGRPO

Звичайний GRPO здебільшого винагороджує за правильні відповіді. DocSeeker натомість використовує три винагороди: за формат, за докази й за відповідь, з вагами 0,1, 0,3 і 0,6.

• Винагорода за докази — це зважена F1 з beta = 2,0. Вона віддає перевагу повноті, тож пропуск сторінки з доказом коштує моделі дорожче, ніж зайва сторінка.
• Винагорода за відповідь використовує ANLS замість суворого точного збігу — це стандарт для document VQA, адже правильні відповіді можуть трохи відрізнятися оформленням.

Як EGRA знижує вартість візуальних токенів

Щоб навчання лишалося доступним, EGRA зберігає сторінки з доказами у високій роздільності й випадково зменшує 70% решти сторінок з ri = 1024 до ri = 256. Інші 30% зберігають повну роздільність. Це застосовується лише під час навчання. Під час інференсу кожна сторінка обробляється у високій роздільності, а в опублікованій оцінці використано 1024 на 784 на сторінку.

Результати

DocSeeker випереджає базову модель на всіх п'яти бенчмарках:

• DUDE: з 35,2 до 57,4 — найбільший приріст, 22,2 пункту.
• MPDocVQA: з 70,1 до 86,2.
• SlideVQA: з 59,8 до 77,1.
• LongDocURL: з 37,8 до 51,7.
• MMLongBench-doc: з 25,4 до 40,1.

У наведеному порівнянні це найсильніший відкритий метод, і він непогано тримається навіть проти закритих моделей. На двох бенчмарках зі своєї галузі він випереджає GPT-4o, хоча на MMLongBench-doc і LongDocURL усе ще йому поступається.

Що з цього випливає

Головний внесок роботи — перетворення розмитої задачі на набір підзадач із учителем: знайти потрібні сторінки, а тоді міркувати за ними. Видаючи структуровані думки, ідентифікатори сторінок і сторінки з доказами, модель навчається того, що можна назвати маршрутизацією уваги, і для промислового застосування це дуже привабливо.

Напрям виглядає правильним, але до широкого використання в продакшені лишається кілька питань:

• Наскільки надійна локалізація поза рівнем сторінок?
• Скільки коштує згенерувати дані ALR для інших галузей?
• Як контролювати додаткову затримку на міркування?
• Чи можна посилатися точніше, ніж на цілі сторінки?

Останнє питання найважливіше. Докази на рівні сторінок — добрий початок, але багатьом реальним впровадженням знадобляться цитати, клітинки таблиць чи ділянки зображень, щоб перевірка відповіді тривала секунди й лишала слід для аудиту.