Вы читаете книгу «Сверхпродуктивность с искусственым интеллектом: От первого промпта до собственной системы агентов» онлайн

Предисловие

Сверхпродуктивность с искусственым интеллектом: Практическое руководство по ИИ: от первого промпта до системы агентов

Предисловие

Эта книга пишется в 2026 году — в момент, когда ИИ перестал быть экзотикой и стал частью рабочей среды. Языковые модели встроены в текстовые редакторы, почтовые клиенты, корпоративные системы и мессенджеры. Вопрос больше не «использовать ли ИИ», а «насколько осознанно».

Большинство людей застряли на уровне чат-бота: задали вопрос, получили ответ, закрыли вкладку. Между этим и полноценной системой работы — пропасть, которую не перепрыгнуть случайными экспериментами. Книга строит мост.

* * *

Что внутри

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

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

* * *

Про российский контекст

Большинство книг по ИИ написаны для западного читателя с западным набором инструментов. Эта — нет. Здесь также разобраны и отечественные модели; учтено законодательство о персональных данных; описаны инструменты, реально доступные в России в 2026 году.

Там, где зарубежные решения недоступны или нецелесообразны, предложены альтернативы. Там, где они работают — они описаны честно, без замалчивания.

* * *

Главная идея

ИИ не заменяет специалиста. Он заменяет специалиста без ИИ.

Человек с выстроенной системой закрывает задачи, которые раньше требовали команды. Не потому что он умнее — а потому что он правильно делегирует. Этому и учит книга.

* * *

Как читать

Книга читается последовательно — каждая глава опирается на предыдущую. Если вы опытный пользователь, начните с диагностики в Главе 2: она покажет, с какого места имеет смысл стартовать.

Три трека для разной аудитории описаны в разделе «Как работать с учебником». Студентам рекомендован полный путь. Специалистам — акцент на Частях II–V. Руководителям — Части I, VI и VII плюс профессиональные кейсы.

Практикумы — не опциональный бонус. Без них книга даёт знания, но не навык. Разница между знанием и навыком здесь принципиальна: ИИ-грамотность проявляется только в действии.

Инструмент готов. Осталось научиться им пользоваться.

Москва, 2026

Глава 1. Что такое современный ИИ и почему он изменил всё

Часть I · Фундамент

Учебные результаты: объяснить принцип работы LLM; назвать ≥5 актуальных инструментов; составить личную карту инструментов.

Если вы начнёте изучать любую технологию с вопроса «как ею пользоваться», вы рискуете стать её заложником. Человек, который знает только кнопки, теряет ориентацию при каждом обновлении интерфейса. Человек, который понимает принцип работы, адаптируется к любому интерфейсу. Эта глава — о принципе.

Речь не о том, чтобы «разобраться в ИИ» в абстрактном смысле. Речь о конкретной рабочей модели: почему языковые модели ведут себя именно так, откуда берутся ошибки и неожиданные успехи, какие инструменты реально доступны в 2026 году и как не попасть в ловушку расхожих заблуждений. Без этой базы даже хорошие промпты будут работать вслепую.

1.1 Краткая история: от правил к нейросетям

История ИИ — это история трёх принципиально разных ответов на один вопрос: как сделать так, чтобы компьютер вёл себя «умно»? Каждый ответ доминировал в своё время, у каждого были реальные успехи и реальные потолки. Понять эту эволюцию — значит понять, почему нынешние модели устроены именно так, а не иначе.

1.1.1 Символьный ИИ и экспертные системы

Первый подход, господствовавший с 1950-х по 1980-е годы, исходил из простой идеи: знания можно записать в виде правил. Если пациент — мужчина старше 40 лет, у него повышенное давление и одышка — вероятен сердечный приступ. Экспертные системы типа MYCIN (диагностика инфекций, 1972) или XCON (конфигурирование компьютеров, 1980) работали именно так: специалисты формализовали свои знания в тысячи правил «ЕСЛИ — ТО», программисты их кодировали.

Эти системы показывали впечатляющие результаты в узких областях. Но у них был фундаментальный изъян: они не умели справляться с тем, что выходило за рамки прописанных правил. Реальность богаче любого набора правил — и эти системы раз за разом разбивались о пограничные случаи, которые их создатели не предусмотрели. К 1987 году рынок экспертных систем рухнул: затраты на поддержку и обновление правил превышали выгоду от автоматизации.

1.1.2 Машинное обучение: когда модель учится сама

Второй подход перевернул логику: вместо того чтобы писать правила, дайте компьютеру много примеров и позвольте ему самому найти закономерности. Именно это делает машинное обучение (machine learning). Вместо правила «спам, если в тексте есть слово «выиграли»» — тысячи примеров спама и не-спама, из которых алгоритм сам извлекает признаки.

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

1.1.3 Глубокое обучение и революция 2010-х

Третий подход снял и это ограничение. Глубокое обучение (deep learning) — это многослойные нейронные сети, которые сами учатся извлекать признаки из данных, не нуждаясь в ручном проектировании. Идею нейросетей предложили ещё в 1940-х, но до 2010-х она оставалась маргинальной: не хватало вычислительных мощностей и данных.

В 2012 году сеть AlexNet выиграла конкурс ImageNet с результатом, который превзошёл второе место на 10 процентных пунктов. Это был статистический шок: такого разрыва никто не ожидал. С этого момента глубокое обучение стало доминирующей парадигмой в распознавании изображений, речи, игре в шахматы и го. Когда AlphaGo в 2016 году обыграл Ли Седоля — одного из лучших игроков в мире — это была победа не правил, а обученной нейросети.

1.1.4 Трансформеры и появление языковых моделей

В 2017 году исследователи Google опубликовали статью «Attention Is All You Need» — и предложили архитектуру трансформер (transformer). Ключевое изобретение — механизм внимания (attention): способность сети при обработке каждого слова учитывать весь контекст предложения, взвешивая важность каждого другого слова. До этого языковые модели обрабатывали текст последовательно — слово за словом, быстро теряя контекст длинных фрагментов. Трансформер обрабатывает весь текст параллельно.

Это открыло путь к масштабированию: чем больше данных и вычислений — тем лучше модель. GPT-1 (2018) обучился на книгах. GPT-2 (2019) — на текстах из интернета, и его авторы поначалу отказались публиковать полную версию, опасаясь злоупотреблений. GPT-3 (2020) с 175 миллиардами параметров продемонстрировал то, что назвали «эмерджентными способностями»: модель стала делать вещи, которым её не учили явно — переводить, решать задачи по аналогии, писать код. С этого момента языковые модели перестали быть инструментом для специализированных задач и стали общим инструментом для работы со смыслом.

Определение: большая языковая модель (LLM)

Большая языковая модель (large language model, LLM) — нейронная сеть трансформерной архитектуры, обученная на массиве текстовых данных (как правило, от сотен гигабайт до нескольких терабайт) с целью предсказывать следующий токен в последовательности. «Большая» означает от нескольких миллиардов параметров и выше. Параметры — это числовые веса связей между нейронами, которые настраиваются в процессе обучения.

1.2 Как работает большая языковая модель (без математики)

Понимание механики LLM на уровне пользователя — не академическое упражнение. Это прямая карта того, где модель надёжна, а где ненадёжна, почему повторный запрос даёт другой ответ и почему длинный разговор деградирует. Каждый из следующих принципов имеет практическое следствие.

1.2.1 Токены, вероятности и предсказание следующего слова

LLM не читает текст словами — она работает с токенами (tokens). Токен — это фрагмент текста, обычно от одного символа до нескольких букв или целого короткого слова. Слово «продуктивность» может быть разбито на несколько токенов; английское «cat» — скорее всего один. Это техническая деталь, но у неё есть следствие: модель «считает» не слова, а токены, и в нестандартных задачах подсчёта слогов или букв легко ошибается.

Работа модели — это итеративное вычисление вероятностей. На каждом шаге модель смотрит на всё, что написано до сих пор (контекст), и выбирает следующий токен на основе распределения вероятностей по всему словарю. Параметр температура (temperature) регулирует, насколько детерминировано это семплирование: при низкой температуре модель почти всегда выбирает наиболее вероятный токен, при высокой — чаще выбирает «неожиданные» варианты. Именно поэтому один и тот же промпт даёт разные ответы при разных запросах — это не случайность и не баг, это функция.

Важнейшее следствие: модель предсказывает «правдоподобный продолжатель текста», а не «правдивый ответ». Она не знает правды — она знает, что было написано в текстах, на которых её обучили. Если в обучающих данных что-то написано неверно, но написано часто, — модель будет уверенно воспроизводить ошибку.

1.2.2 Что такое «понимание» для модели — и понимает ли она вообще

Этот вопрос продолжает вызывать споры среди исследователей, но для практика важна прагматическая позиция. LLM демонстрируют поведение, которое функционально неотличимо от понимания в большом классе задач: анализ аргументации, переформулировка сложных концепций, нахождение аналогий, перенос знаний между областями. При этом они демонстрируют провалы, которых не бывает у людей с реальным пониманием: могут блестяще объяснить принцип математической задачи и ошибиться в её численном решении; могут описать протокол действий в чрезвычайной ситуации и «не заметить», что описали нечто опасное.

Рабочая формула: считайте, что модель понимает контекст и семантику — но не понимает мир. Она знает, как слова связаны друг с другом, но не имеет прямого опыта взаимодействия с реальностью. Из этого следует конкретное правило: в задачах, где нужно рассуждать о мире (числа, причинно-следственные связи, факты), — проверяйте. В задачах, где нужно работать с текстом (перефразировать, структурировать, адаптировать стиль), — доверяйте значительно больше.

Важно: модель не «думает» во время вашего разговора

LLM не накапливает знания в процессе диалога с вами. Когда разговор заканчивается — всё, что было сказано, исчезает. Модель не «запомнила» ваши предпочтения, не «научилась» на вашей обратной связи. Всё, что она знает о вас в данный момент — это текст текущего контекстного окна. Если вы хотите персонализированного ассистента — нужны внешние механизмы памяти (о них в Главах 6 и 9).

1.2.3 Контекстное окно: память, которая исчезает

Контекстное окно (context window) — это максимальный объём текста, который модель может «видеть» одновременно при генерации ответа. Всё, что произошло в диалоге до начала текущего окна, для модели не существует. В 2022 году стандарт был около 4 000 токенов (примерно 3 000 слов). В 2024–2025 годах ведущие модели перешли к 128 000–200 000 токенов, а некоторые достигли 1 миллиона и более.

Практическое следствие: чем длиннее диалог, тем больше риск, что ранние инструкции и детали «вытеснятся» из фокуса внимания модели. Исследования показывают, что модели хуже удерживают информацию из середины длинного контекста, чем из его начала и конца — эффект, известный как «потеря в середине» (lost in the middle). Это не значит, что нужно избегать длинных диалогов — но это значит, что ключевые инструкции лучше повторять или выносить в системный промпт.

1.2.4 Почему одна и та же модель даёт разные ответы

Три причины разной реакции на одинаковый промпт. Первая — стохастичность семплирования: при ненулевой температуре каждый запрос — это новое случайное блуждание по пространству вероятностей. Вторая — чувствительность к формулировке: порядок слов, наличие или отсутствие знаков препинания, конкретность контекста — всё это смещает распределение вероятностей. Небольшое изменение промпта может дать принципиально другой ответ. Третья — дообучение с подкреплением на основе обратной связи от людей (RLHF): модель не просто предсказывает следующий токен, она дополнительно обучена давать «предпочтительные» ответы — по критериям безопасности, полезности, честности. Это иногда конфликтует с буквальным следованием промпту.

Отсюда практический вывод: вариативность — нормальное свойство инструмента, а не дефект. Если вам нужен воспроизводимый результат — используйте параметр температуры 0 там, где интерфейс его предоставляет, и фиксируйте успешные промпты для повторного использования.

1.3 Ландшафт ИИ-инструментов в 2026 году

Карта инструментов 2026 года не похожа на карту 2022 года настолько же, насколько карта мобильных приложений 2012 года не похожа на 2007-й. Появились новые категории, некоторые пионеры потеряли лидерство, граница между «ИИ-продуктом» и «обычным приложением» практически стёрлась. Ориентироваться в этом ландшафте удобнее через уровни: базовые модели, их надстройки и встроенный ИИ в знакомых инструментах.

1.3.1 Глобальные модели: поколения и возможности

К 2026 году зрелый рынок LLM — это несколько семейств моделей, конкурирующих по разным осям: возможности, скорость, цена, политика работы с данными. OpenAI, Anthropic, Google и т.д. — каждый из них предлагает линейку от быстрых и дешёвых «рабочих лошадок» до флагманских моделей для сложных задач. Важно понимать: все флагманские модели 2026 года умеют работать с текстом, кодом, изображениями, таблицами, часто — с аудио и видео. Разница между ними — в качестве рассуждений, точности, скорости и ограничениях.

Ключевое изменение по сравнению с 2023–2024 годами: модели приобрели способность рассуждать (reasoning) перед ответом. Флагманские модели теперь могут тратить «вычислительное время» на обдумывание задачи, прежде чем выдать финальный ответ. Это принципиально улучшило качество решения сложных математических, логических и многошаговых задач. Для пользователя это означает, что на сложных задачах выгоднее дождаться «думающей» модели, чем сразу получить быстрый и ошибочный ответ.

1.3.2 Российская экосистема: GigaChat, YandexGPT, GigaCode и другие

Российский рынок языковых моделей к 2026 году сформировал собственные конкурентоспособные решения. Два главных игрока — Сбер с семейством GigaChat и Яндекс с семейством YandexGPT. Оба предлагают API, потребительские интерфейсы и корпоративные решения.

GigaChat развивался как общая языковая модель с акцентом на русскоязычный контент и интеграцию в продукты Сбера (СберЗвук, SaluteDevices, корпоративные системы). К 2026 году линейка включает базовые, профессиональные и специализированные версии. Важная особенность для корпоративного сектора — возможность развёртывания в закрытом контуре, что снимает вопросы передачи данных за пределы России.

YandexGPT интегрирован в экосистему Яндекс 360: он работает в Яндекс Браузере (встроенный ассистент Алиса), в облачных сервисах, почте и календаре. GigaCode — специализированная модель для работы с кодом от Сбера — конкурирует с GitHub Copilot в задачах разработки. Экосистема VK активно развивает ИИ-инструменты внутри собственных продуктов, хотя к 2026 году они менее зрелы для корпоративного использования.

Пример: выбор модели под задачу

Юрист готовит анализ договора. Если документ содержит персональные данные клиентов — российский закон требует обработки на серверах в РФ, и выбор очевиден: GigaChat или YandexGPT в корпоративной версии. Если документ — обезличенный шаблон международного контракта и нужно максимальное качество юридического анализа — можно рассмотреть глобальные модели, убедившись в соответствии политике организации.

1.3.3 Специализированные модели: код, изображения, аудио, видео

Параллельно с общими языковыми моделями существуют специализированные. Для кода: GitHub Copilot и его конкуренты, интегрированные в IDE и обученные на миллиардах строк публичного кода. Для изображений: Midjourney, Stable Diffusion, DALL-E, Kandinsky (российская разработка) — генерация по текстовому описанию, редактирование, расширение кадра. Для аудио: модели транскрипции речи (Whisper и его аналоги), синтез голоса с заданными характеристиками. Для видео: к 2026 году генерация видео достигла качества, пригодного для маркетинговых материалов, хотя профессиональное кино-производство ещё требует доработки.

Тенденция 2025–2026 годов — слияние специализированных возможностей в мультимодальные системы. Флагманские LLM теперь умеют не только анализировать изображения, но и генерировать их; не только транскрибировать речь, но и говорить. Выбор между специализированной и универсальной моделью — вопрос баланса: специализированная даёт лучшее качество в своей нише, универсальная — бесшовный опыт в одном интерфейсе.

1.3.4 Локальные модели: когда данные нельзя отдавать в облако

Для задач с конфиденциальными данными (медицинские записи, персональные данные, коммерческая тайна) существуют локальные модели — те, что работают на оборудовании организации или пользователя без отправки данных во внешние сервисы. С 2023 года подобные модели достигли качества, практически сопоставимого с облачными моделями предыдущего поколения.

Такие инструменты позволяют запустить языковую модель на обычном ноутбуке с 16–32 ГБ оперативной памяти. Качество будет ниже, чем у облачных флагманов, но для многих задач — анализ внутренних документов, черновики текстов, кодовые помощники — этого вполне достаточно. Российские организации всё активнее внедряют локальные решения в связке с российскими моделями — в рамках политики импортозамещения и требований регуляторов.

1.3.5 ИИ внутри привычных инструментов: Word, Excel, браузер, почта

Самое важное изменение 2025–2026 годов для нетехнического пользователя — ИИ перестал быть отдельным приложением, которое нужно открывать. Он встроен. Microsoft Copilot работает внутри Word, Excel, Outlook и Teams — напрямую с вашим документом, письмом, таблицей. Google Gemini встроен в Google Docs и Gmail. Яндекс Браузер с Алисой предлагает ИИ-ассистента прямо на любой веб-странице. Notion, Confluence, Figma, 1С — практически все корпоративные инструменты к 2026 году имеют встроенные ИИ-функции.

Это меняет точку входа: для большинства специалистов первый контакт с ИИ происходит не через ChatGPT или специализированный чат, а через кнопку «Улучшить текст» в почтовом клиенте. Важно понимать: встроенный ИИ — это та же языковая модель под капотом, просто с узким интерфейсом. Всё, что вы узнаете о принципах работы с LLM в этой работе, применимо и к встроенным помощникам.

1.3.6 Карта выбора инструмента под задачу

Выбор инструмента определяется пятью факторами: тип задачи (текст, код, изображение, аудио, данные), требования к конфиденциальности данных, нужная скорость ответа, качественный порог и бюджет. Ни один инструмент не является лучшим по всем осям одновременно.

Практическое правило выбора модели

Для задач с любыми персональными данными, коммерческой тайной или данными, подпадающими под 152-ФЗ: только российские модели в корпоративной версии или локальное развёртывание. Для задач с обезличенными данными и максимально высоким качеством: используйте глобальные флагманы, сверившись с политикой организации. Для встроенных рабочих задач (почта, документы, таблицы): встроенный ИИ вашей экосистемы — самый быстрый путь, пусть и не самый мощный.

1.4 Распространённые заблуждения об ИИ

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

1.4.1 «ИИ знает правду» — миф о всезнании

Это самое опасное заблуждение с точки зрения практических последствий. Языковая модель — это не энциклопедия и не поисковик. Она генерирует текст, который статистически похож на правдоподобные утверждения по данной теме. Когда модель пишет «согласно исследованию Стэнфордского университета 2023 года...» — она не цитирует реальное исследование. Она генерирует фрагмент, который звучит как цитата из реального исследования, потому что именно так строятся похожие утверждения в обучающих данных.

Это явление называется галлюцинацией (hallucination). В Главе 2 мы разберём базовые сигналы ненадёжного ответа, в Главе 15 — системные методы верификации. Пока запомните одно правило: любое конкретное фактическое утверждение (число, дата, имя, ссылка) нуждается в независимой проверке перед использованием в работе.

1.4.2 «ИИ думает как человек» — миф о сознании

Языковые модели демонстрируют способности, которые мы привыкли считать признаками интеллекта: понимание контекста, гибкость, юмор, эмпатия в диалоге. Это создаёт ощущение присутствия собеседника. Однако за этим нет ни сознания, ни намерений, ни эмоций — только статистические паттерны, обученные имитировать такое поведение.

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

1.4.3 «ИИ заменит всех» — миф о полной автоматизации

Тезис о тотальной автоматизации появляется в публичном пространстве волнами при каждом технологическом скачке. История показывает, что автоматизация обычно трансформирует профессии, а не уничтожает их полностью. Телефонные операторы исчезли, но появились операторы call-центров. Стенографисты исчезли, но появились специалисты по транскрипции и редакторы.

ИИ 2026 года исключительно хорошо справляется с задачами, которые: хорошо определены, имеют однозначный критерий правильности, могут быть сформулированы как текстовый запрос, не требуют физических действий. Он плохо справляется с задачами, требующими уникального контекстного суждения, ответственности за последствия, долгосрочного планирования в нестабильной среде, физического взаимодействия с миром. Заменяются не профессии целиком — заменяются конкретные задачи внутри профессий.

1.4.4 «ИИ опасен сам по себе» — миф об автономной угрозе

Языковые модели 2026 года — это не агенты с собственными целями. Они не планируют, не инициируют действия по собственной воле и не имеют механизмов самосохранения. Существующие риски — реальные, но иного рода: дезинформация в масштабе, дипфейки, снижение когнитивной самостоятельности, утечка данных через облачные сервисы. Этим рискам посвящены Главы 15, 16 и 17.

Отдельная история — автономные агенты с инструментами (см. Главу 12): там действительно появляются системы, способные выполнять последовательности действий без участия человека в каждом шаге. Но и они работают в рамках, заданных разработчиком, и не обладают автономными целями.

1.4.5 «ИИ — это только для программистов» — миф о высоком пороге входа

В 2020 году для использования языковых моделей действительно требовались технические знания: API, Python, понимание параметров модели. Сегодня порог входа — это умение формулировать задачу в тексте. Если вы можете написать письмо, поставить задачу подчинённому или составить рабочий документ — вы уже владеете ключевым навыком. Всё остальное — техника улучшения этого навыка, и именно этому посвящена Часть II данного учебника.

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

Практикум 1.А: Первый диалог с тремя моделями — одна задача, три ответа, сравнение по пяти метрикам

Задача: сформировать первичное понимание различий между доступными вам моделями на одной конкретной задаче из вашей профессии.

Шаг 1 — Выберите реальную профессиональную задачу среднего уровня сложности. Примеры: «Напиши структуру отчёта по итогам квартала для моей отрасли», «Составь список ключевых рисков при запуске нового продукта в сегменте [ваша область]», «Объясни концепцию [X] для коллеги без опыта в этой области». Задача должна быть такой, чтобы вы могли оценить качество ответа — то есть из вашей профессиональной области.

Шаг 2 — Запустите один и тот же промпт (дословно, без изменений) в трёх разных моделях. Минимальный вариант: GigaChat + YandexGPT + одна зарубежная модель (при наличии доступа). Если доступ к зарубежным моделям ограничен — используйте разные версии доступных (например, базовую и профессиональную версию одной модели).

Шаг 3 — Оцените каждый ответ по пяти метрикам (оценка 1–5):

• Точность: насколько фактически корректен ответ в вашей оценке?

• Полнота: охвачены ли ключевые аспекты задачи?

• Структура: удобно ли читать и использовать ответ?

• Релевантность: насколько ответ применим именно к вашей ситуации?

• Неожиданные находки: есть ли в ответе что-то, что вы не ожидали и что оказалось полезным?

Шаг 4 — Зафиксируйте результаты в таблице (3 модели × 5 метрик) и напишите 2–3 предложения о том, какая модель показалась наиболее подходящей для данного типа задач и почему.

Ожидаемый результат: таблица сравнения + краткий вывод о предпочтительной модели для данного класса задач.

На что обратить внимание: модели могут давать принципиально разные структуры ответа на одну задачу. Обратите внимание не только на содержание, но и на то, насколько уверенно каждая модель формулирует утверждения — и насколько эта уверенность соответствует вашей оценке качества.

Кейс 2026: Менеджер по развитию федеральной розничной сети

Алексей — менеджер по развитию категории в розничной сети с 600+ магазинами. В его задачи входят: мониторинг конкурентов, подготовка категорийных обзоров для байеров, ответы на запросы поставщиков, участие в еженедельных планёрках. До активного использования ИИ он делил рабочее время примерно так: 40% — сбор и обработка данных, 30% — написание текстов и презентаций, 20% — коммуникации, 10% — анализ и стратегические задачи.

В марте 2025 года Алексей провёл эксперимент: в течение двух недель фиксировал каждую задачу длительностью более 30 минут и задавал себе вопрос «а мог бы ИИ ускорить это?». Вывод оказался неожиданным: 8 из 11 крупных задач содержали значительный текстовый или аналитический компонент, который можно делегировать.

Три месяца спустя картина изменилась. Категорийный обзор, который раньше занимал полный рабочий день, теперь готовится за 2–2,5 часа. Схема: загрузить данные по продажам в чат с ИИ, попросить выделить аномалии и сформулировать гипотезы, черновик раздела «выводы и рекомендации» написать вместе с моделью, финальная редактура — 20 минут. Ответы поставщикам на стандартные запросы Алексей теперь генерирует с помощью шаблонных промптов и проверяет, а не пишет с нуля. Подготовка к планёрке — краткое саммари по ключевым KPI — 15 минут вместо 40.

По итогам квартала Алексей взял на себя одну дополнительную категорию, объём которой раньше потребовал бы найма помощника. Расчётная экономия времени — около 8–10 часов в неделю. Из них примерно половина перераспределена на более глубокую аналитику и переговоры с поставщиками, вторая половина — на обучение и личные проекты.

Честный вывод: не всё пошло гладко. Первые три недели Алексей тратил больше времени, чем обычно, — приходилось переформулировать промпты, проверять факты, разбираться с галлюцинациями. Модель однажды уверенно написала данные о доле рынка, которые оказались неверными на 12 процентных пунктов. Система верификации — отдельный навык, который пришлось нарабатывать. Через месяц работа вошла в ритм.

Важно: ключевой урок кейса

Переход к продуктивной работе с ИИ не происходит за первые 20 минут. Период адаптации — 3–4 недели — во время которого производительность может временно падать. Это инвестиция, а не мгновенный результат. Те, кто прерывает использование в этот период (обычно после первой значимой ошибки модели), теряют эффект, который приходит позже.

Типичные ошибки новичка при первом знакомстве с моделью

Ошибка 1: «Одна модель — всё»

В чём: пользователь открывает один чат с одной моделью и убеждён, что теперь «работает с ИИ». Не сравнивает инструменты, не знает, где каждый из них силён.

Как правильно: потратьте один рабочий день на сравнение двух-трёх доступных моделей на реальных задачах. Разница в качестве на конкретной профессиональной задаче может быть значительной. Разные модели имеют разные сильные стороны: одна лучше структурирует длинный текст, другая точнее в аналитических задачах.

Ошибка 2: Доверие к уверенному тону

В чём: модель даёт ответ с категоричными утверждениями («Исследования показывают...», «По данным 2024 года...»), пользователь принимает это как факт. Уверенный тон — не признак достоверности. LLM одинаково уверенно говорит о хорошо задокументированных фактах и о собственных галлюцинациях.

Как правильно: любое конкретное фактическое утверждение с числами, датами, именами, ссылками — проверяйте в первичном источнике. Особенно если оно будет использоваться в документе или публичном контексте.

Ошибка 3: Слишком общий первый запрос

В чём: первый промпт звучит как «Помоги мне с маркетингом» или «Напиши что-нибудь про наш продукт». Пользователь получает общий ответ, разочаровывается и делает вывод, что «ИИ не умеет делать полезное».

Как правильно: первый промпт должен содержать конкретный контекст (кто вы, какова задача), конкретный формат вывода (список, письмо, таблица) и конкретные ограничения (для какой аудитории, каким тоном). Этому посвящены Главы 3 и 4.

Ошибка 4: Игнорирование контекстного окна

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

Как правильно: для длинных сессий работы — начинайте новый диалог, повторяя ключевой контекст. Ключевые инструкции и параметры задачи — всегда в начале запроса.

Ошибка 5: Ожидание памяти между сессиями

В чём: пользователь возвращается к модели на следующий день и ожидает, что та «помнит» вчерашний разговор, его предпочтения, его проект. Разочарование, когда приходится объяснять всё заново.

Как правильно: готовьте «карточку контекста» — несколько абзацев о себе, своей задаче, предпочтениях и ограничениях. Вставляйте её в начало нового диалога. Инструменты с памятью существуют (некоторые платформы сохраняют историю и передают её модели), но полагаться на их наличие не стоит без проверки.

Контрольные вопросы к Главе 1

1. (Понимание) Объясните своими словами, почему языковая модель может уверенно давать неверные факты. Какой механизм порождает «галлюцинации»?

2. (Применение) У вас есть задача: подготовить аналитический отчёт на основе внутренних финансовых данных компании. Какие факторы вы рассмотрите при выборе между облачной глобальной моделью и российской корпоративной? Обоснуйте.

3. (Анализ) Сравните три подхода к созданию ИИ — символьный, машинное обучение, глубокое обучение. Для каждого приведите пример задачи, где он показывает себя лучше других, и объясните почему.

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

5. (Оценка) Вы читаете в новостях: «Новая модель ИИ прошла тест Тьюринга и признана мыслящей». Какие вопросы вы зададите, прежде чем принять это утверждение? Опираясь на содержание параграфа 1.2.2, сформулируйте три критических вопроса к такому заявлению.

→ К Главе 2: Мышление продуктивного пользователя ИИ

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

Глава 2. Мышление продуктивного пользователя ИИ

Часть I · Фундамент

Учебные результаты: применить модель человек+ИИ к своим задачам; построить карту задач с потенциалом ИИ; описать первые признаки галлюцинаций.

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

Большинство людей, начавших использовать ИИ, проходят через один и тот же цикл: первый энтузиазм от нескольких удачных ответов, разочарование при первой значимой ошибке, неустойчивое использование «когда не лень». Те, кто выходит за рамки этого цикла, как правило, сделали не технический шаг, а концептуальный: они переосмыслили логику делегирования задач. Именно эту логику мы разберём здесь.

2.1 Новая грамотность: что значит уметь работать с ИИ

Каждая волна инструментов создаёт новый слой грамотности, которая со временем становится базовой. Не уметь работать с ИИ в 2026 году — примерно то же самое, что не уметь пользоваться электронной почтой в 2005-м: пока ещё не критично, но с каждым месяцем всё заметнее как ограничение.

2.1.1 Аналогия с появлением текстовых редакторов и интернета

В 1995-м менеджеры могли обсуждать, зачем им электронная почта: «Есть обычная почта, факс». К 2000-м годам вопрос исчез. Инструмент казался дополнительным — до момента, пока не стал стандартом среды.

Ключевое наблюдение: люди, освоившие текстовые редакторы первыми, не просто «делали то же самое быстрее». Они начали делать то, чего раньше не делали вовсе — потому что стоимость итерации упала в разы. Исправить абзац раньше означало перепечатать страницу. Теперь это секунды. Точно так же языковая модель не просто ускоряет написание текста — она снижает стоимость первого черновика до почти нуля, что меняет логику того, когда вообще стоит браться за задачу.

Практическое следствие этой аналогии: навык работы с ИИ не в том, чтобы «знать все возможности инструмента». Никто не изучал все функции Word перед тем, как начать использовать его. Навык — в способности формулировать то, что вам нужно, достаточно точно, чтобы инструмент понял задачу. И в умении оценить, хорошо ли задача выполнена.

2.1.2 Навык задавать вопросы как ключевая компетенция

Исторически умение правильно формулировать запросы было профессиональным навыком — юристы, аналитики, исследователи десятилетиями оттачивали точность постановки вопроса. ИИ не отменяет этот навык — он переносит его из элитной компетенции в массовую необходимость. Человек, который умеет чётко сформулировать, что ему нужно, получает от ИИ принципиально другой результат, чем тот, кто формулирует расплывчато.

Что конкретно означает «умение задавать вопрос» применительно к ИИ? Это четыре вещи одновременно: точность контекста (кто вы, в какой ситуации, что уже известно), ясность задачи (что именно должно получиться на выходе), критерии качества (как выглядит хороший результат) и осознание ограничений (что точно не нужно включать). Главы 3 и 4 подробно разбирают технику. Здесь важен принцип: слабый результат ИИ — чаще проблема формулировки, чем проблема модели.

Пример: одна задача, два промпта

Слабый промпт: «Напиши письмо поставщику». Результат: общее вежливое письмо без конкретики, которое придётся полностью переписывать.

Сильный промпт: «Напиши деловое письмо поставщику строительных материалов с просьбой предоставить скидку 7% на повторный заказ в связи с увеличением объёма. Тон: корректный, не требовательный. Длина: не более 150 слов. Письмо для российского B2B-контекста». Результат: готовый черновик, требующий 5 минут правки.

Разница — не в модели. Разница — в том, насколько подробно поставлена задача.

2.1.3 Разница между «использую ИИ» и «работаю вместе с ИИ»

Это различие определяет, получит ли пользователь 10% прироста эффективности или 100%. «Использую ИИ» — поведение человека, который иногда задаёт вопросы в чате и получает ответы. Пассивная позиция: запрос — ответ — принять или отвергнуть. «Работаю вместе с ИИ» — другой режим: итеративный диалог, в котором пользователь активно формирует контекст, направляет рассуждение модели, встраивает вывод в свой рабочий процесс.

Конкретная иллюстрация: аналитик работает над рыночным обзором. «Использую ИИ» выглядит так: задал вопрос «что происходит на рынке Х», получил общий текст, скопировал пару абзацев. «Работаю вместе с ИИ» выглядит так: загрузил пять отраслевых отчётов, попросил выделить противоречия между ними, уточнил интерпретацию конкретного тренда, попросил сыграть роль скептика и атаковать собственный вывод, финальный текст написал сам — но с принципиально иным качеством аналитики за счёт итерации. Время на задачу — сопоставимо. Глубина результата — несопоставима.

2.2 Модель взаимодействия: человек + ИИ как система

Самый распространённый способ думать об ИИ — как о замене человека для конкретных задач. Эта рамка продуктивна для автоматизации рутины, но ограничивает мышление о более сложных применениях. Рамка «человек + ИИ как система» открывает другой класс задач — те, где ни человек, ни ИИ в отдельности не дали бы сопоставимого результата.

2.2.1 Что хорошо делает человек, что хорошо делает ИИ

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

У ИИ есть устойчивые преимущества перед человеком. Первое — скорость генерации текста: первый черновик за 15 секунд против 45 минут. Второе — широта обобщения: модель обучена на огромном объёме текстов и может предложить угол зрения, который вы никогда не встречали в своей области. Третье — терпеливость к повторению: модель одинаково качественно обрабатывает двухсотый однотипный документ, тогда как человек к концу дня неизбежно теряет внимание. Четвёртое — доступность в любое время: модель не устаёт, не болеет и не уходит в отпуск.

Человек делает лучше

Ситуативное суждение (неявный контекст)

Ответственность за результат

Долгосрочная память о контексте

Этическая оценка последствий

Физическое взаимодействие с миром

Уникальные профессиональные знания

ИИ делает лучше

Скорость первого черновика

Широта обобщений и аналогий

Стабильность при повторяющихся задачах

Доступность без перерывов

Одновременная обработка множества текстов

Многоязычная обработка без деградации

2.2.2 Зоны совместной работы и зоны исключительной ответственности человека

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

Зона делегирования: типовые тексты с ясными параметрами (стандартные ответы на запросы, черновики протоколов, первичная структура документа), транскрипция и резюмирование записей, первичная обработка данных с очевидными критериями. Главный критерий делегирования — цена ошибки в данной задаче достаточно мала, чтобы вы могли позволить себе ошибиться на первой итерации.

Зона совместной работы: аналитика со сложным контекстом, стратегические решения, творческие задачи с неявными критериями качества. Здесь ИИ работает как интеллектуальный партнёр — предлагает гипотезы, атакует аргументы, генерирует варианты, — а человек принимает решения.

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

Важно: зоны меняются вместе с задачей

Одна и та же задача «написать юридическое заключение» попадает в разные зоны в зависимости от контекста. Для внутреннего черновика на обсуждение — зона совместной работы. Для документа, который будет подписан и отправлен в суд, — зона исключительной ответственности человека, где ИИ максимум помогает с поиском прецедентов. Задача одна — зона разная.

2.2.3 Концепция усиленного интеллекта

Усиленный интеллект (augmented intelligence) — это рамка, в которой ИИ рассматривается не как замена человеческих когнитивных функций, а как их расширение. Аналогия: калькулятор не «заменил» способность считать — он позволил людям заниматься более сложной математикой, не тратя время на арифметику. Очки не «заменяют» зрение — они позволяют видеть лучше, чем без них.

Применительно к профессиональной работе это означает конкретное: задачи, которые раньше не брались из-за временных затрат, теперь становятся выполнимыми. Юрист, которому нужно было бы потратить неделю на изучение нового нормативного акта, теперь получает структурированный разбор за час и тратит оставшееся время на нюансы применения. Маркетолог, которому не хватало бюджета на 15 вариантов рекламного текста для A/B-тестирования, теперь генерирует их за полчаса. Не «то же самое быстрее», а «другое, что раньше было недоступно по цене».

2.2.4 Логика делегирования: не «как зайти в чат», а «что передать ИИ»

Самый практически ценный сдвиг в мышлении — переход от вопроса «как использовать ИИ» к вопросу «какие задачи из моего рабочего потока стоит делегировать». Это не технический вопрос. Это вопрос анализа собственной работы.

Три критерия задачи, которую стоит делегировать ИИ. Первый — задача формулируется текстом. Если вы можете написать задание подчинённому так, чтобы он её выполнил без дополнительных вопросов, — вероятно, можете написать и промпт. Второй — задача повторяется. Единоразовая уникальная работа редко стоит времени на конструирование промпта с нуля; повторяющаяся задача окупает шаблон с первых двух-трёх использований. Третий — цена ошибки на первой итерации невысока. Если черновик, требующий правки, лучше, чем пустой лист, — делегируйте.

Три критерия задачи, которую делегировать не стоит. Во-первых, задача требует уникального контекста, который слишком трудно передавать в промпте. Во-вторых, ошибка на первой итерации создаёт проблему (публикация, юридический документ, кадровое решение). В-третьих, сам процесс выполнения задачи развивает навык, который вам важно сохранить.

2.3 Психология работы с ИИ

Технические аспекты работы с ИИ часто обсуждаются, психологические — редко. Между тем именно психологические эффекты определяют, превратится ли инструмент в реальное усиление или, наоборот, создаст новые проблемы. Три из них — автоматизированное доверие, «синдром самозванца наоборот» и когнитивная разгрузка — стоит знать заранее, поскольку они возникают предсказуемо.

2.3.1 Эффект автоматизированного доверия и как его преодолеть

Автоматизированное доверие (automation bias) — когнитивный эффект, при котором люди склонны принимать ответы автоматизированных систем без критической проверки. Впервые описан применительно к системам автопилота: пилоты, доверявшие бортовому компьютеру больше, чем собственным показаниям приборов, допускали ошибки в нестандартных ситуациях. Применительно к LLM эффект проявляется в том же: уверенный, хорошо структурированный ответ модели снижает вероятность его проверки.

Механизм понятен: наш мозг интерпретирует качество оформления как сигнал достоверности. Текст без орфографических ошибок, с логичной структурой и профессиональным тоном воспринимается как написанный компетентным автором. LLM производит именно такой текст — независимо от его фактической точности. Это не свойство конкретной модели, это свойство всех современных языковых моделей: они оптимизированы на «правдоподобность», а не на «правдивость».

Конкретный способ противодействия — не «проверяй всё», что нереалистично, а «проверяй категории риска». Числа, даты, имена, цитаты, ссылки на источники — вот четыре категории, которые требуют проверки по умолчанию. Всё остальное — оценочно: чем выше ставка (документ для суда против внутренней заметки), тем глубже проверка.

Важно: красивое не значит правильное

LLM генерирует одинаково уверенный и хорошо отформатированный текст, когда пишет корректную статистику и когда галлюцинирует. Внешние признаки достоверности (структура, грамматика, профессиональный тон) не коррелируют с фактической точностью. Единственный надёжный критерий — проверка по первичным источникам для критически важных утверждений.

2.3.2 Синдром самозванца наоборот: «это сделал не я»

Это менее очевидный, но широко распространённый эффект. Когда профессионал с десятилетним опытом получает от ИИ текст, который выглядит лучше, чем то, что он написал бы сам, возникает дискомфорт: «Мне не следует предъявлять это как свою работу». Дискомфорт понятен, но логика неточна.

Профессиональная ценность — не в способности производить текст без помощи инструментов, а в способности задать правильную задачу, оценить качество результата, отвечать за него и применить его уместно. Когда финансовый директор использует Excel для составления финансовой модели, никто не говорит «это сделал Excel, а не я». Excel — инструмент вычисления; финансовый директор предоставил данные, логику, интерпретацию и ответственность. ИИ — инструмент генерации и структурирования текста; специалист предоставляет контекст, задачу, суждение о качестве и ответственность за использование.

Практический вопрос, который стоит себе задать: «Если бы этот результат оказался неверным — понял бы я это?» Если ответ «да» — значит, у вас есть профессиональное суждение, которое стоит за результатом. Если «нет» — это сигнал либо о необходимости более глубокой проверки, либо о том, что задача находится вне вашей компетенции.

2.3.3 Когнитивная разгрузка: польза и риски

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

Риск менее очевиден. Когнитивные навыки деградируют без практики — это установленный нейропсихологический факт. Если человек перестаёт писать тексты самостоятельно, его способность формулировать мысли на бумаге со временем ухудшается. Если перестаёт делать быстрые оценки в уме — теряет интуицию относительно порядка чисел. Это не аргумент против использования ИИ, но аргумент за осознанность: какие навыки для вас стратегически важны и требуют регулярной практики без ИИ-помощи?

Рабочее правило: разделяйте задачи на «рутинные операции» (делегировать ИИ без сожаления) и «навыкообразующие задачи» (делать самостоятельно или с минимальным ИИ-участием, чтобы поддерживать профессиональную форму). Для юриста рутинная операция — составление стандартного запроса; навыкообразующая — анализ сложного прецедента. Для преподавателя рутина — шаблон программы курса; навык — разработка сценария занятия с нестандартной аудиторией.

2.3.4 Как не утратить собственное мышление при активном использовании ИИ

Конкретная техника: «правило пустой страницы». Прежде чем открывать чат с ИИ, потратьте 5–10 минут на запись собственных мыслей по задаче — тезисно, без стилистической отделки. Это делает две вещи. Во-первых, принуждает вас сформулировать, что вы думаете, до того как ИИ начнёт влиять на ваши взгляды. Во-вторых, даёт вам точку отсчёта для оценки ИИ-ответа: вы видите, где модель совпала с вашим мышлением, где расширила его, а где вы с ней не согласны.

Второй инструмент — «техника несогласия»: после получения ответа ИИ намеренно формулируйте возражения, даже если ответ кажется верным. «С чем я не согласен в этом тексте?» «Что здесь упущено?» «Где я вижу это иначе?» Эта техника одновременно улучшает результат (вы находите реальные слабые места) и поддерживает критическое мышление.

Пример: правило пустой страницы в действии

Стратегический директор перед подготовкой ежеквартального обзора рынка сначала записывает от руки: три главных тренда, которые он видит, два риска, которые его беспокоят, один нестандартный вывод. Затем открывает ИИ с запросом на обзор. Сравнение своих заметок с ИИ-ответом даёт ему карту расхождений — именно в местах расхождений он находит либо слепые пятна в своём анализе, либо ошибки модели. Финальный обзор сильнее, чем любой из двух исходных.

2.4 Первое знакомство с ограничениями

Ограничения языковых моделей — не список досадных недостатков, а системные свойства технологии. Знание их заранее меняет реакцию: вместо разочарования при первой ошибке — предсказуемая проверка предсказуемых категорий риска. Главу 15 посвящена детальному анализу верификации; здесь — базовый рефлекс, который нужен уже сейчас.

2.4.1 Что такое галлюцинация и почему она неизбежна

Из Главы 1 вы помните: LLM предсказывает следующий токен на основе распределения вероятностей, а не извлекает факты из базы данных. Когда модель «не знает» ответа на фактический вопрос, она не говорит «я не знаю» (хотя современные модели часто так и делают на прямые вопросы). Она генерирует статистически правдоподобный ответ — фрагмент текста, который выглядит так, как выглядел бы правильный ответ. Это и есть галлюцинация.

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

2.4.2 Три быстрых сигнала ненадёжного ответа

Первый сигнал — точные числа без указания источника. Любое число, которое звучит конкретно («в 2024 году рынок вырос на 23,4%», «согласно исследованию, 68% пользователей...»), требует проверки. Модели часто генерируют правдоподобно выглядящие цифры там, где реальных данных нет. Второй сигнал — конкретные ссылки: названия статей, авторы, DOI, URL. Модель может сгенерировать ссылку, которая выглядит реальной, но не существует. Проверка здесь проста: пробуйте перейти по ссылке или найти источник. Третий сигнал — уверенный ответ на вопрос из узкоспециальной области или о недавних событиях. Если тема достаточно специфична, что вы сами не можете оценить правдоподобность ответа — это именно та ситуация, когда надо проверять.

Запомнить: три сигнала ненадёжного ответа

1. Конкретные числа и статистика без явного источника

2. Ссылки, цитаты, DOI, URL — проверяйте их существование

3. Уверенный ответ на узкоспециальный вопрос или о событиях после даты обучения модели

2.4.3 Базовый рефлекс верификации: перекрёстная проверка за 2 минуты

Для большинства рабочих задач не нужен полноценный фактчек — достаточно быстрой перекрёстной проверки. Алгоритм: берёте одно-два ключевых утверждения из ответа ИИ, которые кажутся наиболее важными или неожиданными, и проверяете их в независимом источнике. Для деловой информации — отраслевые базы данных, официальные сайты компаний. Для правовой информации — Консультант Плюс, Гарант, официальные тексты актов. Для научных утверждений — Киберленинка, Google Scholar, первичные публикации.

Два минуты — реалистичная оценка для быстрой проверки одного-двух ключевых фактов. Если ответ прошёл эту проверку, вероятность критических ошибок в остальной части значительно ниже. Если обнаружена ошибка — это сигнал проверить всё ответственное содержание более тщательно. Логика: одна обнаруженная галлюцинация повышает вероятность наличия других.

2.4.4 Зоны повышенного риска: числа, даты, имена, цитаты

Это четыре категории, где галлюцинации наиболее часты и наиболее опасны, потому что выглядят конкретно. Числа: рыночные данные, статистика, финансовые показатели, доли рынка. Даты: даты принятия законов, события, исторические факты (особенно если речь о точных датах, а не о десятилетиях). Имена: должности конкретных людей, авторство работ, состав советов директоров — всё это меняется, и модель может работать с устаревшими данными. Цитаты: прямые цитаты реальных людей могут быть созданы моделью без какого-либо реального высказывания.

Практическое правило для работы с этими категориями: не используйте числа, даты, имена и прямые цитаты из ИИ-ответа без проверки по первичному источнику. Это не значит, что ИИ бесполезен для таких задач — он полезен как инструмент поиска направления и структурирования. Но конкретные факты из этих четырёх категорий — всегда верифицировать.

2.5 Личный стиль работы с ИИ

Попытка следовать «правильному» сценарию использования ИИ, не вписанному в собственный рабочий контекст, — одна из причин, по которым люди бросают инструмент после первых недель. Продуктивная работа с ИИ персональна: она строится вокруг конкретных задач, конкретных профессиональных привычек и конкретного стиля мышления. Эта часть главы — о том, как найти свою точку входа.

2.5.1 Диагностика своих задач: где ИИ уже может помочь

Отправная точка — не «что умеет ИИ», а «что делаю я». Большинство профессионалов проводят значительную часть рабочего времени за операциями, которые являются явными кандидатами на ИИ-поддержку, но не осознают этого, потому что не смотрят на свою работу через этот фильтр. Неделя аудита меняет картину.

Аудит рабочей недели — это практикум 2.А в конце этого параграфа. Здесь дадим критерии оценки. Задача является сильным кандидатом на ИИ-поддержку, если: она связана с созданием или обработкой текста (написание, редактирование, резюмирование, структурирование), она повторяется хотя бы раз в неделю, первый черновик можно передать без критических последствий от ошибки, на неё уходит непропорционально много времени относительно её стратегической важности.

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

2.5.2 Типы пользователей и их сценарии

Можно выделить несколько характерных профилей входа в работу с ИИ. Не для классификации — для того, чтобы вы увидели, в каком профиле узнаёте себя, и выбрали соответствующую точку старта.

Создатель текстов — человек, значительная часть работы которого состоит из создания текстов: менеджер, маркетолог, преподаватель, консультант. Для него ИИ сразу даёт ощутимый эффект в качестве соавтора черновиков и редактора. Быстрая победа: первый черновик за 15 минут вместо двух часов. Риск: автоматизированное доверие к тексту, который «неплохо звучит».

Аналитик данных без кода — специалист, работающий с таблицами и отчётами, но не пишущий код. Для него ИИ открывает доступ к анализу данных через описание задачи на естественном языке — без формул и скриптов. Быстрый результат: анализ таблицы с поиском аномалий за 20 минут. Риск: принятие некорректной интерпретации данных без проверки.

Специалист с узкой экспертизой — юрист, врач, инженер, финансист. Для него ИИ наиболее полезен как инструмент структурирования и первичного поиска, но наиболее опасен в части специализированных фактов. Быстрый результат: первичный анализ документа по чек-листу критериев. Риск: доверие к галлюцинации в узкоспециальной области, которую сложно проверить.

Координатор и менеджер — человек, большую часть времени проводящий в коммуникациях, встречах, согласованиях. Для него ИИ наиболее ценен в подготовке к встречам, протоколировании и формулировке задач. Быстрый результат: структурированный протокол из записи встречи за 10 минут. Риск: потеря нюансов межличностных договорённостей, которые не были зафиксированы явно.

2.5.3 Построение первой личной карты инструментов

Карта инструментов — это живой документ, который вы будете обновлять по мере нарабатывания опыта. На старте достаточно простой структуры: задача → инструмент → тип использования (делегирование / совместная работа / информационный ресурс) → ключевые риски.

Практикум 2.Б в конце этой главы — пошаговое построение такой карты. Здесь — принципы. Карта должна быть конкретной: не «использую ИИ для текстов», а «черновики еженедельного отчёта → GigaChat Professional → делегирование → проверяю числа и ссылки перед отправкой». Карта должна быть честной: включайте задачи, которые вы попробовали и отказались делегировать, — с объяснением почему. Это столь же ценная информация. Карта должна обновляться: раз в месяц стоит смотреть, не изменилось ли что-то в доступных инструментах или ваших задачах.

Первая версия карты не должна быть исчерпывающей. Начните с трёх-пяти задач, которые занимают большую часть вашего времени. Хорошая карта инструментов для одного человека редко содержит более 10–15 позиций — всё остальное решается ситуативно.

Практикум 2.А: Аудит рабочей недели — таблица задач с оценкой потенциала автоматизации

Задача: за пять рабочих дней собрать данные о своих задачах и оценить потенциал ИИ-поддержки для каждой из них.

Шаг 1 — В конце каждого рабочего дня (или по ходу, если удобнее) записывайте все задачи, которым посвятили более 20 минут. Для каждой фиксируйте: название задачи, затраченное время, был ли это текст/анализ/коммуникация/что-то другое.

Шаг 2 — После сбора данных за неделю оцените каждую задачу по четырём критериям (оценка: высокий / средний / низкий потенциал):

• Доля текстовой работы в задаче (написание, редактирование, резюмирование)

• Частота повторения (ежедневно / еженедельно / редко)

• Цена ошибки на первом черновике (низкая / средняя / высокая)

• Доступность контекста для передачи в промпте (легко / затруднительно / невозможно)

Шаг 3 — Выберите три задачи с наивысшим суммарным потенциалом. Для каждой сформулируйте черновой промпт: кто вы, какова задача, какой формат нужен на выходе, какие ограничения.

Шаг 4 — Протестируйте хотя бы один из черновых промптов в доступной модели и зафиксируйте, насколько результат приблизился к тому, что вам нужно.

Ожидаемый результат: таблица с оценкой 15–20 задач + три черновых промпта + первый тест одного из них.

На что обратить внимание: задачи с «высокой ценой ошибки» не означают «не делегировать» — они означают «делегировать черновик с обязательной проверкой». Это разные вещи.

Практикум 2.Б: Личная карта ИИ-инструментов и первый шаблон проверки ответа

Задача: построить первую версию личной карты инструментов и создать персональный чек-лист верификации.

Часть 1 — Карта инструментов

Создайте таблицу с пятью столбцами: Задача | Инструмент | Тип использования | Ключевые риски | Статус (активно / тестирую / отказался).

Заполните минимум пять строк на основе результатов практикума 2.А или текущего опыта.

Для каждой строки: «Тип использования» — выберите из трёх вариантов: делегирование (ИИ делает, я проверяю), соавторство (итеративный диалог), справочник (ИИ как источник информации, решение за мной).

Часть 2 — Чек-лист верификации

Составьте персональный список из 4–6 вопросов, которые вы будете задавать себе перед использованием ИИ-ответа в работе. Обязательно включите:

• Есть ли в ответе числа, даты, имена или цитаты? Если да — проверил ли я хотя бы ключевые из них?

• Соответствует ли этот ответ тому, что я знаю о теме из других источников?

• Какова цена ошибки, если этот ответ окажется неверным?

Добавьте 1–3 специфических для вашей профессии вопроса (например, для юриста: «Актуальна ли ссылка на нормативный акт?»; для маркетолога: «Соответствуют ли данные о конкурентах реальности на сегодняшний день?»).

Ожидаемый результат: таблица карты (минимум 5 строк) + персональный чек-лист (4–6 вопросов).

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

Типичные ошибки при формировании рабочей модели с ИИ

Ошибка 1: «Всё или ничего»

В чём: пользователь либо пытается делегировать ИИ абсолютно все задачи (и разочаровывается при первых ошибках), либо использует его только для совсем простых вещей, не позволяя инструменту проявить реальный потенциал.

Как правильно: начать с трёх-пяти задач со средним потенциалом. Не самых тривиальных (там выигрыш незаметен), не самых критических (там риск ошибки высок). Ощутимый выигрыш в знакомой задаче — лучшая мотивация для расширения применения.

Ошибка 2: Игнорирование фазы адаптации

В чём: человек пробует ИИ несколько раз, не получает нужного результата и делает вывод «не работает». Адаптация к новому инструменту всегда требует времени: нужно научиться формулировать задачи, понять, где модель надёжна, выработать личный стиль взаимодействия.

Как правильно: зарезервировать под адаптацию минимум 3–4 недели активного использования (не «поиграть пять раз»). Качество работы с инструментом улучшается нелинейно: первые две недели — медленно и с разочарованиями, затем — скачок.

Ошибка 3: Перекладывание ответственности

В чём: «ИИ написал, я не виноват». Пользователь отправляет ИИ-ответ или ИИ-документ без критической проверки, и когда обнаруживается ошибка — считает, что ответственность с него снята. С профессиональной и юридической точки зрения — нет.

Как правильно: человек, подписывающий документ, несёт ответственность за его содержание независимо от того, каким инструментом он воспользовался при подготовке. ИИ — инструмент, как печатная машинка или Excel. Ответственность за результат — за автором.

Ошибка 4: Принятие «улучшенного» как «правильного»

В чём: человек пишет черновик, просит ИИ его улучшить, получает стилистически более гладкий текст — и принимает его без сравнения с оригиналом. Стилистическое улучшение может сопровождаться искажением смысла: модель переформулировала «ориентировочно 30%» как «более 30%», или заменила осторожную оценку на уверенное утверждение.

Как правильно: при использовании ИИ для редактирования своих текстов всегда сравнивайте версии по смысловому содержанию, а не только по стилю. Обращайте особое внимание на модальные слова («возможно», «по оценкам», «примерно») — именно они чаще всего меняются при «улучшении».

Ошибка 5: Статичная карта инструментов

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

Как правильно: раз в один-два месяца делайте краткий ретроспективный обзор: какие задачи добавились, где качество модели изменилось, где вы обнаружили новые риски или возможности. Карта инструментов — живой документ, а не зафиксированное решение.

Кейс 2026: Юрист, который обнаружил ошибку через месяц

Елена — старший юрист в юридической фирме, специализирующейся на корпоративном праве. Опыт работы — 11 лет. В начале 2025 года она начала использовать ИИ для первичного анализа договоров: загружала документ, просила выделить потенциально проблемные условия и несоответствия стандартной практике.

Первый месяц — без проблем и с ощутимым эффектом. Стандартный договор поставки, который раньше занимал полтора часа, теперь проходил первичный скрининг за 20 минут. Елена концентрировалась на нестандартных условиях, которые ИИ выделял как потенциально проблемные. Производительность выросла, клиенты получали документы быстрее.

На шестой неделе произошёл инцидент. Елена работала с договором аренды нежилого помещения. ИИ провёл анализ, не выделив проблем с условиями об ответственности арендатора. Елена ограничилась беглой проверкой и передала клиенту. Через три дня клиент обратился с вопросом о формулировке пункта об ответственности за ущерб — и именно тогда Елена при детальном прочтении обнаружила условие, которое существенно расширяло ответственность её клиента относительно рыночной нормы. ИИ не отметил его как проблему — вероятно, потому что формулировка была юридически корректной, хотя и невыгодной для арендатора.

Потери: час работы на исправление, репутационный дискомфорт перед клиентом, но без юридических последствий — договор ещё не был подписан. Главный урок, по словам Елены: «ИИ хорошо видит юридические аномалии — нарушения стандартных формулировок. Он плохо видит стратегическую невыгодность условий для конкретного клиента, потому что для этого нужно понимать контекст сделки, который я ему не даю».

Изменение подхода: Елена ввела дополнительный промпт — «Теперь оцени каждое условие с позиции арендатора: насколько оно выгодно/невыгодно по сравнению со стандартной практикой?» Добавила контекст о типе клиента и характере сделки в начало каждого запроса. Результат следующих трёх месяцев — ни одного пропущенного существенного условия.

Честный итог: инцидент потребовал пересмотра подхода, но не отказа от инструмента. Разница между «ИИ не работает» и «мой промпт недостаточен» — ключевая. После уточнения подхода Елена сохраняет экономию около 35–40% времени на первичный анализ договоров. Этот случай стал основой внутреннего стандарта фирмы: каждый юрист при использовании ИИ для анализа документов обязан включать в промпт контекст стороны, интересы которой он представляет.

Ключевой вывод кейса

ИИ анализирует текст. Стратегический контекст — интересы клиента, ситуацию сделки, баланс переговорных позиций — нужно передавать явно. Отсутствие «красных флагов» в ИИ-анализе не означает отсутствие проблем — оно означает отсутствие проблем в рамках переданного контекста.

Контрольные вопросы к Главе 2

1. (Применение) Опишите три задачи из вашей профессиональной практики. Для каждой определите зону: делегирование, совместная работа или исключительная ответственность человека. Обоснуйте критерии отнесения.

2. (Анализ) Коллега говорит: «Я получил от ИИ отчёт об исследовании рынка — всё чётко структурировано, написано профессионально, поэтому я сразу отправил его клиенту». Какие конкретные риски он допустил? Что следовало проверить перед отправкой?

3. (Применение) Используя технику «правила пустой страницы», опишите задачу из вашей работы, которую вы планируете делегировать ИИ. Сформулируйте: что вы напишете на «пустой странице» до обращения к модели, и как вы будете оценивать, где ответ ИИ совпадает с вашим мышлением, а где расходится.

4. (Оценка) Елена из кейса этой главы изменила подход после инцидента: стала добавлять контекст стороны в промпт. Предложите ещё два изменения в её рабочем процессе, которые снизили бы риск пропуска стратегически невыгодных условий — без радикального увеличения времени работы.

5. (Синтез) Один из аргументов против активного использования ИИ звучит так: «Если я буду делегировать написание текстов, я потеряю навык письма». Согласны ли вы с этим аргументом? Сформулируйте позицию, опираясь на концепцию когнитивной разгрузки и «навыкообразующих задач» из параграфа 2.3.3.

→ К Главе 3: Основы промпт-инжиниринга

Следующая глава переходит от философии к технике. Вы уже знаете, зачем формулировать задачу точно; теперь — конкретно как. Анатомия промпта, базовые техники, итеративный диалог — всё, что превращает «я задаю вопрос» в системный инструмент производительности.

Глава 3. Основы промпт-инжиниринга

Часть II · Язык взаимодействия: промпт-инжиниринг

Учебные результаты: сконструировать промпт по анатомии КЗФО (контекст–задача–формат–ограничения); провести итеративный диалог; собрать первый промпт-шаблон.

Из Главы 2 вы вынесли рабочее убеждение: слабый результат ИИ — чаще проблема формулировки, а не проблема модели. Эта глава — практический ответ на вопрос, как выглядит хорошая формулировка, из каких компонентов она состоит и как выстроить диалог, который с каждой итерацией движется к нужному результату, а не топчется на месте.

Промпт-инжиниринг (prompt engineering) — это не программирование. Это дисциплина точного технического задания на естественном языке. У хорошего промпта есть предсказуемая структура. Знание этой структуры сокращает путь от «хаотичного набора текста» до «воспроизводимого результата» с нескольких часов экспериментов до нескольких минут.

3.1 Что такое промпт и почему его формулировка так важна

Промпт — это не просто «запрос к ИИ». Это инструкция, которая задаёт контекст рассуждения модели, а не только тему ответа. Понимание этого различия является отправной точкой для систематического подхода.

3.1.1 Промпт как техническое задание

Представьте, что вы нанимаете фрилансера для выполнения задачи. Хорошее техническое задание включает: кто вы и что за проект, что именно нужно сделать, в каком формате сдать результат, какие ограничения учесть. Плохое ТЗ — это «напишите что-нибудь хорошее». Между этими двумя полюсами вся разница в качестве результата.

Языковая модель ведёт себя как очень быстрый, очень широкообразованный и абсолютно неинициативный исполнитель. Она не уточняет, не переспрашивает (если не запрограммирована на это), не догадывается о подразумеваемом контексте. Она работает строго с тем, что получила. Из этого следует прямое следствие: каждый элемент, который вы не указали явно, модель заполнит по умолчанию — своим суждением о «типичном» ответе на данный запрос. Иногда это совпадает с тем, что вам нужно. Часто — нет.

Чем точнее ТЗ, тем выше вероятность, что первый ответ модели будет либо готовым результатом, либо качественным черновиком. На практике это означает: 10 минут на составление промпта могут сэкономить 40 минут на переработку ответа.

3.1.2 Анатомия хорошего промпта: КЗФО

Большинство методологий промпт-инжиниринга сводятся к одной и той же идее, сформулированной разными словами. Здесь мы используем аббревиатуру КЗФО: Контекст — Задача — Формат — Ограничения. Это четыре компонента, каждый из которых решает отдельную проблему.

Контекст сообщает модели, кто вы, в какой ситуации и что уже известно. Без контекста модель выдаёт «среднестатистический» ответ на тему. С контекстом — ответ, привязанный к вашей конкретной ситуации. Задача формулирует, что именно нужно сделать. Не тему, а действие: «напиши», «проанализируй», «сравни», «выдели», «переформулируй». Формат описывает, как должен выглядеть вывод: объём, структура, стиль, уровень детализации. Ограничения задают границы: что не включать, каких слов избегать, какой аудитории предназначен текст.

К — Контекст

З — Задача

Ф — Формат

О — Ограничения

Пример 1:

К:Я — HR-менеджер производственной компании (500 человек). Готовлю внутреннее объявление.

З:Напиши объявление о запуске программы наставничества.

Ф:Объём: 150–200 слов. Структура: заголовок + 2 абзаца + призыв к действию.

О:Без корпоративного жаргона. Тон — живой, не официозный. Без фраз «в рамках стратегии» и «в соответствии с приоритетами».

Пример 2:

К:Я — маркетолог небольшого интернет-магазина спортивного питания. ЦА: мужчины 25–50 лет, любители тренажёрного зала.

З:Напиши 5 вариантов заголовка для карточки товара — протеина.

Ф:Каждый вариант — одна строка, не более 8 слов. Без кавычек и восклицательных знаков.

О:Не использовать слова «лучший», «премиум», «топ». Акцент на результат, не на состав.

КЗФО — это не жёсткий шаблон. Не каждый промпт требует всех четырёх компонентов: простая задача может обойтись без контекста, а знакомая модели тема — без ограничений. Но каждый раз, когда вы получаете неудовлетворительный ответ, стоит проверить: какой из четырёх компонентов отсутствовал или был сформулирован нечётко?

3.1.3 Почему «напиши текст про маркетинг» — плохой промпт

Этот пример не случайный — именно с таких промптов начинают большинство новичков. Проблема не в теме, а в том, что каждое из четырёх измерений КЗФО здесь неопределено. Контекст: кто пишет, для кого, в каком контексте бизнеса? Задача: «напиши» — текст какого жанра? статья, пост, лонгрид, ответ на возражение? Формат: длина, структура, стиль? Ограничения: что исключить? На что делать акцент?

Модель при таком промпте делает единственно возможное: заполняет все пробелы усреднёнными предположениями. Получается что-то вроде вводной статьи из учебника — академичная, безличная, без чётко выраженной позиции. Технически это ответ на запрос. Прагматически — почти бесполезный черновик.

Пример 1:

❌ Слабый промпт

Напиши текст про маркетинг.

✓ Сильный промпт

Ты — контент-стратег. Напиши колонку (450–500 слов) для корпоративного блога производителя промышленного оборудования. Тема: почему B2B-маркетинг в 2026 году строится на данных, а не на интуиции. Аудитория: коммерческие директора. Тон: деловой, без воды. Закончи конкретным призывом к действию. Не использовать слова «экосистема» и «синергия».

Пример 2:

❌ Слабый промпт

Что такое таргетинг?

✓ Сильный промпт

Объясни концепцию поведенческого таргетинга маркетологу с 10 годами опыта в офлайн-рознице, который только начинает работать с digital. Без базовых определений — он знает, что такое аудитория и сегментация. Сосредоточься на том, чем поведенческий таргетинг отличается от демографического и почему это меняет логику медиапланирования.

Пример 3:

❌ Слабый промпт

Помоги с презентацией.

✓ Сильный промпт

Я готовлю питч-презентацию для инвестора (8 слайдов, 7 минут). Стартап: платформа для управления складскими запасами малого бизнеса, Россия, B2B, ARR — 4 млн руб. Предложи структуру слайдов и для каждого — 2–3 ключевых тезиса, которые стоит вынести. Инвестор — фонд ранних стадий, интересуется SaaS.

3.2 Базовые техники

Структура КЗФО даёт каркас. Базовые техники — это конкретные инструменты, которыми вы наполняете каждый из компонентов. Каждая техника решает одну конкретную задачу и имеет предсказуемый эффект на качество ответа.

3.2.1 Ролевые инструкции: «Ты — эксперт по...»

Ролевая инструкция — самый мощный одиночный инструмент контекста. Фраза «Ты — опытный налоговый консультант» запускает в модели принципиально другой режим ответа, чем отсутствие роли. Почему? Модель обучена на огромном количестве текстов — и среди них есть тексты, написанные налоговыми консультантами. Ролевая инструкция активирует паттерны этого специфического корпуса: словарь, стиль рассуждения, типичные оговорки и нюансы.

Ролевая инструкция работает лучше, когда она конкретна. «Ты — эксперт» хуже, чем «Ты — коммерческий директор со специализацией в B2B-продажах промышленного оборудования». «Ты — юрист» хуже, чем «Ты — юрист по корпоративному праву с опытом сопровождения M&A-сделок в российском праве». Чем точнее профиль, тем более прицельным будет ответ.

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

Пример: одна тема, три роли — три ответа

Тема: «Объясни, как работает NPS (индекс потребительской лояльности)».

Роль 1 — «Ты — маркетолог-аналитик» → акцент на методологию сбора данных, сегментацию, бенчмарки.

Роль 2 — «Ты — CEO стартапа» → акцент на то, что NPS показывает о здоровье бизнеса и когда его считать критичным.

Роль 3 — «Ты — преподаватель MBA» → акцент на теоретическую основу, ограничения метода, альтернативные подходы.

Тема одна. Роль определяет, с какой стороны модель к ней подходит.

3.2.2 Указание формата вывода

Формат — это инструкция, которую большинство пользователей пропускают и о которой потом больше всего жалеют. «Я попросил написать список, а получил сплошной текст» — почти всегда результат отсутствия явного указания на формат.

Ключевые параметры формата: тип вывода (список, таблица, эссе, маркированный план, диалог, Q&A), объём (количество слов, абзацев, пунктов), уровень заголовков (если нужна структура). Чем более специфична инструкция по формату, тем предсказуемее результат. «Напиши список» хуже, чем «Напиши список из 7–9 пунктов, каждый пункт — одно действенное предложение без вводных слов». «Сделай таблицу» хуже, чем «Сделай таблицу с четырьмя столбцами: Инструмент — Ключевая функция — Цена/месяц — Ограничения».

Особый случай — Markdown-форматирование. Большинство современных ИИ-интерфейсов рендерят Markdown: двойная звёздочка даёт **жирный**, решётка — заголовок. Если вы копируете ответ в документ, где Markdown не рендерится, — попросите «без Markdown-форматирования, чистый текст». Если вы работаете в интерфейсе с рендерингом — наоборот, явная инструкция «используй заголовки H2/H3 и маркированные списки» улучшит навигацию по длинному ответу.

3.2.3 Задание тона и стиля

Тон — это не украшение. Тон определяет, будет ли текст работать для своей аудитории. Письмо в налоговую и письмо клиенту с предложением о партнёрстве — разные регистры даже при одинаковом смысловом содержании. Языковая модель по умолчанию тяготеет к нейтрально-официальному регистру — потому что именно такой преобладает в обучающих данных.

Эффективные инструкции по тону работают через конкретные описания, а не через абстрактные прилагательные. «Профессиональный» — слишком широко. «Деловой, без канцеляризмов, как письмо коллеге-партнёру, которого знаешь три года» — значительно точнее. Другие рабочие конструкции: «как объяснял бы эксперт на конференции (без академических оборотов)», «как написал бы старший менеджер подчинённому — требовательно, но без агрессии», «как пишет РБК — факты без лирики».

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

Важно: тон и сложность аудитории — разные параметры

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

3.2.4 Ограничения и рамки

Ограничения — недооценённый компонент промпта. Начинающие пользователи формулируют, что нужно делать, и почти никогда — что не нужно. Между тем «не делай X» часто более ценная инструкция, чем «делай Y», особенно когда X — типичная ошибка модели на данном типе задач.

Три категории ограничений, которые стоит указывать: лексические (конкретные слова и фразы, которых нужно избегать — особенно профессиональный жаргон, клише, стоп-слова вашей организации), объёмные (максимальное и минимальное количество слов/пунктов), содержательные (что не включать в ответ — например, «без исторической справки», «только практические рекомендации, без теории»).

Лексические ограничения особенно важны для брендированных текстов. Если у вашей организации есть список запрещённых формулировок (слова-паразиты корпоративного общения типа «синергия», «экосистема», «инновационное решение»), включите его в промпт явно. Модель точно следует таким инструкциям при условии, что список не слишком длинный (до 10–15 слов оптимально).

3.2.5 Постановка аудитории

Аудитория — это параметр, который меняет не только тон, но и содержание: какие термины объяснять, какой базовый уровень предполагать, какие примеры использовать. «Объясни мне как специалисту» и «объясни мне как новичку» — это не инструкция о стиле, это инструкция о глубине и точке входа.

Конкретные формулировки аудитории работают лучше, чем расплывчатые. «Для специалиста» — слабо. «Для финансового директора, который не имеет технического образования, но хочет оценить ROI проекта по внедрению ИИ-аналитики» — сильно. Или: «для студента второго курса экономического факультета, который прошёл курс по статистике, но не изучал машинное обучение».

Практический тест: достаточно ли конкретно описана аудитория? Если по вашей инструкции об аудитории можно представить двух разных людей с принципиально разным уровнем знаний — уточняйте.

Практикум 3.А: Переписать 5 плохих промптов в хорошие — с разбором каждого

Задача: взять пять слабых промптов и улучшить каждый, применяя структуру КЗФО. Зафиксировать, какие компоненты добавили и почему.

Шаг 1 — Возьмите следующие пять исходных промптов (или замените их своими, актуальными для вашей работы):

1. «Помоги с резюме»

2. «Напиши письмо в банк»

3. «Объясни, что такое блокчейн»

4. «Сделай план проекта»

5. «Напиши пост для соцсетей о нашем продукте»

Шаг 2 — Для каждого промпта письменно ответьте на четыре вопроса:

К: Какой контекст отсутствует? (кто вы, какова ситуация?)

З: Насколько точно сформулировано действие? Что нужно уточнить?

Ф: Какой формат ожидается? Объём, структура?

О: Какие ограничения важны для данной задачи?

Шаг 3 — Напишите улучшенный вариант каждого промпта. Каждый улучшенный промпт должен быть не менее 3–4 предложений и явно содержать все четыре компонента КЗФО.

Шаг 4 — Запустите исходный и улучшенный промпт в одной модели. Зафиксируйте: насколько отличаются ответы по качеству, специфичности, применимости.

Ожидаемый результат: 5 пар промптов (исходный + улучшенный) с письменным разбором добавленных компонентов + краткий вывод о наиболее ценном компоненте КЗФО для вашего типа задач.

На что обратить внимание: часто самый недооценённый компонент — формат. Указание на структуру и объём ответа нередко даёт больший прирост качества, чем уточнение содержания.

3.3 Итеративный диалог

Самая распространённая ошибка в работе с ИИ — ожидание идеального ответа с первого запроса. Даже опытные пользователи с отточенными промптами редко получают финальный результат за один раунд. Итеративный диалог — это не признак слабого промпта; это рабочий процесс, при котором качество растёт итерационно.

3.3.1 Промптинг как переговоры, а не одиночный запрос

Удачная аналогия для итеративного диалога — работа с редактором. Вы сдаёте черновик, получаете правки, дорабатываете, снова получаете обратную связь. Ни один профессиональный автор не считает это признаком провала первой версии. Это нормальный процесс производства качественного текста.

Разница между случайными итерациями и продуктивными — в том, насколько осознанно вы направляете каждый следующий шаг. «Перепиши лучше» — неинформативная инструкция, которая часто даёт вариант того же уровня. «Перепиши, убрав все метафоры и сделав каждое предложение не длиннее 15 слов» — конкретная инструкция, которая двигает результат в нужном направлении.

Практика показывает, что большинство задач разрешаются за 2–4 итерации при осознанном диалоге. Если после 5–6 итераций результат не приближается к цели — это сигнал либо переформулировать задачу с нуля, либо проверить, не является ли задача принципиально плохо подходящей для данной модели.

3.3.2 Техника уточнения и доработки ответа

Три класса уточняющих инструкций с разным эффектом. Первый — уточнение через критику конкретного элемента: «Первый абзац слишком общий — сделай его конкретнее, добавь числа или кейс». «Пункт 3 противоречит пункту 7 — разреши это противоречие». «Заключение звучит как вывод по другой теме — перепиши его, опираясь на аргументы выше». Эти инструкции работают точечно и дают быструю коррекцию.

Второй класс — расширение и углубление: «Разверни пункт 2 в отдельный раздел на 200 слов», «Добавь к каждому аргументу пример из российской практики», «Дополни таблицу ещё тремя строками с инструментами для малого бизнеса». Эти инструкции наращивают результат в указанном направлении.

Третий класс — трансформация: «Перепиши этот же текст как FAQ из 8 вопросов и ответов», «Сожми до 100 слов без потери ключевых тезисов», «Переведи в формат чек-листа для практика». Трансформационные инструкции радикально меняют форму при сохранении содержания — мощный инструмент для адаптации одного материала под разные каналы.

Пример: итеративный диалог по шагам

Запрос 1: «Напиши краткую инструкцию по проведению 1-на-1 встреч для новых руководителей» → Модель даёт 5 общих пунктов.

Запрос 2: «Добавь к каждому пункту конкретный пример вопроса, который руководитель может задать» → Инструкция стала ощутимо практичнее.

Запрос 3: «Пункты 2 и 4 дублируют друг друга по смыслу. Объедини их и добавь новый пункт о том, как документировать договорённости» → Финальная версия с устранённым дублированием.

Три итерации. От общего шаблона — к практически применимой инструкции.

3.3.3 Управление контекстом в длинном диалоге

По мере роста диалога накапливается ещё одна проблема: модель начинает опираться на более ранние части разговора меньше, чем на свежие. Если в начале сессии вы задали важные параметры («тон — сухой профессиональный», «аудитория — технические специалисты»), через 10–15 обменов модель может начать отступать от них — не потому что игнорирует инструкцию, а потому что вес этой части контекста снижается относительно последних сообщений.

Два практических приёма. Первый — «напоминание параметров»: через каждые 5–7 итераций добавляйте в запрос краткое резюме ключевых ограничений. «Продолжаем: тон — деловой без канцеляризмов, объём раздела — до 150 слов». Второй — «закрепление в системном промпте»: если платформа позволяет задать системный промпт (инструкцию, которая действует на весь диалог), — вынесите ключевые параметры туда. В GigaChat, YandexGPT и большинстве зарубежных платформ эта функция доступна в API-режиме и, в ряде случаев, через настройки интерфейса.

Признак того, что диалог «сломался»: модель начала противоречить параметрам, которые вы установили в начале, или резко снизила качество ответов по сравнению с первыми итерациями. В этом случае продуктивнее начать новый диалог с полным контекстом, чем продолжать текущий.

3.3.4 Когда начать новый диалог, а когда продолжить старый

Простое правило: один диалог — одна задача. Если задача завершена или принципиально изменилась, новый диалог эффективнее. Это не только вопрос качества — это вопрос ясности для вас самих: один диалог = одна цепочка мышления, которую можно сохранить, вернуться к ней или показать коллеге.

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

Практическое правило: длина диалога и качество

В большинстве современных моделей заметная деградация качества в длинном диалоге начинается примерно после 20–25 обменов (в зависимости от длины каждого сообщения и ответа). Это связано с эффектом «потери в середине» — модель хуже удерживает информацию из ранних частей длинного контекста. Для сложных задач, требующих множества итераций, сохраняйте промежуточные результаты отдельно.

3.4 Встроенная верификация в диалоге

Из Главы 2 вы помните: ключевой риск — автоматизированное доверие к уверенно сформулированному ответу. В итеративном диалоге есть встроенный инструмент снижения этого риска: попросить саму модель поставить под сомнение свой ответ. Эта группа техник — простая и действенная.

3.4.1 Попросить ИИ обосновать ответ: «почему именно так?»

После получения ответа задайте один вопрос: «Объясни логику первого пункта» или «Почему ты рекомендуешь именно этот подход, а не альтернативный X?». Этот простой шаг делает две вещи. Во-первых, вы получаете цепочку рассуждений, которую можете проверить — легче увидеть ошибку в логике, чем в итоговом утверждении. Во-вторых, если модель галлюцинировала, обоснование часто содержит противоречия или откровенно слабые аргументы, которые вы немедленно заметите.

Этот приём особенно ценен при анализе и рекомендациях: «Ты рекомендуешь стратегию А. Какие аргументы против этой стратегии ты не учёл?». Модели с хорошей калибровкой ответят реальными контраргументами; модели с низкой калибровкой либо повторят те же тезисы в другой форме, либо дадут тривиальные возражения — оба варианта информативны.

3.4.2 Техника самопроверки: «проверь своё утверждение»

Прямая инструкция: после получения ответа добавьте запрос «Проверь факты в своём ответе и укажи, в каких местах ты не уверен». Современные модели при такой инструкции честно помечают неопределённость — они могут написать что-то вроде «Я уверен в пунктах 1–3, пункт 4 основан на менее надёжных данных, рекомендую проверить». Это не гарантия точности, но значительно лучше, чем единый уверенный ответ без оговорок.

Вариант этой техники — разделить запрос на части: сначала попросить ответ, затем отдельно — оценку уверенности по каждому пункту по шкале высокая/средняя/низкая. Разделение на два шага часто даёт более честную оценку, чем просьба сделать всё сразу: в одном промпте модель иногда задним числом «обосновывает» своё решение вместо того, чтобы критически его оценивать.

Пример: двухшаговая верификация

Шаг 1 — запрос: «Перечисли 5 ключевых изменений в 152-ФЗ за 2024–2025 годы».

Шаг 2 — верификация: «Для каждого пункта выше оцени, насколько ты уверен в точности: высокая / средняя / низкая. Для пунктов со средней и низкой уверенностью — укажи, что именно стоит проверить в первичном источнике».

Результат: вы получаете не просто список, а список с явной картой рисков — и знаете, куда направить усилия по верификации.

3.4.3 Добавление вопроса «что ты не знаешь по этой теме?»

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

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

Включение этого вопроса в рабочий процесс — отличный противовес automation bias. Когда модель сама обозначает пробелы, пользователю психологически проще воспринять её ответ как черновик, а не как окончательную истину.

Практикум 3.Б: Итеративный диалог — довести черновик до финального результата за ≤5 итераций

Задача: на реальной профессиональной задаче отработать итеративный диалог и зафиксировать, как меняется качество от итерации к итерации.

Шаг 1 — Выберите задачу из вашей практики, результат которой можете оценить содержательно. Примеры: написание раздела для внутреннего регламента, подготовка структуры аналитического отчёта, черновик коммерческого предложения, план учебного модуля.

Шаг 2 — Напишите первый промпт, применяя структуру КЗФО. Запустите — зафиксируйте результат (скопируйте или сохраните).

Шаг 3 — Оцените ответ по трём вопросам:

• Что получилось хорошо? (не меняем)

• Что конкретно не так? (критика одного-двух элементов)

• Какой следующий шаг исправит главную проблему?

Шаг 4 — Сформулируйте уточняющий запрос, основанный на оценке из шага 3. Запустите. Зафиксируйте результат итерации 2.

Шаг 5 — Повторяйте шаги 3–4, пока результат не устроит вас или пока не исчерпаете лимит в 5 итераций.

Шаг 6 — После завершения: применим ли приём верификации? Добавьте запрос «Укажи, в каких утверждениях текста ты не уверен» и зафиксируйте ответ.

Ожидаемый результат: зафиксированные версии результата после каждой итерации (1–5) + финальный ответ модели на запрос верификации + вывод: на какой итерации наступил наибольший прирост качества и почему.

На что обратить внимание: если качество не растёт между итерациями 3 и 4 — причина почти всегда в неточности инструкции по уточнению, а не в ограничениях модели. Попробуйте сформулировать критику через конкретное действие («замени X на Y»), а не через оценку («сделай лучше»).

Типичные ошибки промпт-инжиниринга

Ошибка 1: Перегруженный контекст

В чём: пользователь добавляет в промпт всё, что считает потенциально релевантным — страницу биографии, подробности о компании, историю вопроса. В итоге промпт превращается в документ на 800 слов, где ключевая задача теряется.

Как правильно: контекст должен быть необходимым и достаточным. Спросите себя: без этой информации модель дала бы принципиально другой ответ? Если нет — уберите. Компактный промпт с чётко выраженной задачей надёжнее длинного с размытым акцентом. Сначала — задача, затем — контекст. Не наоборот.

Ошибка 2: Расплывчатая критика при итерации

В чём: пользователь пишет «перепиши лучше», «не то, что мне нужно», «сделай более профессионально». Модель получает сигнал о недовольстве, но не знает, что именно исправить. Результат — вариация на ту же тему, часто ничуть не лучше.

Как правильно: каждая итерационная инструкция должна указывать конкретный элемент и конкретное изменение. «Перепиши второй абзац: убери все прилагательные, каждое предложение — не более 12 слов, добавь конкретный пример из ритейла». Чем точнее критика, тем точнее исправление.

Ошибка 3: Смешение нескольких задач в одном промпте

В чём: «Напиши текст о нашем продукте, переведи его на английский, сделай версию для соцсетей и предложи три заголовка». Технически модель выполнит всё — но качество каждого элемента будет ниже, чем при отдельном запросе на каждую задачу.

Как правильно: один промпт — одна задача. Если вам нужно несколько форматов одного материала — последовательные запросы в рамках одного диалога дадут лучший результат, чем один запрос с четырьмя подзадачами. Исключение: параллельные задачи одного типа (например, «напиши 5 вариантов заголовка» — это один запрос на одну задачу с несколькими вариантами, а не пять задач).

Ошибка 4: Слишком широкая ролевая инструкция

В чём: «Ты — эксперт» или «Ты — умный ИИ». Такая инструкция не даёт модели ничего: всё и так является её базовым режимом. Ролевая инструкция имеет смысл только тогда, когда она конкретизирует специализацию и контекст.

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

Ошибка 5: Отказ от верификации после «хорошего» ответа

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

Как правильно: применяйте минимальный чек-лист верификации (из Главы 2) независимо от того, насколько убедителен ответ. Особенно — если в нём есть числа, даты, ссылки или специализированные утверждения.

Кейс 2026: Методист онлайн-школы — система промптов вместо шаблонов

Анна — методист крупной онлайн-школы по подготовке к ЕГЭ (Россия). В её задачи входят: разработка структуры учебных модулей, написание заданий и объяснений для учеников, создание материалов для преподавателей. Объём производства контента — около 15–20 учебных материалов в месяц.

До систематического использования ИИ у Анны существовали Word-шаблоны для разных типов материалов — контурный план модуля, карточка задания, методическая записка. Шаблоны экономили время на структуру, но содержание приходилось писать с нуля каждый раз. Средняя скорость: один полноценный учебный модуль (объяснение + задания + методкомментарии) — около 4 часов.

Первые два месяца Анна использовала ИИ хаотично: задавала разовые вопросы, получала неровные результаты и была скептична. Перелом произошёл, когда она потратила один день на то, чтобы создать не случайные промпты, а систему: библиотеку из 12 шаблонных промптов для каждого типа задач её работы.

Пример одного шаблона — для создания объяснения сложного правила русского языка:

Ты — методист с опытом работы с учениками 10–11 классов,

готовящимися к ЕГЭ по русскому языку. Пиши как человек,

которому важно, чтобы ученик понял — не зазубрил.

Задача: объясни правило «[ВСТАВИТЬ ПРАВИЛО]».

Формат:

1. Формулировка правила (1–2 предложения, без канцелярита)

2. Почему ученики ошибаются (самая частая ловушка — 1 абзац)

3. Алгоритм применения (нумерованный список, 3–5 шагов)

4. Два разобранных примера (с объяснением каждого шага)

5. Задание для самопроверки (1 предложение с пропуском)

Ограничения: без академического языка, без ссылок

на учебники. Обращение к ученику — на «ты»,

дружески, без снисхождения.

Результат через три месяца: время на создание одного модуля сократилось с 4 часов до 1,5–2 часов. Не за счёт снижения качества — Анна всегда редактирует и дополняет ИИ-черновики — а за счёт того, что первый черновик теперь уже имеет правильную структуру, тон и уровень детализации. Редактирование готового черновика занимает 30–40 минут против написания с нуля за 3 часа.

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

Честное ограничение: промпт-система не работает для нестандартных задач. Когда школа запускала новый формат курса — с интерактивными сценариями вместо объяснений — существующие шаблоны не подходили, и Анне пришлось разрабатывать новые промпты с нуля, что заняло около 3 часов на первый рабочий шаблон. Это разовые инвестиции, которые затем окупаются на каждом следующем материале того же типа.

Ключевой вывод кейса

Ценность промпта пропорциональна частоте использования задачи. Разовая задача не требует идеального промпта. Повторяющаяся задача требует шаблона — один раз хорошо написанного и проверенного промпта, который потом используется без существенных изменений. Инвестиция в шаблон окупается уже на третьем-четвёртом использовании.

Контрольные вопросы к Главе 3

1. (Понимание) В чём принципиальная разница между ролевой инструкцией «Ты — эксперт» и «Ты — налоговый консультант с опытом работы с ИП и малым бизнесом в России»? Почему второй вариант лучше с точки зрения механики работы языковой модели?

2. (Применение) Вам нужно написать промпт для следующей задачи: составить план выступления на внутренней конференции вашей организации на 15 минут по теме, в которой вы специализируетесь. Напишите промпт, используя структуру КЗФО, с явным указанием всех четырёх компонентов. После написания: укажи, какие компоненты было сложнее всего сформулировать и почему.

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

4. (Применение) Вы ведёте итеративный диалог уже 18 итераций по сложному аналитическому проекту. В последних трёх ответах модель начала противоречить параметрам, которые вы установили в начале разговора. Какие два варианта действий у вас есть? Опишите плюсы и минусы каждого.

5. (Оценка) Методист из кейса этой главы создала систему из 12 шаблонных промптов. Предложите два сценария, при которых такой подход (фиксированные шаблоны) может навредить, а не помочь, — и как скорректировать практику для каждого из этих сценариев.

→ К Главе 4: Продвинутый промпт-инжиниринг

Базовая структура КЗФО работает для большинства стандартных задач. Глава 4 разбирает ситуации, когда стандартного промпта недостаточно: сложные многошаговые рассуждения, обучение модели на примерах внутри промпта, системные промпты для регулярных задач и работа с длинным контекстом от 100 000 токенов и выше.

Глава 4. Продвинутый промпт-инжиниринг

Часть II · Язык взаимодействия: промпт-инжиниринг

Учебные результаты: применить CoT, few-shot и мета-промптинг; сформировать структурированный вывод в JSON; создать систему промптов для регулярных задач; работать с длинным контекстом.

Структура КЗФО из предыдущей главы решает большинство стандартных задач. Продвинутые техники нужны там, где стандартный промпт упирается в потолок: сложные многошаговые рассуждения, задачи с неоднозначными критериями качества, повторяющиеся рабочие процессы, требующие консистентности, и работа с документами, которые не помещаются ни в одну страницу. Эта глава — набор инструментов для именно таких случаев.

Важная оговорка перед началом: продвинутые техники не заменяют базовую точность промпта. Chain-of-Thought не исправит расплывчато сформулированную задачу. Системный промпт не компенсирует отсутствие контекста. Сначала — база, затем — надстройка.

4.1 Техники управления рассуждением

Языковые модели решают многошаговые задачи значительно лучше, когда рассуждают явно, а не «в уме». Это не метафора: эксперименты показывают, что модель, явно записывающая промежуточные шаги, решает одну и ту же математическую или логическую задачу существенно точнее, чем та же модель, выдающая ответ сразу. Техники управления рассуждением — это способы активировать этот режим через промпт.

4.1.1 Chain-of-Thought: «думай шаг за шагом»

Пошаговое рассуждение (chain-of-thought, CoT) — самая простая и одновременно одна из наиболее эффективных продвинутых техник. Суть: добавить в промпт инструкцию, которая заставляет модель явно записать промежуточные шаги рассуждения, прежде чем дать финальный ответ. Классическая формулировка — «Думай шаг за шагом» — работает для многих задач. Но специфичная инструкция работает лучше.

Как выглядит CoT на практике. Без CoT: «Какую систему автоматизации выбрать для нашего отдела?» — модель выдаёт итоговую рекомендацию. С CoT: «Сначала перечисли критерии выбора системы автоматизации для отдела (5–7 критериев). Затем оцени каждый из них по шкале важности для нашей ситуации [контекст]. Затем на основе этой оценки сформулируй рекомендацию с обоснованием». Второй вариант не просто формирует более обоснованный ответ — он позволяет вам увидеть логику и скорректировать её, если вы не согласны с каким-то критерием или оценкой.

CoT наиболее ценен для задач трёх типов: многофакторные решения (выбор между вариантами с несколькими критериями), задачи с расчётами (где нужно проследить цепочку вычислений), анализ с последовательными выводами (где каждый следующий вывод опирается на предыдущий). Для задач с однозначным ответом или простой генерации текста CoT добавляет лишний объём без прироста качества.

Пример CoT для управленческого решения

Задача: «Стоит ли переносить еженедельную командную встречу с пятницы на понедельник?»

Промпт с CoT: «Прежде чем дать рекомендацию, выполни следующие шаги:

Шаг 1: Перечисли аргументы в пользу пятницы (итоги недели, фокус на завершении).

Шаг 2: Перечисли аргументы в пользу понедельника (планирование, настрой на неделю).

Шаг 3: Оцени, для какого типа задач и команды каждый вариант предпочтителен.

Шаг 4: Учитывая, что команда работает в режиме проектной работы с еженедельными дедлайнами, сформулируй рекомендацию.»

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

4.1.2 Tree-of-Thought: несколько параллельных линий рассуждения

Дерево мыслей (tree-of-thought, ToT) — расширение CoT для задач, где существуют принципиально разные подходы к решению и нельзя заранее знать, какой окажется более продуктивным. Вместо одной линии рассуждения модель строит несколько параллельных и затем оценивает их сравнительно.

На практике ToT реализуется через промпт такого рода: «Рассмотри три принципиально разных подхода к решению следующей задачи. Для каждого подхода: опиши его суть (2–3 предложения), назови главное преимущество и главный риск. Затем сравни три подхода и выбери наиболее перспективный для нашей ситуации с обоснованием».

ToT имеет смысл в ситуациях стратегических развилок — где выбор между альтернативами неочевиден и цена ошибки высока. Для операционных задач ToT избыточен и создаёт лишний объём. Практический ориентир: если задача сводится к «как лучше сделать X», достаточно CoT. Если задача — «что делать: X, Y или Z», ToT оправдан.

4.1.3 Self-Consistency: попросить ИИ проверить самого себя

Самосогласованность (self-consistency) — техника, при которой вы просите модель решить одну задачу несколькими независимыми путями, а затем проверить, совпадают ли ответы. Исходная идея из области математики и логики: если разные пути рассуждения приводят к одному ответу — он, скорее всего, верен. Если ответы расходятся — нужен дополнительный анализ.

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

Для пользователей без API-доступа self-consistency реализуется вручную — через несколько итераций с разными ролевыми инструкциями. Это занимает больше времени, но для критически важных решений (выбор стратегии, оценка риска, анализ перед крупной инвестицией) оправдано.

4.1.4 ReAct-паттерн: рассуждение + действие

ReAct (reasoning + acting) — паттерн, изначально разработанный для агентных систем (Глава 12), но применимый и в обычных диалогах. Суть: модель явно чередует рассуждение («Что я знаю? Что мне нужно выяснить?») и действие («Задать уточняющий вопрос / проверить допущение / выполнить подзадачу»).

Для нетехнического пользователя ReAct наиболее ценен при решении задач с неполной информацией. Промпт: «Перед тем как давать рекомендации, определи: какую информацию о ситуации тебе нужно уточнить, чтобы ответ был полезным. Задай мне 3–5 уточняющих вопроса. После получения ответов — сформулируй рекомендацию». Такой подход превращает монологичный запрос в структурированный диалог, где модель активно участвует в сборе контекста.

Техника

Chain-of-Thought (CoT)

Когда применять

Многофакторные решения, расчёты, последовательный анализ

Когда не нужна

Простые задачи с однозначным ответом — добавит объём без пользы

Техника

Tree-of-Thought (ToT)

Когда применять

Стратегические развилки с принципиально разными подходами

Когда не нужна

Операционные задачи типа «как сделать X лучше»

Техника

Self-Consistency

Когда применять

Критически важные решения с высокой ценой ошибки

Когда не нужна

Задачи с быстрым дедлайном — три параллельных анализа занимают время

Техника

ReAct

Когда применять

Задачи с неполной исходной информацией

Когда не нужна

Задачи, где весь контекст уже дан в промпте

Практикум 4.Б: Chain-of-Thought — решение сложной профессиональной задачи через пошаговое рассуждение

Задача: применить CoT к реальной многофакторной задаче из своей практики и сравнить с результатом без CoT.

Шаг 1 — Выберите задачу, требующую взвешенного суждения. Примеры: «Стоит ли нам сменить подрядчика по [направлению]?», «Как приоритизировать три конкурирующих проекта?», «Какую модель ценообразования выбрать для нового продукта?». Задача должна иметь несколько факторов и неочевидный ответ.

Шаг 2 — Сначала запустите «наивный» промпт: задайте вопрос без CoT-инструкции. Зафиксируйте ответ.

Шаг 3 — Теперь напишите CoT-промпт для той же задачи. Структура CoT:

• Шаг 1: Перечисли факторы, которые нужно учесть при принятии решения (5–8 факторов).

• Шаг 2: Для каждого фактора оцени его значимость в нашей ситуации [контекст] по шкале высокая/средняя/низкая с обоснованием.

• Шаг 3: Определи, какие факторы указывают в пользу решения А, какие — в пользу решения Б.

• Шаг 4: Сформулируй итоговую рекомендацию с обоснованием.

Шаг 4 — Запустите CoT-промпт. Зафиксируйте ответ.

Шаг 5 — Сравните два ответа по трём критериям: глубина анализа, наличие аргументов, которые вы не учли самостоятельно, практическая применимость рекомендации.

Ожидаемый результат: два ответа (наивный + CoT) + письменное сравнение по трём критериям + оценка: изменила ли CoT ваш взгляд на задачу?

На что обратить внимание: CoT не всегда даёт другой итоговый ответ, но почти всегда даёт более богатую аргументацию. Ценность нередко не в финальной рекомендации, а в перечне факторов и их весов — именно здесь обнаруживаются пробелы в собственном анализе.

4.2 Few-shot и zero-shot промптинг

Языковые модели могут обучаться на примерах прямо внутри промпта — без какого-либо переобучения или изменения весов модели. Это называется few-shot обучением, и оно работает немедленно. Понимание механики помогает решить вопрос: когда примеры нужны, а когда лишние?

4.2.1 Zero-shot: без примеров

Zero-shot — это стандартный режим работы с моделью: промпт описывает задачу, и модель выполняет её без демонстрационных примеров. Это работает хорошо для задач, которые хорошо представлены в обучающих данных: написание деловых писем, анализ аргументации, структурирование текста. Модель «знает», как выглядит качественный результат для таких задач.

Zero-shot перестаёт работать хорошо, когда задача имеет нестандартный формат вывода, специфическую структуру или корпоративные соглашения, отличные от общепринятых. Именно тогда примеры становятся незаменимыми.

4.2.2 One-shot и Few-shot: обучение на примерах внутри промпта

One-shot — один пример в промпте. Few-shot — несколько (обычно 2–5). Механика: вы показываете модели, как выглядит входные данные и как выглядит правильный вывод — и затем даёте новые входные данные для обработки. Модель экстраполирует паттерн из примеров на новую задачу.

Структура few-shot промпта: сначала инструкция (что нужно делать), затем пример или примеры в формате «Вход: [X] → Выход: [Y]», затем финальная задача «Вход: [новый X] → Выход:». Модель продолжает паттерн.

Задача: классифицировать отзывы клиентов по категориям.

Категории: Доставка / Качество товара / Обслуживание / Цена / Прочее

Примеры:

Отзыв: «Заказ пришёл через 2 дня вместо обещанных 5, очень доволен»

Категория: Доставка

Отзыв: «Ткань оказалась тоньше, чем на фото, разочарован»

Категория: Качество товара

Отзыв: «Менеджер не перезвонил, хотя обещал»

Категория: Обслуживание

Теперь классифицируй следующие отзывы:

Отзыв: «За эти деньги ожидал большего»

Категория:

Этот промпт чётко обучает модель нужному формату и набору категорий. Без примеров модель могла бы выдать категории в другом формате, использовать другие названия или добавить лишние рассуждения.

4.2.3 Как подбирать и форматировать примеры

Три правила качественных примеров для few-shot промпта. Первое — примеры должны быть репрезентативными: охватывать разные паттерны из ожидаемого входного пространства, а не только типичные случаи. Если вы классифицируете отзывы, среди примеров должны быть как однозначные, так и граничные случаи. Второе — примеры должны быть согласованными: если в примере 1 вы показали вывод в одном формате, в примере 2 должен быть тот же формат. Любое несоответствие путает модель. Третье — порядок примеров имеет значение: последний пример перед финальной задачей оказывает наибольшее влияние на стиль ответа.

По количеству примеров: 2–3 примера обычно достаточно для формата вывода. 4–6 примеров нужны, когда задача имеет несколько принципиально разных классов или когда граничные случаи критически важны. Больше 6–8 примеров редко улучшают результат и лишь увеличивают длину промпта.

Важно: примеры задают паттерн, а не правила

Few-shot промпт — это обучение на паттерне, а не формальное задание правил. Если ваши примеры нечаянно демонстрируют нежелательный паттерн (например, все позитивные примеры — короткие, все негативные — длинные), модель выучит этот паттерн как часть задачи. Перечитайте примеры глазами внешнего наблюдателя: какой неявный паттерн они демонстрируют помимо явного?

4.2.4 Когда примеры вредят, а не помогают

Few-shot промпт может снизить качество в двух случаях. Первый: когда модель «залипает» на формате примеров в ущерб содержанию. Если ваши примеры — короткие ответы, а вам нужен развёрнутый анализ, модель будет тяготеть к краткости, даже если явная инструкция требует иного. Решение: добавьте явную инструкцию по объёму, которая перебивает паттерн примеров.

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

4.3 Системные промпты и настройка поведения модели

Системный промпт (system prompt) — это инструкция, которая задаётся один раз и действует на всё поведение модели в рамках сессии или настроенного ассистента. Это не просто «первое сообщение в диалоге» — это технически отдельный уровень инструкций, которому модель придаёт более высокий приоритет, чем сообщениям пользователя. Понимание этого механизма открывает принципиально иной класс применений.

4.3.1 Что такое системный промпт и где он используется

В большинстве пользовательских интерфейсов системный промпт недоступен напрямую. Он используется самой платформой: именно системный промпт определяет «характер» и «правила» конкретного ИИ-продукта. Для конечного пользователя системный промпт становится доступен при: работе через API, использовании платформ для построения ИИ-ассистентов (Botpress, Flowise, Langchain и другие), создании «настроенных ИИ-инструментов» внутри некоторых корпоративных продуктов.

Если платформа не даёт доступа к системному промпту, его функцию можно частично воспроизвести через «инструкционный блок» в начале каждого диалога — раздел с постоянными параметрами, который вы вставляете в первое сообщение. Это менее элегантно, но работает для большинства задач.

4.3.2 Создание «персонажа» для регулярных задач

Системный промпт позволяет создать специализированного ассистента под конкретную повторяющуюся задачу — с фиксированным именем, ролью, стилем общения, ограничениями и знанием контекста. Один раз настроенный «персонаж» избавляет от необходимости повторять контекст в каждом диалоге.

Хороший системный промпт включает четыре блока. Первый — роль и специализация: кто этот ассистент, что он умеет лучше всего, какова его область знаний. Второй — контекст применения: для какой организации, проекта, задачи он работает. Третий — стиль и формат ответов: тон, уровень детализации, типичные форматы вывода. Четвёртый — явные ограничения: что ассистент не делает, каких тем избегает, на что запрашивает разрешение.

Ты — внутренний редактор корпоративных коммуникаций компании «Альфа-Ресурс».

Твоя задача — улучшать деловые тексты: письма, отчёты, презентационные материалы.

Правила работы:

• Сохраняй смысл оригинала — не добавляй новых тезисов.

• Убирай канцеляризмы: «в целях», «в соответствии с», «осуществлять».

• Сокращай без потери смысла: каждое предложение — не длиннее 20 слов.

• Тон — деловой, но живой. Не официозный, не разговорный.

• После каждой правки кратко поясни, что изменил и почему.

Запрещено: добавлять фактические утверждения, которых нет в оригинале.

Этот системный промпт превращает любую языковую модель в специализированный редакторский инструмент. Пользователь просто вставляет текст — и получает отредактированную версию с пояснениями, без необходимости каждый раз объяснять правила.

4.3.3 Корпоративные и профессиональные шаблоны

Системный промпт — главный инструмент стандартизации ИИ-работы внутри команды или организации. Если несколько человек работают с одним типом задач (анализ договоров, подготовка отчётов, ответы клиентам), единый системный промпт обеспечивает консистентность стиля и качества вне зависимости от того, кто именно запускает модель.

Практика лучших корпоративных внедрений: организация создаёт библиотеку из 5–15 системных промптов для наиболее распространённых рабочих сценариев, каждый — протестированный и утверждённый. Это не «запрет использовать ИИ по-своему» — это снижение барьера входа для новых сотрудников и гарантия минимального качества для критических задач.

Пример: корпоративный шаблон для анализа договоров

Системный промпт для юридического отдела: «Ты — ассистент по анализу договоров. Работаешь исключительно с текстом, который предоставляет пользователь. Никаких домыслов о сторонах или ситуации.

Для каждого договора:

1. Перечисли стороны и предмет договора.

2. Выдели нестандартные условия (отклонения от типовой практики).

3. Укажи условия с повышенным риском для [сторона — вставить]. 4. Перечисли отсутствующие стандартные положения.

Формат: структурированный список. Тон: нейтральный, без юридических заключений — только наблюдения. Напоминание в конце каждого анализа: результат требует проверки практикующим юристом.»

4.4 Мета-промптинг

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

4.4.1 Попросить ИИ написать промпт для ИИ

Сценарий: у вас есть задача, которую сложно описать точно. Вместо того чтобы мучиться с формулировкой, опишите её неточно и попросите модель предложить промпт. Запрос: «Мне нужно регулярно [описание задачи]. Я хочу создать шаблонный промпт для этой задачи. Помоги мне его сформулировать: задай уточняющие вопросы о задаче, а затем напиши промпт с использованием структуры КЗФО».

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

4.4.2 Автоматическое улучшение промптов

Если у вас есть рабочий промпт, который даёт неплохие, но не отличные результаты, — попросите модель его улучшить. Схема: «Вот промпт, который я использую: [ПРОМПТ]. Вот что в его результатах мне не нравится: [КРИТИКА]. Предложи три варианта улучшения промпта, каждый с объяснением, что именно ты изменил и почему это должно устранить проблему».

Три варианта, а не один, полезны по той же причине, что и ToT: разные подходы к улучшению могут решать проблему по-разному, и вам как пользователю виднее, какой из вариантов адекватен вашему контексту. После выбора варианта — тестируйте на 3–5 реальных задачах, прежде чем принять как стандарт.

4.4.3 Библиотека промптов: как собирать и систематизировать

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

Минимальная структура записи в библиотеке: название задачи, рекомендованная модель (GigaChat Professional, YandexGPT, другая — задача по умолчанию для того, с чем конкретная модель справляется лучше), текст промпта с явными плейсхолдерами для переменных частей (например, [ВАШ ОТДЕЛ], [ДЕДЛАЙН]), ожидаемый формат вывода, известные ограничения («не работает для договоров с иностранными сторонами»), дата последнего обновления.

Для команды: библиотека промптов эффективнее работает в общем пространстве (Notion, Confluence, папка в корпоративном облаке), где каждый может добавить новый шаблон и отметить, что старый устарел. Промпты, которые никто не использует три месяца подряд, — кандидаты на удаление или пересмотр.

Практикум 4.А: Сборка личного промпт-плейбука — 20+ шаблонов под свою профессию

Задача: создать структурированную личную библиотеку промптов для регулярных задач своей профессии.

Шаг 1 — Перечислите 10–15 задач из вашей работы, которые: повторяются не реже раза в месяц, содержат значительную текстовую или аналитическую составляющую, имеют более-менее предсказуемый формат вывода.

Шаг 2 — Для каждой задачи создайте запись в формате:

Название: [краткое описание задачи]

Промпт: [полный текст промпта с плейсхолдерами для переменных частей]

Модель: [рекомендованная модель]

Ожидаемый вывод: [описание формата]

Ограничения: [что промпт не покрывает]

Шаг 3 — Воспользуйтесь мета-промптингом для задач, которые сложно сформулировать: опишите задачу модели, получите уточняющие вопросы, ответьте на них, получите черновой промпт.

Шаг 4 — Протестируйте каждый шаблон минимум на двух реальных задачах. Зафиксируйте, что работает и что требует доработки.

Шаг 5 — Попросите модель проверить и улучшить три промпта, результатами которых вы менее всего довольны: «Вот мой промпт: [ПРОМПТ]. Его слабое место: [КРИТИКА]. Предложи улучшение».

Ожидаемый результат: библиотека из 20+ промптов в удобном для вас формате (Notion, Google Docs, Word) с заполненными метаданными.

На что обратить внимание: наиболее ценные промпты — не универсальные («напиши деловое письмо»), а специализированные под ваш контекст («напиши письмо поставщику с запросом скидки в B2B-контексте промышленного производства»). Чем конкретнее плейсхолдеры, тем стабильнее результат.

4.5 Структурированный вывод и форматирование

Пока предыдущие параграфы касались преимущественно текстовых задач, этот параграф — о ситуациях, когда вывод модели нужно встроить в другой инструмент или обработать программно. Структурированный вывод (JSON, XML, CSV) превращает языковую модель из «инструмента для текста» в «компонент рабочего процесса».

4.5.1 Markdown внутри промпта: заголовки, таблицы, списки как инструкция

Использование Markdown в промпте — не только стилистическое решение. Заголовки помогают структурировать длинный промпт так, чтобы модель чётко разграничивала его части: «# Контекст», «## Задача», «## Формат вывода». Таблицы в промпте задают модели пример формата, который нужно воспроизвести. Списки в промпте сигнализируют модели о том, что ответ тоже должен иметь параллельную структуру.

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

4.5.2 Получение ответа в JSON и XML: зачем и как

JSON-вывод нужен тогда, когда результат модели будет обрабатываться другим инструментом: импортироваться в таблицу, передаваться в API, встраиваться в приложение. Без явной инструкции модель добавляет пояснения вокруг данных — «Вот JSON, который вы просили:» — что ломает парсинг. Инструкция должна быть явной: «Верни ответ только в формате JSON, без пояснений, без Markdown-обёртки. Структура: ...».

Проанализируй следующий отзыв клиента и верни результат ТОЛЬКО в формате JSON.

Без пояснений, без кода в тройных кавычках, только чистый JSON объект.

Структура:

{

"sentiment": "positive" | "negative" | "neutral",

"score": число от 1 до 10,

"main_topic": "строка — главная тема отзыва",

"actionable": true | false,

"suggested_action": "строка или null если actionable=false"

}

Отзыв: «Доставка была быстрой, но упаковка повреждена — товар помялся»

Такой промпт возвращает машиночитаемый JSON, который можно напрямую вставить в таблицу или передать в другую программу. Это превращает разовый анализ в масштабируемый процесс: тот же промпт обработает 200 отзывов с тем же качеством.

4.5.3 Шаблонный вывод для последующей обработки

Помимо JSON и XML, существуют промежуточные форматы — структурированный текст с разделителями, который не требует программирования для обработки, но при этом легко импортируется в Excel или Google Sheets. Например: вывод в формате «поле: значение», или CSV с чётко заданными заголовками, или таблица Markdown с предсказуемыми столбцами.

Практическое правило: если вы планируете обрабатывать вывод вручную — Markdown-таблица удобнее JSON. Если планируете передавать в другой инструмент — JSON или CSV. Если неизвестно — просите Markdown-таблицу с возможностью «позже попрошу то же самое в JSON».

4.5.4 Сравнение: когда структура помогает, когда мешает

Структурированный вывод — не улучшение по умолчанию. Для творческих задач (написание текста, генерация идей, редактура) принудительная структура JSON может ухудшить качество: модель начнёт подгонять нарратив под поля схемы вместо того, чтобы строить органичный текст. Структура помогает там, где задача имеет чёткие поля и критерии — анализ, классификация, извлечение данных. Она мешает там, где качество определяется плавностью и органичностью — написание, перефразирование, творческие задачи.

Практикум 4.В: Получить структурированный JSON-ответ и использовать его в таблице

Задача: создать промпт, возвращающий JSON, и встроить результат в рабочий процесс.

Шаг 1 — Выберите задачу с чёткими полями. Подходящие варианты: анализ отзывов / обращений клиентов, извлечение ключевых данных из описаний вакансий или резюме, классификация входящих заявок, извлечение структурированной информации из неструктурированного текста (например, из новостных заметок — организация, дата, тип события).

Шаг 2 — Спроектируйте JSON-схему: какие поля нужны, какие типы данных (строка, число, булево, перечисление). Нарисуйте схему на бумаге или в текстовом редакторе.

Шаг 3 — Напишите промпт с инструкцией на JSON-вывод. Обязательные элементы:

• «Верни ответ ТОЛЬКО в формате JSON»

• «Без пояснений, без кода в тройных кавычках»

• Явная схема с примером структуры

• Описание допустимых значений для полей-перечислений

Шаг 4 — Протестируйте на 3–5 объектах одного типа. Проверьте: корректно ли парсится JSON? Все ли поля заполняются предсказуемо?

Шаг 5 — Скопируйте полученный JSON в онлайн-инструмент конвертации JSON→CSV (их несколько бесплатных) и откройте в Excel или Google Sheets.

Ожидаемый результат: работающий JSON-промпт + 3–5 успешно обработанных объектов + таблица с результатами.

На что обратить внимание: если модель возвращает JSON с пояснениями вокруг — добавьте в промпт: «Если ты хочешь добавить пояснение — помести его в поле 'note' внутри JSON-объекта, не вне него». Это изящнее, чем запрет на пояснения, который модель иногда игнорирует.

4.6 Длинный контекст (1M+ токенов)

Одно из самых значимых изменений 2024–2025 годов — распространение моделей с контекстом от 128 000 до 1 000 000+ токенов. Это принципиально новый класс задач, который стал доступен без специального технического обеспечения. Понимание возможностей и ограничений длинного контекста — необходимая часть инструментального арсенала в 2026 году.

4.6.1 Что изменилось с приходом длинного контекста

До 2024 года работа с документом больше 50–80 страниц требовала либо специальных технических решений (RAG, разбивка на чанки, программирование), либо ручного выбора релевантных фрагментов. Теперь для многих задач достаточно просто загрузить документ целиком. 1 млн токенов — это примерно 750 000 слов, или книга объёмом 1 500 страниц, или несколько сотен типовых деловых документов одновременно.

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

4.6.2 Работа с целыми книгами, архивами, кодовыми базами как с одним промптом

Три наиболее ценных применения длинного контекста для нетехнического специалиста: поиск конкретной информации в большом массиве документов, кросс-документный анализ (поиск противоречий, трендов, паттернов), синтез материала из множества источников в один связный вывод.

Конкретный пример корпоративного применения: аналитик загружает 30 отчётов от региональных офисов за год и задаёт вопрос: «Какие проблемы встречаются в более чем трёх регионах? Оформи как таблицу: проблема — сколько регионов — первое упоминание по дате». Раньше это был многочасовой ручной анализ. Теперь — несколько минут на загрузку и обработку.

4.6.3 Стратегии навигации в длинном контексте

Длинный контекст требует более точной навигации, чем обычный диалог. Три рабочих приёма. Первый — «якорные вопросы»: прежде чем делать развёрнутый запрос, попросите модель сначала составить структуру или оглавление загруженного материала. Это помогает обоим — и вам ориентироваться в ответах, и модели — «настроиться» на структуру документа. Второй — прогрессивное уточнение: сначала задайте общий вопрос («Какие главные темы в этих документах?»), затем уточняйте по конкретным темам. Третий — явные ссылки: в запросе указывайте на конкретные части материала («В третьем разделе договора... в строке 47 таблицы...»), чтобы снизить вероятность того, что модель будет работать с другим фрагментом.

Для задач с несколькими документами полезен промпт «сначала читай, потом отвечай»: «Внимательно прочитай все загруженные документы целиком. Не отвечай на вопросы, пока я не скажу 'готов'. После того как закончишь — напиши 'Готов к вопросам'». Такой порядок снижает вероятность того, что модель ответит на первый вопрос, не полностью обработав весь материал.

4.6.4 Ограничения: где длинный контекст не помогает

Длинный контекст не устраняет ограничения точности. Эффект «потери в середине», описанный в Главе 1, сохраняется: информация из середины очень длинного документа удерживается хуже, чем из начала и конца. Для критически важного поиска конкретного факта в 500-страничном документе — верифицируйте результат прямым поиском по тексту.

Длинный контекст не заменяет RAG для задач с постоянно обновляющейся базой знаний. Если ваша база документов растёт каждую неделю, загружать её целиком каждый раз неэффективно — RAG (Глава 6) здесь предпочтительнее. Длинный контекст оптимален для разовых аналитических задач с конечным набором документов.

Важно: большой контекст — большие токены = большая цена

При работе через API каждый токен в контексте стоит денег. 1 млн токенов контекста может стоить существенно дороже, чем несколько сотен токенов. Для частых задач с большими документами — оцените, не выгоднее ли RAG-подход с меньшим контекстом. Для разовых аналитических задач — длинный контекст оправдан.

4.7 Специфика разных моделей

Одинаковый промпт в разных моделях даёт разный результат — иногда незначительно, иногда принципиально. Это не случайность: у каждой модели есть особенности обучения, политика безопасности, культурный контекст обучающих данных и технические параметры. Знание ключевых различий помогает выбирать инструмент под задачу, а не адаптировать задачу под инструмент.

4.7.1 Различия в поведении GigaChat, YandexGPT, зарубежных моделей

GigaChat оптимизирован для русскоязычного корпоративного контекста и задач, типичных для российского делового оборота: деловая переписка, юридические формулировки, нормативная документация. Его сильные стороны — знание российского делового и правового контекста, хорошая работа с русскоязычными текстами, соответствие требованиям российского законодательства о персональных данных. В задачах с международным контекстом или на английском языке качество уступает специализированным зарубежным моделям.

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

Зарубежные флагманские модели (при наличии доступа) показывают лучшие результаты в задачах сложного рассуждения, анализа аргументации, работы с кодом и мультимодальных задачах. Их ограничение в российском контексте — меньшая глубина знания российского права, нормативной базы и делового этикета.

4.7.2 Как адаптировать промпт под конкретную модель

Три аспекта, по которым промпты чаще всего требуют адаптации. Первый — длина и структура инструкции: GigaChat и YandexGPT хорошо справляются с чёткими структурированными инструкциями; флагманские зарубежные модели лучше следуют длинным сложным промптам с многоуровневыми инструкциями. Если переносите промпт из одной модели в другую — проверяйте, не стала ли инструкция избыточно сложной или, наоборот, слишком краткой.

Второй аспект — контент-политика: у каждой модели своя политика ограничений. Некоторые задачи (критический анализ, ролевое разыгрывание сценариев переговоров, анализ рисков) одна модель выполнит без вопросов, другая потребует переформулировки. Если модель отказывается от задачи, которая кажется вам рабочей, — попробуйте переформулировать контекст: уточнить профессиональную цель, добавить явную роль.

Третий аспект — особенности форматирования: некоторые модели возвращают ответы с большим количеством Markdown-форматирования по умолчанию, другие — в виде сплошного текста. Явная инструкция по формату из параграфа 3.2.2 решает это, но нужно помнить, что «умолчания» у разных моделей разные.

Типичные ошибки продвинутого промпт-инжиниринга

Ошибка 1: CoT там, где он не нужен

В чём: пользователь добавляет CoT-инструкцию к каждому промпту как «магический улучшитель». Для простых задач (написать объявление, перевести абзац, ответить на фактический вопрос) CoT добавляет объём без качества и замедляет ответ.

Как правильно: CoT — инструмент для задач с многофакторным рассуждением. Для простых задач с однозначным ответом — стандартный чёткий промпт по КЗФО лучше.

Ошибка 2: Few-shot примеры из «чужой» области

В чём: пользователь берёт few-shot примеры из интернета или учебника, не адаптируя их под свой контекст. Модель обучается на чужом стиле, терминологии, форматах — и воспроизводит их вместо нужных.

Как правильно: few-shot примеры должны быть из вашей реальной практики — образцы ваших реальных текстов, классификаций, анализов. Это единственный способ передать специфику вашего контекста через примеры.

Ошибка 3: JSON-промпт без теста на парсинг

В чём: пользователь пишет JSON-промпт, получает ответ, который выглядит как JSON, — и использует его без проверки корректности. Модели иногда возвращают «почти JSON» с ошибками (лишними запятыми, некорректными кавычками, добавленными комментариями), который ломается при парсинге.

Как правильно: проверяйте JSON-вывод через онлайн-валидатор (jsonlint.com или аналог) перед тем как встраивать в рабочий процесс. Для регулярного использования добавьте в промпт: «Убедись, что JSON валиден. Если нет — исправь перед ответом».

Ошибка 4: Длинный контекст как замена критического мышления

В чём: «Я загрузил все документы — теперь ИИ сам во всём разберётся». Даже с 1 миллионом токенов контекста модель не заменяет профессиональное суждение о том, что в этих документах важно, что противоречиво и что требует внимания.

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

Ошибка 5: Один системный промпт на все задачи

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

Как правильно: системные промпты создаются под конкретные типы задач. У хорошей библиотеки — несколько системных промптов: один для редактуры текстов, другой для аналитики, третий для коммуникации с клиентами. Переключаетесь между контекстами — переключаете системный промпт.

Кейс 2026: Аналитик инвестиционного фонда — от ручного скрининга к системе промптов

Игорь — старший аналитик в российском венчурном фонде ранних стадий. Ключевая задача: первичный скрининг стартапов — оценка питч-деков и кратких описаний для решения о встрече с основателями. До систематизации промптов: около 40–50 стартапов в месяц, первичный анализ каждого — 45–60 минут.

Игорь начал с простого: попросил языковую модель помочь ему сформулировать критерии оценки. Результатом стал список из 12 критериев с описанием того, что означает «сильно» и «слабо» по каждому. Затем создал системный промпт, превращавший модель в «скрининговый комитет»: не дающий финального вердикта, но структурированно оценивающий по каждому критерию.

Ты — аналитик венчурного фонда с фокусом на B2B SaaS и deep tech.

Твоя задача — первичный скрининг стартапа по питч-деку или описанию.

Для каждого стартапа:

1. Оцени по 12 критериям (ниже). Оценка: 1–5 + обоснование (2 предложения).

2. Выдели 2–3 главных сильных стороны.

3. Выдели 2–3 главных red flags.

4. Сформулируй 3 вопроса, которые аналитик должен задать на встрече.

5. Итог: recommend / pass / need_more_info.

Критерии: [список из 12 критериев с описанием]

Формат: структурированный текст с явными заголовками.

Тон: нейтральный аналитический, без энтузиазма.

Результаты через три месяца: время на первичный анализ одного стартапа сократилось с 45–60 минут до 15–20 минут (10 минут на загрузку и запрос, 5–10 минут на проверку и уточнение). Пропускная способность выросла: Игорь стал обрабатывать 80–100 стартапов в месяц, не увеличивая рабочее время. Качество не снизилось — по оценке партнёров фонда, структурированные аналитические записки стали более последовательными и полными.

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

Второй урок: промпт для анализа software-стартапа не работал для hardware и deeptech. Пришлось создать три отдельных варианта системного промпта — по типу стартапа. Универсальный шаблон оказался неэффективным там, где специфика отрасли критически важна для оценки.

Честное ограничение: ИИ-анализ — первый фильтр, не замена суждению. Два стартапа, которые модель оценила низко, но которые Игорь всё равно встретил «по интуиции» — показали более интересные результаты, чем предсказывал алгоритм. Суждение аналитика, накопленное за 7 лет работы с основателями, — не заменяется текстовым анализом питч-дека. Системный промпт заменил рутинный скрининг, но не инвестиционное суждение.

Ключевой вывод кейса

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

Контрольные вопросы к Главе 4

1. (Применение) Вам нужно выбрать, в каком городе открыть второй офис компании. Есть три кандидата: Москва, Санкт-Петербург, Екатеринбург. Напишите CoT-промпт для этого решения: определите, по каким шагам должна идти модель, прежде чем дать рекомендацию. Укажите, какой контекст о компании нужно добавить.

2. (Анализ) Few-shot промпт с тремя примерами даёт хорошие результаты для анализа положительных отзывов, но систематически ошибается при анализе негативных. Предложите две возможные причины этой проблемы и опишите, как скорректировать промпт для каждой причины.

3. (Применение) Напишите системный промпт для ассистента, который будет помогать вам с одним конкретным типом задач из вашей профессии. Системный промпт должен содержать все четыре блока (роль, контекст, стиль, ограничения). После написания: какой блок оказался наиболее сложным для формулировки и почему?

4. (Оценка) Игорь из кейса обнаружил, что модель систематически завышает оценки стартапам с хорошим нарративом. Почему это происходит с точки зрения механики работы языковой модели (вспомните Главу 1)? Какие ещё систематические смещения можно ожидать в подобной задаче скрининга?

5. (Синтез) У вас есть 200-страничный внутренний регламент компании. Предложите два принципиально разных подхода к работе с ним с помощью ИИ: один — через длинный контекст (параграф 4.6), другой — через систему промптов с частичной загрузкой. Для каждого подхода: назовите задачи, для которых он предпочтителен, и задачи, для которых он не подходит.

→ К Главе 5: Мультимодальный промптинг

Главы 3 и 4 охватывают работу с текстом. Глава 5 разбирает то, что стало нормой в 2025–2026 годах: работу с изображениями, аудио, документами и видео в едином промпте. Граница между «текстовым ИИ» и «остальными» практически стёрта.

Глава 5. Мультимодальный промтинг

Часть II. Язык взаимодействия: промпт-инжиниринг

Учебные результаты: построить мультимодальный промпт для документа, изображения и аудио; создать полный контент-кит из одного исходного материала.

5.1 Мультимодальность: что это значит для пользователя

5.1.1 Omni-модели: текст + изображение + аудио + видео в одном запросе

В 2022 году граница между «языковой моделью» и «моделью для изображений» была чёткой и непреодолимой. Одни системы понимали текст, другие — картинки, третьи — звук. Соединить их вместе требовало отдельной инженерии, нескольких API и специалиста, который умеет их связывать. К 2026 году эта граница практически стёрта — и это меняет не только инструменты, но и сам способ постановки задачи.

Современные omni-модели (от латинского omni — «всё») принимают любую комбинацию входных данных: текст, изображение, аудиозапись, видеофрагмент — и генерируют ответ в одном или нескольких форматах одновременно. Пользователь больше не выбирает «нужна мне языковая модель или модель для изображений» — он описывает задачу и прикладывает нужные файлы. Модель разбирается, что с ними делать.

На практике это означает принципиально иной дизайн промпта. В одном запросе вы можете приложить скриншот интерфейса и попросить выявить UX-проблемы; загрузить аудиозапись переговоров и получить структурированный протокол с задачами и ответственными; вставить PDF-договор и задать конкретный вопрос по одному разделу; подать фотографию доски с задачами и получить таблицу для Jira или Notion. Это не последовательность отдельных шагов через разные сервисы — это один запрос, один ответ.

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

Мультимодальный промпт— запрос, содержащий данные более чем одного типа (текст + изображение, текст + аудио, текст + документ и т.д.), адресованный модели, способной обрабатывать несколько модальностей одновременно.

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 Автоматическое заполнение форм

Рутинная задача, которую редко рассматривают как мультимодальную: заполнение стандартных форм — анкет, заявок, типовых бланков — по имеющимся данным из другого документа.

Типичный сценарий: у вас есть исходный документ с данными (паспорт сотрудника, регистрационная карточка компании, резюме, выписка из реестра) и форма, которую нужно заполнить (анкета для тендера, заявление в орган, форма партнёрской регистрации). Задача для модели: извлечь нужные данные из исходника и подставить в форму в нужном формате.

Промпт: «Вот исходный документ с данными о компании [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 Почему языковые модели плохо знают ваши данные

6.1.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 секунд.

6.2.3 Шаг «поиск + генерация»: как ИИ отвечает на основе документов

После того как релевантные фрагменты найдены, они включаются в промпт вместе с исходным вопросом. Промпт для языковой модели в RAG-системе содержит три слоя: системная инструкция (роль, правила ответа), найденные фрагменты документов, оригинальный вопрос пользователя.

Системная инструкция задаёт поведение модели при отсутствии ответа в документах. Это критически важно: если нужной информации в найденных фрагментах нет, модель должна сказать «В доступных мне документах ответа на этот вопрос нет» — а не придумать правдоподобный ответ из своих общих знаний. Именно это разграничение делает RAG-систему полезной для работы с корпоративными данными.

Хорошо настроенный системный промпт для корпоративной RAG-системы включает четыре элемента: (1) указание отвечать только на основе предоставленных документов; (2) обязательная ссылка на источник при каждом утверждении; (3) явное признание незнания, если ответа нет в документах; (4) запрет на домысливание, даже если модель «знает» ответ из обучения. Нарушение любого из этих требований превращает RAG-систему в источник правдоподобных, но непроверенных утверждений.

Ссылки на источники — не просто удобство. Они делают ответы проверяемыми. Специалист, получивший ответ «Согласно регламенту управления рисками (раздел 5.3, редакция от 15.01.2025), лимит по сделкам с новыми контрагентами без залога составляет 2 млн рублей», может за 30 секунд открыть этот раздел и убедиться в точности цитаты. Это принципиально другой уровень доверия, чем «ИИ сказал, что лимит 2 миллиона».

6.2.4 Ограничения RAG: когда он не поможет

RAG решает конкретную проблему: дать модели доступ к нужным документам в момент ответа. Он не решает другие проблемы — и важно понимать, где именно проходит эта граница.

RAG не помогает, когда нужного документа просто нет в базе. Система может искать только по тому, что в неё загружено. Если политика, регламент или договор не были включены в индекс — система либо честно ответит «не нашла», либо найдёт и предложит что-то похожее, но не то. Неполная база знаний — самая частая причина неудовлетворительной работы RAG-системы в реальных организациях.

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

RAG не заменяет глубокое понимание предметной области. Если найденный документ сам по себе неточен, устарел или противоречив — RAG усилит эту проблему, не устранит её. Система воспроизводит качество базы знаний, а не улучшает его. Если в базе хранятся устаревшие версии регламентов рядом с актуальными — система может вернуть любую из них.

RAG не работает для задач, требующих длинных цепочек рассуждений через несколько документов одновременно. Найти релевантный фрагмент и ответить на основе него — работает. Провести сравнительный анализ пятидесяти договоров, синтезировать выводы, учесть все исключения из всех документов — здесь RAG-поиск должен быть дополнен более сложной логикой обработки.

Распространённая ловушка: система внедрена, специалисты пользуются ей несколько месяцев, а потом выясняется, что часть регламентов в базе — устаревшие версии. Все ответы, данные на основе этих документов, были «правильными» с точки зрения системы, но не соответствовали актуальным требованиям. RAG-система настолько хороша, насколько хороша её база. Управление версиями документов — организационная задача, которую технология не решает сама по себе.

6.3 Практические реализации для пользователя

Понять концепцию RAG и развернуть работающую систему — разные задачи. Хорошая новость 2026 года: для большинства практических сценариев программирование не требуется. No-code инструменты достигли уровня, при котором специалист без технического фона может создать работающего ИИ-ассистента по своей документации за несколько часов.

6.3.1 No-code инструменты для работы с базой документов

Инструменты этого класса работают по одной логике: загрузить документы, задать вопрос, получить ответ со ссылкой на источник. Различаются возможностями интеграции, объёмом базы, поддерживаемыми форматами, конфиденциальностью обработки и ценой.

Российский контур: GigaChat API Сбера с инструментами для работы с документами позволяет строить ИИ-ассистентов с обработкой данных в российском облаке — это принципиально для организаций, где передача данных за рубеж ограничена. Яндекс Foundry и YandexGPT с документным поиском предоставляют аналогичные возможности в экосистеме Яндекса. Обе платформы имеют no-code интерфейсы для создания баз знаний без программирования и подходят для работы с данными, к которым применяется 152-ФЗ.

Специализированные платформы для управления знаниями с ИИ-поиском в 2026 году имеют встроенные RAG-возможности поверх базы знаний. Они решают задачу «документы + поиск + ИИ» как единый продукт.

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

6.3.2 ИИ-ассистент по папке файлов: настройка без программирования

Для индивидуального использования или небольших команд существует сценарий «подключить папку документов и задавать вопросы» — без корпоративного развёртывания, без технической команды, за время от получаса до нескольких часов.

Наиболее доступный путь в 2026 году: специализированные no-code платформы типа Poe (через корпоративный аккаунт), ChatPDF для работы с отдельными PDF, локальные решения на базе LM Studio или Ollama с подключаемыми плагинами для работы с документами. Для пользователей с базовыми техническими навыками — Dify или AnythingLLM, которые устанавливаются локально и обеспечивают полный контроль над данными.

Рабочий процесс без программирования на примере AnythingLLM (локальная установка): скачать и установить приложение (работает как обычный десктоп), создать «рабочее пространство», загрузить документы (PDF, DOCX, TXT, MD), дождаться индексации (несколько минут для небольшой базы), начать задавать вопросы. Модель работает локально — данные не покидают компьютер. Подходит для документов под NDA или с персональными данными.

Три параметра, которые стоит настроить при первоначальной конфигурации. Первый — размер чанка: для нормативных документов оптимально 300–500 слов, для технических инструкций — 200–300, для деловой переписки — одно письмо как единица. Второй — количество извлекаемых фрагментов (top-k): значение 4–6 обычно даёт достаточно контекста без перегрузки. Третий — формат ссылок на источники: задайте в системном промпте явное требование указывать название документа и раздел при каждом факте.

Ограничение локальных решений — требования к ресурсам компьютера. Для приемлемого качества ответов нужна достаточная оперативная память (16–32 ГБ) и желательно производительная видеокарта. Облачные решения работают на любом устройстве с браузером, но требуют передачи данных на серверы сервиса.

6.3.3 Корпоративные базы знаний и их RAG-интеграции

Корпоративная RAG-система — это не просто «папка документов с поиском». Это система с управлением жизненным циклом документов, разграничением доступа, аудитом запросов, интеграцией с корпоративными инструментами и процедурами обновления базы. Разница между персональным ассистентом и корпоративной системой — это разница между записной книжкой и ERP-системой.

Разграничение доступа — первое требование. Не все сотрудники должны видеть все документы. HR-директор может спрашивать про зарплатные вилки — рядовой сотрудник не должен получать эти данные из той же системы. Это требует интеграции с Active Directory или корпоративной системой управления правами. Хорошая RAG-платформа поддерживает фильтрацию результатов по правам доступа пользователя — плохая возвращает всё из базы без учёта ограничений.

Управление версиями документов — второе требование. Если в базе есть несколько версий одного регламента, система должна знать, какая актуальная, и отвечать на основе именно неё. Это не техническая задача RAG-системы по умолчанию — это организационная задача: назначить ответственных за обновление базы, определить процедуру замены устаревших версий, настроить метаданные документов (версия, дата, статус: действующий / отменён / в редакции). Без этой процедуры база быстро становится неуправляемой.

Аудит и логирование запросов — третье требование. В корпоративном контексте важно понимать, какие вопросы задавались системе и какие ответы давались. Это нужно для контроля качества, выявления пробелов в базе знаний, аудита при расследовании инцидентов. Хорошие корпоративные RAG-платформы имеют встроенный аудит; при самостоятельном развёртывании это нужно предусмотреть отдельно.

Интеграция с рабочими процессами определяет, насколько система используется в реальной работе. RAG-система, изолированная от рабочих инструментов, не даёт полной ценности. Максимум — когда она встроена в интерфейс, где сотрудник и так работает: в корпоративный мессенджер, в систему управления задачами, в почту. Тогда вопрос возникает и задаётся там, где возникает потребность — без переключения контекста.

Экономика внедрения для небольших компаний: корпоративное развёртывание RAG при использовании no-code платформ обходится значительно дешевле, чем кажется. Типичная конфигурация для компании 50–200 человек — cloud-решение на российской платформе с базой 1 000–5 000 документов и 50–200 запросами в день — по оценкам практиков, укладывается в 30 000–80 000 рублей в месяц включая стоимость модели, хранения и интерфейса. Альтернативная стоимость — часы специалистов, потраченные на поиск информации в документах.

6.3.4 Личная база знаний с ИИ-поиском

Персональная база знаний с ИИ-поиском — инструмент, который индивидуально ценен для специалиста, работающего с большим объёмом материалов: исследователя, консультанта, юриста, аналитика, преподавателя. Идея: накапливать заметки, статьи, документы и иметь возможность быстро находить нужное через естественный язык, а не через теги и папки.

Obsidian с плагинами Copilot или Smart Connections — наиболее распространённое решение для исследователей и специалистов. База заметок в Markdown-формате, семантический поиск поверх неё, возможность задавать вопросы через встроенный интерфейс. Данные хранятся локально. Качество поиска зависит от качества заметок — система не улучшает то, что написано плохо.

Notion AI в личном плане — более доступный вариант для тех, кто уже пользуется Notion. Вопросы по базе, суммаризация, поиск по содержанию — без настройки, работает из коробки. Данные в облаке Notion; при работе с чувствительными материалами — фактор, который нужно учитывать.

Ценность личной базы знаний формируется медленно. Первые три месяца — ощущение «я пишу в пустоту». Через полгода активного пополнения система начинает экономить значимое время: «я точно это читал, но где?» превращается в запрос к ассистенту с ответом за 15 секунд. Это не немедленный эффект — это инвестиция с накопительным возвратом.

Практикум 6.А: Создание ИИ-ассистента по папке документов

Задача: за один сеанс работы создать работающего ИИ-ассистента по набору реальных рабочих документов и провести тест качества ответов.

Что делать:

1. Выберите инструмент по своей ситуации: если данные конфиденциальны — AnythingLLM (локальная установка, бесплатно); если данные публичные или внутренние без ограничений — Notion AI или GigaChat с функцией документного поиска.

2. Подготовьте набор из 15–25 реальных рабочих документов одной тематики: регламенты, FAQ, процедуры, шаблоны договоров, приказы. Форматы: PDF, DOCX, TXT — что есть.

3. Создайте новое рабочее пространство в инструменте, загрузите документы, дождитесь завершения индексации.

4. Составьте тестовый список из 10 вопросов трёх типов: (а) прямой фактический вопрос, ответ на который точно есть в документах; (б) косвенный вопрос, требующий синтеза из нескольких документов; (в) вопрос, ответа на который в документах нет.

5. Задайте все 10 вопросов. Для каждого ответа: проверьте ссылку на источник, откройте исходный документ и убедитесь в точности. Зафиксируйте: сколько ответов точны со ссылкой; сколько содержат ошибки; как система повела себя при отсутствующей информации — честно отказала или галлюцинировала.

Ожидаемый результат: работающий ИИ-ассистент с базой из 15–25 документов. Точность по прямым вопросам ≥ 80%, понимание отсутствующей информации — честный отказ хотя бы в 2 из 3 случаев типа (в).

На что обратить внимание: если система уверенно отвечает на вопрос (в), которого в документах нет — переработать системный промпт с более жёстким требованием «отвечай только на основе документов». Если ссылки неточные или отсутствуют — добавить в системный промпт: «При каждом утверждении указывай название документа и раздел».

6.4 Суммаризация и синтез документов

RAG даёт доступ к информации в документах через вопросно-ответный интерфейс. Но работа с документами не сводится только к поиску конкретного факта — она включает понимание целого документа, сравнение нескольких версий, выявление противоречий и слабых мест. Эти задачи требуют другого подхода: не «найди фрагмент», а «обработай документ целиком или несколько документов вместе».

6.4.1 Суммаризация длинных документов

Суммаризация — самая часто используемая операция с документами. Но «суммаризируй этот документ» как промпт даёт посредственные результаты, потому что не задаёт цель и аудиторию. Результат суммаризации, полезный для юриста, принципиально отличается от результата, полезного для генерального директора, который за пять минут до встречи хочет понять суть.

Структура эффективного промпта для суммаризации содержит три компонента: кто будет читать результат и зачем; какой формат нужен (тезисы, нарративный текст, таблица, executive summary); что именно нужно выделить — ключевые выводы, риски, обязательства, сроки, числа.

Промпт для суммаризации технического регламента для руководителя: «Суммаризируй этот регламент для генерального директора, который должен принять решение о его утверждении. Формат: executive summary на одну страницу. Структура: (1) что меняется относительно предыдущей версии; (2) ключевые требования, влияющие на бизнес-процессы; (3) требования к бюджету или ресурсам, если есть; (4) риски неисполнения. Числа и сроки — явно.»

Тот же документ для юриста, проверяющего соответствие 152-ФЗ: «Проверь этот регламент на соответствие требованиям 152-ФЗ. Для каждого раздела, где упоминается обработка персональных данных: цитата из регламента, соответствующая норма 152-ФЗ, оценка — соответствует / требует уточнения / противоречит. Если регламент содержит пробелы в части ПДн — укажи явно.»

Для длинных документов (50+ страниц) стратегия суммаризации зависит от инструмента. Модели с длинным контекстом принимают большие документы целиком — это наилучший вариант при наличии доступа. При ограниченном контексте — иерархическая суммаризация: сначала суммаризировать каждый раздел по отдельности, затем суммаризировать полученные резюме. Качество хуже, чем при работе с полным текстом, но приемлемо для большинства задач.

Принципиальная ошибка: просить «кратко» без указания формата и аудитории. «Кратко» — это 200 слов или 2000? Тезисы или нарратив? С числами или без? Без ответа на эти вопросы модель выберет по умолчанию — и этот выбор может не совпасть с тем, что нужно.

6.4.2 Извлечение ключевых тезисов и структуры

Извлечение (extraction) — операция, при которой из документа берётся конкретная категория информации, а остальное игнорируется. Это точнее, чем суммаризация: суммаризация создаёт сжатое изложение всего; извлечение достаёт только нужное.

Сценарии извлечения с измеримой экономией времени. Извлечение реквизитов из договора: наименования сторон, дата, срок, стоимость, порядок оплаты, ответственность, условия расторжения — за 30 секунд вместо 10–15 минут чтения. Извлечение задач и ответственных из протокола: «Перечисли все задачи из этого протокола. Для каждой: формулировка, ответственный, срок. Если ответственный или срок не указан — отметь явно.» Извлечение технических требований из ТЗ: «Перечисли все функциональные требования из этого технического задания. Нумерацию сохрани из оригинала.»

Для юридических документов извлечение особенно ценно, когда нужно сравнивать несколько договоров по единому набору параметров. Промпт для каждого договора одинаковый; результаты — таблица сравнения. Это аналитика, которую раньше делал юрист вручную часами.

Извлечение структуры — особый вид операции для документов, у которых структура не очевидна из форматирования. Например, длинный нарративный документ без заголовков: «Определи логические разделы этого документа. Для каждого раздела: предполагаемое название, краткое описание содержания (1–2 предложения), диапазон страниц.» Результат — карта документа, с которой потом проще задавать прицельные вопросы.

6.4.3 Сравнение нескольких документов

Сравнительный анализ нескольких документов — задача, где языковые модели с длинным контекстом дают наибольший прирост продуктивности. Сравнить пять версий договора по двадцати параметрам вручную — несколько часов работы юриста или специализированный инструмент. С языковой моделью — 15–30 минут при правильном промпте.

Принцип работы: все сравниваемые документы подаются в контекст одновременно (или последовательно при ограниченном контексте), задача формулируется как сравнение по конкретным критериям. Модель находит структурные и содержательные различия между документами при правильно сформулированном запросе.

Промпт для сравнения трёх версий регламента: «Перед тобой три версии регламента управления инцидентами: V1 (2022), V2 (2023), V3 (2025). Для каждого из следующих аспектов опиши, что изменилось от версии к версии: (1) ответственные роли; (2) сроки реагирования; (3) эскалация; (4) отчётность. Если аспект не изменился — укажи это явно. Если в какой-то версии аспект отсутствует — укажи отсутствие.»

Для сравнения договоров с разными контрагентами по стандартному набору параметров эффективен формат «таблица-чек-лист»: «Сравни три договора поставки и заполни таблицу: строки — критерии (срок, стоимость, условия оплаты, ответственность за нарушение сроков, порядок расторжения, форс-мажор); столбцы — Договор А, Договор Б, Договор В. В каждой ячейке — краткое содержание соответствующего условия или "не указано".»

Ограничение: при очень большом количестве длинных документов (20+ договоров по 30 страниц) одновременная обработка требует модели с контекстным окном на несколько миллионов токенов. Альтернатива — двухэтапный процесс: сначала провести извлечение реквизитов из каждого документа по отдельности, затем сравнивать уже извлечённые структурированные данные. Двухэтапный процесс надёжнее в этом сценарии.

6.4.4 Поиск противоречий и слабых мест

Критический анализ документа — задача, где языковая модель может сыграть роль рецензента, который не устаёт и не пропускает детали из-за знакомости текста. Когда документ писали одни и те же люди месяцами, они часто не замечают внутренних противоречий, неясных формулировок и пробелов — «замыленный глаз». Модель читает текст «свежо» каждый раз.

Для регламентов и процедур: «Найди в этом регламенте пункты, которые: (1) противоречат друг другу; (2) не определяют ответственного за выполнение; (3) не устанавливают срок или критерий завершения; (4) допускают неоднозначную интерпретацию. Для каждого найденного пункта: цитата, тип проблемы, краткое описание.»

Для договоров: «Проверь этот договор с позиции стороны А. Найди пункты, которые: (1) создают непропорциональную ответственность для стороны А; (2) дают стороне Б одностороннее право изменить условия; (3) содержат размытые формулировки, которые можно трактовать в пользу стороны Б при споре; (4) противоречат законодательству РФ — укажи, какому именно.»

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

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

Пример: методист образовательной программы использует модель для рецензирования учебных программ курсов перед утверждением. Промпт: «Проверь эту программу курса. Найди: (1) учебные результаты, которые не поддерживаются содержанием; (2) темы без явного LO; (3) оценочные задания, не соответствующие среднему уровню заявленных критериев обучения; (4) пробелы в логике — где порядок тем нарушает принцип от простого к сложному.» До внедрения: каждая программа рецензировалась 3–4 дня. После: первичный список замечаний — 15 минут, финальная рецензия методиста — 1–2 часа. Общее время сократилось в 3–4 раза.

Практикум 6.Б: Сравнение версий документа с извлечением ключевых расхождений

Задача: провести сравнительный анализ двух версий одного документа и получить структурированный отчёт об изменениях.

Что делать:

1. Найдите два документа, которые представляют разные версии одного и того же: два варианта договора с одним контрагентом, два издания внутреннего регламента, черновик и финальная версия технического задания. Если реальных нет — два похожих публичных документа (уставы схожих организаций, положения об одном органе из разных регионов).

2. Составьте список из 6–8 критериев сравнения, важных для вашей предметной области. Примеры для договора: стороны, срок действия, стоимость, порядок оплаты, ответственность за нарушение, расторжение, форс-мажор, подсудность.

3. Сформулируйте промпт: «Ниже два документа. Сравни их по следующим критериям: [список критериев]. Для каждого критерия: что в документе 1, что в документе 2, есть ли значимое расхождение (да/нет). Если критерий отсутствует в одном из документов — укажи явно. Выдай результат таблицей.»

4. Загрузите оба документа и задайте промпт.

5. Проверьте 3–4 ячейки таблицы по первоисточнику: откройте соответствующее место в документе и убедитесь, что модель воспроизвела содержание корректно.

Ожидаемый результат: сравнительная таблица по всем критериям. Время выполнения: 15–25 минут включая выбор документов и проверку.

На что обратить внимание: проверьте, не «придумала» ли модель содержание для критерия, которого в документах нет, вместо «не указано». Для очень длинных документов (30+ страниц каждый) — проверьте, не потеряла ли модель фрагменты из середины: у некоторых моделей есть феномен «потери середины», когда контент из центра длинного текста извлекается хуже, чем начало и конец.

Типичные ошибки

1. База знаний без управления версиями

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

✓ Как правильно: назначить ответственного за обновление базы. При каждом обновлении документа — удалить старую версию из базы, загрузить новую с чёткими метаданными (дата, версия, статус). Лучше маленькая, но актуальная база, чем большая с устаревшим контентом.

2. «Суммаризируй это» без указания аудитории и формата

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

✓ Как правильно: всегда задавать три параметра — кто читатель, какой формат нужен (тезисы, нарратив, executive summary, таблица), что именно нужно выделить. Промпт в три строки даёт результат в три раза лучше.

3. Доверие ответу без проверки ссылки на источник

В чём состоит: RAG-система дала ответ с указанием источника. Специалист принял ответ, не открыв документ. В 10–15% случаев (по опыту практиков) ссылка либо неточная, либо фрагмент вырван из контекста, меняющего смысл.

✓ Как правильно: для решений с последствиями (юридическими, финансовыми, операционными) всегда открывать исходный документ и читать указанный раздел. RAG — инструмент быстрого нахождения, не замена верификации.

4. Один промпт для всех задач с документами

В чём состоит: один шаблон «кратко изложи суть» применяется и для суммаризации, и для извлечения, и для критического анализа. Разные задачи дают одинаково средний результат.

✓ Как правильно: три заготовленных промпта покрывают 80% работы с документами. Суммаризация: «изложи для [аудитория] в формате [формат]». Извлечение: «перечисли только [конкретные элементы]». Критический анализ: «найди проблемы типа [конкретные типы]».

5. Игнорирование проблемы «потери середины»

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

✓ Как правильно: для критически важной информации из середины длинного документа — вырезать соответствующий раздел и обрабатывать отдельным запросом. Или явно указать в промпте: «Особое внимание разделу [название/номер] — убедись, что он обработан полностью».

Кейс 2026: Юридическая фирма — ИИ-ассистент по 5 000 документам клиентской базы

Контекст: московская юридическая фирма среднего размера (18 юристов) специализируется на корпоративном праве и M&A. За 12 лет работы накоплено около 5 000 документов: договоры, корпоративные документы клиентов, заключения, переписка с контрагентами. Документы хранятся в структурированных папках на корпоративном файловом сервере, но поиск — только через Windows Search.

Проблема: при работе над новым проектом юрист тратил от 40 минут до 2,5 часов на поиск релевантных прецедентов и аналогичных конструкций в прошлых документах. «Я помню, что мы решали похожую ситуацию с залогом года три назад, но не помню, для кого» — типичная ситуация. Знание было в базе, но добраться до него было слишком дорого.

Решение: фирма развернула RAG-систему на базе корпоративного сервера без передачи данных в облако — требование клиентских NDA. Стек: локальная языковая модель среднего размера, векторная база на базе открытого решения, веб-интерфейс для юристов. Индексация всех 5 000 документов заняла около 14 часов машинного времени. Разбиение на чанки: для договоров — по разделу (200–600 слов), для заключений — по тезису.

Использование: юрист через веб-интерфейс задаёт вопрос на естественном языке — «Как мы формулировали условие о конкурентных ограничениях в M&A-сделках для продавцов из технологического сектора?» Система возвращает 4–6 релевантных фрагментов с указанием документа, клиента (анонимизированного) и раздела. Юрист читает фрагменты и открывает полный документ при необходимости.

Результаты через 6 месяцев. Среднее время поиска прецедентов сократилось с 1 ч 20 мин до 18 мин (по внутренней оценке партнёров на выборке из 30 задач). Специалисты начали находить релевантные прецеденты, о существовании которых не знали — система «помнит» больше, чем помнят юристы. Несколько раз система нашла противоречие между условиями двух действующих договоров одного клиента, что при ручном поиске вряд ли было бы обнаружено.

Ограничения, которые фирма зафиксировала честно: качество поиска заметно хуже для документов, оформленных нестандартно или содержащих много сканированных страниц плохого качества. Система не умеет самостоятельно отслеживать изменения законодательства. Часть юристов принимает результаты поиска без проверки исходного документа — с этим приходится бороться организационно.

Вывод: 30% экономии времени на поиск — консервативная оценка. При 18 юристах это значимая цифра. Более важный эффект: снижение потерь знания при ротации команды. Когда юрист уходит из фирмы, его знание о прошлых сделках остаётся в системе.

Контрольные вопросы

1. Ваша организация хочет создать ИИ-ассистента по внутренней базе нормативных документов. Среди документов есть положения о зарплате и кадровые приказы. Опишите, как вы будете выбирать инструмент и какие требования к безопасности данных предъявите, учитывая российское законодательство. Обоснуйте каждое решение.

2. Вам нужно сравнить пятнадцать однотипных договоров поставки по восьми параметрам. Опишите пошаговый процесс — от получения документов до итоговой таблицы — включая промпты, которые вы используете на каждом шаге. Учтите, что некоторые договоры могут быть длиннее контекстного окна модели.

3. Специалист сообщает, что RAG-система их отдела «иногда даёт устаревшие ответы». Перечислите не менее трёх возможных причин этой проблемы и объясните, как диагностировать каждую. Для каждой причины — конкретное организационное или техническое решение.

4. Вам поручили написать критику 40-страничного проекта регламента с позиции его исполнимости. Составьте промпт для этой задачи: он должен задавать конкретные критерии анализа, формат вывода и инструкцию по поведению модели при неоднозначных ситуациях. Объясните, почему вы включили каждый элемент.

5. Сравните два подхода к работе с базой документов: (А) специалист каждый раз копирует нужный документ в чат и задаёт вопрос; (Б) настроена RAG-система с индексом базы. Для каждого назовите две задачи, где он работает лучше, и объясните почему. Когда разница в качестве принципиальна, а когда несущественна?

Глава 7. ИИ и работа с информацией и данными

Часть III. Знания и данные

Учебные результаты: провести анализ данных без программирования - от сырой таблицы до аналитических выво