Александр Костин – ИИ для управления проектами: планы, риски, сроки, контрольные точки (страница 4)

Третий: сузить задачу до одного результата. Плохие ответы часто возникают, когда вы просите «всё сразу». Разбейте: «Сейчас сделай только первый экран», или «Сейчас дай только план проверки гипотез», или «Сейчас выпиши только риски и как их закрыть».

Обычно после этого качество резко повышается, потому что модель перестаёт распыляться.

Мини-чеклист перед отправкой любого важного запроса

Перед тем как нажать Enter, пробегитесь по пяти вопросам.

Ясно ли, какой результат нужен, а не просто тема?

Есть ли минимальный контекст, без которого ответ будет общим?

Есть ли запреты, чтобы исключить выдуманные факты и «красивые детали»?

Задан ли формат, чтобы ответ был структурой, а не рассказом?

Есть ли критерии качества, по которым я смогу принять или отклонить результат?

Если на два и более вопроса ответ «нет», вы почти гарантированно получите воду или фантазии. И это не «плохой ИИ». Это просто недостроенный запрос.

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

Глава 3. Контекст, который реально нужен: как давать минимум данных и получать максимум точности

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

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

Почему «контекст» – это не объём, а релевантность

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

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

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

Три уровня контекста: базовый, рабочий, экспертный

Не всегда нужно давать всё. У контекста есть уровни, и важно понимать, какой нужен для конкретной задачи.

Базовый контекст – для простых задач: текст, идеи, структура, шаблоны. Обычно достаточно 6–10 строк: кто аудитория, цель, тон, ограничения, формат результата, что нельзя делать.

Рабочий контекст – для задач, где есть риск ошибиться и где важна применимость: стратегия, план действий, анализ причин, позиционирование, коммерческие предложения, регламенты. Здесь нужно 10–20 строк, но они должны быть параметрическими: ресурсы, сроки, ограничения, текущая точка, что уже пробовали, критерии успеха.

Экспертный контекст – для задач, где важны детали процесса и зависимости: сложные интеграции, юридические нюансы, аналитика, финансы, медицина, большие проекты. Здесь нужен не «больше текста», а структура данных: список фактов, таблица параметров, выдержка ключевых документов, либо точная выдержка из логов/ошибок/метрик. Иногда нужен файл, иногда – цитата из конкретного абзаца. Но принцип тот же: структурированность важнее объёма.

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

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

Есть набор полей, которые полезны в 80% задач. Это ваша «карточка запроса». Если вы научитесь быстро заполнять эти поля, вы перестанете терять время на переписки.

Цель: что должно измениться после результата (метрика, решение, документ, согласование).

Объект: что именно делаем (страница, текст, процесс, кампания, интеграция, глава книги).

Аудитория: кто будет читать/пользоваться (сегмент, опыт, боли, ожидания).

Ограничения: юридические, этические, брендовые, платформенные (что нельзя).

Ресурсы: кто делает и сколько времени (1 человек 2 часа или команда 2 недели – это разные решения).

Сроки: дедлайн и этапность (нужно «сегодня» или «в течение месяца»).

Текущая точка: что уже есть сейчас (черновик, метрики, текущая версия, результаты тестов).

Желаемый формат: как должен выглядеть результат (структура, объём, выходной артефакт).

Критерии качества: по чему вы примете результат.

Это не бюрократия. Это минимальная рамка, которая делает ответ предсказуемым.

Два типа вводных: факты и интерпретации, их нужно разделять

Очень частая причина ошибок – когда пользователь смешивает факты и свою интерпретацию. Модель воспринимает всё как истину и строит ответ на неверном основании.

Факт: «конверсия снизилась с 2,4% до 1,7%».

Интерпретация: «конверсия упала из-за плохого дизайна».

Факт: «в карточке товара добавили новый блок».

Интерпретация: «этот блок отвлекает и мешает покупать».

Если вы хотите, чтобы модель помогла вам думать, а не просто согласилась, вы должны разделять эти две части. Тогда модель может предложить альтернативные объяснения и план проверки.

Практический вывод: пишите вводные в двух разделах. «Факты» – то, что наблюдаемо. «Гипотезы/мои предположения» – то, что вы думаете. И отдельно попросите: «проверь гипотезы, предложи альтернативы, составь план проверки».

Как давать цифры и метрики так, чтобы не получить мусор

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

Плохие вводные: «трафик упал», «CTR низкий», «продаж мало», «бюджет большой».

Хорошие вводные: «трафик -12% неделя к неделе, органика -18%, платный +3%», «CTR в поиске 5,2% был, стал 3,9% после изменения заголовков», «конверсия в заявку 1,1% при 30 000 посетителей/мес», «бюджет 200 000 ₽/мес, цель – 120 лидов, текущая цена лида 2 900 ₽».

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

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

Чего не надо давать: контекст-шум

Есть типы информации, которые часто не помогают и даже мешают.

Длинные эмоциональные описания: «нас достали», «всё плохо», «клиент не понимает». Это понятно по-человечески, но для модели это шум, если вы не превращаете это в ограничения и критерии.

История компании «с основания»: если это не влияет на задачу, лучше убрать.

Переписка целиком: обычно полезнее вытащить 5–10 ключевых тезисов и требований, чем залить весь чат.

Смешивание нескольких задач в одном контексте: модель начинает перескакивать и выдаёт общий текст.

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

Контекст как «карточка проекта»: самый удобный формат

Один из лучших способов – держать «карточку проекта» и вставлять её в запросы. Это экономит время и даёт стабильное качество. Карточка – это не документ на 10 страниц, а 12–20 строк с параметрами.

Пример структуры карточки для маркетинга/контента:

Проект: что продаём, где, сегмент.

ЦА: 2–3 сегмента и ключевые боли.

Цель: метрика и срок.

Ограничения: юридические, бренд, что нельзя обещать/упоминать.

Каналы: что используем, что запрещено, что пробовали.