Gemini 2.5 Pro: стоит ли переходить для мультимодальных задач?
«Понимает изображения» — формулировка, за которой прячется десяток разных умений. Описать фотографию, прочитать таблицу со скана, разобрать схему, найти нужный фрагмент на скриншоте интерфейса, посчитать объекты, прочитать рукописный текст — всё это отдельные задачи с очень разным качеством у одной и той же модели. Решение о переходе принимается не по общим заявлениям, а по проверке своего сценария.
Разложите задачу на элементы
| Что нужно | Что реально проверять |
|---|---|
| Разбор документов | Таблицы со слиянием ячеек, многоколоночная вёрстка, печати и подписи |
| Скриншоты интерфейса | Мелкий текст, точность координат элементов, состояния кнопок |
| Схемы и чертежи | Направление стрелок, подписи мелким шрифтом, вложенность блоков |
| Фотографии | Плохое освещение, наклон, частичное перекрытие |
| Видео | Что именно анализируется: кадры, звук, речь, и с какой частотой |
| Подсчёт | Число объектов больше десяти — здесь ошибаются почти все |
Тест на двадцати примерах
Возьмите двадцать реальных файлов из вашего потока, включая заведомо плохие: смазанные, перевёрнутые, с посторонними элементами. Прогоните и считайте не «понравилось — не понравилось», а конкретное:
- Точность извлечения. Сколько полей из документа извлечены верно, сколько с ошибкой, сколько пропущено.
- Тихие ошибки. Самое опасное: модель выдаёт число, которого в документе нет, вместо того чтобы сказать, что не разобрала. Считайте такие случаи отдельно — именно они определяют, можно ли встраивать это в процесс без ручной проверки.
- Поведение на плохом входе. Перевёрнутая страница: скажет об этом или уверенно прочитает что-то не то?
- Повторяемость. Один и тот же файл трижды — одинаков ли результат.
Промт, который снижает тихие ошибки
Извлеки из изображения следующие поля: [список]. Правила: - Для каждого поля укажи уверенность: точно вижу / вижу частично / не могу разобрать. - Если поле не читается — пиши «не разобрано», не подставляй правдоподобное значение. - Приведи, в какой части изображения находится каждое поле. - Не вычисляй и не суммируй ничего, чего нет прямо в документе. - Если изображение перевёрнуто, повёрнуто или обрезано — скажи об этом первым делом.
Требование указывать уверенность и место — простой приём, который заметно уменьшает долю выдуманного и позволяет отправлять на ручную проверку только неуверенные поля.
Когда переход оправдан
- Ваш сценарий сейчас требует ручной работы, и модель закрывает его хотя бы на 80% с явной пометкой остального.
- Формат входа однотипный. Однотипные документы дают предсказуемое качество; произвольные фотографии — нет.
- Цена ошибки терпима или ошибка ловится проверкой на следующем шаге.
- Есть куда деть неуверенные случаи. Процесс, где нераспознанное уходит человеку, работает; процесс без такой ветки — нет.
Когда не стоит
Если решение принимается по извлечённым данным без проверки человеком и цена ошибки высока — финансовые документы, медицинские данные, юридические сроки. Здесь разница между 95% и 99% точности принципиальна, а обе цифры выглядят одинаково хорошо в презентации.
Как считать выгоду
Посчитайте на своих числах: - сколько минут занимает ручная обработка одного документа; - сколько документов в месяц; - какая доля уйдёт на ручную проверку после внедрения (по результатам теста); - стоимость запросов на этот объём; - время на исправление ошибок, которые пройдут дальше. Выгода = сэкономленные часы минус проверка минус исправления минус стоимость запросов.
Часто выясняется, что выгода есть, но втрое меньше ожидаемой — из-за той самой ручной проверки, которую при планировании не учли.
Номера версий и цены здесь намеренно не названы: они меняются каждые несколько месяцев. Сверяйтесь с документацией провайдера, а тест на своих двадцати файлах проводите заново после каждого обновления модели — качество на конкретных задачах меняется и в лучшую, и в худшую сторону.