busya/BlackboxBook
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
d67af9836341e5250591cbdf4095d7a3958fd8c6
BlackboxBook/book/18_multimodal_systems.md
busya d67af98363 init
2026-05-20 20:55:03 +03:00

43 KiB
Raw Blame History

ГЛАВА 18. МУЛЬТИМОДАЛЬНЫЕ СИСТЕМЫ: ТЕКСТ, ИЗОБРАЖЕНИЯ, ДОКУМЕНТЫ, ГОЛОС

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

Мультимодальные модели «расширили» каналы восприятия. Claude Opus 4.6, GPT-5.4, Gemini 3 — все они принимают изображения, аудио, иногда видео. Но «видеть» и «видеть хорошо» — разные вещи. Визуальные токены стоят в разы дороже текстовых. Пространственное мышление моделей ненадёжно. Мультимодальный вход открывает новые поверхности атаки (инъекции через изображения). А выбор между OCR и LLM vision, между speech-to-speech и цепочкой STT→LLM→TTS — это инженерные решения с измеримыми последствиями для стоимости, латенси и качества.

В Главе 1, раздел 1.5 мы разобрали механику: как изображения превращаются в токены через ViT-патчи, как аудио квантуется в дискретные единицы. В Главе 3, раздел 3.4 затронули мультимодальные галлюцинации. Эта глава — инженерная: как строить production-системы, которые обрабатывают визуальный, текстовый и аудио-вход вместе.

18.1. Токенизация изображений: правила и стоимость

Механизм: от пикселей к токенам

Напомним суть из Главы 1: визуальный энкодер (как правило, Vision Transformer, ViT) разбивает изображение на прямоугольные патчи, каждый патч проецируется в embedding-пространство модели. Конкретная формула зависит от провайдера — и разница существенна.

Правила по провайдерам

Провайдер Модель Правило токенизации Макс. изображений Примечания
OpenAI GPT-5.4 Patch-based: патчи 32×32 px. До 10 000 патчей (original), ≤2 500 (high), 256 патчей (low, 512×512 px) — Уровень "detail": "original" для задач локализации
Anthropic Claude Opus 4.6 После автомасштабирования до 1568 px по длинной стороне считает примерно один токен на 750 пикселей 600 (API), 20 (UI) 1 MP ≈ 1 334 токена
Google Gemini 3 258 токенов если ≤384 px; иначе тайлы 768×768, каждый = 258 токенов 3 600 Поддержка HEIC/HEIF. Параметр media_resolution

Практический расчёт стоимости

Возьмём Anthropic Claude Opus 4.6 ($5/M input tokens, по данным anthropic.com/pricing). Практическое правило простое: после автомасштабирования длинной стороны до 1568 px модель считает примерно один токен на 750 пикселей.

4K скриншот (3840 × 2160): масштабируется до 1568 × 882 → 1 843 токена. Стоимость: 1 843 × $5/1M ≈ $0.0092.

Предварительно ресайзнутое изображение (1024 × 768): 1024 × 768 / 750 ≈ 1 049 токенов. Стоимость: 1 049 × $5/1M ≈ $0.0052.

Экономия: ~43% токенов при предварительном ресайзе.

AI-промпт для генерации калькулятора: «Напиши Python-функцию estimate_image_tokens_anthropic(width, height), которая вычисляет количество визуальных токенов для Anthropic Claude: автомасштабирование длинной стороны до 1568 px, затем оценка по правилу “примерно один токен на 750 пикселей”. Покажи примеры для 4K (3840×2160) и ресайзнутого (1024×768) изображений.»

Ключевой вывод: предварительный ресайз изображений — самая простая оптимизация стоимости. 4K-скриншот, ресайзнутый до 1024 px по длинной стороне, теряет минимум качества для большинства задач, но экономит 40–60% токенов.

Стоимость аудио

Gemini 3 токенизирует аудио примерно как 32 токена в секунду.

1 минута = 1 920 токенов. Максимум — 9.5 часов аудио в одном запросе. При $1.00/M audio input tokens (Gemini 3 Flash Preview): 1 час аудио ≈ 115 200 токенов ≈ $0.115.

18.2. Vision-language промпты: паттерны и приёмы

Визуальные модели принимают изображения, но качество ответа критически зависит от того, как вы структурируете запрос. Три ключевых паттерна.

Паттерн 1: Image-first ordering

Anthropic рекомендует размещать изображения перед текстом в сообщении. Это работает у всех провайдеров: модель «видит» изображение, формирует визуальные представления, а затем читает инструкции — attention-веса к визуальным токенам оказываются сильнее.

Схема сообщения: сначала блок image (с base64 или URL), затем блок text с инструкцией. Это единый паттерн для OpenAI, Anthropic и Google.

AI-промпт для генерации кода: «Покажи пример вызова Anthropic Messages API с изображением в base64: сначала блок image (тип base64, media_type image/png), затем блок text с задачей «Извлеки все позиции из счёта в формате JSON». Используй anthropic Python SDK, модель claude-opus-4-6.»

Паттерн 2: Управление уровнем детализации

OpenAI предоставляет три уровня детализации:

Уровень Токены Когда использовать
low 256 патчей (512×512 px, patch-based) Классификация, общее описание. «Это фото кота или собаки?»
high До 2 500 (патчи, сжатое представление) Анализ, чтение текста на изображении
original До 10 000 (патчи 32×32, макс. 6000 px) Локализация объектов, детальная диагностика

Практическое правило: начинайте с low. Если качество недостаточно — переходите на high. original — только для задач, где нужна точная пространственная привязка.

Паттерн 3: Координатный grounding (bounding boxes)

Gemini нативно поддерживает задачи object detection. Модель возвращает координаты в формате [ymin, xmin, ymax, xmax], нормализованные к диапазону 0–1000. Промпт для grounding: «Найди все таблицы на этой странице. Верни bounding boxes в формате [ymin, xmin, ymax, xmax], нормализованные к 0–1000».

AI-промпт для генерации кода: «Напиши Python-скрипт, который отправляет изображение в Gemini 3 Flash через google-genai SDK и просит вернуть bounding boxes всех таблиц в формате [ymin, xmin, ymax, xmax], нормализованных к 0–1000. Используй модель gemini-3-flash-preview.»

Координатный grounding полезен для:

  • понимания структуры документа (где таблица, где заголовок, где подпись);
  • visual QA с привязкой к регионам изображения;
  • автоматической нарезки страницы на зоны для дальнейшего OCR.

Антипаттерны

Что делают Почему это проблема Что делать вместо
Спрашивают о мелких деталях в режиме low Модель буквально не видит их — 256 патчей на всё изображение Использовать high или original
Отправляют полноразмерный скриншот для извлечения текста Перерасход токенов в 3–5× Ресайз + кроп до области с текстом
Просят модель точно посчитать объекты Модели плохо считают — это известное ограничение Использовать grounding + подсчёт bounding boxes программно
Отправляют множество изображений без указания порядка Модель не знает, в каком порядке их анализировать Нумеровать: «Image 1: …, Image 2: …»

18.3. OCR и обработка документов

Два уровня: понимание vs точность

Визуальные LLM и специализированный OCR решают разные задачи:

  • LLM vision — понимает документ: видит layout, связывает таблицу с контекстом, извлекает смысл из формы целиком. Но может «додумать» текст, который плохо виден.
  • Специализированный OCR — читает документ: детерминированный вывод, пиксельная точность, обработка плотных таблиц, рукописного текста, нестандартных шрифтов. Но не понимает контекст.

Когда что использовать

Сценарий Подход Почему
General document QA LLM vision Понимает layout + содержание в контексте
Массовое извлечение структурированных данных OCR + LLM Детерминированный OCR + LLM для нормализации
Регуляторный / аудит Специализированный OCR Нужен детерминированный, воспроизводимый вывод
Рукописный текст, исторические документы Специализированный OCR LLM vision ненадёжен на нестандартных шрифтах
Визуально сложные формы (чертежи, схемы) LLM vision + OCR LLM для layout, OCR для точного текста

Инструменты

  • Google Document AI — интеграция с Gemini, поддержка 200+ языков, специализированные процессоры для invoices, receipts, identity documents.
  • Azure Document Intelligence — layout analysis, prebuilt модели для типовых форм, custom extraction.
  • DocTR (open-source) — end-to-end OCR: detection + recognition. Python, PyTorch / TensorFlow. GitHub: mindee/doctr.

Pipeline: PDF → структурированный JSON

Типичный production-пайплайн для обработки документов:

PDF → Рендеринг страниц (PNG, 150 DPI)
    → Отправка в LLM vision (image-first, base64)
    → Structured output (JSON с валидацией схемой)

AI-промпт для генерации кода: «Напиши Python-функцию extract_invoice_data(pdf_path), которая: (1) открывает PDF через PyMuPDF (fitz), (2) рендерит каждую страницу в PNG при 150 DPI, (3) отправляет base64-изображение в Anthropic Messages API (модель claude-opus-4-6) с инструкцией извлечь позиции счёта в JSON (поля: description, quantity, unit_price, total; null для неразборчивых значений). Используй паттерн image-first. Добавь валидацию JSON-ответа через pydantic.»

Ключевые решения в этом пайплайне:

  • DPI при рендеринге: 150 DPI — разумный баланс. 72 DPI теряет мелкий текст, 300 DPI — перерасход токенов.
  • Инструкция о null: явно скажите модели, что делать, когда текст неразборчив — иначе она будет галлюцинировать.
  • Постобработка: JSON-ответ нужно валидировать схемой. LLM может вернуть дополнительные поля или пропустить обязательные.

18.4. Multimodal RAG: ColPali и визуальный retrieval

Проблема: OCR теряет визуальную структуру

Классический RAG для документов работает так: PDF → OCR → текстовые чанки → embedding → vector DB → retrieval → LLM. Проблема в первом шаге: OCR теряет layout. Таблица превращается в поток текста, где столбцы перемешаны. Диаграмма исчезает. Подпись под графиком отрывается от графика. Информация заключена не только в тексте, но и в визуальном расположении — а OCR-based RAG это расположение уничтожает.

ColPali: retrieval по скриншотам страниц

ColPali (Faysse et al., 2024) предлагает радикально другой подход: пропустить OCR полностью. Вместо этого:

  1. Рендерим каждую страницу документа как изображение.
  2. Подаём изображение в vision-language модель (VLM), которая генерирует мультивекторные embeddings — по одному вектору на каждый патч изображения.
  3. При поиске: текстовый запрос также превращается в набор векторов.
  4. Сопоставление — late interaction в стиле ColBERT: каждый вектор запроса ищет максимально похожий вектор в документе, затем скоры суммируются.
Классический RAG:  PDF → OCR → Чанки → Embed → Vector DB → Retrieve → LLM
ColPali:           PDF → Скриншот → Embed (VLM) → Vector DB → Retrieve → LLM (с изображением)

Почему это работает

Мультивекторное представление страницы сохраняет пространственную информацию. Вектор, соответствующий патчу с таблицей, будет близок к запросу «выручка за Q3». Вектор патча с графиком — к запросу «динамика продаж». При этом не нужен OCR, не теряется layout, не разрываются связи между элементами страницы.

Бенчмарк: ViDoRe

ViDoRe (Visual Document Retrieval) — бенчмарк для оценки визуального retrieval. По данным ViDoRe leaderboard (апрель 2026), лидирующие модели на базе ColQwen3.5 достигают ~90+ NDCG@5.

Оптимизация хранения: мультивекторные embeddings занимают больше места, чем одновекторные. Token pooling (иерархический mean pooling с pool factor 3) сокращает количество векторов на 66.7%, сохраняя 97.8% NDCG. Это делает ColPali практичным для коллекций в десятки тысяч страниц.

Когда использовать ColPali, а когда классический RAG

Критерий ColPali Классический RAG (OCR + text embed)
Документы с таблицами, диаграммами Layout сохранён OCR разрушает структуру
Чисто текстовые документы Избыточен Проще и дешевле
Скорость индексации Медленнее (VLM inference) Быстрее (OCR + text embed)
Размер индекса Больше (мультивекторный) Меньше (одновекторный)
Финансовые отчёты, слайды, чертежи Основной сценарий Потеря визуальной информации

18.5. Audio и speech: два контура

Голосовой интерфейс к LLM — это не просто STT + LLM + TTS. Существуют две принципиально разные архитектуры, и выбор между ними определяет латенси, контроль, стоимость и возможности отладки.

Контур 1: Speech-to-speech (Realtime API)

OpenAI Realtime API (General Availability) позволяет вести двусторонний голосовой диалог с моделью. Модель принимает аудио напрямую и генерирует аудио-ответ — без промежуточного текста.

Транспорт:

  • WebRTC — для браузерных приложений (p2p, низкая латенси);
  • WebSocket — для серверных приложений;
  • SIP — для интеграции с VoIP-телефонией (PSTN).

Возможности:

  • Function calling и MCP-серверы — модель может вызывать инструменты прямо в середине разговора;
  • Прерывание (interruption) — пользователь может прервать модель, она остановится и ответит на новый вопрос;
  • Несколько голосов на выбор.

Ограничения:

  • Ограниченный контроль над промежуточным текстом — нельзя «подкрутить» транскрипцию до того, как модель её обработает.
  • Сложнее логировать и модерировать: контент проходит через аудиоканал, а не через текст.
  • Стоимость: аудио-токены дороже текстовых.

Контур 2: Цепочка STT → LLM → TTS

Альтернатива — последовательная обработка: сначала транскрибируем аудио в текст, затем передаём текст в LLM, затем синтезируем ответ.

Компоненты (OpenAI):

  • STT: gpt-4o-transcribe (высокое качество), gpt-4o-mini-transcribe (дешевле), gpt-4o-transcribe-diarize (с метками спикеров).
  • TTS: gpt-4o-mini-tts — управляемый синтез речи.

Примечание: модели STT/TTS у OpenAI остаются в линейке gpt-4o-*, а не в семействе GPT-5.x. Speech-модели развиваются отдельно от text-флагманов.

Компоненты (Google):

  • STT: Cloud Speech-to-Text или Gemini Live API.
  • TTS: Cloud Text-to-Speech или Gemini.

Преимущества:

  • Полный контроль над текстом на каждом этапе — можно логировать, модерировать, трансформировать.
  • Промежуточный текст доступен для structured outputs, tool use, RAG.
  • Проще дебажить: каждый этап можно проверить отдельно.

Недостаток: латенси. Три последовательных вызова: STT (200–500 мс) + LLM (500–2000 мс) + TTS (200–500 мс) = 1–3 секунды суммарно. Для телефонного разговора это ощутимо; для асинхронной обработки — приемлемо.

Выбор контура

Критерий Speech-to-speech STT → LLM → TTS
Латенси ~300–800 мс ~1–3 с
Контроль над текстом Ограничен Полный
Логирование и аудит Сложнее Просто
Tool use Поддерживается Поддерживается
Модерация контента Через аудио-канал На этапе текста
Интеграция с RAG Ограничена Полная
Сценарий Голосовой ассистент, call-центр Обработка записей, QA-бот с голосом

Оценка стоимости аудио

Gemini токенизирует аудио на уровне модели: 32 токена/секунду. Перед токенизацией аудио даунсэмплируется до 16 kbps mono.

Пример расчёта: 5-минутный звонок = 300 с × 32 = 9 600 токенов. При $1.00/M audio input (Gemini 3 Flash Preview): $0.0096.

Live voice agents: from demo to production

В 2025–2026 live voice agents перешли из демо в production. OpenAI Realtime API (GA) и Gemini Live API — уже не эксперимент, а production-surface с SLA и поддержкой tool use.

Ключевое различие: voice agent — это не speech-to-speech обёртка, а агент, работающий в голосовом цикле. Он вызывает tool'ы, принимает решения, управляет workflow — всё в реальном времени, пока пользователь ждёт на линии. Архитектурно это тот же agent loop из Главы 10, но с жёстким latency budget: ~500 мс на ответ для естественного диалога. Tool call внутри voice loop должен укладываться в этот бюджет. Если tool медленный — нужны filler phrases («Секунду, проверяю…»), partial responses или async execution с callback.

Следствие для проектирования tool'ов: все инструменты, вызываемые из voice loop, должны иметь p95 latency < 300 мс (оставляя ~200 мс на сетевой overhead и генерацию). Медленные операции (RAG-запрос, обращение к внешнему API) требуют отдельного паттерна: модель произносит filler, запускает tool асинхронно и возвращается к ответу после получения результата.

Transport и session management

Три транспортных протокола для live voice определяют архитектурные ограничения:

Протокол Латенция Deployment Типичный сценарий
WebRTC Минимальная (p2p) Браузер Web-приложения, клиентский ассистент
WebSocket Низкая (через сервер) Backend Серверный voice bot, кастомная логика
SIP Средняя (телефонная сеть) PSTN / VoIP Call-центр, IVR-замена

Session state в голосовом цикле сложнее текстового: сессия — это долгоживущее соединение (минуты → часы). Четыре аспекта, которые необходимо контролировать:

  1. Turn-taking — определение, кто сейчас говорит, и передача «слова» между пользователем и моделью.
  2. Barge-in (interruption) — пользователь перебивает модель до завершения ответа. Правильное поведение: модель останавливает генерацию, отбрасывает незавершённый аудио-ответ, переключается на слушание. В Realtime API barge-in реализован на уровне протокола; в цепочке STT → LLM → TTS управлять им сложнее — нужен cancel pipeline, который прерывает TTS и сбрасывает буфер.
  3. Silence detection — определение момента, когда пользователь закончил говорить, без преждевременного cut-off.
  4. Session timeout — завершение сессии при продолжительном молчании, с корректным сохранением состояния.

Наблюдаемость voice workflows

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

  • Запись аудио каждой сессии — для post-mortem и compliance.
  • Transcript каждого turn — даже для speech-to-speech режима нужен параллельный STT для логирования. Без transcript нет ни поиска по сессиям, ни модерации.
  • Trace с timeline — кто говорил когда, какие tool calls были, сколько длилась каждая фаза (STT, LLM inference, TTS, network).
  • Latency breakdown по turn — STT latency, LLM latency, TTS latency, network latency отдельно. Без этого невозможно понять, где «тормозит».

Ключевые метрики voice agent: response latency p50/p95, interruption rate (высокий показатель = пользователь не дожидается ответа), successful task completion rate, user hang-up rate (индикатор плохого UX). Интеграция с OpenTelemetry (см. Главу 17): voice span → tool call span → LLM span — единый trace от входного аудио до ответа.

18.6. Мультимодальные галлюцинации

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

Четыре типа визуальных галлюцинаций

1. Галлюцинация объектов. Модель «видит» объекты, которых нет на изображении. Бенчмарк POPE (Polling-based Object Probing Evaluation) (Li et al., 2023) измеряет это систематически: модели задают вопросы вида «Есть ли на изображении X?» и проверяют, не соглашается ли она, когда X отсутствует. Даже фронтирные модели допускают ненулевой процент ложноположительных ответов — проблема не решена полностью.

2. Ошибки пространственного мышления. «Кот слева от собаки» — когда он справа. «Третья строка таблицы содержит…» — когда это четвёртая строка. Пространственные отношения — одна из самых слабых сторон vision-language моделей: attention-механизм агрегирует патчи, но может терять точную позиционную привязку.

3. Ошибки подсчёта. Все три фронтирных провайдера (OpenAI, Anthropic, Google) явно указывают в документации: модели оценивают количество объектов, а не считают их. «Примерно 7–8 человек» — это потолок точности для типичной сцены. Детерминированный подсчёт требует object detection + программный count.

4. Ошибки OCR в визуальном режиме. Мелкий текст, повёрнутый текст, нестандартные шрифты, не-латинские скрипты — всё это зоны риска. Модель может «прочитать» слово, которое визуально похоже на правильное, но отличается на один-два символа.

Антигаллюцинационные паттерны для мультимодальных систем

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

  • Шаг 1 (локализация): «Есть ли на изображении штрих-код? Если да — укажи bounding box [ymin, xmin, ymax, xmax].»
  • Шаг 2 (извлечение): Если bbox получен — «Прочитай штрих-код в области [ymin, xmin, ymax, xmax]. Верни числовое значение.»

Перекрёстная проверка несколькими изображениями. Для критичных задач (медицина, финансы) — отправьте то же содержимое в разных ракурсах или масштабах. Если ответы расходятся — доверие падает.

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

Явная инструкция об неопределённости. Добавьте в prompt: «Если текст неразборчив или объект не виден чётко, укажи это явно, а не угадывай». Без такой инструкции модель будет догадываться — и звучать уверенно.

18.7. Стоимость и латентность мультимодальных систем

Сравнительная таблица модальностей

Модальность Токенов на единицу Типичная стоимость (input) Влияние на латенси
Текст ~0.75 токенов/слово $1–15/M токенов Baseline
Изображение (1 MP) ~1 300–1 600 токенов $4–24 за 1K изображений +0.5–2 с на изображение
Аудио (1 мин) ~1 920 токенов (Gemini) Варьируется +2–5 с на STT
Видео (1 мин, 1 FPS) ~15K–25K токенов Высокая +5–15 с

Стратегии оптимизации

1. Предварительный ресайз. Самый простой и эффективный способ — ресайзить изображения до минимально необходимого разрешения ДО отправки в API. 4K → 1024 px = экономия 40–60% токенов.

2. Управление уровнем детализации. Для классификации («это чек или не чек?») — low (256 патчей). Для анализа — high. Не используйте original по умолчанию.

3. Кэширование визуальных embeddings. Если один и тот же документ обрабатывается повторно (например, RAG-индекс) — кэшируйте embeddings, а не перевычисляйте при каждом запросе.

4. Батчинг изображений. Все провайдеры поддерживают несколько изображений в одном запросе. Один запрос с 5 изображениями дешевле по overhead, чем 5 отдельных запросов.

5. ColPali для retrieval. Для поисковых задач используйте ColPali — один проход для индексации. Не пересчитывайте визуальные токены при каждом запросе.

6. Edge-модели для latency- и privacy-sensitive задач. Для мультимодальной обработки с минимальной латенси или без передачи данных в облако существуют on-device модели (Gemma 4 E2B/E4B) — подробнее в Главе 24, §24.4.

Пример расчёта бюджета

Сценарий: обработка 10 000 страниц финансовых отчётов в месяц (Claude Opus 4.6, $5/M input tokens).

Без оптимизации (4K сканы):
  10,000 страниц × 1,843 токена = 18.4M токенов = $92/мес

С ресайзом до 1024 px:
  10,000 страниц × 1,049 токенов = 10.5M токенов = $52.5/мес

С ColPali (retrieval, не нужно отправлять все страницы):
  Retrieval: 10,000 × индексация (одноразово)
  LLM calls: top-5 страниц × 1,049 = 5,245 токенов на запрос
  1,000 запросов/мес × 5,245 = 5.2M токенов = $26/мес

Практический вывод

Мультимодальные системы добавляют к LLM-инженерии три новых измерения: визуальные токены (дорогие), пространственное мышление (ненадёжное) и аудиоканал (с выбором архитектуры). Чек-лист для production-системы:

  1. Ресайз перед отправкой. Минимальное разрешение, при котором задача решается. Не отправляйте 4K, если хватает 1024 px.

  2. Выбирайте уровень детализации. low для классификации, high для анализа, original для локализации. По умолчанию — не original.

  3. OCR vs LLM vision — не "или", а "когда". LLM для понимания; специализированный OCR для точности, воспроизводимости и регуляторных требований. Для сложных документов — оба.

  4. ColPali для визуально-насыщенных документов. Если ваши документы полны таблиц, диаграмм и схем — ColPali сохраняет layout при retrieval. Для чисто текстовых — классический RAG дешевле.

  5. Speech: два контура — два сценария. Realtime API для разговорных агентов, где латенси критична. STT → LLM → TTS для пайплайнов, где нужны логирование, модерация, structured outputs.

  6. Ожидайте визуальные галлюцинации — и проектируйте защиту. Bounding box верификация, перекрёстная проверка, гибридные пайплайны, явная инструкция об неуверенности.

  7. Считайте стоимость мультимодальных вызовов отдельно. Токены изображений в 5–10× дороже токенов текста в пересчёте на единицу извлечённой информации. Мониторьте визуальные токены как отдельную cost-линию.

Задания

  1. Сравнение OCR vs LLM vision. Возьмите 10 разнородных PDF-документов (счета, таблицы, формы): обработайте каждый (a) специализированным OCR (DocTR или Document AI) и (b) LLM vision (Gemini 3 или Claude Opus 4.6). Сравните по метрикам: точность извлечения текста (Character Error Rate), сохранение структуры таблиц, стоимость на страницу, латенси. Ожидаемый результат: таблица сравнения для принятия решения о выборе подхода для вашего типа документов.

  2. Оптимизация стоимости визуальных токенов. Возьмите реальный пайплайн с изображениями и проведите A/B-тест: (А) оригинальные изображения vs (Б) ресайз до 1024 px по длинной стороне. Измерьте: количество токенов, стоимость, качество ответов (ручная оценка на 20 примерах). Ожидаемый результат: понимание порога ресайза, при котором качество не деградирует для вашей задачи.

  3. Проверка визуальных галлюцинаций. Соберите 10 изображений с известным содержимым. Отправьте в модель вопросы в стиле POPE: «Есть ли на изображении X?» (где X заведомо отсутствует). Оцените долю ложноположительных ответов. Попробуйте bounding box верификацию: снижает ли она долю галлюцинаций? Ожидаемый результат: количественная оценка надёжности вашей модели и эффективности антигаллюцинационного паттерна.

Источники

Навигация: