Сверхпродуктивность с искусственым интеллектом: От первого промпта до собственной системы агентов
- -
- 100%
- +
Типичный сценарий: у вас есть исходный документ с данными (паспорт сотрудника, регистрационная карточка компании, резюме, выписка из реестра) и форма, которую нужно заполнить (анкета для тендера, заявление в орган, форма партнёрской регистрации). Задача для модели: извлечь нужные данные из исходника и подставить в форму в нужном формате.
Промпт: «Вот исходный документ с данными о компании [PDF или изображение]. Вот форма для заполнения [изображение или описание полей]. Заполни форму данными из исходного документа. Если данные в форме требуют другого формата — адаптируй (например, ИНН как 12 цифр без пробелов, если в форме поле для него). Если данных нет в исходнике — оставь поле пустым. Не заполняй поля данными, которых нет в исходном документе.»
Последняя инструкция — «не заполняй то, чего нет» — обязательна и должна стоять явно. Без неё модель может заполнить недостающие поля «правдоподобными» значениями. В официальных документах это недопустимо — любой реквизит, заполненный без исходника, является фальсификацией.
Другой сценарий: форма существует в формате PDF с заполняемыми полями, но их автоматическое заполнение технически недоступно. Модель может сгенерировать текстовый список всех значений в порядке следования полей — человек копирует их последовательно. Не элегантно, но быстрее ручного поиска каждого реквизита.
5.5 Мультимодальные рабочие цепочки
Отдельные мультимодальные задачи — это инструменты. Рабочие цепочки, объединяющие несколько модальностей в единый процесс — это система. Разница между инструментом и системой — в том, что система работает устойчиво, воспроизводимо и без необходимости каждый раз придумывать подход заново.
5.5.1 Создание контент-кита: один материал — несколько форматовКонтент-кит (content kit) — набор материалов об одном и том же событии или теме, адаптированных под разные форматы и каналы. Стандартный состав для корпоративного или профессионального контекста: пост в каналы на разных соцсетях; краткое резюме для внутренней рассылки; расшифровка выступления для публикации или архива; анонс с ключевыми тезисами; alt-тексты к иллюстрациям.
До мультимодальных цепочек создание контент-кита из одного исходника требовало нескольких человек или нескольких часов одного человека: расшифровать, выделить ключевые мысли, написать пост в одном тоне, резюме в другом, подобрать или создать иллюстрации, подписать их. Теперь это последовательность из 5–7 промптов, которую может выполнить один человек гораздо быстрее.
Типовая цепочка. Шаг 1: исходный материал — запись вебинара, презентация, интервью. Если аудио или видео — расшифровать в транскрипт. Шаг 2: из транскрипта — ключевые тезисы (5–7 утверждений, каждое в одном предложении). Промпт: «Из этого транскрипта выдели 7 ключевых тезисов. Каждый — одно предложение без вводных слов типа «в данном материале» или «автор считает».» Шаг 3: из тезисов — пост для конкретной соцсети. Промпт с указанием тона, объёма и структуры. Шаг 4: из тезисов — резюме для рассылки с другим тоном и структурой. Шаг 5: из транскрипта — 3 цитаты, пригодные для карточек или визуального контента.
Ключевое: исходный материал подаётся один раз, не копируется под каждый формат. Каждый шаг — отдельный промпт, использующий результат предыдущего. Человек остаётся в роли редактора, который проверяет и дорабатывает черновики — но не создаёт их с нуля.
Пример: эксперт провёл 40-минутный вебинар для профессионального сообщества. Раньше подготовка контент-кита (пост, расшифровка, анонс следующего события, резюме для рассылки 500 подписчикам) занимала 4–6 часов чужого рабочего времени. С мультимодальной цепочкой — 80–90 минут с проверкой и редактурой. Качество черновиков: «хорошо, надо доработать», а не «написано роботом, надо переписать».
Отдельный вопрос — управление тоном в разных форматах. Одни и те же факты подаются в соцсети живо и с конкретным инсайтом в начале, в рассылку — структурированно и сдержанно, в анонс для партнёров — с акцентом на ценности для аудитории. Это не автоматически — каждый промпт должен явно задавать тон, аудиторию и ключевую задачу форматируемого текста. Без этого все форматы будут похожи друг на друга.
5.5.2 Единый рабочий процесс «текст + таблица + голос»Второй тип цепочки — операционный, а не контентный. Он объединяет разные форматы данных в рамках одной регулярной рабочей задачи: еженедельный отчёт, ежемесячный дайджест, итоги квартала.
Типовой сценарий: аналитик готовит еженедельный операционный отчёт. Источники — три типа данных одновременно: таблица с показателями (числовые данные), аудиозаписи коротких стендапов (неструктурированный контекст), скриншоты из CRM (визуальный контент). Раньше это значило: извлечь данные из таблицы вручную, прослушать записи, переписать данные из CRM — несколько часов работы.
С мультимодальной цепочкой процесс выглядит иначе. Шаг 1: загрузить таблицу с KPI → «Какие показатели вышли за пределы допустимого диапазона на этой неделе? Для каждого — значение, норма и отклонение.» Шаг 2: загрузить аудио стендапа → «Какие проблемы или риски упоминались чаще всего? Назови участников, если они себя называли.» Шаг 3: скриншоты CRM → «Сколько сделок перешли из стадии X в стадию Y? Какие зависли дольше 7 дней?» Шаг 4: синтезирующий промпт на основе трёх предыдущих ответов → «Составь отчёт за неделю. Структура: ключевые результаты, проблемы, следующие шаги команды.»
Итог: 20–30 минут вместо 2–3 часов. Важно: человек остаётся принимающим решения — он проверяет отчёт, добавляет контекст, который не попал в источники, утверждает формулировки. Но не является компилятором и расшифровщиком.
Ещё один операционный сценарий — подготовка к встрече. Исходные материалы: протоколы предыдущих встреч (PDF), переписка по теме (текст), презентация с последней сессией (слайды). Задача: «Из этих материалов составь краткое вводное резюме для участников завтрашней встречи: что было решено на прошлой встрече, что остаётся нерешённым, какие вопросы вынесены на завтра.» Это работает с несколькими документами разных форматов в одном промпте.
Принцип, который объединяет все рабочие цепочки: один источник правды, несколько промптов, каждый с чёткой задачей. Мультимодальность снимает ограничение на формат источника. Хороший промпт-инжиниринг определяет, что именно из этого источника нужно.
Практикум 5.Б: Создание контент-кита из одного материала
Задача: из одного исходного материала получить три разных формата контента.
Что делать:
1. Выберите исходный материал — любой из: запись своего выступления или учебной презентации (аудио или видео, 5–15 минут); статья из профессионального издания (PDF или текст); любая запись лекции, интервью или подкаста.
2. Если исходник — аудио/видео: сначала получите транскрипт через мультимодальную модель или отдельный сервис транскрипции.
3. Сформулируйте три задачи последовательно:
Задача А (на основе транскрипта/текста): «Выдели 5–7 ключевых тезисов этого материала — каждый в одном предложении, без вводных слов типа "автор говорит" или "в материале рассматривается".»
Задача Б (на основе тезисов из А): «Напиши Telegram-пост на основе этих тезисов. Объём — 900–1200 символов. Начни с самого неожиданного или важного инсайта — не с «В этом посте я расскажу». Тон — профессиональный, но живой, без канцеляризмов. Без хэштегов.»
Задача В (на основе тезисов из А): «Напиши краткое резюме этого материала для внутренней рассылки коллегам. Три абзаца: (1) о чём материал — одно предложение, (2) три ключевых вывода, (3) рекомендация — стоит ли ознакомиться и кому именно из команды.»
4. Сравните три результата: насколько разные тон и структура при одном источнике?
Ожидаемый результат: три готовых к использованию черновика в разных форматах — от одного исходника, без ручного переписывания.
На что обратить внимание: проверьте, не «съела» ли модель важные нюансы при суммаризации — особенно оговорки, ограничения, числа. Оцените тон поста: не слишком ли формальный или, наоборот, не слишком ли разговорный для вашего канала? Проверьте, что Задача Б действительно начинается с инсайта, а не с описания «о чём этот пост».
Типичные ошибки1. Промпт без задачи: «Посмотри на картинку»
В чём состоит: загрузить изображение или документ и написать «что здесь?», «проанализируй», «опиши». Модель возвращает поверхностное описание, потому что не знает, что именно вас интересует.
✓ Как правильно: каждый мультимодальный промпт должен содержать конкретную задачу («выдели задачи», «найди UX-проблемы», «сравни с версией 2»), ожидаемый формат вывода и, желательно, критерий качества.
2. Доверие транскрипции без проверки критических данных
В чём состоит: использовать расшифровку совещания как финальный документ без проверки имён, чисел и сумм. Числа — зона повышенного риска: «пятнадцать» и «пятьдесят» акустически близки. Суммы, даты, проценты — первые кандидаты на ошибку.
✓ Как правильно: при любой аудио-задаче с критическими числовыми данными — перекрёстная проверка по оригинальной записи или с участниками. Транскрипт — черновик, не финальный документ.
3. Игнорирование качества входных данных
В чём состоит: загрузить размытое фото, плохо освещённый документ или запись с сильным фоновым шумом и ожидать нормального результата. Мультимодальность не улучшает качество данных — она обрабатывает то, что получает.
✓ Как правильно: 30 секунд, потраченные на качественную фотографию доски при хорошем освещении, меняют результат принципиально. Для аудио — выносной микрофон или запись вблизи источника звука.
4. Не указывать поведение при нечитаемом контенте
В чём состоит: не задавать модели инструкцию, что делать с неразборчивыми фрагментами. По умолчанию модель начинает угадывать — и делает это уверенно. Уверенная ошибка в протоколе или расшифровке хуже честного пробела.
✓ Как правильно: всегда включать инструкцию «если нечитаемо — помечай [?]» для рукописного текста и аудио с плохим качеством. Для критических документов — обязательно.
5. Проверка только финального результата цепочки
В чём состоит: строить цепочку из 4–5 шагов (аудио → транскрипт → тезисы → пост → рассылка) и проверять только финальный результат. Ошибка на раннем этапе — например, неверная расшифровка ключевого решения — проходит через всю цепочку и размножается.
✓ Как правильно: проверять каждый значимый промежуточный шаг. Транскрипт и ключевые тезисы — обязательные точки контроля, прежде чем строить на них дальнейшее.
Кейс 2026: HR-команда — скрининг 200 резюме в PDF за 53 минуты
Контекст: региональный ретейлер объявил набор на 12 должностей — от специалистов по закупкам до категорийных менеджеров. За 72 часа поступило 214 резюме в формате PDF. HR-директор и два специалиста должны были провести первичный скрининг до конца рабочего дня.
Стандартный процесс: ручной просмотр одного резюме — 3–5 минут при вдумчивом чтении. 214 резюме × 4 минуты = примерно 14 часов командного времени только на первичный просмотр. При трёх сотрудниках — около 5 часов каждого.
Мультимодальный подход: команда разработала единый промпт-шаблон. Каждое резюме подавалось в мультимодальную модель как PDF-файл с одним промптом: «Это резюме кандидата на позицию категорийного менеджера в ретейл. Критерии — обязательные: опыт от 3 лет в категорийном менеджменте или закупках, работа с ассортиментной матрицей; желательные: опыт в FMCG, знание 1С или ERP; стоп-факторы: полное отсутствие опыта в ретейле или дистрибуции. По каждому резюме выдай: (1) соответствие обязательным критериям — да/частично/нет; (2) желательные критерии, которые есть; (3) стоп-факторы — есть/нет; (4) рекомендация — пригласить/рассмотреть/отклонить; (5) обоснование в 2–3 предложениях.»
Результат: 214 резюме обработаны за 38 минут машинного времени + 15 минут на организацию процесса. Итого 53 минуты вместо 14 часов. Модель рекомендовала 34 кандидата к приглашению, 51 — к дополнительному рассмотрению, 129 — к отклонению. HR-директор проверил 34 «приглашённых» за 40 минут. Скорректировал 3 решения. Общая погрешность первичного скрининга — около 9%.
Ограничения, которые команда зафиксировала: резюме с нестандартной структурой (дизайнерские макеты, инфографика вместо текста) давали менее надёжный результат — модель иногда пропускала блоки. Самооценочные формулировки («стрессоустойчив», «командный игрок») модель правильно игнорировала — в этом смысле скрининг получился даже чище человеческого. Выборочная перепроверка отклонённых (каждое пятое) нашла 2 кандидата, которых стоило рассмотреть.
Вывод: мультимодальный скрининг не заменяет HR-экспертизу — он перемещает её в правильное место. Специалист оценивает 34 кандидата вдумчиво вместо того, чтобы механически просматривать 214. Экономия: около 12 часов командного рабочего времени на одну волну найма.
Контрольные вопросы1. Вам нужно проанализировать 50-страничный договор с партнёром и выделить все условия, которые могут создать риски для вашей компании. Опишите мультимодальный промпт для этой задачи: что именно вы зададите модели, какой формат вывода запросите и как будете верифицировать ответ?
2. Ваш коллега предлагает использовать расшифровку совещания, сделанную мультимодальной моделью, как официальный протокол без дополнительной проверки. Какие конкретные типы ошибок наиболее вероятны в этом документе и как бы вы выстроили процесс проверки, не перечитывая расшифровку целиком?
3. Вы строите рабочую цепочку: еженедельный операционный отчёт из трёх источников — таблица с KPI, аудиозаписи стендапов, скриншоты из CRM. Какие промежуточные точки контроля вы введёте в эту цепочку и почему именно эти?
4. Сравните два подхода к работе с фото доски после совещания: (А) промпт «Что написано на этой доске?» и (Б) промпт с детальными инструкциями по категоризации задач, решений и открытых вопросов с указанием формата Markdown. Объясните, почему результаты будут принципиально разными — не с точки зрения формата ответа, а с точки зрения практической применимости.
5. Определите одну задачу в вашей профессиональной деятельности, где данные существуют в нетекстовом формате: изображения, аудио, документы со сложной структурой. Опишите мультимодальный промпт для этой задачи, назовите потенциальные точки ошибки и укажите, как вы будете проверять качество результата.
Глава 6. Работа с документами и RAG
Часть III. Знания и данные
Учебные результаты: объяснить принцип RAG без погружения в математику; создать работающий ИИ-ассистент по папке документов без программирования; выстроить корпоративную базу знаний с ИИ-поиском; оценить, когда RAG помогает, а когда создаёт иллюзию работы.
6.1 Почему языковые модели плохо знают ваши данные
Языковая модель обучена на огромном корпусе публичных текстов. Она знает, что такое факторинг, как выглядит типовой договор поставки и какие пункты в нём бывают проблемными. Она не знает, что в вашей конкретной компании факторинг согласуется через казначейство, а не через юридический отдел, что в договоре с ключевым поставщиком есть нестандартный пункт 11.3 о форс-мажоре, который однажды уже сыграл против вас, и что внутренний регламент 2024 года изменил порядок подписания на трёх уровнях согласования вместо двух.
Это фундаментальное ограничение, а не баг. Модель была обучена один раз на данных, которые существовали до определённого момента. Ваши внутренние документы в этот корпус не входили — и войти не могут, потому что они конфиденциальны. Разрыв между «знаниями о мире вообще» и «знаниями о нашей конкретной ситуации» — именно то, что делает языковую модель без дополнительной настройки неприменимой для большинства реальных корпоративных задач.
Это проявляется в двух режимах. Первый — модель просто не знает нужной информации и либо честно признаёт это, либо галлюцинирует «правдоподобный» ответ на основе общих паттернов. Второй — модель знает предметную область достаточно хорошо, чтобы дать убедительный ответ, который, однако, не соответствует вашим конкретным условиям: не вашим нормативам, не вашим договорённостям, не вашей версии регламента. Второй режим опаснее, потому что ошибку труднее заметить.
Языковая модель, отвечающая на вопрос о вашем внутреннем регламенте без доступа к нему, работает по аналогии с публично известными регламентами той же отрасли. Ответ будет правдоподобным. Он не будет вашим.
6.1.2 Устаревание: модель обучена до определённой датыУ каждой языковой модели есть дата отсечения данных (knowledge cutoff) — момент, после которого новые факты в обучающий корпус не попадали. Для практических задач это означает: законодательные изменения, новые стандарты, актуализированные нормы, свежие судебные решения, последние версии внутренних политик — всего этого в модели нет.
Типичные последствия для работы с документами: модель цитирует устаревшую редакцию закона; ссылается на норматив, который был отменён или изменён; предлагает формулировку, которая перестала быть актуальной. Чем быстрее меняется область — налоговое законодательство, технические регламенты, медицинские протоколы — тем выше риск устаревания. Юрист, использующий модель для работы с договорами без актуальной базы, рискует пропустить поправку, принятую полгода назад.
Решение этой проблемы — не в более частом обновлении модели (это технически дорого и в любом случае не решает вопрос с частными данными), а в механизме, который даёт модели доступ к актуальным документам в момент ответа на вопрос. Именно об этом механизме — RAG.
6.1.3 Конфиденциальность: почему нельзя просто загрузить всё в облакоПервый импульс пользователя, который хочет, чтобы ИИ знал корпоративные документы, — загрузить их в облачный сервис. Интуитивно понятно, технически просто. Проблема в том, что большинство корпоративных документов содержат данные, которые нельзя передавать за пределы организации без соответствующих правовых оснований.
Российское законодательство в части персональных данных (152-ФЗ) требует, чтобы обработка персональных данных граждан РФ происходила на серверах, расположенных на территории России. Если облачный сервис размещён за рубежом — передача туда HR-документов, данных клиентов, договоров с физическими лицами создаёт правовой риск. Дополнительно: коммерческая тайна, служебная тайна, данные, защищённые NDA — это категории, где передача в сторонний облачный сервис может нарушать условия соглашений или внутренние политики безопасности.
Практическая матрица: публичные документы — методические материалы, открытые регламенты, FAQ-документы — можно обрабатывать в большинстве облачных сервисов. Внутренние операционные документы без персональных данных требуют проверки условий сервиса и политики хранения данных. Документы с персональными данными — либо только российские облачные платформы (GigaChat API, YandexGPT API), либо локальное развёртывание. Документы под NDA или с грифом конфиденциальности — только локальные решения в контролируемом корпоративном контуре.
RAG как архитектура не решает правовой вопрос автоматически. Но она позволяет его решить, потому что предполагает развёртывание на инфраструктуре, которую контролирует организация. Это принципиальное отличие от подхода «скопировать и вставить в публичный чат».
Knowledge cutoff (дата отсечения) — момент времени, после которого новые данные не попадали в обучающий корпус модели. Модель не имеет информации о событиях, изменениях и документах, появившихся после этой даты.
6.2 Концепция RAG (Retrieval-Augmented Generation)
RAG — это архитектурный подход, при котором языковая модель перед генерацией ответа получает возможность «заглянуть» в релевантные документы. Не обучается на них заново, не запоминает их навсегда, а именно обращается в нужный момент. Это похоже на разницу между специалистом, который выучил всё наизусть, и специалистом, у которого под рукой актуальный справочник: второй при прочих равных надёжнее там, где справочник важнее памяти.
6.2.1 Что такое RAG — в двух словах и в деталяхRAG расшифровывается как Retrieval-Augmented Generation — генерация, дополненная извлечением. Смысл в трёх словах: сначала найти, потом сгенерировать. Когда пользователь задаёт вопрос, система сначала ищет в базе документов фрагменты, наиболее релевантные вопросу, затем передаёт их языковой модели вместе с исходным вопросом, и модель формирует ответ на основе найденного контекста — а не на основе того, что помнит из обучения.
Важно понять, что именно передаётся модели. Не весь документ целиком и не все документы из базы. Система извлекает только релевантные фрагменты — обычно несколько абзацев или страниц — и помещает их в контекст вопроса. Это позволяет работать с базой документов, которая во много раз превышает вместимость контекстного окна модели. База может содержать тысячи страниц; в контекст попадут только те 5–10 страниц, которые имеют отношение к конкретному вопросу.
Для пользователя это выглядит как обычный диалог с ИИ — задал вопрос, получил ответ. За кулисами произошло три шага: поиск, извлечение контекста, генерация ответа. Модель при этом может (и должна) ссылаться на источники: «Согласно регламенту 2024/03 (раздел 4.2)...» или «В договоре с поставщиком X указано (страница 7)...». Это принципиальное свойство хорошо настроенной RAG-системы — возможность проверить ответ по первоисточнику.
RAG (Retrieval-Augmented Generation, генерация с извлечением) — архитектура, при которой языковая модель получает релевантные фрагменты документов в момент ответа на вопрос, а не хранит эти данные в параметрах. Позволяет работать с актуальными, конфиденциальными и специализированными данными без переобучения модели.
6.2.2 Как работает поиск по документам: индексация, эмбеддинги, семантический поискЧтобы понять, почему RAG находит нужные фрагменты, нужно разобраться в механизме поиска. Обычный поиск по ключевым словам — как в Ctrl+F — ищет точные совпадения текста. Если документ содержит «расторжение договора», а пользователь спрашивает «как можно прекратить соглашение» — ключевой поиск не найдёт связи. Именно поэтому RAG-системы используют семантический поиск (semantic search), который ищет смысловое сходство, а не совпадение слов.
Основа семантического поиска — векторные представления, или эмбеддинги (embeddings). Каждый фрагмент текста преобразуется в числовой вектор — массив из сотен чисел — который кодирует смысловое содержание этого фрагмента. Тексты с похожим смыслом получают близкие векторы, даже если написаны разными словами. «Расторжение договора», «прекращение соглашения», «выход из контракта» — в пространстве эмбеддингов это близкие точки.
Когда пользователь задаёт вопрос, вопрос тоже преобразуется в вектор. Система вычисляет расстояние от вектора вопроса до векторов всех фрагментов в базе и возвращает те фрагменты, векторы которых ближе всего к вектору вопроса. Это происходит за миллисекунды — специализированные векторные базы данных оптимизированы именно для этой операции.
Процесс подготовки базы называется индексацией. Документы загружаются, разбиваются на фрагменты подходящего размера (чанки, chunks) — обычно по несколько сотен слов с небольшим перекрытием — каждый фрагмент преобразуется в эмбеддинг и сохраняется в векторной базе. Это делается один раз; потом при каждом запросе происходит только поиск по готовому индексу.
Разбиение на чанки — тонкий момент, который сильно влияет на качество поиска. Слишком маленькие чанки (одно предложение) теряют контекст: одно предложение, вырванное из смысловой группы, часто непонятно. Слишком большие чанки (целая глава) снижают точность поиска: в большом фрагменте много разных тем, и он «относится ко всему понемногу». Оптимальный размер зависит от типа документов: для нормативных актов — один раздел, для технической документации — один процедурный шаг, для деловой переписки — одно письмо.
Пример: корпоративная база содержит 200 регламентов по 10–30 страниц каждый. При индексации каждый регламент разбивается на фрагменты по 400 слов с перекрытием 50 слов. Итого около 15 000 фрагментов. При вопросе пользователя система за 80–150 мс находит 5–8 наиболее релевантных фрагментов и передаёт их модели. Модель отвечает на основе этих фрагментов, указывая источник. Всё взаимодействие — 3–6 секунд.