Сергей Смирнов, ИИ-инженер и основатель LLMStart.ru, опубликовал разбор архитектурных решений по мультимодальности в ИИ-агенте, который консультирует сотрудников компании Айтон по системе 1С:УНФ. Агент работает в Telegram: пользователь задаёт вопрос, часто прикладывает скриншот с ошибкой, агент ищет ответ в методичке и отвечает текстом плюс собственным скриншотом-инструкцией. Именно здесь обнаружилось, что входящие и исходящие картинки требуют принципиально разных подходов.
Для входящих скриншотов команда рассматривала два варианта. Первый — caption+tool: отдельная модель описывает картинку текстом, оригинал сохраняется и запрашивается агентом только при необходимости. Это экономит токены в контексте. Второй — image-only: оригинал картинки в base64 сразу попадает в контекст LLM. Чтобы выбрать, разработчики проанализировали 258 реальных диалогов. Результат: 88,8% скриншотов полностью заменяемы текстовым описанием, 8,9% дают частичную потерю деталей, и лишь 2,3% требуют оригинала. Казалось бы, экономия оправдана. Но у подхода caption+tool есть системный изъян: модель решает, нужен ли ей оригинал, опираясь на текстовое описание — то есть именно на тот источник, в котором уже потеряны детали. В 8,9% пограничных случаев она может не догадаться запросить картинку. При image-only оригинал всегда в контексте, и качество ответа не зависит от того, правильно ли модель оценила важность визуала.
| Подход | Принцип работы | Примеры | Главный минус |
|---|---|---|---|
| CLIP-style | Текст и картинка в едином векторном пространстве | Cohere Embed Multimodal, Jina CLIP, ImageBind | Теряет мелкие визуальные детали |
| ColPali / late-interaction | Страница нарезается на патчи, каждый векторизуется отдельно | ColPali (Faysse et al., 2024) | Дороже в вычислениях |
| VLM-as-captioner | Модель описывает картинку текстом, текст векторизуется | Любая Vision-LLM | Детали, не попавшие в описание, невидимы для поиска |
Дополнительный аргумент — масштаб. Коммерческий диалог в среднем занимает 3–5 сообщений, картинки есть лишь в 16% из них. Экономия от caption+tool составляет $0,01–0,03 за диалог. На текущей нагрузке это не окупает усложнение архитектуры и затруднение отладки: при image-only разработчик открывает логи и видит оригинальный скриншот. Переход на caption+tool авторы описывают как «отложенную оптимизацию» — она станет оправданной при существенном росте числа пользователей.
Входящие картинки передаются в LLM напрямую в base64 — без промежуточных описаний и инструментов.
Исходящие скриншоты — полностью другая задача. Агент находит в методичке нужный текстовый чанк, к которому прикреплена иллюстрация: «нажми сюда». Нейросети не нужно понимать эту картинку — ей нужно просто доставить её пользователю вместе с правильным текстом. Архитектура здесь трёхшаговая: файлы хранятся в MinIO, индексируются без векторизации (поиск идёт по тексту, картинка следует за своим чанком), доставляются клиенту в base64 внутри JSON-ответа. В Telegram это реализуется отправкой до 10 фото за раз через API.
Отдельно авторы разбирают Multimodal RAG — технологию, при которой картинки превращаются в векторы наравне с текстом и участвуют в семантическом поиске. В индустрии существует три основных семейства подходов. CLIP-style (Cohere Embed Multimodal, Jina CLIP, ImageBind) помещает текст и изображение в единое математическое пространство; подход дешёв, но теряет мелкие детали. ColPali (Faysse et al., 2024) рендерит страницу документа как картинку, нарезает её на патчи и векторизует каждый отдельно — дороже, но хорошо работает на диаграммах и таблицах. VLM-as-captioner использует языковую модель с поддержкой зрения для генерации текстового описания, которое затем векторизуется; самый дешёвый вариант, но «глухой» к визуальным нюансам, не попавшим в описание.
Для методички 1С:УНФ ни один из этих подходов не нужен: каждая картинка by design прикреплена к конкретному разделу и не имеет самостоятельного смысла без окружающего текста. Пользователь никогда не ищет по визуальному признаку — он ищет по задаче. Multimodal RAG оправдан, когда документы содержат разнородные изображения (графики, фото, схемы), когда пользователь может искать по внешнему виду объекта, или когда картинки несут информацию, недоступную в тексте. В противном случае это усложнение без выгоды.