Kitabı oxu: «Работа с нейросетями. ChatGPT, Claude, Gemini и другие AI-инструменты без лишней теории»

Глава 1. Не разговаривайте с нейросетью как с оракулом

Самая дорогая ошибка при работе с нейросетями выглядит безобидно. Человек открывает ChatGPT, Claude или Gemini, пишет вопрос так, как написал бы знакомому в мессенджере, получает складный ответ и принимает его за результат. Иногда это работает. Именно поэтому привычка закрепляется. Модель вежлива, текст гладкий, аргументы связаны, а уверенный тон создаёт впечатление, что где-то внутри действительно сидит специалист, который понял задачу, проверил факты и только после этого сформулировал вывод.

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

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

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

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

У промпта нет волшебной формулы

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

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

Это хороший ориентир. Не нужно становиться «промпт-инженером», который час шлифует одну фразу. Нужно научиться проектировать работу.

Вместо:

«Ты лучший маркетолог мира. Придумай крутую рекламу нашей школы»

полезнее написать:

«Мы продаём индивидуальные онлайн-занятия по русскому языку для родителей учеников 1–4 классов. Родитель уже прошёл с ребёнком пробное занятие и получил обратную связь учителя. Нужны пять рекламных сообщений для переписки после пробного урока. Цель — не давить на покупку, а перевести родителя к обсуждению подходящего пакета. Частые сомнения: “хочу посоветоваться” и “сначала пройдём пробные в других школах”. Не обещай гарантированный результат и не используй фразы “уникальная методика”, “лучшие преподаватели”, “места заканчиваются”. Каждое сообщение до 500 знаков. Сделай пять разных подходов и после каждого в одной строке объясни, на каком мотиве он построен».

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

Что нейросеть действительно «видит»

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

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

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

Хороший контекст не равен большому контексту. Сотня страниц документов может быть хуже двух страниц, если в них нет нужной информации или если документы противоречат друг другу. Умение отбирать входные данные часто важнее умения писать эффектные промпты.

Три режима доверия

Полезно заранее решить, насколько вы имеете право доверять ответу. Для этого можно разделить задачи на три режима.

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

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

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

Перед сложной работой задайте себе один вопрос: «Что произойдёт, если модель уверенно ошибётся?» Ответ определит, сколько проверки нужно заложить в процесс.

Не просите ответ, проектируйте результат

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

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

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

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

Первая версия почти никогда не должна быть последней

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

Гораздо эффективнее работать короткими циклами. Сначала получить скелет. Затем проверить, где модель неправильно поняла задачу. Потом добавить недостающие данные. После этого потребовать второй вариант, уже с учётом критериев. Наконец, провести отдельную проверку.

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

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

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

Глава 2. Как выбирать ChatGPT, Claude, Gemini и другие сервисы

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

Поэтому выбирать стоит не победителя абстрактного теста, а связку «задача + рабочая среда + цена проверки».

Сначала определите тип работы

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

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

ChatGPT: универсальная рабочая среда

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

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

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

Claude: длинная интеллектуальная работа и код

Claude часто удобен в проектах, где приходится долго удерживать структуру, читать большие массивы текста, редактировать длинные документы, проектировать решения или работать с кодом. Проектные пространства, коннекторы, MCP и инструменты разработки делают его сильной второй средой даже для пользователя, который ведёт повседневную работу в другом сервисе.

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

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

Gemini: длинный контекст, мультимодальность и экосистема Google

Gemini особенно интересен, когда исходные данные уже находятся в Gmail, Docs, Sheets, Drive и других сервисах Google либо когда задача опирается на очень длинные материалы, изображения, видео и мультимодальный контекст. В таких случаях выигрыш часто появляется не из-за «умности вообще», а из-за меньшего числа ручных переносов между системами.

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

Практический выбор: Gemini особенно силён, когда ценность создают длинный контекст, мультимодальность и тесная работа с Google-сервисами.

Perplexity: исследование начинается с источника

Perplexity вырос вокруг поиска и синтеза источников. Его естественная задача звучит не «что ты знаешь?», а «что можно найти сейчас и чем это подтверждается?». Он особенно удобен для первичного исследования рынков, компаний, технологий, новостей и других быстро меняющихся тем.

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

Практический выбор: Perplexity полезно рассматривать как исследовательский слой, а не как последнюю инстанцию.

Grok и специализированные инструменты

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

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

Как выбирать модель внутри одного сервиса

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

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

Сравнивайте на своих задачах, а не по рейтингу

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

Такой тест за час даёт больше практической информации, чем десятки роликов о том, какая модель «уничтожила» конкурента.

Когда имеет смысл вторая нейросеть

Вторая система полезна, если у неё появляется отдельная роль. Один инструмент собирает источники, другой проверяет вывод. Один агент изменяет репозиторий, другой делает review по diff и тестам. Одна модель работает внутри корпоративной экосистемы, другая получает очищенную выжимку и выступает независимым критиком.

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

Практический выбор за минуту

Если нужна одна универсальная среда для самых разных задач, начните с ChatGPT. Если основная работа состоит из больших текстов, кода и длительного интеллектуального сотрудничества, протестируйте Claude на своих реальных проектах. Если большая часть контекста живёт в Gmail, Docs, Sheets и Drive или вам регулярно нужен очень длинный мультимодальный вход, проверьте Gemini. Если первая задача — свежий веб и проверяемые источники, начните с Perplexity. Если важны оперативные данные из X и связанные с ним сценарии, отдельно оцените Grok.

И не покупайте второй тариф до собственного теста. Хороший инструмент — не тот, чей первый ответ звучит эффектнее, а тот, с которым вы стабильно быстрее получаете проверенный результат.

Глава 3. Разбивайте работу, а не промпт

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

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

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

Определите конечное решение

Начинайте не с текста промпта, а с вопроса: какое решение станет возможным после работы?

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

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

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

Когда цель ясна, этапы начинают выстраиваться естественно.

Схема: собрать, преобразовать, проверить, решить, оформить

Для многих сложных задач работает пятиступенчатая схема.

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

Потом преобразование. Данные очищаются, группируются, сокращаются, классифицируются, переводятся в сравнимый вид.

Третий этап — проверка. Ищутся пропуски, противоречия, ошибки расчётов, слабые источники, нарушения ограничений.

Четвёртый — решение. На основе подготовленного материала модель формирует вывод, приоритеты или варианты действий.

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

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

Пример: выбор квартиры

Плохой запрос:

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

Даже если сервис умеет искать в интернете, здесь слишком много скрытых решений. Что значит «рядом»? Какой бюджет? Что считать двухкомнатной? Нужна ли мебель? Как проверять актуальность объявления? Входит ли коммуналка? Как оценивать район?

Рабочий процесс может выглядеть иначе.

Шаг 1. Зафиксировать фильтры: бюджет, районы, расстояние до конкретных точек, животные, этаж, мебель, дата въезда.

Шаг 2. Собрать только актуальные варианты с прямыми ссылками и датой проверки.

Шаг 3. Нормализовать цены: отдельно аренда, залог, комиссия, коммунальные платежи.

Шаг 4. Отбросить варианты, не проходящие жёсткие условия.

Шаг 5. Оценить оставшиеся по шкале и отдельно указать неизвестные данные.

Шаг 6. Сформировать короткий список вопросов владельцу по каждому финалисту.

Только после ответов владельца выбирать.

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

Контрольные точки

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

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

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

Параллельные ветки

Не все задачи нужно решать последовательно. Иногда полезно поручить модели несколько независимых направлений анализа, а затем объединить результаты.

Например, перед запуском продукта можно отдельно проанализировать:

потребности клиентов;

предложения конкурентов;

экономику;

технические ограничения;

юридические риски.

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

В API и агентных системах подобные ветки можно автоматизировать. В обычном чате их легко сделать вручную в нескольких диалогах. Смысл одинаков: независимые задачи не должны мешать друг другу.

Разделяйте создание и критику

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

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

Пример для текста:

«Ниже черновик коммерческого предложения. Не переписывай его. Сначала выступи редактором-проверяющим. Найди: 1) неподтверждённые обещания, 2) места, где выгода сформулирована абстрактно, 3) повторяющиеся мысли, 4) фразы, звучащие как шаблонный AI-текст, 5) вопросы клиента, на которые документ не отвечает. Для каждого замечания процитируй короткий фрагмент и объясни проблему».

После этого:

«Теперь перепиши документ, исправив только подтверждённые проблемы. Не добавляй новых фактов, которых нет в исходных данных».

Так вы получаете контролируемую редактуру вместо бесконечного «сделай лучше».

Не заставляйте модель показывать скрытое рассуждение

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

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

Вместо:

«Покажи все шаги своего мышления и выбери стратегию»

напишите:

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

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

Передавайте состояние явно

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

Например:

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

Такой снимок можно сохранить в проекте или перенести в новый чат. Он снижает зависимость от огромной истории переписки и помогает заметить, когда модель начала противоречить прежним решениям.

Декомпозиция — это не бюрократия

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

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

Глава 4. Конструкция сильного запроса

После разговора о процессах можно вернуться к самому промпту. Сильный запрос не обязан быть длинным. Он обязан устранять те неопределённости, которые влияют на результат.

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

Цель

Цель отвечает на вопрос «зачем вообще нужен результат?». Модель по-разному напишет один и тот же текст, если он предназначен для принятия решения, обучения новичка или убеждения клиента.

Сравните:

«Объясни разницу между ипотекой и потребительским кредитом».

И:

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

Во втором запросе понятна функция ответа.

Контекст

Контекст включает сведения, без которых модель будет угадывать. Кто аудитория? Что уже произошло? Какие решения приняты? Каковы ваши ресурсы? Что считается успехом?

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

Входные данные

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

Например:

КОНТЕКСТ

Мы продаём подписку для малого бизнеса.

ДАННЫЕ

[вставка отзывов]

ЗАДАЧА

Сгруппируй причины отказа...

Так модель меньше путает текст, который нужно анализировать, с командами.

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

Операция

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

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

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

Ограничения

Ограничения работают лучше, когда конкретны и проверяемы.

Слабо: «не пиши много».

Сильнее: «до 700 слов».

Слабо: «без воды».

Сильнее: «каждый абзац должен либо сообщать новый факт, либо объяснять решение; убери повторение одной мысли разными словами».

Слабо: «пиши живо».

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

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

Формат результата

Формат нужен не ради красоты. Он помогает проверить ответ и использовать его дальше.

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

Один и тот же анализ можно попросить вернуть в разных форматах:

«Сделай таблицу: проблема, доказательство, частота, серьёзность, рекомендуемое действие».

или:

«Дай пять выводов для руководителя. Каждый: один тезис, одна цифра, одно действие».

Формат должен соответствовать следующему шагу работы.

Пример хорошего универсального каркаса

Не нужно копировать шаблон слово в слово. Используйте его как проверочный список.

«Цель: [что должно стать возможным после ответа].

Контекст: [кто мы, что произошло, что уже известно].

Материалы: [вставка, файл, ссылки или описание данных].

Задача: [конкретное действие модели].

Критерии и ограничения: [что обязательно, что запрещено, что считать качеством].

Если данных недостаточно: [задать вопросы / сделать допущения с маркировкой / остановиться].

Формат результата: [структура, объём, таблица, файл, код и т. п.].

Перед финальным ответом проверь результат по этим критериям и исправь обнаруженные несоответствия».

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

Когда нужны примеры

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

Пример должен демонстрировать именно нужный принцип. Не давайте десять почти одинаковых примеров: модель может начать копировать поверхностные детали.

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

Плохо: «Благодарим вас за обращение. Приносим искренние извинения за доставленные неудобства. В целях урегулирования ситуации...»

Хорошо: «Да, вижу проблему. Платёж прошёл, а доступ не открылся. Сейчас проверим статус заказа и вернём доступ либо оформим возврат».

После этого задайте новое сообщение клиента и попросите ответить по тому же принципу, не копируя фразы.

Когда полезна роль

Роль не бесполезна. Просто её переоценивают. «Ты юрист» не добавляет в контекст конкретное законодательство и не гарантирует актуальность. Но роль может помочь выбрать точку зрения и критерии.

Хорошая роль описывает функцию:

«Проведи ревью как редактор научно-популярной книги. Тебя интересуют фактическая точность, логика объяснения и места, где автор выдаёт предположение за факт».

Или:

«Проверь код как инженер, который будет поддерживать его через год. Приоритеты: читаемость, обработка ошибок, тестируемость и отсутствие скрытых зависимостей».

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

Не перегружайте запрос конфликтующими правилами

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

Если ограничения конфликтуют, сначала исправьте саму постановку. Определите приоритеты. Например:

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

Это гораздо лучше, чем одновременно запрещать вопросы и запрещать предположения.

Скажите, что делать при неопределённости

Одна из сильнейших строк в профессиональном промпте звучит примерно так: «Если точного ответа нет, не заполняй пробел догадкой».

Но лучше пойти дальше и объяснить желаемое поведение:

«Разделяй результат на три категории: подтверждено входными данными; вероятный вывод; неизвестно. Для вероятного вывода укажи, на чём он основан».

Или:

«Если источник не подтверждает конкретное утверждение, не ставь его в качестве ссылки. Оставь утверждение неподтверждённым либо найди другой источник».

Или:

«Если в таблице отсутствует значение, используй пустое поле. Не восстанавливай его по соседним строкам без отдельной пометки».

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

Метапромпт: попросить модель помочь поставить задачу

Иногда вы сами не знаете, какие параметры важны. В этом случае нейросеть можно использовать до основного запроса.

«Я хочу выбрать CRM для отдела из 12 менеджеров. Не рекомендуй системы пока. Сначала задай мне вопросы, ответы на которые реально изменят выбор. Не спрашивай то, что можно безопасно принять по умолчанию. После моих ответов сформируй критерии сравнения с весами».

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

Но после интервью всё равно полезно проверить сформулированные критерии. Модель может не знать о специфическом ограничении вашей отрасли.

Промпт — это контракт на один этап

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

Именно поэтому универсальный «идеальный промпт на все случаи» невозможен. Хороший запрос всегда связан с конкретной работой.

Глава 5. Контекст, примеры и длинные документы

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

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

Четыре вида контекста

Полезно различать четыре вида информации.

Первый — факты задачи. Цены, даты, характеристики продукта, правила, история проекта, данные клиента.

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

Третий — примеры. Прошлые документы, удачные ответы, образцы кода, эталонные карточки, тексты, которые нравятся заказчику.

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

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

Что класть в контекст, а что оставлять за бортом

Перед добавлением любого материала задайте три вопроса.

Первый: изменит ли эта информация решение? Если нет, скорее всего, она не нужна.

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

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

Это приводит к полезной практике: подписывайте источники внутри контекста.

Например:

«ИСТОЧНИК A — действующий прайс, обновлён 1 сентября 2026 года.

ИСТОЧНИК B — старая презентация; используй только как пример структуры, цены из неё считать недействительными.

ИСТОЧНИК C — комментарии руководителя; они имеют приоритет при конфликте со старой презентацией».

Одной такой маркировкой можно предотвратить десятки ошибок.

Большой документ не означает, что модель одинаково хорошо использует каждую строку

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

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

Для длинного корпуса хорошо работает двухэтапная схема.

Сначала индекс:

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

Потом задача:

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

Так вы видите, на каком основании модель построила ответ.

Пример как спецификация

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

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

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

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

Few-shot: несколько примеров вместо длинной лекции

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

Это особенно полезно в классификации.

Например, вам нужно разбирать обращения клиентов:

«Категории: возврат, техническая проблема, вопрос по тарифу, жалоба на преподавателя, прочее.

Пример 1. “С карты списали второй раз” → возврат.

Пример 2. “Урок не открывается, белый экран” → техническая проблема.

Пример 3. “Можно ли платить частями?” → вопрос по тарифу.

Теперь классифицируй следующие 200 обращений. Если сообщение подходит к двум категориям, выбери основную и добавь вторичную отдельным полем».

Для нестандартной задачи три хороших примера часто эффективнее двадцати правил.

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

Разделители и структура

Когда в запросе перемешаны инструкции и большие данные, используйте простые разделители. Не обязательно XML. Подойдут Markdown-заголовки, тройные кавычки, блоки «ИНСТРУКЦИЯ», «ДАННЫЕ», «ФОРМАТ».

Важно не украшение, а однозначность.

Для сложного проекта можно использовать такой шаблон:

«# Задача

Проверить новую версию договора.

# Приоритет правил

1. Действующее законодательство и официальный текст договора.

2. Политика компании от 12.09.2026.

3. Старые договоры только как справка.

# Материалы

[файлы]

# Что проверить

...

# Что не делать

Не переписывай договор целиком. Не придумывай юридические последствия без основания.

# Результат

Таблица: пункт, риск, основание, серьёзность, рекомендуемое действие».

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

Контекст должен иметь срок годности

Если вы используете проекты, пользовательские инструкции или постоянные знания, периодически проводите уборку. Старое правило может незаметно конфликтовать с новым.

Представьте, что в январе вы указали «во всех рекламных материалах использовать скидку 20%», а в марте акция закончилась. Через полгода модель получает задачу написать карточку товара и послушно возвращает скидку.

Полезно хранить дату и статус у бизнес-критичных инструкций:

«Действует до 30 сентября».

«Устарело, только для истории».

«Версия 3 заменяет версию 2».

Для постоянного проекта раз в несколько недель просите:

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

Это простая профилактика странных ответов.

Сжатие контекста без потери смысла

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

Хороший паспорт содержит:

цель;

принятые решения;

жёсткие ограничения;

важные факты и цифры;

перечень файлов и их назначение;

что уже пробовали;

нерешённые вопросы;

следующее действие.

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

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

Глава 6. Галлюцинации: как не получить красивую ложь

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

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

Почему просьба «не выдумывай» недостаточна

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

Поэтому борьба с ошибками начинается с конструкции задачи.

Нужно разрешить модели не знать.

«Если данных нет, напиши “нет данных”. Это лучше, чем предположение».

Нужно отделить факт от вывода.

«Для каждого утверждения укажи статус: прямо указано в источнике; логический вывод; предположение».

Нужно создавать проверяемые опоры.

«Для каждого юридического вывода укажи номер пункта договора, на котором он основан».

Нужно применять инструмент, если вопрос требует внешних фактов.

«Проверь актуальную информацию в интернете и используй источники не старше 30 дней».

Ни одна фраза не гарантирует истину. Вместе они делают ошибку заметнее.

Факт, вывод и рекомендация

Полезно требовать три слоя ответа.

Факт: «В таблице конверсия снизилась с 18% до 12%».

Вывод: «Снижение совпало с изменением источника трафика».

Рекомендация: «Проверить качество нового канала на отдельной выборке».

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

Пример запроса:

«Проанализируй данные. Не переходи сразу к рекомендациям. Сначала перечисли только наблюдаемые факты с числами. Затем отдельно дай интерпретации и для каждой укажи альтернативное объяснение. В конце предложи действия, которые позволяют различить эти объяснения».

Это особенно хорошо работает в бизнес-аналитике, диагностике проблем и исследованиях.

Проверяйте цитаты

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

Если вам нужен источник, просите ссылку на первичный материал, DOI, официальный документ или страницу организации. Затем открывайте её. Не ограничивайтесь наличием синей ссылки рядом с текстом.

Проверка источника состоит из трёх вопросов.

Существует ли источник?

Говорит ли он то, что утверждает модель?

Подходит ли он по дате, территории и контексту?

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

Техника «закрытой книги»

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

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

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

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

Двойная проверка расчётов

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

Плохая формулировка:

«Посчитай итог по этим 427 строкам».

Лучше:

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

Два способа подсчёта уменьшают риск тихой ошибки.

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

Красная команда для собственного ответа

Для важных результатов используйте отдельный этап adversarial review, то есть попытку опровергнуть вывод.

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

После этого не просите модель автоматически «исправить всё». Некоторые замечания будут ложными. Сначала решите, какие критические замечания обоснованы.

Вероятность вместо ложной точности

Модель часто любит конкретику. Пользователь спрашивает «сколько будет стоить разработка», а она отвечает «350–450 тысяч рублей», хотя не знает состава команды и объёма проекта.

Разрешите диапазоны и зависимости.

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

Так результат становится инструментом решения, а не декоративной цифрой.

Калибровка уверенности

Просить модель поставить «уверенность 92%» обычно бессмысленно: число не обязано соответствовать реальной вероятности ошибки. Гораздо полезнее спрашивать о качестве основания.

Например:

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

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

Когда нужен человек

Нейросеть ускоряет проверку, но не отменяет ответственность. Если документ подписываете вы, деньги переводите вы, лекарство принимает человек, а код управляет реальным оборудованием, финальный контроль должен соответствовать риску.

Хорошая автоматизация не устраняет человека из любого процесса. Она помещает его туда, где человеческое решение действительно ценно.

Глава 7. Поиск, Deep Research и работа с источниками

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

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

Дата важнее уверенного тона

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

«Проверь информацию на 15 сентября 2026 года».

«Используй источники, опубликованные или обновлённые за последние 30 дней; старые источники привлекай только для истории».

«Если официальный источник и новостная статья расходятся, приоритет у официального источника для текущих правил».

Дата не делает поиск идеальным, но заставляет процесс учитывать свежесть.

Обычный поиск или глубокое исследование

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

Обычный веб-поиск выбирайте, если нужен простой свежий факт: текущая цена, последнее обновление продукта, расписание, новость, определённый документ.

Глубокое исследование оправдано для сравнений, обзора рынка, due diligence, научной темы, сложного путешествия, анализа конкурентов или вопроса, где источники противоречат друг другу.

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

Поставьте исследовательскую задачу правильно

Плохой запрос:

«Изучи рынок онлайн-образования».

Слишком широкий объект породит энциклопедический отчёт, после которого всё равно непонятно, что делать.

Сильнее:

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

Теперь исследование имеет границы и конечное решение.

Иерархия источников

Для разных утверждений подходит разный источник. Универсальной шкалы нет, но можно использовать здравый приоритет.

Для закона — официальный текст закона и государственные разъяснения.

Для функции продукта — документация производителя и release notes.

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

Для научного вывода — оригинальная работа, систематический обзор или авторитетная организация, а не пересказ в СМИ.

Для мнения пользователей — отзывы, форумы, Reddit, сообщества могут быть ценнее официального маркетинга, но они описывают опыт, а не статистическую истину.

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

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

Первичный источник против удобного пересказа

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

Используйте запрос:

«Для каждого правила сначала ищи первичный источник. Вторичные статьи используй для контекста и объяснения, но не как единственное подтверждение требований платформы».

Это относится к OpenAI, Anthropic и Google точно так же. Если вы хотите узнать, как текущий ChatGPT использует данные, читайте актуальный центр конфиденциальности и справку, а не пост 2024 года о старом интерфейсе.

Сравнивайте дату публикации и дату события

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

«В хронологии указывай дату события и дату публикации источника. Если они отличаются более чем на месяц, не называй материал “новым событием” без пояснения».

Это защищает от типичной ошибки в новостных и политических темах.

Исследование с противоположными гипотезами

Если вы хотите понять, стоит ли принимать решение, не задавайте исследованию только одну сторону.

Плохой запрос:

«Найди доказательства, что электромобили выгоднее бензиновых».

Он уже содержит желаемый вывод.

Лучше:

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

Так вы превращаете поиск из машины подтверждения в инструмент решения.

Как читать отчёт Deep Research

Не начинайте с текста. Сначала посмотрите на карту источников. Есть ли официальные и первичные материалы? Не цитирует ли весь отчёт три сайта, которые пересказывают друг друга? Соответствуют ли даты вопросу? Есть ли источники с противоположной позицией?

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

Только затем оценивайте красоту аргумента.

Попросите таблицу доказательств

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

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

Эта таблица иногда ценнее основного отчёта. Она позволяет другому человеку проверить работу без повторения всего поиска.

Поиск не равен исследованию пользователя

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

Поэтому до поиска формализуйте критерии. После поиска проверяйте не только факты, но и соответствие задаче.

Глава 8. Файлы, таблицы, PDF, изображения и мультимодальная работа

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

Но загрузить файл недостаточно. Нужно сказать, что с ним делать.

Начинайте с разведки файла

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

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

Для PDF:

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

Такая разведка предотвращает смешные ошибки, когда модель принимает строку «Итого» за обычный заказ или не замечает, что цены на втором листе указаны без НДС.

Таблицы: не считайте глазами

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

Хороший запрос к таблице состоит из трёх фаз.

Сначала проверка данных:

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

Затем преобразование:

«Создай очищенную копию. Для каждого изменения сохрани журнал: что было, что стало, почему изменение безопасно».

Потом анализ:

«Посчитай конверсию по менеджерам и неделям. Минимальная выборка для сравнения — 30 лидов. Менеджеров с меньшей выборкой вынеси отдельно, не ранжируй их вместе с остальными».

Последняя строка важнее красивого графика. Без неё человек с двумя продажами из трёх лидов легко станет «лучшим менеджером».

Не позволяйте молча чинить данные

Нейросеть любит помогать. Если она видит «12O0» вместо «1200», то может автоматически решить, что буква O является опечаткой. Иногда это правильно. Иногда это код товара.

Укажите политику:

«Не исправляй неоднозначные значения автоматически. Безопасные преобразования, например пробелы по краям, можно сделать. Всё, что меняет смысл, вынеси в список на подтверждение».

Это особенно важно для финансовых, медицинских, юридических и исследовательских данных.

PDF: текст и изображение — не одно и то же

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

Если решение зависит от таблицы или схемы, попросите сначала показать, как модель её поняла.

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

После проверки структуры можно считать.

Для договора полезна другая последовательность:

«Найди все упоминания срока, штрафа, расторжения и автоматического продления. Для каждого дай страницу и короткую цитату. Затем объясни взаимосвязь пунктов».

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

Скриншоты: показывайте, а не описывайте

Если у вас баг интерфейса, гораздо быстрее приложить скриншот, чем писать «кнопка куда-то съехала». Но запрос должен указывать, что именно искать.

«Это реальный скриншот приложения на экране 1080×2400. Не предлагай редизайн. Найди только нарушения адаптивности: элементы, которые обрезаны, перекрываются, выходят за safe area или имеют слишком маленькую область нажатия. Для каждой проблемы укажи визуальный признак и вероятную причину в вёрстке».

Последняя фраза отделяет диагностику от вкусовщины.

Для серии скриншотов полезно сравнение:

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

Изображение как источник данных

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

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

Аудио и видео

С аудио полезно разделять транскрипцию и анализ. Сначала получите расшифровку, желательно с говорящими и временными метками. Затем проверьте несколько спорных мест. Только после этого просите выводы.

Плохой процесс:

«Вот запись созвона, скажи, что решил клиент».

Хороший:

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

Это защищает от ситуации, когда продавец предложил скидку, а модель позже записала её как согласованное условие.

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

Создание файлов

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

Поэтому спецификация должна содержать требования к самому артефакту.

Для таблицы:

«Создай XLSX, а не картинку таблицы. Формулы должны оставаться формулами. Заморозь строку заголовков. Денежные поля отформатируй как числа с двумя знаками. Не используй объединённые ячейки в диапазоне данных. Добавь отдельный лист “Проверка”, где суммы сверяются контрольными формулами».

Для презентации:

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

Для документа:

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

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

Нейросеть может написать верный код, который создаёт неправильный документ. Результат существует только тогда, когда готовый файл прошёл проверку.