init

book/18_multimodal_systems.md

@@ -0,0 +1,397 @@
+# ГЛАВА 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)