Изображения и сканы в запросе: как это работает на практике

Модель умеет смотреть на картинку и отвечать на вопросы о ней: разобрать снимок экрана, вытащить данные из фотографии накладной, объяснить, что не так на схеме. Механика простая, но пара деталей определяет, получится осмысленный ответ или общие слова.

Как устроено сообщение

Содержимое одного сообщения — это список блоков. Блоки бывают разных типов, и текст с изображением спокойно соседствуют в одном сообщении.

Изображение передаётся закодированным вместе с указанием формата — так же через прямой доступ и через посредника вроде anthropic api в российском контуре. Отсюда первое практическое следствие: размер запроса растёт примерно на треть от размера файла, и картинка на несколько мегабайт превращается в весьма объёмный запрос. Уменьшать файл до отправки — не оптимизация, а необходимость.

Второе следствие — порядок блоков. Изображение логично ставить перед вопросом: сначала предмет разговора, потом задача. На коротких запросах разница невелика, на длинных — заметна.

Что разбирается хорошо, а что плохо

Закономерность простая и довольно точная: если человек не может прочитать надпись, не увеличивая картинку, модель тоже её не прочитает. Это правило избавляет от большинства разочарований.

Отдельная история — крупные изображения. Слишком большая картинка масштабируется перед обработкой, и мелкие детали при этом теряются. Отправить скан во всём разрешении в надежде, что «модель разглядит», — распространённая ошибка. Если нужен мелкий текст, надёжнее разрезать изображение на части и отправить фрагменты.

Многостраничные документы стоит обрабатывать постранично, а не одним куском. Так проще привязать ответ к источнику, дешевле повторить неудачный кусок и понятнее, где именно произошла ошибка.

Что спросить, чтобы получить пригодный ответ

Общий вопрос даёт общий ответ. «Что на картинке» — это описание, которое почти никогда не нужно.

Полезнее задавать конкретную задачу: перечислить позиции таблицы, назвать сумму и дату, сказать, какие поля не заполнены, найти расхождение между двумя столбцами. И сразу задать формат: список, набор полей, короткий ответ без пояснений.

Отдельно стоит попросить помечать неразличимое. Без такой просьбы модель заполнит непрочитанное поле правдоподобным значением, и отличить его от настоящего будет невозможно. Формулировка «если значение не читается, напиши «не разобрано» вместо предположения» стоит одной строки и снимает целый класс проблем.

Проверка — обязательный шаг

Распознанные значения нельзя принимать на веру, особенно суммы, даты и номера. Это не недоверие к модели, а обычная практика работы с любым распознаванием.

Что помогает:

• Проверка формата на своей стороне: дата разбирается как дата, сумма — как число.
• Сверка контрольных соотношений: сумма позиций совпадает с итогом.
• Повторный прогон сомнительных документов с другим кадрированием.
• Ручная проверка выборки при массовой обработке — полсотни документов из партии.

Где картинка выигрывает у распознавания текстом

Классическая схема обработки документов — сначала распознать текст отдельной программой, потом отдать его модели. Она дешевле и остаётся разумной для чистых текстовых страниц.

Но там, где смысл несёт расположение, распознавание теряет главное. Таблица со сложной шапкой, форма с галочками, схема со стрелками, чек с колонками — после превращения в плоский текст всё это становится набором слов в непонятном порядке. Модель, которая смотрит на изображение, видит структуру и отвечает точнее.

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

Подготовка файла

Несколько операций перед отправкой заметно повышают долю удачных разборов и снижают расход.

Обрезка. Если нужна таблица в нижней половине документа, отправлять весь лист незачем. Меньше площади — выше эффективное разрешение того, что важно.

Выравнивание. Фотография под углом разбирается хуже ровного скана. Простое выпрямление по краям документа даёт больше, чем смена модели.

Контраст. Бледный чек или выцветшая печать читаются лучше после повышения контраста. Обрабатывать стоит осторожно: пережатый контраст съедает тонкие линии.

Формат и размер. Скриншот интерфейса лучше сохранять без потерь — сжатие размывает мелкий шрифт. Фотографию, наоборот, разумно сжать: разница в качестве разбора невелика, а объём запроса падает в разы.

Несколько изображений в одном запросе

Формат допускает несколько картинок в сообщении, и это удобно для сравнения: две версии макета, до и после, лицевая и оборотная сторона документа.

Но у приёма есть цена и предел. Каждое изображение добавляет к запросу свой объём, и четыре снимка экрана легко превращаются в запрос, сопоставимый по стоимости с большим текстом.

Полезная привычка — нумеровать изображения текстом между ними: «Снимок 1», «Снимок 2». Без этого в ответе будет «на первой картинке», и что считать первой, придётся угадывать.

Когда изображений действительно много, надёжнее обрабатывать их по одному и сводить результаты кодом. Это дороже по числу обращений, но каждый разбор получается точнее, а ошибка не портит всю партию.

Про персональные данные

Фотография паспорта, медицинская справка, договор с реквизитами — во всех этих случаях вы отправляете во внешний сервис чувствительные сведения. Решение о том, допустимо ли это, принимается до написания кода, а не после.

Практический минимум: закрывать поля, которые не нужны для задачи, не хранить исходники дольше необходимого и заранее выяснить у поставщика доступа, сохраняются ли переданные файлы и на какой срок. Ответ на этот вопрос лучше получить письменно.

Коротко

Картинка и вопрос — это два блока одного сообщения, и порядок между ними имеет значение. Уменьшайте файл до отправки, режьте крупные сканы на части и обрабатывайте многостраничные документы постранично. Спрашивайте конкретное, задавайте формат ответа и просите помечать нечитаемое. Распознанные суммы и даты проверяйте на своей стороне, а с чувствительными документами решайте вопрос допустимости до, а не после.