Сверхпродуктивность с искусственым интеллектом: От первого промпта до собственной системы агентов
- -
- 100%
- +
Мультимодальный промпт— запрос, содержащий данные более чем одного типа (текст + изображение, текст + аудио, текст + документ и т.д.), адресованный модели, способной обрабатывать несколько модальностей одновременно.
5.1.2 Какие задачи принципиально изменилисьМультимодальность не просто ускорила существующие задачи — она сделала выполнимыми задачи, которые раньше требовали специалиста, специализированного программного обеспечения или значительного ручного труда.
Работа с физическим контентом. До omni-моделей, чтобы перевести написанное от руки или нарисованное на доске в цифровой формат, нужен был либо человек с развитой способностью читать чужой почерк, либо специализированный OCR с последующей ручной правкой, либо переключение в специализированный сервис. Теперь фотография доски на смартфон плюс промпт с инструкцией — и за 90 секунд задачи структурированы, ответственные назначены, дедлайны зафиксированы в удобном формате.
Документный анализ без копирования. Раньше работа с PDF означала: скопировать текст, вставить в чат, сформулировать вопрос. При этом таблицы теряли структуру, схемы не копировались вообще, многоколоночные документы превращались в непрерывный поток текста без разметки. Сейчас PDF подаётся как файл целиком — модель видит его визуальную структуру так же, как видит её человек: колонки, таблицы, врезки, рисунки.
Аудио напрямую. Расшифровка диктофонной записи прежде требовала отдельного сервиса. Сегодня многие omni-модели принимают аудио напрямую и сразу выполняют над ним задачу: расшифровать, выделить ключевые решения, сформировать список задач с ответственными — одним промптом, без промежуточного этапа.
Сравнение визуальных версий. Отследить изменения между двумя версиями дизайна макета или схемы бизнес-процесса — задача, для которой раньше нужно было специализированное ПО или внимательный и неторопливый взгляд. Загрузить оба изображения и попросить найти различия — сейчас это обычный промпт с ожидаемым временем ответа около 20 секунд.
Принципиально изменилось вот что: убраны «шлюзы» между форматами. Контент больше не нужно приводить к тексту, чтобы с ним работал ИИ. Это меняет дизайн рабочих процессов: вы начинаете с того, что есть — фото, запись, скан, — а не с того, что было удобно прежней модели.
5.1.3 Особенности российских и зарубежных мультимодальных моделейПо состоянию на 2026 год мультимодальные возможности распределены между моделями неравномерно — и эта неравномерность важна при выборе инструмента под конкретную задачу.
Зарубежные omni-модели — GPT и его преемники, Gemini, Claude — работают с изображениями и документами устойчиво: понимают схемы, таблицы, рукописный текст на латинице и кириллице, обрабатывают аудио в большинстве сценариев. Прямой доступ через API в России ограничен — реальное использование идёт через корпоративные договорённости, посредников или зарубежные аккаунты. Для задач с английским контентом — по-прежнему стандарт качества в сложных случаях.
GigaChat от Сбера к 2026 году поддерживает анализ изображений в диалоговом режиме. Качество работы с документами на русском языке — конкурентоспособное для деловых задач: письма, таблицы, отчёты, стандартные формы. Аудиовход как нативная функция появился в 2025 году. Рукописный текст на кириллице распознаётся заметно лучше, чем у большинства зарубежных моделей, — что критично для российских деловых документов с ручными пометками. Преимущество — обработка данных в российском контуре без передачи за рубеж.
YandexGPT с интеграцией в Яндекс 360 позволяет работать с документами через привычную экосистему: суммаризация, вопросы по содержанию, структурирование текста из файлов Яндекс.Диска. Прямой мультимодальный промпт «приложи любую картинку и задай вопрос» — в стадии активного развития. Для задач внутри экосистемы Яндекса — практичный выбор с минимальной настройкой.
Практический вывод: для задач с изображениями и документами на русском языке, где данные конфиденциальны, GigaChat — первый кандидат. Для нативного аудио и видео — проверяйте актуальные возможности конкретной платформы на момент использования: эта область меняется быстрее всего остального в ИИ-инструментах. Для англоязычного контента и сложных аналитических задач над документами зарубежные модели пока дают более стабильный результат в нестандартных ситуациях.
Мультимодальные возможности моделей— одна из наиболее динамично меняющихся областей. Описания возможностей полугодовой давности устаревают. Перед запуском рабочего процесса, где качество критично, всегда тестируйте на реальном образце задачи — не доверяйте только документации или обзорам.
5.2 Работа с изображениями
Изображения — первая и наиболее зрелая область мультимодального взаимодействия. Многие пользователи останавливаются на поверхностном «опиши картинку», не зная о куда более практичных сценариях.
5.2.1 Анализ скриншотов интерфейсаДизайнер, менеджер продукта или аналитик делает скриншот экрана — и задаёт вопрос о нём. Это кажется простым, но за ним стоит принципиальный сдвиг в том, как ИИ используется для дизайн-ревью, UX-аудита и технической поддержки. Раньше описать проблему на экране нужно было словами. Теперь — показать.
Типичные задачи для скриншотного анализа: оценить UX формы регистрации («насколько очевидно, какие поля обязательны?»); проверить читаемость иерархии действий на странице; найти потенциальные точки отвала в воронке оформления заказа; оценить, соответствует ли сообщение об ошибке тому, что пользователь реально сможет понять и сделать.
Ключевой принцип: промпт должен задавать конкретный угол анализа, а не общий вопрос. Разница между «что не так?» и «оцени читаемость иерархии действий для пользователя, который видит этот экран впервые и пришёл оформить заказ» — принципиальная. Первый вопрос получит список поверхностных замечаний. Второй — анализ с точки зрения конкретной цели конкретного пользователя.
Пример: менеджер по продукту загружает скриншот корзины и пишет: «Это страница корзины нашего сайта. Представь, что ты пользователь, который хочет оформить заказ впервые. Что может вызвать замешательство или заставить бросить покупку? Перечисли не более 5 конкретных проблем в порядке критичности, для каждой — аргумент.» Ответ содержит: два замечания по иерархии кнопок («Оформить заказ» визуально слабее «Продолжить покупки»), одно по отсутствию итоговой суммы с доставкой до клика на оплату, одно по неочевидному полю промокода, одно по отсутствию индикатора шага воронки. Каждое с обоснованием.
Для технической поддержки сценарий аналогичен: пользователь присылает скриншот с ошибкой, и специалист (или сам пользователь) получает объяснение проблемы и инструкцию к решению без необходимости долго описывать состояние экрана. Это особенно ценно в асинхронной коммуникации, где «опиши словами» порождает долгие переписки с уточнениями.
Важный формат для скриншотного анализа — сравнительный. Два скриншота в одном промпте: версия интерфейса до редизайна и после. Задача: «Какие изменения улучшили UX? Какие создали новые проблемы? Что осталось нерешённым?» Это быстрее и конкретнее, чем устный или письменный разбор — потому что модель видит то же, что видит команда.
5.2.2 Распознавание и структурирование таблиц и схемКогда таблица существует как изображение — отсканированная, сделанная скриншотом из PDF, сфотографированная, — работать с ней в текстовом режиме раньше было болезненно. Специализированный OCR давал непредсказуемый результат, особенно со сложными таблицами с объединёнными ячейками или многоуровневыми заголовками. Ручной перенос данных — очевидно медленно и prone to errors.
Мультимодальная модель позволяет преобразовать таблицу-изображение в структурированный текст: CSV-формат для импорта в Excel, Markdown-таблицу для документации, JSON для дальнейшей обработки. При этом можно сразу задавать вопросы по содержанию: «Какой показатель максимален во втором квартале?», «Есть ли строки, где значение в столбце «план» превышает «факт» более чем на 20%?»
Схемы и диаграммы — отдельно ценная область. Бизнес-процессы, организационные структуры, блок-схемы алгоритмов, диаграммы потоков данных — всё это раньше требовало либо живого эксперта в предметной области, либо специализированного ПО для анализа. Промпт «Опиши эту схему бизнес-процесса. Найди шаги, где нет ответственного или не обозначен выход при ошибке» — рабочий инструмент аналитика.
Особо ценный сценарий — восстановление неполной информации. «На схеме организационной структуры часть должностей не подписана, но их позиция в иерархии видна. Что можно предположить об этих ролях на основе структуры?» Это не галлюцинация — это обоснованная гипотеза, которую модель строит на основе видимого контекста. Разница важна: гипотеза всегда должна быть верифицирована, но иметь её как отправную точку уже ценно.
Два ограничения, которые нужно знать. Первое: очень мелкий текст — цифры и подписи мельче определённого размера — модель часто не читает корректно. Если числа критичны, подайте укрупнённый фрагмент или несколько изображений с разными масштабами. Второе: цвет как единственный носитель смысла (красный = плохо, зелёный = хорошо — без подписей и легенды) может восприниматься неверно. Добавляйте словесный контекст в промпт: «На схеме красный цвет означает проблемные шаги, зелёный — нормальные».
5.2.3 Анализ фото доски после совещания: извлечение задачБелая маркерная доска — один из самых распространённых рабочих инструментов, результат которого теряется в течение нескольких дней: стирается, фотографируется на телефон и остаётся в галерее без дальнейшей обработки. Это хронический источник потери договорённостей.
Смартфон плюс мультимодальная модель решают эту проблему радикально. Сценарий: в конце встречи кто-то фотографирует доску, загружает фото в модель и формулирует задачу. Вот промпт, который даёт рабочий результат:
«На фото — маркерная доска после рабочего совещания нашей команды. Из всего написанного извлеки: (1) задачи — формулировка, ответственный (если указан), срок (если виден); (2) принятые решения — кратко, что именно решили; (3) открытые вопросы — то, на что не нашли ответа; (4) прочее — всё, что не вошло в первые три категории. Выведи как таблицу в Markdown. Если слово нечитаемо — пиши [?] вместо угадывания.»
Это не просто «распознай текст» — это аналитическая задача над визуальным содержанием. Модель читает доску, категоризирует содержимое по функциональным типам и форматирует результат для копирования в систему управления задачами. Время от фотографии до структурированного протокола — 60–90 секунд.
Дополнительный сценарий — ретроспективный анализ. Если у вас есть серия фотографий доски с разных встреч по одному проекту, можно задать сводный вопрос: «Какие задачи появлялись на разных встречах и до сих пор не отмечены как выполненные?» Это требует подачи нескольких изображений и более сложного промпта, но сам принцип работает.
Рукописный текст на кириллице распознаётся хуже, чем печатный или латинский рукописный. Если почерк неразборчив или написано мелко, включайте в промпт инструкцию: «Если слово нечитаемо — помечай [?] вместо угадывания». Это предотвращает галлюцинации — ситуации, когда модель уверенно «читает» слово, которого нет или которое совсем другое.
5.2.4 Генерация описаний и alt-текстовAlt-тексты (альтернативные текстовые описания изображений) — обязательный элемент доступного веб-контента. Они нужны для слабовидящих пользователей, работающих с экранными считывателями, и для поисковых систем, которые индексируют содержание страниц через текст. Стандарт WCAG 2.1 делает их де-факто обязательными для большинства публичных цифровых продуктов. На практике их либо не пишут вообще, либо пишут формально («картинка1.jpg»), либо пишут размыто и бесполезно.
Мультимодальная модель генерирует alt-тексты корректно и быстро — при условии правильного промпта с контекстом. Разница между промптом без контекста («Опиши это изображение для alt-текста») и с контекстом существенна. «Это изображение для статьи о методах agile-планирования. Напиши alt-текст длиной 100–125 символов: точное описание того, что изображено, с акцентом на информации, которую изображение добавляет к тексту статьи» — даёт конкретный полезный результат вместо общего описания.
Та же логика — для подписей к изображениям в презентациях, описаний инфографики, технической документации. Задача 20–30 секунд вместо 3–5 минут ручной работы — если делать это вдумчиво, а не формально. Умножьте на количество изображений в типичной корпоративной презентации — и получите ощутимую экономию времени.
Ещё один сценарий — описание изображений для внутренней документации. Когда технический документ или инструкция содержат схемы и скриншоты, которые нужно подписать или описать в тексте вокруг них, промпт «Опиши этот скриншот в одном абзаце так, чтобы читатель понял, что именно здесь отображается, без необходимости смотреть на изображение» — стандартная утилита технического писателя.
Практикум 5.А: Анализ фотографии доски
Задача: превратить фотографию рабочей доски в структурированный протокол встречи.
Что делать:
1. Проведите любую короткую рабочую встречу или возьмите фото существующей доски — учебной, домашней с планами, рабочей.
2. Сфотографируйте доску смартфоном. Качество — достаточное для чтения текста. Не нужно идеальное освещение, но нужна нормальная резкость.
3. Загрузите фото в GigaChat или доступную мультимодальную модель.
4. Используйте промпт: «Это фото рабочей доски после обсуждения. Структурируй содержимое по четырём разделам: (1) Принятые решения, (2) Задачи с ответственными и сроками (если указаны), (3) Открытые вопросы, (4) Прочие заметки. Выведи в виде таблицы Markdown. Если что-то нечитаемо — помечай [?] вместо догадок.»
5. Оцените результат: насколько полно извлечено содержание? Что пропущено? Что распознано неверно?
Ожидаемый результат: структурированная таблица в Markdown, пригодная для вставки в корпоративную вики или систему задач. Погрешность извлечения при читаемом почерке — менее 15%.
На что обратить внимание: сравните с тем, что вы запомнили с доски. Проверьте: не добавила ли модель того, чего не было (галлюцинации). Если модель угадывала неразборчивые слова без инструкции [?] — это сигнал переформулировать промпт.
5.3 Работа с аудио и видео
Аудио и видео — вторая крупная область мультимодальности, и именно здесь разрыв между «до» и «после» omni-моделей наиболее очевиден для большинства специалистов.
5.3.1 Расшифровка записи совещания и извлечение задачДеловое совещание средней длины занимает около 45 минут — это один из наиболее стабильных показателей, который исследователи фиксируют в разных контекстах и культурах. Из них содержательными оказываются, как правило, меньше половины. Полезная расшифровка — та, где зафиксированы только решения и задачи, а не стенограмма — существенно ценнее, чем дословный текст.
Мультимодальный промпт для аудио строится иначе, чем для изображений. Вы не можете «указать» на конкретный момент записи, как указываете на фрагмент картинки. Зато вы можете чётко задать задачу над содержанием целиком. Вот промпт, который даёт результат:
«Это запись рабочего совещания нашего отдела. Из записи извлеки: (1) список задач — кому поручено, что именно, в какой срок, если назван; (2) принятые решения — кратко, что именно решили, без пересказа обсуждения; (3) вопросы, по которым консенсус не достигнут — что осталось открытым. Не пересказывай разговор. Только структурированный вывод. Язык — русский, даже если в записи есть английские термины.»
Пример: руководитель проекта записывает еженедельную рабочую встречу на 35 минут. Раньше протокол готовился вручную 20–30 минут после встречи. Теперь: загрузить запись + промпт → получить черновик протокола за 2 минуты → проверить и утвердить за 5. Итого 7 минут вместо 30. Умножьте на 52 недели — около 20 часов сохранённого рабочего времени в год только на этой задаче.
Дополнительная возможность: идентификация спикеров. Если участники называют друг друга по имени в ходе разговора, модель обычно способна разметить высказывания по спикерам — «Антон предложил перенести дедлайн», «Марина возразила, что это создаст конфликт с релизом». Без имён в записи — «Спикер 1», «Спикер 2». Это не точная диаризация (разметка по голосам), но для практических нужд рабочего протокола — достаточно.
Для длинных записей (более 30–40 минут) возможности конкретных платформ различаются: некоторые обрабатывают аудио целиком, другие работают через сегментацию. Проверяйте ограничения вашей модели на тестовом примере, прежде чем встраивать в рабочий процесс. Если платформа не принимает аудио напрямую — опция: расшифровать через специализированный сервис, а затем работать с текстом транскрипта.
5.3.2 Суммаризация видеоконтентаВидео — наиболее «тяжёлая» модальность для языковых моделей: информация в нём комбинированная (изображение, аудио, часто текст на экране или субтитры), и обрабатывать её в реальном времени технически сложнее, чем любой другой тип.
К 2026 году практические возможности распределены так. Короткие видео — до 5–7 минут — большинство omni-моделей обрабатывают нативно: загрузить файл и задать вопрос. Для образовательного контента, записей выступлений, коротких демо — рабочий сценарий. Длинные видео — лекции, вебинары, интервью продолжительностью 30–90 минут — чаще всего обрабатываются через аудиодорожку: её извлекают и транскрибируют, затем работают с текстом. Видео с субтитрами — наиболее простой случай: файл субтитров (SRT или VTT) как текстовый ввод плюс запрос суммаризации.
Для образовательного контента суммаризация с дополнительными задачами — мощный инструмент самообучения. Промпт поверх транскрипта лекции: «Составь: (1) структурный конспект с заголовками по темам, (2) список из 7 ключевых идей — каждая в одном предложении, (3) 5 вопросов для самопроверки понимания материала, (4) список понятий, которые вводятся впервые и требуют отдельного изучения.» Результат — готовые учебные материалы, на создание которых вручную ушло бы несколько часов.
Корпоративный сценарий: видеозаписи внутренних тренингов, вебинаров с партнёрами, записи демонстраций продукта. Обычно они накапливаются в архиве и не используются, потому что «смотреть 2 часа» — барьер. Суммаризация снижает этот барьер до «прочитать конспект за 10 минут и посмотреть нужный фрагмент, если интересно».
5.3.3 Мультиязычная транскрипцияРабочий контекст в международных или смешанных командах нередко выглядит так: запись совещания, где часть говорит по-русски, часть — по-английски, а некоторые участники переключаются между языками внутри одной фразы. Традиционные ASR-системы (Automatic Speech Recognition — автоматическое распознавание речи) теряются в таких переходах.
Мультимодальные модели обрабатывают смешанный код (code-switching) значительно лучше специализированных ASR-систем. При этом промпт важен: «Запись содержит русский и английский языки. Транскрибируй, сохраняя оригинальный язык каждой фразы. Технические термины на английском не переводи. Если фраза начата по-русски и завершена по-английски — сохрани это как есть.»
Для задач с переводом — другой формат: «Транскрибируй эту запись на русском и одновременно переведи на английский. Выдай двуколонную таблицу: левая — оригинал, правая — перевод.» Это не замена профессиональному переводу для юридически значимых документов. Но для рабочего обмена знаниями между командами, краткого изложения ключевых решений из встречи для иностранного партнёра — вполне применимо.
Отдельный сценарий — акцент. Не все говорящие произносят чисто. Региональные акценты, смешение с родным языком, быстрый темп речи — всё это снижает точность транскрипции. В таких случаях помогает явная инструкция: «Если фраза неразборчива — пиши [неразборчиво] вместо угадывания». Лучше честный пробел, чем уверенная ошибка в протоколе.
Качество транскрипции напрямую зависит от качества записи. Фоновый шум, перекрёстные разговоры, плохой микрофон, большое расстояние от источника звука — всё это снижает точность. Запись встречи через громкую связь телефона в конференц-зале даёт принципиально другой результат, чем запись через выносной микрофон. Инвестиция в нормальное оборудование для записи — это инвестиция в качество транскрипции.
5.4 Работа с документами как объектами
Документ как визуальный объект — принципиально другой способ взаимодействия с ним, чем документ как текстовый файл. И разница эта важнее, чем кажется.
5.4.1 PDF, презентации, таблицы — анализ без копирования текстаСтандартный рабочий сценарий до omni-моделей: скопировать текст из PDF → вставить в чат → сформулировать вопрос. Проблем несколько. Многоколоночные PDF теряют структуру при копировании — текст из двух колонок соединяется в непрерывный поток. Таблицы в PDF копируются как непрерывный текст, где строки и столбцы перемешаны. Схемы и диаграммы вообще не копируются в текстовом виде. Скрипты защищённых документов блокируют копирование. Наконец, сам процесс занимает время — особенно для документов на 30–50 и более страниц.
Подача PDF напрямую как файла решает первые четыре проблемы. Модель видит документ таким, каким его видит человек: с колонками, таблицами, схемами, врезками. Вопросы по содержанию задаются так же, как вы задали бы их коллеге, который только что прочитал этот документ.
Формат промпта важен. Для длинного договора: «Это договор на оказание услуг. Выдели: (1) срок действия, (2) стоимость и порядок оплаты, (3) условия одностороннего расторжения, (4) ответственность за нарушение сроков. По каждому пункту — точная цитата из текста и номер раздела.» Запрос цитаты с указанием раздела — критически важный элемент: он позволяет быстро верифицировать ответ модели, не перечитывая документ целиком.
Для научной статьи формат другой: «Из этой статьи опиши: методологию (дизайн исследования, выборка, инструменты), ключевые выводы с уровнем доказательности, который сами авторы присваивают своим результатам, и ограничения — в формулировке самих авторов.» Последнее важно: ограничения, которые авторы признают сами, — принципиально ценнее, чем те, что читатель додумывает.
Для финансового отчёта: «В этом квартальном отчёте выдели три ключевых показателя, которые изменились по сравнению с предыдущим периодом более чем на 10%, и направление изменения. Для каждого — абсолютное значение и процентное изменение из текста документа.» Числа — зона повышенного риска галлюцинаций, поэтому запрос привязать к тексту документа, а не вычислять — правильная тактика.
Ограничение, которое важно понимать: очень длинные документы (100+ страниц) могут обрабатываться с потерями — особенно если контекстное окно модели не позволяет вместить весь документ. В таком случае стратегия — разбить на смысловые части и работать с каждой отдельно, или использовать модели с длинным контекстом (1M+ токенов), которые способны принять большой документ целиком.
5.4.2 Сравнение версий документов через изображенияОтслеживать изменения между версиями договора, технического задания, дизайн-макета или регламента — задача, которая традиционно требовала специальной функции в Word, специализированных инструментов или тщательного ручного сравнения. Для документов, где версии существуют как PDF или изображения — что типично при работе с внешними партнёрами — omni-модель позволяет сравнить страницы напрямую.
Промпт для сравнения двух версий одной страницы: «Это две версии одной страницы технического задания. Версия 1 — слева, версия 2 — справа. Найди все отличия. Для каждого: (1) что было, (2) что стало, (3) насколько изменение влияет на смысл документа — существенно, незначительно или только стилистически.»
Для дизайн-ревью — другой угол: «Это два варианта одного экрана мобильного приложения. Опиши изменения. Какие из них улучшают пользовательский опыт и почему? Какие вызывают вопросы?»
Ограничение здесь реальное и важное: если изменений много, а документ плотный, модель может пропустить некоторые из них — особенно небольшие правки в числах или формулировках. Для юридически значимых документов это не замена специализированного инструмента сравнения (типа функции Compare в Word). Но как первичный быстрый срез — «посмотри, что вообще изменилось, прежде чем углубляться» — вполне работает.
5.4.3 Автоматическое заполнение формРутинная задача, которую редко рассматривают как мультимодальную: заполнение стандартных форм — анкет, заявок, типовых бланков — по имеющимся данным из другого документа.