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

---

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

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

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

---

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

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

Напомним суть из [Главы 1](01_tokens_vectors_and_semantic_space.md): визуальный энкодер (как правило, 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](https://github.com/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](10_agent_not_chat.md), но с жёстким 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](17_observability_and_operations.md)): voice span → tool call span → LLM span — единый trace от входного аудио до ответа.

---

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

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

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

**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](24_landscape_2026.md).

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

Сценарий: обработка 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 верификацию: снижает ли она долю галлюцинаций? **Ожидаемый результат:** количественная оценка надёжности вашей модели и эффективности антигаллюцинационного паттерна.

---

## Источники

- OpenAI. "Vision." https://developers.openai.com/api/docs/guides/images-vision
- Anthropic. "Vision." https://platform.claude.com/docs/en/docs/build-with-claude/vision
- Google. "Image Understanding." https://ai.google.dev/gemini-api/docs/image-understanding
- Google. "Audio Understanding." https://ai.google.dev/gemini-api/docs/audio
- OpenAI. "Realtime API." https://developers.openai.com/api/docs/guides/realtime
- Faysse, M., et al. (2024). "ColPali: Efficient Document Retrieval with Vision Language Models." arXiv:2407.01449. ICLR 2025.
- Li, Y., et al. (2023). "Evaluating Object Hallucination in Large Vision-Language Models." EMNLP 2023. arXiv:2305.10355.
- DocTR — open-source OCR. https://github.com/mindee/doctr

---

**Навигация:**
- Назад: [Глава 17. Наблюдаемость и эксплуатация LLM-продукта](17_observability_and_operations.md)
- Далее: [Глава 19. Дообучение и post-training](19_fine_tuning_and_post_training.md)
