Gemini для документов: как проверять PDF и длинный контекст
Как испытывать Gemini на договорах, отчётах и сканах: выбор входного формата, проверка таблиц и ссылок на страницы, цена контекста и ручная сверка.
Gemini может быть кандидатом для анализа PDF, в том числе страниц с визуальными элементами. Перед рабочим применением проверьте извлечение таблиц, примечаний и противоречий на собственных файлах; длинный контекст не превращает ответ в доказательство.
PDF бывает текстом, сканом и смесью
Сначала откройте несколько реальных по структуре файлов. В одном текст можно выделить мышью, в другом каждая страница: картинка, в третьем таблица собрана из ячеек и сносок. Официальная документация Gemini API описывает работу с PDF и визуальными элементами, но способ передачи и ограничения зависят от API и модели. Не подменяйте испытание каждого типа одним чистым PDF.
Синтетический тест можно собрать из двух страниц: на первой указаны товар и количество, на второй: скидка в таблице и примечание о доставке. Ожидаемое извлечение запишите заранее. Если модель прочла текст, но пропустила сноску, задача не выполнена. Отдельно проверьте повёрнутый скан и документ с плохим контрастом: именно они чаще обнаруживают слабые места процесса.
Узкий вопрос лучше просьбы пересказать всё
Запрос «проанализируй договор» заставляет модель решать за вас, что важно. Сформулируйте проверяемые поля: срок, сумма, условия расторжения и пункты без однозначного толкования. Для каждого поля требуйте фрагмент и страницу. Если сведения отсутствуют, ответ должен оставить значение пустым. Так результат можно сопоставить с исходником, а не читать как самостоятельное мнение.
Два поля могут относиться к разным редакциям договора. Попросите явно указать номер приложения или дату редакции, если они есть во входе. В тесте поместите старый тариф в приложении и новый в основной части. Цель: увидеть, замечает ли модель конфликт. Если нет, автоматическое заполнение карточки документа пока преждевременно.
Большое окно — ресурс с ценой
Gemini API описывает модели с длинным контекстом, пригодным для больших документов. Это не значит, что стоит отправлять весь архив при каждом вопросе. Повторная передача одинаковых страниц расходует токены и время. Для серии запросов исследуйте доступные механизмы хранения или кэширования у выбранного поставщика, а для агрегированного маршрута отдельно проверьте, какие из них доступны по его контракту.
Длинный вход не гарантирует одинакового качества поиска нескольких фактов. Сделайте тест с несколькими похожими пунктами на разных страницах и спросите о каждом. Если ошибки растут, попробуйте заранее выделить релевантные страницы и показать модели меньший набор. Изменение стратегии подачи часто полезнее увеличения лимита ответа.
Проверяйте числа вне модели
Пусть ответ содержит структурированные поля, но не позволяйте ему быть единственным валидатором. Если документ говорит «три коробки по 350 рублей», приложение должно само проверить арифметику результата. Если модель извлекла сумму, которой нет в исходнике, фиксируйте ошибку и отправляйте на просмотр. Не исправляйте её незаметно по соседнему полю: это скроет дефект источника или распознавания.
Единицы измерения в таблицах
Для таблиц важны заголовки строк и единицы измерения. Сумма в тысячах рублей и сумма в рублях могут выглядеть одинаково после удаления колонки с единицей. В тестах держите эти случаи рядом. Показывайте оператору исходный фрагмент страницы и извлечённое значение, чтобы у него был шанс заметить неверную привязку.
Ссылка на страницу должна вести к нужному месту
Попросите указать значение, номер страницы, название раздела и короткий фрагмент. Затем откройте PDF и проверьте, действительно ли эти признаки относятся к одному месту. Модель может назвать правильную сумму из приложения, но приписать её основной части договора. Для человека это выглядит убедительно, пока он не откроет файл. Проверка привязки нужна отдельно от проверки числа.
Если PDF обновляется, храните версию файла вместе с извлечением. Ссылка на страницу в новой редакции может указывать уже на другой абзац. В рабочем интерфейсе оператор должен видеть именно ту копию, по которой модель готовила ответ. Без этого даже корректное извлечение трудно подтвердить через неделю после загрузки.
Документ ещё надо иметь право отправить
Перед загрузкой PDF проверьте, какие сведения в нём есть и куда их разрешено передавать. Договоры, анкеты и медицинские формы могут содержать персональные данные. Удаление имён в одном месте не обезличивает файл, если они остались в колонтитуле или приложении. Для разработки используйте синтетические образцы с теми же структурными трудностями.
Сохранение файла на стороне приложения тоже требует решения: срок хранения, доступ сотрудников, журнал действий и удаление результатов. Не пишите ключ API в браузерный код и не прикладывайте документ к отладочному логу. Возможность модели прочитать PDF не отвечает на эти вопросы за команду.
Прежде чем подключать через Kvantora
Откройте /models и проверьте доступный API ID, операции и поддержку нужного типа входа. Публичная документация Gemini описывает возможности прямого API Google; она не доказывает, что каждый формат проходит через конкретный агрегатор. Начните с разрешённого теста без клиентских данных и сравните ответ с эталоном. Если PDF-вход не подтверждён текущим контрактом, не проектируйте вокруг него рабочий процесс.
В результате испытания сохраните тип документа, сложные страницы, версию маршрута и классы ошибок. При новой модели перепроверяйте именно слабые места: сноски, повторяющиеся суммы и отсутствующие поля. Хорошее резюме двадцати страниц приятно читать. Надёжный рабочий процесс начинается там, где можно объяснить каждое извлечённое значение.