На связи Сергей Смирнов, AI-инженер и основатель LLMStart.ru. Мы делаем AI-системы для бизнеса. Сегодня разбираем мультимодальность в нашем ИИ-агенте для компании Айтон. Этот агент консультирует сотрудников по 1С:УНФ.

В первой статье серии я рассказывал про контекст-инжиниринг. Во второй — про оценку качества. Сейчас поговорим про картинки. В нашем агенте мультимодальность — это не просто модная фишка. Это реальная необходимость.

Агент живет в Telegram. Как это работает:

• Пользователь пишет вопрос.

• Часто прикрепляет скриншот с ошибкой.

• Агент ищет ответ в методичке.

• Отвечает текстом и прикладывает свой скриншот-инструкцию.

И вот тут логика ломается. Оказывается, у входящих и исходящих картинок — совершенно разная физика. Нельзя просто сказать «мы используем мультимодальность» и закрыть вопрос. Выбор технологии зависит не от масштаба проекта, а от свойств самих картинок в вашем домене.

Спойлер: ниже мы разберем две стороны работы со скриншотами. Я покажу анализ 258 реальных диалогов из продакшена. И объясню, почему модный multimodal RAG (векторизация картинок) нам вообще не понадобился.

Давайте разберем оба потока отдельно, а в конце сведем все в понятную схему принятия решений.

Как бот читает ваши ошибки: почему мы не стали экономить копейки на токенах

Когда пользователь присылает скриншот в Telegram, обычно это значит одно из двух:

• Он поймал ошибку и показывает её.

• Он запутался в интерфейсе и просит подсказать, куда нажать.

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

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

Идея красивая, экономия видна сразу. Но мы решили проверить её на реальности и проанализировали 258 скриншотов из диалогов наших пользователей. И вот что получилось:

• 88.8% скриншотов полностью заменяемы текстовым описанием.

• 8.9% — частичная потеря информации (важные детали видны только в оригинале).

• 2.3% — требуют оригинальное изображение (без картинки ответ агента вообще бесполезен).

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

Так почему же мы не пошли в подход caption+tool, несмотря на заманчивую экономию?

Во-первых, надёжность. При подходе caption+tool нейросеть сама решает, когда ей нужен оригинал. И это решение она принимает на основе текстового описания, а не самой картинки! В тех самых 8.9% случаев (где часть деталей теряется) модель может просто не догадаться, что в описании упущено что-то критичное, и не запросит оригинал. А вот при подходе image-only картинка всегда в контексте. Ответ агента не зависит от того, поняла ли модель, насколько важен визуал.

Во-вторых, мы выбрали KISS (Keep It Simple, Stupid) и осознанно отказались от преждевременной оптимизации. Image-only — это максимально простой подход. Экономия на коммерческом диалоге (где обычно 3–5 сообщений, и только 16% из них с картинками) составляет всего $0.01–0.03. Это сущие копейки. На нашем текущем масштабе такая экономия просто не оправдывает усложнение архитектуры.

В-третьих, у нас есть понятный маршрут на будущее. Если агент выйдет на массовую нагрузку, и эти копейки начнут складываться в реальные деньги — вот тогда переход на caption+tool станет оправдан. Это не отвергнутый путь, это просто отложенная оптимизация.

Поэтому сейчас мы используем подход image-only. Мы отправляем оригинал картинки прямо в контекст LLM, без всяких описаний и промежуточных инструментов. Скриншот улетает в формате base64, без предварительной обработки.

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

Исходящие скриншоты: когда боту вообще не нужно понимать картинку

Теперь посмотрим на обратный поток. Агент нашел в методичке нужный кусок текста (чанк) про меню. К этому тексту прикреплен скриншот: «нажми сюда». Картинка здесь заменяет скучное описание интерфейса на конкретное действие. Пользователь сразу видит нужную кнопку, а не читает длинную инструкцию, как до нее добраться.

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

Мы решили эту задачу тремя простыми архитектурными шагами:

• Хранение: MinIO. Картинки из документов — это просто файлы. Логично хранить их в надежном месте для быстрой доставки.

• Индексация: БЕЗ векторизации картинок. Да, мы думали о том, чтобы векторизовать изображения, но быстро отказались. В наших методичках картинка by design прикреплена к конкретному разделу урока. Сама по себе она не имеет смысла, это часть связки «текст + картинка». Текст говорит «нажми эту кнопку», а картинка показывает, какую именно. Ее смысл полностью зависит от текста вокруг. Поэтому обычный поиск по тексту работает идеально: нашли нужный текст — забрали прикрепленную к нему картинку.

• Доставка: Base64 в JSON-ответе. В Telegram картинка улетает отдельным сообщением (API позволяет отправить до 10 фото за раз). Клиент сам расшифровывает Base64, но это уже технические мелочи.

Чувствуете разницу? Входящие картинки — это маршрут «пользователь → нейросеть», где главное — понимание. Исходящие картинки — это маршрут «документ → пользователь», где главное — наглядность. Разные задачи — разные решения.

Multimodal RAG: модная технология, которая оказалась нам не нужна

Чуть выше я обронил фразу «без векторизации картинок». За этими словами скрывается целая развилка в индустрии — технология Multimodal RAG. Мы отказались от неё совершенно осознанно. И вот почему.

Multimodal RAG — это когда картинки превращают в векторы (набор чисел) наравне с текстом, а потом ищут по визуальному смыслу. Сейчас в индустрии есть три главных подхода к этому:

• CLIP-style. Текст и картинку запихивают в одно математическое пространство. Запрос пользователя превращается в вектор, и система ищет похожие векторы-картинки. Это простой и дешевый подход, который пошел от модели CLIP (Radford et al., 2021). Минус в том, что нейросеть понимает картинку очень грубо и теряет мелкие детали. Современные примеры: Cohere Embed Multimodal, Jina CLIP, ImageBind.

• ColPali / late-interaction. Страница документа рендерится целиком как картинка и нарезается на кусочки (patches). Каждый кусочек получает свой вектор. Когда пользователь делает запрос, система сравнивает его не со всей страницей, а с каждым кусочком отдельно. Это дороже, но шикарно работает на сложных документах: диаграммах, таблицах, графиках. Подробности можно почитать в ColPali (Faysse et al., 2024).

• VLM-as-captioner. Нейросеть (Vision-LLM) просто описывает картинку словами. Потом это текстовое описание превращается в вектор и кладется в базу. Это самый дешевый способ, но он абсолютно «глух» к визуальным нюансам. Если нейросеть не упомянула что-то в описании — для поиска этого не существует. По сути, это тот же caption+tool, который мы забраковали для входящих картинок.

Когда Multimodal RAG реально нужен? Есть три четких триггера:

1. Картинки в документах очень разные (графики, фото, схемы, таблицы).

2. Пользователь может искать по визуальному признаку (например, «как выглядит отчет» или «какого цвета индикатор»).

3. Картинка несет свой собственный смысл, даже если оторвать ее от текста.

Почему нам это не подошло? В нашем проекте не выполняется ни одно из этих условий!

• Скриншоты 1С:УНФ абсолютно однородны. Это всегда интерфейс, который показывает путь по меню.

• Пользователи спрашивают про функционал, а не про цвет кнопок.

• Картинка намертво привязана к тексту методички. Без текста она бесполезна.

Текст вокруг картинки (описание полей, заголовки) позволяет найти нужный кусок лучше любого навороченного ColPali. У нас есть точная, железобетонная привязка «текст ↔ картинка». Вероятностный поиск по картинкам здесь просто не нужен.

Мы не говорим, что Multimodal RAG — это плохо. Мы говорим, что Multimodal RAG решает проблемы, которых у нас просто нет. Внедрять его было бы усложнением ради усложнения.

Дерево решений: когда вам нужен Multimodal RAG, а когда — нет

Итак, у нас есть два решения: image-only для входящих картинок и прямое прикрепление к тексту для исходящих. У обоих подходов есть альтернативы. И водораздел здесь проходит не по линии «у нас большой проект» или «нам нужно супер-качество». Все решают два конкретных вопроса про свойства самих картинок.

Для входящих картинок главный вопрос звучит так: «Можно ли заменить картинку текстовым описанием без потери смысла?»

• Если ДА — смело берите caption+tool. Это идеальный вариант для массовых и дешевых сценариев. Например, FAQ-система, где 99% вопросов — текстовые, а редкие скриншоты нужны просто для иллюстрации. Здесь вы реально сэкономите токены, а риск пропустить важную деталь минимален.

• Если НЕТ — ваш выбор image-only. Это наш случай. Скриншоты 1С несут критичные визуальные детали: точные названия кнопок, конкретные поля, состояние интерфейса в момент ошибки. Текстовое описание просто не сможет надежно схватить все эти нюансы. Да, на огромных объемах экономия от caption+tool начнет манить, но это уже вопрос баланса между ценой и усложнением системы, а не выбор базовой технологии.

Для исходящих картинок главный вопрос другой: «Однороден ли визуальный домен картинок?»

• Если ДА (однороден) — используйте прямое прикрепление к тексту. Снова наш случай. Все картинки в методичках — это скриншоты интерфейса 1С. Они одинаковы по смыслу и намертво привязаны к конкретным урокам. Нужный скриншот легко находится по тексту вокруг него. Собственного, отдельного от текста смысла у этих картинок нет.

• Если НЕТ (неоднороден) — добро пожаловать в Multimodal RAG. Если в ваших документах вперемешку идут скриншоты, сложные диаграммы, графики и фотографии, то у картинок появляется свой собственный смысл. Вот тут поиск по визуальному сходству начинает реально тащить. А какой именно подход выбрать (CLIP-style, ColPali или captioner) — зависит от сложности ваших документов и бюджета на сервера.

Вывод простой: не гонитесь за тем, что красиво звучит на конференциях. Смотрите на свои данные. Часто это означает осознанный отказ от модной оптимизации, которая в вашем случае просто не нужна.

Сухой остаток: что делать с картинками в вашем проекте

Если вы прямо сейчас ломаете голову над мультимодальностью в своем проекте, вот три практических ориентира:

• Для входящих картинок: проверяйте, можно ли заменить их текстом. И проверяйте на реальных данных (как мы на 258 диалогах), а не на интуиции. Если нельзя — используйте image-only. Если можно — внедряйте caption+tool.

• Для исходящих картинок: смотрите на однородность. Если у вас в одном продукте только скриншоты интерфейса — просто привязывайте их к тексту. Если у вас сложный микс из диаграмм, графиков и фото — идите в Multimodal RAG (CLIP-style для простых случаев, ColPali для сложных).

• Не усложняйте архитектуру ради копеечной экономии. Экономия в $0.01–0.03 на диалог — это не повод городить сложную систему. Вот когда эти копейки сложатся в реальные тысячи долларов при росте нагрузки — тогда и оптимизируйте.

В production-агенте нет единого «правильного» подхода к мультимодальности. Входящие картинки требуют качества распознавания, исходящие — надежной доставки. За каждым вашим решением должны стоять измеримые причины. У нас это были 258 скриншотов и пара центов экономии. У вас цифры будут другими, но главное — чтобы они у вас были.

В следующей статье я расскажу про мульти-тенант: как мы организовали инфраструктуру, сделали биллинг через ContextVar и настроили append-only логи. Это уже не про картинки, но из того же самого production-агента.

А как обстоят дела у вас? Для входящих картинок вы держитесь за image-only или уже перешли на caption+tool? На каком объеме диалогов экономия перевесила простоту? И если вы используете Multimodal RAG — какой подход выбрали? Расскажите в комментариях, этот живой опыт для меня важнее любых сухих метрик.

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

В LLMStart.ru мы помогаем бизнесу решать такие задачи и получать реальный эффект от ИИ — от прототипа до промышленной эксплуатации. Если вы уперлись в архитектурные развилки при создании своих ИИ-агентов, приходите к нам за консультацией или разработкой под ключ.

Если хотите перенять опыт и научиться делать подобные системы самостоятельно, у нас есть Комбо из четырех курсов по AI-driven разработке и ИИ-агентам. Это полный гайд от AI-кодинга и первых ассистентов к AI-продуктам, RAG-системам, агентам и мультиагентным системам.

По любым вопросам пишите мне в личку: Telegram или ВК. Приглашаем также в наши соцсети про ИИ-кодинг ИИ-агентов: в ТГ-канал и ВК-сообщество